Re: [PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core
Hi Geert, On Thursday 24 April 2014 12:13:19 Geert Uytterhoeven wrote: On SoCs like ARM/SH-mobile, gate clocks are available for modules, allowing Runtime PM for a device controlled by a gate clock. On legacy shmobile kernels, this is handled by the PM runtime code in drivers/sh/pm_runtime.c, which installs a clock notifier for the platform bus, registering the NULL clock of each platform device with the PM core. This approach is also used on davinci, keystone, and omap1. This requires the device to have the MSTP clock defined as the first clock in its DT node. I'm not against that, but the requirement should be clearly documented, and we need to check existing DT bindings to make sure they comply with that. I'd like to also take this as an opportunity to discuss how we should name clocks in DT bindings for Renesas devices. Most devices have a single MSTP clock, in which case we don't specify a name. Other devices need several clocks. Names for the non-MSTP clocks will obviously be device-dependent, but how should the MSTP clock be called in that time ? Should it have an empty name (a string in DT) ? Should it have a standard name ? Maybe fck for functional clock ? On multi-platform shmobile kernels, this was not handled at all, leading to spurious disabled clocks on drivers relying on Runtime PM, depending on implicit reset state, or on the bootloader. A first solution, enabling the PM runtime code in drivers/sh/pm_runtime.c in a multi-platform-safe way, was provided by the patch series [PATCH v2 00/17] ARM: shmobile: Enable drivers/sh/pm_runtime.c on multi-platform (http://www.spinics.net/lists/linux-sh/msg30887.html). Here is an alternative approach, avoiding the reliance on C board files, which are being phased out. This is also related to a patch series by Felipe Balbi ([RFC/PATCH] base: platform: add generic clock handling for platform-bus, https://lkml.org/lkml/2014/1/31/290) This series: 1. Lets the MSTP clock driver indicate that its clocks are suitable for Runtime PM, 2. Lets the DT code retrieve clock information when adding a device (it already retrieves information for resources (registers, irq) --- unfortunately clocks are not resources), and registering clocks suitable for Runtime PM with the PM core. If Runtime PM is disabled, the clocks are just enabled. Note that this works for devices instantiated from DT only. Fortunately the drivers for the remaining platform devices (SCI and CMT) handle clocks theirselves, without Runtime PM, so they get properly enabled. Patches: - [1/4] clk: Add CLK_RUNTIME_PM and clk_may_runtime_pm() - [2/4] PM / clock_ops: Add pm_clk_add_clk() - [3/4] of/clk: Register clocks suitable for Runtime PM with the - [4/4] clk: shmobile: mstp: Set CLK_RUNTIME_PM flag This series was tested on Renesas r8a7791, using the Koelsch development board. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core
Hi Laurent,
On Wed, Apr 30, 2014 at 11:29 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Thursday 24 April 2014 12:13:19 Geert Uytterhoeven wrote:
On SoCs like ARM/SH-mobile, gate clocks are available for modules, allowing
Runtime PM for a device controlled by a gate clock.
On legacy shmobile kernels, this is handled by the PM runtime code in
drivers/sh/pm_runtime.c, which installs a clock notifier for the platform
bus, registering the NULL clock of each platform device with the PM core.
This approach is also used on davinci, keystone, and omap1.
This requires the device to have the MSTP clock defined as the first clock in
its DT node. I'm not against that, but the requirement should be clearly
documented, and we need to check existing DT bindings to make sure they comply
with that.
Being the first clock is only required for the NULL clock. And that
is only done
for legacy shmobile kernels, not for multi-platform.
In this patch series, the clock would be chosen based on the presence of the
CLK_RUNTIME_PM flag, to be set by the clock driver. I.e. DT is not involved
directly (for a change... why does everybody think the whole world revolves
around DT these days ? :-)
I'd like to also take this as an opportunity to discuss how we should name
clocks in DT bindings for Renesas devices. Most devices have a single MSTP
clock, in which case we don't specify a name. Other devices need several
clocks. Names for the non-MSTP clocks will obviously be device-dependent, but
how should the MSTP clock be called in that time ? Should it have an empty
name (a string in DT) ? Should it have a standard name ? Maybe fck for
functional clock ?
Empty names should not be used if there can be multiple clocks, right?
Grepping in arch/*/boot/dts/, fck seems to be popular (only) for TI SoCs.
Stadardizing across SoCs and architectures would be nice, though.
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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core
On SoCs like ARM/SH-mobile, gate clocks are available for modules, allowing
Runtime PM for a device controlled by a gate clock.
On legacy shmobile kernels, this is handled by the PM runtime code in
drivers/sh/pm_runtime.c, which installs a clock notifier for the platform
bus, registering the NULL clock of each platform device with the PM core.
This approach is also used on davinci, keystone, and omap1.
On multi-platform shmobile kernels, this was not handled at all, leading
to spurious disabled clocks on drivers relying on Runtime PM, depending on
implicit reset state, or on the bootloader.
A first solution, enabling the PM runtime code in drivers/sh/pm_runtime.c
in a multi-platform-safe way, was provided by the patch series
[PATCH v2 00/17] ARM: shmobile: Enable drivers/sh/pm_runtime.c on
multi-platform (http://www.spinics.net/lists/linux-sh/msg30887.html).
Here is an alternative approach, avoiding the reliance on C board files,
which are being phased out.
This is also related to a patch series by Felipe Balbi ([RFC/PATCH] base:
platform: add generic clock handling for platform-bus,
https://lkml.org/lkml/2014/1/31/290)
This series:
1. Lets the MSTP clock driver indicate that its clocks are suitable for
Runtime PM,
2. Lets the DT code retrieve clock information when adding a device
(it already retrieves information for resources (registers, irq) ---
unfortunately clocks are not resources), and registering clocks
suitable for Runtime PM with the PM core.
If Runtime PM is disabled, the clocks are just enabled.
Note that this works for devices instantiated from DT only.
Fortunately the drivers for the remaining platform devices (SCI and CMT)
handle clocks theirselves, without Runtime PM, so they get properly enabled.
Patches:
- [1/4] clk: Add CLK_RUNTIME_PM and clk_may_runtime_pm()
- [2/4] PM / clock_ops: Add pm_clk_add_clk()
- [3/4] of/clk: Register clocks suitable for Runtime PM with the
- [4/4] clk: shmobile: mstp: Set CLK_RUNTIME_PM flag
This series was tested on Renesas r8a7791, using the Koelsch development
board.
Thanks for your comments!
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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
