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
Quoted 6 lines · Tero Kristo
Quoted 4 lines · Tony Lindgren
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.
Quoted 7 lines
Some of the old clock nodes are being dropped by this series, namely the timer ones, and they are getting merged to the new
timerX_mod_cknodes.The reason for this is the behavior of the clock driver itself; it assumes it gets a clock handle for which it can do
clk_set_parent(for setting proper source clock to get correct time-base), but normal_mod_cknodes do not support this. So, what happens for example for omap4 is following:
OK
Quoted 9 lines
These clocks are then directly referenced by hwmod. The reason for having two registers under the new timer node is that in some hardwares (like AM33xx), the register address for the gate and mux component are different.
Anyway, compatibility will be broken once the
hwmod_datachanges go in for individual SoCs, as the clkctrl portion is going to be dropped, and the hwmod has no chance to work with old DT data. If this is not acceptable, then the whole exercise becomes moot as we need to move the data someplace else within the kernel, and forget about the transition to DT.
Yeah if have hwmod lookup the clkctrl clock based on the generated clock name, it can still find the clock. But naturally if the clocks are not defined, hwmod won't find them for an old dtb.
If we want to avoid that, the clkctrl data would have be built in for each SoC in the clock driver, and we'd still need to provide the DT bindings for them. We do have the TI clock bindings tagged as unstable and defining clocks for SoCs is the dts files is pretty much the standard.. Probably the best we can do is to things in phases where we drop the hwmod data only later on.
Regards,
Tony