On 09/18/2012 08:18 PM, Oliver Schinagl wrote:
On 09/17/12 23:57, Oliver Schinagl wrote:
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 :)
Turns out, the chip REALLY REALLY is 0x5a. I took some snapshots of both
the tuner and bridge/demodulator and uploaded them to the linuxtv wiki
[1]. If you could compare that one to your Chips? The markings are:
FCI 2580 01BD
AF9035B-N2
1012 QJFSQ
I haven't opened my device at all...
On a more serious note, right now, the driver soft-locks-up. Either with
or without accepting the 0x5a chip_id.
What I do is, manually load all modules, enable debugging and plug in
the device.
Everything appears to work normally for a while, I can do the dmesg dump
etc, but after about 22 seconds, I get this warning:
BUG: soft lockup - CPU#2 stuck for 22s! [udev-acl:2320]
(With the CPU# number being arbitrary). 22s later, another CPU fails. I
haven't waited for the other core's to fail.
Also, removing the module is impossible. Rebooting also fails. I have to
sys-req reboot it.
I don't know how much my patch is responsible for this of course, but
since attaching of the tuner fails due to the wrong chip_id in one case,
the only code affected is the USB id that loads the driver/firmware. I
did see this with the older firmware too btw, so appears to be firmware
unrelated.
In the meantime, I continue finding out why after accepting chip_id
0x5a, it still fails on tuner attach. I suppose somehow the tuner_id
isn't matching, which is weird, but will find out about it in the next
few days.
Tuner attach does nothing more that could fail than check that one
register. It is almost impossible to get it failing if tuner ID match.
Maybe I2C communication is not working, error returned and it bails out?
Anyhow, such situation should be visible when debugs are enabled.
[1] http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T
regards
Antti
--
http://palosaari.fi/
--
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
