linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: "David.Wu" <david.wu@rock-chips.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	'黄涛' <huangtao@rock-chips.com>,
	"Kever Yang" <kever.yang@rock-chips.com>,
	张睛 <zhangqing@rock-chips.com>, 许剑群 <jay.xu@rock-chips.com>,
	"Doug Anderson" <dianders@chromium.org>,
	"Brian Norris" <briannorris@chromium.org>,
	linux-rockchip@lists.infradead.org,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@codeaurora.org>
Subject: Re: [v5,22/46] pwm: rockchip: avoid glitches on already running PWMs
Date: Fri, 04 Aug 2017 16:48:56 +0200	[thread overview]
Message-ID: <2250536.aM833QY2s7@phil> (raw)
In-Reply-To: <20170804160701.4d9f404d@bbrezillon>

Hi,

Am Freitag, 4. August 2017, 16:07:01 CEST schrieb Boris Brezillon:
> +Stephen, Mike and the linux-clk ML.
>=20
> On Fri, 4 Aug 2017 20:45:04 +0800
> "David.Wu" <david.wu@rock-chips.com> wrote:
>=20
> > Hi Boris & Heiko,
> >=20
> > =E5=9C=A8 2016/3/31 4:03, Boris BREZILLON =E5=86=99=E9=81=93:
> > > +	/* Keep the PWM clk enabled if the PWM appears to be up and running=
=2E */
> > > +	pwm_get_state(pc->chip.pwms, &pstate);
> > > +	if (!pstate.enabled)
> > > +		clk_disable(pc->clk); =20
> >=20
> > We found a issue recently, if the pwm0 is not enabled at uboot and pwm2=
=20
> > is enabled at uboot, the PWM clock will be disabled at pwm0's probe. It=
=20
> > is true to close the pwm clock, and the pwm2 can't work during a while,=
=20
> > until the pwm2 probe, because the pwm0 and pwm2 are the same clock for=
=20
> > their work. In fact, the pwm0 can not know the pwm2's status.
> >=20
> > So we need to get all the PWMs state in a public place where it's early=
=20
> > than the PWM probe, if that's the way it is. Then keep the PWM clk=20
> > enabled if theis is one PWM appears to be up and running. The place=20
> > maybe in the clock core init, like adding pwm clock as critial one.
> >=20
> > Another way is that we don't enable pwm clock firstly at PWM probe,=20
> > because whether or not the PWM state has been enabled in the Uboot, lik=
e=20
> > other modules, our chip default PWM clock registers are enabled at the=
=20
> > beginning, read the PWM registers directly to know the PWM state. Then=
=20
> > if the PWM state is enabled, call the enable_clk(pc->clk) to add the=20
> > clock count=3D1. If the PWM state is disabled, we do nothing. After all=
=20
> > the PWMs are probed and all modules are probed, the clock core will gat=
e=20
> > the PWM clock if the clock count is 0, and keep clk enabled if the cloc=
k=20
> > count is not 0.
> >=20
> > How do you feel about it?
>=20
> Ouch. That's indeed hard to solve in a clean way. I may have
> something to suggest but I'm not sure clk maintainers will like it: what
> if we make clk_disable() and clk_unprepare() just decrement the refcount
> before the disable-unused-clks procedure has been executed (see
> proposed patch below)? This way all clks that have been enabled by the
> bootloader will stay in such state until all drivers have had a chance
> to retain them (IOW, call clk_prepare()+clk_enable()).
>=20
> BTW, I think the problem you're describing here is not unique to PWM
> devices, it's just that now, some PWM drivers are smart and try to keep
> clks enabled to prevent glitches.

Actually, Mike had patches that introduced so called "handoff" clocks [0].
Clocks that were handled as critical until some driver picked them up.

It's not exactly the same as your change and still would require
intervention from clock-drivers to mark clocks in such a way.

So I really also like your approach, as it would make clock wiggling
during early boot safe for everyone involved :-) .

And both seem to cater to slightly different use-cases as well.


Heiko

[0] https://lwn.net/Articles/675658/

> --->8---
> From 47dcdc1bcc30b3ae1f76d33be824d2519a4dcca8 Mon Sep 17 00:00:00 2001
> From: Boris Brezillon <boris.brezillon@free-electrons.com>
> Date: Fri, 4 Aug 2017 15:55:49 +0200
> Subject: [PATCH] clk: Keep clocks in their initial state until
>  clk_disable_unused() is called
>=20
> Some drivers are briefly preparing+enabling the clock in their
> ->probe() hook and disable+unprepare them before leaving the function.
>=20
> This can be problem if a clock is shared between different devices, and
> one of these devices is critical to the system. If this clock is
> enabled/disabled by a non-critical device before the driver of the
> critical one had a chance to enable+prepare it, there might be a short
> period of time during which the critical device is not clocked.
>=20
> To solve this problem, we save the initial clock state (at registration
> time) and prevent the clock from being disabled until kernel init is done
> (which is when clk_disable_unused() is called).
>=20
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
>  drivers/clk/clk.c | 29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>=20
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index fc58c52a26b4..3f61374a364b 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -58,6 +58,8 @@ struct clk_core {
>  	struct clk_core		*new_child;
>  	unsigned long		flags;
>  	bool			orphan;
> +	bool			keep_enabled;
> +	bool			keep_prepared;
>  	unsigned int		enable_count;
>  	unsigned int		prepare_count;
>  	unsigned long		min_rate;
> @@ -486,7 +488,7 @@ static void clk_core_unprepare(struct clk_core *core)
> =20
>  	trace_clk_unprepare(core);
> =20
> -	if (core->ops->unprepare)
> +	if (core->ops->unprepare && !core->keep_prepared)
>  		core->ops->unprepare(core->hw);
> =20
>  	trace_clk_unprepare_complete(core);
> @@ -602,7 +604,7 @@ static void clk_core_disable(struct clk_core *core)
> =20
>  	trace_clk_disable_rcuidle(core);
> =20
> -	if (core->ops->disable)
> +	if (core->ops->disable && !core->keep_enabled)
>  		core->ops->disable(core->hw);
> =20
>  	trace_clk_disable_complete_rcuidle(core);
> @@ -739,6 +741,12 @@ static void clk_unprepare_unused_subtree(struct clk_=
core *core)
>  	hlist_for_each_entry(child, &core->children, child_node)
>  		clk_unprepare_unused_subtree(child);
> =20
> +	/*
> +	 * Reset the ->keep_prepared flag so that subsequent calls to
> +	 * clk_unprepare() on this clk actually unprepare it.
> +	 */
> +	core->keep_prepared =3D false;
> +
>  	if (core->prepare_count)
>  		return;
> =20
> @@ -770,6 +778,12 @@ static void clk_disable_unused_subtree(struct clk_co=
re *core)
> =20
>  	flags =3D clk_enable_lock();
> =20
> +	/*
> +	 * Reset the ->keep_enabled flag so that subsequent calls to
> +	 * clk_disable() on this clk actually disable it.
> +	 */
> +	core->keep_enabled =3D false;
> +
>  	if (core->enable_count)
>  		goto unlock_out;
> =20
> @@ -2446,6 +2460,17 @@ static int __clk_core_init(struct clk_core *core)
>  		core->accuracy =3D 0;
> =20
>  	/*
> +	 * We keep track of the initial clk status to keep clks in the state
> +	 * they were left in by the bootloader until all drivers had a chance
> +	 * to keep them prepared/enabled if they need to.
> +	 */
> +	if (core->ops->is_prepared && !clk_ignore_unused)
> +		core->keep_prepared =3D core->ops->is_prepared(core->hw);
> +
> +	if (core->ops->is_enabled && !clk_ignore_unused)
> +		core->keep_enabled =3D core->ops->is_enabled(core->hw);
> +
> +	/*
>  	 * Set clk's phase.
>  	 * Since a phase is by definition relative to its parent, just
>  	 * query the current clock phase, or just assume it's in phase.
>=20
>=20

  reply	other threads:[~2017-08-04 14:48 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 20:03 [PATCH v5 00/46] pwm: add support for atomic update Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 01/46] pwm: rcar: make use of pwm_is_enabled() Boris Brezillon
2016-04-12 11:01   ` Thierry Reding
2016-04-14 11:05     ` Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 02/46] backlight: pwm_bl: remove useless call to pwm_set_period() Boris Brezillon
2016-04-12 11:03   ` Thierry Reding
2016-04-12 14:16     ` Lee Jones
2016-04-12 14:25       ` Thierry Reding
2016-03-30 20:03 ` [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field Boris Brezillon
2016-04-12 11:08   ` Thierry Reding
2016-04-12 14:16     ` Lee Jones
2016-04-12 14:26       ` Thierry Reding
2016-04-13  8:25         ` Lee Jones
2016-04-13  8:26           ` Lee Jones
2016-03-30 20:03 ` [PATCH v5 04/46] pwm: get rid of pwm->lock Boris Brezillon
2016-04-12 11:22   ` Thierry Reding
2016-04-12 11:32     ` Boris Brezillon
2016-04-12 11:46       ` Thierry Reding
2016-03-30 20:03 ` [PATCH v5 05/46] pwm: introduce the pwm_args concept Boris Brezillon
2016-03-30 21:55   ` Stephen Boyd
2016-03-31  7:09     ` Boris Brezillon
2016-03-31  7:57     ` Boris Brezillon
2016-04-12 11:39   ` Thierry Reding
2016-04-12 12:04     ` Boris Brezillon
2016-04-12 12:20       ` Thierry Reding
2016-04-12 12:55         ` Boris Brezillon
2016-04-12 13:06     ` Boris Brezillon
2016-04-12 13:15       ` Thierry Reding
2016-03-30 20:03 ` [PATCH v5 06/46] pwm: use pwm_get/set_xxx() helpers where appropriate Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 07/46] clk: pwm: use pwm_get_args() " Boris Brezillon
2016-03-30 21:58   ` Stephen Boyd
2016-03-30 20:03 ` [PATCH v5 08/46] hwmon: pwm-fan: " Boris Brezillon
2016-03-30 22:52   ` Guenter Roeck
2016-03-31  7:07     ` Boris Brezillon
2016-04-04 15:20       ` Thierry Reding
2016-04-01  8:29   ` Kamil Debski
2016-03-30 20:03 ` [PATCH v5 09/46] misc: max77693-haptic: " Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 10/46] leds: pwm: " Boris Brezillon
2016-03-31  7:13   ` Jacek Anaszewski
2016-03-30 20:03 ` [PATCH v5 11/46] regulator: " Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 12/46] fbdev: ssd1307fb: " Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 13/46] backlight: pwm_bl: " Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 14/46] pwm: keep PWM state in sync with hardware state Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 15/46] pwm: introduce the pwm_state concept Boris Brezillon
2016-04-12 11:49   ` Thierry Reding
2016-04-12 12:17     ` Boris Brezillon
2016-04-12 12:21       ` Thierry Reding
2016-04-12 12:45         ` Boris Brezillon
2016-04-12 13:11           ` Thierry Reding
2016-04-12 13:26             ` Boris Brezillon
2016-04-12 14:05               ` Thierry Reding
2016-04-12 14:13                 ` Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 16/46] pwm: move the enabled/disabled info into pwm_state Boris Brezillon
2016-04-12 11:51   ` Thierry Reding
2016-03-30 20:03 ` [PATCH v5 17/46] pwm: add the PWM initial state retrieval infra Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 18/46] pwm: add the core infrastructure to allow atomic update Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 19/46] pwm: switch to the atomic API Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 20/46] pwm: add information about polarity, duty cycle and period to debugfs Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 21/46] pwm: rockchip: add initial state retrieval Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 22/46] pwm: rockchip: avoid glitches on already running PWMs Boris Brezillon
     [not found]   ` <a5efa7d7-ceb5-e6b0-b2d1-2d79cd20265f@rock-chips.com>
2017-08-04 14:07     ` [v5,22/46] " Boris Brezillon
2017-08-04 14:48       ` Heiko Stuebner [this message]
2017-08-04 16:22         ` Doug Anderson
2017-08-21 15:39           ` Boris Brezillon
2017-08-21 16:49             ` Doug Anderson
2017-08-21 19:50               ` Boris Brezillon
2017-08-07  7:43         ` Elaine Zhang
2016-03-30 20:03 ` [PATCH v5 23/46] pwm: rockchip: add support for atomic update Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 24/46] pwm: sti: add support for initial state retrieval Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 25/46] pwm: sti: avoid glitches on already running PWMs Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 26/46] pwm: sun4i: implement hardware readout Boris Brezillon
2016-03-31  8:00   ` Alexandre Belloni
2016-03-30 20:03 ` [PATCH v5 27/46] regulator: pwm: adjust PWM config at probe time Boris Brezillon
2016-03-30 21:22   ` Mark Brown
2016-03-30 20:03 ` [PATCH v5 28/46] regulator: pwm: swith to the atomic PWM API Boris Brezillon
2016-03-30 21:23   ` Mark Brown
2016-03-30 20:03 ` [PATCH v5 29/46] regulator: pwm: properly initialize the ->state field Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 30/46] regulator: pwm: retrieve correct voltage Boris Brezillon
2016-03-30 21:24   ` Mark Brown
2016-04-07 21:54     ` Boris Brezillon
2016-04-12  4:42       ` Mark Brown
2016-04-12  8:37         ` Boris Brezillon
2016-04-12 10:09           ` Mark Brown
2016-04-12 10:31             ` Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 31/46] pwm: update documentation Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 32/46] pwm: deprecate pwm_config(), pwm_enable() and pwm_disable() Boris Brezillon
2016-03-31 17:38   ` Dmitry Torokhov
2016-03-31 18:54     ` Boris Brezillon
2016-04-04 15:22       ` Thierry Reding
2016-03-30 20:03 ` [PATCH v5 33/46] pwm: replace pwm_disable() by pwm_apply_state() Boris Brezillon
2016-03-30 20:03 ` [PATCH v5 34/46] clk: pwm: switch to the atomic API Boris Brezillon
2016-03-30 22:01   ` Stephen Boyd
2016-03-31  6:57     ` Boris Brezillon
2016-04-04 15:30       ` Thierry Reding
2016-03-30 20:03 ` [PATCH v5 35/46] hwmon: pwm-fan: " Boris Brezillon
2016-04-01  8:29   ` Kamil Debski
2016-03-30 20:03 ` [PATCH v5 36/46] input: misc: max77693: " Boris Brezillon
2016-03-31 17:48   ` Dmitry Torokhov
2016-03-31 18:57     ` Boris Brezillon
2016-04-04 15:34       ` Thierry Reding
2016-03-30 20:04 ` [PATCH v5 37/46] input: misc: max8997: switch to the atomic PWM API Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 38/46] input: misc: pwm-beeper: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 39/46] leds: pwm: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 40/46] backlight: lm3630a: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 41/46] backlight: lp855x: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 42/46] backlight: lp8788: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 43/46] backlight: pwm_bl: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 44/46] video: ssd1307fb: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 45/46] drm: i915: " Boris Brezillon
2016-03-30 20:04 ` [PATCH v5 46/46] ARM: s3c24xx: rx1950: " Boris Brezillon
2016-03-30 20:18 ` [PATCH v5 00/46] pwm: add support for atomic update Boris Brezillon
2016-04-11 22:42 ` Boris Brezillon

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=2250536.aM833QY2s7@phil \
    --to=heiko@sntech.de \
    --cc=boris.brezillon@free-electrons.com \
    --cc=briannorris@chromium.org \
    --cc=david.wu@rock-chips.com \
    --cc=dianders@chromium.org \
    --cc=huangtao@rock-chips.com \
    --cc=jay.xu@rock-chips.com \
    --cc=kever.yang@rock-chips.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=thierry.reding@gmail.com \
    --cc=zhangqing@rock-chips.com \
    /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).