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

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/

Relevant Pages

  • Re: Bug in OHCI2 driver for Windows CE 5.0?
    ... CE's USB stack is not derived from any of the desktop Windows stacks; ... A short packet (i.e., a packet smaller ... I'm in a middle of porting USB device-driver from Windows NT/2k/XP... ... A low-speed device (Contains couple of firmware versions) ...
    (microsoft.public.windowsce.platbuilder)
  • usb2: kernel panic with an USB floppy drive
    ... 8-current with the old USB stack. ... When I connect the floppy drive to the system with the new USB2 stack, ... <ACPI PCI bus> on pcib0 ... 2 ports with 2 removable, ...
    (freebsd-current)
  • Re: netatm: plan for removal unless an active maintainer is found
    ... :> The other large chunk of non-MPSAFE network device driver and stack ... The USB stack is also a part of the problem, ... posted for review on the NetBSD lists and this was the biggest set of ...
    (freebsd-arch)
  • Re: panic when removing pccard
    ... If i insert and then remove a pcmcia card using the ubsa module ... devices by the kernel is not correct. ... If you want to be able to remove the card you need to install the new USB ... The old USB stack is completely broken when it comes to this ...
    (freebsd-current)
  • Re: USB data Transfer question
    ... I'm afraid you can't pass 1-byte length buffer ... the pBuffer!=0 if there is data sending from client. ... and both USB analizer and the pBuffer value is the ... and the write function which write data from USB host to client works ...
    (microsoft.public.windowsce.platbuilder)