* Tero Kristo <t-kristo@xxxxxx> [160413 00:00]: > On 04/12/2016 06:58 PM, Tony Lindgren wrote: > > > >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. > > 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_ck nodes. > > 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_ck nodes do > not support this. So, what happens for example for omap4 is following: OK > 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_data changes 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
