[lkml]   [2005]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [spi-devel-general] Re: [PATCH/RFC] SPI: add DMAUNSAFE analog
    On Thu, Dec 15, 2005 at 02:33:22PM -0800, Greg KH wrote:
    > On Fri, Dec 16, 2005 at 01:17:56AM +0300, Vitaly Wool wrote:
    > > I haven't heard of USB device registers needing to be written in IRQ
    > > context. I'm not that well familiar with USB, so if you give such an
    > > example, that'd be fine.
    > The USB host controller drivers routienly allocate memory in irq context
    > as they are being asked to submit a new "packet" from a driver which was
    > called in irq context. Lots of USB drivers also allocate buffers in irq
    > context too.
    > So, please, drop this line of argument, it will not go any further.

    I know almost nothing about SPI, so I could be completely wrong here,
    but I think I might have an inkling about the problem Vitaly is trying
    to solve. Note that I haven't actually had to make a design like this
    work, so I'm not intimately familiar with the issues, but I have seen
    designs that I believe would suffer from the following problem.

    Suppose you have a chip (temp sensor for example) controlled via serial
    bus (I2C is what I'm familiar with, from what I know this scenario would
    apply to SPI too) that *also* drives an interrupt into the CPU. You
    want to be able to share the interrupt, so you need to be able to
    turn off the interrupt from IRQ context (when the driver decides that it
    is going to handle the interrupt). But the only way to turn off the
    interrupt on the peripheral chip is to send a message via the serial
    bus. Now if the IRQ gets entered while the serial bus is busy servicing
    another device, the device driver author is in trouble - she can't
    return from the irq handler until she's acked the IRQ and the device is
    no longer asserting the interrupt, but she can't ack the IRQ without
    sending a command on the serial bus, which she can't do because the bus
    is currently in use higher up the call stack.

    Now one could argue that this design is broken (requiring a slow serial
    bus access to ack an irq means that you end up with very high-latency
    interrupt handlers) but it's my impression that such designs are not
    unheard of in the embedded world.

    You end up having to leave the interrupt masked on return from the
    irq_handler routine, ack it at a higher level at some later point, and
    then re-enable it.

    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-12-16 04:37    [W:0.026 / U:18.692 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site