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:4.048 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site