From: Chuck Meade <chuckmeade@mindspring.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: MPC83xx SDMR setup error
Date: Thu, 22 Mar 2007 13:30:33 -0400 [thread overview]
Message-ID: <4602BD39.9020102@mindspring.com> (raw)
In-Reply-To: <E9D1DC31-9730-4431-9414-0870FDD3EAF6@kernel.crashing.org>
>> .... 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
next prev parent reply other threads:[~2007-03-22 17:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 14:30 MPC83xx SDMR setup error Chuck Meade
2007-03-22 16:13 ` Kumar Gala
2007-03-22 17:30 ` Chuck Meade [this message]
2007-03-22 17:57 ` Kim Phillips
2007-03-22 18:13 ` Chuck Meade
2007-03-26 20:10 ` Kumar Gala
2007-03-26 22:53 ` Segher Boessenkool
2007-03-27 0:22 ` Chuck Meade
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4602BD39.9020102@mindspring.com \
--to=chuckmeade@mindspring.com \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.