From: Joonhoe Kim <[email protected]>
On Mon, Oct 19, 2026 at 09:10:28PM +0800, Qianhui Xu wrote:
> Question: with your runtime-callback variant, does dispcc end up suspended
> after DPMS off, and does the panel still come back on DPMS on?
Yes to both, on SM8850 with v7.3-rc4. With the display off and the
system awake:
current code and Arpit's patch: disp_cc_mdss_ahb_clk prepared twice,
dispcc runtime active, MMCX on
prepare only in the PHY runtime callbacks: prepare count 0,
dispcc runtime suspended, MMCX off
The panel came back on every one of 30 DPMS off/on cycles with that
variant. I repeated it today with the same variant on v7.3-rc4,
blanking both outputs from the compositor, with nothing on
DisplayPort and with four different sinks (a 4K TV and monitors at
5120x2160, 2560x1600 and 1920x2400):
nothing on DP: DPU, both DSI and their PHYs, the DP controller, MDSS
and dispcc all runtime suspended,
disp_cc_mdss_ahb_clk enable=0 prepare=0
sink on DP: DPU, DSI and PHYs suspended, but the DP controller,
MDSS and dispcc stay runtime active,
disp_cc_mdss_ahb_clk enable=2 prepare=2
So here the remaining dispcc reference comes from the DP side while a
sink is connected, and the display controller does not keep the MDP
clock when blanked. This tree carries my DP patch that holds one
runtime PM reference per plugged sink, so the DP part may differ from
mainline.
Arpit, thanks for confirming it is prepare=1 with enable=0 on your
board during s2idle; that matches what I see. I could not measure a
difference from it in s2idle (CX collapse counts were the same in all
three cases), only in the display-off, system-awake case above.
Thanks,
Joonhoe Kim
