Re: [PATCH 0/3] PM / Domains: Add initial PM clock support to genpd
On 20 November 2014 01:33, Kevin Hilman khil...@kernel.org wrote: Ulf Hansson ulf.hans...@linaro.org writes: It's quite common for PM domains to use PM clocks. Typically from SOC specific code, the per device PM clock list is created and pm_clk_suspend|resume() are invoked to handle clock gating/ungating. A step towards consolidation is to integrate PM clock support into genpd, which is what this patchset does. In this initial step, the calls to the pm_clk_suspend|resume() are handled within genpd, but the per device PM clock list still needs to be created from SOC specific code. It seems reasonable to have gendp to handle that as well, but that left to future patchsets to address. I think we need to get rid of the SoC specific code already. For example, we're already seeing SoCs where the arm32 core is being replaced by an arm64 core but the other IPs, and power-domain logic is staying more or less the same. It's not every users of genpd that are keen on using PM clocks thus we need to provide this a configuration option for genpd. Or more likely, probably some compatible string, or property in the domain node. Grygorii, Arnd and myself were discussing this elsewhere in the context of the TI Keystone2 PM domain support[1]. Thanks for pointing that out. It was actually the reason to why I posted this patchset now, I have been keeping the patches locally in my tree for too long. :-) Let me comment of that thread, instead of here. Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] PM / Domains: Add initial PM clock support to genpd
It's quite common for PM domains to use PM clocks. Typically from SOC specific code, the per device PM clock list is created and pm_clk_suspend|resume() are invoked to handle clock gating/ungating. A step towards consolidation is to integrate PM clock support into genpd, which is what this patchset does. In this initial step, the calls to the pm_clk_suspend|resume() are handled within genpd, but the per device PM clock list still needs to be created from SOC specific code. It seems reasonable to have gendp to handle that as well, but that left to future patchsets to address. It's not every users of genpd that are keen on using PM clocks thus we need to provide this a configuration option for genpd. In patch 2 and patch 3, we convert some of the SH-MOBILE SOCs to start using the new PM clock support in genpd. Ulf Hansson (3): PM / Domains: Initial PM clock support for genpd ARM: shmobile: Convert to genpd flags for PM clocks for r8a7779 ARM: shmobile: Convert to genpd flags for PM clocks for R-mobile arch/arm/mach-shmobile/pm-r8a7779.c | 3 +-- arch/arm/mach-shmobile/pm-rmobile.c | 3 +-- drivers/base/power/domain.c | 7 +++ include/linux/pm_domain.h | 3 +++ 4 files changed, 12 insertions(+), 4 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PM / Domains: Add initial PM clock support to genpd
Hi Ulf,
On Wed, Nov 19, 2014 at 3:00 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
It's quite common for PM domains to use PM clocks. Typically from SOC specific
code, the per device PM clock list is created and pm_clk_suspend|resume() are
invoked to handle clock gating/ungating.
A step towards consolidation is to integrate PM clock support into genpd,
which
is what this patchset does.
Thanks, this sounds like a good idea.
In this initial step, the calls to the pm_clk_suspend|resume() are handled
within genpd, but the per device PM clock list still needs to be created from
SOC specific code. It seems reasonable to have gendp to handle that as well,
but
s/gendp/genpd/
that left to future patchsets to address.
If/when genpd will handle the clock creation, perhaps the flag can just
be replaced by a pointer to a list of clocks?
Or do you have other uses in mind for adding the flags field now?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PM / Domains: Add initial PM clock support to genpd
Ulf Hansson ulf.hans...@linaro.org writes: It's quite common for PM domains to use PM clocks. Typically from SOC specific code, the per device PM clock list is created and pm_clk_suspend|resume() are invoked to handle clock gating/ungating. A step towards consolidation is to integrate PM clock support into genpd, which is what this patchset does. In this initial step, the calls to the pm_clk_suspend|resume() are handled within genpd, but the per device PM clock list still needs to be created from SOC specific code. It seems reasonable to have gendp to handle that as well, but that left to future patchsets to address. I think we need to get rid of the SoC specific code already. For example, we're already seeing SoCs where the arm32 core is being replaced by an arm64 core but the other IPs, and power-domain logic is staying more or less the same. It's not every users of genpd that are keen on using PM clocks thus we need to provide this a configuration option for genpd. Or more likely, probably some compatible string, or property in the domain node. Grygorii, Arnd and myself were discussing this elsewhere in the context of the TI Keystone2 PM domain support[1]. Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304099.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
