[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190208110053.GA7913@e107155-lin>
Date: Fri, 8 Feb 2019 11:00:53 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-samsung-soc@...r.kernel.org,
Viresh Kumar <viresh.kumar@...aro.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Dave Gerlach <d-gerlach@...com>,
Wolfram Sang <wsa@...-dreams.de>
Subject: Re: [PATCH 0/2] cpufreq/opp: rework regulator initialization
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.
--
Regards,
Sudeep
Powered by blists - more mailing lists