On Wed, Oct 07, 2009 at 01:41:33, [email protected] wrote:
> Greetings,
>
> > > Example: LL = Left LSB, LM = Left MSB, RL = Right LSB, RM = Right MSB
> > >
> > > data to copy : LL LM RL RM
> > > interpreted as dword: RM RL LM LL (cast above memory to unsigned int)
> > >
> > > data sent by McASP : RM RL LM LL (always big-endian unless companding
> is
> > > turned on)
> >
> > Hmm, where is the ending issue occurring? I don't think EDMA causes
> endian
> > change when ACOUNT is set to 4. There is no ACOUNT=4 example in the EDMA
> > user guide, but the two byte burst transfer example in section 3.4.2 in
> the
> > spru (http://focus.ti.com/lit/ug/sprue23d/sprue23d.pdf) did not show any
> > endian swap.
>
> I think this EDMA transfer is a special case because the destination
> address is a register.
David and Troy, you are both right and Mukul (from TI h/w team) explained
this with a detailed example which I am reproducing here:
"
DM6441 is a little endian device
So if you have 0x44332211
Its arranged in memory as
Addr data
0x0 0x11
0x1 0x22
0x3 0x33
0x4 0x44
The McBSP shifts out data with MSB first
So for the 32 bit case the EDMA will put 0x44332211 in the DXR register,
and McBSP will shift it out as
0x44 0x33 0x22 0x11
(time -->) t0 t1 t2 t3
When you change ACNT=2, and still have the source address as 0x0 the EDMA
will pick 0x2211 in the first XEVT event and 0x4433 in the second XEVT
So the data will go out as
0x22 0x11 0x44 0x33
(time-->) t0 t1 t2 t3
So if the want it the data transferred in the 32 bit case the same way as
16bit then I think the data buffer would need to be arranged differently,
such that for the 32 bit case the data is:
0x22114433
0x0 33
0x1 44
0x2 11
0x4 22
"
[...]
>
> All in all, I would expect the behavior of the EDMA and ASP to vary by chip
> and
> silicon revision because we noticed a huge EDMA prioritization performance
> change
> between the DM6441 1.3 silicon and the DM6441 PG 2.1 silicon running the
> exact
> same code.
I think some system priority defaults changed between the two revisions.
Other than that, there was nothing else that could affect EDMA performance.
The kernel could try and restore prioritization parity between the two
versions; I don't see that happening currently though.
Thanks,
Sekhar
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
