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

[Detlev Zundel <dzu@denx.de>]

Hi Jerry,

> 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.

Isn't this "natural" for a 64-bitter?

>> 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.

Why 4 bytes?  3 + 1 + 12 = 16 as stated.

>>> or this also might work,
>>>
>>> struct NS16550 {
>>>        unsigned long rbr;
>>>        unsigned long pre_padrbr[3];
>>>        :        ^^^^
>>>        :
>>> };
>
> Again, a stride of 4 bytes, *not* 16.

4 * sizeof(unsigned long) = 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).

It's a 16-byte stride, although the register shows up neither at the
top, nor at the low end, but "slightly to the left", i.e. at offset 0x3
;)

> 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.

That's what my previous hack offered - REG_TYPE for the actual "size" of
accesses and REG_SIZE for the stride.  Now that you mention it, one
should probably use REG_TYPE and REG_STRIDE...

Cheers
  Detlev

-- 
Cyberwar is certainly not a myth. But you haven't seen it yet, despite
the attacks on Estonia. Cyberwar is warfare in cyberspace. And warfare
involves massive death and destruction. When you see it, you'll know it.
                           -- Bruce Schneier, Nov. 2007
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de