David Hawkins wrote:
So are you saying you would DMA to a register with a specific endianness.
Typically, yes. Theoretically, a device could be programmed to handle any number of bit- and byte-endianness, but I haven't found one. Most of them time, it's just a shift register and so which means the bit and the bytes have to be in the same order. The result is that the endianness of the host processor has to to match the endianness of the audio samples.
The Freescale SSI has this problem. When the SSI is on an i.MX, it only supports little-endian samples. On an MPC8610, it only supports big-endian samples.
The two situations I can think of with a DMA controller moving data that requires a specific endianness are;
- DMA controller scatter-gather descriptor entries. These would normally consist of source, destination, length, and next pointers in a specific endianness format.
I don't think this applies. The descriptor entries are "manually programmed"; that is, you write to individual fields in the descriptor one at a time.
- DMA from memory to a FIFO destination address that expects little-endian format 16-bit values.
Yes, this is what audio drivers do.
In either case, you would use the byte-conversion routines to serialize the descriptor entries in memory, or in the source buffer, into the correct endianness before performing enabling the DMA.
Very true. However, this means that if the original data is in the wrong endian, you have to have a middle layer that modifies the data when copying from the source buffer to the DMA buffer. This adds overhead.
If Vivek's application correctly serializes any endian-specific data before using the MPC8349EA DMA controller, then he should have no issues.
Yes, but it may take him weeks to find all the places in the where the endianness matters.
Does an audio driver differ in any respect to the above situations?
Not really.