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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
