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