Ignatios Souvatzis wrote:
> On Wed, Mar 08, 2006 at 10:47:44AM +0000, Steve Woodford wrote:
>   
>> On Tuesday 07 March 2006 03:13, Garrett D'Amore wrote:
>>
>>     
>>>     2) use a separate bus space.  I don't know of any existing
>>> examples outside of my AR5212 com driver.  In this case I had to
>>> implement a pretty hefty amount of bus space logic *in com_arbus.c". 
>>> This seems ugly and unwieldy.
>>>       
>> It's also one of the only ways to go.
>>
>>     
>>> #define   GETREG(x)   bus_space_read_1(bst, bsh, sc_regoffs[x])
>>>       
>> If the underlying bus does not support byte-wise read/writes, this'll 
>> still have to bounce through a bus_space(9) shim layer. I've worked with 
>> hardware which supports 32-bit access only to those registers, for 
>> example.
>>
>> Perhaps a compromise is called for. Add some accessor function pointers 
>> to com_softc, to be filled in by the bus-specific code.
>>     
>
> Uhm - in my book, those accessor functions are called bus_space_read_foo()!
> I don't like every other port to be penalized on com just because one of 
> them doesn't want to do a bit of legwork like everybody else in that 
> situation did. Some of us use com ports at 115200 or 230400 bps.
>
> Besides - as soon as you have one other device with that access method,
> it's actually less work!
>   
Yes, except when the differences are not necessarily just bus-specific,
but also *chip* specific.

In the two cases I'm looking at, one has a split TX/RX data register
(not shared) so cannot be handled easily by a bus_space (at least not
without teaching the bus space about the details of this particular com
chip!), and in the other case the com chip is the only device on this
bus that exhibits this "weird" behavior.

    -- Garrett
> Regards,
> 	-is
>   


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