ARM: shmobile: r8a7740/sh73a0 DT Cache Handling
Subsystems (5)
Geert Uytterhoeven
maintainerv4 cover ARM: shmobile: r8a7740/sh73a0 DT Cache Handling
Hi Simon, Magnus,
This patch series add L1 and L2 cache descriptions to DT for r8a7740 and sh73a0, and migrates the shmobile DT-based generic r8a7740 and armadillo legacy platforms from calling l2x0_of_init() to the generic l2c OF initialization.
Note that the conversion to the generic l2c OF initialization is not done yet for sh73a0, as this initializes the L2 cache earlier, breaking the (fragile) sh73a0 secondary CPU bringup code.
Also note that this conversion should be done on r8a7778, and r8a7779, too.
Changes compared to v3 ("[PATCH v3 0/6] ARM: l2c / shmobile: r8a7740 : Shared Override",
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/340636.html):
- "l2c: Add support for the "arm,shared-override" property" was split off into an independent patch, and is now queued for v4.3 in arm/for-next,
- Dropped armadillo legacy migration, as it no longer exists,
- Added sh73a0 L1 and L2 DT cache description.
Changes compared to v2 ("[PATCH v2 0/5] ARM: shmobile: r8a7740/armadillo:
Migrate to generic l2c OF",
http://www.spinics.net/lists/devicetree/msg68176.html):
- Add DT support for Shared Override,
- Setting Shared Override is done only if CMA is not available (as Russell claims it's not needed if CMA is available),
- Use 0/~0 in machine_desc.l2c_aux_{val,mask}, as DT now supports "arm,shared-override".
Changes compared to v1:
- Fix interrupt reference in DT,
- Describe L2 better in DT,
- Keep only {,~}L2C_AUX_CTRL_SHARED_OVERRIDE in machine_desc.l2c_aux_{val,mask}, as there's no DT property for this.
- Add L1 cache to DT.
Dependencies:
- This series applies to renesas-devel-20150805-v4.2-rc5,
- Patch 2 depends on patch 1,
- Patch 4 depends on patch 2,
- Patch 5 depends on patch 1 and on "ARM: 8395/1: l2c: Add support for the "arm,shared-override" property" in arm/for-next,
- Patch 6 depends on patch 5.
Given C code patches depending on DT patches in the same branch are frowned upon, I think it would be best if patch 1 (and patch 3, if anyone thinks we may fix the secondary CPU bringup issue during the next 3 months) are queued for v4.3. The other patches can be queued for 2016^H^H^H^Hv4.4.
I've been running this on r8a7740/armadillo and sh73a0/kzm9g during the past 9 months.
Thanks!
Geert Uytterhoeven (6):
ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
ARM: shmobile: r8a7740 dtsi: Add L1 cache information to CPU node
ARM: shmobile: sh73a0 dtsi: Add L2 cache-controller node
ARM: shmobile: sh73a0 dtsi: Add L1 cache information to CPU nodes
ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
ARM: shmobile: r8a7740: Remove mapping of L2 cache controller
registers
arch/arm/boot/dts/r8a7740.dtsi | 25 +++++++++++++++++++++++++ arch/arm/boot/dts/sh73a0.dtsi | 34 ++++++++++++++++++++++++++++++++++ arch/arm/mach-shmobile/setup-r8a7740.c | 18 ++---------------- 3 files changed, 61 insertions(+), 16 deletions(-)
Signature · 12 lines
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus TorvaldsGeert Uytterhoeven
maintainerPATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Add the missing L2 cache-controller node. This will allow migration to the generic l2c OF initialization.
The L2 cache is an ARM L2C-310 (r3p1-150rel0), of size 256 KiB (32 KiB x 8 ways).
---
v4:
- Commit eeedcea69e927857 ("ARM: 8395/1: l2c: Add support for the "arm,shared-override" property") is queued for 4.3 in arm/for-next,
v3:
- Add "arm,shared-override",
v2:
- Fix interrupt (should be 3 cells, not 1),
- Describe cache better.
--- arch/arm/boot/dts/r8a7740.dtsi | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
arch/arm/boot/dts/r8a7740.dtsi +16 -0
@@ -37,6 +37,22 @@ <0xc2000000 0x1000>; }; + L2: cache-controller { + compatible = "arm,pl310-cache"; + reg = <0xf0100000 0x1000>; + interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_a3sm>; + arm,data-latency = <3 3 3>; + arm,tag-latency = <2 2 2>; + arm,shared-override; + cache-unified; + cache-level = <2>; + cache-size = <0x40000>; + cache-sets = <1024>; + cache-block-size = <32>; + cache-line-size = <32>; + }; + dbsc3: memory-controller at fe400000 { compatible = "renesas,dbsc3-r8a7740"; reg = <0xfe400000 0x400>;
Signature · 1 line
1.9.1
PATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Quoted 34 lines · Geert Uytterhoeven
Add the missing L2 cache-controller node. This will allow migration to the generic l2c OF initialization.
The L2 cache is an ARM L2C-310 (r3p1-150rel0), of size 256 KiB (32 KiB x 8 ways).
Signed-off-by Geert Uytterhoeven <[email protected]>---
v4:
- Commiteeedcea69e927857("ARM: 8395/1: l2c: Add support for the "arm,shared-override" property") is queued for 4.3 in arm/for-next,v3:
- Add "arm,shared-override",v2:
- Fix interrupt (should be 3 cells, not 1),
- Describe cache better.--- arch/arm/boot/dts/r8a7740.dtsi | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)arch/arm/boot/dts/r8a7740.dtsi +4
-0@@ -37,6 +37,22 @@ <0xc2000000 0x1000>; }; + L2: cache-controller { + compatible = "arm,pl310-cache"; + reg = <0xf0100000 0x1000>; + interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>;
arch/arm/boot/dts/r8a7740.dtsi line 53
Quoted 10 lines
arch/arm/boot/dts/r8a7740.dtsi +10
-0+ power-domains = <&pd_a3sm>; + arm,data-latency = <3 3 3>; + arm,tag-latency = <2 2 2>; + arm,shared-override; + cache-unified; + cache-level = <2>; + cache-size = <0x40000>; + cache-sets = <1024>; + cache-block-size = <32>; + cache-line-size = <32>;
Any particular reason whey you need all this cache-* properties ? Is something broken on these SoCs ? We should be able to get most of these information from the SoC(reading some registers). It's good to avoid passing them via DT if they can be discovered from hardware.
Regards,
Sudeep
PATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Hi Sudeep,
Quoted 27 lines · Sudeep Holla
Quoted 26 lines · Geert Uytterhoeven
Add the missing L2 cache-controller node. This will allow migration to the generic l2c OF initialization.
The L2 cache is an ARM L2C-310 (r3p1-150rel0), of size 256 KiB (32 KiB x 8 ways).
Signed-off-by Geert Uytterhoeven <[email protected]>arch/arm/boot/dts/r8a7740.dtsi +9
-0@@ -37,6 +37,22 @@ <0xc2000000 0x1000>; }; + L2: cache-controller { + compatible = "arm,pl310-cache"; + reg = <0xf0100000 0x1000>; + interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_a3sm>; + arm,data-latency = <3 3 3>; + arm,tag-latency = <2 2 2>; + arm,shared-override; + cache-unified;
Quoted 8 lines
arch/arm/boot/dts/r8a7740.dtsi line 53
Quoted 5 lines
arch/arm/boot/dts/r8a7740.dtsi +5
-0+ cache-level = <2>; + cache-size = <0x40000>; + cache-sets = <1024>; + cache-block-size = <32>; + cache-line-size = <32>;Any particular reason whey you need all this cache-* properties ? Is
To describe the cache as good as possible.
Quoted 3 lines
something broken on these SoCs ? We should be able to get most of these information from the SoC(reading some registers). It's good to avoid passing them via DT if they can be discovered from hardware.
So we have all these documented properties in Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to be used?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
PATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Hi Geert,
Quoted 39 lines · Geert Uytterhoeven
Hi Sudeep,
Quoted 27 lines · Sudeep Holla
Quoted 26 lines · Geert Uytterhoeven
Add the missing L2 cache-controller node. This will allow migration to the generic l2c OF initialization.
The L2 cache is an ARM L2C-310 (r3p1-150rel0), of size 256 KiB (32 KiB x 8 ways).
Signed-off-by Geert Uytterhoeven <[email protected]>arch/arm/boot/dts/r8a7740.dtsi +9
-0@@ -37,6 +37,22 @@ <0xc2000000 0x1000>; }; + L2: cache-controller { + compatible = "arm,pl310-cache"; + reg = <0xf0100000 0x1000>; + interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_a3sm>; + arm,data-latency = <3 3 3>; + arm,tag-latency = <2 2 2>; + arm,shared-override; + cache-unified;Quoted 8 lines
arch/arm/boot/dts/r8a7740.dtsi line 53
Quoted 5 lines
arch/arm/boot/dts/r8a7740.dtsi +5
-0+ cache-level = <2>; + cache-size = <0x40000>; + cache-sets = <1024>; + cache-block-size = <32>; + cache-line-size = <32>;Any particular reason whey you need all this cache-* properties ? Is
Quoted 2 lines
To describe the cache as good as possible.
Why if you can probe it ? IMO DT is mostly useful to describe things that can't be probed/discovered using hardware.
Quoted 8 lines
Quoted 3 lines
something broken on these SoCs ? We should be able to get most of these information from the SoC(reading some registers). It's good to avoid passing them via DT if they can be discovered from hardware.
So we have all these documented properties in
Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to be used?
No I didn't mean that, I just wanted to know if they can't be probed due to some hardware issue. It would avoid issues with wrong DTs especially if they are not so easy to upgrade.
Regards,
Sudeep
PATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Hi Sudeep,
Quoted 48 lines · Sudeep Holla
Quoted 38 lines · Geert Uytterhoeven
Quoted 19 lines · Sudeep Holla
Quoted 18 lines · Geert Uytterhoeven
Add the missing L2 cache-controller node. This will allow migration to the generic l2c OF initialization.
The L2 cache is an ARM L2C-310 (r3p1-150rel0), of size 256 KiB (32 KiB x 8 ways).
Signed-off-by Geert Uytterhoeven <[email protected]>arch/arm/boot/dts/r8a7740.dtsi +0
-0@@ -37,6 +37,22 @@ <0xc2000000 0x1000>; };Quoted 16 lines
Quoted 4 lines
arch/arm/boot/dts/r8a7740.dtsi +4
-0+ L2: cache-controller { + compatible = "arm,pl310-cache"; + reg = <0xf0100000 0x1000>; + interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>;arch/arm/boot/dts/r8a7740.dtsi line 53
Quoted 10 lines
arch/arm/boot/dts/r8a7740.dtsi +10
-0+ power-domains = <&pd_a3sm>; + arm,data-latency = <3 3 3>; + arm,tag-latency = <2 2 2>; + arm,shared-override; + cache-unified; + cache-level = <2>; + cache-size = <0x40000>; + cache-sets = <1024>; + cache-block-size = <32>; + cache-line-size = <32>;Any particular reason whey you need all this cache-* properties ? Is
Quoted 1 line
To describe the cache as good as possible.
Why if you can probe it ? IMO DT is mostly useful to describe things that can't be probed/discovered using hardware.
Quoted 4 lines
Quoted 3 lines
something broken on these SoCs ? We should be able to get most of these information from the SoC(reading some registers). It's good to avoid passing them via DT if they can be discovered from hardware.
Quoted 7 lines
Quoted 3 lines
So we have all these documented properties in
Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to be used?No I didn't mean that, I just wanted to know if they can't be probed due to some hardware issue. It would avoid issues with wrong DTs especially if they are not so easy to upgrade.
I think it works just fine without them.
Should I drop all cache-* properties marked optional in Documentation/devicetree/bindings/arm/l2cc.txt?
That would be cache-size, cache-sets, cache-block-size, and cache-line-size.
What about the L1 cache? I know Linux uses none of the d-cache-* and i-cache-* properties.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
PATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Quoted 6 lines · Geert Uytterhoeven
Hi Sudeep,
Quoted 3 lines · Sudeep Holla
Quoted 2 lines · Geert Uytterhoeven
On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <[email protected]> wrote:
[..]
Quoted 16 lines
Quoted 16 lines
Quoted 4 lines
Quoted 2 lines
Any particular reason whey you need all this cache-* properties ? Is
To describe the cache as good as possible.
Why if you can probe it ? IMO DT is mostly useful to describe things that can't be probed/discovered using hardware.
Quoted 7 lines
Quoted 3 lines
something broken on these SoCs ? We should be able to get most of these information from the SoC(reading some registers). It's good to avoid passing them via DT if they can be discovered from hardware.
So we have all these documented properties in
Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to be used?
Quoted 6 lines
Quoted 3 lines
No I didn't mean that, I just wanted to know if they can't be probed due to some hardware issue. It would avoid issues with wrong DTs especially if they are not so easy to upgrade.
I think it works just fine without them.
Yes, in general if you specify a value in DT that can be probed, its usually to override the probed value(useful if there is some h/w errata)...
Quoted 4 lines
Should I drop all cache-* properties marked optional in
Documentation/devicetree/bindings/arm/l2cc.txt?
That would be cache-size, cache-sets, cache-block-size, and cache-line-size.
... however if you incorrect values by mistake, then it's problematic even if h/w provides correct value.
Quoted 3 lines
What about the L1 cache? I know Linux uses none of the d-cache-* and i-cache-* properties.
Same there, IIRC PPC use them, but on ARM I think so far the need has not arise.
Just to re-iterate myself, I am not against adding them, but it's not really needed. I just wanted to know if there was any h/w issue.
Regards,
Sudeep
PATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Hi Sudeep,
[reviving this old thread, now we're two merge windows further]
Quoted 42 lines · Sudeep Holla
Quoted 5 lines · Geert Uytterhoeven
Quoted 3 lines · Sudeep Holla
Quoted 2 lines · Geert Uytterhoeven
On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <[email protected]> wrote:
[..]
Quoted 15 lines
Quoted 15 lines
Quoted 3 lines
Quoted 1 line
Any particular reason whey you need all this cache-* properties ? Is
To describe the cache as good as possible.
Why if you can probe it ? IMO DT is mostly useful to describe things that can't be probed/discovered using hardware.
Quoted 7 lines
Quoted 3 lines
something broken on these SoCs ? We should be able to get most of these information from the SoC(reading some registers). It's good to avoid passing them via DT if they can be discovered from hardware.
So we have all these documented properties in
Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to be used?Quoted 5 lines
Quoted 3 lines
No I didn't mean that, I just wanted to know if they can't be probed due to some hardware issue. It would avoid issues with wrong DTs especially if they are not so easy to upgrade.
I think it works just fine without them.
Yes, in general if you specify a value in DT that can be probed, its usually to override the probed value(useful if there is some h/w errata)...
Quoted 4 lines
Should I drop all cache-* properties marked optional in
Documentation/devicetree/bindings/arm/l2cc.txt? That would be cache-size, cache-sets, cache-block-size, and cache-line-size.... however if you incorrect values by mistake, then it's problematic even if h/w provides correct value.
Quoted 8 lines
Quoted 2 lines
What about the L1 cache? I know Linux uses none of the d-cache-* and i-cache-* properties.
Same there, IIRC PPC use them, but on ARM I think so far the need has not arise.
Just to re-iterate myself, I am not against adding them, but it's not really needed. I just wanted to know if there was any h/w issue.
AFAIK, there's nothing to be overridden. The cache seems to be configured in the exact same way with and without cache-size, cache-sets, cache-block-size, and cache-line-size.
With:
L2C OF: override cache size: 262144 bytes (256KB)
L2C OF: override line size: 32 bytes
L2C OF: override way size: 32768 bytes (32KB)
L2C OF: override associativity: 8
L2C: DT/platform modifies aux control register: 0x02040000 -> 0x02440000
L2C: DT/platform tries to modify or specify cache size L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 dynamic clock gating enabled, standby mode enabled L2C-310 cache controller enabled, 8 ways, 256 kB
L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x46440001
Without:
L2C: DT/platform modifies aux control register: 0x02040000 -> 0x02440000 L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 dynamic clock gating enabled, standby mode enabled L2C-310 cache controller enabled, 8 ways, 256 kB
L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x46440001
Hence I'll drop cache-size, cache-sets, cache-block-size, and cache-line-size, for both unified L2 and L1 I/D caches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
PATCH v4 1/6 ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Quoted 2 lines · Geert Uytterhoeven
Hi Sudeep,
[...]
Quoted 29 lines
AFAIK, there's nothing to be overridden. The cache seems to be configured in the exact same way with and without cache-size, cache-sets, cache-block-size, and cache-line-size.
With:
L2C OF: override cache size: 262144 bytes (256KB)
L2C OF: override line size: 32 bytes
L2C OF: override way size: 32768 bytes (32KB)
L2C OF: override associativity: 8
L2C: DT/platform modifies aux control register:0x02040000->0x02440000
L2C: DT/platform tries to modify or specify cache size L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 dynamic clock gating enabled, standby mode enabled L2C-310 cache controller enabled, 8 ways, 256 kB
L2C-310:CACHE_ID0x410000c7,AUX_CTRL0x46440001Without:
L2C: DT/platform modifies aux control register:
0x02040000->0x02440000L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 dynamic clock gating enabled, standby mode enabled L2C-310 cache controller enabled, 8 ways, 256 kB
L2C-310:CACHE_ID0x410000c7,AUX_CTRL0x46440001
Quoted 3 lines
Hence I'll drop cache-size, cache-sets, cache-block-size, and cache-line-size, for both unified L2 and L1 I/D caches.
Sorry for the delay, was on vacation. Looks fine for me.
Signature · 2 lines
Regards, Sudeep
Geert Uytterhoeven
maintainerPATCH v4 2/6 ARM: shmobile: r8a7740 dtsi: Add L1 cache information to CPU node
In reply to Geert UytterhoevenDescribe the L1 cache in the CPU node:
- L1 instruction cache: 32 KiB (8 KiB x 4 ways),
- L1 data cache: 32 KiB (8 KiB x 4 ways).
Add a link to the L2 cache.
---
v4:
- No changes,
v3:
- No changes,
v2:
- New.
--- arch/arm/boot/dts/r8a7740.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/arm/boot/dts/r8a7740.dtsi +9 -0
@@ -26,6 +26,15 @@ reg = <0x0>; clock-frequency = <800000000>; power-domains = <&pd_a3sm>; + i-cache-size = <0x8000>; + i-cache-sets = <256>; + i-cache-block-size = <32>; + i-cache-line-size = <32>; + d-cache-size = <0x8000>; + d-cache-sets = <256>; + d-cache-block-size = <32>; + d-cache-line-size = <32>; + next-level-cache = <&L2>; }; };
Signature · 1 line
1.9.1
Geert Uytterhoeven
maintainerPATCH v4 3/6 ARM: shmobile: sh73a0 dtsi: Add L2 cache-controller node
In reply to Geert UytterhoevenAdd the missing L2 cache-controller node. This will allow migration to the generic l2c OF initialization.
The L2 cache is an ARM L2C-310 (r3p1), of size 512 KiB (64 KiB x 8 ways).
---
v4:
- New,
- Commit eeedcea69e927857 ("ARM: 8395/1: l2c: Add support for the "arm,shared-override" property") is queued for 4.3 in arm/for-next.
--- arch/arm/boot/dts/sh73a0.dtsi | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
arch/arm/boot/dts/sh73a0.dtsi +16 -0
@@ -53,6 +53,22 @@ <0xf0000100 0x100>; }; + L2: cache-controller { + compatible = "arm,pl310-cache"; + reg = <0xf0100000 0x1000>; + interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_a3sm>; + arm,data-latency = <3 3 3>; + arm,tag-latency = <2 2 2>; + arm,shared-override; + cache-unified; + cache-level = <2>; + cache-size = <0x80000>; + cache-sets = <2048>; + cache-block-size = <32>; + cache-line-size = <32>; + }; + sbsc2: memory-controller at fb400000 { compatible = "renesas,sbsc-sh73a0"; reg = <0xfb400000 0x400>;
Signature · 1 line
1.9.1
Geert Uytterhoeven
maintainerPATCH v4 4/6 ARM: shmobile: sh73a0 dtsi: Add L1 cache information to CPU nodes
In reply to Geert UytterhoevenDescribe the L1 caches in the CPU nodes:
- L1 instruction cache: 32 KiB (8 KiB x 4 ways) per CPU,
- L1 data cache: 32 KiB (8 KiB x 4 ways) per CPU.
Add links to the L2 cache.
---
v4:
- New.
--- arch/arm/boot/dts/sh73a0.dtsi | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
arch/arm/boot/dts/sh73a0.dtsi +18 -0
@@ -28,6 +28,15 @@ reg = <0>; clock-frequency = <1196000000>; power-domains = <&pd_a2sl>; + i-cache-size = <0x8000>; + i-cache-sets = <256>; + i-cache-block-size = <32>; + i-cache-line-size = <32>; + d-cache-size = <0x8000>; + d-cache-sets = <256>; + d-cache-block-size = <32>; + d-cache-line-size = <32>; + next-level-cache = <&L2>; }; cpu at 1 { device_type = "cpu";
@@ -35,6 +44,15 @@ reg = <1>; clock-frequency = <1196000000>; power-domains = <&pd_a2sl>; + i-cache-size = <0x8000>; + i-cache-sets = <256>; + i-cache-block-size = <32>; + i-cache-line-size = <32>; + d-cache-size = <0x8000>; + d-cache-sets = <256>; + d-cache-block-size = <32>; + d-cache-line-size = <32>; + next-level-cache = <&L2>; }; };
Signature · 1 line
1.9.1
Geert Uytterhoeven
maintainerPATCH v4 5/6 ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
In reply to Geert UytterhoevenMigrate the generic r8a7740 platform from calling l2x0_of_init() to the generic l2c OF initialization.
---
v4:
- This depends on commit eeedcea69e927857 ("ARM: 8395/1: l2c: Add support for the "arm,shared-override" property"), which is queued for 4.3 in arm/for-next,
v3:
- Use 0/~0 now DT supports "arm,shared-override",
v2:
- Keep only {,~}L2C_AUX_CTRL_SHARED_OVERRIDE.
--- arch/arm/mach-shmobile/setup-r8a7740.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
arch/arm/mach-shmobile/setup-r8a7740.c +2 -4
@@ -110,10 +110,6 @@ static void __init r8a7740_generic_init(void) {r8a7740_meram_workaround (); -#ifdef CONFIG_CACHE_L2X0 -/* Shared attribute override enable, 32K*8way */ -l2x0_init (IOMEM (0xf0002000 ),0x00400000 ,0xc20f0fff ); -#endif of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); }
@@ -123,6 +119,8 @@ static const char *const r8a7740_boards_compat_dt[] __initconst = { };DT_MACHINE_START (R8A7740_DT ,"Generic R8A7740 (Flattened Device Tree)" ) + .l2c_aux_val = 0, + .l2c_aux_mask = ~0, .map_io = r8a7740_map_io, .init_early = shmobile_init_delay, .init_irq = r8a7740_init_irq_of,
Signature · 1 line
1.9.1
Geert Uytterhoeven
maintainerPATCH v4 6/6 ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
In reply to Geert UytterhoevenNow all r8a7740-based platforms have been migrated to the generic l2c OF initialization, it's no longer needed to map the L2 cache controller registers from .map_io().
---
v4:
- No changes,
v3:
- No changes,
v2:
- No changes.
--- arch/arm/mach-shmobile/setup-r8a7740.c | 12 ------------ 1 file changed, 12 deletions(-)
arch/arm/mach-shmobile/setup-r8a7740.c +0 -12
@@ -38,18 +38,6 @@ static struct map_desc r8a7740_io_desc[] __initdata = { .length = 160 << 20, .type =MT_DEVICE_NONSHARED }, -#ifdef CONFIG_CACHE_L2X0 -/* -* for l2x0_init() -* 0xf0100000-0xf0101000 -> 0xf0002000-0xf0003000 -*/ - { - .virtual = 0xf0002000, - .pfn = __phys_to_pfn(0xf0100000), - .length = PAGE_SIZE, - .type = MT_DEVICE_NONSHARED - }, -#endif };static void __init r8a7740_map_io (void )
Signature · 1 line
1.9.1
v4 cover ARM: shmobile: r8a7740/sh73a0 DT Cache Handling
In reply to Geert UytterhoevenHi Geert,
Quoted 48 lines · Geert Uytterhoeven
Hi Simon, Magnus,
This patch series add L1 and L2 cache descriptions to DT for r8a7740 and sh73a0, and migrates the shmobile DT-based generic r8a7740 and armadillo legacy platforms from calling
l2x0_of_init()to the generic l2c OF initialization.Note that the conversion to the generic l2c OF initialization is not done yet for sh73a0, as this initializes the L2 cache earlier, breaking the (fragile) sh73a0 secondary CPU bringup code.
Also note that this conversion should be done on r8a7778, and r8a7779, too.
Changes compared to v3 ("[PATCH v3 0/6] ARM: l2c / shmobile: r8a7740 : Shared Override",
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/340636.html):
- "l2c: Add support for the "arm,shared-override" property" was split off into an independent patch, and is now queued for v4.3 in arm/for-next,
- Dropped armadillo legacy migration, as it no longer exists,
- Added sh73a0 L1 and L2 DT cache description.Changes compared to v2 ("[PATCH v2 0/5] ARM: shmobile: r8a7740/armadillo:
Migrate to generic l2c OF",
http://www.spinics.net/lists/devicetree/msg68176.html):
- Add DT support for Shared Override,
- Setting Shared Override is done only if CMA is not available (as Russell claims it's not needed if CMA is available),
- Use 0/~0 in machine_desc.l2c_aux_{val,mask}, as DT now supports "arm,shared-override".Changes compared to v1:
- Fix interrupt reference in DT,
- Describe L2 better in DT,
- Keep only {,~}L2C_AUX_CTRL_SHARED_OVERRIDE in machine_desc.l2c_aux_{val,mask}, as there's no DT property for this.
- Add L1 cache to DT.Dependencies:
- This series applies to renesas-devel-20150805-v4.2-rc5,
- Patch 2 depends on patch 1,
- Patch 4 depends on patch 2,
- Patch 5 depends on patch 1 and on "ARM: 8395/1: l2c: Add support for the "arm,shared-override" property" in arm/for-next,
- Patch 6 depends on patch 5.
Quoted 5 lines
Given C code patches depending on DT patches in the same branch are frowned upon, I think it would be best if patch 1 (and patch 3, if anyone thinks we may fix the secondary CPU bringup issue during the next 3 months) are queued for v4.3. The other patches can be queued for 2016^H^H^H^Hv4.4.
Sorry for surprising you with that merge-order requirement.
Unfortunately I am not comfortable with taking patch 1 for v4.3 because:
1. Its now very late in the cycle
2. There now seems to be some discussion around it.
I think I am happy to take the other patches for v4.4, now. But perhaps I should wait for the discussion around patch 1 to conclude first?
v4 cover ARM: shmobile: r8a7740/sh73a0 DT Cache Handling
Quoted 10 lines · Simon Horman
Quoted 9 lines · Geert Uytterhoeven
This patch series add L1 and L2 cache descriptions to DT for r8a7740 and sh73a0, and migrates the shmobile DT-based generic r8a7740 and armadillo legacy platforms from calling
l2x0_of_init()to the generic l2c OF initialization.Dependencies:
- This series applies to renesas-devel-20150805-v4.2-rc5,
- Patch 2 depends on patch 1,
- Patch 4 depends on patch 2,
Sorry, "... on patch 3".
Quoted 11 lines
Quoted 9 lines
- Patch 5 depends on patch 1 and on "ARM: 8395/1: l2c: Add support for the "arm,shared-override" property" in arm/for-next,
- Patch 6 depends on patch 5.Given C code patches depending on DT patches in the same branch are frowned upon, I think it would be best if patch 1 (and patch 3, if anyone thinks we may fix the secondary CPU bringup issue during the next 3 months) are queued for v4.3. The other patches can be queued for 2016^H^H^H^Hv4.4.
Sorry for surprising you with that merge-order requirement.
In theory it sounds fine, as DT and code are independent. Moving functionality from C to DT is something different...
Quoted 2 lines
Unfortunately I am not comfortable with taking patch 1 for v4.3 because:
1. Its now very late in the cycle
I understand.
Quoted 1 line
2. There now seems to be some discussion around it.
Yeah, that's what v4s are for...
Let's wait and see if/when it settles...
Quoted 2 lines
I think I am happy to take the other patches for v4.4, now. But perhaps I should wait for the discussion around patch 1 to conclude first?
Which other patches? Patch 3 has the same issue as patch 1. And all the rest depends on patch 1 or patch 3... So there's nothing left to apply yet...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
v4 cover ARM: shmobile: r8a7740/sh73a0 DT Cache Handling
Quoted 24 lines · Geert Uytterhoeven
Quoted 10 lines · Simon Horman
Quoted 9 lines · Geert Uytterhoeven
This patch series add L1 and L2 cache descriptions to DT for r8a7740 and sh73a0, and migrates the shmobile DT-based generic r8a7740 and armadillo legacy platforms from calling
l2x0_of_init()to the generic l2c OF initialization.Dependencies:
- This series applies to renesas-devel-20150805-v4.2-rc5,
- Patch 2 depends on patch 1,
- Patch 4 depends on patch 2,Sorry, "... on patch 3".
Quoted 10 lines
Quoted 9 lines
- Patch 5 depends on patch 1 and on "ARM: 8395/1: l2c: Add support for the "arm,shared-override" property" in arm/for-next,
- Patch 6 depends on patch 5.Given C code patches depending on DT patches in the same branch are frowned upon, I think it would be best if patch 1 (and patch 3, if anyone thinks we may fix the secondary CPU bringup issue during the next 3 months) are queued for v4.3. The other patches can be queued for 2016^H^H^H^Hv4.4.
Quoted 4 lines
Quoted 1 line
Sorry for surprising you with that merge-order requirement.
In theory it sounds fine, as DT and code are independent. Moving functionality from C to DT is something different...
I agree entirely. This is probably something that we should discuss with the ARM SoC developers. But my feeling is that there should be some scope for flexibility with regards to merge-order in such cases.
By which I mean we should try where possible, not to apply non-DT patches on top of DT patches. But if circumstances arise where it seems to be the best approach then we should to approach things pragmatically.
Quoted 10 lines
Quoted 2 lines
Unfortunately I am not comfortable with taking patch 1 for v4.3 because:
1. Its now very late in the cycleI understand.
Quoted 1 line
2. There now seems to be some discussion around it.
Yeah, that's what v4s are for...
Let's wait and see if/when it settles...
Yes, lets.
Quoted 6 lines
Quoted 2 lines
I think I am happy to take the other patches for v4.4, now. But perhaps I should wait for the discussion around patch 1 to conclude first?
Which other patches? Patch 3 has the same issue as patch 1. And all the rest depends on patch 1 or patch 3... So there's nothing left to apply yet...
Sorry for not being clearer. By other patches I meant patches 2 - 6 of this series. It seems that we should wait and I'm quite happy to do so.