Re: [PATCH] firedtv: refine AVC debugging
Henrik Kurelid wrote: +#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 22) This expression is always true. :-) -- Stefan Richter -=-==--= -=== =---= http://arcgraph.de/sr/ -- 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] firedtv: refine AVC debugging
Henrik Kurelid wrote:
+static int debug_fcp_opcode_flag_set(unsigned int opcode,
+const u8 *data, int length)
+{
+ switch (opcode) {
+ case AVC_OPCODE_VENDOR: break;
+ case AVC_OPCODE_READ_DESCRIPTOR:return avc_debug
AVC_DEBUG_READ_DESCRIPTOR;
+ case AVC_OPCODE_DSIT: return avc_debug
AVC_DEBUG_DSIT;
+ case AVC_OPCODE_DSD:return avc_debug
AVC_DEBUG_DSD;
+ default:return 1;
+ }
+
+ if (length 7 ||
+ data[3] != SFE_VENDOR_DE_COMPANYID_0 ||
+ data[4] != SFE_VENDOR_DE_COMPANYID_1 ||
+ data[5] != SFE_VENDOR_DE_COMPANYID_2)
+ return 1;
+
+ switch (data[6]) {
+ case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return avc_debug
AVC_DEBUG_REGISTER_REMOTE_CONTROL;
+ case SFE_VENDOR_OPCODE_LNB_CONTROL: return avc_debug
AVC_DEBUG_LNB_CONTROL;
+ case SFE_VENDOR_OPCODE_TUNE_QPSK: return avc_debug
AVC_DEBUG_TUNE_QPSK;
+ case SFE_VENDOR_OPCODE_TUNE_QPSK2: return avc_debug
AVC_DEBUG_TUNE_QPSK2;
+ case SFE_VENDOR_OPCODE_HOST2CA: return avc_debug
AVC_DEBUG_HOST2CA;
+ case SFE_VENDOR_OPCODE_CA2HOST: return avc_debug
AVC_DEBUG_CA2HOST;
+ }
+ return 1;
+}
+
static void debug_fcp(const u8 *data, int length)
{
unsigned int subunit_type, subunit_id, op;
const char *prefix = data[0] 7 ? FCP - : FCP - ;
- if (avc_debug AVC_DEBUG_FCP_SUBACTIONS) {
- subunit_type = data[1] 3;
- subunit_id = data[1] 7;
- op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2];
+ subunit_type = data[1] 3;
+ subunit_id = data[1] 7;
+ op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2];
+ if (debug_fcp_opcode_flag_set(op, data, length)) {
printk(KERN_INFO %ssu=%x.%x l=%d: %-8s - %s\n,
[...]
Shouldn't the three return statements in debug_fcp_opcode_flag_set be
'return 0' rather than one?
--
Stefan Richter
-=-==--= -=== =---=
http://arcgraph.de/sr/
--
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: AVerMedia AVerTV GO 007 FM, no radio sound (with routing enabled)
Em Fri, 17 Jul 2009 10:57:38 +0700 Pham Thanh Nam phamthanhnam@gmail.com escreveu: Hi So, should we add an option for this card? For example: modprobe saa7134 card=57 radioontv IMO, we should just apply a patch doing the right thing. I couldn't find any explanation for the change. Let's just fix it with a good explanation and hope that this will work with all AverTV GO 007 FM boards. If not, someone will complain. Cheers, Mauro -- 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] firedtv: refine AVC debugging
Hi,
I gave this some thought when I implemented it. These are should not
happend-situations where the drivers or hardware sends unknown/unimplemented
commands. Rather than making sure that they are never seen in the logs I wanted
them to always be logged (as long as some debug logging is turned
on) since they indicate driver/hw problems.
Do you disagree with my reasoning? I guess that the best would be to make sure
that all unknown messages are always logged as warnings with their
full content.
Regarding your other comment, I will fix that in the next patch version.
Regards,
Henrik
Henrik Kurelid wrote:
+static int debug_fcp_opcode_flag_set(unsigned int opcode,
+const u8 *data, int length) +{
+ switch (opcode) {
+ case AVC_OPCODE_VENDOR: break;
+ case AVC_OPCODE_READ_DESCRIPTOR:return avc_debug
AVC_DEBUG_READ_DESCRIPTOR; + case AVC_OPCODE_DSIT:
return avc_debug AVC_DEBUG_DSIT; + case AVC_OPCODE_DSD:
return avc_debug AVC_DEBUG_DSD; + default:
return 1;
+ }
+
+ if (length 7 ||
+ data[3] != SFE_VENDOR_DE_COMPANYID_0 ||
+ data[4] != SFE_VENDOR_DE_COMPANYID_1 ||
+ data[5] != SFE_VENDOR_DE_COMPANYID_2)
+ return 1;
+
+ switch (data[6]) {
+ case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return avc_debug
AVC_DEBUG_REGISTER_REMOTE_CONTROL; + case
SFE_VENDOR_OPCODE_LNB_CONTROL: return avc_debug
AVC_DEBUG_LNB_CONTROL; + case SFE_VENDOR_OPCODE_TUNE_QPSK:
return avc_debug AVC_DEBUG_TUNE_QPSK; + case
SFE_VENDOR_OPCODE_TUNE_QPSK2: return avc_debug
AVC_DEBUG_TUNE_QPSK2; +
case SFE_VENDOR_OPCODE_HOST2CA: return avc_debug
AVC_DEBUG_HOST2CA; + case SFE_VENDOR_OPCODE_CA2HOST:
return avc_debug AVC_DEBUG_CA2HOST; + }
+ return 1;
+}
+
static void debug_fcp(const u8 *data, int length)
{
unsigned int subunit_type, subunit_id, op;
const char *prefix = data[0] 7 ? FCP - : FCP - ;
- if (avc_debug AVC_DEBUG_FCP_SUBACTIONS) {
- subunit_type = data[1] 3;
- subunit_id = data[1] 7;
- op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2];
+ subunit_type = data[1] 3;
+ subunit_id = data[1] 7;
+ op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2]; +
if (debug_fcp_opcode_flag_set(op, data, length)) {
printk(KERN_INFO %ssu=%x.%x l=%d: %-8s - %s\n,
[...]
Shouldn't the three return statements in debug_fcp_opcode_flag_set be 'return
0' rather than one?
--
Stefan Richter
-=-==--= -=== =---=
http://arcgraph.de/sr/
--
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
--
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
Omap34xx and OV5620
Sergio, Success, I was able to capture data from the OV5620 using the omap34xxcam and isp. The problem I was was having was due to several wrong setups (all my fault of course :) I am using the v4l2 example code. The code wanted YUYV and Interlaced. I changed it to the SGBRG10 and FIELD_NONE and I started getting VD1 interrupts. I read through the isr in isp.c and saw that in raw mode it wanted a VD0. I changed that to VD1 and then got a message stating the wait was too long :( At that point I made the sensor send 1280x 1024 data instead of 640x 480. Now i was getting VD0 and VD1 interrupts. Changed the isp.c back to the original code and voila. Images. So i saved a buffer to a file and converted the data to 8-bit data I saw my first mono image. Now I would like to be able to have a YUYV output pixelformat and let the isp engine do all the conversion for me. The datasheet says this is possible and the code seems to support it, but I am not getting interrupts for it. So here is my new questions: Is converting from raw to YUYV possible in hardware on the omap34xx Specifically omap3530 If so do you think that having the interrupts print is causing the isr to miss other interrupts. Thanks, John Sarman -- 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] firedtv: refine AVC debugging
On 17 Jul, Henrik Kurelid wrote:
[I wrote]
Shouldn't the three return statements in debug_fcp_opcode_flag_set be
'return 0' rather than one?
I gave this some thought when I implemented it. These are should not
happend-situations where the drivers or hardware sends unknown/
unimplemented commands. Rather than making sure that they are never
seen in the logs I wanted them to always be logged (as long as some
debug logging is turned on) since they indicate driver/hw problems.
Ah, that's why. Could be documented:
static int debug_fcp_opcode_flag_set(unsigned int opcode,
const u8 *data, int length)
{
switch (opcode) {
case AVC_OPCODE_VENDOR: break;
case AVC_OPCODE_READ_DESCRIPTOR:return avc_debug
AVC_DEBUG_READ_DESCRIPTOR;
case AVC_OPCODE_DSIT: return avc_debug
AVC_DEBUG_DSIT;
case AVC_OPCODE_DSD:return avc_debug
AVC_DEBUG_DSD;
default:goto unknown_opcode;
}
if (length 7 ||
data[3] != SFE_VENDOR_DE_COMPANYID_0 ||
data[4] != SFE_VENDOR_DE_COMPANYID_1 ||
data[5] != SFE_VENDOR_DE_COMPANYID_2)
goto unknown_opcode;
switch (data[6]) {
case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return avc_debug
AVC_DEBUG_REGISTER_REMOTE_CONTROL;
case SFE_VENDOR_OPCODE_LNB_CONTROL: return avc_debug
AVC_DEBUG_LNB_CONTROL;
case SFE_VENDOR_OPCODE_TUNE_QPSK: return avc_debug
AVC_DEBUG_TUNE_QPSK;
case SFE_VENDOR_OPCODE_TUNE_QPSK2: return avc_debug
AVC_DEBUG_TUNE_QPSK2;
case SFE_VENDOR_OPCODE_HOST2CA: return avc_debug
AVC_DEBUG_HOST2CA;
case SFE_VENDOR_OPCODE_CA2HOST: return avc_debug
AVC_DEBUG_CA2HOST;
}
unknown_opcode: /* should never happen, log it */
return 1;
}
By the way, from here it looks as if your MUA converted tabs to spaces.
In your other patch too.
--
Stefan Richter
-=-==--= -=== =---=
http://arcgraph.de/sr/
--
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] firedtv: refine AVC debugging
On 17 Jul, Henrik Kurelid wrote:
[I wrote]
Shouldn't the three return statements in debug_fcp_opcode_flag_set be
'return 0' rather than one?
I gave this some thought when I implemented it. These are should not
happend-situations where the drivers or hardware sends unknown/
unimplemented commands. Rather than making sure that they are never
seen in the logs I wanted them to always be logged (as long as some
debug logging is turned on) since they indicate driver/hw problems.
Ah, that's why. Could be documented:
static int debug_fcp_opcode_flag_set(unsigned int opcode,
const u8 *data, int length)
{
switch (opcode) {
case AVC_OPCODE_VENDOR: break;
case AVC_OPCODE_READ_DESCRIPTOR:return avc_debug
AVC_DEBUG_READ_DESCRIPTOR;
case AVC_OPCODE_DSIT: return avc_debug
AVC_DEBUG_DSIT;
case AVC_OPCODE_DSD:return avc_debug
AVC_DEBUG_DSD;
default:goto unknown_opcode;
}
if (length 7 ||
data[3] != SFE_VENDOR_DE_COMPANYID_0 ||
data[4] != SFE_VENDOR_DE_COMPANYID_1 ||
data[5] != SFE_VENDOR_DE_COMPANYID_2)
goto unknown_opcode;
switch (data[6]) {
case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return avc_debug
AVC_DEBUG_REGISTER_REMOTE_CONTROL;
case SFE_VENDOR_OPCODE_LNB_CONTROL: return avc_debug
AVC_DEBUG_LNB_CONTROL;
case SFE_VENDOR_OPCODE_TUNE_QPSK: return avc_debug
AVC_DEBUG_TUNE_QPSK;
case SFE_VENDOR_OPCODE_TUNE_QPSK2: return avc_debug
AVC_DEBUG_TUNE_QPSK2;
case SFE_VENDOR_OPCODE_HOST2CA: return avc_debug
AVC_DEBUG_HOST2CA;
case SFE_VENDOR_OPCODE_CA2HOST: return avc_debug
AVC_DEBUG_CA2HOST;
}
unknown_opcode: /* should never happen, log it */
return 1;
}
By the way, from here it looks as if your MUA converted tabs to spaces.
In your other patch too.
--
Stefan Richter
-=-==--= -=== =---=
http://arcgraph.de/sr/
--
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:Fri Jul 17 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12270:d754a2d5a376 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc1-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc1-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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 0/3] ir-kbd-i2c, cx18: IR devices for CX23418 boards
Jean, The following patch series is my preliminary cut at getting the cx18 bridge driver supported IR devices set up properly by the cx18 driver to allow use by ir-kbd-i2c, lirc_i2c, lirc_pvr150, and lirc_zilog for both old and new (= 2.6.30) kernels. They are: 1/3: ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type 2/3: cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers 3/3: ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers Please take a look and tell me what's wrong. I put specific points of concern I have before each patch. If this works for both ir-kbd-i2c and lirc_*, then I can add similar logic to fix up ivtv (at least for Zilog Z8 microcontroller IR devices). Regards, Andy -- 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 2/3] 2/3: cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers
This patch add support to the cx18 driver for setting up the
Z8F0811/Hauppauge IR Tx/Rx chip with the i2c binding model in newer
kernels.
My concerns/questions:
1. When using the new i2c binding model, I'm not saving the returned
pointer from i2c_new_probed_device() and am hence taking no action on
trying to clean up IR i2c devices on module unload. Will the i2c
subsystem clean up this automatically when the adapter is unregistered
on module unload?
2. When using the new i2c binding model, I'm calling
i2c_new_probed_device() twice: once for Rx (addr 0x71 of the Z8F0811)
and another time for Tx (addr 0x70 of the Z8F0811). Is it a problem to
have two Linux i2c devices for two distinct addresses of the same
underlying hardware device?
3. When using the new i2c binding model, I opted not to use ir_video for
the Z8F0811 loaded with microcode from Zilog/Hauppauge. Since I needed
one name for Rx binding and one for Tx binding, I used these names:
ir_tx_z8f0811_haup
ir_rx_z8f0811_haup
[Which is ir_(func)_(part number)_(firmware_oem)]. It made sense to me.
I assume these are the names to which ir-kbd-i2c and lirc_* will have to
bind. Is that correct?
Regards,
Andy
diff -r d754a2d5a376 linux/drivers/media/video/cx18/cx18-cards.c
--- a/linux/drivers/media/video/cx18/cx18-cards.c Wed Jul 15 07:28:02
2009 -0300
+++ b/linux/drivers/media/video/cx18/cx18-cards.c Fri Jul 17 16:05:28
2009 -0400
@@ -56,7 +56,8 @@
.hw_audio_ctrl = CX18_HW_418_AV,
.hw_muxer = CX18_HW_CS5345,
.hw_all = CX18_HW_TVEEPROM | CX18_HW_418_AV | CX18_HW_TUNER |
- CX18_HW_CS5345 | CX18_HW_DVB | CX18_HW_GPIO_RESET_CTRL,
+ CX18_HW_CS5345 | CX18_HW_DVB | CX18_HW_GPIO_RESET_CTRL |
+ CX18_HW_Z8F0811_IR_HAUP,
.video_inputs = {
{ CX18_CARD_INPUT_VID_TUNER, 0, CX18_AV_COMPOSITE7 },
{ CX18_CARD_INPUT_SVIDEO1,1, CX18_AV_SVIDEO1},
@@ -102,7 +103,8 @@
.hw_audio_ctrl = CX18_HW_418_AV,
.hw_muxer = CX18_HW_CS5345,
.hw_all = CX18_HW_TVEEPROM | CX18_HW_418_AV | CX18_HW_TUNER |
- CX18_HW_CS5345 | CX18_HW_DVB | CX18_HW_GPIO_RESET_CTRL,
+ CX18_HW_CS5345 | CX18_HW_DVB | CX18_HW_GPIO_RESET_CTRL |
+ CX18_HW_Z8F0811_IR_HAUP,
.video_inputs = {
{ CX18_CARD_INPUT_VID_TUNER, 0, CX18_AV_COMPOSITE7 },
{ CX18_CARD_INPUT_SVIDEO1,1, CX18_AV_SVIDEO1},
diff -r d754a2d5a376 linux/drivers/media/video/cx18/cx18-cards.h
--- a/linux/drivers/media/video/cx18/cx18-cards.h Wed Jul 15 07:28:02
2009 -0300
+++ b/linux/drivers/media/video/cx18/cx18-cards.h Fri Jul 17 16:05:28
2009 -0400
@@ -22,13 +22,17 @@
*/
/* hardware flags */
-#define CX18_HW_TUNER (1 0)
-#define CX18_HW_TVEEPROM (1 1)
-#define CX18_HW_CS5345 (1 2)
-#define CX18_HW_DVB(1 3)
-#define CX18_HW_418_AV (1 4)
-#define CX18_HW_GPIO_MUX (1 5)
-#define CX18_HW_GPIO_RESET_CTRL(1 6)
+#define CX18_HW_TUNER (1 0)
+#define CX18_HW_TVEEPROM (1 1)
+#define CX18_HW_CS5345 (1 2)
+#define CX18_HW_DVB(1 3)
+#define CX18_HW_418_AV (1 4)
+#define CX18_HW_GPIO_MUX (1 5)
+#define CX18_HW_GPIO_RESET_CTRL(1 6)
+#define CX18_HW_Z8F0811_IR_TX_HAUP (1 7)
+#define CX18_HW_Z8F0811_IR_RX_HAUP (1 8)
+#define CX18_HW_Z8F0811_IR_HAUP(CX18_HW_Z8F0811_IR_RX_HAUP | \
+CX18_HW_Z8F0811_IR_TX_HAUP)
/* video inputs */
#defineCX18_CARD_INPUT_VID_TUNER 1
diff -r d754a2d5a376 linux/drivers/media/video/cx18/cx18-i2c.c
--- a/linux/drivers/media/video/cx18/cx18-i2c.c Wed Jul 15 07:28:02 2009 -0300
+++ b/linux/drivers/media/video/cx18/cx18-i2c.c Fri Jul 17 16:05:28 2009 -0400
@@ -40,16 +40,20 @@
#define GETSDL_BIT 0x0008
#define CX18_CS5345_I2C_ADDR 0x4c
+#define CX18_Z8F0811_IR_TX_I2C_ADDR0x70
+#define CX18_Z8F0811_IR_RX_I2C_ADDR0x71
/* This array should match the CX18_HW_ defines */
static const u8 hw_addrs[] = {
- 0, /* CX18_HW_TUNER */
- 0, /* CX18_HW_TVEEPROM */
- CX18_CS5345_I2C_ADDR, /* CX18_HW_CS5345 */
- 0, /* CX18_HW_DVB */
- 0, /* CX18_HW_418_AV */
- 0, /* CX18_HW_GPIO_MUX */
- 0, /* CX18_HW_GPIO_RESET_CTRL */
+ 0, /* CX18_HW_TUNER */
+ 0, /* CX18_HW_TVEEPROM */
+ CX18_CS5345_I2C_ADDR, /* CX18_HW_CS5345 */
+ 0, /* CX18_HW_DVB */
+ 0, /* CX18_HW_418_AV */
+ 0, /* CX18_HW_GPIO_MUX */
+ 0, /*
[PATCH 3/3] ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers
This patch adds support for Zilog Z8F0811 IR transceiver chips on
CX2341[68] based boards to ir-kbd-i2c for both the old i2c binding model
and the new i2c binding model.
Regards,
Andy
diff -r d754a2d5a376 linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.cWed Jul 15 07:28:02 2009 -0300
+++ b/linux/drivers/media/video/ir-kbd-i2c.cFri Jul 17 16:05:28 2009 -0400
@@ -442,9 +442,11 @@
case 0x47:
case 0x71:
case 0x2d:
- if (adap-id == I2C_HW_B_CX2388x) {
+ if (adap-id == I2C_HW_B_CX2388x ||
+ adap-id == I2C_HW_B_CX2341X) {
/* Handled by cx88-input */
- name= CX2388x remote;
+ name = adap-id == I2C_HW_B_CX2341X ? CX2341x remote
+ : CX2388x remote;
ir_type = IR_TYPE_RC5;
ir-get_key = get_key_haup_xvr;
if (hauppauge == 1) {
@@ -697,7 +726,8 @@
static const struct i2c_device_id ir_kbd_id[] = {
/* Generic entry for any IR receiver */
{ ir_video, 0 },
- /* IR device specific entries could be added here */
+ /* IR device specific entries should be added here */
+ { ir_rx_z8f0811_haup, 0 },
{ }
};
--
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 0/2] gspca sn9c20x subdriver rev2
Mauro, Here is the updated version of the gspca sn9c20x subdriver. I've removed the custom debugging support and replaced it with support for the v4l2 debugging ioctls. The first patch in this set adds support to the gspca core for those ioctls. Also included are the fixes Hans sent in his last email. Regards, Brian Johnson -- 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 1/2] gspca: add support for v4l2 debugging ioctls
This patch adds support for dbg_g_chip_ident, dbg_g_register,
and dbg_s_register to the gspca core module.
Signed-off-by: Brian Johnson brij...@gmail.com
---
drivers/media/video/gspca/gspca.c | 73 +
drivers/media/video/gspca/gspca.h |7
2 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 1e89600..b8561df 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -727,6 +727,74 @@ static int gspca_get_mode(struct gspca_dev *gspca_dev,
return -EINVAL;
}
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int vidioc_g_register(struct file *file, void *priv,
+ struct v4l2_dbg_register *reg)
+{
+ int ret;
+ struct gspca_dev *gspca_dev = priv;
+
+ if (!gspca_dev-sd_desc-get_chip_ident)
+ return -EINVAL;
+
+ if (!gspca_dev-sd_desc-get_register)
+ return -EINVAL;
+
+ if (mutex_lock_interruptible(gspca_dev-usb_lock))
+ return -ERESTARTSYS;
+ if (gspca_dev-present)
+ ret = gspca_dev-sd_desc-get_register(gspca_dev, reg);
+ else
+ ret = -ENODEV;
+ mutex_unlock(gspca_dev-usb_lock);
+
+ return ret;
+}
+
+static int vidioc_s_register(struct file *file, void *priv,
+ struct v4l2_dbg_register *reg)
+{
+ int ret;
+ struct gspca_dev *gspca_dev = priv;
+
+ if (!gspca_dev-sd_desc-get_chip_ident)
+ return -EINVAL;
+
+ if (!gspca_dev-sd_desc-set_register)
+ return -EINVAL;
+
+ if (mutex_lock_interruptible(gspca_dev-usb_lock))
+ return -ERESTARTSYS;
+ if (gspca_dev-present)
+ ret = gspca_dev-sd_desc-set_register(gspca_dev, reg);
+ else
+ ret = -ENODEV;
+ mutex_unlock(gspca_dev-usb_lock);
+
+ return ret;
+}
+#endif
+
+static int vidioc_g_chip_ident(struct file *file, void *priv,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ int ret;
+ struct gspca_dev *gspca_dev = priv;
+
+ if (!gspca_dev-sd_desc-get_chip_ident)
+ return -EINVAL;
+
+ if (mutex_lock_interruptible(gspca_dev-usb_lock))
+ return -ERESTARTSYS;
+ if (gspca_dev-present)
+ ret = gspca_dev-sd_desc-get_chip_ident(gspca_dev, chip);
+ else
+ ret = -ENODEV;
+ mutex_unlock(gspca_dev-usb_lock);
+
+ return ret;
+}
+
static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *fmtdesc)
{
@@ -1883,6 +1951,11 @@ static const struct v4l2_ioctl_ops dev_ioctl_ops = {
.vidioc_s_parm = vidioc_s_parm,
.vidioc_s_std = vidioc_s_std,
.vidioc_enum_framesizes = vidioc_enum_framesizes,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+ .vidioc_g_register = vidioc_g_register,
+ .vidioc_s_register = vidioc_s_register,
+#endif
+ .vidioc_g_chip_ident= vidioc_g_chip_ident,
#ifdef CONFIG_VIDEO_V4L1_COMPAT
.vidiocgmbuf = vidiocgmbuf,
#endif
diff --git a/drivers/media/video/gspca/gspca.h
b/drivers/media/video/gspca/gspca.h
index bd1faff..4f2a873 100644
--- a/drivers/media/video/gspca/gspca.h
+++ b/drivers/media/video/gspca/gspca.h
@@ -69,6 +69,10 @@ typedef void (*cam_v_op) (struct gspca_dev *);
typedef int (*cam_cf_op) (struct gspca_dev *, const struct usb_device_id *);
typedef int (*cam_jpg_op) (struct gspca_dev *,
struct v4l2_jpegcompression *);
+typedef int (*cam_reg_op) (struct gspca_dev *,
+ struct v4l2_dbg_register *);
+typedef int (*cam_ident_op) (struct gspca_dev *,
+ struct v4l2_dbg_chip_ident *);
typedef int (*cam_streamparm_op) (struct gspca_dev *,
struct v4l2_streamparm *);
typedef int (*cam_qmnu_op) (struct gspca_dev *,
@@ -105,6 +109,9 @@ struct sd_desc {
cam_qmnu_op querymenu;
cam_streamparm_op get_streamparm;
cam_streamparm_op set_streamparm;
+ cam_reg_op set_register;
+ cam_reg_op get_register;
+ cam_ident_op get_chip_ident;
};
/* packet types when moving from iso buf to frame buf */
--
1.5.6.3
--
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
DM04+ USB DVB-S adapter
Hello, Does anyone know if there is a driver for this cheap USB DVB-S device? It's only $35 USD on Ebay. I didn't find any info with Google. Model Name: DM04+ (or sometimes listed as DM04) Manufacturer: Forwardvideo (HK) Co., Ltd. Manufacturer Ref.: EQZ2SH5473Y6 Pictures Specs: http://www.esaleschina.com/universal-satellite-tv-receiver-for-pc-dvb-s-69.htm Also shown here: http://www.made-in-china.com/china-products/productviewFejJxqRbbpcr/Digital-Satellite-USB2-0-TV-Box-DM04-.html For sale on Ebay ($35 USD): http://cgi.ebay.com/Digital-USB-DVB-S-TV-Tuner-Box-Satellite-For-PC-Laptop_W0QQitemZ320390301313QQcmdZViewItemQQptZPCC_Video_TV_Cards This product is also being sold on ebay with the moniker T-4. By looking at the paper manual in the picture, one can see that it is really the DM04+: http://cgi.ebay.com/Digital-USB-DVB-S-Satellite-TV-HDTV-Tuner-Box-PC-T-4_W0QQitemZ110414242097QQcategoryZ3761QQcmdZViewItem Beware: there is another DM04 product from China which looks different. Model Name: DM04 Manufacturer: Shenzhen Forward Video Co., Ltd. Pictures Specs: http://www.tootoo.com/d-rp14452556-USB_2_0_Digital_Sat_TV_Box_DM04_/ I think this may have been an older version of the DM04+, because instead of Recommends WinXP it says IBM PC Compatible: Pentium III 667MHz, with 128 MB RAM. Perhaps the + (plus) indicates the newer version of the product. Also, note the company name is roughly the same for both products (Forward Video). Any help or info is greatly appreciated. Thanks, Derek Simkowiak -- 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] saa7134 - ir remote for sinovideo 1300
James Guo jin...@yahoo.com writes: Have a tv tuner believe to be sinovideo 1300, and the remote has h-338 in the back, the tuner is detected as saa7134 proteus 2309, and working fine, the patch is for the remote. following buttons supposed to be working: all the number button, channel up and down, volumn up and down, off, mute, full screen, recall, snapshot, tv. Some buttons do not have valid entry for tvtime, so I did not map them(record, stop ...) to apply, use command modprobe saa7134 card=157 if it does not work, use modprobe saa7134 card=157 ir_debug=1 and send me the output of dmesg(after modprobe and after a button is pressed) I think we should add something printing changes on the GPIO line (and current time). That should be easy, will try to have something soon. That would show what code exactly a remote is using, at last. -- Krzysztof Halasa -- 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: AVerMedia AVerTV GO 007 FM, no radio sound (with routing enabled)
Hi,
Am Freitag, den 17.07.2009, 05:19 -0300 schrieb Mauro Carvalho Chehab:
Em Fri, 17 Jul 2009 10:57:38 +0700
Pham Thanh Nam phamthanhnam@gmail.com escreveu:
Hi
So, should we add an option for this card? For example:
modprobe saa7134 card=57 radioontv
IMO, we should just apply a patch doing the right thing.
I couldn't find any explanation for the change. Let's just fix it with a good
explanation and hope that this will work with all AverTV GO 007 FM boards. If
not, someone will complain.
Cheers,
Mauro
have looked up some details and agree with Mauro here.
First, Avermedia cards on the saa7134 driver are all identified safely
by PCI subsystem. No problems and we deal with GO 007 FM tda8275c1 and
not the later tda8275ac1.
Assaf reported the radio working, _but later_ he reported also that the
frequencies are off. I saw the same later too and lots of ghosting radio
stations with Asus P7131 Dual until Hartmut added radio IF support for
saa7133/35/31e and all tda8290 tuners with the 5.5MHz filter.
LINE1 was never changed for radio on the GO 007. Assaf's patch came in
with a bunch of patches Nickolay collected that time.
http://linuxtv.org/hg/v4l-dvb/rev/291d5d1089eb
Then Hartmut added correct basic radio IF support and I guess this did
break the previous ghost radio.
http://linuxtv.org/hg/v4l-dvb/rev/b9edd4165113
Else there was only this change unrelated to radio.
hg export 5481
# HG changeset patch
# User Mauro Carvalho Chehab mche...@infradead.org
# Date 1175168859 10800
# Node ID 9f42fb6940eeaa63305b1048811ea25d74c9e806
# Parent bcf83c0130363da08eabac5092013ed6fec1d9eb
4linux: Fix audio input for AverTv Go 007
From: Damian Minkov damen...@damencho.com
Fix audio input source for capturing(playing) audio on AverTv Go 007 cards.
Signed-off-by: Damian Minkov damen...@damencho.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Mauro Carvalho Chehab mche...@infradead.org
diff -r bcf83c013036 -r 9f42fb6940ee
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 29 08:47:04
2007 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 29 08:47:39
2007 -0300
@@ -1544,12 +1544,12 @@
},{
.name = name_comp1,
.vmux = 0,
- .amux = LINE2,
+ .amux = LINE1,
.gpio = 0x02,
},{
.name = name_svideo,
.vmux = 6,
- .amux = LINE2,
+ .amux = LINE1,
.gpio = 0x02,
}},
.radio = {
--
And furthermore it has .gpiomask = 0x0033
and gpio21 is set high for radio and low for TV.
.radio = {
.name = name_radio,
.amux = LINE1,
.gpio = 0x0031,
},
That is why changing the radio amux to TV just works.
Cheers,
Hermann
--
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] Implement V4L2_CAP_STREAMING for zr364xx driver
Hi,
Lamarque Vieira Souza wrote:
Em Quinta-feira 16 Julho 2009, Mauro Carvalho Chehab escreveu:
Em Wed, 15 Jul 2009 20:54:55 -0300
[...]
+ if (pipe_info-state != 0) {
+ if (usb_submit_urb(pipe_info-stream_urb, GFP_KERNEL))
+ dev_err(cam-udev-dev, error submitting urb\n);
+ } else {
+ DBG(read pipe complete state 0\n);
+ }
Hmm... for the usb_submit_urb() call that happens during IRQ context
(while you're receiving stream), you need to use:
urb-status = usb_submit_urb(pipe_info-stream_urb, GFP_ATOMIC);
otherwise, you may get the errors that Antoine is reporting
Ok, changed to GPF_ATOMIC. Could someone test this for me since I was not
able to reproduce this problem? The new patch is here
http://bach.metasys.com.br/~lamarque/zr364xx/zr364xx.c-streaming.patch-v4l-
dvb-20090716 . I upload it to avoid bloating the mailing-list with a 40k
patch.
I confirm it fixes the issue.
I will upload the patch to my branch and send a pull request to Mauro.
Thanks and best regards,
Antoine
--
Antoine Royale Jacquet
http://royale.zerezo.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
[PULL] http://linuxtv.org/hg/~ajacquet/v4l-dvb/
Mauro, Please pull from http://linuxtv.org/hg/~ajacquet/v4l-dvb for the following changeset: 01/01: zr364xx: implement V4L2_CAP_STREAMING http://linuxtv.org/hg/~ajacquet/v4l-dvb?cmd=changeset;node=3d99e4f816e5 zr364xx.c | 1209 +- 1 file changed, 960 insertions(+), 249 deletions(-) Thanks, Antoine -- 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: Report: Compro Videomate Vista T750F
Am Mittwoch, den 15.07.2009, 20:35 +0200 schrieb Samuel Rakitnican: On Sun, 12 Jul 2009 23:33:06 +0200, hermann pitton hermann-pit...@arcor.de wrote: Hi Samuel, Am Sonntag, den 12.07.2009, 13:30 +0200 schrieb Samuel Rakitnican: As the card=139 (Compro Videomate T750) DVB: Not working, not implemented Analog: Not working Audio In: ? (my T750F has additional connector ?) if amux LINE2 doesn't work it is usually LINE1. If both don't work, there is a external gpio controlled switch/mux chip. Default is loop through for external audio in. Means, if the saa7134 driver is unloaded, should be passed through to audio out. If not, there is such a mux chip involved. [snip] Well, I haven't managed to get sound from Audio In connector, it's possible however that I'm doing something wrong. I tried selecting in tvtime both Composite and S-Video, and I've tried using SoX: console$ ls /dev/dsp* dsp dsp1 console$ sox -c 2 -s -r 32000 -t ossdsp /dev/dsp1 -t ossdsp -r 32000 /dev/dsp for both .amux = LINE1 and LINE2 in saa7134-cards.c source file. RegSpy log: I have used RegSpy that comes with DScaler version 4.1.15. I'm hoping that they are of some use for both Analog television and Audio In. I have found out values crucial to changing inputs for both audio and video. Note that SAA7134_GPIO_GPSTATUS keeps changing all the time between 84ff00 and 94bf00 nevertheless of the device status. I have used VirtualDub (v1.7.7) as capturing application because it gives more control on input selecting (I can change audio input, not depending on video). From that I manage to distinguish values changing between video and audio. The crucial value for video seems to be SAA7134_ANALOG_IN_CTRL1 while for audio seems to be values SAA7133_AUDIO_CLOCK_NOMINAL and SAA7133_PLL_CONTROL. Changes: State 0 - State 1: *(Switch: Analog TV - Composite) SAA7134_GPIO_GPSTATUS: 0094ff00 - 0494ff00 (-0-- ) SAA7134_ANALOG_IN_CTRL1: 83 - 81(--1-) SAA7133_AUDIO_CLOCK_NOMINAL: 03187de7 - 43187de7 (-0-- ) SAA7133_PLL_CONTROL: 03 - 43(-0--) Changes: State 1 - State 2: *(Switch: Composite - S-Video) SAA7134_GPIO_GPSTATUS: 0494ff00 - 0284ff00 (-10- ---1 ) SAA7134_ANALOG_IN_CTRL1: 81 - 88(0--1) Changes: State 2 - State 3: ***(Switch: Audio Source - Audio Tuner (Still in S-Video mode)) SAA7134_GPIO_GPSTATUS: 0284ff00 - 0294ff00 ( ---0 ) SAA7133_AUDIO_CLOCK_NOMINAL: 43187de7 - 03187de7 (-1-- ) (same as 0) SAA7133_PLL_CONTROL: 43 - 03 (-1--) (same as 0) Changes: State 3 - State 4: **(Switch: Audio Source - Audio Line (Still in S-Video mode)) SAA7134_GPIO_GPSTATUS: 0294ff00 - 0484ff00 (-01- ---1 ) SAA7133_AUDIO_CLOCK_NOMINAL: 03187de7 - 43187de7 (-0-- ) (same as 1, 2) SAA7133_PLL_CONTROL: 03 - 43 (-0--) (same as 1, 2) (full log: http://pastebin.com/f5f8e6184) Hi Samuel, the above link still gives error not found. For an external audio mux it is always a single gpio pin for that. It is some same pin in the same state for composite and s-video, but different for TV mode. The above seems not to show such a pattern. Also you missed to print GPIO_GPMODE, which is the gpio mask. In that, pins actively used for switching are high, but m$ drivers do often also have for that specific card unrelated pins high. Gpio 8 to 15 are the remote gpios and gpio18 should be the key press/release. The rest above seems not to be consistent for what we are searching for. If you get some time again, do a cold boot and dump the gpio mode and state before any application did use the card. Then dump analog TV, composite and s-video and anything else you can test. The GPMODE and the GPSTATUS on top of any mode used is what is really interesting. It also prints the state of all gpios for each mode in binary, so if you manually mark the states you used, one can just copy and paste line by line and see the changing pins. As said, it should be a pin in the mask/GPMODE being the same for composite and s-video, but different for analog TV. Maybe better use the Compro software to get the logs. Cheers, Hermann -- 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] saa7134 - ir remote for sinovideo 1300
Have a tv tuner believe to be sinovideo 1300, and the remote has h-338 in the
back, the tuner is detected as saa7134 proteus 2309, and working fine, the
patch is for the remote.
following buttons supposed to be working: all the number button, channel up and
down, volumn up and down, off, mute, full screen, recall, snapshot, tv. Some
buttons do not have valid entry for tvtime, so I did not map them(record, stop
...)
to apply, use command
modprobe saa7134 card=157
if it does not work, use
modprobe saa7134 card=157 ir_debug=1
and send me(yahoo.com) the output of dmesg(after modprobe and after a button is
pressed)
--- a/include/media/ir-common.h2009-07-08 19:28:50.0 -0400
+++ b/include/media/ir-common.h2009-07-16 01:37:41.0 -0400
@@ -162,6 +162,7 @@
extern IR_KEYTAB_TYPE ir_codes_kworld_plus_tv_analog[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_kaiomy[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_dm1105_nec[IR_KEYTAB_SIZE];
+extern IR_KEYTAB_TYPE ir_codes_sinovideo_1300[IR_KEYTAB_SIZE];
#endif
/*
--- a/drivers/media/common/ir-keymaps.c2009-07-08 19:28:49.0 -0400
+++ b/drivers/media/common/ir-keymaps.c2009-07-16 13:17:30.0 -0400
@@ -62,6 +62,38 @@
};
EXPORT_SYMBOL_GPL(ir_codes_proteus_2309);
+
+IR_KEYTAB_TYPE ir_codes_sinovideo_1300[IR_KEYTAB_SIZE] = {
+/* numeric */
+[ 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,
+
+[ 0x5c ] = KEY_POWER, /* power */
+[ 0x20 ] = KEY_F, /* full screen */
+[ 0x0f ] = KEY_BACKSPACE, /* recall */
+[ 0x1b ] = KEY_M, /* mute*/
+[ 0x41 ] = KEY_RECORD,/* record */
+[ 0x43 ] = KEY_STOP, /* stop*/
+[ 0x16 ] = KEY_S, /* snapshot*/
+[ 0x1a ] = KEY_Q, /* off */
+[ 0x2e ] = KEY_RED,
+[ 0x1f ] = KEY_DOWN, /* channel - */
+[ 0x1c ] = KEY_UP,/* channel + */
+[ 0x10 ] = KEY_LEFT, /* volume -*/
+[ 0x1e ] = KEY_RIGHT, /* volume +*/
+[ 0x14 ] = KEY_F1,
+[ 0x15 ] = KEY_I, /* tv */
+};
+
+EXPORT_SYMBOL_GPL(ir_codes_sinovideo_1300);
/* Matt Jesson d...@jesson.eclipse.co.uk */
IR_KEYTAB_TYPE ir_codes_avermedia_dvbt[IR_KEYTAB_SIZE] = {
[ 0x28 ] = KEY_0, //'0' / 'enter'
--- a/drivers/media/video/saa7134/saa7134-cards.c2009-07-08
19:28:49.0 -0400
+++ b/drivers/media/video/saa7134/saa7134-cards.c2009-07-15
22:37:16.0 -0400
@@ -4744,6 +4744,37 @@
.gpio = 0x01,
},
},
+[SAA7134_BOARD_SINOVIDEO_1300] = {
+.name = Sinovideo 1300,
+.audio_clock= 0x00187de7,
+.tuner_type= TUNER_PHILIPS_FM1216ME_MK3,
+.radio_type = UNSET,
+.tuner_addr= ADDR_UNSET,
+.radio_addr= ADDR_UNSET,
+.tda9887_conf = TDA9887_PRESENT,
+.inputs = {{
+.name = name_tv,
+.vmux = 1,
+.amux = LINE2,
+.tv = 1,
+},{
+.name = name_comp1,
+.vmux = 0,
+.amux = LINE2,
+},{
+.name = name_comp2,
+.vmux = 3,
+.amux = LINE2,
+},{
+.name = name_svideo,
+.vmux = 8,
+.amux = LINE2,
+}},
+.mute = {
+.name = name_mute,
+.amux = LINE1,
+},
+},
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -5838,6 +5869,12 @@
.subvendor= 0x1461, /* Avermedia Technologies Inc */
.subdevice= 0xf31d,
.driver_data = SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS,
+},{
+.vendor = PCI_VENDOR_ID_PHILIPS,
+.device = PCI_DEVICE_ID_PHILIPS_SAA7130,
+.subvendor= 0x0919,
+.subdevice= 0x2003,
+.driver_data = SAA7134_BOARD_SINOVIDEO_1300,
}, {
/* --- boards without eeprom + subsystem ID --- */
@@ -6133,6 +6170,7 @@
case SAA7134_BOARD_REAL_ANGEL_220:
case SAA7134_BOARD_KWORLD_PLUS_TV_ANALOG:
case SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS:
+case SAA7134_BOARD_SINOVIDEO_1300:
dev-has_remote = SAA7134_REMOTE_GPIO;
break;
case SAA7134_BOARD_FLYDVBS_LR300:
--- a/drivers/media/video/saa7134/saa7134.h2009-07-08 19:28:49.0
-0400
+++ b/drivers/media/video/saa7134/saa7134.h2009-07-16 15:31:54.0
-0400
@@ -280,6 +280,7 @@
#define SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS 154
#define SAA7134_BOARD_HAUPPAUGE_HVR1120 155
#define SAA7134_BOARD_HAUPPAUGE_HVR1110R3 156
+#define SAA7134_BOARD_SINOVIDEO_1300 157
#define SAA7134_MAXBOARDS 32
#define SAA7134_INPUT_MAX 8
--- a/drivers/media/video/saa7134/saa7134-input.c2009-03-23
19:12:14.0
