s5h1411_readreg: readreg error (ret == -5)

From looking at "linux/drivers/media/dvb/frontends/s5h1411.c", The

Quoted 1 line

From looking at "linux/drivers/media/dvb/frontends/s5h1411.c", The

s5h1411_readreg wants to see "2" but is getting "-5" from the i2c bus.

--- Snip ---

s5h1411_readreg: readreg error (ret == -5)
pvrusb2: unregistering DVB devices
device: 'dvb0.net0': device_unregister

--- Snip ---

What exactly does this mean?

Quoted 11 lines · Roger

Quoted 1 line

From looking at "linux/drivers/media/dvb/frontends/s5h1411.c", The

s5h1411_readreg wants to see "2" but is getting "-5" from the i2c bus.

--- Snip ---

s5h1411_readreg: readreg error (ret == -5)
pvrusb2: unregistering DVB devices
device: 'dvb0.net0': device_unregister

--- Snip ---

Quoted 1 line

What exactly does this mean?

Roger:

It means that the module attempted an I2C transfer and the transfer failed. The I2C adapter within the pvrusb2 driver will return either the number of bytes that it transferred or a failure code. The failure code, as is normal convention in the kernel, will be a negated errno value. Thus the expected value of 2 would be the fact that it probably tried a 2 byte transfer, while the actual value returned of -5 indicate an EIO error, which is what the pvrusb2 driver will return when the underlying I2C transaction has failed.

Of course the real question is not that it failed but why it failed. And for that I unfortunately do not have an answer. It's possible that the s5h1411 driver did something that the chip didn't like and the chip responded by going deaf on the I2C bus. More than a few I2C-driven parts can behave this way. It's also possible that the part might have been busy and unable to respond - but usually in that case the driver for such a part will be written with this in mind and will know how / when to communicate with the hardware.

Quoted 25 lines · Mike Isely

Quoted 5 lines · Roger

Quoted 1 line

From looking at "linux/drivers/media/dvb/frontends/s5h1411.c", The

s5h1411_readreg wants to see "2" but is getting "-5" from the i2c bus.

--- Snip ---

Quoted 7 lines

s5h1411_readreg: readreg error (ret == -5)
pvrusb2: unregistering DVB devices
device: 'dvb0.net0': device_unregister

--- Snip ---

What exactly does this mean?

Roger:

It means that the module attempted an I2C transfer and the transfer failed. The I2C adapter within the pvrusb2 driver will return either the number of bytes that it transferred or a failure code. The failure code, as is normal convention in the kernel, will be a negated errno value. Thus the expected value of 2 would be the fact that it probably tried a 2 byte transfer, while the actual value returned of -5 indicate an EIO error, which is what the pvrusb2 driver will return when the underlying I2C transaction has failed.

Quoted 8 lines

Of course the real question is not that it failed but why it failed. And for that I unfortunately do not have an answer. It's possible that the s5h1411 driver did something that the chip didn't like and the chip responded by going deaf on the I2C bus. More than a few I2C-driven parts can behave this way. It's also possible that the part might have been busy and unable to respond - but usually in that case the driver for such a part will be written with this in mind and will know how / when to communicate with the hardware.

Roger:

Another possibility, although I don't know the PVRUSB2 driver too well, the s5h1411 is being held in reset when the driver unloads _AFTER_ the last active use was analog video (assuming the s5h1411 is floated in reset as the FX2 input port might be shared with the analog encoder)

Quoted 35 lines · Steven Toth

Quoted 25 lines · Mike Isely

Quoted 5 lines · Roger

Quoted 1 line

From looking at "linux/drivers/media/dvb/frontends/s5h1411.c", The

s5h1411_readreg wants to see "2" but is getting "-5" from the i2c bus.

--- Snip ---

Quoted 7 lines

s5h1411_readreg: readreg error (ret == -5)
pvrusb2: unregistering DVB devices
device: 'dvb0.net0': device_unregister

--- Snip ---

What exactly does this mean?

Roger:

It means that the module attempted an I2C transfer and the transfer failed. The I2C adapter within the pvrusb2 driver will return either the number of bytes that it transferred or a failure code. The failure code, as is normal convention in the kernel, will be a negated errno value. Thus the expected value of 2 would be the fact that it probably tried a 2 byte transfer, while the actual value returned of -5 indicate an EIO error, which is what the pvrusb2 driver will return when the underlying I2C transaction has failed.

Quoted 8 lines

Of course the real question is not that it failed but why it failed. And for that I unfortunately do not have an answer. It's possible that the s5h1411 driver did something that the chip didn't like and the chip responded by going deaf on the I2C bus. More than a few I2C-driven parts can behave this way. It's also possible that the part might have been busy and unable to respond - but usually in that case the driver for such a part will be written with this in mind and will know how / when to communicate with the hardware.

Quoted 6 lines

Roger:

Another possibility, although I don't know the PVRUSB2 driver too well, the s5h1411 is being held in reset when the driver unloads _AFTER_ the last active use was analog video (assuming the s5h1411 is floated in reset as the FX2 input port might be shared with the analog encoder)

Good point. The pvrusb2 driver is not currently doing anything specific
- or at least deliberate - via the FX2 to move that part in/out of reset. (Of course, I am issuing FX2 commands to shift modes and that might in turn be triggering other things.) But even if I did do something specific, what kind of impact is that likely to do on the corresponding, blissfully ignorant, driver?

This actually drives towards a larger issue - the pvrusb2 driver works with various V4L-only sub-devices, e.g. cx25840, which have no relevance in digital mode but I can't really control when that corresponding driver is enabled / disabled. So if I have to take an extra step to physically disable a chip when in digital mode, then this might impact the sub-driver which otherwise is going to have no clue what is really going on.

-Mike

Signature · 3 lines

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

I am unable to reproduce the s5h1411 error here.

However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder if Hauppauge has changed chips on newer devices and so you're running a different tuner module.

That would explain the different behavior.
Unfortunately it also means it will be very difficult for me to track the problem down here since I don't have that device variant.

-Mike

Quoted 5 lines · Mike Isely

I am unable to reproduce the s5h1411 error here.

However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder if Hauppauge has changed chips on newer devices and so you're running a different tuner module.

The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:

static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
        .frontend_attach = pvr2_s5h1409_attach,
        .tuner_attach    = pvr2_tda18271_8295_attach,
};

static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
        .frontend_attach = pvr2_s5h1411_attach,
        .tuner_attach    = pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
                .description = "WinTV HVR-1950 Model Category 750xx",
...
                .dvb_props = &pvr2_750xx_dvb_props,

#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = "WinTV HVR-1950 Model Category 751xx",
...

                .dvb_props = &pvr2_751xx_dvb_props,

#endif
};

Quoted 3 lines

That would explain the different behavior.
Unfortunately it also means it will be very difficult for me to track the problem down here since I don't have that device variant.

If you have more than 1 HVR-1950, maybe one is a 751xx variant.

When I ran into I2C errors often, it was because of PCI bus errors screwing up the bit banging. Obviously, that's not the case here.

-Andy

Quoted 1 line

-Mike

Well now I feel like an idiot. Thanks for pointing that out in my own code :-)

Still digging through this.

-Mike

Quoted 50 lines · Mike Isely

Quoted 5 lines

I am unable to reproduce the s5h1411 error here.

However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder if Hauppauge has changed chips on newer devices and so you're running a different tuner module.

The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:

static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
        .frontend_attach = pvr2_s5h1409_attach,
        .tuner_attach    = pvr2_tda18271_8295_attach,
};

static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
        .frontend_attach = pvr2_s5h1411_attach,
        .tuner_attach    = pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
                .description = "WinTV HVR-1950 Model Category 750xx",
...
                .dvb_props = &pvr2_750xx_dvb_props,

#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = "WinTV HVR-1950 Model Category 751xx",
...

                .dvb_props = &pvr2_751xx_dvb_props,

#endif
};

Quoted 3 lines

That would explain the different behavior.
Unfortunately it also means it will be very difficult for me to track the problem down here since I don't have that device variant.

If you have more than 1 HVR-1950, maybe one is a 751xx variant.

When I ran into I2C errors often, it was because of PCI bus errors screwing up the bit banging. Obviously, that's not the case here.

-Andy

Quoted 1 line

-Mike

The most undiscovered configurations seem to be such ones about antenna inputs and their switching. Again according to Hartmut, and he did not know exactly what is going on here, some for us and him at this point unknown checksums are used to derive even that information :(

For what I can see, and I might be of course still wrong, we can also not determine plain digital tuner types, digital demodulator types of any kind and the type of possibly present second and third tuners, but at least their addresses, regularly shared by multiple chips, become often visible. (some OEMs have only 0xff still for all that)

Quoted 17 lines

The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:

static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
        .frontend_attach = pvr2_s5h1409_attach,
        .tuner_attach    = pvr2_tda18271_8295_attach,
};

static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
        .frontend_attach = pvr2_s5h1411_attach,
        .tuner_attach    = pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
                .description = "WinTV HVR-1950 Model Category 750xx",
...
                .dvb_props = &pvr2_750xx_dvb_props,

Quoted 8 lines

#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = "WinTV HVR-1950 Model Category 751xx",
...

                .dvb_props = &pvr2_751xx_dvb_props,

#endif

[snip]

Quoted 5 lines

The most undiscovered configurations seem to be such ones about antenna inputs and their switching. Again according to Hartmut, and he did not know exactly what is going on here, some for us and him at this point unknown checksums are used to derive even that information :(

From my brief research on the Internet, I didn't see any chip specs

Well now I feel like an idiot. Thanks for pointing that out in my own code :-)

Still digging through this.

-Mike

[snip]

Quoted 5 lines

The most undiscovered configurations seem to be such ones about antenna inputs and their switching. Again according to Hartmut, and he did not know exactly what is going on here, some for us and him at this point unknown checksums are used to derive even that information :(

Quoted 5 lines

For what I can see, and I might be of course still wrong, we can also not determine plain digital tuner types, digital demodulator types of any kind and the type of possibly present second and third tuners, but at least their addresses, regularly shared by multiple chips, become often visible. (some OEMs have only 0xff still for all that)

forgot, and not any LNB supplies behind some i2c bridges, shared or not on whatever.