[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200225095433.tyxamibqyrgw5355@gilmour.lan>
Date: Tue, 25 Feb 2020 10:54:33 +0100
From: Maxime Ripard <maxime@...no.tech>
To: Stefan Wahren <stefan.wahren@...e.com>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
Eric Anholt <eric@...olt.net>,
Tim Gover <tim.gover@...pberrypi.com>,
Dave Stevenson <dave.stevenson@...pberrypi.com>,
Stephen Boyd <sboyd@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-clk@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com,
linux-rpi-kernel@...ts.infradead.org,
Phil Elwell <phil@...pberrypi.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 16/89] clk: bcm: rpi: Add clock id to data
Hi Stefan,
On Mon, Feb 24, 2020 at 08:25:46PM +0100, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 24.02.20 um 10:06 schrieb Maxime Ripard:
> > The driver has really only supported one clock so far and has hardcoded the
> > ID used in communications with the firmware in all the functions
> > implementing the clock framework hooks. Let's store that in the clock data
> > structure so that we can support more clocks later on.
>
> thank you for this series. I looked through it but i couldn't find an
> explanation why we need to expose firmware clocks via DT instead of
> extending clk-bcm2835. The whole pllb / clk-raspberrypi stuff was an
> exception to get cpufreq working. I prefer to keep it an exception.
Thanks for pointing this out, I indeed forgot to address it in my
cover letter or my commit log.
I'm not quite sure what the situation was with the previous
RaspberryPi, but the RPi4 firmware does a bunch of things under the
hood to make sure that everything works as expected:
- The HSM (and V3D) clocks will be reparented to multiple PLLs
depending on the rate being asked for.
- Still depending on the rate, the firmware will adjust the voltage
of the various PLLs.
- Depending on the temperature of the CPU and GPU, the firmware will
change the rate of clocks to throttle in case of the cores
overheating, with all the fallout that might happen to clocks
deriving from it.
- No matter what we choose to do in Linux, this will happen so
whether or not we want to do it, so doing it behind the firmware's
back (or the firmware doing it behind Linux's back) will only
result in troubles, with voltages too low, or the firmware trying
to access the same register at the same time than the Linux driver
would, etc.
So all in all, it just seems much easier and safer to use the firmware
clocks.
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists