From: Maxime Ripard <mripard@kernel.org>
To: "Maíra Canal" <mcanal@igalia.com>
Cc: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Nicolas Saenz Julienne <nsaenz@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Stefan Wahren <wahrenst@gmx.net>, Melissa Wen <mwen@igalia.com>,
Iago Toral Quiroga <itoral@igalia.com>,
Dom Cobley <popcornmix@gmail.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-clk@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
dri-devel@lists.freedesktop.org,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
kernel-dev@igalia.com
Subject: Re: [PATCH 1/3] clk: bcm: rpi: Turn firmware clock on/off when preparing/unpreparing
Date: Tue, 29 Jul 2025 14:14:25 +0200 [thread overview]
Message-ID: <20250729-whispering-accelerated-raptor-134e8a@houat> (raw)
In-Reply-To: <1bc23ad0-7273-4ddf-a0ef-4a80186f2581@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]
On Tue, Jul 29, 2025 at 08:53:51AM -0300, Maíra Canal wrote:
> Hi Maxime,
>
> On 29/07/25 04:27, Maxime Ripard wrote:
> > Hi Maíra,
> >
> > On Mon, Jul 28, 2025 at 09:35:38AM -0300, Maíra Canal wrote:
> > > Currently, when we prepare or unprepare RPi's clocks, we don't actually
> > > enable/disable the firmware clock. This means that
> > > `clk_disable_unprepare()` doesn't actually change the clock state at
> > > all, nor does it lowers the clock rate.
> > >
> > > From the Mailbox Property Interface documentation [1], we can see that
> > > we should use `RPI_FIRMWARE_SET_CLOCK_STATE` to set the clock state
> > > off/on. Therefore, use `RPI_FIRMWARE_SET_CLOCK_STATE` to create a
> > > prepare and an unprepare hook for RPi's firmware clock.
> > >
> > > As now the clocks are actually turned off, some of them are now marked
> > > with CLK_IGNORE_UNUSED or CLK_IS_CRITICAL, as those are required since
> > > early boot or are required during reboot.
> >
> > What difference is there between the CLK_IGNORE_UNUSED and
> > CLK_IS_CRITICAL clocks?
>
> From my understanding, CLK_IGNORE_UNUSED will prevent the clock to be
> gated during boot (on "clk: Disabling unused clocks"), but after it, the
> clock can be gated.
>
> With CLK_IS_CRITICAL, the clock will never be disabled.
Yeah, that's correct.
> For example, RPI_FIRMWARE_M2MC_CLK_ID is used by vc4. It needs to be
> enabled at boot (I tested; if not enabled, it won't boot). However,
> after vc4 is probed, we would like vc4 to have control of it and be able
> to unprepare it in `vc4_hdmi_runtime_suspend()`. If I set it as
> CLK_IS_CRITICAL, vc4 won't be able to unprepare it.
If the clock can be disabled by Linux, but it breaks some drivers if
it's not enabled during their probe, something is fishy somewhere, and
it's likely it would be just as broken if you compiled the driver as a
module.
Even then, some of the other clocks should probably never be disabled,
like the CPU clock.
> I only set RPI_FIRMWARE_PIXEL_BVB_CLK_ID as critical, as, otherwise, the
> RPi won't reboot.
Why?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
next prev parent reply other threads:[~2025-07-29 12:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 12:35 [PATCH 0/3] Power Management for Raspberry Pi V3D GPU Maíra Canal
2025-07-28 12:35 ` [PATCH 1/3] clk: bcm: rpi: Turn firmware clock on/off when preparing/unpreparing Maíra Canal
2025-07-28 16:33 ` Stefan Wahren
2025-07-28 20:15 ` Maíra Canal
2025-07-29 7:27 ` Maxime Ripard
2025-07-29 11:53 ` Maíra Canal
2025-07-29 12:14 ` Maxime Ripard [this message]
2025-07-29 16:19 ` Maíra Canal
2025-07-30 0:33 ` Maíra Canal
2025-07-30 15:13 ` Maxime Ripard
2025-07-28 12:35 ` [PATCH 2/3] drm/v3d: Allocate all resources before enabling the clock Maíra Canal
2025-07-28 14:31 ` Philipp Zabel
2025-07-28 12:35 ` [PATCH 3/3] drm/v3d: Introduce Runtime Power Management Maíra Canal
2025-07-28 21:00 ` [PATCH 0/3] Power Management for Raspberry Pi V3D GPU Stefan Wahren
2025-07-29 0:30 ` Maíra Canal
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=20250729-whispering-accelerated-raptor-134e8a@houat \
--to=mripard@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=florian.fainelli@broadcom.com \
--cc=itoral@igalia.com \
--cc=kernel-dev@igalia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=mcanal@igalia.com \
--cc=mturquette@baylibre.com \
--cc=mwen@igalia.com \
--cc=nsaenz@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=popcornmix@gmail.com \
--cc=sboyd@kernel.org \
--cc=wahrenst@gmx.net \
/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