MPC83xx SDMR setup error

[Chuck Meade]

>> .... the CEN field will be set to
>> zero.  This means the SDMR buffer size will always be 512, rather than
>> the intended (and allocated) 1024 bytes.
> 
> What does this effect?  I agree the code is wrong.

The SDMA moves data between the QUICC Engine (which includes the units for
Ethernet, etc.) and external memory.  The buffer we are talking about
exists in on-chip MURAM, and is used internally by the SDMA controller.
The manual does not go into detail on its use.  It is pointed to by the
SDEBCR, which in one section of the manual is referred to as a "temporary
buffer base" and in another section as "SDMA CAM entries base".

This buffer can be set to sizes ranging from 512 bytes to 3Kbytes.  I
assume, based on this, that the size of this buffer affects SDMA performance.
The current code allocates a 1Kbyte buffer for this use, but does not
correctly set the buffer size to 1K, but rather it is left at 512 bytes.
This in itself is probably just a reduced performance issue, caused by
a coding error.

However, as I mention below, it is unclear whether the buffer alignment
requirement is 64 bytes or 4Kbytes.  The code aligns the buffer to 64 bytes.
If the alignment requirement is truly 4Kbytes, then it is conceivable that
with the current code, the SDMA controller could be overwriting MURAM that
it has not allocated, potentially owned by other controllers.  That would
be a much worse situation, and lead to some nasty and hard to find problems.

>> ..... The code
>> in arch/powerpc/sysdev/qe_lib/qe.c (line 254) that allocates this buffer
>> aligns it to a 64-byte boundary.  This is only correct if the manual 
>> section
>> 18.1.7, which requires a 4KByte alignment, is wrong.  Which manual 
>> section
>> is correct?
> 
> Hopefully someone at freescale will know.  I'd suggest possibly posting 
> a support request to them to see if you can get a clarification since 
> their UM is not self-consistent on the details.

I am hoping that some of the Freescale regulars on this list, Dave Liu,
Timur Tabi, Li Yang, Kim Phillips, will know and can comment.

Thanks,
Chuck