Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled

[Rafael J. Wysocki]

On Friday, November 14, 2014 09:27:41 AM Kevin Hilman wrote:
> Hi Ulf,
> 
> Ulf Hansson <ulf.hansson@xxxxxxxxxx> writes:
> 
> > On 13 November 2014 23:28, Kevin Hilman <khilman@xxxxxxxxxx> wrote:
> >> From: Kevin Hilman <khilman@xxxxxxxxxx>
> >>
> >> It makes little sense to use generic power domains without runtime PM.
> >> Also, since the complexities of handling the !PM_RUNTIME case are
> >> causing more trouble and confusion than they're worth, let's simplify
> >> the world by making genpd always enable runtime PM.
> >
> > I do agree that your above statement seems reasonable, even if can't
> > really tell if that would break some SOCs use-cases.
> 
> Break in what way?
> 
> > My concern is though, that I fear we will be taking short-cuts in
> > genpd that might bite us later on, but I might be wrong.
> >
> > The reason for my concern is that on every other place, like in the
> > subsystem level, driver core, PM core and of course in drivers -  we
> > need to cope with all the combinations of CONFIG_PM_SLEEP and
> > CONFIG_PM_SLEEP.  So theoretically, why shouldn't genpd be able to do
> > that as well?
> 
> Good question, and one we need to figure out.  (I meant to mark this
> patch as RFC for that reason.)
> 
> I think the primary question is: why would one want to use genpd without
> runtime PM?
> 
> I understand why one might want to use/test drivers with various
> combinations of PM_SLEEP and PM_RUNTIME, but I'm not seeing why we
> should need to support genpd without PM_RUNTIME enabled.
> 
> In fact, on all the SoCs I've worked closely with, power domains,
> suspend/resume and runtime PM are all so closely intertwined that I
> can't imagine a useful scenario where they they are not all used
> together.  If you care about PM, you turn them all on.  If you don't,
> you turn them all off and ensure everything is enabled at boot.
> 
> IMO, we're spending a lot of cycles supporting these various
> combinations and permutations and as a result are not really able to
> solve the real problems people are raising.
> 
> Seems like most of the time a new feature/fixup/cleanup is proposed, the
> discussion always ends up around how to support things when this or that
> option is disabled, or some combination of kconfig options that weren't
> considered.
> 
> I think we should simplify the config space permuations so we can focus
> on improving the frameworks.

Moreover, recently we've spend quite some time on discussing pretty much
how to do runtime PM for CONFIG_PM_RUNTIME unset and really the conclusion
to me is "Don't do that".

There evidently are systems that require runtime PM (in some form) for basic
functionality and it looks like all systems using genpd will fall into that
category, more or less.  Now, the runtime PM framework is what we have for
handling this kind of stuff and I don't see a reason to pretend that it may
be unnecessary.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/