ARM clock API to PowerPC
benh at kernel.crashing.org
Thu Aug 13 07:34:07 EST 2009
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
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
More information about the devicetree-discuss