Re: [PATCH/RFC] SPI: add DMAUNSAFE analog to David Brownell's core

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Brownell wrote:

That's not "core" in the normal "everyone must use this" sense.
Even the folk that do use synchronous transfers aren't always
going to use that particular codepath.
Lemme explain once more why what you have is a lot worse than what I suggest. Take for instance spi_w8r8 function used in lotsa places in the drivers you and Stephen have posted. This function has a) *implicit memcpy* inherited from spi_write_then_read b) *implicit priority inversion* inherited from the same place. On the other hand, any smart enough SPI controller driver wouldn't ever want to send and receive one byte via DMA, especially chaining messages because the overhead will be great; memcpy's also adding overhead. It's gonna use PIO instead. So this is a serious reason to let controller driver decide things related to memory allocation. It doesn't concern only static-allocated buffers but also, say, stack-allocated (used in your core in many places). And controller driver needs something to track whether it has allocated a buffer for transfer for DMA safety or not. Don't you want a linked list of allocated buffers in the controller driver?! And the flag I'm adding within the patch does that with minimal intrusion to your core.

Hope that helps understand my reasons.

Vitaly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux