From: jbrunet@baylibre.com (Jerome Brunet)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH v3 00/10] clk: implement clock rate protection mechanism
Date: Tue, 20 Jun 2017 14:32:30 +0200 [thread overview]
Message-ID: <1497961950.7387.7.camel@baylibre.com> (raw)
In-Reply-To: <CACRpkdacB3HKgewSciQWB0c8v2KCF7u+eT0A_RSC0+z_KrQzhA@mail.gmail.com>
On Tue, 2017-06-20 at 13:54 +0200, Linus Walleij wrote:
> On Tue, Jun 20, 2017 at 12:50 PM, Jerome Brunet <jbrunet@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
next prev parent reply other threads:[~2017-06-20 12:32 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 19:44 [PATCH v3 00/10] clk: implement clock rate protection mechanism Jerome Brunet
2017-06-12 19:44 ` [PATCH v3 01/10] clk: take the prepare lock out of clk_core_set_parent Jerome Brunet
2017-07-12 1:21 ` Stephen Boyd
2017-06-12 19:44 ` [PATCH v3 02/10] clk: add clk_core_set_phase_nolock function Jerome Brunet
2017-07-12 1:22 ` Stephen Boyd
2017-06-12 19:44 ` [PATCH v3 03/10] clk: rework calls to round and determine rate callbacks Jerome Brunet
2017-07-12 1:49 ` Stephen Boyd
2017-06-12 19:44 ` [PATCH v3 04/10] clk: use round rate to bail out early in set_rate Jerome Brunet
2017-07-12 2:00 ` Stephen Boyd
2017-07-26 17:13 ` Jerome Brunet
2017-08-04 0:32 ` Stephen Boyd
2017-06-12 19:44 ` [PATCH v3 05/10] clk: add support for clock protection Jerome Brunet
2017-07-26 0:12 ` Stephen Boyd
2017-07-26 17:18 ` Jerome Brunet
2017-08-04 0:18 ` Stephen Boyd
2017-08-08 22:37 ` Michael Turquette
2017-08-09 2:19 ` Stephen Boyd
2017-08-09 11:45 ` Russell King - ARM Linux
2017-08-09 13:34 ` Jerome Brunet
2017-08-09 13:40 ` Russell King - ARM Linux
2017-08-09 13:45 ` Jerome Brunet
2017-08-10 16:48 ` Michael Turquette
2017-08-10 16:46 ` Michael Turquette
2017-08-09 13:07 ` Jerome Brunet
2017-08-09 12:18 ` Jerome Brunet
2017-08-10 16:54 ` Michael Turquette
2017-06-12 19:44 ` [PATCH v3 06/10] clk: add clk_set_rate_protect Jerome Brunet
2017-07-26 0:59 ` Stephen Boyd
2017-06-12 19:44 ` [PATCH v3 07/10] clk: rollback set_rate_range changes on failure Jerome Brunet
2017-07-12 2:02 ` Stephen Boyd
2017-07-26 17:22 ` Jerome Brunet
2017-06-12 19:44 ` [PATCH v3 08/10] clk: cosmetic changes to clk_summary debugfs entry Jerome Brunet
2017-07-12 2:02 ` Stephen Boyd
2017-06-12 19:44 ` [PATCH v3 09/10] clk: fix incorrect usage of ENOSYS Jerome Brunet
2017-07-12 2:03 ` Stephen Boyd
2017-06-12 19:44 ` [PATCH v3 10/10] clk: fix CLK_SET_RATE_GATE with clock rate protection Jerome Brunet
2017-06-20 9:07 ` [PATCH v3 00/10] clk: implement clock rate protection mechanism Linus Walleij
2017-06-20 10:50 ` Jerome Brunet
2017-06-20 11:54 ` Linus Walleij
2017-06-20 12:32 ` Jerome Brunet [this message]
2017-06-20 12:47 ` Boris Brezillon
2017-06-22 7:07 ` Quentin Schulz
2017-06-22 10:09 ` Jerome Brunet
2017-06-20 15:29 ` Linus Walleij
2017-06-21 13:15 ` Jerome Brunet
2017-07-12 1:16 ` Stephen Boyd
2017-07-26 17:05 ` Jerome Brunet
2017-07-27 22:44 ` Stephen Boyd
2017-08-08 22:40 ` Michael Turquette
2017-08-09 12:14 ` Jerome Brunet
2017-07-11 21:04 ` Jerome Brunet
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=1497961950.7387.7.camel@baylibre.com \
--to=jbrunet@baylibre.com \
--cc=linus-amlogic@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).