[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200907262352.09797.laurent.pinchart@skynet.be>
Date: Sun, 26 Jul 2009 23:52:09 +0200
From: Laurent Pinchart <laurent.pinchart@...net.be>
To: Jonathan Corbet <corbet@....net>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Should I use kmap or kmap_atomic to map user pages that will be written in a loop ?
Hi Jonathan,
first of all thanks for your answer.
On Sunday 26 July 2009 23:26:55 Jonathan Corbet wrote:
> On Sat, 25 Jul 2009 23:41:47 +0200
>
> Laurent Pinchart <laurent.pinchart@...net.be> wrote:
> > Pages will be written to from the kernel in USB interrupt context. I can
> > then either kmap_atomic() pages before copying data and kunmap_atomic()
> > them right after, or kmap() them once at the beginning of the video
> > stream and keep them mapped until the end.
>
> Video buffers can be big, and the streaming interface requires at least
> two of them. That's a lot of kmap'd pages. It seems to me that
> kmap_atomic() is the way to go for something like this.
Ok thanks.
> But, then, these are user-space buffers, and you're seemingly buffering
> the data through kernel space buffers first? It seems like using
> copy_to_user() in a workqueue (or a threaded interrupt handler) might be
> a more straightforward way to go, unless I'm missing something.
I receive data from the USB subsystem in URB buffers, which are small kernel
buffers. As I have to strip headers from those buffers, I can't initialize the
URBs to copy data directly to the userspace buffers, so there's at least one
memcpy operation involved :-S
I could indeed append the URBs to a list in the callback called from interrupt
context, and process them from a threaded interrupt handler. Would it make
much difference ?
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists