[PATCH] ppc32: make sure we have an L3 before touch its control register

Ben,

Can you take a look at this.  I think its pretty straight forward and if 
your ok with it please forward on to linus.

- kumar

--

Some variants of 745x may not actually have the L3CR register.  Since
we mark which variants of 745x have L3CRs in the cputable we can
use that information to ensure that the mfspr L3CR will not cause
an exception in the processors that don't have the register.

Signed-off-by: Kumar K. Gala <redacted>

---
commit f706b6046f1fee29bdf3081dd783f7e482012165
tree 6d42ee61458ec94ac7d4567e3f0383dd1e47a537
parent d8ac10639b6a1ed900efbee38c18baaca31e64dc
author Kumar K. Gala [off-list ref] Thu, 22 Sep 2005 14:47:52 -0500
committer Kumar K. Gala [off-list ref] Thu, 22 Sep 2005 14:47:52 -0500

 arch/ppc/kernel/cpu_setup_6xx.S |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/ppc/kernel/cpu_setup_6xx.S b/arch/ppc/kernel/cpu_setup_6xx.S
--- a/arch/ppc/kernel/cpu_setup_6xx.S
+++ b/arch/ppc/kernel/cpu_setup_6xx.S

@@ -212,9 +212,11 @@ setup_745x_specifics:
 	 * the firmware. If any, we disable NAP capability as
 	 * it's known to be bogus on rev 2.1 and earlier
 	 */
+BEGIN_FTR_SECTION
 	mfspr	r11,SPRN_L3CR
 	andis.	r11,r11,L3CR_L3E@h
 	beq	1f
+END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
 	lwz	r6,CPU_SPEC_FEATURES(r5)
 	andi.	r0,r6,CPU_FTR_L3_DISABLE_NAP
 	beq	1f

On Thu, 2005-09-22 at 14:51 -0500, Kumar Gala wrote:

Ben,

Can you take a look at this.  I think its pretty straight forward and if 
your ok with it please forward on to linus.

We usually haven't dong the fixup of cpu features yet at the point
setup() is run, thus your change will have no effect. You need to
actually go look at the CPU feature bits. (You can look a bit below in
that same code how it does for CPU_FTR_L3_DISABLE_NAP and
CCPU_FTR_CAN_NAP.

Also, it's 745x, those CPUs so far always existed in their 744x version
without L3 and no way to recongnize them via PVR afaik (until before
7447A). I would expect L3CR to just return 0. Is this not the case on
7447/7448 ? If yes, then there is no need to change the code...

Ben.

On Sep 24, 2005, at 5:10 PM, Benjamin Herrenschmidt wrote:

On Thu, 2005-09-22 at 14:51 -0500, Kumar Gala wrote:

quoted

Ben,

Can you take a look at this.  I think its pretty straight forward and

if

quoted

your ok with it please forward on to linus.

We usually haven't dong the fixup of cpu features yet at the point
setup() is run, thus your change will have no effect. You need to
actually go look at the CPU feature bits. (You can look a bit below in
that same code how it does for CPU_FTR_L3_DISABLE_NAP and
CCPU_FTR_CAN_NAP.

Dope, you're right.  I notice that we apparent do this for BTIC and DPM in this function though?

Also, it's 745x, those CPUs so far always existed in their 744x version
without L3 and no way to recongnize them via PVR afaik (until before
7447A). I would expect L3CR to just return 0. Is this not the case on
7447/7448 ? If yes, then there is no need to change the code...

Need to check.  I was lead to believe on 7448 they may have gotten ride of L3CR and thus my patch.  I do some digging internally to see what's happening with L3CR on 7448.

Ben.

quoted

- kumar

--

Some variants of 745x may not actually have the L3CR register.  Since
we mark which variants of 745x have L3CRs in the cputable we can
use that information to ensure that the mfspr L3CR will not cause
an exception in the processors that don't have the register.

Signed-off-by: Kumar K. Gala <redacted>

---
commit f706b6046f1fee29bdf3081dd783f7e482012165
tree 6d42ee61458ec94ac7d4567e3f0383dd1e47a537
parent d8ac10639b6a1ed900efbee38c18baaca31e64dc
author Kumar K. Gala [off-list ref] Thu, 22 Sep 2005

14:47:52 -0500

quoted

committer Kumar K. Gala [off-list ref] Thu, 22 Sep 2005

14:47:52 -0500

quoted

 arch/ppc/kernel/cpu_setup_6xx.S |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/ppc/kernel/cpu_setup_6xx.S

b/arch/ppc/kernel/cpu_setup_6xx.S

quoted

--- a/arch/ppc/kernel/cpu_setup_6xx.S
+++ b/arch/ppc/kernel/cpu_setup_6xx.S

@@ -212,9 +212,11 @@ setup_745x_specifics:
      * the firmware. If any, we disable NAP capability as
      * it's known to be bogus on rev 2.1 and earlier
      */
+BEGIN_FTR_SECTION
     mfspr    r11,SPRN_L3CR
     andis.    r11,r11,L3CR_L3E@h
     beq    1f
+END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
     lwz    r6,CPU_SPEC_FEATURES(r5)
     andi.    r0,r6,CPU_FTR_L3_DISABLE_NAP
     beq    1f

Dope, you're right.  I notice that we apparent do this for BTIC and  
DPM in this function though?

Yes, those bits are buggy. Good catch

Ben.

On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:

quoted

Dope, you're right.  I notice that we apparent do this for BTIC and  
DPM in this function though?

Yes, those bits are buggy. Good catch

And no, in fact, my brain is buggy... On ppc32 we identify first, then
fixup, then only do the call_setup_cpu ! That's why the Idle NAP code
actually goes test the feature bit.

I think ppc64 does it the other way around. ppc64 certainly _requires_
taht the fixup has not yet been applied while running early_setup() as
it may change some CPU features according to firmware properties.

So in the merged kernel, we need to be extra careful here. I think we
should go the ppc64 way actually and apply the fixups later. But that
means fixing the code in cpu_setup_6xx.S indeed.

Ben.

On Oct 6, 2005, at 7:33 PM, Benjamin Herrenschmidt wrote:

On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:

quoted

quoted

Dope, you're right.  I notice that we apparent do this for BTIC and

quoted

quoted

DPM in this function though?

Yes, those bits are buggy. Good catch

And no, in fact, my brain is buggy... On ppc32 we identify first, then
fixup, then only do the call_setup_cpu ! That's why the Idle NAP code
actually goes test the feature bit.

I think ppc64 does it the other way around. ppc64 certainly _requires_
taht the fixup has not yet been applied while running early_setup() as
it may change some CPU features according to firmware properties.

So in the merged kernel, we need to be extra careful here. I think we
should go the ppc64 way actually and apply the fixups later. But that
means fixing the code in cpu_setup_6xx.S indeed.

Well, since we do this early on ppc32, my patch should be ok than. (And is need on 7448, do to some crazyness in how L3CR works on various versions of 7448).

I'd like to see we push this now and worry about "fixing" all of cpu_setup_6xx.S when we move it over to arch/powerpc

- kumar