On 28/10/2020 04:11, Viresh Kumar wrote: > On 26-10-20, 12:57, Jon Hunter wrote: >> Thinking about this some more, what are your thoughts on making the >> following change? >> >> Basically, if the driver sets the CPUFREQ_NEED_INITIAL_FREQ_CHECK, > > This flag only means that the platform would like the core to check > the currently programmed frequency and get it in sync with the table. Yes exactly. >> then I wonder if we should not fail if the frequency return by >>> get() is not known. > > When do we fail if the frequency isn't known ? That's the case where > we try to set it to one from the table. Currently, if the frequency is not known, we fail right before we do the initial frequency check [0]. > But (looking at your change), ->get() can't really return 0. We depend > on it to get us the exact frequency the hardware is programmed at > instead of reading a cached value in the software. Actually it can and it does currently. Note in tegra186_cpufreq_get() the variable 'freq' is initialised to 0, and if no match is found, then it returns 0. This is what happens currently on some Tegra186 boards. >>> This would fix the problem I see on Tegra186 >> where the initial boot frequency may not be in the frequency table. > > With current mainline, what's the problem you see now ? Sorry I missed > track of it a bit :) No problem, this has been an on-going saga now for sometime. Cheers Jon [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/cpufreq.c#n1429 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/tegra186-cpufreq.c#n95 -- nvpublic
