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).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.
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/ regards Antti
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) { <snip> 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? OliverAnyway, 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. oliverAnttiOliverOn 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 addressWell 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 standbyHow/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.384MHzOne 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.AnttiOliver [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<snipped patch>-- 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
-- http://palosaari.fi/ -- 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
