Linux-Clk Archive on lore.kernel.org
 help / color / Atom feed
From: Samuel Holland <samuel@sholland.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Chen-Yu Tsai <wens@csie.org>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Corentin Labbe <clabbe.montjoie@gmail.com>,
	Vasily Khoruzhick <anarsoul@gmail.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-sunxi@googlegroups.com
Subject: Re: [PATCH v4 02/10] clk: sunxi-ng: Mark AR100 clocks as critical
Date: Tue, 20 Aug 2019 08:02:55 -0500
Message-ID: <3b67534a-eb1b-c1e8-b5e8-e0a74ae85792@sholland.org> (raw)
In-Reply-To: <20190820071142.2bgfsnt75xfeyusp@flea>

On 8/20/19 2:11 AM, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Aug 19, 2019 at 10:23:03PM -0500, Samuel Holland wrote:
>> On sun8i, sun9i, and sun50i SoCs, system suspend/resume support requires
>> firmware running on the AR100 coprocessor (the "SCP"). Such firmware can
>> provide additional features, such as thermal monitoring and poweron/off
>> support for boards without a PMIC.
>>
>> Since the AR100 may be running critical firmware, even if Linux does not
>> know about it or directly interact with it (all requests may go through
>> an intermediary interface such as PSCI), Linux must not turn off its
>> clock.

This paragraph here is the key. The firmware won't necessarily have a device
tree node, and in the current design it will not, since Linux never communicates
with it directly. All communication goes through ATF via PSCI.

>> At this time, such power management firmware only exists for the A64 and
>> H5 SoCs.  However, it makes sense to take care of all CCU drivers now
>> for consistency, and to ease the transition in the future once firmware
>> is ported to the other SoCs.
>>
>> Leaving the clock running is safe even if no firmware is present, since
>> the AR100 stays in reset by default. In most cases, the AR100 clock is
>> kept enabled by Linux anyway, since it is the parent of all APB0 bus
>> peripherals. This change only prevents Linux from turning off the AR100
>> clock in the rare case that no peripherals are in use.
>>
>> Signed-off-by: Samuel Holland <samuel@sholland.org>
> 
> So I'm not really sure where you want to go with this.
> 
> That clock is only useful where you're having a firmware running on
> the AR100, and that firmware would have a device tree node of its own,
> where we could list the clocks needed for the firmware to keep
> running, if it ever runs. If the driver has not been compiled in /
> loaded, then we don't care either.

See above. I don't expect that the firmware would have a device tree node,
because the firmware doesn't need any Linux drivers.

> But more fundamentally, if we're going to use SCPI, then those clocks
> will not be handled by that driver anyway, but by the firmware, right?

In the future, we might use SCPI clocks/sensors/regulators/etc. from Linux, but
that's not the plan at the moment. Given that it's already been two years since
I started this project, I'm trying to limit its scope so I can get at least some
part merged. The first step is to integrate a firmware that provides
suspend/resume functionality only. That firmware does implement SCPI, and if the
top-level Linux SCPI driver worked with multiple mailbox channels, it could
query the firmware's version and fetures. But all of the SCPI commands used for
suspend/resume must go through ATF via PSCI.

> So I'm not really sure that we should do it statically this way, and
> that we should do it at all.

Do you have a better way to model "firmware uses this clock behind the scenes,
so Linux please don't touch it"? It's unfortunate that we have Linux and
firmware fighting over the R_CCU, but since we didn't have firmware (e.g. SCPI
clocks) in the beginning, it's where we are today.

The AR100 clock doesn't actually have a gate, and it generally has dependencies
like R_INTC in use. So as I mentioned in the commit message, the clock will
normally be on anyway. The goal was to model the fact that there are users of
this clock that Linux doesn't/can't know about.

> Maxime

Thanks,
Samuel

  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20  3:23 [PATCH v4 00/10] Allwinner sunxi message box support Samuel Holland
2019-08-20  3:23 ` [PATCH v4 01/10] clk: sunxi-ng: Mark msgbox clocks as critical Samuel Holland
2019-08-20  3:23 ` [PATCH v4 02/10] clk: sunxi-ng: Mark AR100 " Samuel Holland
2019-08-20  7:11   ` Maxime Ripard
2019-08-20 13:02     ` Samuel Holland [this message]
2019-08-21 12:24       ` Maxime Ripard
2019-09-05 18:56         ` Stephen Boyd
2019-08-20  3:23 ` [PATCH v4 03/10] dt-bindings: mailbox: Add a sunxi message box binding Samuel Holland
2019-08-20  7:14   ` Maxime Ripard
2019-08-20 13:04     ` Samuel Holland
2019-08-21 12:07       ` Maxime Ripard
2019-08-20  3:23 ` [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver Samuel Holland
2019-08-20  8:27   ` Maxime Ripard
2019-08-20 11:18   ` Ondřej Jirman
2019-08-20 13:07     ` Samuel Holland
2019-08-20 13:34       ` Ondřej Jirman
2019-08-21 12:30       ` Maxime Ripard
2019-08-20  3:23 ` [PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node Samuel Holland
2019-08-20  8:15   ` Maxime Ripard
2019-08-20 13:17     ` Samuel Holland
2019-08-23 14:56       ` Maxime Ripard
2019-08-20  3:23 ` [PATCH v4 06/10] ARM: dts: sunxi: a83t: " Samuel Holland
2019-08-20  3:23 ` [PATCH v4 07/10] ARM: dts: sunxi: h3/h5: " Samuel Holland
2019-08-20  3:23 ` [PATCH v4 08/10] arm64: dts: allwinner: a64: " Samuel Holland
2019-08-20  3:23 ` [PATCH v4 09/10] arm64: dts: allwinner: h6: " Samuel Holland
2019-08-20  3:23 ` [PATCH v4 10/10] [DO NOT MERGE] drivers: firmware: msgbox demo Samuel Holland
2019-09-09  3:22 ` [PATCH v4 00/10] Allwinner sunxi message box support Ondřej Jirman
2019-09-09  3:54   ` Samuel Holland
2019-09-09 12:36     ` Ondřej Jirman

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=3b67534a-eb1b-c1e8-b5e8-e0a74ae85792@sholland.org \
    --to=samuel@sholland.org \
    --cc=anarsoul@gmail.com \
    --cc=clabbe.montjoie@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=wens@csie.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

Linux-Clk Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-clk/0 linux-clk/git/0.git

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

Example config snippet for mirrors

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


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