[pvrusb2] HVR-1950 driver loading problem

[Mike Isely]

On Sun, 14 Jun 2009, James Edward Geiger wrote:

> Running pvrusb2 with a HVR-1950 from Hauppauge
> 
> Fedora 11 running the release kernel
> 
> Linux version 2.6.29.4-167.fc11.i586
> (mockbuild at x86-2.fedora.phx.redhat.com) (gcc version 4.4.0 20090506
> (Red Hat 4.4.0-4) (GCC) ) #1 SMP Wed May 27 17:14:37 EDT 2009
> 
> on a CPU
> 
> model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
> 
> 
> I first tried the pvrusb2 video driver that came with the stock
> kernel, but it did not properly load.  I got the pvrusb2 dmesg with
> repeating resets.
> 
> I then tried the current v4l-dvb mercurial code and got the exact same
> continuing reset.  One thing I noticed is that the address is changing
> by one on the reset and it may be that the pvrusb2 driver is unable to
> associate the first instance with the second instance since the
> address is changed by one.
> 
> The USB disconnect address is X and when the usb layer returns the
> "new" device after the reset, it is X+1.
> 
> I would also observe that this is the "first" firmware to be loaded to
> the device; it does not get to the other firmware for the real video
> chips.
> 
> Any comments from the pvrusb2 driver authors?

  [...]

What's happening here is that the driver is deciding that the FX2 
firmware needs to be loaded - this is the program for the 
microcontroller that controls the entire device and mediates access to 
the USB cable, handles I2C, and generally is responsible for the entire 
thing.

Once it loads the FX2 firmware, the device must be reset.  When that 
happens the device will logically disconnect from the USB controller - 
it looks the same as being unplugged, which then causes the pvrusb2 
driver to tear down the instance of itself that was controlling it.  
That's all perfectly normal.  Then when the device comes out of reset it 
reconnects to the USB controller, is spotted by the Linux kernel, and 
the pvrusb2 driver is (re)associated with it.

At this point the pvrusb2 driver will test the hardware and see if the 
firmware needs to be loaded.  This time the test should pass and normal 
initialization continue.  But in your case it's probably failing again.  
Thus you get into this loop.

There isn't much the driver can do to defend against this because 
there's no internal "memory" that it had previously connected to that 
exact device.

My first guess is that the firmware file is corrupt or that something is 
going wrong with the loading process.  A while back there were some 
posts here showing problems loading the encoder's firmware.  In that 
case the Linux kernel was handing truncated / bad data to the driver.  I 
pointed this out but I never got a followup from the user so I don't 
know what that root cause was.  It might be related however because the 
mechanism for requesting firmware data out of user space is the same 
regardless of the specific firmware in question.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8