On Wednesday 14 December 2005 5:50 am, Vitaly Wool 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?
> His synchronous transfer functions
You seem to be referring to one non-generic function that's
documented as OK to pass DMA-unsafe buffers to. There are
several other synchronous transfer calls that don't make
such guarantees.
> are allocating transfer buffers on
> stack which is not DMA-safe.
I think the very first version did that, but nothing since
has taken that shortcut. (Several months now.) It uses
a buffer that's allocated on the heap.
> 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
So that the typical case, with little SPI contention, doesn't
hit the heap? That's sure what I thought ... though I can't speak
for what other people may think I thought. You were the one that
wanted to optimize the atypical case to remove a blocking path!
> (as he proposes for upper layer drivers to do)?
No I didn't. I actually said that the upper layer drivers should
just not use DMA-unsafe areas for I/O buffers in the first place.
Places like stacks or static data. Doing that means there's never
a need for a new kmalloc buffer, unless maybe you're marshaling
things into a scratch buffer.
> 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.
Given the policy that all code avoids DMA-unsafe areas for I/O buffers,
the issue has already been worked out globally.
- Dave
-
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]
