| Message ID | 1431537092-19597-3-git-send-email-Liviu.Dudau@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote: > Prepare the device tree for adding more boards based on Juno r0. > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> > --- > arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++ > arch/arm64/boot/dts/arm/juno.dts | 122 +------------------------------- What criteria were used to select the contents of juno-base.dtsi? From what I can see, the stuff left out of base is still the same for r0 and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be ------------------------------------------------------------------------- #include "juno.dts" / { model = "ARM Juno development board (r1)"; }; &memtimer { status = "okay"; }; ------------------------------------------------------------------------- Yes, it's a bit hacky, but avoids duplication of source code. I can only assume there are come non-public differences between r0 and r1?
On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote: > On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote: > > Prepare the device tree for adding more boards based on Juno r0. > > > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> > > --- > > arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++ > > arch/arm64/boot/dts/arm/juno.dts | 122 +------------------------------- > > > What criteria were used to select the contents of juno-base.dtsi? > From what I can see, the stuff left out of base is still the same for r0 > and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be > > ------------------------------------------------------------------------- > #include "juno.dts" > > / { > model = "ARM Juno development board (r1)"; > > }; > > &memtimer { > status = "okay"; > }; > ------------------------------------------------------------------------- > > Yes, it's a bit hacky, but avoids duplication of source code. > > I can only assume there are come non-public differences between r0 and > r1? Hi Tixy, There are potential differences. Cortex-A53 cluster in r1 has limited CPUfreq functionality due to a chip errata and there were talks internally to actually disable it, hence the reason for keeping CPUs outside the juno-base.dtsi. r2 will have a different set of big CPUs as well, so this is preparing for the future as well. PMU are linked to the CPUs, hence the reason they stayed. As for the memory and psci nodes the thinking behind it was mostly to allow for ACPI to make changes there, but it does look now like retrofitting an explanation to something that I did not give too much thought at that moment. Best regards, Liviu > > -- > Tixy >
On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote: > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote: [...] > > > > What criteria were used to select the contents of juno-base.dtsi? > > From what I can see, the stuff left out of base is still the same for r0 > > and r1 (cpu, pmu, memory, psci!). [...] > > There are potential differences. Cortex-A53 cluster in r1 has limited > CPUfreq functionality due to a chip errata and there were talks internally > to actually disable it, hence the reason for keeping CPUs outside the > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this > is preparing for the future as well. > > PMU are linked to the CPUs, hence the reason they stayed. As for the > memory and psci nodes the thinking behind it was mostly to allow for > ACPI to make changes there, but it does look now like retrofitting an > explanation to something that I did not give too much thought at that > moment. I guess my concern was motivated by the selfish aspect of having to maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq related DT updates) and having to duplicate those in more than one DT, and also having backport DT reorgs like this patch. Of course, none of that should be a consideration in deciding what goes into mainline, I just wanted to make sure there was a reason for the patch.
On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote: > On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote: > > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote: > [...] > > > > > > What criteria were used to select the contents of juno-base.dtsi? > > > From what I can see, the stuff left out of base is still the same for r0 > > > and r1 (cpu, pmu, memory, psci!). > [...] > > > > There are potential differences. Cortex-A53 cluster in r1 has limited > > CPUfreq functionality due to a chip errata and there were talks internally > > to actually disable it, hence the reason for keeping CPUs outside the > > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this > > is preparing for the future as well. > > > > PMU are linked to the CPUs, hence the reason they stayed. As for the > > memory and psci nodes the thinking behind it was mostly to allow for > > ACPI to make changes there, but it does look now like retrofitting an > > explanation to something that I did not give too much thought at that > > moment. > > I guess my concern was motivated by the selfish aspect of having to > maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq > related DT updates) and having to duplicate those in more than one DT, > and also having backport DT reorgs like this patch. Of course, none of > that should be a consideration in deciding what goes into mainline, I > just wanted to make sure there was a reason for the patch. You are probably the best placed engineer to offer feedback on these patches, as it will affect you in the downstream. Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and that HMP/EAS will not be working optimally on R1, do you still want to see the CPUs nodes moved into juno-base.dtsi? Best regards, Liviu > > -- > Tixy > >
On 14/05/15 12:04, Jon Medhurst (Tixy) wrote: > On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote: >> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote: > [...] >>> >>> What criteria were used to select the contents of juno-base.dtsi? >>> From what I can see, the stuff left out of base is still the same for r0 >>> and r1 (cpu, pmu, memory, psci!). > [...] >> >> There are potential differences. Cortex-A53 cluster in r1 has limited >> CPUfreq functionality due to a chip errata and there were talks internally >> to actually disable it, hence the reason for keeping CPUs outside the >> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this >> is preparing for the future as well. >> >> PMU are linked to the CPUs, hence the reason they stayed. As for the >> memory and psci nodes the thinking behind it was mostly to allow for >> ACPI to make changes there, but it does look now like retrofitting an >> explanation to something that I did not give too much thought at that >> moment. > > I guess my concern was motivated by the selfish aspect of having to > maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq Hopefully not too long :) > related DT updates) and having to duplicate those in more than one DT, > and also having backport DT reorgs like this patch. Of course, none of > that should be a consideration in deciding what goes into mainline, I > just wanted to make sure there was a reason for the patch. > But I agree with you to remove duplicates as much as possible. Since it's not possible to speculate how things will be in future platform, IMO we can have all the device nodes that are common to both r0 and r1 in juno-base.dtsi for now and move them out as and when required. Regards, Sudeep
On Thu, 2015-05-14 at 14:11 +0100, Liviu Dudau wrote: > On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote: > > On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote: > > > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote: > > [...] > > > > > > > > What criteria were used to select the contents of juno-base.dtsi? > > > > From what I can see, the stuff left out of base is still the same for r0 > > > > and r1 (cpu, pmu, memory, psci!). > > [...] > > > > > > There are potential differences. Cortex-A53 cluster in r1 has limited > > > CPUfreq functionality due to a chip errata and there were talks internally > > > to actually disable it, hence the reason for keeping CPUs outside the > > > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this > > > is preparing for the future as well. > > > > > > PMU are linked to the CPUs, hence the reason they stayed. As for the > > > memory and psci nodes the thinking behind it was mostly to allow for > > > ACPI to make changes there, but it does look now like retrofitting an > > > explanation to something that I did not give too much thought at that > > > moment. > > > > I guess my concern was motivated by the selfish aspect of having to > > maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq > > related DT updates) and having to duplicate those in more than one DT, > > and also having backport DT reorgs like this patch. Of course, none of > > that should be a consideration in deciding what goes into mainline, I > > just wanted to make sure there was a reason for the patch. > > You are probably the best placed engineer to offer feedback on these patches, > as it will affect you in the downstream. > > Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and > that HMP/EAS will not be working optimally on R1, do you still want to see > the CPUs nodes moved into juno-base.dtsi? Well, I can only answer that if I knew what the requirements were for the kernels I maintain, and as I'm unlikely to get any sensible answer, or one that doesn't change depending on the day of the week or the person I ask, then I think it probably best that we have the greatest flexibility and have the cpu-nodes in separate files as you plan. I can always carry a patch to make juno-r1.dts #include juno.dts if that makes my life easier ;-) Hopefully the cpufreq and cpuidle stuff will find it way into mainline in a kernel version or two anyway.
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi new file mode 100644 index 0000000..2faa68a --- /dev/null +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi @@ -0,0 +1,125 @@ + /* + * Devices shared by all Juno boards + */ + + gic: interrupt-controller@2c010000 { + compatible = "arm,gic-400", "arm,cortex-a15-gic"; + reg = <0x0 0x2c010000 0 0x1000>, + <0x0 0x2c02f000 0 0x2000>, + <0x0 0x2c04f000 0 0x2000>, + <0x0 0x2c06f000 0 0x2000>; + #address-cells = <0>; + #interrupt-cells = <3>; + interrupt-controller; + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>; + }; + + /include/ "juno-clocks.dtsi" + + dma@7ff00000 { + compatible = "arm,pl330", "arm,primecell"; + reg = <0x0 0x7ff00000 0 0x1000>; + #dma-cells = <1>; + #dma-channels = <8>; + #dma-requests = <32>; + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&soc_faxiclk>; + clock-names = "apb_pclk"; + }; + + soc_uart0: uart@7ff80000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0x7ff80000 0x0 0x1000>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&soc_uartclk>, <&soc_refclk100mhz>; + clock-names = "uartclk", "apb_pclk"; + }; + + i2c@7ffa0000 { + compatible = "snps,designware-i2c"; + reg = <0x0 0x7ffa0000 0x0 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <400000>; + i2c-sda-hold-time-ns = <500>; + clocks = <&soc_smc50mhz>; + + dvi0: dvi-transmitter@70 { + compatible = "nxp,tda998x"; + reg = <0x70>; + }; + + dvi1: dvi-transmitter@71 { + compatible = "nxp,tda998x"; + reg = <0x71>; + }; + }; + + ohci@7ffb0000 { + compatible = "generic-ohci"; + reg = <0x0 0x7ffb0000 0x0 0x10000>; + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&soc_usb48mhz>; + }; + + ehci@7ffc0000 { + compatible = "generic-ehci"; + reg = <0x0 0x7ffc0000 0x0 0x10000>; + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&soc_usb48mhz>; + }; + + memory-controller@7ffd0000 { + compatible = "arm,pl354", "arm,primecell"; + reg = <0 0x7ffd0000 0 0x1000>; + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&soc_smc50mhz>; + clock-names = "apb_pclk"; + }; + + smb { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0 0x08000000 0x04000000>, + <1 0 0 0x14000000 0x04000000>, + <2 0 0 0x18000000 0x04000000>, + <3 0 0 0x1c000000 0x04000000>, + <4 0 0 0x0c000000 0x04000000>, + <5 0 0 0x10000000 0x04000000>; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 15>; + interrupt-map = <0 0 0 &gic 0 68 IRQ_TYPE_LEVEL_HIGH>, + <0 0 1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>, + <0 0 2 &gic 0 70 IRQ_TYPE_LEVEL_HIGH>, + <0 0 3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>, + <0 0 4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>, + <0 0 5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>, + <0 0 6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>, + <0 0 7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>, + <0 0 8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>, + <0 0 9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>, + <0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>, + <0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>, + <0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>; + + /include/ "juno-motherboard.dtsi" + }; diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts index 7ab0713..60e8928 100644 --- a/arch/arm64/boot/dts/arm/juno.dts +++ b/arch/arm64/boot/dts/arm/juno.dts @@ -98,26 +98,6 @@ <0x00000008 0x80000000 0x1 0x80000000>; }; - gic: interrupt-controller@2c010000 { - compatible = "arm,gic-400", "arm,cortex-a15-gic"; - reg = <0x0 0x2c010000 0 0x1000>, - <0x0 0x2c02f000 0 0x2000>, - <0x0 0x2c04f000 0 0x2000>, - <0x0 0x2c06f000 0 0x2000>; - #address-cells = <0>; - #interrupt-cells = <3>; - interrupt-controller; - interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>; - }; - - timer { - compatible = "arm,armv8-timer"; - interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, - <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, - <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, - <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>; - }; - pmu { compatible = "arm,armv8-pmuv3"; interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>, @@ -134,105 +114,5 @@ <&A53_3>; }; - /include/ "juno-clocks.dtsi" - - dma@7ff00000 { - compatible = "arm,pl330", "arm,primecell"; - reg = <0x0 0x7ff00000 0 0x1000>; - #dma-cells = <1>; - #dma-channels = <8>; - #dma-requests = <32>; - interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&soc_faxiclk>; - clock-names = "apb_pclk"; - }; - - soc_uart0: uart@7ff80000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x0 0x7ff80000 0x0 0x1000>; - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&soc_uartclk>, <&soc_refclk100mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - i2c@7ffa0000 { - compatible = "snps,designware-i2c"; - reg = <0x0 0x7ffa0000 0x0 0x1000>; - #address-cells = <1>; - #size-cells = <0>; - interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>; - clock-frequency = <400000>; - i2c-sda-hold-time-ns = <500>; - clocks = <&soc_smc50mhz>; - - dvi0: dvi-transmitter@70 { - compatible = "nxp,tda998x"; - reg = <0x70>; - }; - - dvi1: dvi-transmitter@71 { - compatible = "nxp,tda998x"; - reg = <0x71>; - }; - }; - - ohci@7ffb0000 { - compatible = "generic-ohci"; - reg = <0x0 0x7ffb0000 0x0 0x10000>; - interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&soc_usb48mhz>; - }; - - ehci@7ffc0000 { - compatible = "generic-ehci"; - reg = <0x0 0x7ffc0000 0x0 0x10000>; - interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&soc_usb48mhz>; - }; - - memory-controller@7ffd0000 { - compatible = "arm,pl354", "arm,primecell"; - reg = <0 0x7ffd0000 0 0x1000>; - interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&soc_smc50mhz>; - clock-names = "apb_pclk"; - }; - - smb { - compatible = "simple-bus"; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0 0 0 0x08000000 0x04000000>, - <1 0 0 0x14000000 0x04000000>, - <2 0 0 0x18000000 0x04000000>, - <3 0 0 0x1c000000 0x04000000>, - <4 0 0 0x0c000000 0x04000000>, - <5 0 0 0x10000000 0x04000000>; - - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 15>; - interrupt-map = <0 0 0 &gic 0 68 IRQ_TYPE_LEVEL_HIGH>, - <0 0 1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>, - <0 0 2 &gic 0 70 IRQ_TYPE_LEVEL_HIGH>, - <0 0 3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>, - <0 0 4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>, - <0 0 5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>, - <0 0 6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>, - <0 0 7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>, - <0 0 8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>, - <0 0 9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>, - <0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>, - <0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>, - <0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>; - - /include/ "juno-motherboard.dtsi" - }; + #include "juno-base.dtsi" };
Prepare the device tree for adding more boards based on Juno r0. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> --- arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++ arch/arm64/boot/dts/arm/juno.dts | 122 +------------------------------- 2 files changed, 126 insertions(+), 121 deletions(-) create mode 100644 arch/arm64/boot/dts/arm/juno-base.dtsi