On Mon, May 18, 1998 at 11:01:02AM -0700, Chris G. Demetriou wrote:
> /*
>  * NOTE: This driver has been tested in TCOM "UNIX mode" with base address
>  * set to 0x200 and baud rate jumpers to "normal".  This code does NOT know
>  * about the 2x and 4x baud rates available on TCOM cards.
>  */
> 
> Are those global baud rate multiplier settings, or can they be set
> per-port?  (looking for a data point.)
> 
> I've been thinking that it probably makes sense to set things like
> this:
> 
> 	* as 'com' driver flags (interpreted by the attachment code),
> 	  when 'com' attaches directly to a bus and/or a per-port
> 	  multiplier is possible, and
> 
> 	* as driver flags for parent devices, when 'com' attaches to
> 	  a parent device pseudo-bus which has a global multipler
> 	  setting.
> 
> I've seen several examples now of the former, but I dunno if i've seen
> any of the latter.  Your card could be one.  8-)

The baud-rate multipliers are per-port settable using _jumpers_, nothing
can be changed in software.  It would be difficult to probe the jumper
settings in the driver (I guess it would be possible to transmit a character
and see how log it takes to do it, but this would be annoying because then
the driver would transmit "garbage" data at boot time).

> #define NSLAVES 8                       /* TCOM cards have 4 or 8 UARTs */
> #define STATUS_OFFSET   0x40            /* offset from board base address */
> 
> So, regardless of whether the card has 4 or 8 uarts, it always eats 8
> UARTs worth (64 bytes) of I/O space?

I'm not sure.  I haven't got any technical docs for the card.  The status
register may be address decoded separately, so it might be possible to use
the addresses between the last UART and the status register.  Dunno.

> Does it give you a good way of telling how many UARTs it actually has?

AFAIK, no.  The board has 4 or 8 UARTs and the status register (which
just contains a bit mask of UART interrupt outputs), that seems to be
all.

> Really, you should config_found() only the UARTs that you know are
> there (or, at least, the UARTs that are "supposed to be" there, but
> there may be no easy way to do the right thing (other than a driver
> flag, and if it always eats 64 bytes of I/O space that's probably a
> waste of time).

I don't think the I/O space costs that much - isn't it the interrupts
that ppl always run out of, anyway?

  -jm