* [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
@ 2014-08-22 5:53 Allen Pais
2014-08-23 18:51 ` David Miller
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-22 5:53 UTC (permalink / raw)
To: sparclinux
The following patch adds support for correctly
recognising M7 cpu type.
Signed-off-by: Allen Pais <allen.pais@oracle.com>
---
arch/sparc/include/asm/spitfire.h | 1 +
arch/sparc/kernel/cpu.c | 6 ++++++
arch/sparc/kernel/head_64.S | 14 ++++++++++++++
3 files changed, 21 insertions(+)
diff --git a/arch/sparc/include/asm/spitfire.h b/arch/sparc/include/asm/spitfire.h
index 3fc58691..9aec17b 100644
--- a/arch/sparc/include/asm/spitfire.h
+++ b/arch/sparc/include/asm/spitfire.h
@@ -45,6 +45,7 @@
#define SUN4V_CHIP_NIAGARA3 0x03
#define SUN4V_CHIP_NIAGARA4 0x04
#define SUN4V_CHIP_NIAGARA5 0x05
+#define SUN4V_CHIP_SPARC_M7 0x08
#define SUN4V_CHIP_SPARC64X 0x8a
#define SUN4V_CHIP_UNKNOWN 0xff
diff --git a/arch/sparc/kernel/cpu.c b/arch/sparc/kernel/cpu.c
index 82a3a71..55dfb62 100644
--- a/arch/sparc/kernel/cpu.c
+++ b/arch/sparc/kernel/cpu.c
@@ -494,6 +494,12 @@ static void __init sun4v_cpu_probe(void)
sparc_pmu_type = "niagara5";
break;
+ case SUN4V_CHIP_SPARC_M7:
+ sparc_cpu_type = "SPARC-M7";
+ sparc_fpu_type = "SPARC-M7 integrated FPU";
+ sparc_pmu_type = "sparc-m7";
+ break;
+
case SUN4V_CHIP_SPARC64X:
sparc_cpu_type = "SPARC64-X";
sparc_fpu_type = "SPARC64-X integrated FPU";
diff --git a/arch/sparc/kernel/head_64.S b/arch/sparc/kernel/head_64.S
index 452f04f..577abba0 100644
--- a/arch/sparc/kernel/head_64.S
+++ b/arch/sparc/kernel/head_64.S
@@ -414,6 +414,8 @@ sun4v_chip_type:
cmp %g2, 'T'
be,pt %xcc, 70f
cmp %g2, 'M'
+ be,pt %xcc, 71f
+ nop
bne,pn %xcc, 49f
nop
@@ -430,6 +432,14 @@ sun4v_chip_type:
ba,pt %xcc, 49f
nop
+71:
+ ldub [%g1 + 7], %g2
+ cmp %g2, '7'
+ be,pt %xcc, 5f
+ mov SUN4V_CHIP_SPARC_M7, %g4
+ ba,pt %xcc, 49f
+ nop
+
91: sethi %hi(prom_cpu_compatible), %g1
or %g1, %lo(prom_cpu_compatible), %g1
ldub [%g1 + 17], %g2
@@ -586,6 +596,10 @@ niagara_tlb_fixup:
be,pt %xcc, niagara4_patch
nop
+ cmp %g1, SUN4V_CHIP_SPARC_M7
+ be,pt %xcc, niagara4_patch
+ nop
+
call generic_patch_copyops
nop
call generic_patch_bzero
--
1.8.4.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
@ 2014-08-23 18:51 ` David Miller
2014-08-24 6:18 ` David Miller
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-23 18:51 UTC (permalink / raw)
To: sparclinux
From: Allen Pais <allen.pais@oracle.com>
Date: Fri, 22 Aug 2014 11:22:51 +0530
> The following patch adds support for correctly
> recognising M7 cpu type.
>
> Signed-off-by: Allen Pais <allen.pais@oracle.com>
I don't think this is correct.
> @@ -414,6 +414,8 @@ sun4v_chip_type:
> cmp %g2, 'T'
> be,pt %xcc, 70f
> cmp %g2, 'M'
> + be,pt %xcc, 71f
> + nop
> bne,pn %xcc, 49f
> nop
This code block is supposed to fallthrough when %g2 is 'M' so that
we accept all of "{T,M}345..." but your change is breaking that
such that we will now only accept "M" as a prefix for "7".
That's a regression.
All you have to do is add the new comparison against '7' in the
"70:" label code block, and you're done.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
2014-08-23 18:51 ` David Miller
@ 2014-08-24 6:18 ` David Miller
2014-08-24 6:19 ` Allen Pais
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-24 6:18 UTC (permalink / raw)
To: sparclinux
From: Allen Pais <allen.pais@oracle.com>
Date: Sun, 24 Aug 2014 11:37:09 +0530
>>
>> I don't think this is correct.
>>
>>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>>> cmp %g2, 'T'
>>> be,pt %xcc, 70f
>>> cmp %g2, 'M'
>>> + be,pt %xcc, 71f
>>> + nop
>>> bne,pn %xcc, 49f
>>> nop
>>
>> This code block is supposed to fallthrough when %g2 is 'M' so that
>> we accept all of "{T,M}345..." but your change is breaking that
>> such that we will now only accept "M" as a prefix for "7".
>>
>> That's a regression.
>>
>> All you have to do is add the new comparison against '7' in the
>> "70:" label code block, and you're done.
>
> The idea was to also have M5 and M6-32 cpu types supported too with M7.
>
> +71:
> + ldub [%g1 + 7], %g2
> + cmp %g1, '5'
> + be,pt %xcc, 5f
> + mov SUN4V_CHIP_SPARC_M5, %g4
> + cmp %g1, '6'
> + be,pt %xcc, 5f
> + mov SUN4V_CHIP_SPARC_M6, %g4
> + cmp %g2, '7'
> + be,pt %xcc, 5f
> + mov SUN4V_CHIP_SPARC_M7, %g4
> + ba,pt %xcc, 49f
> + nop
> +
Again, why are you bothing with a special code path at all? You don't
need to.
Just add the M7 test to the "70:" label code block, and you're done.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
2014-08-23 18:51 ` David Miller
2014-08-24 6:18 ` David Miller
@ 2014-08-24 6:19 ` Allen Pais
2014-08-24 6:31 ` Allen Pais
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-24 6:19 UTC (permalink / raw)
To: sparclinux
>
> I don't think this is correct.
>
>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>> cmp %g2, 'T'
>> be,pt %xcc, 70f
>> cmp %g2, 'M'
>> + be,pt %xcc, 71f
>> + nop
>> bne,pn %xcc, 49f
>> nop
>
> This code block is supposed to fallthrough when %g2 is 'M' so that
> we accept all of "{T,M}345..." but your change is breaking that
> such that we will now only accept "M" as a prefix for "7".
>
> That's a regression.
>
> All you have to do is add the new comparison against '7' in the
> "70:" label code block, and you're done.
The idea was to also have M5 and M6-32 cpu types supported too with M7.
+71:
+ ldub [%g1 + 7], %g2
+ cmp %g1, '5'
+ be,pt %xcc, 5f
+ mov SUN4V_CHIP_SPARC_M5, %g4
+ cmp %g1, '6'
+ be,pt %xcc, 5f
+ mov SUN4V_CHIP_SPARC_M6, %g4
+ cmp %g2, '7'
+ be,pt %xcc, 5f
+ mov SUN4V_CHIP_SPARC_M7, %g4
+ ba,pt %xcc, 49f
+ nop
+
I haven't tested it yet on M5, I should have perhaps sent all them together.
lemme know what you think.
- Allen
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
` (2 preceding siblings ...)
2014-08-24 6:19 ` Allen Pais
@ 2014-08-24 6:31 ` Allen Pais
2014-08-24 6:43 ` David Miller
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-24 6:31 UTC (permalink / raw)
To: sparclinux
David,
>
>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>> cmp %g2, 'T'
>> be,pt %xcc, 70f
>> cmp %g2, 'M'
>> + be,pt %xcc, 71f
>> + nop
>> bne,pn %xcc, 49f
>> nop
>
> This code block is supposed to fallthrough when %g2 is 'M' so that
> we accept all of "{T,M}345..." but your change is breaking that
> such that we will now only accept "M" as a prefix for "7".
>
> That's a regression.
>
> All you have to do is add the new comparison against '7' in the
> "70:" label code block, and you're done.
>
When we are on this topic, here's a patch that attempts to simplify
cpu detection.
Here's a quick diff.
diff --git a/arch/sparc/kernel/cpu.c b/arch/sparc/kernel/cpu.c
index 5c51258..c06e27e 100644
--- a/arch/sparc/kernel/cpu.c
+++ b/arch/sparc/kernel/cpu.c
@@ -460,6 +460,36 @@ static int __init cpu_type_probe(void)
#endif /* CONFIG_SPARC32 */
#ifdef CONFIG_SPARC64
+
+static struct sun4v_chip_names {
+ const char *name;
+ unsigned long chip;
+} sun4v_names[] __initdata = {
+ {"SUNW,UltraSPARC-T1", SUN4V_CHIP_NIAGARA1},
+ {"SUNW,UltraSPARC-T2", SUN4V_CHIP_NIAGARA2},
+ {"SUNW,UltraSPARC-T2+", SUN4V_CHIP_NIAGARA2},
+ {"SUNW,UltraSPARC-T3", SUN4V_CHIP_NIAGARA3},
+ {"SPARC-T4", SUN4V_CHIP_NIAGARA4},
+ {"SPARC64-X", SUN4V_CHIP_SPARC64X},
+ {"SPARC-T5", SUN4V_CHIP_NIAGARA5},
+ {"SPARC-M7", SUN4V_CHIP_SPARC_M7},
+};
+
+unsigned long __init determine_sun4v_cpu(void)
+{
+ unsigned int nr_chips = ARRAY_SIZE(sun4v_names);
+ unsigned long chip_type = SUN4V_CHIP_UNKNOWN;
+ unsigned int i;
+
+ for (i = 0; i < nr_chips; i++) {
+ if (strcmp(prom_cpu_compatible, sun4v_names[i].name) = 0) {
+ chip_type = sun4v_names[i].chip;
+ break;
+ }
+ }
+ return chip_type;
+}
+
static void __init sun4v_cpu_probe(void)
{
switch (sun4v_chip_type) {
diff --git a/arch/sparc/kernel/head_64.S b/arch/sparc/kernel/head_64.S
index 26b706a..be49bef 100644
--- a/arch/sparc/kernel/head_64.S
+++ b/arch/sparc/kernel/head_64.S
@@ -130,12 +130,6 @@ prom_set_trap_table_name:
.asciz "SUNW,set-trap-table"
prom_sun4v_name:
.asciz "sun4v"
-prom_niagara_prefix:
- .asciz "SUNW,UltraSPARC-T"
-prom_sparc_prefix:
- .asciz "SPARC-"
-prom_sparc64x_prefix:
- .asciz "SPARC64-X"
.align 4
prom_root_compatible:
.skip 64
@@ -376,91 +370,10 @@ sun4v_chip_type:
call %l7
add %sp, (2047 + 128), %o0 ! argument array
+ call determine_sun4v_cpu
add %sp, (192 + 128), %sp
- sethi %hi(prom_cpu_compatible), %g1
- or %g1, %lo(prom_cpu_compatible), %g1
- sethi %hi(prom_niagara_prefix), %g7
- or %g7, %lo(prom_niagara_prefix), %g7
- mov 17, %g3
-90: ldub [%g7], %g2
- ldub [%g1], %g4
- cmp %g2, %g4
- bne,pn %icc, 89f
- add %g7, 1, %g7
- subcc %g3, 1, %g3
- bne,pt %xcc, 90b
- add %g1, 1, %g1
- ba,pt %xcc, 91f
- nop
-
-89: sethi %hi(prom_cpu_compatible), %g1
- or %g1, %lo(prom_cpu_compatible), %g1
- sethi %hi(prom_sparc_prefix), %g7
- or %g7, %lo(prom_sparc_prefix), %g7
- mov 6, %g3
-90: ldub [%g7], %g2
- ldub [%g1], %g4
- cmp %g2, %g4
- bne,pn %icc, 4f
- add %g7, 1, %g7
- subcc %g3, 1, %g3
- bne,pt %xcc, 90b
- add %g1, 1, %g1
-
- sethi %hi(prom_cpu_compatible), %g1
- or %g1, %lo(prom_cpu_compatible), %g1
- ldub [%g1 + 6], %g2
- cmp %g2, 'T'
- be,pt %xcc, 70f
- cmp %g2, 'M'
- bne,pn %xcc, 49f
- nop
-
-70: ldub [%g1 + 7], %g2
- cmp %g2, '3'
- be,pt %xcc, 5f
- mov SUN4V_CHIP_NIAGARA3, %g4
- cmp %g2, '4'
- be,pt %xcc, 5f
- mov SUN4V_CHIP_NIAGARA4, %g4
- cmp %g2, '5'
- be,pt %xcc, 5f
- mov SUN4V_CHIP_NIAGARA5, %g4
- ba,pt %xcc, 49f
- nop
-
-91: sethi %hi(prom_cpu_compatible), %g1
- or %g1, %lo(prom_cpu_compatible), %g1
- ldub [%g1 + 17], %g2
- cmp %g2, '1'
- be,pt %xcc, 5f
- mov SUN4V_CHIP_NIAGARA1, %g4
- cmp %g2, '2'
- be,pt %xcc, 5f
- mov SUN4V_CHIP_NIAGARA2, %g4
-
-4:
- /* Athena */
- sethi %hi(prom_cpu_compatible), %g1
- or %g1, %lo(prom_cpu_compatible), %g1
- sethi %hi(prom_sparc64x_prefix), %g7
- or %g7, %lo(prom_sparc64x_prefix), %g7
- mov 9, %g3
-41: ldub [%g7], %g2
- ldub [%g1], %g4
- cmp %g2, %g4
- bne,pn %icc, 49f
- add %g7, 1, %g7
- subcc %g3, 1, %g3
- bne,pt %xcc, 41b
- add %g1, 1, %g1
- mov SUN4V_CHIP_SPARC64X, %g4
- ba,pt %xcc, 5f
- nop
-
-49:
- mov SUN4V_CHIP_UNKNOWN, %g4
+ or %o0, %g0, %g4
5: sethi %hi(sun4v_chip_type), %g2
or %g2, %lo(sun4v_chip_type), %g2
stw %g4, [%g2]
- Allen
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
` (3 preceding siblings ...)
2014-08-24 6:31 ` Allen Pais
@ 2014-08-24 6:43 ` David Miller
2014-08-24 6:43 ` Allen Pais
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-24 6:43 UTC (permalink / raw)
To: sparclinux
From: Allen Pais <allen.pais@oracle.com>
Date: Sun, 24 Aug 2014 11:49:29 +0530
> David,
>>
>>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>>> cmp %g2, 'T'
>>> be,pt %xcc, 70f
>>> cmp %g2, 'M'
>>> + be,pt %xcc, 71f
>>> + nop
>>> bne,pn %xcc, 49f
>>> nop
>>
>> This code block is supposed to fallthrough when %g2 is 'M' so that
>> we accept all of "{T,M}345..." but your change is breaking that
>> such that we will now only accept "M" as a prefix for "7".
>>
>> That's a regression.
>>
>> All you have to do is add the new comparison against '7' in the
>> "70:" label code block, and you're done.
>>
>
> When we are on this topic, here's a patch that attempts to simplify
> cpu detection.
>
> Here's a quick diff.
You can't call C code until you've cleared the BSS, you can't clear
the BSS until you hook up the proper optimized routines, you can't
hook up the proper optimized routined until you know the cpu type.
I would have done this years ago otherwise.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
` (4 preceding siblings ...)
2014-08-24 6:43 ` David Miller
@ 2014-08-24 6:43 ` Allen Pais
2014-08-24 12:35 ` Bob Picco
2014-08-24 19:06 ` David Miller
7 siblings, 0 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-24 6:43 UTC (permalink / raw)
To: sparclinux
David,
>> The idea was to also have M5 and M6-32 cpu types supported too with M7.
>>
>> +71:
>> + ldub [%g1 + 7], %g2
>> + cmp %g1, '5'
>> + be,pt %xcc, 5f
>> + mov SUN4V_CHIP_SPARC_M5, %g4
>> + cmp %g1, '6'
>> + be,pt %xcc, 5f
>> + mov SUN4V_CHIP_SPARC_M6, %g4
>> + cmp %g2, '7'
>> + be,pt %xcc, 5f
>> + mov SUN4V_CHIP_SPARC_M7, %g4
>> + ba,pt %xcc, 49f
>> + nop
>> +
>
> Again, why are you bothing with a special code path at all? You don't
> need to.
>
> Just add the M7 test to the "70:" label code block, and you're done.
>
I was a little confused when you initially mentioned about using "70:" label
code block, now I see the point. I'll re-do the patch and test it.
- Allen
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
` (5 preceding siblings ...)
2014-08-24 6:43 ` Allen Pais
@ 2014-08-24 12:35 ` Bob Picco
2014-08-24 19:06 ` David Miller
7 siblings, 0 replies; 9+ messages in thread
From: Bob Picco @ 2014-08-24 12:35 UTC (permalink / raw)
To: sparclinux
Hi,
David Miller wrote: [Sun Aug 24 2014, 02:43:11AM EDT]
> From: Allen Pais <allen.pais@oracle.com>
> Date: Sun, 24 Aug 2014 11:49:29 +0530
>
> > David,
> >>
> >>> @@ -414,6 +414,8 @@ sun4v_chip_type:
> >>> cmp %g2, 'T'
> >>> be,pt %xcc, 70f
> >>> cmp %g2, 'M'
> >>> + be,pt %xcc, 71f
> >>> + nop
> >>> bne,pn %xcc, 49f
> >>> nop
> >>
> >> This code block is supposed to fallthrough when %g2 is 'M' so that
> >> we accept all of "{T,M}345..." but your change is breaking that
> >> such that we will now only accept "M" as a prefix for "7".
> >>
> >> That's a regression.
> >>
> >> All you have to do is add the new comparison against '7' in the
> >> "70:" label code block, and you're done.
> >>
> >
> > When we are on this topic, here's a patch that attempts to simplify
> > cpu detection.
> >
> > Here's a quick diff.
>
> You can't call C code until you've cleared the BSS, you can't clear
> the BSS until you hook up the proper optimized routines, you can't
> hook up the proper optimized routined until you know the cpu type.
I'm aware of BSS and cpu initialization routines. Many issues are subtle
until paging_init finishes.
What BSS does this code touch or reference? None that I'm aware of.
The code is executing on OBP stack and the kernel has been remapped and
doesn't require PIC address manipulation any longer. Your only assumptions
should be OBP handling register window events and accessing compile time
initialized data. BSS is taboo for the reason you state.
One obviously has to be VERY careful. The "VERY" part is true of all code
here. Should there be fear of strcmp then implement it in simple "C" and name
it "boot_strcmp".
Perhaps I've missed an issue.
thanx,
bob
>
> I would have done this years ago otherwise.
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
` (6 preceding siblings ...)
2014-08-24 12:35 ` Bob Picco
@ 2014-08-24 19:06 ` David Miller
7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-24 19:06 UTC (permalink / raw)
To: sparclinux
From: Bob Picco <bpicco@meloft.net>
Date: Sun, 24 Aug 2014 08:35:06 -0400
> What BSS does this code touch or reference? None that I'm aware of.
You cannot control what code the compiler emits, it is therefore not
safe to call C code.
Please just drop this for now, thank you.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-08-24 19:06 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-22 5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
2014-08-23 18:51 ` David Miller
2014-08-24 6:18 ` David Miller
2014-08-24 6:19 ` Allen Pais
2014-08-24 6:31 ` Allen Pais
2014-08-24 6:43 ` David Miller
2014-08-24 6:43 ` Allen Pais
2014-08-24 12:35 ` Bob Picco
2014-08-24 19:06 ` David Miller
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.