Hi,
I'm trying to make a PCI 2S1P Multi I/O card (NM9835 chip) work with
Linux 2.4.19. I've applied the 2.5.x linux-netmos.patch (with manual
patching of rejected hunks), and I can see this in the boot messages:
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport_pc: Via 686A parallel port: io=0x378
PCI parallel port detected: 9710:9835, I/O at 0xb800(0x0)
parport1: PC-style at 0xb800 [PCSPP,TRISTATE,EPP]
ttyS00 at port 0xb000 (irq = 9) is a 16550A
ttyS00 at port 0xb400 (irq = 9) is a 16550A
.....
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
lp0: using parport0 (polling).
lp0: console ready
lp1: using parport1 (polling).
The two PCI serial ports (incorrectly reported as ttyS00) are really
ttyS4 and ttyS5, but setserial reports unknown UART (with correct I/O
and IRQ), so they don't work until I do this:
setserial /dev/ttyS4 autoconfig
setserial /dev/ttyS5 autoconfig
I suspect that the parport_serial driver should be initialized after
the serial driver, so it can register the detected UARTs properly.
(I have the necessary drivers compiled into the kernel, no modules.)
The serial ports appear to work fine after the setserial autoconfig
commands. I haven't tested the NM9835 parallel port just yet - what
I really needed is more serial ports, but a PCI card with only two
serial ports (no parallel) was hard to find and twice as expensive ;)
I suspect the NM9835 may be a quite popular chip - any chances of
making support for it available in 2.4.x kernel series?
Thanks,
Marek
On Mon, Aug 05, 2002 at 11:00:52PM +0200, Marek Michalkiewicz wrote:
> I suspect that the parport_serial driver should be initialized after
> the serial driver, so it can register the detected UARTs properly.
> (I have the necessary drivers compiled into the kernel, no modules.)
You are correct; the same bug just got fixed in the 2.5 series.
> I suspect the NM9835 may be a quite popular chip - any chances of
> making support for it available in 2.4.x kernel series?
Unfortunately its all controlled by the link ordering, and serial is
buried in within drivers/char. Moving it before parport needs some
careful analysis and may very well end up breaking other stuff.
The simple answer for 2.4 may well be to move serial.c into
drivers/serial so it can be ordered into the right place on its own.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
> Unfortunately its all controlled by the link ordering, and serial is
> buried in within drivers/char. Moving it before parport needs some
> careful analysis and may very well end up breaking other stuff.
>
> The simple answer for 2.4 may well be to move serial.c into
> drivers/serial so it can be ordered into the right place on its own.
How about making register_serial() initialize the serial driver by
calling rs_init(), if it was not initialized yet? Works for me -
see below. Do you see any problems with this?
Marek
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport_pc: Via 686A parallel port: io=0x378
PCI parallel port detected: 9710:9835, I/O at 0xb400(0x0)
parport1: PC-style at 0xb400 [PCSPP,TRISTATE,EPP]
register_serial(): calling rs_init()
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS04 at port 0xac00 (irq = 5) is a 16550A
ttyS05 at port 0xb000 (irq = 5) is a 16550A
--- drivers/char/serial.c.orig 2002-08-03 02:39:43.000000000 +0200
+++ drivers/char/serial.c 2002-08-14 00:16:00.000000000 +0200
@@ -254,6 +254,7 @@
static struct tty_driver serial_driver, callout_driver;
static int serial_refcount;
+static int serial_initialized;
static struct timer_list serial_timer;
@@ -5385,6 +5386,10 @@
int i;
struct serial_state * state;
+ if (serial_initialized)
+ return;
+ serial_initialized++;
+
init_bh(SERIAL_BH, do_serial_bh);
init_timer(&serial_timer);
serial_timer.function = rs_timer;
@@ -5603,6 +5608,11 @@
struct async_struct *info;
unsigned long port;
+ if (!serial_initialized) {
+ printk("register_serial(): calling rs_init()\n");
+ rs_init();
+ }
+
port = req->port;
if (HIGH_BITS_OFFSET)
port += (unsigned long) req->port_high << HIGH_BITS_OFFSET;
On Wed, Aug 14, 2002 at 11:11:52AM +0200, Marek Michalkiewicz wrote:
> How about making register_serial() initialize the serial driver by
> calling rs_init(), if it was not initialized yet? Works for me -
> see below. Do you see any problems with this?
What are the bad effects of having rs_init called twice during
boot-up?
Tim.
*/
> What are the bad effects of having rs_init called twice during
> boot-up?
On the second call, it returns immediately because serial_initalized
is set. Or am I missing something here?
Marek