Re: [spi-devel-general] Re: [PATCH/RFC] SPI: add DMAUNSAFE analog

[Greg KH <greg@kroah.com>]

On Fri, Dec 16, 2005 at 01:17:56AM +0300, Vitaly Wool wrote:
> David Brownell wrote:
> 
> >On Wednesday 14 December 2005 10:47 pm, Vitaly Wool wrote:
> >
> > 
> >
> >>One cannot allocate memory in interrupt context, so the way to go is 
> >>allocating it on stack, thus the buffer is not DMA-safe.
> >>   
> >>
> >
> >kmalloc(..., GFP_ATOMIC) is the way to allocate memory in irq context.
> >It's done that way throughout the kernel.
> > 
> >
> It's not applicable within the RT-related changes. kmalloc anyway takes 
> mutexes, so allocationg it in interrupt context is buggy.

What RT-related changes cause this?

> *Legacy* kernel code does that but why produce a new code with that?

In this terminoligy, you are calling 2.6.15-rc5 "legacy".  Which is not
true.

> >>Making it DMA-safe in thread that does the very message processing is a 
> >>good way of overcoming this.
> >>   
> >>
> >
> >The rest of Linux appears to work fine without needing such mechanisms...
> > 
> >
> The rest of Linux still has a lot of bugs. Noone I guess is ready to 
> argue that.

Huh?  Please point out these bugs in the mainline tree and we will be
glad to fix them.

> >I really fail to see why you think SPI needs that.  USB isn't the only
> >counterexample, but it's particularly relevant since both USB and SPI
> >use asynchronous message passing over serial links ... and USB has a
> >rather complete driver stack over it.   (None of the USB based WLAN
> >drivers need those static buffers you worry about, by the way...)
> > 
> >
> 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.

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/