Re: [PATCH] ARM: dts: Add Raspberry Pi Compute Module 4 CANOPi Board

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alexander,

Am 20.09.22 um 10:31 schrieb Alexander Dahl:
Hello Stefan,

Am Mon, Sep 19, 2022 at 01:18:21PM +0200 schrieb Stefan Wahren:
Hi Alexander,

[fix address of Krzysztof]

Am 19.09.22 um 09:47 schrieb Alexander Dahl:
Hei hei,

Am Fri, Sep 16, 2022 at 12:31:56PM -0300 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.

[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";
+		};
+	};
This looks like using the node name and the deprecated "label"
property for LED naming.  Please see
Documentation/devicetree/bindings/leds/common.yaml and use the
properties "function" and "color" instead.  Also check the node names
itself, see the example in that binding or the leds-gpio binding for
reference.
Oops, i didn't noticed this.

Unfortunately the ACT-LED is already a little bit opaque defined in
bcm2835-rpi.dtsi:

leds {
         compatible = "gpio-leds";

         led-act {
             label = "ACT";
             default-state = "keep";
             linux,default-trigger = "heartbeat";
         };
};

So a reference (currently missing) would have make it clear that the ACT-LED
is common for all Raspberry Pi boards.
Yes, a reference would probably good, would make it easier to spot
this is already defined in the dtsi.
I will take care of this.

So you wish that this is fixed for the CANOPi board or all Raspberry Pi
boards?

I'm asking because switching to function would change the sysfs path and
breaking userspace ABI.
You're right, and the effective label should stay as is for existing
boards to not break userspace.

Not sure what the policy is for baseboards with compute modules.  Are
those LEDs on the compute module?  Or does the CM just expose those
GPIOs?
These are GPIOs expose by the Compute Module. Since these are initialized by the VC4 firmware, it's not the best idea to use them for other functions.
   Is there some policy all baseboards must use them for LEDs?
An what about additional LEDs on the baseboard?  Is this allowed?
Definitely
(I don't think there a generic rules for that, but maybe some best
practices for certain SoMs like the RPi CM?)
I think we should for Ariel's reponse.
IMHO for new independent boards though, new LEDs should not be
introduced the old way. I thought this is the case here, but it seems
I was wrong due to that baseboard vs. SoM thing.

Without your comment i hadn't noticed this :-)

I'm thinking of a dtsi file in order to encapsulate the deprecated LED stuff, remove the global ACT-LED from bcm2835-rpi.dtsi and include the dtsi from all board files.

Best regards



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux