From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mark Brown <broonie@sirena.org.uk>
Cc: John Jacques <john.jacques@lsi.com>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>,
devicetree-discuss@lists.ozlabs.org,
Torez Smith <torez@us.ibm.com>,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: ARM clock API to PowerPC
Date: Thu, 13 Aug 2009 07:34:07 +1000 [thread overview]
Message-ID: <1250112847.3587.26.camel@pasglop> (raw)
In-Reply-To: <20090812123551.GC11227@sirena.org.uk>
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.
next prev parent reply other threads:[~2009-08-12 21:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-12 7:57 ARM clock API to PowerPC Benjamin Herrenschmidt
2009-08-12 8:29 ` Benjamin Herrenschmidt
2009-08-12 17:31 ` Mitch Bradley
2009-08-12 21:30 ` Benjamin Herrenschmidt
2009-08-12 11:19 ` Josh Boyer
2009-08-12 13:40 ` Kumar Gala
2009-08-12 21:29 ` Benjamin Herrenschmidt
2009-08-13 8:59 ` Li Yang-R58472
2009-08-14 9:29 ` Benjamin Herrenschmidt
2009-08-14 11:29 ` Guennadi Liakhovetski
2009-08-14 12:07 ` Benjamin Herrenschmidt
2009-08-15 12:43 ` Russell King
2009-08-15 22:18 ` Benjamin Herrenschmidt
2009-08-16 5:09 ` Grant Likely
2009-08-12 12:35 ` Mark Brown
2009-08-12 21:34 ` Benjamin Herrenschmidt [this message]
2009-08-12 21:44 ` Mark Brown
2009-08-12 21:56 ` Benjamin Herrenschmidt
2009-08-12 22:20 ` Mark Brown
2009-08-12 22:32 ` Benjamin Herrenschmidt
2009-08-12 23:00 ` Mark Brown
2009-08-12 23:15 ` Benjamin Herrenschmidt
2009-08-12 22:28 ` Russell King
2009-08-12 22:45 ` Mark Brown
2009-08-12 22:52 ` Benjamin Herrenschmidt
2009-08-12 23:40 ` Russell King
2009-08-12 23:47 ` Benjamin Herrenschmidt
2009-08-13 3:45 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250112847.3587.26.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=broonie@sirena.org.uk \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=john.jacques@lsi.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=rmk@arm.linux.org.uk \
--cc=torez@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).