From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Russell King <rmk@arm.linux.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>,
Mark Brown <broonie@sirena.org.uk>
Subject: Re: ARM clock API to PowerPC
Date: Thu, 13 Aug 2009 13:45:46 +1000 [thread overview]
Message-ID: <1250135146.3587.87.camel@pasglop> (raw)
In-Reply-To: <20090812234048.GB7118@flint.arm.linux.org.uk>
On Thu, 2009-08-13 at 00:40 +0100, Russell King wrote:
> Maybe - and since you're just starting to look at clkdev, I'll point
> out that it's actually not intuitive which way around the "wildcard"
> matching works in clkdev. The clk_get() arguments aren't the
> wildcards, they're in the clk_lookup structure. Yes, it seems odd,
> but if you consider it from the point of view of the platform code
> wanting to match clocks to a specific set of devices and clock inputs,
> it's actually the way around that you want.
Ok so I had a look, it's basically a list of bindings between a device
"ID" (dev_name(dev)) and a clock input name, matched to a struct clk *.
I'm not entirely sure I want to port that over, because I believe that I
can do better with the device-tree, but then, it will mostly depend
whether we end up wanting to use drivers that do rely on the clkdev
mechanism.
For one, I'm not 100% certain that our dev_id's are unique. Then, that
means that at some stage, the clock source provider need to create the
struct clk for anything devices -may- need, so for all the device clock
connections in the system, it cannot be done on-demand.
I'm thus tempted to pursue for now an approach where the connection is
provided by the device-tree exclusively (or override platform code but
that's to be avoided most of the time), we'll see where it takes us.
IE.
In case you haven't looked at what I had in mind there, basically the
device-node of a device contains properties linking each clock input to
the device node of the clock provider, along with the ID of that clock
within the provider space. So all I need is register clock providers,
that get passed in clk_get() with the "translated" clock ID and that can
spit out struct clk* "on demand".
For example, if I have an external PLL chip that provides 4 clocks, I
can register a clock provider driver attached to that device-node (which
can then also contain properties indicating to the driver how to program
the said PLL chip if so desired).
Then, if 2 of those lines (PLL1 and PLL3) go respectively to a device
SYS_CLK and PHY_CLK inputs, for example, then all I need is to have a
"clock-names" and "clock-map" properties in that device node. The first
one contains "SYS_CLK" and "PHY_CLK", and the second one, a list of two
items, each being the the phandle to the PLL and respectively 1 and 3.
I could just parse the tree and generate all the struct clk* at boot
time and somewhat generate clkdev for them etc... but I believe that
isn't needed, ie, clkdev is an ARM specific mechanism for expressing the
linkage between devices and clock sources but not something that we
would benefit from moving over since we can do better, I believe, with
the device-tree.
Or am I missing something still ? :-)
Cheers,
Ben.
prev parent reply other threads:[~2009-08-13 3:46 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
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 [this message]
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=1250135146.3587.87.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).