On Sat, 16 Sep 2000, Steve Woodford wrote:

> Hi folks,
> 
> The current driver for the Zilog 8530 serial chip and its derivatives is
> only partially machine independent, despite most of its guts being in
> /sys/dev/ic/z8530*.

True.

> The problem is that it can only have one type of "parent" zsc device,
> namely the native parent for each NetBSD platform which uses it. That
> interface is currently defined in <machine/z8530var.h> and is very
> specific to how the zs chip is wired up on each platform's hardware.

It could be made extensable as is - you just shove info into the MD
section of the chanstate, and have these routines switch to the right
thing. I'm not saying you SHOULD, but that you can. :-)

> So, along comes a VMEbus board with a bunch of Z8530 chips whose registers
> are directly mapped onto the bus. With the current state of the zs driver,
> there's no way I can write MI VMEbus glue to make it work. Not to mention
> the ports which can have a VMEbus attached, but don't have
> <machine/z8530var.h> ...

Then that's a good reason for z8530var.h to go away.

> My plan is to put a __BROKEN_ZS_DRIVER_ATTACHMENT define in the
> <machine/types.h> file of each port which currently has a
> <machine/z8530var.h>, and modify the zs driver to conditionally present
> the original not-quite-MI attachment interface or a new proper-MI
> interface depending on this #define. (Note: alpha and sgimips have a
> <machine/z8530var.h> header file, but don't seem to use the driver!)

Please don't do it this way. :-) Just move everyone to a better MI
interface. :-)

> None of the original functionality will be lost with the new interface.
> Specifically, there will be MI versions of zs_read_{reg,csr,data} and
> zs_write_{reg,csr,data} which will insert the optional delay between
> accesses. The only problem I could see with this was the mipsco port; it
> seems to do a dummy read of another hardware register as well as a delay.
> I'm not sure how to fix this one right now...

I'd recomend doing something a little different. Add a pointer to a table
of functions to either the zsc or channlestate structures (which ever
makes more sense). Then have the zsc attachment just fill this in. As all
of the zsc attachment is done in MD (or bus dependent) code, you won't
need to do anything in the MI code.

My concern with you having MI versions is that there are a lot of silly
things people have done with these chips, and so that'd be a lot of silly
adaptation which'd need to be in the MI code.

Oh, in this table of functions would be all of the same functions declared
in machine/z8530var.h now - the zs_{read,write}_{reg,csr,data}. Plus have
a slot for the clock changing routine, and for the mdioctl routine (both
of which are needed for macs). Eventually we should add DMA routines - one
to start the DMA of a block, and another to trigger the reading of any
bytes DMA'd into memory but not passed to the input routine.

> Other slightly oddball platforms are mac68k and macppc. These have CTS
> wired up backwards and need to flip the status bit in the CSR to
> compensate. I've added a flag to the MI code to take this into account.

Just let them use their own routine. :-)

The advantage of what I'm proposing is that 1) you don't really need to
change much code. Every port already has these routines, so all you need
to do is add the table (to /dev/ic/z8530sc.h), and have the zsc attach
routines fill it in. 2) quirks of different hardware are totally hidden
from MI routines. :-)

Take care,

Bill