From: Stephen Boyd <sboyd@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Rob Herring <robh@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Frank Rowand <frowand.list@gmail.com>,
Michael Turquette <mturquette@baylibre.com>,
devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
Aymeric Aillet <aymeric.aillet@iot.bzh>,
Yusuke Goda <yusuke.goda.sx@renesas.com>
Subject: Re: [PATCH 4/4] drivers: clk: renesas: enable all clocks which is assinged to non Linux system
Date: Mon, 27 Nov 2023 13:32:26 -0800 [thread overview]
Message-ID: <31afd614c5eb5e82a860fecfc1c21c39.sboyd@kernel.org> (raw)
In-Reply-To: <CAMuHMdU0Hqem8Ooehoo64rrGn8q8+5A8_DjGZd9Tvh=Xej6mdA@mail.gmail.com>
Quoting Geert Uytterhoeven (2023-11-16 13:08:46)
> On Thu, Nov 16, 2023 at 8:23 PM Rob Herring <robh@kernel.org> wrote:
> > On Tue, Nov 14, 2023 at 12:01:14AM +0000, Kuninori Morimoto wrote:
> > > Some board might use Linux and another OS in the same time. In such
> > > case, current Linux will stop necessary module clock when booting
> > > which is not used on Linux side, but is used on another OS side.
> > >
> > > To avoid such situation, renesas-cpg-mssr try to find
> > > status = "reserved" devices (A), and add CLK_IGNORE_UNUSED flag to its
> > > <&cgp CPG_MOD xxx> clock (B).
> >
> > See Stephen's presentation from Plumbers this week. The default behavior
> > for unused clocks may be changing soon.
>
> Thank you!
>
> ou mean "Make sync_state()/handoff work for the common clk
> framework"[1]? IIUIC, that presentation didn't cover the problem we are
> facing, except for the big "Kconfig for clk_ignore_unused=true" hammer.
:)
>
> > > Table 2.4: Values for status property
> > > https://github.com/devicetree-org/devicetree-specification/releases/download/v0.4/devicetree-specification-v0.4.pdf
> > >
> > > "reserved"
> > > Indicates that the device is operational, but should not be
> > > used. Typically this is used for devices that are controlled
> > > by another software component, such as platform firmware.
> > >
> > > ex)
> > > scif5: serial@e6f30000 {
> > > ...
> > > (B) clocks = <&cpg CPG_MOD 202>,
> > > <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> > > <&scif_clk>;
> > > ...
> > > (A) status = "reserved";
> > > };
> >
> > I have some reservations about whether a reserved node should be touched
> > at all by Linux. I suppose since it is platform specific, it's okay. I
> > don't think we could apply such behavior globally.
>
> That's an interesting comment, as the issue is that currently Linux
> does touch (resources belonging to) reserved nodes, and this patch
> would prevent doing that for module clock resources;-)
I think I get it.
>
> The core issue is that Linux distinguishes only between two cases:
> 1. "device is used by Linux" (if a driver is available),
> as indicated by 'status = "okay"' in DT, or
> 2. "device is unused by Linux".
> On a heterogenous system, the latter actually comprises two cases:
> 2a. "device is unused", or
> 2b. "device is used by another OS running on another CPU core".
>
> Looking for 'status = "reserved"' allows us to distinguish between 2a
> and 2b, and can prevent disabling clocks that are used by another OS.
> Probably we need a similar solution for power domains.
>
> Do you have a better or alternative suggestion?
Does the protected-clocks property work? That basically says "don't use
these clks in the OS". The driver implementation would not register
those clks and then the framework would be unaware of their existence,
leading to them never being disabled during late init.
This approach also looks OK to me, basically programmatically creating
the protected-clocks list by parsing DT for reserved consumer nodes and
then figuring out that no consumer exists so we can skip registering the
clk entirely, or add the flag. I'm not sure we want to implement that
policy globally, because maybe someone really wants to disable the clk
still to clean up bootloader state and then let a remoteproc use the clk
later.
Do you want to keep those clks registered with the framework? Is there
any benefit to keeping clks around if linux can't do anything with them?
next prev parent reply other threads:[~2023-11-27 21:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 23:59 [PATCH 0/4] drivers: clk: renesas: enable all clocks which is assinged to non Linux system Kuninori Morimoto
2023-11-14 0:00 ` [PATCH 1/4] of: add __of_device_is_status() and makes more generic status check Kuninori Morimoto
2023-11-16 19:17 ` Rob Herring
2023-11-14 0:00 ` [PATCH 2/4] of: add __of_get_next_status_child() and makes more generic of_get_next Kuninori Morimoto
2023-11-14 0:01 ` [PATCH 3/4] of: add for_each_reserved_child_of_node() Kuninori Morimoto
2023-11-14 0:01 ` [PATCH 4/4] drivers: clk: renesas: enable all clocks which is assinged to non Linux system Kuninori Morimoto
2023-11-14 13:10 ` kernel test robot
2023-11-16 1:04 ` Kuninori Morimoto
2023-11-16 19:23 ` Rob Herring
2023-11-16 21:08 ` Geert Uytterhoeven
2023-11-27 21:32 ` Stephen Boyd [this message]
2023-11-27 23:48 ` Kuninori Morimoto
2023-12-01 22:39 ` Stephen Boyd
2023-12-04 0:26 ` Kuninori Morimoto
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=31afd614c5eb5e82a860fecfc1c21c39.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=aymeric.aillet@iot.bzh \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=geert@linux-m68k.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh@kernel.org \
--cc=yusuke.goda.sx@renesas.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).