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

[Vitaly Wool]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/