Jason Thorpe wrote:
>
> On Mar 9, 2006, at 1:01 PM, Garrett D'Amore wrote:
>
>> Okay.  I think there is consensus that if I provide a compile time
>> option so that on these ancient boxes the code path is no longer, then
>> its okay.   I'll probably do that.  Frankly, I'll probably just do it so
>> that the code path is only longer on those boxes that need it.  :-)
>
> If there is an #ifdef (and I don't think there should be--- I just
> think we should not have "register access function pointers" in the
> com_softc), it should be to DISABLE the flexibility, rather than
> enable it.
Okay, well I will defer to whatever the consensus is.  I do want to have
*some* way to solve these without inventing new bus spaces for every
possible com variant though...

>
> But, again, I think the best way to handle this is:
>
> 1- bus_space tags to deal with the 8-bit vs 32-bit bus access
> requirements
Reasonable, I think.  The only problem I have is how to distinguish
between these cases:

    1) a part that has 8-bit registers that are located within the same
32-bit word, and you access them with masks.  (I guess in this case that
these must be idempotent for read access, and write accesses are some
how "safe", e.g. a write is ignored unless a bit enabling the write is
set or a register that ignores zero bits or somesuch).  (Also, only
8-byte registers might have this stride applied.  So you can't just
universally apply e.g. a shift to the offset.

    2) a part that has its registers spaced by e.g. 4 vs. 2 vs. 1 byte
apart (stride)

    3) *which* byte of the 32-bit word (as an example) the part in #2
has the registers located in (usually either the top or bottom).

Bus space tags don't deal well with all of the possible options here.
>
> 2- Add a register offset map to deal with the different register
> ordering on different chips.
Exactly.  The bus_space_tags get let us deal with the issue of masking
and accessing 32-bits at a time, and the offset maps allow us deal with
pretty much everything else.

If folks like this, then I'm happy to implement it this way.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191