linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@sirena.org.uk>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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: Wed, 12 Aug 2009 22:44:45 +0100	[thread overview]
Message-ID: <20090812214444.GA4731@sirena.org.uk> (raw)
In-Reply-To: <1250112847.3587.26.camel@pasglop>

On Thu, Aug 13, 2009 at 07:34:07AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:

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

The issue I'm worrying about here is what happens if the device has only
one clock in current revisions of the hardware but another revision of
the same hardware is produced which adds another clock.  When that
happens your NULL lookup gets confused.

> I think it's reasonable to ask whoever produces the device-tree to keep
> the two properties in sync.

It's not just the device tree, it's also the drivers which have to be
able to cope with whatever random device tree that's thrown at them.
This is less of a problem on ARM where it's fairly straightforward to
adjust the users at the same time as the driver but if you've got a
device tree delivered via a completely different distribution mechanism
it gets more sticky.

> > 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.

The problem with the API at the minute in this regard is that there is
no standard way of registering new clocks.  Only something that knows
about the magic sauce for a given architecture (if any) is able to add
clocks.  My concern here is that if PowerPC moves in this direction
without some general agreement from elsewhere then there may be problems
for drivers.

  reply	other threads:[~2009-08-12 21:45 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
2009-08-12 21:44     ` Mark Brown [this message]
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=20090812214444.GA4731@sirena.org.uk \
    --to=broonie@sirena.org.uk \
    --cc=benh@kernel.crashing.org \
    --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).