* [PATCH] MIPS: Tell R4k SC and MC variations apart
@ 2013-09-22 22:30 Maciej W. Rozycki
2013-09-23 11:37 ` Jonas Gorski
2013-09-24 8:48 ` [PATCH] " Ralf Baechle
0 siblings, 2 replies; 9+ messages in thread
From: Maciej W. Rozycki @ 2013-09-22 22:30 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
There is no reliable way to tell R4000/R4400 SC and MC variations apart,
however simple heuristic should give good results. Only the MC version
supports coherent caching so we can rely on such a mode having been set
for KSEG0 by the power-on firmware to reliably indicate an MC processor.
SC processors reportedly hang on coherent cached memory accesses and Linux
is linked to a cached load address so the firmware has to use the correct
caching mode to download the kernel image in a cached mode successfully.
OTOH if the firmware chooses to use either the non-coherent cached or the
uncached mode for KSEG0 on an MC processor, then the SC variant will be
reported, just as we currently do, so no regression here.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Ralf,
I believe we discussed this once long ago and you had some concerns about
such an approach although I don't recall exactly what they were. I
maintain that this heuristic is reasonable, has no drawbacks and has a
potential to make some optimisations or errata workarounds easier. Also
we can collect data about systems affected to see what their firmware does
-- R4000SC/R4400SC DECstations definitely get CP0.Config.K0 right.
Maciej
linux-mips-r4k-mc.patch
Index: linux/arch/mips/kernel/cpu-probe.c
===================================================================
--- linux.orig/arch/mips/kernel/cpu-probe.c
+++ linux/arch/mips/kernel/cpu-probe.c
@@ -362,13 +362,33 @@ static inline void cpu_probe_legacy(stru
__cpu_name[cpu] = "R4000PC";
}
} else {
+ int cca = read_c0_config() & CONF_CM_CMASK;
+ int mc;
+
+ /*
+ * SC and MC versions can't be reliably told apart,
+ * but only the latter support coherent caching
+ * modes so assume the firmware has set the KSEG0
+ * coherency attribute reasonably (if uncached, we
+ * assume SC).
+ */
+ switch (cca) {
+ case CONF_CM_CACHABLE_CE:
+ case CONF_CM_CACHABLE_COW:
+ case CONF_CM_CACHABLE_CUW:
+ mc = 1;
+ break;
+ default:
+ mc = 0;
+ break;
+ }
if ((c->processor_id & PRID_REV_MASK) >=
PRID_REV_R4400) {
- c->cputype = CPU_R4400SC;
- __cpu_name[cpu] = "R4400SC";
+ c->cputype = mc ? CPU_R4400MC : CPU_R4400SC;
+ __cpu_name[cpu] = mc ? "R4400MC" : "R4400SC";
} else {
- c->cputype = CPU_R4000SC;
- __cpu_name[cpu] = "R4000SC";
+ c->cputype = mc ? CPU_R4000MC : CPU_R4000SC;
+ __cpu_name[cpu] = mc ? "R4400SC" : "R4000SC";
}
}
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] MIPS: Tell R4k SC and MC variations apart
2013-09-22 22:30 [PATCH] MIPS: Tell R4k SC and MC variations apart Maciej W. Rozycki
@ 2013-09-23 11:37 ` Jonas Gorski
2013-09-23 12:35 ` [PATCH v2] " Maciej W. Rozycki
2013-09-24 8:48 ` [PATCH] " Ralf Baechle
1 sibling, 1 reply; 9+ messages in thread
From: Jonas Gorski @ 2013-09-23 11:37 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, MIPS Mailing List
On Mon, Sep 23, 2013 at 12:30 AM, Maciej W. Rozycki
<macro@linux-mips.org> wrote:
> There is no reliable way to tell R4000/R4400 SC and MC variations apart,
> however simple heuristic should give good results. Only the MC version
> supports coherent caching so we can rely on such a mode having been set
> for KSEG0 by the power-on firmware to reliably indicate an MC processor.
> SC processors reportedly hang on coherent cached memory accesses and Linux
> is linked to a cached load address so the firmware has to use the correct
> caching mode to download the kernel image in a cached mode successfully.
>
> OTOH if the firmware chooses to use either the non-coherent cached or the
> uncached mode for KSEG0 on an MC processor, then the SC variant will be
> reported, just as we currently do, so no regression here.
>
> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
> ---
> Ralf,
>
> I believe we discussed this once long ago and you had some concerns about
> such an approach although I don't recall exactly what they were. I
> maintain that this heuristic is reasonable, has no drawbacks and has a
> potential to make some optimisations or errata workarounds easier. Also
> we can collect data about systems affected to see what their firmware does
> -- R4000SC/R4400SC DECstations definitely get CP0.Config.K0 right.
>
> Maciej
>
> linux-mips-r4k-mc.patch
> Index: linux/arch/mips/kernel/cpu-probe.c
> ===================================================================
> --- linux.orig/arch/mips/kernel/cpu-probe.c
> +++ linux/arch/mips/kernel/cpu-probe.c
> @@ -362,13 +362,33 @@ static inline void cpu_probe_legacy(stru
> __cpu_name[cpu] = "R4000PC";
> }
> } else {
> + int cca = read_c0_config() & CONF_CM_CMASK;
> + int mc;
> +
> + /*
> + * SC and MC versions can't be reliably told apart,
> + * but only the latter support coherent caching
> + * modes so assume the firmware has set the KSEG0
> + * coherency attribute reasonably (if uncached, we
> + * assume SC).
> + */
> + switch (cca) {
> + case CONF_CM_CACHABLE_CE:
> + case CONF_CM_CACHABLE_COW:
> + case CONF_CM_CACHABLE_CUW:
> + mc = 1;
> + break;
> + default:
> + mc = 0;
> + break;
> + }
> if ((c->processor_id & PRID_REV_MASK) >=
> PRID_REV_R4400) {
> - c->cputype = CPU_R4400SC;
> - __cpu_name[cpu] = "R4400SC";
> + c->cputype = mc ? CPU_R4400MC : CPU_R4400SC;
> + __cpu_name[cpu] = mc ? "R4400MC" : "R4400SC";
> } else {
> - c->cputype = CPU_R4000SC;
> - __cpu_name[cpu] = "R4000SC";
> + c->cputype = mc ? CPU_R4000MC : CPU_R4000SC;
> + __cpu_name[cpu] = mc ? "R4400SC" : "R4000SC";
I guess the first one should be "R4000MC", not "R4400SC".
Regards
Jonas
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH v2] MIPS: Tell R4k SC and MC variations apart
2013-09-23 11:37 ` Jonas Gorski
@ 2013-09-23 12:35 ` Maciej W. Rozycki
2013-09-23 12:41 ` Jonas Gorski
0 siblings, 1 reply; 9+ messages in thread
From: Maciej W. Rozycki @ 2013-09-23 12:35 UTC (permalink / raw)
To: Jonas Gorski, Ralf Baechle; +Cc: MIPS Mailing List
There is no reliable way to tell R4000/R4400 SC and MC variations apart,
however simple heuristic should give good results. Only the MC version
supports coherent caching so we can rely on such a mode having been set
for KSEG0 by the power-on firmware to reliably indicate an MC processor.
SC processors reportedly hang on coherent cached memory accesses and Linux
is linked to a cached load address so the firmware has to use the correct
caching mode to download the kernel image in a cached mode successfully.
OTOH if the firmware chooses to use either the non-coherent cached or the
uncached mode for KSEG0 on an MC processor, then the SC variant will be
reported, just as we currently do, so no regression here.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
> > + c->cputype = mc ? CPU_R4000MC : CPU_R4000SC;
> > + __cpu_name[cpu] = mc ? "R4400SC" : "R4000SC";
>
> I guess the first one should be "R4000MC", not "R4400SC".
Good catch, thanks, here's an update.
Maciej
linux-mips-r4k-mc.patch
Index: linux/arch/mips/kernel/cpu-probe.c
===================================================================
--- linux.orig/arch/mips/kernel/cpu-probe.c
+++ linux/arch/mips/kernel/cpu-probe.c
@@ -362,13 +362,33 @@ static inline void cpu_probe_legacy(stru
__cpu_name[cpu] = "R4000PC";
}
} else {
+ int cca = read_c0_config() & CONF_CM_CMASK;
+ int mc;
+
+ /*
+ * SC and MC versions can't be reliably told apart,
+ * but only the latter support coherent caching
+ * modes so assume the firmware has set the KSEG0
+ * coherency attribute reasonably (if uncached, we
+ * assume SC).
+ */
+ switch (cca) {
+ case CONF_CM_CACHABLE_CE:
+ case CONF_CM_CACHABLE_COW:
+ case CONF_CM_CACHABLE_CUW:
+ mc = 1;
+ break;
+ default:
+ mc = 0;
+ break;
+ }
if ((c->processor_id & PRID_REV_MASK) >=
PRID_REV_R4400) {
- c->cputype = CPU_R4400SC;
- __cpu_name[cpu] = "R4400SC";
+ c->cputype = mc ? CPU_R4400MC : CPU_R4400SC;
+ __cpu_name[cpu] = mc ? "R4400MC" : "R4400SC";
} else {
- c->cputype = CPU_R4000SC;
- __cpu_name[cpu] = "R4000SC";
+ c->cputype = mc ? CPU_R4000MC : CPU_R4000SC;
+ __cpu_name[cpu] = mc ? "R4400MC" : "R4000SC";
}
}
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2] MIPS: Tell R4k SC and MC variations apart
2013-09-23 12:35 ` [PATCH v2] " Maciej W. Rozycki
@ 2013-09-23 12:41 ` Jonas Gorski
2013-09-23 13:01 ` [PATCH v3] " Maciej W. Rozycki
0 siblings, 1 reply; 9+ messages in thread
From: Jonas Gorski @ 2013-09-23 12:41 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, MIPS Mailing List
On Mon, Sep 23, 2013 at 2:35 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
(snip)
> linux-mips-r4k-mc.patch
> Index: linux/arch/mips/kernel/cpu-probe.c
> ===================================================================
> --- linux.orig/arch/mips/kernel/cpu-probe.c
> +++ linux/arch/mips/kernel/cpu-probe.c
> @@ -362,13 +362,33 @@ static inline void cpu_probe_legacy(stru
> __cpu_name[cpu] = "R4000PC";
> }
> } else {
> + int cca = read_c0_config() & CONF_CM_CMASK;
> + int mc;
> +
> + /*
> + * SC and MC versions can't be reliably told apart,
> + * but only the latter support coherent caching
> + * modes so assume the firmware has set the KSEG0
> + * coherency attribute reasonably (if uncached, we
> + * assume SC).
> + */
> + switch (cca) {
> + case CONF_CM_CACHABLE_CE:
> + case CONF_CM_CACHABLE_COW:
> + case CONF_CM_CACHABLE_CUW:
> + mc = 1;
> + break;
> + default:
> + mc = 0;
> + break;
> + }
> if ((c->processor_id & PRID_REV_MASK) >=
> PRID_REV_R4400) {
> - c->cputype = CPU_R4400SC;
> - __cpu_name[cpu] = "R4400SC";
> + c->cputype = mc ? CPU_R4400MC : CPU_R4400SC;
> + __cpu_name[cpu] = mc ? "R4400MC" : "R4400SC";
> } else {
> - c->cputype = CPU_R4000SC;
> - __cpu_name[cpu] = "R4000SC";
> + c->cputype = mc ? CPU_R4000MC : CPU_R4000SC;
> + __cpu_name[cpu] = mc ? "R4400MC" : "R4000SC";
You are still calling it "R4400", not "R4000" as expected.
Jonas
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH v3] MIPS: Tell R4k SC and MC variations apart
2013-09-23 12:41 ` Jonas Gorski
@ 2013-09-23 13:01 ` Maciej W. Rozycki
2013-09-24 9:11 ` Ralf Baechle
0 siblings, 1 reply; 9+ messages in thread
From: Maciej W. Rozycki @ 2013-09-23 13:01 UTC (permalink / raw)
To: Jonas Gorski, Ralf Baechle; +Cc: MIPS Mailing List
There is no reliable way to tell R4000/R4400 SC and MC variations apart,
however simple heuristic should give good results. Only the MC version
supports coherent caching so we can rely on such a mode having been set
for KSEG0 by the power-on firmware to reliably indicate an MC processor.
SC processors reportedly hang on coherent cached memory accesses and Linux
is linked to a cached load address so the firmware has to use the correct
caching mode to download the kernel image in a cached mode successfully.
OTOH if the firmware chooses to use either the non-coherent cached or the
uncached mode for KSEG0 on an MC processor, then the SC variant will be
reported, just as we currently do, so no regression here.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
> > + c->cputype = mc ? CPU_R4000MC : CPU_R4000SC;
> > + __cpu_name[cpu] = mc ? "R4400MC" : "R4000SC";
>
> You are still calling it "R4400", not "R4000" as expected.
Sigh, sorry about that, and thanks for your persistence.
Maciej
linux-mips-r4k-mc.patch
Index: linux/arch/mips/kernel/cpu-probe.c
===================================================================
--- linux.orig/arch/mips/kernel/cpu-probe.c
+++ linux/arch/mips/kernel/cpu-probe.c
@@ -362,13 +362,33 @@ static inline void cpu_probe_legacy(stru
__cpu_name[cpu] = "R4000PC";
}
} else {
+ int cca = read_c0_config() & CONF_CM_CMASK;
+ int mc;
+
+ /*
+ * SC and MC versions can't be reliably told apart,
+ * but only the latter support coherent caching
+ * modes so assume the firmware has set the KSEG0
+ * coherency attribute reasonably (if uncached, we
+ * assume SC).
+ */
+ switch (cca) {
+ case CONF_CM_CACHABLE_CE:
+ case CONF_CM_CACHABLE_COW:
+ case CONF_CM_CACHABLE_CUW:
+ mc = 1;
+ break;
+ default:
+ mc = 0;
+ break;
+ }
if ((c->processor_id & PRID_REV_MASK) >=
PRID_REV_R4400) {
- c->cputype = CPU_R4400SC;
- __cpu_name[cpu] = "R4400SC";
+ c->cputype = mc ? CPU_R4400MC : CPU_R4400SC;
+ __cpu_name[cpu] = mc ? "R4400MC" : "R4400SC";
} else {
- c->cputype = CPU_R4000SC;
- __cpu_name[cpu] = "R4000SC";
+ c->cputype = mc ? CPU_R4000MC : CPU_R4000SC;
+ __cpu_name[cpu] = mc ? "R4000MC" : "R4000SC";
}
}
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v3] MIPS: Tell R4k SC and MC variations apart
2013-09-23 13:01 ` [PATCH v3] " Maciej W. Rozycki
@ 2013-09-24 9:11 ` Ralf Baechle
0 siblings, 0 replies; 9+ messages in thread
From: Ralf Baechle @ 2013-09-24 9:11 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Jonas Gorski, MIPS Mailing List
On Mon, Sep 23, 2013 at 02:01:53PM +0100, Maciej W. Rozycki wrote:
> There is no reliable way to tell R4000/R4400 SC and MC variations apart,
> however simple heuristic should give good results. Only the MC version
> supports coherent caching so we can rely on such a mode having been set
> for KSEG0 by the power-on firmware to reliably indicate an MC processor.
> SC processors reportedly hang on coherent cached memory accesses and Linux
> is linked to a cached load address so the firmware has to use the correct
> caching mode to download the kernel image in a cached mode successfully.
>
> OTOH if the firmware chooses to use either the non-coherent cached or the
> uncached mode for KSEG0 on an MC processor, then the SC variant will be
> reported, just as we currently do, so no regression here.
Queued for 3.13. Thanks,
Ralf
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] MIPS: Tell R4k SC and MC variations apart
2013-09-22 22:30 [PATCH] MIPS: Tell R4k SC and MC variations apart Maciej W. Rozycki
2013-09-23 11:37 ` Jonas Gorski
@ 2013-09-24 8:48 ` Ralf Baechle
2013-09-24 23:37 ` Maciej W. Rozycki
1 sibling, 1 reply; 9+ messages in thread
From: Ralf Baechle @ 2013-09-24 8:48 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips
On Sun, Sep 22, 2013 at 11:30:59PM +0100, Maciej W. Rozycki wrote:
> There is no reliable way to tell R4000/R4400 SC and MC variations apart,
> however simple heuristic should give good results. Only the MC version
> supports coherent caching so we can rely on such a mode having been set
> for KSEG0 by the power-on firmware to reliably indicate an MC processor.
> SC processors reportedly hang on coherent cached memory accesses and Linux
> is linked to a cached load address so the firmware has to use the correct
> caching mode to download the kernel image in a cached mode successfully.
>
> OTOH if the firmware chooses to use either the non-coherent cached or the
> uncached mode for KSEG0 on an MC processor, then the SC variant will be
> reported, just as we currently do, so no regression here.
>
> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
> ---
> Ralf,
>
> I believe we discussed this once long ago and you had some concerns about
> such an approach although I don't recall exactly what they were. I
> maintain that this heuristic is reasonable, has no drawbacks and has a
> potential to make some optimisations or errata workarounds easier. Also
> we can collect data about systems affected to see what their firmware does
> -- R4000SC/R4400SC DECstations definitely get CP0.Config.K0 right.
I'm fairly sure it gets k0 right - otherwise it'd likely not work at all!
My reservations may have been about userland reading /proc/cpuinfo and
looking at the CPU type. Some software may know how to handle the
PC/SC variants but not the MC versions. But this seems to be a fairly
weak concern - and I trust you checked gcc's parsing of /proc/cpuinfo.
Ralf
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] MIPS: Tell R4k SC and MC variations apart
2013-09-24 8:48 ` [PATCH] " Ralf Baechle
@ 2013-09-24 23:37 ` Maciej W. Rozycki
2013-09-25 11:02 ` Ralf Baechle
0 siblings, 1 reply; 9+ messages in thread
From: Maciej W. Rozycki @ 2013-09-24 23:37 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
On Tue, 24 Sep 2013, Ralf Baechle wrote:
> My reservations may have been about userland reading /proc/cpuinfo and
> looking at the CPU type. Some software may know how to handle the
> PC/SC variants but not the MC versions. But this seems to be a fairly
> weak concern - and I trust you checked gcc's parsing of /proc/cpuinfo.
Actually I wasn't actually aware GCC's got /proc/cpuinfo-based native
arch support for the MIPS target these days, thanks for the hint.
I have now checked the relevant source file and support is pretty weak
there, only half a dozen processors are recognised and no R4k model is
among them. In any case strstr is used to check for matches there so I'd
expect strings like "R4000" or "R4400" without a further suffix to be
chosen.
Maciej
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] MIPS: Tell R4k SC and MC variations apart
2013-09-24 23:37 ` Maciej W. Rozycki
@ 2013-09-25 11:02 ` Ralf Baechle
0 siblings, 0 replies; 9+ messages in thread
From: Ralf Baechle @ 2013-09-25 11:02 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips
On Wed, Sep 25, 2013 at 12:37:42AM +0100, Maciej W. Rozycki wrote:
> > My reservations may have been about userland reading /proc/cpuinfo and
> > looking at the CPU type. Some software may know how to handle the
> > PC/SC variants but not the MC versions. But this seems to be a fairly
> > weak concern - and I trust you checked gcc's parsing of /proc/cpuinfo.
>
> Actually I wasn't actually aware GCC's got /proc/cpuinfo-based native
> arch support for the MIPS target these days, thanks for the hint.
>
> I have now checked the relevant source file and support is pretty weak
> there, only half a dozen processors are recognised and no R4k model is
> among them. In any case strstr is used to check for matches there so I'd
> expect strings like "R4000" or "R4400" without a further suffix to be
> chosen.
It'd be worth a change in particular for users how higher end CPUs and
enhanced ISAs such as Octeons.
Or should we just default to O32 w/ MIPS I + LL/SC as the MIPS Esperanto
forever ...
Ralf
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-09-25 11:02 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-22 22:30 [PATCH] MIPS: Tell R4k SC and MC variations apart Maciej W. Rozycki
2013-09-23 11:37 ` Jonas Gorski
2013-09-23 12:35 ` [PATCH v2] " Maciej W. Rozycki
2013-09-23 12:41 ` Jonas Gorski
2013-09-23 13:01 ` [PATCH v3] " Maciej W. Rozycki
2013-09-24 9:11 ` Ralf Baechle
2013-09-24 8:48 ` [PATCH] " Ralf Baechle
2013-09-24 23:37 ` Maciej W. Rozycki
2013-09-25 11:02 ` Ralf Baechle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.