| Message ID | 20180607233853.p7iw7nlxxuyi66og@kahuna (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, Some comments on the ranges below. * 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 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 :) 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. 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. Regards, Tony
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?
* Nishanth Menon <nm@ti.com> [180614 13:07]: > 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. It does not have a real reg or range. > > 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 That comment at the link above not true I've found. What we have there as "ocp" should be just "l3" and then the "l4" instances are children of "l3". The direct ports from some "l4" devices are just ranges at the parent "l3". And this will get changed slowly over next few merge cycles. > 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.. In the above example the connection from main to wkup is just a range provided by main so not a problem. > we can represent NAVSS as a bus segment as well. Well ideally each module on the interconnects would be set up separately to prevent drivers trying to ioremap ranges from multiple modules. This is important as flushing posted write to one module will not flush it for the other module. > > 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. There are other reasons beyond genpd too. Flushing posted writes to modules is one. Getting rid of pointless deferred probe is another one. Preventing device drivers trying to ioremap multiple module is yet another one.. > I think it is just how accurate a representation is it worth. The dts really is intended to describe the hardware :) So let's not repeat the same mistake again with imaginary ranges. > > > > 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 { > }; > }; > }; > }; Well if we follow the hardware representation of the interconnects, it should not matter from which processor view you're looking at things. There are just different ranges provided. > 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). Based on my experience yes. See also the reasons I listed above. > 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). Just model it based on the hardware, then there's no need to debate it or rework it later on :) Regards, Tony
Hi Tony, On Friday 15 June 2018 10:31 AM, Tony Lindgren wrote: > * Nishanth Menon <nm@ti.com> [180614 13:07]: >> On 12:38-20180614, Tony Lindgren wrote: >> 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 { >> }; >> }; >> }; >> }; > > Well if we follow the hardware representation of the interconnects, > it should not matter from which processor view you're looking at things. > There are just different ranges provided. AFAIK, the root node needs to have the CPU which is using the DT. So, the hierarchy will change based on CPU view (if we describe it fully). How well we can reuse individual interconnect segments is something I have to think about / experiment. Will have to be wary of any "short paths" or "cross connections". Thanks, Sekhar
* Sekhar Nori <nsekhar@ti.com> [180615 13:41]: > > How well we can reuse individual interconnect segments is something I > have to think about / experiment. Will have to be wary of any "short > paths" or "cross connections". These short paths and cross connections are almost certainly just additional ranges from the parent interconnect. See for example what we have in Linux next for wdt3 in omap4.dtsi for separate ranges for L4 and L3 interconnects. Regards, Tony
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..700c56eda12d --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi @@ -0,0 +1,172 @@ +// 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 = <&gic500>; + #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"; + }; + }; + + 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>; + }; + + soc0: soc0 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + main_domain: cbass@100000 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x00100000 0x00 0x00100000 0x00020000>, /* ctrl mmr */ + <0x00600000 0x00 0x00600000 0x00001100>, /* GPIO */ + <0x00900000 0x00 0x00900000 0x00012000>, /* serdes */ + <0x01000000 0x00 0x01000000 0x0AF02400>, /* Most peripherals */ + <0x30800000 0x00 0x30800000 0x0BC00000>; /* MAIN NAVSS */ + + gic500: interrupt-controller@1800000 { + compatible = "arm,gic-v3"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x01800000 0x10000>, /* GICD */ + <0x01880000 0x90000>; /* GICR */ + + /* + * vcpumntirq: + * virtual CPU interface maintenance interrupt + */ + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + + gic_its: gic-its@18200000 { + compatible = "arm,gic-v3-its"; + reg = <0x01820000 0x10000>; + msi-controller; + #msi-cells = <1>; + }; + }; + + main_uart0: serial@2800000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x02800000 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 = <0x02810000 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 = <0x02820000 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + }; + + wkup_domain: cbass@42040000 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x42040000 0x00 0x42040000 0x03AC2400>; /* Basic peripherals */ + + wkup_uart0: serial@42300000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x42300000 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_domain: cbass@28380000 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x28380000 0x00 0x28380000 0x03880000>, /* MCU NAVSS*/ + <0x40200000 0x00 0x40200000 0x00900100>, /* First peripheral window */ + <0x45100000 0x00 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */ + <0x46000000 0x00 0x46000000 0x00200000>, /* CPSW */ + <0x47000000 0x00 0x47000000 0x00068400>; /* OSPI space 1 */ + + mcu_uart0: serial@40a00000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x40a00000 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <96000000>; + 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..bffa414180ea --- /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 { + #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>; + }; +};