From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: Samsung SoC clock updates
Date: Tue, 12 Jan 2010 23:50:19 +0000 [thread overview]
Message-ID: <20100112235019.GH18532@trinity.fluff.org> (raw)
In-Reply-To: <20100112224833.GA19957@sirena.org.uk>
On Tue, Jan 12, 2010 at 10:48:34PM +0000, Mark Brown wrote:
> On Tue, Jan 12, 2010 at 10:03:51PM +0000, Ben Dooks wrote:
>
> > I'm not sure that clkdev will do what we need, we have a situatio where
> > our platform-device names change depending on the system and thus we
> > would have to either change the clk array at init time or do our own
> > thing.
>
> Surely this is exactly the sort of use case that clkdev is designed to
> handle? Essentially all it does is provide a remapping layer so that
> the data associated with the struct clk doesn't have to bear any direct
> relationship to the device and name used to look it up. This means that
> the SoC specific code can just define its clock tree in some way that
> looks good for the hardware and then easily layer a mapping to what the
> drivers expect without the two jobs having to interfere with each other.
For the first thing this ends up allocating more memory at run time when
we've already got a list of our clocks created from the compile time
structures that describe them.
I could certainly see that we could use clkdev to deal with this, but I
would like to schedule looking at this until after the current round of
SoC code cleanups and the addition of the s5p6440 SoC.
> > I will certainly eliminate the driver's use of clk_get(dev, "name") to get
> > their default bus clock.
>
> I don't understand what the problem is with that? That's exactly what
> I'd expect to see a driver doing (possibly with NULL instead of a
> specific name).
next prev parent reply other threads:[~2010-01-12 23:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-08 2:30 Samsung SoC clock updates Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: S3C64XX: Fix possible clock look in EPLL and MPLL clock chains Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: SAMSUNG: Move <plat/clock.h> to plat-samsung Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: S3C64XX: Cleanup common init code in s3c6400-clock.c Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: S3C64XX: Compress s3c6400-clock.c code Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: SAMSUNG: Add core clock implementation for clksrc based clocks Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: S3C64XX: Use new clock-clksrc.c code for clocks Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: S3C64XX: Remove unused clock definitions from clock header Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: SAMSUNG: Reduce size of struct clk Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: S3C64XX: Fixup .reg_src and .reg_div with named initialisers Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: S3C64XX: Avoid announcing clksrc clocks twice Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: SAMSUNG: Move clock.c to arch/arm/plat-samsung Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: SAMSUNG: Do not allow get/set/round rate calls with no divider Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: SAMSUNG: Add call to register array of clocks Ben Dooks
2010-01-08 2:30 ` [S3C-CLK] ARM: SAMSUNG: Do not register set_parent call if no source Ben Dooks
2010-01-12 9:16 ` Samsung SoC clock updates Russell King - ARM Linux
2010-01-12 22:03 ` Ben Dooks
2010-01-12 22:48 ` Mark Brown
2010-01-12 23:50 ` Ben Dooks [this message]
2010-01-13 11:57 ` Mark Brown
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=20100112235019.GH18532@trinity.fluff.org \
--to=ben-linux@fluff.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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).