From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from 7of9.schinagl.nl ([88.159.158.68]:38747 "EHLO 7of9.schinagl.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133Ab2IPWKe (ORCPT ); Sun, 16 Sep 2012 18:10:34 -0400 Message-ID: <50564E58.20004@schinagl.nl> Date: Mon, 17 Sep 2012 00:10:32 +0200 From: Oliver Schinagl MIME-Version: 1.0 To: Antti Palosaari 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> In-Reply-To: <50560B82.7000205@iki.fi> 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/16/12 19:25, Antti Palosaari wrote: > On 09/16/2012 06:03 PM, Oliver Schinagl wrote: >> I don't have windows, so capturing using windows is near impossible. >> Also since the vendor driver used to work, I guess I will have to dig >> into that more. > > You could capture data from Linux too (eg. Wireshark). Ah of course. I'll dig up the old vendor driver and see if I can get it running on 3.2 or better yet, on 3.5/your-3.6. I know there's patches for 3.2 but I've never tested those. Otherwise the older 2.6.2* series should still work. > > But with a little experience you could see those GPIOs reading existing > Linux driver and then do some tests to see what happens. For example > some GPIO powers tuner off, you will see I2C error. Changing it back > error disappears. I have zero experience so I'll try to figure things out. I guess you currently turn on/off GPIO's etc in the current driver? Any line which does this so I can examine how it's done? As for the I2C errors, I suppose the current driver will spew those out? Speaking off, in my previous message, I wrote about the driver spitting out the following error: [dvb_usb_af9035]af9035_read_config =_ "%s: [%d]tuner=%02x\012" None of the values where set however. Did I miss-configure anything for it to cause to 'forget' substituting? > >> Since all the pieces should be there, fc2580 driver, af9033/5 driver, >> it's just a matter of glueing things together, right? I'll dig further >> into it and see what I can find/do. > > Correct. Tuner init (demod settings fc2580) for is needed for af9033. > And GPIOs for AF9035. In very bad luck some changes for fc2580 is needed > too, but it is not very, very, unlikely. > > This patch is very similar you will need to do (tda18218 tuner support > for af9035): > http://patchwork.linuxtv.org/patch/10547/ I re-did my patch using that as a template (before I used your work on the rtl) and got the exact result. Your rtl|fc2580 combo btw (from bare memory) didn't have the fc2580_init stream in af9033_priv.h. What exactly gets init-ed there? The af9033 to work with the fc2580? > > > regards > Antti Thanks so far, Oliver >> >> On 09/16/12 18:43, Antti Palosaari wrote: >>> Hello >>> You have about all the possible info. There is chipset vendor driver >>> look example and existing Linux drivers for all the used chips. Just few >>> lines of code needed for the device profile. I surely can help, but it >>> is not something I would like to teach and say do that and test that. It >>> is wasting my time. I encourage you to take one simple USB capture from >>> Windows driver and look help from there. GPIOs are the first thing to >>> test. >>> >>> Also maintaining driver without a hardware is something that causes >>> always headache later when some changes are needed to do that >>> driver.... :s >>> >>> regards >>> Antti >>> >>> >>> >>> On 09/16/2012 05:07 PM, Oliver Schinagl wrote: >>>> Any pointers where else to look? I'm kinda lost at the moment :) >>>> >>>> Oliver >>>> >>>> On 09/10/12 19:28, Oliver Schinagl wrote: >>>>> On 09/10/12 16:29, Oliver Schinagl wrote: >>>>>> On 10-09-12 13:46, Antti Palosaari wrote: >>>>>>> On 09/10/2012 12:58 PM, Oliver Schinagl wrote: >>>>>>>> Changed the address as recommended, which after reading 7bit and >>>>>>>> 8bit >>>>>>>> addressing makes perfect sense (drop the r/w bit and get the actual >>>>>>>> address). >>>>>>>> >>>>>>>> static struct fc2580_config af9035_fc2580_config = { >>>>>>>> - .i2c_addr = 0xac, >>>>>>>> + .i2c_addr = 0x56, >>>>>>>> .clock = 16384000, >>>>>>>> }; >>>>>>>> >>>>>>>> >>>>>>>> So now the address should actually be correct ;) >>>>>>>> >>>>>>>> Unfortunately, nothing. What other debug options do I need to >>>>>>>> enable >>>>>>>> besides CONFIG_DVB_USB_DEBUG to get more interesting output? >>>>>>> >>>>>>> For me it sees something happens as there is no I2C error seen >>>>>>> anymore. >>>>>>> >>>>>>> AF9035 driver uses Kernel dynamic debugs. CONFIG_DVB_USB_DEBUG is >>>>>>> legacy and proprietary DVB subsystem debug which should not be used >>>>>>> anymore. >>>>>>> You could order dynamic debugs like that: >>>>>>> modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' > >>>>>>> /sys/kernel/debug/dynamic_debug/control >>>>>>> >>>>>>> For tuner, demod and dvb_usbv2 similarly if needed. >>>>>> I've did and added output from control and dmesg output. >>>>>> >>>>>> I don't exactly know how to read the dynamic debug output, the only >>>>>> thing that jumped out at me, was: >>>>>> drivers/media/dvb-frontends/af9033.c:327 [af9033]af9033_init =p "%s: >>>>>> unsupported tuner ID=%d\012" >>>>>> >>>>>> So I will search and see where in the driver the supported tunerID's >>>>>> are >>>>>> stored and fix that. >>>>>> >>>>>> Any other pointers/things you see I should look at? >>>>> Appearantly, I setup the tuner, like the others, but it skips that >>>>> because the tuner id is wrong/not set. >>>>> >>>>> case AF9033_TUNER_FC2580: >>>>> len = ARRAY_SIZE(tuner_init_fc2580); >>>>> init = tuner_init_fc2580; >>>>> break; >>>>> >>>>> So where is the tuner set? >>>>> >>>>> I did find this bit: >>>>> >>>>> tatic int af9035_read_config(struct dvb_usb_device *d) >>>>> { >>>>> >>>>> ret = af9035_rd_reg(d, EEPROM_1_TUNER_ID + eeprom_shift, >>>>> &tmp); >>>>> >>>>> which suggests that it comes from the actual eeprom. I assumed that >>>>> the >>>>> 'init/script/firmware' bit, the first 'message' was the ID, 0x32 in >>>>> the >>>>> case of this tuner. I guess I'm wrong? >>>>> >>>>> The log is not exactly helpful either: >>>>> drivers/media/usb/dvb-usb-v2/af9035.c:542 >>>>> [dvb_usb_af9035]af9035_read_config =_ "%s: [%d]tuner=%02x\012" >>>>> >>>>> So close, yet so far. So if I'm right, the actual ID of the tuner and >>>>> the first byte in the init are not always the same? Then why use the >>>>> define in the first place there? And why would the 'official' code >>>>> user >>>>> 0x32 as tuner ID. Or is this simply a dec/hex conversion goof? >>>>> >>>>> >>>>> Oliver >>>>> >>>>>>> >>>>>>>> Anyway, dmesg reports the following. >>>>>>>> [60.071538] usb 1-3: new high-speed USB device number 3 using >>>>>>>> ehci_hcd >>>>>>>> [60.192627] usb 1-3: New USB device found, idVendor=0b05, >>>>>>>> idProduct=1779 >>>>>>>> [60.192638] usb 1-3: New USB device strings: Mfr=1, Product=2, >>>>>>>> SerialNumber=3 >>>>>>>> [60.192646] usb 1-3: Product: AF9035A USB Device >>>>>>>> [60.192652] usb 1-3: Manufacturer: Afa Technologies Inc. >>>>>>>> [60.192657] usb 1-3: SerialNumber: AF010asdfasdf12314 >>>>>>>> [60.198686] input: Afa Technologies Inc. AF9035A USB Device as >>>>>>>> /devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.1/input/input14 >>>>>>>> [60.198832] hid-generic 0003:0B05:1779.0003: input: USB HID v1.01 >>>>>>>> Keyboard [Afa Technologies Inc. AF9035A USB Device] on >>>>>>>> usb-0000:00:12.2-3/input1 >>>>>>>> [60.263893] usbcore: registered new interface driver dvb_usb_af9035 >>>>>>>> [60.264605] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in >>>>>>>> cold >>>>>>>> state >>>>>>>> [60.273924] usb 1-3: dvb_usbv2: downloading firmware from file >>>>>>>> 'dvb-usb-af9035-02.fw' >>>>>>>> [60.584267] dvb_usb_af9035: firmware version=11.5.9.0 >>>>>>>> [60.584287] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in >>>>>>>> warm >>>>>>>> state >>>>>>>> [60.586802] usb 1-3: dvb_usbv2: will pass the complete MPEG2 >>>>>>>> transport >>>>>>>> stream to the software demuxer >>>>>>>> [60.586871] DVB: registering new adapter (Asus U3100Mini Plus) >>>>>>>> [60.595637] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1 >>>>>>>> [60.595654] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech >>>>>>>> AF9033 (DVB-T))... >>>>>>>> [60.599889] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while >>>>>>>> loading driver (-19) >>>>>>>> >>>>>>>> I then tried using the firmware that came with said driver, as the >>>>>>>> version seems slightly different/newer. >>>>>>>> >>>>>>>> #define FW_RELEASE_VERSION "v8_8_63_0" >>>>>>>> >>>>>>>> #define DVB_LL_VERSION1 11 >>>>>>>> #define DVB_LL_VERSION2 22 >>>>>>>> #define DVB_LL_VERSION3 12 >>>>>>>> #define DVB_LL_VERSION4 0 >>>>>>>> >>>>>>>> #define DVB_OFDM_VERSION1 5 >>>>>>>> #define DVB_OFDM_VERSION2 66 >>>>>>>> #define DVB_OFDM_VERSION3 12 >>>>>>>> #define DVB_OFDM_VERSION4 0 >>>>>>>> >>>>>>>> (which also gets displayed when loading the firmware, originally on >>>>>>>> the >>>>>>>> old kernel). >>>>>>>> >>>>>>>> This however results in a hard lock/dump when plugging in the >>>>>>>> device. >>>>>>>> Are there certain size restrictions etc? What I did to obtain said >>>>>>>> firmware was write a simple program that reads the array, static >>>>>>>> unsigned char Firmware_codes[] and outputs the read bytes to a >>>>>>>> file. >>>>>>>> From what I saw from the -02 firmware, the first few bytes are >>>>>>>> identical (header?) so should be right procedure. >>>>>>> >>>>>>> Firmare surely works but you make some mistake. I have extracted >>>>>>> those >>>>>>> from the windows driver. >>>>>>> >>>>>>> http://palosaari.fi/linux/v4l-dvb/firmware/af9035/ >>>>>>> >>>>>> A link to, or your files should be listed at the linuxdvb firmware >>>>>> download page ;) >>>>>> >>>>>> I noticed your latest firmware is way newer then the one I had. So >>>>>> deffinatly using that one. >>>>>>>> Btw, when using the -02 firmware and trying to unload the af9033 >>>>>>>> module, >>>>>>>> either with or without the stick plugged in, it just hangs there >>>>>>>> for a >>>>>>>> long time. Reboot fails too (it hangs at trying to disable swap). >>>>>>>> Only a >>>>>>>> sys-req-reisub successfully reboots. >>>>>>>> >>>>>>>> oliver >>>>>>> >>>>>>> >>>>>>> Antti >>>>>> >>>>>> Oliver >>>>>>>> >>>>>>>> >>>>>>>> On 09/10/12 00:29, Antti Palosaari wrote: >>>>>>>>> On 09/10/2012 01:26 AM, Oliver Schinagl wrote: >>>>>>>>>> On 09/09/12 23:51, Antti Palosaari wrote: >>>>>>>>>>> On 09/09/2012 11:49 PM, Oliver Schinagl wrote: >>>>>>>>>>>> Hi All/Antti, >>>>>>>>>>>> >>>>>>>>>>>> I used Antti's previous patch to try to get some support in for >>>>>>>>>>>> the >>>>>>>>>>>> Asus >>>>>>>>>>>> MyCinema U3100Mini Plus as it uses a supported driver (af9035) >>>>>>>>>>>> and now >>>>>>>>>>>> supported tuner (FCI FC2580). >>>>>>>>>>>> >>>>>>>>>>>> It compiles fine and almost works :( >>>>>>>>>>>> >>>>>>>>>>>> Here's what I get, which I have no idea what causes it. >>>>>>>>>>>> >>>>>>>>>>>> dmesg output: >>>>>>>>>>>> [ 380.677434] usb 1-3: New USB device found, idVendor=0b05, >>>>>>>>>>>> idProduct=1779 >>>>>>>>>>>> [ 380.677445] usb 1-3: New USB device strings: Mfr=1, >>>>>>>>>>>> Product=2, >>>>>>>>>>>> SerialNumber=3 >>>>>>>>>>>> [ 380.677452] usb 1-3: Product: AF9035A USB Device >>>>>>>>>>>> [ 380.677458] usb 1-3: Manufacturer: Afa Technologies Inc. >>>>>>>>>>>> [ 380.677463] usb 1-3: SerialNumber: AF01020abcdef12301 >>>>>>>>>>>> [ 380.683361] input: Afa Technologies Inc. AF9035A USB >>>>>>>>>>>> Device as >>>>>>>>>>>> /devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.1/input/input15 >>>>>>>>>>>> [ 380.683505] hid-generic 0003:0B05:1779.0004: input: USB HID >>>>>>>>>>>> v1.01 >>>>>>>>>>>> Keyboard [Afa Technologies Inc. AF9035A USB Device] on >>>>>>>>>>>> usb-0000:00:12.2-3/input1 >>>>>>>>>>>> [ 380.703807] usbcore: registered new interface driver >>>>>>>>>>>> dvb_usb_af9035 >>>>>>>>>>>> [ 380.704553] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini >>>>>>>>>>>> Plus' in >>>>>>>>>>>> cold >>>>>>>>>>>> state >>>>>>>>>>>> [ 380.705075] usb 1-3: dvb_usbv2: downloading firmware from >>>>>>>>>>>> file >>>>>>>>>>>> 'dvb-usb-af9035-02.fw' >>>>>>>>>>>> [ 381.014996] dvb_usb_af9035: firmware version=11.5.9.0 >>>>>>>>>>>> [ 381.015018] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini >>>>>>>>>>>> Plus' in >>>>>>>>>>>> warm >>>>>>>>>>>> state >>>>>>>>>>>> [ 381.017172] usb 1-3: dvb_usbv2: will pass the complete MPEG2 >>>>>>>>>>>> transport stream to the software demuxer >>>>>>>>>>>> [ 381.017242] DVB: registering new adapter (Asus U3100Mini >>>>>>>>>>>> Plus) >>>>>>>>>>>> [ 381.037184] af9033: firmware version: LINK=11.5.9.0 >>>>>>>>>>>> OFDM=5.17.9.1 >>>>>>>>>>>> [ 381.037200] usb 1-3: DVB: registering adapter 0 frontend 0 >>>>>>>>>>>> (Afatech >>>>>>>>>>>> AF9033 (DVB-T))... >>>>>>>>>>>> [ 381.044197] i2c i2c-1: fc2580: i2c rd failed=-5 reg=01 len=1 >>>>>>>>>>>> [ 381.044357] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error >>>>>>>>>>>> while >>>>>>>>>>>> loading driver (-19) >>>>>>>>>>> >>>>>>>>>>> I2C communication to tuner chip does not work at all. It >>>>>>>>>>> tries to >>>>>>>>>>> read >>>>>>>>>>> chip id register but fails. If you enable debugs you will see >>>>>>>>>>> which >>>>>>>>>>> error status af9035 reports. >>>>>>>>>> CONFIG_DVB_USB_DEBUG was enabled, but nothing extra :( >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is likely 3 possibilities: >>>>>>>>>>> 1) wrong I2C address >>>>>>>>>> Well as linked before, I used it from the 'official' driver, >>>>>>>>>> where it >>>>>>>>>> says: >>>>>>>>>> #define FC2580_ADDRESS 0xAC >>>>>>>>>> >>>>>>>>>> grepping the entire source of theirs, I then found this in >>>>>>>>>> FC2580.c >>>>>>>>>> TunerDescription tuner_FC2580 = { >>>>>>>>>> FC2580_open, /** Function to open tuner. */ >>>>>>>>>> FC2580_close, /** Function to close tuner. */ >>>>>>>>>> FC2580_set, /** Function set frequency. */ >>>>>>>>>> FC2580_scripts, /** Scripts. */ >>>>>>>>>> FC2580_scriptSets, /** Length of scripts. */ >>>>>>>>>> FC2580_ADDRESS, /** The I2C address of tuner. */ >>>>>>>>>> 1, /** Valid length of tuner register. */ >>>>>>>>>> 0, /** IF frequency of tuner. */ >>>>>>>>>> True, /** Spectrum inversion. */ >>>>>>>>>> 0x32, /** tuner id */ >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> The only other thing that I recognize is the scripts, which is >>>>>>>>>> some >>>>>>>>>> init >>>>>>>>>> code (which I asked about below, which should also be right, >>>>>>>>>> unless I >>>>>>>>>> made a typo) and the tuner id, which is the first thing in the >>>>>>>>>> script >>>>>>>>>> and in my patch defined as AF9033_TUNER_FC2580. No idea of its >>>>>>>>>> significance :) >>>>>>>>>> >>>>>>>>>>> 2) wrong GPIOs >>>>>>>>>>> * tuner is not powered on or it is on standby >>>>>>>>>> How/where would I check that? >>>>>>>>>> >>>>>>>>>>> 3) wrong firmware >>>>>>>>>>> * it very unlikely that even wrong firmware fails basic I2C... >>>>>>>>>> I know there's a few versions right? the 01 02 etc? But that is >>>>>>>>>> mostly >>>>>>>>>> in relation with the af9035 mostly right? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> using the following modules. >>>>>>>>>>>> fc2580 4189 -1 >>>>>>>>>>>> af9033 10266 0 >>>>>>>>>>>> dvb_usb_af9035 8924 0 >>>>>>>>>>>> dvb_usbv2 11388 1 dvb_usb_af9035 >>>>>>>>>>>> dvb_core 71756 1 dvb_usbv2 >>>>>>>>>>>> rc_core 10583 2 dvb_usbv2,dvb_usb_af9035 >>>>>>>>>>>> >>>>>>>>>>>> I'm supprised though that dvb-pll isn't there. Wasn't that a >>>>>>>>>>>> requirement? [1] >>>>>>>>>>> >>>>>>>>>>> No. dvb-pll is used for old simple 4-byte PLLs. FCI FC2580 is >>>>>>>>>>> modern >>>>>>>>>>> silicon tuner. There is PLL used inside FC2580 for frequency >>>>>>>>>>> synthesizer >>>>>>>>>>> but no dvb-pll needed as all calculations are done inside that >>>>>>>>>>> driver. >>>>>>>>>>> Silicon tuners are so much more complicated to program than old >>>>>>>>>>> 4-byte >>>>>>>>>>> PLLs, thus own driver is needed for each silicon tuner chip. >>>>>>>>>> Ah, well then the wiki needs a small update ;) >>>>>>>>>>> >>>>>>>>>>>> For the tuner 'script' firmware/init bit, I used the 'official' >>>>>>>>>>>> driver >>>>>>>>>>>> [2]. >>>>>>>>>>>> >>>>>>>>>>>> Also the i2c-addr and clock comes from these files. >>>>>>>>>>> >>>>>>>>>>> Aaah, now I see. At least I2C address is wrong. You use 0xac but >>>>>>>>>>> should >>>>>>>>>>> be 0x56. There is wrong "8-bit" address used. 0xac >> 1 == 0x56. >>>>>>>>>> That I don't understand (as I wrote above) 0xac 'should' be the >>>>>>>>>> correct, >>>>>>>>>> but appearantly it needs to be shifted. Why? >>>>>>>>> >>>>>>>>> Because it is wrong in vendor driver you look. I2C addresses are 7 >>>>>>>>> bit >>>>>>>>> long and LSB bit used for direction (read or write). Try to search >>>>>>>>> some >>>>>>>>> I2C tutorials. This kind of wrong I2C addresses are called usually >>>>>>>>> 8-bit >>>>>>>>> I2C address. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 16384000 (16.384MHz) is FC2580 internal clock what I >>>>>>>>>>> understand. It >>>>>>>>>>> should be OK. I suspect that everyone uses it for DVB-T to save >>>>>>>>>>> components / make design simple. >>>>>>>>>> I would assume so, since also that is in the original sources; >>>>>>>>>> fc2580.c >>>>>>>>>> lists it as: >>>>>>>>>> #define FREQ_XTAL 16384 //16.384MHz >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> One minor questions I have regarding the recently submitted RTL >>>>>>>>>>>> and >>>>>>>>>>>> AF9033 drivers, is one uses AF9033_TUNER_* whereas the other >>>>>>>>>>>> uses >>>>>>>>>>>> TUNER_RTL2832_*. Any reason for this? It just confused me is >>>>>>>>>>>> all. >>>>>>>>>>> >>>>>>>>>>> It is just naming issue driver, driver author decision. Usually >>>>>>>>>>> names >>>>>>>>>>> start with driver name letters (in that case RTL28XXU_). It is >>>>>>>>>>> not >>>>>>>>>>> big >>>>>>>>>>> issue for variable names unless it is too "general" to conflict >>>>>>>>>>> some >>>>>>>>>>> library. For function names driver names prefix (rtl28xxu_) >>>>>>>>>>> should be >>>>>>>>>>> used as it eases debugging (example ooops is dumped showing >>>>>>>>>>> function >>>>>>>>>>> names). >>>>>>>>>> >>>>>>>>>> Ok I will test the shifted i2c address and try that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Antti >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Oliver >>>>>>>>>>>> >>>>>>>>>>>> [1] http://linuxtv.org/wiki/index.php/DVB_via_USB#Introduction >>>>>>>>>>>> [2] >>>>>>>>>>>> http://git.schinagl.nl/AF903x_SRC.git/tree/api/FCI_FC2580_Script.h >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >> > >