* [PATCH] Support for Asus MyCinema U3100Mini Plus
@ 2012-09-09 20:47 oliver
2012-09-09 20:49 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: oliver @ 2012-09-09 20:47 UTC (permalink / raw)
To: linux-media; +Cc: Oliver Schinagl
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;
--
1.7.12
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-09 20:47 oliver
@ 2012-09-09 20:49 ` Oliver Schinagl
2012-09-09 21:51 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-09 20:49 UTC (permalink / raw)
To: linux-media; +Cc: Antti Palosaari
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;
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-09 20:49 ` Oliver Schinagl
@ 2012-09-09 21:51 ` Antti Palosaari
2012-09-09 22:26 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-09 21:51 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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;
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-09 21:51 ` Antti Palosaari
@ 2012-09-09 22:26 ` Oliver Schinagl
2012-09-09 22:29 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-09 22:26 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-09 22:26 ` Oliver Schinagl
@ 2012-09-09 22:29 ` Antti Palosaari
2012-09-10 9:58 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-09 22:29 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-09 22:29 ` Antti Palosaari
@ 2012-09-10 9:58 ` Oliver Schinagl
2012-09-10 11:46 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-10 9:58 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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>
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-10 9:58 ` Oliver Schinagl
@ 2012-09-10 11:46 ` Antti Palosaari
2012-09-10 14:29 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-10 11:46 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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>
>>
>>
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-10 11:46 ` Antti Palosaari
@ 2012-09-10 14:29 ` Oliver Schinagl
2012-09-10 17:28 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-10 14:29 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
[-- Attachment #1: Type: text/plain, Size: 11312 bytes --]
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>
>>>
>>>
>>
>
>
[-- Attachment #2: debug.log --]
[-- Type: text/x-log, Size: 25121 bytes --]
drivers/media/tuners/fc2580.c:448 [fc2580]fc2580_release =p "%s:\012"
drivers/media/tuners/fc2580.c:403 [fc2580]fc2580_init =p "%s: failed=%d\012"
drivers/media/tuners/fc2580.c:383 [fc2580]fc2580_init =p "%s:\012"
drivers/media/tuners/fc2580.c:429 [fc2580]fc2580_sleep =p "%s: failed=%d\012"
drivers/media/tuners/fc2580.c:412 [fc2580]fc2580_sleep =p "%s:\012"
drivers/media/tuners/fc2580.c:374 [fc2580]fc2580_set_params =p "%s: failed=%d\012"
drivers/media/tuners/fc2580.c:360 [fc2580]fc2580_set_params =p "%s: loop=%i\012"
drivers/media/tuners/fc2580.c:133 [fc2580]fc2580_set_params =p "%s: delivery_system=%d frequency=%d bandwidth_hz=%d\012"
drivers/media/tuners/fc2580.c:437 [fc2580]fc2580_get_if_frequency =p "%s:\012"
drivers/media/tuners/fc2580.c:516 [fc2580]fc2580_attach =p "%s: failed=%d\012"
drivers/media/tuners/fc2580.c:499 [fc2580]fc2580_attach =p "%s: chip_id=%02x\012"
drivers/media/dvb-frontends/af9033.c:355 [af9033]af9033_init =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:327 [af9033]af9033_init =p "%s: unsupported tuner ID=%d\012"
drivers/media/dvb-frontends/af9033.c:303 [af9033]af9033_init =p "%s: load tuner specific settings\012"
drivers/media/dvb-frontends/af9033.c:292 [af9033]af9033_init =p "%s: load ofsm settings\012"
drivers/media/dvb-frontends/af9033.c:258 [af9033]af9033_init =p "%s: adc=%d adc_cw=%06x\012"
drivers/media/dvb-frontends/af9033.c:240 [af9033]af9033_init =p "%s: clock=%d clock_cw=%08x\012"
drivers/media/dvb-frontends/af9033.c:408 [af9033]af9033_sleep =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:382 [af9033]af9033_sleep =p "%s: loop=%d\012"
drivers/media/dvb-frontends/af9033.c:185 [af9033]af9033_div =p "%s: a=%d b=%d x=%d r=%d r=%x\012"
drivers/media/dvb-frontends/af9033.c:168 [af9033]af9033_div =p "%s: a=%d b=%d x=%d\012"
drivers/media/dvb-frontends/af9033.c:546 [af9033]af9033_set_frontend =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:446 [af9033]af9033_set_frontend =p "%s: invalid bandwidth_hz\012"
drivers/media/dvb-frontends/af9033.c:432 [af9033]af9033_set_frontend =p "%s: frequency=%d bandwidth_hz=%d\012"
drivers/media/dvb-frontends/af9033.c:673 [af9033]af9033_get_frontend =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:558 [af9033]af9033_get_frontend =p "%s\012"
drivers/media/dvb-frontends/af9033.c:719 [af9033]af9033_read_status =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:795 [af9033]af9033_read_signal_strength =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:773 [af9033]af9033_read_snr =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:839 [af9033]af9033_update_ch_stat =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:885 [af9033]af9033_i2c_gate_ctrl =p "%s: failed=%d\012"
drivers/media/dvb-frontends/af9033.c:876 [af9033]af9033_i2c_gate_ctrl =p "%s: enable=%d\012"
drivers/media/dvb-frontends/af9033.c:899 [af9033]af9033_attach =p "%s:\012"
drivers/media/rc/rc-main.c:517 [rc_core]rc_g_keycode_from_table =_ "%s: %s: scancode 0x%04x keycode 0x%02x\012"
drivers/media/rc/rc-main.c:647 [rc_core]ir_do_keydown =_ "%s: %s: key down event, key 0x%04x, scancode 0x%04x\012"
drivers/media/rc/rc-main.c:536 [rc_core]ir_do_keyup =_ "%s: keyup key 0x%04x\012"
drivers/media/rc/rc-main.c:786 [rc_core]show_protocols =_ "%s: allowed - 0x%llx, enabled - 0x%llx\012"
drivers/media/rc/rc-main.c:923 [rc_core]store_protocols =_ "%s: Current protocol(s): 0x%llx\012"
drivers/media/rc/rc-main.c:908 [rc_core]store_protocols =_ "%s: Error setting protocols to 0x%llx\012"
drivers/media/rc/rc-main.c:899 [rc_core]store_protocols =_ "%s: Protocol not specified\012"
drivers/media/rc/rc-main.c:883 [rc_core]store_protocols =_ "%s: Unknown protocol: '%s'\012"
drivers/media/rc/rc-main.c:848 [rc_core]store_protocols =_ "%s: Protocol switching not supported\012"
drivers/media/rc/rc-main.c:230 [rc_core]ir_update_mapping =_ "%s: #%d: %s scan 0x%04x with key 0x%04x\012"
drivers/media/rc/rc-main.c:222 [rc_core]ir_update_mapping =_ "%s: #%d: Deleting scan 0x%04x\012"
drivers/media/rc/rc-main.c:188 [rc_core]ir_resize_table =_ "%s: Failed to kmalloc %u bytes\012"
drivers/media/rc/rc-main.c:180 [rc_core]ir_resize_table =_ "%s: Shrinking table to %u bytes\012"
drivers/media/rc/rc-main.c:174 [rc_core]ir_resize_table =_ "%s: Growing table to %u bytes\012"
drivers/media/rc/rc-main.c:134 [rc_core]ir_create_table =_ "%s: Allocated space for %u keycode entries (%u bytes)\012"
drivers/media/rc/rc-main.c:381 [rc_core]ir_setkeytable =_ "%s: Allocated space for %u keycode entries (%u bytes)\012"
drivers/media/rc/rc-main.c:1131 [rc_core]rc_register_device =_ "%s: Registered rc%ld (driver: %s, remote: %s, mode %s)\012"
drivers/media/rc/rc-main.c:1110 [rc_core]rc_register_device =_ "%s: Loading raw decoders\012"
drivers/media/rc/rc-main.c:1163 [rc_core]rc_unregister_device =_ "%s: Freed keycode table\012"
drivers/media/rc/ir-raw.c:91 [rc_core]ir_raw_event_store =_ "%s: sample: (%05dus %s)\012"
drivers/media/rc/ir-raw.c:203 [rc_core]ir_raw_event_set_idle =_ "%s: %s idle mode\012"
drivers/media/dvb-core/dvb_frontend.c:2475 [dvb_core]dvb_frontend_suspend =_ "%s: adap=%d fe=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2493 [dvb_core]dvb_frontend_resume =_ "%s: adap=%d fe=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2635 [dvb_core]dvb_validate_params_dvbt =_ "%s: code_rate_LP=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2621 [dvb_core]dvb_validate_params_dvbt =_ "%s: code_rate_LP=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2603 [dvb_core]dvb_validate_params_dvbt =_ "%s: code_rate_HP=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2589 [dvb_core]dvb_validate_params_dvbt =_ "%s: hierarchy=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2576 [dvb_core]dvb_validate_params_dvbt =_ "%s: guard_interval=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2563 [dvb_core]dvb_validate_params_dvbt =_ "%s: modulation=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2551 [dvb_core]dvb_validate_params_dvbt =_ "%s: transmission_mode=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2540 [dvb_core]dvb_validate_params_dvbt =_ "%s: bandwidth_hz=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2529 [dvb_core]dvb_validate_params_dvbt =_ "%s: frequency=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2519 [dvb_core]dvb_validate_params_dvbt =_ "%s: delivery_system=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2512 [dvb_core]dvb_validate_params_dvbt =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:2754 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: fec_inner=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2739 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: guard_interval=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2723 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: modulation=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2710 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: transmission_mode=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2695 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: dvbt2_plp_id=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2684 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: bandwidth_hz=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2670 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: frequency=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2655 [dvb_core]dvb_validate_params_dvbt2 =_ "%s: delivery_system=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2648 [dvb_core]dvb_validate_params_dvbt2 =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:2808 [dvb_core]dvb_validate_params_dvbc_annex_a =_ "%s: modulation=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2794 [dvb_core]dvb_validate_params_dvbc_annex_a =_ "%s: symbol_rate=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2786 [dvb_core]dvb_validate_params_dvbc_annex_a =_ "%s: frequency=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2773 [dvb_core]dvb_validate_params_dvbc_annex_a =_ "%s: delivery_system=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2766 [dvb_core]dvb_validate_params_dvbc_annex_a =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:2905 [dvb_core]dvb_validate_params_dtmb =_ "%s: interleaving=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2894 [dvb_core]dvb_validate_params_dtmb =_ "%s: fec_inner=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2881 [dvb_core]dvb_validate_params_dtmb =_ "%s: guard_interval=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2869 [dvb_core]dvb_validate_params_dtmb =_ "%s: transmission_mode=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2858 [dvb_core]dvb_validate_params_dtmb =_ "%s: modulation=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2844 [dvb_core]dvb_validate_params_dtmb =_ "%s: bandwidth_hz=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2835 [dvb_core]dvb_validate_params_dtmb =_ "%s: frequency=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2827 [dvb_core]dvb_validate_params_dtmb =_ "%s: delivery_system=%d\012"
drivers/media/dvb-core/dvb_frontend.c:2820 [dvb_core]dvb_validate_params_dtmb =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:924 [dvb_core]dvb_frontend_clear_cache =_ "%s: Clearing cache for delivery system %d\012"
drivers/media/dvb-core/dvb_frontend.c:238 [dvb_core]dvb_frontend_get_event =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:1144 [dvb_core]dtv_property_cache_sync =_ "%s: Preparing ATSC req\012"
drivers/media/dvb-core/dvb_frontend.c:1111 [dvb_core]dtv_property_cache_sync =_ "%s: Preparing OFDM req\012"
drivers/media/dvb-core/dvb_frontend.c:1105 [dvb_core]dtv_property_cache_sync =_ "%s: Preparing QAM req\012"
drivers/media/dvb-core/dvb_frontend.c:1100 [dvb_core]dtv_property_cache_sync =_ "%s: Preparing QPSK req\012"
drivers/media/dvb-core/dvb_frontend.c:2115 [dvb_core]dvb_frontend_ioctl_legacy =_ "%s: current delivery system on cache: %d, V3 type: %d\012"
drivers/media/dvb-core/dvb_frontend.c:1083 [dvb_core]dtv_property_dump =_ "%s: tvp.u.data = 0x%08x\012"
drivers/media/dvb-core/dvb_frontend.c:1080 [dvb_core]dtv_property_dump =_ "%s: tvp.u.buffer.data[0x%02x] = 0x%02x\012"
drivers/media/dvb-core/dvb_frontend.c:1075 [dvb_core]dtv_property_dump =_ "%s: tvp.u.buffer.len = 0x%02x\012"
drivers/media/dvb-core/dvb_frontend.c:1071 [dvb_core]dtv_property_dump =_ "%s: tvp.cmd = 0x%08x (%s)\012"
drivers/media/dvb-core/dvb_frontend.c:1642 [dvb_core]set_delivery_system =_ "%s: change delivery system on cache to %d\012"
drivers/media/dvb-core/dvb_frontend.c:1622 [dvb_core]set_delivery_system =_ "%s: Using defaults for SYS_ISDBT\012"
drivers/media/dvb-core/dvb_frontend.c:1612 [dvb_core]set_delivery_system =_ "%s: Using delivery system %d emulated as if it were a %d\012"
drivers/media/dvb-core/dvb_frontend.c:1594 [dvb_core]set_delivery_system =_ "%s: Incompatible DVBv3 FE_SET_FRONTEND call for this frontend\012"
drivers/media/dvb-core/dvb_frontend.c:1575 [dvb_core]set_delivery_system =_ "%s: can't use a DVBv3 FE_SET_FRONTEND call on this frontend\012"
drivers/media/dvb-core/dvb_frontend.c:1559 [dvb_core]set_delivery_system =_ "%s: Changing delivery system to %d\012"
drivers/media/dvb-core/dvb_frontend.c:1544 [dvb_core]set_delivery_system =_ "%s: Couldn't find a delivery system that matches %d\012"
drivers/media/dvb-core/dvb_frontend.c:1521 [dvb_core]set_delivery_system =_ "%s: This frontend doesn't support DVBv3 calls\012"
drivers/media/dvb-core/dvb_frontend.c:1502 [dvb_core]set_delivery_system =_ "%s: Using delivery system to %d\012"
drivers/media/dvb-core/dvb_frontend.c:1676 [dvb_core]dtv_property_process_set =_ "%s: Finalised property cache\012"
drivers/media/dvb-core/dvb_frontend.c:1901 [dvb_core]dvb_frontend_ioctl_properties =_ "%s: properties.props = %p\012"
drivers/media/dvb-core/dvb_frontend.c:1900 [dvb_core]dvb_frontend_ioctl_properties =_ "%s: properties.num = %d\012"
drivers/media/dvb-core/dvb_frontend.c:1894 [dvb_core]dvb_frontend_ioctl_properties =_ "%s: Property cache is full, tuning\012"
drivers/media/dvb-core/dvb_frontend.c:1868 [dvb_core]dvb_frontend_ioctl_properties =_ "%s: properties.props = %p\012"
drivers/media/dvb-core/dvb_frontend.c:1867 [dvb_core]dvb_frontend_ioctl_properties =_ "%s: properties.num = %d\012"
drivers/media/dvb-core/dvb_frontend.c:1862 [dvb_core]dvb_frontend_ioctl_properties =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:1826 [dvb_core]dvb_frontend_ioctl =_ "%s: (%d)\012"
drivers/media/dvb-core/dvb_frontend.c:2325 [dvb_core]dvb_frontend_poll =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:408 [dvb_core]dvb_frontend_swzigzag_autotune =_ "%s: drift:%i inversion:%i auto_step:%i auto_sub_step:%i started_auto_step:%i\012"
drivers/media/dvb-core/dvb_frontend.c:312 [dvb_core]dvb_frontend_swzigzag_update_delay =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:208 [dvb_core]dvb_frontend_add_event =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:1224 [dvb_core]dtv_property_legacy_params_sync =_ "%s: Preparing VSB req\012"
drivers/media/dvb-core/dvb_frontend.c:1192 [dvb_core]dtv_property_legacy_params_sync =_ "%s: Preparing OFDM req\012"
drivers/media/dvb-core/dvb_frontend.c:1186 [dvb_core]dtv_property_legacy_params_sync =_ "%s: Preparing QAM req\012"
drivers/media/dvb-core/dvb_frontend.c:1181 [dvb_core]dtv_property_legacy_params_sync =_ "%s: Preparing QPSK req\012"
drivers/media/dvb-core/dvb_frontend.c:285 [dvb_core]dvb_frontend_init =_ "%s: initialising adapter %i frontend %i (%s)...\012"
drivers/media/dvb-core/dvb_frontend.c:715 [dvb_core]dvb_frontend_thread =_ "%s: UNDEFINED ALGO !\012"
drivers/media/dvb-core/dvb_frontend.c:679 [dvb_core]dvb_frontend_thread =_ "%s: Retune requested, FESTAT_RETUNE\012"
drivers/media/dvb-core/dvb_frontend.c:677 [dvb_core]dvb_frontend_thread =_ "%s: Frontend ALGO = DVBFE_ALGO_CUSTOM, state=%d\012"
drivers/media/dvb-core/dvb_frontend.c:673 [dvb_core]dvb_frontend_thread =_ "%s: Frontend ALGO = DVBFE_ALGO_SW\012"
drivers/media/dvb-core/dvb_frontend.c:667 [dvb_core]dvb_frontend_thread =_ "%s: state changed, adding current state\012"
drivers/media/dvb-core/dvb_frontend.c:656 [dvb_core]dvb_frontend_thread =_ "%s: Retune requested, FESTATE_RETUNE\012"
drivers/media/dvb-core/dvb_frontend.c:653 [dvb_core]dvb_frontend_thread =_ "%s: Frontend ALGO = DVBFE_ALGO_HW\012"
drivers/media/dvb-core/dvb_frontend.c:607 [dvb_core]dvb_frontend_thread =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:821 [dvb_core]dvb_frontend_start =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:2343 [dvb_core]dvb_frontend_open =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:2438 [dvb_core]dvb_frontend_release =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:2925 [dvb_core]dvb_register_frontend =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:752 [dvb_core]dvb_frontend_stop =_ "%s:\012"
drivers/media/dvb-core/dvb_frontend.c:2967 [dvb_core]dvb_unregister_frontend =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:230 [dvb_usbv2]dvb_usbv2_adapter_stream_init =_ "%s: adap=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:242 [dvb_usbv2]dvb_usbv2_adapter_stream_exit =_ "%s: adap=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:357 [dvb_usbv2]dvb_usb_ctrl_feed =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:298 [dvb_usbv2]dvb_usb_ctrl_feed =_ "%s: start feeding\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:267 [dvb_usbv2]dvb_usb_ctrl_feed =_ "%s: stop feeding\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:258 [dvb_usbv2]dvb_usb_ctrl_feed =_ "%s: adap=%d active_fe=%d feed_type=%d setting pid [%s]: %04x (%04d) at index %d '%s'\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:381 [dvb_usbv2]dvb_usbv2_adapter_dvb_init =_ "%s: dvb_register_adapter() failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:375 [dvb_usbv2]dvb_usbv2_adapter_dvb_init =_ "%s: adap=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:446 [dvb_usbv2]dvb_usbv2_adapter_dvb_exit =_ "%s: adap=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:480 [dvb_usbv2]dvb_usbv2_device_power_ctrl =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:470 [dvb_usbv2]dvb_usbv2_device_power_ctrl =_ "%s: power=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:516 [dvb_usbv2]dvb_usb_fe_init =_ "%s: ret=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:490 [dvb_usbv2]dvb_usb_fe_init =_ "%s: adap=%d fe=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:552 [dvb_usbv2]dvb_usb_fe_sleep =_ "%s: ret=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:526 [dvb_usbv2]dvb_usb_fe_sleep =_ "%s: adap=%d fe=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:619 [dvb_usbv2]dvb_usbv2_adapter_frontend_init =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:601 [dvb_usbv2]dvb_usbv2_adapter_frontend_init =_ "%s: tuner_attach() failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:574 [dvb_usbv2]dvb_usbv2_adapter_frontend_init =_ "%s: frontend_attach() do not exists\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:569 [dvb_usbv2]dvb_usbv2_adapter_frontend_init =_ "%s: frontend_attach() failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:560 [dvb_usbv2]dvb_usbv2_adapter_frontend_init =_ "%s: adap=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:627 [dvb_usbv2]dvb_usbv2_adapter_frontend_exit =_ "%s: adap=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:189 [dvb_usbv2]dvb_usbv2_remote_init =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:133 [dvb_usbv2]dvb_usbv2_remote_init =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:712 [dvb_usbv2]dvb_usbv2_adapter_init =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:91 [dvb_usbv2]dvb_usbv2_i2c_init =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:71 [dvb_usbv2]dvb_usbv2_i2c_init =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:782 [dvb_usbv2]dvb_usbv2_init =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:749 [dvb_usbv2]dvb_usbv2_init =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:64 [dvb_usbv2]dvb_usbv2_download_firmware =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:38 [dvb_usbv2]dvb_usbv2_download_firmware =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:869 [dvb_usbv2]dvb_usbv2_init_work =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:799 [dvb_usbv2]dvb_usbv2_init_work =_ "%s: work_pid=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:925 [dvb_usbv2]dvb_usbv2_probe =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:883 [dvb_usbv2]dvb_usbv2_probe =_ "%s: bInterfaceNumber=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:97 [dvb_usbv2]dvb_usbv2_i2c_exit =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:719 [dvb_usbv2]dvb_usbv2_adapter_exit =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:195 [dvb_usbv2]dvb_usbv2_remote_exit =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:735 [dvb_usbv2]dvb_usbv2_exit =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:936 [dvb_usbv2]dvb_usbv2_disconnect =_ "%s: pid=%d work_pid=%d\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:957 [dvb_usbv2]dvb_usbv2_suspend =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1017 [dvb_usbv2]dvb_usbv2_resume =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:987 [dvb_usbv2]dvb_usbv2_resume_common =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1027 [dvb_usbv2]dvb_usbv2_reset_resume =_ "%s:\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c:65 [dvb_usbv2]dvb_usbv2_generic_rw =_ "%s: <<< %*ph\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c:39 [dvb_usbv2]dvb_usbv2_generic_rw =_ "%s: >>> %*ph\012"
drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c:31 [dvb_usbv2]dvb_usbv2_generic_rw =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:81 [dvb_usbv2]usb_urb_killv2 =_ "%s: kill urb=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:101 [dvb_usbv2]usb_urb_submitv2 =_ "%s: submit urb=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:124 [dvb_usbv2]usb_urb_free_urbs =_ "%s: free urb=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:214 [dvb_usbv2]usb_free_stream_buffers =_ "%s: free buf=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:249 [dvb_usbv2]usb_alloc_stream_buffers =_ "%s: alloc buf=%d %p (dma %llu)\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:241 [dvb_usbv2]usb_alloc_stream_buffers =_ "%s: alloc buf=%d failed\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:233 [dvb_usbv2]usb_alloc_stream_buffers =_ "%s: all in all I will use %lu bytes for streaming\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:301 [dvb_usbv2]usb_urb_reconfig =_ "%s: re-alloc urbs\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:175 [dvb_usbv2]usb_urb_alloc_isoc_urbs =_ "%s: failed\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:171 [dvb_usbv2]usb_urb_alloc_isoc_urbs =_ "%s: alloc urb=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:55 [dvb_usbv2]usb_urb_complete =_ "%s: iso frame descriptor has an error=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:43 [dvb_usbv2]usb_urb_complete =_ "%s: urb completition failed=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:30 [dvb_usbv2]usb_urb_complete =_ "%s: %s urb completed status=%d length=%d/%d pack_num=%d errors=%d\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:143 [dvb_usbv2]usb_urb_alloc_bulk_urbs =_ "%s: failed\012"
drivers/media/usb/dvb-usb-v2/usb_urb.c:140 [dvb_usbv2]usb_urb_alloc_bulk_urbs =_ "%s: alloc urb=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:334 [dvb_usb_af9035]af9035_identify_state =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:325 [dvb_usb_af9035]af9035_identify_state =_ "%s: reply=%*ph\012"
drivers/media/usb/dvb-usb-v2/af9035.c:438 [dvb_usb_af9035]af9035_download_firmware =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:411 [dvb_usb_af9035]af9035_download_firmware =_ "%s: data uploaded=%zu\012"
drivers/media/usb/dvb-usb-v2/af9035.c:380 [dvb_usb_af9035]af9035_download_firmware =_ "%s: bad firmware\012"
drivers/media/usb/dvb-usb-v2/af9035.c:376 [dvb_usb_af9035]af9035_download_firmware =_ "%s: core=%d addr=%04x data_len=%d checksum=%04x\012"
drivers/media/usb/dvb-usb-v2/af9035.c:588 [dvb_usb_af9035]af9035_read_config =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:570 [dvb_usb_af9035]af9035_read_config =_ "%s: [%d]IF=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:542 [dvb_usb_af9035]af9035_read_config =_ "%s: [%d]tuner=%02x\012"
drivers/media/usb/dvb-usb-v2/af9035.c:533 [dvb_usb_af9035]af9035_read_config =_ "%s: 2nd demod I2C addr:%02x\012"
drivers/media/usb/dvb-usb-v2/af9035.c:526 [dvb_usb_af9035]af9035_read_config =_ "%s: dual mode=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:679 [dvb_usb_af9035]af9035_fc0011_tuner_callback =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:762 [dvb_usb_af9035]af9035_frontend_attach =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:928 [dvb_usb_af9035]af9035_tuner_attach =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:974 [dvb_usb_af9035]af9035_init =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:961 [dvb_usb_af9035]af9035_init =_ "%s: USB speed=%d frame_size=%04x packet_size=%02x\012"
drivers/media/usb/dvb-usb-v2/af9035.c:1049 [dvb_usb_af9035]af9035_get_rc_config =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:1026 [dvb_usb_af9035]af9035_get_rc_config =_ "%s: ir_type=%02x\012"
drivers/media/usb/dvb-usb-v2/af9035.c:1018 [dvb_usb_af9035]af9035_get_rc_config =_ "%s: ir_mode=%02x\012"
drivers/media/usb/dvb-usb-v2/af9035.c:115 [dvb_usb_af9035]af9035_ctrl_msg =_ "%s: failed=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:102 [dvb_usb_af9035]af9035_ctrl_msg =_ "%s: command=%02x failed fw error=%d\012"
drivers/media/usb/dvb-usb-v2/af9035.c:58 [dvb_usb_af9035]af9035_ctrl_msg =_ "%s: too much data wlen=%d rlen=%d\012"
[ 187.551577] usb 1-3: new high-speed USB device number 3 using ehci_hcd
[ 187.672952] usb 1-3: New USB device found, idVendor=0b05, idProduct=1779
[ 187.672965] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 187.672974] usb 1-3: Product: AF9035A USB Device
[ 187.672981] usb 1-3: Manufacturer: Afa Technologies Inc.
[ 187.672986] usb 1-3: SerialNumber: AF0102020700001
[ 187.679952] input: Afa Technologies Inc. AF9035A USB Device as /devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.1/input/input14
[ 187.680230] 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
[ 187.731117] usbcore: registered new interface driver dvb_usb_af9035
[ 187.731822] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold state
[ 187.742775] usb 1-3: dvb_usbv2: downloading firmware from file 'dvb-usb-af9035-02.fw'
[ 188.044792] dvb_usb_af9035: firmware version=12.13.15.0
[ 188.044914] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm state
[ 188.047433] usb 1-3: dvb_usbv2: will pass the complete MPEG2 transport stream to the software demuxer
[ 188.047541] DVB: registering new adapter (Asus U3100Mini Plus)
[ 188.050526] af9033_attach:
[ 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)
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-10 14:29 ` Oliver Schinagl
@ 2012-09-10 17:28 ` Oliver Schinagl
2012-09-16 14:07 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-10 17:28 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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>
>>>>
>>>>
>>>
>>
>>
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-10 17:28 ` Oliver Schinagl
@ 2012-09-16 14:07 ` Oliver Schinagl
2012-09-16 16:43 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-16 14:07 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-16 16:43 ` Antti Palosaari
@ 2012-09-16 15:03 ` Oliver Schinagl
2012-09-16 17:25 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-16 15:03 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
>>
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-16 14:07 ` Oliver Schinagl
@ 2012-09-16 16:43 ` Antti Palosaari
2012-09-16 15:03 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-16 16:43 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-16 15:03 ` Oliver Schinagl
@ 2012-09-16 17:25 ` Antti Palosaari
2012-09-16 22:10 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-16 17:25 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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
>>>
>>
>>
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-16 17:25 ` Antti Palosaari
@ 2012-09-16 22:10 ` Oliver Schinagl
2012-09-16 23:36 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-16 22:10 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-16 22:10 ` Oliver Schinagl
@ 2012-09-16 23:36 ` Antti Palosaari
2012-09-17 8:25 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-16 23:36 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-16 23:36 ` Antti Palosaari
@ 2012-09-17 8:25 ` Oliver Schinagl
2012-09-17 13:02 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-17 8:25 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 8:25 ` Oliver Schinagl
@ 2012-09-17 13:02 ` Oliver Schinagl
2012-09-17 13:16 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-17 13:02 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 13:02 ` Oliver Schinagl
@ 2012-09-17 13:16 ` Antti Palosaari
2012-09-17 13:26 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-17 13:16 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 13:16 ` Antti Palosaari
@ 2012-09-17 13:26 ` Oliver Schinagl
2012-09-17 13:52 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-17 13:26 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 13:26 ` Oliver Schinagl
@ 2012-09-17 13:52 ` Antti Palosaari
2012-09-17 15:20 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-17 13:52 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 13:52 ` Antti Palosaari
@ 2012-09-17 15:20 ` Oliver Schinagl
2012-09-17 20:43 ` Oliver Schinagl
` (2 more replies)
0 siblings, 3 replies; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-17 15:20 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 15:20 ` Oliver Schinagl
@ 2012-09-17 20:43 ` Oliver Schinagl
2012-09-17 21:07 ` Antti Palosaari
2012-09-17 20:43 ` Oliver Schinagl
2012-09-18 22:59 ` Antti Palosaari
2 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-17 20:43 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 15:20 ` Oliver Schinagl
2012-09-17 20:43 ` Oliver Schinagl
@ 2012-09-17 20:43 ` Oliver Schinagl
2012-09-18 22:59 ` Antti Palosaari
2 siblings, 0 replies; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-17 20:43 UTC (permalink / raw)
Cc: linux-media
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 20:43 ` Oliver Schinagl
@ 2012-09-17 21:07 ` Antti Palosaari
2012-09-17 21:57 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-17 21:07 UTC (permalink / raw)
To: oliver+list; +Cc: Oliver Schinagl, linux-media
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
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 21:07 ` Antti Palosaari
@ 2012-09-17 21:57 ` Oliver Schinagl
2012-09-18 17:18 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-17 21:57 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 21:57 ` Oliver Schinagl
@ 2012-09-18 17:18 ` Oliver Schinagl
2012-09-18 22:51 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-18 17:18 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-18 17:18 ` Oliver Schinagl
@ 2012-09-18 22:51 ` Antti Palosaari
2012-09-19 10:41 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-18 22:51 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-17 15:20 ` Oliver Schinagl
2012-09-17 20:43 ` Oliver Schinagl
2012-09-17 20:43 ` Oliver Schinagl
@ 2012-09-18 22:59 ` Antti Palosaari
2 siblings, 0 replies; 41+ messages in thread
From: Antti Palosaari @ 2012-09-18 22:59 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
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
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-18 22:51 ` Antti Palosaari
@ 2012-09-19 10:41 ` Oliver Schinagl
2012-09-19 10:53 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-19 10:41 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
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
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-19 10:41 ` Oliver Schinagl
@ 2012-09-19 10:53 ` Antti Palosaari
0 siblings, 0 replies; 41+ messages in thread
From: Antti Palosaari @ 2012-09-19 10:53 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
On 09/19/2012 01:41 PM, Oliver Schinagl wrote:
> On 19-09-12 00:51, Antti Palosaari wrote:
>> On 09/18/2012 08:18 PM, Oliver Schinagl wrote:
>>> On 09/17/12 23:57, Oliver Schinagl wrote:
>>>> On 09/17/12 23:07, Antti Palosaari wrote:
>>>>> On 09/17/2012 11:43 PM, Oliver Schinagl wrote:
>>>>>> On 09/17/12 17:20, Oliver Schinagl wrote:
>>>>>>
>>>>>>>>>> If tuner communication is really working and it says chip id is
>>>>>>>>>> 0x5a
>>>>>>>>>> then it is different than driver knows. It could be new
>>>>>>>>>> revision of
>>>>>>>>>> tuner. Change chip_id to match 0x5a
>>>>>>>>>>
>>>>>>>>> Ah, so it's called chip_id on one end, but tuner_id on the other
>>>>>>>>> end.
>>>>>>>>> If/when I got this link working properly, I'll write a patch to
>>>>>>>>> fix
>>>>>>>>> some
>>>>>>>>> naming consistencies.
>>>>>>>>
>>>>>>>> No, you are totally wrong now. Chip ID is value inside chip
>>>>>>>> register.
>>>>>>>> Almost every chip has some chip id value which driver could
>>>>>>>> detect it
>>>>>>>> is speaking with correct chip. In that case value is stored inside
>>>>>>>> fc2580.
>>>>>>>>
>>>>>>>> Tuner ID is value stored inside AF9035 chip / eeprom. It is
>>>>>>>> configuration value for AF9035 hardware design. It says "that
>>>>>>>> AF9035
>>>>>>>> device uses FC2580 RF-tuner". AF9035 (FC2580) tuner ID and FC2580
>>>>>>>> chip
>>>>>>>> ID are different values having different meaning.
>>>>>>> Ok, I understand the difference between Chip ID and Tuner ID I
>>>>>>> guess,
>>>>>>> and with my new knowledge about dynamic debug I know also
>>>>>>> understand my
>>>>>>> findings and where it goes wrong. I also know understand the
>>>>>>> chipID is
>>>>>>> stored in fc2580.c under the fc2580_attach, where it checks for
>>>>>>> 0x56.
>>>>>>> Appearantly my chipID is 0x5a. I wasn't triggered by this as none of
>>>>>>> the
>>>>>>> other fc2580 or af9035 devices had such a change so it wasn't
>>>>>>> obvious.
>>>>>>> Tuner ID is actively being chechked/set in the source, so that
>>>>>>> seemed
>>>>>>> more obvious.
>>>>>> It can't be 0x5a as chipid. I actually found that the vendor driver
>>>>>> also
>>>>>> reads from 0x01 once to test the chip.
>>>>>>
>>>>>> This function is a generic function which tests I2C interface's
>>>>>> availability by reading out it's I2C id data from reg. address
>>>>>> '0x01'.
>>>>>>
>>>>>> int fc2580_i2c_test( void ) {
>>>>>> return ( fc2580_i2c_read( 0x01 ) == 0x56 )? 0x01 : 0x00;
>>>>>> }
>>>>>>
>>>>>> So something else is going weird. chipid being 0x56 is good though;
>>>>>> same
>>>>>> chip revision. However I now got my system to hang, got some
>>>>>> soft-hang
>>>>>> errors and the driver only reported failure on loading. No other
>>>>>> debug
>>>>>> that I saw from dmesg before the crash. Will investigate more.
>>>>>
>>>>> huoh.
>>>>>
>>>>> usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 <<< 56
>>>>> usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 >>> ff
>>>>> usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 <<< 56
>>>>> usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 >>> 00
>>>>> usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 <<< 56
>>>>> i2c i2c-5: fc2580: FCI FC2580 successfully identified
>>>>>
>>>>> Why do you think its value is static - it cannot be changed...
>>>> I'm not saying it can be at all :p
>>>>
>>>> according to debug output, I had
>>>>
>>>> [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a
>>>>
>>>> so to your suggestion, I made it accept chip_id 0x5a as well.
>>>> if ((chip_id != 0x56) || (chip_id != 0x5a))
>>>> goto err;
>>>>
>>>> But theoretically, it can't be 0x5a, as even the vendor driver would
>>>> only check for 0x56 (the function actually never gets called, so any
>>>> revision according the those sources could work).
>>>>
>>>> So I will investigate why it would return 0x5a for the chip id :)
>>>>
>>>>
>>> Turns out, the chip REALLY REALLY is 0x5a. I took some snapshots of both
>>> the tuner and bridge/demodulator and uploaded them to the linuxtv wiki
>>> [1]. If you could compare that one to your Chips? The markings are:
>>>
>>> FCI 2580 01BD
>>>
>>> AF9035B-N2
>>> 1012 QJFSQ
>>
>> I haven't opened my device at all...
>>
>>> On a more serious note, right now, the driver soft-locks-up. Either with
>>> or without accepting the 0x5a chip_id.
>>>
>>> What I do is, manually load all modules, enable debugging and plug in
>>> the device.
>>>
>>> Everything appears to work normally for a while, I can do the dmesg dump
>>> etc, but after about 22 seconds, I get this warning:
>>> BUG: soft lockup - CPU#2 stuck for 22s! [udev-acl:2320]
>>> (With the CPU# number being arbitrary). 22s later, another CPU fails. I
>>> haven't waited for the other core's to fail.
>>>
>>> Also, removing the module is impossible. Rebooting also fails. I have to
>>> sys-req reboot it.
>>>
>>> I don't know how much my patch is responsible for this of course, but
>>> since attaching of the tuner fails due to the wrong chip_id in one case,
>>> the only code affected is the USB id that loads the driver/firmware. I
>>> did see this with the older firmware too btw, so appears to be firmware
>>> unrelated.
>>>
>>> In the meantime, I continue finding out why after accepting chip_id
>>> 0x5a, it still fails on tuner attach. I suppose somehow the tuner_id
>>> isn't matching, which is weird, but will find out about it in the next
>>> few days.
>>
>> Tuner attach does nothing more that could fail than check that one
>> register. It is almost impossible to get it failing if tuner ID match.
>> Maybe I2C communication is not working, error returned and it bails
>> out? Anyhow, such situation should be visible when debugs are enabled.
> When it hangs the PC, nothing is visible. All functions bail out with
> error code -19. The fc2580 module is then used -1 times and can't be
> unloaded, as can't the others. As with my other post, when the tuner IS
> detected and is working, no hangs or stalls appear to be happening.
Sounds like a bug somewhere in dvb-usb-v2 framework. Actually, I have
seen similar cases few times but lastly I made quick decision it was due
to "positive" error status returned. Maybe I should take new round of
tests and checks...
>>
>>> [1] http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T
>>
>> regards
>> Antti
>>
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH] Support for Asus MyCinema U3100Mini Plus
@ 2012-09-19 18:44 oliver
2012-09-19 20:52 ` Devin Heitmueller
2012-09-19 21:36 ` Antti Palosaari
0 siblings, 2 replies; 41+ messages in thread
From: oliver @ 2012-09-19 18:44 UTC (permalink / raw)
To: linux-media; +Cc: crope, Oliver Schinagl
From: Oliver Schinagl <oliver@schinagl.nl>
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.
Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.
It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
used is the FCI FC2580.
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 | 38 +++++++++++++++++++++++++++++++
drivers/media/tuners/fc2580.c | 3 ++-
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++++++++++++++++++++++
drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
8 files changed, 75 insertions(+), 1 deletion(-)
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 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,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:
dev_dbg(&state->i2c->dev, "%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 288622b..739137e 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 /* FIC FC2580 */
u8 tuner;
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..d2c9ae6 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,43 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
};
+/* FIC FC2580 tuner init
+ AF9033_TUNER_FC2580 = 0x32 */
+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/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index afc0491..51bc39c 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);
- if (chip_id != 0x56)
+ if ((chip_id != 0x56) && (chip_id != 0x5a)) {
goto err;
+ }
dev_info(&priv->i2c->dev,
"%s: FCI FC2580 successfully identified\n",
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 89cc901..8ca13e4 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -513,6 +513,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:
@@ -750,6 +751,11 @@ static struct tda18218_config af9035_tda18218_config = {
.i2c_wr_max = 21,
};
+static struct fc2580_config af9035_fc2580_config = {
+ .i2c_addr = 0x56,
+ .clock = 16384000,
+};
+
static int af9035_tuner_attach(struct dvb_usb_adapter *adap)
{
struct state *state = adap_to_priv(adap);
@@ -851,6 +857,25 @@ 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:
+ /* Tuner enable using gpiot2_o, gpiot2_en and gpiot2_on */
+ ret = af9035_wr_reg(d, 0xd8eb, 1);
+ if (ret < 0)
+ goto err;
+
+ ret = af9035_wr_reg(d, 0xd8ec, 1);
+ if (ret < 0)
+ goto err;
+
+ ret = af9035_wr_reg(d, 0xd8ed, 1);
+ if (ret < 0)
+ goto err;
+
+ usleep_range(10000, 50000);
+ /* attach tuner */
+ fe = dvb_attach(fc2580_attach, adap->fe[0],
+ &d->i2c_adap, &af9035_fc2580_config);
+ break;
default:
fe = NULL;
}
@@ -1075,6 +1100,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 de8e761..75ef1ec 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;
--
1.7.12
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-19 18:44 [PATCH] Support for Asus MyCinema U3100Mini Plus oliver
@ 2012-09-19 20:52 ` Devin Heitmueller
2012-09-19 22:47 ` Oliver Schinagl
2012-09-20 18:54 ` Oliver Schinagl
2012-09-19 21:36 ` Antti Palosaari
1 sibling, 2 replies; 41+ messages in thread
From: Devin Heitmueller @ 2012-09-19 20:52 UTC (permalink / raw)
To: oliver; +Cc: linux-media, crope
On Wed, Sep 19, 2012 at 2:44 PM, <oliver@schinagl.nl> wrote:
> From: Oliver Schinagl <oliver@schinagl.nl>
>
> This is initial support for the Asus MyCinema U3100Mini Plus. The driver
> in its current form gets detected and loads properly.
>
> Scanning using dvbscan works without problems, Locking onto a channel
> using tzap also works fine. Only playback using tzap -r + mplayer was
> tested and was fully functional.
Hi Oliver,
The previous thread suggested that this driver didn't work with
dvbv5-scan and w_scan. Is that still the case? If so, do we really
want a "half working" driver upstream? Seems like this is more likely
to cause support headaches than the device not being supported at all
(since users will "think" it's supported but it's actually broken in
some pretty common use cases).
Or perhaps I'm mistaken and the issues have been addressed and now it
works with all the common applications.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-19 18:44 [PATCH] Support for Asus MyCinema U3100Mini Plus oliver
2012-09-19 20:52 ` Devin Heitmueller
@ 2012-09-19 21:36 ` Antti Palosaari
2012-09-20 18:54 ` Oliver Schinagl
1 sibling, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-19 21:36 UTC (permalink / raw)
To: oliver; +Cc: linux-media
This is review, please fix those minor findings mentioned and resend
fixed patch!
On 09/19/2012 09:44 PM, oliver@schinagl.nl wrote:
> From: Oliver Schinagl <oliver@schinagl.nl>
>
> This is initial support for the Asus MyCinema U3100Mini Plus. The driver
> in its current form gets detected and loads properly.
>
> Scanning using dvbscan works without problems, Locking onto a channel
> using tzap also works fine. Only playback using tzap -r + mplayer was
> tested and was fully functional.
>
> It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
> used is the FCI FC2580.
>
> 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 | 38 +++++++++++++++++++++++++++++++
> drivers/media/tuners/fc2580.c | 3 ++-
> drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
> drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++++++++++++++++++++++
> drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
> 8 files changed, 75 insertions(+), 1 deletion(-)
>
> 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 0979ada..b40f5a0 100644
> --- a/drivers/media/dvb-frontends/af9033.c
> +++ b/drivers/media/dvb-frontends/af9033.c
> @@ -314,6 +314,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:
> dev_dbg(&state->i2c->dev, "%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 288622b..739137e 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 /* FIC FC2580 */
typo in name
> u8 tuner;
>
> /*
> diff --git a/drivers/media/dvb-frontends/af9033_priv.h b/drivers/media/dvb-frontends/af9033_priv.h
> index 0b783b9..d2c9ae6 100644
> --- a/drivers/media/dvb-frontends/af9033_priv.h
> +++ b/drivers/media/dvb-frontends/af9033_priv.h
> @@ -466,5 +466,43 @@ static const struct reg_val tuner_init_tda18218[] = {
> {0x80f1e6, 0x00},
> };
>
> +/* FIC FC2580 tuner init
> + AF9033_TUNER_FC2580 = 0x32 */
> +static const struct reg_val tuner_init_fc2580[] = {
> + { 0x800046, AF9033_TUNER_FC2580 },
Personally I don't like that define here. It causes some extra work last
time I looked USB sniffs as *just* that field is the field you are first
looking for. I am going to change it anyway, feel free to leave if you
wish, it is not error, thus I am not going to say you must change it.
> + { 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/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
> index afc0491..51bc39c 100644
> --- a/drivers/media/tuners/fc2580.c
> +++ b/drivers/media/tuners/fc2580.c
> @@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
>
> dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);
>
> - if (chip_id != 0x56)
> + if ((chip_id != 0x56) && (chip_id != 0x5a)) {
> goto err;
> + }
hmm, braces added without a reason. That is Kernel CodingStyle
violation. You didn't ran checkpatch.pl ?
>
> dev_info(&priv->i2c->dev,
> "%s: FCI FC2580 successfully identified\n",
> 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 89cc901..8ca13e4 100644
> --- a/drivers/media/usb/dvb-usb-v2/af9035.c
> +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
> @@ -513,6 +513,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:
> @@ -750,6 +751,11 @@ static struct tda18218_config af9035_tda18218_config = {
> .i2c_wr_max = 21,
> };
>
> +static struct fc2580_config af9035_fc2580_config = {
> + .i2c_addr = 0x56,
> + .clock = 16384000,
> +};
I usually define config structures as a const. Is there some reason it
is not static? Compiler should also print warning as it is likely
defined as const in fc2580. ?
> +
> static int af9035_tuner_attach(struct dvb_usb_adapter *adap)
> {
> struct state *state = adap_to_priv(adap);
> @@ -851,6 +857,25 @@ 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:
> + /* Tuner enable using gpiot2_o, gpiot2_en and gpiot2_on */
> + ret = af9035_wr_reg(d, 0xd8eb, 1);
> + if (ret < 0)
> + goto err;
> +
> + ret = af9035_wr_reg(d, 0xd8ec, 1);
> + if (ret < 0)
> + goto err;
> +
> + ret = af9035_wr_reg(d, 0xd8ed, 1);
> + if (ret < 0)
> + goto err;
> +
> + usleep_range(10000, 50000);
> + /* attach tuner */
> + fe = dvb_attach(fc2580_attach, adap->fe[0],
> + &d->i2c_adap, &af9035_fc2580_config);
> + break;
These GPIO config registers are bitfields. You should use masked write
to change only the bit needed leaving undefined / unused bits to default.
> default:
> fe = NULL;
> }
> @@ -1075,6 +1100,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 de8e761..75ef1ec 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;
>
And ran the checkpatch.pl. I suspect it was not ran as there was at
least that braces violation which is reported by checkpatch what I remember.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-19 20:52 ` Devin Heitmueller
@ 2012-09-19 22:47 ` Oliver Schinagl
2012-09-20 18:54 ` Oliver Schinagl
1 sibling, 0 replies; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-19 22:47 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: linux-media
Devin Heitmueller <dheitmueller@kernellabs.com> wrote:
>On Wed, Sep 19, 2012 at 2:44 PM, <oliver@schinagl.nl> wrote:
>> From: Oliver Schinagl <oliver@schinagl.nl>
>>
>> This is initial support for the Asus MyCinema U3100Mini Plus. The
>driver
>> in its current form gets detected and loads properly.
>>
>> Scanning using dvbscan works without problems, Locking onto a channel
>> using tzap also works fine. Only playback using tzap -r + mplayer was
>> tested and was fully functional.
>
>Hi Oliver,
>
>The previous thread suggested that this driver didn't work with
>dvbv5-scan and w_scan. Is that still the case? If so, do we really
>want a "half working" driver upstream? Seems like this is more likely
>to cause support headaches than the device not being supported at all
>(since users will "think" it's supported but it's actually broken in
>some pretty common use cases).
>
>Or perhaps I'm mistaken and the issues have been addressed and now it
>works with all the common applications.
I've only tested with dvbscan, which worked fine. So initial problems apear to be solved. After working in antti's comments I will also test some more tools, but don't forsee any other issues.
>
>Devin
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-19 20:52 ` Devin Heitmueller
2012-09-19 22:47 ` Oliver Schinagl
@ 2012-09-20 18:54 ` Oliver Schinagl
2012-09-20 19:21 ` Devin Heitmueller
1 sibling, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-20 18:54 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: linux-media, crope
On 19-09-12 22:52, Devin Heitmueller wrote:
> On Wed, Sep 19, 2012 at 2:44 PM, <oliver@schinagl.nl> wrote:
>> From: Oliver Schinagl <oliver@schinagl.nl>
>>
>> This is initial support for the Asus MyCinema U3100Mini Plus. The driver
>> in its current form gets detected and loads properly.
>>
>> Scanning using dvbscan works without problems, Locking onto a channel
>> using tzap also works fine. Only playback using tzap -r + mplayer was
>> tested and was fully functional.
> Hi Oliver,
>
> The previous thread suggested that this driver didn't work with
> dvbv5-scan and w_scan. Is that still the case? If so, do we really
> want a "half working" driver upstream? Seems like this is more likely
> to cause support headaches than the device not being supported at all
> (since users will "think" it's supported but it's actually broken in
> some pretty common use cases).
After working in antti's changes.
dvbscan: works
dvbv5-scan: works
w_scan -X: works
w_scan -x: works
tzap: works (only tested the 3 available FTA channels)
dvbv5-zap: couldn't figure out how to work it :) It says: Usage:
dvbv5-zap [OPTION...] <initial file> but probably means <Channel name>?
I tried several combinations, with both a regular channels.conf file and
a dvb_channels.conf file. I will play more with it when I find some
extra time.
dvbscan and dvbv5-scan does constantly say 'tuning failed' but it does
say that on my terratec too. It does work fine however, so probably a
bug in driver/tool unrelated to this patch.
>
> Or perhaps I'm mistaken and the issues have been addressed and now it
> works with all the common applications.
>
> Devin
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-19 21:36 ` Antti Palosaari
@ 2012-09-20 18:54 ` Oliver Schinagl
0 siblings, 0 replies; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-20 18:54 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
On 19-09-12 23:36, Antti Palosaari wrote:
> This is review, please fix those minor findings mentioned and resend
> fixed patch!
Will do!
>
> On 09/19/2012 09:44 PM, oliver@schinagl.nl wrote:
>> From: Oliver Schinagl <oliver@schinagl.nl>
>>
>> This is initial support for the Asus MyCinema U3100Mini Plus. The driver
>> in its current form gets detected and loads properly.
>>
>> Scanning using dvbscan works without problems, Locking onto a channel
>> using tzap also works fine. Only playback using tzap -r + mplayer was
>> tested and was fully functional.
>>
>> It uses the af9035 USB Bridge chip, with an af9033 demodulator. The
>> tuner
>> used is the FCI FC2580.
>>
>> 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 | 38
>> +++++++++++++++++++++++++++++++
>> drivers/media/tuners/fc2580.c | 3 ++-
>> drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
>> drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++++++++++++++++++++++
>> drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
>> 8 files changed, 75 insertions(+), 1 deletion(-)
>>
>> 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 0979ada..b40f5a0 100644
>> --- a/drivers/media/dvb-frontends/af9033.c
>> +++ b/drivers/media/dvb-frontends/af9033.c
>> @@ -314,6 +314,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:
>> dev_dbg(&state->i2c->dev, "%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 288622b..739137e 100644 This is review, please fix those minor
>> findings mentioned an
>> --- 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 /* FIC FC2580 */
>
> typo in name
It took me atleast 5 minutes to realize I wrote FCI as FIC. I corrected
all instances.
>
>> u8 tuner;
>>
>> /*
>> diff --git a/drivers/media/dvb-frontends/af9033_priv.h
>> b/drivers/media/dvb-frontends/af9033_priv.h
>> index 0b783b9..d2c9ae6 100644
>> --- a/drivers/media/dvb-frontends/af9033_priv.h
>> +++ b/drivers/media/dvb-frontends/af9033_priv.h
>> @@ -466,5 +466,43 @@ static const struct reg_val
>> tuner_init_tda18218[] = {
>> {0x80f1e6, 0x00},
>> };
>>
>> +/* FIC FC2580 tuner init
>> + AF9033_TUNER_FC2580 = 0x32 */
>> +static const struct reg_val tuner_init_fc2580[] = {
>> + { 0x800046, AF9033_TUNER_FC2580 },
>
> Personally I don't like that define here. It causes some extra work
> last time I looked USB sniffs as *just* that field is the field you
> are first looking for. I am going to change it anyway, feel free to
> leave if you wish, it is not error, thus I am not going to say you
> must change it.
I was actually going to ask if it is 100% guaranteed to always be the
tuner identifier here. If that is the case, for all tuners, I don't see
the harm, especially with comment above. But I have removed it as per
request, and also since I doubt one can always guarantee that all
tuners have the tunerid there.
>
>> + { 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/tuners/fc2580.c
>> b/drivers/media/tuners/fc2580.c
>> index afc0491..51bc39c 100644
>> --- a/drivers/media/tuners/fc2580.c
>> +++ b/drivers/media/tuners/fc2580.c
>> @@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct
>> dvb_frontend *fe,
>>
>> dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);
>>
>> - if (chip_id != 0x56)
>> + if ((chip_id != 0x56) && (chip_id != 0x5a)) {
>> goto err;
>> + }
>
> hmm, braces added without a reason. That is Kernel CodingStyle
> violation. You didn't ran checkpatch.pl ?
Checkpatch did not trigger on this. Which makes sense. Kernel
CodingStyle is in very strong favor of K&R and from what I know from
K&R, K&R strongly discourage not using braces as it is very likely to
introduce bugs. Wikipedia has a small mention of this, then again
wikipedia is wikipedia. ;)
I will take it out of you really want it out, but with checkpatch not
even complaining, I would think this as an improvement. :D
>
>>
>> dev_info(&priv->i2c->dev,
>> "%s: FCI FC2580 successfully identified\n",
>> 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 89cc901..8ca13e4 100644
>> --- a/drivers/media/usb/dvb-usb-v2/af9035.c
>> +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
>> @@ -513,6 +513,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:
>> @@ -750,6 +751,11 @@ static struct tda18218_config
>> af9035_tda18218_config = {
>> .i2c_wr_max = 21,
>> };
>>
>> +static struct fc2580_config af9035_fc2580_config = {
>> + .i2c_addr = 0x56,
>> + .clock = 16384000,
>> +};
>
> I usually define config structures as a const. Is there some reason it
> is not static? Compiler should also print warning as it is likely
> defined as const in fc2580. ?
But it is static! I think you ment, not const ;)
I admit admit, I blindly copied the above laying code and changed what
needed changing. I guess the others should also be static const's and
should be streamlined?
>
>> +
>> static int af9035_tuner_attach(struct dvb_usb_adapter *adap)
>> {
>> struct state *state = adap_to_priv(adap);
>> @@ -851,6 +857,25 @@ 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:
>> + /* Tuner enable using gpiot2_o, gpiot2_en and gpiot2_on */
>> + ret = af9035_wr_reg(d, 0xd8eb, 1);
>> + if (ret < 0)
>> + goto err;
>> +
>> + ret = af9035_wr_reg(d, 0xd8ec, 1);
>> + if (ret < 0)
>> + goto err;
>> +
>> + ret = af9035_wr_reg(d, 0xd8ed, 1);
>> + if (ret < 0)
>> + goto err;
>> +
>> + usleep_range(10000, 50000);
>> + /* attach tuner */
>> + fe = dvb_attach(fc2580_attach, adap->fe[0],
>> + &d->i2c_adap, &af9035_fc2580_config);
>> + break;
>
> These GPIO config registers are bitfields. You should use masked write
> to change only the bit needed leaving undefined / unused bits to default.
I wasn't sure which of the two writes to use, and saw that most above
tuners where not bitfields so guessed this one to be too.
>
>> default:
>> fe = NULL;
>> }
>> @@ -1075,6 +1100,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 de8e761..75ef1ec 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;
>>
>
> And ran the checkpatch.pl. I suspect it was not ran as there was at
> least that braces violation which is reported by checkpatch what I
> remember.
I have, and it's happy :) Even used --strict.
>
> regards
> Antti
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH] Support for Asus MyCinema U3100Mini Plus
@ 2012-09-20 18:57 oliver
2012-09-20 19:15 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: oliver @ 2012-09-20 18:57 UTC (permalink / raw)
To: linux-media; +Cc: crope, Oliver Schinagl
From: Oliver Schinagl <oliver@schinagl.nl>
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.
Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.
It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
used is the FCI FC2580.
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 | 37 +++++++++++++++++++++++++++++++
drivers/media/tuners/fc2580.c | 3 ++-
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++++++++++++++++++++++
drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
8 files changed, 74 insertions(+), 1 deletion(-)
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 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,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:
dev_dbg(&state->i2c->dev, "%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 288622b..bfa4313 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..34dddcd 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,42 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
};
+/* FCI FC2580 tuner init */
+static const struct reg_val tuner_init_fc2580[] = {
+ { 0x800046, 0x32 },
+ { 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/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index afc0491..51bc39c 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);
- if (chip_id != 0x56)
+ if ((chip_id != 0x56) && (chip_id != 0x5a)) {
goto err;
+ }
dev_info(&priv->i2c->dev,
"%s: FCI FC2580 successfully identified\n",
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 89cc901..e7b2aff 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -513,6 +513,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:
@@ -750,6 +751,11 @@ static struct tda18218_config af9035_tda18218_config = {
.i2c_wr_max = 21,
};
+static const struct fc2580_config af9035_fc2580_config = {
+ .i2c_addr = 0x56,
+ .clock = 16384000,
+};
+
static int af9035_tuner_attach(struct dvb_usb_adapter *adap)
{
struct state *state = adap_to_priv(adap);
@@ -851,6 +857,25 @@ 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:
+ /* Tuner enable using gpiot2_o, gpiot2_en and gpiot2_on */
+ ret = af9035_wr_reg_mask(d, 0xd8eb, 0x01, 0x01);
+ if (ret < 0)
+ goto err;
+
+ ret = af9035_wr_reg_mask(d, 0xd8ec, 0x01, 0x01);
+ if (ret < 0)
+ goto err;
+
+ ret = af9035_wr_reg_mask(d, 0xd8ed, 0x01, 0x01);
+ if (ret < 0)
+ goto err;
+
+ usleep_range(10000, 50000);
+ /* attach tuner */
+ fe = dvb_attach(fc2580_attach, adap->fe[0],
+ &d->i2c_adap, &af9035_fc2580_config);
+ break;
default:
fe = NULL;
}
@@ -1075,6 +1100,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 de8e761..75ef1ec 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;
--
1.7.12
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-20 18:57 oliver
@ 2012-09-20 19:15 ` Antti Palosaari
2012-09-20 19:28 ` Oliver Schinagl
0 siblings, 1 reply; 41+ messages in thread
From: Antti Palosaari @ 2012-09-20 19:15 UTC (permalink / raw)
To: oliver; +Cc: linux-media
On 09/20/2012 09:57 PM, oliver@schinagl.nl wrote:
> From: Oliver Schinagl <oliver@schinagl.nl>
>
> This is initial support for the Asus MyCinema U3100Mini Plus. The driver
> in its current form gets detected and loads properly.
>
> Scanning using dvbscan works without problems, Locking onto a channel
> using tzap also works fine. Only playback using tzap -r + mplayer was
> tested and was fully functional.
>
> It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
> used is the FCI FC2580.
>
> Signed-off-by: Oliver Schinagl <oliver@schinagl.nl>
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
It is OK. Mauro, please merge to the master.
@Oliver, you didn't fixed FC2580 useless braces as I requested. Anyway,
I will sent another patch to fix it later. Action not required.
regards
Antti
> ---
> 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 | 37 +++++++++++++++++++++++++++++++
> drivers/media/tuners/fc2580.c | 3 ++-
> drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
> drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++++++++++++++++++++++
> drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
> 8 files changed, 74 insertions(+), 1 deletion(-)
>
> 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 0979ada..b40f5a0 100644
> --- a/drivers/media/dvb-frontends/af9033.c
> +++ b/drivers/media/dvb-frontends/af9033.c
> @@ -314,6 +314,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:
> dev_dbg(&state->i2c->dev, "%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 288622b..bfa4313 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..34dddcd 100644
> --- a/drivers/media/dvb-frontends/af9033_priv.h
> +++ b/drivers/media/dvb-frontends/af9033_priv.h
> @@ -466,5 +466,42 @@ static const struct reg_val tuner_init_tda18218[] = {
> {0x80f1e6, 0x00},
> };
>
> +/* FCI FC2580 tuner init */
> +static const struct reg_val tuner_init_fc2580[] = {
> + { 0x800046, 0x32 },
> + { 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/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
> index afc0491..51bc39c 100644
> --- a/drivers/media/tuners/fc2580.c
> +++ b/drivers/media/tuners/fc2580.c
> @@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
>
> dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);
>
> - if (chip_id != 0x56)
> + if ((chip_id != 0x56) && (chip_id != 0x5a)) {
> goto err;
> + }
>
> dev_info(&priv->i2c->dev,
> "%s: FCI FC2580 successfully identified\n",
> 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 89cc901..e7b2aff 100644
> --- a/drivers/media/usb/dvb-usb-v2/af9035.c
> +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
> @@ -513,6 +513,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:
> @@ -750,6 +751,11 @@ static struct tda18218_config af9035_tda18218_config = {
> .i2c_wr_max = 21,
> };
>
> +static const struct fc2580_config af9035_fc2580_config = {
> + .i2c_addr = 0x56,
> + .clock = 16384000,
> +};
> +
> static int af9035_tuner_attach(struct dvb_usb_adapter *adap)
> {
> struct state *state = adap_to_priv(adap);
> @@ -851,6 +857,25 @@ 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:
> + /* Tuner enable using gpiot2_o, gpiot2_en and gpiot2_on */
> + ret = af9035_wr_reg_mask(d, 0xd8eb, 0x01, 0x01);
> + if (ret < 0)
> + goto err;
> +
> + ret = af9035_wr_reg_mask(d, 0xd8ec, 0x01, 0x01);
> + if (ret < 0)
> + goto err;
> +
> + ret = af9035_wr_reg_mask(d, 0xd8ed, 0x01, 0x01);
> + if (ret < 0)
> + goto err;
> +
> + usleep_range(10000, 50000);
> + /* attach tuner */
> + fe = dvb_attach(fc2580_attach, adap->fe[0],
> + &d->i2c_adap, &af9035_fc2580_config);
> + break;
> default:
> fe = NULL;
> }
> @@ -1075,6 +1100,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 de8e761..75ef1ec 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;
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-20 18:54 ` Oliver Schinagl
@ 2012-09-20 19:21 ` Devin Heitmueller
0 siblings, 0 replies; 41+ messages in thread
From: Devin Heitmueller @ 2012-09-20 19:21 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media, crope
On Thu, Sep 20, 2012 at 2:54 PM, Oliver Schinagl
<oliver+list@schinagl.nl> wrote:
> dvbscan and dvbv5-scan does constantly say 'tuning failed' but it does say
> that on my terratec too. It does work fine however, so probably a bug in
> driver/tool unrelated to this patch.
Just to be clear, the message "tuning failed" is expected behavior
(albeit very misleading). Basically it means that the tuning attempt
was performed but it failed to get a frequency lock on that channel.
This is very common in cases where you're scanning a range of
frequencies where many of them will not actually achieve a signal
lock.
I would really like to change that message to something more clear,
especially since you're certainly not the first one to think it
indicated there was a problem. Suggestions/patches welcome.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-20 19:15 ` Antti Palosaari
@ 2012-09-20 19:28 ` Oliver Schinagl
2012-09-20 19:37 ` Antti Palosaari
0 siblings, 1 reply; 41+ messages in thread
From: Oliver Schinagl @ 2012-09-20 19:28 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media
On 20-09-12 21:15, Antti Palosaari wrote:
> On 09/20/2012 09:57 PM, oliver@schinagl.nl wrote:
>> From: Oliver Schinagl <oliver@schinagl.nl>
>>
>> This is initial support for the Asus MyCinema U3100Mini Plus. The driver
>> in its current form gets detected and loads properly.
>>
>> Scanning using dvbscan works without problems, Locking onto a channel
>> using tzap also works fine. Only playback using tzap -r + mplayer was
>> tested and was fully functional.
>>
>> It uses the af9035 USB Bridge chip, with an af9033 demodulator. The
>> tuner
>> used is the FCI FC2580.
>>
>> Signed-off-by: Oliver Schinagl <oliver@schinagl.nl>
>
> Acked-by: Antti Palosaari <crope@iki.fi>
> Reviewed-by: Antti Palosaari <crope@iki.fi>
>
> It is OK. Mauro, please merge to the master.
I do hope that it won't be a problem as I based it on your
remotes/origin/for_v3.7-13
>
> @Oliver, you didn't fixed FC2580 useless braces as I requested.
> Anyway, I will sent another patch to fix it later. Action not required.
Ah, I did comment on that change in my reply on your comments; a
re-paste from that:
Checkpatch did not trigger on this. Which makes sense. Kernel
CodingStyle is in very strong favor of K&R and from what I know from
K&R, K&R strongly discourage not using braces as it is very likely to
introduce bugs. Wikipedia has a small mention of this, then again
wikipedia is wikipedia.
I will take it out of you really want it out, but with checkpatch not
even complaining, I would think this as an improvement. :D
>
>
> regards
> Antti
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
2012-09-20 19:28 ` Oliver Schinagl
@ 2012-09-20 19:37 ` Antti Palosaari
0 siblings, 0 replies; 41+ messages in thread
From: Antti Palosaari @ 2012-09-20 19:37 UTC (permalink / raw)
To: Oliver Schinagl; +Cc: linux-media
On 09/20/2012 10:28 PM, Oliver Schinagl wrote:
> On 20-09-12 21:15, Antti Palosaari wrote:
>> On 09/20/2012 09:57 PM, oliver@schinagl.nl wrote:
>>> From: Oliver Schinagl <oliver@schinagl.nl>
>>>
>>> This is initial support for the Asus MyCinema U3100Mini Plus. The driver
>>> in its current form gets detected and loads properly.
>>>
>>> Scanning using dvbscan works without problems, Locking onto a channel
>>> using tzap also works fine. Only playback using tzap -r + mplayer was
>>> tested and was fully functional.
>>>
>>> It uses the af9035 USB Bridge chip, with an af9033 demodulator. The
>>> tuner
>>> used is the FCI FC2580.
>>>
>>> Signed-off-by: Oliver Schinagl <oliver@schinagl.nl>
>>
>> Acked-by: Antti Palosaari <crope@iki.fi>
>> Reviewed-by: Antti Palosaari <crope@iki.fi>
>>
>> It is OK. Mauro, please merge to the master.
> I do hope that it won't be a problem as I based it on your
> remotes/origin/for_v3.7-13
>>
>> @Oliver, you didn't fixed FC2580 useless braces as I requested.
>> Anyway, I will sent another patch to fix it later. Action not required.
> Ah, I did comment on that change in my reply on your comments; a
> re-paste from that:
>
> Checkpatch did not trigger on this. Which makes sense. Kernel
> CodingStyle is in very strong favor of K&R and from what I know from
> K&R, K&R strongly discourage not using braces as it is very likely to
> introduce bugs. Wikipedia has a small mention of this, then again
> wikipedia is wikipedia.
I am quite sure it says braces are not allowed for if () when it is
single line.
> I will take it out of you really want it out, but with checkpatch not
> even complaining, I would think this as an improvement. :D
Seems like you are correct, it does not detect it from the patch for
reason or the other. Maybe you could sent patch to fix checkpatch.pl :)
But it seems to find it when asked to check file correctness.
Anyway, my eyes seems to be again more careful than checkpatch ;-)
[crope@localhost linux]$ git show --format=email | ./scripts/checkpatch.pl -
total: 0 errors, 0 warnings, 141 lines checked
Your patch has no obvious style problems and is ready for submission.
[crope@localhost linux]$ ./scripts/checkpatch.pl --file
drivers/media/tuners/fc2580.c
WARNING: braces {} are not necessary for single statement blocks
#501: FILE: media/tuners/fc2580.c:501:
+ if ((chip_id != 0x56) && (chip_id != 0x5a)) {
+ goto err;
+ }
total: 0 errors, 1 warnings, 525 lines checked
drivers/media/tuners/fc2580.c has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[crope@localhost linux]$
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-09-20 19:38 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-19 18:44 [PATCH] Support for Asus MyCinema U3100Mini Plus oliver
2012-09-19 20:52 ` Devin Heitmueller
2012-09-19 22:47 ` Oliver Schinagl
2012-09-20 18:54 ` Oliver Schinagl
2012-09-20 19:21 ` Devin Heitmueller
2012-09-19 21:36 ` Antti Palosaari
2012-09-20 18:54 ` Oliver Schinagl
-- strict thread matches above, loose matches on Subject: below --
2012-09-20 18:57 oliver
2012-09-20 19:15 ` Antti Palosaari
2012-09-20 19:28 ` Oliver Schinagl
2012-09-20 19:37 ` Antti Palosaari
2012-09-09 20:47 oliver
2012-09-09 20:49 ` Oliver Schinagl
2012-09-09 21:51 ` Antti Palosaari
2012-09-09 22:26 ` Oliver Schinagl
2012-09-09 22:29 ` Antti Palosaari
2012-09-10 9:58 ` Oliver Schinagl
2012-09-10 11:46 ` Antti Palosaari
2012-09-10 14:29 ` Oliver Schinagl
2012-09-10 17:28 ` Oliver Schinagl
2012-09-16 14:07 ` Oliver Schinagl
2012-09-16 16:43 ` Antti Palosaari
2012-09-16 15:03 ` Oliver Schinagl
2012-09-16 17:25 ` Antti Palosaari
2012-09-16 22:10 ` Oliver Schinagl
2012-09-16 23:36 ` Antti Palosaari
2012-09-17 8:25 ` Oliver Schinagl
2012-09-17 13:02 ` Oliver Schinagl
2012-09-17 13:16 ` Antti Palosaari
2012-09-17 13:26 ` Oliver Schinagl
2012-09-17 13:52 ` Antti Palosaari
2012-09-17 15:20 ` Oliver Schinagl
2012-09-17 20:43 ` Oliver Schinagl
2012-09-17 21:07 ` Antti Palosaari
2012-09-17 21:57 ` Oliver Schinagl
2012-09-18 17:18 ` Oliver Schinagl
2012-09-18 22:51 ` Antti Palosaari
2012-09-19 10:41 ` Oliver Schinagl
2012-09-19 10:53 ` Antti Palosaari
2012-09-17 20:43 ` Oliver Schinagl
2012-09-18 22:59 ` Antti Palosaari
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).