Re: [PATCH 1/2 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
On Mon, 30 Nov 2009, Hans Verkuil wrote: On Thu, 26 Nov 2009, Guennadi Liakhovetski wrote: From 8b24c617e1ac4d324538a3eec476d48b85c2091f Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski g.liakhovet...@gmx.de Date: Thu, 26 Nov 2009 18:20:45 +0100 Subject: [PATCH] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats Video subdevices, like cameras, decoders, connect to video bridges over specialised busses. Data is being transferred over these busses in various formats, which only loosely correspond to fourcc codes, describing how video data is stored in RAM. This is not a one-to-one correspondence, therefore we cannot use fourcc codes to configure subdevice output data formats. This patch adds codes for several such on-the-bus formats and an API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those codes. After all users of the old API in struct v4l2_subdev_video_ops are converted, it will be removed. Also add helper routines to support generic pass-through mode for the soc-camera framework. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v2 - v3: more comments: 1. moved enum v4l2_mbus_packing, enum v4l2_mbus_order, and struct v4l2_mbus_pixelfmt to soc-camera specific header, renamed them into soc-namespace. 2. commented enum v4l2_mbus_pixelcode and removed unused values. v1 - v2: addressed comments from Hans, namely: 1. renamed image bus to media bus, now using mbus as a shorthand in function and data type names. 2. made media-bus helper functions soc-camera local. 3. moved colorspace from struct v4l2_mbus_pixelfmt to struct v4l2_mbus_framefmt. 4. added documentation for data types and enums. 5. added V4L2_MBUS_FMT_FIXED = 1, format as the first in enum. soc-camera driver port will follow tomorrow. Thanks Guennadi drivers/media/video/Makefile |2 +- drivers/media/video/soc_mediabus.c | 157 include/media/soc_mediabus.h | 84 +++ include/media/v4l2-mediabus.h | 59 ++ include/media/v4l2-subdev.h| 19 - cut diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h new file mode 100644 index 000..359840c --- /dev/null +++ b/include/media/v4l2-mediabus.h @@ -0,0 +1,59 @@ +/* + * Media Bus API header + * + * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef V4L2_MEDIABUS_H +#define V4L2_MEDIABUS_H + +/* + * These pixel codes uniquely identify data formats on the media bus. Mostly + * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is + * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the + * data format is fixed. Additionally, 2X8 means that one pixel is transferred + * in two 8-bit samples, BE or LE specify in which order those samples + * should be stored in RAM, and PADHI and PADLO define which bits - low or + * high, in the incomplete high byte, are filled with padding bits. + */ Hi Guennadi, This still needs some improvement. There are two things that need to be changed here: 1) add the width of the data bus to the format name: so V4L2_MBUS_FMT_YUYV becomes _FMT_YUYV_8. This is required since I know several video receivers that can be programmed to use one of several data widths (8, 10, 12 bits per color component). Perhaps _1X8 is even better since that is nicely consistent with the 2X8 suffix that you already use. The PADHI and PADLO naming convention is fine and should be used whereever it is neeeded. Ditto for BE and LE. Ok, my first thought was no, there only very seldom will be a need for a different padding / order / bus-width, but the second thought was but if there ever will be one, you'll have to rename the original code too... 2) Rephrase 'BE or LE specify in which order those samples should be stored in RAM' to: 'BE or LE specify in which order those samples are transferred over the bus: BE means that the most significant bits are transferred first, LE means that the least significant bits are transferred first.' This also means that formats like RGB555 need to be renamed to RGB555_2X8_PADHI_LE. I think that this would make this list of pixelcodes unambiguous and understandable. Right, how about this: /* * These pixel codes uniquely identify data formats on the media bus. Mostly * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the * data format is fixed. Additionally, 2X8 means
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Alan, Alan Cox wrote: Does it really make sense to put big chunks of protocol decoding crap for an interface which runs at about 1 character per second on a good day into the kernel ? Does it really make sense ot move 50K of code from user context to kernel context where it must meet strict security requirements, be extensively audited and cannot be paged. For embedded users will also have to be highly modular so no unused bits are loaded. The same logic would apply to mouse, keyboards and serial consoles. It is possible to move everything to userspace. However, there are some reassons for they to be in kernelspace: - you may need them during boot time; - they are mandatory to allow the users interaction; - you need low latency. The same arguments apply to IR, especially on embedded devices: some devices, like TVs, Set Top TV boxes and IPTV Set Top Boxes have IR as their primary input device. Also, as changing a digital TV or an IP TV channel requires to discard the current MPEG stream and getting a newer one, and it requires a large time until you'll be able to output something to the user, one of the needs is to handle IR keystrokes (especially channel up/down) as fast as possible, to try to minimize the discomfort of changing a channel. Using an approach where you'll send a raw event to userspace, process there and return back to kernel will increase the latency and can only be done after when loading the SYSV runlevel stuff. On the other hand, we already have IR decoding in-kernel. Most of the code are at: drivers/media/common/ir-functions.c But there are also some other decoders at bttv, saa7134 and cx88 drivers. In the case of drivers/media stuff, there common case is that the drivers have support for both space/pulse decoding and in-hardware decoding. On both cases, the scancode is converted to a keystroke via evdev. IMHO, we shouldn't really consider dropping those decoders from kernel. 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?
Andy Walls wrote: On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote: On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com wrote: This has zero advantages besides good developer feeling that My system has one less daemon... Surely it's clear that having an unnecessary daemon is introducing another point of failure? A failure in a userspace IR daemon is worst case loss of IR functionality. A failure in kernel space can oops or panic the machine. If IR is the only interface between the user and the system (like in a TV or a Set Top Box), both will give you the same practical result: the system will be broken, if you got a crash at the IR driver. Userspace is much more flexible. Why? The flexibility about the same on both kernelspace and userspace, except for the boot time. A kernelspace input device driver can start working since boot time. On the other hand, an userspace device driver will be available only after mounting the filesystems and starting the deamons (e. g. after running inittab). So, you cannot catch a key that would be affecting the boot (for example to ask the kernel to run a different runlevel or entering on some administrative mode). After the boot, and providing that the kernel has the proper API's, a pure userspace driver can behave just like a kernelspace driver and vice-versa. The only difference may be in terms of device transfer rate (not relevant for input devices) and latency. 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?
Christoph Bartelmus wrote: Hi Mauro, I just don't want to change a working interface just because it could be also implemented in a different way, but having no other visible advantage than using more recent kernel features. I agree. The main reasons to review the interface is: 1) to avoid any overlaps (if are there any) with the evdev interface; 2) to have it stable enough to be used, without changes, for a long time. I haven't seen such limitations on his proposal. We currently have in-kernel decoders for NEC, pulse-distance, RC4 protocols, and some variants. If non-RC5 decoders are missing, we need for sure to add them. That was not my point. If you point a NEC remote at the Igor USB device, you won't be able to use a NEC decoder because the device will swallow half of the bits. LIRC won't care unless the resulting scancodes are identical. If the difference is just the bits order, and assuming that we use a standard NEC decoder, a (kernel) driver will simply provide a different scancode for that device, and the keymap table will be different, but it will still work (an can still be plug and play). In this specific case, we can opt to simply don't add any special hack for Igor USB at the driver, but to leting the userspace tool to invert the bits order when loading the keymap for that device. Providing that we agree on what we'll do, I don't see why not adding it on staging for 2.6.33 and targeting to have everything done for 2.6.34 or 2.6.35. The problem that I see here is just that even when we have very talented people working on this, that put together all resources, we won't be able to cover all the corner cases with all the different receivers and remote control protocols out there. It will still require lots of fine-tuning which was done in LIRC over the years. True, but even if we want to merge lirc drivers as-is, the drivers will still need changes, due to kernel CodingStyle, due to the usage of some API's that may be deprecated, due to some breakage with non-Intel architectures, due to some bugs that kernel hackers may discover, etc. Also, there will be the needs for integrating with V4L/DVB code that may also require some changes. So, the drivers will still be different than what you currently have and they may still need some fine-tuning after the merge. 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
[resend] radio-sf16fmi: add autoprobing
Add automatic probing of ports 0x284 and 0x384 to radio-sf16fmi if no card is
found using PnP.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-source-2.6.31/drivers/media/radio/Kconfig.1 2009-11-28
21:40:32.0 +0100
+++ linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28
21:32:58.0 +0100
@@ -199,10 +199,7 @@
tristate SF16-FMI/SF16-FMP Radio
depends on ISA VIDEO_V4L2
---help---
- Choose Y here if you have one of these FM radio cards. If you
- compile the driver into the kernel and your card is not PnP one, you
- have to add sf16fm=io to the kernel command line (I/O address is
- 0x284 or 0x384).
+ Choose Y here if you have one of these FM radio cards.
In order to control your radio card, you will need to use programs
that are compatible with the Video For Linux API. Information on
--- linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c.1 2009-11-28
21:27:22.0 +0100
+++ linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c 2009-11-28
22:15:57.0 +0100
@@ -54,6 +54,7 @@ struct fmi
static struct fmi fmi_card;
static struct pnp_dev *dev;
+bool pnp_attached;
/* freq is in 1/16 kHz to internal number, hw precision is 50 kHz */
/* It is only useful to give freq in interval of 800 (=0.05Mhz),
@@ -316,26 +317,54 @@ static int __init fmi_init(void)
{
struct fmi *fmi = fmi_card;
struct v4l2_device *v4l2_dev = fmi-v4l2_dev;
- int res;
+ int res, i;
+ int probe_ports[] = { 0, 0x284, 0x384 };
- if (io 0)
- io = isapnp_fmi_probe();
- strlcpy(v4l2_dev-name, sf16fmi, sizeof(v4l2_dev-name));
- fmi-io = io;
- if (fmi-io 0) {
- v4l2_err(v4l2_dev, No PnP card found.\n);
- return fmi-io;
+ if (io 0) {
+ for (i = 0; i ARRAY_SIZE(probe_ports); i++) {
+ io = probe_ports[i];
+ if (io == 0) {
+ io = isapnp_fmi_probe();
+ if (io 0)
+ continue;
+ pnp_attached = 1;
+ }
+ if (!request_region(io, 2, radio-sf16fmi)) {
+ if (pnp_attached)
+ pnp_device_detach(dev);
+ io = -1;
+ continue;
+ }
+ if (pnp_attached ||
+ ((inb(io) 0xf9) == 0xf9 (inb(io) 0x4) == 0))
+ break;
+ release_region(io, 2);
+ io = -1;
+ }
+ } else {
+ if (!request_region(io, 2, radio-sf16fmi)) {
+ printk(KERN_ERR radio-sf16fmi: port %#x already in
use\n, io);
+ return -EBUSY;
+ }
+ if (inb(io) == 0xff) {
+ printk(KERN_ERR radio-sf16fmi: card not present at
%#x\n, io);
+ release_region(io, 2);
+ return -ENODEV;
+ }
}
- if (!request_region(io, 2, radio-sf16fmi)) {
- v4l2_err(v4l2_dev, port 0x%x already in use\n, fmi-io);
- pnp_device_detach(dev);
- return -EBUSY;
+ if (io 0) {
+ printk(KERN_ERR radio-sf16fmi: no cards found\n);
+ return -ENODEV;
}
+ strlcpy(v4l2_dev-name, sf16fmi, sizeof(v4l2_dev-name));
+ fmi-io = io;
+
res = v4l2_device_register(NULL, v4l2_dev);
if (res 0) {
release_region(fmi-io, 2);
- pnp_device_detach(dev);
+ if (pnp_attached)
+ pnp_device_detach(dev);
v4l2_err(v4l2_dev, Could not register v4l2_device\n);
return res;
}
@@ -352,7 +381,8 @@ static int __init fmi_init(void)
if (video_register_device(fmi-vdev, VFL_TYPE_RADIO, radio_nr) 0) {
v4l2_device_unregister(v4l2_dev);
release_region(fmi-io, 2);
- pnp_device_detach(dev);
+ if (pnp_attached)
+ pnp_device_detach(dev);
return -EINVAL;
}
@@ -369,7 +399,7 @@ static void __exit fmi_exit(void)
video_unregister_device(fmi-vdev);
v4l2_device_unregister(fmi-v4l2_dev);
release_region(fmi-io, 2);
- if (dev)
+ if (dev pnp_attached)
pnp_device_detach(dev);
}
--
Ondrej Zary
--
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
[resend] radio-sf16fmi: fix mute, add SF16-FMP to texts
Fix completely broken mute handling radio-sf16fmi.
The sound was muted immediately after tuning in KRadio.
Also fix typos and add SF16-FMP to the texts.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
diff -urp linux-source-2.6.31-orig/drivers/media/radio/Kconfig
linux-source-2.6.31/drivers/media/radio/Kconfig
--- linux-source-2.6.31-orig/drivers/media/radio/Kconfig2009-09-10
00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28
11:51:42.0 +0100
@@ -196,7 +196,7 @@ config RADIO_MAESTRO
module will be called radio-maestro.
config RADIO_SF16FMI
- tristate SF16FMI Radio
+ tristate SF16-FMI/SF16-FMP Radio
depends on ISA VIDEO_V4L2
---help---
Choose Y here if you have one of these FM radio cards. If you
diff -urp linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c
--- linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
2009-09-10 00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c 2009-11-28
11:39:35.0 +0100
@@ -1,4 +1,4 @@
-/* SF16FMI radio driver for Linux radio support
+/* SF16-FMI and SF16-FMP radio driver for Linux radio support
* heavily based on rtrack driver...
* (c) 1997 M. Kirkwood
* (c) 1998 Petr Vandrovec, vandr...@vc.cvut.cz
@@ -11,7 +11,7 @@
*
* Frequency control is done digitally -- ie out(port,encodefreq(95.8));
* No volume control - only mute/unmute - you have to use line volume
- * control on SB-part of SF16FMI
+ * control on SB-part of SF16-FMI/SF16-FMP
*
* Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org
*/
@@ -30,14 +30,14 @@
#include media/v4l2-ioctl.h
MODULE_AUTHOR(Petr Vandrovec, vandr...@vc.cvut.cz and M. Kirkwood);
-MODULE_DESCRIPTION(A driver for the SF16MI radio.);
+MODULE_DESCRIPTION(A driver for the SF16-FMI and SF16-FMP radio.);
MODULE_LICENSE(GPL);
static int io = -1;
static int radio_nr = -1;
module_param(io, int, 0);
-MODULE_PARM_DESC(io, I/O address of the SF16MI card (0x284 or 0x384));
+MODULE_PARM_DESC(io, I/O address of the SF16-FMI or SF16-FMP card (0x284 or
0x384));
module_param(radio_nr, int, 0);
#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
@@ -47,7 +47,7 @@ struct fmi
struct v4l2_device v4l2_dev;
struct video_device vdev;
int io;
- int curvol; /* 1 or 0 */
+ bool mute;
unsigned long curfreq; /* freq in kHz */
struct mutex lock;
};
@@ -105,7 +105,7 @@ static inline int fmi_setfreq(struct fmi
outbits(8, 0xC0, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
mutex_unlock(fmi-lock);
- if (fmi-curvol)
+ if (!fmi-mute)
fmi_unmute(fmi);
return 0;
}
@@ -116,7 +116,7 @@ static inline int fmi_getsigstr(struct f
int res;
mutex_lock(fmi-lock);
- val = fmi-curvol ? 0x08 : 0x00;/* unmute/mute */
+ val = fmi-mute ? 0x00 : 0x08; /* mute/unmute */
outb(val, fmi-io);
outb(val | 0x10, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
@@ -204,7 +204,7 @@ static int vidioc_g_ctrl(struct file *fi
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value = fmi-curvol;
+ ctrl-value = fmi-mute;
return 0;
}
return -EINVAL;
@@ -221,7 +221,7 @@ static int vidioc_s_ctrl(struct file *fi
fmi_mute(fmi);
else
fmi_unmute(fmi);
- fmi-curvol = ctrl-value;
+ fmi-mute = ctrl-value;
return 0;
}
return -EINVAL;
--
Ondrej Zary
--
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 Mon, Nov 30, 2009 at 7:57 AM, Andy Walls awa...@radix.net wrote: I suppose my best answer to that is question back to you: Why does udev run in userspace versus a kernel thread? Because udev is a scripting system. I've always said that the scripting piece of IR belongs in user space. IR scripting should be optional, none of the systems I work on need it. This is the event flow being built... device timing data -- send timing data to user space -- do protocol decode (40K code) -- send decoded data back to kernel other devices that decode in HW add events here -- send decoded data to user space -- map to keys (30K code) -- send keys back to kernel apps listen for keys -- send keys back to user space -- user space apps act on key (possibly run scripts) I'd like to see... device timing data -- user space can inject timing data from user space drivers do protocol decode (40K code) other devices that decode in HW add events here -- user space can inject decoded data from user space drivers map to keys (30K code) apps listen for keys -- send keys back to user space -- user space apps act on key (possibly run scripts) My personal thoughts on why user space is more flexible: 1. You have all of *NIX available to you to use as tools to achieve your requirements. 2. You are not constrained to use C. 3. You can link in libraries with functions that are not available in the kernel. (udev has libudev IIRC to handle complexities) 4. Reading a configuration file or other file from the filesystem is trivial - file access from usespace is easy. 5. You don't have to be concerned about the running context (am I allowed to sleep here or not?). A kernelspace input device driver can start working since boot time. On the other hand, an userspace device driver will be available only after mounting the filesystems and starting the deamons (e. g. after running inittab). So, you cannot catch a key that would be affecting the boot (for example to ask the kernel to run a different runlevel or entering on some administrative mode). Right. That's another requirement that makes sense, if we're talking about systems that don't have any other keyboard handy to the user. So are we optimizing for the embedded/STB and HTPC with no keyboard use case, or the desktop or HTPC with a keyboard for maintencance? Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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?
On Mon, 2009-11-30 at 07:57 -0500, Andy Walls wrote: On Mon, 2009-11-30 at 09:56 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote: On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com wrote: This has zero advantages besides good developer feeling that My system has one less daemon... Surely it's clear that having an unnecessary daemon is introducing another point of failure? A failure in a userspace IR daemon is worst case loss of IR functionality. A failure in kernel space can oops or panic the machine. If IR is the only interface between the user and the system (like in a TV or a Set Top Box), both will give you the same practical result: the system will be broken, if you got a crash at the IR driver. Yes, true. I had forgotten about the embedded space. Nonetheless I'd still rather debug a problem with a dead process in userspace than an oops or panic (not that an end user cares) and avoid the risk of filesystem corruption. Userspace is much more flexible. Why? The flexibility about the same on both kernelspace and userspace, except for the boot time. I suppose my best answer to that is question back to you: Why does udev run in userspace versus a kernel thread? My personal thoughts on why user space is more flexible: 1. You have all of *NIX available to you to use as tools to achieve your requirements. 2. You are not constrained to use C. 3. You can link in libraries with functions that are not available in the kernel. (udev has libudev IIRC to handle complexities) 4. Reading a configuration file or other file from the filesystem is trivial - file access from usespace is easy. 5. You don't have to be concerned about the running context (am I allowed to sleep here or not?). 6. You can modify userspace driver easily to cope with all weird setups. Like you know that there are remotes that send whole packet of data that consist of many numbers that are also displayed on the LCD of the remote. Otherwise you will have to go through same fight for every minor thing you like to add to kernel... 7. You don't have an ABI constraints, your userspace program can read a configuration file in any format you wish. I for example was thinking about putting all lirc config files into an sqllite database, and pulling them out when specific remote is detected. A kernelspace input device driver can start working since boot time. On the other hand, an userspace device driver will be available only after mounting the filesystems and starting the deamons (e. g. after running inittab). So, you cannot catch a key that would be affecting the boot (for example to ask the kernel to run a different runlevel or entering on some administrative mode). Right. That's another requirement that makes sense, if we're talking about systems that don't have any other keyboard handy to the user. So are we optimizing for the embedded/STB and HTPC with no keyboard use case, or the desktop or HTPC with a keyboard for maintencance? 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 2.6.32] V4L/DVB updates
Em Sat, 28 Nov 2009 14:33:30 -0600 (CST) Mike Isely is...@isely.net escreveu: On Sat, 28 Nov 2009, Hans Verkuil wrote: On Friday 27 November 2009 22:40:01 Stefan Lippers-Hollmann wrote: Hi On Friday 27 November 2009, Mauro Carvalho Chehab wrote: Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the following drivers and building fixes: - radio-gemtek-pci: fix double mutex_lock - v4l: add more missing linux/sched.h includes - soc-camera: properly initialise the device object when reusing - soc-camera: sh_mobile_ceu_camera: call pm_runtime_disable - em28xx: fix Reddo DVB-C USB TV Box GPIO - davinci: remove stray duplicate config pointer - SMS_SIANO_MDTV should depend on HAS_DMA - cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) - sh_mobile_ceu_camera: fix compile warning - Fix wrong parameter order in memset [...] Please consider cherry picking the following two patches from Hans Verkuil [1]: - add the missing s2250-loader.h - s2250 mutex patch Good catch. Mauro, can you please add these two as well for 2.6.32? I'm sure I marked these two as high-prio patches. This staging driver is actively being used and developed so this regression should be fixed. Mauro: I had also posted up two high priority pvrusb2 patches that should really be cherry-picked for 2.6.32. You've already pulled them into v4l/dvb and I did mark them as high priority at the time. These patches enable use of FX2 microcontroller firmware that is 16KB in size. Hauppauge is no longer shipping 8KB firmware for HVR-1950 and HVR-1900 and without these changes then those devices won't work AT ALL in kernel 2.6.32. You can find these within the v4l-dvb Mercurial repository here: Changeset 13495:87c3853fe2b3 Subject: pvrusb2: Support 16KB FX2 firmware http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3 Changeset 13500:d4c418d4b25c Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c I do not believe these patches have any ordering dependencies with other patches, though between the two the second one technically should come after the first. There are. Picking just those patches broke compilation. Also, it seemed too late for adding support for newer boards/firmware when Linus is about to release a kernel. 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 Mon, Nov 30, 2009 at 8:43 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Mon, 2009-11-30 at 07:57 -0500, Andy Walls wrote: On Mon, 2009-11-30 at 09:56 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote: On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com wrote: This has zero advantages besides good developer feeling that My system has one less daemon... Surely it's clear that having an unnecessary daemon is introducing another point of failure? A failure in a userspace IR daemon is worst case loss of IR functionality. A failure in kernel space can oops or panic the machine. If IR is the only interface between the user and the system (like in a TV or a Set Top Box), both will give you the same practical result: the system will be broken, if you got a crash at the IR driver. Yes, true. I had forgotten about the embedded space. Nonetheless I'd still rather debug a problem with a dead process in userspace than an oops or panic (not that an end user cares) and avoid the risk of filesystem corruption. Userspace is much more flexible. Why? The flexibility about the same on both kernelspace and userspace, except for the boot time. I suppose my best answer to that is question back to you: Why does udev run in userspace versus a kernel thread? My personal thoughts on why user space is more flexible: 1. You have all of *NIX available to you to use as tools to achieve your requirements. 2. You are not constrained to use C. 3. You can link in libraries with functions that are not available in the kernel. (udev has libudev IIRC to handle complexities) 4. Reading a configuration file or other file from the filesystem is trivial - file access from usespace is easy. 5. You don't have to be concerned about the running context (am I allowed to sleep here or not?). 6. You can modify userspace driver easily to cope with all weird setups. Like you know that there are remotes that send whole packet of data that consist of many numbers that are also displayed on the LCD of the remote. Otherwise you will have to go through same fight for every minor thing you like to add to kernel... 7. You don't have an ABI constraints, your userspace program can read a configuration file in any format you wish. I for example was thinking about putting all lirc config files into an sqllite database, and pulling them out when specific remote is detected. Linux is not a microkernel it is a monolithic kernel. http://en.wikipedia.org/wiki/Microkernel If you want to push all of the device drivers to user space go run a microkernel. Even the X server has finally come around to getting rid of their cross platform OS in user space model and begun the switch to kernel drivers. That transition is going to take ten years to complete. Once things get into the kernel they become far harder to change. Stop for a minute and think about designing the best IR system for Linux and forget about making a cross platform solution. IR is an input device, it should be integrated into the Linux input subsystem. You may not like the designs I have proposed, but running IR in user space and injecting a keystroke at the end of the process is not integrating it into the input subsystem. A kernelspace input device driver can start working since boot time. On the other hand, an userspace device driver will be available only after mounting the filesystems and starting the deamons (e. g. after running inittab). So, you cannot catch a key that would be affecting the boot (for example to ask the kernel to run a different runlevel or entering on some administrative mode). Right. That's another requirement that makes sense, if we're talking about systems that don't have any other keyboard handy to the user. So are we optimizing for the embedded/STB and HTPC with no keyboard use case, or the desktop or HTPC with a keyboard for maintencance? 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 -- 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: [GIT PULL for 2.6.32] V4L/DVB updates
Em Sat, 28 Nov 2009 03:57:58 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Friday 27 November 2009 22:40:01 Stefan Lippers-Hollmann wrote: Hi On Friday 27 November 2009, Mauro Carvalho Chehab wrote: Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the following drivers and building fixes: - radio-gemtek-pci: fix double mutex_lock - v4l: add more missing linux/sched.h includes - soc-camera: properly initialise the device object when reusing - soc-camera: sh_mobile_ceu_camera: call pm_runtime_disable - em28xx: fix Reddo DVB-C USB TV Box GPIO - davinci: remove stray duplicate config pointer - SMS_SIANO_MDTV should depend on HAS_DMA - cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) - sh_mobile_ceu_camera: fix compile warning - Fix wrong parameter order in memset [...] Please consider cherry picking the following two patches from Hans Verkuil [1]: - add the missing s2250-loader.h - s2250 mutex patch Good catch. Mauro, can you please add these two as well for 2.6.32? I'm sure I marked these two as high-prio patches. This staging driver is actively being used and developed so this regression should be fixed. There were a merge problem when applying those patches at -git. As this is a staging driver, I opted to just move all patches to linux-next, as there were no mention on the patch subject mentioned that they are, in fact, fixes. I'll see what can we do to solve the s2250 compilation breakage. As Linus didn't merge from this pull request yet, I'll work on a fix, based on one of the Stefan suggestions, preferably backporting the patches. -- 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] gspca sunplus: propagate error for higher level
2009/11/30 Jean-Francois Moine moin...@free.fr: On Sun, 29 Nov 2009 13:15:37 +0100 Németh Márton nm...@freemail.hu wrote: I think that the return value of the usb_control_msg() is to be evaluated. If other drivers also not evaluating the usb_control_msg() *they* has to be fixed. The benefit would be that the userspace program can recognise error condition faster and react accordingly. For example the USB device can be unplugged any time. In this case there is no use to continue sending URBs. Otherwise the user program thinks that everything went on correctly and the user will be surprised how come that he or she unplugged a device and it is still working. I see 2 cases for getting errors in usb control messages: - there are permanent problems in the USB subsystem - device disconnection The first case is detected immediately at probe time and the device will not run (/dev/videon not created) On device disconnection, if streaming is active, it is be stopped and the device is marked for deletion. The only way to get errors in usb control message is to change some control value at the same time the device disconnects (i.e. disconnection while the ioctl runs in the subdriver). The probability for this to occur is surely less than 10**-9. Otherwise, once the disconnection is seen, no IO may be performed. If you want absolutely to propagate the errors at higher level, the simplest way is to have an 'error' variable in the gspca descriptor. You set it to 0 in gspca.c before calling the subdriver (i.e. just after getting the usb_lock), you check it before calling usb_control_msg (in the low level routines reg_r, reg_w..) , you set it if this last function returns an error, and you get its value before releasing the usb_lock. In this way, there are less changes and less code overhead. an example from one of my customers, there's one customer who uses a USB VOIP device, the device is actually bad designed and regulary hangs up and sometimes even resets the entire usb stack. That customer was previously using the em28xx kernel driver (which for some reason actually locked up the entire USB device/if it didn't cause some other corruptions...) Every check can just be appreciated, for sure alot usb kernel drivers do not handle errors properly at critical codeparts. Trent Piepho once suggested a macro for writing blocks of registers, this looked just fine actually. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4 v11] Support for TVP7002 in DM365
This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application and video output in 480P, 576P, 720P and 1080I. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri. Removed shadow register values. Removed unnecesary power down and up of the device (tests work fine). Improved readability. -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.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 1/4 v11] Support for TVP7002 in v4l2 definitions
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides required chip identification definitions
within v4l2. Included only definitions for TVP7002.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
include/media/v4l2-chip-ident.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index cf16689..7e80c4f 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -129,6 +129,9 @@ enum {
V4L2_IDENT_SAA6752HS = 6752,
V4L2_IDENT_SAA6752HS_AC3 = 6753,
+ /* module tvp7002: just ident 7002 */
+ V4L2_IDENT_TVP7002 = 7002,
+
/* module adv7170: just ident 7170 */
V4L2_IDENT_ADV7170 = 7170,
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4 v11] Definitions for TVP7002 in DM365
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides the required definitions for the TVP7002 driver in DM365. Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com --- drivers/media/video/tvp7002_reg.h | 150 + include/media/tvp7002.h | 57 ++ 2 files changed, 207 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/tvp7002_reg.h create mode 100644 include/media/tvp7002.h diff --git a/drivers/media/video/tvp7002_reg.h b/drivers/media/video/tvp7002_reg.h new file mode 100644 index 000..0e34ca9 --- /dev/null +++ b/drivers/media/video/tvp7002_reg.h @@ -0,0 +1,150 @@ +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics + * Digitizer with Horizontal PLL registers + * + * Copyright (C) 2009 Texas Instruments Inc + * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com + * + * This code is partially based upon the TVP5150 driver + * written by Mauro Carvalho Chehab (mche...@infradead.org), + * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com + * and the TVP7002 driver in the TI LSP 2.10.00.14 + * + * 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; either version 2 of the License, or + * (at your option) any later version. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* Naming conventions + * -- + * + * FDBK: Feedback + * DIV: Divider + * CTL: Control + * SEL: Select + * IN:Input + * OUT: Output + * R: Red + * G: Green + * B: Blue + * OFF: Offset + * THRS: Threshold + * DGTL: Digital + * LVL: Level + * PWR: Power + * MVIS: Macrovision + * W: Width + * H: Height + * ALGN: Alignment + * CLK: Clocks + * TOL: Tolerance + * BWTH: Bandwidth + * COEF: Coefficient + * STAT: Status + * AUTO: Automatic + * FLD: Field + * L:Line + */ + +#define TVP7002_CHIP_REV 0x00 +#define TVP7002_HPLL_FDBK_DIV_MSBS 0x01 +#define TVP7002_HPLL_FDBK_DIV_LSBS 0x02 +#define TVP7002_HPLL_CRTL 0x03 +#define TVP7002_HPLL_PHASE_SEL 0x04 +#define TVP7002_CLAMP_START0x05 +#define TVP7002_CLAMP_W0x06 +#define TVP7002_HSYNC_OUT_W0x07 +#define TVP7002_B_FINE_GAIN0x08 +#define TVP7002_G_FINE_GAIN0x09 +#define TVP7002_R_FINE_GAIN0x0a +#define TVP7002_B_FINE_OFF_MSBS0x0b +#define TVP7002_G_FINE_OFF_MSBS 0x0c +#define TVP7002_R_FINE_OFF_MSBS 0x0d +#define TVP7002_SYNC_CTL_1 0x0e +#define TVP7002_HPLL_AND_CLAMP_CTL 0x0f +#define TVP7002_SYNC_ON_G_THRS 0x10 +#define TVP7002_SYNC_SEPARATOR_THRS0x11 +#define TVP7002_HPLL_PRE_COAST 0x12 +#define TVP7002_HPLL_POST_COAST0x13 +#define TVP7002_SYNC_DETECT_STAT 0x14 +#define TVP7002_OUT_FORMATTER 0x15 +#define TVP7002_MISC_CTL_1 0x16 +#define TVP7002_MISC_CTL_2 0x17 +#define TVP7002_MISC_CTL_3 0x18 +#define TVP7002_IN_MUX_SEL_1 0x19 +#define TVP7002_IN_MUX_SEL_20x1a +#define TVP7002_B_AND_G_COARSE_GAIN0x1b +#define TVP7002_R_COARSE_GAIN 0x1c +#define TVP7002_FINE_OFF_LSBS 0x1d +#define TVP7002_B_COARSE_OFF 0x1e +#define TVP7002_G_COARSE_OFF0x1f +#define TVP7002_R_COARSE_OFF0x20 +#define TVP7002_HSOUT_OUT_START0x21 +#define TVP7002_MISC_CTL_4 0x22 +#define TVP7002_B_DGTL_ALC_OUT_LSBS0x23 +#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24 +#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25 +#define TVP7002_AUTO_LVL_CTL_ENABLE0x26 +#define TVP7002_DGTL_ALC_OUT_MSBS 0x27 +#define TVP7002_AUTO_LVL_CTL_FILTER0x28 +/* Reserved 0x29*/ +#define TVP7002_FINE_CLAMP_CTL 0x2a +#define TVP7002_PWR_CTL0x2b +#define TVP7002_ADC_SETUP 0x2c +#define TVP7002_COARSE_CLAMP_CTL 0x2d +#define TVP7002_SOG_CLAMP 0x2e +#define TVP7002_RGB_COARSE_CLAMP_CTL 0x2f +#define TVP7002_SOG_COARSE_CLAMP_CTL 0x30 +#define TVP7002_ALC_PLACEMENT 0x31 +/* Reserved 0x32 */ +/* Reserved 0x33 */ +#define TVP7002_MVIS_STRIPPER_W0x34 +#define TVP7002_VSYNC_ALGN 0x35 +#define TVP7002_SYNC_BYPASS0x36 +#define TVP7002_L_FRAME_STAT_LSBS 0x37 +#define TVP7002_L_FRAME_STAT_MSBS 0x38 +#define
[PATCH 3/4 v11] TVP7002 driver for DM365
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values. Testing shows that the device
needs not to be powered down and up for correct behaviour.
Improved readability.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
drivers/media/video/tvp7002.c | 1227 +
1 files changed, 1227 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/tvp7002.c
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..9ed7b89
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1227 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tvp7002.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include tvp7002_reg.h
+
+MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
+MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
+MODULE_LICENSE(GPL);
+
+/* Module Name */
+#define TVP7002_MODULE_NAMEtvp7002
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Read write definition for registers */
+#define TVP7002_READ 0
+#define TVP7002_WRITE 1
+#define TVP7002_RESERVED 2
+
+/* Interlaced vs progressive mask and shift */
+#define TVP7002_IP_SHIFT 5
+#define TVP7002_INPR_MASK (0x01 TVP7002_IP_SHIFT)
+
+/* Shift for CPL and LPF registers */
+#define TVP7002_CL_SHIFT 8
+#define TVP7002_CL_MASK0x0f
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-2));
+
+/* Structure for register values */
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+ u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+ { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+ { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+ { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+ { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+ { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+ { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+ { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+ { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+ { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+ { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
+ { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_2, 0x00, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_3, 0x01, TVP7002_WRITE },
+ { TVP7002_IN_MUX_SEL_1, 0x00, TVP7002_WRITE },
+ {
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: After the boot, a device can open the raw API, disabling any in-kernel decoding/handling and handle IR directly. Alternatively, an udev rule can load a different keymap based on some config written on a file. This idea of the in-kernel decoding being disabled when the raw API is opened worries me. What guarantees that the following scenario will not happen? User uses apps which retrieve the decoded IR messages from the kernel. User installs an app which decodes messages via the raw API (not lirc). User's other applications no longer receive IR messages. I know the assumption has been that only lirc will use the raw API, but this seems like a poor assumption for an API design to me. A related question, what is an application developer who wishes to decode the raw IR signal (for whatever reason) to do? Are they *required* to implement full decoding and feed all the messages back to the kernel so they don't break other applications? For clarity, I'm not arguing for a particular approach, I'm not fully able to follow the discussion on this issue, but this one issue bothered me. Thank you for your time, Kevin Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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: Nonetheless I'd still rather debug a problem with a dead process in userspace than an oops or panic (not that an end user cares) and avoid the risk of filesystem corruption. Considering my experience adding in-kernel support for IR's, I'd say that in general, a driver does some things: 1) it polls or waits IRQ's for an IR event. On raw IR devices, the read value means a mark or a space; 2) it counts the timings between each pulse, and pulse/space duration; 3) it runs a protocol decoding logic that, based on pulse/space duration, one scancode is produced; 4) it does a table lookup to convert the scancode into the corresponding keycode; 5) it generates an evdev event. Steps 2 and 3 happen only when the device doesn't have hardware decoding capabilities. For devices with hardware decoding, the polling/IRQ process already retrieves a scancode. Based on my experience, I can say that, from the above logic, the one where you're more likely to generate an OOPS is at the first one, where you need to do the proper memory barriers for example to avoid unregistering an IR while you're in the middle of an IRQ or pull handling. In the case of IRQ, you'll also need to take care to not sleep, since you're in interrupt mode. If you're outputing raw pulse/space to userspace (a lirc-like raw interface), you'll still need to do steps (1) and (2) in kernel, and doing a logic close to (5) to output an event to userspace. So, the basic difference is that you won't run the decoder (3) nor do a table lookup (4). The logic for (4) is trivial (a simple a table lookup). If you do a mistake there, the bug will likely arise at the development time. Also, if you're not able to write a proper code to get a value from a table, you shouldn't be trying to write a driver anyway. The logic for (3) is as simple as identifying the length of a pulse and the length of the spaces. Depending on the length, it will produce a zero or one. Pure integer math. The only risk of such logic is if you try to divide by zero. Except of that, this type of code shouldn't cause any OOPS or panic. Also, for (3) and (4), it is very easy to write it first on userspace (if you feel more comfortable on doing so) and, after doing enough testing, add the same code to kernelspace. 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 - v0 1/2] V4L - vpfe capture - make clocks configurable
Vaibhav,
Thanks for testing this. I will update the patch for your comments.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Tuesday, November 24, 2009 11:25 PM
To: Karicheri, Muralidharan; linux-media@vger.kernel.org;
hverk...@xs4all.nl; khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Subject: RE: [PATCH - v0 1/2] V4L - vpfe capture - make clocks configurable
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of Karicheri, Muralidharan
Sent: Wednesday, November 25, 2009 5:07 AM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Subject: [PATCH - v0 1/2] V4L - vpfe capture - make clocks
configurable
From: Muralidharan Karicheri m-kariche...@ti.com
On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture.
[Hiremath, Vaibhav] Adding one more platform here, AM3517, which uses 2
clocks, internal clock used by internal logic and pixel clock.
Some minor review comments below -
Please note that I have validated these changes already on AM3517EVM, so
adding -
Tested-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Thanks,
Vaibhav
So
this
patch makes it configurable on a per platform basis. This is
needed for supporting DM365 for which patches will be available
soon.
This is for review only. For merge to upstream, it will be
re-crated against the v4l-dbv tree.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 98
+--
include/media/davinci/vpfe_capture.h | 11 ++-
2 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index cad60e3..1ba9d07 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1743,61 +1743,87 @@ static struct vpfe_device
*vpfe_initialize(void)
return vpfe_dev;
}
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+int i;
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
+for (i = 0; i vpfe_cfg-num_clocks; i++) {
+clk_disable(vpfe_dev-clks[i]);
+clk_put(vpfe_dev-clks[i]);
+}
+kfree(vpfe_dev-clks);
+v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks
disabled\n);
}
+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
+int ret = -EFAULT, i;
[Hiremath, Vaibhav] No need of variable ret, since we are not making use
of it. We can directly return -EFAULT from out: label.
Thanks,
Vaibhav
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-return ret;
-}
+if (!vpfe_cfg-num_clocks)
+return 0;
-if (clk_enable(vpfe_cfg-vpssclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss master clock not enabled\n);
-goto out;
-}
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master clock enabled\n);
+vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
+ sizeof(struct clock *), GFP_KERNEL);
-vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
-if (NULL == vpfe_cfg-slaveclk) {
-v4l2_err(vpfe_dev-pdev-driver,
-No clock defined for vpss slave\n);
-goto out;
+if (NULL == vpfe_dev-clks) {
+v4l2_err(vpfe_dev-pdev-driver, Memory allocation
failed\n);
+return -ENOMEM;
}
-if (clk_enable(vpfe_cfg-slaveclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss slave clock not
Re: [GIT PULL for 2.6.32] V4L/DVB updates
Em Mon, 30 Nov 2009 12:03:32 -0200 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Sat, 28 Nov 2009 03:57:58 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Friday 27 November 2009 22:40:01 Stefan Lippers-Hollmann wrote: Hi On Friday 27 November 2009, Mauro Carvalho Chehab wrote: Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the following drivers and building fixes: - radio-gemtek-pci: fix double mutex_lock - v4l: add more missing linux/sched.h includes - soc-camera: properly initialise the device object when reusing - soc-camera: sh_mobile_ceu_camera: call pm_runtime_disable - em28xx: fix Reddo DVB-C USB TV Box GPIO - davinci: remove stray duplicate config pointer - SMS_SIANO_MDTV should depend on HAS_DMA - cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) - sh_mobile_ceu_camera: fix compile warning - Fix wrong parameter order in memset [...] Please consider cherry picking the following two patches from Hans Verkuil [1]: - add the missing s2250-loader.h I'm not finding the above patch. I remember I got one patch at the go7007 conversion series to V4L2 that were removing this patch that didn't exist upstream. I had to manually fix the patch to apply at my linux-next tree. The patches I actually merged from hans v4l-dvb-staging (after the tree rebase) were: changeset: 13455:0eb2e476ac2a parent: 13372:8bff7e6c44d4 user:Hans Verkuil hverk...@xs4all.nl date:Mon Nov 16 19:07:42 2009 +0100 summary: go7007: Add struct v4l2_device. changeset: 13456:f6f0c5647657 user:Hans Verkuil hverk...@xs4all.nl date:Mon Nov 16 19:13:51 2009 +0100 summary: s2250: Change module structure changeset: 13457:701aead61759 user:Hans Verkuil hverk...@xs4all.nl date:Mon Nov 16 19:15:07 2009 +0100 summary: s2250: subdev conversion changeset: 13458:2ca6a9dc112b user:Hans Verkuil hverk...@xs4all.nl date:Mon Nov 16 19:16:00 2009 +0100 summary: go7007: subdev conversion changeset: 13459:28dc36f9dfdc parent: 13454:0ba581813fde parent: 13458:2ca6a9dc112b user:Mauro Carvalho Chehab mche...@redhat.com date:Tue Nov 24 14:45:53 2009 -0200 summary: merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging Unfortunately, the original tree were already removed. I suspect that hans didn't merge that patch on the latest version of v4l-dvb-stating tree. - s2250 mutex patch This one were merged on my tree: http://linuxtv.org/hg/v4l-dvb/rev/8bff7e6c44d4 However, I suspect that just applying it won't solve the compilation breakage. There wasn't a patch in my tree for the header because it is only missing in the git tree. The hg repo does have it. So that header should be copied from our master v4l-dvb tree to Linus' git tree. Together with the mutex patch this driver should compile again. Regards, Hans Good catch. Mauro, can you please add these two as well for 2.6.32? I'm sure I marked these two as high-prio patches. This staging driver is actively being used and developed so this regression should be fixed. There were a merge problem when applying those patches at -git. As this is a staging driver, I opted to just move all patches to linux-next, as there were no mention on the patch subject mentioned that they are, in fact, fixes. I'll see what can we do to solve the s2250 compilation breakage. As Linus didn't merge from this pull request yet, I'll work on a fix, based on one of the Stefan suggestions, preferably backporting the patches. Cheers, Mauro -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 Sat, Nov 28, 2009 at 06:26:55PM -0500, Andy Walls wrote: The only thing this buys for the user is remote/products bundles that work out of the box. That can only be a solution for the 80% case. I don't hear users crying out Please integrate IR with the input system. I do hear users say I want my remote to work, and How can I make my remote work?. Users are not specifically asking for this integration of IR and the input system - a technical nuance. If such a tecnical desire-ment drives excessive rework, I doubt anyone will care enough about IR to follow through to make a complete system. Please integrate it so I can stop having issues with the lirc moduels when going to a new kernel version. What does equal footing mean as an incentive anyway? The opportunity to reimplement *everything* that exists for IR already over again in kernel-space for the sake of developer technical desires? That's just a lot of work for not invented here syndrome. IR transceivers are arguably superior to keyboards and mice anyway because they can transmit data too. I have no idea. I am sure you guys will come up with a great interface. I just use lirc with my mythtv box. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher - Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs Patrick, You added the USB ID for the 74e? Is that the result of actually trying it with the hardware? As far as I know, the 74e is not a Dibcom design. 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
RE: [PATCH 3/4 v8] TVP7002 driver for DM365
Hans, Note: Murali made a new function that will fill in the v4l2_dv_enum_preset based on the preset value. It's not yet in the v4l-dvb repository although I hope that the timing patches will go in soon. The only thing I'm waiting for is the revised documentation patch. I will try to spend some time on these this week. BTW: I think we need a g_dv_preset ops as well. That seems to be missing. Murali, is there any reason why we do not have that? One reason is we don't have a g_std() ops since core maintains the current norm. Other reason is at this point I don't see why we need this since bridge device driver is going to save the current std or current dv_preset set by application if s_std() or s_dv_preset() is successful. So if application calls G_DV_PRESET, bridge device driver will return the last successful std or dv_preset value. If we really need it for some reason, we could add it later when we integrate the vpfe/vpif drivers with this driver. +} Did you check whether it is really needed to power the chip off and on here? It still makes no sense to me that you have to do this. Can we make this a TODO item which can be addressed later? This driver is holding up my vpfe enhancements to support HD. This works functionally and we can always enhance the driver as required. So I suggest to keep this as a TODO item and address later using another patch. Murali -- 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 Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote: kevin granade wrote: On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: After the boot, a device can open the raw API, disabling any in-kernel decoding/handling and handle IR directly. Alternatively, an udev rule can load a different keymap based on some config written on a file. This idea of the in-kernel decoding being disabled when the raw API is opened worries me. What guarantees that the following scenario will not happen? User uses apps which retrieve the decoded IR messages from the kernel. User installs an app which decodes messages via the raw API (not lirc). User's other applications no longer receive IR messages. I know the assumption has been that only lirc will use the raw API, but this seems like a poor assumption for an API design to me. All those questions are theoretical, as we haven't a raw API code already merged in kernel. So, this is just my understanding on how this should work. If the user wants to use the raw interface, it is because the in-kernel decoding is not appropriate for his usage Not necessarily, someone might just want to observe the data stream for one reason or enough. You would not believe how many times I wanted to use evtest from X but could not because X grabs the device and had to switch to console (at least while such application is opened). So, not disabling the evdev output seems senseless. You know what they say when you assume things? Btw, this is the same behavior that happens when some application directly opens an evdev interface, instead of letting it to be redirected to stdin. Well, console applications don't get their input directly from event device but even if they did not redirecting it to stdin will not affect any other application that has the same event device open. This is a _huge_ difference. A related question, what is an application developer who wishes to decode the raw IR signal (for whatever reason) to do? Are they *required* to implement full decoding and feed all the messages back to the kernel so they don't break other applications? If such application won't do it, the IR will stop working, while the application is in use. I don't think it is indication of a good solution. -- Dmitry -- 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 3/4 v10] TVP7002 driver for DM365
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, November 27, 2009 10:07 PM To: santiago.nu...@ridgerun.com Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux- me...@vger.kernel.org; Narnakaje, Snehaprabha; Karicheri, Muralidharan; diego.do...@ridgerun.com; todd.fisc...@ridgerun.com; Grosen, Mark Subject: Re: [PATCH 3/4 v10] TVP7002 driver for DM365 On Friday 27 November 2009 23:32:20 santiago.nu...@ridgerun.com wrote: From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides the implementation of the TVP7002 decoder driver for DM365. Implemented using the V4L2 DV presets API. Removed shadow register values. Testing shows that the device needs not to be powered down and up for correct behaviour. Improved readability. Ok. That is great!. Looks like we are almost ready for merge. So please ignore my previous comments to keep this issue as a TODO list. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for November 30 (media/common/tuners/max2165)
Stephen Rothwell wrote: Hi all, Changes since 20091127: The v4l-dvb tree lost its conflict. on i386 (X86_32): a 'double' variable is used, causing: ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined! ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined! ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined! -- ~Randy -- 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?
Dmitry Torokhov wrote: On Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote: kevin granade wrote: On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: After the boot, a device can open the raw API, disabling any in-kernel decoding/handling and handle IR directly. Alternatively, an udev rule can load a different keymap based on some config written on a file. This idea of the in-kernel decoding being disabled when the raw API is opened worries me. What guarantees that the following scenario will not happen? User uses apps which retrieve the decoded IR messages from the kernel. User installs an app which decodes messages via the raw API (not lirc). User's other applications no longer receive IR messages. I know the assumption has been that only lirc will use the raw API, but this seems like a poor assumption for an API design to me. All those questions are theoretical, as we haven't a raw API code already merged in kernel. So, this is just my understanding on how this should work. If the user wants to use the raw interface, it is because the in-kernel decoding is not appropriate for his usage Not necessarily, someone might just want to observe the data stream for one reason or enough. You would not believe how many times I wanted to use evtest from X but could not because X grabs the device and had to switch to console (at least while such application is opened). So, not disabling the evdev output seems senseless. You know what they say when you assume things? Btw, this is the same behavior that happens when some application directly opens an evdev interface, instead of letting it to be redirected to stdin. Well, console applications don't get their input directly from event device but even if they did not redirecting it to stdin will not affect any other application that has the same event device open. This is a _huge_ difference. A related question, what is an application developer who wishes to decode the raw IR signal (for whatever reason) to do? Are they *required* to implement full decoding and feed all the messages back to the kernel so they don't break other applications? If such application won't do it, the IR will stop working, while the application is in use. I don't think it is indication of a good solution. Well, maybe then we may have an ioctl to explicitly disable the evdev processing of the data that could be applied to the raw IR interface, instead of making assumptions. -- 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
DIY Satellite Web Radio
Hi all, I'm not a DVB expert but I'm wondering if this idea is feasible: For an amateur web radio, for what I know, it is really hard to being listened in cars, like people do with commercial satellite radio [1] . Basically this is unaffortable for private user and this is probably the most relevant factor that penalize web radios againt terrestrial one. My question is: is there any way to use the current, cheap, satellite internet connections to stream some data above all the coverage of a geo satellite? and make the receiver handy (so without any dishes) ? Probably by introducing some _very_ redundant code inside the stream that we upload through the modem and that the satellite will stream from the sky, we can get some S/N db. The patch to do at the receiver is just software or maybe hardware? Lorenzo [1] http://www.xmradio.com/ signature.asc Description: OpenPGP digital signature
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes: That's a question that I have not answered for myself concludingly. Is a remote control really on exactly the same level as a keyboard or mouse? On some devices like STB and TV sets (most of modern LCD/Plasma TV's run Linux), they are at the same level. I'd say that the same applies to PC's that the user has dedicated to work as an MCE. A remote can just _be_ keyboard and/or (sort of) mouse. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Andy Walls awa...@radix.net writes: Nonetheless I'd still rather debug a problem with a dead process in userspace than an oops or panic (not that an end user cares) and avoid the risk of filesystem corruption. I'll concentrate on IRQ-driven space/mark drivers/devices since it's what I've been using. They are: very simple hardware (as simple as a TSOP1836 3-pin receiver chip + a resistor), very simple driver (the hardware signals change in input state with IRQ). Something like maybe 50 lines of code + the (default) key mapping table. Anyway, you can't move the whole driver to userspace, as it has to handle IRQs with timestamps. It doesn't have to sleep. It's about the last thing I'd worry about WRT the stability. So are we optimizing for the embedded/STB and HTPC with no keyboard use case, or the desktop or HTPC with a keyboard for maintencance? IOW the question is: do we want to continue supporting keyboard-less machines? -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
kevin granade kevin.gran...@gmail.com writes: This idea of the in-kernel decoding being disabled when the raw API is opened worries me. I don't think we need to disable the in-kernel decoding automatically. That would be rather unfortunate. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 2.6.32] V4L/DVB updates
Hi Linus, Em 27-11-2009 19:40, Stefan Lippers-Hollmann escreveu: Please consider cherry picking the following two patches from Hans Verkuil [1]: - add the missing s2250-loader.h - s2250 mutex patch or revert the patch which broke compiling go7007-usb (imho it would be better to re-add the 2 externs [2], than throwing away the needed mutex conversion, but it would be an option) Commit: fd9a40da1db372833e1af6397d2f6c94ceff3dad V4L/DVB (12859): go7007: semaphore - mutex conversion or mark CONFIG_VIDEO_GO7007_USB_S2250_BOARD as BROKEN, as it fails to compile since the afforementioned patch was merged on september 19th (this is a 2.6.31 -- 2.6.32 regression) [2,3]. Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus It is basically the same pull request as before with two more patches added, in order to fix the staging/g07007 compilation/work. The two new patches are: staging/go7007: Fix compilation by re-adding the missing s2250-loader.h staging/go7007: fix mutex function usage for s2250 (I replaced the subjects for a more adequate one, to explicitly say that those are fixes) Thanks! Mauro --- MAINTAINERS|7 +++ drivers/media/common/ir-functions.c|2 +- drivers/media/dvb/dvb-usb/cxusb.c | 10 +- drivers/media/dvb/siano/Kconfig|2 +- drivers/media/radio/radio-gemtek-pci.c |2 -- drivers/media/video/davinci/vpif_display.c |1 - drivers/media/video/em28xx/em28xx-cards.c |2 +- drivers/media/video/mx1_camera.c |1 + drivers/media/video/mx3_camera.c |1 + drivers/media/video/sh_mobile_ceu_camera.c |7 +-- drivers/media/video/soc_camera.c | 17 - drivers/media/video/videobuf-dma-contig.c |1 + drivers/staging/go7007/s2250-board.c |4 ++-- drivers/staging/go7007/s2250-loader.h | 24 14 files changed, 65 insertions(+), 16 deletions(-) create mode 100644 drivers/staging/go7007/s2250-loader.h Alan Cox (1): V4L/DVB (13530): Fix wrong parameter order in memset Antti Palosaari (1): V4L/DVB (13366): em28xx: fix Reddo DVB-C USB TV Box GPIO Geert Uytterhoeven (1): V4L/DVB (13412): SMS_SIANO_MDTV should depend on HAS_DMA Guennadi Liakhovetski (2): V4L/DVB (13343): v4l: add more missing linux/sched.h includes V4L/DVB (13344): soc-camera: properly initialise the device object when reusing Hans Verkuil (3): V4L/DVB (13321): radio-gemtek-pci: fix double mutex_lock V4L/DVB (13371): davinci: remove stray duplicate config pointer V4L/DVB (13481): sh_mobile_ceu_camera: fix compile warning Kuninori Morimoto (1): V4L/DVB (13345): soc-camera: sh_mobile_ceu_camera: call pm_runtime_disable Mauro Carvalho Chehab (1): staging/go7007: Fix compilation by re-adding the missing s2250-loader.h Olivier Lorin (1): V4L/DVB (13372a): MAINTAINERS: addition of gspca_gl860 driver Pete Eberlein (1): V4L/DVB (13372): staging/go7007: fix mutex function usage for s2250 Robert Lowery (1): V4L/DVB (13436): cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) --- V4L/DVB development is hosted at http://linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DIY Satellite Web Radio
Em 30-11-2009 17:13, OrazioPirataDelloSpazio (Lorenzo) escreveu: Hi all, I'm not a DVB expert but I'm wondering if this idea is feasible: For an amateur web radio, for what I know, it is really hard to being listened in cars, like people do with commercial satellite radio [1] . Basically this is unaffortable for private user and this is probably the most relevant factor that penalize web radios againt terrestrial one. My question is: is there any way to use the current, cheap, satellite internet connections to stream some data above all the coverage of a geo satellite? and make the receiver handy (so without any dishes) ? Receiving sat signals without dishes? From some trials we had on a telco I used to work, You would need to use a network of low-orbit satellites, carefully choosing the better frequencies and it will provide you low bandwidth. This will likely cost a lot of money, if you find someone providing a service like that. One trial for such network were the Iridum project. AFAIK, the original company bankrupted due to the very high costs of launching and managing about a hundred satellite network. I'm not tracking such things nowadays, but I won't doubt that you would find someone providing this kind of services. I think the telephones that are onboard of some flight companies use a satellite service like that. Probably by introducing some _very_ redundant code inside the stream that we upload through the modem and that the satellite will stream from the sky, we can get some S/N db. The patch to do at the receiver is just software or maybe hardware? You'll likely need to design an special hardware for such usage. 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 Sun, Nov 29, 2009 at 7:01 AM, Christoph Bartelmus l...@bartelmus.de wrote: Hi Jon, on 27 Nov 09 at 12:49, Jon Smirl wrote: [...] Christoph, take what you know from all of the years of working on LIRC and design the perfect in-kernel system. This is the big chance to redesign IR support and get rid of any past mistakes. Incorporate any useful chunks of code and knowledge from the existing LIRC into the new design. Drop legacy APIs, get rid of daemons, etc. You can do this redesign in parallel with existing LIRC. Everyone can continue using the existing code while the new scheme is being built. Think of it as LIRC 2.0. You can lead this design effort, you're the most experience developer in the IR area. This is a very difficult thing for me to do. I must admit that I'm very biased. Because lircd is the only userspace application that uses the LIRC kernel interface, we never had any problems changing the interface when needed. I can't say there's much legacy stuff inside. I'm quite happy with the interface. The other thing is that I can't really move the decoder from userspace to kernel because there are way too many userspace drivers that do require a userspace decoder. LIRC also is running on FreeBSD, MacOS and even Cygwin. So letting the userspace drivers take advantage of a potential Linux in- kernel decoder is not an option for me either. I'm having my 'LIRC maintainer' hat on mostly during this discussion and I do understand that from Linux kernel perspective things look different. It would be interesting to split the lirc daemon. Put the protocol decoder stuff in one daemon and the scripting support in the other. The scripting daemon would then be optional. What would be the relative sizes of the two daemons? -- The LIRC daemon always works with timing data, right? When it reads the config files generated by irrecord it internally converts those to timing data and then matches the incoming data against it. Have you looked at the protocol engine idea? Running the protocol engines in parallel until a match is achieved. Then map the vendor/device/command triplet. The protocol engine concept fixes the problem of Sony remotes in irrecord. Various Sony remote buttons transmit in different protocols. irrecord assumes that a remote is only using a single protocol. Since it can't figure out a protocol it always records these remotes as raw. If the IR data is being decoded in a protocol engine it becomes possible to get rid of the need to configure IR in some cases. Apps like MythTV could pretend like they are a common piece of electronics hardware - say a Motorola DVR. MythTV can then look for the vendor/device/command triplet from a Motorola DVR. Set your programmable remote to send the Motorola DVR commands and everything will just work. Button on remote programed to be Mot DVR -- protocol engine -- Mot/dev/command -- MythTV which is looking for Mot/dev/command No config files needed. Make a command in MythTV to switch to emulating a different DVR if you happen to own this one. Take this a step further and register a MythTV profile with the various IR databases. Take advantage of this window to make a design that is fully integrated with Linux - put IR on equal footing with the keyboard and mouse as it should be. That's a question that I have not answered for myself concludingly. Is a remote control really on exactly the same level as a keyboard or mouse? Christoph -- 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: DIY Satellite Web Radio
Mauro Carvalho Chehab ha scritto: Receiving sat signals without dishes? From some trials we had on a telco I used to work, You would need to use a network of low-orbit satellites, carefully choosing the better frequencies and it will provide you low bandwidth. I also believed this, but their use geostationary orbit [1] and terrestrial devices handly and without dishes [2] [3]. I belive they should rely on some very robust modulation e channel coding, but unfortunately I didn't find any specification. Lorenzo [1]http://en.wikipedia.org/wiki/XM_Satellite_Radio [2]http://shop.xmradio.com/xm/ctl10600/cp49770/si4025808/cl1/xmp3_portable_radio_with_home_kit [3]http://shop.xmradio.com/xm/ctl10600/cp56879/si4343009/cl1/xm_direct_2 signature.asc Description: OpenPGP digital signature
Re: Compile error saa7134 - compro videomate S350
Hi Hermann, There is a sign of life coming from the card (I connected my SAT finder and got a loud tone from it). You might want to set dvb_powerdown_on_sleep=0 for dvb_core. How do you specify this and which file (saa7134-dvb.c or saa7134-core.c or some other file)? I tried Kaffeine, to scan Astra 19.2 but no luck, at first I can see the signal meters light up and then stop. The output from dmesg at this point shows: [ 72.944834] DVB: registering adapter 0 frontend 0 (Zarlink ZL10313 DVB-S)... [ 2183.208025] DVB: adapter 0 frontend 0 frequency 7401500 out of range (95..215) [ 2191.756534] DVB: adapter 0 frontend 0 frequency 7401500 out of range (95..215) [ 2195.908528] DVB: adapter 0 frontend 0 frequency 7401500 out of range (95..215) Not sure what this means. Thanks, Dominic - Original Message From: hermann pitton hermann-pit...@arcor.de To: Dominic Fernandes dalf...@yahoo.com Cc: linux-media@vger.kernel.org Sent: Mon, November 30, 2009 1:29:25 AM Subject: Re: Compile error saa7134 - compro videomate S350 Hi Dominic, Am Samstag, den 28.11.2009, 17:30 -0800 schrieb Dominic Fernandes: Hi Hermann, I'm getting closer!!! I'm using ubuntu 9.10, unloading saa7134 alsa wasn't working for me so I put it into the blacklist which prevented it from loading and then I was able to do the modprobe -vr saa7134-alsa saa7134-dvb and modprobe -v saa7134 card=16. And now the card recongnised correctly as the S350 and the dvb frontend loads. So, now I've plugged in the cable to the SAT dish which is pointing to Astra 19.2 and want to tune into some channels. I installed dvb-apps and use the command below to create a channels.conf to use later:- scan -x0 /usr/share/dvb/dvb-s/Astra-19.2E | tee channels.conf but this soon concludes with tunning finished with no channels found. I get a warning tuning failed. So, I tried both the modification of the GPIO address of xc and what it was originally x8000 which gave the same tuning failed message. Are there some other commands to test the DVB Frontend? if Astra-19.2E is unchanged in dvb-apps, it has not much. # Astra 19.2E SDT info service transponder # freq pol sr fec S 12551500 V 2200 5/6 We don't even know if 13 and 18 Volts to the LNB work both for sure with that variant, IIRC. The report says just somehow works. I think I would try with some peace of copper from a LNB cable into the RF connector and a Voltmeter, if there is any sign of life first, either using kaffeine with better files for scanning or the setvoltage tool in /test. You might want to set dvb_powerdown_on_sleep=0 for dvb_core. For the other saa7134 driver cards currently is hacked on, For Dominic with the Leadtek on the saa7134 driver, Terry, me or anyone else interested should provide some test patches. Why that AverMedia analog only in the Ukraine doesn't have sound even on PAL around there, is beyond my imagination, except it would not have ever been tested for TV sound, also beyond what I can imagine. Any log for obviously failing sound carrier detection is still missing. 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 -- 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 -next] media/common/tuners: fix use of KERNEL_VERSION
From: Randy Dunlap randy.dun...@oracle.com pms.c uses KERNEL_VERSION so it needs to include version.h. drivers/media/video/pms.c:682: error: implicit declaration of function 'KERNEL_VERSION' Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/video/pms.c |1 + 1 file changed, 1 insertion(+) --- linux-next-20091130.orig/drivers/media/video/pms.c +++ linux-next-20091130/drivers/media/video/pms.c @@ -29,6 +29,7 @@ #include linux/mm.h #include linux/ioport.h #include linux/init.h +#include linux/version.h #include asm/io.h #include linux/videodev2.h #include media/v4l2-common.h -- 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 -next] media/common/tuners: fix use of KERNEL_VERSION
Randy Dunlap wrote: From: Randy Dunlap randy.dun...@oracle.com pms.c uses KERNEL_VERSION so it needs to include version.h. Incorrect $subject, sorry. drivers/media/video/pms.c:682: error: implicit declaration of function 'KERNEL_VERSION' Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/video/pms.c |1 + 1 file changed, 1 insertion(+) --- linux-next-20091130.orig/drivers/media/video/pms.c +++ linux-next-20091130/drivers/media/video/pms.c @@ -29,6 +29,7 @@ #include linux/mm.h #include linux/ioport.h #include linux/init.h +#include linux/version.h #include asm/io.h #include linux/videodev2.h #include media/v4l2-common.h -- ~Randy -- 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 Jon, on 30 Nov 09 at 16:35, Jon Smirl wrote: [...] It would be interesting to split the lirc daemon. Put the protocol decoder stuff in one daemon and the scripting support in the other. The scripting daemon would then be optional. What would be the relative sizes of the two daemons? -- The LIRC daemon always works with timing data, right? Timing data or hex codes (if decoding is done in hardware). When it reads the config files generated by irrecord it internally converts those to timing data No. and then matches the incoming data against it. Pattern matching is only done with raw mode config files. The normal case is that lircd is decoding the incoming data using the protocol description found in the config file. Have you looked at the protocol engine idea? Running the protocol engines in parallel until a match is achieved. Then map the vendor/device/command triplet. The protocol engine concept fixes the problem of Sony remotes in irrecord. No, only rewriting irrecord would fix the problem of Sony remotes. irrecord tries to guess the protocol parameters without any prior knowledge about any protocols. irrecord could also be rewritten to use the protocol engine concept without changing anything in the decoder itself. In fact partly this is already available. You can give irrecord a template config file and it will skip the protocol guessing step. This just would have to be extended so that the template config file could contain several protocol descriptions to match against. I havn't implemented this yet, because I don't care much. Sony remotes do work flawlessly also in raw mode. It's only a problem from the aesthetic view point. Various Sony remote buttons transmit in different protocols. irrecord assumes that a remote is only using a single protocol. Since it can't figure out a protocol it always records these remotes as raw. With manual intervention you can convert these raw config files afterwards with irrecord -a. [...] Button on remote programed to be Mot DVR -- protocol engine -- Mot/dev/command -- MythTV which is looking for Mot/dev/command No config files needed. You just move complexity to the application. MythTV would have to know how a Motorola command set looks like. Currently I would tend to an approach like this: - raw interface to userspace using LIRC - fixed set of in-kernel decoders that can handle bundled remotes That would allow zero configuration for simple use cases and full flexibility for more advanced use cases. Christoph -- 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
