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

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

[Kumar Gala]

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 <kumar.gala@freescale.com>

---
commit f706b6046f1fee29bdf3081dd783f7e482012165
tree 6d42ee61458ec94ac7d4567e3f0383dd1e47a537
parent d8ac10639b6a1ed900efbee38c18baaca31e64dc
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 22 Sep 2005 14:47:52 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> 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

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

[Benjamin Herrenschmidt]

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.

> - 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 <kumar.gala@freescale.com>
> 
> ---
> commit f706b6046f1fee29bdf3081dd783f7e482012165
> tree 6d42ee61458ec94ac7d4567e3f0383dd1e47a537
> parent d8ac10639b6a1ed900efbee38c18baaca31e64dc
> author Kumar K. Gala <kumar.gala@freescale.com> Thu, 22 Sep 2005 14:47:52 -0500
> committer Kumar K. Gala <kumar.gala@freescale.com> 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

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

[Kumar Gala]

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

> 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.

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.
>
>
>> - 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 <kumar.gala@freescale.com>
>>
>> ---
>> commit f706b6046f1fee29bdf3081dd783f7e482012165
>> tree 6d42ee61458ec94ac7d4567e3f0383dd1e47a537
>> parent d8ac10639b6a1ed900efbee38c18baaca31e64dc
>> author Kumar K. Gala <kumar.gala@freescale.com> Thu, 22 Sep 2005
>>
> 14:47:52 -0500
>
>> committer Kumar K. Gala <kumar.gala@freescale.com> 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
>

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

[Benjamin Herrenschmidt]

> 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.

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

[Benjamin Herrenschmidt]

On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:
> > 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.

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

[Kumar Gala]

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

> On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:
>
>>> 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.

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