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

From: Vitaly Wool
Date: Thu Dec 15 2005 - 17:17:23 EST


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.
*Legacy* kernel code does that but why produce a new code with that?




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.

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.

Using preallocated buffer is not a good way, since it may well be already used by another interrupt or not yet processed by the worker thread (or tasklet, or whatever).



We would call those "driver bugs" and expect patches. :)



Well, I know one such patch ;)

One can not predict how many transfers are gonna be dropped due to "previous trransfer is being processed" problem, it depends on the system load. And though it's not a problem for touchscreen, it *will* be a problem if it were MMC, for instance.



Huh, well I've already seen one nice "mmc/sd over SPI" driver, using
a slightly earlier version of the framework than is found in mm3.
It's being used for root filesystems.

So demonstrably there is no problem for MMC/SD, either.


No problem... Has the driver been tested in stress conditions? If not, then I guess you can't say this for sure :)

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