All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Eric Anholt <eric@anholt.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	bcm-kernel-feedback-list@broadcom.com,
	Stefan Wahren <stefan.wahren@i2se.com>,
	Lee Jones <lee@kernel.org>,
	linux-rpi-kernel@lists.infradead.org,
	Mike Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	linux-clk@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 4/4] clk: bcm2835: Make sure the PLL is gated before changing its rate
Date: Mon, 12 Feb 2018 10:27:52 +0100	[thread overview]
Message-ID: <20180212102752.21e22328@bbrezillon> (raw)
In-Reply-To: <87vaf6v77r.fsf@anholt.net>

-Stephen Warren
+Stefan Wahren

On Fri, 09 Feb 2018 09:32:40 +0000
Eric Anholt <eric@anholt.net> wrote:

> Boris Brezillon <boris.brezillon@bootlin.com> writes:
> 
> > On Thu, 08 Feb 2018 15:20:16 +0000
> > Eric Anholt <eric@anholt.net> wrote:
> >  
> >> Boris Brezillon <boris.brezillon@bootlin.com> writes:
> >>   
> >> > All bcm2835 PLLs should be gated before their rate can be changed.
> >> > Setting CLK_SET_RATE_GATE will let the core enforce that, but this is
> >> > not enough to make the code work in all situations. Indeed, the
> >> > CLK_SET_RATE_GATE flag prevents a user from changing the rate while
> >> > the clock is enabled, but this check only guarantees there's no Linux
> >> > users. In our case, the clock might have been enabled by the
> >> > bootloader/FW, and, because we have CLK_IGNORE_UNUSED set, Linux never
> >> > disables the PLL. So we have to make sure the PLL is actually disabled
> >> > before changing the rate.
> >> >
> >> > Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
> >> > Cc: <stable@vger.kernel.org>
> >> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> >> > ---
> >> >  drivers/clk/bcm/clk-bcm2835.c | 14 +++++++++++++-
> >> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> >> > index 6c5d4a8e426c..051ce769c109 100644
> >> > --- a/drivers/clk/bcm/clk-bcm2835.c
> >> > +++ b/drivers/clk/bcm/clk-bcm2835.c
> >> > @@ -678,6 +678,18 @@ static int bcm2835_pll_set_rate(struct clk_hw *hw,
> >> >  	u32 ana[4];
> >> >  	int i;
> >> >  
> >> > +	/*
> >> > +	 * Normally, the CLK_SET_RATE_GATE flag prevents a user from changing
> >> > +	 * the rate while the clock is enabled, but this check only makes sure
> >> > +	 * there's no Linux users.
> >> > +	 * In our case, the clock might have been enabled by the bootloader/FW,
> >> > +	 * and, since CLK_IGNORE_UNUSED flag is set, Linux never disables it.
> >> > +	 * So we have to make sure the clk is actually disabled before changing
> >> > +	 * the rate.
> >> > +	 */
> >> > +	if (bcm2835_pll_is_on(hw))
> >> > +		bcm2835_pll_off(hw);
> >> > +    
> >> 
> >> I'm not sure this improves the situation.  If the PLL was on, then
> >> presumably there's a divider using it and a CM clock using that, so
> >> we'll probably end up driving some glitches on them.  
> >
> > Hm, yes, but if someone is trying to change the rate of the PLL, and the
> > core doesn't know other clks depend on this PLL (which is the case if
> > we reach this point), we're already in big trouble.
> >  
> >> 
> >> Does the common clk framework have a way to disable unused clocks from
> >> the leaf clocks up to this root, before the general
> >> disable-unused-clocks path happens late in the boot process?  
> >
> > Not that I know of. What do you have in mind?   
> 
> I was hoping that Stephen Boyd or Mike might have an answer for this
> problem.

Having a generic solution for this sort of issue is definitely the
way to go, but I think this temporary hack is needed to make HDMI/SDTV
work properly. If we don't have it and the FW configures and enables
PLLH with a rate that is different from the one the HDMI or SDTV
encoder tries to set, we're screwed, because I doubt the CPRMAN block
allows you to change the rate of the PLL when it's not gated. Which
means the new rate is not applied and the clk user has no way of
knowing that, which in turn means the display output is likely to not
work properly the first time it's enabled.

Of course, this all goes away the second time the HDMI/SDTV encoder is
enabled, because then clk_disable_unprepare() is called which has the
effect of disabling the PLL.

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

  reply	other threads:[~2018-02-12  9:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08 13:43 [PATCH 1/4] clk: bcm2835: Fix ana->maskX definitions Boris Brezillon
2018-02-08 13:43 ` [PATCH 2/4] clk: bcm2835: Protect sections updating shared registers Boris Brezillon
2018-02-08 15:14   ` Eric Anholt
2018-02-09  9:34   ` Eric Anholt
2018-03-19 16:29   ` Stephen Boyd
2018-03-19 16:29     ` Stephen Boyd
2018-02-08 13:43 ` [PATCH 3/4] clk: bcm2835: De-assert/assert PLL reset signal when appropriate Boris Brezillon
2018-02-08 15:15   ` Eric Anholt
2018-02-08 17:49     ` Boris Brezillon
2018-02-14 10:37     ` Boris Brezillon
2018-02-22 20:18       ` Eric Anholt
2018-02-08 13:43 ` [PATCH 4/4] clk: bcm2835: Make sure the PLL is gated before changing its rate Boris Brezillon
2018-02-08 15:20   ` Eric Anholt
2018-02-08 17:56     ` Boris Brezillon
2018-02-09  9:32       ` Eric Anholt
2018-02-12  9:27         ` Boris Brezillon [this message]
2018-03-12 21:21           ` Stephen Boyd
2018-03-12 21:21             ` Stephen Boyd
2018-03-13 16:56             ` Eric Anholt
2018-03-19 16:26               ` Stephen Boyd
2018-03-19 16:26                 ` Stephen Boyd
2018-03-22  9:13             ` Boris Brezillon
2018-03-22 16:38               ` Eric Anholt
2018-03-19 16:29 ` [PATCH 1/4] clk: bcm2835: Fix ana->maskX definitions Stephen Boyd
2018-03-19 16:29   ` Stephen Boyd

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=20180212102752.21e22328@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=eric@anholt.net \
    --cc=f.fainelli@gmail.com \
    --cc=lee@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=rjui@broadcom.com \
    --cc=sboyd@codeaurora.org \
    --cc=sbranden@broadcom.com \
    --cc=stable@vger.kernel.org \
    --cc=stefan.wahren@i2se.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 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.