In article <440DB884.2070900@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.)

Well, the frodo is not a real bus but a custom chip which
has four 16550 compatible UARTs with a 4-byte stride.

Please take a look at hp300/dev/frodo.c, then you can see
the frodo is a pseudo bus to handle these children, and
I actually added bus_space ops in frodo.c only for them.
(though bus specific hooks are also required by DIO devices
 and few other intio devices use bus_space functions)

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

Hmm, but someone could also say "bus_dma(9) is too complicated
and painful to handle simple ISA DMA bounce buffer."
Is this reasonable for you? ;-)

Even if you changed MI com(4) driver to use sc_regoff[]
method instead of MD bus_space ops with a jackhammer,
you also have to change *all* existing com(4) attachments
in each port and bus to initialize each sc_regoff[] values.
If you miss some of them, it silently fails and it would
cause some serious trouble because com(4) device is often used
as a serial console and users can't see any messages on it.

BTW, there was a similar discussion "how these
devices with sparse address space should be handled"
when I was working on wdc(4) driver for macppc port:
http://mail-index.netbsd.org/tech-kern/1998/10/25/0000.html

At that time, the conclusion was it should be handled by bus_space
because some ports (especially amiga) already had method to handle
strides. (Though wdc(4) has changed later to have individual
bus space handles for each regsiters to handle shadow registers,
which could be at the different places even on the same bus, IIRC)

On the other hand, as Jason said in the above discussion,
some existing drivers like dp8390.c use your sc_regoff[]
(or sc_reg_map[]) method. In this case, some MD backend drivers
really have weird register mappings even on the same bus.
(see macppc/nubus/if_ne_nubus.c etc.)

So, if some com(4) variants could have more complecated
quirks (not only the "stride"), it's acceptable to use
reg_map[] method for me, but with a quick grance current
aucom(4) (arch/mips/alchemy/dev/aucom*.[ch]) seems to have 
independent data registers for RX and TX while MI com assume
there is only one common data regsiter. In this case,
I have a feeling that we should split current com(4) driver
into a generic common part and register access functions
rather than just adding simple reg_map[] method.

Anyway, the implementation should be determined by how it
is reasonable or consistent, not how much work is needed ;-)
---
Izumi Tsutsui