ARM: OMAP2+: hwmod module clock type support
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 30 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 30 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/30] ARM: OMAP2+: hwmod module clock type support
Hi,
Quoted 8 lines · Rob Herring
Quoted 6 lines · Tero Kristo
Hi,
This series transfers the hwmod clkctrl handling from the hwmod core under clock driver, the data is also transferred from hwmod data to devicetree. Done for most of the OMAP2+ platforms, except OMAP2 / OMAP3, where work is still under progress.
Quoted 4 lines
Some high level questions.
Why a DT node per clock? We've pretty much decided that is a bad idea in the complex cases. TI chips certainly fall in the complex case.
Well the clkctrl instances are separate independent devices under each clockdomain, so having a proper DT node for them makes sense to me.
It's not like the clkctrl registers are just outputs of a single clock. A clockdomain typically has multiple inputs that are then routed in some combination to the clkctrl modules.
I think we can group them though, here's how I'd like to set these up. This from dts point of view modelling omap4 TRM "3.11.16.1 WKUP_CM Register Summary":
cm_wkup: clock at 1800 { /* offset from prm_clocks at 0x4a306000 */
...
reg = <0x1800 0x100>;
ranges = <...>;
...
gpio1_mod_ck: clock at 38 {
compatible = "ti,clock-abc";
reg = <0x38 0x10>;
clocks = <...>;
ranges = <...>;
...
gpio1_dbclk: clock at 8 {
#address-cells = <1>;
#size-cells = <0>;
ranges = <...>;
compatible = "ti,clock-db";
reg = <8>; /* bit offset */
...
};
};
counter_32k_mod_ck: clock at 50 {
compatible = "ti,clock-xyz";
reg = <0x50 0x10>;
clocks = <...>;
...
};
...
};This then allows adding support for the clockdomain CLKSTCTRL and DYNAMICKDEP registers later on.
Then I'd like to also have consumers be able to reference these using one of the two methods:
1. clocks = <&counter_32k_mod_ck>;
2. clocks = <&cm_wkup 0x50>;
And the gpio1 debounce clock could be addressed with one of:
1. clocks = <&gpio1_dbclk>;
2. clocks = <&gpio1_mod_ck 8>;
Quoted 2 lines
You are changing compatible strings and possibly breaking compatibility. Don't do that or justify why.
Yes Tero please check those, we need to support the old behavior too. Sounds like you figured that out how to do that alreadey by generating the clock name for the built-in data.
Regards,
Tony