Re: [PATCH 2/2] V4L/DVB: Use custom I2C probing function mechanism
Hi Andy, On Sun, 04 Apr 2010 21:54:39 -0400, Andy Walls wrote: On Sun, 2010-04-04 at 16:14 +0200, Jean Delvare wrote: Now that i2c-core offers the possibility to provide custom probing function for I2C devices, let's make use of it. Signed-off-by: Jean Delvare kh...@linux-fr.org --- I wasn't too sure where to put the custom probe function: in each driver, in the ir-common module or in the v4l2-common module. I went for the second option as a middle ground, but am ready to discuss it if anyone objects. With respect to cx23885, could you comment on the interaction of this patch with some patches of yours that are not merged yet: http://linuxtv.org/hg/~awalls/cx23885-ir2/rev/b39f8849a35b http://linuxtv.org/hg/~awalls/cx23885-ir2/rev/3cf1ac545ca5 http://linuxtv.org/hg/~awalls/cx23885-ir2/rev/ef5d2c08106f Are they related to the IR microcontroller not being probed properly? No, I don't expect any interaction between this new patch and the older patchset. The older patchset would let the cx23885 I2C implementation properly report slave nacks, but a successful IR device probing wouldn't return a nack. So, the patches can be merged in any order, nothing wrong will happen either way. (I tried to get these patches merged, but didn't due to problems with other patches in my PULL request, and then a severe shortage of time.) 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: new V4L control framework
On Monday 05 April 2010 04:58:02 Andy Walls wrote: On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote: Hi all, The support in drivers for the V4L2 control API is currently very chaotic. Few if any drivers support the API correctly. Especially the support for the new extended controls is very much hit and miss. Combine that with the requirements for the upcoming embedded devices that will want to use controls much more actively and you end up with a big mess. I've wanted to fix this for a long time and last week I finally had the time. The new framework works like a charm and massively reduces the complexity in drivers when it comes to control handling. And just as importantly, any driver that uses it is fully compliant to the V4L spec. Something that application writers will appreciate. I have converted the cx2341x.c module and tested it with ivtv since that is by far the most complex example of control handling. The new code is much, much cleaner. The documentation is available here: http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt From reading the Documentation. Things look very much improved. However: When a subdevice is registered with a bridge driver and the ctrl_handler fields of both v4l2_subdev and v4l2_device are set, then the controls of the subdev will become automatically available in the bridge driver as well. If the subdev driver contains controls that already exist in the bridge driver, then those will be skipped (so a bridge driver can always override a subdev control). I think I have 2 cases where that is undesriable: 1. cx18 volume control: av_core subdev has a volume control (which the bridge driver currently reports as it's volume control) and the cs5435 subdev has a volume control. I'd really need them *both* to be controllable by the user. I'd also like them to appear as a single (bridge driver) volume control to the user - as that is what a user would expect. So the bridge driver implements the volume control, but the bridge's s_ctrl operation will in turn control the subdev's volume implementation, right? That's no problem. I do need to add a few utility functions to make this easy, though. I realized that I need that anyway when I worked on converting bttv yesterday. Of course, once we can create device nodes for sub-devices, then the controls of the cs5435 will show up there as well so the user can have direct access to that volume control. But that's not really for applications, though. 2. ivtv volume control for an AverTV M113 card. The CX2584x chip is normally the volume control. However, due to some poor baseband audio noise performance on this card, it is advantagous to adjust the volume control on the WM8739 subdev that feeds I2S audio into the CX2584x chip. Here, I would like a secondary volume control, not an override of the primary. (Here's my old hack: http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 ) Maybe there's a way to use the control clusters to handle some of this. I'm a bit too tired to figure it all out at the moment. Interesting use case. I have several ideas, but I need some time to think about it a bit more. Basically you want to be able to merge-and-remap controls. Or perhaps even allow some sort of control hierarchy. 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: update gspca driver in linux source tree
The problem with all the trees (http://linuxtv.org/hg/v4l-dvb/ and http://linuxtv.org/hg/v4l-dvb/) are the used perl scripts to build the makefile. They use uname -r to get the kernel version and they use directories like /lib/modules as default. Now, I try to cross compile the tree on my ubuntu machine for an ARM embedded system. The arm kernel tree is under a different path than /lib/modules//build and uname -r returns the kernel version of my local machine. So the drivers don't get properly compiled. After some changes in the perl scripts I was able to cross compile the drivers for my ARM linux system. I have already tried it some weeks before, but at that time I had no succes. For this reason I tried it by copying the driver sources into my ARM kernel tree. Now it works for me. I have still one question: Where can I find the .config file in the linux tree after make menuconfig? Regards, Joern You will want to not use my tree, but use the latest generic tree: hg clone http://linuxtv.org/hg/v4l-dvb/ Then simply compile that tree (this will need the headers of your 2.6.29 kernel in the usual place): cd v4l-dvb make menuconfig make sudo make install And then reboot, now you will be using your 2.9.29 kernel with a fully up2date v4l-dvb subsystem. 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 -- 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: STV6110 vs STV6110x
Hi Patrick, On Mon, Apr 5, 2010 at 5:21 PM, Patrick Boettcher pboettc...@kernellabs.com wrote: Hi Igor, hi Manu, I'm currently adding support for a device based on STV0903+STV6110 frontend combination. Early investigation have shown that for both devices there is a driver - now looking in more detail because I'm doing the actual coding, I'm finding out that there is actually 2 drivers for STV6110. Which one I need to/can use for my hardware? From a first glance the actual code is identical (not the coding itself, but the things done). Please advise me what to do? stv090x supports both the STV0900 and STV0903 demodulators. TT S2-1600 (Budget card) uses STV0903 (stv090x)+STV6110A(stv6110x) with budget.c Most likely, you can copy the configuration from budget.c as well for your card. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: new V4L control framework
Hans Verkuil wrote: On Monday 05 April 2010 04:58:02 Andy Walls wrote: On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote: Hi all, The support in drivers for the V4L2 control API is currently very chaotic. Few if any drivers support the API correctly. Especially the support for the new extended controls is very much hit and miss. Combine that with the requirements for the upcoming embedded devices that will want to use controls much more actively and you end up with a big mess. I've wanted to fix this for a long time and last week I finally had the time. The new framework works like a charm and massively reduces the complexity in drivers when it comes to control handling. And just as importantly, any driver that uses it is fully compliant to the V4L spec. Something that application writers will appreciate. I have converted the cx2341x.c module and tested it with ivtv since that is by far the most complex example of control handling. The new code is much, much cleaner. The documentation is available here: http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt From reading the Documentation. Things look very much improved. However: When a subdevice is registered with a bridge driver and the ctrl_handler fields of both v4l2_subdev and v4l2_device are set, then the controls of the subdev will become automatically available in the bridge driver as well. If the subdev driver contains controls that already exist in the bridge driver, then those will be skipped (so a bridge driver can always override a subdev control). I think I have 2 cases where that is undesriable: 1. cx18 volume control: av_core subdev has a volume control (which the bridge driver currently reports as it's volume control) and the cs5435 subdev has a volume control. I'd really need them *both* to be controllable by the user. I'd also like them to appear as a single (bridge driver) volume control to the user - as that is what a user would expect. So the bridge driver implements the volume control, but the bridge's s_ctrl operation will in turn control the subdev's volume implementation, right? That's no problem. I do need to add a few utility functions to make this easy, though. I realized that I need that anyway when I worked on converting bttv yesterday. I think this is a common case for some audio controls: in general, bridge drivers have a set of volume adjustments, but, depending on how the audio is connected (I2S, analog input, analog directly wired to an output pin or to an AC97 chip), the bridge volume may or may not work, and you may need to map the sub-device volume control. Em28xx is probably an interesting case, since it is designed to work with an AC97 audio chip, but it also supports I2S. Older designs were shipped with a msp34xx audio chip, while newer designs come with an Empia202 or with other AC97 chips. Depending on the specific hardware, the volume should be controlled into either one of the devices. Of course, once we can create device nodes for sub-devices, then the controls of the cs5435 will show up there as well so the user can have direct access to that volume control. But that's not really for applications, though. I don't think that a technical volume control per subdevice would make sense, except on a very few cases, where you might need to deal with more than one volume control, to avoid distortions. On most cases, you need to use just one of the controls. 2. ivtv volume control for an AverTV M113 card. The CX2584x chip is normally the volume control. However, due to some poor baseband audio noise performance on this card, it is advantagous to adjust the volume control on the WM8739 subdev that feeds I2S audio into the CX2584x chip. Here, I would like a secondary volume control, not an override of the primary. (Here's my old hack: http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 ) Maybe there's a way to use the control clusters to handle some of this. I'm a bit too tired to figure it all out at the moment. Interesting use case. I have several ideas, but I need some time to think about it a bit more. Basically you want to be able to merge-and-remap controls. Or perhaps even allow some sort of control hierarchy. I'd say that the bridge driver should be able to disable the visibility of a control from userspace, while keeping being able of accessing it for its own control implementations. -- 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: new V4L control framework
On Sun, Apr 4, 2010 at 10:58 PM, Andy Walls awa...@md.metrocast.net wrote: I think I have 2 cases where that is undesriable: 1. cx18 volume control: av_core subdev has a volume control (which the bridge driver currently reports as it's volume control) and the cs5435 subdev has a volume control. I'd really need them *both* to be controllable by the user. I'd also like them to appear as a single (bridge driver) volume control to the user - as that is what a user would expect. For what it's worth, I've got a similar problem I am going to need to deal with. I'm working on a hardware design which has a volume control built into the audio processor, as well as a separate i2c controllable volume control (a cs3308). So I am indeed *very* interested in seeing the best approach for dealing with this issue. 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
[PULL] an soc-camera fix for 2.6.34
Hi Mauro as agreed on IRC, please add the following Acked-by: Sascha Hauer s.ha...@pengutronix.de (see also http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17845 ) when pulling from: The following changes since commit a8f0df5fc2bc2e0aa0ead578bb93214915573efd: Michael Hunold (1): V4L/DVB: saa7146: fix up bytesperline if it is an impossible value are available in the git repository at: ssh://linuxtv.org/git/gliakhovetski/soc-camera.git fixes Uwe Kleine-König (1): V4L/DVB: mx1-camera: compile fix arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h |8 +++- drivers/media/video/mx1_camera.c |8 +++- 2 files changed, 10 insertions(+), 6 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: new V4L control framework
On Monday 05 April 2010 17:41:47 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: On Monday 05 April 2010 04:58:02 Andy Walls wrote: On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote: Hi all, The support in drivers for the V4L2 control API is currently very chaotic. Few if any drivers support the API correctly. Especially the support for the new extended controls is very much hit and miss. Combine that with the requirements for the upcoming embedded devices that will want to use controls much more actively and you end up with a big mess. I've wanted to fix this for a long time and last week I finally had the time. The new framework works like a charm and massively reduces the complexity in drivers when it comes to control handling. And just as importantly, any driver that uses it is fully compliant to the V4L spec. Something that application writers will appreciate. I have converted the cx2341x.c module and tested it with ivtv since that is by far the most complex example of control handling. The new code is much, much cleaner. The documentation is available here: http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/9b6708e8293c/linux/Documentation/video4linux/v4l2-controls.txt From reading the Documentation. Things look very much improved. However: When a subdevice is registered with a bridge driver and the ctrl_handler fields of both v4l2_subdev and v4l2_device are set, then the controls of the subdev will become automatically available in the bridge driver as well. If the subdev driver contains controls that already exist in the bridge driver, then those will be skipped (so a bridge driver can always override a subdev control). I think I have 2 cases where that is undesriable: 1. cx18 volume control: av_core subdev has a volume control (which the bridge driver currently reports as it's volume control) and the cs5435 subdev has a volume control. I'd really need them *both* to be controllable by the user. I'd also like them to appear as a single (bridge driver) volume control to the user - as that is what a user would expect. So the bridge driver implements the volume control, but the bridge's s_ctrl operation will in turn control the subdev's volume implementation, right? That's no problem. I do need to add a few utility functions to make this easy, though. I realized that I need that anyway when I worked on converting bttv yesterday. I think this is a common case for some audio controls: in general, bridge drivers have a set of volume adjustments, but, depending on how the audio is connected (I2S, analog input, analog directly wired to an output pin or to an AC97 chip), the bridge volume may or may not work, and you may need to map the sub-device volume control. Em28xx is probably an interesting case, since it is designed to work with an AC97 audio chip, but it also supports I2S. Older designs were shipped with a msp34xx audio chip, while newer designs come with an Empia202 or with other AC97 chips. Depending on the specific hardware, the volume should be controlled into either one of the devices. There are a few possibilities: 1) The bridge controls the volume. Easy, just make a bridge volume control and that will hide any subdev volume controls you might have. 2) The subdev handles the volume. Easy again, just don't make a bridge volume control. I am not sure whether I should make some code to remove a control. Right now you can only add, not remove, which makes the framework a lot easier. Some sort of removal scheme could be made, but it would be more like hiding controls than actually removing it (as that would make pointer management so much harder). 3) The bridge controls the volume, but needs to cooperate with the subdev's volume control. Fairly easy: make a bridge volume control, get a pointer to the subdev's volume control and let the volume control code of the bridge use that pointer to manipulate the volume of the subdev. Note that the bridge has to know how that control works. The min/max/step values for such a control may not match those of the bridge. 4) The user needs to see both volume controls. While this is possible once subdevs have their own device nodes, this is really meant for embedded systems and not for use with consumer hardware. One option is to make a new set of control IDs to control the secondary audio controls. Then all I need to do in the control framework is to make something like: v4l2_ctrl_add_ctrl_remap(struct v4l2_ctrl_handler *hdl, struct v4l2_ctrl_info *cinfo, u32 new_id); However, that requires new control IDs (and who knows for what other controls we need to do this as well in the future) and a lot of manual work in the driver. Also, they won't be visible in applications unless those applications are recompiled with the new V4L2_CID_LASTP1 value (or
Re: [PATCH 2/2] V4L/DVB: Use custom I2C probing function mechanism
Hi Jean,
Jean Delvare wrote:
Now that i2c-core offers the possibility to provide custom probing
function for I2C devices, let's make use of it.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
I wasn't too sure where to put the custom probe function: in each driver,
in the ir-common module or in the v4l2-common module. I went for the
second option as a middle ground, but am ready to discuss it if anyone
objects.
Please, don't add new things at ir-common module. It basically contains the
decoding functions for RC5 and pulse/distance, plus several IR keymaps. With
the IR rework I'm doing, this module will go away, after having all the current
IR decoders implemented via ir-raw-input binding.
The keymaps were already removed from it, on my experimental tree
(http://git.linuxtv.org/mchehab/ir.git), and rc5 decoder is already written
(but still needs a few fixes).
The new ir-core is creating an abstract way to deal with Remote Controllers,
meant to be used not only by IR's, but also for other types of RC, like,
bluetooth and USB HID. It will also export a raw event interface, for use
with lirc. As this is the core of the RC subsystem, a i2c-specific binding
method also doesn't seem to belong there. SO, IMO, the better place is to add
it as a static inline function at ir-kbd-i2c.h.
drivers/media/IR/ir-functions.c | 12
drivers/media/video/cx23885/cx23885-i2c.c | 14 +++---
drivers/media/video/cx88/cx88-i2c.c | 18 +++---
include/media/ir-common.h |5 +
4 files changed, 23 insertions(+), 26 deletions(-)
--- linux-2.6.34-rc3.orig/drivers/media/video/cx23885/cx23885-i2c.c
2010-04-04 09:06:38.0 +0200
+++ linux-2.6.34-rc3/drivers/media/video/cx23885/cx23885-i2c.c
2010-04-04 13:34:34.0 +0200
@@ -28,6 +28,7 @@
#include cx23885.h
#include media/v4l2-common.h
+#include media/ir-common.h
static unsigned int i2c_debug;
module_param(i2c_debug, int, 0644);
@@ -365,17 +366,8 @@ int cx23885_i2c_register(struct cx23885_
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, ir_video, I2C_NAME_SIZE);
- /*
- * We can't call i2c_new_probed_device() because it uses
- * quick writes for probing and the IR receiver device only
- * replies to reads.
- */
- if (i2c_smbus_xfer(bus-i2c_adap, addr_list[0], 0,
-I2C_SMBUS_READ, 0, I2C_SMBUS_QUICK,
-NULL) = 0) {
- info.addr = addr_list[0];
- i2c_new_device(bus-i2c_adap, info);
- }
+ i2c_new_probed_device(bus-i2c_adap, info, addr_list,
+ ir_i2c_probe);
}
return bus-i2c_rc;
--- linux-2.6.34-rc3.orig/drivers/media/video/cx88/cx88-i2c.c 2010-04-04
09:06:38.0 +0200
+++ linux-2.6.34-rc3/drivers/media/video/cx88/cx88-i2c.c 2010-04-04
13:34:34.0 +0200
@@ -34,6 +34,7 @@
#include cx88.h
#include media/v4l2-common.h
+#include media/ir-common.h
static unsigned int i2c_debug;
module_param(i2c_debug, int, 0644);
@@ -188,24 +189,11 @@ int cx88_i2c_init(struct cx88_core *core
0x18, 0x6b, 0x71,
I2C_CLIENT_END
};
- const unsigned short *addrp;
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, ir_video, I2C_NAME_SIZE);
- /*
- * We can't call i2c_new_probed_device() because it uses
- * quick writes for probing and at least some R receiver
- * devices only reply to reads.
- */
- for (addrp = addr_list; *addrp != I2C_CLIENT_END; addrp++) {
- if (i2c_smbus_xfer(core-i2c_adap, *addrp, 0,
-I2C_SMBUS_READ, 0,
-I2C_SMBUS_QUICK, NULL) = 0) {
- info.addr = *addrp;
- i2c_new_device(core-i2c_adap, info);
- break;
- }
- }
+ i2c_new_probed_device(core-i2c_adap, info, addr_list,
+ ir_i2c_probe);
}
return core-i2c_rc;
}
--- linux-2.6.34-rc3.orig/drivers/media/IR/ir-functions.c 2010-03-18
17:06:30.0 +0100
+++ linux-2.6.34-rc3/drivers/media/IR/ir-functions.c 2010-04-04
14:30:29.0 +0200
@@ -23,6 +23,7 @@
#include linux/module.h
#include linux/string.h
#include linux/jiffies.h
+#include linux/i2c.h
#include media/ir-common.h
/*
-- */
@@ -353,3 +354,14 @@ void ir_rc5_timer_keyup(unsigned long da
Re: [PATCH 04/15] V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core
Andy Walls wrote: 2. A common glitch filtering library function that can be used by all decoders, and that also can accept a decoder specified minimum acceptable pulse width. Seems a nice improvement. I doubt I'll have time for handling it right now, since there are still many things to do, but I'll put it on my todo list. Of course, patches adding it are wellcome ;) :) OK. When I find time I'll hack something up as a prototype. Thanks! Btw, I added a RC-5 decoder there, at my IR experimental tree: http://git.linuxtv.org/mchehab/ir.git I'll try to review it some time this week. Streaming state machine decoders do seem to be best way to go with these decoders. I have an RC-5 decoder in cx23885-input.c that isn't as clean as the NEC protocol decoder I developed. The cx23885-input.c RC-5 decoder is not a very explicit state machine however (it is a bit hack-ish). The state machine seems to be working fine with the code, but I think I found the issue: it was expecting 14 bits after the start+toggle bits, instead of a total of 14 bits. I'll fix it. I'll probably end by simplifying it to have only 3 states: inactive, mark-space and trailer. Unfortunately, there's some problem with either my Remote Controller or with the saa7134 driver. After 11 bits received, after the 2 start bits, it receives a pause (see the enclosed sequence). -ENOATTACHMENT Sorry! It is basically the same output as yours. See enclosed. I'm starting to suspect that the Hauppauge Grey IR produces a sequence with shorter bits, but, as the hardware decoders are capable or receiving IR codes, it may also be a hardware problem. The fundamental unit in RC-5 is 32 cycles / 36 kHz = 89 ns ~= 889 us. I turned on the cx23888-ir.c debugging on the HVR-1850 and using a Hauppague grey remote (address 0x1e IIRC) and got this as just one example: cx23885[1]/888-ir: rx read: 802037 ns mark cx23885[1]/888-ir: rx read: 852704 ns space cx23885[1]/888-ir: rx read: 775370 ns mark cx23885[1]/888-ir: rx read: 852407 ns space cx23885[1]/888-ir: rx read: 802037 ns mark cx23885[1]/888-ir: rx read: 852852 ns space cx23885[1]/888-ir: rx read: 775667 ns mark cx23885[1]/888-ir: rx read: 852407 ns space cx23885[1]/888-ir: rx read: 801741 ns mark cx23885[1]/888-ir: rx read: 852852 ns space cx23885[1]/888-ir: rx read: 775667 ns mark cx23885[1]/888-ir: rx read: 852407 ns space cx23885[1]/888-ir: rx read:1602926 ns mark cx23885[1]/888-ir: rx read: 852407 ns space cx23885[1]/888-ir: rx read: 801741 ns mark cx23885[1]/888-ir: rx read: 852852 ns space cx23885[1]/888-ir: rx read: 775074 ns mark cx23885[1]/888-ir: rx read: 853148 ns space cx23885[1]/888-ir: rx read: 801593 ns mark cx23885[1]/888-ir: rx read: 852704 ns space cx23885[1]/888-ir: rx read: 775667 ns mark cx23885[1]/888-ir: rx read: 852556 ns space cx23885[1]/888-ir: rx read: 801741 ns mark cx23885[1]/888-ir: rx read: 852259 ns space cx23885[1]/888-ir: rx read: 775963 ns mark cx23885[1]/888-ir: rx read: end of rx That should be a press of '0' on the remote. 'end of rx' means the hardware measured a really long space. I also had the hardware low pass filter on. I think that would effect the space measurements by making them shorter, if IR noise caused a glitch. Note that many of the marks are a bit shorter than the ideal 889 us. In fact the single marks from the grey remote seem to alternate between 775 us and 802 us. The same happened here. The carrier doesn't seem to be precisely 36 kHz. The code on saa7134 has a way to adjust the time, plus a logic a timer to adjust the end of a RC5 code reception. It seems a good idea to allow adjusting those timers via sysfs. I have attached a larger capture of (attempted) single presses of the digits '0' through '9' and then an intentionally held down press of '7'. With a quick glance, I don't see pauses from the grey remote. Thanks for your dumps! It is not clear that the saa7134 is doing the right thing, and that the IR uses less bits than the standard. Regards, Andy -- Cheers, Mauro The ir-raw-event output for digit '0' is: [ 2803.106396] ir_raw_event_handle: event type 6, time before event: 000us [ 2803.106404] ir_raw_event_handle: event type 1, time before event: 919us [ 2803.106409] ir_raw_event_handle: event type 2, time before event: 868us [ 2803.106412] ir_raw_event_handle: event type 1, time before event: 893us [ 2803.106415] ir_raw_event_handle: event type 2, time before event: 869us [ 2803.106418] ir_raw_event_handle: event type 1, time before event: 921us [ 2803.106424] ir_raw_event_handle: event type 2, time before event: 869us [ 2803.106427] ir_raw_event_handle: event type 1, time before event: 893us [ 2803.106433] ir_raw_event_handle: event type 2, time before event: 869us [
[PATCH 00/11] treewide: rename dev_info variables to something else
There is a macro called dev_info that prints struct device specific information. Having variables with the same name can be confusing and prevents conversion of the macro to a function. Rename the existing dev_info variables to something else in preparation to converting the dev_info macro to a function. Joe Perches (11): arch/ia64/hp/common/sba_iommu.c: Rename dev_info to adi drivers/usb/host/hwa-hc.c: Rename dev_info to hdi drivers/usb/wusbcore/wusbhc.h: Remove unused dev_info from struct wusb_port drivers/s390/block/dcssblk.c: Rename dev_info to ddi drivers/edac/amd: Rename dev_info to adi drivers/edac/cpc925_edac.c: Rename dev_info to cdi drivers/edac/e7*_edac.c: Rename dev_info to edi drivers/staging/iio: Rename dev_info to idi pvrusb2-v4l2: Rename dev_info to pdi drivers/char/mem.c: Rename dev_info to bdi drivers/uwb: Rename dev_info to wdi arch/ia64/hp/common/sba_iommu.c|8 +- drivers/char/mem.c |6 +- drivers/edac/amd8111_edac.c| 88 drivers/edac/amd8131_edac.c| 86 drivers/edac/cpc925_edac.c | 122 +- drivers/edac/e752x_edac.c | 18 +- drivers/edac/e7xxx_edac.c |8 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 22 +- drivers/s390/block/dcssblk.c | 328 ++-- drivers/staging/iio/accel/lis3l02dq_core.c |4 +- drivers/staging/iio/accel/lis3l02dq_ring.c | 20 +- drivers/staging/iio/accel/sca3000_core.c | 24 +- drivers/staging/iio/adc/max1363_core.c | 36 ++-- drivers/staging/iio/adc/max1363_ring.c |6 +- drivers/staging/iio/chrdev.h |2 +- drivers/staging/iio/iio.h | 54 +++--- drivers/staging/iio/industrialio-core.c| 232 ++-- drivers/staging/iio/industrialio-ring.c| 38 ++-- drivers/staging/iio/industrialio-trigger.c | 34 ++-- drivers/staging/iio/ring_generic.h |4 +- drivers/staging/iio/trigger_consumer.h | 16 +- drivers/usb/host/hwa-hc.c | 18 +- drivers/usb/wusbcore/wusbhc.h | 10 - drivers/uwb/i1480/i1480u-wlp/lc.c | 16 +- drivers/uwb/wlp/messages.c | 40 ++-- drivers/uwb/wlp/sysfs.c| 46 ++-- drivers/uwb/wlp/wlp-lc.c | 12 +- 27 files changed, 644 insertions(+), 654 deletions(-) -- 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 09/11] pvrusb2-v4l2: Rename dev_info to pdi
There is a macro called dev_info that prints struct device specific
information. Having variables with the same name can be confusing and
prevents conversion of the macro to a function.
Rename the existing dev_info variables to something else in preparation
to converting the dev_info macro to a function.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index cc8ddb2..ba32c91 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -48,7 +48,7 @@ struct pvr2_v4l2_dev {
struct pvr2_v4l2_fh {
struct pvr2_channel channel;
- struct pvr2_v4l2_dev *dev_info;
+ struct pvr2_v4l2_dev *pdi;
enum v4l2_priority prio;
struct pvr2_ioread *rhp;
struct file *file;
@@ -161,7 +161,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
{
struct pvr2_v4l2_fh *fh = file-private_data;
struct pvr2_v4l2 *vp = fh-vhead;
- struct pvr2_v4l2_dev *dev_info = fh-dev_info;
+ struct pvr2_v4l2_dev *pdi = fh-pdi;
struct pvr2_hdw *hdw = fh-channel.mc_head-hdw;
long ret = -EINVAL;
@@ -563,14 +563,14 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_STREAMON:
{
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means
that we're not currently allowed to stream from
this node. */
ret = -EPERM;
break;
}
- ret = pvr2_hdw_set_stream_type(hdw,dev_info-config);
+ ret = pvr2_hdw_set_stream_type(hdw,pdi-config);
if (ret 0) return ret;
ret = pvr2_hdw_set_streaming(hdw,!0);
break;
@@ -578,7 +578,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
case VIDIOC_STREAMOFF:
{
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means
that we're not currently allowed to stream from
this node. */
@@ -1031,7 +1031,7 @@ static int pvr2_v4l2_open(struct file *file)
}
init_waitqueue_head(fhp-wait_data);
- fhp-dev_info = dip;
+ fhp-pdi = dip;
pvr2_trace(PVR2_TRACE_STRUCT,Creating pvr_v4l2_fh id=%p,fhp);
pvr2_channel_init(fhp-channel,vp-channel.mc_head);
@@ -1112,7 +1112,7 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
struct pvr2_hdw *hdw;
if (fh-rhp) return 0;
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means that we're
not currently allowed to stream from this node. */
return -EPERM;
@@ -1121,21 +1121,21 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
/* First read() attempt. Try to claim the stream and start
it... */
if ((ret = pvr2_channel_claim_stream(fh-channel,
-fh-dev_info-stream)) != 0) {
+fh-pdi-stream)) != 0) {
/* Someone else must already have it */
return ret;
}
- fh-rhp = pvr2_channel_create_mpeg_stream(fh-dev_info-stream);
+ fh-rhp = pvr2_channel_create_mpeg_stream(fh-pdi-stream);
if (!fh-rhp) {
pvr2_channel_claim_stream(fh-channel,NULL);
return -ENOMEM;
}
hdw = fh-channel.mc_head-hdw;
- sp = fh-dev_info-stream-stream;
+ sp = fh-pdi-stream-stream;
pvr2_stream_set_callback(sp,(pvr2_stream_callback)pvr2_v4l2_notify,fh);
- pvr2_hdw_set_stream_type(hdw,fh-dev_info-config);
+ pvr2_hdw_set_stream_type(hdw,fh-pdi-config);
if ((ret = pvr2_hdw_set_streaming(hdw,!0)) 0) return ret;
return pvr2_ioread_set_enabled(fh-rhp,!0);
}
--
1.7.0.3.311.g6a6955
--
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
V4L2 and Media controller mini-summit in Helsinki 14.--16. June
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. Hans' original posting is available here: URL:http://www.mail-archive.com/linux-media@vger.kernel.org/msg15526.html The participation to the event is free of charge and open for anyone. However, we do have a limited number of seats but I'm very trustful everyone will be able to fit in. I'd like to ask the participants to sign up by sending me mail telling they want to participate. Best regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Mon Apr 5 19:00:22 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14544:4ee1e97ba6ad git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 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: WARNINGS 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: new V4L control framework
On Monday 05 April 2010 20:11:13 Hans Verkuil wrote: Another option would be to set aside a range of IDs at the end of each control class that could be used as a 'remap' area. For example: the IDs for user class controls go from 0x98-0x98. Of which anything = 0x981000 is a private control (i.e. specific to a driver). We could set aside 0x98f000-0x98 for remapped controls. So if you want to make a subdev's volume control available as a secondary control you can do something like this: v4l2_ctrl_add_ctrl_remap(struct v4l2_ctrl_handler *hdl, struct v4l2_ctrl_info *cinfo, const char *fmt); The framework will pick a new ID from the remap range and add this control with the name created using snprintf(fmt, sz, cinfo-name). Since this control is remapped as a private control it will be seen by old applications as well since they just iterate from V4L2_CID_PRIVATE_BASE, and the framework handles that transparently. It is even possible to do this for all controls from a subdev, e.g.: v4l2_ctrl_add_handler_remap(struct v4l2_ctrl_handler *hdl, struct v4l2_ctrl_handler *add, const char *fmt); Every control in 'add' that already exists in 'hdl' would then be remapped and a new name is generated. I implemented this scheme in this tree: http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw-remap/ I also hacked vivi to use this. After creating a second handler with volume, mute and saturation controls I added this line to merge the two: v4l2_ctrl_add_handler_remap(dev-hdl, dev-hdl2, Secondary %s); The end result is this: $ v4l2-ctl --list-ctrls User Controls brightness (int) : min=0 max=255 step=1 default=127 value=127 flags=slider contrast (int) : min=0 max=255 step=1 default=16 value=16 flags=slider saturation (int) : min=0 max=255 step=1 default=127 value=127 flags=slider hue (int) : min=-128 max=127 step=1 default=0 value=0 flags=slider volume (int) : min=0 max=255 step=1 default=200 value=200 flags=slider mute (bool) : default=1 value=1 integer_test_control (int) : min=-2147483648 max=2147483647 step=1 default=0 value=0 toggle_text_color (bool) : default=0 value=0 press_me (btn) : flags=write-only menu_test_control (menu) : min=0 max=5 default=1 value=1 integer64_test_control (int64): value=0 string_test_control (str) : min=0 max=100 step=2 value='' secondary_volume (int) : min=0 max=128 step=1 default=20 value=20 flags=slider secondary_saturation (int) : min=100 max=200 step=1 default=150 value=150 flags=slider So mute was added unchanged while volume and saturation were remapped automatically. And they showed up in xawtv as well. 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
Possible bug with FusionHDTV7 Dual Express
For some time I have been having problems with VDR seemingly loosing control over one of the two tuners. It seems to be related to the atscepg plugin. It happened quicker after VDR had timer recorded a show. Removing the plugin seemed to stop it but also get no epg data. basicly, which ever tuner vdr was displaying from, the other tuner would seem to stop working. You get no signal. But only vdr needed to be restarted to get the tuner back. One tuner always seemed to go down within 24hrs when using the plugin. It seems to be related to when the plugin used a free tuner to scan epg. I put a second card in, an HVR-1800 which became the 3rd dvb device according to vdr. Same thing kept happening. Always the first or second tuner since no mater which vdr was using, it would always be one of those that was left free. I started vdr with -D 1 -D 2 to force vdr to only use 1 tuner of the dual and the second card. I also use femon to make sure vdr is using dvb1 after changing channels so that the plugin uses the second card for scanning. It has been running for a couple of days and done recordings without loosing a tuner. Since forcing it to use only one tuner of the dual seems to have stopped the problem, it is starting to look like a driver problem with the fusion card. Today I used femon to put vdr on dvb2 so that the plugin uses the fusion to scan epg. In a couple days if the problem still doesn't show, I may swap slot positions of the two cards so vdr use the 1800 without forcing by blocking a tuner. The plugin Author has also been looking into this, but he only recently got a second tuner card working. -- 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 PULL] V4L2 file handles and event interface, take 2
Hi Mauro, Hans Verkuil has provided the patches to support the V4L2 events on ivtv (thanks, Hans!). Those patches are part of this pull request. The documentation has been improved --- v4l2_fh is now clearly marked as optional interface. Rebased, too. Please pull. The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d: Jonathan Corbet (1): V4L/DVB: ov7670: silence some compiler warnings are available in the git repository at: git://gitorious.org/omap3camera/camera-firmware.git v4l-dvb-event Hans Verkuil (4): v4l: add VSYNC and EOS events for use with ivtv. ivtv: support the new events API. v4l spec: document what odd and even fields are. v4l spec: document new events. Sakari Ailus (6): V4L: File handles V4L: File handles: Add documentation V4L: Events: Add new ioctls for events V4L: Events: Add backend V4L: Events: Support event handling in do_ioctl V4L: Events: Add documentation Documentation/DocBook/media-entities.tmpl | 11 + Documentation/DocBook/v4l/dev-event.xml| 31 ++ Documentation/DocBook/v4l/io.xml |8 +- Documentation/DocBook/v4l/v4l2.xml |3 + Documentation/DocBook/v4l/vidioc-dqevent.xml | 131 + .../DocBook/v4l/vidioc-subscribe-event.xml | 133 + Documentation/video4linux/v4l2-framework.txt | 132 + drivers/media/video/Makefile |3 +- drivers/media/video/ivtv/ivtv-driver.h |7 + drivers/media/video/ivtv/ivtv-fileops.c| 53 +++- drivers/media/video/ivtv/ivtv-ioctl.c | 24 ++- drivers/media/video/ivtv/ivtv-irq.c| 15 +- drivers/media/video/ivtv/ivtv-streams.c|5 + drivers/media/video/v4l2-compat-ioctl32.c |3 + drivers/media/video/v4l2-dev.c |4 + drivers/media/video/v4l2-event.c | 289 drivers/media/video/v4l2-fh.c | 79 ++ drivers/media/video/v4l2-ioctl.c | 53 include/linux/videodev2.h | 35 +++ include/media/v4l2-dev.h |5 + include/media/v4l2-event.h | 67 + include/media/v4l2-fh.h| 65 + include/media/v4l2-ioctl.h |7 + 23 files changed, 1141 insertions(+), 22 deletions(-) create mode 100644 Documentation/DocBook/v4l/dev-event.xml create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml create mode 100644 drivers/media/video/v4l2-event.c create mode 100644 drivers/media/video/v4l2-fh.c create mode 100644 include/media/v4l2-event.h create mode 100644 include/media/v4l2-fh.h -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman da...@hardeman.nu wrote: On Thu, Apr 01, 2010 at 09:44:12PM -0400, Jon Smirl wrote: On Thu, Apr 1, 2010 at 1:56 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: This series of 15 patches improves support for IR, as discussed at the What are the goals for the architecture of an in-kernel IR system? thread. It basically adds a raw decoder layer at ir-core, allowing decoders to plug into IR core, and preparing for the addition of a lirc_dev driver that will allow raw IR codes to be sent to userspace. There's no lirc patch in this series. I have also a few other patches from David Härdeman that I'm about to test/review probably later today, but as I prefer to first merge what I have at V4L/DVB tree, before applying them. Has anyone ported the MSMCE driver onto these patches yet? That would be a good check to make sure that rc-core has the necessary API. I still plan to make lots of changes to the rc-core API (I just have to convince Mauro first, but I'll get there). What I have done is to port your port of the msmce driver to the suggested rc-core subsystem I sent you in private a week or so ago, and it works fine (I've bought the hardware and tested it with 20 or so different protocols). The subsystem I suggested is basically what I'm using as inspiration while working with Mauro in improving rc-core so msmce should work well with the end product...but there's still some ground to cover. Porting the msmce driver to rc-core will be high on my list of priorities once I've done some more changes to the API. Very cool. Though note that the latest lirc_mceusb is quite heavily modified from what Jon had initially ported, and I still have a few outstanding enhancements to make, such as auto-detecting xmit mask to eliminate the crude inverted mask list and support for the mce IR keyboard/mouse, though that'll probably be trivial once RC5 and RC6 in-kernel decoders are in place. I'd intended to start with porting the imon driver I'm working on over to this new infra (onboard hardware decoder, should be rather easy to port), and then hop over to the mceusb driver, but if you beat me to it, I've got no problem with you doing it instead. :) Cooler if it works both through LIRC and with an internal protocol decoder. The MSMCE driver in my old patches was very simplified, it removed about half of the code from the LIRC version. Yes, and it was a great help to me at least...thanks :) Yeah, copy that. Good to see we've got some major momentum going now, just need to get off my butt and do some more work on it myself... -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4L/DVB: Use custom I2C probing function mechanism
Hi Mauro, On Mon, 05 Apr 2010 15:26:32 -0300, Mauro Carvalho Chehab wrote: Jean Delvare wrote: Now that i2c-core offers the possibility to provide custom probing function for I2C devices, let's make use of it. Signed-off-by: Jean Delvare kh...@linux-fr.org --- I wasn't too sure where to put the custom probe function: in each driver, in the ir-common module or in the v4l2-common module. I went for the second option as a middle ground, but am ready to discuss it if anyone objects. Please, don't add new things at ir-common module. It basically contains the decoding functions for RC5 and pulse/distance, plus several IR keymaps. With the IR rework I'm doing, this module will go away, after having all the current IR decoders implemented via ir-raw-input binding. The keymaps were already removed from it, on my experimental tree (http://git.linuxtv.org/mchehab/ir.git), and rc5 decoder is already written (but still needs a few fixes). The new ir-core is creating an abstract way to deal with Remote Controllers, meant to be used not only by IR's, but also for other types of RC, like, bluetooth and USB HID. It will also export a raw event interface, for use with lirc. As this is the core of the RC subsystem, a i2c-specific binding method also doesn't seem to belong there. SO, IMO, the better place is to add it as a static inline function at ir-kbd-i2c.h. Ever tried to pass the address of an inline function as another function's parameter? :) -- 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
RFC: exposing controls in sysfs
Hi all, The new control framework makes it very easy to expose controls in sysfs. The way it is implemented now in the framework is that each device node will get a 'controls' subdirectory in sysfs. Below which are all the controls associated with that device node. So different device nodes can have different controls if so desired. The name of each sysfs file is derived from the control name, basically making it lowercase, replacing ' ', '-' and '_' with '_' and skipping any other non- alphanumerical characters. Seems to work well. For numerical controls you can write numbers in decimal, octal or hexadecimal. When you write to a button control it will ignore what you wrote, but still execute the action. It looks like this for ivtv: $ ls /sys/class/video4linux/video1 controls dev device index name power subsystem uevent $ ls /sys/class/video4linux/video1/controls audio_crcchroma_gain spatial_chroma_filter_type video_bitrate_mode audio_emphasis contrast spatial_filter video_encoding audio_encoding hue spatial_filter_mode video_gop_closure audio_layer_ii_bitrate insert_navigation_packets spatial_luma_filter_typevideo_gop_size audio_mute median_chroma_filter_maximum stream_type video_mute audio_sampling_frequency median_chroma_filter_minimum stream_vbi_format video_mute_yuv audio_stereo_modemedian_filter_typetemporal_filter video_peak_bitrate audio_stereo_mode_extension median_luma_filter_maximumtemporal_filter_mode video_temporal_decimation balance median_luma_filter_minimumvideo_aspect volume brightness mute video_b_frames chroma_agc saturationvideo_bitrate The question is, is this sufficient? One of the few drivers that exposes controls in sysfs is pvrusb2. As far as I can tell from the source it will create subdirectories under the device node for each control. Those subdirs have the name ctl_control-name (e.g. ctl_volume), and below that are files exposing all the attributes of that control: name, type, min_val, max_val, def_val, cur_val, custom_val, enum_val and bit_val. Most are clear, but some are a bit more obscure. enum_val is basically a QUERYMENU and returns all menu options. bit_val seems to be used for some non-control values like the TV standard that pvrusb2 also exposes and where bit_val is a bit mask of all the valid bits that can be used. Mike, if you have any additional information, just let us know. My pvrusb2 is in another country at the moment so I can't do any testing. Personally I think that it is overkill to basically expose the whole QUERYCTRL information to sysfs. I see it as an easy and quick way to read and modify controls via a command line. Mike, do you know of anyone actively using that additional information? And which non-control values do you at the moment expose in pvrusb2 through sysfs? Can you perhaps give an ls -R of all the files you create in sysfs for pvrusb2? I am wondering whether some of those should get a place in the framework as well. While I don't think e.g. cropping parameters are useful, things like the current input or tuner frequency can be handy. However, for those to be useful they would have to be wired up internally through the framework. For example, VIDIOC_S_FREQUENCY would have to be hooked up internally to a control. That would ensure that however you access it (ioctl or sysfs) it will both end up in the same s_ctrl function. It will be nice to hear from you what your experience is. Comments? Ideas? Once we commit to something it is there for a long time to come since sysfs is after all a public API (although it seems to be more changable than ioctls). 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: RFC: exposing controls in sysfs
On Monday 05 April 2010 23:47:10 Hans Verkuil wrote: Hi all, The new control framework makes it very easy to expose controls in sysfs. The way it is implemented now in the framework is that each device node will get a 'controls' subdirectory in sysfs. Below which are all the controls associated with that device node. So different device nodes can have different controls if so desired. The name of each sysfs file is derived from the control name, basically making it lowercase, replacing ' ', '-' and '_' with '_' and skipping any other non- alphanumerical characters. Seems to work well. For numerical controls you can write numbers in decimal, octal or hexadecimal. When you write to a button control it will ignore what you wrote, but still execute the action. It looks like this for ivtv: $ ls /sys/class/video4linux/video1 controls dev device index name power subsystem uevent $ ls /sys/class/video4linux/video1/controls audio_crcchroma_gain spatial_chroma_filter_type video_bitrate_mode audio_emphasis contrast spatial_filter video_encoding audio_encoding hue spatial_filter_mode video_gop_closure audio_layer_ii_bitrate insert_navigation_packets spatial_luma_filter_typevideo_gop_size audio_mute median_chroma_filter_maximum stream_type video_mute audio_sampling_frequency median_chroma_filter_minimum stream_vbi_format video_mute_yuv audio_stereo_modemedian_filter_typetemporal_filter video_peak_bitrate audio_stereo_mode_extension median_luma_filter_maximum temporal_filter_modevideo_temporal_decimation balance median_luma_filter_minimumvideo_aspect volume brightness mute video_b_frames chroma_agc saturationvideo_bitrate The question is, is this sufficient? One thing that might be useful is to prefix the name with the control class name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It would groups them better. Or one could make a controls/user and controls/mpeg directory. That might not be such a bad idea actually. One of the few drivers that exposes controls in sysfs is pvrusb2. As far as I can tell from the source it will create subdirectories under the device node for each control. Those subdirs have the name ctl_control-name (e.g. ctl_volume), and below that are files exposing all the attributes of that control: name, type, min_val, max_val, def_val, cur_val, custom_val, enum_val and bit_val. Most are clear, but some are a bit more obscure. enum_val is basically a QUERYMENU and returns all menu options. bit_val seems to be used for some non-control values like the TV standard that pvrusb2 also exposes and where bit_val is a bit mask of all the valid bits that can be used. Mike, if you have any additional information, just let us know. My pvrusb2 is in another country at the moment so I can't do any testing. Personally I think that it is overkill to basically expose the whole QUERYCTRL information to sysfs. I see it as an easy and quick way to read and modify controls via a command line. An in between solution would be to add _type files. So you would have 'hue' and 'hue_type'. 'cat hue_type' would give something like: int 0 255 1 128 0x Hue In other words 'type min max step flags name'. And for menu controls like stream_type (hmm, that would become stream_type_type...) you would get: menu 0 5 1 0 Stream Type MPEG-2 Program Stream MPEG-1 System Stream MPEG-2 DVD-compatible Stream MPEG-1 VCD-compatible Stream MPEG-2 SVCD-compatible Stream Note the empty line to denote the unsupported menu item (transport stream). This would give the same information with just a single extra file. Still not sure whether it is worth it though. Regards, Hans Mike, do you know of anyone actively using that additional information? And which non-control values do you at the moment expose in pvrusb2 through sysfs? Can you perhaps give an ls -R of all the files you create in sysfs for pvrusb2? I am wondering whether some of those should get a place in the framework as well. While I don't think e.g. cropping parameters are useful, things like the current input or tuner frequency can be handy. However, for those to be useful they would have to be wired up internally through the framework. For example, VIDIOC_S_FREQUENCY would have to be hooked up internally to a control. That would ensure that however you access it (ioctl or sysfs) it will both end up in the same s_ctrl function. It will be nice to hear from you what your experience is. Comments? Ideas? Once we commit to something it is there for a long time to come since
[PATCH] saa7134: add support for Avermedia M733A
This change adds support for Avermedia M733A. The original version for
linux 2.6.31 was sent to me from Avermedia, original author is unknown.
I ported it to current kernels, and modified for the two pci ids
supported (1461:4155, 1461:4255).
Signed-off-by: Herton Ronaldo Krzesinski her...@mandriva.com.br
---
Documentation/video4linux/CARDLIST.saa7134 |1 +
drivers/media/IR/ir-keymaps.c | 53 +
drivers/media/video/saa7134/saa7134-cards.c | 57 ++-
drivers/media/video/saa7134/saa7134-input.c |6 +++
drivers/media/video/saa7134/saa7134.h |1 +
include/media/ir-common.h |1 +
6 files changed, 118 insertions(+), 1 deletions(-)
diff --git a/Documentation/video4linux/CARDLIST.saa7134
b/Documentation/video4linux/CARDLIST.saa7134
index bb3d5fa..321d00b 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -176,3 +176,4 @@
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
177 - Hawell HW-404M7
+178 - Avermedia M733A [1461:4155,1461:4255]
diff --git a/drivers/media/IR/ir-keymaps.c b/drivers/media/IR/ir-keymaps.c
index dfc777b..8c8c056 100644
--- a/drivers/media/IR/ir-keymaps.c
+++ b/drivers/media/IR/ir-keymaps.c
@@ -172,6 +172,59 @@ static struct ir_scancode ir_codes_avermedia_m135a[] = {
};
IR_TABLE(avermedia_m135a, IR_TYPE_UNKNOWN, ir_codes_avermedia_m135a);
+/* Herton Ronaldo Krzesinski her...@mandriva.com.br */
+static struct ir_scancode ir_codes_avermedia_m733a[] = {
+ { 0x00, KEY_POWER2 },
+ { 0x2e, KEY_DOT },
+ { 0x01, KEY_MODE },
+
+ { 0x05, KEY_1 },
+ { 0x06, KEY_2 },
+ { 0x07, KEY_3 },
+ { 0x09, KEY_4 },
+ { 0x0a, KEY_5 },
+ { 0x0b, KEY_6 },
+ { 0x0d, KEY_7 },
+ { 0x0e, KEY_8 },
+ { 0x0f, KEY_9 },
+ { 0x11, KEY_0 },
+
+ { 0x13, KEY_RIGHT },
+ { 0x12, KEY_LEFT },
+
+ { 0x17, KEY_SLEEP },
+ { 0x10, KEY_SHUFFLE },
+
+ { 0x43, KEY_CHANNELUP },
+ { 0x42, KEY_CHANNELDOWN },
+ { 0x1f, KEY_VOLUMEUP },
+ { 0x1e, KEY_VOLUMEDOWN },
+ { 0x0c, KEY_ENTER },
+
+ { 0x14, KEY_MUTE },
+ { 0x08, KEY_AUDIO },
+
+ { 0x03, KEY_TEXT },
+ { 0x04, KEY_EPG },
+ { 0x2b, KEY_TV2 },
+
+ { 0x1d, KEY_RED },
+ { 0x1c, KEY_YELLOW },
+ { 0x41, KEY_GREEN },
+ { 0x40, KEY_BLUE },
+
+ { 0x1a, KEY_PLAYPAUSE },
+ { 0x19, KEY_RECORD },
+ { 0x18, KEY_PLAY },
+ { 0x1b, KEY_STOP },
+};
+
+struct ir_scancode_table ir_codes_avermedia_m733a_table = {
+ .scan = ir_codes_avermedia_m733a,
+ .size = ARRAY_SIZE(ir_codes_avermedia_m733a),
+};
+EXPORT_SYMBOL_GPL(ir_codes_avermedia_m733a_table);
+
/* Oldrich Jedlicka oldium@seznam.cz */
static struct ir_scancode ir_codes_avermedia_cardbus[] = {
{ 0x00, KEY_POWER },
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 655068f..bf53270 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -3897,6 +3897,40 @@ struct saa7134_board saa7134_boards[] = {
.gpio = 0x01,
},
},
+ [SAA7134_BOARD_AVERMEDIA_M733A] = {
+ .name = Avermedia PCI M733A,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tuner_config = 0,
+ .gpiomask = 0x02020,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x0020,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = TV,
+ .gpio = 0x01,
+ },
+ },
[SAA7134_BOARD_BEHOLD_401] = {
/* Beholder Intl. Ltd. 2008 */
/*Dmitry Belimov d.beli...@gmail.com */
@@ -5764,7 +5798,19 @@ struct pci_device_id saa7134_pci_tbl[] = {
.subvendor= 0x1461, /* Avermedia Technologies Inc */
.subdevice= 0xf11d,
.driver_data =
Re: RFC: new V4L control framework
Hi Hans, On Sunday 04 April 2010 17:41:51 Hans Verkuil wrote: Hi all, The support in drivers for the V4L2 control API is currently very chaotic. Few if any drivers support the API correctly. Especially the support for the new extended controls is very much hit and miss. Combine that with the requirements for the upcoming embedded devices that will want to use controls much more actively and you end up with a big mess. I've wanted to fix this for a long time and last week I finally had the time. The new framework works like a charm and massively reduces the complexity in drivers when it comes to control handling. And just as importantly, any driver that uses it is fully compliant to the V4L spec. Something that application writers will appreciate. Thanks for working on this. [snip] There is one thing though that needs to be proven first: can uvc use it as well? The UVC driver is unusual in that it can dynamically add controls. The framework should be able to handle this, but it would be great if Laurent can take a good look at it. I really wish I could do it now, but I won't have time to work on this before two weeks. I'm sorry about that. -- Regards, Laurent Pinchart -- 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] Serialization flag example
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote: After looking at the proposed solution, I personally find the suggestion for a serialization flag to be quite ridiculous. As others have mentioned, the mere presence of the flag means that driver writers will gloss over any concurrency issues that might exist in their driver on the mere assumption that specifying the serialization flag will handle it all for them. I happen to agree with this. Proper locking is difficult, but that's not a reason to introduce such a workaround. I'd much rather see proper documentation for driver developers on how to implement locking properly. -- Regards, Laurent Pinchart -- 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: new V4L control framework
On Mon, 2010-04-05 at 11:25 +0200, Hans Verkuil wrote: On Monday 05 April 2010 04:58:02 Andy Walls wrote: On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote: 1. cx18 volume control: av_core subdev has a volume control (which the bridge driver currently reports as it's volume control) and the cs5435 subdev has a volume control. I'd really need them *both* to be controllable by the user. I'd also like them to appear as a single (bridge driver) volume control to the user - as that is what a user would expect. So the bridge driver implements the volume control, but the bridge's s_ctrl operation will in turn control the subdev's volume implementation, right? Yes, I think we're saying the same thing. The bridge only has one analog audio capture going on at a time and that volume is what needs to be controlled with the bridge *driver's* s_ctrl. The actual implementation of volume control for analog audio capture is performed by different subdevs depending on the input source: av_core subdev for tuner audio, or cs5345 subdev for line-in audio. That's no problem. I do need to add a few utility functions to make this easy, though. I realized that I need that anyway when I worked on converting bttv yesterday. Good. :) Of course, once we can create device nodes for sub-devices, then the controls of the cs5435 will show up there as well so the user can have direct access to that volume control. But that's not really for applications, though. That's convenient. But yes you are correct. It is not a control one would expect an end user app to find and use. 2. ivtv volume control for an AverTV M113 card. The CX2584x chip is normally the volume control. However, due to some poor baseband audio noise performance on this card, it is advantagous to adjust the volume control on the WM8739 subdev that feeds I2S audio into the CX2584x chip. Here, I would like a secondary volume control, not an override of the primary. (Here's my old hack: http://linuxtv.org/hg/~awalls/ivtv-avertv-m113/rev/c8f2378a3119 ) Maybe there's a way to use the control clusters to handle some of this. I'm a bit too tired to figure it all out at the moment. Interesting use case. I have several ideas, but I need some time to think about it a bit more. Basically you want to be able to merge-and-remap controls. Or perhaps even allow some sort of control hierarchy. Something. Maybe worst case the user will just have to knwo about the subdev device node specific volume control and fix it with a start-up script or module post-install script. The ideas is really just to crank up the baseband analog audio gain in as early a stage as possible to improve the noise figure. http://en.wikipedia.org/wiki/Friis_formulas_for_noise The WM8739 and CX25841(!) are cascaded on this board, so both sliders could be active at once. However, I suspect the CX25841 volume should be fixed at something less than 0 dB, and the primary volume control remapped to the WM8739 when using line-in. 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] Add support new TV cards
Hi
Add support our new TV cards.
diff -r 4ee1e97ba6ad linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Apr 04 20:58:13
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Apr 06 13:51:11
2010 +1000
@@ -5411,6 +5411,62 @@
.gpio = 0x389c00,
} },
},
+ [SAA7134_BOARD_BEHOLD_H7] = {
+ /* Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com */
+ .name = Beholder BeholdTV H7,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_XC5000,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
+ .ts_type= SAA7134_MPEG_TS_PARALLEL,
+ .inputs = { {
+ .name = name_tv,
+ .vmux = 2,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 9,
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ },
+ },
+ [SAA7134_BOARD_BEHOLD_A7] = {
+ /* Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com */
+ .name = Beholder BeholdTV A7,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_XC5000,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .inputs = { {
+ .name = name_tv,
+ .vmux = 2,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 9,
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ },
+ },
};
@@ -6605,6 +6661,18 @@
.subvendor= PCI_ANY_ID,
.subdevice= PCI_ANY_ID,
.driver_data = SAA7134_BOARD_UNKNOWN,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
+ .subdevice= 0x7190,
+ .driver_data = SAA7134_BOARD_BEHOLD_H7,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
+ .subdevice= 0x7090,
+ .driver_data = SAA7134_BOARD_BEHOLD_A7,
},{
/* --- end of list --- */
}
@@ -6696,6 +6764,8 @@
{
switch (dev-board) {
case SAA7134_BOARD_BEHOLD_X7:
+ case SAA7134_BOARD_BEHOLD_H7:
+ case SAA7134_BOARD_BEHOLD_A7:
if (command == XC5000_TUNER_RESET) {
/* Down and UP pheripherial RESET pin for reset all chips */
saa_writeb(SAA7134_SPECIAL_MODE, 0x00);
@@ -7074,6 +7144,8 @@
case SAA7134_BOARD_BEHOLD_M6_EXTRA:
case SAA7134_BOARD_BEHOLD_H6:
case SAA7134_BOARD_BEHOLD_X7:
+ case SAA7134_BOARD_BEHOLD_H7:
+ case SAA7134_BOARD_BEHOLD_A7:
dev-has_remote = SAA7134_REMOTE_I2C;
break;
case SAA7134_BOARD_AVERMEDIA_A169_B:
diff -r 4ee1e97ba6ad linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Sun Apr 04 20:58:13
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Tue Apr 06 13:51:11
2010 +1000
@@ -1537,6 +1537,15 @@
dev-i2c_adap, behold_x7_tunerconfig);
}
break;
+ case SAA7134_BOARD_BEHOLD_H7:
+ fe0-dvb.frontend = dvb_attach(zl10353_attach,
+ behold_x7_config,
+ dev-i2c_adap);
+ if (fe0-dvb.frontend) {
+ dvb_attach(xc5000_attach, fe0-dvb.frontend,
+ dev-i2c_adap, behold_x7_tunerconfig);
+ }
+ break;
case SAA7134_BOARD_AVERMEDIA_A700_PRO:
case SAA7134_BOARD_AVERMEDIA_A700_HYBRID:
Re: [PATCH 04/15] V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core
Mauro Carvalho Chehab wrote: Andy Walls wrote: I have an RC-5 decoder in cx23885-input.c that isn't as clean as the NEC protocol decoder I developed. The cx23885-input.c RC-5 decoder is not a very explicit state machine however (it is a bit hack-ish). The state machine seems to be working fine with the code, but I think I found the issue: it was expecting 14 bits after the start+toggle bits, instead of a total of 14 bits. I'll fix it. I'll probably end by simplifying it to have only 3 states: inactive, mark-space and trailer. Done. I've re-written the state machine logic. The code is now simpler to understand, require less processing and works properly with RC-5. Instead of generating an intermediate code, like the code in ir-functions, it measures directly the length of each pulse or space event and generate the corresponding bit directly, putting it into a shift register. At the end of the 14 bits reception, the shift register will contain the scancode. When compared with saa7134 original RC5 decoder, this code is much more reliable, since it doesn't propagate the errors, if the frequency is not precisely 36 kHz. I tested here with my device and it is properly recognizing the Hauppauge Grey IR keys. Both NEC and RC-5 decoders can run in parallel. The patch here: http://git.linuxtv.org/mchehab/ir.git?a=commitdiff;h=37b215ea1280a621d652469cd35328a208f8ef77 And the complete code: http://git.linuxtv.org/mchehab/ir.git?a=blob;f=drivers/media/IR/ir-rc5-decoder.c;h=a62277b625a8ed78028e7060a677598eeae03ffe;hb=37b215ea1280a621d652469cd35328a208f8ef77 I'll likely send an email to the ML with the RC patches that are on my experimental tree, to properly document, and merge it at the -git, together with the other pending requests. -- 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 2/2] V4L/DVB: Use custom I2C probing function mechanism
Jean Delvare wrote: Hi Mauro, On Mon, 05 Apr 2010 15:26:32 -0300, Mauro Carvalho Chehab wrote: Jean Delvare wrote: Now that i2c-core offers the possibility to provide custom probing function for I2C devices, let's make use of it. Signed-off-by: Jean Delvare kh...@linux-fr.org --- I wasn't too sure where to put the custom probe function: in each driver, in the ir-common module or in the v4l2-common module. I went for the second option as a middle ground, but am ready to discuss it if anyone objects. Please, don't add new things at ir-common module. It basically contains the decoding functions for RC5 and pulse/distance, plus several IR keymaps. With the IR rework I'm doing, this module will go away, after having all the current IR decoders implemented via ir-raw-input binding. The keymaps were already removed from it, on my experimental tree (http://git.linuxtv.org/mchehab/ir.git), and rc5 decoder is already written (but still needs a few fixes). The new ir-core is creating an abstract way to deal with Remote Controllers, meant to be used not only by IR's, but also for other types of RC, like, bluetooth and USB HID. It will also export a raw event interface, for use with lirc. As this is the core of the RC subsystem, a i2c-specific binding method also doesn't seem to belong there. SO, IMO, the better place is to add it as a static inline function at ir-kbd-i2c.h. Ever tried to pass the address of an inline function as another function's parameter? :) :) Never tried... maybe gcc would to the hard thing, de-inlining it ;) Well, we need to put this code somewhere. Where are the other probing codes? Probably the better is to put them together. -- 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] Serialization flag example
On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote: On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote: After looking at the proposed solution, I personally find the suggestion for a serialization flag to be quite ridiculous. As others have mentioned, the mere presence of the flag means that driver writers will gloss over any concurrency issues that might exist in their driver on the mere assumption that specifying the serialization flag will handle it all for them. I happen to agree with this. Proper locking is difficult, but that's not a reason to introduce such a workaround. I'd much rather see proper documentation for driver developers on how to implement locking properly. I've taken a different approach in another tree: http://linuxtv.org/hg/~hverkuil/v4l-dvb-ser2/ It adds two callbacks to ioctl_ops: pre_hook and post_hook. You can use these to do things like prio checking and taking your own mutex to serialize the ioctl call. This might be a good compromise between convenience and not hiding anything. 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
