From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.kapsi.fi ([217.30.184.167]:39989 "EHLO mail.kapsi.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751718Ab2ISKxY (ORCPT ); Wed, 19 Sep 2012 06:53:24 -0400 Message-ID: <5059A410.3020106@iki.fi> Date: Wed, 19 Sep 2012 13:53:04 +0300 From: Antti Palosaari MIME-Version: 1.0 To: Oliver Schinagl CC: linux-media Subject: Re: [PATCH] Support for Asus MyCinema U3100Mini Plus References: <1347223647-645-1-git-send-email-oliver+list@schinagl.nl> <504D00BC.4040109@schinagl.nl> <504D0F44.6030706@iki.fi> <504D17AA.8020807@schinagl.nl> <504D1859.5050201@iki.fi> <504DB9D4.6020502@schinagl.nl> <504DD311.7060408@iki.fi> <504DF950.8060006@schinagl.nl> <504E2345.5090800@schinagl.nl> <5055DD27.7080501@schinagl.nl> <505601B6.2010103@iki.fi> <5055EA30.8000200@schinagl.nl> <50560B82.7000205@iki.fi> <50564E58.20004@schinagl.nl> <50566260.1090108@iki.fi> <5056DE5C.70003@schinagl.nl> <50571F83.10708@schinagl.nl> <50572290.8090308@iki.fi> <505724F0.20502@schinagl.nl> <50572B1D.3080807@iki.fi> <50573FC5.40307@schinagl.nl> <50578B61.1040700@schinagl.nl> <5057910C.10408@iki.fi> <50579CC3.5040703@schinagl.nl> <5058ACE4.6070408@schinagl.nl> <5058FAD9.4090204@iki.fi> <5059A155.3000502@schinagl.nl> In-Reply-To: <5059A155.3000502@schinagl.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On 09/19/2012 01:41 PM, Oliver Schinagl wrote: > On 19-09-12 00:51, Antti Palosaari wrote: >> 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. > When it hangs the PC, nothing is visible. All functions bail out with > error code -19. The fc2580 module is then used -1 times and can't be > unloaded, as can't the others. As with my other post, when the tuner IS > detected and is working, no hangs or stalls appear to be happening. Sounds like a bug somewhere in dvb-usb-v2 framework. Actually, I have seen similar cases few times but lastly I made quick decision it was due to "positive" error status returned. Maybe I should take new round of tests and checks... >> >>> [1] http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T >> >> regards >> Antti >> > -- http://palosaari.fi/