Hi Ulf, Ulf Hansson <ulf.hans...@linaro.org> writes:
> On 13 November 2014 23:28, Kevin Hilman <khil...@kernel.org> wrote: >> From: Kevin Hilman <khil...@linaro.org> >> >> 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. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
