MPC5200 Cache coherency with BestComm issue

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

MPC5200 Cache coherency with BestComm issue

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

MPC5200 Cache coherency with BestComm issue

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

MPC5200 Cache coherency with BestComm issue

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

MPC5200 Cache coherency with BestComm issue (was: Lite5200 FEC Driver on linux 2.6 (updated))

Hi roger Using your latest tree still shows the packet checksum errors, despite XLB snooping being enabled. I think that the cache flush is required It really shouldn't be. Take a look at http://www.freescale.com/files/microcontrollers/doc/app_note/AN2604.pdf, page 3, 4th paragraph quote :