lkml.org 
[lkml]   [2020]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 16/89] clk: bcm: rpi: Add clock id to data
From
Date
Hi Maxime,

On Tue, 2020-02-25 at 10:54 +0100, Maxime Ripard wrote:
> 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.

I agree with your assesment. Both DVFS and overheating/overvoltage protections
will cause trouble, if not, make a Linux solution impossible while using the
Foundation's firmware.

Please note that, as Stefan says, it'd be nice to keep track of those arguments
somewhere in the commit messages.

Regards,
Nicolas

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2020-02-25 15:34    [W:0.096 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site