Re: [PATCH 3/3] PM: domains: Add a ->dev_get_performance_state() callback to genpd
From: Ulf Hansson <hidden>
Date: 2021-09-09 14:47:25
Also in:
linux-pm, lkml
On Thu, 9 Sept 2021 at 15:48, Dmitry Osipenko [off-list ref] wrote:
07.09.2021 12:57, Ulf Hansson пишет:quoted
I don't mind extending the genpd API, but it needs to serve a good purpose. As I said earlier, genpd doesn't know nor can control how the consumer driver deploys runtime PM. Unfortunately, that also includes genpd providers, as the behavior isn't a platform or PM domain specific thing. This means genpd needs to be generic enough so it works for all cases. In the $subject patch, we rely on the pm_runtime_suspended() check in dev_pm_genpd_set_performance_state(), which should work for all cases, even if it may be sub-optimal for some scenarios. Note that, in the approach your suggested [1], pm_runtime_status_suspended() is used instead. This doesn't work when a consumer driver doesn't enable runtime PM - or calls pm_runtime_set_active() during ->probe(), because genpd_runtime_resume() won't be invoked to restore the gpd->rpm_state. That said, I wouldn't mind to simply skip adding the ->dev_get_performance_state() all together, if that is what you prefer? In this way, it becomes the responsibility for the consumer driver to do right thing, with the cost of some boilerplate code added in its ->probe() routine.Until a day ago, it wasn't clear to me that consumer drivers now can set up rpm_pstate during probe(), which is a cleaner solution that works well. So let's skip adding the questionable ->dev_get_performance_state(). The boilerplate code in the probe() is minimal in comparison to a previous variant with the state-syncing done by rpm-resume callbacks of consumer drivers, it's good enough.
Alright, that sounds good to me as well. I am happy to help with review of the consumer driver changes, just keep me posted. Thanks and kind regards Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel