Fw: tm6000 driver questions
- Message Transféré - Date: Wed, 25 Apr 2012 10:16:57 -0700 De: Vladimir Kerkez À: castet.matth...@free.fr Sujet: tm6000 driver questions > Hello, > > I would like to thank you for your outstanding work on the tm6000 > chipset. Because of you (and many other people) I now have a pal tv > tuner I can use. > > I just recently bought a mac book pro, how ever most of the drivers > were not supported under the 3.2 kernel. I pulled down the latestest > drivers for my Hauppauge 900H from linux tv (tm6000 edition). > > I read the your patch changes that you have made here: > http://patchwork.linuxtv.org/patch/8968/ > > One of the first things I noticed is that the firmware for the tm6000 > loads about 10-12 seconds faster, my tvtime starting at a normal > speed ( it used to take up to 20 seconds to load ). Im assuming this > is something you may have patched? If you did thanks so much! > > However I am now running into a issue I never saw before with my > tm6000 tuner. I noticed that in this new version of the driver the > channel switching is a lot faster, but it seems to be causing kernel > panics. I believe the issues is that the channel switches so fast > before the tuner gets a signal causing the kernel panic (the usb gets > bad data and throws and emi). This always happens when the channel > is changed. > > Here is a snippet of the kernel panic: > > [ 4760.587553] xc2028 14-0061: xc2028_get_reg 0004 called > [ 4760.591160] xc2028 14-0061: xc2028_get_reg 0008 called > *[ 4760.633815] hub 2-0:1.0: port 4 disabled by hub (EMI?), > re-enabling...* [ 4760.633827] usb 2-4: USB disconnect, device number > 3 [ 4760.637748] xc2028 14-0061: Device is Xceive 0 version 2.0, > firmware version 3.6 > [ 4760.637756] xc2028 14-0061: Read invalid device hardware > information - tuner hung? > [ 4760.650641] tm6000: IR URB failure: status: -71, length 0 > > Have you seen this issue? I would love to fix this and commit it to > linux tv but, im still uncertain as to what changes need to be made. > The drivers that do come with the 3.2 kernel work fine but however > the firmware loading is taking forever (stable though when it is > running). > > Any information you may have to help me out here would be much > appreciated. I am not working this weekend and was looking forward to > take a peak at the driver. I'll let you know where I stand with this > next week. > > thank you so much for your hard work, > > -Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000 : improve loading speed on hauppauge 900H
- enable fast usb quirk
- use usleep_range instead on msleep for short sleep
- merge i2c out and usb delay
- do like the windows driver that upload the tuner firmware with 80 bytes
packets
Signed-off-by: Matthieu CASTET
CC: Thierry Reding
---
drivers/media/video/tm6000/tm6000-cards.c |2 ++
drivers/media/video/tm6000/tm6000-core.c | 16 ++--
drivers/media/video/tm6000/tm6000-i2c.c |8 +---
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-cards.c
b/drivers/media/video/tm6000/tm6000-cards.c
index 6b74259..3678918 100644
--- a/drivers/media/video/tm6000/tm6000-cards.c
+++ b/drivers/media/video/tm6000/tm6000-cards.c
@@ -943,6 +943,7 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
case TM6010_BOARD_HAUPPAUGE_900H:
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
case TM6010_BOARD_TWINHAN_TU501:
+ ctl.max_len = 80;
ctl.fname = "xc3028L-v36.fw";
break;
default:
@@ -1004,6 +1005,7 @@ static int fill_board_specific_data(struct tm6000_core
*dev)
/* setup per-model quirks */
switch (dev->model) {
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+ case TM6010_BOARD_HAUPPAUGE_900H:
dev->quirks |= TM6000_QUIRK_NO_USB_DELAY;
break;
diff --git a/drivers/media/video/tm6000/tm6000-core.c
b/drivers/media/video/tm6000/tm6000-core.c
index 979c85b..22cc011 100644
--- a/drivers/media/video/tm6000/tm6000-core.c
+++ b/drivers/media/video/tm6000/tm6000-core.c
@@ -38,6 +38,7 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
int ret, i;
unsigned int pipe;
u8 *data = NULL;
+ int delay = 5000;
mutex_lock(&dev->usb_lock);
@@ -89,8 +90,19 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
kfree(data);
- if ((dev->quirks & TM6000_QUIRK_NO_USB_DELAY) == 0)
- msleep(5);
+ if (dev->quirks & TM6000_QUIRK_NO_USB_DELAY)
+ delay = 0;
+
+ if (req == REQ_16_SET_GET_I2C_WR1_RDN && !(req_type & USB_DIR_IN)) {
+ unsigned int tsleep;
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = (len * 200) + 200;
+ if (tsleep < delay)
+ tsleep = delay;
+ usleep_range(tsleep, tsleep + 1000);
+ }
+ else if (delay)
+ usleep_range(delay, delay + 1000);
mutex_unlock(&dev->usb_lock);
return ret;
diff --git a/drivers/media/video/tm6000/tm6000-i2c.c
b/drivers/media/video/tm6000/tm6000-i2c.c
index 0290bbf..c7e23e3 100644
--- a/drivers/media/video/tm6000/tm6000-i2c.c
+++ b/drivers/media/video/tm6000/tm6000-i2c.c
@@ -46,11 +46,10 @@ static int tm6000_i2c_send_regs(struct tm6000_core *dev,
unsigned char addr,
__u8 reg, char *buf, int len)
{
int rc;
- unsigned int tsleep;
unsigned int i2c_packet_limit = 16;
if (dev->dev_type == TM6010)
- i2c_packet_limit = 64;
+ i2c_packet_limit = 80;
if (!buf)
return -1;
@@ -71,10 +70,6 @@ static int tm6000_i2c_send_regs(struct tm6000_core *dev,
unsigned char addr,
return rc;
}
- /* Calculate delay time, 14000us for 64 bytes */
- tsleep = ((len * 200) + 200 + 1000) / 1000;
- msleep(tsleep);
-
/* release mutex */
return rc;
}
@@ -145,7 +140,6 @@ static int tm6000_i2c_recv_regs16(struct tm6000_core *dev,
unsigned char addr,
return rc;
}
- msleep(1400 / 1000);
rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
reg, 0, buf, len);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000 : dvb doesn't work on usb1.1
Signed-off-by: Matthieu CASTET
---
drivers/staging/tm6000/tm6000-dvb.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-dvb.c
b/drivers/staging/tm6000/tm6000-dvb.c
index 8f2a50b..cbecb7d 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -396,6 +396,11 @@ static int dvb_init(struct tm6000_core *dev)
if (!dev->caps.has_dvb)
return 0;
+ if (dev->udev->speed == USB_SPEED_FULL) {
+ printk(KERN_INFO "This USB2.0 device cannot be run on a USB1.1
port. (it lacks a hardware PID filter)\n");
+ return 0;
+ }
+
dvb = kzalloc(sizeof(struct tm6000_dvb), GFP_KERNEL);
if (!dvb) {
printk(KERN_INFO "Cannot allocate memory\n");
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000 : improve loading speed on hauppauge 900H
- enable fast usb quirk
- use usleep_range instead on msleep for short sleep
- merge i2c out and usb delay
- do like the windows driver that upload the tuner firmware with 80 bytes
packets
Signed-off-by: Matthieu CASTET
CC: Thierry Reding
---
drivers/staging/tm6000/tm6000-cards.c |2 ++
drivers/staging/tm6000/tm6000-core.c | 16 +++-
drivers/staging/tm6000/tm6000-i2c.c |8 +---
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index ec2578a..2136fa9 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -941,6 +941,7 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
case TM6010_BOARD_HAUPPAUGE_900H:
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
case TM6010_BOARD_TWINHAN_TU501:
+ ctl.max_len = 80;
ctl.fname = "xc3028L-v36.fw";
break;
default:
@@ -1002,6 +1003,7 @@ static int fill_board_specific_data(struct tm6000_core
*dev)
/* setup per-model quirks */
switch (dev->model) {
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+ case TM6010_BOARD_HAUPPAUGE_900H:
dev->quirks |= TM6000_QUIRK_NO_USB_DELAY;
break;
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 6d0803c..c559f9f 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -38,6 +38,7 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
int ret, i;
unsigned int pipe;
u8 *data = NULL;
+ int delay = 5000;
mutex_lock(&dev->usb_lock);
@@ -88,7 +89,20 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
}
kfree(data);
- msleep(5);
+
+ if (dev->quirks & TM6000_QUIRK_NO_USB_DELAY)
+ delay = 0;
+
+ if (req == REQ_16_SET_GET_I2C_WR1_RDN && !(req_type & USB_DIR_IN)) {
+ unsigned int tsleep;
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = (len * 200) + 200;
+ if (tsleep < delay)
+ tsleep = delay;
+ usleep_range(tsleep, tsleep + 1000);
+ }
+ else if (delay)
+ usleep_range(delay, delay + 1000);
mutex_unlock(&dev->usb_lock);
return ret;
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 76a8e3a..8809ed1 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -46,11 +46,10 @@ static int tm6000_i2c_send_regs(struct tm6000_core *dev,
unsigned char addr,
__u8 reg, char *buf, int len)
{
int rc;
- unsigned int tsleep;
unsigned int i2c_packet_limit = 16;
if (dev->dev_type == TM6010)
- i2c_packet_limit = 64;
+ i2c_packet_limit = 80;
if (!buf)
return -1;
@@ -71,10 +70,6 @@ static int tm6000_i2c_send_regs(struct tm6000_core *dev,
unsigned char addr,
return rc;
}
- /* Calculate delay time, 14000us for 64 bytes */
- tsleep = ((len * 200) + 200 + 1000) / 1000;
- msleep(tsleep);
-
/* release mutex */
return rc;
}
@@ -145,7 +140,6 @@ static int tm6000_i2c_recv_regs16(struct tm6000_core *dev,
unsigned char addr,
return rc;
}
- msleep(1400 / 1000);
rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
reg, 0, buf, len);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: add dvb-t fr-All frequency
Le Wed, 16 Mar 2011 16:46:38 +0100, Christoph Pfister a écrit : > 2011/3/15 matthieu castet : > > Hi, > > > > can this file be added to dvb-apps/util/scan/dvb-t > > No. Use "auto-Normal" [1] (or the +-167kHz file if needed). > Ok, thanks I wasn't aware of the auto files. How does the offset version works ? The scan tools is clever enough to not duplicate freq, freq-offset, freq+offset and choose the one with best signal ? BTW in theory in France, offset can be : - 0,166 MHz /+ 0,166 MHz /+ 0,332 MHz /+ 0,498 MHz. Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
add dvb-t fr-All frequency
Hi, can this file be added to dvb-apps/util/scan/dvb-t Thanks Matthieu #http://tvignaud.pagesperso-orange.fr/ T 47400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 48200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 49000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 49800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 50600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 51400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 52200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 53000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 53800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 54600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 55400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 56200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 57000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 57800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 58600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 59400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 60200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 61000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 61800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 62600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 63400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 64200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 65000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 65800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 66600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 67400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 68200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 69000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 69800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 70600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 71400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 72200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 73000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 73800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 74600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 75400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 76200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 77000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 77800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 78600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 79400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 80200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 81000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 81800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 82600 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 83400 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 84200 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 85000 8MHz AUTO AUTO QAM64 AUTO AUTO NONE T 85800 8MHz AUTO AUTO QAM64 AUTO AUTO NONE
Re: [PATCH] fix dvb frontend lockup
matthieu castet a écrit :
Hi,
With my current kernel (2.6.32), if my dvb device is removed while in use, I
got [1].
After checking the source code, the problem seems to happen also in master :
If there are users (for example users == -2) :
- dvb_unregister_frontend :
- stop kernel thread with dvb_frontend_stop :
- fepriv->exit = 1;
- thread loop catch stop event and break while loop
- fepriv->thread = NULL; and fepriv->exit = 0;
- dvb_unregister_frontend wait on "fepriv->dvbdev->wait_queue" that
fepriv->dvbdev->users==-1.
The user finish :
- dvb_frontend_release - set users to -1
- don't wait wait_queue because fepriv->exit != 1
=> dvb_unregister_frontend never exit the wait queue.
Matthieu
[ 4920.484047] khubd D c2008000 0 198 2 0x
[ 4920.484056] f64c8000 0046 c2008000 0004 c13fa000 c13fa000 f
64c8000
[ 4920.484066] f64c81bc c2008000 d9d9dce6 0452 0001 f64c8000 c
102daad
[ 4920.484075] 00100100 f64c81bc 0286 f0a7ccc0 f0913404 f0cba404 f644de58 f
092b0a8
[ 4920.484084] Call Trace:
[ 4920.484102] [] ? default_wake_function+0x0/0x8
[ 4920.484147] [] ? dvb_unregister_frontend+0x95/0xcc [dvb_core]
[ 4920.484157] [] ? autoremove_wake_function+0x0/0x2d
[ 4920.484168] [] ? dvb_usb_adapter_frontend_exit+0x12/0x21 [dvb_usb]
[ 4920.484176] [] ? dvb_usb_exit+0x26/0x88 [dvb_usb]
[ 4920.484184] [] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb]
[ 4920.484217] [] ? usb_unbind_interface+0x3f/0xb4 [usbcore]
[ 4920.484227] [] ? __device_release_driver+0x74/0xb7
[ 4920.484233] [] ? device_release_driver+0x15/0x1e
[ 4920.484243] [] ? bus_remove_device+0x6e/0x87
[ 4920.484249] [] ? device_del+0xfa/0x152
[ 4920.484264] [] ? usb_disable_device+0x59/0xb9 [usbcore]
[ 4920.484279] [] ? usb_disconnect+0x70/0xdc [usbcore]
[ 4920.484294] [] ? hub_thread+0x521/0xe1d [usbcore]
[ 4920.484301] [] ? autoremove_wake_function+0x0/0x2d
[ 4920.484316] [] ? hub_thread+0x0/0xe1d [usbcore]
[ 4920.484321] [] ? kthread+0x61/0x66
[ 4920.484327] [] ? kthread+0x0/0x66
[ 4920.484336] [] ? kernel_thread_helper+0x7/0x10
Here a patch that fix the issue
Signed-off-by: Matthieu CASTET
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 55ea260..6932def 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -95,6 +95,10 @@ MODULE_PARM_DESC(dvb_mfe_wait_time, "Wait up to seconds on open(
* FESTATE_LOSTLOCK. When the lock has been lost, and we're searching it again.
*/
+#define DVB_FE_NO_EXIT 0
+#define DVB_FE_NORMAL_EXIT 1
+#define DVB_FE_DEVICE_REMOVED 2
+
static DEFINE_MUTEX(frontend_mutex);
struct dvb_frontend_private {
@@ -497,7 +501,7 @@ static int dvb_frontend_is_exiting(struct dvb_frontend *fe)
{
struct dvb_frontend_private *fepriv = fe->frontend_priv;
- if (fepriv->exit)
+ if (fepriv->exit != DVB_FE_NO_EXIT)
return 1;
if (fepriv->dvbdev->writers == 1)
@@ -559,7 +563,7 @@ restart:
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
- fepriv->exit = 1;
+ fepriv->exit = DVB_FE_NORMAL_EXIT;
break;
}
@@ -673,7 +677,10 @@ restart:
}
fepriv->thread = NULL;
- fepriv->exit = 0;
+ if (kthread_should_stop())
+ fepriv->exit = DVB_FE_DEVICE_REMOVED;
+ else
+ fepriv->exit = DVB_FE_NO_EXIT;
mb();
dvb_frontend_wakeup(fe);
@@ -686,7 +693,7 @@ static void dvb_frontend_stop(struct dvb_frontend *fe)
dprintk ("%s\n", __func__);
- fepriv->exit = 1;
+ fepriv->exit = DVB_FE_NORMAL_EXIT;
mb();
if (!fepriv->thread)
@@ -755,7 +762,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
dprintk ("%s\n", __func__);
if (fepriv->thread) {
- if (!fepriv->exit)
+ if (fepriv->exit == DVB_FE_NO_EXIT)
return 0;
else
dvb_frontend_stop (fe);
@@ -767,7 +774,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
return -EINTR;
fepriv->state = FESTATE_IDLE;
- fepriv->exit = 0;
+ fepriv->exit = DVB_FE_NO_EXIT;
fepriv->thread = NULL;
mb();
@@ -1490,7 +1497,7 @@ static int dvb_frontend_ioctl(struct inode *inode, struct file *file,
dprintk("%s (%d)\n", __func__, _IOC_NR(cmd));
- if (fepriv->exit)
+ if (fepriv->exit != DVB_FE_NO_EXIT)
return -ENODEV;
if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
@@ -1916,6 +1923,8 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)
int ret;
dprintk ("%s\n", __func__);
+ if (fepriv->exit == DVB_FE_DEVICE_REMOVED)
+ return -ENODEV;
if (adapter->mfe_shared) {
mutex_lock (&adapter->mfe_lock);
@@ -2008,7 +2017,7 @@ static int dvb_frontend_release(struct inode *inode, struct file *file)
ret = dvb_generic_release (inode, file);
if (dvbdev->users == -1) {
- if (fepriv->exit == 1) {
+ if (fepriv->exit != DVB_FE_NO_EXIT) {
fops_put(file->f_op);
file->f_op = NULL;
wake_up(&dvbdev->wait_queue);
Re: [PATCH] fix dvb frontend lockup
matthieu castet a écrit : matthieu castet a écrit : Hi, With my current kernel (2.6.32), if my dvb device is removed while in use, I got [1]. After checking the source code, the problem seems to happen also in master : If there are users (for example users == -2) : - dvb_unregister_frontend : - stop kernel thread with dvb_frontend_stop : - fepriv->exit = 1; - thread loop catch stop event and break while loop - fepriv->thread = NULL; and fepriv->exit = 0; - dvb_unregister_frontend wait on "fepriv->dvbdev->wait_queue" that fepriv->dvbdev->users==-1. The user finish : - dvb_frontend_release - set users to -1 - don't wait wait_queue because fepriv->exit != 1 => dvb_unregister_frontend never exit the wait queue. Matthieu [ 4920.484047] khubd D c2008000 0 198 2 0x [ 4920.484056] f64c8000 0046 c2008000 0004 c13fa000 c13fa000 f 64c8000 [ 4920.484066] f64c81bc c2008000 d9d9dce6 0452 0001 f64c8000 c 102daad [ 4920.484075] 00100100 f64c81bc 0286 f0a7ccc0 f0913404 f0cba404 f644de58 f 092b0a8 [ 4920.484084] Call Trace: [ 4920.484102] [] ? default_wake_function+0x0/0x8 [ 4920.484147] [] ? dvb_unregister_frontend+0x95/0xcc [dvb_core] [ 4920.484157] [] ? autoremove_wake_function+0x0/0x2d [ 4920.484168] [] ? dvb_usb_adapter_frontend_exit+0x12/0x21 [dvb_usb] [ 4920.484176] [] ? dvb_usb_exit+0x26/0x88 [dvb_usb] [ 4920.484184] [] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb] [ 4920.484217] [] ? usb_unbind_interface+0x3f/0xb4 [usbcore] [ 4920.484227] [] ? __device_release_driver+0x74/0xb7 [ 4920.484233] [] ? device_release_driver+0x15/0x1e [ 4920.484243] [] ? bus_remove_device+0x6e/0x87 [ 4920.484249] [] ? device_del+0xfa/0x152 [ 4920.484264] [] ? usb_disable_device+0x59/0xb9 [usbcore] [ 4920.484279] [] ? usb_disconnect+0x70/0xdc [usbcore] [ 4920.484294] [] ? hub_thread+0x521/0xe1d [usbcore] [ 4920.484301] [] ? autoremove_wake_function+0x0/0x2d [ 4920.484316] [] ? hub_thread+0x0/0xe1d [usbcore] [ 4920.484321] [] ? kthread+0x61/0x66 [ 4920.484327] [] ? kthread+0x0/0x66 [ 4920.484336] [] ? kernel_thread_helper+0x7/0x10 Here a patch that fix the issue Signed-off-by: Matthieu CASTET Any news on that -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix dvb frontend lockup
matthieu castet a écrit :
Hi,
With my current kernel (2.6.32), if my dvb device is removed while in
use, I got [1].
After checking the source code, the problem seems to happen also in
master :
If there are users (for example users == -2) :
- dvb_unregister_frontend :
- stop kernel thread with dvb_frontend_stop :
- fepriv->exit = 1;
- thread loop catch stop event and break while loop
- fepriv->thread = NULL; and fepriv->exit = 0;
- dvb_unregister_frontend wait on "fepriv->dvbdev->wait_queue" that
fepriv->dvbdev->users==-1.
The user finish :
- dvb_frontend_release - set users to -1
- don't wait wait_queue because fepriv->exit != 1
=> dvb_unregister_frontend never exit the wait queue.
Matthieu
[ 4920.484047] khubd D c2008000 0 198 2 0x
[ 4920.484056] f64c8000 0046 c2008000 0004 c13fa000
c13fa000 f
64c8000
[ 4920.484066] f64c81bc c2008000 d9d9dce6 0452 0001
f64c8000 c
102daad
[ 4920.484075] 00100100 f64c81bc 0286 f0a7ccc0 f0913404 f0cba404
f644de58 f
092b0a8
[ 4920.484084] Call Trace:
[ 4920.484102] [] ? default_wake_function+0x0/0x8
[ 4920.484147] [] ? dvb_unregister_frontend+0x95/0xcc [dvb_core]
[ 4920.484157] [] ? autoremove_wake_function+0x0/0x2d
[ 4920.484168] [] ? dvb_usb_adapter_frontend_exit+0x12/0x21
[dvb_usb]
[ 4920.484176] [] ? dvb_usb_exit+0x26/0x88 [dvb_usb]
[ 4920.484184] [] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb]
[ 4920.484217] [] ? usb_unbind_interface+0x3f/0xb4 [usbcore]
[ 4920.484227] [] ? __device_release_driver+0x74/0xb7
[ 4920.484233] [] ? device_release_driver+0x15/0x1e
[ 4920.484243] [] ? bus_remove_device+0x6e/0x87
[ 4920.484249] [] ? device_del+0xfa/0x152
[ 4920.484264] [] ? usb_disable_device+0x59/0xb9 [usbcore]
[ 4920.484279] [] ? usb_disconnect+0x70/0xdc [usbcore]
[ 4920.484294] [] ? hub_thread+0x521/0xe1d [usbcore]
[ 4920.484301] [] ? autoremove_wake_function+0x0/0x2d
[ 4920.484316] [] ? hub_thread+0x0/0xe1d [usbcore]
[ 4920.484321] [] ? kthread+0x61/0x66
[ 4920.484327] [] ? kthread+0x0/0x66
[ 4920.484336] [] ? kernel_thread_helper+0x7/0x10
Here a patch that fix the issue
Signed-off-by: Matthieu CASTET
--- 1/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2010-03-27 22:59:50.0 +0100
+++ 2/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2010-03-27 23:01:34.0 +0100
@@ -686,7 +686,10 @@
}
fepriv->thread = NULL;
- fepriv->exit = 0;
+ if (kthread_should_stop())
+ fepriv->exit = 2;
+ else
+ fepriv->exit = 0;
mb();
dvb_frontend_wakeup(fe);
@@ -1929,6 +1932,8 @@
int ret;
dprintk ("%s\n", __func__);
+ if (fepriv->exit == 2)
+ return -ENODEV;
if (adapter->mfe_shared) {
mutex_lock (&adapter->mfe_lock);
@@ -2021,7 +2026,7 @@
ret = dvb_generic_release (inode, file);
if (dvbdev->users == -1) {
- if (fepriv->exit == 1) {
+ if (fepriv->exit) {
fops_put(file->f_op);
file->f_op = NULL;
wake_up(&dvbdev->wait_queue);
i2c interface bugs in dvb drivers
Hi,
some dvb driver that export a i2c interface contains some mistakes because they
mainly used by driver (frontend, tuner) wrote for them.
But the i2c interface is exposed to everybody.
One mistake is expect msg[i].addr with 8 bits address instead of 7 bits
address. This make them use eeprom address at 0xa0 instead of 0x50. Also they
shift tuner address (qt1010 tuner is likely to be at address 0x62, but some put
it a 0xc4 (af9015, af9005, dtv5100)).
Other mistakes is in xfer callback. Often the controller support a limited i2c
support (n bytes write then m bytes read). The driver try to convert the linux
i2c msg to this pattern, but they often miss cases :
- msg[i].len can be null
- msg write are not always followed by msg read
And this can be dangerous if these interfaces are exported to userspace via
i2c-dev :
- some scanning program avoid eeprom by filtering 0x5x range, but now it is at
0xax range (well that should happen because scan limit should be 0x77)
- some read only command can be interpreted as write command.
What should be done ?
Fix the drivers.
Have a mode where i2c interface are not exported to everybody.
Don't care.
First why does the i2c stack doesn't check that the address is on 7 bits (like
the attached patch) ?
Also I believe a program for testing i2c interface corner case should catch
most of these bugs :
- null msg[i].len
- different transactions on a device :
- one write/read transaction
- one write transaction then one read transaction
[...]
Does a such program exist ?
Matthieu
PS : please keep me in CC
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 3202a86..91e63ea 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1150,6 +1150,17 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
(msgs[ret].flags & I2C_M_RECV_LEN) ? "+" : "");
}
#endif
+ for (ret = 0; ret < num; ret++) {
+ if (msgs[ret].flags & I2C_M_TEN) {
+/* XXX what"s I2C_M_TEN range */
+if (msgs[ret].addr < 0x03 || msgs[ret].addr > 0x377)
+ return -EINVAL;
+ }
+ else {
+if (msgs[ret].addr < 0x03 || msgs[ret].addr > 0x77)
+ return -EINVAL;
+ }
+ }
if (in_atomic() || irqs_disabled()) {
ret = rt_mutex_trylock(&adap->bus_lock);
dvb frontend lockup
Hi, With my current kernel (2.6.32), if my dvb device is removed while in use, I got [1]. After checking the source code, the problem seems to happen also in master : If there are users (for example users == -2) : - dvb_unregister_frontend : - stop kernel thread with dvb_frontend_stop : - fepriv->exit = 1; - thread loop catch stop event and break while loop - fepriv->thread = NULL; and fepriv->exit = 0; - dvb_unregister_frontend wait on "fepriv->dvbdev->wait_queue" that fepriv->dvbdev->users==-1. The user finish : - dvb_frontend_release - set users to -1 - don't wait wait_queue because fepriv->exit != 1 => dvb_unregister_frontend never exit the wait queue. Matthieu [ 4920.484047] khubd D c2008000 0 198 2 0x [ 4920.484056] f64c8000 0046 c2008000 0004 c13fa000 c13fa000 f 64c8000 [ 4920.484066] f64c81bc c2008000 d9d9dce6 0452 0001 f64c8000 c 102daad [ 4920.484075] 00100100 f64c81bc 0286 f0a7ccc0 f0913404 f0cba404 f644de58 f 092b0a8 [ 4920.484084] Call Trace: [ 4920.484102] [] ? default_wake_function+0x0/0x8 [ 4920.484147] [] ? dvb_unregister_frontend+0x95/0xcc [dvb_core] [ 4920.484157] [] ? autoremove_wake_function+0x0/0x2d [ 4920.484168] [] ? dvb_usb_adapter_frontend_exit+0x12/0x21 [dvb_usb] [ 4920.484176] [] ? dvb_usb_exit+0x26/0x88 [dvb_usb] [ 4920.484184] [] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb] [ 4920.484217] [] ? usb_unbind_interface+0x3f/0xb4 [usbcore] [ 4920.484227] [] ? __device_release_driver+0x74/0xb7 [ 4920.484233] [] ? device_release_driver+0x15/0x1e [ 4920.484243] [] ? bus_remove_device+0x6e/0x87 [ 4920.484249] [] ? device_del+0xfa/0x152 [ 4920.484264] [] ? usb_disable_device+0x59/0xb9 [usbcore] [ 4920.484279] [] ? usb_disconnect+0x70/0xdc [usbcore] [ 4920.484294] [] ? hub_thread+0x521/0xe1d [usbcore] [ 4920.484301] [] ? autoremove_wake_function+0x0/0x2d [ 4920.484316] [] ? hub_thread+0x0/0xe1d [usbcore] [ 4920.484321] [] ? kthread+0x61/0x66 [ 4920.484327] [] ? kthread+0x0/0x66 [ 4920.484336] [] ? kernel_thread_helper+0x7/0x10 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] af9015 : more robust eeprom parsing
the af9015 eeprom parsing accept 0x38 as 2nd demodulator. But this is
impossible because the
first one is already hardcoded to 0x38.
This remove a special case for AverMedia AVerTV Volar Black HD.
Also in af9015_copy_firmware don't hardcode the 2nd demodulator address to 0x3a.
Signed-off-by: Matthieu CASTET
diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
index d797538..f93767e 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -493,7 +493,7 @@ static int af9015_copy_firmware(struct dvb_usb_device *d)
/* wait 2nd demodulator ready */
msleep(100);
- ret = af9015_read_reg_i2c(d, 0x3a, 0x98be, &val);
+ ret = af9015_read_reg_i2c(d, af9015_af9013_config[1].demod_address, 0x98be, &val);
if (ret)
goto error;
else
@@ -913,8 +913,13 @@ static int af9015_read_config(struct usb_device *udev)
ret = af9015_rw_udev(udev, &req);
if (ret)
goto error;
- af9015_af9013_config[1].demod_address = val;
+ if (val != AF9015_I2C_DEMOD)
+ af9015_af9013_config[1].demod_address = val;
+ else
+ af9015_config.dual_mode = 0;
+ }
+ if (af9015_config.dual_mode) {
/* enable 2nd adapter */
for (i = 0; i < af9015_properties_count; i++)
af9015_properties[i].num_adapters = 2;
@@ -1023,11 +1028,6 @@ error:
if (le16_to_cpu(udev->descriptor.idVendor) == USB_VID_AVERMEDIA &&
le16_to_cpu(udev->descriptor.idProduct) == USB_PID_AVERMEDIA_A850) {
deb_info("%s: AverMedia A850: overriding config\n", __func__);
- /* disable dual mode */
- af9015_config.dual_mode = 0;
- /* disable 2nd adapter */
- for (i = 0; i < af9015_properties_count; i++)
- af9015_properties[i].num_adapters = 1;
/* set correct IF */
af9015_af9013_config[0].tuner_if = 4570;
videobuf cached user mapping
Hi, Is that possible to have user mapping cached in Memory Mapping mode ? This means buffer allocated by mmap in userspace, will have cache support, and it will be faster to work on it. But how the cache coherency can be done ? For a camera we should : - invalidate cache before dma operation (to have not old buffer data in the cache) - forbid the user to access the buffer during the dma operation (to not pollute the cache) Is it possible ? How can we achieve that ? I see sync method, that seems only called after frame capture ? Or user "User Pointers" is the solution ? But they should have the same problems. Is there some documentation of how "user pointer" are synchronised with dma ? Thanks, Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
videobuf-dma-contig.c cached user mapping
Hi, I would like to add support for cached user mapping to videobuf-dma-contig.c. For enabling this, "vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);" line should be removed. But now we should ensure user mapping cache coherency. For that, for a camera we should : - invalidate cache before dma operation (to have not old buffer data in the cache) - forbid the user to access the buffer during the dma operation (to not pollute the cache) Is it possible ? How can we achieve that ? I see sync method, that seems only called after frame capture ? Thanks, Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tm6010 status
Hi, Dênis Goes wrote: Hi Matthieu... I made the same answer yesterday... I want to help in development for use my PixelView 405 USB. Do you have the correct tridvid.sys file to extract the firmware ? No, I took the firmware (for the tuner) somewhere on internet. Some time ago I have done some usb sniffing on Windows for my HVR900H, study the linux driver and start some analysis [2]. I found some strange thing on i2c bus [1]. Then I figure out what should be done to make work the digital part. But because of lack of time and motivation (like everybody ;) ), I stopped working on this. Matthieu [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg00987.html [2] == i2c == 0x1f zl 0xa0 eeprom 0xa2 ??? (0xff) 0xa4 0xa6->0xac ??? (0xff) 0xae 0xc2 (tuner) == gpio == 0 (WP eeprom ?? ) 1 ZL RESET 2 tuner_reset_gpio 4 input sel ??? 5 (led green) 7 (led blue) == eeprom format == 0x0-0x3 : magic ??? 0x4-0x15 : GetDescriptor device 0xc VID 0xE PID 0x10 DID 0x12 iManufacturer 0x13 Product string 0x14 SerialNumber 0x40 string size (10 03) ??? 0x42-0x4f (Product string @32) 0x94 string size (16 03) 0x96-0xa9 (SerialNumber @64) 0x16 string size (02 03) 0x18- (iManufacturer @16) 0x60 : iConfiguration index ??? 0x6a string size (0a 03) 0x6c (iConfiguration @48) where is mac address and rev ??? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tm6010 status
Hi, what's the status of tm6010 support ? http://www.mail-archive.com/linux-media@vger.kernel.org/msg04048.html announced some patches, but nothing seems to have happened ? Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
Laurent Pinchart a écrit : > On Thursday 06 August 2009 20:46:14 David Xiao wrote: > > Think about the simple following use case. An application wants to display > video it acquires from the device to the screen using Xv. The video buffer is > allocated by Xv. Using the v4l2 user pointer streaming method, the device can > DMA directly to the Xv buffer. Using driver-allocated buffers, a memcpy() is > required between the v4l2 buffer and the Xv buffer. > v4l2 got an API (overlay IRRC) that allow drivers to write directly in framebuffer memory. BTW Xv buffer is not always in video memory and the X driver can do a memcpy. Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DIBUSB_MC : fix i2c to not corrupt eeprom in case of strange read pattern
Hi,
dibusb_i2c_xfer seems to do things very dangerous :
it assumes that it get only write/read request or write request.
That means that read can be understood as write. For example a program
doing
file = open("/dev/i2c-x", O_RDWR);
ioctl(file, I2C_SLAVE, 0x50)
read(file, data, 10)
will corrupt the eeprom as it will be understood as a write.
I attach a possible (untested) patch.
Matthieu
Signed-off-by: Matthieu CASTET
Signed-off-by: Matthieu CASTET
Index: linux-2.6/drivers/media/dvb/dvb-usb/dibusb-common.c
===
--- linux-2.6.orig/drivers/media/dvb/dvb-usb/dibusb-common.c2009-02-09
20:36:03.0 +0100
+++ linux-2.6/drivers/media/dvb/dvb-usb/dibusb-common.c 2009-02-09
20:38:21.0 +0100
@@ -133,14 +133,18 @@
for (i = 0; i < num; i++) {
/* write/read request */
- if (i+1 < num && (msg[i+1].flags & I2C_M_RD)) {
+ if (i+1 < num && (msg[i].flags & I2C_M_RD) == 0
+ && (msg[i+1].flags & I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len) < 0)
break;
i++;
- } else
+ } else if ((msg[i].flags & I2C_M_RD) == 0) {
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,NULL,0) < 0)
break;
+ }
+ else
+ break;
}
mutex_unlock(&d->i2c_mutex);
Re: [PATCH] videobuf-dma-contig: remove sync operation
Paul Mundt a écrit : > On Tue, Apr 28, 2009 at 05:45:39PM +0900, Magnus Damm wrote: >> From: Magnus Damm >> >> Remove the videobuf-dma-contig sync operation. Sync is only needed >> for noncoherent buffers, and since videobuf-dma-contig is built on >> coherent memory allocators the memory is by definition always in sync. >> > Note that this also fixes a bogus oops, which is what caused this to be > brought up in the first place.. > >> Reported-by: Matthieu CASTET >> Signed-off-by: Magnus Damm >> --- >> >> Thanks to Mattieu, Paul and Paulius for all the help! >> Tested on SH7722 Migo-R with CEU and ov7725. >> >> drivers/media/video/videobuf-dma-contig.c | 14 ------ >> 1 file changed, 14 deletions(-) >> > Reviewed-by: Paul Mundt Test-by : Matthieu CASTET Well I backport it on a older kernel (2.6.27), but the result should be the same. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] [PATCH] Support faulty USB IDs on DIBUSB_MC
Devin Heitmueller wrote: On Mon, Feb 9, 2009 at 2:40 PM, matthieu castet wrote: Hi, matthieu castet wrote: matthieu castet wrote: Hi Patrick, Patrick Boettcher wrote: Hi, The assumption that you can only have write/read or write requests is one of the big things fixed in the 1.20 firmware. If you are running the 1.20 firmware, you just need to add the option to use the new i2c function instead of the legacy i2c transfer function. Unfortunamty this is for dib0700 and not dib3000. dib3000 doesn't got new firmware/i2c API. But the same patch should be done for dib0700_i2c_xfer_legacy... Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support faulty USB IDs on DIBUSB_MC
Hi,
matthieu castet wrote:
matthieu castet wrote:
Hi Patrick,
Patrick Boettcher wrote:
Hi,
sorry for not answering ealier, recently I became the master of
postponing things. :(
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote:
+/* 14 */{ USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
It doesn't sound a very good approach the need of recompiling the
driver to
allow it to work with a broken card. The better would be to have
some modprobe
option to force it to accept a certain USB ID as a valid ID for the
card.
The most correct way would be to reprogram the eeprom, by simply
writing to 0xa0 (0x50 << 1) I2C address... There was a thread on the
linux-dvb some time ago.
BTW dibusb_i2c_xfer seems to do things very dangerous :
it assumes that it get only write/read request or write request.
That means that read can be understood as write. For example a program
doing
file = open("/dev/i2c-x", O_RDWR);
ioctl(file, I2C_SLAVE, 0x50)
read(file, data, 10)
will corrupt the eeprom as it will be understood as a write.
Patrick, any info about that.
I attach a possible (untested) patch.
Matthieu
Signed-off-by: Matthieu CASTET
Index: linux-2.6/drivers/media/dvb/dvb-usb/dibusb-common.c
===
--- linux-2.6.orig/drivers/media/dvb/dvb-usb/dibusb-common.c2009-02-09
20:36:03.0 +0100
+++ linux-2.6/drivers/media/dvb/dvb-usb/dibusb-common.c 2009-02-09
20:38:21.0 +0100
@@ -133,14 +133,18 @@
for (i = 0; i < num; i++) {
/* write/read request */
- if (i+1 < num && (msg[i+1].flags & I2C_M_RD)) {
+ if (i+1 < num && (msg[i].flags & I2C_M_RD) == 0
+ && (msg[i+1].flags & I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len) < 0)
break;
i++;
- } else
+ } else if ((msg[i].flags & I2C_M_RD) == 0) {
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,NULL,0) < 0)
break;
+ }
+ else
+ break;
}
mutex_unlock(&d->i2c_mutex);
tm6010 : strange i2c
Hi, I am trying to make work my hauppauge HVR900H, and I start looking at http://linuxtv.org/hg/~mchehab/tm6010/ drivers and windows usb trace. After some experiment I found that the i2c is very strange : * for the zl10353 demodulator, the register read only seems to work if the register address is odd and we read at least 2 bytes[1]. And the windows driver seems to really do that according usb trace (read always 2 bytes at odd address). * the windows driver read the eeprom in the strange way : it use REQ_14_SET_GET_I2C_WR2_RDN, but setting the offset in the high byte of wIndex. And it does 16 bytes read, 1 bytes read for reading again the last 16th byte, and continue 16 bytes read, 1 byte read. Did the people that worked on the tm6000 driver saw that weird i2c ? Matthieu [1] Doing REQ_16_SET_GET_I2C_WR1_RDN on the demodulator with different register address and read size. 0051: 00 -- 0051: 00 -- 0052: 00 -- 0050: 00 -- 004f: 00 -- 0050: 00 -- 0051: 44 46 -- 0051: 44 46 -- 0052: 46 46 -- 0050: 46 46 -- 004f: 46 0c -- 0050: 0c 0c -- 0051: 44 46 15 0f -- 0051: 44 46 15 0f -- 0052: 0f 0f 00 00 -- 0050: 00 00 00 00 -- 004f: 00 0c 44 46 -- 0050: 46 46 00 00 -- 0051: 44 46 15 0f 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 -- 0052: 00 00 00 00 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 -- 004f: 00 0c 44 46 15 0f 00 00 -- 0050: 00 00 00 00 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 -- 0052: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 004f: 00 0c 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d -- 0050: 0d 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 0061: 4d 0a 0f 0f 0f 0f c2 00 00 80 00 00 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 0061: 4d 0a 0f 0f 0f 0f c2 00 00 80 00 00 00 00 00 00 -- 0052: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0062: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 004f: 00 0c 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 005f: 0d 00 4d 0a 0f 0f 0f 0f c2 00 00 80 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support faulty USB IDs on DIBUSB_MC
matthieu castet wrote:
Hi Patrick,
Patrick Boettcher wrote:
Hi,
sorry for not answering ealier, recently I became the master of
postponing things. :(
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote:
+/* 14 */{ USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
It doesn't sound a very good approach the need of recompiling the
driver to
allow it to work with a broken card. The better would be to have some
modprobe
option to force it to accept a certain USB ID as a valid ID for the
card.
The most correct way would be to reprogram the eeprom, by simply
writing to 0xa0 (0x50 << 1) I2C address... There was a thread on the
linux-dvb some time ago.
BTW dibusb_i2c_xfer seems to do things very dangerous :
it assumes that it get only write/read request or write request.
That means that read can be understood as write. For example a program
doing
file = open("/dev/i2c-x", O_RDWR);
ioctl(file, I2C_SLAVE, 0x50)
read(file, data, 10)
will corrupt the eeprom as it will be understood as a write.
Now that I think of that, I run sensors-detect on this machine, may be
this is what trash the eeprom ?
Matthieu
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support faulty USB IDs on DIBUSB_MC
Hi Patrick,
Patrick Boettcher wrote:
Hi,
sorry for not answering ealier, recently I became the master of
postponing things. :(
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote:
+/* 14 */{ USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
It doesn't sound a very good approach the need of recompiling the
driver to
allow it to work with a broken card. The better would be to have some
modprobe
option to force it to accept a certain USB ID as a valid ID for the card.
The most correct way would be to reprogram the eeprom, by simply writing
to 0xa0 (0x50 << 1) I2C address... There was a thread on the linux-dvb
some time ago.
Why not, I only don't want to maintain a patch for my device.
I wonder why didn't they use WP pin of the eeprom to avoid write.
Do you know what should be written.
After a quick search, I found [1]. Is that ok ?
Matthieu
[1]
EEPROM AddressContents
00xC0
1Vendor ID (VID) L
2Vendor ID (VID) H
3Product ID (PID) L
4Product ID (PID) H
5Device ID (DID) L
6Device ID (DID) H
7Configuration byte
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: haupauge remote keycode for av7110_loadkeys
Hi, Mauro Carvalho Chehab wrote: On Mon, 19 Jan 2009 21:35:52 +0100 matthieu castet wrote: Matthieu, You can replace the ir-kbd-i2c keys using the standard input ioctls for it. Take a look at v4l2-apps/util/keycode app. It allows you to read and replace any IR keycodes on the driver that properly implements the event support (including ir-kbd-i2c). great I wasn't aware of this. But this doesn't seem very friendly : all remote keycodes are in kernel. If you want to change the remote, you have to do/provide the keycode for your remote even if it is already in kernel. Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support faulty USB IDs on DIBUSB_MC
matthieu castet wrote:
Hi,
I got a LITE-ON USB2.0 DVB-T Tuner that loose it's cold state vid/pid
and got FX2 dev kit one (0x04b4, 0x8613).
This patch introduce an option similar to the DVB_USB_DIBUSB_MB_FAULTY :
it add the FX2 dev kit ids to the DIBUSB_MC driver if
DVB_USB_DIBUSB_MC_FAULTY is selected.
Signed-off-by: Matthieu CASTET
Ping
diff --git a/drivers/media/dvb/dvb-usb/Kconfig
b/drivers/media/dvb/dvb-usb/Kconfig
index f00a0eb..a656b9b 100644
--- a/drivers/media/dvb/dvb-usb/Kconfig
+++ b/drivers/media/dvb/dvb-usb/Kconfig
@@ -68,6 +68,12 @@ config DVB_USB_DIBUSB_MC
Say Y if you own such a device and want to use it. You should build
it as
a module.
+config DVB_USB_DIBUSB_MC_FAULTY
+ bool "Support faulty USB IDs"
+ depends on DVB_USB_DIBUSB_MC
+ help
+ Support for faulty USB IDs due to an invalid EEPROM on some LITE-ON
devices.
+
config DVB_USB_DIB0700
tristate "DiBcom DiB0700 USB DVB devices (see help for supported
devices)"
depends on DVB_USB
diff --git a/drivers/media/dvb/dvb-usb/dibusb-mc.c
b/drivers/media/dvb/dvb-usb/dibusb-mc.c
index 059cec9..ab5766a 100644
--- a/drivers/media/dvb/dvb-usb/dibusb-mc.c
+++ b/drivers/media/dvb/dvb-usb/dibusb-mc.c
@@ -42,6 +42,17 @@ static struct usb_device_id dibusb_dib3000mc_table [] = {
/* 11 */ { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, USB_PID_ARTEC_T14_WARM)
},
/* 12 */ { USB_DEVICE(USB_VID_LEADTEK,
USB_PID_WINFAST_DTV_DONGLE_COLD) },
/* 13 */ { USB_DEVICE(USB_VID_LEADTEK,
USB_PID_WINFAST_DTV_DONGLE_WARM) },
+/*
+ * XXX: Some LITE-ON devices seem to loose their id after some time. Bad
EEPROM ???.
+ * We don't catch these faulty IDs (namely 'Cypress FX2 USB controller')
that
+ * have been left on the device. If you don't have such a device but an
LITE-ON
+ * device that's supposed to work with this driver but is not detected by
it,
+ * free to enable CONFIG_DVB_USB_DIBUSB_MC_FAULTY via your kernel config.
+ */
+
+#ifdef CONFIG_DVB_USB_DIBUSB_MC_FAULTY
+/* 14 */ { USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, dibusb_dib3000mc_table);
@@ -88,7 +99,11 @@ static struct dvb_usb_device_properties dibusb_mc_properties
= {
.generic_bulk_ctrl_endpoint = 0x01,
+#ifdef CONFIG_DVB_USB_DIBUSB_MC_FAULTY
+ .num_device_descs = 8,
+#else
.num_device_descs = 7,
+#endif
.devices = {
{ "DiBcom USB2.0 DVB-T reference design (MOD3000P)",
{ &dibusb_dib3000mc_table[0], NULL },
@@ -119,6 +134,13 @@ static struct dvb_usb_device_properties
dibusb_mc_properties = {
{ &dibusb_dib3000mc_table[12], NULL },
{ &dibusb_dib3000mc_table[13], NULL },
},
+#ifdef CONFIG_DVB_USB_DIBUSB_MC_FAULTY
+ { "LITE-ON USB2.0 DVB-T Tuner (faulty USB IDs)",
+ /* Also rebranded as Intuix S800, Toshiba */
+ { &dibusb_dib3000mc_table[14], NULL },
+ { NULL },
+ },
+#endif
{ NULL },
}
};
haupauge remote keycode for av7110_loadkeys
Hi, I attached keycodes for http://www.hauppauge.eu/boutique_us/images_produits/111.jpg remote. Can it be added to dvb-apps/util/av7110_loadkeys/ repo. Matthieu PS : this is more or less a duplicate of keycode in ir_codes_hauppauge_new (ir-kbd-i2c.c) and it could be useful to merge them. But I like better the av7110_loadkeys approch, because with ir-kbd-i2c you can't use other remote without modifying the source code. 0x3d KEY_POWER 0x3b KEY_GOTO 0x1c KEY_TV 0x18 KEY_VIDEO 0x19 KEY_AUDIO 0x1a KEY_MHP 0x1b KEY_EPG 0x0c KEY_RADIO 0x14 KEY_UP 0x16 KEY_LEFT 0x17 KEY_RIGHT 0x15 KEY_DOWN 0x25 KEY_ENTER 0x1f KEY_EXIT 0x0d KEY_MENU 0x10 KEY_VOLUMEUP 0x11 KEY_VOLUMEDOWN 0x20 KEY_CHANNELUP 0x21 KEY_CHANNELDOWN 0x12 KEY_PREVIOUS 0x0f KEY_MUTE 0x32 KEY_REWIND 0x35 KEY_PLAY 0x34 KEY_FASTFORWARD 0x37 KEY_RECORD 0x36 KEY_STOP 0x30 KEY_PAUSE 0x24 KEY_PREVIOUSSONG 0x1e KEY_NEXTSONG 0x00 KEY_0 0x01 KEY_1 0x02 KEY_2 0x03 KEY_3 0x04 KEY_4 0x05 KEY_5 0x06 KEY_6 0x07 KEY_7 0x08 KEY_8 0x09 KEY_9 0x0a KEY_TEXT 0x0e KEY_SUBTITLE 0x0b KEY_RED 0x2e KEY_GREEN 0x38 KEY_YELLOW 0x29 KEY_BLUE
