linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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; 5+ 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";
+};
+
+&timesync_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] 5+ 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
  1 sibling, 0 replies; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ messages in thread

end of thread, other threads:[~2022-03-31  7:20 UTC | newest]

Thread overview: 5+ 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
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).