Hi Joonhoe, Thanks for the detailed data points in this thread. We are bringing up an SM8750P board with a bonded dual-DSI panel (NT36536) on a v7.3-rc7 based tree (this file is unchanged in 7.3 final), and your "display off, system awake" observation matches what we see.
Measured with DPMS off (org.gnome.ScreenSaver.SetActive(true)), reading power/runtime_status before and after, in this order: ae00000.display-subsystem active -> suspended .../ae01000.display-controller active -> suspended .../ae94000.dsi active -> suspended af00000.clock-controller (dispcc) active -> ACTIVE So the DSI/MDSS devices do runtime-suspend, but dispcc keeps runtime_status=active. We then read clk_summary last (we are aware it runtime-resumes clock controllers, hence last) and while blanked it shows disp_cc_mdss_mdp_clk with enable=prepare=1 still held by display-controller@ae01000, and disp_cc_mdss_ahb_clk at 3 with one consumer being af54000.displayport-controller. Question: with your runtime-callback variant, does dispcc end up suspended after DPMS off, and does the panel still come back on DPMS on? We are trying to tell whether the remaining dispcc reference is a DSI/PHY artifact or something on the DPU/DP side. Separately, on a fraction of cold boots our panel init fails (first DCS command DMA timeout) and in that state DPU core_irq stops incrementing within ~3 s while DSI interrupts stay at 0. We have no causal link to the dispcc runtime state yet; just noting it in case it is useful. No logs needed from you -- just curious whether "dispcc stays active" is a shared property. Thanks, Qianhui
