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

[Greg KH]

On Wed, Dec 14, 2005 at 04:50:03PM +0300, Vitaly Wool wrote:
> Greg KH wrote:
> 
> >On Tue, Dec 13, 2005 at 11:01:01AM -0800, David Brownell wrote:
> > 
> >
> >>It's way better to just insist that all I/O buffers (in all
> >>generic APIs) be DMA-safe.  AFAICT that's a pretty standard
> >>rule everywhere in Linux.
> >>   
> >>
> >
> >I agree.
> > 
> >
> Well, why then David doesn't insist on that in his own code?

Heh, I don't know, only David can answer that :)

> His synchronous transfer functions are allocating transfer buffers on
> stack which is not DMA-safe.
> Then he starts messing with allocate-or-use-preallocated stuff etc. etc.
> Why isn't he just kmalloc'ing/kfree'ing buffers each time these 
> functions are called (as he proposes for upper layer drivers to do)?
> That's a significant inconsistency. Is it also the thing you agree with?
> 
> And they way he does it implies redundant memcpy's and kmalloc's: 
> suppose we have two controller drivers working in two threads and 
> calling write_then_read in such a way that the one called later has to 
> allocate a new buffer. Suppose also that both controller drivers are 
> working in *PIO* mode. In this situation you have one redundant kmalloc 
> and two redundant memcpy's, not speaking about overhead brought up by 
> mutexes.
> 
> The thing is that only controller driver is aware whether DMA is
> needed or not, so it's controller driver that should work it out.
> Requesting all the buffers to be DMA-safe will make a significant
> performance drop on all small transfers!

What is the speed of your SPI bus?

And what are your preformance requirements?

thanks,

greg k-h
-
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/