Messages in this thread | | | Date | Tue, 20 Sep 2022 17:41:16 +0200 | Subject | Re: [PATCH] ARM: dts: Add Raspberry Pi Compute Module 4 CANOPi Board | From | 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@collabora.com> >>>> --- >>>> 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
| |