s5h1411_readreg: readreg error (ret == -5)

s5h1411_readreg: readreg error (ret == -5)

[Roger]

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



$ uname -a
Linux localhost2.local 2.6.29-gentoo-r4Y #9 SMP PREEMPT Tue Jun 2
03:38:16 AKDT 2009 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux

Using pvrusb2 module which requests firmware to initialize a Hauppauge
HVR-1950 device.

-- 
Roger
http://rogerx.freeshell.org

Re: s5h1411_readreg: readreg error (ret == -5)

[Mike Isely]

On Sun, 7 Jun 2009, Roger wrote:

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

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.

  -Mike


-- 

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

Re: s5h1411_readreg: readreg error (ret == -5)

[Steven Toth]

Mike Isely wrote:
> On Sun, 7 Jun 2009, Roger wrote:
> 
>> >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?
> 
> 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.

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)

I don't have all the details so your failure case could be complete different.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: s5h1411_readreg: readreg error (ret == -5)

[Mike Isely]

On Thu, 11 Jun 2009, Steven Toth wrote:

> Mike Isely wrote:
> > On Sun, 7 Jun 2009, Roger wrote:
> > 
> > > >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?
> > 
> > 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.
> 
> 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


-- 

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

Re: s5h1411_readreg: readreg error (ret == -5)

[Roger]

On Thu, 2009-06-11 at 13:48 -0500, Mike Isely wrote:
> On Thu, 11 Jun 2009, Steven Toth wrote:
> 
> > Mike Isely wrote:
> > > On Sun, 7 Jun 2009, Roger wrote:
> > > 
> > > > >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?
> > > 
> > > 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.
> > 
> > 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
> 
> 
> -- 
> 
> Mike Isely
> isely @ isely (dot) net
> PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8


Just a freak accidental view of dmesg, and I found it absolutely loaded
with the following repeated errors (until the point I reloaded the
pvrusb2 modules this morning along with the cold boot of the HVR-1950
usb device).

All I have to say is, I've never seen this many s5h1411 related errors
ever.  I've set "options pvrusb2 debug=19".  So I think I'm onto
something?

reg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_writereg: writereg error 0x19 0xf7 0x0000, ret == -5)
s5h1411_writereg: writereg error 0x19 0xf7 0x0001, ret == -5)
s5h1411_writereg: writereg error 0x19 0xf5 0x0001, ret == -5)
tda18271_write_regs: ERROR: i2c_transfer returned: -5
tda18271_init: error -5 on line 805
tda18271_tune: error -5 on line 831
tda18271_set_params: error -5 on line 912
s5h1411_writereg: writereg error 0x19 0xf5 0x0000, ret == -5)
s5h1411_writereg: writereg error 0x19 0xf7 0x0000, ret == -5)
s5h1411_writereg: writereg error 0x19 0xf7 0x0001, ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)



-- 
Roger
http://rogerx.freeshell.org

Re: s5h1411_readreg: readreg error (ret == -5)

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


-- 

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

Re: s5h1411_readreg: readreg error (ret == -5)

[Andy Walls]

On Fri, 2009-06-12 at 15:33 -0500, Mike Isely wrote:
> 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
};


>   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

>   -Mike

Re: s5h1411_readreg: readreg error (ret == -5)

[Mike Isely]

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

Still digging through this.

  -Mike


On Fri, 12 Jun 2009, Andy Walls wrote:

> On Fri, 2009-06-12 at 15:33 -0500, Mike Isely wrote:
> > 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
> };
> 
> 
> >   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
> 
> >   -Mike
> 
> 
> 

-- 

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

Re: s5h1411_readreg: readreg error (ret == -5)

[hermann pitton]

Hi,

Am Freitag, den 12.06.2009, 16:27 -0500 schrieb Mike Isely:
> Well now I feel like an idiot.  Thanks for pointing that out in my own 
> code :-)
> 
> Still digging through this.
> 
>   -Mike

despite of that and to feed the weasel.

We'll have to look through different drivers, if we can make more use of
potential present device information in the eeproms.

There are always OEMs not following for example the Philips eeprom
layout in all details, most visible on different primary analog/hybrid
tuner type enumeration, and I don't even claim to know the latter in all
details,

and it needs more work on it,

but we have a lot of congruence for details in the 16 bytes including
0x40 and up from it across most manufacturers, including Hauppauge.

According to Hartmut, unfortunately not active currently, even different
LNA types, more and more devices with such do appear, are encoded in the
eeprom, if the OEM follows the plan. I don't know where yet, but might
be worth some time to try to find it out.

I had some hopes that this would also be known for the Hauppauge
eeproms, but seems not.

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)

Cheers,
Hermann

> 
On Fri, 12 Jun 2009, Andy Walls wrote:
> 
> > On Fri, 2009-06-12 at 15:33 -0500, Mike Isely wrote:
> > > 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
> > };
> > 
> > 
> > >   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
> > 
> > >   -Mike
> > 
> > 
> > 
> 

Re: s5h1411_readreg: readreg error (ret == -5)

[hermann pitton]

[snip]
> 
> 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)

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

Regards.
Hermann

Re: s5h1411_readreg: readreg error (ret == -5)

[Roger]

> On Fri, 12 Jun 2009, Andy Walls wrote:
> > 
> > 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

And, just to verify the obvious:

WinTV-HVR-1950
NTSC/ATSC/QAM
75111 LF
REV C3E9

(with a very nice light green RoHS sticker)

-- 
Roger
http://rogerx.freeshell.org

Re: s5h1411_readreg: readreg error (ret == -5)

[Roger]

On Sat, 2009-06-13 at 02:07 +0200, hermann pitton wrote:
> [snip]
> > 
> > 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
published for the s5h1411. :-/

-- 
Roger
http://rogerx.freeshell.org

Re: s5h1411_readreg: readreg error (ret == -5)

[Andy Walls]

On Fri, 2009-06-12 at 16:27 -0500, Mike Isely wrote:
> Well now I feel like an idiot.  Thanks for pointing that out in my own 
> code :-)

Well, that wasn't my objective, but you're welcome! ;)

Don't worry.  I can almost guarantee you'll have an opportunity to
return the favor sometime in the future. :)

Regards,
Andy

> Still digging through this.
> 
>   -Mike

Re: s5h1411_readreg: readreg error (ret == -5)

[Steven Toth]

hermann pitton wrote:
> [snip]
>> 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)
> 
> forgot, and not any LNB supplies behind some i2c bridges, shared or not
> on whatever.

The use of Hauppauge eeproms I consider advisory at best. Yes, they have 
reasonably good fields to identify tuners, IR but a number of recent silicon 
additions (last 3 years) to the product line is not fully implemented in the 
eeproms. Some of the important feature decisions is done purely in software 
based on sub id for example.

In general I agree with Hermann's comments, that is,  where possible making 
maximum use of the eeprom.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com