Merge patch series "devfreq: check the get_cur_freq() return value and use it in ufshcd"

Bean Huo <beanhuo@iokpp.de> says:

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.

Link: https://patch.msgid.link/20260907192140.2701755-1-beanhuo@iokpp.de
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>

0 files changed, 0 insertions, 0 deletions