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

[Mike Isely]

On Sun, 10 Feb 2008, Mike Isely wrote:

> On Sun, 10 Feb 2008, Mark Goldberg wrote:
> 
> 
> > 
> > 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?

Been thinking about this one a little more.

Just from what you've described I can see a race happening on system 
bootup where multiple v4l drivers are starting at once.  In that case 
the order of /dev/videoX assignment may be driven in part by how fast 
each driver starts.  It can take a few seconds for the pvrusb2 driver 
due to various factors - including loading of the FX2 firmware.  In 
fact, if you were to just reboot the host without power cycling, then 
the pvrusb2 driver is going to start even faster in that scenario 
because it will discover that the device already has the FX2 firmware 
loaded and will skip that step - cutting several seconds out of the boot 
time.  So if two drivers are in close competition to grab available 
/dev/videoX numbers, then the results might not be entirely 
deterministic.  And of course, for this latest snapshot, initialization 
is shuffled around a bit between several threads so the timing is likely 
affected anyway.

Given that mythtv really needs to be told which device is which when you 
set it up, then letting drivers race to get those /dev/videoX 
allocations might not be that great an idea.  But there's an easy fix 
for this: Tell the driver what number to use.  Read the description 
for the video_nr module parameter and you will see how to use it to get 
this effect.

[And I just saw your other reply while typing this so you already know 
what to do 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
                        |                             |