Hi Sudeep, On 2019-02-08 12:00, Sudeep Holla wrote: > On Thu, Feb 07, 2019 at 01:22:25PM +0100, Marek Szyprowski wrote: >> Dear All, >> >> This is a scenario that triggers the above issue: > [...] >> 1. system disables non-boot cpu's at the end of system suspend procedure, >> 2. this in turn deinitializes cpufreq drivers for the disabled cpus, >> 3. early in the system resume procedure all cpus are got back to online >> state, >> 4. this in turn causes cpufreq to be initialized for the newly onlined >> cpus, >> 5. cpufreq-dt acquires all its resources (clocks, regulators) during >> ->init() callback, > This is strictly not just restricted to cpufreq-dt, but to any driver > supporting multiple policies. So we need a generic fix not just > cpufreq-dt specific. Could you point which other driver needs similar fix? Here in cpufreq-dt the problem was caused by using regulator api (indirectly) from ->init(). All other drivers, which have regulators support, are for old, obsolete, uni-processor systems, which don't have the problem of secondary cpu suspend during system suspend/resume cycle. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
