| Message ID | 20221026-rpi-display-fw-clk-v1-2-5c29b7a3d8b0@cerno.tech |
|---|---|
| State | Accepted |
| Commit | 27ab05e1b7e5c5ec9b4f658e1b2464c0908298a6 |
| Headers | show |
| Series | [1/2] ARM: dts: bcm283x: Remove bcm2835-rpi-common.dtsi from SoC DTSI | expand |
diff --git a/arch/arm/boot/dts/bcm2835-rpi-common.dtsi b/arch/arm/boot/dts/bcm2835-rpi-common.dtsi index 8a55b6cded59..4e7b4a592da7 100644 --- a/arch/arm/boot/dts/bcm2835-rpi-common.dtsi +++ b/arch/arm/boot/dts/bcm2835-rpi-common.dtsi @@ -7,6 +7,23 @@ #include <dt-bindings/power/raspberrypi-power.h> +&firmware { + firmware_clocks: clocks { + compatible = "raspberrypi,firmware-clocks"; + #clock-cells = <1>; + }; +}; + +&hdmi { + clocks = <&firmware_clocks 9>, + <&firmware_clocks 13>; + clock-names = "pixel", "hdmi"; +}; + &v3d { power-domains = <&power RPI_POWER_DOMAIN_V3D>; }; + +&vec { + clocks = <&firmware_clocks 15>; +};
We've experienced a number of issues around the cohabitation between the "real" clock driver in Linux and the one backed by the firmware. One solution around this is to follow what the RaspberryPi foundation in its downstream clock, which is also what we've been doing on the RaspberryPi4: to use the clocks exposed by the firmware. Link: https://lore.kernel.org/linux-clk/20221021140505.kjmw5x4s6qhnrfif@houat/ Signed-off-by: Maxime Ripard <maxime@cerno.tech> --- arch/arm/boot/dts/bcm2835-rpi-common.dtsi | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)