Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Eduardo Horvath <eeh@netbsd.org>
List: tech-kern
Date: 03/10/2006 16:58:08
On Thu, 9 Mar 2006, Garrett D'Amore wrote:
> Jason Thorpe wrote:
> > 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.
You need to expand your imagination a bit. On several architectures the
bus space tag contains a jump table to the actual bus space accessor
function. By replacing individual vectors in the table you can make the
bus space calls do anything you want. Granted, most architectures
implement bus space accessor functions as macros instead of indirect
function calls for efficiency reasons. But in some cases you may need to
bite the bullet and do things the slow way.
Eduardo