[PATCH v3 00/10] clk: implement clock rate protection mechanism

Jerome Brunet jbrunet at baylibre.com
Tue Jun 20 05:32:30 PDT 2017

On Tue, 2017-06-20 at 13:54 +0200, Linus Walleij wrote:
> On Tue, Jun 20, 2017 at 12:50 PM, Jerome Brunet <jbrunet at baylibre.com> wrote:
> > On Tue, 2017-06-20 at 11:07 +0200, Linus Walleij wrote:
> > When the rate is critical to perform a particular task. My example is the
> > audio
> > and i2s output. You can't tolerate glitches during the playback, the end
> > user
> > would complain (longer description in the original RFC)
> I see. Thanks for your detailed explanation!
> > It also fixes the behavior of CLK_SET_RATE_GATE flag, which is why I put you
> > in
> > CC.
> > 
> > ux500 uses this flag several time, I'd like make sure people are not relying
> > on
> > its broken implementation.
> Ux500 audio is broken, but I'm fixing it a little at a time...

No problem with Ux500 audio, don't worry :)
Audio is just one application among others.

The concern regarding ux500 is that the clock controller declares clocks using
the CLK_SET_RATE_GATE flag (like qcom, at91 and several other)

here is the definition:
#define CLK_SET_RATE_GATE	BIT(0) /* must be gated across rate change */

My interpretation it that, as long as clock is enabled, rate can't change.

The implementation of this flag is currently broken:
* If you call set_rate on directly on the clock while it is enabled, you will
get -EBUSY, as expected
* If you call set_rate on its parent, rate will change, changing the rate of the
child clock as well ...

With this patchset applied, calling set_rate on the parent would also return
-EBUSY, enforcing the "rate can't change while enabled" property.

To build confidence that this won't be causing regression, I'd like to check
that platform using this flag are no relying on the broken behavior.

I've included the clock maintainers of at91, qcom, and ux500 (you) in this
thread because they are the heaviest users of this flag, so the more likely to
report a problem.

If you could apply this series and just do things as usual, It'd be awesome !

I'll also seek the help of the kci guys, see if it is possible to give the
series spin on it.

> Yours,
> Linus Walleij

More information about the linux-amlogic mailing list