[pvrusb2] pvrusb2 driver status for new hardware version

[Mike Isely]

To all:

I thought people might want to hear what is going on with the new PVR
USB2 hardware that Hauppauge is shipping and how the pvrusb2 driver is
dealing with it.  So here's the update:

An increasing number of people are (not surprisingly) contacting me
about this new device.  About one new person every week shows up;
I imagine that rate is going to rapidly increase :-(

Unfortunately I do not have one of the new devices, which is making
the driver changes needed rather hard to do.  I am trying to get a
sample sent to me but so far I'm not having much success.  (And just
going out and buying one may not work either since I have no guarantee
that the $150 I'd have to drop to get it won't just be another
instance of the older hardware...)

But in working through several people who have this device, I've
learned that the new hardware has at least the following differences:

   1. The msp3400 and saa7115 chips have been replaced with a cx25840.

   2. The eeprom in the device uses 16 bit addresses now instead of 8
      bit addresses.

   3. The USB configuration of the new hardware is no longer different
      before the FX2 firmware is loaded to it.

   4. The FX2 firmware is updated and has a somewhat different command
      set (some commands removed, others added).

   5. There is an as-yet unidentified new part on the board responding
      at I2C address 0x1b.

Change (1) is obviously the biggest change and probably the reason why
the hardware was respun.  The other changes are all mainly annoyances.
For example, change (3) disrupts the mechanism that the pvrusb2 driver
was using to determine if the FX2 firmware needed to be loaded.

The progress as of tonight is:

   o The different eeprom type is working now - the driver can detect
     the larger eeprom and adjust behavior to address it correctly and
     find the Hauppauge metadata within it.

   o The different FX2 firmware so far has not caused a problem.  The
     commands missing from the firmware weren't being used by the
     driver and I haven't yet found a need to use any of the new
     commands yet.

   o The FX2 firmware detection / loading algorithm has been
     successfully adjusted to handle the new device.  Previously the
     driver looked for the different USB configuration to recognize a
     need to load the FX2 firmware.  However now the configuration in
     the "unloaded" case is the same.  So - if the configuration is the
     same - the driver attempts to probe the device with a command.  If
     the device fails to respond to the probe, the driver will load the
     firmware and kick the hardware to reset.  So far that trick is
     working perfectly.

   o I've changed the pvrusb2 driver to communicate correctly with the
     cx25840.ko V4L module if that module attaches to the driver's I2C
     bus.  I also know the correct input settings for the cx25840 for
     the "tuner" input, and that appears to work.

   o With the appearance of the cx25840, we now have another firmware
     image to deal with.  While the cx25840.ko module handles the
     loading of the firmware image, we still need to extract it from
     the Windows drivers (and this firmware image apparently is
     *different* than the one(s) used for ivtv, unfortunately - no idea
     yet if they're compatible).  I've updated fwextract.pl (actually I
     rewrote most of it) to locate and extract the additional firmware
     image.  In fact, fwextract.pl is considerably more generic now; it
     can be configured to extract any number of binary blobs from any
     arbitrary set of container files.

   o Even though the encoder chip (the cx23416) hasn't changed,
     operation of it has, apparently due to the presence of the
     cx25840.  I took a stab at that problem today and on the first
     attempt (!) we got video streaming out of the new device.  Yay!!

The following issues still exist:

   o Still no idea what that part is at I2C address 0x1b.

   o The cx25840 module is doing large I2C transfers to download to its
     chip.  Unfortunately the I2C protocol over USB (for the FX2)
     limits I2C transfers to roughly 60 bytes at a time.  That module
     is pumping 1024 bytes at a time.  There's a simple macro in the
     cx25840 module's source that can be reduced to fix this, but the
     change needs to be committed in (and I haven't done that yet
     because I've been looking for an alternate solution).  Realize
     that cx25840 is a module from V4L; it is not part of the pvrusb2
     driver.  This is a problem because it means that anyone with new
     hardware will no longer be able to use the standalone pvrusb2
     driver even after all these other fixes - since all current kernel
     resident instances of cx25840 all try 1024 bytes at a time.  While
     obviously we want to get pvrusb2 into V4L, it is still useful to
     support people using the out-of-tree standalone driver but this
     problem in cx25840 may simply preclude that.

   o While we did get video from the cx23416, I need to refine the
     changes & tweaks and figure out exactly which ones were the
     critical changes.  We were about to begin that investigation when
     another issue cropped up...

   o There is a serious unsolved problem with detection of the cx25840.
     Right now, if the PVR USB2 hardware is hotplugged in, probes of
     the cx25840 chip over I2C fail.  But if we reload cx25840.ko a
     little while later, then the corresponding probe succeeds and the
     module loads.  I've just spent the past 4 hours in IRC with a
     tester (Martin, see below) chasing this but found no smoking gun
     reason for the problem.

   o We don't know yet what the correct input settings on the cx25840
     should be for the composite or s-video inputs on the device.

At this point, Martin Galese is loaning me his PVR USB2 hardware,
since I can't get Hauppauge to cough one up.  I hope to make more
progress on the driver soon.  I will release a new snapshot as soon as
I have something that I think can be considered useful.  I think we're
really close here.  The fact that we *have* successfully gotten video
to stream out of it with just the right magic coaxing says that odds
are very very good that we'll soon have a stable solution.

Thanks go to Richard Vieira and Martin Galese for being very patient
testers for me.  ALL of my debug work so far has been by proxy through
them.  Martin is sending me his device, and I think that goes way
above and beyond the call 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
                         |                             |