Re: [PATCH] Support for Asus MyCinema U3100Mini Plus

[Oliver Schinagl <oliver+list@schinagl.nl>]

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


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.


[1] http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T
>>
>> Antti
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html