linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@canonical.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>,
	Tony Lindgren <tony@atomide.com>,
	Sylwester Nawrocki <snjw23@gmail.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	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: Fri, 23 Dec 2011 17:51:11 +0800	[thread overview]
Message-ID: <CACVXFVNdczv=tu7VG24766myCnGDRWAjkthbdfMwTGzTwFCoBA@mail.gmail.com> (raw)
In-Reply-To: <015201ccc156$033f73a0$09be5ae0$%szyprowski@samsung.com>

Hi,

On Fri, Dec 23, 2011 at 5:34 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:

>> For example, on ARM, there is very limited kernel virtual address space reserved
>> for DMA coherent buffer mapping, the default size is about 2M if I
>> don't remember mistakenly.
>
> It can be easily increased for particular boards, there is no problem with this.

It is not easily to increase it because there is very limited space reserved for
this purpose, see Documentation/arm/memory.txt. Also looks like it is
not configurable.

>
>> > 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
>>
>> Also there is poor performance inside kernel space, see [1]
>
> Your driver doesn't access video data inside kernel space, so this is also not an issue.

Why not introduce it so that other drivers(include face detection) can
benefit with it? :-)

>> >
>> > 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
>>
>> I think returning vaddr is enough.
>>
>> > you should use cookie method. vaddr is intended to provide only a pointer to
>> > kernel virtual mapping, but you pass a struct page * there.
>>
>> No, __get_free_pages returns virtual address instead of 'struct page *'.
>
> Then you MUST use cookie for it. vaddr method should return kernel virtual address
> to the buffer video data. Some parts of videobuf2 relies on this - it is used by file
> io emulator (read(), write() calls) and mmap equivalent for non-mmu systems.
>
> Manual casting in the driver is also a bad idea, that's why there are helper functions

I don't see any casts are needed. The dma address can be got from vaddr with
dma_map_* easily in drivers, see the usage on patch 8/8(media: video: introduce
omap4 face detection module driver).

> defined for both dma_contig and dma_sg allocators: vb2_dma_contig_plane_dma_addr() and
> vb2_dma_sg_plane_desc().

These two helpers are not needed and won't be provided by VIDEOBUF2_PAGE memops.

thanks,
--
Ming Lei

  reply	other threads:[~2011-12-23  9:51 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
2011-12-23  9:22     ` Ming Lei
2011-12-23  9:34       ` Marek Szyprowski
2011-12-23  9:51         ` Ming Lei [this message]
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='CACVXFVNdczv=tu7VG24766myCnGDRWAjkthbdfMwTGzTwFCoBA@mail.gmail.com' \
    --to=ming.lei@canonical.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=m.szyprowski@samsung.com \
    --cc=mchehab@infradead.org \
    --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).