[U-Boot] [PATCH] include/ns16550.h: Unify structure declaration for registers

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Detlev Zundel wrote:
> Hello Shinya,
> 
>> Detlev Zundel wrote:
>>> As I said, I understand now why there were different data-types involved
>>> although this was kind of non-obvious.  So I take it, you had a working
>>> configuration with REG_SIZE = 4, correct?
>> I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
>> are located at 0, +0x10, +0x20, ..., .

16 byte stride.  That is seriously odd.

> Ah, so you actually maintain an out-of-tree port.  How should I have
> foreseen that I break something that I don't even have the code to?
> 
>> In this case, I don't think REG_SIZE = 4/-4 works.  Let's see:
> 
> No surely not.  My replies were based on the (wrong) assumption that
> your board port was in U-Boot code.
> 
>> What I need is something like this:
>>
>> struct NS16550 {
>>        unsigned char prepad_rbr[3];
>>        unsigned char rbr;
>>        unsigned char postpad_rbr[12];
>>        :
>>        :
>> };

This is showing a stride of 4 bytes, *not* 16.

>> or this also might work,
>>
>> struct NS16550 {
>>        unsigned long rbr;
>>        unsigned long pre_padrbr[3];
>>        :        ^^^^
>>        :
>> };

Again, a stride of 4 bytes, *not* 16.

>> Makes sense?
> 
> Although I can see what you need, I would be lying if I said that this
> makes sense to me.
> 
>>> Can you enlighten me, why exactly the 8-bit accesses do not work on your
>>> hardware?  Is this because of a "too simplistic" address decoding logic?
>>> What endianness is your CPU using?
>> I don't know much about precise hardware logics, but the byte addresses
>> under 16-bytes-border are ignored.  I'm using a big-endian mips machine.
> 
> This does not make much sense to me, sorry.

The "16" of the "16-bytes-border" statement confuses me too.

It sounds like Shinya has some pretty odd (read "broken") hardware that 
is decoding the registers with a 16 byte stride, although his example 
above shows a 4 byte stride (less broken).

I would further deduce his hardware does not support byte write 
operations (I've never seen hardware that didn't support byte reads). 
I've had hardware that did not support byte writes, so s/w needed to 
write a word instead (given Shinya's description, the extra bytes are 
"don't care").  (I've also dealt with flash connections that only 
supported 64 bit writes - PITA!).

My guess is his processor limitations prevent byte writes so he has to 
do 32bit (4byte) writes, but his hardware decoding results in a 16 byte 
stride.  The result is setting REG_SIZE to 4 gives him the r/w access he 
needs (32 bits), but fails the stride.  Setting it to 16 gives him the 
stride he needs, but a 16 byte register is nonsensical and breaks the 
software.  My guess is Shinya needs another customization dial (I'm 
making this up) "REG_STRIDE" = 16 as well as "REG_SIZE" = 4.

[snip]

Best regards,
gvb