Thread (13 messages) flat view 13 messages, 6 authors, 2009-06-09

Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2009-06-09 03:51:17
Also in: linux-next, lkml

On Sun, 2009-06-07 at 20:06 +0530, Subrata Modak wrote:
On Sat, 2009-06-06 at 09:36 -0400, Frank Mori Hess wrote:
quoted
On Saturday 06 June 2009, Greg KH wrote:
quoted
Frank and Ian, any thoughts about the vmap call in the
comedi_buf_alloc() call?  Why is it using PAGE_KERNEL_NOCACHE, and what
is the prealloc_buf buffer used for?
It is a circular buffer used to hold data streaming either to or from a 
board (for example when producing an analog output waveform).  Reads and 
writes to the device files read/write to the circular buffer, plus a few 
drivers do dma directly to/from it.  I personally don't have a problem 
with requiring drivers to have their own dma buffers and making them copy 
data between their private dma buffers and the main circular buffer.  I 
guess the original design wanted to support zero-copy dma.
Great to hear that. How about a patch that solves my build problem on
PPC64(the problem seems to be existing for long) ? 
In any case, doing PAGE_KERNEL_NOCACHE for DMA memory is incorrect on
many architectures. So at this stage, there's no much option but ifdef I
suspect for now until this is fixed properly.

It does make sense to want to have some memory like that shared between
user space and DMA, though I don't know what the right approach that
works on all archs is at this stage. Worth asking the Alsa guys, I think
they have similar issues :-)

But doing double buffering might do the trick fine for now.

Cheers,
Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help