[pvrusb2] driver status / update

Hans Verkuil hverkuil at xs4all.nl
Thu Jan 15 01:25:30 CST 2009


On Thursday 15 January 2009 06:51:03 Mike Isely wrote:
> On Wed, 14 Jan 2009, Mike Isely wrote:
> > On Wed, 14 Jan 2009, Mike Isely wrote:
> > > Hmm, audio isn't working.  I just also tried a 29xxx (with
> > > saa7115+msp3400) and audio is OK there, so there's still
> > > something else apparently broken involving the pvrusb2 driver and
> > > cx25840.  However this whole thing still is an improvement over
> > > what's there now so I'm posting the pull request anyway.  I will
> > > do more digging on the audio problem tonight.
> > >
> > >   -Mike
> >
> > Well this is interesting.  The v4l-dvb changeset that messed up the
> > cx25840 module and caused the "no decoder present" bug is ALSO the
> > changeset where the cx25840 audio gets screwed up.
> >
> > I sense a pattern :-(
>
> Problem found.
>
> The cx25840 module wasn't being initialized.  Without this
> initialization taking place, the entire audio side of the cx25840
> chip won't start (the video side however still works which is why I
> was getting video but no audio).  The telltale sign in the kernel log
> is that no attempt is ever made to load the chip's firmware (this is
> a step in the initialization sequence).
>
> So why is this a problem only now?  Well before that cx25840
> changeset had been committed (same changeset that triggered the bug
> found last night), the cx25840 module's previous behavior was that it
> would implicitly initialize itself on its own upon receipt of the
> first command from the host driver (e.g. pvrusb2).  In fact, there
> wasn't even a command present to manually perform such an
> initialization.  Now with this changeset in place, the module has
> been moved over to a new model of communication ("v4l2_subdev"), and
> when that change was made, the implicit initialization went away. 
> Now the host driver apparently MUST issue a VIDIOC_INT_INIT command
> to the module before doing anything else with it.

Hmm, that's my fault again. I didn't realize the consequences of this 
change. Allow me to fix this in the cx25840 driver itself so that no 
changes are needed in the bridge drivers that use this module.

I'll have something for you tonight.

> I imagine as more stuff moves over to the v4l2_subdev model that this
> might become more common.  I will see about fixing the pvrusb2 driver
> to always issue this command to any v4l2 modules which are bound to
> it. For modules that don't know about this command the result should
> be a harmless nop.

No need to change pvrusb2 for this, it's cx25840 that needs to be 
changed.

Apologies once again,

	Hans

>
> There's more synchronization and testing I have to do before
> releasing a new standalone snapshot.  I also have to revert the
> bus_info change. There's also still the LIRC issue.  So the earliest
> that there will be a snapshot might be tomorrow night, maybe even not
> until Friday night.
>
>   -Mike



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG


More information about the pvrusb2 mailing list