From: "Michael Walle" <mwalle@kernel.org>
To: "Randolph Sapp" <rs@ti.com>,
"Frank Binns" <frank.binns@imgtec.com>,
"Matt Coster" <matt.coster@imgtec.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Nishanth Menon" <nm@ti.com>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Tero Kristo" <kristo@kernel.org>,
"Santosh Shilimkar" <ssantosh@kernel.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@kernel.org>
Cc: "Andrew Davis" <afd@ti.com>, <dri-devel@lists.freedesktop.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-clk@vger.kernel.org>
Subject: Re: [PATCH 2/3] clk: keystone: don't cache clock rate
Date: Mon, 22 Sep 2025 09:23:01 +0200 [thread overview]
Message-ID: <DCZ5D3DB786G.3JANU1P578TCY@kernel.org> (raw)
In-Reply-To: <DCX03UL17R3K.1MRUGNR4PUIDL@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3219 bytes --]
Hi,
> > The TISCI firmware will return 0 if the clock or consumer is not
> > enabled although there is a stored value in the firmware. IOW a call to
> > set rate will work but at get rate will always return 0 if the clock is
> > disabled.
> > The clk framework will try to cache the clock rate when it's requested
> > by a consumer. If the clock or consumer is not enabled at that point,
> > the cached value is 0, which is wrong. Thus, disable the cache
> > altogether.
> >
> > Signed-off-by: Michael Walle <mwalle@kernel.org>
> > ---
> > I guess to make it work correctly with the caching of the linux
> > subsystem a new flag to query the real clock rate is needed. That
> > way, one could also query the default value without having to turn
> > the clock and consumer on first. That can be retrofitted later and
> > the driver could query the firmware capabilities.
> >
> > Regarding a Fixes: tag. I didn't include one because it might have a
> > slight performance impact because the firmware has to be queried
> > every time now and it doesn't have been a problem for now. OTOH I've
> > enabled tracing during boot and there were just a handful
> > clock_{get/set}_rate() calls.
> > ---
> > drivers/clk/keystone/sci-clk.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
> > index c5894fc9395e..d73858b5ca7a 100644
> > --- a/drivers/clk/keystone/sci-clk.c
> > +++ b/drivers/clk/keystone/sci-clk.c
> > @@ -333,6 +333,14 @@ static int _sci_clk_build(struct sci_clk_provider *provider,
> >
> > init.ops = &sci_clk_ops;
> > init.num_parents = sci_clk->num_parents;
> > +
> > + /*
> > + * A clock rate query to the SCI firmware will return 0 if either the
> > + * clock itself is disabled or the attached device/consumer is disabled.
> > + * This makes it inherently unsuitable for the caching of the clk
> > + * framework.
> > + */
> > + init.flags = CLK_GET_RATE_NOCACHE;
> > sci_clk->hw.init = &init;
> >
> > ret = devm_clk_hw_register(provider->dev, &sci_clk->hw);
>
>
> Thanks for looking into this Michael. I'm still convinced that it's unusual to
> report 0 for a clock rate when the device is powered down. In most cases it's
> not actually 0 and is actually just in bypass mode.
Yeah. And you can't query the clock rate you've just set if the
clock is off (and if enabled the clock will have the frequency of
the last set_rate). I still think that is a gap in the firmware
interface.
> I was told it's a way to indicate clock status and probably won't be changing
> any time soon though. Ignore the fact that we also already have a separate way
> to query clock status. :)
>
> This series looks good, but won't quite result in a functional GPU without the
> following patch: https://lore.kernel.org/all/20250808232522.1296240-1-rs@ti.com/
Ahh, I was puzzled why it was working for me. But then I've noticed
that your patch is for the am62p. I'm working with the am67a and
there the ranges are correct for the GPU.
> I suppose I'll submit that again on it's own.
>
> Reviewed-by: Randolph Sapp <rs@ti.com>
Thanks.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
next prev parent reply other threads:[~2025-09-22 7:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 14:34 [PATCH 0/3] drm/imagination: add AM62P/AM67A/J722S support Michael Walle
2025-09-15 14:34 ` [PATCH 1/3] dt-bindings: gpu: img: Add AM62P SoC specific compatible Michael Walle
2025-09-15 17:19 ` Conor Dooley
2025-09-15 14:34 ` [PATCH 2/3] clk: keystone: don't cache clock rate Michael Walle
2025-09-17 15:24 ` Kevin Hilman
2025-09-18 9:48 ` Michael Walle
2025-09-18 18:03 ` Dhruva Gole
2025-09-19 7:10 ` Michael Walle
2025-09-23 9:07 ` Maxime Ripard
2025-09-25 2:26 ` Randolph Sapp
2025-09-25 11:43 ` Maxime Ripard
2025-09-25 18:32 ` Randolph Sapp
2025-09-19 18:50 ` Randolph Sapp
2025-09-22 7:23 ` Michael Walle [this message]
2025-09-15 14:34 ` [PATCH 3/3] arm64: dts: ti: add GPU node Michael Walle
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=DCZ5D3DB786G.3JANU1P578TCY@kernel.org \
--to=mwalle@kernel.org \
--cc=afd@ti.com \
--cc=airlied@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frank.binns@imgtec.com \
--cc=kristo@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matt.coster@imgtec.com \
--cc=mripard@kernel.org \
--cc=mturquette@baylibre.com \
--cc=nm@ti.com \
--cc=robh@kernel.org \
--cc=rs@ti.com \
--cc=sboyd@kernel.org \
--cc=simona@ffwll.ch \
--cc=ssantosh@kernel.org \
--cc=tzimmermann@suse.de \
--cc=vigneshr@ti.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).