[pvrusb2] New driver snapshot: pvrusb2-mci-20080210

[Mike Isely]

On Sun, 10 Feb 2008, Mark Goldberg wrote:

> Compiling under FC8 Kernel 2.6.23.14-115.fc8, I get these warnings,
> leading directory names removed to protect the innocent:
> 
> In file included from pvrusb2-mci-20080210/driver/pvrusb2-sysfs-sel.c:39:
> pvrusb2-mci-20080210/driver/pvrusb2-sysfs.c: In function 'store_val_norm':
> pvrusb2-mci-20080210/driver/pvrusb2-sysfs.c:293: warning: field
> precision should have type 'int', but argument 4 has type 'size_t'
> pvrusb2-mci-20080210/driver/pvrusb2-sysfs.c: In function 'store_val_custom':
> pvrusb2-mci-20080210/driver/pvrusb2-sysfs.c:306: warning: field
> precision should have type 'int', but argument 4 has type 'size_t'

My test platform right now is vanilla kernel 2.6.23.12 and I didn't get 
these warnings.  I just checked again to be sure.  Can you try a vanilla 
kernel?  The lines in question haven't changed for quite some time.


> 
> It happened on the last snapshot, but with this one, mythtv thinks the
> tuner is in use and it won't use it. Going back to the last snapshot
> works fine.  This snapshot grabs /dev/video0 instead of /dev/video2
> that all the others grabbed. I've got two SAA7134 based card that
> should be /dev/video0 and /dev/video1.

The driver doesn't control what /dev/videoX device is grabbed (unless 
you force it).  Rather it asks v4l to allocate the first available 
device.  Initialization timing might be different; that could cause the 
two competing drivers to hit the v4l core in a different order if 
they've both been loaded nearly the same time at boot.  It is possible 
that the pvrusb2 driver could be initializing a little faster now.

Is the mythtv problem you are seeing a facet of the different 
/dev/videoX assignment (i.e. mythtv things they are the other way around 
and are treating them perhaps differently) or do you think that is a 
separate problem?


> 
> It also gives this on initialization:
> 
> pvrusb2: Failed to lock USB device ret=-16

This is the result of the driver's attempt to issue a USB reset as part 
of device initialization.  If this message prints, the reset is simply 
skipped, which itself should not be a real problem.  What's interesting 
here is the failure.  The error code (-16) is EBUSY.  Because of the 
recent changes, this part of the initialization might be happening with 
somewhat different timing but it still should not fail.  I'm not seeing 
that happen here :-(

  -Mike

-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |