Re: V4L2 and Media controller mini-summit in Helsinki 14.--16. June
On Monday 05 April 2010 21:36:35 Sakari Ailus wrote: Hello everyone, I'm glad to announce Nokia will be hosting a V4L2 and Media controller mini-summit in Helsinki, Finland from 14th to 16th June --- that's from Monday to Wednesday. The event replaces the V4L2 Media Controller mini-summit in Oslo in April / May proposed by Hans Verkuil. Just the location is different; Hans is still responsible for the technical content. Then I'd better start on that technical content :-) Here is a short overview of the topics I want to put on the agenda (in no particular order): - Media controller progress. Especially with regards to the roadmap of getting this merged. - Memory handling. See this link for a report on a preliminary meeting: http://www.mail-archive.com/linux-media@vger.kernel.org/msg16618.html It would be nice if we can spend some more time on the memory pool concept. - V4L1 removal. We need to decide how we are going to do this. In particular the role that libv4l1 can play in this is of interest. Also: which unmaintained applications should we 'adopt' and convert from V4L1 to V4L2. - Work on the V4L core framework: what is in place, what still needs to be done, what other parts can be moved to the core. - Compliance tests. I'd like to start discussing this as well. I think we have to start work on a tool that will do basic compliance testing of new (and existing) drivers. The API is so big that it is way too easy to forget things. My guess is that at least 80% of all drivers violate the spec in one way or another. Relates as well to the framework topic: if we can move more into the core, then it is much easier to enforce spec compliance. - Anything else someone wants to discuss? Regards, Hans -- 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: [PATCH 2/2] V4L/DVB: Use custom I2C probing function mechanism
Hi Mauro, On Fri, 09 Apr 2010 01:09:08 -0300, Mauro Carvalho Chehab wrote: Jean Delvare wrote: There are no other probing functions yet, this is the first one. I have added the mechanism to i2c-core for these very IR chips. Putting all probe functions together would mean moving them to i2c-core. This wasn't my original intent, but after all, it makes some sense. Would you be happy with the following? It seems fine for me. As you're touching on i2c core and on other drivers on this series, I think that the better is if you could apply it on your tree. Yes, this is the plan. However, before I can add them to my tree, patch named: [PATCH] FusionHDTV: Use quick reads for I2C IR device probing which I posted to the linux-media mailing list some weeks ago must go upstream. Otherwise these 2 patches do not apply cleanly. For both patches 1 and 2: Acked-by: Mauro Carvalho Chehab mche...@redhat.com Thanks. -- Jean Delvare -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: Comments? I haven't seen this mentioned yet, but are there any plans for a sysfs interface to set up waking from suspend/standby on a particular IR scancode (for hardware decoders that support masking of comparing of the IR data), kind of analagous to the rtc framework's wakealarm sysfs file? Cheers James signature.asc Description: This is a digitally signed message part.
em28xx: board id [eb1a:e310]
Hi, I've made tests with my *KWORLD DVB USB 2.0 310U* board: *Model*: KWORLD DVB USB 2.0 310U *Vendor/Product id*: [eb1a:e310] *Kernel:* 2.6.33 + v4l-dvb-fw-bf7cd2fb7a35 + xc3028-v27.fw *Tests made*: - Analog [Worked Video+Audio, But i can change channels correctly only if i set manually frequencies to mplayer freq=] - DVB[No] - VBI[ Seems to work ] * Part of Kernel Logs:* --- [ 2268.140148] em28xx: New device USB 2881 Device @ 480 Mbps (eb1a:e310, interface 0, class 0) [ 2268.141492] em28xx #0: chip ID is em2882/em2883 ... [ 2269.439708] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 ... [ 2271.510368] em28xx #0: /2: dvb frontend not attached. Can't attach xc3028 [ 2271.510373] Em28xx: Initialized (Em28xx dvb Extension) extension More tests i will post soon. If you need more informations/logs about this board let me know. *Tested-by*: int_nick_...@yahoo.gr -- 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 4/4] Add RC6 support to ir-core
Hello David, David Härdeman wrote: --- a/drivers/media/IR/ir-core-priv.h +++ b/drivers/media/IR/ir-core-priv.h @@ -109,4 +109,11 @@ void ir_raw_init(void); #define load_rc5_decode()0 #endif +/* from ir-rc6-decoder.c */ +#ifdef CONFIG_IR_RC5_DECODER_MODULE +#define load_rc6_decode()request_module(ir-rc6-decoder) +#else +#define load_rc6_decode()0 +#endif + #endif /* _IR_RAW_EVENT */ you probably intended to use CONFIG_IR_RC6_DECODER_MODULE instead. Regards, Andreas -- 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 4/4] Add RC6 support to ir-core
On Fri, April 9, 2010 10:17, Andreas Oberritter wrote: +/* from ir-rc6-decoder.c */ +#ifdef CONFIG_IR_RC5_DECODER_MODULE you probably intended to use CONFIG_IR_RC6_DECODER_MODULE instead. Of course, thanks for noticing. Mauro, do you want a new patch or will you fix it yourself? (and by the way, Mauro, how come the patches went straight to the v4l-dvb.git tree? I assume they'll be merged back to your ir.git tree at a later stage?) -- David Härdeman -- 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: V4L2 and Media controller mini-summit in Helsinki 14.--16. June
Hi, On 04/09/2010 08:58 AM, Hans Verkuil wrote: On Monday 05 April 2010 21:36:35 Sakari Ailus wrote: Hello everyone, I'm glad to announce Nokia will be hosting a V4L2 and Media controller mini-summit in Helsinki, Finland from 14th to 16th June --- that's from Monday to Wednesday. The event replaces the V4L2 Media Controller mini-summit in Oslo in April / May proposed by Hans Verkuil. Just the location is different; Hans is still responsible for the technical content. Then I'd better start on that technical content :-) Here is a short overview of the topics I want to put on the agenda (in no particular order): - Media controller progress. Especially with regards to the roadmap of getting this merged. - Memory handling. See this link for a report on a preliminary meeting: http://www.mail-archive.com/linux-media@vger.kernel.org/msg16618.html It would be nice if we can spend some more time on the memory pool concept. - V4L1 removal. We need to decide how we are going to do this. In particular the role that libv4l1 can play in this is of interest. Let me chime in here by mail, as I assume I won't be able to attend (see below), libv4l1 can completely replace the in kernel compatibility layer. Moreover it cannot only completely replace it, it can even do a better job then the in kernel compat layer. Actually in many cases libv4l1 is already needed for v4l1 apps to work with v4l2 drivers: 1) Many v4l2 drivers don't implement VIDIOCGMBUF, which in the kernel compat implementation is something which needs to be handled at the driver level and thus separately for each driver. Since this is a rather important ioctl this means in practice that v4l1 apps won't work with these drivers using the kernel compat ioctl support. libv4l1 emulates VIDIOCGMBUF without needing any special driver support (it can even emulate it on drivers which only support read()). One well known example of a driver missing VIDIOCGMBUF support is uvcvideo. 2) Many video devices produce video formats v4l1 apps don't grok (and there aren't even VIDEO_PALETTE_FOO defines for them). libv4l1 will use libv4l2 + libv4lconvert to let the app see well known formats. So I definitely believe that libv4l1 can meet all v4l1 compat needs, and even do a better job then the in kernel code. But ... libv4l1 atm is not ready to fully replace the kernel compat ioctl stuff, as it relies on it in some cases. This is fixable, and fixing it isn't hard, but this needs someone to work on it. Patches welcome :) - Work on the V4L core framework: what is in place, what still needs to be done, what other parts can be moved to the core. - Compliance tests. I'd like to start discussing this as well. I think we have to start work on a tool that will do basic compliance testing of new (and existing) drivers. The API is so big that it is way too easy to forget things. My guess is that at least 80% of all drivers violate the spec in one way or another. Relates as well to the framework topic: if we can move more into the core, then it is much easier to enforce spec compliance. - Anything else someone wants to discuss? I know that there are various people who would like to use libv4l's video processing to work together with video processing abilities of various SOC's (Nokia and Intel come to mind here). So that the controlling of those video processing abilities (lens correction, whitebalance, etc, etc.) can be done with libv4l processing plugins rather then with solutions using custom ioctl's and daemons as is done now. I plan to write a RFC with a new libv4l plugin API for this in time for it to be discussed at the summit. It certainly would be nice if I could be present at the summit to discuss this in person, but -ENOBUDGET. If any of the companies interested in this work would be willing to sponsor my travel to the summit that would be great! Regards, Hans -- 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
[GIT PATCHES FOR 2.6.35] gspca for_2.6.35
Hi Mauro, The following changes since commit 680af931a10ba684c617038a0149281c193295ff: Mauro Carvalho Chehab (1): V4L/DVB: tm6000: fix compilation due to the lack of a semicolon are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.35 Erik Andrén (1): gspca - stv06xx: Remove the 046d:08da from the stv06xx driver. Jean-François Moine (3): gspca - main: Check the file doing stream on/off. gspca - main: Restart streaming after reqbuf. gspca - main: Stop the webcam when bandwidth too small. drivers/media/video/gspca/gspca.c | 84 --- drivers/media/video/gspca/stv06xx/stv06xx.c |2 - 2 files changed, 49 insertions(+), 37 deletions(-) Thanks. -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote: Hi, On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: Comments? I haven't seen this mentioned yet, but are there any plans for a sysfs interface to set up waking from suspend/standby on a particular IR scancode (for hardware decoders that support masking of comparing of the IR data), kind of analagous to the rtc framework's wakealarm sysfs file? This requires support at the hardware level. (You can't have CPU code running to decode IR pulses when your CPU is asleep.) I know of two video chips supported under linux that provide such a function. Wake-up from IR for these chips will rely on the kernel PCIe or USB infrastructure supporting PCIe or USB Power Managment Events from hardware. It will take a huge amount of work and time to get the respective linux video drivers to properly support suspend/resume properly. If you're waiting for me to get that working, I'll advise you to plan on getting off the couch and pushing the power switch for some time to come. ;) The MCE-USB, I *speculate*, can perform wakes. It's driver would need to support that, if it can. 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
Re: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
On Thu, 2010-04-08 at 13:39 +0200, David Härdeman wrote:
drivers/media/IR/ir-raw-event.c is currently written with the assumption
that all raw hardware will generate events only on state change (i.e.
when a pulse or space starts).
However, some hardware (like mceusb, probably the most popular IR receiver
out there) only generates duration data (and that data is buffered so using
any kind of timing on the data is futile).
Furthermore, using signed int's to represent pulse/space durations in ms
is a well-known approach to anyone with experience in writing ir decoders.
This patch (which has been tested this time) is still a RFC on my proposed
interface changes.
Changes since last version:
o s64's are used to represent pulse/space durations in ns.
o Lots of #defines are used in the decoders
o Refreshed to apply cleanly on top of Mauro's current git tree
o Jon's comments wrt. interrupt-context safe functions have been added
Index: ir/drivers/media/IR/ir-raw-event.c
===
--- ir.orig/drivers/media/IR/ir-raw-event.c 2010-04-08 12:30:28.036098192
+0200
+++ ir/drivers/media/IR/ir-raw-event.c2010-04-08 12:45:19.780145403
+0200
@@ -15,9 +15,10 @@
#include media/ir-core.h
#include linux/workqueue.h
#include linux/spinlock.h
+#include linux/sched.h
-/* Define the max number of bit transitions per IR keycode */
-#define MAX_IR_EVENT_SIZE256
+/* Define the max number of pulse/space transitions to buffer */
+#define MAX_IR_EVENT_SIZE 512
/* Used to handle IR raw handler extensions */
static LIST_HEAD(ir_raw_handler_list);
@@ -53,19 +54,30 @@
/* Used to load the decoders */
static struct work_struct wq_load;
+static void ir_raw_event_work(struct work_struct *work)
+{
+ s64 d;
+ struct ir_raw_event_ctrl *raw =
+ container_of(work, struct ir_raw_event_ctrl, rx_work);
+
+ while (kfifo_out(raw-kfifo, d, sizeof(d)) == sizeof(d))
+ RUN_DECODER(decode, raw-input_dev, d);
+}
+
int ir_raw_event_register(struct input_dev *input_dev)
{
struct ir_input_dev *ir = input_get_drvdata(input_dev);
- int rc, size;
+ int rc;
ir-raw = kzalloc(sizeof(*ir-raw), GFP_KERNEL);
if (!ir-raw)
return -ENOMEM;
- size = sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE * 2;
- size = roundup_pow_of_two(size);
+ ir-raw-input_dev = input_dev;
+ INIT_WORK(ir-raw-rx_work, ir_raw_event_work);
- rc = kfifo_alloc(ir-raw-kfifo, size, GFP_KERNEL);
+ rc = kfifo_alloc(ir-raw-kfifo, sizeof(s64) * MAX_IR_EVENT_SIZE,
+ GFP_KERNEL);
if (rc 0) {
kfree(ir-raw);
ir-raw = NULL;
@@ -90,6 +102,7 @@
if (!ir-raw)
return;
+ cancel_work_sync(ir-raw-rx_work);
RUN_DECODER(raw_unregister, input_dev);
kfifo_free(ir-raw-kfifo);
@@ -97,74 +110,90 @@
ir-raw = NULL;
}
-int ir_raw_event_store(struct input_dev *input_dev, enum raw_event_type type)
+/**
+ * ir_raw_event_store() - pass a pulse/space duration to the raw ir decoders
+ * @input_dev: the struct input_dev device descriptor
+ * @duration:duration of the pulse or space in ns
+ *
+ * This routine (which may be called from an interrupt context) stores a
+ * pulse/space duration for the raw ir decoding state machines. Pulses are
+ * signalled as positive values and spaces as negative values. A zero value
+ * will reset the decoding state machines.
+ */
+int ir_raw_event_store(struct input_dev *input_dev, s64 duration)
{
- struct ir_input_dev *ir = input_get_drvdata(input_dev);
- struct timespec ts;
- struct ir_raw_event event;
- int rc;
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
if (!ir-raw)
return -EINVAL;
- event.type = type;
- event.delta.tv_sec = 0;
- event.delta.tv_nsec = 0;
+ if (kfifo_in(ir-raw-kfifo, duration, sizeof(duration)) !=
sizeof(duration))
+ return -ENOMEM;
- ktime_get_ts(ts);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store);
- if (timespec_equal(ir-raw-last_event, event.delta))
- event.type |= IR_START_EVENT;
- else
- event.delta = timespec_sub(ts, ir-raw-last_event);
+/**
+ * ir_raw_event_store_edge() - notify raw ir decoders of the start of a
pulse/space
+ * @input_dev: the struct input_dev device descriptor
+ * @type:the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) is used to
+ * store the beginning of an ir pulse or space (or the start/end of ir
+ * reception) for the raw ir decoding state machines. This is used by
+ * hardware which does not provide durations directly but only interrupts
+ * (or similar
remote control for idVendor=2040, idProduct=5500 Siano MDTV
Hi, I am using this stick with a 2.6.33.2 kernel kernel.org) and kaffeine. Works nicely so far but the infrared remote does not work. I am quite happy to apply pacthes or experimental dirvers - are there any? Is there any documentation that woud allow me to write the code? Apr 8 15:05:23 localhost kernel: [ 1204.812906] usb 5-6: Product: WinTV MiniStick Apr 8 15:05:23 localhost kernel: [ 1204.812908] usb 5-6: Manufacturer: Hauppauge Computer Works Apr 8 15:05:23 localhost kernel: [ 1204.812910] usb 5-6: SerialNumber: f069684c Apr 8 15:05:23 localhost kernel: [ 1204.815314] usb 5-6: firmware: requesting sms1xxx-hcw-55xxx-dvbt-02.fw Apr 8 15:05:24 localhost kernel: [ 1205.396048] smscore_set_device_mode: firmware download success: sms1xxx-hcw-55xxx-dvbt-02.fw Apr 8 15:05:24 localhost kernel: [ 1205.396478] DVB: registering new adapter (Hauppauge WinTV MiniStick) Apr 8 15:05:24 localhost kernel: [ 1205.397538] DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... Regards Richard -- 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: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
On Fri, Apr 9, 2010 at 7:25 AM, Andy Walls awa...@md.metrocast.net wrote:
On Thu, 2010-04-08 at 13:39 +0200, David Härdeman wrote:
drivers/media/IR/ir-raw-event.c is currently written with the assumption
that all raw hardware will generate events only on state change (i.e.
when a pulse or space starts).
However, some hardware (like mceusb, probably the most popular IR receiver
out there) only generates duration data (and that data is buffered so using
any kind of timing on the data is futile).
Furthermore, using signed int's to represent pulse/space durations in ms
is a well-known approach to anyone with experience in writing ir decoders.
This patch (which has been tested this time) is still a RFC on my proposed
interface changes.
Changes since last version:
o s64's are used to represent pulse/space durations in ns.
o Lots of #defines are used in the decoders
o Refreshed to apply cleanly on top of Mauro's current git tree
o Jon's comments wrt. interrupt-context safe functions have been added
Index: ir/drivers/media/IR/ir-raw-event.c
===
--- ir.orig/drivers/media/IR/ir-raw-event.c 2010-04-08 12:30:28.036098192
+0200
+++ ir/drivers/media/IR/ir-raw-event.c 2010-04-08 12:45:19.780145403
+0200
@@ -15,9 +15,10 @@
#include media/ir-core.h
#include linux/workqueue.h
#include linux/spinlock.h
+#include linux/sched.h
-/* Define the max number of bit transitions per IR keycode */
-#define MAX_IR_EVENT_SIZE 256
+/* Define the max number of pulse/space transitions to buffer */
+#define MAX_IR_EVENT_SIZE 512
/* Used to handle IR raw handler extensions */
static LIST_HEAD(ir_raw_handler_list);
@@ -53,19 +54,30 @@
/* Used to load the decoders */
static struct work_struct wq_load;
+static void ir_raw_event_work(struct work_struct *work)
+{
+ s64 d;
+ struct ir_raw_event_ctrl *raw =
+ container_of(work, struct ir_raw_event_ctrl, rx_work);
+
+ while (kfifo_out(raw-kfifo, d, sizeof(d)) == sizeof(d))
+ RUN_DECODER(decode, raw-input_dev, d);
+}
+
int ir_raw_event_register(struct input_dev *input_dev)
{
struct ir_input_dev *ir = input_get_drvdata(input_dev);
- int rc, size;
+ int rc;
ir-raw = kzalloc(sizeof(*ir-raw), GFP_KERNEL);
if (!ir-raw)
return -ENOMEM;
- size = sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE * 2;
- size = roundup_pow_of_two(size);
+ ir-raw-input_dev = input_dev;
+ INIT_WORK(ir-raw-rx_work, ir_raw_event_work);
- rc = kfifo_alloc(ir-raw-kfifo, size, GFP_KERNEL);
+ rc = kfifo_alloc(ir-raw-kfifo, sizeof(s64) * MAX_IR_EVENT_SIZE,
+ GFP_KERNEL);
if (rc 0) {
kfree(ir-raw);
ir-raw = NULL;
@@ -90,6 +102,7 @@
if (!ir-raw)
return;
+ cancel_work_sync(ir-raw-rx_work);
RUN_DECODER(raw_unregister, input_dev);
kfifo_free(ir-raw-kfifo);
@@ -97,74 +110,90 @@
ir-raw = NULL;
}
-int ir_raw_event_store(struct input_dev *input_dev, enum raw_event_type
type)
+/**
+ * ir_raw_event_store() - pass a pulse/space duration to the raw ir decoders
+ * @input_dev: the struct input_dev device descriptor
+ * @duration: duration of the pulse or space in ns
+ *
+ * This routine (which may be called from an interrupt context) stores a
+ * pulse/space duration for the raw ir decoding state machines. Pulses are
+ * signalled as positive values and spaces as negative values. A zero value
+ * will reset the decoding state machines.
+ */
+int ir_raw_event_store(struct input_dev *input_dev, s64 duration)
{
- struct ir_input_dev *ir = input_get_drvdata(input_dev);
- struct timespec ts;
- struct ir_raw_event event;
- int rc;
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
if (!ir-raw)
return -EINVAL;
- event.type = type;
- event.delta.tv_sec = 0;
- event.delta.tv_nsec = 0;
+ if (kfifo_in(ir-raw-kfifo, duration, sizeof(duration)) !=
sizeof(duration))
+ return -ENOMEM;
- ktime_get_ts(ts);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store);
- if (timespec_equal(ir-raw-last_event, event.delta))
- event.type |= IR_START_EVENT;
- else
- event.delta = timespec_sub(ts, ir-raw-last_event);
+/**
+ * ir_raw_event_store_edge() - notify raw ir decoders of the start of a
pulse/space
+ * @input_dev: the struct input_dev device descriptor
+ * @type: the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) is used to
+ * store the beginning of an ir pulse or space (or the start/end of ir
+ * reception) for the raw ir decoding state machines. This is used by
+ * hardware which does not provide durations directly
Re: [PATCH 4/4] Add RC6 support to ir-core
David Härdeman wrote: On Fri, April 9, 2010 10:17, Andreas Oberritter wrote: +/* from ir-rc6-decoder.c */ +#ifdef CONFIG_IR_RC5_DECODER_MODULE you probably intended to use CONFIG_IR_RC6_DECODER_MODULE instead. Andreas, thanks for pointing it! Of course, thanks for noticing. Mauro, do you want a new patch or will you fix it yourself? Fixed. Just sent the correction patches upstream. As, in this case, it doesn't break bisect, I just added a one-line change patch. (and by the way, Mauro, how come the patches went straight to the v4l-dvb.git tree? I assume they'll be merged back to your ir.git tree at a later stage?) I just merged it back at the ir.git tree. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Apr 9, 2010 at 8:58 AM, Jarod Wilson ja...@redhat.com wrote: On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote: On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote: Hi, On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: Comments? I haven't seen this mentioned yet, but are there any plans for a sysfs interface to set up waking from suspend/standby on a particular IR scancode (for hardware decoders that support masking of comparing of the IR data), kind of analagous to the rtc framework's wakealarm sysfs file? This requires support at the hardware level. (You can't have CPU code running to decode IR pulses when your CPU is asleep.) I know of two video chips supported under linux that provide such a function. Wake-up from IR for these chips will rely on the kernel PCIe or USB infrastructure supporting PCIe or USB Power Managment Events from hardware. It will take a huge amount of work and time to get the respective linux video drivers to properly support suspend/resume properly. If you're waiting for me to get that working, I'll advise you to plan on getting off the couch and pushing the power switch for some time to come. ;) The MCE-USB, I *speculate*, can perform wakes. It's driver would need to support that, if it can. Yep, it can perform wakes, and the current lirc_mceusb does support it, though it requires some screwing around with echoing something into somewhere in sysfs (for the usb controller its attached to) to enable it, You probably need to tell the USB system to leave the MSMCE's power turned on during suspend. Maybe the MSMCE driver can tell the USB subsystem to leave it powered across suspend when the driver loads. from what I recall... Making it Just Work would be a good idea. -- Jarod Wilson ja...@redhat.com -- Jon Smirl jonsm...@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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi James, Andy Walls wrote: On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote: Hi, On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: Comments? I haven't seen this mentioned yet, but are there any plans for a sysfs interface to set up waking from suspend/standby on a particular IR scancode (for hardware decoders that support masking of comparing of the IR data), kind of analagous to the rtc framework's wakealarm sysfs file? This requires support at the hardware level. (You can't have CPU code running to decode IR pulses when your CPU is asleep.) The additions at IR core, if needed [1], shouldn't be hard, but the main changes should happen at the hardware driver level. There's no current plans for it, at least from my side, but, let's see if some hardware driver developers want to implement it on the corresponding driver. [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. -- 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: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
Jon Smirl wrote:
+/* macros for ir decoders */
+#define PULSE(units) ((units))
+#define SPACE(units) (-(units))
Encoding pulse vs space with a negative sign, even if now hidden with
macros, is still just using a sign instead of a boolean. Memory in
modern computers (and now microcontrollers) is cheap and only getting
cheaper. Don't give up readability, flexibility, or mainatainability,
for the sake of saving memory.
That was my point since the beginning: the amount of saved memory doesn't
justify the lack of readability. I understand such constraints when using
a hardware implementation on a microcontroller chip that offers just a very
few limited registers and a very small or no RAM. Also, if you define it with
something like:
struct {
unsigned mark : 1;
unsigned duration :31;
}
There's no memory spend at all: it will use just one unsigned int and it is
clearly indicated what's mark and what's duration.
I agree with this. I did it with signed ints in my first version, then
ripped it out and switched to duration + boolean. The duration/boolean
pair was much easier to understand. This is a matter of style, both
schemes work.
Yes. It shouldn't be hard to convert the code to better represent the
type/duration
vector in the future. Actually, that's one of the things i took into
consideration
when accepting the patch: the code readability were not seriously compromised
with
the usage of the macros, and, if needed, a patch converting it to a structured
type
wouldn't be hard.
#endif /* _IR_CORE */
Index: ir/drivers/media/IR/ir-nec-decoder.c
===
--- ir.orig/drivers/media/IR/ir-nec-decoder.c 2010-04-08 12:30:28.0
+0200
+++ ir/drivers/media/IR/ir-nec-decoder.c 2010-04-08 12:35:02.276484204
+0200
@@ -13,15 +13,16 @@
*/
#include media/ir-core.h
+#include linux/bitrev.h
#define NEC_NBITS32
-#define NEC_UNIT 559979 /* ns */
-#define NEC_HEADER_MARK (16 * NEC_UNIT)
-#define NEC_HEADER_SPACE (8 * NEC_UNIT)
-#define NEC_REPEAT_SPACE (4 * NEC_UNIT)
-#define NEC_MARK (NEC_UNIT)
-#define NEC_0_SPACE (NEC_UNIT)
-#define NEC_1_SPACE (3 * NEC_UNIT)
+#define NEC_UNIT 562500 /* ns */
Have you got a spec on the NEC protocol that justifies 562.5 usec?
From the best I can tell from the sources I have read and some deductive
reasoning, 560 usec is the actual number. Here's one:
http://www.audiodevelopers.com/temp/Remote_Controls.ppt
Note:
560 usec * 38 kHz ~= 4192/197
In the PPT you reference there are three numbers...
http://www.sbprojects.com/knowledge/ir/nec.htm
560us
1.12ms
2.25ms
I think those are rounding errors.
562.5 * 2 = 1.125ms * 2 = 2.25ms
Most IR protocols are related in a power of two pattern for their
timings to make them easy to decode.
The protocol doesn't appear to be based on an even number of 38Khz cycles.
These are easy things to change as we get better data on the protocols.
I don't think that the actual number really matters much. The decoders are
reliable enough to work with such small differences. I suspect that, in
practice, hardware developers just use a close frequency that can be divided
by some existing XTAL clock already available at the machines. In the case of
video devices, most of them use a 27 MHz clock. If divided by 711, this gives
a clock of 37.974 kHz, and the closest timings are 579 us and 605 us.
So, in practical, I think we'll see much more devices using 579 us than
560 us or 562 us.
and that the three numbers that yield ~560 usec don't evenly divide each
other:
$ factor 4192 197 38000
4192: 2 2 2 2 2 131
197: 197
38000: 2 2 2 2 5 5 5 19
which strikes me as being done on purpose (maybe only by me?).
Also note that:
4192 / 38 kHz = 110.32 usec
and public sources list 110 usec as the NEC repeat period.
+#define NEC_HEADER_PULSE PULSE(16)
+#define NEC_HEADER_SPACE SPACE(8)
+#define NEC_REPEAT_SPACE SPACE(4)
+#define NEC_BIT_PULSEPULSE(1)
+#define NEC_BIT_0_SPACE SPACE(1)
+#define NEC_BIT_1_SPACE SPACE(3)
This is slightly better than your previous patch, but the original
#defines were still clearer. A maintainer coming through has to spend
time and energy on asking 16 what? for example.
The units can be expressed as a comment:
#define NEC_BIT_PULSEPULSE(1) /* nec units */
A patch like that is welcome.
--
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] V4L/DVB: budget-av: wait longer for frontend to power on
Mauro Carvalho Chehab wrote: Bjørn Mork wrote: Some devices need much more time than 100ms to power on, leading to a failure to enable the frontend on the first attempt. Instead we get [ 38.194200] saa7146: register extension 'budget_av'. [ 38.253828] budget_av :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 38.601572] saa7146: found saa7146 @ mem c9c6ac00 (revision 1, irq 17) (0x1894,0x0022). [ 39.251324] saa7146 (0): dma buffer size 1347584 [ 39.306757] DVB: registering new adapter (KNC1 DVB-C MK3) [ 39.462785] adapter failed MAC signature check [ 39.516159] encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff [ 39.892397] KNC1-0: MAC addr = 00:09:d6:6d:94:5c [ 40.552028] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.580044] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.608026] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.636027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.652026] DVB: TDA10023(-1): tda10023_writereg, writereg error (reg == 0x00, val == 0x33, ret == -5) [ 40.664027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.692027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.720027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.748027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.764025] DVB: TDA10023(-1): tda10023_readreg: readreg error (reg == 0x1a, ret == -5) [ 40.764067] budget-av: A frontend driver was not found for device [1131:7146] subsystem [1894:0022] Unloading and the reloading the driver will work around this problem. But it can also be easily fixed by increasing the wait period after powering on. The optimum value is unclear to me. But I've found the 500 ms is not enough. 5 s is enough for my card, but might be more than actually needed. However, as long as we don't handle this failure more gracefully, then the timeout need to be long enough. Signed-off-by: Bjørn Mork bj...@mork.no Cc: sta...@kernel.org --- Hello, I have recently bought a KNC1 clone, called Mystique CaBiX-C2. This card would just not work on reboot in my system, giving the errors shown above. Unloading the module and then loading it again always fixed the problem, indicating that it was just a startup timing problem. As you can see, the i2c timeouts are from the frontend attach function, tda10023_attach(): /* wakeup if in standby */ tda10023_writereg (state, 0x00, 0x33); /* check if the demod is there */ if ((tda10023_readreg(state, 0x1a) 0xf0) != 0x70) goto error; cleary showing that it just isn't responding yet at that point. I first tried increasing the msleep() to 500 ms, but still got the same error. Increasing it to 5000 ms helped, however, and made my card work from boot. I have not tried any values inbetween, as each attempt AFAIK requires a reboot to get the card into the cold state where it will fail. dmesg with the patch installed: [ 37.786955] saa7146: register extension 'budget_av'. [ 37.846592] budget_av :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 37.933318] saa7146: found saa7146 @ mem c9c70c00 (revision 1, irq 17) (0x1894,0x0022). [ 38.037851] saa7146 (0): dma buffer size 1347584 [ 38.093224] DVB: registering new adapter (KNC1 DVB-C MK3) [ 38.194254] adapter failed MAC signature check [ 38.247527] encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff [ 38.622678] KNC1-0: MAC addr = 00:09:d6:6d:94:5c [ 43.765897] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... [ 43.851587] budget-av: ci interface initialised. Please consider this patch. Or maybe it is possible to wait smarter, testing actual frontend power status instead of just a blind sleep? I've also included a CC stable as I've had the same problem with the 2.6.32 and 2.6.33 stable drivers. Are you sure you really need 5 seconds to initialize? This time is probably board-specific, and shouldn't be applied as-is. So, if you really need such high timeout, it should be added inside the switch. I dunno if is there a way to test if the power-on cycle has completed, but for sure an approach like that would be better than blindly waiting for 5 secs. Mauro, please do not apply this patch! Afaik there is no tuner which takes 5 seconds to initialize. (And if there was one, it would be a bad idea to add a 5s delay for all tuners!) The saa7146_i2c_writeout errors are likely caused by broken hardware. CU Oliver --
Re: [PATCH] V4L/DVB: budget-av: wait longer for frontend to power on
Oliver Endriss wrote: Mauro Carvalho Chehab wrote: Bjørn Mork wrote: Some devices need much more time than 100ms to power on, leading to a failure to enable the frontend on the first attempt. Instead we get [ 38.194200] saa7146: register extension 'budget_av'. [ 38.253828] budget_av :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 38.601572] saa7146: found saa7146 @ mem c9c6ac00 (revision 1, irq 17) (0x1894,0x0022). [ 39.251324] saa7146 (0): dma buffer size 1347584 [ 39.306757] DVB: registering new adapter (KNC1 DVB-C MK3) [ 39.462785] adapter failed MAC signature check [ 39.516159] encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff [ 39.892397] KNC1-0: MAC addr = 00:09:d6:6d:94:5c [ 40.552028] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.580044] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.608026] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.636027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.652026] DVB: TDA10023(-1): tda10023_writereg, writereg error (reg == 0x00, val == 0x33, ret == -5) [ 40.664027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.692027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.720027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.748027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 40.764025] DVB: TDA10023(-1): tda10023_readreg: readreg error (reg == 0x1a, ret == -5) [ 40.764067] budget-av: A frontend driver was not found for device [1131:7146] subsystem [1894:0022] Unloading and the reloading the driver will work around this problem. But it can also be easily fixed by increasing the wait period after powering on. The optimum value is unclear to me. But I've found the 500 ms is not enough. 5 s is enough for my card, but might be more than actually needed. However, as long as we don't handle this failure more gracefully, then the timeout need to be long enough. Signed-off-by: Bjørn Mork bj...@mork.no Cc: sta...@kernel.org --- Hello, I have recently bought a KNC1 clone, called Mystique CaBiX-C2. This card would just not work on reboot in my system, giving the errors shown above. Unloading the module and then loading it again always fixed the problem, indicating that it was just a startup timing problem. As you can see, the i2c timeouts are from the frontend attach function, tda10023_attach(): /* wakeup if in standby */ tda10023_writereg (state, 0x00, 0x33); /* check if the demod is there */ if ((tda10023_readreg(state, 0x1a) 0xf0) != 0x70) goto error; cleary showing that it just isn't responding yet at that point. I first tried increasing the msleep() to 500 ms, but still got the same error. Increasing it to 5000 ms helped, however, and made my card work from boot. I have not tried any values inbetween, as each attempt AFAIK requires a reboot to get the card into the cold state where it will fail. dmesg with the patch installed: [ 37.786955] saa7146: register extension 'budget_av'. [ 37.846592] budget_av :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 37.933318] saa7146: found saa7146 @ mem c9c70c00 (revision 1, irq 17) (0x1894,0x0022). [ 38.037851] saa7146 (0): dma buffer size 1347584 [ 38.093224] DVB: registering new adapter (KNC1 DVB-C MK3) [ 38.194254] adapter failed MAC signature check [ 38.247527] encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff [ 38.622678] KNC1-0: MAC addr = 00:09:d6:6d:94:5c [ 43.765897] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... [ 43.851587] budget-av: ci interface initialised. Please consider this patch. Or maybe it is possible to wait smarter, testing actual frontend power status instead of just a blind sleep? I've also included a CC stable as I've had the same problem with the 2.6.32 and 2.6.33 stable drivers. Are you sure you really need 5 seconds to initialize? This time is probably board-specific, and shouldn't be applied as-is. So, if you really need such high timeout, it should be added inside the switch. I dunno if is there a way to test if the power-on cycle has completed, but for sure an approach like that would be better than blindly waiting for 5 secs. Mauro, please do not apply this patch! Don't worry, I won't apply this patch. Afaik there is no tuner which takes 5 seconds to initialize. (And if there was one, it would be a bad idea to add a 5s delay for all tuners!) Yes, that's my point: if is there such hardware, the fix should touch only on the hardware with that broken design. (btw, there is one tuner that takes almost 30 seconds to
Re: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
On Fri, Apr 9, 2010 at 10:00 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Jon Smirl wrote:
+/* macros for ir decoders */
+#define PULSE(units) ((units))
+#define SPACE(units) (-(units))
Encoding pulse vs space with a negative sign, even if now hidden with
macros, is still just using a sign instead of a boolean. Memory in
modern computers (and now microcontrollers) is cheap and only getting
cheaper. Don't give up readability, flexibility, or mainatainability,
for the sake of saving memory.
That was my point since the beginning: the amount of saved memory doesn't
justify the lack of readability. I understand such constraints when using
a hardware implementation on a microcontroller chip that offers just a very
few limited registers and a very small or no RAM. Also, if you define it with
something like:
struct {
unsigned mark : 1;
unsigned duration :31;
}
There's no memory spend at all: it will use just one unsigned int and it is
clearly indicated what's mark and what's duration.
I agree with this. I did it with signed ints in my first version, then
ripped it out and switched to duration + boolean. The duration/boolean
pair was much easier to understand. This is a matter of style, both
schemes work.
Yes. It shouldn't be hard to convert the code to better represent the
type/duration
vector in the future. Actually, that's one of the things i took into
consideration
when accepting the patch: the code readability were not seriously compromised
with
the usage of the macros, and, if needed, a patch converting it to a
structured type
wouldn't be hard.
#endif /* _IR_CORE */
Index: ir/drivers/media/IR/ir-nec-decoder.c
===
--- ir.orig/drivers/media/IR/ir-nec-decoder.c 2010-04-08
12:30:28.0 +0200
+++ ir/drivers/media/IR/ir-nec-decoder.c 2010-04-08
12:35:02.276484204 +0200
@@ -13,15 +13,16 @@
*/
#include media/ir-core.h
+#include linux/bitrev.h
#define NEC_NBITS 32
-#define NEC_UNIT 559979 /* ns */
-#define NEC_HEADER_MARK (16 * NEC_UNIT)
-#define NEC_HEADER_SPACE (8 * NEC_UNIT)
-#define NEC_REPEAT_SPACE (4 * NEC_UNIT)
-#define NEC_MARK (NEC_UNIT)
-#define NEC_0_SPACE (NEC_UNIT)
-#define NEC_1_SPACE (3 * NEC_UNIT)
+#define NEC_UNIT 562500 /* ns */
Have you got a spec on the NEC protocol that justifies 562.5 usec?
From the best I can tell from the sources I have read and some deductive
reasoning, 560 usec is the actual number. Here's one:
http://www.audiodevelopers.com/temp/Remote_Controls.ppt
Note:
560 usec * 38 kHz ~= 4192/197
In the PPT you reference there are three numbers...
http://www.sbprojects.com/knowledge/ir/nec.htm
560us
1.12ms
2.25ms
I think those are rounding errors.
562.5 * 2 = 1.125ms * 2 = 2.25ms
Most IR protocols are related in a power of two pattern for their
timings to make them easy to decode.
The protocol doesn't appear to be based on an even number of 38Khz cycles.
These are easy things to change as we get better data on the protocols.
I don't think that the actual number really matters much. The decoders are
reliable enough to work with such small differences. I suspect that, in
I found that the ratios between the numbers are the critical item, not
the numbers themselves.
The absolute numbers are used to differentiate the protocol families.
The total length of the messages is also important in differentiating
the families.
The protocol decoders should reconcile the total message length as
another check to make sure they aren't triggering on a message in the
wrong protocol. Add up the durations of everything seen and see if it
is within 5-10% of the expected message length.
practice, hardware developers just use a close frequency that can be divided
by some existing XTAL clock already available at the machines. In the case of
video devices, most of them use a 27 MHz clock. If divided by 711, this gives
a clock of 37.974 kHz, and the closest timings are 579 us and 605 us.
So, in practical, I think we'll see much more devices using 579 us than
560 us or 562 us.
and that the three numbers that yield ~560 usec don't evenly divide each
other:
$ factor 4192 197 38000
4192: 2 2 2 2 2 131
197: 197
38000: 2 2 2 2 5 5 5 19
which strikes me as being done on purpose (maybe only by me?).
Also note that:
4192 / 38 kHz = 110.32 usec
and public sources list 110 usec as the NEC repeat period.
+#define NEC_HEADER_PULSE PULSE(16)
+#define NEC_HEADER_SPACE SPACE(8)
+#define NEC_REPEAT_SPACE SPACE(4)
+#define NEC_BIT_PULSE PULSE(1)
+#define NEC_BIT_0_SPACE SPACE(1)
+#define NEC_BIT_1_SPACE SPACE(3)
This is slightly better than your previous patch,
Re: [PATCH] V4L/DVB: budget-av: wait longer for frontend to power on
Mauro Carvalho Chehab mche...@redhat.com writes: Oliver Endriss wrote: Mauro, please do not apply this patch! Don't worry, I won't apply this patch. Afaik there is no tuner which takes 5 seconds to initialize. (And if there was one, it would be a bad idea to add a 5s delay for all tuners!) Yes, that's my point: if is there such hardware, the fix should touch only on the hardware with that broken design. (btw, there is one tuner that takes almost 30 seconds to initialize: the firmware load for xc3028 on tm6000 rev A should go on slow speed, otherwise, it fails loading - the i2c implementation on tm6000 were really badly designed) The saa7146_i2c_writeout errors are likely caused by broken hardware. I think so. You are so right both of you. Please drop the patch. I believe this problem was yet another symptom of my faulty SATA hard drive. The driver is working fine with the default 100 ms timeout after replacing that drive. Sorry about all the unnecessary work I created for you, and thanks for taking the time to review this even though you suspected user/hardware error. Bjørn -- 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] cx88: implement sharpness control
On 04/09/2010 06:33 AM, Mauro Carvalho Chehab wrote: You're not adjusting the sharpness. Instead, you're changing the vertical tap filter, and just for the even frames, plus the notch filter. Tricky, and you're probably affecting the sharpness, but on an indirect and non-linear way, as you're adjusting different measures. No, I actually change the luma peak filter, which can add a peak of up to about 6 dB centered at the chroma subcarrier frequency. So, it does increase sharpness, and horizontally, not vertically. I did test the patch before submitting it. Also, there is code in the patch that sets the parameter for the odd field as well. So, in fact, this control affects three registers: two for the peak filter, and a third one for the notch filter. If this is really needed, it would be better to break it into two controls (one for the notch filter and another for the vertical tap filter). Yes, that could possibly have been a good idea to have a separate control for the notch filter. It was just easier to implement this way, and I think there is no existing control that would be well suited for the notch filter. Since both parameters do affect sharpness in some way, I implemented it as a single control, rather than creating a separate new one. Also, the side effect is not good: if you're using those bits, your code should assure that no other part of the driver will touch on the used bits, and that the device will be initialized with the default standard. That is correct, and I did note that it would be addressed later if the general idea of implementing the control is accepted. Fortunately, the registers are changed elsewhere at only about two places. By the way, did you have a look at the other two cx88 patches (containing minor fixes only) I sent at the same time ? -- 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: WARNINGS
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 Apr 9 19:00:23 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14561:7c0b887911cf git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8b680a770f6bdcd52f6816d7a5fe7aee9a9f7c78 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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 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
Found NEC IR specification in NEC uPD6122 datasheet (Re: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations)
On Fri, 2010-04-09 at 11:00 -0300, Mauro Carvalho Chehab wrote: Jon Smirl wrote: #define NEC_NBITS32 -#define NEC_UNIT 559979 /* ns */ -#define NEC_HEADER_MARK (16 * NEC_UNIT) -#define NEC_HEADER_SPACE (8 * NEC_UNIT) -#define NEC_REPEAT_SPACE (4 * NEC_UNIT) -#define NEC_MARK (NEC_UNIT) -#define NEC_0_SPACE (NEC_UNIT) -#define NEC_1_SPACE (3 * NEC_UNIT) +#define NEC_UNIT 562500 /* ns */ Have you got a spec on the NEC protocol that justifies 562.5 usec? From the best I can tell from the sources I have read and some deductive reasoning, 560 usec is the actual number. Here's one: http://www.audiodevelopers.com/temp/Remote_Controls.ppt Note: 560 usec * 38 kHz ~= 4192/197 In the PPT you reference there are three numbers... http://www.sbprojects.com/knowledge/ir/nec.htm 560us 1.12ms 2.25ms I think those are rounding errors. 562.5 * 2 = 1.125ms * 2 = 2.25ms Most IR protocols are related in a power of two pattern for their timings to make them easy to decode. The protocol doesn't appear to be based on an even number of 38Khz cycles. These are easy things to change as we get better data on the protocols. I just found authoritative data. It is in the datasheet for the uPD6122 authored by NEC Corporation: http://www.datasheetcatalog.org/datasheet/nec/UPD6122G-002.pdf Looking at page 11, especially line (5), it appears that all the timings are derived in terms of 1/3 of a carrier period and powers of 2. So Resonator frequency: fr = 455 kHz (AM IF parts are cheap apparently) Carrier frequency: fc = fr / 12 = 37.91667 kHz Duty cycle: 1/3 unit pulse: 64/3 / fc = 562.637 us (Jon was closer than me) header pulse: 16 * 64/3 / fc = 9.002 ms header space: 8 * 64/3 / fc = 4.501 ms repeat space: 4 * 64/3 / fc = 2.250 ms '1' symbol: 4 * 64/3 / fc = 2.250 ms '0' symbol: 2 * 64/3 / fc = 1.125 ms repeat time: 192 * 64/3 / fc = 108.026 ms Page 15 also shows that the older chips had a silence gap that could result in signals coming closer than 108 ms. Whew! I'm glad I've worked through my fit of Obsessive Compulsive Disorder for now. :) 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
Re: [PATCH] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble
On Thu, 2010-04-08 at 12:05 +0200, Bjørn Mork wrote: Ehh, this is very embarrassing, but please disregard all my statements about a hanging system related to IRQF_DISABLED. It turns out that I've had a faulty SATA hard drive which probably have caused all these problems. I do not understand the inner workings of the SATA hardware and software, but it appears that this drive has been able to block interrupts for a considerable time without SMART detecting any error at all. I wrongly suspected saa7146 to be the cause because these problems appeared after adding the saa7146 hardware. But that was probably just a coincidence (or maybe not really, only unrelated: I suspect that the problem was triggered by the powercycle when adding this card) The drive has now been replaced, and I will start verifying that use of saa7146 with IRQF_DISABLED does not in fact pose any real problems at all. Don't bother. It's probably a good thing you found your root cause. Your patch was going to be invalidated in the near future: http://lwn.net/Articles/380931/ It appears that IRQF_DISABLED behavior is to be the default behavior for all drivers and the flag is to have no effect. I still find the discussion about it's usefulness interesting though... Good. :) 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
Re: [PATCH] Teach drivers/media/IR/ir-raw-event.c to use durations
On Thu, 2010-04-08 at 18:10 +0200, David Härdeman wrote: With this patch: s64 int's are used to represent pulse/space durations in ns If performing divides on 64 bit numbers, please check to make sure your code compiles, links, and loads on a 32-bit system. We've had problems in the past in where gcc will build the module to reference __udivdi3 under 32-bit kernels; but that symbol is not in the kernel. Search for 'do_div' in: linux/drivers/media/video/cx18/cx18-av-core.c for a simple example divide that works on both 64 and 32 bit machines. 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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote: If you're waiting for me to get that working, I'll advise you to plan on getting off the couch and pushing the power switch for some time to come. ;) :-) On Friday 09 April 2010 14:01:46 Mauro Carvalho Chehab wrote: The additions at IR core, if needed [1], shouldn't be hard, but the main changes should happen at the hardware driver level. There's no current plans for it, at least from my side, but, let's see if some hardware driver developers want to implement it on the corresponding driver. [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. Thanks for the info Mauro. Cheers James signature.asc Description: This is a digitally signed message part.
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. Really? Have you actually seen any hardware where a particular scan code can be used to wake up the hardware? The only hardware I have seen has the ability to unsuspend on arrival of IR traffic, but you didn't have the granularity to dictate that it only wake up on particular scancodes. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s2255drv: v4l2_dev bug fix
# HG changeset patch
# User Dean Anderson linux-...@sensoray.com
# Date 1270850190 25200
# Node ID 040de984898870b01dfe553319aa18edb3a442bb
# Parent f987f637d904a281992844f2b17f805edd4734c2
s2255drv: v4l2_dev fixed
From: Dean Anderson linux-...@sensoray.com
v4l2_dev should be registered once only.
usb_set_intfdata should not be used when using v4l2_device_register
and a non-NULL argument for the device.
Priority: high
Signed-off-by: Dean Anderson linux-...@sensoray.com
diff -r f987f637d904 -r 040de9848988 linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Fri Apr 09 14:28:44 2010 -0700
+++ b/linux/drivers/media/video/s2255drv.c Fri Apr 09 14:56:30 2010 -0700
@@ -229,7 +229,7 @@
struct s2255_dev {
struct video_device vdev[MAX_CHANNELS];
- struct v4l2_device v4l2_dev[MAX_CHANNELS];
+ struct v4l2_device v4l2_dev;
int channels; /* number of channels registered */
int frames;
struct mutexlock;
@@ -278,7 +278,14 @@
u16 pid; /* product id */
struct kref kref;
};
-#define to_s2255_dev(d) container_of(d, struct s2255_dev, kref)
+
+/* kref will be removed soon */
+#define to_s2255_dev_from_kref(d) container_of(d, struct s2255_dev, kref)
+
+static inline struct s2255_dev *to_s2255_dev(struct v4l2_device *v4l2_dev)
+{
+ return container_of(v4l2_dev, struct s2255_dev, v4l2_dev);
+}
struct s2255_fmt {
char *name;
@@ -1829,7 +1836,7 @@
static void s2255_destroy(struct kref *kref)
{
- struct s2255_dev *dev = to_s2255_dev(kref);
+ struct s2255_dev *dev = to_s2255_dev_from_kref(kref);
/* board shutdown stops the read pipe if it is running */
s2255_board_shutdown(dev);
/* make sure firmware still not trying to load */
@@ -1947,11 +1954,9 @@
int ret;
int i;
int cur_nr = video_nr;
- for (i = 0; i MAX_CHANNELS; i++) {
- ret = v4l2_device_register(dev-udev-dev, dev-v4l2_dev[i]);
- if (ret)
- goto unreg_v4l2;
- }
+ ret = v4l2_device_register(dev-interface-dev, dev-v4l2_dev);
+ if (ret)
+ return ret;
/* initialize all video 4 linux */
/* register 4 video devices */
for (i = 0; i MAX_CHANNELS; i++) {
@@ -1976,7 +1981,7 @@
break;
}
dev-channels++;
- v4l2_info(dev-v4l2_dev[i], V4L2 device registered as %s\n,
+ v4l2_info(dev-v4l2_dev, V4L2 device registered as %s\n,
video_device_node_name(dev-vdev[i]));
}
@@ -1984,15 +1989,13 @@
S2255_MAJOR_VERSION,
S2255_MINOR_VERSION);
/* if no channels registered, return error and probe will fail*/
- if (dev-channels == 0)
+ if (dev-channels == 0) {
+ v4l2_device_unregister(dev-v4l2_dev);
return ret;
+ }
if (dev-channels != MAX_CHANNELS)
printk(KERN_WARNING s2255: Not all channels available.\n);
return 0;
-unreg_v4l2:
- for (i-- ; i 0; i--)
- v4l2_device_unregister(dev-v4l2_dev[i]);
- return ret;
}
/* this function moves the usb stream read pipe data
@@ -2595,8 +2598,6 @@
dev_err(interface-dev, Could not find bulk-in endpoint\n);
goto errorEP;
}
- /* set intfdata */
- usb_set_intfdata(interface, dev);
init_timer(dev-timer);
dev-timer.function = s2255_timer;
dev-timer.data = (unsigned long)dev-fw_data;
@@ -2681,13 +2682,12 @@
return retval;
}
-
/* disconnect routine. when board is removed physically or with rmmod */
static void s2255_disconnect(struct usb_interface *interface)
{
- struct s2255_dev *dev = NULL;
+ struct s2255_dev *dev = to_s2255_dev(usb_get_intfdata(interface));
int i;
- dev = usb_get_intfdata(interface);
+ v4l2_device_unregister(dev-v4l2_dev);
/* unregister each video device. */
for (i = 0; i MAX_CHANNELS; i++)
if (video_is_registered(dev-vdev[i]))
@@ -2701,7 +2701,6 @@
dev-vidstatus_ready[i] = 1;
wake_up(dev-wait_vidstatus[i]);
}
- usb_set_intfdata(interface, NULL);
kref_put(dev-kref, s2255_destroy);
dev_info(interface-dev, %s\n, __func__);
}
--
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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote: On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. Really? Have you actually seen any hardware where a particular scan code can be used to wake up the hardware? The only hardware I have seen has the ability to unsuspend on arrival of IR traffic, but you didn't have the granularity to dictate that it only wake up on particular scancodes. The CX23888 and CX23102 can do it. Basically any IR pulse pattern your heart desires; within reason. And any carrier freq you want too; within reason. But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere near properly supporing suspend/resume for their main video and DMA functions, AFAIK. 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] s2255drv: removes kref tracking and videodev parent
# HG changeset patch
# User Dean Anderson linux-...@sensoray.com
# Date 1270853488 25200
# Node ID f2f44853e2eb914d4fc6c7004631839b86fb6d0e
# Parent 040de984898870b01dfe553319aa18edb3a442bb
s2255drv: removes kref tracking and videodev parent
From: Dean Anderson linux-...@sensoray.com
kref replaced as suggested in code review
uses atomic variable to track when it is ok to delete device
removes setting of video device parent, which is now
handled in v4l2_device.c
Priority: normal
Signed-off-by: Dean Anderson linux-...@sensoray.com
diff -r 040de9848988 -r f2f44853e2eb linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Fri Apr 09 14:56:30 2010 -0700
+++ b/linux/drivers/media/video/s2255drv.c Fri Apr 09 15:51:28 2010 -0700
@@ -230,7 +230,7 @@
struct s2255_dev {
struct video_device vdev[MAX_CHANNELS];
struct v4l2_device v4l2_dev;
- int channels; /* number of channels registered */
+ atomic_tchannels; /* number of channels registered */
int frames;
struct mutexlock;
struct mutexopen_lock;
@@ -276,12 +276,8 @@
/* dsp firmware version (f2255usb.bin) */
int dsp_fw_ver;
u16 pid; /* product id */
- struct kref kref;
};
-/* kref will be removed soon */
-#define to_s2255_dev_from_kref(d) container_of(d, struct s2255_dev, kref)
-
static inline struct s2255_dev *to_s2255_dev(struct v4l2_device *v4l2_dev)
{
return container_of(v4l2_dev, struct s2255_dev, v4l2_dev);
@@ -372,7 +368,7 @@
struct s2255_mode *mode);
static int s2255_board_shutdown(struct s2255_dev *dev);
static void s2255_fwload_start(struct s2255_dev *dev, int reset);
-static void s2255_destroy(struct kref *kref);
+static void s2255_destroy(struct s2255_dev *dev);
static long s2255_vendor_req(struct s2255_dev *dev, unsigned char req,
u16 index, u16 value, void *buf,
s32 buf_len, int bOut);
@@ -1720,7 +1716,7 @@
dprintk(1, s2255: open called (dev=%s)\n,
video_device_node_name(vdev));
- for (i = 0; i dev-channels; i++)
+ for (i = 0; i MAX_CHANNELS; i++)
if (dev-vdev[i] == vdev) {
cur_channel = i;
break;
@@ -1834,9 +1830,8 @@
return rc;
}
-static void s2255_destroy(struct kref *kref)
+static void s2255_destroy(struct s2255_dev *dev)
{
- struct s2255_dev *dev = to_s2255_dev_from_kref(kref);
/* board shutdown stops the read pipe if it is running */
s2255_board_shutdown(dev);
/* make sure firmware still not trying to load */
@@ -1936,7 +1931,9 @@
static void s2255_video_device_release(struct video_device *vdev)
{
struct s2255_dev *dev = video_get_drvdata(vdev);
- kref_put(dev-kref, s2255_destroy);
+ dprintk(4, %s, chnls: %d \n, __func__, atomic_read(dev-channels));
+ if (atomic_dec_and_test(dev-channels))
+ s2255_destroy(dev);
return;
}
@@ -1965,7 +1962,8 @@
dev-vidq[i].channel = i;
/* register 4 video devices */
memcpy(dev-vdev[i], template, sizeof(struct video_device));
- dev-vdev[i].parent = dev-interface-dev;
+ dev-vdev[i].v4l2_dev = dev-v4l2_dev;
+ video_set_drvdata(dev-vdev[i], dev);
if (video_nr == -1)
ret = video_register_device(dev-vdev[i],
VFL_TYPE_GRABBER,
@@ -1974,13 +1972,12 @@
ret = video_register_device(dev-vdev[i],
VFL_TYPE_GRABBER,
cur_nr + i);
- video_set_drvdata(dev-vdev[i], dev);
if (ret) {
dev_err(dev-udev-dev,
failed to register video device!\n);
break;
}
- dev-channels++;
+ atomic_inc(dev-channels);
v4l2_info(dev-v4l2_dev, V4L2 device registered as %s\n,
video_device_node_name(dev-vdev[i]));
@@ -1989,11 +1986,11 @@
S2255_MAJOR_VERSION,
S2255_MINOR_VERSION);
/* if no channels registered, return error and probe will fail*/
- if (dev-channels == 0) {
+ if (atomic_read(dev-channels) == 0) {
v4l2_device_unregister(dev-v4l2_dev);
return ret;
}
- if (dev-channels != MAX_CHANNELS)
+ if (atomic_read(dev-channels) != MAX_CHANNELS)
printk(KERN_WARNING s2255: Not all channels available.\n);
return 0;
}
@@ -2566,7 +2563,7 @@
s2255_dev_err(interface-dev, out of
[PATCH] DVB-T initial scan file for Israel (dvb-utils)
Hi, Here is an initial scan file for IBA's DVB-T transmitters. Generated from info at http://www.iba.org.il/reception/ (Hebrew) # HG changeset patch # User Shaul Kremer shau...@gmail.com # Date 1270854557 -10800 # Node ID ac84f6db6f031db82509c247ac1775ca48b0e2f3 # Parent 7de0663facd92bbb9049aeeda3dcba9601228f30 Added DVB-T initial tuning tables for Israel. diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN1 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN1 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-1 transmitter (northern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN2 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN2 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-2 transmitter (central Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN3 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN3 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-3 transmitter (southern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Andy Walls wrote: On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote: On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. Really? Have you actually seen any hardware where a particular scan code can be used to wake up the hardware? The only hardware I have seen has the ability to unsuspend on arrival of IR traffic, but you didn't have the granularity to dictate that it only wake up on particular scancodes. The CX23888 and CX23102 can do it. Basically any IR pulse pattern your heart desires; within reason. And any carrier freq you want too; within reason. But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere near properly supporing suspend/resume for their main video and DMA functions, AFAIK. AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching TV, do a suspend and waking the hardware again, and you'll keep seeing the same channel (I tested it some time ago, when the proper suspend code were added, on analog mode, with alsa enabled). Other drivers can suspend/resume, but they won't properly restore the video registers, so, you'll see artifacts when it returns. So, yes, you're right: before any suspend/resume code on those drivers, we first need to add some code to properly handle kernel threads and work queues during suspend, and to restore all the registers to a sane state at resume, before implementing IR wakeup on them. In the case of mceusb, as there is already an userspace code for it on lirc, it would probably not be that hard to make this feature to work with ir-core. [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software decoder, the IR IRQ might be used to wake, but this means that everything, even a glitch, would wake the hardware, so this won't work neither. -- 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] DVB-T initial scan file for Israel (dvb-utils)
Hi Shaul, Am Samstag, den 10.04.2010, 02:16 +0300 schrieb Shaul Kremer: Hi, Here is an initial scan file for IBA's DVB-T transmitters. Generated from info at http://www.iba.org.il/reception/ (Hebrew) # HG changeset patch # User Shaul Kremer shau...@gmail.com # Date 1270854557 -10800 # Node ID ac84f6db6f031db82509c247ac1775ca48b0e2f3 # Parent 7de0663facd92bbb9049aeeda3dcba9601228f30 Added DVB-T initial tuning tables for Israel. diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN1 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN1 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-1 transmitter (northern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN2 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN2 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-2 transmitter (central Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN3 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN3 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-3 transmitter (southern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE why you don't put them into one scan file for now? scan for sure does not know about any difference between northern and southern Israel from the above and to scan the central transponder too in one run might cost in worst case a few seconds. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software decoder, the IR IRQ might be used to wake, but this means that everything, even a glitch, would wake the hardware, so this won't work neither. On my embedded hardware there is 100KB of static RAM on the CPU die. It is preserved even in deep sleep. An IR pulse can wake the CPU and run code in this 100KB RAM. Then the CPU can decide whether it wants to power on main RAM and restore the OS. But implementing this is outside the scope of the Linux kernel. In someways this is how an MSMCE behaves in suspend. There is code running on the MCU inside the MSMCE receiver. Too bad we can't tell it a pattern to watch for and then trigger USB wake up. It is easy to build a MSMCE clone, maybe someone will clone it and add the wakeup pattern match. An enterprising hacker can probably change the firmware in the existing devices. -- Jon Smirl jonsm...@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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi! Am Freitag, den 09.04.2010, 20:32 -0300 schrieb Mauro Carvalho Chehab: Andy Walls wrote: On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote: On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. Really? Have you actually seen any hardware where a particular scan code can be used to wake up the hardware? The only hardware I have seen has the ability to unsuspend on arrival of IR traffic, but you didn't have the granularity to dictate that it only wake up on particular scancodes. The CX23888 and CX23102 can do it. Basically any IR pulse pattern your heart desires; within reason. And any carrier freq you want too; within reason. But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere near properly supporing suspend/resume for their main video and DMA functions, AFAIK. AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching TV, do a suspend and waking the hardware again, and you'll keep seeing the same channel (I tested it some time ago, when the proper suspend code were added, on analog mode, with alsa enabled). Other drivers can suspend/resume, but they won't properly restore the video registers, so, you'll see artifacts when it returns. Yes, that was Maxim with enough testers around and Matthias Schwarzott had fixes. To remind, we don't recover from suspend on DVB, needs to reload the driver once. We are also not MFE ready with mixed init calls through v4l and dvb. But yes, analog is on leading edge on that ;) Cheers, Hermann So, yes, you're right: before any suspend/resume code on those drivers, we first need to add some code to properly handle kernel threads and work queues during suspend, and to restore all the registers to a sane state at resume, before implementing IR wakeup on them. In the case of mceusb, as there is already an userspace code for it on lirc, it would probably not be that hard to make this feature to work with ir-core. [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software decoder, the IR IRQ might be used to wake, but this means that everything, even a glitch, would wake the hardware, so this won't work neither. -- 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] Teach drivers/media/IR/ir-raw-event.c to use durations
Andy Walls wrote: On Thu, 2010-04-08 at 18:10 +0200, David Härdeman wrote: With this patch: s64 int's are used to represent pulse/space durations in ns If performing divides on 64 bit numbers, please check to make sure your code compiles, links, and loads on a 32-bit system. We've had problems in the past in where gcc will build the module to reference __udivdi3 under 32-bit kernels; but that symbol is not in the kernel. Good catch! Search for 'do_div' in: linux/drivers/media/video/cx18/cx18-av-core.c for a simple example divide that works on both 64 and 32 bit machines. Unfortunately, not all gcc versions complain about the lack of the __udivi32 library. Some (like the one I run on my desktop), will add some inlined assembler code for it, instead of requiring some library to do the division. We'll likely only discover such bugs only after sending the code to linux-next (done later yesterday - but I suspect that it were pulled only today from my tree) and receiving a complain for the ones that run those robots that test hundreds of different CONFIG_foo options. So, I suspect that we'll have some of such complaints by tomorrow... -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software decoder, the IR IRQ might be used to wake, but this means that everything, even a glitch, would wake the hardware, so this won't work neither. On my embedded hardware there is 100KB of static RAM on the CPU die. It is preserved even in deep sleep. An IR pulse can wake the CPU and run code in this 100KB RAM. Then the CPU can decide whether it wants to power on main RAM and restore the OS. But implementing this is outside the scope of the Linux kernel. In someways this is how an MSMCE behaves in suspend. There is code running on the MCU inside the MSMCE receiver. Too bad we can't tell it a pattern to watch for and then trigger USB wake up. It is easy to build a MSMCE clone, maybe someone will clone it and add the wakeup pattern match. An enterprising hacker can probably change the firmware in the existing devices. Waking up the entire hardware just because an IRQ was triggered doesn't seem a good idea on PC's. Here, I had to put the IR sensors behind the table to avoid receiving too many noise from my room's lamp. If I put it on the right place, I start receiving several of glitches per second. I doubt this would be useful for suspend/resume operations. -- 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 4/4] Add RC6 support to ir-core
On Fri, 2010-04-09 at 01:04 +0200, David Härdeman wrote: This patch adds an RC6 decoder (modes 0 and 6A) to ir-core. Signed-off-by: David Härdeman da...@hardeman.nu David, Overall, a nice job of implementing RC6 decoder logic. I have a few comments below (along with some of me reasoning to myself out loud). --- drivers/media/IR/Kconfig |9 + drivers/media/IR/Makefile |1 drivers/media/IR/ir-core-priv.h |7 + drivers/media/IR/ir-raw-event.c |1 drivers/media/IR/ir-rc6-decoder.c | 412 + drivers/media/IR/ir-sysfs.c |2 include/media/rc-map.h|1 7 files changed, 433 insertions(+), 0 deletions(-) create mode 100644 drivers/media/IR/ir-rc6-decoder.c diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index ba81bda..28d336d 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -27,3 +27,12 @@ config IR_RC5_DECODER ---help--- Enable this option if you have IR with RC-5 protocol, and if the IR is decoded in software + +config IR_RC6_DECODER + tristate Enable IR raw decoder for the RC6 protocol + depends on IR_CORE + default y + + ---help--- +Enable this option if you have an infrared remote control which +uses the RC6 protocol, and you need software decoding support. diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile index 62e12d5..792d9ca 100644 --- a/drivers/media/IR/Makefile +++ b/drivers/media/IR/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_IR_CORE) += ir-core.o obj-$(CONFIG_VIDEO_IR) += ir-common.o obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o +obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h index ab785bc..853ec80 100644 --- a/drivers/media/IR/ir-core-priv.h +++ b/drivers/media/IR/ir-core-priv.h @@ -109,4 +109,11 @@ void ir_raw_init(void); #define load_rc5_decode()0 #endif +/* from ir-rc6-decoder.c */ +#ifdef CONFIG_IR_RC5_DECODER_MODULE +#define load_rc6_decode()request_module(ir-rc6-decoder) +#else +#define load_rc6_decode()0 +#endif + #endif /* _IR_RAW_EVENT */ diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c index 2efc051..ef0f231 100644 --- a/drivers/media/IR/ir-raw-event.c +++ b/drivers/media/IR/ir-raw-event.c @@ -224,6 +224,7 @@ static void init_decoders(struct work_struct *work) load_nec_decode(); load_rc5_decode(); + load_rc6_decode(); /* If needed, we may later add some init code. In this case, it is needed to change the CONFIG_MODULE test at ir-core.h diff --git a/drivers/media/IR/ir-rc6-decoder.c b/drivers/media/IR/ir-rc6-decoder.c new file mode 100644 index 000..ccc5be2 --- /dev/null +++ b/drivers/media/IR/ir-rc6-decoder.c @@ -0,0 +1,412 @@ +/* ir-rc6-decoder.c - A decoder for the RC6 IR protocol + * + * Copyright (C) 2010 by David Härdeman da...@hardeman.nu + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include ir-core-priv.h + +/* + * This decoder currently supports: + * RC6-0-16 (standard toggle bit in header) + * RC6-6A-24 (no toggle bit) + * RC6-6A-32 (MCE version with toggle bit in body) + */ Just for reference for review: http://slycontrol.ru/scr/kb/rc6.htm http://www.picbasic.nl/info_rc6_uk.htm RC6 Mode 0: prefix mark: 11 prefix space: 00 start bit:10 (biphase encoding of '1') mode bits:010101 (biphase encoding of '000') toggle bits: 0011 or 1100 (double duration biphase coding of '0' or '1') system byte: (biphase encoding of 8 bits) command byte: (biphase encoding of 8 bits) RC6 Mode 6A: prefix mark: 11 prefix space: 00 start bit: 10 (biphase encoding of '1') mode bits: 101001 (biphase encoding of '110' for '6') trailer bits: 0011 (double duration biphase encoding of '0' for 'A') customer len: 01 or 10 (biphase encoding of '0' for 7 bits or '1' for 15 bits) customer bits: xx (biphase encoding of 7 bits for a short customer code) or xx (biphase encoding of 15 bits for a long customer code) system byte: (biphase encoding of 8 bits) command byte: (biphase encoding of 8 bits) +#define RC6_UNIT 44 /* us */
OOPS: cx18
I recieved an oops today while loading the cx18 driver: [342153.973342] cx18: Start initialization, version 1.4.0 [342153.974007] cx18-0: Initializing card 0 [342153.974012] cx18-0: Autodetected Hauppauge card [342153.974451] cx18 :07:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [342153.976826] cx18-0: cx23418 revision 0101 (B) [342154.197416] tveeprom 0-0050: Hauppauge model 74041, rev C6B2, serial# 7037045 [342154.197420] tveeprom 0-0050: MAC address is 00:0d:fe:6b:60:75 [342154.197424] tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) [342154.197427] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) [342154.197430] tveeprom 0-0050: audio processor is CX23418 (idx 38) [342154.197433] tveeprom 0-0050: decoder processor is CX23418 (idx 31) [342154.197435] tveeprom 0-0050: has no radio, has IR receiver, has IR transmitter [342154.197439] cx18-0: Autodetected Hauppauge HVR-1600 [342154.197441] cx18-0: Simultaneous Digital and Analog TV capture supported [342154.280378] IRQ 17/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs [342154.292388] tuner 1-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) [342154.305399] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [342154.371726] tuner-simple 1-0061: creating new instance [342154.371731] tuner-simple 1-0061: type set to 50 (TCL 2002N) [342154.380824] cx18-0: Couldn't allocate buffers for encoder YUV stream [342154.381088] BUG: unable to handle kernel NULL pointer dereference at 0008 [342154.381092] IP: [a0763ba0] cx18_queue_flush+0x60/0xf0 [cx18] [342154.381106] PGD 0 [342154.381109] Oops: [#1] SMP [342154.381112] last sysfs file: /sys/devices/pci:00/:00:1f.2/host2/target2:0:0/2:0:0:0/block/sdc/sdc1/stat [342154.381116] CPU 0 [342154.381118] Modules linked in: tuner_simple tuner_types cs5345 tuner cx18(+) dvb_core cbc cryptd aes_x86_64 aes_generic ecb usblp nls_iso8859_1 nls_cp437 vfat fat usb_storage binfmt_misc vboxdrv kvm_intel kvm vmnet ppdev parport_pc vmblock vsock vmci vmmon cx8800 cx88xx ivtv cx2341x bttv v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 ir_common i2c_algo_bit videobuf_dma_sg videobuf_core btcx_risc tveeprom ir_core lirc_i2c lirc_dev snd_hda_codec_atihdmi snd_hda_codec_realtek snd_seq_dummy snd_hda_intel snd_seq_oss snd_hda_codec snd_seq_midi snd_hwdep snd_rawmidi snd_pcm_oss snd_seq_midi_event snd_mixer_oss snd_pcm snd_seq iptable_filter snd_timer snd_seq_device lp ip_tables snd x_tables parport soundcore snd_page_alloc asus_atk0110 fglrx(P) dm_raid45 xor ohci1394 usbhid ieee1394 r8169 mii [342154.381180] Pid: 31669, comm: work_for_cpu Tainted: P 2.6.31-19-generic #56-Ubuntu System Product Name [342154.381183] RIP: 0010:[a0763ba0] [a0763ba0] cx18_queue_flush+0x60/0xf0 [cx18] [342154.381192] RSP: 0018:880193dcdc70 EFLAGS: 00010282 [342154.381195] RAX: RBX: 880144e52220 RCX: 8800273c2800 [342154.381197] RDX: 880144e52208 RSI: 880144e52218 RDI: 880144e52220 [342154.381200] RBP: 880193dcdc90 R08: R09: [342154.381202] R10: 0390 R11: 0001 R12: 880144e521e0 [342154.381205] R13: 880144e521c8 R14: 880144e52208 R15: [342154.381208] FS: () GS:880028034000() knlGS: [342154.381211] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [342154.381213] CR2: 0008 CR3: 01001000 CR4: 26f0 [342154.381216] DR0: DR1: DR2: [342154.381219] DR3: DR6: 0ff0 DR7: 0400 [342154.381222] Process work_for_cpu (pid: 31669, threadinfo 880193dcc000, task 8800024edac0) [342154.381224] Stack: [342154.381225] 880144e52220 880144e52138 880144e52208 003f [342154.381229] 0 880193dcdcc0 a0763cae 8801965ff5c0 880144e52138 [342154.381234] 0 880144e52208 0006 880193dcdcf0 a0763e20 [342154.381239] Call Trace: [342154.381248] [a0763cae] cx18_unload_queues+0x2e/0xf0 [cx18] [342154.381256] [a0763e20] cx18_stream_free+0x30/0x120 [cx18] [342154.381265] [a0765747] cx18_streams_cleanup+0xe7/0x120 [cx18] [342154.381273] [a0765d62] cx18_streams_setup+0x332/0x3c0 [cx18] [342154.381282] [a07734c5] cx18_probe+0x134f/0x148a [cx18] [342154.381289] [8101062b] ? __switch_to+0xcb/0x370 [342154.381294] [8104f025] ? finish_task_switch+0x65/0x120 [342154.381301] [81073e50] ? do_work_for_cpu+0x0/0x30 [342154.381306] [8128e462] local_pci_probe+0x12/0x20 [342154.381310] [81073e63] do_work_for_cpu+0x13/0x30 [342154.381314] [810785d6] kthread+0xa6/0xb0 [342154.381317] [810130ea] child_rip+0xa/0x20 [342154.381321] [81078530] ? kthread+0x0/0xb0 [342154.381324]
