From: Marek Szyprowski <m.szyprowski@samsung.com>
To: "'Ming Lei'" <ming.lei@canonical.com>,
"'Mauro Carvalho Chehab'" <mchehab@infradead.org>,
"'Tony Lindgren'" <tony@atomide.com>
Cc: "'Sylwester Nawrocki'" <snjw23@gmail.com>,
"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
"'Pawel Osciak'" <p.osciak@gmail.com>
Subject: RE: [RFC PATCH v2 4/8] media: videobuf2: introduce VIDEOBUF2_PAGE memops
Date: Thu, 22 Dec 2011 10:28:49 +0100 [thread overview]
Message-ID: <010501ccc08c$1c7b7870$55726950$%szyprowski@samsung.com> (raw)
In-Reply-To: <1323871214-25435-5-git-send-email-ming.lei@canonical.com>
Hello,
On Wednesday, December 14, 2011 3:00 PM Ming Lei wrote:
> DMA contig memory resource is very limited and precious, also
> accessing to it from CPU is very slow on some platform.
>
> For some cases(such as the comming face detection driver), DMA Streaming
> buffer is enough, so introduce VIDEOBUF2_PAGE to allocate continuous
> physical memory but letting video device driver to handle DMA buffer mapping
> and unmapping things.
>
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
Could you elaborate a bit why do you think that DMA contig memory resource
is so limited? If dma_alloc_coherent fails because of the memory fragmentation,
the alloc_pages() call with order > 0 will also fail.
I understand that there might be some speed issues with coherent (uncached)
userspace mappings, but I would solve it in completely different way. The interface
for both coherent/uncached and non-coherent/cached contig allocator should be the
same, so exchanging them is easy and will not require changes in the driver.
I'm planning to introduce some design changes in memory allocator api and introduce
prepare and finish callbacks in allocator ops. I hope to post the rfc after
Christmas. For your face detection driver using standard dma-contig allocator
shouldn't be a big issue.
Your current implementation also abuses the design and api of videobuf2 memory
allocators. If the allocator needs to return a custom structure to the driver
you should use cookie method. vaddr is intended to provide only a pointer to
kernel virtual mapping, but you pass a struct page * there.
(snipped)
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
next prev parent reply other threads:[~2011-12-22 9:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 14:00 [RFC PATCH v2 0/7] media: introduce object detection(OD) driver Ming Lei
2011-12-14 14:00 ` [RFC PATCH v2 1/8] omap4: introduce fdif(face detect module) hwmod Ming Lei
2011-12-16 5:53 ` Paul Walmsley
2011-12-16 14:54 ` Cousson, Benoit
2011-12-19 21:48 ` Paul Walmsley
2011-12-14 14:00 ` [RFC PATCH v2 2/8] omap4: build fdif omap device from hwmod Ming Lei
2011-12-14 14:00 ` [RFC PATCH v2 3/8] media: videobuf2: move out of setting pgprot_noncached from vb2_mmap_pfn_range Ming Lei
2011-12-14 14:00 ` [RFC PATCH v2 4/8] media: videobuf2: introduce VIDEOBUF2_PAGE memops Ming Lei
2011-12-22 9:28 ` Marek Szyprowski [this message]
2011-12-23 9:22 ` Ming Lei
2011-12-23 9:34 ` Marek Szyprowski
2011-12-23 9:51 ` Ming Lei
2011-12-23 10:38 ` Marek Szyprowski
2011-12-23 12:20 ` Ming Lei
2012-01-10 10:20 ` Marek Szyprowski
2012-01-10 11:55 ` Ming Lei
2011-12-14 14:00 ` [RFC PATCH v2 5/8] media: v4l2-ioctl: support 64/32 compatible array parameter Ming Lei
2011-12-14 14:00 ` [RFC PATCH v2 6/8] media: v4l2: introduce two IOCTLs for object detection Ming Lei
2012-01-13 21:16 ` Sylwester Nawrocki
2011-12-14 14:00 ` [RFC PATCH v2 7/8] media: video: introduce object detection driver module Ming Lei
2011-12-29 17:16 ` Sylwester Nawrocki
2012-01-04 8:13 ` Ming Lei
2012-01-17 21:05 ` Sylwester Nawrocki
2011-12-14 14:00 ` [RFC PATCH v2 8/8] media: video: introduce omap4 face detection module driver Ming Lei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='010501ccc08c$1c7b7870$55726950$%szyprowski@samsung.com' \
--to=m.szyprowski@samsung.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=ming.lei@canonical.com \
--cc=p.osciak@gmail.com \
--cc=snjw23@gmail.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).