The PCI card itself gets a signal from the add-on card when an interrupt on
the serial ports occur. The PCI card generates the pci interrupt when this
is the case. The serial com driver should respond first, as that has an
interrupt priority of IPL_SERIAL. The four serial ports on the add-on card
are mapped onto com2-com5. The com driver will access the registers of the
16550 USART devices on the add-on card through the subregion of the PCI
card's pci_mapreg_map space. The driver for the PCI card should respond to
the interrupt after the com driver, as the PCI card driver's interrupt
priority is IPL_TTY. Am I correct in this assumption? The PCI card driver
will clear the interrupt. The PCI card can also do a whole lot of other
stuff that isn't being used in the test.

We measured the delay between rising edge of the interrupt from the add-on
card to when the registers on the USART are being accessed with a logic
analyser. The logic analyser was set to trigger on a long delay between the
interrupt and the register access.

Everything works great until something memory/disk intensive runs (like a
compile of a large project). The man pages seem to suggest that only
splhigh(), spllock() and splserial() would block the com driver's
interrupts. I wouldn't have thought that such high level blocking would
block for several milliseconds...? Say a lower priority interrupt triggers
(say IPL_TTY) and an isr starts running to handle that, and while the isr is
still busy, another interrupt of a higher priority (say IPL_SERIAL) occurs.
My understanding is that it would break out of the lower priority isr and
run the higher priority isr and then return to the lower isr. Is that
correct?

----- Original Message -----
From: "Manuel Bouyer" <bouyer@antioche.eu.org>
To: "Daniel Brewer" <danielb@cat.co.za>
Cc: <tech-kern@NetBSD.org>
Sent: Monday, August 18, 2003 9:14 PM
Subject: Re: what blocks splserial?


> On Mon, Aug 18, 2003 at 04:47:03PM +0200, Daniel Brewer wrote:
> > Hi
> >
> > We have a serial piggy-back add-on card to one of our PCI card and we're
> > seeing some oddities with the interrupts.
> >
> > The serial add-on causes the PCI card to generate interrupts as
necessary.
> > In the attach function for the pci card, we use bus_space_subregion and
> > config_found_sm to attach the 4 extra serial com devices. There is a
> > transparent channel through the PCI card to the serial add-on, so the
> > registers on the serial device are mapped directly into the register
memory
> > space on the PCI card. We've written a test program that writes and
reads
> > data to all 4 serial ports on the add-on card (mapped to tty02-tty05).
> >
> > Everything works great under normal operation. But, we've noticed that
> > running the test program and a compile at the same time, can sometimes
cause
> > the loss of a few characters. Digging deeper, we've measured the time
> > between when the card raises the interrupt line and when the driver
accesses
> > the registers on the serial card to handle the interrupt is sometimes
really
> > long when compiling and reading/writing to the com ports (up to about
> > 7ms!!!). At 115200 baud, that's quite a few characters.
> >
> > The com devices are using the IPL_SERIAL level interrupts and access the
> > serial-port registers. The PCI device's driver is responding to IPL_TTY
> > level interrupts, and it is the device that will actually clear the
> > interrupt pin on the PCI device's controller chip. So, what could block
the
> > IPL_SERIAL level interrupts for several milliseconds while a compile is
> > occurring?
>
> I don't understand... is your interrupt handler registered with
> IPL_SERIAL or IPL_TTY ?
>
> Also you don't say on which port you're working. IPLs don't have the same
> priority on all ports.
>
> --
> Manuel Bouyer <bouyer@antioche.eu.org>
>      NetBSD: 24 ans d'experience feront toujours la difference
> --
>