linux-kernel - Re: Update VIP to videobuf2 and control framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120801070418.51885637@lwn.net>
Date:	Wed, 1 Aug 2012 07:04:18 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Hans Verkuil <hverkuil@...all.nl>
Cc:	Federico Vaga <federico.vaga@...il.com>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Pawel Osciak <pawel@...iak.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Hans Verkuil <hans.verkuil@...co.com>,
	Giancarlo Asnaghi <giancarlo.asnaghi@...com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Update VIP to videobuf2 and control framework

On Wed, 1 Aug 2012 08:41:56 +0200
Hans Verkuil <hverkuil@...all.nl> wrote:

> > The second patch adds a new memory allocator for the videobuf2. I name it
> > videobuf2-dma-streaming but I think "streaming" is not the best choice, so
> > suggestions are welcome. My inspiration for this buffer come from
> > videobuf-dma-contig (cached) version. After I made this buffer I found the
> > videobuf2-dma-nc made by Jonathan Corbet and I improve the allocator with
> > some suggestions (http://patchwork.linuxtv.org/patch/7441/). The VIP doesn't
> > work with videobu2-dma-contig and I think this solution is easier the sg.  
> 
> I leave this to the vb2 experts. It's not obvious to me why we would need
> a fourth memory allocator.

I first wrote my version after observing that performance dropped by a
factor of three on the OLPC XO 1.75 when using contiguous, coherent
memory.  If the architecture needs to turn off caching, things really slow
down, to the point that it's unusable.  There's no real reason why a V4L2
device shouldn't be able to use streaming mappings in this situation; it
performs better and doesn't eat into the limited amounts of coherent DMA
space available on some systems.

I never got my version into a mergeable state only because I finally
figured out how to bludgeon the hardware into doing s/g DMA and didn't
need it anymore.  But I think it's a worthwhile functionality to have,
and, with CMA, it could be the preferred mode for a number of devices.

jon
--
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/