Quoting Maxime Ripard (2020-06-15 01:41:01) > The RaspberryPi4 firmware actually exposes more clocks than are currently > handled by the driver and we will need to change some of them directly > based on the pixel rate for the display related clocks, or the load for the > GPU. > > Since the firmware implements DVFS, this rate change can have a number of > side-effects, including adjusting the various PLL voltages or the PLL > parents. The firmware also implements thermal throttling, so even some > thermal pressure can change those parameters behind Linux back. > > DVFS is currently implemented on the arm, core, h264, v3d, isp and hevc > clocks, so updating any of them using the MMIO driver (and thus behind the > firmware's back) can lead to troubles, the arm clock obviously being the > most problematic. > > In order to make Linux play as nice as possible with those constraints, it > makes sense to rely on the firmware clocks as much as possible. However, > the firmware doesn't seem to provide some equivalents to their MMIO > counterparts, so we can't really replace that driver entirely. > > Fortunately, the firmware has an interface to discover the clocks it > exposes. > > Let's use it to discover, register the clocks in the clocks framework and > then expose them through the device tree for consumers to use them. > > Cc: Michael Turquette <[email protected]> > Cc: Stephen Boyd <[email protected]> > Cc: [email protected] > Acked-by: Nicolas Saenz Julienne <[email protected]> > Reviewed-by: Stephen Boyd <[email protected]> > Tested-by: Nicolas Saenz Julienne <[email protected]> > Signed-off-by: Maxime Ripard <[email protected]> > ---
Applied to clk-next
