archive mirror
 help / color / mirror / Atom feed
From: Jonas Gorski <>
To: Christophe JAILLET
Cc: Mark Brown <>,
	Florian Fainelli
Subject: Re: [PATCH] spi: bcm63xx-hsspi: Really keep pll clk enabled
Date: Mon, 2 Mar 2020 14:03:04 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 28 Feb 2020 at 22:38, Christophe JAILLET
<> wrote:
> The purpose of commit 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled")
> was to keep the pll clk enabled through the lifetime of the device.
> In order to do that, some 'clk_prepare_enable()'/'clk_disable_unprepare()'
> calls have been added in the error handling path of the probe function, in
> the remove function and in the suspend and resume functions.
> However, a 'clk_disable_unprepare()' call has been unfortunately left in
> the probe function. So the commit seems to be more or less a no-op.
> Axe it now, so that the pll clk is left enabled through the lifetime of
> the device, as described in the commit.

Good catch!

Acked-by: Jonas Gorski <>

> Fixes: 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled")
> Signed-off-by: Christophe JAILLET <>
> ---
> To be honest, I don't see why we need to keep pll clk, or hsspi clk
> enabled during the lifetime of the driver. My understanding of the code is
> that it is only used to get the 'speed_hz' value in the probe function.
> This value is never refreshed afterwards.
> I don't see the point in enabling/disabling the clks. I think that they
> both could be disabled in the probe function, without the need to keep
> track in the bcm63xx_hsspi structure, neither during pm cycles or the
> remove fucntion.

The hsspi clock is actually gated, so it needs to stay on during use.
The pll clock is only used to convey the rate, but is not gate-able.
These used to be the same (that's why it checks for the rate of the
hsspi clock first), but were split to make it easier to move to common
clock framework (since we can just use the generic gated and
fixed-rate clock implementations).

Incidentally these are AFAIK also two inputs, so it even happens to
match the hardware more closely.

Since the pll clock isn't gated, we don't need to keep it enabled - we
don't even need to enable it in theory, but IIRC the common clock
system will complain if you try to get the rate of a non-enabled
clock. And if we do enable it, then we can also just keep it enabled
over the lifetime of the device.


  parent reply	other threads:[~2020-03-02 13:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28 21:38 Christophe JAILLET
     [not found] ` <>
2020-03-02 12:38   ` Mark Brown
2020-03-02 13:03   ` Jonas Gorski [this message]
2020-03-02 16:05 ` Applied "spi: bcm63xx-hsspi: Really keep pll clk enabled" to the spi tree 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \
    --cc=bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] spi: bcm63xx-hsspi: Really keep pll clk enabled' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).