MPC5200 Cache coherency with BestComm issue

MPC5200 Cache coherency with BestComm issue

[roger blofeld]

>Hi Roger
>
>> By experimenting I have found that the BestComm and FEC work without
>>the cache flush provided CPU_FTR_MAYBE_CAN_NAP is removed from the
>>cputable (nap disables snooping) and that CPU_FTR_NEED_COHERENT is
>>added to the cputable (turns on "M" bit in BAT/PTE so that the XLB
has
>>a chance of seeing a global transaction).
>>  
>>
>Thanks for the info.
>
>The nap thing was indeed obvious ... The proper way to deactivate it 
>would be in lite5200.c
>I added the powersave_nap = 1; as an example on how to allow it to
nap. 
>I'll probably comment it out by default with a note.
>
>For the CPU_FTR_NEED_COHERENT, are you sure it's required ?
 >From my understanding of the G2Core manual, the M bit must be set if 
>you want the G2Core
>to assert the global signal when it access memory. Here, we don't care

>since only the G2Core is snooping on the bus. So that should not be
required ...
>
>
>    Sylvain

Sylvain,
 You are correct. The CPU_FTR_NEED_COHERENT is not required. Perhaps
the solution is to only turn on powersave_nap if CONFIG_PPC_BESTCOMM is
not selected.
-rb




		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 

Re: MPC5200 Cache coherency with BestComm issue

[Sylvain Munaut]

Hi Roger

>
>Sylvain,
> You are correct. The CPU_FTR_NEED_COHERENT is not required. Perhaps
>the solution is to only turn on powersave_nap if CONFIG_PPC_BESTCOMM is
>not selected.
>  
>
Pull the latest tree. I've just commented it out with a note.
I didn't rip it off so that people copying lite5200.c for their own 
board know how to activate
it if they need to ...
It can also be controlled from userspace /proc/sys/kernel/powersave-nap

You just need to be aware of the consequences ( like USB not working 
either ! ) if you want
to save power.


    Sylvain

Re: Lite5200 FEC Driver on linux 2.6 broken? (again)

[Dale Farnsworth]

On Tue, Nov 16, 2004 at 10:26:09AM -0800, roger blofeld wrote:
> Retransmissions from the lite5200 work OK now, but the occasional ACK
> packet is sent from the lite5200 with a bad checksum causing
> retransmissions. Perhaps another patch would fix this problem too?

I too have seen occasional errors, but I don't think it's a software
issue.

-Dale

Re: MPC5200 Cache coherency with BestComm issue

[roger blofeld]

Sylvain,
 By experimenting I have found that the BestComm and FEC work without
the cache flush provided CPU_FTR_MAYBE_CAN_NAP is removed from the
cputable (nap disables snooping) and that CPU_FTR_NEED_COHERENT is
added to the cputable (turns on "M" bit in BAT/PTE so that the XLB has
a chance of seeing a global transaction).

I don't know if that will work for all G2_LE cores, but it seems
required for the 5200.
-rb

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: MPC5200 Cache coherency with BestComm issue

[Sylvain Munaut]

Hi Roger

> By experimenting I have found that the BestComm and FEC work without
>the cache flush provided CPU_FTR_MAYBE_CAN_NAP is removed from the
>cputable (nap disables snooping) and that CPU_FTR_NEED_COHERENT is
>added to the cputable (turns on "M" bit in BAT/PTE so that the XLB has
>a chance of seeing a global transaction).
>  
>
Thanks for the info.

The nap thing was indeed obvious ... The proper way to deactivate it 
would be in lite5200.c
I added the powersave_nap = 1; as an example on how to allow it to nap. 
I'll probably
comment it out by default with a note.

For the CPU_FTR_NEED_COHERENT, are you sure it's required ?
 From my understanding of the G2Core manual, the M bit must be set if 
you want the G2Core
to assert the global signal when it access memory. Here, we don't care 
since only
the G2Core is snooping on the bus. So that should not be required ...


    Sylvain