Re: s5h1411_readreg: readreg error (ret == -5)
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
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
Re: s5h1411_readreg: readreg error (ret == -5)
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
