Re: [PATCH 3/3] scsi: ufs: core: Report the current clock frequency to devfreq

[Bean Huo <beanhuo@iokpp.de>]

On Tue, 2026-09-01 at 09:33 +0800, Stanley Jhu wrote:
> On Mon, 31 Aug 2026 15:01:29 +0200, Bean Huo wrote:
> > +     /*
> > +      * target_freq stays 0 until something scales the controller for the
> > +      * first time. Report nothing rather than 0 so devfreq falls back to
> > +      * the frequency it last set.
> > +      */
> > +     if (!cur_freq)
> > +             return -EINVAL;
> 
> If ufshcd_devfreq_get_cur_freq() returns -EINVAL here, devfreq falls back
> to devfreq->previous_freq. However, because UFS does not set
> devfreq_profile.initial_freq, previous_freq is also 0 at boot. On platforms
> with use_pm_opp=true, the initial sysfs read or the first transition before
> scaling still ends up seeing 0 Hz.
> 
> Would it be cleaner to initialize hba->clk_scaling.target_freq and
> devfreq_profile.initial_freq to the max frequency in ufshcd_devfreq_init()?
> That way, cur_freq is valid from the start and we wouldn't need to handle
> the !cur_freq case here.
> 
> Thanks,
> Stanley Jhu

yes, thanks, that is better. I will do it in v2.
digging deeper, the problem is a bit wider than the sysfs read. with use_pm_opp,
ufshcd_init_clocks() already puts the controller at the highest OPP, but nothing
records that, so target_freq stays 0. Then ufshcd_devfreq_get_dev_status()
reports 0 Hz, the ondemand governor asks for the maximum frequency, and
ufshcd_devfreq_target() sees 0 != max and 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. This happens today, without my patch.

Patches 1 and 2 are not affected.

Kind regards,
Bean