OK, here's my second attempt at getting rid of cx18 YUV frame alignment
and tearing issues.
http://linuxtv.org/hg/~awalls/cx18-yuv2
This change primarily implements full scatter-gather buffer handling
between the cx18 driver and the CX23418 firmware. That in turn allows
me to set the MDL
On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
>
> Could folks give this cx18 code a test to make sure their primary use
> cases didn't break?
>
>
> Regards,
> Andy
>
Andy,
I have loaded the drivers (also pulling in Devin's change request too)
and am running with 3 cards and SageTV. I'll let
On Wed, 2009-11-11 at 19:38 -0500, Brandon Jenkins wrote:
> On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
> >
> > Could folks give this cx18 code a test to make sure their primary use
> > cases didn't break?
> >
> >
> > Regards,
> > Andy
> >
> Andy,
>
> I have loaded the drivers (also pulli
On Wed, Nov 11, 2009 at 8:06 PM, Andy Walls wrote:
> On Wed, 2009-11-11 at 19:38 -0500, Brandon Jenkins wrote:
>> On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
>
> I assume you mean the mxl5005s and s5h1409 changes for clear QAM when
> you say Devin's change.
>
> Regards,
> Andy
>
>
You a
On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
> OK, here's my second attempt at getting rid of cx18 YUV frame alignment
> and tearing issues.
>
> http://linuxtv.org/hg/~awalls/cx18-yuv2
Hi Andy,
I did some testing of your tree, using the following command
mplayer /dev/video32 -demu
On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote:
> On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
> > OK, here's my second attempt at getting rid of cx18 YUV frame alignment
> > and tearing issues.
> >
> >http://linuxtv.org/hg/~awalls/cx18-yuv2
>
> Hi Andy,
>
> I did some
On Mon, 2009-11-23 at 07:12 -0500, Andy Walls wrote:
> On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote:
> > On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
> > > OK, here's my second attempt at getting rid of cx18 YUV frame alignment
> > > and tearing issues.
> > >
> > >http
On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls wrote:
> 5. If you don't give an MDL back to the firmware, it never uses it
> again. That's why you see the sweep-up log messages. As soon as an MDL
> is skipped *on the order of the depth* of q_busy times, when looking for
> the currently DMA_DONE'd M
On Mon, 2009-11-23 at 12:09 -0500, Devin Heitmueller wrote:
> On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls wrote:
> > 5. If you don't give an MDL back to the firmware, it never uses it
> > again. That's why you see the sweep-up log messages. As soon as an MDL
> > is skipped *on the order of the d
On Mon, Nov 23, 2009 at 8:49 PM, Andy Walls wrote:
> Of course that's all speculation about the problem. If you could
> reproduce the condition and then
>
> # echo 271 > /sys/modules/cx18/parameters/debug
Hi Andy,
Thanks for the additional info. I had to tear down my HVR-1600 test
rig to finis
On Tue, 2009-11-24 at 12:57 -0500, Devin Heitmueller wrote:
> On Mon, Nov 23, 2009 at 8:49 PM, Andy Walls wrote:
> > Of course that's all speculation about the problem. If you could
> > reproduce the condition and then
> >
> > # echo 271 > /sys/modules/cx18/parameters/debug
>
> Hi Andy,
>
> Tha
On Tue, Nov 24, 2009 at 6:39 PM, Andy Walls wrote:
> BTW, I did a quick skim of your cx18-alsa stuff. I noticed two things:
>
> 1. A memory leak in an error path:
>
> http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2/rev/cb267593943f#l85
>
>
> 2. Technically open_id should probably be
12 matches
Mail list logo