[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[David Hawkins]

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