[pvrusb2] Brand new HVR-1950 - no IR device!

[Michael Krufky]

Mike Isely wrote:
>> The device at 0x1a is the atsc/qam demodulator.  This particular ic 
>> has 16-bit registers, so when you address it using only 8 bits, 
>> results are unpredictable.  This might be related to "[ 8780.549011] 
>> pvrusb2: Timed out control-write" message, which later rendered the 
>> device inoperable.
> 
> The "Timed out control-write" message is a sign of a fatal error.  When 
> this happens, the driver has lost the ability to communicate with the 
> hardware.  The scenario you describe is certainly a plausible 
> explanation for this, though it's unfortunate that any kind of 
> mis-addressed I2C transfer can fatally wedge the bus :-(

That's what happens when you probe a 16-bit device using an 8-bit write.  The 16-bit device hangs, bringing the i2c bus down with it.  Probes are bad.


>> What you actually need to do is configure this IR receiver device as 
>> if it was a zilog commonly found on a Hauppauge PVR150.  I believe 
>> that lirc has a predefined configuration for this, called 
>> "lirc_pvr150" or something.
> 
> It's unfortunate that you have to select an option in LIRC that on the 
> surface sounds like it has nothing to do with this device :-(

The lirc developers should have named it by the device, and not the card it was installed on.  There is a zilog present in certain configurations of almost every Hauppauge PCI / PCIe desgin.

They should have called it, "zilog" rather than "pvr150"

> What Mike has pointed out is that the probe operation causes a fatal 
> problem with the hardware.  What we have here is a situation where if 
> you load the wrong Hauppauge IR driver, then the pvrusb2-driven hardware 
> gets wedged.  Damnit.  I might be able to build a defense against this 
> in the pvrusb2 driver, by detecting the probe attempt and filtering it 
> out (I've had to do this already to protect the cx24840 from fatal 
> probes by the msp3400 chip level driver).  But this approach is at best 
> a horrible hack.

LIRC is the hack.  One can use lirc to bring down an i2c bus on many, many, many other devices.

I wouldnt want to stop you from attempting a workaround, but just know that lirc is the problem, and not pvrusb2.  If you create a workaround for this problem, it would really only mask the issue, while the same scenario persists within other drivers.

I'd be quicker to try to contact an lirc developer and try to resolve this in a safe way, rather than implementing hacks in every driver to mask the issue.

Regards,

Mike Krufky