clock bindings

clock bindings

[Rob Herring]

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.

Rob

Re: clock bindings

[Grant Likely]

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.

g.

Re: 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

Re: 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.