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

[Mike Isely]

A new pvrusb2 driver snapshot is available.  The driver changes are:

  (+) Configuration tweaks from Steve Toth for Hauppauge HVR-1900.

  (+) Implement experimental support for Terratec Grabster AV400.
      This is very experimental; I am including this so that others
      can test and help improve things.  I strongly suspect that since
      this does not include any help for the CS5340 that I'm told is
      on the board that audio might still not quite be right...
      Credit goes to Andrea Venturis, Tobias Seiler, and Dave Craig
      for providing the critical details to make this possible.

  (+) Remove use of usb_settoggle(); this is no longer available with
      later kernels.

  (+) Attempt to autoload ir-kbd (v4l-dvb's module for some IR
      receivers) where appropriate.  Note!  This is new behavior and
      may interfere if lirc was being used.  A new module option is
      defined to suppress this: disable_autoload_ir_kbd.  It is
      entirely possible that this option may disappear in the future,
      if/when lirc is updated to operate with the new i2c binding
      mechanism.  For now, we default this option to "1", i.e. we
      won't try to autoload anything to handle IR.

  (+) Include configuration data to select and track actual IR scheme
      in use.  This change includes reporting of the IR scheme in use
      via the driver's debug info output.

  (+) Correctly initialize v4l2_routing structures everywhere.  This
      wasn't causing a problem, but this is the sort of thing that
      should be cleaned up.

  (+) Account for various API changes related to v4l2-subdev changes
      since 2.6.29 kernel.

  (+) Fix unitialized struct element during tuner setup.  Stack
      allocated foreign struct instances should always be memset() to
      zero in order to guard against fields being added later (and
      thus being left uninitialized).  This bug was causing bogus agc
      warnings from the tuner module when using an HVR-1950.  This bug
      has also been around for a very long time.

  (+) In sysfs, show default values symbolically, same as current
      values, where appropriate.

  (+) Fix longstanding bug (since Aug 2008) that caused corrupted
      values to be returned for control default values when the
      control is not an integer.  Actually that bug propagated from
      another bug dating back to Apr 2006 where default values for
      non-integer valued controls was always returning zero.

Note above the item about the Grabster AV400.  Yes, I finally got the
changes that have been circulating for this into the driver.  I hope.
Oh, and I think Hell froze over too :-) Really sorry about taking
forever on this.  But with that said...

1. I have not tested anything related to the Grabster AV400.  I can't,
   since I don't have a sample of this device.  What I've done is
   pulled together the collected information from various posts over
   the past 1.5 years (yes it really has been that long, sigh...)
   about this device and integrated what I believe to be the correct
   configuration into the driver.  For all I know this is horribly
   broken.  Thus....

2. I really REALLY need the people here who have Grabster AV400 (or
   equivalent) devices to test the driver!  I have no other means to
   know if these changes are good.

3. There is a CS5340 audio digitizer chip on the AV400 (or so I've
   been told).  Right now the driver implements ZERO support for this,
   so if it is working it's probably just by luck.  We need to get to
   the bottom of that.  There's a cs5345 sub-device driver in v4l-dvb;
   this might be the right driver to use.  But somebody has to try it.
   I can't.  To "try it" means including it in the client list in
   pvrusb2-devattr.c and probably writing an adapter for it so that
   correct routing info can be sent to it (see pvrusb2-cs53l32a.[ch]
   in the driver for a similar example).

4. Because of the above, right now I'm not letting this get into
   v4l-dvb.  Maybe I should.  But without extra effort (i.e. kernel
   CONFIG_xxx setup craziness), anything I make visible there will
   find its way into the kernel mainline and I don't want to do that
   until / if we know these changes are really working.  So for now to
   use this device you need to use the standalone driver.

5. I have not updated any pvrusb2 documentation yet for this device.

6. It's entirely likely that I may have missed something that I had
   been previously told.  I combed through 30+ e-mails over 2 years in
   order to attempt to get this right, but...  So please remind me if
   I missed something.

On a different matter, there are changes in the driver that
potentially affect how IR support is handled.  This issue is forced
upon us because of upcoming changes in the kernel's I2C subsystem.
The changes are all good, but we're probably going to be in for some
rough road until lirc catches up.  The changes that are in the driver
*in theory* should cause no harm, but if you see new IR problems I'd
like to hear about it.  There's a new module option that controls this
behavior; the default value of the option (enabled) should correctly
mimic previous behavior.

I've also gotten some feedback that suggests HVR-1900 digital tuning
might be broken.  The problem (AFAIK) is not due to any recent change
in the pvrusb2 driver but rather may involve the v4l-dvb tuner core.
I don't have an HVR-1900 here so I can't really do much to chase the
problem, unfortunately (my HVR-1950 still works fine).  One thing I've
heard is that running on a 32 bit vs 64 bit system might influence the
trouble.  If you are having HVR-1900 problems (or not), post some
comments here so that others who have an HVR-1900 might be able to
help chase this.

As usual, the pvrusb2 web site can be found at:

  http://www.isely.net/pvrusb2/pvrusb2.html

  -Mike

-- 

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