Re: [PATCH v2 2/3] drm/msm/a5xx: Hold a CPU latency request while the GPU is powered

[Dmitry Baryshkov]

On Mon, Oct 19, 2026 at 11:05:09PM -0300, Fabricio Akio wrote:
> On SDM630 the GPU was observed to stop executing while the SoC is in
> system-level power collapse, and to continue once the SoC wakes. Its
> interrupts have no wakeup route through the MPM, so it cannot wake the
> SoC itself. A submission overlapping such a state would stall until a
> CPU wakes, and a stall longer than the hang detector's threshold makes
> the driver recover the GPU, which can lose a frame.

Do you have any extra patches that you are running with? I don't think
that currently Linux can hit system power collapse with the GPU still
running.

On SDM630 the GPU is running from the CX, but we don't vote on it (yet).
With the CPUs awake we keep a vote on CX. With the cores going to the
deep sleep, the CX might drop below the required leven, causing GPU to
die.

> Qualcomm's downstream driver holds a CPU latency request while the GPU
> is active, qcom,pm-qos-active-latency, which keeps the CPU idle
> governors out of cluster and system-level power collapse. Do the same:

Could you please check what actually stops in your setup (CX corner, the
BIMC vote, XO)? I think the proper fix is for the GPU to vote its real
rail, scaled per OPP, in both RPM sets, rather than keeping the CPUs out
of their idle states. I'll have it as a part of the CPR series, but it
needs a bit more of the cleanup and polishing.

> take the request when the GPU resumes and drop it when it suspends, so
> those states remain available once the GPU has gone idle, and on
> destroy, which unbind reaches even when suspending the GPU failed. The
> limit is a per-GPU catalog value, downstream's for each SoC: 424 us
> for the A508 in SDM630, and 518 us for the A509 in SDM636 and the A512
> in SDM660.
> 
> Signed-off-by: Fabricio Akio <fabricioakio@xxxxxxxxx>

-- 
With best wishes
Dmitry