Re: [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.

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

Relevant Pages

  • Re: [linux-usb-devel] OHCI problems with suspend/resume
    ... for USB is still a blocking issue for many people. ... USB IRQ problems are one of the longest-standing open 2.6 bugs: ... where is interrupt deallocated? ... >>The OHCI code does that already on the normal panic path ...
    (Linux-Kernel)
  • Re: lockdep and threaded IRQs (was: ...)
    ... to set it up so that toplevel IRQ doesn't wrongly ... thread context, but looking at the code there is a work queue as well. ... status bits) to determine which SIH moduleraised ... Dispatch through generic SIH module code; ...
    (Linux-Kernel)
  • Any problem if softirq are done in a interrupt context (IRQ stack)?
    ... That means the dedicated IRQ stack is used for hardirq handler ... A hardware interrupt happened. ... After saving context in process kernel stack, ... Copy the softirq bits in preempt_count so that the ...
    (Linux-Kernel)
  • Re: 5 devices sharing one irq
    ... And the usb devices I use are a external hard disk, ... The top half typically is what is wired to the interrupt and should complete ... each registered top half handler for that interrupt is called in turn ... things on an IRQ, though I bet someone somewhere has. ...
    (comp.os.linux.hardware)
  • Re: [PATCH 0/7] Boot IRQ quirks and rerouting
    ... things (so you need to schedule some kind of deferred work), ... hardirq context than split the thing and deal with all the communication, ... In principle all the interrupt handlers could be split like this except ... preventing the device from asserting the IRQ line any longer. ...
    (Linux-Kernel)