On Thu, 2020-06-11 at 09:32 +0200, Maxime Ripard wrote: > 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 <mturque...@baylibre.com> > Cc: Stephen Boyd <sb...@kernel.org> > Cc: linux-...@vger.kernel.org > Reviewed-by: Stephen Boyd <sb...@kernel.org> > Signed-off-by: Maxime Ripard <max...@cerno.tech> > ---
Acked-by: Nicolas Saenz Julienne <nsaenzjulie...@suse.de> Regards, Nicolas
signature.asc
Description: This is a digitally signed message part
