RE: questions about 8250 uart support for adhoc boards

["Stuart MacDonald" <stuartm@connecttech.com>]

From: On Behalf Of Rob Prowel
> Russell King wrote:
> > You don't even need to do that.  Just configure SERIAL_8250_NR_UARTS
> > and SERIAL_8250_RUNTIME_UARTS appropriately for your 
> system.  There's
> > absolutely no need to build any of the additional modules.
> >   
> Unfortunately what I'm seeing in 2.6.20.1 seems to differ 
> from this.  If 

PC104 is really an ISA bus. The ISA ports are stored in a table in the
8250 driver (instead of allocated dynamically like PCI ports); the
config option _NR_UARTS just tells the driver how large to make the
table.

> I use the options below:
> 
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_NR_UARTS=32

This makes the internal table be 32 ports big. The first four ports
end up configured for legacy/standard com ports, the rest are
unconfigured. You should be able to see them as unknowns with
setserial.

> CONFIG_SERIAL_8250_RUNTIME_UARTS=16
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_MANY_PORTS=y
> # CONFIG_SERIAL_8250_FOURPORT is not set

All _FOURPORT does is specifically config ports 4-7 in the table to
have specific address/irqs for the FourPort board. What you do with
setserial is then change that config info to match your board.

You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it
looks like you don't. As long as _NR_UARTS is big enough, thus making
the internal table big enough, you should be able to configure, with
setserial, any of the ports in the table, including the first four.

> Then I can only access ttyS0 through ttyS3 sith setserial.  
> Only after I add
> CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do 
> anything with the 
> additional ports.  I would otherwise get the evil setserial: invalid 
> parameter error.

Very odd. You get this error when doing "setserial /dev/ttySxx", no
configuration? If so, that would imply that the table wasn't made big
enough, and the unconfigured ports haven't been registered with the
serial core.

> OK.  Fair enough.  My question then becomes, how does the driver deal 
> with this now? scan all applicable uarts when any relevant 
> interrupt is 
> detected (as identified in setserial)?

With our boards, the multiport is just a status register; it shows
which port has produced the interrupt, so the driver doesn't have to
loop through all the ports on the board looking for the correct one.
It doesn't actually enable/disable the sharing of the interrupt. The
setting of "irq 12" on multiple ports (from your original post) is
what enables the sharing, from the driver-side view. Maybe your
hardware is unusual and requires this ISR port to be set properly to
enable sharing; more likely is that the board itself has one or more
jumpers to set which interrupt it's using, and that's what enables the
sharing from the hardware-side view.

If I get some time tomorrow, I'll set up 2.6.20.1 and see what the
current options are doing.

If you can't get your board working, we have similar boards that do.

..Stu

-- 
We make multiport serial products.
http://www.connecttech.com/
(800) 426-8979

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/