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

[Stefan Wahren]

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