* [RFC] arm64: dts: ti: introduce a minimal am642 device tree @ 2022-03-21 15:54 Bryan Brattlof 2022-03-22 18:14 ` Krzysztof Kozlowski 2022-03-30 13:55 ` Wadim Egorov 0 siblings, 2 replies; 11+ messages in thread From: Bryan Brattlof @ 2022-03-21 15:54 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel, Bryan Brattlof Texas Instrument's am642 is one of many k3 based, low cost, low power, chips designed to work in a wide range of applications spanning an even wider range of industries that TI is actively developing With its pin-mux and peripheral rich designs, these chips will likely have a multitude of custom device trees that range wildly from one another and (hopefully) guarantee an influx of variants into the kernel in the coming years With overlays no longer a thing, I wanted to ask for opinions on how we can best help integrate these dt files as they begin to be developed I also wanted to introduce a skeletonized (nothing but uart) device tree to give others a good starting point while developing their projects. Let me know what you think :) Signed-off-by: Bryan Brattlof <bb@ti.com> --- .../devicetree/bindings/arm/ti/k3.yaml | 1 + arch/arm64/boot/dts/ti/Makefile | 1 + arch/arm64/boot/dts/ti/k3-am642-skeleton.dts | 335 ++++++++++++++++++ 3 files changed, 337 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am642-skeleton.dts diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index 61c6ab4f52e26..e65053d6465bd 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -55,6 +55,7 @@ properties: - description: K3 AM642 SoC items: - enum: + - ti,am642-generic - ti,am642-evm - ti,am642-sk - const: ti,am642 diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile index 02e5d80344d00..df7bdf087558c 100644 --- a/arch/arm64/boot/dts/ti/Makefile +++ b/arch/arm64/boot/dts/ti/Makefile @@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-common-proc-board.dtb dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb +dtb-$(CONFIG_ARCH_K3) += k3-am642-skeleton.dtb dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb diff --git a/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts new file mode 100644 index 0000000000000..2b789c9c25ced --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts @@ -0,0 +1,335 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * The absolute minimum DTS file needed for an AM642 + */ + +/dts-v1/; + +#include <dt-bindings/pinctrl/k3.h> +#include "k3-am642.dtsi" + +/ { + compatible = "ti,am642-generic", "ti,am642"; + model = "Texas Instruments AM642 Generic"; + + chosen { + stdout-path = "serial2:115200n8"; + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000"; + }; + + cpus { + /delete-node/ cpu@1; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00000000 0x20000000 0x00000000 0x20000000>; + }; + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + secure_ddr: optee@9e800000 { + reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */ + alignment = <0x1000>; + no-map; + }; + }; +}; + +/* reserved for mcu firmware */ +&mcu_gpio0 { + status = "reserved"; +}; + +&mcu_i2c0 { + status = "disabled"; +}; + +&mcu_i2c1 { + status = "disabled"; +}; + +&mcu_gpio_intr { + status = "disabled"; +}; + +&mcu_pmx0 { + status = "disabled"; +}; + +&mcu_uart0 { + status = "disabled"; +}; + +&mcu_uart1 { + status = "disabled"; +}; + +&mcu_spi0 { + status = "disabled"; +}; + +&mcu_spi1 { + status = "disabled"; +}; + +/* dmss */ + +&fss { + status = "disabled"; +}; + +&main_mcan0 { + status = "disabled"; +}; + +&main_mcan1 { + status = "disabled"; +}; + +&usbss0 { + status = "disabled"; +}; + +&cpsw3g { + status = "disabled"; +}; + +&main_gpio0 { + status = "disabled"; +}; + +&main_gpio1 { + status = "disabled"; +}; + +&main_i2c0 { + status = "disabled"; +}; + +&main_i2c1 { + status = "disabled"; +}; + +&main_i2c2 { + status = "disabled"; +}; + +&main_i2c3 { + status = "disabled"; +}; + +&icssg0 { + status = "disabled"; +}; + +&icssg1 { + status = "disabled"; +}; + +/* gic500 */ + +&main_gpio_intr { + status = "disabled"; +}; + +&mailbox0_cluster2 { + status = "disabled"; +}; + +&mailbox0_cluster3 { + status = "disabled"; +}; + +&mailbox0_cluster4 { + status = "disabled"; +}; + +&mailbox0_cluster5 { + status = "disabled"; +}; + +&mailbox0_cluster6 { + status = "disabled"; +}; + +&mailbox0_cluster7 { + status = "disabled"; +}; + +&sdhci1 { + status = "disabled"; +}; + +&sdhci0 { + status = "disabled"; +}; + +&pcie0_ep { + status = "disabled"; +}; + +&pcie0_rc { + status = "disabled"; +}; + +×ync_router { + status = "disabled"; +}; + +&main_pmx0 { + /* (optional) for console */ + main_uart0_pins_default: main-uart0-pins-default { + pinctrl-single,pins = < + AM64X_IOPAD(0x0230, PIN_INPUT, 0) /* (D15) UART0_RXD */ + AM64X_IOPAD(0x0234, PIN_OUTPUT, 0) /* (C16) UART0_TXD */ + >; + }; +}; + +&epwm0 { + status = "disabled"; +}; + +&epwm1 { + status = "disabled"; +}; + +&epwm2 { + status = "disabled"; +}; + +&epwm3 { + status = "disabled"; +}; + +&epwm4 { + status = "disabled"; +}; + +&epwm5 { + status = "disabled"; +}; + +&epwm6 { + status = "disabled"; +}; + +&epwm7 { + status = "disabled"; +}; + +&epwm8 { + status = "disabled"; +}; + +&ecap0 { + status = "disabled"; +}; + +&ecap1 { + status = "disabled"; +}; + +&ecap2 { + status = "disabled"; +}; + +&main_r5fss0 { + status = "disabled"; +}; + +&main_r5fss1 { + status = "disabled"; +}; + +/* (optional) for console */ +&main_uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&main_uart0_pins_default>; +}; + +/* reserved for firmware */ +&main_uart1 { + status = "reserved"; +}; + +&main_uart2 { + status = "disabled"; +}; + +&main_uart3 { + status = "disabled"; +}; + +&main_uart4 { + status = "disabled"; +}; + +&main_uart5 { + status = "disabled"; +}; + +&main_uart6 { + status = "disabled"; +}; + +&main_spi0 { + status = "disabled"; +}; + +&main_spi1 { + status = "disabled"; +}; + +&main_spi2 { + status = "disabled"; +}; + +&main_spi3 { + status = "disabled"; +}; + +&main_spi4 { + status = "disabled"; +}; + +&hwspinlock { + status = "disabled"; +}; + +/* oc_sram */ + +&main_conf { + status = "disabled"; +}; + +/* dmsc */ + +&tscadc0 { + status = "disabled"; +}; + +&serdes_wiz0 { + status = "disabled"; +}; + +/* !cbass_main */ + +/* transceiver1 */ +/* transceiver2 */ + +&serdes_refclk { + status = "disabled"; +}; + +&cluster0 { + /delete-node/ core1; +}; + +&pmu { + status = "disabled"; +}; -- 2.17.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2022-03-21 15:54 [RFC] arm64: dts: ti: introduce a minimal am642 device tree Bryan Brattlof @ 2022-03-22 18:14 ` Krzysztof Kozlowski 2024-07-09 16:20 ` Logan Bristol 2022-03-30 13:55 ` Wadim Egorov 1 sibling, 1 reply; 11+ messages in thread From: Krzysztof Kozlowski @ 2022-03-22 18:14 UTC (permalink / raw) To: Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel On 21/03/2022 16:54, Bryan Brattlof wrote: > Texas Instrument's am642 is one of many k3 based, low cost, low power, > chips designed to work in a wide range of applications spanning an even > wider range of industries that TI is actively developing > > With its pin-mux and peripheral rich designs, these chips will likely > have a multitude of custom device trees that range wildly from one > another and (hopefully) guarantee an influx of variants into the kernel > in the coming years > > With overlays no longer a thing, I wanted to ask for opinions on how > we can best help integrate these dt files as they begin to be developed > > I also wanted to introduce a skeletonized (nothing but uart) device tree > to give others a good starting point while developing their projects. Real hardware as DTS please. There is no need to add some skeleton for specific SoC. What if every SoC goes that way? Feel free to create re-usable components in DTSI ways, still reflecting some hardware parts. > > Let me know what you think :) > > Signed-off-by: Bryan Brattlof <bb@ti.com> > --- > .../devicetree/bindings/arm/ti/k3.yaml | 1 + > arch/arm64/boot/dts/ti/Makefile | 1 + > arch/arm64/boot/dts/ti/k3-am642-skeleton.dts | 335 ++++++++++++++++++ > 3 files changed, 337 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-am642-skeleton.dts > > diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml > index 61c6ab4f52e26..e65053d6465bd 100644 > --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml > +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml > @@ -55,6 +55,7 @@ properties: > - description: K3 AM642 SoC > items: > - enum: > + - ti,am642-generic Real hardware is needed. > - ti,am642-evm > - ti,am642-sk > - const: ti,am642 > diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile > index 02e5d80344d00..df7bdf087558c 100644 > --- a/arch/arm64/boot/dts/ti/Makefile > +++ b/arch/arm64/boot/dts/ti/Makefile > @@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-common-proc-board.dtb > > dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb > > +dtb-$(CONFIG_ARCH_K3) += k3-am642-skeleton.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb > > diff --git a/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts > new file mode 100644 > index 0000000000000..2b789c9c25ced > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts > @@ -0,0 +1,335 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * The absolute minimum DTS file needed for an AM642 > + */ > + > +/dts-v1/; > + > +#include <dt-bindings/pinctrl/k3.h> > +#include "k3-am642.dtsi" > + > +/ { > + compatible = "ti,am642-generic", "ti,am642"; > + model = "Texas Instruments AM642 Generic"; > + > + chosen { > + stdout-path = "serial2:115200n8"; > + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000"; No development bootargs. > + }; > + > + cpus { > + /delete-node/ cpu@1; A bit weird... especially without any comment. > + }; > + > + memory@80000000 { > + device_type = "memory"; > + reg = <0x00000000 0x20000000 0x00000000 0x20000000>; > + }; > + > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + secure_ddr: optee@9e800000 { > + reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */ > + alignment = <0x1000>; > + no-map; > + }; > + }; > +}; > + > +/* reserved for mcu firmware */ > +&mcu_gpio0 { > + status = "reserved"; > +}; > + > +&mcu_i2c0 { > + status = "disabled"; > +}; > + Judging by this file - several disabled or reserved blocks - this does not look at all usable. What's the point? How does it even help anyone? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2022-03-22 18:14 ` Krzysztof Kozlowski @ 2024-07-09 16:20 ` Logan Bristol 2024-07-10 6:52 ` Krzysztof Kozlowski 2024-07-10 7:38 ` Francesco Dolcini 0 siblings, 2 replies; 11+ messages in thread From: Logan Bristol @ 2024-07-09 16:20 UTC (permalink / raw) To: Krzysztof Kozlowski, Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel Hi all, On 3/22/22 13:14, Krzysztof Kozlowski wrote: > On 21/03/2022 16:54, Bryan Brattlof wrote: >> Texas Instrument's am642 is one of many k3 based, low cost, low power, >> chips designed to work in a wide range of applications spanning an even >> wider range of industries that TI is actively developing >> >> With its pin-mux and peripheral rich designs, these chips will likely >> have a multitude of custom device trees that range wildly from one >> another and (hopefully) guarantee an influx of variants into the kernel >> in the coming years >> >> With overlays no longer a thing, I wanted to ask for opinions on how >> we can best help integrate these dt files as they begin to be developed >> >> I also wanted to introduce a skeletonized (nothing but uart) device tree >> to give others a good starting point while developing their projects. > > Real hardware as DTS please. There is no need to add some skeleton for > specific SoC. What if every SoC goes that way? > > Feel free to create re-usable components in DTSI ways, still reflecting > some hardware parts. > I am working on a project for the AM62 and came across this email thread. Following Krzysztof's direction, I am wanting to submit a DTSI to serve as a minimal configuration for the existing boards based on the AM62 SoC, which are currently defined by bloated DTS files. This DTSI file can be consumed by other board DTS files to reduce the configuration. Krzysztof, could this be merged upstream? Thanks, Logan Bristol >> >> Let me know what you think :) >> >> Signed-off-by: Bryan Brattlof <bb@ti.com> >> --- >> .../devicetree/bindings/arm/ti/k3.yaml | 1 + >> arch/arm64/boot/dts/ti/Makefile | 1 + >> arch/arm64/boot/dts/ti/k3-am642-skeleton.dts | 335 ++++++++++++++++++ >> 3 files changed, 337 insertions(+) >> create mode 100644 arch/arm64/boot/dts/ti/k3-am642-skeleton.dts >> >> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml >> index 61c6ab4f52e26..e65053d6465bd 100644 >> --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml >> +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml >> @@ -55,6 +55,7 @@ properties: >> - description: K3 AM642 SoC >> items: >> - enum: >> + - ti,am642-generic > > Real hardware is needed. > >> - ti,am642-evm >> - ti,am642-sk >> - const: ti,am642 >> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile >> index 02e5d80344d00..df7bdf087558c 100644 >> --- a/arch/arm64/boot/dts/ti/Makefile >> +++ b/arch/arm64/boot/dts/ti/Makefile >> @@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-common-proc-board.dtb >> >> dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb >> >> +dtb-$(CONFIG_ARCH_K3) += k3-am642-skeleton.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb >> >> diff --git a/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts >> new file mode 100644 >> index 0000000000000..2b789c9c25ced >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts >> @@ -0,0 +1,335 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * The absolute minimum DTS file needed for an AM642 >> + */ >> + >> +/dts-v1/; >> + >> +#include <dt-bindings/pinctrl/k3.h> >> +#include "k3-am642.dtsi" >> + >> +/ { >> + compatible = "ti,am642-generic", "ti,am642"; >> + model = "Texas Instruments AM642 Generic"; >> + >> + chosen { >> + stdout-path = "serial2:115200n8"; >> + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000"; > > > No development bootargs. > >> + }; >> + >> + cpus { >> + /delete-node/ cpu@1; > > A bit weird... especially without any comment. > >> + }; >> + >> + memory@80000000 { >> + device_type = "memory"; >> + reg = <0x00000000 0x20000000 0x00000000 0x20000000>; >> + }; >> + >> + reserved-memory { >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; >> + >> + secure_ddr: optee@9e800000 { >> + reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */ >> + alignment = <0x1000>; >> + no-map; >> + }; >> + }; >> +}; >> + >> +/* reserved for mcu firmware */ >> +&mcu_gpio0 { >> + status = "reserved"; >> +}; >> + >> +&mcu_i2c0 { >> + status = "disabled"; >> +}; >> + > > Judging by this file - several disabled or reserved blocks - this does > not look at all usable. What's the point? How does it even help anyone? > > > Best regards, > Krzysztof > > From mboxrd@z Thu Jan 1 00:00:00 1970 > Return-Path: <linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org> > X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on > aws-us-west-2-korg-lkml-1.web.codeaurora.org > Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) > (No client certificate requested) > by smtp.lore.kernel.org (Postfix) with ESMTPS id 5064FC433EF > for <linux-arm-kernel@archiver.kernel.org>; Tue, 22 Mar 2022 18:15:38 +0000 (UTC) > DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; > d=lists.infradead.org; s=bombadil.20210309; h=Sender: > Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: > List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: > Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: > Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: > List-Owner; bh=b11MEVmqRLF+jj9/rtqsBkiDpamrd5oQVRiYmZE68eM=; b=kz+0d/sZgV7fS+ > hqxQmmiX+UhdZGQhPjCB0vDywhWUFM5N9LXvCjVmAPIiW73+5d20vKI35Pqzq7FhUvt0abI212Omq > xA70WW5t27CGolgST7/t763EBk3qS5HrPcHbh3cF6I5IBGSC1COOoieUaMOKGT3eOPd77BRYpUZX5 > ZOFBtgYAkU+AACb1SfxOjpFwxJAXgRNYJMdKeaTiDzEwUAGKWvnR34WkUj9y3vMXaxxxQ3GOC+25r > iEk4YUSWRTYNHFiRi0VumbUM7KW5EMAZHD1WK3qoGybpEF+jMYaIrM6/F3/7vSkAcZ3FXphIMeUmx > K2G+NXzpQXNDdh6eRAgw==; > Received: from localhost ([::1] helo=bombadil.infradead.org) > by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) > id 1nWj1Q-00BqZe-Th; Tue, 22 Mar 2022 18:14:21 +0000 > Received: from mail-ed1-f42.google.com ([209.85.208.42]) > by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) > id 1nWj1M-00BqYR-K6 > for linux-arm-kernel@lists.infradead.org; Tue, 22 Mar 2022 18:14:18 +0000 > Received: by mail-ed1-f42.google.com with SMTP id a17so21661927edm.9 > for <linux-arm-kernel@lists.infradead.org>; > Tue, 22 Mar 2022 11:14:11 -0700 (PDT) > X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=1e100.net; s=20210112; > h=x-gm-message-state:message-id:date:mime-version:user-agent:subject > :content-language:to:cc:references:from:in-reply-to > :content-transfer-encoding; > bh=YSNtfm2I+E7ZPtbQKZG0Nrw6hi+P+RYiX3Pd+JP3Ab4=; > b=b5L7SUGqENepcUJ0I+stC8g2ipIMnL1DYhzdPZ6mlga1Cr13e9v83P4vidTkvI3NiK > 8RZ8kgLc7rPTD5QTkequIpqKxok3PJQe+BKY5m/AVFwiXGrODsf1cs6CUp4G0kyFZ51v > S2ugShWorsaWP/gkaHrt/FqIPCZiCJd8WM+eyL/VV0V5NqzdLMeGpNvDa3VX9G8t3kAk > J9KuLqVsjQNerDbjLoW+jAheXgPfrjQZsKLCX1xmxL/83wYrw3JSr/ee0TZAGmM74px4 > /QrmDYnv4nR5k7tS8ziD5OByuFsm1BVEkA4lDrl/Y4G0N5IflRPp483Ld7GiQsqubjOV > 3jzA== > X-Gm-Message-State: AOAM530bVfXqqu36LMJh9oigYabIp8MnyKdNFRYuxTvWlvdXcgcF5FEd > AnclY4HUCVnXYTMijnwCBk8= > X-Google-Smtp-Source: ABdhPJwdUri/i8z1B7zh8yu0O1Iy/wywZGubvdSv0lI+ID/JVL2IS4yIxLLkfnX8yWWh3ln4JtofCQ== > X-Received: by 2002:a50:c00a:0:b0:418:f10f:b27c with SMTP id > r10-20020a50c00a000000b00418f10fb27cmr29450490edb.204.1647972850517; > Tue, 22 Mar 2022 11:14:10 -0700 (PDT) > Received: from [192.168.0.17] (78-11-189-27.static.ip.netia.com.pl. > [78.11.189.27]) by smtp.googlemail.com with ESMTPSA id > n24-20020a17090673d800b006df8ec24712sm7481201ejl.215.2022.03.22.11.14.09 > (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); > Tue, 22 Mar 2022 11:14:09 -0700 (PDT) > Message-ID: <55e161d1-face-6958-1d86-8a85b82e8485@kernel.org> > Date: Tue, 22 Mar 2022 19:14:08 +0100 > MIME-Version: 1.0 > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 > Thunderbird/91.5.0 > Subject: Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree > Content-Language: en-US > To: Bryan Brattlof <bb@ti.com>, Nishanth Menon <nm@ti.com>, > Vignesh Raghavendra <vigneshr@ti.com>, Tero Kristo <kristo@kernel.org> > Cc: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski > <krzk+dt@kernel.org>, linux-arm-kernel@lists.infradead.org, > devicetree@vger.kernel.org, linux-kernel@vger.kernel.org > References: <20220321155417.13267-1-bb@ti.com> > From: Krzysztof Kozlowski <krzk@kernel.org> > In-Reply-To: <20220321155417.13267-1-bb@ti.com> > X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 > X-CRM114-CacheID: sfid-20220322_111416_699438_4DF67032 > X-CRM114-Status: GOOD ( 27.85 ) > X-BeenThere: linux-arm-kernel@lists.infradead.org > X-Mailman-Version: 2.1.34 > Precedence: list > List-Id: <linux-arm-kernel.lists.infradead.org> > List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>, > <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe> > List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/> > List-Post: <mailto:linux-arm-kernel@lists.infradead.org> > List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help> > List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>, > <mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe> > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org> > Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > > On 21/03/2022 16:54, Bryan Brattlof wrote: >> Texas Instrument's am642 is one of many k3 based, low cost, low power, >> chips designed to work in a wide range of applications spanning an even >> wider range of industries that TI is actively developing >> >> With its pin-mux and peripheral rich designs, these chips will likely >> have a multitude of custom device trees that range wildly from one >> another and (hopefully) guarantee an influx of variants into the kernel >> in the coming years >> >> With overlays no longer a thing, I wanted to ask for opinions on how >> we can best help integrate these dt files as they begin to be developed >> >> I also wanted to introduce a skeletonized (nothing but uart) device tree >> to give others a good starting point while developing their projects. > > Real hardware as DTS please. There is no need to add some skeleton for > specific SoC. What if every SoC goes that way? > > Feel free to create re-usable components in DTSI ways, still reflecting > some hardware parts. > >> >> Let me know what you think :) >> >> Signed-off-by: Bryan Brattlof <bb@ti.com> >> --- >> .../devicetree/bindings/arm/ti/k3.yaml | 1 + >> arch/arm64/boot/dts/ti/Makefile | 1 + >> arch/arm64/boot/dts/ti/k3-am642-skeleton.dts | 335 ++++++++++++++++++ >> 3 files changed, 337 insertions(+) >> create mode 100644 arch/arm64/boot/dts/ti/k3-am642-skeleton.dts >> >> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml >> index 61c6ab4f52e26..e65053d6465bd 100644 >> --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml >> +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml >> @@ -55,6 +55,7 @@ properties: >> - description: K3 AM642 SoC >> items: >> - enum: >> + - ti,am642-generic > > Real hardware is needed. > >> - ti,am642-evm >> - ti,am642-sk >> - const: ti,am642 >> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile >> index 02e5d80344d00..df7bdf087558c 100644 >> --- a/arch/arm64/boot/dts/ti/Makefile >> +++ b/arch/arm64/boot/dts/ti/Makefile >> @@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-common-proc-board.dtb >> >> dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb >> >> +dtb-$(CONFIG_ARCH_K3) += k3-am642-skeleton.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb >> >> diff --git a/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts >> new file mode 100644 >> index 0000000000000..2b789c9c25ced >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am642-skeleton.dts >> @@ -0,0 +1,335 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * The absolute minimum DTS file needed for an AM642 >> + */ >> + >> +/dts-v1/; >> + >> +#include <dt-bindings/pinctrl/k3.h> >> +#include "k3-am642.dtsi" >> + >> +/ { >> + compatible = "ti,am642-generic", "ti,am642"; >> + model = "Texas Instruments AM642 Generic"; >> + >> + chosen { >> + stdout-path = "serial2:115200n8"; >> + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000"; > > > No development bootargs. > >> + }; >> + >> + cpus { >> + /delete-node/ cpu@1; > > A bit weird... especially without any comment. > >> + }; >> + >> + memory@80000000 { >> + device_type = "memory"; >> + reg = <0x00000000 0x20000000 0x00000000 0x20000000>; >> + }; >> + >> + reserved-memory { >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; >> + >> + secure_ddr: optee@9e800000 { >> + reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */ >> + alignment = <0x1000>; >> + no-map; >> + }; >> + }; >> +}; >> + >> +/* reserved for mcu firmware */ >> +&mcu_gpio0 { >> + status = "reserved"; >> +}; >> + >> +&mcu_i2c0 { >> + status = "disabled"; >> +}; >> + > > Judging by this file - several disabled or reserved blocks - this does > not look at all usable. What's the point? How does it even help anyone? > > > Best regards, > Krzysztof > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2024-07-09 16:20 ` Logan Bristol @ 2024-07-10 6:52 ` Krzysztof Kozlowski 2024-07-15 14:12 ` Logan Bristol 2024-07-10 7:38 ` Francesco Dolcini 1 sibling, 1 reply; 11+ messages in thread From: Krzysztof Kozlowski @ 2024-07-10 6:52 UTC (permalink / raw) To: Logan Bristol, Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel On 09/07/2024 18:20, Logan Bristol wrote: > > Hi all, > > On 3/22/22 13:14, Krzysztof Kozlowski wrote: >> On 21/03/2022 16:54, Bryan Brattlof wrote: >>> Texas Instrument's am642 is one of many k3 based, low cost, low power, >>> chips designed to work in a wide range of applications spanning an even >>> wider range of industries that TI is actively developing >>> >>> With its pin-mux and peripheral rich designs, these chips will likely >>> have a multitude of custom device trees that range wildly from one >>> another and (hopefully) guarantee an influx of variants into the kernel >>> in the coming years >>> >>> With overlays no longer a thing, I wanted to ask for opinions on how >>> we can best help integrate these dt files as they begin to be developed >>> >>> I also wanted to introduce a skeletonized (nothing but uart) device tree >>> to give others a good starting point while developing their projects. >> >> Real hardware as DTS please. There is no need to add some skeleton for >> specific SoC. What if every SoC goes that way? >> >> Feel free to create re-usable components in DTSI ways, still reflecting >> some hardware parts. >> > > I am working on a project for the AM62 and came across this email thread. > > Following Krzysztof's direction, I am wanting to submit a DTSI to serve > as a minimal configuration for the existing boards based on the AM62 > SoC, which are currently defined by bloated DTS files. > > This DTSI file can be consumed by other board DTS files to reduce the > configuration. Krzysztof, could this be merged upstream? Aren't you writing something contradictory to what I wrote above? I do not see your description matching my earlier guideline. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2024-07-10 6:52 ` Krzysztof Kozlowski @ 2024-07-15 14:12 ` Logan Bristol 0 siblings, 0 replies; 11+ messages in thread From: Logan Bristol @ 2024-07-15 14:12 UTC (permalink / raw) To: Krzysztof Kozlowski, Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel On 7/10/24 01:52, Krzysztof Kozlowski wrote: > On 09/07/2024 18:20, Logan Bristol wrote: >> >> Hi all, >> >> On 3/22/22 13:14, Krzysztof Kozlowski wrote: >>> On 21/03/2022 16:54, Bryan Brattlof wrote: >>>> Texas Instrument's am642 is one of many k3 based, low cost, low power, >>>> chips designed to work in a wide range of applications spanning an even >>>> wider range of industries that TI is actively developing >>>> >>>> With its pin-mux and peripheral rich designs, these chips will likely >>>> have a multitude of custom device trees that range wildly from one >>>> another and (hopefully) guarantee an influx of variants into the kernel >>>> in the coming years >>>> >>>> With overlays no longer a thing, I wanted to ask for opinions on how >>>> we can best help integrate these dt files as they begin to be developed >>>> >>>> I also wanted to introduce a skeletonized (nothing but uart) device tree >>>> to give others a good starting point while developing their projects. >>> >>> Real hardware as DTS please. There is no need to add some skeleton for >>> specific SoC. What if every SoC goes that way? >>> >>> Feel free to create re-usable components in DTSI ways, still reflecting >>> some hardware parts. >>> >> >> I am working on a project for the AM62 and came across this email thread. >> >> Following Krzysztof's direction, I am wanting to submit a DTSI to serve >> as a minimal configuration for the existing boards based on the AM62 >> SoC, which are currently defined by bloated DTS files. >> >> This DTSI file can be consumed by other board DTS files to reduce the >> configuration. Krzysztof, could this be merged upstream? > > Aren't you writing something contradictory to what I wrote above? I do > not see your description matching my earlier guideline. > > Best regards, > Krzysztof > I understand your statement now. Are there any other paths you can suggest for a minimal configuration to be accepted? Thanks, Logan Bristol ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2024-07-09 16:20 ` Logan Bristol 2024-07-10 6:52 ` Krzysztof Kozlowski @ 2024-07-10 7:38 ` Francesco Dolcini 2024-07-15 14:02 ` Logan Bristol 1 sibling, 1 reply; 11+ messages in thread From: Francesco Dolcini @ 2024-07-10 7:38 UTC (permalink / raw) To: Logan Bristol Cc: Krzysztof Kozlowski, Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel Hello Logan On Tue, Jul 09, 2024 at 11:20:24AM -0500, Logan Bristol wrote: > On 3/22/22 13:14, Krzysztof Kozlowski wrote: > > On 21/03/2022 16:54, Bryan Brattlof wrote: > >> Texas Instrument's am642 is one of many k3 based, low cost, low power, > >> chips designed to work in a wide range of applications spanning an even > >> wider range of industries that TI is actively developing > >> > >> With its pin-mux and peripheral rich designs, these chips will likely > >> have a multitude of custom device trees that range wildly from one > >> another and (hopefully) guarantee an influx of variants into the kernel > >> in the coming years > >> > >> With overlays no longer a thing, I wanted to ask for opinions on how > >> we can best help integrate these dt files as they begin to be developed > >> > >> I also wanted to introduce a skeletonized (nothing but uart) device tree > >> to give others a good starting point while developing their projects. > > > > Real hardware as DTS please. There is no need to add some skeleton for > > specific SoC. What if every SoC goes that way? > > > > Feel free to create re-usable components in DTSI ways, still reflecting > > some hardware parts. > > > > I am working on a project for the AM62 and came across this email thread. > > Following Krzysztof's direction, I am wanting to submit a DTSI to serve > as a minimal configuration for the existing boards based on the AM62 > SoC, which are currently defined by bloated DTS files. > > This DTSI file can be consumed by other board DTS files to reduce the > configuration. Krzysztof, could this be merged upstream? Can you elaborate a little bit what you meant as bloated dts file? Why would you need different DTSI files compared to the existing one? Which problem are you trying to solve (make some example, be specific please). My experience with verdin am62 (k3-am62-verdin*dts*) was pretty smooth, I was just able to use the SOC dtsi file and use it to define my own board (and I had the same good experience with other SOC/Vendors). Francesco ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2024-07-10 7:38 ` Francesco Dolcini @ 2024-07-15 14:02 ` Logan Bristol 2024-07-15 14:55 ` Francesco Dolcini 0 siblings, 1 reply; 11+ messages in thread From: Logan Bristol @ 2024-07-15 14:02 UTC (permalink / raw) To: Francesco Dolcini Cc: Krzysztof Kozlowski, Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel Hello Francesco, On 7/10/24 02:38, Francesco Dolcini wrote: > Hello Logan > > On Tue, Jul 09, 2024 at 11:20:24AM -0500, Logan Bristol wrote: >> On 3/22/22 13:14, Krzysztof Kozlowski wrote: >>> On 21/03/2022 16:54, Bryan Brattlof wrote: >>>> Texas Instrument's am642 is one of many k3 based, low cost, low power, >>>> chips designed to work in a wide range of applications spanning an even >>>> wider range of industries that TI is actively developing >>>> >>>> With its pin-mux and peripheral rich designs, these chips will likely >>>> have a multitude of custom device trees that range wildly from one >>>> another and (hopefully) guarantee an influx of variants into the kernel >>>> in the coming years >>>> >>>> With overlays no longer a thing, I wanted to ask for opinions on how >>>> we can best help integrate these dt files as they begin to be developed >>>> >>>> I also wanted to introduce a skeletonized (nothing but uart) device tree >>>> to give others a good starting point while developing their projects. >>> >>> Real hardware as DTS please. There is no need to add some skeleton for >>> specific SoC. What if every SoC goes that way? >>> >>> Feel free to create re-usable components in DTSI ways, still reflecting >>> some hardware parts. >>> >> >> I am working on a project for the AM62 and came across this email thread. >> >> Following Krzysztof's direction, I am wanting to submit a DTSI to serve >> as a minimal configuration for the existing boards based on the AM62 >> SoC, which are currently defined by bloated DTS files. >> >> This DTSI file can be consumed by other board DTS files to reduce the >> configuration. Krzysztof, could this be merged upstream? > > Can you elaborate a little bit what you meant as bloated dts file? Why > would you need different DTSI files compared to the existing one? > Which problem are you trying to solve (make some example, be specific > please). > > My experience with verdin am62 (k3-am62-verdin*dts*) was pretty smooth, > I was just able to use the SOC dtsi file and use it to define my own > board (and I had the same good experience with other SOC/Vendors). > > Francesco > The resulting DTB after compiling AM62 SoC DTSI files initializes a large number of devices. A DTSI that initializes a minimal configuration that is immediately functional across SoC variations could be used on existing boards for test and debug purposes to isolate root cause of failure. It could also serve as a minimal configuration for board bringup. Thanks, Logan Bristol ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2024-07-15 14:02 ` Logan Bristol @ 2024-07-15 14:55 ` Francesco Dolcini 0 siblings, 0 replies; 11+ messages in thread From: Francesco Dolcini @ 2024-07-15 14:55 UTC (permalink / raw) To: Logan Bristol Cc: Francesco Dolcini, Krzysztof Kozlowski, Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel On Mon, Jul 15, 2024 at 09:02:38AM -0500, Logan Bristol wrote: > > Hello Francesco, > > On 7/10/24 02:38, Francesco Dolcini wrote: > > Hello Logan > > > > On Tue, Jul 09, 2024 at 11:20:24AM -0500, Logan Bristol wrote: > >> On 3/22/22 13:14, Krzysztof Kozlowski wrote: > >>> On 21/03/2022 16:54, Bryan Brattlof wrote: > >>>> Texas Instrument's am642 is one of many k3 based, low cost, low power, > >>>> chips designed to work in a wide range of applications spanning an even > >>>> wider range of industries that TI is actively developing > >>>> > >>>> With its pin-mux and peripheral rich designs, these chips will likely > >>>> have a multitude of custom device trees that range wildly from one > >>>> another and (hopefully) guarantee an influx of variants into the kernel > >>>> in the coming years > >>>> > >>>> With overlays no longer a thing, I wanted to ask for opinions on how > >>>> we can best help integrate these dt files as they begin to be developed > >>>> > >>>> I also wanted to introduce a skeletonized (nothing but uart) device tree > >>>> to give others a good starting point while developing their projects. > >>> > >>> Real hardware as DTS please. There is no need to add some skeleton for > >>> specific SoC. What if every SoC goes that way? > >>> > >>> Feel free to create re-usable components in DTSI ways, still reflecting > >>> some hardware parts. > >>> > >> > >> I am working on a project for the AM62 and came across this email thread. > >> > >> Following Krzysztof's direction, I am wanting to submit a DTSI to serve > >> as a minimal configuration for the existing boards based on the AM62 > >> SoC, which are currently defined by bloated DTS files. > >> > >> This DTSI file can be consumed by other board DTS files to reduce the > >> configuration. Krzysztof, could this be merged upstream? > > > > Can you elaborate a little bit what you meant as bloated dts file? Why > > would you need different DTSI files compared to the existing one? > > Which problem are you trying to solve (make some example, be specific > > please). > > > > My experience with verdin am62 (k3-am62-verdin*dts*) was pretty smooth, > > I was just able to use the SOC dtsi file and use it to define my own > > board (and I had the same good experience with other SOC/Vendors). > > > > The resulting DTB after compiling AM62 SoC DTSI files initializes a > large number of devices. I do not understand the issue. The SOC dtsi enables (or should enable) only IP that are self contained within the SOC, everything else is disabled. If you need something like that it means you are debugging the silicon, am I wrong? Francesco ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2022-03-21 15:54 [RFC] arm64: dts: ti: introduce a minimal am642 device tree Bryan Brattlof 2022-03-22 18:14 ` Krzysztof Kozlowski @ 2022-03-30 13:55 ` Wadim Egorov 2022-03-31 6:58 ` Vignesh Raghavendra 1 sibling, 1 reply; 11+ messages in thread From: Wadim Egorov @ 2022-03-30 13:55 UTC (permalink / raw) To: Bryan Brattlof, Nishanth Menon, Vignesh Raghavendra, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel Hi Bryan, > +/* (optional) for console */ > +&main_uart0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&main_uart0_pins_default>; > +}; > + > +/* reserved for firmware */ > +&main_uart1 { > + status = "reserved"; > +}; k3-image-gen says UART0 is used as a debug interface. See https://git.ti.com/cgit/k3-image-gen/k3-image-gen/tree/soc/am64x/evm/board-cfg.c#n81 So it seems that you can enable uart1 here. But people may run into a conflict with uart0 and k3-image-gen compiled with ENABLE_TRACE=1. If I am wrong, can you please clarify why you mark uart1 as reserved. Regards, Wadim ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2022-03-30 13:55 ` Wadim Egorov @ 2022-03-31 6:58 ` Vignesh Raghavendra 2022-03-31 7:19 ` Wadim Egorov 0 siblings, 1 reply; 11+ messages in thread From: Vignesh Raghavendra @ 2022-03-31 6:58 UTC (permalink / raw) To: Wadim Egorov, Bryan Brattlof, Nishanth Menon, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel Hi Wadim, On 30/03/22 7:25 pm, Wadim Egorov wrote: > Hi Bryan, > >> +/* (optional) for console */ >> +&main_uart0 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&main_uart0_pins_default>; >> +}; >> + >> +/* reserved for firmware */ >> +&main_uart1 { >> + status = "reserved"; >> +}; > > k3-image-gen says UART0 is used as a debug interface. See > > > https://git.ti.com/cgit/k3-image-gen/k3-image-gen/tree/soc/am64x/evm/board-cfg.c#n81 > > > So it seems that you can enable uart1 here. But people may run into a > conflict with uart0 and k3-image-gen compiled with ENABLE_TRACE=1. > > If I am wrong, can you please clarify why you mark uart1 as reserved. > We just seem to have same macro shared across multiple SoCs, BOARDCFG_TRACE_DST_UART0 means logs are also directed to UART. Instance of UART used for logging is platform specific. On AM64 SYSFW logs are directed to MAIN UART1 (MAIN UART0 is used for linux console). I will work internally and get SYSFW documentation updated to reflect the same. Thanks! Regards Vignesh ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree 2022-03-31 6:58 ` Vignesh Raghavendra @ 2022-03-31 7:19 ` Wadim Egorov 0 siblings, 0 replies; 11+ messages in thread From: Wadim Egorov @ 2022-03-31 7:19 UTC (permalink / raw) To: Vignesh Raghavendra, Bryan Brattlof, Nishanth Menon, Tero Kristo Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel Am 31.03.22 um 08:58 schrieb Vignesh Raghavendra: > Hi Wadim, > > On 30/03/22 7:25 pm, Wadim Egorov wrote: >> Hi Bryan, >> >>> +/* (optional) for console */ >>> +&main_uart0 { >>> + pinctrl-names = "default"; >>> + pinctrl-0 = <&main_uart0_pins_default>; >>> +}; >>> + >>> +/* reserved for firmware */ >>> +&main_uart1 { >>> + status = "reserved"; >>> +}; >> >> k3-image-gen says UART0 is used as a debug interface. See >> >> >> https://git.ti.com/cgit/k3-image-gen/k3-image-gen/tree/soc/am64x/evm/board-cfg.c#n81 >> >> >> So it seems that you can enable uart1 here. But people may run into a >> conflict with uart0 and k3-image-gen compiled with ENABLE_TRACE=1. >> >> If I am wrong, can you please clarify why you mark uart1 as reserved. >> > > We just seem to have same macro shared across multiple SoCs, > BOARDCFG_TRACE_DST_UART0 means logs are also directed to UART. Instance > of UART used for logging is platform specific. > > On AM64 SYSFW logs are directed to MAIN UART1 (MAIN UART0 is used for > linux console). I will work internally and get SYSFW documentation > updated to reflect the same. Thanks! OK, thank you for the clarification. > > Regards > Vignesh ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-07-15 14:55 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-03-21 15:54 [RFC] arm64: dts: ti: introduce a minimal am642 device tree Bryan Brattlof 2022-03-22 18:14 ` Krzysztof Kozlowski 2024-07-09 16:20 ` Logan Bristol 2024-07-10 6:52 ` Krzysztof Kozlowski 2024-07-15 14:12 ` Logan Bristol 2024-07-10 7:38 ` Francesco Dolcini 2024-07-15 14:02 ` Logan Bristol 2024-07-15 14:55 ` Francesco Dolcini 2022-03-30 13:55 ` Wadim Egorov 2022-03-31 6:58 ` Vignesh Raghavendra 2022-03-31 7:19 ` Wadim Egorov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).