* Nishanth Menon <nm@xxxxxx> [130405 04:31]: > On Fri, Apr 5, 2013 at 4:50 AM, Rajendra Nayak <rnayak@xxxxxx> wrote: > > On Friday 05 April 2013 12:30 AM, Nishanth Menon wrote: > > - I am agree with Tony in his discussion in > >> http://marc.info/?t=136370325600009&r=1&w=2 > >> > >> *if* we are moving clock to DT, we should move the data to DT as well - > > > > I don't think Tony said 'move all clock data into DT'. He was suggesting > > a combination of DT and /lib/firmware Yes that also covers the case of 100% DT clocks and 0% /lib/firmware clocks if somebody wants that. But most usable combination would be: 1. Parent clocks allocated by the driver 2. Timer, serial, MMC, Ethernet and whatever is needed for mounting root clocks defined in DT 3. The rest of the clocs loaded from /lib/firmware > >> similar to what other platforms do - highbank as far as i can quickly > >> see. (drivers/clk/clk-highbank.c and arch/arm/boot/dts/ecx-common.dtsi > > > > Well, you chose to look at highbank (which has 8 clock nodes in DT, as > > opposed to OMAP5 which has around 250 in kernel) why don't you also look at imx? > > drivers/clk/mxs/clk-imx28.c and Documentation/devicetree/bindings/clock/imx28-clock.txt > > for examples. > > They have around 65 nodes (still way lesser than OMAP) and see what > > they do. Thats exactly what Roger does in his patch. > > > > Precisely - thanks for highlighting my view - all the more reason for > us to move clock data out of kernel image :). > $ c_count arch/arm/mach-omap2/cclock*_data.c|tail -1 > 8110 > $ wc -l arch/arm/mach-omap2/cclock*_data.c|tail -1 > 10310 total > > that much code sitting in kernel makes it heavier for us(and others > working on clock framework code) - > we do also foresee that eventually dt data might move out to it's own > repository. Yes we want to get rid of the large amounts of static data in the kernel. It's just a constant source for flames, and I'm getting pretty tired of that. We already did that with pinctrl-single.c for the mux data, so it's cleary doable even with more complex data such as the clock data or hwmod data. BTW, regarding the legacy mux data, although we have not yet been able to remove the legacy mux data, we have am33xx already using it, and can drop the omap4 legacy mux data probably for v3.11. > Further, maintaining dts vs kernel code compatibility aside, consider > adding new platforms - more code containing clock data that we have to > carry on in kernel - If we have ! > > I love the idea that Roger's patch does, as a *step #1* of > transitioning clock data out-of-kernel image and enabling drivers to > entitle DT based boot. > > if this is the only step we will ever take, then it will be a > disappointing decision. whether the final data goes to /lib/firmware > or arch/arm/boot/dts - even though, I prefer it in dts, I have no > strong feelings about it. > However, we need to be prepared (at the earliest possible time) to > move that data out of kernel image as *step #2*. Yes agreed, Roger's approach is a good first step. It just needs to be a proper device driver under drivers/clock/omap. Also note that the /lib/firmware part is an additional step to the DT defined clocks, but might actually make it easier to implement various PM related bits than trying to map them as DT properties. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
