LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Lubomir Rintel <lkundrak@v3.sk>,
	Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] clk: mmp2: avoid disabling the SP clock when unused
Date: Fri, 18 Jan 2019 09:31:10 -0800
Message-ID: <154783267051.169631.3197836544646625747@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <bec06415e980f18d5d3407d498cad372dc3abd1b.camel@v3.sk>

Quoting Lubomir Rintel (2019-01-17 01:47:55)
> On Wed, 2019-01-16 at 15:29 -0800, Stephen Boyd wrote:
> > Quoting Lubomir Rintel (2019-01-16 09:26:31)
> > > On Wed, 2019-01-16 at 08:37 -0800, Stephen Boyd wrote:
> > > > 
> > > > Is it a critical clk that should never be turned off?
> > > 
> > > I don't think it is. It is entirely plausible to have no use for the
> > > "security processor", and in that case it's just okay to keep the clock
> > > disabled.
> > 
> > So does the firmware/bootloader leave the clk enabled out of boot and we
> > shouldn't really touch the on/off bits of the clk hardware from the
> > kernel?
> 
> I think so.
> 
> > Or do we want to actively manage this clk from a driver
> > somewhere in the kernel?
> 
> The olpc_apsp driver actually manages this clock, but that might turn
> out to be the wrong thing to do. It currently only works if the driver
> is built-in and thus the clock is always kept enabled.
> 
> I'm now somewhat more confused that I believed myself to be when
> sending the patch. Perhaps you could help me understand things a bit
> more:
> 
> 1.) What's the principal difference between CLK_IGNORE_UNUSED and
> CLK_IS_CRITICAL? Is it that the CLK_IGNORE_UNUSED clocks are permitted 
> to be disabled by a driver, but an attempt to disable CLK_IS_CRITICAL
> is a bug?

Yes. CLK_IGNORE_UNUSED is a workaround for two opposing forces. The
first being the lack of a way for the clk framework to "hand off" the
state of a clk to clk consumers after late init and the second being the
desire to save power by disabling unused clocks.

> 
> 2.) Perhaps it makes sense to disable the SP on the machines that don't
> utilize it even if firmware keeps it enabled? Would it make sense to
> make the clk driver use the  "protected-clocks" DT property for this?

I don't think so. The protected-clocks property lists clks that
shouldn't be touched by the OS. Critical clks in theory are still
touched because the framework turns them on once, in case they're not
already enabled. That's sort of a weird implementation detail that some
drivers rely on. We haven't had a situation where drivers shouldn't
read/write clk registers but also mark them as critical. I would think
that we just wouldn't register those clks with the kernel because they
would never be used.

Does having this clk actually matter? Maybe it can just be removed
instead? Put another way, is it saving any power to manage the clk from
the kernel?

> 
> ----8<----
> 
> Here's some more context for the SP on the MMP2:
> 
> The SP is a small PJ1 core. It starts when the platform is powered on
> and eventually brings up the large PJ4 core.
> 
> On the OLPC machine, the first stage firmware (cforth) starts running
> on the SP, configures the DRAM, starts the boot firmware (openfirmware)
> on the main PJ4 core and then enters a loop that bit-bangs the PS/2
> protocol on the attached keyboard/touchpad.
> 
> It is entirely possible that on some boards the SP is not used for
> anything but the bringup of the bootloader on the main core.
> 
> SP is sometimes referred to as WTM, "wireless trusted module", but it's
> not clear to me why is it the case. There's no documentation.
> 

Ok. Thanks for the background.


      reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16  9:35 Lubomir Rintel
2019-01-16 16:37 ` Stephen Boyd
2019-01-16 17:26   ` Lubomir Rintel
2019-01-16 23:29     ` Stephen Boyd
2019-01-17  9:47       ` Lubomir Rintel
2019-01-18 17:31         ` Stephen Boyd [this message]

Reply instructions:

You may reply publically 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=154783267051.169631.3197836544646625747@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkundrak@v3.sk \
    --cc=mturquette@baylibre.com \
    --cc=stable@vger.kernel.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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox