From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
pawel@osciak.com, linux-media@vger.kernel.org
Subject: Re: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Date: Thu, 13 Jan 2011 10:58:21 -0200 [thread overview]
Message-ID: <4D2EF6ED.1020405@redhat.com> (raw)
In-Reply-To: <000001cbb2fe$5d8f2290$18ad67b0$%p@samsung.com>
Em 13-01-2011 06:46, Andrzej Pietrasiewicz escreveu:
> Hello Mauro,
>
> On Wednesday, January 12, 2011 9:24 PM Mauro Carvalho Chehab wrote:
>>
>> Em 12-01-2011 08:25, Marek Szyprowski escreveu:
>>> Hello Mauro,
>>>
>>> I've rebased our fimc and saa patches onto
>> http://linuxtv.org/git/mchehab/experimental.git
>>> vb2_test branch.
>>>
>>> The last 2 patches are for SAA7134 driver and are only to show that
>> videobuf2-dma-sg works
>>> correctly.
>>
>> On my first test with saa7134, it hanged. It seems that the code
>> reached a dead lock.
>>
>> On my test environment, I'm using a remote machine, without monitor. My
>> test is using
>> qv4l2 via a remote X server. Using a remote X server is an interesting
>> test, as it will
>> likely loose some frames, increasing the probability of races and dead
>> locks.
>>
>
> We did a similar test using a remote machine and qv4l2 with X forwarding.
> Both userptr and mmap worked. Read does not work because it is not
> implemented, but there was no freeze anyway, just green screen in qv4l2.
> However, we set "Capture Image Formats" to "YUV - 4:2:2 packed, YUV", "TV
> Standard" to "PAL". I enclose a (lengthy) log for reference - it is a log of
> a short session when modules where loaded, qv4l2 started, userptr mode run
> for a while and then mmap mode run for a while.
>
> We did it on a 32-bit system. We are going to repeat the test on a 64-bit
> system, it just takes some time to set it up. Perhaps this is the
> difference.
Yeah, I tested where with PAL/M and 64-bits, but I don't think that the hangs
have something due to 64 bits. It is probably because of the high delay introduced
by using the 100 Mbps Ethernet connection to display the stream. This introduces
a high delay (the max frame rate drops from 30 fps to about 6 fps on my setup).
So, qv4l2 will loose frames. This increases the possibility of a race between
qbuf/dqbuf.
Cheers,
Mauro
next prev parent reply other threads:[~2011-01-13 12:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-03 16:48 [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates Sylwester Nawrocki
2011-01-11 18:23 ` Mauro Carvalho Chehab
2011-01-11 16:42 ` Pawel Osciak
2011-01-11 19:06 ` Mauro Carvalho Chehab
2011-01-11 20:19 ` Mauro Carvalho Chehab
2011-01-12 10:25 ` Marek Szyprowski
2011-01-12 18:49 ` Mauro Carvalho Chehab
2011-01-13 3:05 ` Pawel Osciak
2011-01-13 12:18 ` Mauro Carvalho Chehab
2011-01-12 20:23 ` Mauro Carvalho Chehab
2011-01-13 8:46 ` Andrzej Pietrasiewicz
2011-01-13 12:13 ` Andrzej Pietrasiewicz
2011-01-13 13:04 ` Mauro Carvalho Chehab
2011-01-13 12:58 ` Mauro Carvalho Chehab [this message]
2011-01-16 15:11 ` Mauro Carvalho Chehab
2011-01-11 21:31 ` Mauro Carvalho Chehab
2011-01-11 21:57 ` Mauro Carvalho Chehab
2011-01-12 2:47 ` Pawel Osciak
2011-01-12 16:19 ` Sylwester Nawrocki
2011-01-11 22:08 ` Mauro Carvalho Chehab
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=4D2EF6ED.1020405@redhat.com \
--to=mchehab@redhat.com \
--cc=andrzej.p@samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pawel@osciak.com \
--cc=s.nawrocki@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