Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Jason Thorpe <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/09/2006 13:30:34
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
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
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 D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191