Hi Timur,
When you are dealing with a driver, register accesses need to be in a specific format. The MPC8349EA has some of its registers in big-endian format, and others in little-endian format. Regardless of the mode you operate your processor, you will *have* to use the correct byte-swap functions.
That's why we use cpu_to_be32() to write to big-endian registers. On a big-endian processor, this macro doesn't modify the parameter. So,
*p = be32_to_cpu(12);
will be compiled to
*p = 12;
On a little-endian process, the macro will do a byte-swap.
This macro, and others like it, eliminates the need to have two different versions of the code.
Sure. I wasn't pointing out the clarification to you, but to Vivek as it seemed like he had limited experience with endianness issues.
DMA would be used to move a block of data, not to manipulate a register.
I can see you've never written an audio driver before. The data itself has endianness, and the register may require the data to appear in one endian or another. If
Note that I'm was not trying to be antagonistic here, so no offense was intended in any my response to your message. It seemed to me that Vivek was not very experienced with endianness issues so wanted to clarify your application examples - to Vivek.
I haven't written an audio driver, so I'm interested in learning more.
So are you saying you would DMA to a register with a specific endianness. The two situations I can think of with a DMA controller moving data that requires a specific endianness are;
1) DMA controller scatter-gather descriptor entries. These would normally consist of source, destination, length, and next pointers in a specific endianness format.
2) DMA from memory to a FIFO destination address that expects little-endian format 16-bit values.
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. So the discussion on serializing data into a source buffer applies to this case too.
If Vivek's application correctly serializes any endian-specific data before using the MPC8349EA DMA controller, then he should have no issues.
Does an audio driver differ in any respect to the above situations?
Thanks for the feedback.
Cheers, Dave