Re: [PATCH] input: imon driver for SoundGraph iMON/Antec Veris IR devices
On Dec 29, 2009, at 5:30 PM, Dmitry Torokhov wrote: On Tue, Dec 29, 2009 at 12:04:00AM -0500, Jarod Wilson wrote: On Dec 28, 2009, at 4:31 AM, Dmitry Torokhov wrote: Hm, will this work on big-endian? Good question. Not sure offhand. Probably not. Unfortunately, the only devices I have to test with at the moment are integrated into cases with x86 boards in them, so testing isn't particularly straight-forward. I should probably get ahold of one of the plain external usb devices to play with... Mind if I just add a TODO marker near that for now? How about just do le32_to_cpu() instead of memcpy()ing and that's probably it? Hrm. My endian-fu sucks. Not sure what the right way to do it without the memcpy is. I thought I had something together than would work, using 2 lines (memcpy, then le32_to_cpu), but I just realized that'll go south on the keys where we're only looking at half the buffer (i.e., the wrong half on big-endian)... Will see what I can do to fix that up in the morning, was hoping to get this out tonight, but its nearly 3am (again)... Also, forgot to reply to this bit last time: +init_completion(context-tx.finished); +atomic_set((context-tx.busy), 1); What does this atomic give you? Atomic operations do not imply memory barriers IIRC... Code is borrowed from lirc_imon from before my time, honestly hadn't really looked into that much until now. I'm guessing it was *supposed* to provide an assurance that later readers saw the correct value for busy, but indeed, I don't think its actually guaranteeing that. I've changed busy to a bool and inserted smp_rmb()'s after each change to it, which I think *will* provide the desired guarantee. (In practice, its been working just fine either way for me so far). We have pretty different behavior depending on the interface, maybe the driver should be split further? This is what we'll call a fun topic... These devices expose two interfaces, and a while back in the lirc_imon days, they actually loaded up as two separate lirc devices. But there's a catch: they can't operate independently. Some keys come in via intf0, some via intf1, even from the very same remote. And the interfaces share a hardware-internal buffer (or something), and if you're only listening to one of the two devices, and a key is decoded and sent via the interface you're not listening to, it wedges the entire device until you flush the other interface. Horribly bad hardware design at play there, imo, but meh. What exactly did you have in mind as far as a split? (And/or does it still apply with the above info taken into consideration? ;). Ok, fair enough. I'd still want to see larger functions split up a bit though. I've hacked imon_probe() up into 6 different functions now: imon_probe() - imon_init_intf0() - imon_init_idev() - imon_init_display() - imon_init_intf1() - imon_init_touch() (and there was an existing imon_set_ir_protocol() in the mix) Quite a bit more manageable and readable now, I think. Haven't looked yet for other candidates for similar refactoring. Were there others you had in mind? At a glance, imon_incoming_packet() seems to be the only remaining function that is particularly hefty. Well, imon_probe() is still ~180 lines, but it used to be north of 400, I think... So perhaps I try trimming imon_probe() a bit more, and see what can be done to make imon_incoming_packet() less chunky. Current work-in-progress pushed to git.kernel.org again. Thanks much, -- Jarod Wilson ja...@wilsonet.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
Re: patch to support for 0x0802 sensor in t613.c
Hi Nicoulau,
could you try the attached patch and add the Signed-Off by so we can
merge it???
It's your patch, just removed some lines.
Best Regards
On Fri, Dec 18, 2009 at 4:52 PM, leandro Costantino
lcostant...@gmail.com wrote:
Nicolau, if you need help, let me know.
I also, sent you some mails asking for the patch for review some weeks
ago, i thougth you were missing :)
good woork
best regards
On Fri, Dec 18, 2009 at 8:13 PM, Jean-Francois Moine moin...@free.fr wrote:
On Fri, 18 Dec 2009 16:46:04 -0200
Nicolau Werneck nwern...@gmail.com wrote:
Hello. I am a clueless n00b, and I can't make patches or use any
proper development tools. But I made this modification to t613.c to
support this new sensor. It is working fine with me. I just cleaned
the code up a bit and compiled and tested with the 2.6.32 kernel, and
it seems to be working fine.
If somebody could help me creating a proper patch to submit to the
source tree, I would be most grateful. The code is attached.
Hello Nicolau,
Your code seems fine. To create a patch, just go to the linux tree
root, make a 'diff -u' from the original file to your new t613.c, edit
it, at the head, add a comment and a 'Signed-off-by: your email', and
submit to the mailing-list with subject '[PATCH] gspca - t613: Add new
sensor lt168g'.
BTW, as you know the name of your sensor, do you know the real name of
the sensor '0x803' ('other')? (it should be in some xxx.ini file in a
ms-win driver, but I could not find it - the table n4_other of t613.c
should be a table 'Regxxx' in the xx.ini)
Best regards.
--
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
diff -Nru gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c
--- gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c 2009-12-30 02:53:07.0 -0500
+++ gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c 2009-12-30 10:52:47.0 -0500
@@ -52,6 +52,7 @@
#define SENSOR_OM6802 0
#define SENSOR_OTHER 1
#define SENSOR_TAS5130A 2
+#define SENSOR_LT168G 3 /* must verify if this is the actual model */
};
/* V4L2 controls supported by the driver */
@@ -306,6 +307,17 @@
0xbe, 0x36, 0xbf, 0xff, 0xc2, 0x88, 0xc5, 0xc8,
0xc6, 0xda
};
+static const u8 n4_lt168g[] = {
+ 0x66, 0x01, 0x7f, 0x00, 0x80, 0x7c, 0x81, 0x28,
+ 0x83, 0x44, 0x84, 0x20, 0x86, 0x20, 0x8a, 0x70,
+ 0x8b, 0x58, 0x8c, 0x88, 0x8d, 0xa0, 0x8e, 0xb3,
+ 0x8f, 0x24, 0xa1, 0xb0, 0xa2, 0x38, 0xa5, 0x20,
+ 0xa6, 0x4a, 0xa8, 0xe8, 0xaf, 0x38, 0xb0, 0x68,
+ 0xb1, 0x44, 0xb2, 0x88, 0xbb, 0x86, 0xbd, 0x40,
+ 0xbe, 0x26, 0xc1, 0x05, 0xc2, 0x88, 0xc5, 0xc0,
+ 0xda, 0x8e, 0xdb, 0xca, 0xdc, 0xa8, 0xdd, 0x8c,
+ 0xde, 0x44, 0xdf, 0x0c, 0xe9, 0x80
+};
static const struct additional_sensor_data sensor_data[] = {
{/* 0: OM6802 */
@@ -422,6 +434,23 @@
.stream =
{0x0b, 0x04, 0x0a, 0x40},
},
+{/* 3: LT168G */
+ .n3 = {0x61, 0xc2, 0x65, 0x68, 0x60, 0x00},
+ .n4 = n4_lt168g,
+ .n4sz = sizeof n4_lt168g,
+ .reg80 = 0x7c,
+ .reg8e = 0xb3,
+ .nset8 = {0xa8, 0xf0, 0xc6, 0xba, 0xc0, 0x00},
+ .data1 = {0xc0, 0x38, 0x08, 0x10, 0xc0, 0x30, 0x10, 0x40,
+ 0xb0, 0xf4},
+ .data2 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+ 0xff},
+ .data3 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+ 0xff},
+ .data4 = {0x66, 0x41, 0xa8, 0xf0},
+ .data5 = {0x0c, 0x03, 0xab, 0x4b, 0x81, 0x2b},
+ .stream = {0x0b, 0x04, 0x0a, 0x28},
+},
};
#define MAX_EFFECTS 7
@@ -758,6 +787,10 @@
PDEBUG(D_PROBE, sensor tas5130a);
sd-sensor = SENSOR_TAS5130A;
break;
+ case 0x0802:
+ PDEBUG(D_PROBE, sensor lt168g);
+ sd-sensor = SENSOR_LT168G;
+ break;
case 0x0803:
PDEBUG(D_PROBE, sensor 'other');
sd-sensor = SENSOR_OTHER;
@@ -800,6 +833,13 @@
reg_w_buf(gspca_dev, sensor-n3, sizeof sensor-n3);
reg_w_buf(gspca_dev, sensor-n4, sensor-n4sz);
+ if (sd-sensor == SENSOR_LT168G) {
+ test_byte = reg_r(gspca_dev, 0x80);
+ PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+ test_byte);
+ reg_w(gspca_dev, 0x6c80);
+ }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2);
reg_w_ixbuf(gspca_dev, 0xe0, sensor-data3, sizeof sensor-data3);
@@ -824,6 +864,13 @@
reg_w_buf(gspca_dev, sensor-nset8, sizeof sensor-nset8);
reg_w_buf(gspca_dev, sensor-stream, sizeof sensor-stream);
+ if (sd-sensor == SENSOR_LT168G) {
+ test_byte = reg_r(gspca_dev, 0x80);
+ PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+ test_byte);
+ reg_w(gspca_dev, 0x6c80);
+ }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2);
Re: [PATCH] gspca: make control descriptors constant
On Tue, 29 Dec 2009 22:45:52 +0100 Németh Márton nm...@freemail.hu wrote: The ctrls field of struct sd_desc is declared as const in gspca.h. It is worth to initialize the content also with constant values. Thanks, I got it. -- 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
Re: patch to support for 0x0802 sensor in t613.c
Em Wed, 30 Dec 2009 04:56:03 -0500
leandro Costantino lcostant...@gmail.com escreveu:
Hello. Thanks for the help! The problem is I'm away from home, on
vacation. Also my two computers back home are not workig. But I'm
going to work with that again at my lab next week, at most.
I'll take the chance to ask: where do the gamma correction table values
come from? Because I got slightly different values from the driver I
sniffed...
See you,
++nicolau
Hi Nicoulau,
could you try the attached patch and add the Signed-Off by so we can
merge it???
It's your patch, just removed some lines.
Best Regards
On Fri, Dec 18, 2009 at 4:52 PM, leandro Costantino
lcostant...@gmail.com wrote:
Nicolau, if you need help, let me know.
I also, sent you some mails asking for the patch for review some
weeks ago, i thougth you were missing :)
good woork
best regards
On Fri, Dec 18, 2009 at 8:13 PM, Jean-Francois Moine
moin...@free.fr wrote:
On Fri, 18 Dec 2009 16:46:04 -0200
Nicolau Werneck nwern...@gmail.com wrote:
Hello. I am a clueless n00b, and I can't make patches or use any
proper development tools. But I made this modification to t613.c
to support this new sensor. It is working fine with me. I just
cleaned the code up a bit and compiled and tested with the 2.6.32
kernel, and it seems to be working fine.
If somebody could help me creating a proper patch to submit to the
source tree, I would be most grateful. The code is attached.
Hello Nicolau,
Your code seems fine. To create a patch, just go to the linux tree
root, make a 'diff -u' from the original file to your new t613.c,
edit it, at the head, add a comment and a 'Signed-off-by: your
email', and submit to the mailing-list with subject '[PATCH]
emailgspca - t613: Add new
sensor lt168g'.
BTW, as you know the name of your sensor, do you know the real
name of the sensor '0x803' ('other')? (it should be in some
xxx.ini file in a ms-win driver, but I could not find it - the
table n4_other of t613.c should be a table 'Regxxx' in the xx.ini)
--
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://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver - V4L: vpfe capture: header files for ISIF driver - V4L: vpfe capture: source for ISIF driver on DM365 - V4L: vpfe capture: vpss driver enhancements for DM365 - V4L: vpfe_capture: bug fixes and enhancements - V4L: vpfe capture: build environment for isif driver And after the first three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ And after the other four patches are pulled in, then this arch patch should be merged for git: http://patchwork.kernel.org/patch/68876/ I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. I also think it is a good idea if you ask for an account on linuxtv.org so that you can set up your own hg trees and you don't have to wait for me. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/isif.c | 1512 +++ b/linux/drivers/media/video/davinci/isif_regs.h | 269 b/linux/include/media/davinci/isif.h | 531 linux/drivers/media/video/Kconfig| 14 linux/drivers/media/video/davinci/Makefile |1 linux/drivers/media/video/davinci/dm355_ccdc.c | 413 +++--- linux/drivers/media/video/davinci/dm644x_ccdc.c | 362 +++-- linux/drivers/media/video/davinci/vpfe_capture.c | 254 +-- linux/drivers/media/video/davinci/vpss.c | 289 +++- linux/include/media/davinci/vpfe_capture.h | 12 linux/include/media/davinci/vpss.h | 41 11 files changed, 3180 insertions(+), 518 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, December 30, 2009 8:49 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan; khil...@deeprootsystems.com Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver - V4L: vpfe capture: header files for ISIF driver - V4L: vpfe capture: source for ISIF driver on DM365 - V4L: vpfe capture: vpss driver enhancements for DM365 - V4L: vpfe_capture: bug fixes and enhancements - V4L: vpfe capture: build environment for isif driver And after the first three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ And after the other four patches are pulled in, then this arch patch should be merged for git: http://patchwork.kernel.org/patch/68876/ Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. I also think it is a good idea if you ask for an account on linuxtv.org so that you can set up your own hg trees and you don't have to wait for me. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/isif.c | 1512 +++ b/linux/drivers/media/video/davinci/isif_regs.h | 269 b/linux/include/media/davinci/isif.h | 531 linux/drivers/media/video/Kconfig| 14 linux/drivers/media/video/davinci/Makefile |1 linux/drivers/media/video/davinci/dm355_ccdc.c | 413 +++--- linux/drivers/media/video/davinci/dm644x_ccdc.c | 362 +++-- linux/drivers/media/video/davinci/vpfe_capture.c | 254 +-- linux/drivers/media/video/davinci/vpss.c | 289 +++- linux/include/media/davinci/vpfe_capture.h | 12 linux/include/media/davinci/vpss.h | 41 11 files changed, 3180 insertions(+), 518 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG
help on mercurial
Hi,
I am trying to build and install mercurial 1.4 on my Redhat Linux machine. I
could build and install python. When building mercurial, I got following
error log:-
make all
= error log...
python setup.py build
File setup.py, line 147
for l in open('.hg_archival.txt'))
^
SyntaxError: invalid syntax.
I am trying to learn mercurial for hosting my own hg tree and ended up here :(.
Any help will be appreciated.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.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
Re: [PATCH] input: imon driver for SoundGraph iMON/Antec Veris IR devices
On Dec 30, 2009, at 3:02 AM, Jarod Wilson wrote: On Dec 29, 2009, at 5:30 PM, Dmitry Torokhov wrote: On Tue, Dec 29, 2009 at 12:04:00AM -0500, Jarod Wilson wrote: On Dec 28, 2009, at 4:31 AM, Dmitry Torokhov wrote: Hm, will this work on big-endian? Good question. Not sure offhand. Probably not. Unfortunately, the only devices I have to test with at the moment are integrated into cases with x86 boards in them, so testing isn't particularly straight-forward. I should probably get ahold of one of the plain external usb devices to play with... Mind if I just add a TODO marker near that for now? How about just do le32_to_cpu() instead of memcpy()ing and that's probably it? Hrm. My endian-fu sucks. Not sure what the right way to do it without the memcpy is. I thought I had something together than would work, using 2 lines (memcpy, then le32_to_cpu), but I just realized that'll go south on the keys where we're only looking at half the buffer (i.e., the wrong half on big-endian)... Will see what I can do to fix that up in the morning, was hoping to get this out tonight, but its nearly 3am (again)... Got something that works in place now. Well, definitely works on x86, works in theory on big-endian, haven't got a way to test it on the latter just yet. [...] I'd still want to see larger functions split up a bit though. I've hacked imon_probe() up into 6 different functions now: imon_probe() - imon_init_intf0() - imon_init_idev() - imon_init_display() - imon_init_intf1() - imon_init_touch() (and there was an existing imon_set_ir_protocol() in the mix) Quite a bit more manageable and readable now, I think. Haven't looked yet for other candidates for similar refactoring. Were there others you had in mind? At a glance, imon_incoming_packet() seems to be the only remaining function that is particularly hefty. Well, imon_probe() is still ~180 lines, but it used to be north of 400, I think... So perhaps I try trimming imon_probe() a bit more, and see what can be done to make imon_incoming_packet() less chunky. Making good headway on imon_incoming_packet(), in-progress bits pushed again. Gotta take my son and a buddy to a movie. Life keeps getting in the way of me finishing this as quickly as I'd like... :) -- Jarod Wilson ja...@wilsonet.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
[PATCH] drivers/media/video/tveeprom.c: use %pM to show MAC address
Use the %pM kernel extension to display the MAC address. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com --- diff --git a/drivers/media/video/tveeprom.c b/drivers/media/video/tveeprom.c index d533ea5..0a87749 100644 --- a/drivers/media/video/tveeprom.c +++ b/drivers/media/video/tveeprom.c @@ -680,10 +680,7 @@ void tveeprom_hauppauge_analog(struct i2c_client *c, struct tveeprom *tvee, tveeprom_info(Hauppauge model %d, rev %s, serial# %d\n, tvee-model, tvee-rev_str, tvee-serial_number); if (tvee-has_MAC_address == 1) - tveeprom_info(MAC address is %02X-%02X-%02X-%02X-%02X-%02X\n, - tvee-MAC_address[0], tvee-MAC_address[1], - tvee-MAC_address[2], tvee-MAC_address[3], - tvee-MAC_address[4], tvee-MAC_address[5]); + tveeprom_info(MAC address is %pM\n, tvee-MAC_address); tveeprom_info(tuner model is %s (idx %d, type %d)\n, t_name1, tuner1, tvee-tuner_type); tveeprom_info(TV standards%s%s%s%s%s%s%s%s (eeprom 0x%02x)\n, -- 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] drivers/media/video/cx23885/cx23885-dvb.c: use %pM to show MAC address
Use the %pM kernel extension to display the MAC address. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Cc: Steven Toth st...@kernellabs.com --- diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c index e45d2df..f9243de 100644 --- a/drivers/media/video/cx23885/cx23885-dvb.c +++ b/drivers/media/video/cx23885/cx23885-dvb.c @@ -994,15 +994,8 @@ static int dvb_register(struct cx23885_tsport *port) netup_get_card_info(dev-i2c_bus[0].i2c_adap, cinfo); memcpy(port-frontends.adapter.proposed_mac, cinfo.port[port-nr - 1].mac, 6); - printk(KERN_INFO NetUP Dual DVB-S2 CI card port%d MAC= - %02X:%02X:%02X:%02X:%02X:%02X\n, - port-nr, - port-frontends.adapter.proposed_mac[0], - port-frontends.adapter.proposed_mac[1], - port-frontends.adapter.proposed_mac[2], - port-frontends.adapter.proposed_mac[3], - port-frontends.adapter.proposed_mac[4], - port-frontends.adapter.proposed_mac[5]); + printk(KERN_INFO NetUP Dual DVB-S2 CI card port%d MAC=%pM\n, + port-nr, port-frontends.adapter.proposed_mac); netup_ci_init(port); break; -- 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
Test email. Please ignore
-- Murali Karicheri mkarich...@gmail.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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
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:Wed Dec 30 19:00:08 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13877:59e746a1c5d1 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK 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: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
[PATCH] drivers/media/dvb/dvb-core/dvb_net.c: use %pM to show MAC address
Use the %pM kernel extension to display the MAC address and mask. The only difference in the output is that the output is shown in the usual colon-separated hex notation. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Cc: David S. Miller da...@davemloft.net --- diff --git a/drivers/media/dvb/dvb-core/dvb_net.c b/drivers/media/dvb/dvb-core/dvb_net.c index 8b8558f..da6552d 100644 --- a/drivers/media/dvb/dvb-core/dvb_net.c +++ b/drivers/media/dvb/dvb-core/dvb_net.c @@ -949,11 +949,8 @@ static int dvb_net_filter_sec_set(struct net_device *dev, (*secfilter)-filter_mask[10] = mac_mask[1]; (*secfilter)-filter_mask[11]=mac_mask[0]; - dprintk(%s: filter mac=%02x %02x %02x %02x %02x %02x\n, - dev-name, mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); - dprintk(%s: filter mask=%02x %02x %02x %02x %02x %02x\n, - dev-name, mac_mask[0], mac_mask[1], mac_mask[2], - mac_mask[3], mac_mask[4], mac_mask[5]); + dprintk(%s: filter mac=%pM\n, dev-name, mac); + dprintk(%s: filter mask=%pM\n, dev-name, mac_mask); return 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
AverMedia A577 (cx23385, xc3028, af9013)
Hi, Now that DVB-T is finally available in my town, I would like to ask for help to make my AverMedia HybridExpress (A577) work under Linux. This is the information I have gathered so far: Main chips are the following (see http://www.ixbt.com/monitor/aver-hybrid-express.shtml for pictures, the page is in Russian though): cx23885 (PCIe A/V decoder) xc3028 (hybrid tuner) af9013 (demod) all of these individual chips are already supported under Linux, only the glue is missing between them, I think. I've also got an A885VCap.inf file (which is some 3164 lines long, that's why I don't attach it here except if requested), along with other files (a885vcap.cat, A885VCap.sys, cpnotify.ax, cxtvrate.dll, but also merlinC.rom and cx416enc.rom) from the Windows driver pack. I don't know if all of these are really needed, especially cx416enc.rom, since this card is not supposed to have a hardware A/V encoder. I would like to ask for help, what is the next step I should take in order to make this card work? Levente -- 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 A577 (cx23385, xc3028, af9013)
On 12/30/2009 10:12 PM, Novák Levente wrote: cx23885 (PCIe A/V decoder) xc3028 (hybrid tuner) af9013 (demod) all of these individual chips are already supported under Linux, only the glue is missing between them, I think. Yes. Also some code changes for af9013 could be needed. There is no any af9013 device currently supported, only af9015 which integrates af9013. I would like to ask for help, what is the next step I should take in order to make this card work? Take USB sniff, parse it and comment out data flow command by command. Look meaning of those bytes from existing drivers. Then use debugs to see data flow is correct. Antti -- http://palosaari.fi/ -- 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 A577 (cx23385, xc3028, af9013)
2009. 12. 30, szerda keltezéssel 22.32-kor Antti Palosaari ezt írta: On 12/30/2009 10:12 PM, Novák Levente wrote: cx23885 (PCIe A/V decoder) xc3028 (hybrid tuner) af9013 (demod) all of these individual chips are already supported under Linux, only the glue is missing between them, I think. Yes. Also some code changes for af9013 could be needed. There is no any af9013 device currently supported, only af9015 which integrates af9013. Ah, I thought af9013 is already supported. I would like to ask for help, what is the next step I should take in order to make this card work? Take USB sniff, parse it and comment out data flow command by command. Look meaning of those bytes from existing drivers. Then use debugs to see data flow is correct. OK, but this card is not USB but ExpressCard. Levente -- 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
Status of Terratec S7 drivers
Hello, at this URL: http://linux.terratec.de/tv_en.html there is a driver package for the Terratec S7 DVB-S/S2 USB. I'd like to know if they are (1) working and (2) being considered for inclusion in the dvb tree. Thanks. -- Daniele Venzano ve...@brownhat.org http://www.brownhat.org -- 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
av7110 error reporting
I need some guidance on error messages..
The machine receives these messages in the systemlog (dmesg)
[ 7673.168026] dvb-ttpci: StartHWFilter error buf 0b07 0010 07e9 b96a
ret 0 handle
[ 7674.192025] dvb-ttpci: StartHWFilter error buf 0b07 0010 07ee b96a
ret 0 handle
[ 7675.224025] dvb-ttpci: StartHWFilter error buf 0b07 0010 07f3 b96a
ret 0 handle
[ 7676.248128] dvb-ttpci: StartHWFilter error buf 0b07 0010 07f9 b96a
ret 0 handle
[ 7677.280026] dvb-ttpci: StartHWFilter error buf 0b07 0010 07fd b96a
ret 0 handle
[ 7678.312025] dvb-ttpci: StartHWFilter error buf 0b07 0010 0803 b96a
ret 0 handle
These start as soon as I view or record a channel, and obviously fills
up the log quickly.
I believe the code that generates these messages is at the bottom of
this message (part of av7110.c). This code was introduced in 2005 to
improve error reporting.
Currently I run today's v4l-dvb (using a hg update), and kernel
2.6.31-16. (Ubuntu), however the issue occurred in older combinations as
well (over a year ago), so it is not introduced by the last kernels or
DVB driverset.
The message seems to be triggered by the variable handle being larger
then 32. On my system it always reports .
Am I looking at faulty hardware, or can I resolve this issue more
elegant than just disabling the fault report?
(keep in mind that I do not have a programming/coding background)
Johan
start of code---
static int StartHWFilter(struct dvb_demux_filter *dvbdmxfilter)
{
struct dvb_demux_feed *dvbdmxfeed = dvbdmxfilter-feed;
struct av7110 *av7110 = dvbdmxfeed-demux-priv;
u16 buf[20];
int ret, i;
u16 handle;
//u16 mode = 0x0320;
u16 mode = 0xb96a;
dprintk(4, %p\n, av7110);
if (av7110-full_ts)
return 0;
if (dvbdmxfilter-type == DMX_TYPE_SEC) {
if (hw_sections) {
buf[4] = (dvbdmxfilter-filter.filter_value[0] 8) |
dvbdmxfilter-maskandmode[0];
for (i = 3; i 18; i++)
buf[i + 4 - 2] =
(dvbdmxfilter-filter.filter_value[i] 8) |
dvbdmxfilter-maskandmode[i];
mode = 4;
}
} else if ((dvbdmxfeed-ts_type TS_PACKET)
!(dvbdmxfeed-ts_type TS_PAYLOAD_ONLY)) {
av7110_p2t_init(av7110-p2t_filter[dvbdmxfilter-index],
dvbdmxfeed);
}
buf[0] = (COMTYPE_PID_FILTER 8) + AddPIDFilter;
buf[1] = 16;
buf[2] = dvbdmxfeed-pid;
buf[3] = mode;
ret = av7110_fw_request(av7110, buf, 20, handle, 1);
if (ret != 0 || handle = 32) {
printk(dvb-ttpci: %s error buf %04x %04x %04x %04x
ret %d handle %04x\n,
__func__, buf[0], buf[1], buf[2], buf[3],
ret, handle);
dvbdmxfilter-hw_handle = 0x;
if (!ret)
ret = -1;
return ret;
}
av7110-handle2filter[handle] = dvbdmxfilter;
dvbdmxfilter-hw_handle = handle;
return ret;
}
--end of code
--
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] gspca: make sd_desc const
From: Márton Németh nm...@freemail.hu
The function callbacks in sd_desc are defined at compile time and
they do not change at runtime. Make the sd_desc initializations const.
The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@c@
identifier x;
@@
static const struct sd_desc x = ...;
@depends on !c@
identifier x;
@@
static
+ const
struct sd_desc x = ...;
// /smpl
Signed-off-by: Márton Németh nm...@freemail.hu
Cc: co...@diku.dk
---
diff -r 62ee2b0f6556 linux/drivers/media/video/gspca/conex.c
--- a/linux/drivers/media/video/gspca/conex.c Wed Dec 30 18:19:11 2009 +0100
+++ b/linux/drivers/media/video/gspca/conex.c Wed Dec 30 22:27:04 2009 +0100
@@ -1032,7 +1032,7 @@
}
/* sub-driver description */
-static struct sd_desc sd_desc = {
+static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
diff -r 62ee2b0f6556 linux/drivers/media/video/gspca/etoms.c
--- a/linux/drivers/media/video/gspca/etoms.c Wed Dec 30 18:19:11 2009 +0100
+++ b/linux/drivers/media/video/gspca/etoms.c Wed Dec 30 22:27:04 2009 +0100
@@ -857,7 +857,7 @@
}
/* sub-driver description */
-static struct sd_desc sd_desc = {
+static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
diff -r 62ee2b0f6556 linux/drivers/media/video/gspca/gl860/gl860.c
--- a/linux/drivers/media/video/gspca/gl860/gl860.c Wed Dec 30 18:19:11
2009 +0100
+++ b/linux/drivers/media/video/gspca/gl860/gl860.c Wed Dec 30 22:27:04
2009 +0100
@@ -161,7 +161,7 @@
/* sud-driver structure initialisation =*/
-static struct sd_desc sd_desc_mi1320 = {
+static const struct sd_desc sd_desc_mi1320 = {
.name= MODULE_NAME,
.ctrls = sd_ctrls_mi1320,
.nctrls = GL860_NCTRLS,
@@ -174,7 +174,7 @@
.dq_callback = sd_callback,
};
-static struct sd_desc sd_desc_mi2020 = {
+static const struct sd_desc sd_desc_mi2020 = {
.name= MODULE_NAME,
.ctrls = sd_ctrls_mi2020,
.nctrls = GL860_NCTRLS,
@@ -187,7 +187,7 @@
.dq_callback = sd_callback,
};
-static struct sd_desc sd_desc_mi2020b = {
+static const struct sd_desc sd_desc_mi2020b = {
.name= MODULE_NAME,
.ctrls = sd_ctrls_mi2020b,
.nctrls = GL860_NCTRLS,
@@ -200,7 +200,7 @@
.dq_callback = sd_callback,
};
-static struct sd_desc sd_desc_ov2640 = {
+static const struct sd_desc sd_desc_ov2640 = {
.name= MODULE_NAME,
.ctrls = sd_ctrls_ov2640,
.nctrls = GL860_NCTRLS,
@@ -213,7 +213,7 @@
.dq_callback = sd_callback,
};
-static struct sd_desc sd_desc_ov9655 = {
+static const struct sd_desc sd_desc_ov9655 = {
.name= MODULE_NAME,
.ctrls = sd_ctrls_ov9655,
.nctrls = GL860_NCTRLS,
diff -r 62ee2b0f6556 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Wed Dec 30 18:19:11 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Wed Dec 30 22:27:04 2009 +0100
@@ -1232,7 +1232,7 @@
#endif
/* sub-driver description for pac7302 */
-static struct sd_desc sd_desc = {
+static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
diff -r 62ee2b0f6556 linux/drivers/media/video/gspca/pac7311.c
--- a/linux/drivers/media/video/gspca/pac7311.c Wed Dec 30 18:19:11 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7311.c Wed Dec 30 22:27:04 2009 +0100
@@ -870,7 +870,7 @@
}
/* sub-driver description for pac7311 */
-static struct sd_desc sd_desc = {
+static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
diff -r 62ee2b0f6556 linux/drivers/media/video/gspca/spca500.c
--- a/linux/drivers/media/video/gspca/spca500.c Wed Dec 30 18:19:11 2009 +0100
+++ b/linux/drivers/media/video/gspca/spca500.c Wed Dec 30 22:27:04 2009 +0100
@@ -1064,7 +1064,7 @@
}
/* sub-driver description */
-static struct sd_desc sd_desc = {
+static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
diff -r 62ee2b0f6556 linux/drivers/media/video/gspca/spca506.c
--- a/linux/drivers/media/video/gspca/spca506.c Wed Dec 30 18:19:11 2009 +0100
+++ b/linux/drivers/media/video/gspca/spca506.c Wed Dec 30 22:27:04 2009 +0100
@@ -673,7 +673,7 @@
}
/* sub-driver description */
-static struct sd_desc sd_desc = {
+static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
--
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
i915 graphics driver
Hello. I am trying to get the different display modes working with my portege M400 laptop. Im running 2.6.32 with the toshiba_acpi module. the problem is that when i do: echo lcd_out:0;crt_out:1 /proc/acpi/toshiba/video cat /proc/acpi/toshiba/video i get: lcd_out: 1 crt_out: 0 tv_out: 0 I am following the guide at http://memebeam.org/toys/ToshibaAcpiDriver. Why does the state of the crt_out variable not change? the kernel file where this is handled is: kernel/drivers/portability/ x86/toshiba_acpi.c. I have the same problem as these guys here: http://osdir.com/ml/linux.hardware.toshiba/2003-04/msg00216.html I tried doing what was suggested at that link, but that did not work either. Is there a known bug where the state of the driver (as seen by cat /proc/acpi/toshiba/video) is not updated by writing to it(echo lcd_out:0;crt_out:1 /proc/acpi/toshiba/video)? It seems that the state written to this file is not persistant. I have posted my problem in full detail here (http://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/tvout-from-toshiba-portege-m400-777822/). thanks. -- Neil Sikka -- 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: i915 graphics driver
wrong list Neil -- try xorg user support: http://lists.freedesktop.org/mailman/listinfo/xorg -- 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: Status of Terratec S7 drivers
Hi Daniele Venzano wrote: Hello, at this URL: http://linux.terratec.de/tv_en.html there is a driver package for the Terratec S7 DVB-S/S2 USB. I'd like to know if they are (1) working no idea, but perhaps someone else knows, or you could try them yourself (slash volunteer to be the guinea pig for everyone else) if you have the hardware and (2) being considered for inclusion in the dvb tree. no idea if anyone at Terratec is working in conjunction with v4l-dvb, or has plans for its inclusion into the kernel ... there may already be such work/plans, but I'm ignorant of such. In any regards, if they are interested, then they should for the following instructions on route to achieving that purpose: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches -- 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: [Bulk] help on mercurial
Karicheri, Muralidharan wrote: I am trying to learn mercurial for hosting my own hg tree and ended up here :(. Any help will be appreciated. Hi, see the following link, as it has embedded links for what your after: http://www.linuxtv.org/wiki/index.php/Maintaining_Mercurial_(Hg)_trees -- 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: i915 graphics driver
Neil Sikka wrote: hey. isnt this mailing list where the i915 driver was developed? On Wed, Dec 30, 2009 at 4:53 PM, CityK ci...@rogers.com wrote: wrong list Neil -- try xorg user support: http://lists.freedesktop.org/mailman/listinfo/xorg (note: added LMML back in .. use reply all) nope. likely on http://lists.freedesktop.org/archives/intel-gfx/ (or some precursor ... see http://intellinuxgraphics.org/ ). Anyway, xorg or the Intel list would likely serve your purposes -- 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: CX23885 IR support - how the (parts obsolecence) grinch stole Christmas.
On Wed, 2009-12-30 at 16:48 -0500, Devin Heitmueller wrote: On Wed, Dec 30, 2009 at 4:16 PM, Andy Walls awa...@radix.net wrote: The delivery man just delivered my shiny new HVR-1250 from NewEgg a half an hour ago - Joy! The unit appears to have a CX23888 instead of the CX23885 - Boo! So much for debugging first-hand the perpetual CX23885 A/V core interrupts when enabling IR. Further research indicates this board is what the Linux drivers call an HVR-1270 Model 22111. At least I'll get its IR supported. Regards, Andy I'm pretty sure I've got a cx23885 based HVR-1250, if you want to trade it out for your 23888 based unit. Let me know if you want me to drop it into the mail, Yes. Thank you very much! Shipping details are under separate cover. Regards, Andy Devin -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Karicheri, Muralidharan wrote: Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. The issue is that non-v4l platform data changes that happens on the same headers where you have also v4l platform data changes cause lots of merge troubles. This happens with -hg, but this also would happen if I just merge from a -git tree. So, the problem is not about having a different procedure due to -hg, but having a way to avoid having merge conflicts every time an omap driver (or another driver that uses the platform_data stuff) is merged. On my experiences, the non-Intel arch headers used by V4L drivers got renamed, had several api changes and mixed several different subsystems at the same header, causing all sorts of merge conflicts. Since the soc_camera and omap drivers got merged, on every single kernel version, we had some sort of conflict to manage. On several cases, git bisect got broken, and we had even some worse case scenarios where the arch compilation got broken for some time, due to those conflicts. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? I can send you one, but maybe it is a little late for it, since my intention is to start discussing and working to replace -hg to -git at the beginning of 2010, if time allows me to do that. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Mauro, What do you suggest for the existing 2 pull requests from Hans? I had suggested something in my last email to do this in 2 steps based on Kevin's proposal. 1) Merge the patches (including arch patches) to linux-next tree based on Hans's pull request. 2) When upstream merge window opens and Kevin's davinci tree is merged to Linus tree, drop the arch patches from v4l-dvb. We could re-work the dropped patches based on Linus tree and send the same to you. Do you think this is doable? If so, please merge these pull requests to linux-next. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Wednesday, December 30, 2009 5:25 PM To: Karicheri, Muralidharan Cc: Hans Verkuil; linux-media@vger.kernel.org; khil...@deeprootsystems.com Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Karicheri, Muralidharan wrote: Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. The issue is that non-v4l platform data changes that happens on the same headers where you have also v4l platform data changes cause lots of merge troubles. This happens with -hg, but this also would happen if I just merge from a - git tree. So, the problem is not about having a different procedure due to -hg, but having a way to avoid having merge conflicts every time an omap driver (or another driver that uses the platform_data stuff) is merged. On my experiences, the non-Intel arch headers used by V4L drivers got renamed, had several api changes and mixed several different subsystems at the same header, causing all sorts of merge conflicts. Since the soc_camera and omap drivers got merged, on every single kernel version, we had some sort of conflict to manage. On several cases, git bisect got broken, and we had even some worse case scenarios where the arch compilation got broken for some time, due to those conflicts. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? I can send you one, but maybe it is a little late for it, since my intention is to start discussing and working to replace -hg to -git at the beginning of 2010, if time allows me to do that. Cheers, Mauro.
Re: [linux-dvb] Compro VideoMate U80 DVB-T USB 2.0 High Definition Digital TV Stick
drappa wrote: Hi All http://www.comprousa.com/en/product/u80/u80.html I'd be grateful if anyone can tell me if this device is supported yet, and if so, any pointers to getting it working. Thanks Drappa ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb In the absence of any feedback to my query, I had a look at the driver entry for this device in a Win7 system. It shows as: Videomate U1xx Digital Series The driver was written by Realtek and is version 5.55.828.2009 So, I guess there may be a number of devices in this series with the same chipset. Does this ring any bells with anyone? Thanks Drappa -- 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/RFC v2.1 0/2] Mem-to-mem device framework
-Original Message- From: Pawel Osciak [mailto:p.osc...@samsung.com] Sent: Monday, December 28, 2009 8:19 PM To: 'Hans Verkuil' Cc: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Marek Szyprowski; kyungmin.p...@samsung.com; Hiremath, Vaibhav; Karicheri, Muralidharan; 'Guru Raj'; 'Xiaolin Zhang'; 'Magnus Damm'; 'Sakari Ailus' Subject: RE: [PATCH/RFC v2.1 0/2] Mem-to-mem device framework Hello Hans, On Wednesday 23 December 2009 16:06:18 Hans Verkuil wrote: Thank you for working on this! It's much appreciated. Now I've noticed that patches regarding memory-to-memory and memory pool tend to get very few comments. I suspect that the main reason is that these are SoC-specific features that do not occur in consumer-type products. So most v4l developers do not have the interest and motivation (and time!) to look into this. Thank you very much for your response. We were a bit surprised with the lack of responses as there seemed to be a good number of people interested in this area. I'm hoping that everybody interested would take a look at the test device posted along with the patches. It's virtual, no specific hardware required, but it demonstrates the concepts behind the framework, including transactions. [Hiremath, Vaibhav] I was on vacation and resumed today itself, I will go through these patch series this weekend and will get back to you. I just had cursory look and I would say it should be really good starting point for us to support mem-to-mem devices. Thanks, Vaibhav One thing that I am missing is a high-level overview of what we want. Currently there are patches/RFCs floating around for memory-to-memory support, multiplanar support and memory-pool support. What I would like to see is a RFC that ties this all together from the point of view of the public API. I.e. what are the requirements? Possibly solutions? Open questions? Forget about how to implement it for the moment, that will follow from the chosen solutions. Yes, that's true, sorry about that. We've been so into it after the memory pool discussion and the V4L2 mini-summit that I neglected describing the big picture behind this. So to give a more high-level description, from the point of view of applications and the V4L2 API: --- Requirements: --- (Some of the following were first posted by Laurent in: http://thread.gmane.org/gmane.linux.drivers.video-input- infrastructure/10204). 1. Support for devices that take input data in a source buffer, take a separate destination buffer, process the source data and put it in the destination buffer. 2. Allow sharing buffers between devices, effectively chaining them to form video pipelines. An example of this could be a video decoder, fed with video stream which returns raw frames, which then have to be postprocessed by another device and displayed. This is the main scenario we need to have for our S3C/S5P series SoCs. Of course, we'd like zero-copy. 3. Allow using more than one buffer by the device at the same time. This is not supported by videobuffer (e.g. we have to choose on which buffer we'd like to sleep, and we do not always know that). This is not really a requirement from the V4L2 API point of view, but has direct influence on how poll() and blocking I/O works. 4. Multiplanar buffers. Our devices require them (see the RFC for more details: http://article.gmane.org/gmane.linux.drivers.video-input- infrastructure/11212). 5. Solve problems with cache coherency on non-x86 architectures, especially in videobuf for OUTPUT buffers. We need to flush the cache before starting the transaction. 6. Reduce buffer queuing latency, e.g.: move operations such as locking, out of qbuf. Applications would like to queue a buffer and be able to fire up the device as fast as possible. 7. Large buffer allocations, buffer preallocation, etc. --- Solutions: --- 1. After a detailed discussion, we agreed in: http://thread.gmane.org/gmane.linux.drivers.video-input- infrastructure/10668, that we'd like the application to be able to queue/dequeue both OUTPUT (as source) and CAPTURE (as destination) buffers on one video node. Activating the device (after streamon) would take effect only if there are both types of buffers available. The application would put source data into OUTPUT buffers and expect to find it processed in dequeued CAPTURE buffers. Addressed by mem2mem framework. 2. I don't see anything to do here from the API's point of view. The application would open two video nodes, e.g. video decoder and video postprocessor and queue buffers dequeued from decoder on the postprocessor. To get the best performance, this requires the buffers to be marked as non cached somehow to avoid unneeded cache syncs. 3. Mem2mem addresses this partially
