| Message ID | 20180605060510.32473-1-nm@ti.com |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
On 12:38-20180614, Tony Lindgren wrote: > Some comments on the ranges below. Thanks for reviewing in detail (I understand we are in the middle of merge window, so thanks for the extra effort). > > * Nishanth Menon <nm@ti.com> [180607 16:41]: > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > I suggest you leave out the soc0, that's not real. Just make Why is that so, on a more complex board representation with multiple SoCs, this is a clear node indicating what the main SoC is in the final dtb representation. > the cbass@0 the top level interconnect. It can then provide > ranges to mcu interconnect which can provide ranges to the wkup > interconnect. So just model it after what's in the hardware :) That might blow up things quite a bit - it is like the comment in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7.dtsi#n141 The trees are pretty deep with many interconnections (example main does have direct connections to wkup as well, which is simplified off in top level diagram) - basically it is not a direct one dimensional relationship. But then, the same is the case for other SoCs.. we can represent NAVSS as a bus segment as well. > > I found the following ranges based on a quick look at the TRM, > they could be split further if needed for power domains for > genpd for example. genpd is not really an issue, since it is handled in system firmware and OSes dont have a visibility into the permitted ranges that the OS is allowed to use. I think it is just how accurate a representation is it worth. > > main covers > 0x0000000000 - 0x5402000000 > > main provides at least the following ranges for mcu > 0x0028380000 - 0x002bc00000 > 0x0040080000 - 0x0041c80000 > 0x0045100000 - 0x0045180000 > 0x0045600000 - 0x0045640000 > 0x0045810000 - 0x0045860000 > 0x0045950000 - 0x0045950400 > 0x0045a50000 - 0x0045a50400 > 0x0045b04000 - 0x0045b06400 > 0x0045d10000 - 0x0045d24000 > 0x0046000000 - 0x0060000000 > 0x0400000000 - 0x0800000000 > 0x4c3c020000 - 0x4c3c030000 > 0x4c3e000000 - 0x4c3e040000 > 0x5400000000 - 0x5402000000 > > then mcu provides the following ranges for wkup > 0x0042000000 - 0x0044410020 > 0x0045000000 - 0x0045030000 > 0x0045080000 - 0x00450a0000 > 0x0045808000 - 0x0045808800 > 0x0045b00000 - 0x0045b02400 > > This based on looking at "figure 1-1. device top-level > block diagram" and the memory map in TRM. Thanks for researching. I did debate something like: From A53 view, a more accurate view might be - from an interconnect view of the world (still simplified - i have ignored the sub bus segments in the representations below): msmc { navss_main { cbass_main{ cbass_mcu { navss_mcu { }; cbass_wkup{ }; }; }; }; }; From R5 view, the view will be very different ofcourse: view of the world (still simplified): cbass_mcu { navss_mcu { }; cbass_wkup{ }; cbass_main{ navss_main { msmc { }; }; }; }; Do we really need this level of representation, I am not sure I had seen this detailed a representation in other aarch64 SoCs (I am sure they are as complex as TI SoCs as well). I am trying to understand the direction and logic why we'd want to have such a detailed representation. A more flatter representation of just the main segments allow for dts reuse between r5 and a53 as well (but that is minor). Thoughts? -- Regards, Nishanth Menon
Hi Tony, On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I <kishon@ti.com> [180808 06:35]: >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >>> Really need 64-bit addresses and sizes? Use ranges to limit the >>> address space if possible. >> >> We now have address-cells as <1>, >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 >> >> However each PCIe instance has 2 data regions and one of the regions >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified >> in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) >> is above the 32bit region and requires 2 cells to specify the start address. >> This region is used to access MEM_SPACE of PCIe endpoint when operating in root >> complex mode and access memory of PCI root complex when operating in endpoint mode. >> >> In order to describe this, should we change the address-cells back to <2> or do >> you suggest any other alternatives? > > It's probably best to have the top level cbass interconnect use > #size-cells = <2> and then have it's child interconnects have > #size-cells = <1> if they don't need ranges above 4GB. PCIe has a region starting at 0x40_00000000 and size 4GB. We need 2 address cells and 2 size cells to describe this no? > > BTW, what's the difference between all these three similar PCIE > ranges? > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005500000 0x0005600000 1 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005600000 0x0005700000 1 MB This is the register space for the two instances of PCIe controller. > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0010000000 0x0018000000 128 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0018000000 0x0020000000 128 MB > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4000000000 0x4100000000 4 GB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4100000000 0x4200000000 4 GB The above are regions which can be used by CPU/DMA to access the PCIe address space. The mapping from the above regions to the PCIe address space will be programmed in the PCIe controller. Thanks Kishon
Hi, On Tuesday 28 August 2018 06:52 AM, Nishanth Menon wrote: > On 15:55-20180827, Tony Lindgren wrote: >> * Kishon Vijay Abraham I <kishon@ti.com> [180827 03:06]: >>> Hi Tony, >>> >>> On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: >>>> * Kishon Vijay Abraham I <kishon@ti.com> [180808 06:35]: >>>>> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >>>>>> Really need 64-bit addresses and sizes? Use ranges to limit the >>>>>> address space if possible. >>>>> >>>>> We now have address-cells as <1>, >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 >>>>> >>>>> However each PCIe instance has 2 data regions and one of the regions >>>>> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified >>>>> in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) >>>>> is above the 32bit region and requires 2 cells to specify the start address. >>>>> This region is used to access MEM_SPACE of PCIe endpoint when operating in root >>>>> complex mode and access memory of PCI root complex when operating in endpoint mode. >>>>> >>>>> In order to describe this, should we change the address-cells back to <2> or do >>>>> you suggest any other alternatives? >>>> >>>> It's probably best to have the top level cbass interconnect use >>>> #size-cells = <2> and then have it's child interconnects have >>>> #size-cells = <1> if they don't need ranges above 4GB. >>> >>> PCIe has a region starting at 0x40_00000000 and size 4GB. We need 2 address >>> cells and 2 size cells to describe this no? >> >> Yes. >> >>>> BTW, what's the difference between all these three similar PCIE >>>> ranges? >>>> >>>> PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005500000 0x0005600000 1 MB >>>> PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005600000 0x0005700000 1 MB >>> >>> This is the register space for the two instances of PCIe controller. >>>> >>>> PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0010000000 0x0018000000 128 MB >>>> PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0018000000 0x0020000000 128 MB >>>> >>>> PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4000000000 0x4100000000 4 GB >>>> PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4100000000 0x4200000000 4 GB >>> >>> The above are regions which can be used by CPU/DMA to access the PCIe address >>> space. The mapping from the above regions to the PCIe address space will be >>> programmed in the PCIe controller. >> >> OK so not just somethng for dma-ranges but also accessible by >> the CPU. >> > > Kishon, Sekhar: > > Can you guys post patches based on v4.19-rc1 for fixing this? I do have > a bunch of dts nodes to build as well for v4.20, once Tony / Rob acks the > changes. Sure, I'll post that today. Thanks Kishon
diff --git a/MAINTAINERS b/MAINTAINERS index cfb35b252ac7..5f5c4eddec7a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/arm/ti/k3.txt +F: arch/arm64/boot/dts/ti/k3-* ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE M: Santosh Shilimkar <ssantosh@kernel.org> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi new file mode 100644 index 000000000000..cdfa12173aac --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi @@ -0,0 +1,144 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC Family + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/ { + model = "Texas Instruments K3 AM654 SoC"; + compatible = "ti,am654"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = &wkup_uart0; + serial1 = &mcu_uart0; + serial2 = &main_uart0; + serial3 = &main_uart1; + serial4 = &main_uart2; + }; + + chosen { }; + + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + + psci: psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + }; + + soc0: soc0 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + 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"; + /* Recommendation from GIC500 TRM Table A.3 */ + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; + }; + + gic: interrupt-controller@1800000 { + compatible = "arm,gic-v3"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + #interrupt-cells = <3>; + interrupt-controller; + /* + * NOTE: we are NOT gicv2 backward compat, so no GICC, + * GICH or GICV + */ + reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */ + <0x0 0x01880000 0x0 0x90000>; /* GICR */ + + /* + * vcpumntirq: + * virtual CPU interface maintenance interrupt + */ + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + + gic_its: gic-its@1000000 { + compatible = "arm,gic-v3-its"; + reg = <0x0 0x1820000 0x0 0x10000>; + msi-controller; + #msi-cells = <1>; + }; + }; + + wkup_uart0: serial@42300000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x42300000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + mcu_uart0: serial@40a00000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x40a00000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <96000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart0: serial@2800000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x02800000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart1: serial@2810000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x02810000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart2: serial@2820000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x02820000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + }; +}; diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi new file mode 100644 index 000000000000..d9b70081daba --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi @@ -0,0 +1,117 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC family in Quad core configuration + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include "k3-am6.dtsi" + +/ { + cpus: cpus { + #address-cells = <1>; + #size-cells = <0>; + cpu-map { + cluster0: cluster0 { + core0 { + cpu = <&cpu0>; + }; + + core1 { + cpu = <&cpu1>; + }; + }; + + cluster1: cluster1 { + core0 { + cpu = <&cpu2>; + }; + + core1 { + cpu = <&cpu3>; + }; + }; + }; + + cpu0: cpu@0 { + compatible = "arm,cortex-a53","arm,armv8"; + 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","arm,armv8"; + 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>; + }; + + cpu2: cpu@100 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x100>; + 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_1>; + }; + + cpu3: cpu@101 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x101>; + 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_1>; + }; + }; +}; + +&soc0 { + L2_0: l2-cache0 { + compatible = "cache"; + cache-level = <2>; + cache-size = <0x80000>; + cache-line-size = <64>; + cache-sets = <512>; + next-level-cache = <&msmc_l3>; + }; + + L2_1: l2-cache1 { + compatible = "cache"; + cache-level = <2>; + cache-size = <0x80000>; + cache-line-size = <64>; + cache-sets = <512>; + next-level-cache = <&msmc_l3>; + }; + + msmc_l3: l3-cache0 { + compatible = "cache"; + cache-level = <3>; + }; +}; diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index 92770d84a288..be4570baad96 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -1,3 +1,17 @@ +# 64-bit ARM SoCs from TI +if ARM64 + +if ARCH_K3 + +config ARCH_K3_AM6_SOC + bool "K3 AM6 SoC" + help + Enable support for TI's AM6 SoC Family support + +endif + +endif + # # TI SOC drivers #