Re: [PATCH 5/8] OPP: Allow multiple clocks for a device

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

On 6/30/22 03:50, Viresh Kumar wrote:
> On 29-06-22, 21:33, Dmitry Osipenko wrote:
>> Today I noticed that tegra30-devfreq driver now fails to probe because
>> dev_pm_opp_find_freq_ceil() fails with -ERANGE. This patch is guilty for
>> that. Could you please take a look?
> 
> I remember this corner case now [1] and it was easy to miss this. So
> you want the OPP core to still parse the DT to read opp-hz, but don't
> want dev_pm_opp_set_opp() to update the clock rate for it.
> 
> What was the reason for this again ?
> 
> I have a couple of solutions in mind, but one may be other than second
> and so want to know the real issue at hand first.
> 

We added memory interconnect support to Tegra and since that time only
the memory controller can drive the clock rate. All other drivers,
including the devfreq, now issue memory bandwidth requests using ICC.

In case of the devfreq driver, it's the OPP core that makes the bw
request using ICC.

But it's the set_freq_table() that fails [2], I see
dev_pm_opp_get_opp_count() returns 17, which is correct, and then
dev_pm_opp_find_freq_ceil(freq=0) returns freq=1, which shall be
freq=12750000.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/?id=16e8b2a7cb886bcc3dd89ad28948d374a2319bbc

[2]
https://elixir.bootlin.com/linux/v5.19-rc4/source/drivers/devfreq/devfreq.c#L179

-- 
Best regards,
Dmitry