| The display-wake reset: a runtime power collapse too short to discharge GX leaves the a5xx CP alive, and hw_init reprograms CP_RB_BASE underneath it |
finding |
soc:msm8998 |
proven |
| Three of the four a540 GPMU limiter “gaps” are vendor parity; only the throttle bit and the stale power level are real |
finding |
soc:msm8998 |
proven |
| GPU rasterisation is visibly wrong on a540 because the a5xx GMEM store never resolves multisample buffers |
finding |
soc:msm8998 |
proven |
| Holding VDD_MX does not stop the display-wake crash – neither enabled nor at TURBO |
finding |
soc:msm8998 |
proven |
| Mainline’s a540_gpmu.fw2 accepts five voltage-table levels; a sixth stops the GPMU booting at all |
finding |
soc:msm8998 |
proven |
| Mainline a5xx_hw_init programs the A540 at parity with kgsl’s a5xx_start; the one extra mainline write is VPC ALLFLATOPTDIS |
finding |
soc:msm8998 |
proven |
| The a540 GPU faults under Skia-GPU are Skia blur/downsample passes stalling SP/TPL1 – not binning, not fp16, and a different class from the compositor’s one VSC fault |
finding |
soc:msm8998 |
proven |
| The phosh top-right strip is the FIRST GMEM tile, restored with the previous process’s MSAA registers – fd5 tile init never programs them |
finding |
soc:msm8998 |
proven |
| The top-right corruption is freedreno’s GMEM tile path, not a GPU fault – the boundary is the a5xx bin column at x=1024 |
finding |
soc:msm8998 |
proven |
| The display-wake crash dies inside a5xx_hw_init() – it IS a GPU register access, and the instrument that said otherwise could not see this window |
finding |
soc:msm8998 |
proven |
| The display-wake crash needs GPU runtime suspend AND devfreq polling – and it is not a GPU register access |
finding |
soc:msm8998 |
proven |
| The display-wake crash is not in any of msm’s devfreq callbacks – but it is specific to the GPU’s devfreq |
finding |
soc:msm8998 |
proven |
