On 9/8/26 1:43 PM, Dmitry Baryshkov wrote: > On Tue, Sep 08, 2026 at 09:03:55AM +0200, Konrad Dybcio wrote: >> On 8/28/26 1:13 AM, Dmitry Baryshkov wrote: >>> The always-on counter behind MSM_PARAM_TIMESTAMP sits in the GPU power >>> domain on a4xx, a5xx and the GMU-less a6xx parts, so it restarts from >>> zero whenever the GPU is powered up again and the timestamp reported to >>> userspace jumps backwards. On an a702 six reads three seconds apart all >>> land in the 500..1200 tick range, stepping backwards twice, and on an >>> a530 the OpenCL device timer conformance test fails because >>> clGetDeviceAndHostTimer() returns an end time below the start time. >>> >>> Save the counter in the suspend path of the affected generations, while >>> the GPU is still powered, and add the accumulated ticks to the value >>> reported to userspace. >>> >>> Assisted-by: LLM >>> Signed-off-by: Dmitry Baryshkov <[email protected]> >>> --- >>> The always-on counter behind MSM_PARAM_TIMESTAMP sits in the GPU power >>> domain on a4xx, a5xx and the GMU-less a6xx parts, so it restarts from zero >>> whenever the GPU is powered up again and the timestamp userspace reads >>> jumps backwards. Accumulate what the counter reached before each suspend >>> and add it to what is reported afterwards. >> >> Could (some) a5xx parts use A5XX_GPMU_ALWAYS_ON_COUNTER/0xa879? >> msm-3.x defines it as KGSL_PERFCOUNTER_NOT_USED fwiw.. > > It seems it also restarts on power collapse (so always on is not > actually always). Also if it worked, it would have helped only a530 and > a540 (MSM8996 and MSM8998), leaving SDM630/660 and all MSM8956/76/53/37 > without the fix.
Yeah, that's why I said "some". Is there a chance that's because we mistreat the cx/gx split on a5xx? Konrad
