On 09/17/12 23:07, Antti Palosaari wrote:
On 09/17/2012 11:43 PM, Oliver Schinagl wrote:
On 09/17/12 17:20, Oliver Schinagl wrote:
If tuner communication is really working and it says chip id is 0x5a
then it is different than driver knows. It could be new revision of
tuner. Change chip_id to match 0x5a
Ah, so it's called chip_id on one end, but tuner_id on the other end.
If/when I got this link working properly, I'll write a patch to fix
some
naming consistencies.
No, you are totally wrong now. Chip ID is value inside chip register.
Almost every chip has some chip id value which driver could detect it
is speaking with correct chip. In that case value is stored inside
fc2580.
Tuner ID is value stored inside AF9035 chip / eeprom. It is
configuration value for AF9035 hardware design. It says "that AF9035
device uses FC2580 RF-tuner". AF9035 (FC2580) tuner ID and FC2580 chip
ID are different values having different meaning.
Ok, I understand the difference between Chip ID and Tuner ID I guess,
and with my new knowledge about dynamic debug I know also understand my
findings and where it goes wrong. I also know understand the chipID is
stored in fc2580.c under the fc2580_attach, where it checks for 0x56.
Appearantly my chipID is 0x5a. I wasn't triggered by this as none of the
other fc2580 or af9035 devices had such a change so it wasn't obvious.
Tuner ID is actively being chechked/set in the source, so that seemed
more obvious.
It can't be 0x5a as chipid. I actually found that the vendor driver also
reads from 0x01 once to test the chip.
This function is a generic function which tests I2C interface's
availability by reading out it's I2C id data from reg. address '0x01'.
int fc2580_i2c_test( void ) {
return ( fc2580_i2c_read( 0x01 ) == 0x56 )? 0x01 : 0x00;
}
So something else is going weird. chipid being 0x56 is good though; same
chip revision. However I now got my system to hang, got some soft-hang
errors and the driver only reported failure on loading. No other debug
that I saw from dmesg before the crash. Will investigate more.
huoh.
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 <<< 56
usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 >>> ff
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 <<< 56
usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 >>> 00
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 <<< 56
i2c i2c-5: fc2580: FCI FC2580 successfully identified
Why do you think its value is static - it cannot be changed...
I'm not saying it can be at all :p
according to debug output, I had
[ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a
so to your suggestion, I made it accept chip_id 0x5a as well.
if ((chip_id != 0x56) || (chip_id != 0x5a))
goto err;
But theoretically, it can't be 0x5a, as even the vendor driver would
only check for 0x56 (the function actually never gets called, so any
revision according the those sources could work).
So I will investigate why it would return 0x5a for the chip id :)
Antti
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
