Hello Jon, On Wed, 16 May 2012, Jon Hunter wrote: > I have been looking into this and in order to get rid for the above > function pointer we would need to move at a minimum the following > functions from omap-mach2/clkt_clksel.c into the platform code. By platform code, do you mean arch/arm/plat-omap? > _get_clksel_by_parent() > _get_div_and_fieldval() > _write_clksel_reg() > omap2_init_clksel_parent() > omap2_clksel_set_parent() > > However, it may be simpler just to move the clkt_clksel.c file > completely. I have tested the above functions on omap1 and they are > working well. However, before doing this we would need to get Paul's > buy-in that this is the right thing to do. > > Paul, do you have any thoughts on this? We were trying to see if we > could eliminate the dmtimer function pointer for setting the timer clock > source. So, just to see if I'm understanding you correctly, you are planning to implement clksel clocks in the clock framework for OMAP1, and then use clk_set_parent() in the DMTIMER driver ? If so, then yes, that sounds like the right thing to do. Eventually both OMAP2+ and OMAP1 will presumably switch to the common clock framework, once things settle down a bit and can be tested. > Also, the only other minor issue I see is that for omap1 devices instead > of having "sys_ck" as the name the clock name is "armxor_ck". We cannot > rename armxor_ck as it is used by many peripherals but we could use a > #define to workaround this or add a dummy clock node. OMAP1 clockfw uses clkdev just like OMAP2+, so you should be able to define as many clock aliases as you want in mach-omap1/clock_data.c. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
