IDMA_G2 and IDMA_G3 crash the decon driver when trying to use them
Closed this issue · 7 comments
Symptoms: when using the Exynos7420 BSP, attempting to use the G2 layer will crash the decon driver and the device black screens. It remains this way until rebooting, where the issue will happen again unless G2 is removed from INTERNAL_MPPS.
Log of the crash:
03-12 23:46:04.248 3072 3163 W libEGL : EGLNativeWindowType 0x71f648e440 disconnect failed
03-12 23:46:04.249 3072 3072 D BootAnimation: BootAnimationStopTiming start time: 23167ms
03-12 23:46:04.268 3123 3123 E display : [PrimaryDisplay] ioctl S3CFB_WIN_CONFIG failed: Out of memory
03-12 23:46:04.275 0 0 E [2:composer@2.1-se: 3123] decon_validate_dma_mapping: IDMA2 is mapped to 2
03-12 23:46:04.275 0 0 E [2:composer@2.1-se: 3123] decon_set_win_config: IDMA2 wrong mapping
03-12 23:46:04.280 3123 3123 E display : [PrimaryDisplay] ioctl S3CFB_WIN_CONFIG failed: Out of memory
03-12 23:46:04.287 0 0 E [0:composer@2.1-se: 3123] decon_validate_dma_mapping: IDMA2 is mapped to 2
03-12 23:46:04.287 0 0 E [0:composer@2.1-se: 3123] decon_set_win_config: IDMA2 wrong mapping
03-12 23:46:04.294 3123 3123 E display : [PrimaryDisplay] ioctl S3CFB_WIN_CONFIG failed: Out of memory
03-12 23:46:04.302 0 0 E [0:composer@2.1-se: 3123] decon_validate_dma_mapping: IDMA2 is mapped to 2
03-12 23:46:04.302 0 0 E [0:composer@2.1-se: 3123] decon_set_win_config: IDMA2 wrong mapping
#1 (comment) contains some useful information
There are a couple of ways to go about this:
- Decompile the original HWC and find out how they manage this. It may or may not be helpful. Not sure as I think currently in the Exynos7420 bsp all layers are added to internalMPPs, where as in the samsung source only non VPP_G layers are added
- Kernel mods to get around the limitation, probably overkill and wont work
- Create a solution from scratch. Probably the best idea. Just need to make sure when checking to see if a layer can be assigned, it fails if it isnt at layer 6, and then to work around the other issues that may cause.
After decompiling stock HWC, it is evident the way that it does HWC is different compared to Enesuzun2002s source
Decompiling the S6 (and A810F) HWC, they both make use of mInternalDMAs for VPP_G layers, where as the public HWC released by enesuzun2002 actively clears mInternalDMAs and choses to treat the units as "MPP_VPP_G". I have no idea what method is superior, but I would prefer sticking to stock HWC methods.
IDMA_G0 and IDMA_G1 are added to mInternalDMAs, and IDMA_G2 under certain circumstances is used as a "secure IDMA", and is always bound to window 6, otherwise the kernel throws an error. Only MPP_VG and MPP_VGR units are added to mInternalMPPs.
Upon further examination, it appears that usage of MPP_VPP_G units as opposed to internalDMAs is more similar to the way the S7 handles hardware layers. I have no idea what ramifications going this way has, but I think the way samsung does it should be followed unless theres a good reason why. Currently HWC tends to exhibit some jitter and slowdowns, and they are noticeably less frequent when using the stock method.
Also there are some strange decisions in the code. For example, it treats MPP_VG units as blending capable, even though they are not, and then reimplements methods to stop VG units from being assigned to blending layers. I don't see why this is done.
Cleaning up the code greatly simplifies the repos, and actually allows HWC to function properly with no proper modifications to the samsung_slsi_exynos publicly available BSP. There are also some files that are not built, like virtual display, hwcservices or hwjpeg. I don't see a reason for this either, as they are present in stock.
HWC1 dump:
hdmi_enabled=0
Primary device's config information
type | handle | color | blend | pa | format | position | size | intMPP | extMPP
----------+--------------|----------+-------+----+---------------+---------------+----------------------------------
OVERLAY | 74e9884220 | - | 0 | ff | RGBA8888 | [ 0, 0] | [ 1440, 1263] | [ -, -] | [ -, -]
OVERLAY | 74e98847a0 | - | 0 | ff | RGBA8888 | [ 0, 1298] | [ 1440, 1262] | [ 0, 0] | [ -, -]
OVERLAY | 74e9885b90 | - | 1 | ff | RGBA8888 | [ 0, 1196] | [ 1440, 169] | [ 2, 0] | [ -, -]
OVERLAY | 74e9885fb0 | - | 1 | ff | RGBA8888 | [ 0, 0] | [ 1440, 98] | [ 2, 1] | [ -, -]
FB | 74e9885f00 | - | 1 | ff | RGBA8888 | [ 0, 424] | [ 694, 1627] | [ -, -] | [ -, -]
OVERLAY | - | - | - | - | - | - | - | [ -, -] | [ -, -]
OVERLAY | 74e9885e50 | - | 1 | ff | RGBA8888 | [ 0, 2392] | [ 1440, 168] | [ -, -] | [ -, -]
Primary device's layer information
type | CheckOverlayFlag | CheckMPPFlag | Comp | mWinIndex | mDmaType | mIntMPP | mExtMPP
------------+------------------+--------------+------+-----------+----------+-----------+----------
HWC | 0x 0 | 0x 0 | N | 0 | 1 | [ -, -] | [ -, -]
HWC | 0x 0 | 0x 0 | N | 1 | 2 | [ VG, 0] | [ -, -]
HWC | 0x 0 | 0x 40 | N | 2 | 4 | [VGR, 0] | [ -, -]
HWC | 0x 0 | 0x 40 | N | 3 | 5 | [VGR, 1] | [ -, -]
GLES | 0x 10000 | 0x 40 | N | 4 | 0 | [ -, -] | [ -, -]
HWC | 0x 0 | 0x 0 | N | 6 | 6 | [ -, -] | [ -, -]
FB TARGET | 0x 0 | 0x 0 | N | 4 | 0 | [ -, -] | [ -, -]
GraphicBufferAllocator buffers:
Handle | Size | W (Stride) x H | Layers | Format | Usage | Requestor
0x7d2e670820 | 14400.00 KiB | 1440 (1440) x 2560 | 1 | 1 | 0x 1b00 | FramebufferSurface
0x7d2e670ae0 | 14400.00 KiB | 1440 (1440) x 2560 | 1 | 1 | 0x 1b00 | FramebufferSurface
0x7d2e680cb0 | 147.00 KiB | 448 ( 448) x 84 | 1 | 1 | 0x 303 | RegionSamplingThread
Total allocated by GraphicBufferAllocator (estimate): 28947.00 KB
FlagManager values:
demo_flag: -1
use_adpf_cpu_hint: false
use_skia_tracing: false
Sample from a test LineageOS-20.0 build using stock methods to assign layers. All 7 layers appear to be working. Everything is smooth and stable. No crashing from my tests
As a reference, here is a stock nougat image doing a similar multiwindow situation to use the IDMA units:
hdmi_enabled=0
Primary device's config information
type | handle | color | blend | pa | format | position | size | intMPP | extMPP
----------+--------------|----------+-------+----+---------------+---------------+----------------------------------
OVERLAY | 7733a15120 | - | 0 | ff | RGBX8888 | [ 0, 1289] | [ 1440, 1271] | [ -, -] | [ -, -]
OVERLAY | 7734067c20 | - | 1 | ff | RGBA8888 | [ 0, 1289] | [ 1440, 1271] | [ -, -] | [ -, -]
OVERLAY | 7733a14f40 | - | 0 | ff | RGBX8888 | [ 0, 0] | [ 1440, 1271] | [ 0, 0] | [ -, -]
OVERLAY | 7733a14540 | - | 1 | ff | RGBA8888 | [ 0, 0] | [ 1440, 1271] | [ 2, 0] | [ -, -]
OVERLAY | 7734067220 | - | 1 | ff | RGBA8888 | [ 0, 1196] | [ 1440, 168] | [ 2, 1] | [ -, -]
OVERLAY | - | - | - | - | - | - | - | [ -, -] | [ -, -]
OVERLAY | 7733a15800 | - | 1 | ff | RGBA8888 | [ 1373, 569] | [ 67, 486] | [ -, -] | [ -, -]
Primary device's layer information
type | CheckOverlayFlag | CheckMPPFlag | Comp | mWinIndex | mDmaType | mIntMPP | mExtMPP
------------+------------------+--------------+------+-----------+----------+-----------+----------
HWC | 0x 0 | 0x 0 | N | 0 | 0 | [ -, -] | [ -, -]
HWC | 0x 0 | 0x 0 | N | 1 | 1 | [ -, -] | [ -, -]
HWC | 0x 0 | 0x 0 | N | 2 | 2 | [ VG, 0] | [ -, -]
HWC | 0x 0 | 0x 40 | N | 3 | 4 | [VGR, 0] | [ -, -]
HWC | 0x 0 | 0x 40 | N | 4 | 5 | [VGR, 1] | [ -, -]
HWC | 0x 0 | 0x 0 | N | 6 | 6 | [ -, -] | [ -, -]
FB TARGET | 0x 0 | 0x 0 | N | 8 | -1 | [ -, -] | [ -, -]
Because of this, it is possible to maybe look into using the samsung_slsi-linaro_graphics branch, which is based off android 10 sources, or perhaps the pixel tensor sources for more updated slsi sources. It appears you can still build hwc 1 from the linaro repos (the files still exist anyways), so it might be worth looking into that also.
Still need to fix up virtual display, its a bit unstable at the moment, but there is some good progress on this front.
I have working builds based off linaro sources. Requires a bit of modification to get working, but its nothing major. I think it is safe to say that HWC can be built from source and near 1 to 1 have the same behavior as stock
So in summary:
- Exynos 7420 has 4 MPP_VPP_G units, 2 MPP_VG units and 2 MPP_VGR units as well as 5 external MPP_MSCs
- IDMA_G0 and G1 are able to be used freely
- IDMA_G2 is used as secure DMA and can only be assigned to window 6
- IDMA_G3 is used for virtual display on decon_wb, though this is not working atm (separate issue)
- MPP_VG units are blending incapable, so in practice are used with less frequency
- MPP_VGR and MPP_MSC have the ability to rotate
- Max hardware windows = 7
- Virtual display cant use layer 0