On Wed, Feb 12, 2020 at 4:09 AM Saravana Kannan saravanak@google.com wrote:
On Tue, Feb 11, 2020 at 11:44 AM Rob Herring robh+dt@kernel.org wrote:
+Saravana
On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat drinkcat@chromium.org wrote:
When there is a single power domain per device, the core will ensure the power domain is switched on (so it is technically equivalent to having not power domain specified at all).
However, when there are multiple domains, as in MT8183 Bifrost GPU, we need to handle them in driver code.
Signed-off-by: Nicolas Boichat drinkcat@chromium.org
[snip]
pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);We're in the process of adding device links based on DT properties. Shouldn't we add power domains to that? See drivers/of/property.c for what's handled.
Rob,
drivers/of/property.c doesn't enable the RPM_ACTIVE AND PM_RUNTIME flags. Wanted to start off conservative. But adding command line ops to change the default flags shouldn't be difficult. But before I do that, I want to change of_devlink to fw_devlink=<disabled|permissive|enabled>. May be I can extend that to "disabled, permissive, suspend, runtime".
Nicholas,
And the adding and removing of device links for power domains will be a 2 line change. I've been meaning to add a few more bindings like hwspinlocks and pinctrl. I can roll power domains support into that if you want.
Adding power domains makes sense to me, as there are a bunch of other users (git grep dev_pm_domain_attach_by_name).
This seems to be a bit orthogonal to this patch though. If your solution lands before this (and not something that is behind a command line option), then I'm happy to make use of it. Either way, happy to test things.