Re: tricky challenge for getting round level-driven interruptproblem: help!

[Alan Cox]

On Maw, 2005-05-03 at 22:56, Luke Kenneth Casson Leighton wrote:
> it only does level-based interrupts and i need to create a driver
> that does two-way 8-bit data communication.

Level triggered is generally considered a feature by people less than
200 years old 8)

> i would genuinely appreciate some advice from people with
> more experience than i on how to go about getting round
> this stupid hardware design - in order to make a RELIABLE,
> non-race-conditioned kernel driver.

Assuming you are using the core Linux IRQ code then you shouldn't have
any great problem. The basic rules with level triggered IRQ are that 

- You must ack the IRQ on the device to clear it either specifically or
as part of some other process.
- The device must raise the IRQ again if the irq condition is present
*at* or after the point of the IRQ ack (or in many implementations 'just
before' in fact)

the core Linux code deals with masking on the controller to ensure IRQ's
dont get called recursively, and ensuring an IRQ gets rechecked/recalled
on the unmask/exit path if it is still asserted.

So an implementation is much like a serial port fifo, assert the IRQ
until the PC has fetched all the bits. In fact the IRQ line is
essentially "NOT(fifo_empty)" and rechecked each time a byte is fetched.

*WAY* simpler than nasty edge triggered stuff 8)

Alan

-
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/