clock bindings

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.

Quoted 7 lines · 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).

Quoted 5 lines

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.

Quoted 24 lines · Grant Likely

Quoted 7 lines · 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).

Quoted 5 lines

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.

Quoted 4 lines

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