On 6/28/22 10:09, Viresh Kumar wrote: > On 27-06-22, 12:51, Viresh Kumar wrote: >> On 27-06-22, 10:14, Dmitry Osipenko wrote: >>> 27.06.2022 09:45, Viresh Kumar пишет: >>>>> Looks okay. If you'll solve the cpufreq problem where OPP config is set >>>>> by two drivers for the same cpu device >>>> This is supported, there is some early freeing of resources on the >>>> removal path though, the reasoning for which I already gave in another >>>> email. Though, I am open to sorting that out as well, but nothing >>>> breaks the code for now AFAICT. >>>> >>> >>> In case of Tegra, we use tegra-cpufreq driver that sets supported_hw and >>> registers cpufreq-dt. If cpufreq-dt driver defers the probe, then the >>> supported_hw will be lost on the re-probe. I haven't checked yet, but I >>> suppose that cpufreq-dt driver defers on Tegra30 because of the CPU >>> regulator and that's why we get the "OPP table is missing" error. >> >> Aha, I get it now. I see, this is a real problem. Will fix it. Give me >> some time to think. Thanks. > > Okay, I fixed this in opp/linux-next, can you or Jon please give it a > go on tegra30 to see if the issue is fixed ? > > FWIW, I have fixed this with the IDR API and the OPP core will only > free the resources in clear-config, that the corresponding set-config > has configured. I have tested it with the clk API only though. > > Once you confirm, I will resend all the patches and hope no issues are > left here. > > Thanks for helping out guys. Really appreciate it. > The opp/linux-next works fine, thank you. Tested-by: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> BTW, the idr_alloc() is obsoleted by xa_alloc(). -- Best regards, Dmitry
