clock bindings

[Shawn Guo]

On Thu, Mar 31, 2011 at 04:45:47PM -0600, Grant Likely wrote:
> On Wed, Feb 02, 2011 at 10:47:40AM -0600, Rob Herring wrote:
> > I've started looking at the DT clock bindings in more depth. To what
> > level should the clock tree be defined in the DT? Should it be a
> > one-to-one correlation of current struct clk nodes to node in DT
> > where each node is a single input and output? Or only define a
> > single (or few) node with the inputs (oscillators) and many outputs
> > for SOC's clock controller (i.e. MX51 CCM).
> > 
> > If the DT itself does not have a hierarchical construction of nodes
> > that matches the clock tree hierarchy, then creating the hierarchy
> > at run-time will be a challenge and not be very efficient. It would
> > require 1 pass for each clock node type to create all the nodes, and
> > then another pass to setup the hierarchy.
> 
> Wow, it takes me a long time to reply sometimes.
> 
> I'm not sure at the moment.  A month ago I would have said
> "everything", but I've thought about it a lot more and I think it is
> more important that dt and non-dt users share the same code base for
> setting up internal-to-the-soc clocks.  Anything available externally
> will need a node describing it in the dt, which means the support code
> shifts from registering all the clocks to matching up dt nodes to
> existing clocks where possible.
> 
> For the time being, I've pushed back on registering all devices from
> the device tree for the same reason which has given some breathing
> room on the topic.  It will be a topic for discussion at UDS.
> 
You must have seen the hot discussion on arch/arm platform device
mess.  People have so much expectation from device tree to partly
clean them up.  You are going on a way which may let those people
down, at lease for quite some time :) 

-- 
Regards,
Shawn