Re: [PATCH 2/3] arm64: dts: ti: Add Support for AM642 SoC

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

 



Suman,

On 12/3/20 4:00 PM, Suman Anna wrote:
> On 12/3/20 3:56 PM, Suman Anna wrote:
>> Hi Dave,
>>
>> On 11/24/20 11:20 PM, Dave Gerlach wrote:
>>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>>> providing advanced system integration to enable applications such as
>>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>>
>>> Some highlights of this SoC are:
>>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>>>   MCUs, and a single Cortex-M4F.
>>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>>> * Integrated Ethernet switch supporting up to a total of two external
>>>   ports.
>>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>>>   controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>>>   peripherals.
>>> * Centralized System Controller for Security, Power, and Resource
>>>   Management (DMSC).
>>>
>>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>>> for further details: https://www.ti.com/lit/pdf/spruim2
>>>
>>> Introduce basic support for the AM642 SoC to enable minimal
>>> ramdisk boot. Introduce a limited set of MAIN domain periperhals
>>> under cbass_main and a placeholder cbass_mcu node for future MCU
>>> domain usage.
>>>
>>> Signed-off-by: Dave Gerlach <d-gerlach@xxxxxx>
>>> ---
>>>  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 178 +++++++++++++++++++++++
>>>  arch/arm64/boot/dts/ti/k3-am64.dtsi      |  95 ++++++++++++
>>>  arch/arm64/boot/dts/ti/k3-am642.dtsi     |  65 +++++++++
>>>  3 files changed, 338 insertions(+)
>>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
>>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>>>

... snip ...

>>> +	main_uart6: serial@2860000 {
>>> +		compatible = "ti,am64-uart", "ti,am654-uart";
>>> +		reg = <0x00 0x02860000 0x00 0x100>;
>>> +		reg-shift = <2>;
>>> +		reg-io-width = <4>;
>>> +		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
>>> +		clock-frequency = <48000000>;
>>> +		current-speed = <115200>;
>>> +		power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
>>> +		clocks = <&k3_clks 158 0>;
>>> +		clock-names = "fclk";
>>> +	};
>>> +};
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>>> new file mode 100644
>>> index 000000000000..0637cf9ede5f
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>>> @@ -0,0 +1,95 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree Source for AM642 SoC Family
>>> + *
>>> + * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
>>> + */
>>> +
>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +#include <dt-bindings/pinctrl/k3.h>
>>> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
>>> +
>>> +/ {
>>> +	model = "Texas Instruments K3 AM642 SoC";
>>> +	compatible = "ti,am642";
>>> +	interrupt-parent = <&gic500>;
>>> +	#address-cells = <2>;
>>> +	#size-cells = <2>;
>>> +
>>> +	aliases {
>>> +		serial2 = &main_uart0;
>>> +		serial3 = &main_uart1;
>>> +		serial4 = &main_uart2;
>>> +		serial5 = &main_uart3;
>>> +		serial6 = &main_uart4;
>>> +		serial7 = &main_uart5;
>>> +		serial8 = &main_uart6;
> 
> Yeah, this looks weird. I understand that serial0 and serial1 are meant for MCU
> UARTs, but any reason why we don't want to add the k3-am64-mcu.dtsi and the MCU
> UARTs along with this patch?
> 
> regards
> Suman

Sure, I will add them. Was originally trying to keep this as bare bones
as possible but I will just add them to give us all uarts.

> 
>>> +	};
>>> +
>>> +	chosen { };
>>> +
>>> +	firmware {
>>> +		optee {
>>> +			compatible = "linaro,optee-tz";
>>> +			method = "smc";
>>> +		};
>>> +
>>> +		psci: psci {
>>> +			compatible = "arm,psci-1.0";
>>> +			method = "smc";
>>> +		};
>>> +	};
>>> +
>>> +	a53_timer0: timer-cl0-cpu0 {
>>> +		compatible = "arm,armv8-timer";
>>> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
>>> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
>>> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
>>> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
>>> +	};
>>> +
>>> +	pmu: pmu {
>>> +		compatible = "arm,armv8-pmuv3";
>>> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
>>> +	};
>>> +
>>> +	cbass_main: bus@f4000 {
>>> +		compatible = "simple-bus";
>>> +		#address-cells = <2>;
>>> +		#size-cells = <2>;
>>> +		ranges = <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
>>> +			 <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
>>> +			 <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
>>> +			 <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
>>> +			 <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
>>> +			 <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
>>> +			 <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
>>> +			 <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
>>> +			 <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
>>> +			 <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
>>> +			 <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
>>> +			 <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
>>> +			 <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
>>> +			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
>>> +			 <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
>>> +			 <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
>>> +			 <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002e4>, /* PINCTRL */
>>
>> Can you move this to the top, so that all these are in increasing memory order?

Yes done.

>>
>>> +			 <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
>>> +			 <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
>>> +			 <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
>>
>> This is atleast missing the ranges for On-Chip SRAM and the R5FSS, but those can
>> always be added incrementally as well.

Yes, I think they should be added incrementally once a user is present.

>>
>> Also, is there a reason for using these ranges a bit more granular compared to
>> the earlier SoCs?

Any reason we shouldn't be? Memory map has different groupings of
peripherals.

Regards,
Dave

>>
>> regards
>> Suman
>>
>>> +
>>> +			 /* MCU Domain Range */
>>> +			 <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
>>> +
>>> +		cbass_mcu: bus@4000000 {
>>> +			compatible = "simple-bus";
>>> +			#address-cells = <2>;
>>> +			#size-cells = <2>;
>>> +			ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
>>> +		};
>>> +	};
>>> +};
>>> +
>>> +/* Now include the peripherals for each bus segments */
>>> +#include "k3-am64-main.dtsi"
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>>> new file mode 100644
>>> index 000000000000..b30f239e84f1
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>>> @@ -0,0 +1,65 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree Source for AM642 SoC family in Dual core configuration
>>> + *
>>> + * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "k3-am64.dtsi"
>>> +
>>> +/ {
>>> +	cpus {
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		cpu-map {
>>> +			cluster0: cluster0 {
>>> +				core0 {
>>> +					cpu = <&cpu0>;
>>> +				};
>>> +
>>> +				core1 {
>>> +					cpu = <&cpu1>;
>>> +				};
>>> +			};
>>> +		};
>>> +
>>> +		cpu0: cpu@0 {
>>> +			compatible = "arm,cortex-a53";
>>> +			reg = <0x000>;
>>> +			device_type = "cpu";
>>> +			enable-method = "psci";
>>> +			i-cache-size = <0x8000>;
>>> +			i-cache-line-size = <64>;
>>> +			i-cache-sets = <256>;
>>> +			d-cache-size = <0x8000>;
>>> +			d-cache-line-size = <64>;
>>> +			d-cache-sets = <128>;
>>> +			next-level-cache = <&L2_0>;
>>> +		};
>>> +
>>> +		cpu1: cpu@1 {
>>> +			compatible = "arm,cortex-a53";
>>> +			reg = <0x001>;
>>> +			device_type = "cpu";
>>> +			enable-method = "psci";
>>> +			i-cache-size = <0x8000>;
>>> +			i-cache-line-size = <64>;
>>> +			i-cache-sets = <256>;
>>> +			d-cache-size = <0x8000>;
>>> +			d-cache-line-size = <64>;
>>> +			d-cache-sets = <128>;
>>> +			next-level-cache = <&L2_0>;
>>> +		};
>>> +	};
>>> +
>>> +	L2_0: l2-cache0 {
>>> +		compatible = "cache";
>>> +		cache-level = <2>;
>>> +		cache-size = <0x40000>;
>>> +		cache-line-size = <64>;
>>> +		cache-sets = <512>;
>>> +	};
>>> +};
>>>
>>
> 



[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