On 08-02-19, 09:12, Marek Szyprowski wrote: > On 2019-02-08 07:49, Viresh Kumar wrote: > > Why don't you get similar problem during suspend? I think you can get > > it when the CPUs are offlined as I2C would have gone by then. The > > cpufreq or OPP core can try and run some regulator or genpd or clk > > calls to disable resources, etc. Even if doesn't happen, it certainly > > can. > > CPUfreq is suspended very early during system suspend and thus it does > nothing when CPUs are being offlined. > > Also at resume the cpufreq core may try to change the frequency right > > from ->init() on certain cases, though not everytime and so the > > problem can come despite of this series. > > cpufreq is still in suspended state (it is being 'resume' very late in > the system resume procedure), so if driver doesn't explicitly change any > opp in ->init(), then cpufreq core waits until everything is resumed. To > sum up, this seems to be fine, beside the issue with regulator > initialization I've addressed in this patchset. Yeah, the governors are suspended very soon, but any frequency change starting from cpufreq core can still happen. There are at least two points in cpufreq_online() where we may end up changing the frequency, but that is conditional and may not be getting hit. > > We guarantee that the resources are available during probe but not > > during resume, that's where the problem is. > > Yes, so I've changed cpufreq-dt to the common approach, in which the > driver keeps all needed resources for the whole lifetime of the device. That's not what I was saying actually. I was saying that it should be fine to do a I2C transfer during resume, else we will always have problems and have to fix them with hacks like the one you proposed where you acquire resources for all the possible CPUs. Maybe we can fix it once and for all. -- viresh
