clock bindings

[Grant Likely]

On Fri, Apr 01, 2011 at 02:43:04PM +0800, Shawn Guo wrote:
> 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 :) 

Actually, I'm not too worried about this.  The real problem is the
board files, not the SoC support code, so even with changing focus a
bit it will still have a huge impact on how the board files look.

g.