Hi Hans,
On Thu, 2013-11-21 at 14:52 +0100, Hans Verkuil wrote:
> Hi Andy,
>
> This seems more complex than is necessary. See my comments below...
>
> On 11/21/13 02:05, Andy Walls wrote:
> > (This patch is RFC, because it was compiled and tested against kernel
> > v3.5)
> >
> > videobuf2 file
Hi Andy,
This seems more complex than is necessary. See my comments below...
On 11/21/13 02:05, Andy Walls wrote:
> (This patch is RFC, because it was compiled and tested against kernel
> v3.5)
>
> videobuf2 file I/O emulation assumed that buffers dequeued from the
> driver would return in the o
Hans Verkuil wrote:
>Hi Andy,
>
>This seems more complex than is necessary. See my comments below...
>
>On 11/21/13 02:05, Andy Walls wrote:
>> (This patch is RFC, because it was compiled and tested against kernel
>> v3.5)
>>
>> videobuf2 file I/O emulation assumed that buffers dequeued from the
On Thu, 2013-11-21 at 08:56 +0100, Hans Verkuil wrote:
> Hi Andy,
>
> As I mentioned in irc I have been working in this same area as well, so
> I'll take this patch and merge it in my tree and test it as well.
>
> I suspect that it might be easiest if I add the patch to my upcoming
> patch series
Hi Andy,
As I mentioned in irc I have been working in this same area as well, so
I'll take this patch and merge it in my tree and test it as well.
I suspect that it might be easiest if I add the patch to my upcoming
patch series in order to prevent merge conflicts. I'll know more later
today.
Re
(This patch is RFC, because it was compiled and tested against kernel
v3.5)
videobuf2 file I/O emulation assumed that buffers dequeued from the
driver would return in the order they were enqueued in the driver.
Improve the file I/O emulator's book-keeping to remove this assumption.
Also remove
