| Message ID | 1347223647-645-1-git-send-email-oliver+list@schinagl.nl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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) 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] For the tuner 'script' firmware/init bit, I used the 'official' driver [2]. Also the i2c-addr and clock comes from these files. 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. 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 On 09/09/12 22:47, oliver@schinagl.nl wrote: > From: Oliver Schinagl<oliver@schinagl.nl> > > Initial support for the Asus MyCinema U3100Mini Plus. This currently > does not work however. It uses teh af9033/5 demodulater with an > FCI FC2580 tuner. > > Signed-off-by: Oliver Schinagl<oliver@schinagl.nl> > --- > drivers/media/dvb-core/dvb-usb-ids.h | 1 + > drivers/media/dvb-frontends/af9033.c | 4 ++++ > drivers/media/dvb-frontends/af9033.h | 1 + > drivers/media/dvb-frontends/af9033_priv.h | 36 +++++++++++++++++++++++++++++++ > drivers/media/usb/dvb-usb-v2/Kconfig | 1 + > drivers/media/usb/dvb-usb-v2/af9035.c | 12 +++++++++++ > drivers/media/usb/dvb-usb-v2/af9035.h | 1 + > 7 files changed, 56 insertions(+) > > diff --git a/drivers/media/dvb-core/dvb-usb-ids.h b/drivers/media/dvb-core/dvb-usb-ids.h > index d572307..58e0220 100644 > --- a/drivers/media/dvb-core/dvb-usb-ids.h > +++ b/drivers/media/dvb-core/dvb-usb-ids.h > @@ -329,6 +329,7 @@ > #define USB_PID_ASUS_U3000 0x171f > #define USB_PID_ASUS_U3000H 0x1736 > #define USB_PID_ASUS_U3100 0x173f > +#define USB_PID_ASUS_U3100MINI_PLUS 0x1779 > #define USB_PID_YUAN_EC372S 0x1edc > #define USB_PID_YUAN_STK7700PH 0x1f08 > #define USB_PID_YUAN_PD378S 0x2edc > diff --git a/drivers/media/dvb-frontends/af9033.c b/drivers/media/dvb-frontends/af9033.c > index cd8c883..1568c6a 100644 > --- a/drivers/media/dvb-frontends/af9033.c > +++ b/drivers/media/dvb-frontends/af9033.c > @@ -318,6 +318,10 @@ static int af9033_init(struct dvb_frontend *fe) > len = ARRAY_SIZE(tuner_init_tda18218); > init = tuner_init_tda18218; > break; > + case AF9033_TUNER_FC2580: > + len = ARRAY_SIZE(tuner_init_fc2580); > + init = tuner_init_fc2580; > + break; > default: > pr_debug("%s: unsupported tuner ID=%d\n", __func__, > state->cfg.tuner); > diff --git a/drivers/media/dvb-frontends/af9033.h b/drivers/media/dvb-frontends/af9033.h > index 9e302c3..3dd6edd 100644 > --- a/drivers/media/dvb-frontends/af9033.h > +++ b/drivers/media/dvb-frontends/af9033.h > @@ -42,6 +42,7 @@ struct af9033_config { > #define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */ > #define AF9033_TUNER_MXL5007T 0xa0 /* MaxLinear MxL5007T */ > #define AF9033_TUNER_TDA18218 0xa1 /* NXP TDA 18218HN */ > +#define AF9033_TUNER_FC2580 0x32 /* FCI FC2580 */ > u8 tuner; > > /* > diff --git a/drivers/media/dvb-frontends/af9033_priv.h b/drivers/media/dvb-frontends/af9033_priv.h > index 0b783b9..4126255 100644 > --- a/drivers/media/dvb-frontends/af9033_priv.h > +++ b/drivers/media/dvb-frontends/af9033_priv.h > @@ -466,5 +466,41 @@ static const struct reg_val tuner_init_tda18218[] = { > {0x80f1e6, 0x00}, > }; > > +static const struct reg_val tuner_init_fc2580[] = { > + { 0x800046, AF9033_TUNER_FC2580 }, > + { 0x800057, 0x01 }, > + { 0x800058, 0x00 }, > + { 0x80005f, 0x00 }, > + { 0x800060, 0x00 }, > + { 0x800071, 0x05 }, > + { 0x800072, 0x02 }, > + { 0x800074, 0x01 }, > + { 0x800079, 0x01 }, > + { 0x800093, 0x00 }, > + { 0x800094, 0x00 }, > + { 0x800095, 0x00 }, > + { 0x800096, 0x05 }, > + { 0x8000b3, 0x01 }, > + { 0x8000c3, 0x01 }, > + { 0x8000c4, 0x00 }, > + { 0x80f007, 0x00 }, > + { 0x80f00c, 0x19 }, > + { 0x80f00d, 0x1A }, > + { 0x80f00e, 0x00 }, > + { 0x80f00f, 0x02 }, > + { 0x80f010, 0x00 }, > + { 0x80f011, 0x02 }, > + { 0x80f012, 0x00 }, > + { 0x80f013, 0x02 }, > + { 0x80f014, 0x00 }, > + { 0x80f015, 0x02 }, > + { 0x80f01f, 0x96 }, > + { 0x80f020, 0x00 }, > + { 0x80f029, 0x96 }, > + { 0x80f02a, 0x00 }, > + { 0x80f077, 0x01 }, > + { 0x80f1e6, 0x01 }, > +}; > + > #endif /* AF9033_PRIV_H */ > > diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig b/drivers/media/usb/dvb-usb-v2/Kconfig > index e09930c..834bfec 100644 > --- a/drivers/media/usb/dvb-usb-v2/Kconfig > +++ b/drivers/media/usb/dvb-usb-v2/Kconfig > @@ -40,6 +40,7 @@ config DVB_USB_AF9035 > select MEDIA_TUNER_FC0011 if MEDIA_SUBDRV_AUTOSELECT > select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT > select MEDIA_TUNER_TDA18218 if MEDIA_SUBDRV_AUTOSELECT > + select MEDIA_TUNER_FC2580 if MEDIA_SUBDRV_AUTOSELECT > help > Say Y here to support the Afatech AF9035 based DVB USB receiver. > > diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c > index 9e5bbf9..952fbdb 100644 > --- a/drivers/media/usb/dvb-usb-v2/af9035.c > +++ b/drivers/media/usb/dvb-usb-v2/af9035.c > @@ -546,6 +546,7 @@ static int af9035_read_config(struct dvb_usb_device *d) > case AF9033_TUNER_FC0011: > case AF9033_TUNER_MXL5007T: > case AF9033_TUNER_TDA18218: > + case AF9033_TUNER_FC2580: > state->af9033_config[i].spec_inv = 1; > break; > default: > @@ -798,6 +799,11 @@ static struct tda18218_config af9035_tda18218_config = { > .i2c_wr_max = 21, > }; > > +static struct fc2580_config af9035_fc2580_config = { > + .i2c_addr = 0xac, > + .clock = 16384000, > +}; > + > static int af9035_tuner_attach(struct dvb_usb_adapter *adap) > { > struct state *state = adap_to_priv(adap); > @@ -903,6 +909,10 @@ static int af9035_tuner_attach(struct dvb_usb_adapter *adap) > fe = dvb_attach(tda18218_attach, adap->fe[0], > &d->i2c_adap,&af9035_tda18218_config); > break; > + case AF9033_TUNER_FC2580: > + fe = dvb_attach(fc2580_attach, adap->fe[0], > + &d->i2c_adap,&af9035_fc2580_config); > + break; > default: > fe = NULL; > } > @@ -1126,6 +1136,8 @@ static const struct usb_device_id af9035_id_table[] = { > &af9035_props, "AVerMedia HD Volar (A867)", NULL) }, > { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_TWINSTAR, > &af9035_props, "AVerMedia Twinstar (A825)", NULL) }, > + { DVB_USB_DEVICE(USB_VID_ASUS, USB_PID_ASUS_U3100MINI_PLUS, > + &af9035_props, "Asus U3100Mini Plus", NULL) }, > { } > }; > MODULE_DEVICE_TABLE(usb, af9035_id_table); > diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h b/drivers/media/usb/dvb-usb-v2/af9035.h > index bb7bc7a..4864d9a 100644 > --- a/drivers/media/usb/dvb-usb-v2/af9035.h > +++ b/drivers/media/usb/dvb-usb-v2/af9035.h > @@ -28,6 +28,7 @@ > #include "fc0011.h" > #include "mxl5007t.h" > #include "tda18218.h" > +#include "fc2580.h" > > struct reg_val { > u32 reg; -- 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
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. There is likely 3 possibilities: 1) wrong I2C address 2) wrong GPIOs * tuner is not powered on or it is on standby 3) wrong firmware * it very unlikely that even wrong firmware fails basic I2C... > 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. > 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. 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. > 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). 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 > > > On 09/09/12 22:47, oliver@schinagl.nl wrote: >> From: Oliver Schinagl<oliver@schinagl.nl> >> >> Initial support for the Asus MyCinema U3100Mini Plus. This currently >> does not work however. It uses teh af9033/5 demodulater with an >> FCI FC2580 tuner. >> >> Signed-off-by: Oliver Schinagl<oliver@schinagl.nl> >> --- >> drivers/media/dvb-core/dvb-usb-ids.h | 1 + >> drivers/media/dvb-frontends/af9033.c | 4 ++++ >> drivers/media/dvb-frontends/af9033.h | 1 + >> drivers/media/dvb-frontends/af9033_priv.h | 36 >> +++++++++++++++++++++++++++++++ >> drivers/media/usb/dvb-usb-v2/Kconfig | 1 + >> drivers/media/usb/dvb-usb-v2/af9035.c | 12 +++++++++++ >> drivers/media/usb/dvb-usb-v2/af9035.h | 1 + >> 7 files changed, 56 insertions(+) >> >> diff --git a/drivers/media/dvb-core/dvb-usb-ids.h >> b/drivers/media/dvb-core/dvb-usb-ids.h >> index d572307..58e0220 100644 >> --- a/drivers/media/dvb-core/dvb-usb-ids.h >> +++ b/drivers/media/dvb-core/dvb-usb-ids.h >> @@ -329,6 +329,7 @@ >> #define USB_PID_ASUS_U3000 0x171f >> #define USB_PID_ASUS_U3000H 0x1736 >> #define USB_PID_ASUS_U3100 0x173f >> +#define USB_PID_ASUS_U3100MINI_PLUS 0x1779 >> #define USB_PID_YUAN_EC372S 0x1edc >> #define USB_PID_YUAN_STK7700PH 0x1f08 >> #define USB_PID_YUAN_PD378S 0x2edc >> diff --git a/drivers/media/dvb-frontends/af9033.c >> b/drivers/media/dvb-frontends/af9033.c >> index cd8c883..1568c6a 100644 >> --- a/drivers/media/dvb-frontends/af9033.c >> +++ b/drivers/media/dvb-frontends/af9033.c >> @@ -318,6 +318,10 @@ static int af9033_init(struct dvb_frontend *fe) >> len = ARRAY_SIZE(tuner_init_tda18218); >> init = tuner_init_tda18218; >> break; >> + case AF9033_TUNER_FC2580: >> + len = ARRAY_SIZE(tuner_init_fc2580); >> + init = tuner_init_fc2580; >> + break; >> default: >> pr_debug("%s: unsupported tuner ID=%d\n", __func__, >> state->cfg.tuner); >> diff --git a/drivers/media/dvb-frontends/af9033.h >> b/drivers/media/dvb-frontends/af9033.h >> index 9e302c3..3dd6edd 100644 >> --- a/drivers/media/dvb-frontends/af9033.h >> +++ b/drivers/media/dvb-frontends/af9033.h >> @@ -42,6 +42,7 @@ struct af9033_config { >> #define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */ >> #define AF9033_TUNER_MXL5007T 0xa0 /* MaxLinear MxL5007T */ >> #define AF9033_TUNER_TDA18218 0xa1 /* NXP TDA 18218HN */ >> +#define AF9033_TUNER_FC2580 0x32 /* FCI FC2580 */ >> u8 tuner; >> >> /* >> diff --git a/drivers/media/dvb-frontends/af9033_priv.h >> b/drivers/media/dvb-frontends/af9033_priv.h >> index 0b783b9..4126255 100644 >> --- a/drivers/media/dvb-frontends/af9033_priv.h >> +++ b/drivers/media/dvb-frontends/af9033_priv.h >> @@ -466,5 +466,41 @@ static const struct reg_val tuner_init_tda18218[] >> = { >> {0x80f1e6, 0x00}, >> }; >> >> +static const struct reg_val tuner_init_fc2580[] = { >> + { 0x800046, AF9033_TUNER_FC2580 }, >> + { 0x800057, 0x01 }, >> + { 0x800058, 0x00 }, >> + { 0x80005f, 0x00 }, >> + { 0x800060, 0x00 }, >> + { 0x800071, 0x05 }, >> + { 0x800072, 0x02 }, >> + { 0x800074, 0x01 }, >> + { 0x800079, 0x01 }, >> + { 0x800093, 0x00 }, >> + { 0x800094, 0x00 }, >> + { 0x800095, 0x00 }, >> + { 0x800096, 0x05 }, >> + { 0x8000b3, 0x01 }, >> + { 0x8000c3, 0x01 }, >> + { 0x8000c4, 0x00 }, >> + { 0x80f007, 0x00 }, >> + { 0x80f00c, 0x19 }, >> + { 0x80f00d, 0x1A }, >> + { 0x80f00e, 0x00 }, >> + { 0x80f00f, 0x02 }, >> + { 0x80f010, 0x00 }, >> + { 0x80f011, 0x02 }, >> + { 0x80f012, 0x00 }, >> + { 0x80f013, 0x02 }, >> + { 0x80f014, 0x00 }, >> + { 0x80f015, 0x02 }, >> + { 0x80f01f, 0x96 }, >> + { 0x80f020, 0x00 }, >> + { 0x80f029, 0x96 }, >> + { 0x80f02a, 0x00 }, >> + { 0x80f077, 0x01 }, >> + { 0x80f1e6, 0x01 }, >> +}; >> + >> #endif /* AF9033_PRIV_H */ >> >> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig >> b/drivers/media/usb/dvb-usb-v2/Kconfig >> index e09930c..834bfec 100644 >> --- a/drivers/media/usb/dvb-usb-v2/Kconfig >> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig >> @@ -40,6 +40,7 @@ config DVB_USB_AF9035 >> select MEDIA_TUNER_FC0011 if MEDIA_SUBDRV_AUTOSELECT >> select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT >> select MEDIA_TUNER_TDA18218 if MEDIA_SUBDRV_AUTOSELECT >> + select MEDIA_TUNER_FC2580 if MEDIA_SUBDRV_AUTOSELECT >> help >> Say Y here to support the Afatech AF9035 based DVB USB receiver. >> >> diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c >> b/drivers/media/usb/dvb-usb-v2/af9035.c >> index 9e5bbf9..952fbdb 100644 >> --- a/drivers/media/usb/dvb-usb-v2/af9035.c >> +++ b/drivers/media/usb/dvb-usb-v2/af9035.c >> @@ -546,6 +546,7 @@ static int af9035_read_config(struct >> dvb_usb_device *d) >> case AF9033_TUNER_FC0011: >> case AF9033_TUNER_MXL5007T: >> case AF9033_TUNER_TDA18218: >> + case AF9033_TUNER_FC2580: >> state->af9033_config[i].spec_inv = 1; >> break; >> default: >> @@ -798,6 +799,11 @@ static struct tda18218_config >> af9035_tda18218_config = { >> .i2c_wr_max = 21, >> }; >> >> +static struct fc2580_config af9035_fc2580_config = { >> + .i2c_addr = 0xac, >> + .clock = 16384000, >> +}; >> + >> static int af9035_tuner_attach(struct dvb_usb_adapter *adap) >> { >> struct state *state = adap_to_priv(adap); >> @@ -903,6 +909,10 @@ static int af9035_tuner_attach(struct >> dvb_usb_adapter *adap) >> fe = dvb_attach(tda18218_attach, adap->fe[0], >> &d->i2c_adap,&af9035_tda18218_config); >> break; >> + case AF9033_TUNER_FC2580: >> + fe = dvb_attach(fc2580_attach, adap->fe[0], >> + &d->i2c_adap,&af9035_fc2580_config); >> + break; >> default: >> fe = NULL; >> } >> @@ -1126,6 +1136,8 @@ static const struct usb_device_id >> af9035_id_table[] = { >> &af9035_props, "AVerMedia HD Volar (A867)", NULL) }, >> { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_TWINSTAR, >> &af9035_props, "AVerMedia Twinstar (A825)", NULL) }, >> + { DVB_USB_DEVICE(USB_VID_ASUS, USB_PID_ASUS_U3100MINI_PLUS, >> + &af9035_props, "Asus U3100Mini Plus", NULL) }, >> { } >> }; >> MODULE_DEVICE_TABLE(usb, af9035_id_table); >> diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h >> b/drivers/media/usb/dvb-usb-v2/af9035.h >> index bb7bc7a..4864d9a 100644 >> --- a/drivers/media/usb/dvb-usb-v2/af9035.h >> +++ b/drivers/media/usb/dvb-usb-v2/af9035.h >> @@ -28,6 +28,7 @@ >> #include "fc0011.h" >> #include "mxl5007t.h" >> #include "tda18218.h" >> +#include "fc2580.h" >> >> struct reg_val { >> u32 reg; >
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? > > > 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 <snipped patch> -- 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
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 > <snipped patch>
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?
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.
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
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
>> <snipped patch>
>
>
--
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
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. > 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/ > 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 > > > 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 >>> <snipped patch> >> >> >
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? > >> 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 >>>> <snipped patch> >>> >>> >> > >
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? 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 >>>>> <snipped patch> >>>> >>>> >>> >> >> > -- 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
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? > > > 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 >>>>>> <snipped patch> >>>>> >>>>> >>>> >>> >>> >> > > -- > 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 -- 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
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. 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. 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? >>> >>> >>> 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 >>>>>>>>>> >>>>>>>> <snipped patch> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> -- >>> 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 >> > > -- 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
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? >> >> >> 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 >>>>>>> <snipped patch> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> -- >> 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 >
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? >>>> >>>> >>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> <snipped patch> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> 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 >>> >> >> >
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) >>>>> { >>>>> <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? >>>>> >>>>> >>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> <snipped patch> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >> > > -- 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
On 09/17/2012 01:10 AM, Oliver Schinagl wrote: > 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? Those GPIOs are set in file af9035.c, functiuons: af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For TDA18218 tuner there is no any GPIOs set, which could be wrong and it just works with good luck OR it is wired/connected directly so that GPIOs are not used at all. > 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" It is the tuner ID value got from eeprom. You should take that number and add it to af9033.h file: #define AF9033_TUNER_FC2580 0xXXXX <= insert number here > None of the values where set however. Did I miss-configure anything for > it to cause to 'forget' substituting? What you mean? Could you enable debugs, plug stick in and copy paste what debugs says? > >> >>> 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? You have to add fc2580 init table to file af9033_priv.h. It configures all the settings needed for AF9033 demod in order to operate with FC2580 tuner. There is some values like "tuner ID" which is passed for AF9033 firmware, dunno what kind of tweaks it done. Maybe calculates some values like signal strengths and AGC values. It could work without, but at least performance is reduced. regards Antti
On 17-09-12 01:36, Antti Palosaari wrote: > On 09/17/2012 01:10 AM, Oliver Schinagl wrote: >> 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? > > Those GPIOs are set in file af9035.c, functiuons: > af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For TDA18218 > tuner there is no any GPIOs set, which could be wrong and it just > works with good luck OR it is wired/connected directly so that GPIOs > are not used at all. Ahah! Then I know what to look for. Since af9035 also has fc0011 support, there should be some similarities I can find. > >> 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" > > It is the tuner ID value got from eeprom. You should take that number > and add it to af9033.h file: > #define AF9033_TUNER_FC2580 0xXXXX <= insert number here Yes, but I think %s, %d and %02x\012 should actually list values? (\012 I belive is \newline) > >> None of the values where set however. Did I miss-configure anything for >> it to cause to 'forget' substituting? > > What you mean? Could you enable debugs, plug stick in and copy paste > what debugs says? I have dynamic debugging enabled and have gotten the above snipped from the proc/sysfs interface. Also dmesg from replugging I've attached a few messages back. [ 188.051502] af9033: firmware version: LINK=12.13.15.0 OFDM=6.20.15.0 [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech AF9033 (DVB-T))... [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 [ 188.054471] i2c i2c-1: fc2580_release: [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while loading driver (-19) is the dmesg output from then, which doesn't list the values from the debugging bit either. I suppose I need more debugging options enabled to have those flag characters actually filled in? > >> >>> >>>> 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? > > You have to add fc2580 init table to file af9033_priv.h. It configures > all the settings needed for AF9033 demod in order to operate with > FC2580 tuner. There is some values like "tuner ID" which is passed for > AF9033 firmware, dunno what kind of tweaks it done. Maybe calculates > some values like signal strengths and AGC values. It could work > without, but at least performance is reduced. I did add it. I found the init tables in the vendor driver, compared them to the existing init tables, found that the others where identical, but offset by 0x8000. I thus copied the table for the fc2580 and added the address offset. You can glance over it in the driver patch I submitted last week, should be there :) But since it modified the AF9033, I understand why your rtl driver didn't have the init table for the fc2580. > > regards > Antti Thanks, Oliver -- 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
On 17-09-12 10:25, Oliver Schinagl wrote: > On 17-09-12 01:36, Antti Palosaari wrote: >> On 09/17/2012 01:10 AM, Oliver Schinagl wrote: >>> 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? >> >> Those GPIOs are set in file af9035.c, functiuons: >> af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For >> TDA18218 tuner there is no any GPIOs set, which could be wrong and it >> just works with good luck OR it is wired/connected directly so that >> GPIOs are not used at all. > Ahah! Then I know what to look for. Since af9035 also has fc0011 > support, there should be some similarities I can find. Which I did. I found that the af9033 sets the "gpiot2" o, en and on values high to enable the tuner. Luckly, the fc2580 is routed to the exact same gpio and thus the same tuner enable/disable routine can be used as the FC0011. Appearantly the FC0011 tuner also has a led that needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I found the tuner enable and should be able to incorporate that without issue. The other callback the fc2580 has, is a 'reset'. The fc2580 appears to be lacking such feature, or is not used in the vendor driver. >> >>> 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" >> >> It is the tuner ID value got from eeprom. You should take that number >> and add it to af9033.h file: >> #define AF9033_TUNER_FC2580 0xXXXX <= insert number here > Yes, but I think %s, %d and %02x\012 should actually list values? > (\012 I belive is \newline) I need to learn dynamic_debug; and I think I may have set it up wrong last time (af9035 and fc2580, but not af9033). I found some good documentation and will try this tonight. >> >>> None of the values where set however. Did I miss-configure anything for >>> it to cause to 'forget' substituting? >> >> What you mean? Could you enable debugs, plug stick in and copy paste >> what debugs says? > I have dynamic debugging enabled and have gotten the above snipped > from the proc/sysfs interface. Also dmesg from replugging I've > attached a few messages back. > > [ 188.051502] af9033: firmware version: LINK=12.13.15.0 OFDM=6.20.15.0 > [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech > AF9033 (DVB-T))... > [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a > [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 > [ 188.054471] i2c i2c-1: fc2580_release: > [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while > loading driver (-19) > > is the dmesg output from then, which doesn't list the values from the > debugging bit either. I suppose I need more debugging options enabled > to have those flag characters actually filled in? > > >> >>> >>>> >>>>> 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? >> >> You have to add fc2580 init table to file af9033_priv.h. It >> configures all the settings needed for AF9033 demod in order to >> operate with FC2580 tuner. There is some values like "tuner ID" which >> is passed for AF9033 firmware, dunno what kind of tweaks it done. >> Maybe calculates some values like signal strengths and AGC values. It >> could work without, but at least performance is reduced. > I did add it. I found the init tables in the vendor driver, compared > them to the existing init tables, found that the others where > identical, but offset by 0x8000. I thus copied the table for the > fc2580 and added the address offset. > You can glance over it in the driver patch I submitted last week, > should be there :) > > But since it modified the AF9033, I understand why your rtl driver > didn't have the init table for the fc2580. >> >> regards >> Antti > > Thanks, > Oliver > -- > 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 -- 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
On 09/17/2012 04:02 PM, Oliver Schinagl wrote: > On 17-09-12 10:25, Oliver Schinagl wrote: >> On 17-09-12 01:36, Antti Palosaari wrote: >>> On 09/17/2012 01:10 AM, Oliver Schinagl wrote: >>>> 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? >>> >>> Those GPIOs are set in file af9035.c, functiuons: >>> af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For >>> TDA18218 tuner there is no any GPIOs set, which could be wrong and it >>> just works with good luck OR it is wired/connected directly so that >>> GPIOs are not used at all. >> Ahah! Then I know what to look for. Since af9035 also has fc0011 >> support, there should be some similarities I can find. > Which I did. I found that the af9033 sets the "gpiot2" o, en and on > values high to enable the tuner. Luckly, the fc2580 is routed to the > exact same gpio and thus the same tuner enable/disable routine can be > used as the FC0011. Appearantly the FC0011 tuner also has a led that > needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I > found the tuner enable and should be able to incorporate that without > issue. > > The other callback the fc2580 has, is a 'reset'. The fc2580 appears to > be lacking such feature, or is not used in the vendor driver. >>> >>>> 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" >>> >>> It is the tuner ID value got from eeprom. You should take that number >>> and add it to af9033.h file: >>> #define AF9033_TUNER_FC2580 0xXXXX <= insert number here >> Yes, but I think %s, %d and %02x\012 should actually list values? >> (\012 I belive is \newline) > I need to learn dynamic_debug; and I think I may have set it up wrong > last time (af9035 and fc2580, but not af9033). I found some good > documentation and will try this tonight. >>> >>>> None of the values where set however. Did I miss-configure anything for >>>> it to cause to 'forget' substituting? >>> >>> What you mean? Could you enable debugs, plug stick in and copy paste >>> what debugs says? >> I have dynamic debugging enabled and have gotten the above snipped >> from the proc/sysfs interface. Also dmesg from replugging I've >> attached a few messages back. >> >> [ 188.051502] af9033: firmware version: LINK=12.13.15.0 OFDM=6.20.15.0 >> [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech >> AF9033 (DVB-T))... >> [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a >> [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 >> [ 188.054471] i2c i2c-1: fc2580_release: >> [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while >> loading driver (-19) >> >> is the dmesg output from then, which doesn't list the values from the >> debugging bit either. I suppose I need more debugging options enabled >> to have those flag characters actually filled in? It should print af9035 debugs too. usb 2-2: af9035_read_config: [0]tuner=27 modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' > /sys/kernel/debug/dynamic_debug/control modprobe dvb_usb_v2; echo -n 'module dvb_usb_v2 +p' > /sys/kernel/debug/dynamic_debug/control 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 >>>>> >>>>>> 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? >>> >>> You have to add fc2580 init table to file af9033_priv.h. It >>> configures all the settings needed for AF9033 demod in order to >>> operate with FC2580 tuner. There is some values like "tuner ID" which >>> is passed for AF9033 firmware, dunno what kind of tweaks it done. >>> Maybe calculates some values like signal strengths and AGC values. It >>> could work without, but at least performance is reduced. >> I did add it. I found the init tables in the vendor driver, compared >> them to the existing init tables, found that the others where >> identical, but offset by 0x8000. I thus copied the table for the >> fc2580 and added the address offset. >> You can glance over it in the driver patch I submitted last week, >> should be there :) >> >> But since it modified the AF9033, I understand why your rtl driver >> didn't have the init table for the fc2580. If you look comment from the rtl28xxu.c around line 635 you will see it. /* FIXME: do not abuse fc0012 settings */ Antti
On 17-09-12 15:16, Antti Palosaari wrote: > On 09/17/2012 04:02 PM, Oliver Schinagl wrote: >> On 17-09-12 10:25, Oliver Schinagl wrote: >>> On 17-09-12 01:36, Antti Palosaari wrote: >>>> On 09/17/2012 01:10 AM, Oliver Schinagl wrote: >>>>> 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? >>>> >>>> Those GPIOs are set in file af9035.c, functiuons: >>>> af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For >>>> TDA18218 tuner there is no any GPIOs set, which could be wrong and it >>>> just works with good luck OR it is wired/connected directly so that >>>> GPIOs are not used at all. >>> Ahah! Then I know what to look for. Since af9035 also has fc0011 >>> support, there should be some similarities I can find. >> Which I did. I found that the af9033 sets the "gpiot2" o, en and on >> values high to enable the tuner. Luckly, the fc2580 is routed to the >> exact same gpio and thus the same tuner enable/disable routine can be >> used as the FC0011. Appearantly the FC0011 tuner also has a led that >> needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I >> found the tuner enable and should be able to incorporate that without >> issue. >> >> The other callback the fc2580 has, is a 'reset'. The fc2580 appears to >> be lacking such feature, or is not used in the vendor driver. >>>> >>>>> 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" >>>> >>>> It is the tuner ID value got from eeprom. You should take that number >>>> and add it to af9033.h file: >>>> #define AF9033_TUNER_FC2580 0xXXXX <= insert number here >>> Yes, but I think %s, %d and %02x\012 should actually list values? >>> (\012 I belive is \newline) >> I need to learn dynamic_debug; and I think I may have set it up wrong >> last time (af9035 and fc2580, but not af9033). I found some good >> documentation and will try this tonight. >>>> >>>>> None of the values where set however. Did I miss-configure >>>>> anything for >>>>> it to cause to 'forget' substituting? >>>> >>>> What you mean? Could you enable debugs, plug stick in and copy paste >>>> what debugs says? >>> I have dynamic debugging enabled and have gotten the above snipped >>> from the proc/sysfs interface. Also dmesg from replugging I've >>> attached a few messages back. >>> >>> [ 188.051502] af9033: firmware version: LINK=12.13.15.0 OFDM=6.20.15.0 >>> [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech >>> AF9033 (DVB-T))... >>> [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a >>> [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 >>> [ 188.054471] i2c i2c-1: fc2580_release: >>> [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while >>> loading driver (-19) >>> >>> is the dmesg output from then, which doesn't list the values from the >>> debugging bit either. I suppose I need more debugging options enabled >>> to have those flag characters actually filled in? > > It should print af9035 debugs too. > > usb 2-2: af9035_read_config: [0]tuner=27 > > modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' > > /sys/kernel/debug/dynamic_debug/control > > modprobe dvb_usb_v2; echo -n 'module dvb_usb_v2 +p' > > /sys/kernel/debug/dynamic_debug/control > > 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. The vendor source also slightly more accurately describes fc2580_init_reg_vals. When writing to 0x45 and 0x4c, it can have different meanings, it controls the AGC. While the vendor driver always uses the same bytes the init table uses, there always exists these differences and its documentation. Is it desired to document this, and if so where? A comment in the source? A wikipage somewhere? Or does it simply not matter? See http://git.schinagl.nl/AF903x_SRC.git/tree/api/fc2580.c#n135 for what I mean exactly. I guess which address goes with which GPIO is far less interesting, as the gpio name could in theory be different from the actual pin due to pin multiplexing, right? > >>>>>> >>>>>>> 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? >>>> >>>> You have to add fc2580 init table to file af9033_priv.h. It >>>> configures all the settings needed for AF9033 demod in order to >>>> operate with FC2580 tuner. There is some values like "tuner ID" which >>>> is passed for AF9033 firmware, dunno what kind of tweaks it done. >>>> Maybe calculates some values like signal strengths and AGC values. It >>>> could work without, but at least performance is reduced. >>> I did add it. I found the init tables in the vendor driver, compared >>> them to the existing init tables, found that the others where >>> identical, but offset by 0x8000. I thus copied the table for the >>> fc2580 and added the address offset. >>> You can glance over it in the driver patch I submitted last week, >>> should be there :) >>> >>> But since it modified the AF9033, I understand why your rtl driver >>> didn't have the init table for the fc2580. > > If you look comment from the rtl28xxu.c around line 635 you will see it. > /* FIXME: do not abuse fc0012 settings */ I take it, if my patch works, it can be also useful to the rtl28xxu driver? > > 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
On 09/17/2012 04:26 PM, Oliver Schinagl wrote: > On 17-09-12 15:16, Antti Palosaari wrote: >> On 09/17/2012 04:02 PM, Oliver Schinagl wrote: >>> On 17-09-12 10:25, Oliver Schinagl wrote: >>>> On 17-09-12 01:36, Antti Palosaari wrote: >>>>> On 09/17/2012 01:10 AM, Oliver Schinagl wrote: >>>>>> 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? >>>>> >>>>> Those GPIOs are set in file af9035.c, functiuons: >>>>> af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For >>>>> TDA18218 tuner there is no any GPIOs set, which could be wrong and it >>>>> just works with good luck OR it is wired/connected directly so that >>>>> GPIOs are not used at all. >>>> Ahah! Then I know what to look for. Since af9035 also has fc0011 >>>> support, there should be some similarities I can find. >>> Which I did. I found that the af9033 sets the "gpiot2" o, en and on >>> values high to enable the tuner. Luckly, the fc2580 is routed to the >>> exact same gpio and thus the same tuner enable/disable routine can be >>> used as the FC0011. Appearantly the FC0011 tuner also has a led that >>> needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I >>> found the tuner enable and should be able to incorporate that without >>> issue. >>> >>> The other callback the fc2580 has, is a 'reset'. The fc2580 appears to >>> be lacking such feature, or is not used in the vendor driver. >>>>> >>>>>> 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" >>>>> >>>>> It is the tuner ID value got from eeprom. You should take that number >>>>> and add it to af9033.h file: >>>>> #define AF9033_TUNER_FC2580 0xXXXX <= insert number here >>>> Yes, but I think %s, %d and %02x\012 should actually list values? >>>> (\012 I belive is \newline) >>> I need to learn dynamic_debug; and I think I may have set it up wrong >>> last time (af9035 and fc2580, but not af9033). I found some good >>> documentation and will try this tonight. >>>>> >>>>>> None of the values where set however. Did I miss-configure >>>>>> anything for >>>>>> it to cause to 'forget' substituting? >>>>> >>>>> What you mean? Could you enable debugs, plug stick in and copy paste >>>>> what debugs says? >>>> I have dynamic debugging enabled and have gotten the above snipped >>>> from the proc/sysfs interface. Also dmesg from replugging I've >>>> attached a few messages back. >>>> >>>> [ 188.051502] af9033: firmware version: LINK=12.13.15.0 OFDM=6.20.15.0 >>>> [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech >>>> AF9033 (DVB-T))... >>>> [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a >>>> [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 >>>> [ 188.054471] i2c i2c-1: fc2580_release: >>>> [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while >>>> loading driver (-19) >>>> >>>> is the dmesg output from then, which doesn't list the values from the >>>> debugging bit either. I suppose I need more debugging options enabled >>>> to have those flag characters actually filled in? >> >> It should print af9035 debugs too. >> >> usb 2-2: af9035_read_config: [0]tuner=27 >> >> modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' > >> /sys/kernel/debug/dynamic_debug/control >> >> modprobe dvb_usb_v2; echo -n 'module dvb_usb_v2 +p' > >> /sys/kernel/debug/dynamic_debug/control >> >> 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. > The vendor source also slightly more accurately describes > fc2580_init_reg_vals. When writing to 0x45 and 0x4c, it can have > different meanings, it controls the AGC. While the vendor driver always > uses the same bytes the init table uses, there always exists these > differences and its documentation. Is it desired to document this, and > if so where? A comment in the source? A wikipage somewhere? Or does it > simply not matter? See > http://git.schinagl.nl/AF903x_SRC.git/tree/api/fc2580.c#n135 for what I > mean exactly. It does not matter how vendor have implemented it and how I have implemented it if both end up same register value anyway. And even register value is different it could be still correct. Driver does not need to be similar, driver aim is just program chip and it could do totally differently. If you do... write_register(0x1a, 0x12); write_register(0x1b, 0x34); OR write_register(0x1b, 0x34); write_register(0x1a, 0x12); OR write_registers(0x1a, "\x12\x34", 2); all will generally end up similar solution, even all those are done differently. > I guess which address goes with which GPIO is far less interesting, as > the gpio name could in theory be different from the actual pin due to > pin multiplexing, right? dunno what you mean >> >>>>>>> >>>>>>>> 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? >>>>> >>>>> You have to add fc2580 init table to file af9033_priv.h. It >>>>> configures all the settings needed for AF9033 demod in order to >>>>> operate with FC2580 tuner. There is some values like "tuner ID" which >>>>> is passed for AF9033 firmware, dunno what kind of tweaks it done. >>>>> Maybe calculates some values like signal strengths and AGC values. It >>>>> could work without, but at least performance is reduced. >>>> I did add it. I found the init tables in the vendor driver, compared >>>> them to the existing init tables, found that the others where >>>> identical, but offset by 0x8000. I thus copied the table for the >>>> fc2580 and added the address offset. >>>> You can glance over it in the driver patch I submitted last week, >>>> should be there :) >>>> >>>> But since it modified the AF9033, I understand why your rtl driver >>>> didn't have the init table for the fc2580. >> >> If you look comment from the rtl28xxu.c around line 635 you will see it. >> /* FIXME: do not abuse fc0012 settings */ > I take it, if my patch works, it can be also useful to the rtl28xxu driver? If there is someday tuner version having different tuner id. Idea of checking that ID is to ensure driver is speaking with chip it know. The language is something that both chip and driver both understand. Hey these are so basic questions I hope you will try to google answers first. regards Antti
On 17-09-12 15:52, Antti Palosaari wrote: > On 09/17/2012 04:26 PM, Oliver Schinagl wrote: >> On 17-09-12 15:16, Antti Palosaari wrote: >>> On 09/17/2012 04:02 PM, Oliver Schinagl wrote: >>>> On 17-09-12 10:25, Oliver Schinagl wrote: >>>>> On 17-09-12 01:36, Antti Palosaari wrote: >>>>>> On 09/17/2012 01:10 AM, Oliver Schinagl wrote: >>>>>>> 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? >>>>>> >>>>>> Those GPIOs are set in file af9035.c, functiuons: >>>>>> af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For >>>>>> TDA18218 tuner there is no any GPIOs set, which could be wrong >>>>>> and it >>>>>> just works with good luck OR it is wired/connected directly so that >>>>>> GPIOs are not used at all. >>>>> Ahah! Then I know what to look for. Since af9035 also has fc0011 >>>>> support, there should be some similarities I can find. >>>> Which I did. I found that the af9033 sets the "gpiot2" o, en and on >>>> values high to enable the tuner. Luckly, the fc2580 is routed to the >>>> exact same gpio and thus the same tuner enable/disable routine can be >>>> used as the FC0011. Appearantly the FC0011 tuner also has a led that >>>> needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I >>>> found the tuner enable and should be able to incorporate that without >>>> issue. >>>> >>>> The other callback the fc2580 has, is a 'reset'. The fc2580 appears to >>>> be lacking such feature, or is not used in the vendor driver. >>>>>> >>>>>>> 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" >>>>>> >>>>>> It is the tuner ID value got from eeprom. You should take that >>>>>> number >>>>>> and add it to af9033.h file: >>>>>> #define AF9033_TUNER_FC2580 0xXXXX <= insert number here >>>>> Yes, but I think %s, %d and %02x\012 should actually list values? >>>>> (\012 I belive is \newline) >>>> I need to learn dynamic_debug; and I think I may have set it up wrong >>>> last time (af9035 and fc2580, but not af9033). I found some good >>>> documentation and will try this tonight. >>>>>> >>>>>>> None of the values where set however. Did I miss-configure >>>>>>> anything for >>>>>>> it to cause to 'forget' substituting? >>>>>> >>>>>> What you mean? Could you enable debugs, plug stick in and copy paste >>>>>> what debugs says? >>>>> I have dynamic debugging enabled and have gotten the above snipped >>>>> from the proc/sysfs interface. Also dmesg from replugging I've >>>>> attached a few messages back. >>>>> >>>>> [ 188.051502] af9033: firmware version: LINK=12.13.15.0 >>>>> OFDM=6.20.15.0 >>>>> [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 >>>>> (Afatech >>>>> AF9033 (DVB-T))... >>>>> [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a >>>>> [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 >>>>> [ 188.054471] i2c i2c-1: fc2580_release: >>>>> [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while >>>>> loading driver (-19) >>>>> >>>>> is the dmesg output from then, which doesn't list the values from the >>>>> debugging bit either. I suppose I need more debugging options enabled >>>>> to have those flag characters actually filled in? >>> >>> It should print af9035 debugs too. >>> >>> usb 2-2: af9035_read_config: [0]tuner=27 >>> >>> modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' > >>> /sys/kernel/debug/dynamic_debug/control >>> >>> modprobe dvb_usb_v2; echo -n 'module dvb_usb_v2 +p' > >>> /sys/kernel/debug/dynamic_debug/control >>> >>> 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. > >> The vendor source also slightly more accurately describes >> fc2580_init_reg_vals. When writing to 0x45 and 0x4c, it can have >> different meanings, it controls the AGC. While the vendor driver always >> uses the same bytes the init table uses, there always exists these >> differences and its documentation. Is it desired to document this, and >> if so where? A comment in the source? A wikipage somewhere? Or does it >> simply not matter? See >> http://git.schinagl.nl/AF903x_SRC.git/tree/api/fc2580.c#n135 for what I >> mean exactly. > > It does not matter how vendor have implemented it and how I have > implemented it if both end up same register value anyway. And even > register value is different it could be still correct. Driver does not > need to be similar, driver aim is just program chip and it could do > totally differently. > > If you do... > write_register(0x1a, 0x12); > write_register(0x1b, 0x34); > OR > write_register(0x1b, 0x34); > write_register(0x1a, 0x12); > OR > write_registers(0x1a, "\x12\x34", 2); > > all will generally end up similar solution, even all those are done > differently. No, you misunderstand me here entirely. Although I'm sure in some cases order can be of influence, I don't think this is the case. What happens in the original driver, upon init of the fc2580 they write some bytes over the i2c bus, at one point, (at line 135) there's a simple statement: if (ifagc_mode == 1) { write(0x45, 0x10); /* internal AGC */ write(0x4c, 0x00); /* HOLD_AGC polarity */ } else if (ifagc_mode == 2) { write(0x45, 0x20); /* Voltage Control Mode */ write (0x4c, 0x02); /* HOLD_AGC polarity */ } else if(ifagc_mode == 3) { write(0x45, 0x30); /* Up/Down Control (Digital AGC) */ write(0x4c, 0x02); /* HOLD_AGC polarity */ } Thus there is 3 ways to init the fc2580, with 0x45 being 10, 20 or 30. > > >> I guess which address goes with which GPIO is far less interesting, as >> the gpio name could in theory be different from the actual pin due to >> pin multiplexing, right? > > dunno what you mean A microcontroler can change the meaning of a pin at startup. E.g. pin1 could be GPIO1 or I2C_M, I believe this is set with fuses internal to the uC. So while we assume pin1 is always I2C_M, the chip could be reconfigured to have pin2 be I2C_M. Or anything really. So documenting which address/pin is GPIO1, 2 or 3 isn't that interesting? Or is the address always linked to a certain 'meaning' and not pin number? > >>> >>>>>>>> >>>>>>>>> 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? >>>>>> >>>>>> You have to add fc2580 init table to file af9033_priv.h. It >>>>>> configures all the settings needed for AF9033 demod in order to >>>>>> operate with FC2580 tuner. There is some values like "tuner ID" >>>>>> which >>>>>> is passed for AF9033 firmware, dunno what kind of tweaks it done. >>>>>> Maybe calculates some values like signal strengths and AGC >>>>>> values. It >>>>>> could work without, but at least performance is reduced. >>>>> I did add it. I found the init tables in the vendor driver, compared >>>>> them to the existing init tables, found that the others where >>>>> identical, but offset by 0x8000. I thus copied the table for the >>>>> fc2580 and added the address offset. >>>>> You can glance over it in the driver patch I submitted last week, >>>>> should be there :) >>>>> >>>>> But since it modified the AF9033, I understand why your rtl driver >>>>> didn't have the init table for the fc2580. >>> >>> If you look comment from the rtl28xxu.c around line 635 you will see >>> it. >>> /* FIXME: do not abuse fc0012 settings */ >> I take it, if my patch works, it can be also useful to the rtl28xxu >> driver? > > If there is someday tuner version having different tuner id. Idea of > checking that ID is to ensure driver is speaking with chip it know. > The language is something that both chip and driver both understand. > Hey these are so basic questions I hope you will try to google answers > first. I think then this is such a day, where there exists another chip ID for the FC2580 :) I can read of specifics of the chips, so you can compare it to your other FC2580's and see maybe why the chip id is different. meanwhile I try to see how compatible the 5a is and how much the vendor driver relies on the chip ID. As for basic questions, Maybe somewhat basic, but certainly not extremly basic I would think. Also I wouldn't even know where to start googling with such specifics. I did not intend to offend you with my lack of knowledge, for that I sincerely appologize :( > > regards > 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
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. -- 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
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. -- 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
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... Antti
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 :) > > 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
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 -- 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
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
On 09/17/2012 06:20 PM, Oliver Schinagl wrote: > On 17-09-12 15:52, Antti Palosaari wrote: >> On 09/17/2012 04:26 PM, Oliver Schinagl wrote: >>> On 17-09-12 15:16, Antti Palosaari wrote: >>>> On 09/17/2012 04:02 PM, Oliver Schinagl wrote: >>>>> On 17-09-12 10:25, Oliver Schinagl wrote: >>>>>> On 17-09-12 01:36, Antti Palosaari wrote: >>>>>>> On 09/17/2012 01:10 AM, Oliver Schinagl wrote: >>>>>>>> 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? >>>>>>> >>>>>>> Those GPIOs are set in file af9035.c, functiuons: >>>>>>> af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For >>>>>>> TDA18218 tuner there is no any GPIOs set, which could be wrong >>>>>>> and it >>>>>>> just works with good luck OR it is wired/connected directly so that >>>>>>> GPIOs are not used at all. >>>>>> Ahah! Then I know what to look for. Since af9035 also has fc0011 >>>>>> support, there should be some similarities I can find. >>>>> Which I did. I found that the af9033 sets the "gpiot2" o, en and on >>>>> values high to enable the tuner. Luckly, the fc2580 is routed to the >>>>> exact same gpio and thus the same tuner enable/disable routine can be >>>>> used as the FC0011. Appearantly the FC0011 tuner also has a led that >>>>> needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I >>>>> found the tuner enable and should be able to incorporate that without >>>>> issue. >>>>> >>>>> The other callback the fc2580 has, is a 'reset'. The fc2580 appears to >>>>> be lacking such feature, or is not used in the vendor driver. >>>>>>> >>>>>>>> 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" >>>>>>> >>>>>>> It is the tuner ID value got from eeprom. You should take that >>>>>>> number >>>>>>> and add it to af9033.h file: >>>>>>> #define AF9033_TUNER_FC2580 0xXXXX <= insert number here >>>>>> Yes, but I think %s, %d and %02x\012 should actually list values? >>>>>> (\012 I belive is \newline) >>>>> I need to learn dynamic_debug; and I think I may have set it up wrong >>>>> last time (af9035 and fc2580, but not af9033). I found some good >>>>> documentation and will try this tonight. >>>>>>> >>>>>>>> None of the values where set however. Did I miss-configure >>>>>>>> anything for >>>>>>>> it to cause to 'forget' substituting? >>>>>>> >>>>>>> What you mean? Could you enable debugs, plug stick in and copy paste >>>>>>> what debugs says? >>>>>> I have dynamic debugging enabled and have gotten the above snipped >>>>>> from the proc/sysfs interface. Also dmesg from replugging I've >>>>>> attached a few messages back. >>>>>> >>>>>> [ 188.051502] af9033: firmware version: LINK=12.13.15.0 >>>>>> OFDM=6.20.15.0 >>>>>> [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 >>>>>> (Afatech >>>>>> AF9033 (DVB-T))... >>>>>> [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a >>>>>> [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 >>>>>> [ 188.054471] i2c i2c-1: fc2580_release: >>>>>> [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while >>>>>> loading driver (-19) >>>>>> >>>>>> is the dmesg output from then, which doesn't list the values from the >>>>>> debugging bit either. I suppose I need more debugging options enabled >>>>>> to have those flag characters actually filled in? >>>> >>>> It should print af9035 debugs too. >>>> >>>> usb 2-2: af9035_read_config: [0]tuner=27 >>>> >>>> modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' > >>>> /sys/kernel/debug/dynamic_debug/control >>>> >>>> modprobe dvb_usb_v2; echo -n 'module dvb_usb_v2 +p' > >>>> /sys/kernel/debug/dynamic_debug/control >>>> >>>> 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. >> >>> The vendor source also slightly more accurately describes >>> fc2580_init_reg_vals. When writing to 0x45 and 0x4c, it can have >>> different meanings, it controls the AGC. While the vendor driver always >>> uses the same bytes the init table uses, there always exists these >>> differences and its documentation. Is it desired to document this, and >>> if so where? A comment in the source? A wikipage somewhere? Or does it >>> simply not matter? See >>> http://git.schinagl.nl/AF903x_SRC.git/tree/api/fc2580.c#n135 for what I >>> mean exactly. >> >> It does not matter how vendor have implemented it and how I have >> implemented it if both end up same register value anyway. And even >> register value is different it could be still correct. Driver does not >> need to be similar, driver aim is just program chip and it could do >> totally differently. >> >> If you do... >> write_register(0x1a, 0x12); >> write_register(0x1b, 0x34); >> OR >> write_register(0x1b, 0x34); >> write_register(0x1a, 0x12); >> OR >> write_registers(0x1a, "\x12\x34", 2); >> >> all will generally end up similar solution, even all those are done >> differently. > No, you misunderstand me here entirely. Although I'm sure in some cases > order can be of influence, I don't think this is the case. What happens > in the original driver, upon init of the fc2580 they write some bytes > over the i2c bus, at one point, (at line 135) there's a simple statement: > if (ifagc_mode == 1) { > write(0x45, 0x10); /* internal AGC */ write(0x4c, 0x00); /* > HOLD_AGC polarity */ > } else if (ifagc_mode == 2) { > write(0x45, 0x20); /* Voltage Control Mode */ write (0x4c, 0x02); > /* HOLD_AGC polarity */ > } else if(ifagc_mode == 3) { > write(0x45, 0x30); /* Up/Down Control (Digital AGC) */ write(0x4c, > 0x02); /* HOLD_AGC polarity */ > } > > Thus there is 3 ways to init the fc2580, with 0x45 being 10, 20 or 30. It is tuner AGC configuration. I suspect could work in any case, but performance is surely reduced. Likely mode == 1 is correct, it is automatic AGC. 2 means control is coming outside, like from demod using voltage levels. And 3 means AGC which is controlled by steps, one step more / less every time some chip PIN is changed. I have never seen DVB stick that uses digital ADC control. >>> I guess which address goes with which GPIO is far less interesting, as >>> the gpio name could in theory be different from the actual pin due to >>> pin multiplexing, right? >> >> dunno what you mean > A microcontroler can change the meaning of a pin at startup. E.g. pin1 > could be GPIO1 or I2C_M, I believe this is set with fuses internal to > the uC. So while we assume pin1 is always I2C_M, the chip could be > reconfigured to have pin2 be I2C_M. Or anything really. So documenting > which address/pin is GPIO1, 2 or 3 isn't that interesting? Or is the > address always linked to a certain 'meaning' and not pin number? Yes those pins are very often multipurpose. If there is some unused pin it could be used as a GPIO. In real life those are just same pins from device to device, because of chip vendor design some reference and device vendors just follow that. >> >>>> >>>>>>>>> >>>>>>>>>> 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? >>>>>>> >>>>>>> You have to add fc2580 init table to file af9033_priv.h. It >>>>>>> configures all the settings needed for AF9033 demod in order to >>>>>>> operate with FC2580 tuner. There is some values like "tuner ID" >>>>>>> which >>>>>>> is passed for AF9033 firmware, dunno what kind of tweaks it done. >>>>>>> Maybe calculates some values like signal strengths and AGC >>>>>>> values. It >>>>>>> could work without, but at least performance is reduced. >>>>>> I did add it. I found the init tables in the vendor driver, compared >>>>>> them to the existing init tables, found that the others where >>>>>> identical, but offset by 0x8000. I thus copied the table for the >>>>>> fc2580 and added the address offset. >>>>>> You can glance over it in the driver patch I submitted last week, >>>>>> should be there :) >>>>>> >>>>>> But since it modified the AF9033, I understand why your rtl driver >>>>>> didn't have the init table for the fc2580. >>>> >>>> If you look comment from the rtl28xxu.c around line 635 you will see >>>> it. >>>> /* FIXME: do not abuse fc0012 settings */ >>> I take it, if my patch works, it can be also useful to the rtl28xxu >>> driver? >> >> If there is someday tuner version having different tuner id. Idea of >> checking that ID is to ensure driver is speaking with chip it know. >> The language is something that both chip and driver both understand. >> Hey these are so basic questions I hope you will try to google answers >> first. > I think then this is such a day, where there exists another chip ID for > the FC2580 :) I can read of specifics of the chips, so you can compare > it to your other FC2580's and see maybe why the chip id is different. > meanwhile I try to see how compatible the 5a is and how much the vendor > driver relies on the chip ID. > > As for basic questions, Maybe somewhat basic, but certainly not extremly > basic I would think. Also I wouldn't even know where to start googling > with such specifics. I did not intend to offend you with my lack of > knowledge, for that I sincerely appologize :( >> >> regards >> Antti >> > > Antti
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. > >> [1] http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T > > regards > 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
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 >> >
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h b/drivers/media/dvb-core/dvb-usb-ids.h index d572307..58e0220 100644 --- a/drivers/media/dvb-core/dvb-usb-ids.h +++ b/drivers/media/dvb-core/dvb-usb-ids.h @@ -329,6 +329,7 @@ #define USB_PID_ASUS_U3000 0x171f #define USB_PID_ASUS_U3000H 0x1736 #define USB_PID_ASUS_U3100 0x173f +#define USB_PID_ASUS_U3100MINI_PLUS 0x1779 #define USB_PID_YUAN_EC372S 0x1edc #define USB_PID_YUAN_STK7700PH 0x1f08 #define USB_PID_YUAN_PD378S 0x2edc diff --git a/drivers/media/dvb-frontends/af9033.c b/drivers/media/dvb-frontends/af9033.c index cd8c883..1568c6a 100644 --- a/drivers/media/dvb-frontends/af9033.c +++ b/drivers/media/dvb-frontends/af9033.c @@ -318,6 +318,10 @@ static int af9033_init(struct dvb_frontend *fe) len = ARRAY_SIZE(tuner_init_tda18218); init = tuner_init_tda18218; break; + case AF9033_TUNER_FC2580: + len = ARRAY_SIZE(tuner_init_fc2580); + init = tuner_init_fc2580; + break; default: pr_debug("%s: unsupported tuner ID=%d\n", __func__, state->cfg.tuner); diff --git a/drivers/media/dvb-frontends/af9033.h b/drivers/media/dvb-frontends/af9033.h index 9e302c3..3dd6edd 100644 --- a/drivers/media/dvb-frontends/af9033.h +++ b/drivers/media/dvb-frontends/af9033.h @@ -42,6 +42,7 @@ struct af9033_config { #define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */ #define AF9033_TUNER_MXL5007T 0xa0 /* MaxLinear MxL5007T */ #define AF9033_TUNER_TDA18218 0xa1 /* NXP TDA 18218HN */ +#define AF9033_TUNER_FC2580 0x32 /* FCI FC2580 */ u8 tuner; /* diff --git a/drivers/media/dvb-frontends/af9033_priv.h b/drivers/media/dvb-frontends/af9033_priv.h index 0b783b9..4126255 100644 --- a/drivers/media/dvb-frontends/af9033_priv.h +++ b/drivers/media/dvb-frontends/af9033_priv.h @@ -466,5 +466,41 @@ static const struct reg_val tuner_init_tda18218[] = { {0x80f1e6, 0x00}, }; +static const struct reg_val tuner_init_fc2580[] = { + { 0x800046, AF9033_TUNER_FC2580 }, + { 0x800057, 0x01 }, + { 0x800058, 0x00 }, + { 0x80005f, 0x00 }, + { 0x800060, 0x00 }, + { 0x800071, 0x05 }, + { 0x800072, 0x02 }, + { 0x800074, 0x01 }, + { 0x800079, 0x01 }, + { 0x800093, 0x00 }, + { 0x800094, 0x00 }, + { 0x800095, 0x00 }, + { 0x800096, 0x05 }, + { 0x8000b3, 0x01 }, + { 0x8000c3, 0x01 }, + { 0x8000c4, 0x00 }, + { 0x80f007, 0x00 }, + { 0x80f00c, 0x19 }, + { 0x80f00d, 0x1A }, + { 0x80f00e, 0x00 }, + { 0x80f00f, 0x02 }, + { 0x80f010, 0x00 }, + { 0x80f011, 0x02 }, + { 0x80f012, 0x00 }, + { 0x80f013, 0x02 }, + { 0x80f014, 0x00 }, + { 0x80f015, 0x02 }, + { 0x80f01f, 0x96 }, + { 0x80f020, 0x00 }, + { 0x80f029, 0x96 }, + { 0x80f02a, 0x00 }, + { 0x80f077, 0x01 }, + { 0x80f1e6, 0x01 }, +}; + #endif /* AF9033_PRIV_H */ diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig b/drivers/media/usb/dvb-usb-v2/Kconfig index e09930c..834bfec 100644 --- a/drivers/media/usb/dvb-usb-v2/Kconfig +++ b/drivers/media/usb/dvb-usb-v2/Kconfig @@ -40,6 +40,7 @@ config DVB_USB_AF9035 select MEDIA_TUNER_FC0011 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_TDA18218 if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_FC2580 if MEDIA_SUBDRV_AUTOSELECT help Say Y here to support the Afatech AF9035 based DVB USB receiver. diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c index 9e5bbf9..952fbdb 100644 --- a/drivers/media/usb/dvb-usb-v2/af9035.c +++ b/drivers/media/usb/dvb-usb-v2/af9035.c @@ -546,6 +546,7 @@ static int af9035_read_config(struct dvb_usb_device *d) case AF9033_TUNER_FC0011: case AF9033_TUNER_MXL5007T: case AF9033_TUNER_TDA18218: + case AF9033_TUNER_FC2580: state->af9033_config[i].spec_inv = 1; break; default: @@ -798,6 +799,11 @@ static struct tda18218_config af9035_tda18218_config = { .i2c_wr_max = 21, }; +static struct fc2580_config af9035_fc2580_config = { + .i2c_addr = 0xac, + .clock = 16384000, +}; + static int af9035_tuner_attach(struct dvb_usb_adapter *adap) { struct state *state = adap_to_priv(adap); @@ -903,6 +909,10 @@ static int af9035_tuner_attach(struct dvb_usb_adapter *adap) fe = dvb_attach(tda18218_attach, adap->fe[0], &d->i2c_adap, &af9035_tda18218_config); break; + case AF9033_TUNER_FC2580: + fe = dvb_attach(fc2580_attach, adap->fe[0], + &d->i2c_adap, &af9035_fc2580_config); + break; default: fe = NULL; } @@ -1126,6 +1136,8 @@ static const struct usb_device_id af9035_id_table[] = { &af9035_props, "AVerMedia HD Volar (A867)", NULL) }, { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_TWINSTAR, &af9035_props, "AVerMedia Twinstar (A825)", NULL) }, + { DVB_USB_DEVICE(USB_VID_ASUS, USB_PID_ASUS_U3100MINI_PLUS, + &af9035_props, "Asus U3100Mini Plus", NULL) }, { } }; MODULE_DEVICE_TABLE(usb, af9035_id_table); diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h b/drivers/media/usb/dvb-usb-v2/af9035.h index bb7bc7a..4864d9a 100644 --- a/drivers/media/usb/dvb-usb-v2/af9035.h +++ b/drivers/media/usb/dvb-usb-v2/af9035.h @@ -28,6 +28,7 @@ #include "fc0011.h" #include "mxl5007t.h" #include "tda18218.h" +#include "fc2580.h" struct reg_val { u32 reg;