RE: Audio Video synchronization for data received from a HDMI receiver chip
On Wednesday, May 18, 2011 06:10:43 Bhupesh SHARMA wrote: Hi, (adding alsa mailing list in cc) On Thursday, May 12, 2011 18:59:33 Charlie X. Liu wrote: Which HDMI receiver chip? Indeed, that's my question as well :-) We use Sil 9135 receiver chip which is provided by Silicon Image. Please see details here: http://www.siliconimage.com/products/product.aspx?pid=109 Anyway, this question comes up regularly. V4L2 provides timestamps for each frame, so that's no problem. But my understanding is that ALSA does not give you timestamps, so if there are processing delays between audio and video, then you have no way of knowing. The obvious solution is to talk to the ALSA people to see if some sort of timestamping is possible, but nobody has done that. I am aware of the time stamping feature provided by V4L2, but I am also not sure whether the same feature is supported by ALSA. I have included alsa-mailing list also in copy of this mail. Let's see if we can get some sort of confirmation on this from them. This is either because everyone that needs it hacks around it instead of trying to really solve it, or because it is never a problem in practice. What should be the proper solution according to you to solve this issue. Do we require a Audio-Video Bridge kind of utility/mechanism? I don't believe so. All you need is reliable time stamping for your audio and video streams. That's enough for userspace to detect AV sync issues. Hi Hans, I have another doubt regarding the framework choice for the entire system that I have, especially the video part of the system. The overall system is similar to the one depicted below: HDMI data -- HDMI receiver chip -- Video Port IP on SoC -- System DDR HDMI data is received from external world (from say a set-up box or dvd player), which is fed to the HDMI receiver chip on-board and then parallel data lines feed this data to a Video Port IP on the SoC which has a DMA master interface and hence can push the data thus received directly on system DDR. Now, I can figure out that there will be two drivers required here: # HDMI receiver chip driver (which is essentially a v4l2 subdev being controller via I2C) # Video Port driver (which is a v4l2 bridge driver) Is my understanding correct? Are there any HDMI receiver subdev driver and video bridge driver already available which I can use for reference? Also will the audio ALSA driver fit as a subdev driver in the entire system? P.S. I use the terminology 'bridge' and 'subdev' as mentioned in 'v4l2-subdev.h' header file. Regards, Bhupesh Regards, Hans Regards, Bhupesh -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Bhupesh SHARMA Sent: Wednesday, May 11, 2011 10:49 PM To: linux-media@vger.kernel.org Cc: Laurent Pinchart; Guennadi Liakhovetski; Hans Verkuil Subject: Audio Video synchronization for data received from a HDMI receiver chip Hi Linux media folks, We are considering putting an advanced HDMI receiver chip on our SoC, to allow reception of HDMI audio and video. The chip receives HDMI data from a host like a set-up box or DVD player. It provides a video data interface and SPDIF/I2S audio data interface. We plan to support the HDMI video using the V4L2 framework and the HDMI audio using ALSA framework. Now, what seems to be intriguing us is how the audio-video synchronization will be maintained? Will a separate bridging entity required to ensure the same or whether this can be left upon a user space application like mplayer or gstreamer. Also is there a existing interface between the V4L2 and ALSA frameworks and the same can be used in our design? Regards, Bhupesh ST Microelectronics -- 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 -- regards Shiraz Hashim -- 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 v4] tea575x: convert to control framework
On Wednesday, May 18, 2011 23:35:22 Ondrej Zary wrote:
Convert tea575x-tuner to use the new V4L2 control framework. Also add
ext_init() callback that can be used by a card driver for additional
initialization right before registering the video device (for SF16-FMR2).
Also embed struct video_device to struct snd_tea575x to simplify the code.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h2011-05-18
23:14:48.0 +0200
@@ -23,8 +23,8 @@
*/
#include linux/videodev2.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
-#include media/v4l2-ioctl.h
#define TEA575X_FMIF 10700
@@ -42,7 +42,8 @@ struct snd_tea575x_ops {
};
struct snd_tea575x {
- struct video_device *vd;/* video device */
+ struct video_device vd; /* video device */
+ bool initialized;
This isn't needed, more about that below.
bool tea5759; /* 5759 chip is present */
bool mute; /* Device is muted? */
bool stereo;/* receiving stereo */
@@ -54,6 +55,8 @@ struct snd_tea575x {
void *private_data;
u8 card[32];
u8 bus_info[32];
+ struct v4l2_ctrl_handler ctrl_handler;
+ void (*ext_init)(struct snd_tea575x *tea);
ext_init should return int to pass back errors.
};
int snd_tea575x_init(struct snd_tea575x *tea);
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c 2011-05-18
23:22:44.0 +0200
@@ -22,11 +22,11 @@
#include asm/io.h
#include linux/delay.h
-#include linux/interrupt.h
#include linux/init.h
#include linux/slab.h
#include linux/version.h
-#include sound/core.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
#include sound/tea575x-tuner.h
MODULE_AUTHOR(Jaroslav Kysela pe...@perex.cz);
@@ -62,17 +62,6 @@ module_param(radio_nr, int, 0);
#define TEA575X_BIT_DUMMY(115) /* buffer */
#define TEA575X_BIT_FREQ_MASK0x7fff
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = Mute,
- .minimum = 0,
- .maximum = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- }
-};
-
/*
* lowlevel part
*/
@@ -266,47 +255,17 @@ static int vidioc_s_audio(struct file *f
return 0;
}
-static int vidioc_queryctrl(struct file *file, void *priv,
- struct v4l2_queryctrl *qc)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(radio_qctrl); i++) {
- if (qc-id qc-id == radio_qctrl[i].id) {
- memcpy(qc, (radio_qctrl[i]),
- sizeof(*qc));
- return 0;
- }
- }
- return -EINVAL;
-}
-
-static int vidioc_g_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
+static int tea575x_s_ctrl(struct v4l2_ctrl *ctrl)
{
- struct snd_tea575x *tea = video_drvdata(file);
+ struct snd_tea575x *tea = container_of(ctrl-handler, struct
snd_tea575x, ctrl_handler);
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value = tea-mute;
+ tea-mute = ctrl-val;
+ snd_tea575x_set_freq(tea);
return 0;
}
- return -EINVAL;
-}
-
-static int vidioc_s_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct snd_tea575x *tea = video_drvdata(file);
- switch (ctrl-id) {
- case V4L2_CID_AUDIO_MUTE:
- if (tea-mute != ctrl-value) {
- tea-mute = ctrl-value;
- snd_tea575x_set_freq(tea);
- }
- return 0;
- }
return -EINVAL;
}
@@ -355,16 +314,17 @@ static const struct v4l2_ioctl_ops tea57
.vidioc_s_input = vidioc_s_input,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
- .vidioc_queryctrl = vidioc_queryctrl,
- .vidioc_g_ctrl = vidioc_g_ctrl,
- .vidioc_s_ctrl = vidioc_s_ctrl,
};
static struct video_device tea575x_radio = {
.name = tea575x-tuner,
.fops = tea575x_fops,
.ioctl_ops = tea575x_ioctl_ops,
- .release= video_device_release,
+ .release= video_device_release_empty,
+};
+
+static const struct v4l2_ctrl_ops tea575x_ctrl_ops = {
+ .s_ctrl = tea575x_s_ctrl,
};
/*
@@ -373,7 +333,6 @@ static struct video_device tea575x_radio
int snd_tea575x_init(struct
Re: Audio Video synchronization for data received from a HDMI receiver chip
On Thursday, May 19, 2011 07:39:32 Bhupesh SHARMA wrote: On Wednesday, May 18, 2011 06:10:43 Bhupesh SHARMA wrote: Hi, (adding alsa mailing list in cc) On Thursday, May 12, 2011 18:59:33 Charlie X. Liu wrote: Which HDMI receiver chip? Indeed, that's my question as well :-) We use Sil 9135 receiver chip which is provided by Silicon Image. Please see details here: http://www.siliconimage.com/products/product.aspx?pid=109 Anyway, this question comes up regularly. V4L2 provides timestamps for each frame, so that's no problem. But my understanding is that ALSA does not give you timestamps, so if there are processing delays between audio and video, then you have no way of knowing. The obvious solution is to talk to the ALSA people to see if some sort of timestamping is possible, but nobody has done that. I am aware of the time stamping feature provided by V4L2, but I am also not sure whether the same feature is supported by ALSA. I have included alsa-mailing list also in copy of this mail. Let's see if we can get some sort of confirmation on this from them. This is either because everyone that needs it hacks around it instead of trying to really solve it, or because it is never a problem in practice. What should be the proper solution according to you to solve this issue. Do we require a Audio-Video Bridge kind of utility/mechanism? I don't believe so. All you need is reliable time stamping for your audio and video streams. That's enough for userspace to detect AV sync issues. Hi Hans, I have another doubt regarding the framework choice for the entire system that I have, especially the video part of the system. The overall system is similar to the one depicted below: HDMI data -- HDMI receiver chip -- Video Port IP on SoC -- System DDR HDMI data is received from external world (from say a set-up box or dvd player), which is fed to the HDMI receiver chip on-board and then parallel data lines feed this data to a Video Port IP on the SoC which has a DMA master interface and hence can push the data thus received directly on system DDR. Now, I can figure out that there will be two drivers required here: # HDMI receiver chip driver (which is essentially a v4l2 subdev being controller via I2C) # Video Port driver (which is a v4l2 bridge driver) Is my understanding correct? Yes. Are there any HDMI receiver subdev driver and video bridge driver already available which I can use for reference? Video bridge drivers are easier: examples are in drivers/media/video/s5p-fimc or in drivers/media/video/davinci. Note that you should use the new videobuf2 framework instead of the older videobuf framework. s5p-fimc is using vb2 already. but the vpif capture and display drivers in the davinci directory do not. With regards to HDMI receivers: these are still under development. One example is here: http://git.linuxtv.org/hverkuil/cisco.git?a=shortlog;h=refs/heads/cobalt This tree contains a driver for the adv7604 HDMI/Graphics receiver. It is fairly simplistic at the moment, our internal driver is developed a lot further but I haven't had the chance yet to update the git tree with our latest code (Cisco is developing this driver). In addition the HDMI API for V4L2 is still under development. It requires some V4L2 core support to be merged first (control events) before we can continue with that. Also will the audio ALSA driver fit as a subdev driver in the entire system? No, although I have heard that the ALSA developers are looking at a subdev-like approach. There are several V4L drivers that support ALSA as a separate driver (cx18 for example). This is usually not a problem. 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
Re: [RFC v4] V4L2 API for flash devices
Sylwester Nawrocki wrote: Hi Sakari, Hi Sylwester, On 05/17/2011 10:34 PM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 05/09/2011 12:11 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 05/07/2011 02:46 PM, Hans Verkuil wrote: On Thursday, May 05, 2011 20:49:21 Sakari Ailus wrote: Hi, This is a fourth proposal for an interface for controlling flash devices on the V4L2/v4l2_subdev APIs. ... 3. Sensor metadata on frames It'd be useful to be able to read back sensor metadata. If the flash is strobed (on sensor hardware) while streaming, it's difficult to know otherwise which frame in the stream has been exposed with flash. I wonder if it would make sense to have a V4L2_BUF_FLAG_FLASH buffer flag? That way userspace can tell if that particular frame was taken with flash. This looks more as a workaround for the problem rather than a good long term solution. It might be tempting to use the buffer flags which seem to be be more or less intended for buffer control. I'd like much more to see a buffer flags to be used to indicate whether an additional plane of (meta)data is carried by the buffer. There seem to be many more parameters, than a single flag indicating whether the frame has been exposed with flash or not, needed to be carried over to user space. But then we might need some standard format of the meta data, perhaps control id/value pairs and possibly a per plane configurable memory type. There are multiple possible approaches for this. For sensors where metadata is register-value pairs, that is, essentially V4L2 control values, I think this should be parsed by the sensor driver. The ISP (camera bridge) driver does receive the data so it'd have to ask for help from the sensor driver. I am inclined to let the ISP drivers parse the data but on the other hand it might be difficult to access same DMA buffers in kernel _and_ user space. This is just about mapping the buffer to both kernel and user spaces. If the ISP has an iommu the kernel mapping might already exist if it comes from vmalloc(). Yes, I know. I was thinking of possibly required different mapping attributes for kernel and user space and the problems on ARM with that. As I replied to Laurent, this is not an issue since the memory wouldn't be mapped to user space. The user space would get the result which has been interpreted by the sensor driver. Also as metadata is supposed to occupy only small part of a frame buffer perhaps only one page or so could be mapped in kernel space. I'm referring here mainly to SMIA++ method of storing metadata. Yes, I agree. In case of sensors I used to work with it wouldn't be necessary to touch the main frame buffers as the metadata is transmitted out of band. This depends on link a little, but on CSI-2 this is a separate channel. In other cases the metadata is part of the frame --- but I don't know anyone using metadata in such a case, so it _might_ be possible to just ignore this use case. Another alternative would be to pass binary blobs to user space and let a library to interpret the data. This might be the way to go at least with some more exotic cases. As discussed previously, using V4L2 control events shouldn't probably be the way to go, but I think it's obvious that this is _somehow_ bound to controls, at least control ids. Also as Sakari indicated some sensors adopt custom meta data formats so maybe we need to introduce standard fourcc like IDs for meta data formats? I am not sure whether it is possible to create common description of an image meta data that fits all H/W. I'm not sure either since I know of only one example. That example, i.e. register-value pairs, should be something that I'd assume _some_ other hardware uses as well, but there could exist also hardware which doesn't. This solution might not work on that hardware. Of course it's hard to find a silver bullet for a hardware we do not know ;) If there is metadata which does not associate to V4L2 controls (or ioctls), either existing or not yet existing, then that probably should be parsed by the driver. On the other hand, I can't think of metadata that wouldn't fall under this right now. :-) Some metadata are arrays of length specific to a given attribute, I wonder how to support that with v4l2 controls ? Is the metadata something which really isn't associated to any V4L2 control? Are we now talking about a sensor which is more complex than a regular raw bayer sensor? I referred to tags defined in EXIF standard, as you may know every tag is basically an array of specific data type. For most tag types the array length is 1 though. Similar problem is solved by the V4L extended string controls API. And yes this kind of tags are mostly produced by more powerful ISPs, with, for instance, 3A or distortion corrections implemented in their firmware. So this is a little bit different situation than a raw
[RFC] Make dvb_net.c optional
Hi, In my setup I am building the DVB code without dvb_net.c, because there is no IP-stack currently in my Linux kernel. Is this worth a separate configuration entry? --HPS From e7fe34933638e882e1ed1eab1761ecd14ef9125e Mon Sep 17 00:00:00 2001 From: Hans Petter Selasky hsela...@c2i.net Date: Thu, 19 May 2011 02:26:33 +0200 Subject: [PATCH] Make dvb_net configurable. --- ../media_tree/drivers/media/dvb/dvb-core/Makefile |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/../media_tree/drivers/media/dvb/dvb-core/Makefile b/../media_tree/drivers/media/dvb/dvb-core/Makefile index 0b51828..8f22bcd 100644 --- a/../media_tree/drivers/media/dvb/dvb-core/Makefile +++ b/../media_tree/drivers/media/dvb/dvb-core/Makefile @@ -2,8 +2,10 @@ # Makefile for the kernel DVB device drivers. # +dvb-net-$(CONFIG_DVB_NET) := dvb_net.o + dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o dvb_filter.o \ dvb_ca_en50221.o dvb_frontend.o \ - dvb_net.o dvb_ringbuffer.o dvb_math.o + $(dvb-net-y) dvb_ringbuffer.o dvb_math.o obj-$(CONFIG_DVB_CORE) += dvb-core.o -- 1.7.1.1
[PATCHES] Various MODULE parameter releated fixes
--HPS
From 0e135fa9cd9cb377bd8930253a547d6d9ae6d01b Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Thu, 19 May 2011 02:46:40 +0200
Subject: [PATCH] Parameter description should be after parameter.
---
../media_tree/drivers/media/video/tda7432.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/../media_tree/drivers/media/video/tda7432.c b/../media_tree/drivers/media/video/tda7432.c
index 3941f95..398b9fb 100644
--- a/../media_tree/drivers/media/video/tda7432.c
+++ b/../media_tree/drivers/media/video/tda7432.c
@@ -50,8 +50,8 @@ static int loudness; /* disable loudness by default */
static int debug; /* insmod parameter */
module_param(debug, int, S_IRUGO | S_IWUSR);
module_param(loudness, int, S_IRUGO);
-MODULE_PARM_DESC(maxvol,Set maximium volume to +20db (0), default is 0db(1));
module_param(maxvol, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(maxvol,Set maximium volume to +20db (0), default is 0db(1));
--
1.7.1.1
From 7191938e7da088ccb5e8bad36e99ca495e53d206 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Thu, 19 May 2011 02:56:48 +0200
Subject: [PATCH] Remove invalid parameter description.
---
../media_tree/drivers/media/dvb/frontends/tda8261.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/../media_tree/drivers/media/dvb/frontends/tda8261.c b/../media_tree/drivers/media/dvb/frontends/tda8261.c
index 1742056..53c7d8f 100644
--- a/../media_tree/drivers/media/dvb/frontends/tda8261.c
+++ b/../media_tree/drivers/media/dvb/frontends/tda8261.c
@@ -224,7 +224,6 @@ exit:
}
EXPORT_SYMBOL(tda8261_attach);
-MODULE_PARM_DESC(verbose, Set verbosity level);
MODULE_AUTHOR(Manu Abraham);
MODULE_DESCRIPTION(TDA8261 8PSK/QPSK Tuner);
--
1.7.1.1
--- cx24116.c.orig 2011-03-20 23:11:40.0 +0100
+++ cx24116.c 2011-03-20 23:12:35.0 +0100
@@ -137,7 +137,7 @@
/* SNR measurements */
static int esno_snr;
module_param(esno_snr, int, 0644);
-MODULE_PARM_DESC(debug, SNR return units, 0=PERCENTAGE 0-100, \
+MODULE_PARM_DESC(esno_snr, SNR return units, 0=PERCENTAGE 0-100, \
1=ESNO(db * 10) (default:0));
enum cmds {
[PATCH 0/3] V4L2 API for flash devices and the adp1653 flash controller driver
Hi, This patchset implements RFC v4 of V4L2 API for flash devices [1], with minor modifications, and adds the adp1653 flash controller driver. This patchset depends on the bitmask controls patch [4]. Changes since v2 [3] of the RFC patchset: - Improved flash control documentation in general. - Faults may change the LED mode to none. This is now documented. - adp1653 is returned to sane after faults are detected. - Proper error handling for adp1653_get_fault() in adp1653_strobe(). - Remove useless function: adp1653_registered() and the corresponding callback. Controls are now initialised in adp1653_probe(). - Improved fault handling in adp1653_init_device(). Changes since v1 [2] of the RFC patchset: - Faults on the flash LED are allowed to make the LED unusable before the faults are read. This is implemented in the adp1653 driver. - Intensities are using standard units; mA for flash / torch and uA for the indicator. Thanks to those who have given their feedback so far in the process! [1] http://www.spinics.net/lists/linux-media/msg32030.html [2] http://www.spinics.net/lists/linux-media/msg32396.html [3] http://www.spinics.net/lists/linux-media/msg32436.html [4] http://www.spinics.net/lists/linux-media/msg31001.html Cheers, -- 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
[PATCH 3/3] adp1653: Add driver for LED flash controller
This patch adds the driver for the adp1653 LED flash controller. This
controller supports a high power led in flash and torch modes and an
indicator light, sometimes also called privacy light.
The adp1653 is used on the Nokia N900.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: Tuukka Toivonen tuukka...@gmail.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: David Cohen daco...@gmail.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |2 +
drivers/media/video/adp1653.c | 481 +
include/media/adp1653.h | 126 +++
4 files changed, 616 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/adp1653.c
create mode 100644 include/media/adp1653.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..c004dbb 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -344,6 +344,13 @@ config VIDEO_TCM825X
This is a driver for the Toshiba TCM825x VGA camera sensor.
It is used for example in Nokia N800.
+config VIDEO_ADP1653
+ tristate ADP1653 flash support
+ depends on I2C VIDEO_V4L2 MEDIA_CONTROLLER
+ ---help---
+ This is a driver for the ADP1653 flash controller. It is used for
+ example in Nokia N900.
+
config VIDEO_SAA7110
tristate Philips SAA7110 video decoder
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..abdf021 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -131,6 +131,8 @@ obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/
+obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
+
obj-$(CONFIG_USB_ZR364XX) += zr364xx.o
obj-$(CONFIG_USB_STKWEBCAM) += stkwebcam.o
diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c
new file mode 100644
index 000..5bd64a2
--- /dev/null
+++ b/drivers/media/video/adp1653.c
@@ -0,0 +1,481 @@
+/*
+ * drivers/media/video/adp1653.c
+ *
+ * Copyright (C) 2008--2011 Nokia Corporation
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * Contributors:
+ * Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ * Tuukka Toivonen tuukka...@gmail.com
+ *
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ * TODO:
+ * - fault interrupt handling
+ * - faster strobe (use i/o pin instead of i2c)
+ * - should ensure that the pin is in some sane state even if not used
+ * - power doesn't need to be ON if all lights are off
+ *
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/version.h
+#include media/adp1653.h
+#include media/v4l2-device.h
+
+#define TIMEOUT_MAX82
+#define TIMEOUT_STEP 54600
+#define TIMEOUT_MIN(TIMEOUT_MAX - ADP1653_REG_CONFIG_TMR_SET_MAX \
+* TIMEOUT_STEP)
+#define TIMEOUT_US_TO_CODE(t) ((TIMEOUT_MAX + (TIMEOUT_STEP / 2) - (t)) \
+/ TIMEOUT_STEP)
+#define TIMEOUT_CODE_TO_US(c) (TIMEOUT_MAX - (c) * TIMEOUT_STEP)
+
+/* Write values into ADP1653 registers. */
+static int adp1653_update_hw(struct adp1653_flash *flash)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(flash-subdev);
+ u8 out_sel;
+ u8 config = 0;
+ int rval;
+
+ out_sel = ADP1653_INDICATOR_INTENSITY_uA_TO_REG(
+ flash-indicator_intensity-val)
+ADP1653_REG_OUT_SEL_ILED_SHIFT;
+
+ switch (flash-led_mode-val) {
+ case V4L2_FLASH_LED_MODE_NONE:
+ break;
+ case V4L2_FLASH_LED_MODE_FLASH:
+ /* Flash mode, light on with strobe, duration from timer */
+ config = ADP1653_REG_CONFIG_TMR_CFG;
+ config |= TIMEOUT_US_TO_CODE(flash-flash_timeout-val)
+ ADP1653_REG_CONFIG_TMR_SET_SHIFT;
+ break;
+ case V4L2_FLASH_LED_MODE_TORCH:
+ /* Torch mode, light immediately on, duration indefinite */
+ out_sel |= ADP1653_FLASH_INTENSITY_mA_TO_REG(
+ flash-torch_intensity-val)
+ADP1653_REG_OUT_SEL_HPLED_SHIFT;
+ break;
+
[PATCH 1/3] v4l: Add a class and a set of controls for flash devices.
From: Sakari Ailus sakari.ai...@iki.fi
Add a control class and a set of controls to support LED and Xenon flash
devices. An example of such a device is the adp1653.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-ctrls.c | 45 ++
include/linux/videodev2.h| 36 ++
2 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..74aae36 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -216,6 +216,17 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
75 useconds,
NULL,
};
+ static const char * const flash_led_mode[] = {
+ Off,
+ Flash,
+ Torch,
+ NULL,
+ };
+ static const char * const flash_strobe_source[] = {
+ Software,
+ External,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -256,6 +267,10 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_FLASH_LED_MODE:
+ return flash_led_mode;
+ case V4L2_CID_FLASH_STROBE_SOURCE:
+ return flash_strobe_source;
default:
return NULL;
}
@@ -389,6 +404,21 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return Tune Antenna Capacitor;
+ /* Flash controls */
+ case V4L2_CID_FLASH_CLASS: return Flash controls;
+ case V4L2_CID_FLASH_LED_MODE: return LED mode;
+ case V4L2_CID_FLASH_STROBE_SOURCE: return Strobe source;
+ case V4L2_CID_FLASH_STROBE: return Strobe;
+ case V4L2_CID_FLASH_STROBE_STOP:return Stop strobe;
+ case V4L2_CID_FLASH_STROBE_STATUS: return Strobe status;
+ case V4L2_CID_FLASH_TIMEOUT:return Strobe timeout;
+ case V4L2_CID_FLASH_INTENSITY: return Intensity, flash mode;
+ case V4L2_CID_FLASH_TORCH_INTENSITY:return Intensity, torch mode;
+ case V4L2_CID_FLASH_INDICATOR_INTENSITY: return Intensity, indicator;
+ case V4L2_CID_FLASH_FAULT: return Faults;
+ case V4L2_CID_FLASH_CHARGE: return Charge;
+ case V4L2_CID_FLASH_READY: return Ready to strobe;
+
default:
return NULL;
}
@@ -423,12 +453,17 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_PILOT_TONE_ENABLED:
case V4L2_CID_ILLUMINATORS_1:
case V4L2_CID_ILLUMINATORS_2:
+ case V4L2_CID_FLASH_STROBE_STATUS:
+ case V4L2_CID_FLASH_CHARGE:
+ case V4L2_CID_FLASH_READY:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
break;
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
+ case V4L2_CID_FLASH_STROBE:
+ case V4L2_CID_FLASH_STROBE_STOP:
*type = V4L2_CTRL_TYPE_BUTTON;
*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
*min = *max = *step = *def = 0;
@@ -452,6 +487,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+ case V4L2_CID_FLASH_LED_MODE:
+ case V4L2_CID_FLASH_STROBE_SOURCE:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
@@ -462,6 +499,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
+ case V4L2_CID_FLASH_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -474,6 +512,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
/* Max is calculated as RGB888 that is 2^24 */
*max = 0xFF;
break;
+ case V4L2_CID_FLASH_FAULT:
+ *type = V4L2_CTRL_TYPE_BITMASK;
+ break;
default:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -519,6 +560,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ZOOM_RELATIVE:
*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
break;
+ case V4L2_CID_FLASH_STROBE_STATUS:
+ case
[PATCH 2/3] v4l: Add flash control documentation
Add documentation for V4L2 flash controls. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/v4l/controls.xml | 275 ++ Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml |7 + 2 files changed, 282 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index a920ee8..77913b7 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -2092,6 +2092,281 @@ manually or automatically if set to zero. Unit, range and step are driver-specif paraFor more details about RDS specification, refer to xref linkend=en50067 / document, from CENELEC./para /section + +section id=flash-controls + titleFlash Control Reference/title + + para + The V4L2 flash controls are intended to provide generic access + to flash controller devices. Flash controller devices are + typically used in digital cameras. + /para + + para + The interface can support both LED and xenon flash devices. As + of writing this, there is no xenon flash driver using this + interface. + /para + + section id=flash-controls-use-cases + titleSupported use cases/title + + section + titleUnsynchronised LED flash (software strobe)/title + + para + Unsynchronised LED flash is controlled directly by the + host as the sensor. The flash must be enabled by the host + before the exposure of the image starts and disabled once + it ends. The host is fully responsible for the timing of + the flash. + /para + + paraExample of such device: Nokia N900./para + /section + + section + titleSynchronised LED flash (hardware strobe)/title + + para + The synchronised LED flash is pre-programmed by the host + (power and timeout) but controlled by the sensor through a + strobe signal from the sensor to the flash. + /para + + para + The sensor controls the flash duration and timing. This + information typically must be made available to the + sensor. + /para + + /section + + section + titleLED flash as torch/title + + para + LED flash may be used as torch in conjunction with another + use case involving camera or individually. + /para + + /section + + /section + + table pgwide=1 frame=none id=flash-control-id + titleFlash Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* / + colspec colname=c2 colwidth=6* / + colspec colname=c3 colwidth=2* / + colspec colname=c4 colwidth=6* / + spanspec namest=c1 nameend=c2 spanname=id / + spanspec namest=c2 nameend=c4 spanname=descr / + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FLASH_CLASS/constant/entry + entryclass/entry + /row + row + entry spanname=descrThe FLASH class descriptor./entry + /row + row + entry spanname=idconstantV4L2_CID_FLASH_LED_MODE/constant/entry + entrymenu/entry + /row + row + entry spanname=descrDefines the mode of the flash LED, + the high-power white LED attached to the flash controller. + Setting this control may not be possible in presence of + some faults. See V4L2_CID_FLASH_FAULT./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_FLASH_LED_MODE_NONE/constant/entry + entryOff./entry + /row + row + entryconstantV4L2_FLASH_LED_MODE_FLASH/constant/entry + entryFlash mode./entry + /row + row + entryconstantV4L2_FLASH_LED_MODE_TORCH/constant/entry + entryTorch mode. See V4L2_CID_FLASH_TORCH_INTENSITY./entry + /row + /tbody + /entrytbl + /row + row + entry spanname=idconstantV4L2_CID_FLASH_STROBE_SOURCE/constant/entry + entrymenu/entry + /row + rowentry spanname=descrDefines the mode of the + flash LED strobe./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_FLASH_STROBE_SOURCE_SOFTWARE/constant/entry + entryThe flash strobe is triggered by
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 18-05-2011 16:46, Sakari Ailus escreveu: Hans Verkuil wrote: Note that many video receivers cannot stall. You can't tell them to wait until the last buffer finished processing. This is different from some/most? sensors. Not even image sensors. They just output the frame data; if the receiver runs out of buffers the data is just lost. And if any part of the frame is lost, there's no use for other parts of it either. But that's something the receiver must handle, i.e. discard the data and increment frame number (field_count in v4l2_buffer). The interfaces used by image sensors, be they parallel or serial, do not provide means to inform the sensor that the receiver has run out of buffer space. These interfaces are just unidirectional. Well, it depends on how the hardware works, really. On most (all?) designs, the IP block responsible to receive data from a sensor (or to transmit data, on an output device) is capable of generating an IRQ to notify the OS that a framebuffer was filled. So, the V4L driver can mark that buffer as finished and remove it from the list of the queued buffers. Although the current API's don't allow to create a new buffer if the list is empty, it may actually make sense to allow kernel to dynamically create a new buffer, warranting that the sensor (or receiver) will never run out of buffers under normal usage. Of course, the maximum number of buffers should be specified, to avoid having an unacceptable delay. On such case, the frame will end by being discarded. It makes sense to provide a way to report userspace if this happens. 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: Audio Video synchronization for data received from a HDMI receiver chip
Hi Hans, I have another doubt regarding the framework choice for the entire system that I have, especially the video part of the system. The overall system is similar to the one depicted below: HDMI data -- HDMI receiver chip -- Video Port IP on SoC -- System DDR HDMI data is received from external world (from say a set-up box or dvd player), which is fed to the HDMI receiver chip on-board and then parallel data lines feed this data to a Video Port IP on the SoC which has a DMA master interface and hence can push the data thus received directly on system DDR. Now, I can figure out that there will be two drivers required here: # HDMI receiver chip driver (which is essentially a v4l2 subdev being controller via I2C) # Video Port driver (which is a v4l2 bridge driver) Is my understanding correct? Yes. Thanks for clarifying this. Are there any HDMI receiver subdev driver and video bridge driver already available which I can use for reference? Video bridge drivers are easier: examples are in drivers/media/video/s5p-fimc or in drivers/media/video/davinci. Note that you should use the new videobuf2 framework instead of the older videobuf framework. s5p-fimc is using vb2 already. but the vpif capture and display drivers in the davinci directory do not. I quickly had a look at the s5p-fimc and davinci approaches, but I found that the video bridge drivers supported in both the Samsung and TI SoCs, support video post-processing operations whereas in our case the Video Port IP performs almost no additional processing and only passes the unpacked RBG raw data received from HDMI bus to system DDR via a DMA master interface. So as such these are no format conversion operations(rgb-to-yuv or vice-versa), image resizing operations (cropping, scaling..) and image quality operations (filtering, distortion removal) available in the H/W block. What should be the correct choice in such a case? With regards to HDMI receivers: these are still under development. One example is here: http://git.linuxtv.org/hverkuil/cisco.git?a=shortlog;h=refs/heads/cobal t This tree contains a driver for the adv7604 HDMI/Graphics receiver. It is fairly simplistic at the moment, our internal driver is developed a lot further but I haven't had the chance yet to update the git tree with our latest code (Cisco is developing this driver). In addition the HDMI API for V4L2 is still under development. It requires some V4L2 core support to be merged first (control events) before we can continue with that. Ok, I will have a look at the git tree. Thanks for sharing the same. Also will the audio ALSA driver fit as a subdev driver in the entire system? No, although I have heard that the ALSA developers are looking at a subdev-like approach. There are several V4L drivers that support ALSA as a separate driver (cx18 for example). This is usually not a problem. Ok, I will have a look at the cx18 driver. Regards, Bhupesh -- 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: Audio Video synchronization for data received from a HDMI receiver chip
Hi Hans, I have another doubt regarding the framework choice for the entire system that I have, especially the video part of the system. The overall system is similar to the one depicted below: HDMI data -- HDMI receiver chip -- Video Port IP on SoC -- System DDR HDMI data is received from external world (from say a set-up box or dvd player), which is fed to the HDMI receiver chip on-board and then parallel data lines feed this data to a Video Port IP on the SoC which has a DMA master interface and hence can push the data thus received directly on system DDR. Now, I can figure out that there will be two drivers required here: # HDMI receiver chip driver (which is essentially a v4l2 subdev being controller via I2C) # Video Port driver (which is a v4l2 bridge driver) Is my understanding correct? Yes. Thanks for clarifying this. Are there any HDMI receiver subdev driver and video bridge driver already available which I can use for reference? Video bridge drivers are easier: examples are in drivers/media/video/s5p-fimc or in drivers/media/video/davinci. Note that you should use the new videobuf2 framework instead of the older videobuf framework. s5p-fimc is using vb2 already. but the vpif capture and display drivers in the davinci directory do not. I quickly had a look at the s5p-fimc and davinci approaches, but I found that the video bridge drivers supported in both the Samsung and TI SoCs, support video post-processing operations whereas in our case the Video Port IP performs almost no additional processing and only passes the unpacked RBG raw data received from HDMI bus to system DDR via a DMA master interface. This is similar to the davinci vpif-capture/vpif-display drivers for the TI dm646x SoCs. Those videoports are also just a DMA engine without video processing. So as such these are no format conversion operations(rgb-to-yuv or vice-versa), image resizing operations (cropping, scaling..) and image quality operations (filtering, distortion removal) available in the H/W block. What should be the correct choice in such a case? vpif-capture/display drivers are identical in that respect. 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
FW: FW: OMAP 3 ISP
Thanks for your quick response :-) Unfortunately, my video source has no additional interfaces. Best Regards, Alex Gershgorin Embedded Software Engineer E-mail: al...@meprolight.com -Original Message- From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: Thursday, May 19, 2011 2:09 PM To: Alex Gershgorin Cc: 'age...@rambler.ru' Subject: Re: FW: OMAP 3 ISP On Thu, May 19, 2011 at 12:08:41PM +0300, Alex Gershgorin wrote: Hi Sakari, Hi Alex, We wish to develop video device and use omap3530. Our video source has an 8-bit raw data, vertical and horizontal signals, and has no i2c bus. I was briefly acquainted with Linux OMAP 3 Image Signal Processor (ISP) and found, that to register video device I need to provide I2C subdevs board information array, but my device does not have i2c information. I'm asking for your support on this issue. Does your image data source have some other kind of control interface, possibly SPI? Please reply to linux-media@vger.kernel.org and cc myself and laurent.pinch...@ideasonboard.com. Regards, -- Sakari Ailus sakari dot ailus at iki dot fi __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.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
AUTO: Ben Ellis is out of the office (returning 05/27/2011)
I am out of the office until 05/27/2011. For urgent matters please contact Peter Hine on 02 6243 8668 or peter.h...@familycourt.gov.au Note: This is an automated response to your message Re: [linux-dvb] Technisat Cablestar HD2 not automatically detected by kernel 2.6.33? sent on 19/5/2011 19:12:37. This is the only notification you will receive while this person is away. ** The information contained in this e-mail (including any attachments) is for the exclusive use of the addressee. If you are not the intended recipient please notify the sender immediately and delete this e-mail. It is noted that legal privilege is not waived because you have read this e-mail. ** -- 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 0/3] V4L2 API for flash devices and the adp1653 flash controller driver
Hi Sakari, On Thursday 19 May 2011 12:41:14 Sakari Ailus wrote: Hi, This patchset implements RFC v4 of V4L2 API for flash devices [1], with minor modifications, and adds the adp1653 flash controller driver. As already answered in private: Acked-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com This patchset depends on the bitmask controls patch [4]. Changes since v2 [3] of the RFC patchset: - Improved flash control documentation in general. - Faults may change the LED mode to none. This is now documented. - adp1653 is returned to sane after faults are detected. - Proper error handling for adp1653_get_fault() in adp1653_strobe(). - Remove useless function: adp1653_registered() and the corresponding callback. Controls are now initialised in adp1653_probe(). - Improved fault handling in adp1653_init_device(). Changes since v1 [2] of the RFC patchset: - Faults on the flash LED are allowed to make the LED unusable before the faults are read. This is implemented in the adp1653 driver. - Intensities are using standard units; mA for flash / torch and uA for the indicator. Thanks to those who have given their feedback so far in the process! [1] http://www.spinics.net/lists/linux-media/msg32030.html [2] http://www.spinics.net/lists/linux-media/msg32396.html [3] http://www.spinics.net/lists/linux-media/msg32436.html [4] http://www.spinics.net/lists/linux-media/msg31001.html -- 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
[RESEND PATCH 1/1] libv4l2: Add plugin support to libv4l
A libv4l2 plugin will sit in between libv4l2 itself and the actual
/dev/video device node a fd refers to. It will be called each time
libv4l2 wants to do an operation (read/write/ioctl) on the actual
/dev/video node in question.
Signed-off-by: Yordan Kamenov ykame...@mm-sol.com
---
lib/include/libv4l2-plugin.h | 36 ++
lib/include/libv4lconvert.h|5 +-
lib/libv4l2/Makefile |6 +-
lib/libv4l2/libv4l2-priv.h | 10 ++
lib/libv4l2/libv4l2.c | 88 ++
lib/libv4l2/v4l2-plugin.c | 158
lib/libv4l2/v4l2convert.c |9 --
lib/libv4lconvert/control/libv4lcontrol-priv.h |4 +
lib/libv4lconvert/control/libv4lcontrol.c | 35 --
lib/libv4lconvert/control/libv4lcontrol.h |5 +-
lib/libv4lconvert/libv4lconvert-priv.h |2 +
lib/libv4lconvert/libv4lconvert.c | 34 --
utils/qv4l2/qv4l2.cpp | 17 +++-
utils/qv4l2/qv4l2.h|1 +
14 files changed, 347 insertions(+), 63 deletions(-)
create mode 100644 lib/include/libv4l2-plugin.h
create mode 100644 lib/libv4l2/v4l2-plugin.c
diff --git a/lib/include/libv4l2-plugin.h b/lib/include/libv4l2-plugin.h
new file mode 100644
index 000..158c0c2
--- /dev/null
+++ b/lib/include/libv4l2-plugin.h
@@ -0,0 +1,36 @@
+/*
+* Copyright (C) 2010 Nokia Corporation multime...@maemo.org
+
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU Lesser General Public License as published by
+* the Free Software Foundation; either version 2.1 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
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+*/
+
+#ifndef __LIBV4L2_PLUGIN_H
+#define __LIBV4L2_PLUGIN_H
+
+#include sys/types.h
+
+/* Structure libv4l2_dev_ops holds the calls from libv4ls to video nodes.
+ They can be normal open/close/ioctl etc. or any of them may be replaced
+ with a callback by a loaded plugin.
+*/
+
+struct libv4l2_dev_ops {
+void * (*init)(int fd);
+void (*close)(void *dev_ops_priv);
+int (*ioctl)(void *dev_ops_priv, int fd, unsigned long int request, void
*arg);
+ssize_t (*read)(void *dev_ops_priv, int fd, void *buffer, size_t n);
+};
+
+#endif
diff --git a/lib/include/libv4lconvert.h b/lib/include/libv4lconvert.h
index 0264290..351142e 100644
--- a/lib/include/libv4lconvert.h
+++ b/lib/include/libv4lconvert.h
@@ -38,6 +38,8 @@
#include linux/videodev2.h
+#include libv4l2-plugin.h
+
#ifdef __cplusplus
extern C {
#endif /* __cplusplus */
@@ -50,7 +52,8 @@ extern C {
struct v4lconvert_data;
-LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd);
+LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd,
+ void *dev_ops_priv, struct libv4l2_dev_ops *dev_ops);
LIBV4L_PUBLIC void v4lconvert_destroy(struct v4lconvert_data *data);
/* When doing flipping / rotating / video-processing, only supported
diff --git a/lib/libv4l2/Makefile b/lib/libv4l2/Makefile
index d78632f..f8b3714 100644
--- a/lib/libv4l2/Makefile
+++ b/lib/libv4l2/Makefile
@@ -1,12 +1,12 @@
override CPPFLAGS += -I../include -fvisibility=hidden
-LIBS_libv4l2 = -lpthread
+LIBS_libv4l2 = -lpthread -ldl
-V4L2_OBJS = libv4l2.o log.o
+V4L2_OBJS = libv4l2.o v4l2-plugin.o log.o
V4L2CONVERT = v4l2convert.so
V4L2CONVERT_O = v4l2convert.o libv4l2.so
TARGETS = $(V4L2_LIB) libv4l2.pc
-INCLUDES = ../include/libv4l2.h
+INCLUDES = ../include/libv4l2.h ../include/libv4l2-plugin.h
ifeq ($(LINKTYPE),static)
V4L2_LIB = libv4l2.a
diff --git a/lib/libv4l2/libv4l2-priv.h b/lib/libv4l2/libv4l2-priv.h
index 46d6103..d06a508 100644
--- a/lib/libv4l2/libv4l2-priv.h
+++ b/lib/libv4l2/libv4l2-priv.h
@@ -85,8 +85,18 @@ struct v4l2_dev_info {
/* buffer when doing conversion and using read() for read() */
int readbuf_size;
unsigned char *readbuf;
+ struct libv4l2_dev_ops *dev_ops;
+ /* plugin info */
+ void *plugin_library;
+ void *dev_ops_priv;
};
+void v4l2_plugin_init(int fd, void **plugin_lib_ret, void **plugin_priv_ret,
+ struct libv4l2_dev_ops **dev_ops_ret);
+void v4l2_plugin_cleanup(void *plugin_priv, void *plugin_lib,
+ struct libv4l2_dev_ops *dev_ops);
+
+
/* From log.c */
void v4l2_log_ioctl(unsigned long int
[libv4l-mcplugin PATCH 0/3] Media controller plugin for libv4l2
Hi, This is the Media Controller plugin for libv4l. It uses libv4l2 plugin support which is accepted by Hans De Goede, but not yet included in mainline libv4l2: http://www.spinics.net/lists/linux-media/msg32017.html The plugin allows a traditional v4l2 applications to work with Media Controller framework. The plugin is loaded when application opens /dev/video0 and it configures the media controller and then all ioctl's by the applicatin are handled by the plugin. The plugin implements init, close and ioctl callbacks. The init callback checks it's input file descriptor and if it coresponds to /dev/video0, then the media controller is initialized and appropriate pipeline is created. The close callback deinitializes the pipeline, and closes the media device. The ioctl callback is responsible to handle ioctl calls from application by using the media controller pipeline. The plugin uses media-ctl library for media controller operations: http://git.ideasonboard.org/?p=media-ctl.git;a=summary The plugin is divided in three separate patches: * Media Controller pipelines initialization, configuration and destruction * v4l operations - uses some functionality from the first one * Plugin interface operations (init, close and ioctl) - uses functionality from first two Yordan Kamenov (3): Add files for media controller pipelines Add files for v4l operations Add libv4l2 media controller plugin interface files -- 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
[libv4l-mcplugin PATCH 1/3] Add files for media controller pipelines
Add Makefile.
Add files for Media Controller pipelines initialization, configuration and
destruction.
Add file for list operations.
Add config file.
Signed-off-by: Yordan Kamenov ykame...@mm-sol.com
---
Makefile | 30 ++
omap3-mc.conf | 82 +
paths.c | 959 +
paths.h | 64
sl_list.h | 65
5 files changed, 1200 insertions(+), 0 deletions(-)
create mode 100644 Makefile
create mode 100644 omap3-mc.conf
create mode 100644 paths.c
create mode 100644 paths.h
create mode 100644 sl_list.h
diff --git a/Makefile b/Makefile
new file mode 100644
index 000..2b3b375
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,30 @@
+ARCH ?= arm
+KDIR ?= /usr/src/linux
+LIBV4LINCDIR ?= ../../v4l-utils/lib/include/
+LIBMEDIACTLDIR ?= /usr/local/lib
+CONF_INST_DIR := $(DESTDIR)/etc/libv4l2plugins
+PLUGIN_INST_DIR := $(DESTDIR)/usr/lib/libv4l/plugins
+
+KINC := -I$(KDIR)/include -I$(KDIR)/arch/$(ARCH)/include
+INC := -I$(LIBV4LINCDIR) $(KINC)
+CC := $(CROSS_COMPILE)gcc
+
+LDFLAGS += -L$(LIBMEDIACTLDIR) -lmediactl
+
+CFLAGS += -O2 -Wall -fpic -I. $(INC)
+OBJS = libv4l2plugin-omap3mc.o paths.o operations.o
+
+all: libv4l2plugin-omap3mc.so
+
+libv4l2plugin-omap3mc.so: $(OBJS)
+ $(CC) $(CFLAGS) -shared $(LDFLAGS) -o libv4l2plugin-omap3mc.so $(OBJS)
+clean:
+ rm -f $(OBJS) libv4l2plugin-omap3mc.so
+
+install: libv4l2plugin-omap3mc.so
+ test -z $(CONF_INST_DIR) || mkdir -p $(CONF_INST_DIR)
+ install -m 666 omap3-mc.conf $(CONF_INST_DIR)
+ test -z $(PLUGIN_INST_DIR) || mkdir -p $(PLUGIN_INST_DIR)
+ install -m 755 libv4l2plugin-omap3mc.so $(PLUGIN_INST_DIR)
+
+.PHONY: clean all
diff --git a/omap3-mc.conf b/omap3-mc.conf
new file mode 100644
index 000..3b7947c
--- /dev/null
+++ b/omap3-mc.conf
@@ -0,0 +1,82 @@
+# Configuration file for media controller plugin for libv4l
+#
+#
+# Format:
+#
+# [primary|secondary]_path
+# list of subdevice names
+# end
+#
+# [primary|secondary]_in_pixfmt
+# list of formats supported by input device
+# end
+#
+# [primary|secondary]_out_pixfmt
+# list of formats supported by output device
+# end
+#
+#
+#
+# Sensors:
+# jt8ev1, smiapp-001, smiapp-002, smiapp-003, smiapp-004, tcm8500md,
vw6558
+#
+# Subdevices:
+# OMAP3 ISP CSI2a
+# OMAP3 ISP CSI2a output
+# OMAP3 ISP CCP2
+# OMAP3 ISP CCP2 input
+# OMAP3 ISP CCDC
+# OMAP3 ISP preview
+# OMAP3 ISP preview output
+# OMAP3 ISP resizer input
+# OMAP3 ISP resizer
+# OMAP3 ISP resizer output
+#
+#
+# Formats:
+# BAYER8_SBGGR, BAYER8_SGBRG, BAYER8_SGRBG, BAYER10_SGRBG, BAYER10_SRGGB,
+# BAYER10_SBGGR, BAYER10_SGBRG, BAYER10DPCM8_SGRBG, YUYV, UYVY
+#
+#
+
+
+
+primary_path
+jt8ev1
+OMAP3 ISP CSI2a
+OMAP3 ISP CCDC
+OMAP3 ISP preview
+OMAP3 ISP resizer
+OMAP3 ISP resizer output
+end
+
+primary_in_pixfmt
+BAYER10DPCM8_SGRBG
+BAYER10_SGRBG
+end
+
+primary_out_pixfmt
+UYVY
+end
+
+
+
+secondary_path
+vw6558
+OMAP3 ISP CCP2
+OMAP3 ISP CCDC
+OMAP3 ISP preview
+OMAP3 ISP resizer
+OMAP3 ISP resizer output
+end
+
+secondary_in_pixfmt
+BAYER10DPCM8_SGRBG
+BAYER10_SGRBG
+end
+
+secondary_out_pixfmt
+UYVY
+end
+
+
diff --git a/paths.c b/paths.c
new file mode 100644
index 000..bbc6cfd
--- /dev/null
+++ b/paths.c
@@ -0,0 +1,959 @@
+/*
+ * Copyright (C) 2011 Nokia Corporation
+ *
+ * Contact: Yordan Kamenov ykame...@mm-sol.com
+ *
+ * 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.,
+ */
+
+#include unistd.h
+#include sys/syscall.h
+#include stdlib.h
+#include errno.h
+#include fcntl.h
+#include string.h
+#include stddef.h
+#include ctype.h
+#include string.h
+
+#include linux/v4l2-subdev.h
+
+#include sl_list.h
+#include paths.h
+
+#define CONFIG_FILE /etc/libv4l2plugins/omap3-mc.conf
+
+#define LINESIZE(256)
+#define CHOMP(x)\
+do {\
+char *p;\
+int sz;\
+p = (x);\
+sz = strlen(p);\
+p += sz - 1;\
+if (sz) \
+while (isspace(*p)) *p-- = 0; \
+} while (0)
+
+/* Sections in configuration file */
+enum mc_plugin_config_sections {
+ CONFIG_SECTION_NONE,
[libv4l-mcplugin PATCH 2/3] Add files for v4l operations
Add files with implementation of v4l ioctls.
Signed-off-by: Yordan Kamenov ykame...@mm-sol.com
---
operations.c | 611 ++
operations.h | 44 +
2 files changed, 655 insertions(+), 0 deletions(-)
create mode 100644 operations.c
create mode 100644 operations.h
diff --git a/operations.c b/operations.c
new file mode 100644
index 000..307785f
--- /dev/null
+++ b/operations.c
@@ -0,0 +1,611 @@
+/*
+ * Copyright (C) 2011 Nokia Corporation
+ *
+ * Contact: Yordan Kamenov ykame...@mm-sol.com
+ *
+ * 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.,
+ */
+
+#include stdarg.h
+#include unistd.h
+#include sys/syscall.h
+#include stdlib.h
+#include errno.h
+#include string.h
+#include stddef.h
+
+#include linux/v4l2-subdev.h
+
+#include sl_list.h
+#include operations.h
+#include paths.h
+
+#define CHECK_DST_SUBMODULE(dst_sm, error_msg) {\
+ if ((dst_sm) == NULL) {\
+ MC_PLUGIN_PRINTF(error_msg);\
+ errno = EBADF;\
+ return -1;\
+ }\
+}
+
+int mc_vidioc_streamon(struct omap3mcplugin *plugin, unsigned long int
request, ...)
+{
+ int ret = -1;
+ enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ struct sub_module *dst_sub_module = NULL;
+
+ if (plugin-path)
+ dst_sub_module = path_destination_submodule(plugin-path);
+
+ CHECK_DST_SUBMODULE(dst_sub_module, streamon failed\n);
+
+ ret = SYS_IOCTL(dst_sub_module-entity-fd, VIDIOC_STREAMON, type);
+ if (ret) {
+ int saved_err = errno;
+ MC_PLUGIN_PRINTF(streamon: %s\n, strerror(errno));
+ errno = saved_err;
+ }
+
+ return ret;
+}
+
+int mc_vidioc_streamoff(struct omap3mcplugin *plugin, unsigned long int
request, ...)
+{
+ int ret = -1;
+ enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ struct sub_module *dst_sub_module = NULL;
+
+ if (plugin-path)
+ dst_sub_module = path_destination_submodule(plugin-path);
+
+ CHECK_DST_SUBMODULE(dst_sub_module, streamoff failed\n);
+
+ ret = SYS_IOCTL(dst_sub_module-entity-fd, VIDIOC_STREAMOFF, type);
+ if (ret) {
+ int saved_err = errno;
+ MC_PLUGIN_PRINTF(streamoff: %s\n, strerror(errno));
+ errno = saved_err;
+ }
+
+ return ret;
+}
+
+int mc_vidioc_s_fmt(struct omap3mcplugin *plugin, unsigned long int request,
...)
+{
+ int pix_count, res_count, found = 0, ret = -1;
+ enum mc_plugin_pixelformat src_pixfmt, dst_pixfmt, temp_pixfmt;
+ struct v4l2_rect src_res, dst_res;
+ const int max_rect = 10;
+ struct v4l2_rect res[max_rect];
+ struct v4l2_format *arg;
+ va_list ap;
+ enum mc_plugin_pixelformat pixfmt;
+
+ va_start(ap, request);
+ arg = va_arg(ap, struct v4l2_format *);
+ va_end(ap);
+
+ pixfmt = pixel_v4l_to_mc_plugin(arg-fmt.pix.pixelformat);
+
+ /* Check if destionation format is supported from pipeline */
+ for (pix_count = 0;
+MC_PLUGIN_PIX_FMT_INVALID !=
plugin-path-pipe-out_pixfmt[pix_count];
+pix_count++)
+ if (pixfmt == plugin-path-pipe-out_pixfmt[pix_count]) {
+ dst_pixfmt = pixfmt;
+ ret = 0;
+ break;
+ }
+
+ if (ret 0) {
+ MC_PLUGIN_PRINTF(Destination format not supported\n);
+ errno = EINVAL;
+ return ret;
+ }
+
+ for (pix_count = 0;
+MC_PLUGIN_PIX_FMT_INVALID !=
plugin-path-pipe-in_pixfmt[pix_count];
+pix_count++) {
+
+ memset(res, 0x0, sizeof(res));
+ src_pixfmt = plugin-path-pipe-in_pixfmt[pix_count];
+ temp_pixfmt = src_pixfmt;
+
+ ret = path_enum_src_framesizes(plugin, src_pixfmt, res,
max_rect);
+
+ /* Find Best capture resolution */
+ for (res_count = 0; res_count max_rect; res_count++) {
+
+ src_res = res[res_count];
+ dst_res.width = arg-fmt.pix.width;
+ dst_res.height = arg-fmt.pix.height;
+
+ /* If width and height are not valid we reach end of
resolutions */
+ if
[libv4l-mcplugin PATCH 3/3] Add libv4l2 media controller plugin interface files
Add interface functions init(), close() and ioctl(), called by libv4l2.
Signed-off-by: Yordan Kamenov ykame...@mm-sol.com
---
libv4l2plugin-omap3mc.c | 241 +++
libv4l2plugin-omap3mc.h | 91 ++
2 files changed, 332 insertions(+), 0 deletions(-)
create mode 100644 libv4l2plugin-omap3mc.c
create mode 100644 libv4l2plugin-omap3mc.h
diff --git a/libv4l2plugin-omap3mc.c b/libv4l2plugin-omap3mc.c
new file mode 100644
index 000..e5b5ef0
--- /dev/null
+++ b/libv4l2plugin-omap3mc.c
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2011 Nokia Corporation
+ *
+ * Contact: Yordan Kamenov ykame...@mm-sol.com
+ *
+ * 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.,
+ */
+
+#include unistd.h
+#include sys/syscall.h
+#include stdarg.h
+#include stdlib.h
+#include string.h
+#include errno.h
+#include glob.h
+#include linux/videodev2.h
+#include mediactl/media.h
+
+#include libv4l2-plugin.h
+#include libv4l2plugin-omap3mc.h
+#include paths.h
+#include operations.h
+
+#if __GNUC__ = 4
+#define PLUGIN_PUBLIC __attribute__ ((visibility(default)))
+#define PLUGIN_HIDDEN __attribute__ ((visibility(hidden)))
+#else
+#define PLUGIN_PUBLIC
+#define PLUGIN_HIDDEN
+#endif
+
+/* Check if /dev/media0 is already open*/
+int media_in_use()
+{
+ int glob_ret, file, ret = 0;
+ glob_t globbuf;
+ ssize_t link_len;
+ char file_name[16];
+
+ glob_ret = glob(/proc/self/fd/*, 0, NULL, globbuf);
+
+ if (glob_ret == GLOB_NOSPACE)
+ return ret;
+
+ if (glob_ret == GLOB_ABORTED || glob_ret == GLOB_NOMATCH)
+ goto leave;
+
+ for (file = 0; file globbuf.gl_pathc; file++) {
+ link_len = readlink(globbuf.gl_pathv[file],
+ file_name, strlen(MEDIA_DEVICE));
+ if (link_len == strlen(MEDIA_DEVICE))
+ file_name[link_len] = '\0';
+ else
+ continue;
+
+ if (!strncmp(file_name, MEDIA_DEVICE, strlen(MEDIA_DEVICE))) {
+ ret = 1;
+ break;
+ }
+ }
+
+leave:
+ globfree(globbuf);
+
+ return ret;
+}
+
+PLUGIN_HIDDEN void * omap3mc_init(int fd)
+{
+ int ret = -1, primary;
+ struct omap3mcplugin *plugin;
+ const struct capture_pipeline *pipe = NULL;
+ struct sub_module *dst_sub_module = NULL;
+ char link_path[20];
+ ssize_t link_len;
+ char file[VIDEO_NODE_LENGTH + 1];
+
+ /* Get filename from fd */
+ sprintf(link_path, /proc/self/fd/%d, fd);
+ link_len = readlink(link_path, file, VIDEO_NODE_LENGTH);
+ if (link_len == VIDEO_NODE_LENGTH)
+ link_path[link_len] = '\0';
+ else
+ return NULL;
+
+ /* FIXME: What we do if the application is aware of video nodes
+ and tries to open() real /dev/video0 (CSI2 capture) */
+ if (strncmp(file, VIDEO_PRIMARY, strlen(VIDEO_PRIMARY)) == 0)
+ primary = 1;
+ else if (strncmp(file, VIDEO_SECONDARY, strlen(VIDEO_SECONDARY)) == 0)
+ primary = 0;
+ else
+ return NULL;
+
+ if (media_in_use())
+ return NULL;
+
+ plugin = calloc(1, sizeof(*plugin));
+ if (plugin == NULL)
+ return NULL;
+
+ plugin-media = media_open(MEDIA_DEVICE, 1);
+ if (plugin-media == NULL) {
+ free(plugin);
+ return NULL;
+ }
+
+ pipe = pipe_sensor_yuv(primary);
+
+ if (pipe)
+ plugin-path = path_allocate(plugin-media, pipe);
+
+ if (plugin-path)
+ dst_sub_module = path_destination_submodule(plugin-path);
+
+ if (dst_sub_module)
+ ret = path_power_on(plugin-path, fd);
+
+ if (ret == 0)
+ ret = path_connect_entities(plugin-media, plugin-path);
+
+ plugin-fd = dst_sub_module-entity-fd;
+
+ if (ret != 0) {
+ path_disconnect_entities(plugin-media, plugin-path);
+ path_power_off(plugin-path);
+
+ media_close(plugin-media);
+ free(plugin);
+ plugin = NULL;
+ }
+
+ return plugin;
+}
+
+PLUGIN_HIDDEN void omap3mc_close(void *dev_ops_priv)
+{
+ struct omap3mcplugin *plugin;
+
+ if
RE: FW: OMAP 3 ISP
Thanks Laurent, My video source is not the video camera and performs many other functions. For this purpose I have RS232 port. As for the video, it runs continuously and is not subject to control except for the power supply. Regards, Alex Gershgorin Can the video source be controlled at all, or is it always running? If it can be controlled, how do you control it? Regards, Laurent Pinchart -Original Message- From: Alex Gershgorin Sent: Thursday, May 19, 2011 2:36 PM To: 'linux-media@vger.kernel.org' Cc: 'sakari.ai...@iki.fi'; 'laurent.pinch...@ideasonboard.com'; 'age...@rambler.ru' Subject: FW: FW: OMAP 3 ISP Thanks for your quick response :-) Unfortunately, my video source has no additional interfaces. Best Regards, Alex Gershgorin Embedded Software Engineer E-mail: al...@meprolight.com -Original Message- From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: Thursday, May 19, 2011 2:09 PM To: Alex Gershgorin Cc: 'age...@rambler.ru' Subject: Re: FW: OMAP 3 ISP On Thu, May 19, 2011 at 12:08:41PM +0300, Alex Gershgorin wrote: Hi Sakari, Hi Alex, We wish to develop video device and use omap3530. Our video source has an 8-bit raw data, vertical and horizontal signals, and has no i2c bus. I was briefly acquainted with Linux OMAP 3 Image Signal Processor (ISP) and found, that to register video device I need to provide I2C subdevs board information array, but my device does not have i2c information. I'm asking for your support on this issue. Does your image data source have some other kind of control interface, possibly SPI? Please reply to linux-media@vger.kernel.org and cc myself and laurent.pinch...@ideasonboard.com. Regards, -- Sakari Ailus sakari dot ailus at iki dot fi __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.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: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent
On 05/18/2011 09:16 PM, Tomer Barletz wrote: On Tue, May 17, 2011 at 8:46 AM, Brice DUBOST bra...@braice.net wrote: On 18/01/2011 15:42, Tomer Barletz wrote: Attached a patch for a bug in the lookup_callback function, were in case of a non-existent resource, the connected_resource_id is not initialized and then used in the open_session_response call of the session layer. Hello Can you explain what kind of bug it fixes ? Thanks The standard states that in case the module can't provide the requested resource , it should reply with the same resource id - this is the only line that was added. Also, since the caller to this function might use the variable returned, this variable must be initialized. The attached patch solves both bugs. Can you please resend the patch inline with a proper signed-off-by line, in order to get it tracked by patchwork.kernel.org? Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: OMAP 3 ISP
Hi Alex, On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote: Thanks Laurent, My video source is not the video camera and performs many other functions. For this purpose I have RS232 port. As for the video, it runs continuously and is not subject to control except for the power supply. As a quick hack, you can create an I2C driver for your video source that doesn't access the device and just returns fixed format and frame size. The correct fix is to implement support for platform subdevs in the V4L2 core. -- 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: [PATCH 0/2] V4L: Extended crop/compose API
Hi Hans, On Wednesday 18 May 2011 14:31:59 Hans Verkuil wrote: On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote: On 05/16/2011 09:21 AM, Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote: On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote: [snip] ... * resolution of an image combined with support for VIDIOC_S_MULTISELECTION allows to pass a triple format/crop/compose sizes in a single ioctl I don't believe S_MULTISELECTION will solve anything. Specific use-cases perhaps, but not the general problem of setting up a pipeline. I feel another brainstorm session coming to solve that. We never came to a solution for it in Warsaw. Pipelines are configured on subdev nodes, not on video nodes, so I'm also unsure whether multiselection support would really be useful. If we decide to implement multiselection support, we might as well use that only. We would need a multiselection target bitmask, so selection targets should all be 32. Thinking some more about it, does it make sense to set both crop and compose on a single video device node (not talking about mem-to-mem, where you use the type to multiplex input/output devices on the same node) ? If so, what would the use cases be ? I can't think of any, one either use crop or compose. I can: you crop in the video receiver and compose it into a larger buffer. Actually quite a desirable feature. Composing into a buffer can be achieved by Should all devices support the selection API, or only the simple ones that don't expose a user-configurable pipeline to userspace through the MC API ? The proposed API looks good to me, but before acking it I'd like to clarify how (if at all) this will interact with subdev pad-level configuration on devices that support that. My current feeling is that video device nodes for such devices should only be used for video streaming. All parameters should be configured directly on the subdevs. Application might still need to call S_FMT in order to be able to allocate buffers though. I'm not sure whether moving all configuration to subdev API for medium complexity devices which well might have exposed core functionality through standard V4L2 device node API and still use MC API for pipeline reconfiguration (in terms of linking entities with each other) is the way to go. One thing we haven't defined is what a medium complexity device is. I believe it should be defined in terms of the hardware pipeline, or in terms of a virtual pipeline that the hardware can map to. When that will be done it shouldn't be too difficult to unambiguously define how the V4L2 ioctls map to actions on that pipeline. In order to support existing applications SoC-specific libraries would have to be used in addition to a MC driver ? Leaving ourselves without support for default configuration that would work with old V4L2 device node API (in connection with common libv4l library) ? I thought that weren't the prerequisites when designing the MC API. I'm afraid we'll end up with two distinct APIs in Video4Linux and thus two sets of drivers and applications that will not work with one another. Indeed. The original requirement was (and is!) that the default video node must be usable by standard apps, either through the driver or through libv4l. And I'm still happy with that requirement :-) The OMAP3 ISP libv4l plugin is not finished yet, but we're working on it. It is a missing piece in the MC how to mark default nodes. We also need to clearly define which ioctls are optional for non-default nodes. -- 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: [PATCH 0/2] V4L: Extended crop/compose API
On Wednesday 18 May 2011 15:03:13 Sylwester Nawrocki wrote: On 05/18/2011 02:31 PM, Hans Verkuil wrote: On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote: On 05/16/2011 09:21 AM, Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: Thinking some more about it, does it make sense to set both crop and compose on a single video device node (not talking about mem-to-mem, where you use the type to multiplex input/output devices on the same node) ? If so, what would the use cases be ? I can't think of any, one either use crop or compose. I can: you crop in the video receiver and compose it into a larger buffer. Actually quite a desirable feature. Yes, right. Don't know why I imagined something different. And we need it in Samsung capture capture interfaces as well. The H/W is capable of cropping and composing with camera interface as a data source similarly as it is done with memory buffers. The same result could be achieved by adding an offset to the buffer address and setting the bytesperline field accordingly, but that would only work with userptr buffers. As we're working on an API to share buffers between subsystems, I agree that composing into a larger buffer is desirable and shouldn't be implemented using offset/stride. -- 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: FW: OMAP 3 ISP
On 05/19/2011 03:02 PM, Laurent Pinchart wrote: Hi Alex, On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote: Thanks Laurent, My video source is not the video camera and performs many other functions. For this purpose I have RS232 port. As for the video, it runs continuously and is not subject to control except for the power supply. As a quick hack, you can create an I2C driver for your video source that doesn't access the device and just returns fixed format and frame size. The correct fix is to implement support for platform subdevs in the V4L2 core. I recently implemented support for platform V4L2 subdevs. Now that it sounds like others would be interested in this, I will try to polish it up and submit the patch for review in the next week or so. -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: FW: OMAP 3 ISP
Hi Michael,
On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
Thanks Laurent,
My video source is not the video camera and performs many other
functions. For this purpose I have RS232 port.
As for the video, it runs continuously and is not subject to control
except for the power supply.
As a quick hack, you can create an I2C driver for your video source that
doesn't access the device and just returns fixed format and frame size.
The correct fix is to implement support for platform subdevs in the V4L2
core.
I recently implemented support for platform V4L2 subdevs. Now that it
sounds like others would be interested in this, I will try to polish it
up and submit the patch for review in the next week or so.
Great. This has been discussed during the V4L meeting in Warsaw, here are a
couple of pointers, to make sure we're going in the same direction.
Bridge drivers should not care whether the subdev sits on an I2C, SPI,
platform or other bus. To achieve that, an abstraction layer must be provided
by the V4L2 core. Here's what I got in one of my trees:
/* V4L2 core */
struct v4l2_subdev_i2c_board_info {
struct i2c_board_info *board_info;
int i2c_adapter_id;
};
enum v4l2_subdev_bus_type {
V4L2_SUBDEV_BUS_TYPE_NONE,
V4L2_SUBDEV_BUS_TYPE_I2C,
V4L2_SUBDEV_BUS_TYPE_SPI,
};
struct v4l2_subdev_board_info {
enum v4l2_subdev_bus_type type;
union {
struct v4l2_subdev_i2c_board_info i2c;
struct spi_board_info *spi;
} info;
};
/* OMAP3 ISP */
struct isp_v4l2_subdevs_group {
struct v4l2_subdev_board_info *subdevs;
enum isp_interface_type interface;
union {
struct isp_parallel_platform_data parallel;
struct isp_ccp2_platform_data ccp2;
struct isp_csi2_platform_data csi2;
} bus; /* gcc 4.6.0 chokes on anonymous union initializers */
};
struct isp_platform_data {
struct isp_v4l2_subdevs_group *subdevs;
};
The V4L2 core would need to provide a function to register a subdev based on a
v4l2_subdev_board_info structure.
Is that in line with what you've done ? I can provide a patch that implements
this for I2C and SPI, and let you add platform subdevs if that can help you.
--
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: [PATCH 0/2] V4L: Extended crop/compose API
Hello, On Thursday, May 19, 2011 3:48 PM Laurent Pinchart wrote: On Wednesday 18 May 2011 15:03:13 Sylwester Nawrocki wrote: On 05/18/2011 02:31 PM, Hans Verkuil wrote: On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote: On 05/16/2011 09:21 AM, Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: Thinking some more about it, does it make sense to set both crop and compose on a single video device node (not talking about mem-to- mem, where you use the type to multiplex input/output devices on the same node) ? If so, what would the use cases be ? I can't think of any, one either use crop or compose. I can: you crop in the video receiver and compose it into a larger buffer. Actually quite a desirable feature. Yes, right. Don't know why I imagined something different. And we need it in Samsung capture capture interfaces as well. The H/W is capable of cropping and composing with camera interface as a data source similarly as it is done with memory buffers. The same result could be achieved by adding an offset to the buffer address and setting the bytesperline field accordingly, but that would only work with userptr buffers. Playing with offset and bytesperline to achieve composing effect should be considered only as a huge hack. Please note that there is a bunch of pixel formats that have no clear definition of bytesperline at all - like macro block formats or some (multi)planar ones. We would really like to have a generic solution for the composing problem. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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 0/2] V4L: Extended crop/compose API
Laurent Pinchart wrote: On Wednesday 18 May 2011 15:03:13 Sylwester Nawrocki wrote: On 05/18/2011 02:31 PM, Hans Verkuil wrote: On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote: On 05/16/2011 09:21 AM, Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: Thinking some more about it, does it make sense to set both crop and compose on a single video device node (not talking about mem-to-mem, where you use the type to multiplex input/output devices on the same node) ? If so, what would the use cases be ? I can't think of any, one either use crop or compose. I can: you crop in the video receiver and compose it into a larger buffer. Actually quite a desirable feature. Yes, right. Don't know why I imagined something different. And we need it in Samsung capture capture interfaces as well. The H/W is capable of cropping and composing with camera interface as a data source similarly as it is done with memory buffers. The same result could be achieved by adding an offset to the buffer address and setting the bytesperline field accordingly, but that would only work with userptr buffers. As we're working on an API to share buffers between subsystems, I agree that composing into a larger buffer is desirable and shouldn't be implemented using offset/stride. Hi, Simulation of cropping on a data source using offset/bytesperline is not possible for compressed formats like JPEG. I could not find any good definition of bytesperline for macroblock and planar formats. These problems were the reason of proposing extcrop (aka selection) API. Bye TS -- 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 0/2] V4L: Extended crop/compose API
On Thursday 19 May 2011 16:06:12 Tomasz Stanislawski wrote: Laurent Pinchart wrote: On Wednesday 18 May 2011 15:03:13 Sylwester Nawrocki wrote: On 05/18/2011 02:31 PM, Hans Verkuil wrote: On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote: On 05/16/2011 09:21 AM, Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: Thinking some more about it, does it make sense to set both crop and compose on a single video device node (not talking about mem-to-mem, where you use the type to multiplex input/output devices on the same node) ? If so, what would the use cases be ? I can't think of any, one either use crop or compose. I can: you crop in the video receiver and compose it into a larger buffer. Actually quite a desirable feature. Yes, right. Don't know why I imagined something different. And we need it in Samsung capture capture interfaces as well. The H/W is capable of cropping and composing with camera interface as a data source similarly as it is done with memory buffers. The same result could be achieved by adding an offset to the buffer address and setting the bytesperline field accordingly, but that would only work with userptr buffers. As we're working on an API to share buffers between subsystems, I agree that composing into a larger buffer is desirable and shouldn't be implemented using offset/stride. Hi, Simulation of cropping on a data source using offset/bytesperline is not possible for compressed formats like JPEG. I agree with you, but for composing I wonder how you're going to compose an image into a JPEG buffer :-) I could not find any good definition of bytesperline for macroblock and planar formats. These problems were the reason of proposing extcrop (aka selection) API. As I said, I agree that composing shouldn't be implemented using offset/stride, so there's no disagreement. -- 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: [PATCH 0/3] V4L2 API for flash devices and the adp1653 flash controller driver
Hi Laurent, On Thu, May 19, 2011 at 3:14 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sakari, On Thursday 19 May 2011 12:41:14 Sakari Ailus wrote: Hi, This patchset implements RFC v4 of V4L2 API for flash devices [1], with minor modifications, and adds the adp1653 flash controller driver. As already answered in private: Acked-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Sorry if I missed something, but shouldn't be your ack here? :) The patches are from Sakari already. Br, David This patchset depends on the bitmask controls patch [4]. Changes since v2 [3] of the RFC patchset: - Improved flash control documentation in general. - Faults may change the LED mode to none. This is now documented. - adp1653 is returned to sane after faults are detected. - Proper error handling for adp1653_get_fault() in adp1653_strobe(). - Remove useless function: adp1653_registered() and the corresponding callback. Controls are now initialised in adp1653_probe(). - Improved fault handling in adp1653_init_device(). Changes since v1 [2] of the RFC patchset: - Faults on the flash LED are allowed to make the LED unusable before the faults are read. This is implemented in the adp1653 driver. - Intensities are using standard units; mA for flash / torch and uA for the indicator. Thanks to those who have given their feedback so far in the process! [1] http://www.spinics.net/lists/linux-media/msg32030.html [2] http://www.spinics.net/lists/linux-media/msg32396.html [3] http://www.spinics.net/lists/linux-media/msg32436.html [4] http://www.spinics.net/lists/linux-media/msg31001.html -- 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: [PATCH 0/3] V4L2 API for flash devices and the adp1653 flash controller driver
Hi David, On Thursday 19 May 2011 16:22:45 David Cohen wrote: On Thu, May 19, 2011 at 3:14 PM, Laurent Pinchart wrote: On Thursday 19 May 2011 12:41:14 Sakari Ailus wrote: Hi, This patchset implements RFC v4 of V4L2 API for flash devices [1], with minor modifications, and adds the adp1653 flash controller driver. As already answered in private: Acked-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Sorry if I missed something, but shouldn't be your ack here? :) The patches are from Sakari already. OK, I'll stop trying to impersonate Sakari :-) Wrong copypaste, sorry. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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: FW: OMAP 3 ISP
Hi Michael,
On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
Thanks Laurent,
My video source is not the video camera and performs many other
functions. For this purpose I have RS232 port.
As for the video, it runs continuously and is not subject to control
except for the power supply.
As a quick hack, you can create an I2C driver for your video source
that doesn't access the device and just returns fixed format and frame
size.
The correct fix is to implement support for platform subdevs in the
V4L2 core.
I recently implemented support for platform V4L2 subdevs. Now that it
sounds like others would be interested in this, I will try to polish it
up and submit the patch for review in the next week or so.
Great. This has been discussed during the V4L meeting in Warsaw, here are
a couple of pointers, to make sure we're going in the same direction.
Bridge drivers should not care whether the subdev sits on an I2C, SPI,
platform or other bus. To achieve that, an abstraction layer must be
provided by the V4L2 core. Here's what I got in one of my trees:
/* V4L2 core */
struct v4l2_subdev_i2c_board_info {
struct i2c_board_info *board_info;
int i2c_adapter_id;
};
enum v4l2_subdev_bus_type {
V4L2_SUBDEV_BUS_TYPE_NONE,
V4L2_SUBDEV_BUS_TYPE_I2C,
V4L2_SUBDEV_BUS_TYPE_SPI,
};
struct v4l2_subdev_board_info {
enum v4l2_subdev_bus_type type;
union {
struct v4l2_subdev_i2c_board_info i2c;
struct spi_board_info *spi;
} info;
};
/* OMAP3 ISP */
struct isp_v4l2_subdevs_group {
struct v4l2_subdev_board_info *subdevs;
enum isp_interface_type interface;
union {
struct isp_parallel_platform_data parallel;
struct isp_ccp2_platform_data ccp2;
struct isp_csi2_platform_data csi2;
} bus; /* gcc 4.6.0 chokes on anonymous union initializers */
};
struct isp_platform_data {
struct isp_v4l2_subdevs_group *subdevs;
};
The V4L2 core would need to provide a function to register a subdev based
on a v4l2_subdev_board_info structure.
Is that in line with what you've done ? I can provide a patch that
implements this for I2C and SPI, and let you add platform subdevs if
that can help you.
Hi Laurent,
Yes, that looks very similar to what I've done. I was going to submit
SPI support, too, which I also have, but it sounds like you've already
done that? I'm currently still using a 2.6.38 tree based on an older
media branch of yours, so I'm not familiar with any new changes there yet.
I just need to know what I should use as my baseline.
Please use mainline, now that the OMAP3 ISP driver has been merged :-)
I don't need to step on toes and submit something you've already done, so
maybe you want to point me to a branch with the SPI stuff, and I'll just put
the platform stuff on top of it?
I'll send the SPI support patches to linux-media, as they haven't been
reviewed publicly yet.
--
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: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC
Laurent,
Thank you for your comments. I have addressed all your suggestions.
Please find my comments inline.
Also,
Would you please review the patch again?
The branch is at:
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h=refs/heads/forkhilman2
and the patch that you last reviewed was:
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=commit;h=690187eb05de65f1e63fc631ad4dc31358d01e55
Thanks,
-Manju
On Mon, May 02, 2011 at 15:28:23, Laurent Pinchart wrote:
Hi Manjunath,
On Tuesday 26 April 2011 16:47:45 Hadli, Manjunath wrote:
Laurent,
Can you please review the patches with your suggestions from :
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h
=refs
/heads/forkhilman2 and let me know if you think all your suggestions
are taken care of?
The patch you reviewed was :
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=commitdiff
;h=69
f60ed7577ab9184ceabd7efbe5bb3453bf7ef1;hp=a400604f47c339831880c50eda6f
6b032
21579e3
I've reviewed the same patch, here are my comments.
+/*
+ * vpbe_display_isr()
+ * ISR function. It changes status of the displayed buffer, takes
+next
buffer
+ * from the queue and sets its address in VPBE registers */ static
+void vpbe_display_isr(unsigned int event, struct vpbe_display
*disp_obj)
+{
+ struct osd_state *osd_device = disp_obj-osd_device;
+ struct timespec timevalue;
+ struct vpbe_layer *layer;
+ unsigned long addr;
+ int fid;
+ int i;
+
+ ktime_get_ts(timevalue);
+
+ for (i = 0; i VPBE_DISPLAY_MAX_DEVICES; i++) {
+ layer = disp_obj-dev[i];
+ /* If streaming is started in this layer */
+ if (!layer-started)
+ continue;
What about moving everything above to venc_isr(), and having this function
handle a single layer only ? It will lower the max indentation level. I also
wonder whether you couldn't share some code between the non-interlaced and
the interlaced cases by reorganizing the function body (the fid == 1 code
looks quite similar to the non-interlaced code).
To make it very clean I have broken the isr in a different way and tried to
neatly arrange it. It has now been made qute small and re-usable.Hope you like
it.
[snip]
+/**
+ * vpbe_try_format()
+ * If user application provides width and height, and have
+bytesperline set
+ * to zero, driver calculates bytesperline and sizeimage based on
+hardware
+ * limits. If application likes to add pads at the end of each line
+and
+ * end of the buffer , it can set bytesperline to line size and
+sizeimage
to
+ * bytesperline * height of the buffer. If driver fills zero for
+ active
+ * video width and height, and has requested user bytesperline and
sizeimage,
+ * width and height is adjusted to maximum display limit or buffer
+ width
+ * height which ever is lower
This still sounds a bit cryptic to me.
vpbe_try_format() should return a format closest to what the user requested:
- If the pixel format is invalid, select a default value (done)
- If the field is invalid or not specified, select a default value (partly
done, you don't check for default values)
- If width and/or height are invalid (including being set to 0), select
default values (partly done, you compute width/height based on bytesperline
and sizeimage when they're set to 0, and I don't understand why)
- If bytesperline is invalid (smaller than the minimum value according to the
selected width, or larger than the maximum allowable value), fix it
- If sizeimage is invalid (smaller than the minimum value according the the
selected height and bytesperline), fix it
Is there a need to allow sizeimage values different than height *
bytesperline ?
Cleaned and taken care of.
+ */
[snip]
+static int vpbe_display_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap) {
+ struct vpbe_fh *fh = file-private_data;
+ struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev;
+
+ cap-version = VPBE_DISPLAY_VERSION_CODE;
+ cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
+ strlcpy(cap-driver, VPBE_DISPLAY_DRIVER, sizeof(cap-driver));
+ strlcpy(cap-bus_info, platform, sizeof(cap-bus_info));
+ /* check the name of davinci device */
+ if (vpbe_dev-cfg-module_name != NULL)
module_name can't be NULL, as it's declared as a char[32].
+ strlcpy(cap-card, vpbe_dev-cfg-module_name,
+ sizeof(cap-card));
+
+ return 0;
+}
[snip]
+static int vpbe_display_g_fmt(struct file *file, void *priv,
+ struct v4l2_format *fmt)
+{
+ struct vpbe_fh *fh = file-private_data;
+ struct vpbe_layer *layer = fh-layer;
+ struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev;
+
+ v4l2_dbg(1, debug, vpbe_dev-v4l2_dev,
+
RE: FW: OMAP 3 ISP
Hi Michael,
I liked the idea of a driver that returns fixed format and frame size.
It certainly could solve my problem.
On the other hand, from your correspondence to Laurent, I realized that it was
already done work on improving V4L2 subdevs.
Michael patch of which you speak will help solve my problem without writing a
special driver?
Advise in what direction to go in my case?
Regards,
Alex Gershgorin
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Thursday, May 19, 2011 5:27 PM
To: Michael Jones
Cc: Alex Gershgorin; 'linux-media@vger.kernel.org'; 'sakari.ai...@iki.fi';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
Hi Michael,
On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
Thanks Laurent,
My video source is not the video camera and performs many other
functions. For this purpose I have RS232 port.
As for the video, it runs continuously and is not subject to control
except for the power supply.
As a quick hack, you can create an I2C driver for your video source
that doesn't access the device and just returns fixed format and frame
size.
The correct fix is to implement support for platform subdevs in the
V4L2 core.
I recently implemented support for platform V4L2 subdevs. Now that it
sounds like others would be interested in this, I will try to polish it
up and submit the patch for review in the next week or so.
Great. This has been discussed during the V4L meeting in Warsaw, here are
a couple of pointers, to make sure we're going in the same direction.
Bridge drivers should not care whether the subdev sits on an I2C, SPI,
platform or other bus. To achieve that, an abstraction layer must be
provided by the V4L2 core. Here's what I got in one of my trees:
/* V4L2 core */
struct v4l2_subdev_i2c_board_info {
struct i2c_board_info *board_info;
int i2c_adapter_id;
};
enum v4l2_subdev_bus_type {
V4L2_SUBDEV_BUS_TYPE_NONE,
V4L2_SUBDEV_BUS_TYPE_I2C,
V4L2_SUBDEV_BUS_TYPE_SPI,
};
struct v4l2_subdev_board_info {
enum v4l2_subdev_bus_type type;
union {
struct v4l2_subdev_i2c_board_info i2c;
struct spi_board_info *spi;
} info;
};
/* OMAP3 ISP */
struct isp_v4l2_subdevs_group {
struct v4l2_subdev_board_info *subdevs;
enum isp_interface_type interface;
union {
struct isp_parallel_platform_data parallel;
struct isp_ccp2_platform_data ccp2;
struct isp_csi2_platform_data csi2;
} bus; /* gcc 4.6.0 chokes on anonymous union initializers */
};
struct isp_platform_data {
struct isp_v4l2_subdevs_group *subdevs;
};
The V4L2 core would need to provide a function to register a subdev based
on a v4l2_subdev_board_info structure.
Is that in line with what you've done ? I can provide a patch that
implements this for I2C and SPI, and let you add platform subdevs if
that can help you.
Hi Laurent,
Yes, that looks very similar to what I've done. I was going to submit
SPI support, too, which I also have, but it sounds like you've already
done that? I'm currently still using a 2.6.38 tree based on an older
media branch of yours, so I'm not familiar with any new changes there yet.
I just need to know what I should use as my baseline.
Please use mainline, now that the OMAP3 ISP driver has been merged :-)
I don't need to step on toes and submit something you've already done, so
maybe you want to point me to a branch with the SPI stuff, and I'll just put
the platform stuff on top of it?
I'll send the SPI support patches to linux-media, as they haven't been
reviewed publicly yet.
--
Regards,
Laurent Pinchart
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6135 (20110519) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6135 (20110519) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.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: FW: OMAP 3 ISP
On Thu, May 19, 2011 at 06:13:28PM +0300, Alex Gershgorin wrote:
Hi Michael,
I liked the idea of a driver that returns fixed format and frame size.
It certainly could solve my problem.
On the other hand, from your correspondence to Laurent, I realized that it
was already done work on improving V4L2 subdevs.
Michael patch of which you speak will help solve my problem without writing a
special driver?
Advise in what direction to go in my case?
Hi Alex,
You still need a driver, but with the patches you can easily implement that
as a driver for a platform device. The driver itself wouldn't have to do
much more than to return a fixed format and size when queried.
Regards,
Alex Gershgorin
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Thursday, May 19, 2011 5:27 PM
To: Michael Jones
Cc: Alex Gershgorin; 'linux-media@vger.kernel.org'; 'sakari.ai...@iki.fi';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
Hi Michael,
On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
Thanks Laurent,
My video source is not the video camera and performs many other
functions. For this purpose I have RS232 port.
As for the video, it runs continuously and is not subject to control
except for the power supply.
As a quick hack, you can create an I2C driver for your video source
that doesn't access the device and just returns fixed format and frame
size.
The correct fix is to implement support for platform subdevs in the
V4L2 core.
I recently implemented support for platform V4L2 subdevs. Now that it
sounds like others would be interested in this, I will try to polish it
up and submit the patch for review in the next week or so.
Great. This has been discussed during the V4L meeting in Warsaw, here are
a couple of pointers, to make sure we're going in the same direction.
Bridge drivers should not care whether the subdev sits on an I2C, SPI,
platform or other bus. To achieve that, an abstraction layer must be
provided by the V4L2 core. Here's what I got in one of my trees:
/* V4L2 core */
struct v4l2_subdev_i2c_board_info {
struct i2c_board_info *board_info;
int i2c_adapter_id;
};
enum v4l2_subdev_bus_type {
V4L2_SUBDEV_BUS_TYPE_NONE,
V4L2_SUBDEV_BUS_TYPE_I2C,
V4L2_SUBDEV_BUS_TYPE_SPI,
};
struct v4l2_subdev_board_info {
enum v4l2_subdev_bus_type type;
union {
struct v4l2_subdev_i2c_board_info i2c;
struct spi_board_info *spi;
} info;
};
/* OMAP3 ISP */
struct isp_v4l2_subdevs_group {
struct v4l2_subdev_board_info *subdevs;
enum isp_interface_type interface;
union {
struct isp_parallel_platform_data parallel;
struct isp_ccp2_platform_data ccp2;
struct isp_csi2_platform_data csi2;
} bus; /* gcc 4.6.0 chokes on anonymous union initializers */
};
struct isp_platform_data {
struct isp_v4l2_subdevs_group *subdevs;
};
The V4L2 core would need to provide a function to register a subdev based
on a v4l2_subdev_board_info structure.
Is that in line with what you've done ? I can provide a patch that
implements this for I2C and SPI, and let you add platform subdevs if
that can help you.
Hi Laurent,
Yes, that looks very similar to what I've done. I was going to submit
SPI support, too, which I also have, but it sounds like you've already
done that? I'm currently still using a 2.6.38 tree based on an older
media branch of yours, so I'm not familiar with any new changes there yet.
I just need to know what I should use as my baseline.
Please use mainline, now that the OMAP3 ISP driver has been merged :-)
I don't need to step on toes and submit something you've already done, so
maybe you want to point me to a branch with the SPI stuff, and I'll just put
the platform stuff on top of it?
I'll send the SPI support patches to linux-media, as they haven't been
reviewed publicly yet.
--
Regards,
Laurent Pinchart
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6135 (20110519) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6135 (20110519) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
Sakari Ailus
sakari dot ailus at iki dot fi
--
To unsubscribe from this list: send
Re: [PATCH 0/2] V4L: Extended crop/compose API
Tomasz Stanislawski wrote: Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote: On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote: Hi Laurent and Hans, I am very sorry for replying so lately. I was really busy during last week. Thank you very much for your interest and comments :). [snip] - Name VIDIOC_S_SELECTION - set cropping rectangle on an input of a device [snip] v4l2-selection::r is filled with suggested coordinates. The coordinates are expressed in driver-dependant units. What kind of driver-dependant units do you think will be used in practice ? In a case of sensors, units could be subpixels. For analog TV inputs, units may be milliseconds. For printers/scanner, units may be centimeters. I think that there are many other examples out there. Applications set V4L2_SEL_TRY flag in v4l2_selection::flags to prevent a driver from applying selection configuration to hardware. I mentioned this before but I am very much opposed to this flag. It is inconsistent with the TRY_FMT and TRY_EXT_CTRLS ioctls. Note that in video_ioctl2 it should be just one function with 'try' boolean argument. It has always been a mistake that the try and set functions were separated in the driver code IMHO. I know that the subdev ioctls do not have a try version, but it is not quite the same in that those try functions actually store the try information. That's exactly why the subdevs pad-level API has a try flag instead of a try operation, and that's why g/s_selection on subdevs will be done with a try flag. As for the video device node API, I won't oppose a TRY ioctl, as long as we can guarantee there will never be dependencies between the selection rectangles and other parameters (or between the different selection rectangles). If the crop rectangle depends on the compose rectangle for instance, how can you implement a TRY ioctl to try a crop rectangle for a specific compose rectangle, without modifying the active compose rectangle first ? In that case the TRY would adjust the crop so that it works with the current compose rectangle. And how do you try both crop and compose settings without modifying the active configuration ? That's not possible, and I think it's a bad API limitation. VIDIOC_TRY_MULTISELECTION ? But this is just one more example of our lack of proper support for pipeline setup. It doesn't really matter whether this is at the subdev level or at the driver level, both have the same problems. This requires a brainstorm session to work out. This is something we need to look into more carefully. I am slowly becoming convinced that we need some sort of transaction-based configuration for pipelines. This RFC is about video device node configuration, not pipelines. For pipelines I think we'll need a transaction-based API. For video device nodes, I'm still unsure. As stated above, if we have multiple parameters that depend on each other, how do we let the user try them without changing the active configuration ? Cropping/scaling/composing IS a pipeline. Until recently the V4L2 device node API was sufficient to setup the trivial pipelines that most V4L2 consumer devices have. But with the more modern devices it starts to show its limitations. It's still a simple pipeline, and I think we should aim at making the V4L2 device node API useful to configure this kind of pipeline. The selection API is a superset of the crop API, applications should be able to use it to replace the crop API in the long term. The whole 'try' concept we had for a long time needs to be re-examined. I agree. As you remember, I was never satisfied with the subdev 'try' approach either, but I never could come up with a better alternative. I've noticed that there are two different meaning of TRY flag a) checking if a proposed configuration is applicable for a driver b) storing proposed configuration in some form of temporary buffer Ad. a. This is a real TRY command. The state of both hardware and driver does not change after TRY call. Ad. b. It should be called not TRY flag because the internal state of a driver changes. It should be named as something like SHADOW flag. It would indicate that the change is applied only to shadow configuration. I propose to change name of TRY flag for subdev to SHADOW flag. I think it would much clear to express the difference of TRY meaning in video node and subdev contexts. Therefore ioctl VIDIOC_TRY_SELECTION is probably better and more convenient way of testing if configuration is applicable. Regardless of how such a scheme should work, one thing that I believe is missing in the format ioctls (both on the video and subdev level) is a similar concept like the flags in this proposal. It would be quite
[PATCH v5] tea575x: convert to control framework
Convert tea575x-tuner to use the new V4L2 control framework. Also add
ext_init() callback that can be used by a card driver for additional
initialization right before registering the video device (for SF16-FMR2).
Also embed struct video_device to struct snd_tea575x to simplify the code.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-05-19
17:27:45.0 +0200
@@ -23,8 +23,8 @@
*/
#include linux/videodev2.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
-#include media/v4l2-ioctl.h
#define TEA575X_FMIF 10700
@@ -42,7 +42,7 @@ struct snd_tea575x_ops {
};
struct snd_tea575x {
- struct video_device *vd;/* video device */
+ struct video_device vd; /* video device */
bool tea5759; /* 5759 chip is present */
bool mute; /* Device is muted? */
bool stereo;/* receiving stereo */
@@ -54,6 +54,8 @@ struct snd_tea575x {
void *private_data;
u8 card[32];
u8 bus_info[32];
+ struct v4l2_ctrl_handler ctrl_handler;
+ int (*ext_init)(struct snd_tea575x *tea);
};
int snd_tea575x_init(struct snd_tea575x *tea);
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-05-19
17:31:45.0 +0200
@@ -22,11 +22,11 @@
#include asm/io.h
#include linux/delay.h
-#include linux/interrupt.h
#include linux/init.h
#include linux/slab.h
#include linux/version.h
-#include sound/core.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
#include sound/tea575x-tuner.h
MODULE_AUTHOR(Jaroslav Kysela pe...@perex.cz);
@@ -62,17 +62,6 @@ module_param(radio_nr, int, 0);
#define TEA575X_BIT_DUMMY (115) /* buffer */
#define TEA575X_BIT_FREQ_MASK 0x7fff
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = Mute,
- .minimum = 0,
- .maximum = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- }
-};
-
/*
* lowlevel part
*/
@@ -266,47 +255,17 @@ static int vidioc_s_audio(struct file *f
return 0;
}
-static int vidioc_queryctrl(struct file *file, void *priv,
- struct v4l2_queryctrl *qc)
+static int tea575x_s_ctrl(struct v4l2_ctrl *ctrl)
{
- int i;
-
- for (i = 0; i ARRAY_SIZE(radio_qctrl); i++) {
- if (qc-id qc-id == radio_qctrl[i].id) {
- memcpy(qc, (radio_qctrl[i]),
- sizeof(*qc));
- return 0;
- }
- }
- return -EINVAL;
-}
-
-static int vidioc_g_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct snd_tea575x *tea = video_drvdata(file);
+ struct snd_tea575x *tea = container_of(ctrl-handler, struct
snd_tea575x, ctrl_handler);
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value = tea-mute;
+ tea-mute = ctrl-val;
+ snd_tea575x_set_freq(tea);
return 0;
}
- return -EINVAL;
-}
-static int vidioc_s_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- switch (ctrl-id) {
- case V4L2_CID_AUDIO_MUTE:
- if (tea-mute != ctrl-value) {
- tea-mute = ctrl-value;
- snd_tea575x_set_freq(tea);
- }
- return 0;
- }
return -EINVAL;
}
@@ -355,16 +314,17 @@ static const struct v4l2_ioctl_ops tea57
.vidioc_s_input = vidioc_s_input,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
- .vidioc_queryctrl = vidioc_queryctrl,
- .vidioc_g_ctrl = vidioc_g_ctrl,
- .vidioc_s_ctrl = vidioc_s_ctrl,
};
static struct video_device tea575x_radio = {
.name = tea575x-tuner,
.fops = tea575x_fops,
.ioctl_ops = tea575x_ioctl_ops,
- .release= video_device_release,
+ .release= video_device_release_empty,
+};
+
+static const struct v4l2_ctrl_ops tea575x_ctrl_ops = {
+ .s_ctrl = tea575x_s_ctrl,
};
/*
@@ -373,7 +333,6 @@ static struct video_device tea575x_radio
int snd_tea575x_init(struct snd_tea575x *tea)
{
int retval;
- struct video_device *tea575x_radio_inst;
tea-mute = 1;
@@ -384,40 +343,45 @@ int snd_tea575x_init(struct snd_tea575x
tea-in_use = 0;
[PATCH v5] radio-sf16fmr2: convert to generic TEA575x interface
Convert radio-sf16fmr2 to use generic TEA575x implementation. Most of the
driver code goes away as SF16-FMR2 is basically just a TEA5757 tuner
connected to ISA bus.
The card can optionally be equipped with PT2254A volume control (equivalent
of TC9154AP) - the volume setting is completely reworked (with balance control
added) and tested.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/sound/pci/Kconfig 2011-05-15 18:50:18.0 +0200
+++ linux-2.6.39-rc2/sound/pci/Kconfig 2011-05-17 23:35:30.0 +0200
@@ -565,8 +565,8 @@ config SND_FM801_TEA575X_BOOL
config SND_TEA575X
tristate
- depends on SND_FM801_TEA575X_BOOL || SND_ES1968_RADIO
- default SND_FM801 || SND_ES1968
+ depends on SND_FM801_TEA575X_BOOL || SND_ES1968_RADIO || RADIO_SF16FMR2
+ default SND_FM801 || SND_ES1968 || RADIO_SF16FMR2
source sound/pci/hda/Kconfig
--- linux-2.6.39-rc2-/drivers/media/radio/radio-sf16fmr2.c 2011-04-06
03:30:43.0 +0200
+++ linux-2.6.39-rc2/drivers/media/radio/radio-sf16fmr2.c 2011-05-19
17:56:08.0 +0200
@@ -1,441 +1,209 @@
-/* SF16FMR2 radio driver for Linux radio support
- * heavily based on fmi driver...
- * (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+/* SF16-FMR2 radio driver for Linux
+ * Copyright (c) 2011 Ondrej Zary
*
- * Notes on the hardware
- *
- * Frequency control is done digitally -- ie out(port,encodefreq(95.8));
- * No volume control - only mute/unmute - you have to use line volume
- *
- * For read stereo/mono you must wait 0.1 sec after set frequency and
- * card unmuted so I set frequency on unmute
- * Signal handling seem to work only on autoscanning (not implemented)
- *
- * Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org
+ * Original driver was (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+ * but almost nothing remained here after conversion to generic TEA575x
+ * implementation
*/
+#include linux/delay.h
#include linux/module.h /* Modules */
#include linux/init.h/* Initdata */
#include linux/ioport.h /* request_region */
-#include linux/delay.h /* udelay */
-#include linux/videodev2.h /* kernel radio structs */
-#include linux/mutex.h
-#include linux/version.h /* for KERNEL_VERSION MACRO */
#include linux/io.h /* outb, outb_p */
-#include media/v4l2-device.h
-#include media/v4l2-ioctl.h
+#include sound/tea575x-tuner.h
-MODULE_AUTHOR(Ziglio Frediano, fredd...@angelfire.com);
-MODULE_DESCRIPTION(A driver for the SF16FMR2 radio.);
+MODULE_AUTHOR(Ondrej Zary);
+MODULE_DESCRIPTION(MediaForte SF16-FMR2 FM radio card driver);
MODULE_LICENSE(GPL);
-static int io = 0x384;
-static int radio_nr = -1;
-
-module_param(io, int, 0);
-MODULE_PARM_DESC(io, I/O address of the SF16FMR2 card (should be 0x384, if do
not work try 0x284));
-module_param(radio_nr, int, 0);
-
-#define RADIO_VERSION KERNEL_VERSION(0,0,2)
-
-#define AUD_VOL_INDEX 1
-
-#undef DEBUG
-//#define DEBUG 1
-
-#ifdef DEBUG
-# define debug_print(s) printk s
-#else
-# define debug_print(s)
-#endif
-
-/* this should be static vars for module size */
-struct fmr2
-{
- struct v4l2_device v4l2_dev;
- struct video_device vdev;
- struct mutex lock;
+struct fmr2 {
int io;
- int curvol; /* 0-15 */
- int mute;
- int stereo; /* card is producing stereo audio */
- unsigned long curfreq; /* freq in kHz */
- int card_type;
+ struct snd_tea575x tea;
+ struct v4l2_ctrl *volume;
+ struct v4l2_ctrl *balance;
};
+/* the port is hardwired so no need to support multiple cards */
+#define FMR2_PORT 0x384
static struct fmr2 fmr2_card;
-/* hw precision is 12.5 kHz
- * It is only useful to give freq in interval of 200 (=0.0125Mhz),
- * other bits will be truncated
- */
-#define RSF16_ENCODE(x)((x) / 200 + 856)
-#define RSF16_MINFREQ (87 * 16000)
-#define RSF16_MAXFREQ (108 * 16000)
-
-static inline void wait(int n, int io)
-{
- for (; n; --n)
- inb(io);
-}
-
-static void outbits(int bits, unsigned int data, int nWait, int io)
-{
- int bit;
-
- for (; --bits = 0;) {
- bit = (data bits) 1;
- outb(bit, io);
- wait(nWait, io);
- outb(bit | 2, io);
- wait(nWait, io);
- outb(bit, io);
- wait(nWait, io);
- }
-}
-
-static inline void fmr2_mute(int io)
-{
- outb(0x00, io);
- wait(4, io);
-}
-
-static inline void fmr2_unmute(int io)
-{
- outb(0x04, io);
- wait(4, io);
-}
-
-static inline int fmr2_stereo_mode(int io)
-{
- int n = inb(io);
-
- outb(6, io);
- inb(io);
- n = ((n 3) 1) ^ 1;
- debug_print((KERN_DEBUG stereo: %d\n, n));
- return n;
-}
-
-static int
[PATCH] saa7134-dvb.c kworld_sbtvd
The correct place to put i2c_gate_ctrl is before calling tda18271_attach, because the driver tda18271 will use it to enable or disable the i2c-bus from the demodulator to the tuner. And thus eliminate the error message: Unknown device (255) detected @ 1-00c0, device not supported in the driver tda18271. In the device kworld_sbtvd (hybrid analog and digital TV) the control of the i2c-bus to tuner is done in the analog demodulator and not in the digital demodulator. Signed-off-by: Manoel Pinheiro pinus...@hotmail.com diff --git a/drivers/media/video/saa7134/saa7134-dvb.c b/drivers/media/video/saa7134/saa7134-dvb.c index f65cad2..c1a18d1 100644 --- a/drivers/media/video/saa7134/saa7134-dvb.c +++ b/drivers/media/video/saa7134/saa7134-dvb.c @@ -1666,10 +1666,10 @@ static int dvb_init(struct saa7134_dev *dev) dvb_attach(tda829x_attach, fe0-dvb.frontend, dev-i2c_adap, 0x4b, tda829x_no_probe); + fe0-dvb.frontend-ops.i2c_gate_ctrl = kworld_sbtvd_gate_ctrl; dvb_attach(tda18271_attach, fe0-dvb.frontend, 0x60, dev-i2c_adap, kworld_tda18271_config); - fe0-dvb.frontend-ops.i2c_gate_ctrl = kworld_sbtvd_gate_ctrl; } /* mb86a20s need to use the I2C gateway */ -- 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/PATCH 2/2] omap3isp: Use generic subdev registration function
Replace custom subdev registration with a call to
v4l2_new_subdev_board().
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isp.c | 32 +---
drivers/media/video/omap3isp/isp.h |7 +--
2 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 472a693..8280165 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1642,9 +1642,9 @@ static void isp_unregister_entities(struct isp_device
*isp)
/*
* isp_register_subdev_group - Register a group of subdevices
* @isp: OMAP3 ISP device
- * @board_info: I2C subdevs board information array
+ * @board_info: V4L2 subdevs board information array
*
- * Register all I2C subdevices in the board_info array. The array must be
+ * Register all V4L2 subdevices in the board_info array. The array must be
* terminated by a NULL entry, and the first entry must be the sensor.
*
* Return a pointer to the sensor media entity if it has been successfully
@@ -1652,36 +1652,22 @@ static void isp_unregister_entities(struct isp_device
*isp)
*/
static struct v4l2_subdev *
isp_register_subdev_group(struct isp_device *isp,
-struct isp_subdev_i2c_board_info *board_info)
+struct v4l2_subdev_board_info *board_info)
{
struct v4l2_subdev *sensor = NULL;
- unsigned int first;
-
- if (board_info-board_info == NULL)
- return NULL;
+ unsigned int i;
- for (first = 1; board_info-board_info; ++board_info, first = 0) {
+ for (i = 0; board_info; ++board_info, ++i) {
struct v4l2_subdev *subdev;
- struct i2c_adapter *adapter;
-
- adapter = i2c_get_adapter(board_info-i2c_adapter_id);
- if (adapter == NULL) {
- printk(KERN_ERR %s: Unable to get I2C adapter %d for
- device %s\n, __func__,
- board_info-i2c_adapter_id,
- board_info-board_info-type);
- continue;
- }
- subdev = v4l2_i2c_new_subdev_board(isp-v4l2_dev, adapter,
- board_info-board_info, NULL);
+ subdev = v4l2_new_subdev_board(isp-v4l2_dev, board_info);
if (subdev == NULL) {
- printk(KERN_ERR %s: Unable to register subdev %s\n,
- __func__, board_info-board_info-type);
+ printk(KERN_ERR %s: Unable to register subdev %u\n,
+ __func__, i);
continue;
}
- if (first)
+ if (i == 0)
sensor = subdev;
}
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 2620c40..c3ecc36 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -180,13 +180,8 @@ struct isp_csi2_platform_data {
unsigned vpclk_div:2;
};
-struct isp_subdev_i2c_board_info {
- struct i2c_board_info *board_info;
- int i2c_adapter_id;
-};
-
struct isp_v4l2_subdevs_group {
- struct isp_subdev_i2c_board_info *subdevs;
+ struct v4l2_subdev_board_info *subdevs;
enum isp_interface_type interface;
union {
struct isp_parallel_platform_data parallel;
--
1.7.3.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
[RFC/PATCH 1/2] v4l: Add generic board subdev registration function
The new v4l2_new_subdev_board() function creates and register a subdev
based on generic board information. The board information structure
includes a bus type and bus type-specific information.
Only I2C and SPI busses are currently supported.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-common.c | 70 +
drivers/media/video/v4l2-device.c |8
include/media/v4l2-common.h | 28 +++
include/media/v4l2-subdev.h |3 ++
4 files changed, 109 insertions(+), 0 deletions(-)
Hi everybody,
This approach has been briefly discussed during the Warsaw V4L meeting. Now
that support for platform subdevs has been requested, I'd like to move bus type
handling to the V4L2 core instead of duplicating the logic in every driver. As
usual, comments will be appreciated.
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 06b9f9f..46aee94 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -474,6 +474,76 @@ EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
#endif /* defined(CONFIG_SPI) */
+/*
+ * v4l2_new_subdev_board - Register a subdevice based on board information
+ * @v4l2_dev: Parent V4L2 device
+ * @info: I2C subdevs board information array
+ *
+ * Register a subdevice identified by a geenric board information structure.
The
+ * structure contains the bus type and bus type-specific information.
+ *
+ * Return a pointer to the subdevice if registration was successful, or NULL
+ * otherwise.
+ */
+struct v4l2_subdev *v4l2_new_subdev_board(struct v4l2_device *v4l2_dev,
+ struct v4l2_subdev_board_info *info)
+{
+ struct v4l2_subdev *subdev;
+
+ switch (info-type) {
+#if defined(CONFIG_I2C)
+ case V4L2_SUBDEV_BUS_TYPE_I2C: {
+ struct i2c_adapter *adapter;
+
+ adapter = i2c_get_adapter(info-info.i2c.i2c_adapter_id);
+ if (adapter == NULL) {
+ printk(KERN_ERR %s: Unable to get I2C adapter %d for
+ device %s/%u\n, __func__,
+ info-info.i2c.i2c_adapter_id,
+ info-info.i2c.board_info-type,
+ info-info.i2c.board_info-addr);
+ return NULL;
+ }
+
+ subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adapter,
+ info-info.i2c.board_info, NULL);
+ if (subdev == NULL) {
+ i2c_put_adapter(adapter);
+ return NULL;
+ }
+
+ subdev-flags |= V4L2_SUBDEV_FL_RELEASE_ADAPTER;
+ break;
+ }
+#endif /* defined(CONFIG_I2C) */
+#if defined(CONFIG_SPI)
+ case V4L2_SUBDEV_BUS_TYPE_SPI: {
+ struct spi_master *master;
+
+ master = spi_busnum_to_master(info-info.spi-bus_num);
+ if (master == NULL) {
+ printk(KERN_ERR %s: Unable to get SPI master %u for
+ device %s/%u\n, __func__,
+ info-info.spi-bus_num,
+ info-info.spi-modalias,
+ info-info.spi-chip_select);
+ return NULL;
+ }
+
+ subdev = v4l2_spi_new_subdev(v4l2_dev, master, info-info.spi);
+ spi_master_put(master);
+ break;
+ }
+#endif /* defined(CONFIG_SPI) */
+ default:
+ subdev = NULL;
+ break;
+ }
+
+ return subdev;
+}
+EXPORT_SYMBOL_GPL(v4l2_new_subdev_board);
+
/* Clamp x to be between min and max, aligned to a multiple of 2^align. min
* and max don't have to be aligned, but there must be at least one valid
* value. E.g., min=17,max=31,align=4 is not allowed as there are no multiples
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index 4aae501..cfd9caf 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -246,5 +246,13 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev *sd)
#endif
video_unregister_device(sd-devnode);
module_put(sd-owner);
+
+#if defined(CONFIG_I2C) || (defined(CONFIG_I2C_MODULE) defined(MODULE))
+ if ((sd-flags V4L2_SUBDEV_FL_IS_I2C)
+ (sd-flags V4L2_SUBDEV_FL_RELEASE_ADAPTER)) {
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ i2c_put_adapter(client-adapter);
+ }
+#endif
}
EXPORT_SYMBOL_GPL(v4l2_device_unregister_subdev);
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index a298ec4..88c38d9 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -171,6 +171,34 @@ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct
spi_device *spi,
const
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu May 19 19:00:32 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
[RFC] add i2c_gate_ctrl to mb86a20s.c
The register 0xfe controls the i2c-bus from the mb86a20s to tuner.
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..f3c4013 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -370,6 +370,17 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state
*state,
mb86a20s_i2c_writeregdata(state, state-config-demod_address, \
regdata, ARRAY_SIZE(regdata))
+static int mb86a20s_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
+{
+ struct mb86a20s_state *state = fe-demodulator_priv;
+
+ /* Enable/Disable I2C bus for tuner control */
+ if (enable)
+ return mb86a20s_writereg(state, 0xfe, 0);
+ else
+ return mb86a20s_writereg(state, 0xfe, 1);
+}
+
static int mb86a20s_initfe(struct dvb_frontend *fe)
{
struct mb86a20s_state *state = fe-demodulator_priv;
@@ -626,6 +637,7 @@ static struct dvb_frontend_ops mb86a20s_ops = {
.release = mb86a20s_release,
+ .i2c_gate_ctrl = mb86a20s_i2c_gate_ctrl,
.init = mb86a20s_initfe,
.set_frontend = mb86a20s_set_frontend,
.get_frontend = mb86a20s_get_frontend,
--
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: Fw: [PATCH -next RESEND/still needed] staging: altera-jtag needs delay.h
On Thu, May 19, 2011 at 04:22:06PM -0300, Mauro Carvalho Chehab wrote: Em 28-03-2011 12:23, Randy Dunlap escreveu: From: Randy Dunlap randy.dun...@oracle.com altera-jtag.c needs to include linux/delay.h to fix a build error: drivers/staging/altera-stapl/altera-jtag.c:398: error: implicit declaration of function 'udelay' Signed-off-by: Randy Dunlap randy.dun...@oracle.com Acked-by: Mauro Carvalho Chehab mche...@redhat.com Cc: Igor M. Liplianin liplia...@netup.ru --- drivers/staging/altera-stapl/altera-jtag.c |1 + 1 file changed, 1 insertion(+) Somehow I was supposed to know to send this to Mauro instead of to Greg, but I don't see anything in drivers/staging/altera-stapl/ that says that. Ah, yes, we need to add a readme file there stating about that. Greg, you may add it on your tree, or if you prefer, I can just add here for my next upstream pull. I see this in my tree already, git commit 92ce52695ccf2b6c4ef7eb02e1bee1bcbf5fde89, what happened to need this again? confused, greg k-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: Fw: [PATCH -next RESEND/still needed] staging: altera-jtag needs delay.h
On 05/19/11 13:39, Greg KH wrote: On Thu, May 19, 2011 at 04:22:06PM -0300, Mauro Carvalho Chehab wrote: Em 28-03-2011 12:23, Randy Dunlap escreveu: From: Randy Dunlap randy.dun...@oracle.com altera-jtag.c needs to include linux/delay.h to fix a build error: drivers/staging/altera-stapl/altera-jtag.c:398: error: implicit declaration of function 'udelay' Signed-off-by: Randy Dunlap randy.dun...@oracle.com Acked-by: Mauro Carvalho Chehab mche...@redhat.com Cc: Igor M. Liplianin liplia...@netup.ru --- drivers/staging/altera-stapl/altera-jtag.c |1 + 1 file changed, 1 insertion(+) Somehow I was supposed to know to send this to Mauro instead of to Greg, but I don't see anything in drivers/staging/altera-stapl/ that says that. Ah, yes, we need to add a readme file there stating about that. Greg, you may add it on your tree, or if you prefer, I can just add here for my next upstream pull. I see this in my tree already, git commit 92ce52695ccf2b6c4ef7eb02e1bee1bcbf5fde89, what happened to need this again? I think that Mauro is just replying to old emails (guess he's just trying to catch up...). -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] tea575x: convert to control framework
On Thursday, May 19, 2011 18:11:49 Ondrej Zary wrote:
Convert tea575x-tuner to use the new V4L2 control framework. Also add
ext_init() callback that can be used by a card driver for additional
initialization right before registering the video device (for SF16-FMR2).
Also embed struct video_device to struct snd_tea575x to simplify the code.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Acked-by: Hans Verkuil hverk...@xs4all.nl
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h2011-05-19
17:27:45.0 +0200
@@ -23,8 +23,8 @@
*/
#include linux/videodev2.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
-#include media/v4l2-ioctl.h
#define TEA575X_FMIF 10700
@@ -42,7 +42,7 @@ struct snd_tea575x_ops {
};
struct snd_tea575x {
- struct video_device *vd;/* video device */
+ struct video_device vd; /* video device */
bool tea5759; /* 5759 chip is present */
bool mute; /* Device is muted? */
bool stereo;/* receiving stereo */
@@ -54,6 +54,8 @@ struct snd_tea575x {
void *private_data;
u8 card[32];
u8 bus_info[32];
+ struct v4l2_ctrl_handler ctrl_handler;
+ int (*ext_init)(struct snd_tea575x *tea);
};
int snd_tea575x_init(struct snd_tea575x *tea);
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c 2011-05-19
17:31:45.0 +0200
@@ -22,11 +22,11 @@
#include asm/io.h
#include linux/delay.h
-#include linux/interrupt.h
#include linux/init.h
#include linux/slab.h
#include linux/version.h
-#include sound/core.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
#include sound/tea575x-tuner.h
MODULE_AUTHOR(Jaroslav Kysela pe...@perex.cz);
@@ -62,17 +62,6 @@ module_param(radio_nr, int, 0);
#define TEA575X_BIT_DUMMY(115) /* buffer */
#define TEA575X_BIT_FREQ_MASK0x7fff
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = Mute,
- .minimum = 0,
- .maximum = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- }
-};
-
/*
* lowlevel part
*/
@@ -266,47 +255,17 @@ static int vidioc_s_audio(struct file *f
return 0;
}
-static int vidioc_queryctrl(struct file *file, void *priv,
- struct v4l2_queryctrl *qc)
+static int tea575x_s_ctrl(struct v4l2_ctrl *ctrl)
{
- int i;
-
- for (i = 0; i ARRAY_SIZE(radio_qctrl); i++) {
- if (qc-id qc-id == radio_qctrl[i].id) {
- memcpy(qc, (radio_qctrl[i]),
- sizeof(*qc));
- return 0;
- }
- }
- return -EINVAL;
-}
-
-static int vidioc_g_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct snd_tea575x *tea = video_drvdata(file);
+ struct snd_tea575x *tea = container_of(ctrl-handler, struct
snd_tea575x, ctrl_handler);
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value = tea-mute;
+ tea-mute = ctrl-val;
+ snd_tea575x_set_freq(tea);
return 0;
}
- return -EINVAL;
-}
-static int vidioc_s_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- switch (ctrl-id) {
- case V4L2_CID_AUDIO_MUTE:
- if (tea-mute != ctrl-value) {
- tea-mute = ctrl-value;
- snd_tea575x_set_freq(tea);
- }
- return 0;
- }
return -EINVAL;
}
@@ -355,16 +314,17 @@ static const struct v4l2_ioctl_ops tea57
.vidioc_s_input = vidioc_s_input,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
- .vidioc_queryctrl = vidioc_queryctrl,
- .vidioc_g_ctrl = vidioc_g_ctrl,
- .vidioc_s_ctrl = vidioc_s_ctrl,
};
static struct video_device tea575x_radio = {
.name = tea575x-tuner,
.fops = tea575x_fops,
.ioctl_ops = tea575x_ioctl_ops,
- .release= video_device_release,
+ .release= video_device_release_empty,
+};
+
+static const struct v4l2_ctrl_ops tea575x_ctrl_ops = {
+ .s_ctrl = tea575x_s_ctrl,
};
/*
@@ -373,7 +333,6 @@ static struct video_device tea575x_radio
int snd_tea575x_init(struct snd_tea575x *tea)
{
int retval;
- struct video_device
Re: [PATCH v5] radio-sf16fmr2: convert to generic TEA575x interface
On Thursday, May 19, 2011 18:15:43 Ondrej Zary wrote:
Convert radio-sf16fmr2 to use generic TEA575x implementation. Most of the
driver code goes away as SF16-FMR2 is basically just a TEA5757 tuner
connected to ISA bus.
The card can optionally be equipped with PT2254A volume control (equivalent
of TC9154AP) - the volume setting is completely reworked (with balance control
added) and tested.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Acked-by: Hans Verkuil hverk...@xs4all.nl
Except for one tiny little typo:
--- linux-2.6.39-rc2-/drivers/media/radio/radio-sf16fmr2.c2011-04-06
03:30:43.0 +0200
+++ linux-2.6.39-rc2/drivers/media/radio/radio-sf16fmr2.c 2011-05-19
17:56:08.0 +0200
+static int fmr2_tea_ext_init(struct snd_tea575x *tea)
{
- return a-index ? -EINVAL : 0;
-}
+ struct fmr2 *fmr2 = tea-private_data;
-static const struct v4l2_file_operations fmr2_fops = {
- .owner = THIS_MODULE,
- .unlocked_ioctl = video_ioctl2,
-};
+ if (inb(fmr2-io) FMR2_HASVOL) {
+ fmr2-volume = v4l2_ctrl_new_std(tea-ctrl_handler,
fmr2_ctrl_ops, V4L2_CID_AUDIO_VOLUME, 0, 68, 2, 56);
+ fmr2-balance = v4l2_ctrl_new_std(tea-ctrl_handler,
fmr2_ctrl_ops, V4L2_CID_AUDIO_BALANCE, -68, 68, 2, 0);
+ if (tea-ctrl_handler.error) {
+ printk(KERN_ERR radio-sf16fmr2: can't initialize
contrls\n);
contrls - controls
+ return tea-ctrl_handler.error;
+ }
+ }
--
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: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Andreas Oberritter Sent: jeudi 19 mai 2011 14:58 To: Tomer Barletz Cc: Brice DUBOST; linux-media@vger.kernel.org Subject: Re: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent On 05/18/2011 09:16 PM, Tomer Barletz wrote: On Tue, May 17, 2011 at 8:46 AM, Brice DUBOST bra...@braice.net wrote: On 18/01/2011 15:42, Tomer Barletz wrote: Attached a patch for a bug in the lookup_callback function, were in case of a non-existent resource, the connected_resource_id is not initialized and then used in the open_session_response call of the session layer. Hello Can you explain what kind of bug it fixes ? Thanks The standard states that in case the module can't provide the requested resource , it should reply with the same resource id - this is the only line that was added. Also, since the caller to this function might use the variable returned, this variable must be initialized. The attached patch solves both bugs. Can you please resend the patch inline with a proper signed-off-by line, in order to get it tracked by patchwork.kernel.org? Yes, of course, but I don't find information that can help me to provide the correct format. Is-there a documentation somewhere that explains how patches must be formatted to be correctly tracked? Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AverMedia A306 (cx23385, xc3028, af9013) (A577 too ?)
Hello All,
I've tried to use my A306 board on my system. All the main chips are fully
supported by linux.
At this stage the CX23385 and the tuner: xc3028 seem to respond properly. But
the DVB-T chip (af9013) is silent. Nevertheless both chips are visible on the
I2C bus.
I've no full datasheet of theses chips. with exception of the af9013 where this
information is available:
http://wenku.baidu.com/view/42240f72f242336c1eb95e08.html
At this stage the CLK signal of the DVB-T chip may be missing or something is
wrong elsewhere.
If you have the datasheets... Any help will be appreciated.
Best Regards,
Wallak.
diff -u -r -b -B -w -x '*.o' -x '*.cmd' -x '*.ko' -x '*.mod.c' -x 'modules.*'
tmp/linux-2.6.37.6/drivers/media/common/tuners/tuner-xc2028.c
linux-2.6.37.6-mdf/drivers/media/common/tuners/tuner-xc2028.c
--- linux-2.6.37.6/drivers/media/common/tuners/tuner-xc2028.c2011-03-27
21:01:41.0 +0200
+++ linux-2.6.37.6-mdf/drivers/media/common/tuners/tuner-xc2028.c2011-05-07
23:30:20.0 +0200
@@ -813,6 +813,10 @@
hwmodel, (version 0xf000) 12, (version 0xf00) 8,
(version 0xf0) 4, version 0xf);
+{
+ void af9013_execdebug(struct dvb_frontend *fe);
+ af9013_execdebug(fe);
+}
if (priv-ctrl.read_not_reliable)
goto read_not_reliable;
diff -u -r -b -B -w -x '*.o' -x '*.cmd' -x '*.ko' -x '*.mod.c' -x 'modules.*'
tmp/linux-2.6.37.6/drivers/media/dvb/frontends/af9013.c
linux-2.6.37.6-mdf/drivers/media/dvb/frontends/af9013.c
--- linux-2.6.37.6/drivers/media/dvb/frontends/af9013.c2011-03-27
21:01:41.0 +0200
+++ linux-2.6.37.6-mdf/drivers/media/dvb/frontends/af9013.c2011-05-15
02:58:34.0 +0200
@@ -69,6 +69,8 @@
buf[2] = mbox;
memcpy(buf[3], val, len);
+printk(KERN_DEBUG af9013_write_regs(%02x, %02x %02x
%02x)\n,state-config.demod_address,buf[0],buf[1],buf[2]);
+
if (i2c_transfer(state-i2c, msg, 1) != 1) {
warn(I2C write failed reg:%04x len:%d, reg, len);
return -EREMOTEIO;
@@ -119,6 +121,10 @@
warn(I2C read failed reg:%04x, reg);
return -EREMOTEIO;
}
+
+printk(KERN_DEBUG af9013_read_reg(%02x, %02x %02x %02x)
=%02x\n,state-config.demod_address,reg 8,reg 0xff, 0, ibuf[0]);
+
+
*val = ibuf[0];
return 0;
}
@@ -1448,6 +1454,22 @@
kfree(state);
}
+void af9013_execdebug(struct dvb_frontend *fe)
+{
+ struct af9013_state *state = fe-demodulator_priv;
+ u8 val;
+ u8 buf[4];
+ int ret, i;
+
+ ret = af9013_read_reg(state, 0x98be, val);
+ printk(KERN_DEBUG (0x0c) running = %02x, ret=%02x\n,val, ret);
+
+ ret = af9013_read_reg_bits(state, 0xd733, 4, 4, buf[2]);
+ for (i = 0; i 2; i++) { ret = af9013_read_reg(state, 0x116b + i, buf[i]);
}
+ printk(KERN_DEBUG %s: chip version:%d ROM version:%d.%d (ret=%d)\n,
__func__, buf[2], buf[0], buf[1], ret);
+}
+EXPORT_SYMBOL(af9013_execdebug);
+
static struct dvb_frontend_ops af9013_ops;
struct dvb_frontend *af9013_attach(const struct af9013_config *config,
@@ -1484,7 +1506,18 @@
if (state-config.output_mode != AF9013_OUTPUT_MODE_USB) {
ret = af9013_download_firmware(state);
if (ret)
-goto error;
+ {
+deb_info(%s: continue...\n, __func__);
+
+/* create dvb_frontend */
+memcpy(state-frontend.ops, af9013_ops,
+ sizeof(struct dvb_frontend_ops));
+state-frontend.demodulator_priv = state;
+
+return state-frontend;
+
+//goto error;
+ }
}
/* firmware version */
diff -u -r -b -B -w -x '*.o' -x '*.cmd' -x '*.ko' -x '*.mod.c' -x 'modules.*'
tmp/linux-2.6.37.6/drivers/media/video/cx23885/cx23885-cards.c
linux-2.6.37.6-mdf/drivers/media/video/cx23885/cx23885-cards.c
--- linux-2.6.37.6/drivers/media/video/cx23885/cx23885-cards.c2011-03-27
21:01:41.0 +0200
+++ linux-2.6.37.6-mdf/drivers/media/video/cx23885/cx23885-cards.c2011-05-15
04:12:20.0 +0200
@@ -275,6 +275,10 @@
.name= Compro VideoMate E800,
.portc= CX23885_MPEG_DVB,
},
+[CX23885_BOARD_AVERMEDIA_A306] = {
+.name= Avermedia A306,
+.portc= CX23885_MPEG_DVB,
+},
[CX23885_BOARD_HAUPPAUGE_HVR1290] = {
.name= Hauppauge WinTV-HVR1290,
.portc= CX23885_MPEG_DVB,
@@ -485,6 +489,10 @@
.subdevice = 0xe800,
.card = CX23885_BOARD_COMPRO_VIDEOMATE_E800,
}, {
+.subvendor = 0x1461,
+.subdevice = 0xc139,
+.card = CX23885_BOARD_AVERMEDIA_A306,
+}, {
.subvendor = 0x0070,
.subdevice = 0x8551,
.card = CX23885_BOARD_HAUPPAUGE_HVR1290,
@@ -967,6 +975,31 @@
/* CX24228 GPIO */
/* Connected to IF / Mux */
break;
+case CX23885_BOARD_AVERMEDIA_A306:
+ // ?? PIO0: 1:on 0:nothing work
+ // ?? PIO1: demodulator address 1: 0x1c, 0:0x1d ??
+ // ??
Re: AverMedia A306 (cx23385, xc3028, af9013) (A577 too ?)
On 05/20/2011 12:13 AM, wal...@free.fr wrote: I've tried to use my A306 board on my system. All the main chips are fully supported by linux. At this stage the CX23385 and the tuner: xc3028 seem to respond properly. But the DVB-T chip (af9013) is silent. Nevertheless both chips are visible on the I2C bus. You should get I2C connection to chip and after that load firmware. I've no full datasheet of theses chips. with exception of the af9013 where this information is available: http://wenku.baidu.com/view/42240f72f242336c1eb95e08.html Those documents are rather useless. There is few versions of Linux AF9015 driver around the net, which are rather near sample SDK code. Try to find one. At this stage the CLK signal of the DVB-T chip may be missing or something is wrong elsewhere. If you have the datasheets... Any help will be appreciated. Best Regards, Wallak. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent
On 19/05/11 23:01, Sébastien RAILLARD (COEXSI) wrote: Yes, of course, but I don't find information that can help me to provide the correct format. Is-there a documentation somewhere that explains how patches must be formatted to be correctly tracked? This should help [http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches] -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
