threaded interrupt handlers: what if hardirq part not disables device interrupt?

[Remy Bohmer]

Hello Thomas, Peter,

While getting the new RT6-patch working properly on a Atmel AT91
board, I ran into the problem that the atmel-serial driver misses
characters since its interrupt hander runs in thread context and it
cannot keep up with the 1-byte RX 'FIFO' of the DBGU port.
It makes the terminal slow and broken.

To solve this issue, I thought to make proper use of the threaded
interrupt mechanism and make:
* 1 part run in hard-irq context, only handling the RX-fifo, push it
in a queue and
*  wake the irq-thread to process the data from the queue.

Digging through the interrupt code I read that the hard-irq part
should disable the device interrupt, while the irq-thread needs to
reenable it after it has handled it completely.
If I am going to use the queue idea as depicted above, the hard-irq
should keep on being enabled forever, and just wake up the irq-thread
once it has pushed data in the queue, on which the irq-thread could
process it on its own.
This seem to be against the principles as on which the current
interrupt handling code is based. It does not even work properly if I
do it this way.
Disabling the device interrupt in the hard-irq until the irq-thread
reenables it again, does not solve the problem since characters will
be missed.

As alternative solution I can do the following as well:
The driver now has a tasklet used for processing the queue. If I add
IRQF_NO_THREAD as irq-flag, the thread is not created and the handler
runs completely in hard-irq context. This seems to work okay, but it
does not feel as the right solution.

How is this supposed to work? Do you have better ideas how to solve
situations like this?

Kind regards,

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