[lkml]   [2005]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: tricky challenge for getting round level-driven interrupt problem: help!
    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)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-04 03:54    [W:0.021 / U:11.176 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site