Re: [PATCH] TT CT-3650 IR and CI support
Thanks a lot Waling,
I often tried to write the support for CT-3650 but it was never
successful (due to leak of time). I will try your patch this week-end.
Gaëtan.
On 06/23/2010 12:48 AM, Waling Dijkstra wrote:
Hi linux-media,
adding support for IR and CI on the TT CT-3650.
CI code was mainly copied from pctv452e (PCTV 452e DVB driver).
IR support is same as on TT-S1500 (and 452e).
Signed-off-by: Waling Dijkstra
rgrds,
Waling
diff --git a/drivers/media/dvb/dvb-usb/ttusb2.c
b/drivers/media/dvb/dvb-usb/ttusb2.c
index a6de489..5ce6a51 100644
--- a/drivers/media/dvb/dvb-usb/ttusb2.c
+++ b/drivers/media/dvb/dvb-usb/ttusb2.c
@@ -32,6 +32,8 @@
#include "tda1002x.h"
#include "tda827x.h"
#include "lnbp21.h"
+/* CA */
+#include "dvb_ca_en50221.h"
/* debug */
static int dvb_usb_ttusb2_debug;
@@ -41,7 +43,26 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info
(or-able))." DVB_USB_DEBUG_
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+#define ci_dbg(format, arg...)\
+do { \
+ if (0)\
+ printk (KERN_DEBUG DVB_USB_LOG_PREFIX \
+ ": " format "\n" , ## arg); \
+} while (0)
+
+enum {
+ TT3650_CMD_CI_TEST = 0x40,
+ TT3650_CMD_CI_RD_CTRL,
+ TT3650_CMD_CI_WR_CTRL,
+ TT3650_CMD_CI_RD_ATTR,
+ TT3650_CMD_CI_WR_ATTR,
+ TT3650_CMD_CI_RESET,
+ TT3650_CMD_CI_SET_VIDEO_PORT
+};
+
struct ttusb2_state {
+ struct dvb_ca_en50221 ca;
+ struct mutex ca_mutex;
u8 id;
};
@@ -128,6 +149,333 @@ static struct i2c_algorithm ttusb2_i2c_algo = {
.functionality = ttusb2_i2c_func,
};
+/* IR */
+/* Remote Control Stuff for CT-3650 (copied from TT-S1500): */
+static struct dvb_usb_rc_key tt_connect_CT_3650_rc_key[] = {
+ {0x1501, KEY_POWER},
+ {0x1502, KEY_SHUFFLE}, /* ? double-arrow key */
+ {0x1503, KEY_1},
+ {0x1504, KEY_2},
+ {0x1505, KEY_3},
+ {0x1506, KEY_4},
+ {0x1507, KEY_5},
+ {0x1508, KEY_6},
+ {0x1509, KEY_7},
+ {0x150a, KEY_8},
+ {0x150b, KEY_9},
+ {0x150c, KEY_0},
+ {0x150d, KEY_UP},
+ {0x150e, KEY_LEFT},
+ {0x150f, KEY_OK},
+ {0x1510, KEY_RIGHT},
+ {0x1511, KEY_DOWN},
+ {0x1512, KEY_INFO},
+ {0x1513, KEY_EXIT},
+ {0x1514, KEY_RED},
+ {0x1515, KEY_GREEN},
+ {0x1516, KEY_YELLOW},
+ {0x1517, KEY_BLUE},
+ {0x1518, KEY_MUTE},
+ {0x1519, KEY_TEXT},
+ {0x151a, KEY_MODE}, /* ? TV/Radio */
+ {0x1521, KEY_OPTION},
+ {0x1522, KEY_EPG},
+ {0x1523, KEY_CHANNELUP},
+ {0x1524, KEY_CHANNELDOWN},
+ {0x1525, KEY_VOLUMEUP},
+ {0x1526, KEY_VOLUMEDOWN},
+ {0x1527, KEY_SETUP},
+ {0x153a, KEY_RECORD},/* these keys are only in the black remote */
+ {0x153b, KEY_PLAY},
+ {0x153c, KEY_STOP},
+ {0x153d, KEY_REWIND},
+ {0x153e, KEY_PAUSE},
+ {0x153f, KEY_FORWARD}
+};
+
+static int tt3650_rc_query(struct dvb_usb_device *d, u32 *keyevent, int
*keystate)
+{
+ u8 keybuf[5];
+ int ret;
+ u8 b[36];/* this was (CMD_BUFFER_SIZE) u8 b[0x28] - dvb_usb_generic_rw
adds another 4 */
+ u8 rx[60];/* same (64 -4) */
+ ret = ttusb2_msg(d, CMD_GET_IR_CODE, b, 0, rx, 9);
+ if (ret != 0)
+ return ret;
+
+ if (rx[8]& 0x01) {
+ /* got a "press" event */
+/* if (debug> 2) {
+ printk("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2],
rx[3]);
+ }
+*/
+ keybuf[0] = 0x01;/* DVB_USB_RC_NEC_KEY_PRESSED; why is this
#define'd privately? */
+ keybuf[1] = rx[3];
+ keybuf[2] = ~keybuf[1]; /* fake checksum */
+ keybuf[3] = rx[2];
+ keybuf[4] = ~keybuf[3]; /* fake checksum */
+ dvb_usb_nec_rc_key_to_event(d, keybuf, keyevent, keystate);
+ }
+ return 0;
+}
+
+/* ci */
+static int tt3650_ci_msg (struct dvb_usb_device *d, u8 cmd, u8 *data,
+ unsigned int write_len,
unsigned int read_len)
+{
+int ret;
+u8 rx[60];/* (64 -4) */
+ret = ttusb2_msg(d, cmd, data, write_len, rx, read_len);
+if (ret == 0)
+ memcpy (data, rx, read_len);
+return ret;
+}
+
+static int tt3650_ci_msg_locked(struct dvb_ca_en50221 *ca,
+ u8 cmd, u8
*data, unsigned int write_len, unsigned int read_len)
+{
+ struct dvb_usb_device *d = (struct dvb_usb_device *)ca->data;
+ struct ttusb2_state *state = (struct ttusb2_state *)d->priv;
+ int ret;
+
+ mutex_lock(&state->ca_mutex);
+ ret = tt3650_ci_msg(d, cmd, data, write_len, read_len);
+ mutex_unlock(&state->ca_mutex);
+
+ return ret;
+}
+
+static int tt3650_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot,
[PATCH] TT CT-3650 IR and CI support
Hi linux-media,
adding support for IR and CI on the TT CT-3650.
CI code was mainly copied from pctv452e (PCTV 452e DVB driver).
IR support is same as on TT-S1500 (and 452e).
Signed-off-by: Waling Dijkstra
rgrds,
Waling
diff --git a/drivers/media/dvb/dvb-usb/ttusb2.c
b/drivers/media/dvb/dvb-usb/ttusb2.c
index a6de489..5ce6a51 100644
--- a/drivers/media/dvb/dvb-usb/ttusb2.c
+++ b/drivers/media/dvb/dvb-usb/ttusb2.c
@@ -32,6 +32,8 @@
#include "tda1002x.h"
#include "tda827x.h"
#include "lnbp21.h"
+/* CA */
+#include "dvb_ca_en50221.h"
/* debug */
static int dvb_usb_ttusb2_debug;
@@ -41,7 +43,26 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info
(or-able))." DVB_USB_DEBUG_
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+#define ci_dbg(format, arg...)\
+do { \
+ if (0)\
+ printk (KERN_DEBUG DVB_USB_LOG_PREFIX \
+ ": " format "\n" , ## arg); \
+} while (0)
+
+enum {
+ TT3650_CMD_CI_TEST = 0x40,
+ TT3650_CMD_CI_RD_CTRL,
+ TT3650_CMD_CI_WR_CTRL,
+ TT3650_CMD_CI_RD_ATTR,
+ TT3650_CMD_CI_WR_ATTR,
+ TT3650_CMD_CI_RESET,
+ TT3650_CMD_CI_SET_VIDEO_PORT
+};
+
struct ttusb2_state {
+ struct dvb_ca_en50221 ca;
+ struct mutex ca_mutex;
u8 id;
};
@@ -128,6 +149,333 @@ static struct i2c_algorithm ttusb2_i2c_algo = {
.functionality = ttusb2_i2c_func,
};
+/* IR */
+/* Remote Control Stuff for CT-3650 (copied from TT-S1500): */
+static struct dvb_usb_rc_key tt_connect_CT_3650_rc_key[] = {
+ {0x1501, KEY_POWER},
+ {0x1502, KEY_SHUFFLE}, /* ? double-arrow key */
+ {0x1503, KEY_1},
+ {0x1504, KEY_2},
+ {0x1505, KEY_3},
+ {0x1506, KEY_4},
+ {0x1507, KEY_5},
+ {0x1508, KEY_6},
+ {0x1509, KEY_7},
+ {0x150a, KEY_8},
+ {0x150b, KEY_9},
+ {0x150c, KEY_0},
+ {0x150d, KEY_UP},
+ {0x150e, KEY_LEFT},
+ {0x150f, KEY_OK},
+ {0x1510, KEY_RIGHT},
+ {0x1511, KEY_DOWN},
+ {0x1512, KEY_INFO},
+ {0x1513, KEY_EXIT},
+ {0x1514, KEY_RED},
+ {0x1515, KEY_GREEN},
+ {0x1516, KEY_YELLOW},
+ {0x1517, KEY_BLUE},
+ {0x1518, KEY_MUTE},
+ {0x1519, KEY_TEXT},
+ {0x151a, KEY_MODE}, /* ? TV/Radio */
+ {0x1521, KEY_OPTION},
+ {0x1522, KEY_EPG},
+ {0x1523, KEY_CHANNELUP},
+ {0x1524, KEY_CHANNELDOWN},
+ {0x1525, KEY_VOLUMEUP},
+ {0x1526, KEY_VOLUMEDOWN},
+ {0x1527, KEY_SETUP},
+ {0x153a, KEY_RECORD},/* these keys are only in the black remote */
+ {0x153b, KEY_PLAY},
+ {0x153c, KEY_STOP},
+ {0x153d, KEY_REWIND},
+ {0x153e, KEY_PAUSE},
+ {0x153f, KEY_FORWARD}
+};
+
+static int tt3650_rc_query(struct dvb_usb_device *d, u32 *keyevent, int
*keystate)
+{
+ u8 keybuf[5];
+ int ret;
+ u8 b[36];/* this was (CMD_BUFFER_SIZE) u8 b[0x28] - dvb_usb_generic_rw
adds another 4 */
+ u8 rx[60];/* same (64 -4) */
+ ret = ttusb2_msg(d, CMD_GET_IR_CODE, b, 0, rx, 9);
+ if (ret != 0)
+ return ret;
+
+ if (rx[8] & 0x01) {
+ /* got a "press" event */
+/* if (debug > 2) {
+ printk("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2],
rx[3]);
+ }
+*/
+ keybuf[0] = 0x01;/* DVB_USB_RC_NEC_KEY_PRESSED; why is this
#define'd privately? */
+ keybuf[1] = rx[3];
+ keybuf[2] = ~keybuf[1]; /* fake checksum */
+ keybuf[3] = rx[2];
+ keybuf[4] = ~keybuf[3]; /* fake checksum */
+ dvb_usb_nec_rc_key_to_event(d, keybuf, keyevent, keystate);
+ }
+ return 0;
+}
+
+/* ci */
+static int tt3650_ci_msg (struct dvb_usb_device *d, u8 cmd, u8 *data,
+ unsigned int write_len,
unsigned int read_len)
+{
+int ret;
+u8 rx[60];/* (64 -4) */
+ret = ttusb2_msg(d, cmd, data, write_len, rx, read_len);
+if (ret == 0)
+ memcpy (data, rx, read_len);
+return ret;
+}
+
+static int tt3650_ci_msg_locked(struct dvb_ca_en50221 *ca,
+ u8 cmd, u8
*data, unsigned int write_len, unsigned int read_len)
+{
+ struct dvb_usb_device *d = (struct dvb_usb_device *)ca->data;
+ struct ttusb2_state *state = (struct ttusb2_state *)d->priv;
+ int ret;
+
+ mutex_lock(&state->ca_mutex);
+ ret = tt3650_ci_msg(d, cmd, data, write_len, read_len);
+ mutex_unlock(&state->ca_mutex);
+
+ return ret;
+}
+
+static int tt3650_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot,
int address)
+{
+ u8 buf[3];
+ int ret;
+
+ if (0 != slot)
+ return -EINVAL;
+
+ buf[0] = (address >> 8) & 0x0F;
+ buf[1] = address;
+
+ ret = tt3650_ci_msg_locked(ca,
[PATCH] TT CT-3650 IR and CI support
Hi linux-media,
adding support for IR and CI on the TT CT-3650.
CI code was mainly copied from pctv452e (PCTV 452e DVB driver).
IR support is same as on TT-S1500 (and 452e).
Signed-off-by: Waling Dijkstra
rgrds,
Waling
diff --git a/drivers/media/dvb/dvb-usb/ttusb2.c
b/drivers/media/dvb/dvb-usb/ttusb2.c
index a6de489..5ce6a51 100644
--- a/drivers/media/dvb/dvb-usb/ttusb2.c
+++ b/drivers/media/dvb/dvb-usb/ttusb2.c
@@ -32,6 +32,8 @@
#include "tda1002x.h"
#include "tda827x.h"
#include "lnbp21.h"
+/* CA */
+#include "dvb_ca_en50221.h"
/* debug */
static int dvb_usb_ttusb2_debug;
@@ -41,7 +43,26 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info
(or-able))." DVB_USB_DEBUG_
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+#define ci_dbg(format, arg...)\
+do { \
+ if (0)\
+ printk (KERN_DEBUG DVB_USB_LOG_PREFIX \
+ ": " format "\n" , ## arg); \
+} while (0)
+
+enum {
+ TT3650_CMD_CI_TEST = 0x40,
+ TT3650_CMD_CI_RD_CTRL,
+ TT3650_CMD_CI_WR_CTRL,
+ TT3650_CMD_CI_RD_ATTR,
+ TT3650_CMD_CI_WR_ATTR,
+ TT3650_CMD_CI_RESET,
+ TT3650_CMD_CI_SET_VIDEO_PORT
+};
+
struct ttusb2_state {
+ struct dvb_ca_en50221 ca;
+ struct mutex ca_mutex;
u8 id;
};
@@ -128,6 +149,333 @@ static struct i2c_algorithm ttusb2_i2c_algo = {
.functionality = ttusb2_i2c_func,
};
+/* IR */
+/* Remote Control Stuff for CT-3650 (copied from TT-S1500): */
+static struct dvb_usb_rc_key tt_connect_CT_3650_rc_key[] = {
+ {0x1501, KEY_POWER},
+ {0x1502, KEY_SHUFFLE}, /* ? double-arrow key */
+ {0x1503, KEY_1},
+ {0x1504, KEY_2},
+ {0x1505, KEY_3},
+ {0x1506, KEY_4},
+ {0x1507, KEY_5},
+ {0x1508, KEY_6},
+ {0x1509, KEY_7},
+ {0x150a, KEY_8},
+ {0x150b, KEY_9},
+ {0x150c, KEY_0},
+ {0x150d, KEY_UP},
+ {0x150e, KEY_LEFT},
+ {0x150f, KEY_OK},
+ {0x1510, KEY_RIGHT},
+ {0x1511, KEY_DOWN},
+ {0x1512, KEY_INFO},
+ {0x1513, KEY_EXIT},
+ {0x1514, KEY_RED},
+ {0x1515, KEY_GREEN},
+ {0x1516, KEY_YELLOW},
+ {0x1517, KEY_BLUE},
+ {0x1518, KEY_MUTE},
+ {0x1519, KEY_TEXT},
+ {0x151a, KEY_MODE}, /* ? TV/Radio */
+ {0x1521, KEY_OPTION},
+ {0x1522, KEY_EPG},
+ {0x1523, KEY_CHANNELUP},
+ {0x1524, KEY_CHANNELDOWN},
+ {0x1525, KEY_VOLUMEUP},
+ {0x1526, KEY_VOLUMEDOWN},
+ {0x1527, KEY_SETUP},
+ {0x153a, KEY_RECORD},/* these keys are only in the black remote */
+ {0x153b, KEY_PLAY},
+ {0x153c, KEY_STOP},
+ {0x153d, KEY_REWIND},
+ {0x153e, KEY_PAUSE},
+ {0x153f, KEY_FORWARD}
+};
+
+static int tt3650_rc_query(struct dvb_usb_device *d, u32 *keyevent, int
*keystate)
+{
+ u8 keybuf[5];
+ int ret;
+ u8 b[36];/* this was (CMD_BUFFER_SIZE) u8 b[0x28] - dvb_usb_generic_rw
adds another 4 */
+ u8 rx[60];/* same (64 -4) */
+ ret = ttusb2_msg(d, CMD_GET_IR_CODE, b, 0, rx, 9);
+ if (ret != 0)
+ return ret;
+
+ if (rx[8] & 0x01) {
+ /* got a "press" event */
+/* if (debug > 2) {
+ printk("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2],
rx[3]);
+ }
+*/
+ keybuf[0] = 0x01;/* DVB_USB_RC_NEC_KEY_PRESSED; why is this
#define'd privately? */
+ keybuf[1] = rx[3];
+ keybuf[2] = ~keybuf[1]; /* fake checksum */
+ keybuf[3] = rx[2];
+ keybuf[4] = ~keybuf[3]; /* fake checksum */
+ dvb_usb_nec_rc_key_to_event(d, keybuf, keyevent, keystate);
+ }
+ return 0;
+}
+
+/* ci */
+static int tt3650_ci_msg (struct dvb_usb_device *d, u8 cmd, u8 *data,
+ unsigned int write_len,
unsigned int read_len)
+{
+int ret;
+u8 rx[60];/* (64 -4) */
+ret = ttusb2_msg(d, cmd, data, write_len, rx, read_len);
+if (ret == 0)
+ memcpy (data, rx, read_len);
+return ret;
+}
+
+static int tt3650_ci_msg_locked(struct dvb_ca_en50221 *ca,
+ u8 cmd, u8
*data, unsigned int write_len, unsigned int read_len)
+{
+ struct dvb_usb_device *d = (struct dvb_usb_device *)ca->data;
+ struct ttusb2_state *state = (struct ttusb2_state *)d->priv;
+ int ret;
+
+ mutex_lock(&state->ca_mutex);
+ ret = tt3650_ci_msg(d, cmd, data, write_len, read_len);
+ mutex_unlock(&state->ca_mutex);
+
+ return ret;
+}
+
+static int tt3650_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot,
int address)
+{
+ u8 buf[3];
+ int ret;
+
+ if (0 != slot)
+ return -EINVAL;
+
+ buf[0] = (address >> 8) & 0x0F;
+ buf[1] = address;
+
+ ret = tt3650_ci_msg_locked(ca,
Re: em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver
Thank you, Devin and Mauro.
Unfortunately I don't have the eeprom data. I can only tell you what
happened to the usb id:
original: 0ccd:0043 TerraTec Electronic GmbH
now: eb1a:2871 eMPIA Technology, Inc.
With 2 lines added to em28xx-cards.c (see the diff at the end of this
mail) I was hoping to get back the old behavior. But you're right -
it's not sufficient. Guess I really need to recover the eeprom.
So... Devin, do you have the very same board?
Thorsten
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index b0fb083..ef2ecd7 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1720,6 +1720,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2880_BOARD_TERRATEC_HYBRID_XS },
{ USB_DEVICE(0x0ccd, 0x0043),
.driver_info = EM2870_BOARD_TERRATEC_XS },
+ { USB_DEVICE(0xeb1a, 0x2871),
+ .driver_info = EM2870_BOARD_TERRATEC_XS },
{ USB_DEVICE(0x0ccd, 0x0047),
.driver_info = EM2880_BOARD_TERRATEC_PRODIGY_XS },
{ USB_DEVICE(0x0ccd, 0x0084),
--
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: em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver
Em 22-06-2010 18:52, Devin Heitmueller escreveu: > On Tue, Jun 22, 2010 at 5:25 PM, Thorsten Hirsch wrote: >> Hi, >> >> as far as I know there's been some trouble in the past regarding >> Markus Rechberger's em28xx driver (em28xx-new) and the official >> development line, resulting in the current situation: >> >> - M. Rechberger isn't developing his driver anymore >> - kernel driver doesn't support em28xx/xc3028 based usb sticks >> (cinergy usb t xs) >> >> Can I help to solve the situation? >> >> So far I opened a bug report on launchpad >> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/460636) >> describing the situation with both drivers. I also tried to update M. >> Rechberger's driver making it work in more recent kernels. This worked >> for a short while, but then my usb stick lost its official (terratec >> branded) usb id and I couldn't manage to make it work again since. You probably damaged the contents of the device's eeprom. If you have the logs with the previous eeprom contents somewhere, it is possible to recover it. There's an util at v4l-utils that allows re-writing the information at the eeprom. >> The >> current situation for my patched version of M. Rechberger's driver is, >> that everything seems to work fine except for locking channels / some >> tuning stuff ...well, I don't know exactly, I just see that kaffeine >> detects the device and can scan for channels. While the 2 signal bars >> (snr/quality) are pretty active and even the green tuning led (in >> kaffeine) is very often active, there is just no channel entering the >> list. >> >> Regarding the official em28xx driver my usb stick is far away from >> working. It stops as soon as when the firmware is being loaded: >> >> [ 576.009547] xc2028 5-0060: Incorrect readback of firmware version >> >> I already wrote an email to Mauro Carvalho Chehab (the author of the >> em28xx driver) and he told me that my firmware file must be corrupted. >> That's xc3028-v27.fw. My version is from Ubuntu's nonfree firmware >> package. But it's the same file as when I follow Mauro's description >> of how to extract the firmware from the Windows driver >> (extract_xc3028.pl). So it looks as if the Cinergy USB T XS needs a >> different xc3028-v27.fw file. >> >> What about the firmware in M. Rechberger's driver? Well, it doesn't >> depend on an external firmware file, because the firmware is included >> in xc3028/xc3028_firmwares.h, which has the following copyright note: >> (c) 2006, Xceive Corporation. Looks like the official one, so I guess >> it should work. And since my device was already working with that >> firmware a while ago when Markus was still developing his driver I >> guess I should focus on the following question: >> >> => How can I extract the firmware from Xceive's official >> xc3028/xc3028_firmwares.h and making it work with the em28xx driver >> (vanilla kernel)? > I hate to say that "you're totally on the wrong track", except that's > almost certainly the case. > > You've got the right firmware already (and there isn't a 'different > v.27'). That error occurs if the driver is unable to read back the > version from the chip after loading the firmware. It's most likely > the board profile isn't setup properly to bring the chip out of reset. I agree with the diagnosis. As you're now saying that the eeprom contents of your board got damaged (different USB ID), this means that it is using the wrong setup for the GPIO pins. One (or two) pins are required to poweron/reset the xc3028 device. If the pin configuration is wrong, the firmware won't load at xc3028, and the device won't work. > The firmware is separated out because the Linux kernel process does > permit firmware embedding. It *must* be provided as a separate blob. Due to GPL licensing for the kernel drivers, the only legal way for a firmware to be inside the kernel (or inside a kernel driver) is if the firmware is also provided as GPL. That's why a separate file is required. > Also, Xceive hasn't granted permission to redistribute the xc3028 > firmware, which is why it usually has to be extracted from the Windows > driver (unlike the xc4000 and xc5000 where they have explicitly > granted redistribution rights). > > Regarding the statement that the "kernel driver doesn't support > em28xx/xc3028 based usb sticks", this is simply incorrect. The > current kernel supports a variety of devices that have a combination > of the em28xx and xc3028. A board profile needs to be added for the > device in question (I have the board but haven't had a chance to do > the necessary work). > > Exactly what is the USB ID of the board you have (there are a variety > different versions of the board with that name). I probably have the > board already, but I want to be sure. > > In the end, it's probably something like 12 lines of code need to be > added to the current driver. > > Devin > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of
Re: em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver
On Tue, Jun 22, 2010 at 5:25 PM, Thorsten Hirsch wrote: > Hi, > > as far as I know there's been some trouble in the past regarding > Markus Rechberger's em28xx driver (em28xx-new) and the official > development line, resulting in the current situation: > > - M. Rechberger isn't developing his driver anymore > - kernel driver doesn't support em28xx/xc3028 based usb sticks > (cinergy usb t xs) > > Can I help to solve the situation? > > So far I opened a bug report on launchpad > (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/460636) > describing the situation with both drivers. I also tried to update M. > Rechberger's driver making it work in more recent kernels. This worked > for a short while, but then my usb stick lost its official (terratec > branded) usb id and I couldn't manage to make it work again since. The > current situation for my patched version of M. Rechberger's driver is, > that everything seems to work fine except for locking channels / some > tuning stuff ...well, I don't know exactly, I just see that kaffeine > detects the device and can scan for channels. While the 2 signal bars > (snr/quality) are pretty active and even the green tuning led (in > kaffeine) is very often active, there is just no channel entering the > list. > > Regarding the official em28xx driver my usb stick is far away from > working. It stops as soon as when the firmware is being loaded: > > [ 576.009547] xc2028 5-0060: Incorrect readback of firmware version > > I already wrote an email to Mauro Carvalho Chehab (the author of the > em28xx driver) and he told me that my firmware file must be corrupted. > That's xc3028-v27.fw. My version is from Ubuntu's nonfree firmware > package. But it's the same file as when I follow Mauro's description > of how to extract the firmware from the Windows driver > (extract_xc3028.pl). So it looks as if the Cinergy USB T XS needs a > different xc3028-v27.fw file. > > What about the firmware in M. Rechberger's driver? Well, it doesn't > depend on an external firmware file, because the firmware is included > in xc3028/xc3028_firmwares.h, which has the following copyright note: > (c) 2006, Xceive Corporation. Looks like the official one, so I guess > it should work. And since my device was already working with that > firmware a while ago when Markus was still developing his driver I > guess I should focus on the following question: > > => How can I extract the firmware from Xceive's official > xc3028/xc3028_firmwares.h and making it work with the em28xx driver > (vanilla kernel)? I hate to say that "you're totally on the wrong track", except that's almost certainly the case. You've got the right firmware already (and there isn't a 'different v.27'). That error occurs if the driver is unable to read back the version from the chip after loading the firmware. It's most likely the board profile isn't setup properly to bring the chip out of reset. The firmware is separated out because the Linux kernel process does permit firmware embedding. It *must* be provided as a separate blob. Also, Xceive hasn't granted permission to redistribute the xc3028 firmware, which is why it usually has to be extracted from the Windows driver (unlike the xc4000 and xc5000 where they have explicitly granted redistribution rights). Regarding the statement that the "kernel driver doesn't support em28xx/xc3028 based usb sticks", this is simply incorrect. The current kernel supports a variety of devices that have a combination of the em28xx and xc3028. A board profile needs to be added for the device in question (I have the board but haven't had a chance to do the necessary work). Exactly what is the USB ID of the board you have (there are a variety different versions of the board with that name). I probably have the board already, but I want to be sure. In the end, it's probably something like 12 lines of code need to be added to the current driver. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver
Hi, as far as I know there's been some trouble in the past regarding Markus Rechberger's em28xx driver (em28xx-new) and the official development line, resulting in the current situation: - M. Rechberger isn't developing his driver anymore - kernel driver doesn't support em28xx/xc3028 based usb sticks (cinergy usb t xs) Can I help to solve the situation? So far I opened a bug report on launchpad (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/460636) describing the situation with both drivers. I also tried to update M. Rechberger's driver making it work in more recent kernels. This worked for a short while, but then my usb stick lost its official (terratec branded) usb id and I couldn't manage to make it work again since. The current situation for my patched version of M. Rechberger's driver is, that everything seems to work fine except for locking channels / some tuning stuff ...well, I don't know exactly, I just see that kaffeine detects the device and can scan for channels. While the 2 signal bars (snr/quality) are pretty active and even the green tuning led (in kaffeine) is very often active, there is just no channel entering the list. Regarding the official em28xx driver my usb stick is far away from working. It stops as soon as when the firmware is being loaded: [ 576.009547] xc2028 5-0060: Incorrect readback of firmware version I already wrote an email to Mauro Carvalho Chehab (the author of the em28xx driver) and he told me that my firmware file must be corrupted. That's xc3028-v27.fw. My version is from Ubuntu's nonfree firmware package. But it's the same file as when I follow Mauro's description of how to extract the firmware from the Windows driver (extract_xc3028.pl). So it looks as if the Cinergy USB T XS needs a different xc3028-v27.fw file. What about the firmware in M. Rechberger's driver? Well, it doesn't depend on an external firmware file, because the firmware is included in xc3028/xc3028_firmwares.h, which has the following copyright note: (c) 2006, Xceive Corporation. Looks like the official one, so I guess it should work. And since my device was already working with that firmware a while ago when Markus was still developing his driver I guess I should focus on the following question: => How can I extract the firmware from Xceive's official xc3028/xc3028_firmwares.h and making it work with the em28xx driver (vanilla kernel)? I wrote a perl script for this job ...well, at least for extraction. Now I've got 48 firmware files: XC3028_base_firmware_i2c_files_base_firmwares_8mhz_init_SEQUENCE XC3028_base_firmware_i2c_files_base_firmwares_8mhz_mts_init_SEQUENCE XC3028_base_firmware_i2c_files_base_firmwares_fm_init_SEQUENCE XC3028_base_firmware_i2c_files_base_firmwares_fm_input1_init_SEQUENCE XC3028_base_firmware_i2c_files_base_firmwares_init_SEQUENCE XC3028_base_firmware_i2c_files_base_firmwares_mts_init_SEQUENCE XC3028_std_firmware_bg_pal_a2_a_SEQUENCE XC3028_std_firmware_bg_pal_a2_a_mts_SEQUENCE XC3028_std_firmware_bg_pal_a2_b_SEQUENCE XC3028_std_firmware_bg_pal_a2_b_mts_SEQUENCE XC3028_std_firmware_bg_pal_nicam_a_SEQUENCE XC3028_std_firmware_bg_pal_nicam_a_mts_SEQUENCE XC3028_std_firmware_bg_pal_nicam_b_SEQUENCE XC3028_std_firmware_bg_pal_nicam_b_mts_SEQUENCE XC3028_std_firmware_dk_pal_a2_SEQUENCE XC3028_std_firmware_dk_pal_a2_mts_SEQUENCE XC3028_std_firmware_dk_pal_nicam_SEQUENCE XC3028_std_firmware_dk_pal_nicam_mts_SEQUENCE XC3028_std_firmware_dk_secam_a2_dk1_SEQUENCE XC3028_std_firmware_dk_secam_a2_dk1_mts_SEQUENCE XC3028_std_firmware_dk_secam_a2_l_dk3_SEQUENCE XC3028_std_firmware_dk_secam_a2_l_dk3_mts_SEQUENCE XC3028_std_firmware_dtv6_atsc_2633_SEQUENCE XC3028_std_firmware_dtv6_qam_2620_SEQUENCE XC3028_std_firmware_dtv6_qam_2633_SEQUENCE XC3028_std_firmware_dtv7_2620_SEQUENCE XC3028_std_firmware_dtv7_2633_SEQUENCE XC3028_std_firmware_dtv78_2620_SEQUENCE XC3028_std_firmware_dtv78_2633_SEQUENCE XC3028_std_firmware_dtv8_2620_SEQUENCE XC3028_std_firmware_dtv8_2633_SEQUENCE XC3028_std_firmware_fm_SEQUENCE XC3028_std_firmware_i_pal_nicam_SEQUENCE XC3028_std_firmware_i_pal_nicam_mts_SEQUENCE XC3028_std_firmware_l_secam_am_SEQUENCE XC3028_std_firmware_l_secam_nicam_SEQUENCE XC3028_std_firmware_lp_secam_nicam_SEQUENCE XC3028_std_firmware_mn_ntscpal_a2_SEQUENCE XC3028_std_firmware_mn_ntscpal_a2_lcd_SEQUENCE XC3028_std_firmware_mn_ntscpal_a2_lcd_nogd_SEQUENCE XC3028_std_firmware_mn_ntscpal_a2_mts_SEQUENCE XC3028_std_firmware_mn_ntscpal_btsc_SEQUENCE XC3028_std_firmware_mn_ntscpal_btsc_lcd_SEQUENCE XC3028_std_firmware_mn_ntscpal_btsc_lcd_nogd_SEQUENCE XC3028_std_firmware_mn_ntscpal_eiaj_SEQUENCE XC3028_std_firmware_mn_ntscpal_mts_SEQUENCE XC3028_std_firmware_mn_ntscpal_mts_lcd_SEQUENCE XC3028_std_firmware_mn_ntscpal_mts_lcd_nogd_SEQUENCE What do I do now? How can I pack them into 1 firmware file that is compatible with the kernel's em28xx driver? Thorsten P.S.: There's also another thing I was trying - I have the Windows BDA driver's emBDA.sys file that consists of the firmwar
Re: [linux-dvb] Cinergy C PCI HD with current v4l-dvb - PATCH for review/pull included
On 6/19/10 15:56 , Marko Ristola wrote: Hello all interested in a robust Mantis driver. hi Marko, is there a hg/git branch where your (and possibly Bjorn Morks) recent patches are already in? since i had difficulties to apply some of them. further more, is there a way/patch for the current tree which gives us a working remote control? regards yannick -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jun 22 19:00:18 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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 1/2] media: Add timberdale video-in driver
Hi,
On 05/26/2010 04:19 PM, Richard Röjfors wrote:
Hi Mauro,
On Sun, 2010-04-25 at 13:13 -0300, Mauro Carvalho Chehab wrote:
2.
I tried using videobuf-dma-contig, but got poor performance. I can not
really explain why, I though it's due to the fact that the contiguous
buffer is allocated coherent -> no caching.
I saw both gstreamer and mplayer perform very badly.
The frame grabber requires the DMA transfer for a frame beeing started
while the frame is decoded. When I tested using contigous buffers
gstreamer sometimes was that slow that it sometimes missed to have a
frame queued when a transfer was finished, so I got frame drops. Any
other ideas of the poor performance? otherwise I would like to go for
the double buffered solution.
The better is to fix videobuf-dma_contig to better work on your hardware.
It makes sense to add a flag to allow specifying if it should use coherent
or non-coherent memory for the dma buffer alloc/free calls.
I have verified the performance issue and it goes back to non cached coherent
buffers.
I did an update to the videobuf-dma-contig. I did it by adding another init
function,
which calls videobuf_queue_core_init with another set of qops.
The other set uses the same functions as the uncached version, but a sync
function
is added, and the alloc_functions are different.
What do you think?
Any comments on this?
I know it doesn't apply on 2.6.35. But the general idea of how to add in cache support in the contig
buffer code.
On our platform we get much better (useful) performance using cached buffers.
//Richard
Signed-off-by: Richard Röjfors
---
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index dce4f3a..2fc923c 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -27,6 +27,7 @@ struct videobuf_dma_contig_memory {
u32 magic;
void *vaddr;
dma_addr_t dma_handle;
+ bool cached;
unsigned long size;
int is_userptr;
};
@@ -38,6 +39,54 @@ struct videobuf_dma_contig_memory {
BUG(); \
}
+static int __videobuf_dc_alloc(struct device *dev,
+ struct videobuf_dma_contig_memory *mem, unsigned long size)
+{
+ mem->size = size;
+ if (mem->cached) {
+ mem->vaddr = kmalloc(mem->size, GFP_KERNEL);
+ if (mem->vaddr) {
+ int err;
+
+ mem->dma_handle = dma_map_single(dev, mem->vaddr,
+ mem->size, DMA_FROM_DEVICE);
+ err = dma_mapping_error(dev, mem->dma_handle);
+ if (err) {
+ dev_err(dev, "dma_map_single failed\n");
+
+ kfree(mem->vaddr);
+ mem->vaddr = 0;
+ return err;
+ }
+ }
+ } else
+ mem->vaddr = dma_alloc_coherent(dev, mem->size,
+ &mem->dma_handle, GFP_KERNEL);
+
+ if (!mem->vaddr) {
+ dev_err(dev, "memory alloc size %ld failed\n",
+ mem->size);
+ return -ENOMEM;
+ }
+
+ dev_dbg(dev, "dma mapped data is at %p (%ld)\n", mem->vaddr, mem->size);
+
+ return 0;
+}
+
+static void __videobuf_dc_free(struct device *dev,
+ struct videobuf_dma_contig_memory *mem)
+{
+ if (mem->cached) {
+ dma_unmap_single(dev, mem->dma_handle, mem->size,
+ DMA_FROM_DEVICE);
+ kfree(mem->vaddr);
+ } else
+ dma_free_coherent(dev, mem->size, mem->vaddr, mem->dma_handle);
+
+ mem->vaddr = NULL;
+}
+
static void
videobuf_vm_open(struct vm_area_struct *vma)
{
@@ -92,9 +141,7 @@ static void videobuf_vm_close(struct vm_area_struct *vma)
dev_dbg(map->q->dev, "buf[%d] freeing %p\n",
i, mem->vaddr);
- dma_free_coherent(q->dev, mem->size,
- mem->vaddr, mem->dma_handle);
- mem->vaddr = NULL;
+ __videobuf_dc_free(q->dev, mem);
}
q->bufs[i]->map = NULL;
@@ -190,7 +237,7 @@ static int videobuf_dma_contig_user_get(struct
videobuf_dma_contig_memory *mem,
return ret;
}
-static void *__videobuf_alloc(size_t size)
+static void *__videobuf_alloc(size_t size, bool cached)
{
struct videobuf_dma_contig_memory *mem;
struct videobuf_buffer *vb;
@@ -199,11 +246,22 @@ static void *__videobuf_alloc(size_t size)
if (vb) {
mem = vb->priv = ((char *)vb) + size;
mem->magic = MAGIC_DC_MEM;
+ mem->cached = cached;
}
return vb;
buffer management
Hi All, While working on a driver, i stumbled up on this question. I have a driver where the driver allocates it's buffers (maybe it's better to term that the hardware requires it that way) in the following fashion: Buffer 1: SG list 1 Buffer 2: SG list 2 Buffer 3: SG list 3 Buffer 4: SG list 4 Buffer 5: SG list 5 Buffer 6: SG list 6 Buffer 7: SG list 7 Buffer 8: SG list 8 Now, on each video interrupt, I know which SG list i need to read from. At this stage i do need to copy the buffers associated with each of the SG lists at once. In this scenario, I don't see how videobuf could be used, while I keep getting this feeling that a simple copy_to_user of the entire buffer could do the whole job in a better way, since the buffers themselves are already managed and initialized already. Am I correct in thinking so, or is it that I am overlooking something ? Comments ? Thanks, Manu -- 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
remote not working for Hauppauge HVR 1120
Hello, My name is Mario Latronico and this is my first message to this list. I'm trying to use the remote commander bundled with my Hauppauge HVR 1120, but the card seems not to be supported by the latest v4l-dvb modules from the Hg repository (I cloned the source around 1 week ago). The output of dmesg after a make unload && make && make uninstall && modprobe saa7134 ir_debug=1 is : [ 4873.304025] IR NEC protocol handler initialized [ 4873.326432] Linux video capture interface: v2.00 [ 4873.337917] IR RC5(x) protocol handler initialized [ 4873.357148] saa7130/34: v4l2 driver version 0.2.16 loaded [ 4873.357227] saa7133[0]: found at :05:09.0, rev: 209, irq: 18, latency: 32, mmio: 0xf050 [ 4873.357241] saa7133[0]: subsystem: 0070:6707, board: Hauppauge WinTV-HVR1120 DVB-T/Hybrid [card=156,autodetected] [ 4873.357591] saa7133[0]: board init: gpio is 440100 [ 4873.359113] IR RC6 protocol handler initialized [ 4873.364155] IR JVC protocol handler initialized [ 4873.368410] IR Sony protocol handler initialized [ 4873.381035] IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 4873.532020] saa7133[0]: i2c eeprom 00: 70 00 07 67 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 4873.532040] saa7133[0]: i2c eeprom 10: ff ff ff 0e ff 20 ff ff ff ff ff ff ff ff ff ff [ 4873.532057] saa7133[0]: i2c eeprom 20: 01 40 01 32 32 01 01 33 88 ff 00 b0 ff ff ff ff [ 4873.532074] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 4873.532091] saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 06 32 97 04 00 20 00 ff ff ff [ 4873.532108] saa7133[0]: i2c eeprom 50: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4873.532125] saa7133[0]: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4873.532141] saa7133[0]: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4873.532158] saa7133[0]: i2c eeprom 80: 84 09 00 04 20 77 00 40 0c 17 64 f0 73 05 29 00 [ 4873.532175] saa7133[0]: i2c eeprom 90: 84 08 00 06 89 06 01 00 95 29 8d 72 07 70 73 09 [ 4873.532192] saa7133[0]: i2c eeprom a0: 23 5f 73 0a f4 9b 72 0b 2f 72 0e 01 72 0f 45 72 [ 4873.532209] saa7133[0]: i2c eeprom b0: 10 01 72 11 ff 73 13 a2 69 79 1e 00 00 00 00 00 [ 4873.532225] saa7133[0]: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4873.532242] saa7133[0]: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4873.532259] saa7133[0]: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4873.532275] saa7133[0]: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4873.532293] saa7133[0]/ir: No I2C IR support for board 9c [ 4873.532302] tveeprom 1-0050: Hauppauge model 67209, rev C2F5, serial# 6559500 [ 4873.532306] tveeprom 1-0050: MAC address is 00:0d:fe:64:17:0c [ 4873.532310] tveeprom 1-0050: tuner model is NXP 18271C2 (idx 155, type 54) [ 4873.532315] tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [ 4873.532319] tveeprom 1-0050: audio processor is SAA7131 (idx 41) [ 4873.532323] tveeprom 1-0050: decoder processor is SAA7131 (idx 35) [ 4873.532327] tveeprom 1-0050: has radio, has IR receiver, has no IR transmitter [ 4873.532330] saa7133[0]: hauppauge eeprom: model=67209 [ 4873.589133] tuner 1-004b: chip found @ 0x96 (saa7133[0]) [ 4873.668026] tda829x 1-004b: setting tuner address to 60 [ 4873.718881] tda18271 1-0060: creating new instance [ 4873.764019] TDA18271HD/C2 detected @ 1-0060 [ 4875.097022] tda18271: performing RF tracking filter calibration [ 4893.348022] tda18271: RF tracking filter calibration complete [ 4893.404025] tda829x 1-004b: type set to tda8290+18271 [ 4897.916287] saa7133[0]: dsp access error [ 4897.916295] saa7133[0]: dsp access error [ 4897.916357] saa7133[0]: dsp access error [ 4897.916362] saa7133[0]: dsp access error [ 4897.985132] saa7133[0]: registered device video0 [v4l2] [ 4897.985180] saa7133[0]: registered device vbi0 [ 4897.985224] saa7133[0]: registered device radio0 [ 4898.050069] dvb_init() allocating 1 frontend [ 4898.392023] tda829x 1-004b: type set to tda8290 [ 4898.408174] tda18271 1-0060: attaching existing instance [ 4898.408182] DVB: registering new adapter (saa7133[0]) [ 4898.408188] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [ 4898.872020] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [ 4898.872032] saa7134 :05:09.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 4898.875233] tda10048_firmware_upload: firmware read 24878 bytes. [ 4898.875240] tda10048_firmware_upload: firmware uploading [ 4902.996032] tda10048_firmware_upload: firmware uploaded [ 4904.436023] tda18271_write_regs: [1-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 4904.436031] tda18271c2_rf_tracking_filters_correction: [1-0060|M] error -5 on line 266 [ 4904.525056] tda18271_write_regs: [1-0060|M] ERROR: idx = 0x10, len = 1, i2c_transfer returned: -5 [ 4904.525066] tda18271_channel_configuration
[PATCH] VIDEO: ivtvfb, remove unneeded NULL test
Stanse found that in ivtvfb_callback_cleanup there is an unneeded test
for itv being NULL. But itv is initialized as container_of with
non-zero offset, so it is never NULL (even if v4l2_dev is). This was
found because itv is dereferenced earlier than the test.
Signed-off-by: Jiri Slaby
Cc: Andy Walls
Cc: Mauro Carvalho Chehab
Cc: Tejun Heo
Cc: Ian Armstrong
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
---
drivers/media/video/ivtv/ivtvfb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtvfb.c
b/drivers/media/video/ivtv/ivtvfb.c
index 9ff3425..5dc460e 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1219,7 +1219,7 @@ static int ivtvfb_callback_cleanup(struct device *dev,
void *p)
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
struct osd_info *oi = itv->osd_info;
- if (itv && (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
if (unregister_framebuffer(&itv->osd_info->ivtvfb_info)) {
IVTVFB_WARN("Framebuffer %d is in use, cannot unload\n",
itv->instance);
--
1.7.1
--
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
Support for 0ccd:0072 in em28xx?
Hello, I have a Terratec Cinergy XS Hybrid card [0ccd:0072] that used to be supported by the em28xx-new driver. The project has since been discontinued and the source code is unmaintained and incompatible with current kernels. Happens anyone to be working on supporting my model in the in-kernel em28xx? It seems my card is based on xc5000, which the current code doesn't take in to account :-( I don't care about analog/FM that much, DVB-T is what matters the most. Please CC me in response! Thanks, best regards, -- Luboš Doležel -- 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: [GIT PATCHES FOR 2.6.36] gspca for_2.6.36
On Mon, 21 Jun 2010 22:23:21 -0300 Mauro Carvalho Chehab wrote: > > Jean-François Moine (15): > > gspca - JPEG subdrivers: Don't allocate the JPEG header. > > gspca - stk014: Change the min and default values of the JPEG > > quality. gspca - zc3xx: Change the max and default JPEG qualities. > > gspca - zc3xx: Don't change the registers 7 and 8 for sensor > > pas202b. gspca - zc3xx: Add back the brightness control. > > > gspca: Remove/move useless inclusions of slab.h. > > This patch doesn't seem right. The addition of slab.h were done in > order to allow the removal of the header from some core files. I'm > not sure if all the upstream changes got applied to 2.6.35, but it > seems prudent to wait for a while before just removing the headers, > especially since the slab.h dependency may be different on non-Intel > architectures. > > I'm applying the remaining patches. If you think that this patch is > correct, please re-send it to both LMML and LKML, c/c the authors of > the slab.h removal, in order to get their acks, or, otherwise, please > re-submit it for 2.6.37 window. Hi Mauro, The slab.h dependency was changed in the kernel 2.6.34 and its inclusion in some gspca source files was needed in case of the usage of kmalloc/kfree only. After removing the JPEG header allocation, most gspca subdrivers do not use alloc/free anymore, so, there is no need to include slab.h anymore. On the other side, this patch is easily checked because, if wrong, it raises compilation errors on any architecture. Then, both patches (removal of JPEG alloc/free and slab.h inclusion) should go to 2.6.36. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
