Bruce Martin <brucem@cat.co.za> writes:

> Does anybody know how we could do this? The problem I see is declaring two 
> different things for the "same" device: e.g.
>  tty00 at isa? ...
>  tty00 at pci? ...
> and things like
>  attach tty00 at isa...
>  attach tty00 at pci...
> 
> So, that is my first concern. Any suggestions on having two sets of files 
> (only really having the bus space accesses to registers different) for a 
> device with the same name, but mounted differently.

Not a problem at all. You'll want an entry in sys/conf/files like so:

device xcom: tty
file dev/ic/xcom.c              xcom

where xcom.c is the back-end "meat" of the driver,

and then in sys/dev/pci/files.pci:
attach xcom at pci with xcom_pci
file dev/pci/xcom_pci.c         xcom_pci

and sys/dev/isa/files.isa:
attach xcom at isa with xcom_isa
file dev/isa/xcom_isa.c         xcom_isa

where xcom_pci.c and xcom_isa.c are responsible for finding and
mapping those variants of the device. Plenty of drivers do this.


> The next concern is interrupts. The serial piggyback will use the same 
> interrupt line as the I/O card it is on. So, let's say an interrupt occurs, 
> the I/O card gets it, and sees that it is not for it, but the serial card. 
> Could I just return 0, and would this mean the serial card would check its 
> interrupts, if it were sharing the same interrupt?

If both the serial driver and the I/O card driver are registered for
the same interrupt, the interupt-handling functions will all be called
until one of them claims it by returning 1. I'm not sure how
predictable the order is; the best thing is if both the main I/O card
driver and the serial piggyback can recognize when an interrupt is for
them.


> Last concern, I promise! ;) The accesses to both I/O Card and Piggyback 
> Serial are through the same set of Base Address Registers, living on the I/O 
> card. Can I map these same BARs for both drivers?

Not directly; the address-space accounting in the bus_space code will
prevent multiple mappings done this way. 

It sounds like you're going to have to work through the I/O card in
order to find the piggyback card anyway, so it might make sense to
attach the piggyback there, rather than directly to the pci bus. So
instead of the "xcom at pci" given above, you might have:

device iocard {}:
attach iocard at pci
file   dev/pci/iocard.c         iocard

attach xcom at iocard with xcom_iocard
file   dev/pci/xcom_iocard.c    xcom_iocard

Then, the iocard code can be responsible for locating the piggyback
and setting up the register access to it, possibly through
bus_space_submap().

        - Nathan