On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:

 - From the above, question: Do we want to keep that parent pointer ?
Does it make sense ? Will we have objects that are clock providers and
themselves source from multiple parent ? Or we don't care and it becomes

That happens and at times one or more of the sources is off-chip.

entirely the responsibility of a given struct clk instance to deal with
its own parenthood ? Parenthood in the core has the advantage of making
it potentially easier to represent clock nets in the device-tree.

The core would thus be able to do a search in that list based on the
clock-id passed in, or if clk_get(dev, NULL), then, use the first one.

What happens if another clock gets added or the list gets reordered for
some reason?

Also, it would be nice to have a way to have "generic" clock provider
drivers. For example, have a driver for the FooBar Clock chip, which is
known to provide 4 fully programmable clocks. So there could be a
generic driver for that, attached to the clock provider by the probe
code or via the device-tree, the devices clock-map's just provide the
clock ID within the chip (which output of the chip they are connected
to), and so the remaining questions is what to program in each clocks.

Note that the present ARM implementations don't handle anything except
the core SoC normally.