On Wed, Feb 12, 2020 at 4:09 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > On Tue, Feb 11, 2020 at 11:44 AM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > > > +Saravana > > > > On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat <drinkcat@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > > > > > > --- > > > [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.
