On Saturday 10 January 2009, Russell King - ARM Linux wrote: > In other words: > > if (cpu_is_omap2430()) > osc = clk_get(NULL, "osc_ck"); > else > osc = clk_get(NULL, "osc_sys_ck"); > > becomes: > > osc = clk_get(dev, "hfclk"); > > since "hfclk" is the name of the input on the device, or it should be > NULL if it is the only input on the device (iow, you don't want to > distinguish it from the 32kHz clock.) Sort of. The twl4030 has "hfclkin" ... from which it generates "hfclkout", and that likely becomes "osc_sys_ck" (or "osc_ck" on omap2430). Agreed that the OMAP main clock is actually a proxy for what's needed. > And that eliminates the need for any platform specific includes (which > is the whole point of the clk API - giving drivers a _generic_ way to > get at clock information without resorting to platform specific crap.) Yeah but ... remembering that the twl4030 is an I2C device, which is initialized well after the clock framework and associated SoC platform devices, that implementation approach begs a few questions: - How to associate clocks with non-SoC devices. This is an issue that comes up repeatedly when folk want to apply <linux/clk.h> calls to things like off-chip codecs ... sometimes fed by programmable off-chip clock generators, for which one would naturally want portable drivers. - How to perform *this* association "late", as part of setting up the I2C device when its i2c_adapter is set up ... and before i2c_driver.probe() for the device is called. This obviously generalizes... - Likewise, how to reverse that association when that device is removed (e.g. because the adapter driver gets removed or unbound). Also generalizes. Full answers for those questions imply some degree of implementation framework for <linux/clk.h> ... a change from its current status as a pure interface. Probably "Answers Mark I" would depend on extensions to the platform specific <linux/clk.h> implementation frameworks. - Dave -- 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
