On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote: > 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.
Right. That's somewhat what I thought. I think the best approach initially is not to impose a hierarchy in our "core" and keep that to the actual clock provider implementation. We'll see in the long term with practice whether we then want to move some of that back into core. > What happens if another clock gets added or the list gets reordered for > some reason? The device-tree is mostly static in that regard. I'm not sure what you mean. Clocks are referenced by IDs so if you want to add more clocks you can just add them to the end. The "NULL" case is typically for things that have only one clock (which seems to be reasonably common in ARM land). I think it's reasonable to ask whoever produces the device-tree to keep the two properties in sync. > Note that the present ARM implementations don't handle anything except > the core SoC normally. Ok, interesting. I don't see why the API would prevent going further tho. In any case, that isn't a big deal, at least until somebody proves me wrong, I believe what I proposed remains simple enough and leaves enough to the actual implementations to allow pretty much anything in that area. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev