Izumi Tsutsui wrote:
> In article <440CFA76.1070500@tadpole.com>
> garrett_damore@tadpole.com 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.
>>     
>
> Well, how about com_dio.c and com_frodo.c in arch/hp300/dev/ ?
>   
I looked at com_frodo.  It uses a bus space, but doesn't need one of its
own.  That is good.  In my case this stupid com port is the only thing
on this bus that behaves this way (with a 4-byte stride.)
>   
>> My proposal is to *change* com so that instead of using fixed offsets,
>> it uses a register look up table.  E.g.
>>
>> bus_offset_t   sc_regoffs[NCOM_PORTS];
>>
>> #define   GETREG(x)   bus_space_read_1(bst, bsh, sc_regoffs[x])
>>
>> Then the various attachment points can populate these registers as they
>> see fit.
>>     
>
> IMHO, if address mapping (sparse address etc.) is bus specific
> it should be handled by bus_space. On the other hand, if the
> (unusual) mapping is the device specific, it should be handled
> by each driver.
>   
Its not really bus specific, its chip & bus combination specific.  And
the other bit here is that some bits (like aucom) are really different.

I'm trying to get out of having to write bus space drivers just to
accomodate differences in com register layout.  Its kind of like using a
jackhammer to build cabinetry...


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