Em 26-09-2011 16:59, Thomas Petazzoni escreveu:
> Hello Laurent,
>
> Le Mon, 26 Sep 2011 21:02:48 +0200,
> Laurent Pinchart a écrit :
>
>> Are you using the MMAP or USERPTR capture method ? If using MMAP, can
>> you try (as a test only) to unmap the buffer before queueing it and
>> to remap it a
Hello Laurent,
Le Mon, 26 Sep 2011 21:02:48 +0200,
Laurent Pinchart a écrit :
> Are you using the MMAP or USERPTR capture method ? If using MMAP, can
> you try (as a test only) to unmap the buffer before queueing it and
> to remap it after dequeuing it ?
So far, we have used VLC, Cheese, or a s
On Monday 26 September 2011 19:32:47 Mauro Carvalho Chehab wrote:
> Em 26-09-2011 05:13, Thomas Petazzoni escreveu:
> > Le Fri, 23 Sep 2011 23:15:54 -0300, Mauro Carvalho Chehab a écrit:
> >>> And still the result is the same: we get a first frame, and then
> >>> nothing more, and we have a large n
Em 26-09-2011 05:13, Thomas Petazzoni escreveu:
> Hello Mauro,
>
> Le Fri, 23 Sep 2011 23:15:54 -0300,
> Mauro Carvalho Chehab a écrit :
>
>>> And still the result is the same: we get a first frame, and then
>>> nothing more, and we have a large number of error messages in the
>>> kernel logs.
>
Hello Mauro,
Le Fri, 23 Sep 2011 23:15:54 -0300,
Mauro Carvalho Chehab a écrit :
> > And still the result is the same: we get a first frame, and then
> > nothing more, and we have a large number of error messages in the
> > kernel logs.
>
> I don't think that this is related to the power manage
Hello Srinivasa,
Le Fri, 23 Sep 2011 05:26:07 -0700,
"Sri Deevi" a écrit :
> Do you have USB Analyzer (hardware) ? If so, Is it possible to take a
> trace and compare it with x86 trace to see for any obvious
> differences ?
Unfortunately, I don't have an hardware USB analyzer to do such a
compa
Em 23-09-2011 09:04, Thomas Petazzoni escreveu:
> Hello Devin,
>
> Le Thu, 22 Sep 2011 17:29:29 +0200,
> Thomas Petazzoni a écrit :
>
>> I guess you're talking about 44ecf1df9493e6684cd1bb34abb107a0ffe1078a,
>> which ensures a 10ms msleep call. We don't have this patch, but as with
>> CONFIG_HZ=
, 2011 5:04 AM
To: Devin Heitmueller
Cc: Thomas Petazzoni; linux-media@vger.kernel.org; Sri Deevi; Maxime Ripard
Subject: Re: cx231xx: DMA problem on ARM
Hello Devin,
Le Thu, 22 Sep 2011 17:29:29 +0200,
Thomas Petazzoni a écrit :
> I guess you're talking about 44ecf1df9493e6684cd1bb34abb107a0
Hello Devin,
Le Thu, 22 Sep 2011 17:29:29 +0200,
Thomas Petazzoni a écrit :
> I guess you're talking about 44ecf1df9493e6684cd1bb34abb107a0ffe1078a,
> which ensures a 10ms msleep call. We don't have this patch, but as with
> CONFIG_HZ=100, msleep() calls are anyway rounded up to 10ms, so I'm not
Le Thu, 22 Sep 2011 11:09:22 -0400,
Devin Heitmueller a écrit :
> Ok, that is a good start. I would definitely submit that as a patch
> (including your Signed-off-by line).
Sure, we will definitely do this.
> Regarding the outstanding issue, I believe I did see that and fixed
> it. Please loo
On Thu, Sep 22, 2011 at 10:45 AM, Thomas Petazzoni
wrote:
> Hello,
>
> Le Wed, 21 Sep 2011 08:04:52 -0400,
> Devin Heitmueller a écrit :
>
>> I ran into the same issue on em28xx in the past (which is what those
>> parts of cx231xx are based on). Yes, just adding
>> URB_NO_TRANSFER_DMA_MAP should
Hello,
Le Wed, 21 Sep 2011 08:04:52 -0400,
Devin Heitmueller a écrit :
> I ran into the same issue on em28xx in the past (which is what those
> parts of cx231xx are based on). Yes, just adding
> URB_NO_TRANSFER_DMA_MAP should result in it starting to work. Please
> try that out, and assuming i
Hello Devin,
Thanks for your quick reply.
Le Wed, 21 Sep 2011 08:04:52 -0400,
Devin Heitmueller a écrit :
> I ran into the same issue on em28xx in the past (which is what those
> parts of cx231xx are based on). Yes, just adding
> URB_NO_TRANSFER_DMA_MAP should result in it starting to work. P
On Wed, Sep 21, 2011 at 7:56 AM, Thomas Petazzoni
wrote:
> Hello,
>
> On an x86 platform, we have managed to use a Hauppauge USB Live 2
> capture device with the cx231xx on a 3.0 kernel with the patch at [1].
> Things work nicely.
>
> However, using a similar 3.0 kernel with the exact same device
Hello,
On an x86 platform, we have managed to use a Hauppauge USB Live 2
capture device with the cx231xx on a 3.0 kernel with the patch at [1].
Things work nicely.
However, using a similar 3.0 kernel with the exact same device on an
ARM platform (BeagleBoard-XM), starting a V4L application to cap
15 matches
Mail list logo