All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/12] tm6000: add Terratec Cinergy Hybrid XE
@ 2010-02-05 22:48 stefan.ringel
  2010-02-05 22:48 ` [PATCH 2/12] tm6000: avoid unregister the driver after success at tm6000_init_dev stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-cards.c |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index c4db903..7f594a2 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -44,6 +44,10 @@
 #define TM6000_BOARD_FREECOM_AND_SIMILAR	7
 #define TM6000_BOARD_ADSTECH_MINI_DUAL_TV	8
 #define TM6010_BOARD_HAUPPAUGE_900H		9
+#define TM6010_BOARD_BEHOLD_WANDER		10
+#define TM6010_BOARD_BEHOLD_VOYAGER		11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE	12
+
 
 #define TM6000_MAXBOARDS        16
 static unsigned int card[]     = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -208,7 +212,21 @@ struct tm6000_board tm6000_boards[] = {
 		},
 		.gpio_addr_tun_reset = TM6000_GPIO_2,
 	},
-
+	[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+		.name         = "Terratec Cinergy Hybrid XE",
+		.tuner_type   = TUNER_XC2028, /* has a XC3028 */
+		.tuner_addr   = 0xc2 >> 1,
+		.demod_addr   = 0x1e >> 1,
+		.type         = TM6010,
+		.caps = {
+			.has_tuner    = 1,
+			.has_dvb      = 1,
+			.has_zl10353  = 1,
+			.has_eeprom   = 1,
+			.has_remote   = 1,
+		},
+		.gpio_addr_tun_reset = TM6010_GPIO_2,
+	}
 };
 
 /* table of devices that work with this driver */
@@ -221,6 +239,7 @@ struct usb_device_id tm6000_id_table [] = {
 	{ USB_DEVICE(0x2040, 0x6600), .driver_info = TM6010_BOARD_HAUPPAUGE_900H },
 	{ USB_DEVICE(0x6000, 0xdec0), .driver_info = TM6010_BOARD_BEHOLD_WANDER },
 	{ USB_DEVICE(0x6000, 0xdec1), .driver_info = TM6010_BOARD_BEHOLD_VOYAGER },
+	{ USB_DEVICE(0x0ccd, 0x0086), .driver_info = TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
 	{ },
 };
 
@@ -311,6 +330,7 @@ static void tm6000_config_tuner (struct tm6000_core *dev)
 
 		switch(dev->model) {
 		case TM6010_BOARD_HAUPPAUGE_900H:
+		case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
 			ctl.fname = "xc3028L-v36.fw";
 			break;
 		default:
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 2/12] tm6000: avoid unregister the driver after success at tm6000_init_dev
  2010-02-05 22:48 [PATCH 1/12] tm6000: add Terratec Cinergy Hybrid XE stefan.ringel
@ 2010-02-05 22:48 ` stefan.ringel
  2010-02-05 22:48   ` [PATCH 3/12] tm6000: clean the identifer string stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-cards.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index 7f594a2..e697ce3 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -422,6 +422,7 @@ static int tm6000_init_dev(struct tm6000_core *dev)
 		}
 #endif
 	}
+	return 0;
 
 err2:
 	v4l2_device_unregister(&dev->v4l2_dev);
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 3/12] tm6000: clean the identifer string
  2010-02-05 22:48 ` [PATCH 2/12] tm6000: avoid unregister the driver after success at tm6000_init_dev stefan.ringel
@ 2010-02-05 22:48   ` stefan.ringel
  2010-02-05 22:48     ` [PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-cards.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index e697ce3..1167b01 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -480,7 +480,7 @@ static int tm6000_usb_probe(struct usb_interface *interface,
 	/* Check to see next free device and mark as used */
 	nr=find_first_zero_bit(&tm6000_devused,TM6000_MAXBOARDS);
 	if (nr >= TM6000_MAXBOARDS) {
-		printk ("tm6000: Supports only %i em28xx boards.\n",TM6000_MAXBOARDS);
+		printk ("tm6000: Supports only %i tm60xx boards.\n",TM6000_MAXBOARDS);
 		usb_put_dev(usbdev);
 		return -ENOMEM;
 	}
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer
  2010-02-05 22:48   ` [PATCH 3/12] tm6000: clean the identifer string stefan.ringel
@ 2010-02-05 22:48     ` stefan.ringel
  2010-02-05 22:48       ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-i2c.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-i2c.c b/drivers/staging/tm6000/tm6000-i2c.c
index 4da10f5..3e43ad7 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -86,6 +86,11 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
 				msgs[i].len == 1 ? 0 : msgs[i].buf[1],
 				msgs[i + 1].buf, msgs[i + 1].len);
 			i++;
+			
+			if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
+				tm6000_set_reg(dev, 0x32, 0,0);
+				tm6000_set_reg(dev, 0x33, 0,0);
+			}
 			if (i2c_debug >= 2)
 				for (byte = 0; byte < msgs[i].len; byte++)
 					printk(" %02x", msgs[i].buf[byte]);
@@ -99,6 +104,12 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
 				REQ_16_SET_GET_I2C_WR1_RDN,
 				addr | msgs[i].buf[0] << 8, 0,
 				msgs[i].buf + 1, msgs[i].len - 1);
+				
+			
+			if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
+				tm6000_set_reg(dev, 0x32, 0,0);
+				tm6000_set_reg(dev, 0x33, 0,0);
+			}
 		}
 		if (i2c_debug >= 2)
 			printk("\n");
@@ -198,7 +209,7 @@ static struct i2c_algorithm tm6000_algo = {
 
 static struct i2c_adapter tm6000_adap_template = {
 	.owner = THIS_MODULE,
-	.class = I2C_CLASS_TV_ANALOG,
+	.class = I2C_CLASS_TV_ANALOG | I2C_CLASS_TV_DIGITAL,
 	.name = "tm6000",
 	.id = I2C_HW_B_TM6000,
 	.algo = &tm6000_algo,
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-05 22:48     ` [PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer stefan.ringel
@ 2010-02-05 22:48       ` stefan.ringel
  2010-02-05 22:48         ` [PATCH 7/12] tm6000: add tuner callback for dvb frontend stefan.ringel
  2010-02-08 11:21         ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Mauro Carvalho Chehab
  0 siblings, 2 replies; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-core.c |  179 ++++++++++++++++++++++++----------
 1 files changed, 128 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
index 7ec13d5..a2e2af5 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
 	{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
 
 	{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
-
+	
+	/* additional from Terratec Cinergy Hybrid XE */
+	{ REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
+	{ REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
+	{ REQ_07_SET_GET_AVREG, 0xde, 0x20 },
+	{ REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
+	{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
+	{ REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
+	
 	/* set remote wakeup key:any key wakeup */
 	{ REQ_07_SET_GET_AVREG,  0xe5,  0xfe },
 	{ REQ_07_SET_GET_AVREG,  0xda,  0xff },
@@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
 {
 	int board, rc=0, i, size;
 	struct reg_init *tab;
+	u8 buf[40];
 
 	if (dev->dev_type == TM6010) {
 		tab = tm6010_init_tab;
@@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
 		}
 	}
 
-	msleep(5); /* Just to be conservative */
-
-	/* Check board version - maybe 10Moons specific */
-	board=tm6000_get_reg16 (dev, 0x40, 0, 0);
-	if (board >=0) {
-		printk (KERN_INFO "Board version = 0x%04x\n",board);
-	} else {
-		printk (KERN_ERR "Error %i while retrieving board version\n",board);
-	}
-
+	/* hack */
 	if (dev->dev_type == TM6010) {
-		/* Turn xceive 3028 on */
-		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01);
-		msleep(11);
-	}
-
-	/* Reset GPIO1 and GPIO4. */
-	for (i=0; i< 2; i++) {
-		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
-					dev->tuner_reset_gpio, 0x00);
-		if (rc<0) {
-			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
-			return rc;
-		}
-
-		msleep(10); /* Just to be conservative */
-		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
-					dev->tuner_reset_gpio, 0x01);
-		if (rc<0) {
-			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
-			return rc;
-		}
-
-		msleep(10);
-		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 0);
-		if (rc<0) {
-			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
-			return rc;
-		}
-
-		msleep(10);
-		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 1);
-		if (rc<0) {
-			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
-			return rc;
-		}
-
-		if (!i) {
-			rc=tm6000_get_reg16(dev, 0x40,0,0);
-			if (rc>=0) {
-				printk ("board=%d\n", rc);
+		
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_4, 0);
+		msleep(15);
+				
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_1, 0);
+	
+		msleep(50);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_1, 1);
+		
+		msleep(15);
+		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
+		
+		msleep(15);
+		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
+	
+		msleep(15);
+		buf[0] = 0x12;
+		buf[1] = 0x34;
+		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x0000, buf, 2);
+	
+		msleep(15);
+		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
+	
+		msleep(15);
+		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x0000, buf, 2);
+
+		msleep(15);
+		buf[0] = 0x00;
+		buf[1] = 0x01;
+		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
+	
+		msleep(15);
+		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x0000, buf, 39);
+	
+		msleep(15);
+		buf[0] = 0x00;
+		buf[1] = 0x00;
+		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
+	
+		msleep(15);
+		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
+//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf [1]);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_4, 1);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+	    			TM6010_GPIO_0, 1);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_7, 0);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_5, 1);
+	
+		msleep(15);
+	
+		for (i=0; i< size; i++) {
+			rc= tm6000_set_reg (dev, tab[i].req, tab[i].reg, tab[i].val);
+			if (rc<0) {
+				printk (KERN_ERR "Error %i while setting req %d, "
+						 "reg %d to value %d\n", rc,
+						 tab[i].req,tab[i].reg, tab[i].val);
+				return rc;
 			}
 		}
+			
+		msleep(15);
+	
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_4, 0);
+		msleep(15);
+
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_1, 0);
+	
+		msleep(50);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_1, 1);
+		
+		msleep(15);
+		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x00c2, 0x0008, buf, 2);
+//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf[1]);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_2, 1);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_2, 0);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_2, 1);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_2, 1);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_2, 0);
+		msleep(15);
+		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				TM6010_GPIO_2, 1);
+		msleep(15);
 	}
+	/* hack end */
+	
+	msleep(5); /* Just to be conservative */
 
+	/* Check board version - maybe 10Moons specific */
+	if (dev->dev_type == TM5600) {
+		 board=tm6000_get_reg16 (dev, 0x40, 0, 0);
+		if (board >=0) {
+			printk (KERN_INFO "Board version = 0x%04x\n",board);
+		} else {
+			printk (KERN_ERR "Error %i while retrieving board version\n",board);
+		}
+	}
+	
 	msleep(50);
 
 	return 0;
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 7/12] tm6000: add tuner callback for dvb frontend
  2010-02-05 22:48       ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 stefan.ringel
@ 2010-02-05 22:48         ` stefan.ringel
  2010-02-05 22:48           ` [PATCH 8/12] tm6000: add tuner parameter stefan.ringel
  2010-02-08 11:21         ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Mauro Carvalho Chehab
  1 sibling, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-cards.c |    2 +-
 drivers/staging/tm6000/tm6000-dvb.c   |    3 ++-
 drivers/staging/tm6000/tm6000.h       |    3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index 5cf5d58..4592397 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -245,7 +245,7 @@ struct usb_device_id tm6000_id_table [] = {
 
 /* Tuner callback to provide the proper gpio changes needed for xc2028 */
 
-static int tm6000_tuner_callback(void *ptr, int component, int command, int arg)
+int tm6000_tuner_callback(void *ptr, int component, int command, int arg)
 {
 	int rc=0;
 	struct tm6000_core *dev = ptr;
diff --git a/drivers/staging/tm6000/tm6000-dvb.c b/drivers/staging/tm6000/tm6000-dvb.c
index e900d6d..fdbee30 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -235,7 +235,8 @@ int tm6000_dvb_register(struct tm6000_core *dev)
 			.i2c_adap = &dev->i2c_adap,
 			.i2c_addr = dev->tuner_addr,
 		};
-
+		
+		dvb->frontend->callback = tm6000_tuner_callback;
 		ret = dvb_register_frontend(&dvb->adapter, dvb->frontend);
 		if (ret < 0) {
 			printk(KERN_ERR
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 877cbf6..d713c48 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -202,6 +202,9 @@ struct tm6000_fh {
 			V4L2_STD_PAL_M|V4L2_STD_PAL_60|V4L2_STD_NTSC_M| \
 			V4L2_STD_NTSC_M_JP|V4L2_STD_SECAM
 
+/* In tm6000-cards.c */
+
+int tm6000_tuner_callback (void *ptr, int component, int command, int arg);
 /* In tm6000-core.c */
 
 int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 8/12] tm6000: add tuner parameter
  2010-02-05 22:48         ` [PATCH 7/12] tm6000: add tuner callback for dvb frontend stefan.ringel
@ 2010-02-05 22:48           ` stefan.ringel
  2010-02-05 22:48             ` [PATCH 9/12] tm6000: remove unused function stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-cards.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index 4592397..f22f8ad 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -312,7 +312,7 @@ static void tm6000_config_tuner (struct tm6000_core *dev)
 	memset(&tun_setup, 0, sizeof(tun_setup));
 	tun_setup.type   = dev->tuner_type;
 	tun_setup.addr   = dev->tuner_addr;
-	tun_setup.mode_mask = T_ANALOG_TV | T_RADIO;
+	tun_setup.mode_mask = T_ANALOG_TV | T_RADIO | T_DIGITAL_TV;
 	tun_setup.tuner_callback = tm6000_tuner_callback;
 
 	v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_type_addr, &tun_setup);
@@ -324,10 +324,12 @@ static void tm6000_config_tuner (struct tm6000_core *dev)
 		memset(&xc2028_cfg, 0, sizeof(xc2028_cfg));
 		memset (&ctl,0,sizeof(ctl));
 
-		ctl.mts   = 1;
-		ctl.read_not_reliable = 1;
+		ctl.input1 = 1;
+		ctl.read_not_reliable = 0;
 		ctl.msleep = 10;
-
+		ctl.demod = XC3028_FE_ZARLINK456;
+		ctl.vhfbw7 = 1;
+		ctl.uhfbw8 = 1;
 		xc2028_cfg.tuner = TUNER_XC2028;
 		xc2028_cfg.priv  = &ctl;
 
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 9/12] tm6000: remove unused function
  2010-02-05 22:48           ` [PATCH 8/12] tm6000: add tuner parameter stefan.ringel
@ 2010-02-05 22:48             ` stefan.ringel
  2010-02-05 22:48               ` [PATCH 10/12] tm6000: bugfix usb DVB transfer stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index d713c48..e88836d 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -212,7 +212,6 @@ int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
 int tm6000_get_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
 int tm6000_set_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
 int tm6000_init (struct tm6000_core *dev);
-int tm6000_init_after_firmware (struct tm6000_core *dev);
 
 int tm6000_init_analog_mode (struct tm6000_core *dev);
 int tm6000_init_digital_mode (struct tm6000_core *dev);
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 10/12] tm6000: bugfix usb DVB transfer
  2010-02-05 22:48             ` [PATCH 9/12] tm6000: remove unused function stefan.ringel
@ 2010-02-05 22:48               ` stefan.ringel
  2010-02-05 22:48                 ` [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/tm6000-dvb.c |  125 ++++++++++++++++++++++-------------
 1 files changed, 79 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-dvb.c b/drivers/staging/tm6000/tm6000-dvb.c
index fdbee30..055a58f 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -17,7 +17,9 @@
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#include <linux/kernel.h>
 #include <linux/usb.h>
+#include <compat.h>
 
 #include "tm6000.h"
 #include "tm6000-regs.h"
@@ -30,13 +32,58 @@
 
 #include "tuner-xc2028.h"
 
+static void inline print_err_status (struct tm6000_core *dev,
+				     int packet, int status)
+{
+	char *errmsg = "Unknown";
+
+	switch(status) {
+	case -ENOENT:
+		errmsg = "unlinked synchronuously";
+		break;
+	case -ECONNRESET:
+		errmsg = "unlinked asynchronuously";
+		break;
+	case -ENOSR:
+		errmsg = "Buffer error (overrun)";
+		break;
+	case -EPIPE:
+		errmsg = "Stalled (device not responding)";
+		break;
+	case -EOVERFLOW:
+		errmsg = "Babble (bad cable?)";
+		break;
+	case -EPROTO:
+		errmsg = "Bit-stuff error (bad cable?)";
+		break;
+	case -EILSEQ:
+		errmsg = "CRC/Timeout (could be anything)";
+		break;
+	case -ETIME:
+		errmsg = "Device does not respond";
+		break;
+	}
+	if (packet<0) {
+		dprintk(dev, 1, "URB status %d [%s].\n",
+			status, errmsg);
+	} else {
+		dprintk(dev, 1, "URB packet %d, status %d [%s].\n",
+			packet, status, errmsg);
+	}
+}
+
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
+static void tm6000_urb_received(struct urb *urb, struct pt_regs *ptregs)
+#else
 static void tm6000_urb_received(struct urb *urb)
+#endif
 {
 	int ret;
 	struct tm6000_core* dev = urb->context;
 
-	if(urb->status != 0){
-		printk(KERN_ERR "tm6000: status != 0\n");
+	if(urb->status != 0) {
+		print_err_status (dev,0,urb->status);
 	}
 	else if(urb->actual_length>0){
 		dvb_dmx_swfilter(&dev->dvb->demux, urb->transfer_buffer,
@@ -56,49 +103,37 @@ static void tm6000_urb_received(struct urb *urb)
 int tm6000_start_stream(struct tm6000_core *dev)
 {
 	int ret;
-	unsigned int pipe, maxPaketSize;
+	unsigned int pipe, size;
 	struct tm6000_dvb *dvb = dev->dvb;
 
 	printk(KERN_INFO "tm6000: got start stream request %s\n",__FUNCTION__);
 
 	tm6000_init_digital_mode(dev);
 
-/*
-	ret = tm6000_set_led_status(tm6000_dev, 0x1);
-	if(ret < 0) {
-		return -1;
-	}
-*/
-
 	dvb->bulk_urb = usb_alloc_urb(0, GFP_KERNEL);
 	if(dvb->bulk_urb == NULL) {
 		printk(KERN_ERR "tm6000: couldn't allocate urb\n");
 		return -ENOMEM;
 	}
 
-	maxPaketSize = dev->bulk_in->desc.wMaxPacketSize;
+	pipe = usb_rcvbulkpipe(dev->udev, dev->bulk_in->desc.bEndpointAddress
+							  & USB_ENDPOINT_NUMBER_MASK);
+							  
+	size = usb_maxpacket(dev->udev, pipe, usb_pipeout(pipe));
+	size = size * 15; /* 512 x 8 or 12 or 15 */
 
-	dvb->bulk_urb->transfer_buffer = kzalloc(maxPaketSize, GFP_KERNEL);
+	dvb->bulk_urb->transfer_buffer = kzalloc(size, GFP_KERNEL);
 	if(dvb->bulk_urb->transfer_buffer == NULL) {
 		usb_free_urb(dvb->bulk_urb);
 		printk(KERN_ERR "tm6000: couldn't allocate transfer buffer!\n");
 		return -ENOMEM;
 	}
 
-	pipe = usb_rcvbulkpipe(dev->udev, dev->bulk_in->desc.bEndpointAddress
-							  & USB_ENDPOINT_NUMBER_MASK);
-
 	usb_fill_bulk_urb(dvb->bulk_urb, dev->udev, pipe,
 						 dvb->bulk_urb->transfer_buffer,
-						 maxPaketSize,
+						 size,
 						 tm6000_urb_received, dev);
 
-	ret = usb_set_interface(dev->udev, 0, 1);
-	if(ret < 0) {
-		printk(KERN_ERR "tm6000: error %i in %s during set interface\n", ret, __FUNCTION__);
-		return ret;
-	}
-
 	ret = usb_clear_halt(dev->udev, pipe);
 	if(ret < 0) {
 		printk(KERN_ERR "tm6000: error %i in %s during pipe reset\n",ret,__FUNCTION__);
@@ -108,14 +143,13 @@ int tm6000_start_stream(struct tm6000_core *dev)
 		printk(KERN_ERR "tm6000: pipe resetted\n");
 	}
 
-// 	mutex_lock(&tm6000_driver.open_close_mutex);
+/*	mutex_lock(&tm6000_driver.open_close_mutex); */
 	ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL);
 
-
-// 	mutex_unlock(&tm6000_driver.open_close_mutex);
+/*	mutex_unlock(&tm6000_driver.open_close_mutex); */
 	if (ret) {
 		printk(KERN_ERR "tm6000: submit of urb failed (error=%i)\n",ret);
-
+		
 		kfree(dvb->bulk_urb->transfer_buffer);
 		usb_free_urb(dvb->bulk_urb);
 		return ret;
@@ -126,18 +160,12 @@ int tm6000_start_stream(struct tm6000_core *dev)
 
 void tm6000_stop_stream(struct tm6000_core *dev)
 {
-	int ret;
 	struct tm6000_dvb *dvb = dev->dvb;
 
-// 	tm6000_set_led_status(tm6000_dev, 0x0);
-
-	ret = usb_set_interface(dev->udev, 0, 0);
-	if(ret < 0) {
-		printk(KERN_ERR "tm6000: error %i in %s during set interface\n",ret,__FUNCTION__);
-	}
-
 	if(dvb->bulk_urb) {
+		printk (KERN_INFO "urb killing\n");
 		usb_kill_urb(dvb->bulk_urb);
+		printk (KERN_INFO "urb buffer free\n");
 		kfree(dvb->bulk_urb->transfer_buffer);
 		usb_free_urb(dvb->bulk_urb);
 		dvb->bulk_urb = NULL;
@@ -154,7 +182,7 @@ int tm6000_start_feed(struct dvb_demux_feed *feed)
 	mutex_lock(&dvb->mutex);
 	if(dvb->streams == 0) {
 		dvb->streams = 1;
-// 		mutex_init(&tm6000_dev->streaming_mutex);
+/*		mutex_init(&tm6000_dev->streming_mutex); */
 		tm6000_start_stream(dev);
 	}
 	else {
@@ -173,14 +201,16 @@ int tm6000_stop_feed(struct dvb_demux_feed *feed) {
 	printk(KERN_INFO "tm6000: got stop feed request %s\n",__FUNCTION__);
 
 	mutex_lock(&dvb->mutex);
-	--dvb->streams;
 
-	if(0 == dvb->streams) {
+	printk (KERN_INFO "stream %#x\n", dvb->streams);
+	--(dvb->streams);
+	if(dvb->streams == 0) {
+		printk (KERN_INFO "stop stream\n");
 		tm6000_stop_stream(dev);
-// 		mutex_destroy(&tm6000_dev->streaming_mutex);
+/*		mutex_destroy(&tm6000_dev->streaming_mutex); */
 	}
 	mutex_unlock(&dvb->mutex);
-// 	mutex_destroy(&tm6000_dev->streaming_mutex);
+/*	mutex_destroy(&tm6000_dev->streaming_mutex); */
 
 	return 0;
 }
@@ -191,13 +221,16 @@ int tm6000_dvb_attach_frontend(struct tm6000_core *dev)
 
 	if(dev->caps.has_zl10353) {
 		struct zl10353_config config =
-				    {.demod_address = dev->demod_addr >> 1,
+				    {.demod_address = dev->demod_addr,
 				     .no_tuner = 1,
-// 				     .input_frequency = 0x19e9,
-// 				     .r56_agc_targets =  0x1c,
+				     .parallel_ts = 1,
+				     .if2 = 45700,
+				     .disable_i2c_gate_ctrl = 1,
+				     .tm6000 = 1,
 				    };
 
 		dvb->frontend = pseudo_zl10353_attach(dev, &config,
+/*		dvb->frontend = dvb_attach (zl10353_attach, &config, */
 							   &dev->i2c_adap);
 	}
 	else {
@@ -259,8 +292,8 @@ int tm6000_dvb_register(struct tm6000_core *dev)
 	dvb->demux.dmx.capabilities = DMX_TS_FILTERING | DMX_SECTION_FILTERING
 							    | DMX_MEMORY_BASED_FILTERING;
 	dvb->demux.priv = dev;
-	dvb->demux.filternum = 256;
-	dvb->demux.feednum = 256;
+	dvb->demux.filternum = 5; /* 256; */
+	dvb->demux.feednum = 5; /* 256; */
 	dvb->demux.start_feed = tm6000_start_feed;
 	dvb->demux.stop_feed = tm6000_stop_feed;
 	dvb->demux.write_to_decoder = NULL;
@@ -308,7 +341,7 @@ void tm6000_dvb_unregister(struct tm6000_core *dev)
 		usb_free_urb(bulk_urb);
 	}
 
-// 	mutex_lock(&tm6000_driver.open_close_mutex);
+/*	mutex_lock(&tm6000_driver.open_close_mutex); */
 	if(dvb->frontend) {
 		dvb_frontend_detach(dvb->frontend);
 		dvb_unregister_frontend(dvb->frontend);
@@ -318,6 +351,6 @@ void tm6000_dvb_unregister(struct tm6000_core *dev)
 	dvb_dmx_release(&dvb->demux);
 	dvb_unregister_adapter(&dvb->adapter);
 	mutex_destroy(&dvb->mutex);
-// 	mutex_unlock(&tm6000_driver.open_close_mutex);
+/*	mutex_unlock(&tm6000_driver.open_close_mutex); */
 
 }
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
  2010-02-05 22:48               ` [PATCH 10/12] tm6000: bugfix usb DVB transfer stefan.ringel
@ 2010-02-05 22:48                 ` stefan.ringel
  2010-02-05 22:48                   ` [PATCH 12/12] tm6000: add a different set param values stefan.ringel
  0 siblings, 1 reply; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/media/common/tuners/tuner-xc2028.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..fcf19cc 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
 
 	/* All S-code tables need a 200kHz shift */
 	if (priv->ctrl.demod) {
-		demod = priv->ctrl.demod + 200;
+		if ((strcmp (priv->ctrl.fname, "xc3028L-v36.fw") == 0) && 
+			(priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
+				((type & DTV78) || (type & DTV8)))
+			demod = priv->ctrl.demod;
+		else
+			demod = priv->ctrl.demod + 200;
 		/*
 		 * The DTV7 S-code table needs a 700 kHz shift.
 		 * Thanks to Terry Wu <terrywu2009@gmail.com> for reporting this
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* [PATCH 12/12] tm6000: add a different set param values
  2010-02-05 22:48                 ` [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift stefan.ringel
@ 2010-02-05 22:48                   ` stefan.ringel
  0 siblings, 0 replies; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:48 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

---
 drivers/staging/tm6000/hack.c |  160 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 157 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/tm6000/hack.c b/drivers/staging/tm6000/hack.c
index f181fce..bb4100b 100644
--- a/drivers/staging/tm6000/hack.c
+++ b/drivers/staging/tm6000/hack.c
@@ -37,7 +37,6 @@ static inline int tm6000_snd_control_msg(struct tm6000_core *dev, __u8 request,
 
 static int pseudo_zl10353_pll(struct tm6000_core *tm6000_dev, struct dvb_frontend_parameters *p)
 {
-	int ret;
 	u8 *data = kzalloc(50*sizeof(u8), GFP_KERNEL);
 
 printk(KERN_ALERT "should set frequency %u\n", p->frequency);
@@ -51,7 +50,7 @@ printk(KERN_ALERT "and bandwith %u\n", p->u.ofdm.bandwidth);
 	}
 
 	// init ZL10353
-	data[0] = 0x0b;
+/*	data[0] = 0x0b;
 	ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x501e, 0x00, data, 0x1);
 	msleep(15);
 	data[0] = 0x80;
@@ -189,7 +188,162 @@ printk(KERN_ALERT "and bandwith %u\n", p->u.ofdm.bandwidth);
 			msleep(15);
 		break;
 	}
-
+*/
+	switch(p->u.ofdm.bandwidth) {
+		case BANDWIDTH_8_MHZ:
+			data[0] = 0x03;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x501e,0,data,1);
+			msleep(40);
+			data[0] = 0x44;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x511e,0,data,1);
+			msleep(40);
+			data[0] = 0x40;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+			msleep(40);
+			data[0] = 0x46;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x521e,0,data,1);
+			msleep(40);
+			data[0] = 0x15;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x531e,0,data,1);
+			msleep(40);
+			data[0] = 0x0f;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x541e,0,data,1);
+			msleep(40);
+			data[0] = 0x80;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+			msleep(40);
+			data[0] = 0x01;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+			msleep(40);
+			data[0] = 0x00;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+			msleep(40);
+			data[0] = 0x8b;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x631e,0,data,1);
+			msleep(40);
+			data[0] = 0x75;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xcc1e,0,data,1);
+			msleep(40);
+			data[0] = 0xe6; //0x19;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6c1e,0,data,1);
+			msleep(40);
+			data[0] = 0x09; //0xf7;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6d1e,0,data,1);
+			msleep(40);
+			data[0] = 0x67;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x651e,0,data,1);
+			msleep(40);
+			data[0] = 0xe5;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x661e,0,data,1);
+			msleep(40);
+			data[0] = 0x75;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5c1e,0,data,1);
+			msleep(40);
+			data[0] = 0x17;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5f1e,0,data,1);
+			msleep(40);
+			data[0] = 0x40;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5e1e,0,data,1);
+			msleep(40);
+			data[0] = 0x01;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x701e,0,data,1);
+			msleep(40);
+			break;
+		case BANDWIDTH_7_MHZ:
+			data[0] = 0x03;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x501e,0,data,1);
+			msleep(40);
+			data[0] = 0x44;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x511e,0,data,1);
+			msleep(40);
+			data[0] = 0x40;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+			msleep(40);
+			data[0] = 0x46;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x521e,0,data,1);
+			msleep(40);
+			data[0] = 0x15;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x531e,0,data,1);
+			msleep(40);
+			data[0] = 0x0f;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x541e,0,data,1);
+			msleep(40);
+			data[0] = 0x80;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+			msleep(40);
+			data[0] = 0x01;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+			msleep(40);
+			data[0] = 0x00;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+			msleep(40);
+			data[0] = 0x83;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x631e,0,data,1);
+			msleep(40);
+			data[0] = 0xa3;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xcc1e,0,data,1);
+			msleep(40);
+			data[0] = 0xe6; //0x19;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6c1e,0,data,1);
+			msleep(40);
+			data[0] = 0x09; //0xf7;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6d1e,0,data,1);
+			msleep(40);
+			data[0] = 0x5a;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x651e,0,data,1);
+			msleep(40);
+			data[0] = 0xe9;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x661e,0,data,1);
+			msleep(40);
+			data[0] = 0x86;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5c1e,0,data,1);
+			msleep(40);
+			data[0] = 0x17;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5f1e,0,data,1);
+			msleep(40);
+			data[0] = 0x40;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5e1e,0,data,1);
+			msleep(40);
+			data[0] = 0x01;
+			tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x701e,0,data,1);
+			msleep(40);
+			break;
+		default:
+			printk(KERN_ALERT "tm6000: bandwidth not supported\n");
+	}
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x051f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x051f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x051f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x051f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x051f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x0f1f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x091f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
+	tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x0b1f,0,data,2);
+	printk(KERN_INFO "buf %#x %#x \n", data[0], data[1]);
+	msleep(40);
+	
 	kfree(data);
 
 	return 0;
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-05 22:48       ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 stefan.ringel
  2010-02-05 22:48         ` [PATCH 7/12] tm6000: add tuner callback for dvb frontend stefan.ringel
@ 2010-02-08 11:21         ` Mauro Carvalho Chehab
  2010-02-08 11:37           ` Mauro Carvalho Chehab
                             ` (2 more replies)
  1 sibling, 3 replies; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2010-02-08 11:21 UTC (permalink / raw)
  To: stefan.ringel; +Cc: linux-media, dheitmueller

Hi Stefan,

First, a few comments about your patch series:

I've committed almost of your patches, and added an extra patch to make the
driver to compile it with -git. There were other broken things when compiling
against -git.

Several of your patches are adding leading whitespaces. Please review them before
submitting. On -git, those whitespaces are shown with a red background color.

I've re-made most of the patch descriptions. Please take a look on them and try
to improve on a next time.

We've got 2 submission for each patches. I just discarded the older one.

I've removed the two BEHOLDER board descriptions from one of your patches. It is
not related to your board, but it is another compilation fix.

>From your series, I didn't merge those 3 patches:

[5/12] tm6000: update init table and sequence for tm6010                http://patchwork.kernel.org/patch/77451
[6/12] tm6000: tuner reset timeing optimation                           http://patchwork.kernel.org/patch/77459
[11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and    http://patchwork.kernel.org/patch/77462

I'll send you separate comments why I didn't merge them, in reply to each email you've sent,
starting with this one (patch 5/12).


stefan.ringel@arcor.de wrote:
> From: Stefan Ringel <stefan.ringel@arcor.de>
> 
> ---
>  drivers/staging/tm6000/tm6000-core.c |  179 ++++++++++++++++++++++++----------
>  1 files changed, 128 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
> index 7ec13d5..a2e2af5 100644
> --- a/drivers/staging/tm6000/tm6000-core.c
> +++ b/drivers/staging/tm6000/tm6000-core.c
> @@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
>  	{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
>  
>  	{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
> -
> +	
> +	/* additional from Terratec Cinergy Hybrid XE */
> +	{ REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
> +	{ REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
> +	{ REQ_07_SET_GET_AVREG, 0xde, 0x20 },
> +	{ REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
> +	{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
> +	{ REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
> +	
>  	/* set remote wakeup key:any key wakeup */
>  	{ REQ_07_SET_GET_AVREG,  0xe5,  0xfe },
>  	{ REQ_07_SET_GET_AVREG,  0xda,  0xff },
> @@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
>  {
>  	int board, rc=0, i, size;
>  	struct reg_init *tab;
> +	u8 buf[40];
>  
>  	if (dev->dev_type == TM6010) {
>  		tab = tm6010_init_tab;
> @@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
>  		}
>  	}
>  
> -	msleep(5); /* Just to be conservative */
> -
> -	/* Check board version - maybe 10Moons specific */
> -	board=tm6000_get_reg16 (dev, 0x40, 0, 0);
> -	if (board >=0) {
> -		printk (KERN_INFO "Board version = 0x%04x\n",board);
> -	} else {
> -		printk (KERN_ERR "Error %i while retrieving board version\n",board);
> -	}
> -
> +	/* hack */
>  	if (dev->dev_type == TM6010) {
> -		/* Turn xceive 3028 on */
> -		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01);
> -		msleep(11);
> -	}

The above is board-specific. It is needed for the tm6010 device I have here
(HVR900H), otherwise no xc3028 command will be handled.

The better here is to add a setup routine to tm6000-cards and move all 
those GPIO codes to it. Then, add there your board-specific setup.

I've added a patch that moves those GPIO board-specific setup to tm6000-cards:
tm6000_cards_setup(). Please move your board specific GPIO init to there.


> -
> -	/* Reset GPIO1 and GPIO4. */
> -	for (i=0; i< 2; i++) {
> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> -					dev->tuner_reset_gpio, 0x00);
> -		if (rc<0) {
> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
> -			return rc;
> -		}
> -
> -		msleep(10); /* Just to be conservative */
> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> -					dev->tuner_reset_gpio, 0x01);
> -		if (rc<0) {
> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
> -			return rc;
> -		}
> -
> -		msleep(10);
> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 0);
> -		if (rc<0) {
> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
> -			return rc;
> -		}
> -
> -		msleep(10);
> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 1);
> -		if (rc<0) {
> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
> -			return rc;
> -		}
> -
> -		if (!i) {
> -			rc=tm6000_get_reg16(dev, 0x40,0,0);
> -			if (rc>=0) {
> -				printk ("board=%d\n", rc);
> +		
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_4, 0);
> +		msleep(15);
> +				
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_1, 0);
> +	
> +		msleep(50);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_1, 1);
> +		

The above reflects the timing needed by your device. Depending on the board,
the sleep time may eventually be different.

> +		msleep(15);
> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
> +		
> +		msleep(15);
> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
> +	
> +		msleep(15);
> +		buf[0] = 0x12;
> +		buf[1] = 0x34;
> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x0000, buf, 2);
> +	
> +		msleep(15);
> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
> +	
> +		msleep(15);
> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x0000, buf, 2);
> +
> +		msleep(15);
> +		buf[0] = 0x00;
> +		buf[1] = 0x01;
> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
> +	
> +		msleep(15);
> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x0000, buf, 39);
> +	
> +		msleep(15);
> +		buf[0] = 0x00;
> +		buf[1] = 0x00;
> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
> +	
> +		msleep(15);
> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf [1]);
> +		msleep(15);


At the above, you're just trying to reproduce whatever the original driver does,
instead of relying on the i2c drivers.

At the Linux drivers, we don't just send random i2c sequences in the middle of
the setup. Instead, we let each i2c driver to do the initialization they need
to do. 

If you take a look on each call, for example:
		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);

The first value determines the USB direction: 0x40 is write; 0xc0 is read;
The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for
i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14
works better for bigger sizes.

The third value gives the first byte of a write message and the i2c address. The lower
8 bits is the i2c address. The above sequence is playing with several different 
i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f.

Most of the calls there are read (0xc0). I don't know any device that requires
a read for it to work. I suspect that the above code is just probing to check
what i2c devices are found at the board. The writes are to a device at address
0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation).

I suspect that the probe sequence noticed something at the address 0x32 and is
sending some init sequence for it. As this is not the tuner nor the demod, you
don't need those setup for your device to work. Also, this address is not typical
for eeprom. Without taking a look at the hardware, we can only guess what's there.
My guess is that it is for some i2c-based remote controller chip. We don't need
this for now. After having the rest working, we may need to return on it when
patching ir-kbd.i2c.

> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_4, 1);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +	    			TM6010_GPIO_0, 1);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_7, 0);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_5, 1);
> +	
> +		msleep(15);
> +	
> +		for (i=0; i< size; i++) {
> +			rc= tm6000_set_reg (dev, tab[i].req, tab[i].reg, tab[i].val);
> +			if (rc<0) {
> +				printk (KERN_ERR "Error %i while setting req %d, "
> +						 "reg %d to value %d\n", rc,
> +						 tab[i].req,tab[i].reg, tab[i].val);
> +				return rc;
>  			}
>  		}
> +			
> +		msleep(15);
> +	
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_4, 0);
> +		msleep(15);
> +
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_1, 0);
> +	
> +		msleep(50);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_1, 1);
> +		
> +		msleep(15);
> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x00c2, 0x0008, buf, 2);
> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf[1]);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_2, 1);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_2, 0);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_2, 1);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_2, 1);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_2, 0);
> +		msleep(15);
> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> +				TM6010_GPIO_2, 1);
> +		msleep(15);
>  	}
> +	/* hack end 

The above sequence is device-specific. Please add your code after I patch
tm6000-cards.

*/
> +	
> +	msleep(5); /* Just to be conservative */
>  
> +	/* Check board version - maybe 10Moons specific */
> +	if (dev->dev_type == TM5600) {
> +		 board=tm6000_get_reg16 (dev, 0x40, 0, 0);
> +		if (board >=0) {
> +			printk (KERN_INFO "Board version = 0x%04x\n",board);
> +		} else {
> +			printk (KERN_ERR "Error %i while retrieving board version\n",board);
> +		}
> +	}
> +	
>  	msleep(50);
>  
>  	return 0;


-- 

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 11:21         ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Mauro Carvalho Chehab
@ 2010-02-08 11:37           ` Mauro Carvalho Chehab
  2010-02-08 16:12             ` Stefan Ringel
  2010-02-08 17:30           ` Stefan Ringel
  2010-02-10 17:09           ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Stefan Ringel
  2 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2010-02-08 11:37 UTC (permalink / raw)
  To: stefan.ringel; +Cc: linux-media, dheitmueller

Mauro Carvalho Chehab wrote:
>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);

> Most of the calls there are read (0xc0). I don't know any device that requires
> a read for it to work. I suspect that the above code is just probing to check
> what i2c devices are found at the board.

Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea
on what the above does:

The register 0x7f is:

        CHIP_ID            = 0x7F,

So, basically, the above code is reading the ID of the chip, likely to be sure that it
is a Zarlink 10353.

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 11:37           ` Mauro Carvalho Chehab
@ 2010-02-08 16:12             ` Stefan Ringel
  2010-02-08 17:29               ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 26+ messages in thread
From: Stefan Ringel @ 2010-02-08 16:12 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-media, dheitmueller

Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab:
> Mauro Carvalho Chehab wrote:
>   
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>>>       
>   
>> Most of the calls there are read (0xc0). I don't know any device that requires
>> a read for it to work. I suspect that the above code is just probing to check
>> what i2c devices are found at the board.
>>     
> Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea
> on what the above does:
>
> The register 0x7f is:
>
>         CHIP_ID            = 0x7F,
>
> So, basically, the above code is reading the ID of the chip, likely to be sure that it
> is a Zarlink 10353.
>
> Cheers,
> Mauro
> --
> 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
>   

yes, but that's for activating Zarlink zl10353 and checking it --> hello
Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353.

-- 
Stefan Ringel <stefan.ringel@arcor.de>


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 16:12             ` Stefan Ringel
@ 2010-02-08 17:29               ` Mauro Carvalho Chehab
  2010-02-08 17:34                 ` Stefan Ringel
  0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2010-02-08 17:29 UTC (permalink / raw)
  To: Stefan Ringel; +Cc: linux-media, dheitmueller

Stefan Ringel wrote:
> Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab:
>> Mauro Carvalho Chehab wrote:
>>   
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>>>>       
>>   
>>> Most of the calls there are read (0xc0). I don't know any device that requires
>>> a read for it to work. I suspect that the above code is just probing to check
>>> what i2c devices are found at the board.
>>>     
>> Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea
>> on what the above does:
>>
>> The register 0x7f is:
>>
>>         CHIP_ID            = 0x7F,
>>
>> So, basically, the above code is reading the ID of the chip, likely to be sure that it
>> is a Zarlink 10353.
>>
>> Cheers,
>> Mauro
>> --
>> 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
>>   
> 
> yes, but that's for activating Zarlink zl10353 and checking it --> hello
> Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353.
> 
Are you sure about that? Is this a new bug on tm6000?

Anyway, the proper place for such code is inside zl10353 driver, not outside.

-- 

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 11:21         ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Mauro Carvalho Chehab
  2010-02-08 11:37           ` Mauro Carvalho Chehab
@ 2010-02-08 17:30           ` Stefan Ringel
  2010-02-08 18:14             ` Mauro Carvalho Chehab
  2010-02-10 17:09           ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Stefan Ringel
  2 siblings, 1 reply; 26+ messages in thread
From: Stefan Ringel @ 2010-02-08 17:30 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-media, dheitmueller

Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
> Hi Stefan,
>
> First, a few comments about your patch series:
>
> I've committed almost of your patches, and added an extra patch to make the
> driver to compile it with -git. There were other broken things when compiling
> against -git.
>
> Several of your patches are adding leading whitespaces. Please review them before
> submitting. On -git, those whitespaces are shown with a red background color.
>
> I've re-made most of the patch descriptions. Please take a look on them and try
> to improve on a next time.
>
> We've got 2 submission for each patches. I just discarded the older one.
>
> I've removed the two BEHOLDER board descriptions from one of your patches. It is
> not related to your board, but it is another compilation fix.
>
> From your series, I didn't merge those 3 patches:
>
> [5/12] tm6000: update init table and sequence for tm6010                http://patchwork.kernel.org/patch/77451
> [6/12] tm6000: tuner reset timeing optimation                           http://patchwork.kernel.org/patch/77459
> [11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and    http://patchwork.kernel.org/patch/77462
>
> I'll send you separate comments why I didn't merge them, in reply to each email you've sent,
> starting with this one (patch 5/12).
>
>
> stefan.ringel@arcor.de wrote:
>   
>> From: Stefan Ringel <stefan.ringel@arcor.de>
>>
>> ---
>>  drivers/staging/tm6000/tm6000-core.c |  179 ++++++++++++++++++++++++----------
>>  1 files changed, 128 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
>> index 7ec13d5..a2e2af5 100644
>> --- a/drivers/staging/tm6000/tm6000-core.c
>> +++ b/drivers/staging/tm6000/tm6000-core.c
>> @@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
>>  	{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
>>  
>>  	{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
>> -
>> +	
>> +	/* additional from Terratec Cinergy Hybrid XE */
>> +	{ REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
>> +	{ REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
>> +	{ REQ_07_SET_GET_AVREG, 0xde, 0x20 },
>> +	{ REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
>> +	{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
>> +	{ REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
>> +	
>>  	/* set remote wakeup key:any key wakeup */
>>  	{ REQ_07_SET_GET_AVREG,  0xe5,  0xfe },
>>  	{ REQ_07_SET_GET_AVREG,  0xda,  0xff },
>> @@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
>>  {
>>  	int board, rc=0, i, size;
>>  	struct reg_init *tab;
>> +	u8 buf[40];
>>  
>>  	if (dev->dev_type == TM6010) {
>>  		tab = tm6010_init_tab;
>> @@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
>>  		}
>>  	}
>>  
>> -	msleep(5); /* Just to be conservative */
>> -
>> -	/* Check board version - maybe 10Moons specific */
>> -	board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>> -	if (board >=0) {
>> -		printk (KERN_INFO "Board version = 0x%04x\n",board);
>> -	} else {
>> -		printk (KERN_ERR "Error %i while retrieving board version\n",board);
>> -	}
>> -
>> +	/* hack */
>>  	if (dev->dev_type == TM6010) {
>> -		/* Turn xceive 3028 on */
>> -		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01);
>> -		msleep(11);
>> -	}
>>     
> The above is board-specific. It is needed for the tm6010 device I have here
> (HVR900H), otherwise no xc3028 command will be handled.
>
> The better here is to add a setup routine to tm6000-cards and move all 
> those GPIO codes to it. Then, add there your board-specific setup.
>
> I've added a patch that moves those GPIO board-specific setup to tm6000-cards:
> tm6000_cards_setup(). Please move your board specific GPIO init to there.
>
>
>   
>> -
>> -	/* Reset GPIO1 and GPIO4. */
>> -	for (i=0; i< 2; i++) {
>> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> -					dev->tuner_reset_gpio, 0x00);
>> -		if (rc<0) {
>> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>> -			return rc;
>> -		}
>> -
>> -		msleep(10); /* Just to be conservative */
>> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> -					dev->tuner_reset_gpio, 0x01);
>> -		if (rc<0) {
>> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>> -			return rc;
>> -		}
>> -
>> -		msleep(10);
>> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 0);
>> -		if (rc<0) {
>> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>> -			return rc;
>> -		}
>> -
>> -		msleep(10);
>> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 1);
>> -		if (rc<0) {
>> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>> -			return rc;
>> -		}
>> -
>> -		if (!i) {
>> -			rc=tm6000_get_reg16(dev, 0x40,0,0);
>> -			if (rc>=0) {
>> -				printk ("board=%d\n", rc);
>> +		
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_4, 0);
>> +		msleep(15);
>> +				
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_1, 0);
>> +	
>> +		msleep(50);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_1, 1);
>> +		
>>     
> The above reflects the timing needed by your device. Depending on the board,
> the sleep time may eventually be different.
>
>   
>> +		msleep(15);
>> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
>> +		
>> +		msleep(15);
>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
>> +	
>> +		msleep(15);
>> +		buf[0] = 0x12;
>> +		buf[1] = 0x34;
>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x0000, buf, 2);
>> +	
>> +		msleep(15);
>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
>> +	
>> +		msleep(15);
>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x0000, buf, 2);
>> +
>> +		msleep(15);
>> +		buf[0] = 0x00;
>> +		buf[1] = 0x01;
>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>> +	
>> +		msleep(15);
>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x0000, buf, 39);
>> +	
>> +		msleep(15);
>> +		buf[0] = 0x00;
>> +		buf[1] = 0x00;
>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>> +	
>> +		msleep(15);
>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf [1]);
>> +		msleep(15);
>>     
>
> At the above, you're just trying to reproduce whatever the original driver does,
> instead of relying on the i2c drivers.
>
> At the Linux drivers, we don't just send random i2c sequences in the middle of
> the setup. Instead, we let each i2c driver to do the initialization they need
> to do. 
>
> If you take a look on each call, for example:
> 		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>
> The first value determines the USB direction: 0x40 is write; 0xc0 is read;
> The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for
> i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14
> works better for bigger sizes.
>
> The third value gives the first byte of a write message and the i2c address. The lower
> 8 bits is the i2c address. The above sequence is playing with several different 
> i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f.
>
> Most of the calls there are read (0xc0). I don't know any device that requires
> a read for it to work. I suspect that the above code is just probing to check
> what i2c devices are found at the board. The writes are to a device at address
> 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation).
>
> I suspect that the probe sequence noticed something at the address 0x32 and is
> sending some init sequence for it. As this is not the tuner nor the demod, you
> don't need those setup for your device to work. Also, this address is not typical
> for eeprom. Without taking a look at the hardware, we can only guess what's there.
> My guess is that it is for some i2c-based remote controller chip. We don't need
> this for now. After having the rest working, we may need to return on it when
> patching ir-kbd.i2c.
>
>   
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_4, 1);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +	    			TM6010_GPIO_0, 1);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_7, 0);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_5, 1);
>> +	
>> +		msleep(15);
>> +	
>> +		for (i=0; i< size; i++) {
>> +			rc= tm6000_set_reg (dev, tab[i].req, tab[i].reg, tab[i].val);
>> +			if (rc<0) {
>> +				printk (KERN_ERR "Error %i while setting req %d, "
>> +						 "reg %d to value %d\n", rc,
>> +						 tab[i].req,tab[i].reg, tab[i].val);
>> +				return rc;
>>  			}
>>  		}
>> +			
>> +		msleep(15);
>> +	
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_4, 0);
>> +		msleep(15);
>> +
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_1, 0);
>> +	
>> +		msleep(50);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_1, 1);
>> +		
>> +		msleep(15);
>> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x00c2, 0x0008, buf, 2);
>> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf[1]);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_2, 1);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_2, 0);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_2, 1);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_2, 1);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_2, 0);
>> +		msleep(15);
>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> +				TM6010_GPIO_2, 1);
>> +		msleep(15);
>>  	}
>> +	/* hack end 
>>     
> The above sequence is device-specific. Please add your code after I patch
> tm6000-cards.
>
> */
>   
>> +	
>> +	msleep(5); /* Just to be conservative */
>>  
>> +	/* Check board version - maybe 10Moons specific */
>> +	if (dev->dev_type == TM5600) {
>> +		 board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>> +		if (board >=0) {
>> +			printk (KERN_INFO "Board version = 0x%04x\n",board);
>> +		} else {
>> +			printk (KERN_ERR "Error %i while retrieving board version\n",board);
>> +		}
>> +	}
>> +	
>>  	msleep(50);
>>  
>>  	return 0;
>>     
>
>   

I have a question, how can I implemented the reinit after activating
demodulator when it use tm6000_cards_setup().

-- 
Stefan Ringel <stefan.ringel@arcor.de>


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 17:29               ` Mauro Carvalho Chehab
@ 2010-02-08 17:34                 ` Stefan Ringel
  2010-02-08 17:37                   ` Stefan Ringel
  0 siblings, 1 reply; 26+ messages in thread
From: Stefan Ringel @ 2010-02-08 17:34 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-media, dheitmueller

Am 08.02.2010 18:29, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>   
>> Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab:
>>     
>>> Mauro Carvalho Chehab wrote:
>>>   
>>>       
>>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>>>>>       
>>>>>           
>>>   
>>>       
>>>> Most of the calls there are read (0xc0). I don't know any device that requires
>>>> a read for it to work. I suspect that the above code is just probing to check
>>>> what i2c devices are found at the board.
>>>>     
>>>>         
>>> Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea
>>> on what the above does:
>>>
>>> The register 0x7f is:
>>>
>>>         CHIP_ID            = 0x7F,
>>>
>>> So, basically, the above code is reading the ID of the chip, likely to be sure that it
>>> is a Zarlink 10353.
>>>
>>> Cheers,
>>> Mauro
>>> --
>>> 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
>>>   
>>>       
>> yes, but that's for activating Zarlink zl10353 and checking it --> hello
>> Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353.
>>
>>     
> Are you sure about that? Is this a new bug on tm6000?
>
> Anyway, the proper place for such code is inside zl10353 driver, not outside.
>
>   

It cannot activate after load xc3028 firmware.

-- 
Stefan Ringel <stefan.ringel@arcor.de>


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 17:34                 ` Stefan Ringel
@ 2010-02-08 17:37                   ` Stefan Ringel
  2010-02-08 17:51                     ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 26+ messages in thread
From: Stefan Ringel @ 2010-02-08 17:37 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-media, dheitmueller

Am 08.02.2010 18:34, schrieb Stefan Ringel:
> Am 08.02.2010 18:29, schrieb Mauro Carvalho Chehab:
>   
>> Stefan Ringel wrote:
>>   
>>     
>>> Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab:
>>>     
>>>       
>>>> Mauro Carvalho Chehab wrote:
>>>>   
>>>>       
>>>>         
>>>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>>>>>>       
>>>>>>           
>>>>>>             
>>>>   
>>>>       
>>>>         
>>>>> Most of the calls there are read (0xc0). I don't know any device that requires
>>>>> a read for it to work. I suspect that the above code is just probing to check
>>>>> what i2c devices are found at the board.
>>>>>     
>>>>>         
>>>>>           
>>>> Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea
>>>> on what the above does:
>>>>
>>>> The register 0x7f is:
>>>>
>>>>         CHIP_ID            = 0x7F,
>>>>
>>>> So, basically, the above code is reading the ID of the chip, likely to be sure that it
>>>> is a Zarlink 10353.
>>>>
>>>> Cheers,
>>>> Mauro
>>>> --
>>>> 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
>>>>   
>>>>       
>>>>         
>>> yes, but that's for activating Zarlink zl10353 and checking it --> hello
>>> Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353.
>>>
>>>     
>>>       
>> Are you sure about that? Is this a new bug on tm6000?
>>
>> Anyway, the proper place for such code is inside zl10353 driver, not outside.
>>
>>   
>>     
> It cannot activate after load xc3028 firmware.
>
>   
That part is I think it's board specific or tm6010.

-- 
Stefan Ringel <stefan.ringel@arcor.de>


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 17:37                   ` Stefan Ringel
@ 2010-02-08 17:51                     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2010-02-08 17:51 UTC (permalink / raw)
  To: Stefan Ringel; +Cc: linux-media, dheitmueller

Stefan Ringel wrote:
> Am 08.02.2010 18:34, schrieb Stefan Ringel:
>> Am 08.02.2010 18:29, schrieb Mauro Carvalho Chehab:
>>   
>>> Stefan Ringel wrote:
>>>   
>>>     
>>>> Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab:
>>>>     
>>>>       
>>>>> Mauro Carvalho Chehab wrote:
>>>>>   
>>>>>       
>>>>>         
>>>>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>>>>>>>       
>>>>>>>           
>>>>>>>             
>>>>>   
>>>>>       
>>>>>         
>>>>>> Most of the calls there are read (0xc0). I don't know any device that requires
>>>>>> a read for it to work. I suspect that the above code is just probing to check
>>>>>> what i2c devices are found at the board.
>>>>>>     
>>>>>>         
>>>>>>           
>>>>> Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea
>>>>> on what the above does:
>>>>>
>>>>> The register 0x7f is:
>>>>>
>>>>>         CHIP_ID            = 0x7F,
>>>>>
>>>>> So, basically, the above code is reading the ID of the chip, likely to be sure that it
>>>>> is a Zarlink 10353.
>>>>>
>>>>> Cheers,
>>>>> Mauro
>>>>> --
>>>>> 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
>>>>>   
>>>>>       
>>>>>         
>>>> yes, but that's for activating Zarlink zl10353 and checking it --> hello
>>>> Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353.
>>>>
>>>>     
>>>>       
>>> Are you sure about that? Is this a new bug on tm6000?
>>>
>>> Anyway, the proper place for such code is inside zl10353 driver, not outside.
>>>
>>>   
>>>     
>> It cannot activate after load xc3028 firmware.
>>
>>   
> That part is I think it's board specific or tm6010.
> 
Probably yet-another-i2c-bug-on-tm6000... Ah, well...

then, convert this call into an i2c call. You may get one example of such in em28xx-cards.
In that specific case, em28xx-based webcams can be shipped with more than one different
sensor. So, the driver needs to read the sensor from I2C:

        rc = i2c_master_recv(&dev->i2c_client, (char *)&version_be, 2);
        if (rc != 2)
                return -EINVAL;

Of course, you need to be sure to register the i2c bus before calling i2c_master_recv.

-- 

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 17:30           ` Stefan Ringel
@ 2010-02-08 18:14             ` Mauro Carvalho Chehab
  2010-02-08 19:07               ` Stefan Ringel
  0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2010-02-08 18:14 UTC (permalink / raw)
  To: Stefan Ringel; +Cc: linux-media, dheitmueller

Stefan Ringel wrote:
> Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
>> Hi Stefan,
>>
>> First, a few comments about your patch series:
>>
>> I've committed almost of your patches, and added an extra patch to make the
>> driver to compile it with -git. There were other broken things when compiling
>> against -git.
>>
>> Several of your patches are adding leading whitespaces. Please review them before
>> submitting. On -git, those whitespaces are shown with a red background color.
>>
>> I've re-made most of the patch descriptions. Please take a look on them and try
>> to improve on a next time.
>>
>> We've got 2 submission for each patches. I just discarded the older one.
>>
>> I've removed the two BEHOLDER board descriptions from one of your patches. It is
>> not related to your board, but it is another compilation fix.
>>
>> From your series, I didn't merge those 3 patches:
>>
>> [5/12] tm6000: update init table and sequence for tm6010                http://patchwork.kernel.org/patch/77451
>> [6/12] tm6000: tuner reset timeing optimation                           http://patchwork.kernel.org/patch/77459
>> [11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and    http://patchwork.kernel.org/patch/77462
>>
>> I'll send you separate comments why I didn't merge them, in reply to each email you've sent,
>> starting with this one (patch 5/12).
>>
>>
>> stefan.ringel@arcor.de wrote:
>>   
>>> From: Stefan Ringel <stefan.ringel@arcor.de>
>>>
>>> ---
>>>  drivers/staging/tm6000/tm6000-core.c |  179 ++++++++++++++++++++++++----------
>>>  1 files changed, 128 insertions(+), 51 deletions(-)
>>>
>>> diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
>>> index 7ec13d5..a2e2af5 100644
>>> --- a/drivers/staging/tm6000/tm6000-core.c
>>> +++ b/drivers/staging/tm6000/tm6000-core.c
>>> @@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
>>>  	{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
>>>  
>>>  	{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
>>> -
>>> +	
>>> +	/* additional from Terratec Cinergy Hybrid XE */
>>> +	{ REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
>>> +	{ REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
>>> +	{ REQ_07_SET_GET_AVREG, 0xde, 0x20 },
>>> +	{ REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
>>> +	{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
>>> +	{ REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
>>> +	
>>>  	/* set remote wakeup key:any key wakeup */
>>>  	{ REQ_07_SET_GET_AVREG,  0xe5,  0xfe },
>>>  	{ REQ_07_SET_GET_AVREG,  0xda,  0xff },
>>> @@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
>>>  {
>>>  	int board, rc=0, i, size;
>>>  	struct reg_init *tab;
>>> +	u8 buf[40];
>>>  
>>>  	if (dev->dev_type == TM6010) {
>>>  		tab = tm6010_init_tab;
>>> @@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
>>>  		}
>>>  	}
>>>  
>>> -	msleep(5); /* Just to be conservative */
>>> -
>>> -	/* Check board version - maybe 10Moons specific */
>>> -	board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>>> -	if (board >=0) {
>>> -		printk (KERN_INFO "Board version = 0x%04x\n",board);
>>> -	} else {
>>> -		printk (KERN_ERR "Error %i while retrieving board version\n",board);
>>> -	}
>>> -
>>> +	/* hack */
>>>  	if (dev->dev_type == TM6010) {
>>> -		/* Turn xceive 3028 on */
>>> -		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01);
>>> -		msleep(11);
>>> -	}
>>>     
>> The above is board-specific. It is needed for the tm6010 device I have here
>> (HVR900H), otherwise no xc3028 command will be handled.
>>
>> The better here is to add a setup routine to tm6000-cards and move all 
>> those GPIO codes to it. Then, add there your board-specific setup.
>>
>> I've added a patch that moves those GPIO board-specific setup to tm6000-cards:
>> tm6000_cards_setup(). Please move your board specific GPIO init to there.
>>
>>
>>   
>>> -
>>> -	/* Reset GPIO1 and GPIO4. */
>>> -	for (i=0; i< 2; i++) {
>>> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> -					dev->tuner_reset_gpio, 0x00);
>>> -		if (rc<0) {
>>> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>>> -			return rc;
>>> -		}
>>> -
>>> -		msleep(10); /* Just to be conservative */
>>> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> -					dev->tuner_reset_gpio, 0x01);
>>> -		if (rc<0) {
>>> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>>> -			return rc;
>>> -		}
>>> -
>>> -		msleep(10);
>>> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 0);
>>> -		if (rc<0) {
>>> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>>> -			return rc;
>>> -		}
>>> -
>>> -		msleep(10);
>>> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 1);
>>> -		if (rc<0) {
>>> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>>> -			return rc;
>>> -		}
>>> -
>>> -		if (!i) {
>>> -			rc=tm6000_get_reg16(dev, 0x40,0,0);
>>> -			if (rc>=0) {
>>> -				printk ("board=%d\n", rc);
>>> +		
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_4, 0);
>>> +		msleep(15);
>>> +				
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_1, 0);
>>> +	
>>> +		msleep(50);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_1, 1);
>>> +		
>>>     
>> The above reflects the timing needed by your device. Depending on the board,
>> the sleep time may eventually be different.
>>
>>   
>>> +		msleep(15);
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
>>> +		
>>> +		msleep(15);
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
>>> +	
>>> +		msleep(15);
>>> +		buf[0] = 0x12;
>>> +		buf[1] = 0x34;
>>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x0000, buf, 2);
>>> +	
>>> +		msleep(15);
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
>>> +	
>>> +		msleep(15);
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x0000, buf, 2);
>>> +
>>> +		msleep(15);
>>> +		buf[0] = 0x00;
>>> +		buf[1] = 0x01;
>>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>>> +	
>>> +		msleep(15);
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x0000, buf, 39);
>>> +	
>>> +		msleep(15);
>>> +		buf[0] = 0x00;
>>> +		buf[1] = 0x00;
>>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>>> +	
>>> +		msleep(15);
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>>> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf [1]);
>>> +		msleep(15);
>>>     
>> At the above, you're just trying to reproduce whatever the original driver does,
>> instead of relying on the i2c drivers.
>>
>> At the Linux drivers, we don't just send random i2c sequences in the middle of
>> the setup. Instead, we let each i2c driver to do the initialization they need
>> to do. 
>>
>> If you take a look on each call, for example:
>> 		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>>
>> The first value determines the USB direction: 0x40 is write; 0xc0 is read;
>> The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for
>> i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14
>> works better for bigger sizes.
>>
>> The third value gives the first byte of a write message and the i2c address. The lower
>> 8 bits is the i2c address. The above sequence is playing with several different 
>> i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f.
>>
>> Most of the calls there are read (0xc0). I don't know any device that requires
>> a read for it to work. I suspect that the above code is just probing to check
>> what i2c devices are found at the board. The writes are to a device at address
>> 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation).
>>
>> I suspect that the probe sequence noticed something at the address 0x32 and is
>> sending some init sequence for it. As this is not the tuner nor the demod, you
>> don't need those setup for your device to work. Also, this address is not typical
>> for eeprom. Without taking a look at the hardware, we can only guess what's there.
>> My guess is that it is for some i2c-based remote controller chip. We don't need
>> this for now. After having the rest working, we may need to return on it when
>> patching ir-kbd.i2c.
>>
>>   
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_4, 1);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +	    			TM6010_GPIO_0, 1);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_7, 0);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_5, 1);
>>> +	
>>> +		msleep(15);
>>> +	
>>> +		for (i=0; i< size; i++) {
>>> +			rc= tm6000_set_reg (dev, tab[i].req, tab[i].reg, tab[i].val);
>>> +			if (rc<0) {
>>> +				printk (KERN_ERR "Error %i while setting req %d, "
>>> +						 "reg %d to value %d\n", rc,
>>> +						 tab[i].req,tab[i].reg, tab[i].val);
>>> +				return rc;
>>>  			}
>>>  		}
>>> +			
>>> +		msleep(15);
>>> +	
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_4, 0);
>>> +		msleep(15);
>>> +
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_1, 0);
>>> +	
>>> +		msleep(50);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_1, 1);
>>> +		
>>> +		msleep(15);
>>> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x00c2, 0x0008, buf, 2);
>>> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf[1]);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_2, 1);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_2, 0);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_2, 1);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_2, 1);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_2, 0);
>>> +		msleep(15);
>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> +				TM6010_GPIO_2, 1);
>>> +		msleep(15);
>>>  	}
>>> +	/* hack end 
>>>     
>> The above sequence is device-specific. Please add your code after I patch
>> tm6000-cards.
>>
>> */
>>   
>>> +	
>>> +	msleep(5); /* Just to be conservative */
>>>  
>>> +	/* Check board version - maybe 10Moons specific */
>>> +	if (dev->dev_type == TM5600) {
>>> +		 board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>>> +		if (board >=0) {
>>> +			printk (KERN_INFO "Board version = 0x%04x\n",board);
>>> +		} else {
>>> +			printk (KERN_ERR "Error %i while retrieving board version\n",board);
>>> +		}
>>> +	}
>>> +	
>>>  	msleep(50);
>>>  
>>>  	return 0;
>>>     
>>   
> 
> I have a question, how can I implemented the reinit after activating
> demodulator when it use tm6000_cards_setup().

We'll need some function to change between analog and digital modes, doing the right
GPIO changes. See em28xx_set_mode() for a way of implementing it.

-- 

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 18:14             ` Mauro Carvalho Chehab
@ 2010-02-08 19:07               ` Stefan Ringel
  2010-02-08 19:17                 ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 26+ messages in thread
From: Stefan Ringel @ 2010-02-08 19:07 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-media, dheitmueller

Am 08.02.2010 19:14, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>   
>> Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
>>     
>>> Hi Stefan,
>>>
>>> First, a few comments about your patch series:
>>>
>>> I've committed almost of your patches, and added an extra patch to make the
>>> driver to compile it with -git. There were other broken things when compiling
>>> against -git.
>>>
>>> Several of your patches are adding leading whitespaces. Please review them before
>>> submitting. On -git, those whitespaces are shown with a red background color.
>>>
>>> I've re-made most of the patch descriptions. Please take a look on them and try
>>> to improve on a next time.
>>>
>>> We've got 2 submission for each patches. I just discarded the older one.
>>>
>>> I've removed the two BEHOLDER board descriptions from one of your patches. It is
>>> not related to your board, but it is another compilation fix.
>>>
>>> From your series, I didn't merge those 3 patches:
>>>
>>> [5/12] tm6000: update init table and sequence for tm6010                http://patchwork.kernel.org/patch/77451
>>> [6/12] tm6000: tuner reset timeing optimation                           http://patchwork.kernel.org/patch/77459
>>> [11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and    http://patchwork.kernel.org/patch/77462
>>>
>>> I'll send you separate comments why I didn't merge them, in reply to each email you've sent,
>>> starting with this one (patch 5/12).
>>>
>>>
>>> stefan.ringel@arcor.de wrote:
>>>   
>>>       
>>>> From: Stefan Ringel <stefan.ringel@arcor.de>
>>>>
>>>> ---
>>>>  drivers/staging/tm6000/tm6000-core.c |  179 ++++++++++++++++++++++++----------
>>>>  1 files changed, 128 insertions(+), 51 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
>>>> index 7ec13d5..a2e2af5 100644
>>>> --- a/drivers/staging/tm6000/tm6000-core.c
>>>> +++ b/drivers/staging/tm6000/tm6000-core.c
>>>> @@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
>>>>  	{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
>>>>  
>>>>  	{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
>>>> -
>>>> +	
>>>> +	/* additional from Terratec Cinergy Hybrid XE */
>>>> +	{ REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
>>>> +	{ REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
>>>> +	{ REQ_07_SET_GET_AVREG, 0xde, 0x20 },
>>>> +	{ REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
>>>> +	{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
>>>> +	{ REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
>>>> +	
>>>>  	/* set remote wakeup key:any key wakeup */
>>>>  	{ REQ_07_SET_GET_AVREG,  0xe5,  0xfe },
>>>>  	{ REQ_07_SET_GET_AVREG,  0xda,  0xff },
>>>> @@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
>>>>  {
>>>>  	int board, rc=0, i, size;
>>>>  	struct reg_init *tab;
>>>> +	u8 buf[40];
>>>>  
>>>>  	if (dev->dev_type == TM6010) {
>>>>  		tab = tm6010_init_tab;
>>>> @@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
>>>>  		}
>>>>  	}
>>>>  
>>>> -	msleep(5); /* Just to be conservative */
>>>> -
>>>> -	/* Check board version - maybe 10Moons specific */
>>>> -	board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>>>> -	if (board >=0) {
>>>> -		printk (KERN_INFO "Board version = 0x%04x\n",board);
>>>> -	} else {
>>>> -		printk (KERN_ERR "Error %i while retrieving board version\n",board);
>>>> -	}
>>>> -
>>>> +	/* hack */
>>>>  	if (dev->dev_type == TM6010) {
>>>> -		/* Turn xceive 3028 on */
>>>> -		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01);
>>>> -		msleep(11);
>>>> -	}
>>>>     
>>>>         
>>> The above is board-specific. It is needed for the tm6010 device I have here
>>> (HVR900H), otherwise no xc3028 command will be handled.
>>>
>>> The better here is to add a setup routine to tm6000-cards and move all 
>>> those GPIO codes to it. Then, add there your board-specific setup.
>>>
>>> I've added a patch that moves those GPIO board-specific setup to tm6000-cards:
>>> tm6000_cards_setup(). Please move your board specific GPIO init to there.
>>>
>>>
>>>   
>>>       
>>>> -
>>>> -	/* Reset GPIO1 and GPIO4. */
>>>> -	for (i=0; i< 2; i++) {
>>>> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> -					dev->tuner_reset_gpio, 0x00);
>>>> -		if (rc<0) {
>>>> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>>>> -			return rc;
>>>> -		}
>>>> -
>>>> -		msleep(10); /* Just to be conservative */
>>>> -		rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> -					dev->tuner_reset_gpio, 0x01);
>>>> -		if (rc<0) {
>>>> -			printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>>>> -			return rc;
>>>> -		}
>>>> -
>>>> -		msleep(10);
>>>> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 0);
>>>> -		if (rc<0) {
>>>> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>>>> -			return rc;
>>>> -		}
>>>> -
>>>> -		msleep(10);
>>>> -		rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 1);
>>>> -		if (rc<0) {
>>>> -			printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>>>> -			return rc;
>>>> -		}
>>>> -
>>>> -		if (!i) {
>>>> -			rc=tm6000_get_reg16(dev, 0x40,0,0);
>>>> -			if (rc>=0) {
>>>> -				printk ("board=%d\n", rc);
>>>> +		
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_4, 0);
>>>> +		msleep(15);
>>>> +				
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_1, 0);
>>>> +	
>>>> +		msleep(50);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_1, 1);
>>>> +		
>>>>     
>>>>         
>>> The above reflects the timing needed by your device. Depending on the board,
>>> the sleep time may eventually be different.
>>>
>>>   
>>>       
>>>> +		msleep(15);
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
>>>> +		
>>>> +		msleep(15);
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
>>>> +	
>>>> +		msleep(15);
>>>> +		buf[0] = 0x12;
>>>> +		buf[1] = 0x34;
>>>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x0000, buf, 2);
>>>> +	
>>>> +		msleep(15);
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x0000, buf, 2);
>>>> +	
>>>> +		msleep(15);
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x0000, buf, 2);
>>>> +
>>>> +		msleep(15);
>>>> +		buf[0] = 0x00;
>>>> +		buf[1] = 0x01;
>>>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>>>> +	
>>>> +		msleep(15);
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x0000, buf, 39);
>>>> +	
>>>> +		msleep(15);
>>>> +		buf[0] = 0x00;
>>>> +		buf[1] = 0x00;
>>>> +		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>>>> +	
>>>> +		msleep(15);
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x0000, buf, 2);
>>>> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf [1]);
>>>> +		msleep(15);
>>>>     
>>>>         
>>> At the above, you're just trying to reproduce whatever the original driver does,
>>> instead of relying on the i2c drivers.
>>>
>>> At the Linux drivers, we don't just send random i2c sequences in the middle of
>>> the setup. Instead, we let each i2c driver to do the initialization they need
>>> to do. 
>>>
>>> If you take a look on each call, for example:
>>> 		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>>>
>>> The first value determines the USB direction: 0x40 is write; 0xc0 is read;
>>> The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for
>>> i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14
>>> works better for bigger sizes.
>>>
>>> The third value gives the first byte of a write message and the i2c address. The lower
>>> 8 bits is the i2c address. The above sequence is playing with several different 
>>> i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f.
>>>
>>> Most of the calls there are read (0xc0). I don't know any device that requires
>>> a read for it to work. I suspect that the above code is just probing to check
>>> what i2c devices are found at the board. The writes are to a device at address
>>> 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation).
>>>
>>> I suspect that the probe sequence noticed something at the address 0x32 and is
>>> sending some init sequence for it. As this is not the tuner nor the demod, you
>>> don't need those setup for your device to work. Also, this address is not typical
>>> for eeprom. Without taking a look at the hardware, we can only guess what's there.
>>> My guess is that it is for some i2c-based remote controller chip. We don't need
>>> this for now. After having the rest working, we may need to return on it when
>>> patching ir-kbd.i2c.
>>>
>>>   
>>>       
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_4, 1);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +	    			TM6010_GPIO_0, 1);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_7, 0);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_5, 1);
>>>> +	
>>>> +		msleep(15);
>>>> +	
>>>> +		for (i=0; i< size; i++) {
>>>> +			rc= tm6000_set_reg (dev, tab[i].req, tab[i].reg, tab[i].val);
>>>> +			if (rc<0) {
>>>> +				printk (KERN_ERR "Error %i while setting req %d, "
>>>> +						 "reg %d to value %d\n", rc,
>>>> +						 tab[i].req,tab[i].reg, tab[i].val);
>>>> +				return rc;
>>>>  			}
>>>>  		}
>>>> +			
>>>> +		msleep(15);
>>>> +	
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_4, 0);
>>>> +		msleep(15);
>>>> +
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_1, 0);
>>>> +	
>>>> +		msleep(50);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_1, 1);
>>>> +		
>>>> +		msleep(15);
>>>> +		tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x00c2, 0x0008, buf, 2);
>>>> +//		printk(KERN_INFO "buf %#x %#x \n", buf[0], buf[1]);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_2, 1);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_2, 0);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_2, 1);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_2, 1);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_2, 0);
>>>> +		msleep(15);
>>>> +		tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>>> +				TM6010_GPIO_2, 1);
>>>> +		msleep(15);
>>>>  	}
>>>> +	/* hack end 
>>>>     
>>>>         
>>> The above sequence is device-specific. Please add your code after I patch
>>> tm6000-cards.
>>>
>>> */
>>>   
>>>       
>>>> +	
>>>> +	msleep(5); /* Just to be conservative */
>>>>  
>>>> +	/* Check board version - maybe 10Moons specific */
>>>> +	if (dev->dev_type == TM5600) {
>>>> +		 board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>>>> +		if (board >=0) {
>>>> +			printk (KERN_INFO "Board version = 0x%04x\n",board);
>>>> +		} else {
>>>> +			printk (KERN_ERR "Error %i while retrieving board version\n",board);
>>>> +		}
>>>> +	}
>>>> +	
>>>>  	msleep(50);
>>>>  
>>>>  	return 0;
>>>>     
>>>>         
>>>   
>>>       
>> I have a question, how can I implemented the reinit after activating
>> demodulator when it use tm6000_cards_setup().
>>     
> We'll need some function to change between analog and digital modes, doing the right
> GPIO changes. See em28xx_set_mode() for a way of implementing it.
>
>   
I don't mean that. I mean it loads the init table then goes to
tm600_cards_setup, then goes to return and loads the init table new and
then ... reset the demodulator or can it without the reset demodulator?
I can test it next weekend.

cheers

Stefan Ringel

-- 
Stefan Ringel <stefan.ringel@arcor.de>


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 19:07               ` Stefan Ringel
@ 2010-02-08 19:17                 ` Mauro Carvalho Chehab
  2010-02-08 20:04                   ` zl10335 with tm6010 or tm6000 Stefan Ringel
  0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2010-02-08 19:17 UTC (permalink / raw)
  To: Stefan Ringel; +Cc: linux-media, dheitmueller

Stefan Ringel wrote:
> Am 08.02.2010 19:14, schrieb Mauro Carvalho Chehab:
>> Stefan Ringel wrote:
>>   
    
>> We'll need some function to change between analog and digital modes, doing the right
>> GPIO changes. See em28xx_set_mode() for a way of implementing it.
>>
>>   
> I don't mean that. I mean it loads the init table then goes to
> tm600_cards_setup, then goes to return and loads the init table new and
> then ... reset the demodulator or can it without the reset demodulator?
> I can test it next weekend.

Tests are required. Maybe you'll need to call it again. The tm6000 chip has lot of
weird behaviours. In the case of xc3028 on analog, you need to re-load the firmware
every time the stream starts. Also, it seems that tm6000 has a timeout: if the image
is not ok for a few seconds, it cuts the tuner down. So, I ended to make it to re-load
part of the firmware (the smaller part of the firmware) every time the channel changes,
when I wrote the first version of the driver. I suspect that this behavior of tuner-xc2028
were removed on the last driver reviews, to speedup tuning with all other devices that
use those chips.

-- 

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 26+ messages in thread
* zl10335 with tm6010 or tm6000
  2010-02-08 19:17                 ` Mauro Carvalho Chehab
@ 2010-02-08 20:04                   ` Stefan Ringel
  0 siblings, 0 replies; 26+ messages in thread
From: Stefan Ringel @ 2010-02-08 20:04 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-media, dheitmueller

I have switched from hack to zl10353 module, and  I have tested more
different setups. I have found what wrong is, in function
tl10353_read_status() and zl10353_read_snr(), not positive value.

zl10353_read_status()

reg                        has digital                            hasn't
digital

0x05                    0x40                                    0x00
0x06                    0x00                                    0x21
0x07                    0x33                                    0x03
0x08                    0x00                                    0x00
more than 0x00
0x09                    0x58                                    0x00

zl10353_read_snr()

reg                        has digital                            hasn't
digital

0x0f                     0x28   inv ( 0xd8) =^87%    0x2b  inv (0xd5) =^ 84%
0x10                    0x00                                    0x00


the function set_parameters is working. I have added (only for test) a
full HAS_FE_* status, so that I tested the set_parameter function.

-- 
Stefan Ringel <stefan.ringel@arcor.de>


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-08 11:21         ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Mauro Carvalho Chehab
  2010-02-08 11:37           ` Mauro Carvalho Chehab
  2010-02-08 17:30           ` Stefan Ringel
@ 2010-02-10 17:09           ` Stefan Ringel
  2010-02-10 17:21             ` Mauro Carvalho Chehab
  2 siblings, 1 reply; 26+ messages in thread
From: Stefan Ringel @ 2010-02-10 17:09 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-media, dheitmueller

Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
>
> At the above, you're just trying to reproduce whatever the original driver does,
> instead of relying on the i2c drivers.
>
> At the Linux drivers, we don't just send random i2c sequences in the middle of
> the setup. Instead, we let each i2c driver to do the initialization they need
> to do. 
>
> If you take a look on each call, for example:
> 		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>
> The first value determines the USB direction: 0x40 is write; 0xc0 is read;
> The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for
> i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14
> works better for bigger sizes.
>
> The third value gives the first byte of a write message and the i2c address. The lower
> 8 bits is the i2c address. The above sequence is playing with several different 
> i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f.
>
> Most of the calls there are read (0xc0). I don't know any device that requires
> a read for it to work. I suspect that the above code is just probing to check
> what i2c devices are found at the board. The writes are to a device at address
> 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation).
>
> I suspect that the probe sequence noticed something at the address 0x32 and is
> sending some init sequence for it. As this is not the tuner nor the demod, you
> don't need those setup for your device to work. Also, this address is not typical
> for eeprom. Without taking a look at the hardware, we can only guess what's there.
> My guess is that it is for some i2c-based remote controller chip. We don't need
> this for now. After having the rest working, we may need to return on it when
> patching ir-kbd.i2c.
>   

The i2c address 0x32 isn't ir, but I think it sets the power or so. Ir
has vendor requests. see tm6000_regs.h . The i2c addresses 0x10 and 0xc0
cannot say what this is (check i2c address space or so). and the i2c
address 0x1f is the read address from demodulator.

-- 
Stefan Ringel <stefan.ringel@arcor.de>


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
  2010-02-10 17:09           ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Stefan Ringel
@ 2010-02-10 17:21             ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2010-02-10 17:21 UTC (permalink / raw)
  To: Stefan Ringel; +Cc: linux-media, dheitmueller

Stefan Ringel wrote:
> Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
>> At the above, you're just trying to reproduce whatever the original driver does,
>> instead of relying on the i2c drivers.
>>
>> At the Linux drivers, we don't just send random i2c sequences in the middle of
>> the setup. Instead, we let each i2c driver to do the initialization they need
>> to do. 
>>
>> If you take a look on each call, for example:
>> 		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>>
>> The first value determines the USB direction: 0x40 is write; 0xc0 is read;
>> The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for
>> i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14
>> works better for bigger sizes.
>>
>> The third value gives the first byte of a write message and the i2c address. The lower
>> 8 bits is the i2c address. The above sequence is playing with several different 
>> i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f.
>>
>> Most of the calls there are read (0xc0). I don't know any device that requires
>> a read for it to work. I suspect that the above code is just probing to check
>> what i2c devices are found at the board. The writes are to a device at address
>> 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation).
>>
>> I suspect that the probe sequence noticed something at the address 0x32 and is
>> sending some init sequence for it. As this is not the tuner nor the demod, you
>> don't need those setup for your device to work. Also, this address is not typical
>> for eeprom. Without taking a look at the hardware, we can only guess what's there.
>> My guess is that it is for some i2c-based remote controller chip. We don't need
>> this for now. After having the rest working, we may need to return on it when
>> patching ir-kbd.i2c.
>>   
> 
> The i2c address 0x32 isn't ir, but I think it sets the power or so. Ir
> has vendor requests. see tm6000_regs.h .

The way IR works depend on vendor's decision. Even having some URB messages dedicated
to IR, someone may use instead an i2c chip.

If 0x32 is not IR, then maybe it might be an audio demod. The only way to know for sure
is to open a device that answers to this address and see what chips are inside.

 The i2c addresses 0x10 and 0xc0
> cannot say what this is (check i2c address space or so). and the i2c
> address 0x1f is the read address from demodulator.

0xc0 is for sure tuner. Allmost 100% of the tuners in the market (including xc3028) can
use 0xc0. All it is needed to change is to send 5V or GND to certain pins at the tuner,
chip in order to define what address will be used. Yet, all projects I've seen so far with
xc3028 use 0xc2.

0x10 can be used by some AM/FM radio chips with RDS.

Anyway, I'm almost sure that your board doesn't have any of those chips. If you're in doubt,
then you'll need to open your device and look what chips are inside, seeking for datasheets
or other info for the other i2c chips you might find.

-- 

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer
  2010-02-05 22:57   ` [PATCH 3/12] tm6000: clean the identifer string stefan.ringel
@ 2010-02-05 22:57     ` stefan.ringel
  0 siblings, 0 replies; 26+ messages in thread
From: stefan.ringel @ 2010-02-05 22:57 UTC (permalink / raw)
  To: linux-media; +Cc: mchehab, dheitmueller, Stefan Ringel

From: Stefan Ringel <stefan.ringel@arcor.de>

Signed-off-by: Stefan Ringel <stefan.ringel@arcor.de>
---
 drivers/staging/tm6000/tm6000-i2c.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-i2c.c b/drivers/staging/tm6000/tm6000-i2c.c
index 4da10f5..3e43ad7 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -86,6 +86,11 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
 				msgs[i].len == 1 ? 0 : msgs[i].buf[1],
 				msgs[i + 1].buf, msgs[i + 1].len);
 			i++;
+			
+			if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
+				tm6000_set_reg(dev, 0x32, 0,0);
+				tm6000_set_reg(dev, 0x33, 0,0);
+			}
 			if (i2c_debug >= 2)
 				for (byte = 0; byte < msgs[i].len; byte++)
 					printk(" %02x", msgs[i].buf[byte]);
@@ -99,6 +104,12 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
 				REQ_16_SET_GET_I2C_WR1_RDN,
 				addr | msgs[i].buf[0] << 8, 0,
 				msgs[i].buf + 1, msgs[i].len - 1);
+				
+			
+			if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
+				tm6000_set_reg(dev, 0x32, 0,0);
+				tm6000_set_reg(dev, 0x33, 0,0);
+			}
 		}
 		if (i2c_debug >= 2)
 			printk("\n");
@@ -198,7 +209,7 @@ static struct i2c_algorithm tm6000_algo = {
 
 static struct i2c_adapter tm6000_adap_template = {
 	.owner = THIS_MODULE,
-	.class = I2C_CLASS_TV_ANALOG,
+	.class = I2C_CLASS_TV_ANALOG | I2C_CLASS_TV_DIGITAL,
 	.name = "tm6000",
 	.id = I2C_HW_B_TM6000,
 	.algo = &tm6000_algo,
-- 
1.6.4.2


^ permalink raw reply related	[flat|nested] 26+ messages in thread
end of thread, other threads:[~2010-02-10 17:22 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-05 22:48 [PATCH 1/12] tm6000: add Terratec Cinergy Hybrid XE stefan.ringel
2010-02-05 22:48 ` [PATCH 2/12] tm6000: avoid unregister the driver after success at tm6000_init_dev stefan.ringel
2010-02-05 22:48   ` [PATCH 3/12] tm6000: clean the identifer string stefan.ringel
2010-02-05 22:48     ` [PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer stefan.ringel
2010-02-05 22:48       ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 stefan.ringel
2010-02-05 22:48         ` [PATCH 7/12] tm6000: add tuner callback for dvb frontend stefan.ringel
2010-02-05 22:48           ` [PATCH 8/12] tm6000: add tuner parameter stefan.ringel
2010-02-05 22:48             ` [PATCH 9/12] tm6000: remove unused function stefan.ringel
2010-02-05 22:48               ` [PATCH 10/12] tm6000: bugfix usb DVB transfer stefan.ringel
2010-02-05 22:48                 ` [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift stefan.ringel
2010-02-05 22:48                   ` [PATCH 12/12] tm6000: add a different set param values stefan.ringel
2010-02-08 11:21         ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Mauro Carvalho Chehab
2010-02-08 11:37           ` Mauro Carvalho Chehab
2010-02-08 16:12             ` Stefan Ringel
2010-02-08 17:29               ` Mauro Carvalho Chehab
2010-02-08 17:34                 ` Stefan Ringel
2010-02-08 17:37                   ` Stefan Ringel
2010-02-08 17:51                     ` Mauro Carvalho Chehab
2010-02-08 17:30           ` Stefan Ringel
2010-02-08 18:14             ` Mauro Carvalho Chehab
2010-02-08 19:07               ` Stefan Ringel
2010-02-08 19:17                 ` Mauro Carvalho Chehab
2010-02-08 20:04                   ` zl10335 with tm6010 or tm6000 Stefan Ringel
2010-02-10 17:09           ` [PATCH 5/12] tm6000: update init table and sequence for tm6010 Stefan Ringel
2010-02-10 17:21             ` Mauro Carvalho Chehab
2010-02-05 22:57 [PATCH 1/12] tm6000: add Terratec Cinergy Hybrid XE stefan.ringel
2010-02-05 22:57 ` [PATCH 2/12] tm6000: avoid unregister the driver after success at tm6000_init_dev stefan.ringel
2010-02-05 22:57   ` [PATCH 3/12] tm6000: clean the identifer string stefan.ringel
2010-02-05 22:57     ` [PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer stefan.ringel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.