Re: [PATCH] drm/msm/dsi: fix AHB clock staying enabled across suspend

[Arpit Saini <arpit.saini@oss.qualcomm.com>]

(Resending with the lists on Cc; I earlier replied only to Kim.)

On 10/16/2026 6:20 PM, Joonhoe Kim wrote:
> (Resending with the lists on Cc; my earlier reply only went to Arpit.)
> 
> On Tue, Oct 06, 2026 at 06:43:53PM +0530, Arpit Saini wrote:
>> pm_clk_suspend()/resume() only call clk_disable()/clk_enable() for the
>> AHB ("iface") clock, never clk_unprepare(), so prepare_count never
>> reaches 0. The clock (and its source) stays reported as enabled
>> through s2idle suspend even though the display stack is fully
>> suspended:
> 
> I looked at this on a Lenovo Legion Tab Y700 Gen 5 (SM8850, bonded DSI,
> v7.3-rc4), comparing the current code, this patch's approach, and
> preparing the clock only in the PHY runtime callbacks.
> 
> In s2idle with the display on I see no difference: in all three cases
> both PHYs are already runtime suspended at system suspend,
> disp_cc_mdss_ahb_clk has enable_count 0, and CX collapse during a 100 s
> s2idle is the same. Is the clock really enabled during suspend on your
> board, or only prepared? Reading clk_summary runtime-resumes the clock
> controllers, so it can show a different state.
> 

Hi Kim,

Thanks for your observation,

The failure is that :

[   55.005539]  disp_cc_mdss_ahb_clk [19200000] (enable=0 prepare=1) ->

enable count is indeed zero, but the prepare is still non-zero.

The enable_count is correctly reduced to zero by pm_clk_suspend().

However, pm_clk_suspend() only calls clk_disable() and does not call clk_unprepare(). 

Therefore, the preparation reference acquired by pm_clk_add() remains held during s2idle.

> The difference here is with the display off and the system awake: with
> the clock prepared from probe (current code and this patch), dispcc
> stays runtime active and MMCX stays on. Preparing it in the runtime
> callbacks lets both go off. I have not measured the power difference.
> 
> That variant survived 30 DPMS off/on cycles with clk_summary read in a
> loop. Did you hit the prepare_lock deadlock, or is it from code
> reading?
> 

The reason for avoiding clk_prepare()/clk_unprepare() in the PHY
runtime callbacks is that the PHY is also a clock provider, so its
runtime resume could potentially be invoked while CCF holds
prepare_lock.

Agreed the CCF prepare_lock deadlock is currently a theoretical
concern. I have not reproduced it.

Thanks,
Arpit