All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonhoe Kim <26rote@gmail.com>
To: Arpit Saini <arpit.saini@oss.qualcomm.com>
Cc: Rob Clark <robin.clark@oss.qualcomm.com>,
	Dmitry Baryshkov <lumag@kernel.org>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Jessica Zhang <jesszhan0024@gmail.com>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	mahadevan.p@oss.qualcomm.com, rajeevny@qti.qualcomm.com
Subject: Re: [PATCH] drm/msm/dsi: fix AHB clock staying enabled across suspend
Date: Fri, 16 Oct 2026 21:50:35 +0900	[thread overview]
Message-ID: <20261016125036.1069-1-26rote@gmail.com> (raw)
In-Reply-To: <20261006-dsi-ahb-clk-suspend-fix-v1-1-67da848e1b0a@oss.qualcomm.com>

(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.

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?

Thanks,
Joonhoe Kim

  parent reply	other threads:[~2026-10-18 14:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06 13:13 [PATCH] drm/msm/dsi: fix AHB clock staying enabled across suspend Arpit Saini
2026-10-08 23:58 ` Alexey Minnekhanov
2026-10-14  6:08   ` Arpit Saini
2026-10-16 12:50 ` Joonhoe Kim [this message]
2026-10-17 18:16   ` Arpit Saini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261016125036.1069-1-26rote@gmail.com \
    --to=26rote@gmail.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=airlied@gmail.com \
    --cc=arpit.saini@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jesszhan0024@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lumag@kernel.org \
    --cc=mahadevan.p@oss.qualcomm.com \
    --cc=marijn.suijten@somainline.org \
    --cc=rajeevny@qti.qualcomm.com \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=sean@poorly.run \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.