From: Sascha Hauer <s.hauer@pengutronix.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/4] clk: Implement clk_set_rate
Date: Thu, 26 May 2011 06:54:29 +0000 [thread overview]
Message-ID: <20110526065429.GL20715@pengutronix.de> (raw)
In-Reply-To: <1306373867.2875.162.camel@pororo>
[put the lists back on cc]
On Thu, May 26, 2011 at 09:37:47AM +0800, Jeremy Kerr wrote:
> Hi Sascha,
>
> > > +
> > > +propagate:
> > > + ret = clk->ops->set_rate(clk->hw, new_rate, &parent_rate);
> > > +
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + /* ops->set_rate may require the parent's rate to change (to
> > > + * parent_rate), we need to propagate the set_rate call to the
> > > + * parent.
> > > + */
> > > + if (ret = CLK_SET_RATE_PROPAGATE) {
> > > + new_rate = parent_rate;
> > > + clk = clk->parent;
> > > + goto propagate;
> > > + }
> >
> > I'm unsure about this one. Every clock should have the ability to stop
> > or continue the rate propagation to the parent. This suggests to leave
> > the decision whether or not to propagate to the core and not to the
> > individual clocks.
>
> Maybe I'm not understanding you correctly, but that's exactly what this
> code does. The decision to propagate is left up to the
> implementation-specific set_rate callback - if it returns
> CLK_SET_RATE_PROPAGATE (and populate the parent_rate argument with the
> requested parent rate), then we propagate the rate change to the parent.
I understood how the code is meant to work. It's just that IMO the place
where the propagation flag is stored is the wrong one, given that it's a
flag that all clocks (can) have.
>
> > Right now each mux/div/gate needs an individual propagate flag. By
> > adding the flag to the core the building block implementations could be
> > simpler and the knowledge about propagatability might become handy for
> > the core later.
>
> We could do this with a flag too, yes. But then there's no way of
> altering the rate (which we need to do with a divider) as we propagate
> it upwards. The current set_rate code lets us do that.
Hm, the core could pass a NULL pointer as the third argument to
set_rate to indicate that the parent rate is not allowed to change.
Then we could initialize &parent_rate to zero before calling set_rate.
If the set_rate function does not change it, we don't have to propagate,
otherwise yes. Or instead we could just use the CLK_SET_RATE_PROPAGATE
return value like we do in the current version.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] clk: Implement clk_set_rate
Date: Thu, 26 May 2011 08:54:29 +0200 [thread overview]
Message-ID: <20110526065429.GL20715@pengutronix.de> (raw)
In-Reply-To: <1306373867.2875.162.camel@pororo>
[put the lists back on cc]
On Thu, May 26, 2011 at 09:37:47AM +0800, Jeremy Kerr wrote:
> Hi Sascha,
>
> > > +
> > > +propagate:
> > > + ret = clk->ops->set_rate(clk->hw, new_rate, &parent_rate);
> > > +
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + /* ops->set_rate may require the parent's rate to change (to
> > > + * parent_rate), we need to propagate the set_rate call to the
> > > + * parent.
> > > + */
> > > + if (ret == CLK_SET_RATE_PROPAGATE) {
> > > + new_rate = parent_rate;
> > > + clk = clk->parent;
> > > + goto propagate;
> > > + }
> >
> > I'm unsure about this one. Every clock should have the ability to stop
> > or continue the rate propagation to the parent. This suggests to leave
> > the decision whether or not to propagate to the core and not to the
> > individual clocks.
>
> Maybe I'm not understanding you correctly, but that's exactly what this
> code does. The decision to propagate is left up to the
> implementation-specific set_rate callback - if it returns
> CLK_SET_RATE_PROPAGATE (and populate the parent_rate argument with the
> requested parent rate), then we propagate the rate change to the parent.
I understood how the code is meant to work. It's just that IMO the place
where the propagation flag is stored is the wrong one, given that it's a
flag that all clocks (can) have.
>
> > Right now each mux/div/gate needs an individual propagate flag. By
> > adding the flag to the core the building block implementations could be
> > simpler and the knowledge about propagatability might become handy for
> > the core later.
>
> We could do this with a flag too, yes. But then there's no way of
> altering the rate (which we need to do with a divider) as we propagate
> it upwards. The current set_rate code lets us do that.
Hm, the core could pass a NULL pointer as the third argument to
set_rate to indicate that the parent rate is not allowed to change.
Then we could initialize &parent_rate to zero before calling set_rate.
If the set_rate function does not change it, we don't have to propagate,
otherwise yes. Or instead we could just use the CLK_SET_RATE_PROPAGATE
return value like we do in the current version.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org
Subject: Re: [PATCH 2/4] clk: Implement clk_set_rate
Date: Thu, 26 May 2011 08:54:29 +0200 [thread overview]
Message-ID: <20110526065429.GL20715@pengutronix.de> (raw)
In-Reply-To: <1306373867.2875.162.camel@pororo>
[put the lists back on cc]
On Thu, May 26, 2011 at 09:37:47AM +0800, Jeremy Kerr wrote:
> Hi Sascha,
>
> > > +
> > > +propagate:
> > > + ret = clk->ops->set_rate(clk->hw, new_rate, &parent_rate);
> > > +
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + /* ops->set_rate may require the parent's rate to change (to
> > > + * parent_rate), we need to propagate the set_rate call to the
> > > + * parent.
> > > + */
> > > + if (ret == CLK_SET_RATE_PROPAGATE) {
> > > + new_rate = parent_rate;
> > > + clk = clk->parent;
> > > + goto propagate;
> > > + }
> >
> > I'm unsure about this one. Every clock should have the ability to stop
> > or continue the rate propagation to the parent. This suggests to leave
> > the decision whether or not to propagate to the core and not to the
> > individual clocks.
>
> Maybe I'm not understanding you correctly, but that's exactly what this
> code does. The decision to propagate is left up to the
> implementation-specific set_rate callback - if it returns
> CLK_SET_RATE_PROPAGATE (and populate the parent_rate argument with the
> requested parent rate), then we propagate the rate change to the parent.
I understood how the code is meant to work. It's just that IMO the place
where the propagation flag is stored is the wrong one, given that it's a
flag that all clocks (can) have.
>
> > Right now each mux/div/gate needs an individual propagate flag. By
> > adding the flag to the core the building block implementations could be
> > simpler and the knowledge about propagatability might become handy for
> > the core later.
>
> We could do this with a flag too, yes. But then there's no way of
> altering the rate (which we need to do with a divider) as we propagate
> it upwards. The current set_rate code lets us do that.
Hm, the core could pass a NULL pointer as the third argument to
set_rate to indicate that the parent rate is not allowed to change.
Then we could initialize &parent_rate to zero before calling set_rate.
If the set_rate function does not change it, we don't have to propagate,
otherwise yes. Or instead we could just use the CLK_SET_RATE_PROPAGATE
return value like we do in the current version.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2011-05-26 6:54 UTC|newest]
Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-20 7:27 [PATCH 0/4] Add a generic struct clk Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 7:27 ` [PATCH 4/4] clk: Add simple gated clock Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 11:37 ` Arnd Bergmann
2011-05-20 11:37 ` Arnd Bergmann
2011-05-20 11:37 ` Arnd Bergmann
2011-05-20 22:19 ` Rob Herring
2011-05-20 22:19 ` Rob Herring
2011-05-20 22:19 ` Rob Herring
2011-05-20 7:27 ` [PATCH 1/4] clk: Add a generic clock infrastructure Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 11:59 ` Sascha Hauer
2011-05-20 11:59 ` Sascha Hauer
2011-05-20 11:59 ` Sascha Hauer
2011-05-20 13:25 ` Thomas Gleixner
2011-05-20 13:25 ` Thomas Gleixner
2011-05-20 13:25 ` Thomas Gleixner
2011-05-20 13:36 ` Sascha Hauer
2011-05-20 13:36 ` Sascha Hauer
2011-05-20 13:36 ` Sascha Hauer
2011-05-23 23:55 ` Colin Cross
2011-05-23 23:55 ` Colin Cross
2011-05-23 23:55 ` Colin Cross
2011-05-24 7:02 ` Sascha Hauer
2011-05-24 7:02 ` Sascha Hauer
2011-05-24 7:02 ` Sascha Hauer
2011-05-24 7:51 ` Colin Cross
2011-05-24 7:51 ` Colin Cross
2011-05-24 7:51 ` Colin Cross
2011-05-24 8:38 ` Sascha Hauer
2011-05-24 8:38 ` Sascha Hauer
2011-05-24 8:38 ` Sascha Hauer
2011-05-25 11:22 ` Richard Zhao
2011-05-25 11:22 ` Richard Zhao
2011-05-25 11:22 ` Richard Zhao
2011-05-25 11:43 ` Thomas Gleixner
2011-05-25 11:43 ` Thomas Gleixner
2011-05-25 11:43 ` Thomas Gleixner
2011-05-24 4:18 ` viresh kumar
2011-05-24 4:30 ` viresh kumar
2011-05-24 4:18 ` viresh kumar
2011-05-25 10:47 ` Richard Zhao
2011-05-25 10:47 ` Richard Zhao
2011-05-25 10:47 ` Richard Zhao
2011-05-30 5:00 ` Mike Frysinger
2011-05-30 5:00 ` Mike Frysinger
2011-05-30 5:00 ` Mike Frysinger
2011-05-20 7:27 ` [PATCH 3/4] clk: Add fixed-rate clock Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-24 7:01 ` Francesco VIRLINZI
2011-05-30 5:01 ` Mike Frysinger
2011-05-30 5:01 ` Mike Frysinger
2011-05-30 5:01 ` Mike Frysinger
2011-05-30 5:02 ` Mike Frysinger
2011-05-30 5:02 ` Mike Frysinger
2011-05-30 5:02 ` Mike Frysinger
2011-05-20 7:27 ` [PATCH 2/4] clk: Implement clk_set_rate Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 7:27 ` Jeremy Kerr
2011-05-20 12:25 ` Sascha Hauer
2011-05-20 12:25 ` Sascha Hauer
2011-05-20 12:25 ` Sascha Hauer
2011-05-24 7:59 ` Colin Cross
2011-05-24 7:59 ` Colin Cross
2011-05-24 7:59 ` Colin Cross
2011-05-25 19:03 ` Sascha Hauer
2011-05-25 19:03 ` Sascha Hauer
2011-05-25 19:03 ` Sascha Hauer
[not found] ` <1306373867.2875.162.camel@pororo>
2011-05-26 6:54 ` Sascha Hauer [this message]
2011-05-26 6:54 ` Sascha Hauer
2011-05-26 6:54 ` Sascha Hauer
2011-05-30 5:05 ` Mike Frysinger
2011-05-30 5:05 ` Mike Frysinger
2011-05-30 5:05 ` Mike Frysinger
2011-05-23 23:12 ` [PATCH 0/4] Add a generic struct clk Colin Cross
2011-05-23 23:12 ` Colin Cross
2011-05-23 23:12 ` Colin Cross
2011-05-24 6:26 ` Sascha Hauer
2011-05-24 6:26 ` Sascha Hauer
2011-05-24 6:26 ` Sascha Hauer
2011-05-24 7:31 ` Colin Cross
2011-05-24 7:31 ` Colin Cross
2011-05-24 7:31 ` Colin Cross
2011-05-24 8:09 ` Sascha Hauer
2011-05-24 8:09 ` Sascha Hauer
2011-05-24 8:09 ` Sascha Hauer
2011-05-24 19:41 ` Colin Cross
2011-05-24 19:41 ` Colin Cross
2011-05-24 19:41 ` Colin Cross
2011-05-25 2:32 ` Richard Zhao
2011-05-25 2:32 ` Richard Zhao
2011-05-25 2:32 ` Richard Zhao
2011-05-25 6:23 ` Sascha Hauer
2011-05-25 6:23 ` Sascha Hauer
2011-05-25 6:23 ` Sascha Hauer
2011-05-25 7:51 ` Thomas Gleixner
2011-05-25 7:51 ` Thomas Gleixner
2011-05-25 7:51 ` Thomas Gleixner
2011-05-27 14:39 ` Mark Brown
2011-05-27 14:39 ` Mark Brown
2011-05-27 14:39 ` Mark Brown
2011-05-24 17:22 ` Richard Zhao
2011-05-24 17:22 ` Richard Zhao
2011-05-24 17:22 ` Richard Zhao
2011-05-24 17:52 ` Colin Cross
2011-05-24 17:52 ` Colin Cross
2011-05-24 17:52 ` Colin Cross
2011-05-25 2:08 ` Richard Zhao
2011-05-25 2:08 ` Richard Zhao
2011-05-25 2:08 ` Richard Zhao
2011-05-30 5:20 ` Mike Frysinger
2011-05-30 5:20 ` Mike Frysinger
2011-05-30 5:20 ` Mike Frysinger
2011-07-10 9:09 ` Mark Brown
2011-07-10 9:09 ` Mark Brown
2011-07-10 9:09 ` Mark Brown
2011-07-10 9:50 ` Russell King - ARM Linux
2011-07-10 9:50 ` Russell King - ARM Linux
2011-07-10 9:50 ` Russell King - ARM Linux
2011-07-10 10:00 ` Russell King - ARM Linux
2011-07-10 10:00 ` Russell King - ARM Linux
2011-07-10 10:00 ` Russell King - ARM Linux
2011-07-10 11:27 ` Mark Brown
2011-07-10 11:27 ` Mark Brown
2011-07-10 11:27 ` Mark Brown
2011-07-10 11:52 ` Russell King - ARM Linux
2011-07-10 11:52 ` Russell King - ARM Linux
2011-07-10 11:52 ` Russell King - ARM Linux
2011-07-11 2:49 ` Jeremy Kerr
2011-07-11 2:49 ` Jeremy Kerr
2011-07-11 2:49 ` Jeremy Kerr
2011-07-11 3:57 ` Mark Brown
2011-07-11 3:57 ` Mark Brown
2011-07-11 3: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=20110526065429.GL20715@pengutronix.de \
--to=s.hauer@pengutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.