[pvrusb2] pvrusb2 driver status for new hardware version

[Hans Verkuil]

On Monday 06 March 2006 05:13, Mike Isely wrote:
> 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.

This is almost certainly the wm8775 chip, the same that is also used on 
PVR150/500 cards. That chip also uses 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).

Are you sure they are different? Can you mail me the firmware you 
extracted?

> 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.

It's likely to be the same as the PVR150. This PVRUSB2 device seems to 
be basically a PVR150 with an USB interface.

	Hans

>
> 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