Re: [PATCH 1/2] ARM: OMAP: Fix missing includes

[David Brownell <david-b@pacbell.net>]

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