[lkml]   [2005]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: tricky challenge for getting round level-driven interrupt problem: help!
    alan, thanks for responding directly.

    the internet is down at the moment (at least, bt's bit is) so
    your continued direct responses, if you have the time, greatly

    i can't get http or ssh access to _anywhere_, but bizarrely,
    smtp is getting through.

    [sod bt. royally.]

    On Wed, May 04, 2005 at 02:50:01AM +0100, Alan Cox wrote:

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

    lots of experience, then, you'd say? my experience with doing this
    kind of stuff is kinda limited (doesn't stop me trying) so your
    response is really appreciated.

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

    bleh :)


    i believe i get it: you raise a level-triggered interrupt which _stays_
    raised until such time as your fifo is empty.

    the original protocol that was written [by somebody even less
    experienced than i] was designed the way it is because the PIC chip
    that's connected to the ARM only has *one* interrupt.

    that interrupt is triggered:

    * on a port read (there are four 8-bit ports!)
    * on a port write
    * by the serial port
    * by the timer

    [skip this bit if you're busy, it's just background info]

    so there's now a _thousand_ lines of hand-written assembly code
    which took well over a year to write and debug on the PIC, that
    implements the state-machine to deal with the GPS on the serial
    port, interleaving the "device status" info into the GPS data
    stream, getting the GPS data stream over the 8-bit port and
    receiving LCD commands over the 8-bit port, interpreting them
    and then feeding the LCD.



    assuming that i can handle the pic having only a single interrupt, then
    does the process go something like this (for read, e.g.):

    1) the ARM unmasks read interrupts when it's ready.

    2) when the PIC has data to be read (which is only ever a single byte),
    it asserts the level-triggered read interrupt to the ARM.

    3) the ARM receives the interrupt, and reads the byte. the _act_ of
    reading the byte causes an edge-triggered interrupt to the PIC.

    5) the first thing the PIC does in its [one] ISR is to de-assert the
    read interrupt. why? because there is only a one byte buffer.

    we have an additional step in the chain - step 4 - which is:

    4) in the ISR, the ARM goes into a tight loop checking that the
    PIC has cleared the level-triggered interrupt.

    the reason for checking this is so that when we come out of the
    ISR on the ARM, the PIC is *SOOO* slow - it's only 6mhz after
    all - that sometimes (frequently, in fact - about 1 in every
    50 times) it hasn't got round to clearing the level-driven
    interrupt by the time we come out of the ARM ISR (!)

    the problem we're having is actually worse than that.

    sometimes something goes screwy and _despite_ having this loop-check,
    we get duplicated characters.

    sometimes, even worse, we lose sync, and the ARM sits there in the

    i was getting _so_ fed up with this that i was thinking that there
    was a problem with the approach being taken.

    hence the redesign to do alternate read-write-read-write, and making
    reads exclusive of writes, etc.

    awful. just awful :)

    ... so - in your opinion, alan, is the old approach we had
    actually _on_ the right lines?

    also, are you going to ukuug in august, it being _in_
    aberystwyth and all :)


    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 23:03    [W:0.055 / U:1.088 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site