public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: linux-media@vger.kernel.org, Hans Verkuil <hans.verkuil@cisco.com>
Subject: Re: [REVIEW PATCH 3/3] saa7134: convert to vb2
Date: Fri, 18 Apr 2014 13:45:50 +0200	[thread overview]
Message-ID: <5351106E.4080700@xs4all.nl> (raw)
In-Reply-To: <20140417101310.0111d236@samsung.com>

On 04/17/2014 03:13 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Apr 2014 11:49:51 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
>> On 04/17/2014 04:17 AM, Mauro Carvalho Chehab wrote:
>>> Em Thu, 17 Apr 2014 00:33:55 +0200
>>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>>
>>>> On 04/17/2014 12:23 AM, Mauro Carvalho Chehab wrote:
>>>>> Em Mon, 10 Mar 2014 13:20:49 +0100
>>>>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>>>>
>>>>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>>>>
>>>>>> Convert the saa7134 driver to vb2.
>>>>>>
>>>>>> Note that while this uses the vb2-dma-sg version, the VB2_USERPTR mode is
>>>>>> disabled. The DMA hardware only supports DMAing full pages, and in the
>>>>>> USERPTR memory model the first and last scatter-gather buffer is almost
>>>>>> never a full page.
>>>>>>
>>>>>> In practice this means that we can't use the VB2_USERPTR mode.
>>>>>
>>>>> Why not? Provided that the buffer is equal or bigger than the number of
>>>>> pages required by saa7134, that should be OK.
>>>>>
>>>>> All the driver needs to do is to check if the USERPTR buffer condition is met,
>>>>> returning an error otherwise (and likely printing a msg at dmesg).
>>>>
>>>> Yuck. Well, I'll take a look at this.
>>>>
>>>> It has in my view the same problem as abusing USERPTR to pass pointers to
>>>> physically contiguous memory: yes, it 'supports' USERPTR, but it has additional
>>>> requirements which userspace has no way of knowing or detecting.
>>>>
>>>> It's really not USERPTR at all, it is PAGE_ALIGNED_USERPTR.

This was a bit confusing following the previous paragraph. I meant to say that the
*saa7134* userptr implementation is not USERPTR at all but PAGE_ALIGNED_USERPTR.

A proper USERPTR implementation (like in bttv) can use any malloc()ed pointer as
it should, but saa7134 can't as it requires the application to align the pointer
to a page boundary, which is non-standard.

Regards,

	Hans

>>>>
>>>> Quite different.
>>>
>>> Hmm... If I remember well, mmapped memory (being userptr or not) are always
>>> page aligned, at least on systems with MMU.
>>
>> Not malloc()ed memory. That's what userptr is about.
> 
> Take a look at videobuf_dma_init_user_locked at
> drivers/media/v4l2-core/videobuf-dma-sg.c:
> 
> 	first = (data          & PAGE_MASK) >> PAGE_SHIFT;
> 	last  = ((data+size-1) & PAGE_MASK) >> PAGE_SHIFT;
> 	dma->offset = data & ~PAGE_MASK;
> 	dma->size = size;
> 	dma->nr_pages = last-first+1;
> 	dma->pages = kmalloc(dma->nr_pages * sizeof(struct page *), GFP_KERNEL);
> 
> The physical memory is always page aligned, even if VM memory isn't.
> The offset there is actually used just to subtract the size, at
> videobuf_pages_to_sg().
> 
> So, with VB1, USERPTR works fine, and no special care is needed on
> userspace to align the offset.
> 
> Btw, it seems that VB2 also does the same. Take a look at
> vb2_dma_sg_get_userptr().



  reply	other threads:[~2014-04-18 11:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 12:20 REVIEW PATCH 0/3] saa7134: convert to vb2 Hans Verkuil
2014-03-10 12:20 ` [REVIEW PATCH 1/3] vb2: add thread support Hans Verkuil
2014-03-10 12:20 ` [REVIEW PATCH 2/3] vb2: Add videobuf2-dvb support Hans Verkuil
2014-03-10 12:20 ` [REVIEW PATCH 3/3] saa7134: convert to vb2 Hans Verkuil
2014-04-16 22:23   ` Mauro Carvalho Chehab
2014-04-16 22:33     ` Hans Verkuil
2014-04-17  2:17       ` Mauro Carvalho Chehab
2014-04-17  9:49         ` Hans Verkuil
2014-04-17 13:13           ` Mauro Carvalho Chehab
2014-04-18 11:45             ` Hans Verkuil [this message]
2014-04-18 13:49               ` Devin Heitmueller
2014-04-18 14:11                 ` Hans Verkuil
2014-04-18 14:28                   ` Devin Heitmueller

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=5351106E.4080700@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=hans.verkuil@cisco.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.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