| Message ID | 1438765090-823-2-git-send-email-geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Simon Horman |
| Headers | show |
On 05/08/15 09:58, Geert Uytterhoeven wrote: > 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 <geert+renesas@glider.be> > --- > 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(+) > > diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi > index d84714468cce18df..ddef5b1c68fa06b3 100644 > --- a/arch/arm/boot/dts/r8a7740.dtsi > +++ b/arch/arm/boot/dts/r8a7740.dtsi > @@ -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>; 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sudeep, On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > On 05/08/15 09:58, Geert Uytterhoeven wrote: >> 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 <geert+renesas@glider.be> >> diff --git a/arch/arm/boot/dts/r8a7740.dtsi >> b/arch/arm/boot/dts/r8a7740.dtsi >> index d84714468cce18df..ddef5b1c68fa06b3 100644 >> --- a/arch/arm/boot/dts/r8a7740.dtsi >> +++ b/arch/arm/boot/dts/r8a7740.dtsi >> @@ -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>; > > > Any particular reason whey you need all this cache-* properties ? Is To describe the cache as good as possible. > 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@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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On 05/08/15 11:44, Geert Uytterhoeven wrote: > Hi Sudeep, > > On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> On 05/08/15 09:58, Geert Uytterhoeven wrote: >>> 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 <geert+renesas@glider.be> > >>> diff --git a/arch/arm/boot/dts/r8a7740.dtsi >>> b/arch/arm/boot/dts/r8a7740.dtsi >>> index d84714468cce18df..ddef5b1c68fa06b3 100644 >>> --- a/arch/arm/boot/dts/r8a7740.dtsi >>> +++ b/arch/arm/boot/dts/r8a7740.dtsi >>> @@ -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>; >> >> >> 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sudeep, On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: > On 05/08/15 11:44, Geert Uytterhoeven wrote: >> On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com> >> wrote: >>> On 05/08/15 09:58, Geert Uytterhoeven wrote: >>>> 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 <geert+renesas@glider.be> >> >> >>>> diff --git a/arch/arm/boot/dts/r8a7740.dtsi >>>> b/arch/arm/boot/dts/r8a7740.dtsi >>>> index d84714468cce18df..ddef5b1c68fa06b3 100644 >>>> --- a/arch/arm/boot/dts/r8a7740.dtsi >>>> +++ b/arch/arm/boot/dts/r8a7740.dtsi >>>> @@ -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>; >>> >>> 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. > >>> 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. 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@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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/08/15 17:21, Geert Uytterhoeven wrote: > Hi Sudeep, > > On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> On 05/08/15 11:44, Geert Uytterhoeven wrote: >>> On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com> >>> wrote: [..] >>>> >>>> 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. >> >>>> 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. > > 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)... > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sudeep, [reviving this old thread, now we're two merge windows further] On Fri, Aug 7, 2015 at 11:45 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > On 06/08/15 17:21, Geert Uytterhoeven wrote: >> On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla <sudeep.holla@arm.com> >> wrote: >>> On 05/08/15 11:44, Geert Uytterhoeven wrote: >>>> On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com> >>>> wrote: > > > [..] > >>>>> 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. >>> >>>>> 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. >> >> 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)... > >> 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. > >> 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@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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 20/11/15 16:14, Geert Uytterhoeven wrote: > Hi Sudeep, > [...] > 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. > Sorry for the delay, was on vacation. Looks fine for me.
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi index d84714468cce18df..ddef5b1c68fa06b3 100644 --- a/arch/arm/boot/dts/r8a7740.dtsi +++ b/arch/arm/boot/dts/r8a7740.dtsi @@ -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@fe400000 { compatible = "renesas,dbsc3-r8a7740"; reg = <0xfe400000 0x400>;
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 <geert+renesas@glider.be> --- 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(+)