From: lethal@linux-sh.org (Paul Mundt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] Add a common struct clk
Date: Tue, 18 Jan 2011 17:44:45 +0900 [thread overview]
Message-ID: <20110118084445.GL2122@linux-sh.org> (raw)
In-Reply-To: <20110111112240.GQ12078@pengutronix.de>
On Tue, Jan 11, 2011 at 12:22:40PM +0100, Sascha Hauer wrote:
> On Tue, Jan 11, 2011 at 06:27:11PM +0800, Jeremy Kerr wrote:
> > Hi Sascha,
> >
> > > The i.MX clk implementation disables the old parent if clk is enabled
> > > and enables the new parent if clk is enabled (modulo bugs). Shouldn't
> > > we do this here aswell?
> >
> > Sounds reasonable, yes.
> >
> > > I thought about returning -EBUSY if clk_set_parent is called for an
> > > enabled clk, but this way we could never reparent the cpu clock which I
> > > think is done in the Freescale BSP for power saving.
> >
> > I think that the possibility for changing the parent really depends on the
> > implementation; in some cases we may want to disallow it, in others it might
> > be fine.
> >
> > Related: do we really need globally-accessible clk_{get,set}_parent in the clk
> > API? For cases where we need to set the parent, we probably need details about
> > the platform clock configuration (eg, which clocks are possible parents). In
> > this case, we could just call into the clock driver directly.
>
> I agree that drivers have no business calling clk_{get,set}_parent, this
> is purely platform specific.
>
Do you guys even bother to grep the kernel for users of the API before
coming up with arbitrary policy?
There are plenty of cases where clocks are allocated dynamically by
driver code that in turn can be set up as a parent for other dynamically
allocated clocks. This has not a damn thing to do with platform code and
everything to do with the clock circuitry of the device or IP block in
question.
If you actually want this API unification thing to not be completely
stillborn, I recommend focusing on how people are actually using the API
today (especially the parts that are used by the majority of users, not
the one you happened to base your implementation off of), and then trying
to push your interpretation or roadmap for the API at a later stage. This
way the former has a chance of getting upstream without the latter
completely derailing it.
next prev parent reply other threads:[~2011-01-18 8:44 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-05 3:51 [PATCH 0/2] Common struct clk implementation, v10 Jeremy Kerr
2011-01-05 3:51 ` [PATCH 2/2] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-01-05 3:51 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2011-01-06 16:07 ` Richard Cochran
2011-01-06 20:11 ` Uwe Kleine-König
2011-01-07 0:10 ` Jeremy Kerr
2011-01-07 0:32 ` Russell King - ARM Linux
2011-01-07 9:40 ` Uwe Kleine-König
2011-01-08 13:15 ` Sascha Hauer
2011-01-10 2:43 ` Jeremy Kerr
2011-01-10 10:41 ` Sascha Hauer
2011-01-10 11:00 ` Russell King - ARM Linux
2011-01-11 0:54 ` Jeremy Kerr
2011-01-16 7:26 ` Grant Likely
2011-01-16 20:41 ` Ryan Mallon
2011-01-16 21:07 ` Uwe Kleine-König
2011-01-16 21:39 ` Ryan Mallon
2011-01-11 10:16 ` Sascha Hauer
2011-01-11 10:27 ` Jeremy Kerr
2011-01-11 11:22 ` Sascha Hauer
2011-01-18 8:44 ` Paul Mundt [this message]
2011-01-18 9:21 ` Sascha Hauer
2011-01-18 9:23 ` Paul Mundt
2011-01-18 12:21 ` Russell King - ARM Linux
2011-01-05 3:55 ` [PATCH 0/2] Common struct clk implementation, v10 Jeremy Kerr
2011-01-07 1:33 ` Ben Dooks
2011-01-07 9:49 ` Uwe Kleine-König
-- strict thread matches above, loose matches on Subject: below --
2011-03-03 6:40 [PATCH 0/2] Common struct clk implementation, v14 Jeremy Kerr
2011-03-03 6:40 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2011-04-14 12:49 ` Tony Lindgren
2011-02-21 2:50 [PATCH 0/2] Common struct clk implementation, v13 Jeremy Kerr
2011-02-21 2:50 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2011-02-22 20:17 ` Uwe Kleine-König
2011-02-23 2:49 ` Jeremy Kerr
2011-01-05 3:18 [PATCH 0/2] Common struct clk implementation, v10 Jeremy Kerr
2011-01-05 3:18 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-12-08 2:08 [PATCH 0/2] Common struct clk implementation, v8 Jeremy Kerr
2010-12-08 2:08 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-12-08 2:05 Jeremy Kerr
2010-12-08 10:21 ` Uwe Kleine-König
2010-12-10 1:58 ` Jeremy Kerr
2010-12-10 9:21 ` Uwe Kleine-König
2010-07-12 2:37 [PATCH 0/2] Common struct clk implementation, v6 Jeremy Kerr
2010-07-12 2:37 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-06-21 5:35 [PATCH 0/2] Common struct clk implementation, v5 Jeremy Kerr
2010-06-21 5:35 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-06-22 4:43 ` Baruch Siach
2010-07-05 2:33 ` MyungJoo Ham
2010-07-12 2:19 ` Jeremy Kerr
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=20110118084445.GL2122@linux-sh.org \
--to=lethal@linux-sh.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).