[GIT PULL] DT clk binding support

[Shawn Guo]

On Mon, May 21, 2012 at 06:52:37PM -0500, Rob Herring wrote:
> As Grant states: "This proposed binding is only about one thing:
> attaching clock providers to clock consumers." This means you have to
> have at least a single provider and a single consumer defined in the DT.
> 
I just read through Grant's comments over again.  I agree with the
statement which implicitly requires the clk provider defined in DT.
However, for some case, this provider in DT is just a skeleton which
is backed by clock driver where the provider is actually defined.

Looking at Grant's comment below, the second option is also to match
the clock in driver just using name.  The only difference to my
proposal is the name here is given by the argument of phandle pointing
to that skeleton provider node.

I'm fine with that.  So go ahead with your bindings.

Regards,
Shawn

On Wed, Nov 16, 2011 at 03:12:50PM -0700, Grant Likely wrote:
> I'm really not convinced that it is a good idea to break out the
> entire clock tree into one node per struct clk.  To begin with, that
> looks to be very centric around the current 'struct clk' Linux
> abstraction, which is potentially in flux.  Also, looking at Sascha's
> initial RFC for describing the clock tree, I see cases where it looks
> like a clock nexus node really makes sense.  For instance, the
> 'divider-ipg <at> 0x53fd4014' node which has a list of child nodes
> which merely provide a register offset and shift value
> (reg=0x53fd4068..0x53fd4084, shift=0x0..0xf).  It would be natural to
> instead encode that as part of the clock reference, or map it directly
> from the clock reference (ie, assign names to each of the clocks, and
> let the clock provider driver match up the name to the reg offset &
> shift values).
>
> I had originally thought that it would be better to use names directly
> for references to clocks (ie. clock = <phandle>,"name") , but after
> actually playing with it and looking at the existing DT conventions,
> I've reverted to cell values for the arguments and a separate set of
> clock-{input,output}-name properties for attaching meaningful names,
> just like we decided to do for assigning names to 'reg' properties.