* [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies
@ 2015-12-01 1:59 Stefan Agner
2015-12-02 8:13 ` Shawn Guo
2015-12-11 14:00 ` Shawn Guo
0 siblings, 2 replies; 4+ messages in thread
From: Stefan Agner @ 2015-12-01 1:59 UTC (permalink / raw)
To: shawnguo, kernel
Cc: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux,
linux-arm-kernel, devicetree, linux-kernel, Stefan Agner
Linux on Vybrid used several different L2 latencies so far, none
of them seem to be the right ones. According to the application note
AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
on CPU clock and is inside the L2 cache controller, whereas the data
portion is stored in the external SRAM running on platform clock.
Hence it is likely that the correct value requires a higher data
latency then tag latency.
These are the values which have been used so far:
- The mainline values:
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
Those values have lead to problems on higher clocks. They look
like a poor translation from the reset values (missing +1 offset
and a mix up between tag/latency values).
- The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
arm,data-latency = <4 2 3>
arm,tag-latency = <4 2 3>
The cache initialization function along with the value matches the
i.MX6 code from the same kernel, so it seems that those values have
just been copied.
- The Colibri values:
arm,data-latency = <2 1 2>;
arm,tag-latency = <3 2 3>;
Those were a mix between the values of the Linux 3.0 based BSP and
the mainline values above.
- The SoC Reset values (converted to DT notation):
arm,data-latency = <3 3 3>;
arm,tag-latency = <2 2 2>;
So far there is no official statement on what the correct values are.
See also the related Freescale community thread:
https://community.freescale.com/message/579785#579785
For now, the reset values seem to be the best bet. Remove all other
"bogus" values and use the reset value on vf610.dtsi level.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Hi Shawn,
Any chance to get this into 4.4?
--
Stefan
arch/arm/boot/dts/vf610-colibri.dtsi | 5 -----
arch/arm/boot/dts/vf610.dtsi | 2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi b/arch/arm/boot/dts/vf610-colibri.dtsi
index 19fe045..2d7eab7 100644
--- a/arch/arm/boot/dts/vf610-colibri.dtsi
+++ b/arch/arm/boot/dts/vf610-colibri.dtsi
@@ -18,8 +18,3 @@
reg = <0x80000000 0x10000000>;
};
};
-
-&L2 {
- arm,data-latency = <2 1 2>;
- arm,tag-latency = <3 2 3>;
-};
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 5f8eb1b..58bc6e4 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -19,7 +19,7 @@
reg = <0x40006000 0x1000>;
cache-unified;
cache-level = <2>;
- arm,data-latency = <1 1 1>;
+ arm,data-latency = <3 3 3>;
arm,tag-latency = <2 2 2>;
};
};
--
2.6.2
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies
2015-12-01 1:59 [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies Stefan Agner
@ 2015-12-02 8:13 ` Shawn Guo
2015-12-02 20:51 ` Stefan Agner
2015-12-11 14:00 ` Shawn Guo
1 sibling, 1 reply; 4+ messages in thread
From: Shawn Guo @ 2015-12-02 8:13 UTC (permalink / raw)
To: Stefan Agner
Cc: kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
linux, linux-arm-kernel, devicetree, linux-kernel
On Mon, Nov 30, 2015 at 05:59:26PM -0800, Stefan Agner wrote:
> Linux on Vybrid used several different L2 latencies so far, none
> of them seem to be the right ones. According to the application note
> AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
> on CPU clock and is inside the L2 cache controller, whereas the data
> portion is stored in the external SRAM running on platform clock.
> Hence it is likely that the correct value requires a higher data
> latency then tag latency.
>
> These are the values which have been used so far:
> - The mainline values:
> arm,data-latency = <1 1 1>;
> arm,tag-latency = <2 2 2>;
> Those values have lead to problems on higher clocks. They look
> like a poor translation from the reset values (missing +1 offset
> and a mix up between tag/latency values).
> - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
> arm,data-latency = <4 2 3>
> arm,tag-latency = <4 2 3>
> The cache initialization function along with the value matches the
> i.MX6 code from the same kernel, so it seems that those values have
> just been copied.
> - The Colibri values:
> arm,data-latency = <2 1 2>;
> arm,tag-latency = <3 2 3>;
> Those were a mix between the values of the Linux 3.0 based BSP and
> the mainline values above.
> - The SoC Reset values (converted to DT notation):
> arm,data-latency = <3 3 3>;
> arm,tag-latency = <2 2 2>;
>
> So far there is no official statement on what the correct values are.
> See also the related Freescale community thread:
> https://community.freescale.com/message/579785#579785
>
> For now, the reset values seem to be the best bet. Remove all other
> "bogus" values and use the reset value on vf610.dtsi level.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> Hi Shawn,
>
> Any chance to get this into 4.4?
I can try. Generally, upstream maintainers are becoming more strict for
-rc inclusion after -rc3 phase. Do you have any user stories about why
this is a critical/urgent fix? If we send this a critical fix for 4.4-rc
inclusion, do we need to Cc stable?
Shawn
>
> --
> Stefan
>
> arch/arm/boot/dts/vf610-colibri.dtsi | 5 -----
> arch/arm/boot/dts/vf610.dtsi | 2 +-
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi b/arch/arm/boot/dts/vf610-colibri.dtsi
> index 19fe045..2d7eab7 100644
> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
> @@ -18,8 +18,3 @@
> reg = <0x80000000 0x10000000>;
> };
> };
> -
> -&L2 {
> - arm,data-latency = <2 1 2>;
> - arm,tag-latency = <3 2 3>;
> -};
> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> index 5f8eb1b..58bc6e4 100644
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@ -19,7 +19,7 @@
> reg = <0x40006000 0x1000>;
> cache-unified;
> cache-level = <2>;
> - arm,data-latency = <1 1 1>;
> + arm,data-latency = <3 3 3>;
> arm,tag-latency = <2 2 2>;
> };
> };
> --
> 2.6.2
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies
2015-12-02 8:13 ` Shawn Guo
@ 2015-12-02 20:51 ` Stefan Agner
0 siblings, 0 replies; 4+ messages in thread
From: Stefan Agner @ 2015-12-02 20:51 UTC (permalink / raw)
To: Shawn Guo
Cc: kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
linux, linux-arm-kernel, devicetree, linux-kernel
On 2015-12-02 00:13, Shawn Guo wrote:
> On Mon, Nov 30, 2015 at 05:59:26PM -0800, Stefan Agner wrote:
>> Linux on Vybrid used several different L2 latencies so far, none
>> of them seem to be the right ones. According to the application note
>> AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
>> on CPU clock and is inside the L2 cache controller, whereas the data
>> portion is stored in the external SRAM running on platform clock.
>> Hence it is likely that the correct value requires a higher data
>> latency then tag latency.
>>
>> These are the values which have been used so far:
>> - The mainline values:
>> arm,data-latency = <1 1 1>;
>> arm,tag-latency = <2 2 2>;
>> Those values have lead to problems on higher clocks. They look
>> like a poor translation from the reset values (missing +1 offset
>> and a mix up between tag/latency values).
>> - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
>> arm,data-latency = <4 2 3>
>> arm,tag-latency = <4 2 3>
>> The cache initialization function along with the value matches the
>> i.MX6 code from the same kernel, so it seems that those values have
>> just been copied.
>> - The Colibri values:
>> arm,data-latency = <2 1 2>;
>> arm,tag-latency = <3 2 3>;
>> Those were a mix between the values of the Linux 3.0 based BSP and
>> the mainline values above.
>> - The SoC Reset values (converted to DT notation):
>> arm,data-latency = <3 3 3>;
>> arm,tag-latency = <2 2 2>;
>>
>> So far there is no official statement on what the correct values are.
>> See also the related Freescale community thread:
>> https://community.freescale.com/message/579785#579785
>>
>> For now, the reset values seem to be the best bet. Remove all other
>> "bogus" values and use the reset value on vf610.dtsi level.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> Hi Shawn,
>>
>> Any chance to get this into 4.4?
>
> I can try. Generally, upstream maintainers are becoming more strict for
> -rc inclusion after -rc3 phase. Do you have any user stories about why
> this is a critical/urgent fix? If we send this a critical fix for 4.4-rc
> inclusion, do we need to Cc stable?
It came up a while ago on Freescale community, but I think that user
used downstream BSP's:
https://community.freescale.com/thread/332326
The Colibri VF61 board overwrites the latency, so it is not really
critical for this board.
The Freescale Tower runs at 400MHz by default, but has a CPU which would
support up to 500MHz. I am pretty sure with 500MHz CPU clock, things
will go south with current settings.
Regarding stable: Would probably be consistent...
--
Stefan
>
> Shawn
>
>>
>> --
>> Stefan
>>
>> arch/arm/boot/dts/vf610-colibri.dtsi | 5 -----
>> arch/arm/boot/dts/vf610.dtsi | 2 +-
>> 2 files changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi b/arch/arm/boot/dts/vf610-colibri.dtsi
>> index 19fe045..2d7eab7 100644
>> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
>> @@ -18,8 +18,3 @@
>> reg = <0x80000000 0x10000000>;
>> };
>> };
>> -
>> -&L2 {
>> - arm,data-latency = <2 1 2>;
>> - arm,tag-latency = <3 2 3>;
>> -};
>> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
>> index 5f8eb1b..58bc6e4 100644
>> --- a/arch/arm/boot/dts/vf610.dtsi
>> +++ b/arch/arm/boot/dts/vf610.dtsi
>> @@ -19,7 +19,7 @@
>> reg = <0x40006000 0x1000>;
>> cache-unified;
>> cache-level = <2>;
>> - arm,data-latency = <1 1 1>;
>> + arm,data-latency = <3 3 3>;
>> arm,tag-latency = <2 2 2>;
>> };
>> };
>> --
>> 2.6.2
>>
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies
2015-12-01 1:59 [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies Stefan Agner
2015-12-02 8:13 ` Shawn Guo
@ 2015-12-11 14:00 ` Shawn Guo
1 sibling, 0 replies; 4+ messages in thread
From: Shawn Guo @ 2015-12-11 14:00 UTC (permalink / raw)
To: Stefan Agner
Cc: kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
linux, linux-arm-kernel, devicetree, linux-kernel
On Mon, Nov 30, 2015 at 05:59:26PM -0800, Stefan Agner wrote:
> Linux on Vybrid used several different L2 latencies so far, none
> of them seem to be the right ones. According to the application note
> AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
> on CPU clock and is inside the L2 cache controller, whereas the data
> portion is stored in the external SRAM running on platform clock.
> Hence it is likely that the correct value requires a higher data
> latency then tag latency.
>
> These are the values which have been used so far:
> - The mainline values:
> arm,data-latency = <1 1 1>;
> arm,tag-latency = <2 2 2>;
> Those values have lead to problems on higher clocks. They look
> like a poor translation from the reset values (missing +1 offset
> and a mix up between tag/latency values).
> - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
> arm,data-latency = <4 2 3>
> arm,tag-latency = <4 2 3>
> The cache initialization function along with the value matches the
> i.MX6 code from the same kernel, so it seems that those values have
> just been copied.
> - The Colibri values:
> arm,data-latency = <2 1 2>;
> arm,tag-latency = <3 2 3>;
> Those were a mix between the values of the Linux 3.0 based BSP and
> the mainline values above.
> - The SoC Reset values (converted to DT notation):
> arm,data-latency = <3 3 3>;
> arm,tag-latency = <2 2 2>;
>
> So far there is no official statement on what the correct values are.
> See also the related Freescale community thread:
> https://community.freescale.com/message/579785#579785
>
> For now, the reset values seem to be the best bet. Remove all other
> "bogus" values and use the reset value on vf610.dtsi level.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-12-11 14:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-01 1:59 [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies Stefan Agner
2015-12-02 8:13 ` Shawn Guo
2015-12-02 20:51 ` Stefan Agner
2015-12-11 14:00 ` Shawn Guo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).