(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
