mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bean Huo <beanhuo@iokpp.de>
To: linux-pm@vger.kernel.org, linux-scsi@vger.kernel.org,
	cw00.choi@samsung.com,  zhanjie9@hisilicon.com
Cc: linux-kernel@vger.kernel.org,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	 Kyungmin Park <kyungmin.park@samsung.com>,
	"Martin K . Petersen" <mkp@kernel.org>,
	"James E . J . Bottomley" <James.Bottomley@HansenPartnership.com>,
	Avri Altman <avri.altman@sandisk.com>,
	 Bart Van Assche <bvanassche@acm.org>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Stanley Jhu <stanleyjhu@google.com>,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/4] devfreq: check the get_cur_freq() return value and use it in ufshcd
Date: Tue, 06 Oct 2026 13:07:40 +0200	[thread overview]
Message-ID: <5377501a53a50bc8162cea277a2ce597ffdaf180.camel@iokpp.de> (raw)
In-Reply-To: <48814f547eeb8a5c575cd143a2569291de890c2a.camel@iokpp.de>


Chanwoo, MyungJoo Ham, Kyungmin Park, who else maintains this, 

Patches 3/4 and 4/4 of this series have been picked up by the SCSI tree.

Patches 1/4 and 2/4 are the devfreq ones and do not depend on them.

Would you like to take them, or should I resend the two on their own against
your devfreq-next branch?

Kind regards,
Bean


On Mon, 2026-09-14 at 15:12 +0200, Bean Huo wrote:
> Hi Chanwoo,
> 
> A quick check. the patch 1/4, and patch 2/4 in this series would be queueing
> up
> for your pull requst?
> 
> Regards,
> Bean
> 
> 
> On Mon, 2026-09-07 at 21:21 +0200, Bean Huo wrote:
> > The devfreq core has three users of the optional ->get_cur_freq()
> > callback. Two of them check the return value, the third one does not and
> > passes an uninitialized frequency to the transition notifiers when the
> > callback fails. Patch 1 fixes that.
> > 
> > Patch 2 writes down what a driver is expected to return from the
> > callback. Today this has to be found by reading the devfreq core.
> > 
> > Patch 3 records the frequency the controller starts at.
> > ufshcd_init_clocks() puts the controller at its highest frequency, but
> > nothing writes that down, so clk_scaling.target_freq stays 0 and devfreq
> > starts with previous_freq at 0 as well. With use_pm_opp this makes
> > ufshcd_devfreq_get_dev_status() report 0 Hz, the ondemand governor then
> > asks for the maximum frequency, and ufshcd_devfreq_target() runs a full
> > ufshcd_devfreq_scale() that holds up the queue for up to a second only to
> > set the same OPP and the same gear again.
> > 
> > Patch 4 adds the ->get_cur_freq() callback to ufshcd. Without it the
> > cur_freq attribute shows the last frequency the governor selected, which
> > is wrong whenever the controller is scaled outside the governor, for
> > example after writing 0 to clkscale_enable.
> > 
> > The patches touch two subsystems. Patches 1 and 2 are for the devfreq
> > tree, patches 3 and 4 are for the SCSI tree. The two halves are
> > independent, at build time and at run time, and can be applied in either
> > order.
> > 
> > Patch was tested on a Radxa Dragon Q6A (1d84000.ufshc):
> > 
> >   before "echo 0 > clkscale_enable":  cur_freq 75000000, target_freq
> > 75000000
> >   after  "echo 0 > clkscale_enable":  cur_freq 300000000, target_freq
> > 75000000
> > 
> > Without it both files report 75000000 and keep doing so for as long as
> > clock scaling stays disabled. A 4 GiB direct read after enabling clock
> > scaling again counted the transitions in trans_stat and attributed time
> > to the 300000000 state, so the frequency the callback returns is one that
> > devfreq recognises.
> > 
> > One thing to be aware of: devfreq_monitor_resume() copies previous_freq
> > from the callback, but it does not call devfreq_update_status(). A
> > frequency change made while the governor was suspended therefore does not
> > show up as a transition. That is how devfreq behaves today and this
> > series does not change it.
> > 
> > Changes since v1:
> > - New patch 3, so that target_freq and devfreq's previous_freq are not 0
> >   at boot (suggested by Stanley Jhu).
> > - Patch 4: drop the !cur_freq check, it cannot happen any more.
> > - Drop the now stale comment in ufshcd_devfreq_get_dev_status().
> > - Patches 1 and 2 are unchanged.
> > - The devfreq and the ufshcd patches no longer depend on each other.
> > - Avri's Reviewed-by is on patches 1, 2 and 4. Patch 3 is new, so it does
> >   not carry it. Avri, please note that patch 4 changed since you reviewed
> >   it, the !cur_freq check is gone. Tell me if you want the tag dropped.
> > 
> > 
> > Bean Huo (4):
> >   PM / devfreq: Fall back to previous_freq when get_cur_freq() fails
> >   PM / devfreq: Add more details to the get_cur_freq() comment
> >   scsi: ufs: core: Record the frequency the controller starts at
> >   scsi: ufs: core: Report the current clock frequency to devfreq
> > 
> >  drivers/devfreq/devfreq.c |  5 ++---
> >  drivers/ufs/core/ufshcd.c | 37 +++++++++++++++++++++++++++++++------
> >  include/linux/devfreq.h   |  7 +++++--
> >  3 files changed, 38 insertions(+), 11 deletions(-)
> > 
> > 
> > base-commit: e30626823a406725ce29bc75cb8ec467d3e1e326
> 


  reply	other threads:[~2026-10-06 11:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07 19:21 Bean Huo
2026-09-07 19:21 ` [PATCH v2 1/4] PM / devfreq: Fall back to previous_freq when get_cur_freq() fails Bean Huo
2026-09-14  6:24   ` Jie Zhan
2026-09-07 19:21 ` [PATCH v2 2/4] PM / devfreq: Add more details to the get_cur_freq() comment Bean Huo
2026-09-14  6:25   ` Jie Zhan
2026-09-07 19:21 ` [PATCH v2 3/4] scsi: ufs: core: Record the frequency the controller starts at Bean Huo
2026-09-07 19:21 ` [PATCH v2 4/4] scsi: ufs: core: Report the current clock frequency to devfreq Bean Huo
2026-09-08  1:34 ` [PATCH v2 0/4] devfreq: check the get_cur_freq() return value and use it in ufshcd Stanley Jhu
2026-09-10  2:28 ` Martin K. Petersen (Oracle)
2026-09-14 13:12 ` Bean Huo
2026-10-06 11:07   ` Bean Huo [this message]
2026-09-17  2:28 ` Martin K. Petersen (Oracle)

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=5377501a53a50bc8162cea277a2ce597ffdaf180.camel@iokpp.de \
    --to=beanhuo@iokpp.de \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@sandisk.com \
    --cc=bvanassche@acm.org \
    --cc=cw00.choi@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mkp@kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=stanleyjhu@google.com \
    --cc=zhanjie9@hisilicon.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®