Re: [PATCH] ARM: dts: Add Raspberry Pi Compute Module 4 CANOPi Board
From: Stefan Wahren
Date: Sat Sep 17 2022 - 06:19:19 EST
Hi Ariel,
Am 16.09.22 um 17:31 schrieb Ariel D'Alessandro:
The Eclipse KUKSA CANOPi [0] is a baseboard for the Raspberry Compute
Module 4 (CM4). It contains a VIA VL805 4 Port USB controller and two
MCP251xFD based CAN-FD interfaces.
this is a cool piece of hardware :-)
Is it correct this baseboard is only intended for Compute Modules
without Wifi/BT? Otherwise we get conflicts with UART0. The
bcm2711-rpi-cm4.dtsi is currently written for all Compute Module
variants. A possible solution is to use delete-node, another cleaner
ones is to split bcm2711-rpi-cm4 into wifi and non-wifi variants and
include the non-wifi one in your case.
[0] https://github.com/boschresearch/kuksa.hardware
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@xxxxxxxxxxxxx>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/bcm2711-rpi-cm4-canopi.dts | 139 ++++++++++++++++++
arch/arm64/boot/dts/broadcom/Makefile | 1 +
.../dts/broadcom/bcm2711-rpi-cm4-canopi.dts | 2 +
4 files changed, 143 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm2711-rpi-cm4-canopi.dts
create mode 100644 arch/arm64/boot/dts/broadcom/bcm2711-rpi-cm4-canopi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 05d8aef6e5d2..8930ab2c132c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2837-rpi-zero-2-w.dtb \
bcm2711-rpi-400.dtb \
bcm2711-rpi-4-b.dtb \
+ bcm2711-rpi-cm4-canopi.dtb \
bcm2711-rpi-cm4-io.dtb \
bcm2835-rpi-zero.dtb \
bcm2835-rpi-zero-w.dtb
diff --git a/arch/arm/boot/dts/bcm2711-rpi-cm4-canopi.dts b/arch/arm/boot/dts/bcm2711-rpi-cm4-canopi.dts
new file mode 100644
index 000000000000..52ec5908883c
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi-cm4-canopi.dts
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi-cm4.dtsi"
+
+/ {
+ model = "Raspberry Pi Compute Module 4 CANOPi Board";
+
+ clocks {
+ clk_mcp251xfd_osc: mcp251xfd-osc {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <20000000>;
+ };
+ };
+
+ leds {
+ led-act {
+ gpios = <&gpio 42 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-pwr {
+ label = "PWR";
+ gpios = <&expgpio 2 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ linux,default-trigger = "default-on";
+ };
+ };
are these LEDs really populated and wired to the BCM2711? The schematics
suggests that they are connected to the STN2120.
+};
+
+&ddc0 {
+ status = "okay";
+};
+
+&ddc1 {
+ status = "okay";
+};
+
+&hdmi0 {
+ status = "okay";
+};
+
+&hdmi1 {
+ status = "okay";
+};
I cannot see any graphical interface in the schematics. So why they are
enabled?
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_gpio44>;
+ status = "okay";
+ clock-frequency = <100000>;
+
+ pcf85063a@51 {
Please use the actual function for the node name like rtc@51
+ compatible = "nxp,pcf85063a";
+ reg = <0x51>;
+ };
+};
+
+&pcie0 {
+ pci@0,0 {
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ reg = <0 0 0 0 0>;
+
+ usb@0,0 {
+ reg = <0 0 0 0 0>;
+ resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
+ };
+ };
+};
+
+&pixelvalve0 {
+ status = "okay";
+};
+
+&pixelvalve1 {
+ status = "okay";
+};
+
+&pixelvalve2 {
+ status = "okay";
+};
+
+&pixelvalve4 {
+ status = "okay";
+};
Without a graphical interface they shouldn't be necessary?
+
+&spi {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_gpio7>;
+ cs-gpios = <&gpio 8 1>, <&gpio 7 1>;
+ dmas = <&dma 6>, <&dma 7>;
+ dma-names = "tx", "rx";
+
+ mcp251xfd0: mcp251xfd@0 {
mcp251xfd0: can@0
+ compatible = "microchip,mcp251xfd";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcp251xfd0_pins>;
+ spi-max-frequency = <20000000>;
I wasn't good at physics, but having spi-max-frequency equal to the
oscillator frequency seems wrong. Is it because of the hack in the
downstream kernel which halves the SPI frequency?
Just guessing because imx6qp-prtwd3.dts uses 10 MHz.
+ interrupt-parent = <&gpio>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk_mcp251xfd_osc>;
+ };
+
+ mcp251xfd1: mcp251xfd@1 {
mcp251xfd1: can@1
+ compatible = "microchip,mcp251xfd";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcp251xfd1_pins>;
+ spi-max-frequency = <20000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk_mcp251xfd_osc>;
+ };
+};
+
+&gpio {
In case there are any GPIOs which should be controlled via user space
(like LTE or FAN control), it would be nice to describe them via
gpio-line-names.
+ mcp251xfd0_pins: mcp251xfd0_pins {
+ brcm,pins = <27>;
+ brcm,function = <BCM2835_FSEL_GPIO_IN>;
+ };
The vendor specific pin properties are deprecated for BCM2711. We have
generic ones for this:
mcp251xfd0_pins: mcp251xfd0_pins {
pin-irq {
pins = "gpio27";
function = "gpio_in";
};
};
+
+ mcp251xfd1_pins: mcp251xfd1_pins {
+ brcm,pins = <22>;
+ brcm,function = <BCM2835_FSEL_GPIO_IN>;
+ };
dito
+};
+
+&vc4 {
+ status = "okay";
+};
I think this is also not necessary for a headless device.
+
+&vec {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index e8584d3b698f..7cd88b8c0345 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_BCM2835) += bcm2711-rpi-400.dtb \
bcm2711-rpi-4-b.dtb \
+ bcm2711-rpi-cm4-canopi.dtb \
bcm2711-rpi-cm4-io.dtb \
bcm2837-rpi-3-a-plus.dtb \
bcm2837-rpi-3-b.dtb \
diff --git a/arch/arm64/boot/dts/broadcom/bcm2711-rpi-cm4-canopi.dts b/arch/arm64/boot/dts/broadcom/bcm2711-rpi-cm4-canopi.dts
new file mode 100644
index 000000000000..e9369aa0eb39
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2711-rpi-cm4-canopi.dts
@@ -0,0 +1,2 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "arm/bcm2711-rpi-cm4-canopi.dts"