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 13:35:51 +0100 [thread overview]
Message-ID: <20090812123551.GC11227@sirena.org.uk> (raw)
In-Reply-To: <1250063825.15143.43.camel@pasglop>
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.
next prev parent reply other threads:[~2009-08-12 13:05 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 [this message]
2009-08-12 21:34 ` Benjamin Herrenschmidt
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=20090812123551.GC11227@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).