[PATCH] media i.MX27 camera: remove legacy dma support
The i.MX27 dma support was introduced with the initial commit of
this driver and originally created by me. However, I never got
this stable due to the racy dma engine and used the EMMA engine
instead. As the DMA support is most probably unused and broken in
its current state, remove it. This also helps us to get rid of
another user of the legacy i.MX DMA support,
Also, remove the dependency on ARCH_MX* macros as these are scheduled
for removal.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Baruch Siach bar...@tkos.co.il
Cc: linux-media@vger.kernel.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mx2_camera.c | 183 --
2 files changed, 1 insertions(+), 184 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f574dc0..27b41b8 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -941,7 +941,7 @@ config VIDEO_MX2_HOSTSUPPORT
config VIDEO_MX2
tristate i.MX27/i.MX25 Camera Sensor Interface driver
- depends on VIDEO_DEV SOC_CAMERA (MACH_MX27 || ARCH_MX25)
+ depends on VIDEO_DEV SOC_CAMERA ARCH_MXC
select VIDEOBUF_DMA_CONTIG
select VIDEO_MX2_HOSTSUPPORT
---help---
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ec2410c..3b5c8eb 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -38,9 +38,6 @@
#include linux/videodev2.h
#include mach/mx2_cam.h
-#ifdef CONFIG_MACH_MX27
-#include mach/dma-mx1-mx2.h
-#endif
#include mach/hardware.h
#include asm/dma.h
@@ -330,41 +327,10 @@ static void mx2_camera_remove_device(struct
soc_camera_device *icd)
pcdev-icd = NULL;
}
-#ifdef CONFIG_MACH_MX27
-static void mx27_camera_dma_enable(struct mx2_camera_dev *pcdev)
-{
- u32 tmp;
-
- imx_dma_enable(pcdev-dma);
-
- tmp = readl(pcdev-base_csi + CSICR1);
- tmp |= CSICR1_RF_OR_INTEN;
- writel(tmp, pcdev-base_csi + CSICR1);
-}
-
-static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
-{
- struct mx2_camera_dev *pcdev = data;
- u32 status = readl(pcdev-base_csi + CSISR);
-
- if (status CSISR_SOF_INT pcdev-active) {
- u32 tmp;
-
- tmp = readl(pcdev-base_csi + CSICR1);
- writel(tmp | CSICR1_CLR_RXFIFO, pcdev-base_csi + CSICR1);
- mx27_camera_dma_enable(pcdev);
- }
-
- writel(CSISR_SOF_INT | CSISR_RFF_OR_INT, pcdev-base_csi + CSISR);
-
- return IRQ_HANDLED;
-}
-#else
static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
{
return IRQ_NONE;
}
-#endif /* CONFIG_MACH_MX27 */
static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
int state)
@@ -547,25 +513,6 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
if (mx27_camera_emma(pcdev)) {
goto out;
-#ifdef CONFIG_MACH_MX27
- } else if (cpu_is_mx27()) {
- int ret;
-
- if (pcdev-active == NULL) {
- ret = imx_dma_setup_single(pcdev-dma,
- videobuf_to_dma_contig(vb), vb-size,
- (u32)pcdev-base_dma + 0x10,
- DMA_MODE_READ);
- if (ret) {
- vb-state = VIDEOBUF_ERROR;
- wake_up(vb-done);
- goto out;
- }
-
- vb-state = VIDEOBUF_ACTIVE;
- pcdev-active = buf;
- }
-#endif
} else { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
@@ -1037,117 +984,6 @@ static int mx2_camera_reqbufs(struct soc_camera_device
*icd,
return 0;
}
-#ifdef CONFIG_MACH_MX27
-static void mx27_camera_frame_done(struct mx2_camera_dev *pcdev, int state)
-{
- struct videobuf_buffer *vb;
- struct mx2_buffer *buf;
- unsigned long flags;
- int ret;
-
- spin_lock_irqsave(pcdev-lock, flags);
-
- if (!pcdev-active) {
- dev_err(pcdev-dev, %s called with no active buffer!\n,
- __func__);
- goto out;
- }
-
- vb = pcdev-active-vb;
- buf = container_of(vb, struct mx2_buffer, vb);
- WARN_ON(list_empty(vb-queue));
- dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
- vb, vb-baddr, vb-bsize);
-
- /* _init is used to debug races, see comment in pxa_camera_reqbufs() */
- list_del_init(vb-queue);
- vb-state = state;
- do_gettimeofday(vb-ts);
- vb-field_count++;
-
- wake_up(vb-done);
-
- if (list_empty(pcdev-capture)) {
- pcdev-active = NULL;
- goto out;
- }
-
- pcdev-active = list_entry(pcdev-capture.next,
-
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Wednesday, August 24, 2011 06:05:44 Pawel Osciak wrote: Hi, On Mon, Aug 22, 2011 at 23:31, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, August 22, 2011 19:21:18 Laurent Pinchart wrote: Hi Hans, On Monday 22 August 2011 17:52:12 Hans Verkuil wrote: On Monday, August 22, 2011 17:42:36 Laurent Pinchart wrote: On Monday 22 August 2011 15:54:03 Guennadi Liakhovetski wrote: We discussed a bit more with Hans on IRC, and below is my attempt of a summary. Hans, please, correct me, if I misunderstood anything. Pawel, Sakari, Laurent: please, reply, whether you're ok with this. Sakari is on holidays this week. On Mon, 22 Aug 2011, Hans Verkuil wrote: On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote: [snip] It would be good if you also could have a look at my reply to this Pawel's mail: http://article.gmane.org/gmane.linux.drivers.video-input- infrastructure/36905 and, specifically, at the vb2_parse_planes() function in it. That's my understanding of what would be needed, if we preserve .queue_setup() and use your last suggestion to include struct v4l2_format in struct v4l2_create_buffers. vb2_parse_planes can be useful as a utility function that 'normal' drivers can call from the queue_setup. But vb2 should not parse the format directly, it should just pass it on to the driver through the queue_setup function. You also mention: All frame-format fields like fourcc code, width, height, colorspace are only input from the user. If the user didn't fill them in, they should not be used. I disagree with that. The user should fill in a full format description, just as with S/TRY_FMT. That's the information that the driver will use to set up the buffers. It could have weird rules like: if the fourcc is this, and the size is less than that, then we can allocate in this memory bank. It is also consistent with REQBUFS: there too the driver uses a full format (i.e. the last set format). I would modify queue_setup to something like this: int (*queue_setup)(struct vb2_queue *q, struct v4l2_format *fmt, unsigned int *num_buffers, unsigned int *num_planes, unsigned int sizes[], void *alloc_ctxs[]); Whether fmt is left to NULL in the reqbufs case, or whether the driver has to call g_fmt first before calling vb2 is something that could be decided by what is easiest to implement. 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user to the kernel, in which struct v4l2_format is embedded. The user _must_ fill in .type member of struct v4l2_format. For .type == V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix is used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these cases the user _must_ fill in .width, .height, .pixelformat, .field, .colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The user also _may_ optionally fill in any further buffer-size related fields, if it believes to have any special requirements to them. On a successful return from the ioctl() .count and .index fields are filled in by the kernel, .format stays unchanged. The user has to call VIDIOC_QUERYBUF to retrieve specific buffer information. Sounds good, just one question: we deliberately don't want to allow CREATE_BUFS to adjust the format in any way, as S_FMT could? That was my initial idea, but I don't think that holds water. The sequence probably has to be (ideal for a utility function): 1) make a copy of the sizeimage fields 2) call try_fmt 3) replace the sizeimage fields with the max value of the 'try' values and the copy. Then this final fmt can be returned. 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, call vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a second argument. vb2_create_bufs() in turn calls the .queue_setup() driver callback, whose prototype is modified as follows: int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, unsigned int *num_buffers, unsigned int *num_planes, unsigned int sizes[], void *alloc_ctxs[]); with create-format as a second argument. As pointed out above, this struct is not modified by V4L, instead, the usual arguments 3-6 are filled in by the
Re: [PATCH] media i.MX27 camera: remove legacy dma support
Sure, if it's broken, let's remove it. But there are a couple of points,
that we have to fix in this patch. Sorry, a stupid question: has this been
tested on i.MX27?
On Wed, 24 Aug 2011, Sascha Hauer wrote:
The i.MX27 dma support was introduced with the initial commit of
this driver and originally created by me. However, I never got
this stable due to the racy dma engine and used the EMMA engine
instead. As the DMA support is most probably unused and broken in
its current state, remove it. This also helps us to get rid of
another user of the legacy i.MX DMA support,
Also, remove the dependency on ARCH_MX* macros as these are scheduled
for removal.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Baruch Siach bar...@tkos.co.il
Cc: linux-media@vger.kernel.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mx2_camera.c | 183
--
2 files changed, 1 insertions(+), 184 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f574dc0..27b41b8 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -941,7 +941,7 @@ config VIDEO_MX2_HOSTSUPPORT
config VIDEO_MX2
tristate i.MX27/i.MX25 Camera Sensor Interface driver
- depends on VIDEO_DEV SOC_CAMERA (MACH_MX27 || ARCH_MX25)
+ depends on VIDEO_DEV SOC_CAMERA ARCH_MXC
select VIDEOBUF_DMA_CONTIG
select VIDEO_MX2_HOSTSUPPORT
---help---
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index ec2410c..3b5c8eb 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -38,9 +38,6 @@
#include linux/videodev2.h
#include mach/mx2_cam.h
-#ifdef CONFIG_MACH_MX27
-#include mach/dma-mx1-mx2.h
-#endif
#include mach/hardware.h
#include asm/dma.h
@@ -330,41 +327,10 @@ static void mx2_camera_remove_device(struct
soc_camera_device *icd)
pcdev-icd = NULL;
}
-#ifdef CONFIG_MACH_MX27
-static void mx27_camera_dma_enable(struct mx2_camera_dev *pcdev)
-{
- u32 tmp;
-
- imx_dma_enable(pcdev-dma);
-
- tmp = readl(pcdev-base_csi + CSICR1);
- tmp |= CSICR1_RF_OR_INTEN;
- writel(tmp, pcdev-base_csi + CSICR1);
-}
-
-static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
-{
- struct mx2_camera_dev *pcdev = data;
- u32 status = readl(pcdev-base_csi + CSISR);
-
- if (status CSISR_SOF_INT pcdev-active) {
- u32 tmp;
-
- tmp = readl(pcdev-base_csi + CSICR1);
- writel(tmp | CSICR1_CLR_RXFIFO, pcdev-base_csi + CSICR1);
- mx27_camera_dma_enable(pcdev);
- }
-
- writel(CSISR_SOF_INT | CSISR_RFF_OR_INT, pcdev-base_csi + CSISR);
-
- return IRQ_HANDLED;
-}
-#else
static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
{
return IRQ_NONE;
}
If this is really all, what's needed for i.MX27 ISR, let's remove it
completely. But maybe you could explain to me, how it is now supposed to
work on i.MX27. In probe() we have
irq_handler_t mx2_cam_irq_handler = cpu_is_mx25() ? mx25_camera_irq
: mx27_camera_irq;
...
err = request_irq(pcdev-irq_csi, mx2_cam_irq_handler, 0,
MX2_CAM_DRV_NAME, pcdev);
So, after this patch i.MX27 will always have a dummy camera ISR and just
use EMMA, right? Then maybe we have to make EMMA resource availability
compulsory on those SoCs, and not optional, as now? You'll have to make
emma the only possibility on i.MX27, then pcdev-use_emma will disappear,
locations like
if (mx27_camera_emma(pcdev)) {
csicr1 |= CSICR1_PRP_IF_EN | CSICR1_FCC |
CSICR1_RXFF_LEVEL(0);
} else if (cpu_is_mx27())
csicr1 |= CSICR1_SOF_INTEN | CSICR1_RXFF_LEVEL(2);
will need to be fixed.
-#endif /* CONFIG_MACH_MX27 */
static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
int state)
@@ -547,25 +513,6 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
if (mx27_camera_emma(pcdev)) {
goto out;
You can remove this goto now and instead
-#ifdef CONFIG_MACH_MX27
- } else if (cpu_is_mx27()) {
- int ret;
-
- if (pcdev-active == NULL) {
- ret = imx_dma_setup_single(pcdev-dma,
- videobuf_to_dma_contig(vb), vb-size,
- (u32)pcdev-base_dma + 0x10,
- DMA_MODE_READ);
- if (ret) {
- vb-state = VIDEOBUF_ERROR;
- wake_up(vb-done);
- goto out;
- }
-
- vb-state = VIDEOBUF_ACTIVE;
- pcdev-active = buf;
-
Re: [PATCH] media i.MX27 camera: remove legacy dma support
Hi Guennadi,
On Wed, Aug 24, 2011 at 09:19:24AM +0200, Guennadi Liakhovetski wrote:
Sure, if it's broken, let's remove it. But there are a couple of points,
that we have to fix in this patch. Sorry, a stupid question: has this been
tested on i.MX27?
Nope, I currently do not have mainline board support for this driver.
Could be a good opportunity to add some...
Your other points are totally valid and I will fix them in the next
round. Let's first see if someone proves me wrong and says this dma
support is indeed working.
- return IRQ_HANDLED;
-}
-#else
static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
{
return IRQ_NONE;
}
If this is really all, what's needed for i.MX27 ISR, let's remove it
completely. But maybe you could explain to me, how it is now supposed to
work on i.MX27. In probe() we have
irq_handler_t mx2_cam_irq_handler = cpu_is_mx25() ? mx25_camera_irq
: mx27_camera_irq;
...
err = request_irq(pcdev-irq_csi, mx2_cam_irq_handler, 0,
MX2_CAM_DRV_NAME, pcdev);
So, after this patch i.MX27 will always have a dummy camera ISR and just
use EMMA, right?
Yes, only the EMMA irq is used, we can remove this one.
Then maybe we have to make EMMA resource availability
compulsory on those SoCs, and not optional, as now? You'll have to make
emma the only possibility on i.MX27, then pcdev-use_emma will disappear,
locations like
ok.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: More vb2 notes
Hello, On Tuesday, August 23, 2011 3:54 PM Hans Verkuil wrote: I've been converting a Cisco internal driver to vb2 and while doing that I found a few issues. 1) I noticed that struct vb2_buffer doesn't have a list_head that the driver can use to hook it in its dma queue. That forces you to make your own buffer struct just to have your own list_head. This is done on purpose to keep clear separation between videobuf2 internal entries and the entries altered by the driver. Drivers usually embed struct vb2_buffer into their own structure, so adding a struct list head entry there is not a problem anyway. I really hated the old videobuf for the fact that it messed around driver's list entries (and requiring drivers to mess with videobuf list entries as well). I think vb2_buffer should either get a driver_entry or the 'done_entry' field can be assigned for driver use (since a buffer can't be owned by the driver and be on the done list at the same time). I abused 'done_entry' for now. Please don't do it! One more struct list_head doesn't really cost much. Using separate entry makes also the code much easier to understand. 2) videobuf2-dma-sg.c no longer calls dma_(un)map_sg()! The old videobuf-dma-sg.c did that for you. Is there any reason for this change? I had to manually add it to my driver. Right, this has been changed mainly because we had no experience with dma sg api. You are right that this should be moved back to the memory allocator. This can be done together with adding new memory allocator ops for buffer synchronization (buf_prepare/buf_finish), so dma_sync_* operations will be also moved to the allocator. 3) videobuf2-core.c uses this in __fill_v4l2_buffer: if (vb-num_planes_mapped == vb-num_planes) b-flags |= V4L2_BUF_FLAG_MAPPED; However, I see no code that ever decreases num_planes_mapped. And I also wonder what happens if vb2_mmap is called multiple times: num_planes_mapped will be increased so vb-num_planes_mapped vb-num_planes and the MAPPED flag is no longer set. This is a particular problem with libv4l2 since that tests for the MAPPED flag and will refuse e.g. format changes if it is set. Hmmm. I didn't know that there is anything that relies on the MAPPED flag. I will add support for this missing feature/bug asap. 4) It is not clear to me when vb2_queue_release should be called. Is it in close() when you close a filehandle that was used for streaming? Yes, this is the best place to call it. 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: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On Wednesday 24 August 2011 03:17:39 CJ wrote: On 23/08/11 19:47, Laurent Pinchart wrote: On Tuesday 23 August 2011 05:47:20 CJ wrote: On 22/08/11 22:15, Michael Jones wrote: I am trying to get the mt9p031 working from nand with a ubifs file system and I am having a few problems. /dev/media0 is not present unless I run: #mknod /dev/media0 c 251 0 #chown root:video /dev/media0 #media-ctl -p Enumerating entities media_open: Unable to enumerate entities for device /dev/media0 (Inappropriate ioctl for device) With the same rig/files it works fine running from EXT4 on an SD card. Any idea why this does not work on nand with ubifs? Is the OMAP3 ISP driver loaded ? Has it probed the device successfully ? Check the kernel log for OMAP3 ISP-related messages. Here is the version running from SD card: # dmesg | grep isp [0.265502] omap-iommu omap-iommu.0: isp registered [2.986541] omap3isp omap3isp: Revision 2.0 found [2.991577] omap-iommu omap-iommu.0: isp: version 1.1 [2.997406] omap3isp omap3isp: hist: DMA channel = 0 [3.006256] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 2160 Hz [3.011932] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz From NAND using UBIFS: # dmesg | grep isp [3.457061] omap3isp omap3isp: Revision 2.0 found [3.462036] omap-iommu omap-iommu.0: isp: version 1.1 [3.467620] omap3isp omap3isp: hist: DMA channel = 0 [3.472564] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 2160 Hz [3.478027] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz Seems to be missing: omap-iommu omap-iommu.0: isp registered Is that the issue? Why would this not work when running from NAND? I'm not sure, either, but I had a similar problem before using Laurent's patch below. IIRC, usually udev would create /dev/media0 from a cached list of /dev/*. Later modutils would come along and load the modules in the proper order (iommu, then omap3-isp) and everybody was happy. Occasionally, udev would fail to use the cached version of /dev/, and look through /sys/devices to re-create the devices in /dev/. When media0 was found, omap3-isp.ko would be loaded, but iommu had not yet been, presumably because it doesn't have an entry in /sys/devices/. So maybe udev is behaving differently for you on NAND than it did on the card? Either way, as I said, using Laurent's patch below did the job for me. I'm not sure why it doesn't work from NAND, but the iommu2 module needs to be loaded before the omap3-isp module. Alternatively you can compile the iommu2 module in the kernel with diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 49a4c75..3c87644 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -132,7 +132,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + bool config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS Thanks for the help! For some reason dmesg does not read early kernel stuff when in UBIFS from NAND. So when I went back and had a look the line I thought was not there is actually included. [0.276977] omap-iommu omap-iommu.0: isp registered So I guess everything is loading fine. I tried the patch and it didn't make a difference. Regarding what Michael said /dev/media0 is not created by udev when boot from NAND. I tried creating it manually with: #mknod /dev/media0 c 251 0 #chown root:video /dev/media0 But this does not work - outputs: # media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media_open: Unable to enumerate entities for device /dev/media0 (Inappropriate ioctl for device) So is there a problem with udev? There could be. What's the output of ls /sys/class/video4linux #ls /sys/class/video4linux v4l-subdev0 v4l-subdev3 v4l-subdev6 video0 video3 video6 v4l-subdev1 v4l-subdev4 v4l-subdev7 video1 video4 v4l-subdev2 v4l-subdev5 v4l-subdev8 video2 video5 Devices are correctly registered with the Linux kernel. Does 'ls /dev/v4l- subdev*' show the same entries ? If not you probably have a udev issue. -- 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
[PATCH] media: vb2: fix handling MAPPED buffer flag
MAPPED flag was set for the buffer only if all it's planes were mapped and
relied on a simple mapping counter. This assumption is really bogus,
especially because the buffers may be mapped multiple times. Also the
meaning of this flag for muliplane buffers was not really useful. This
patch fixes this issue by setting the MAPPED flag for the buffer if any of
it's planes is in use (what means that has been mapped at least once), so
MAPPED flag can be used as 'in_use' indicator.
Reported-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 67 ++
include/media/videobuf2-core.h |3 --
2 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index c360627..e89fd53 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -277,6 +277,41 @@ static int __verify_planes_array(struct vb2_buffer *vb,
struct v4l2_buffer *b)
}
/**
+ * __buffer_in_use() - return true if the buffer is in use and
+ * the queue cannot be freed (by the means of REQBUFS(0)) call
+ */
+static bool __buffer_in_use(struct vb2_queue *q, struct vb2_buffer *vb)
+{
+ unsigned int plane;
+ for (plane = 0; plane vb-num_planes; ++plane) {
+ /*
+* If num_users() has not been provided, call_memop
+* will return 0, apparently nobody cares about this
+* case anyway. If num_users() returns more than 1,
+* we are not the only user of the plane's memory.
+*/
+ if (call_memop(q, plane, num_users,
+ vb-planes[plane].mem_priv) 1)
+ return true;
+ }
+ return false;
+}
+
+/**
+ * __buffers_in_use() - return true if any buffers on the queue are in use and
+ * the queue cannot be freed (by the means of REQBUFS(0)) call
+ */
+static bool __buffers_in_use(struct vb2_queue *q)
+{
+ unsigned int buffer;
+ for (buffer = 0; buffer q-num_buffers; ++buffer) {
+ if (__buffer_in_use(q, q-bufs[buffer]))
+ return true;
+ }
+ return false;
+}
+
+/**
* __fill_v4l2_buffer() - fill in a struct v4l2_buffer with information to be
* returned to userspace
*/
@@ -335,7 +370,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct
v4l2_buffer *b)
break;
}
- if (vb-num_planes_mapped == vb-num_planes)
+ if (__buffer_in_use(q, vb))
b-flags |= V4L2_BUF_FLAG_MAPPED;
return ret;
@@ -400,33 +435,6 @@ static int __verify_mmap_ops(struct vb2_queue *q)
}
/**
- * __buffers_in_use() - return true if any buffers on the queue are in use and
- * the queue cannot be freed (by the means of REQBUFS(0)) call
- */
-static bool __buffers_in_use(struct vb2_queue *q)
-{
- unsigned int buffer, plane;
- struct vb2_buffer *vb;
-
- for (buffer = 0; buffer q-num_buffers; ++buffer) {
- vb = q-bufs[buffer];
- for (plane = 0; plane vb-num_planes; ++plane) {
- /*
-* If num_users() has not been provided, call_memop
-* will return 0, apparently nobody cares about this
-* case anyway. If num_users() returns more than 1,
-* we are not the only user of the plane's memory.
-*/
- if (call_memop(q, plane, num_users,
- vb-planes[plane].mem_priv) 1)
- return true;
- }
- }
-
- return false;
-}
-
-/**
* vb2_reqbufs() - Initiate streaming
* @q: videobuf2 queue
* @req: struct passed from userspace to vidioc_reqbufs handler in driver
@@ -1343,9 +1351,6 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct
*vma)
if (ret)
return ret;
- vb_plane-mapped = 1;
- vb-num_planes_mapped++;
-
dprintk(3, Buffer %d, plane %d successfully mapped\n, buffer, plane);
return 0;
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 496d6e5..984f2ba 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -75,7 +75,6 @@ struct vb2_mem_ops {
struct vb2_plane {
void*mem_priv;
- int mapped:1;
};
/**
@@ -147,7 +146,6 @@ struct vb2_queue;
* @done_entry:entry on the list that stores all buffers ready
to
* be dequeued to userspace
* @planes:private per-plane information; do not change
- * @num_planes_mapped: number of mapped planes; do not
[PATCH] media: vb2: change plane sizes array to unsigned int[]
Plane sizes array was declared as unsigned long[], while unsigned int is
more than enough for storing size of the video buffer. This patch reduces
the size of the array by definiting it as unsigned int[].
Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/atmel-isi.c |2 +-
drivers/media/video/marvell-ccic/mcam-core.c |2 +-
drivers/media/video/mem2mem_testdev.c|2 +-
drivers/media/video/mx3_camera.c |2 +-
drivers/media/video/pwc/pwc-if.c |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c |2 +-
drivers/media/video/s5p-fimc/fimc-core.c |2 +-
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|2 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c|2 +-
drivers/media/video/s5p-tv/mixer_video.c |2 +-
drivers/media/video/sh_mobile_ceu_camera.c |2 +-
drivers/media/video/vivi.c |2 +-
include/media/videobuf2-core.h |4 ++--
13 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7b89f00..5a4b2d7 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -249,7 +249,7 @@ static int atmel_isi_wait_status(struct atmel_isi *isi, int
wait_reset)
Videobuf operations
--*/
static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
+ unsigned int *nplanes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 83c1451..744cf37 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -884,7 +884,7 @@ static int mcam_read_setup(struct mcam_camera *cam)
*/
static int mcam_vb_queue_setup(struct vb2_queue *vq, unsigned int *nbufs,
- unsigned int *num_planes, unsigned long sizes[],
+ unsigned int *num_planes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct mcam_camera *cam = vb2_get_drv_priv(vq);
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
index 166bf93..0d0c0d5 100644
--- a/drivers/media/video/mem2mem_testdev.c
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -739,7 +739,7 @@ static const struct v4l2_ioctl_ops m2mtest_ioctl_ops = {
*/
static int m2mtest_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
+ unsigned int *nplanes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct m2mtest_ctx *ctx = vb2_get_drv_priv(vq);
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index c045b47..9ae7785 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -191,7 +191,7 @@ static void mx3_cam_dma_done(void *arg)
*/
static int mx3_videobuf_setup(struct vb2_queue *vq,
unsigned int *count, unsigned int *num_planes,
- unsigned long sizes[], void *alloc_ctxs[])
+ unsigned int sizes[], void *alloc_ctxs[])
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index 51ca358..a7e4f56 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -745,7 +745,7 @@ static int pwc_video_mmap(struct file *file, struct
vm_area_struct *vma)
/* Videobuf2 operations */
static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
+ unsigned int *nplanes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct pwc_device *pdev = vb2_get_drv_priv(vq);
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 0d730e5..e6afe5f 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -265,7 +265,7 @@ static unsigned int get_plane_size(struct fimc_frame *fr,
unsigned int plane)
}
static int queue_setup(struct vb2_queue *vq, unsigned int *num_buffers,
- unsigned int *num_planes, unsigned long sizes[],
+ unsigned
Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Fix the build break caused when CONFIG_MEDIA_CONTROLLER
option is disabled and if any sensor driver has to be used
between MC and non MC framework compatible devices.
For example,if tvp514x video decoder driver migrated to
MC framework is being built without CONFIG_MEDIA_CONTROLLER
option enabled, the following error messages will result.
drivers/built-in.o: In function `tvp514x_remove':
drivers/media/video/tvp514x.c:1285: undefined reference to
`media_entity_cleanup'
drivers/built-in.o: In function `tvp514x_probe':
drivers/media/video/tvp514x.c:1237: undefined reference to
`media_entity_init'
If the tvp514x is migrated to the MC framework, its Kconfig option should
depend on MEDIA_CONTROLLER.
The file containing definitions of media_entity_init and
media_entity_cleanup functions will not be built if that
config option is disabled. And this is corrected by
defining two dummy functions.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
include/media/media-entity.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index cd8bca6..c90916e 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -121,9 +121,18 @@ struct media_entity_graph {
int top;
};
+#ifdef CONFIG_MEDIA_CONTROLLER
int media_entity_init(struct media_entity *entity, u16 num_pads,
struct media_pad *pads, u16 extra_links);
void media_entity_cleanup(struct media_entity *entity);
+#else
+static inline int media_entity_init(struct media_entity *entity, u16
num_pads, + struct media_pad *pads, u16 extra_links)
+{
+ return 0;
+}
+static inline void media_entity_cleanup(struct media_entity *entity) {}
+#endif
int media_entity_create_link(struct media_entity *source, u16 source_pad,
struct media_entity *sink, u16 sink_pad, u32 flags);
--
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
[PATCH] omap_vout: Add poll() support
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap/omap_vout.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index a1f3c0f..cfc1705 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1184,6 +1184,15 @@ static void omap_vout_buffer_release(struct
videobuf_queue *q,
/*
* File operations
*/
+static unsigned int omap_vout_poll(struct file *file,
+ struct poll_table_struct *wait)
+{
+ struct omap_vout_device *vout = file-private_data;
+ struct videobuf_queue *q = vout-vbq;
+
+ return videobuf_poll_stream(file, q, wait);
+}
+
static void omap_vout_vm_open(struct vm_area_struct *vma)
{
struct omap_vout_device *vout = vma-vm_private_data;
@@ -2175,6 +2184,7 @@ static const struct v4l2_ioctl_ops vout_ioctl_ops = {
static const struct v4l2_file_operations omap_vout_fops = {
.owner = THIS_MODULE,
+ .poll = omap_vout_poll,
.unlocked_ioctl = video_ioctl2,
.mmap = omap_vout_mmap,
.open = omap_vout_open,
--
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
[GIT PULL for v3.2] OMAP3 ISP fixes and new sensor driver
Hi Mauro, The following changes since commit 9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e: [media] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028 (2011-08-06 09:52:47 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-sensors-next Javier Martin (1): mt9p031: Aptina (Micron) MT9P031 5MP sensor driver Laurent Pinchart (2): omap3isp: Don't accept pipelines with no video source as valid omap3isp: Move platform data definitions from isp.h to media/omap3isp.h Michael Jones (1): omap3isp: queue: fail QBUF if user buffer is too small drivers/media/video/Kconfig |7 + drivers/media/video/Makefile|1 + drivers/media/video/mt9p031.c | 963 ++ drivers/media/video/omap3isp/isp.h | 85 +--- drivers/media/video/omap3isp/ispccp2.c |4 +- drivers/media/video/omap3isp/ispqueue.c |4 + drivers/media/video/omap3isp/ispvideo.c | 14 +- include/media/mt9p031.h | 19 + include/media/omap3isp.h| 140 + 9 files changed, 1147 insertions(+), 90 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h create mode 100644 include/media/omap3isp.h -- 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 06/14] [media] cx18: Use current logging styles
On Sun, 2011-08-21 at 15:56 -0700, Joe Perches wrote:
Add pr_fmt.
Convert printks to pr_level.
Convert printks without KERN_level to appropriate pr_level.
Removed embedded prefixes when pr_fmt was added.
Use ##__VA_ARGS__ for variadic macros.
Coalesce format strings.
Signed-off-by: Joe Perches j...@perches.com
Hi Joe:
1. It is important to preserve the per-card prefixes emitted by the
driver: cx18-0, cx18-1, cx18-2, etc. With a quick skim, I think your
change preserves the format of all output messages (except removing
periods). Can you confirm this?
2. PLease don't add a pr_fmt() #define to exevry file. Just put one
where all the other CX18_*() macros are defined. Every file picks those
up.
Thanks,
Andy
---
drivers/media/video/cx18/cx18-alsa-main.c | 26 ++--
drivers/media/video/cx18/cx18-alsa-mixer.c |2 +
drivers/media/video/cx18/cx18-alsa-pcm.c| 12 +-
drivers/media/video/cx18/cx18-alsa.h| 32 +++---
drivers/media/video/cx18/cx18-audio.c |2 +
drivers/media/video/cx18/cx18-av-audio.c|2 +
drivers/media/video/cx18/cx18-av-core.c |2 +
drivers/media/video/cx18/cx18-av-firmware.c |2 +
drivers/media/video/cx18/cx18-av-vbi.c |1 +
drivers/media/video/cx18/cx18-controls.c|3 +
drivers/media/video/cx18/cx18-driver.c | 35 +++---
drivers/media/video/cx18/cx18-driver.h | 177
+++
drivers/media/video/cx18/cx18-dvb.c |2 +
drivers/media/video/cx18/cx18-fileops.c |9 +-
drivers/media/video/cx18/cx18-firmware.c|4 +-
drivers/media/video/cx18/cx18-gpio.c|2 +
drivers/media/video/cx18/cx18-i2c.c |2 +
drivers/media/video/cx18/cx18-io.c |2 +
drivers/media/video/cx18/cx18-ioctl.c |4 +-
drivers/media/video/cx18/cx18-irq.c |2 +
drivers/media/video/cx18/cx18-mailbox.c |2 +
drivers/media/video/cx18/cx18-queue.c |2 +
drivers/media/video/cx18/cx18-scb.c |2 +
drivers/media/video/cx18/cx18-streams.c |2 +
drivers/media/video/cx18/cx18-vbi.c |2 +
drivers/media/video/cx18/cx18-video.c |2 +
26 files changed, 201 insertions(+), 134 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-alsa-main.c
b/drivers/media/video/cx18/cx18-alsa-main.c
index a1e6c2a..99d1b01 100644
--- a/drivers/media/video/cx18/cx18-alsa-main.c
+++ b/drivers/media/video/cx18/cx18-alsa-main.c
@@ -22,6 +22,8 @@
* 02111-1307 USA
*/
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
#include linux/init.h
#include linux/slab.h
#include linux/module.h
@@ -42,11 +44,11 @@
int cx18_alsa_debug;
-#define CX18_DEBUG_ALSA_INFO(fmt, arg...) \
- do { \
- if (cx18_alsa_debug 2) \
- printk(KERN_INFO %s: fmt, cx18-alsa, ## arg); \
- } while (0);
+#define CX18_DEBUG_ALSA_INFO(fmt, ...) \
+do { \
+ if (cx18_alsa_debug 2) \
+ pr_info(fmt, ##__VA_ARGS__); \
+} while (0)
module_param_named(debug, cx18_alsa_debug, int, 0644);
MODULE_PARM_DESC(debug,
@@ -203,14 +205,13 @@ int cx18_alsa_load(struct cx18 *cx)
struct cx18_stream *s;
if (v4l2_dev == NULL) {
- printk(KERN_ERR cx18-alsa: %s: struct v4l2_device * is NULL\n,
-__func__);
+ pr_err(%s: struct v4l2_device * is NULL\n, __func__);
return 0;
}
cx = to_cx18(v4l2_dev);
if (cx == NULL) {
- printk(KERN_ERR cx18-alsa cx is NULL\n);
+ pr_err(cx is NULL\n);
return 0;
}
@@ -239,7 +240,7 @@ int cx18_alsa_load(struct cx18 *cx)
static int __init cx18_alsa_init(void)
{
- printk(KERN_INFO cx18-alsa: module loading...\n);
+ pr_info(module loading...\n);
cx18_ext_init = cx18_alsa_load;
return 0;
}
@@ -260,8 +261,7 @@ static int __exit cx18_alsa_exit_callback(struct device
*dev, void *data)
struct snd_cx18_card *cxsc;
if (v4l2_dev == NULL) {
- printk(KERN_ERR cx18-alsa: %s: struct v4l2_device * is NULL\n,
-__func__);
+ pr_err(%s: struct v4l2_device * is NULL\n, __func__);
return 0;
}
@@ -281,14 +281,14 @@ static void __exit cx18_alsa_exit(void)
struct device_driver *drv;
int ret;
- printk(KERN_INFO cx18-alsa: module unloading...\n);
+ pr_info(module unloading...\n);
drv = driver_find(cx18, pci_bus_type);
ret = driver_for_each_device(drv, NULL, NULL, cx18_alsa_exit_callback);
put_driver(drv);
cx18_ext_init = NULL;
- printk(KERN_INFO cx18-alsa: module unload complete\n);
+ pr_info(module unload complete\n);
}
Re: [PATCH] media: vb2: fix handling MAPPED buffer flag
On Wednesday, August 24, 2011 11:54:23 Marek Szyprowski wrote:
MAPPED flag was set for the buffer only if all it's planes were mapped and
relied on a simple mapping counter. This assumption is really bogus,
especially because the buffers may be mapped multiple times. Also the
meaning of this flag for muliplane buffers was not really useful. This
patch fixes this issue by setting the MAPPED flag for the buffer if any of
it's planes is in use (what means that has been mapped at least once), so
MAPPED flag can be used as 'in_use' indicator.
Looks good!
Tested-by: Hans Verkuil hans.verk...@cisco.com
This makes much more sense...
Regards,
Hans
Reported-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 67
++
include/media/videobuf2-core.h |3 --
2 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index c360627..e89fd53 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -277,6 +277,41 @@ static int __verify_planes_array(struct vb2_buffer *vb,
struct v4l2_buffer *b)
}
/**
+ * __buffer_in_use() - return true if the buffer is in use and
+ * the queue cannot be freed (by the means of REQBUFS(0)) call
+ */
+static bool __buffer_in_use(struct vb2_queue *q, struct vb2_buffer *vb)
+{
+ unsigned int plane;
+ for (plane = 0; plane vb-num_planes; ++plane) {
+ /*
+ * If num_users() has not been provided, call_memop
+ * will return 0, apparently nobody cares about this
+ * case anyway. If num_users() returns more than 1,
+ * we are not the only user of the plane's memory.
+ */
+ if (call_memop(q, plane, num_users,
+ vb-planes[plane].mem_priv) 1)
+ return true;
+ }
+ return false;
+}
+
+/**
+ * __buffers_in_use() - return true if any buffers on the queue are in use
and
+ * the queue cannot be freed (by the means of REQBUFS(0)) call
+ */
+static bool __buffers_in_use(struct vb2_queue *q)
+{
+ unsigned int buffer;
+ for (buffer = 0; buffer q-num_buffers; ++buffer) {
+ if (__buffer_in_use(q, q-bufs[buffer]))
+ return true;
+ }
+ return false;
+}
+
+/**
* __fill_v4l2_buffer() - fill in a struct v4l2_buffer with information to
be
* returned to userspace
*/
@@ -335,7 +370,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
break;
}
- if (vb-num_planes_mapped == vb-num_planes)
+ if (__buffer_in_use(q, vb))
b-flags |= V4L2_BUF_FLAG_MAPPED;
return ret;
@@ -400,33 +435,6 @@ static int __verify_mmap_ops(struct vb2_queue *q)
}
/**
- * __buffers_in_use() - return true if any buffers on the queue are in use
and
- * the queue cannot be freed (by the means of REQBUFS(0)) call
- */
-static bool __buffers_in_use(struct vb2_queue *q)
-{
- unsigned int buffer, plane;
- struct vb2_buffer *vb;
-
- for (buffer = 0; buffer q-num_buffers; ++buffer) {
- vb = q-bufs[buffer];
- for (plane = 0; plane vb-num_planes; ++plane) {
- /*
- * If num_users() has not been provided, call_memop
- * will return 0, apparently nobody cares about this
- * case anyway. If num_users() returns more than 1,
- * we are not the only user of the plane's memory.
- */
- if (call_memop(q, plane, num_users,
- vb-planes[plane].mem_priv) 1)
- return true;
- }
- }
-
- return false;
-}
-
-/**
* vb2_reqbufs() - Initiate streaming
* @q: videobuf2 queue
* @req: struct passed from userspace to vidioc_reqbufs handler in driver
@@ -1343,9 +1351,6 @@ int vb2_mmap(struct vb2_queue *q, struct
vm_area_struct *vma)
if (ret)
return ret;
- vb_plane-mapped = 1;
- vb-num_planes_mapped++;
-
dprintk(3, Buffer %d, plane %d successfully mapped\n, buffer, plane);
return 0;
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 496d6e5..984f2ba 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -75,7 +75,6 @@ struct vb2_mem_ops {
struct vb2_plane {
void*mem_priv;
- int mapped:1;
};
/**
@@ -147,7 +146,6 @@ struct vb2_queue;
* @done_entry: entry on the
RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart
[laurent.pinch...@ideasonboard.com] wrote:
On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Fix the build break caused when CONFIG_MEDIA_CONTROLLER
option is disabled and if any sensor driver has to be used
between MC and non MC framework compatible devices.
For example,if tvp514x video decoder driver migrated to
MC framework is being built without CONFIG_MEDIA_CONTROLLER
option enabled, the following error messages will result.
drivers/built-in.o: In function `tvp514x_remove':
drivers/media/video/tvp514x.c:1285: undefined reference to
`media_entity_cleanup'
drivers/built-in.o: In function `tvp514x_probe':
drivers/media/video/tvp514x.c:1237: undefined reference to
`media_entity_init'
If the tvp514x is migrated to the MC framework, its Kconfig option should
depend on MEDIA_CONTROLLER.
The same TVP514x driver is being used for both MC and non MC compatible
devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA
CONTROLLER, we cannot enable the driver for MC independent devices.
The file containing definitions of media_entity_init and
media_entity_cleanup functions will not be built if that
config option is disabled. And this is corrected by
defining two dummy functions.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
include/media/media-entity.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index cd8bca6..c90916e 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -121,9 +121,18 @@ struct media_entity_graph {
int top;
};
+#ifdef CONFIG_MEDIA_CONTROLLER
int media_entity_init(struct media_entity *entity, u16 num_pads,
struct media_pad *pads, u16 extra_links);
void media_entity_cleanup(struct media_entity *entity);
+#else
+static inline int media_entity_init(struct media_entity *entity, u16
num_pads, + struct media_pad *pads, u16 extra_links)
+{
+ return 0;
+}
+static inline void media_entity_cleanup(struct media_entity *entity) {}
+#endif
int media_entity_create_link(struct media_entity *source, u16 source_pad,
struct media_entity *sink, u16 sink_pad, u32 flags);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-inf
--
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: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
Hi, On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or better, port the AM35x driver to the MC API. -- 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: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
-Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, August 24, 2011 5:00 PM To: Ravi, Deepthy Cc: mche...@infradead.org; linux-media@vger.kernel.org; linux- ker...@vger.kernel.org; linux-o...@vger.kernel.org; Hiremath, Vaibhav Subject: Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and Hi, On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or [Hiremath, Vaibhav] No. I am not in favor of conditional compilation in driver code. better, port the AM35x driver to the MC API. [Hiremath, Vaibhav] Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? Thanks, Vaibhav -- 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: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or [Hiremath, Vaibhav] No. I am not in favor of conditional compilation in driver code. better, port the AM35x driver to the MC API. [Hiremath, Vaibhav] Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? Why should you break the API in unappropriated way? The patch is NACK, obviously. -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- 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: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
-Original Message- From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com] Sent: Wednesday, August 24, 2011 6:26 PM To: Hiremath, Vaibhav Cc: Laurent Pinchart; Ravi, Deepthy; mche...@infradead.org; linux- me...@vger.kernel.org; linux-ker...@vger.kernel.org; linux- o...@vger.kernel.org Subject: RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or [Hiremath, Vaibhav] No. I am not in favor of conditional compilation in driver code. better, port the AM35x driver to the MC API. [Hiremath, Vaibhav] Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? Why should you break the API in unappropriated way? [Hiremath, Vaibhav] Can you explain? Thanks, Vaibhav The patch is NACK, obviously. -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- 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: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
Hi Vaibhav, On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or No. I am not in favor of conditional compilation in driver code. Actually, thinking some more about this, you should make the tvp514x driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that the driver will become unusable by applications that are not MC-aware. Hosts/bridges don't have to export subdev nodes, they can just call subdev pad-level operations internally and let applications control the whole device through a single V4L2 video node. better, port the AM35x driver to the MC API. Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it doesn't have to expose them to userspace. -- 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
dma buffers for camera
Hello, could please anyone explain me a bit situation about using memory buffers for dma for video input devices? Unfortunately I don't understand it at all. I want to capture images 1600x1200 from 2 mpix sensor on i.mx27 board. I gave 8MB to mx2_camera device with dma_declare_coherent_memory. Unfortunately it seems to be not enough. In UYVY format I need 1600x1200x2 for one picture, it is cca 3.8MB. After some digging I noticed, that dma_alloc_coherent() is called three times and each time with the 3.8MB demand. Once it is directly from mx2_camera driver and two times from videobuf_dma_contig. OK, that is more than 8MB available, but why there are so big memory demands for one picture? I'm using gstremer for capturing, so it probably requests several buffers with VIDIOC_REQBUFS. Is this behaviour normal, even if there is explicitly noted that I want only one buffer? gst-launch \ v4l2src num-buffers=1 device=/dev/video1 ! \ video/x-raw-yuv,format=\(fourcc\)UYVY,width=$WIDTH,height=$HEIGHT ! \ jpegenc ! \ filesink location=col_image.jpg with best regards Jan -- Tato zpráva byla vytvořena převratným poštovním klientem Opery: http://www.opera.com/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: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
-Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, August 24, 2011 6:56 PM To: Hiremath, Vaibhav Cc: Ravi, Deepthy; mche...@infradead.org; linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org Subject: Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and Hi Vaibhav, On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or No. I am not in favor of conditional compilation in driver code. Actually, thinking some more about this, you should make the tvp514x driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that the driver will become unusable by applications that are not MC-aware. [Hiremath, Vaibhav] I am not referring to application here, there is no doubt that application must support non-MC devices. I should be able to use standard V4L2 streaming application and use it on streaming device node, the only change would be, for MC aware device, links need to be set before and for non-MC aware devices its default thing. Hosts/bridges don't have to export subdev nodes, they can just call subdev pad-level operations internally and let applications control the whole device through a single V4L2 video node. [Hiremath, Vaibhav] Agreed. That's what I thought. better, port the AM35x driver to the MC API. Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it doesn't have to expose them to userspace. [Hiremath, Vaibhav] Let me digest this. Thanks, Vaibhav -- 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 8/8] ARM: S5PV210: example of CMA private area for FIMC device on Goni board
Hi Marek/Kyungmin,
On Fri, Aug 19, 2011 at 04:27:44PM +0200, Marek Szyprowski wrote:
This patch is an example how device private CMA area can be activated.
It creates one CMA region and assigns it to the first s5p-fimc device on
Samsung Goni S5PC110 board.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/mach-goni.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index 14578f5..f766c45 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -26,6 +26,7 @@
#include linux/input.h
#include linux/gpio.h
#include linux/interrupt.h
+#include linux/dma-contiguous.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -857,6 +858,9 @@ static void __init goni_map_io(void)
static void __init goni_reserve(void)
{
s5p_mfc_reserve_mem(0x4300, 8 20, 0x5100, 8 20);
+
+ /* Create private 16MiB contiguous memory area for s5p-fimc.0 device */
+ dma_declare_contiguous(s5p_device_fimc0.dev, 16*SZ_1M, 0);
This is broken, since according to patch #0006, dma_declare_contiguous requires
a 4th param (limit) which you're not providing here.
Regards,
Sergio
}
static void __init goni_machine_init(void)
--
1.7.1.569.g6f426
--
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] [media] vp7045: fix buffer setup
On Fri, Aug 19, 2011 at 18:35:21 +0200, Florian Mickler wrote: On Wed, 10 Aug 2011 12:05:20 +0200 Florian Mickler flor...@mickler.org wrote: dvb_usb_device_init calls the frontend_attach method of this driver which uses vp7045_usb_ob. In order to have a buffer ready in vp7045_usb_op, it has to be allocated before that happens. Luckily we can use the whole private data as the buffer as it gets separately allocated on the heap via kzalloc in dvb_usb_device_init and is thus apt for use via usb_control_msg. This fixes a BUG: unable to handle kernel paging request at 1e78 reported by Tino Keitel and diagnosed by Dan Carpenter. References: https://bugzilla.kernel.org/show_bug.cgi?id=40062 Cc: v3.0.y sta...@kernel.org Tested-by: Tino Keitel tino.kei...@tikei.de Signed-off-by: Florian Mickler flor...@mickler.org ...ping... Even pinger. I can't see the patch in 3.1 git yet, and I'm using the patch on 3.0 kernels for 2 weeks now without problems. Regards, Tino -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex
Signed-off-by: Andreas Oberritter o...@linuxtv.org
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 23 +++
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index a716627..f433a88 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -31,7 +31,6 @@
#include linux/wait.h
#include linux/slab.h
#include linux/poll.h
-#include linux/semaphore.h
#include linux/module.h
#include linux/list.h
#include linux/freezer.h
@@ -108,7 +107,7 @@ struct dvb_frontend_private {
struct dvb_frontend_parameters parameters_in;
struct dvb_frontend_parameters parameters_out;
struct dvb_fe_events events;
- struct semaphore sem;
+ struct mutex lock;
struct list_head list_head;
wait_queue_head_t wait_queue;
struct task_struct *thread;
@@ -190,12 +189,12 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
if (flags O_NONBLOCK)
return -EWOULDBLOCK;
- up(fepriv-sem);
+ mutex_unlock(fepriv-lock);
ret = wait_event_interruptible (events-wait_queue,
events-eventw !=
events-eventr);
- if (down_interruptible (fepriv-sem))
+ if (mutex_lock_interruptible(fepriv-lock))
return -ERESTARTSYS;
if (ret 0)
@@ -556,7 +555,7 @@ static int dvb_frontend_thread(void *data)
set_freezable();
while (1) {
- up(fepriv-sem); /* is locked when we enter the
thread... */
+ mutex_unlock(fepriv-lock);/* is locked when we enter
the thread... */
restart:
timeout = wait_event_interruptible_timeout(fepriv-wait_queue,
dvb_frontend_should_wakeup(fe) || kthread_should_stop()
@@ -572,7 +571,7 @@ restart:
if (try_to_freeze())
goto restart;
- if (down_interruptible(fepriv-sem))
+ if (mutex_lock_interruptible(fepriv-lock))
break;
if (fepriv-reinitialise) {
@@ -704,7 +703,7 @@ static void dvb_frontend_stop(struct dvb_frontend *fe)
kthread_stop(fepriv-thread);
- sema_init(fepriv-sem, 1);
+ mutex_init(fepriv-lock);
fepriv-state = FESTATE_IDLE;
/* paranoia check in case a signal arrived */
@@ -773,7 +772,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
if (signal_pending(current))
return -EINTR;
- if (down_interruptible (fepriv-sem))
+ if (mutex_lock_interruptible(fepriv-lock))
return -EINTR;
fepriv-state = FESTATE_IDLE;
@@ -786,7 +785,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
if (IS_ERR(fe_thread)) {
ret = PTR_ERR(fe_thread);
printk(dvb_frontend_start: failed to start kthread (%d)\n,
ret);
- up(fepriv-sem);
+ mutex_unlock(fepriv-lock);
return ret;
}
fepriv-thread = fe_thread;
@@ -1535,7 +1534,7 @@ static int dvb_frontend_ioctl(struct file *file,
cmd == FE_DISEQC_RECV_SLAVE_REPLY))
return -EPERM;
- if (down_interruptible (fepriv-sem))
+ if (mutex_lock_interruptible(fepriv-lock))
return -ERESTARTSYS;
if ((cmd == FE_SET_PROPERTY) || (cmd == FE_GET_PROPERTY))
@@ -1545,7 +1544,7 @@ static int dvb_frontend_ioctl(struct file *file,
err = dvb_frontend_ioctl_legacy(file, cmd, parg);
}
- up(fepriv-sem);
+ mutex_unlock(fepriv-lock);
return err;
}
@@ -2115,7 +2114,7 @@ int dvb_register_frontend(struct dvb_adapter* dvb,
}
fepriv = fe-frontend_priv;
- sema_init(fepriv-sem, 1);
+ mutex_init(fepriv-lock);
init_waitqueue_head (fepriv-wait_queue);
init_waitqueue_head (fepriv-events.wait_queue);
mutex_init(fepriv-events.mtx);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] DVB: dvb_frontend: check function pointers on reinitialize
Signed-off-by: Andreas Oberritter o...@linuxtv.org
---
drivers/media/dvb/dvb-core/dvb_frontend.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index f433a88..79a3cc3 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -576,12 +576,10 @@ restart:
if (fepriv-reinitialise) {
dvb_frontend_init(fe);
- if (fepriv-tone != -1) {
+ if (fe-ops.set_tone fepriv-tone != -1)
fe-ops.set_tone(fe, fepriv-tone);
- }
- if (fepriv-voltage != -1) {
+ if (fe-ops.set_voltage fepriv-voltage != -1)
fe-ops.set_voltage(fe, fepriv-voltage);
- }
fepriv-reinitialise = 0;
}
--
1.7.2.5
--
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 1/2] DVB: dvb_frontend: convert semaphore to mutex
On Wed, Aug 24, 2011 at 1:33 PM, Andreas Oberritter o...@linuxtv.org wrote: Signed-off-by: Andreas Oberritter o...@linuxtv.org This may seem like a silly question, but *why* are you making this change? There is no explanation for what prompted it. Is it in response to some issue you encountered? I'm asking because in general dvb_frontend has a fairly complicated locking model, and unless there is a compelling reason to make changes I would be against it. In other words, this is a bad place for arbitrary cleanup patches. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex
On Wed, Aug 24, 2011 at 2:02 PM, Andreas Oberritter o...@linuxtv.org wrote: It's impossible to clean up dvb_frontend.c, which looks quite unmaintained, without touching it. It is quite unmaintained. In fact, it was broken for numerous cards for almost two years before I finally got someone in the Hauppauge UK office to mail me a couple of affected boards to test with. Now that it works, I'm very hesitant to see any chances made unless there is a *very* good reason. It's just too damn easy to introduce subtle bugs in there that work for your card but cause breakage for others. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex
On 24.08.2011 20:06, Devin Heitmueller wrote: On Wed, Aug 24, 2011 at 2:02 PM, Andreas Oberritter o...@linuxtv.org wrote: It's impossible to clean up dvb_frontend.c, which looks quite unmaintained, without touching it. It is quite unmaintained. In fact, it was broken for numerous cards for almost two years before I finally got someone in the Hauppauge UK office to mail me a couple of affected boards to test with. Now that it works, I'm very hesitant to see any chances made unless there is a *very* good reason. It's just too damn easy to introduce subtle bugs in there that work for your card but cause breakage for others. Instead of wasting your time with theory, you could have easily reviewed my patch. It's really *very* simple any anyone having used semphores or mutexes in the kernel should be able to see that. -- 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 1/1] Add driver support for ITE IT9135 device
On Friday 05 of August 2011, jasondong wrote: This is DVB USB Linux driver for ITEtech IT9135 base USB TV module. It supported the IT9135 AX and BX chip versions. Hi, The quick review by crop@freenode was: I quick check it and didnt like much since it is not plitted logically correct, as usb-bridge, demod and tuner. now all are rather much one big blob. so I guess you have to split it into pieces in a way other dvb drivers already in kernel tree are done. Unfortunately I don't know which existing driver is the best example on how to do things. ps. are the IT9135 docs available anywhere? ps2. on current linus 3.1 git + your 2 patches it is at least detected (cannot test more yet - no dbv-t signal here; it's to be available in incoming days) [ 1152.752132] usb 2-2: new high speed USB device number 10 using ehci_hcd [ 1152.820365] hub 2-0:1.0: unable to enumerate USB device on port 2 [ 1153.156792] hub 6-0:1.0: unable to enumerate USB device on port 2 [ 1157.056107] usb 2-1: new high speed USB device number 11 using ehci_hcd [ 1157.192287] usb 2-1: New USB device found, idVendor=048d, idProduct=9005 [ 1157.192297] usb 2-1: New USB device strings: Mfr=1, Product=0, SerialNumber=3 [ 1157.192304] usb 2-1: Manufacturer: ITE Technologies, Inc. [ 1157.192309] usb 2-1: SerialNumber: AF010202071 [ 1157.193145] dvb-usb: found a 'ITEtech USB2.0 DVB-T Recevier' in cold state, will try to load a firmware [ 1157.196882] dvb-usb: downloading firmware from file 'dvb-usb-it9135.fw' [ 1157.198578] IT9135: This is IT9135 chip v1 [ 1157.198678] IT9135: ~~~ .Fw file only include Omega1 firmware, Scripts12!! [ 1157.198684] IT9135: = [ 1157.198689] IT9135: DRIVER_RELEASE_VERSION:v11.08.02.1 [ 1157.198694] IT9135: FW_RELEASE_VERSION:V1_0_26_2 [ 1157.198700] IT9135: API_RELEASE_VERSION: 203.20110426.0 [ 1157.198705] IT9135: = [ 1157.504659] IT9135: it9135_device_init success!! [ 1157.504686] dvb-usb: found a 'ITEtech USB2.0 DVB-T Recevier' in warm state. [ 1157.504708] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 1157.505522] DVB: registering new adapter (ITEtech USB2.0 DVB-T Recevier) [ 1157.506763] DVB: registering adapter 0 frontend 0 (IT9135 USB DVB-T)... [ 1157.506920] dvb-usb: ITEtech USB2.0 DVB-T Recevier successfully initialized and connected. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex
On 24.08.2011 19:54, Devin Heitmueller wrote: On Wed, Aug 24, 2011 at 1:33 PM, Andreas Oberritter o...@linuxtv.org wrote: Signed-off-by: Andreas Oberritter o...@linuxtv.org This may seem like a silly question, but *why* are you making this change? There is no explanation for what prompted it. Is it in response to some issue you encountered? A semaphore with only one unit is nothing but a mutex. Using a mutex structure decreases memory footprint and improves readability. I'm asking because in general dvb_frontend has a fairly complicated locking model, and unless there is a compelling reason to make changes I would be against it. The lock is part of fepriv, which is local to dvb_frontend.c. The patch is really simple. In other words, this is a bad place for arbitrary cleanup patches. It's impossible to clean up dvb_frontend.c, which looks quite unmaintained, without touching it. 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
[PATCH 2/7 v5] V4L: add two new ioctl()s for multi-size videobuffer management
A possibility to preallocate and initialise buffers of different sizes
in V4L2 is required for an efficient implementation of a snapshot
mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
VIDIOC_PREPARE_BUF and defines respective data structures.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-compat-ioctl32.c | 67 +---
drivers/media/video/v4l2-ioctl.c | 29
include/linux/videodev2.h | 15 ++
include/media/v4l2-ioctl.h|2 +
4 files changed, 105 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 61979b7..85758d2 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -159,11 +159,16 @@ struct v4l2_format32 {
} fmt;
};
-static int get_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+struct v4l2_create_buffers32 {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format32format; /* filled in by the user, plane
sizes calculated by the driver */
+ __u32 reserved[8];
+};
+
+static int __get_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
{
- if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_format32)) ||
- get_user(kp-type, up-type))
- return -EFAULT;
switch (kp-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
@@ -192,11 +197,24 @@ static int get_v4l2_format32(struct v4l2_format *kp,
struct v4l2_format32 __user
}
}
-static int put_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+static int get_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+{
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_format32)) ||
+ get_user(kp-type, up-type))
+ return -EFAULT;
+ return __get_v4l2_format32(kp, up);
+}
+
+static int get_v4l2_create32(struct v4l2_create_buffers *kp, struct
v4l2_create_buffers32 __user *up)
+{
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_create_buffers32)) ||
+ copy_from_user(kp, up, offsetof(struct v4l2_create_buffers32,
format.fmt)))
+ return -EFAULT;
+ return __get_v4l2_format32(kp-format, up-format);
+}
+
+static int __put_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
{
- if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_format32)) ||
- put_user(kp-type, up-type))
- return -EFAULT;
switch (kp-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
@@ -225,6 +243,22 @@ static int put_v4l2_format32(struct v4l2_format *kp,
struct v4l2_format32 __user
}
}
+static int put_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+{
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_format32)) ||
+ put_user(kp-type, up-type))
+ return -EFAULT;
+ return __put_v4l2_format32(kp, up);
+}
+
+static int put_v4l2_create32(struct v4l2_create_buffers *kp, struct
v4l2_create_buffers32 __user *up)
+{
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_create_buffers32))
||
+ copy_to_user(up, kp, offsetof(struct v4l2_create_buffers32,
format.fmt)))
+ return -EFAULT;
+ return __put_v4l2_format32(kp-format, up-format);
+}
+
struct v4l2_standard32 {
__u32index;
__u32id[2]; /* __u64 would get the alignment wrong */
@@ -702,6 +736,8 @@ static int put_v4l2_event32(struct v4l2_event *kp, struct
v4l2_event32 __user *u
#define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
#define VIDIOC_TRY_EXT_CTRLS32 _IOWR('V', 73, struct v4l2_ext_controls32)
#defineVIDIOC_DQEVENT32_IOR ('V', 89, struct v4l2_event32)
+#define VIDIOC_CREATE_BUFS32 _IOWR('V', 92, struct v4l2_create_buffers32)
+#define VIDIOC_PREPARE_BUF32 _IOW ('V', 93, struct v4l2_buffer32)
#define VIDIOC_OVERLAY32 _IOW ('V', 14, s32)
#define VIDIOC_STREAMON32 _IOW ('V', 18, s32)
@@ -721,6 +757,7 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
struct v4l2_standard v2s;
struct v4l2_ext_controls v2ecs;
[PATCH 0/7 v5] new ioctl()s and soc-camera implementation
This patch set is now trying to implement our most recent decisions. Any improvements should be doable as incremental patches. As long as we are happy with ioctl()s themselves, the rest can be improved. I'll quote my earlier email with our strategic design decisions: 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user to the kernel, in which struct v4l2_format is embedded. The user _must_ fill in .type member of struct v4l2_format. For .type == V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix is used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these cases the user _must_ fill in .width, .height, .pixelformat, .field, .colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The user also _may_ optionally fill in any further buffer-size related fields, if it believes to have any special requirements to them. On a successful return from the ioctl() .count and .index fields are filled in by the kernel, .format stays unchanged. The user has to call VIDIOC_QUERYBUF to retrieve specific buffer information. 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, call vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a second argument. vb2_create_bufs() in turn calls the .queue_setup() driver callback, whose prototype is modified as follows: int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, unsigned int *num_buffers, unsigned int *num_planes, unsigned int sizes[], void *alloc_ctxs[]); with create-format as a second argument. As pointed out above, this struct is not modified by V4L, instead, the usual arguments 3-6 are filled in by the driver, which are then used by vb2_create_bufs() to call __vb2_queue_alloc(). 3. vb2_reqbufs() shall call .queue_setup() with fmt == NULL, which will be a signal to the driver to use the current format. I also split out ioctl() documentation. I'm sure it's still not perfect and, being a favourite target for improvement suggestions in the past, I humbly propose to leave any comma fixes to incremental patches too. BTW, yes, I did try to replace various constants with '...;' links, it didn't work for me. Thanks Guennadi Guennadi Liakhovetski (7): V4L: add a new videobuf2 buffer state VB2_BUF_STATE_PREPARED V4L: add two new ioctl()s for multi-size videobuffer management V4L: document the new VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctl()s V4L: vb2: prepare to support multi-size buffers V4L: vb2: add support for buffers of different sizes on a single queue V4L: sh-mobile-ceu-camera: prepare to support multi-size buffers V4L: soc-camera: add 2 new ioctl() handlers Documentation/DocBook/media/v4l/io.xml | 17 + Documentation/DocBook/media/v4l/v4l2.xml |2 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 147 + .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96 ++ drivers/media/video/atmel-isi.c|6 +- drivers/media/video/marvell-ccic/mcam-core.c |3 +- drivers/media/video/mem2mem_testdev.c |7 +- drivers/media/video/mx3_camera.c |1 + drivers/media/video/pwc/pwc-if.c |6 +- drivers/media/video/s5p-fimc/fimc-capture.c|6 +- drivers/media/video/s5p-fimc/fimc-core.c |6 +- drivers/media/video/s5p-mfc/s5p_mfc_dec.c |7 +- drivers/media/video/s5p-mfc/s5p_mfc_enc.c |5 +- drivers/media/video/s5p-tv/mixer_video.c |4 +- drivers/media/video/sh_mobile_ceu_camera.c | 122 +--- drivers/media/video/soc_camera.c | 33 ++- drivers/media/video/v4l2-compat-ioctl32.c | 67 - drivers/media/video/v4l2-ioctl.c | 29 ++ drivers/media/video/videobuf2-core.c | 341 drivers/media/video/vivi.c |6 +- include/linux/videodev2.h | 15 + include/media/v4l2-ioctl.h |2 + include/media/videobuf2-core.h | 39 ++- 23 files changed, 804 insertions(+), 163 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml -- 1.7.2.5 -- 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 6/7 v5] V4L: sh-mobile-ceu-camera: prepare to support multi-size buffers
Prepare the sh_mobile_ceu_camera friver to support the new
VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctl()s. The .queue_setup()
vb2 operation must be able to handle buffer sizes, provided by the
caller, and the .buf_prepare() operation must not use the currently
configured frame format for its operation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/sh_mobile_ceu_camera.c | 121 ++--
1 files changed, 78 insertions(+), 43 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index db3a24d..08af456 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -90,7 +90,6 @@
struct sh_mobile_ceu_buffer {
struct vb2_buffer vb; /* v4l buffer must be first */
struct list_head queue;
- enum v4l2_mbus_pixelcode code;
};
struct sh_mobile_ceu_dev {
@@ -100,7 +99,8 @@ struct sh_mobile_ceu_dev {
unsigned int irq;
void __iomem *base;
- unsigned long video_limit;
+ size_t video_limit;
+ size_t buf_total;
spinlock_t lock;/* Protects video buffer lists */
struct list_head capture;
@@ -192,6 +192,12 @@ static int sh_mobile_ceu_soft_reset(struct
sh_mobile_ceu_dev *pcdev)
/*
* Videobuf operations
*/
+
+/*
+ * .queue_setup() is called to check, whether the driver can accept the
+ * requested number of buffers and to fill in plane sizes
+ * for the current frame format if required
+ */
static int sh_mobile_ceu_videobuf_setup(struct vb2_queue *vq,
const struct v4l2_format *fmt,
unsigned int *count, unsigned int *num_planes,
@@ -200,25 +206,43 @@ static int sh_mobile_ceu_videobuf_setup(struct vb2_queue
*vq,
struct soc_camera_device *icd = container_of(vq, struct
soc_camera_device, vb2_vidq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct sh_mobile_ceu_dev *pcdev = ici-priv;
- int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
+ int bytes_per_line;
+ unsigned int height;
+ size_t size;
+
+ if (fmt) {
+ const struct soc_camera_format_xlate *xlate =
soc_camera_xlate_by_fourcc(icd,
+
fmt-fmt.pix.pixelformat);
+ bytes_per_line = soc_mbus_bytes_per_line(fmt-fmt.pix.width,
+xlate-host_fmt);
+ height = fmt-fmt.pix.height;
+ } else {
+ /* Called from VIDIOC_REQBUFS or in compatibility mode */
+ bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
icd-current_fmt-host_fmt);
-
+ height = icd-user_height;
+ }
if (bytes_per_line 0)
return bytes_per_line;
+ sizes[0] = bytes_per_line * height;
+
*num_planes = 1;
- pcdev-sequence = 0;
- sizes[0] = bytes_per_line * icd-user_height;
alloc_ctxs[0] = pcdev-alloc_ctx;
+ if (!vq-num_buffers)
+ pcdev-sequence = 0;
+
if (!*count)
*count = 2;
- if (pcdev-video_limit) {
- if (PAGE_ALIGN(sizes[0]) * *count pcdev-video_limit)
- *count = pcdev-video_limit / PAGE_ALIGN(sizes[0]);
- }
+ size = PAGE_ALIGN(sizes[0]) * *count;
+
+ if (pcdev-video_limit
+ size + pcdev-buf_total pcdev-video_limit)
+ *count = (pcdev-video_limit - pcdev-buf_total) /
+ PAGE_ALIGN(sizes[0]);
dev_dbg(icd-parent, count=%d, size=%lu\n, *count, sizes[0]);
@@ -331,23 +355,40 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev
*pcdev)
static int sh_mobile_ceu_videobuf_prepare(struct vb2_buffer *vb)
{
+ struct sh_mobile_ceu_buffer *buf = to_ceu_vb(vb);
+
+ /* Added list head initialization on alloc */
+ WARN(!list_empty(buf-queue), Buffer %p on queue!\n, vb);
+
+ return 0;
+}
+
+static void sh_mobile_ceu_videobuf_queue(struct vb2_buffer *vb)
+{
struct soc_camera_device *icd = container_of(vb-vb2_queue, struct
soc_camera_device, vb2_vidq);
- struct sh_mobile_ceu_buffer *buf;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct sh_mobile_ceu_dev *pcdev = ici-priv;
+ struct sh_mobile_ceu_buffer *buf = to_ceu_vb(vb);
+ unsigned long size;
int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
[PATCH 7/7 v5] V4L: soc-camera: add 2 new ioctl() handlers
This patch adds two new ioctl() handlers: .vidioc_create_bufs() and
.vidioc_prepare_buf() for compliant vb2 soc-camera hosts.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/soc_camera.c | 33 +++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index ac23916..5943235 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -318,6 +318,32 @@ static int soc_camera_dqbuf(struct file *file, void *priv,
return vb2_dqbuf(icd-vb2_vidq, p, file-f_flags O_NONBLOCK);
}
+static int soc_camera_create_bufs(struct file *file, void *priv,
+ struct v4l2_create_buffers *create)
+{
+ struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+
+ /* videobuf2 only */
+ if (ici-ops-init_videobuf)
+ return -EINVAL;
+ else
+ return vb2_create_bufs(icd-vb2_vidq, create);
+}
+
+static int soc_camera_prepare_buf(struct file *file, void *priv,
+ const struct v4l2_buffer *b)
+{
+ struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+
+ /* videobuf2 only */
+ if (ici-ops-init_videobuf)
+ return -EINVAL;
+ else
+ return vb2_prepare_buf(icd-vb2_vidq, b);
+}
+
/* Always entered with .video_lock held */
static int soc_camera_init_user_formats(struct soc_camera_device *icd)
{
@@ -1101,6 +1127,7 @@ static int soc_camera_probe(struct soc_camera_device *icd)
if (!control || !control-driver || !dev_get_drvdata(control) ||
!try_module_get(control-driver-owner)) {
icl-del_device(icd);
+ ret = -ENODEV;
goto enodrv;
}
}
@@ -1366,19 +1393,21 @@ static int soc_camera_device_register(struct
soc_camera_device *icd)
static const struct v4l2_ioctl_ops soc_camera_ioctl_ops = {
.vidioc_querycap = soc_camera_querycap,
+ .vidioc_try_fmt_vid_cap = soc_camera_try_fmt_vid_cap,
.vidioc_g_fmt_vid_cap= soc_camera_g_fmt_vid_cap,
- .vidioc_enum_fmt_vid_cap = soc_camera_enum_fmt_vid_cap,
.vidioc_s_fmt_vid_cap= soc_camera_s_fmt_vid_cap,
+ .vidioc_enum_fmt_vid_cap = soc_camera_enum_fmt_vid_cap,
.vidioc_enum_input = soc_camera_enum_input,
.vidioc_g_input = soc_camera_g_input,
.vidioc_s_input = soc_camera_s_input,
.vidioc_s_std= soc_camera_s_std,
.vidioc_enum_framesizes = soc_camera_enum_fsizes,
.vidioc_reqbufs = soc_camera_reqbufs,
- .vidioc_try_fmt_vid_cap = soc_camera_try_fmt_vid_cap,
.vidioc_querybuf = soc_camera_querybuf,
.vidioc_qbuf = soc_camera_qbuf,
.vidioc_dqbuf= soc_camera_dqbuf,
+ .vidioc_create_bufs = soc_camera_create_bufs,
+ .vidioc_prepare_buf = soc_camera_prepare_buf,
.vidioc_streamon = soc_camera_streamon,
.vidioc_streamoff= soc_camera_streamoff,
.vidioc_queryctrl= soc_camera_queryctrl,
--
1.7.2.5
--
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/7 v5] V4L: document the new VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctl()s
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Hans Verkuil hverk...@xs4all.nl Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Marek Szyprowski m.szyprow...@samsung.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Pawel Osciak pa...@osciak.com Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/media/v4l/io.xml | 17 +++ Documentation/DocBook/media/v4l/v4l2.xml |2 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 147 .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96 + 4 files changed, 262 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 227e7ac..ff03dd2 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -927,6 +927,23 @@ ioctl is called./entry Applications set or clear this flag before calling the constantVIDIOC_QBUF/constant ioctl./entry /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry + entry0x0400/entry + entryCaches do not have to be invalidated for this buffer. +Typically applications shall use this flag if the data captured in the buffer +is not going to be touched by the CPU, instead the buffer will, probably, be +passed on to a DMA-capable hardware unit for further processing or output. +/entry + /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry + entry0x0800/entry + entryCaches do not have to be cleaned for this buffer. +Typically applications shall use this flag for output buffers if the data +in this buffer has not been created by the CPU but by some DMA-capable unit, +in which case caches have not been used./entry + /row /tbody /tgroup /table diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 0d05e87..06bb179 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -462,6 +462,7 @@ and discussions on the V4L mailing list./revremark sub-close; sub-ioctl; !-- All ioctls go here. -- +sub-create-bufs; sub-cropcap; sub-dbg-g-chip-ident; sub-dbg-g-register; @@ -504,6 +505,7 @@ and discussions on the V4L mailing list./revremark sub-queryctrl; sub-query-dv-preset; sub-querystd; +sub-prepare-buf; sub-reqbufs; sub-s-hw-freq-seek; sub-streamon; diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml new file mode 100644 index 000..eb99604 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -0,0 +1,147 @@ +refentry id=vidioc-create-bufs + refmeta +refentrytitleioctl VIDIOC_CREATE_BUFS/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_CREATE_BUFS/refname +refpurposeCreate buffers for Memory Mapped or User Pointer I/O/refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_create_buffers *parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_CREATE_BUFS/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +paraThis ioctl is used to create buffers for link linkend=mmapmemory +mapped/link or link linkend=userpuser pointer/link +I/O. It can be used as an alternative or in addition to the +constantVIDIOC_REQBUFS/constant ioctl, when a tighter control over buffers +is required. This ioctl can be called multiple times to create buffers of +different sizes./para + +paraTo allocate device buffers applications initialize relevant fields of +the structnamev4l2_create_buffers/structname structure. They set the +structfieldtype/structfield field in the +structnamev4l2_format/structname structure, embedded in this +structure, to the respective stream or buffer type. +structfieldcount/structfield must be set to the number of required buffers. +structfieldmemory/structfield specifies the
[PATCH 4/7 v5] V4L: vb2: prepare to support multi-size buffers
In preparation for the forthcoming VIDIOC_CREATE_BUFS ioctl add a
const struct v4l2_format * argument to the .queue_setup() vb2
operation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/atmel-isi.c |6 +++---
drivers/media/video/marvell-ccic/mcam-core.c |3 ++-
drivers/media/video/mem2mem_testdev.c|7 ---
drivers/media/video/mx3_camera.c |1 +
drivers/media/video/pwc/pwc-if.c |6 +++---
drivers/media/video/s5p-fimc/fimc-capture.c |6 +++---
drivers/media/video/s5p-fimc/fimc-core.c |6 +++---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|7 ---
drivers/media/video/s5p-mfc/s5p_mfc_enc.c|5 +++--
drivers/media/video/s5p-tv/mixer_video.c |4 ++--
drivers/media/video/sh_mobile_ceu_camera.c |1 +
drivers/media/video/videobuf2-core.c |6 +++---
drivers/media/video/vivi.c |6 +++---
include/media/videobuf2-core.h |6 +++---
14 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 3e3d4cc..7c41a87 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -249,9 +249,9 @@ static int atmel_isi_wait_status(struct atmel_isi *isi, int
wait_reset)
/* --
Videobuf operations
--*/
-static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
- void *alloc_ctxs[])
+static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned long sizes[], void *alloc_ctxs[])
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 83c1451..65517c8 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -883,7 +883,8 @@ static int mcam_read_setup(struct mcam_camera *cam)
* Videobuf2 interface code.
*/
-static int mcam_vb_queue_setup(struct vb2_queue *vq, unsigned int *nbufs,
+static int mcam_vb_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt, unsigned int *nbufs,
unsigned int *num_planes, unsigned long sizes[],
void *alloc_ctxs[])
{
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
index 166bf93..c0e633f 100644
--- a/drivers/media/video/mem2mem_testdev.c
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -738,9 +738,10 @@ static const struct v4l2_ioctl_ops m2mtest_ioctl_ops = {
* Queue operations
*/
-static int m2mtest_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
- void *alloc_ctxs[])
+static int m2mtest_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned long sizes[], void *alloc_ctxs[])
{
struct m2mtest_ctx *ctx = vb2_get_drv_priv(vq);
struct m2mtest_q_data *q_data;
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 3f37522f..6bfbce9 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -191,6 +191,7 @@ static void mx3_cam_dma_done(void *arg)
* Calculate the __buffer__ (not data) size and number of buffers.
*/
static int mx3_videobuf_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
unsigned int *count, unsigned int *num_planes,
unsigned long sizes[], void *alloc_ctxs[])
{
diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index 51ca358..d6ff2c9 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -744,9 +744,9 @@ static int pwc_video_mmap(struct file *file, struct
vm_area_struct *vma)
/***/
/* Videobuf2 operations */
-static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int
[PATCH 5/7 v5] V4L: vb2: add support for buffers of different sizes on a single queue
The two recently added ioctl()s VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF
allow user-space applications to allocate video buffers of different
sizes and hand them over to the driver for fast switching between
different frame formats. This patch adds support for buffers of different
sizes on the same buffer-queue to vb2.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/videobuf2-core.c | 278 --
include/media/videobuf2-core.h | 31 +++--
2 files changed, 252 insertions(+), 57 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 8a81a89..fed6f2d 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -44,7 +44,7 @@ module_param(debug, int, 0644);
* __vb2_buf_mem_alloc() - allocate video memory for the given buffer
*/
static int __vb2_buf_mem_alloc(struct vb2_buffer *vb,
- unsigned long *plane_sizes)
+ const unsigned long *plane_sizes)
{
struct vb2_queue *q = vb-vb2_queue;
void *mem_priv;
@@ -110,13 +110,22 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
* __setup_offsets() - setup unique offsets (cookies) for every plane in
* every buffer on the queue
*/
-static void __setup_offsets(struct vb2_queue *q)
+static void __setup_offsets(struct vb2_queue *q, unsigned int n)
{
unsigned int buffer, plane;
struct vb2_buffer *vb;
- unsigned long off = 0;
+ unsigned long off;
- for (buffer = 0; buffer q-num_buffers; ++buffer) {
+ if (q-num_buffers) {
+ struct v4l2_plane *p;
+ vb = q-bufs[q-num_buffers - 1];
+ p = vb-v4l2_planes[vb-num_planes - 1];
+ off = PAGE_ALIGN(p-m.mem_offset + p-length);
+ } else {
+ off = 0;
+ }
+
+ for (buffer = q-num_buffers; buffer q-num_buffers + n; ++buffer) {
vb = q-bufs[buffer];
if (!vb)
continue;
@@ -142,7 +151,7 @@ static void __setup_offsets(struct vb2_queue *q)
*/
static int __vb2_queue_alloc(struct vb2_queue *q, enum v4l2_memory memory,
unsigned int num_buffers, unsigned int num_planes,
-unsigned long plane_sizes[])
+const unsigned long *plane_sizes)
{
unsigned int buffer;
struct vb2_buffer *vb;
@@ -163,7 +172,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
v4l2_memory memory,
vb-state = VB2_BUF_STATE_DEQUEUED;
vb-vb2_queue = q;
vb-num_planes = num_planes;
- vb-v4l2_buf.index = buffer;
+ vb-v4l2_buf.index = q-num_buffers + buffer;
vb-v4l2_buf.type = q-type;
vb-v4l2_buf.memory = memory;
@@ -191,15 +200,13 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
v4l2_memory memory,
}
}
- q-bufs[buffer] = vb;
+ q-bufs[q-num_buffers + buffer] = vb;
}
- q-num_buffers = buffer;
-
- __setup_offsets(q);
+ __setup_offsets(q, buffer);
dprintk(1, Allocated %d buffers, %d plane(s) each\n,
- q-num_buffers, num_planes);
+ buffer, num_planes);
return buffer;
}
@@ -207,12 +214,13 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
v4l2_memory memory,
/**
* __vb2_free_mem() - release all video buffer memory for a given queue
*/
-static void __vb2_free_mem(struct vb2_queue *q)
+static void __vb2_free_mem(struct vb2_queue *q, unsigned int buffers)
{
unsigned int buffer;
struct vb2_buffer *vb;
- for (buffer = 0; buffer q-num_buffers; ++buffer) {
+ for (buffer = q-num_buffers - buffers; buffer q-num_buffers;
+++buffer) {
vb = q-bufs[buffer];
if (!vb)
continue;
@@ -226,17 +234,18 @@ static void __vb2_free_mem(struct vb2_queue *q)
}
/**
- * __vb2_queue_free() - free the queue - video memory and related information
- * and return the queue to an uninitialized state. Might be called even if the
- * queue has already been freed.
+ * __vb2_queue_free() - free buffers at the end of the queue - video memory and
+ * related information, if no buffers are left return the queue to an
+ * uninitialized state. Might be called even if the queue has already been
freed.
*/
-static void __vb2_queue_free(struct vb2_queue *q)
+static void __vb2_queue_free(struct vb2_queue *q, unsigned int
[PATCH 1/7 v5] V4L: add a new videobuf2 buffer state VB2_BUF_STATE_PREPARED
This patch prepares for a better separation of the buffer preparation
stage.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/videobuf2-core.c | 59 +
include/media/videobuf2-core.h |2 +
2 files changed, 39 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 3015e60..fb7a3ac 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -333,6 +333,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct
v4l2_buffer *b)
b-flags |= V4L2_BUF_FLAG_DONE;
break;
case VB2_BUF_STATE_DEQUEUED:
+ case VB2_BUF_STATE_PREPARED:
/* nothing */
break;
}
@@ -817,6 +818,31 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
q-ops-buf_queue(vb);
}
+static int __buf_prepare(struct vb2_buffer *vb, struct v4l2_buffer *b)
+{
+ struct vb2_queue *q = vb-vb2_queue;
+ int ret;
+
+ switch (q-memory) {
+ case V4L2_MEMORY_MMAP:
+ ret = __qbuf_mmap(vb, b);
+ break;
+ case V4L2_MEMORY_USERPTR:
+ ret = __qbuf_userptr(vb, b);
+ break;
+ default:
+ WARN(1, Invalid queue type\n);
+ ret = -EINVAL;
+ }
+
+ if (!ret)
+ ret = call_qop(q, buf_prepare, vb);
+ if (ret)
+ dprintk(1, qbuf: buffer preparation failed: %d\n, ret);
+
+ return ret;
+}
+
/**
* vb2_qbuf() - Queue a buffer from userspace
* @q: videobuf2 queue
@@ -826,8 +852,8 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
* Should be called from vidioc_qbuf ioctl handler of a driver.
* This function:
* 1) verifies the passed buffer,
- * 2) calls buf_prepare callback in the driver (if provided), in which
- *driver-specific buffer initialization can be performed,
+ * 2) if necessary, calls buf_prepare callback in the driver (if provided), in
+ *which driver-specific buffer initialization can be performed,
* 3) if streaming is on, queues the buffer in driver by the means of buf_queue
*callback for processing.
*
@@ -837,7 +863,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
{
struct vb2_buffer *vb;
- int ret = 0;
+ int ret;
if (q-fileio) {
dprintk(1, qbuf: file io in progress\n);
@@ -866,29 +892,18 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
return -EINVAL;
}
- if (vb-state != VB2_BUF_STATE_DEQUEUED) {
+ switch (vb-state) {
+ case VB2_BUF_STATE_DEQUEUED:
+ ret = __buf_prepare(vb, b);
+ if (ret)
+ return ret;
+ case VB2_BUF_STATE_PREPARED:
+ break;
+ default:
dprintk(1, qbuf: buffer already in use\n);
return -EINVAL;
}
- if (q-memory == V4L2_MEMORY_MMAP)
- ret = __qbuf_mmap(vb, b);
- else if (q-memory == V4L2_MEMORY_USERPTR)
- ret = __qbuf_userptr(vb, b);
- else {
- WARN(1, Invalid queue type\n);
- return -EINVAL;
- }
-
- if (ret)
- return ret;
-
- ret = call_qop(q, buf_prepare, vb);
- if (ret) {
- dprintk(1, qbuf: buffer preparation failed\n);
- return ret;
- }
-
/*
* Add to the queued buffers list, a buffer will stay on it until
* dequeued in dqbuf.
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f87472a..65946c5 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -106,6 +106,7 @@ enum vb2_fileio_flags {
/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED:buffer under userspace control
+ * @VB2_BUF_STATE_PREPARED:buffer prepared in videobuf and by the driver
* @VB2_BUF_STATE_QUEUED: buffer queued in videobuf, but not in driver
* @VB2_BUF_STATE_ACTIVE: buffer queued in driver and possibly used
* in a hardware operation
@@ -117,6 +118,7 @@ enum vb2_fileio_flags {
*/
enum vb2_buffer_state {
VB2_BUF_STATE_DEQUEUED,
+ VB2_BUF_STATE_PREPARED,
VB2_BUF_STATE_QUEUED,
VB2_BUF_STATE_ACTIVE,
VB2_BUF_STATE_DONE,
--
1.7.2.5
--
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
Re: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex
On Wed, Aug 24, 2011 at 2:08 PM, Andreas Oberritter o...@linuxtv.org wrote: Instead of wasting your time with theory, you could have easily reviewed my patch. It's really *very* simple any anyone having used semphores or mutexes in the kernel should be able to see that. There's no need to resort to belittlement. Both of us have a non-trivial number of commits to the Linux kernel. My concern is that in the kernel a semaphore with a unit of one is *not* necessarily the same as a mutex. In particular you need to take into account the calling context since mutexes do more enforcement of certain conditions that may have been acceptable for a semaphore. From http://www.kernel.org/doc/Documentation/mutex-design.txt : === - 'struct mutex' semantics are well-defined and are enforced if CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have virtually no debugging code or instrumentation. The mutex subsystem checks and enforces the following rules: * - only one task can hold the mutex at a time * - only the owner can unlock the mutex * - multiple unlocks are not permitted * - recursive locking is not permitted * - a mutex object must be initialized via the API * - a mutex object must not be initialized via memset or copying * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized * - mutexes may not be used in hardware or software interrupt * contexts such as tasklets and timers === and: === Disadvantages - The stricter mutex API means you cannot use mutexes the same way you can use semaphores: e.g. they cannot be used from an interrupt context, nor can they be unlocked from a different context that which acquired it. [ I'm not aware of any other (e.g. performance) disadvantages from using mutexes at the moment, please let me know if you find any. ] === In short, you cannot just arbitrarily replace one with the other. You need to look at all the possible call paths and ensure that there aren't any cases for example where the mutex is set in one but cleared in the other. Did you evaluate your change in the context of each of the differences described in the list above? Without any documentation in the patch, we have absolutely no idea what level of due diligence you exercised in ensuring this didn't cause breakage. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vb2: change plane sizes array to unsigned int[]
On Wed, 24 Aug 2011, Marek Szyprowski wrote:
Plane sizes array was declared as unsigned long[], while unsigned int is
more than enough for storing size of the video buffer. This patch reduces
the size of the array by definiting it as unsigned int[].
Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
https://patchwork.kernel.org/patch/1037612/
:-)
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/atmel-isi.c |2 +-
drivers/media/video/marvell-ccic/mcam-core.c |2 +-
drivers/media/video/mem2mem_testdev.c|2 +-
drivers/media/video/mx3_camera.c |2 +-
drivers/media/video/pwc/pwc-if.c |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c |2 +-
drivers/media/video/s5p-fimc/fimc-core.c |2 +-
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|2 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c|2 +-
drivers/media/video/s5p-tv/mixer_video.c |2 +-
drivers/media/video/sh_mobile_ceu_camera.c |2 +-
drivers/media/video/vivi.c |2 +-
include/media/videobuf2-core.h |4 ++--
13 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7b89f00..5a4b2d7 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -249,7 +249,7 @@ static int atmel_isi_wait_status(struct atmel_isi *isi,
int wait_reset)
Videobuf operations
--*/
static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
+ unsigned int *nplanes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 83c1451..744cf37 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -884,7 +884,7 @@ static int mcam_read_setup(struct mcam_camera *cam)
*/
static int mcam_vb_queue_setup(struct vb2_queue *vq, unsigned int *nbufs,
- unsigned int *num_planes, unsigned long sizes[],
+ unsigned int *num_planes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct mcam_camera *cam = vb2_get_drv_priv(vq);
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
index 166bf93..0d0c0d5 100644
--- a/drivers/media/video/mem2mem_testdev.c
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -739,7 +739,7 @@ static const struct v4l2_ioctl_ops m2mtest_ioctl_ops = {
*/
static int m2mtest_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
+ unsigned int *nplanes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct m2mtest_ctx *ctx = vb2_get_drv_priv(vq);
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index c045b47..9ae7785 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -191,7 +191,7 @@ static void mx3_cam_dma_done(void *arg)
*/
static int mx3_videobuf_setup(struct vb2_queue *vq,
unsigned int *count, unsigned int *num_planes,
- unsigned long sizes[], void *alloc_ctxs[])
+ unsigned int sizes[], void *alloc_ctxs[])
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
diff --git a/drivers/media/video/pwc/pwc-if.c
b/drivers/media/video/pwc/pwc-if.c
index 51ca358..a7e4f56 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -745,7 +745,7 @@ static int pwc_video_mmap(struct file *file, struct
vm_area_struct *vma)
/* Videobuf2 operations */
static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned long sizes[],
+ unsigned int *nplanes, unsigned int sizes[],
void *alloc_ctxs[])
{
struct pwc_device *pdev = vb2_get_drv_priv(vq);
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 0d730e5..e6afe5f 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -265,7 +265,7 @@ static unsigned int get_plane_size(struct fimc_frame *fr,
unsigned int plane)
}
static int
Re: dma buffers for camera
Hi Jan On Wed, 24 Aug 2011, Jan Pohanka wrote: Hello, could please anyone explain me a bit situation about using memory buffers for dma for video input devices? Unfortunately I don't understand it at all. I want to capture images 1600x1200 from 2 mpix sensor on i.mx27 board. I gave 8MB to mx2_camera device with dma_declare_coherent_memory. Unfortunately it seems to be not enough. In UYVY format I need 1600x1200x2 for one picture, it is cca 3.8MB. After some digging I noticed, that dma_alloc_coherent() is called three times and each time with the 3.8MB demand. Once it is directly from mx2_camera driver and two times from videobuf_dma_contig. OK, that is more than 8MB available, but why there are so big memory demands for one picture? I'm using gstremer for capturing, so it probably requests several buffers with VIDIOC_REQBUFS. Is this behaviour normal, even if there is explicitly noted that I want only one buffer? The mx2_camera driver is allocating one discard buffer of the same size, as regular buffers for cases, when the user is not fast enough to queue new buffers for the running capture. Arguably, this could be aliminated and the last submitted buffer could be re-used until either more buffers are available or the streaming is stopped. Otherwise, it could also be possible to stop capture until buffers are available again. In any case, this is the current driver implementation. As for 2 buffers instead of one for the actual capture, I think, gstreamer defines 2 as a minimum number of buffers, which is actually also required for any streaming chance. Thanks Guennadi gst-launch \ v4l2src num-buffers=1 device=/dev/video1 ! \ video/x-raw-yuv,format=\(fourcc\)UYVY,width=$WIDTH,height=$HEIGHT ! \ jpegenc ! \ filesink location=col_image.jpg with best regards Jan --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Aug 24 19:00:29 CEST 2011 git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-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.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-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 linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Image and webcam freeze on Ubuntu with Logitech QuickCam Communicate STX
On Fri, Aug 19, 2011 at 11:32 AM, Jean-Francois Moine moin...@free.fr wrote: I need more information. Sorry for the delay. Here are the information: Aug 24 21:21:05 ancizan kernel: [48546.488081] usb 3-1: new full speed USB device using ohci_hcd and address 3 Aug 24 21:21:05 ancizan kernel: [48546.695280] gspca: probing 046d:08ad Aug 24 21:21:06 ancizan kernel: [48548.039122] zc3xx: probe 2wr ov vga 0x Aug 24 21:21:06 ancizan kernel: [48548.104109] zc3xx: probe sensor - 0011 Aug 24 21:21:06 ancizan kernel: [48548.104116] zc3xx: Find Sensor HV7131R Aug 24 21:21:06 ancizan kernel: [48548.110317] input: zc3xx as /devices/pci:00/:00:02.0/usb3/3-1/input/input6 Aug 24 21:21:06 ancizan kernel: [48548.110565] gspca: video0 created Aug 24 21:21:06 ancizan kernel: [48548.110573] gspca: found int in endpoint: 0x82, buffer_len=8, interval=10 Aug 24 21:21:06 ancizan kernel: [48548.129182] gspca: [v4l_id] open Aug 24 21:21:06 ancizan kernel: [48548.129266] gspca: [v4l_id] close Aug 24 21:21:06 ancizan kernel: [48548.129271] gspca: close done Aug 24 21:21:06 ancizan kernel: [48548.195903] gspca: [GoogleTalkPlugi] open Aug 24 21:21:06 ancizan kernel: [48548.195924] gspca: [GoogleTalkPlugi] close Aug 24 21:21:06 ancizan kernel: [48548.195929] gspca: close done Aug 24 21:21:06 ancizan kernel: [48548.206901] gspca: [GoogleTalkPlugi] open Aug 24 21:21:06 ancizan kernel: [48548.206910] gspca: [GoogleTalkPlugi] close Aug 24 21:21:06 ancizan kernel: [48548.206912] gspca: close done Aug 24 21:21:06 ancizan kernel: [48548.277014] gspca: [GoogleTalkPlugi] open Aug 24 21:21:06 ancizan kernel: [48548.277035] gspca: [GoogleTalkPlugi] close Aug 24 21:21:06 ancizan kernel: [48548.277041] gspca: close done Aug 24 21:21:07 ancizan rtkit-daemon[1470]: Successfully made thread 6289 of process 1668 (n/a) owned by '1000' RT at priority 5. Aug 24 21:21:07 ancizan rtkit-daemon[1470]: Supervising 4 threads of 1 processes of 1 users. Aug 24 21:21:17 ancizan kernel: [48559.302292] gspca: [GoogleTalkPlugi] open Aug 24 21:21:17 ancizan kernel: [48559.302328] gspca: [GoogleTalkPlugi] close Aug 24 21:21:17 ancizan kernel: [48559.302333] gspca: close done Aug 24 21:21:17 ancizan kernel: [48559.308050] gspca: [GoogleTalkPlugi] open Aug 24 21:21:17 ancizan kernel: [48559.308243] gspca: [GoogleTalkPlugi] close Aug 24 21:21:17 ancizan kernel: [48559.308249] gspca: close done Aug 24 21:21:17 ancizan kernel: [48559.308554] gspca: [GoogleTalkPlugi] open Aug 24 21:21:17 ancizan kernel: [48559.308583] gspca: [GoogleTalkPlugi] close Aug 24 21:21:17 ancizan kernel: [48559.308587] gspca: close done Aug 24 21:21:17 ancizan kernel: [48559.342339] gspca: [GoogleTalkPlugi] open Aug 24 21:21:17 ancizan kernel: [48559.342348] gspca: try fmt cap JPEG 640x480 Aug 24 21:21:17 ancizan kernel: [48559.342387] gspca: frame alloc frsz: 115790 Aug 24 21:21:17 ancizan kernel: [48559.342429] gspca: reqbufs st:0 c:4 Aug 24 21:21:17 ancizan kernel: [48559.342470] gspca: mmap start:013dd000 size:118784 Aug 24 21:21:17 ancizan kernel: [48559.342487] gspca: mmap start:013fa000 size:118784 Aug 24 21:21:17 ancizan kernel: [48559.342498] gspca: mmap start:01417000 size:118784 Aug 24 21:21:17 ancizan kernel: [48559.342508] gspca: mmap start:01434000 size:118784 Aug 24 21:21:17 ancizan kernel: [48559.343115] gspca: use alt 7 ep 0x81 Aug 24 21:21:17 ancizan kernel: [48559.345174] gspca: init transfer alt 7 Aug 24 21:21:17 ancizan kernel: [48559.345178] gspca: isoc 32 pkts size 1023 = bsize:32736 Aug 24 21:21:19 ancizan kernel: [48560.684113] zc3xx: probe 2wr ov vga 0x Aug 24 21:21:20 ancizan kernel: [48562.103153] gspca: found int in endpoint: 0x82, buffer_len=8, interval=10 Aug 24 21:21:20 ancizan kernel: [48562.103162] gspca: stream on OK JPEG 640x480 Aug 24 21:22:43 ancizan kernel: [48645.37] gspca: ISOC data error: [0] len=0, status=-18 Hope this helps Best regards, -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry -- 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 1/1] Add driver support for ITE IT9135 device
On Wednesday 24 of August 2011, Arkadiusz Miskiewicz wrote: On Friday 05 of August 2011, jasondong wrote: This is DVB USB Linux driver for ITEtech IT9135 base USB TV module. It supported the IT9135 AX and BX chip versions. Hi, The quick review by crop@freenode was: I quick check it and didnt like much since it is not plitted logically correct, as usb-bridge, demod and tuner. now all are rather much one big blob. so I guess you have to split it into pieces in a way other dvb drivers already in kernel tree are done. Unfortunately I don't know which existing driver is the best example on how to do things. More comments from irc: 22:09 crope arekm: any current DVB USB driver. there is very many of integrated (2-in-1, or 3-in-1) drivers which are splitted correctly 22:10 crope ec168, af9015, some dibcom models?, ce6320, rtl2831u 22:11 crope you *must* implement all logical parts as own drivers no matter of those are integrated to one silicon or not. it is generally seen those parts used are sold as not integrated too 22:12 crope for example that IT9135, I really think it uses af9033 demod, which is sold as own part and also integrated to af9015. and very likely IT9135 contains same USB-brdge than AF9035. only difference is integrated tuner 22:13 crope so IT9135 == AF9035+ IT tuner in one package. when you split driver correctly to logical parts you can use same drivers 22:14 crope and AF9035 == AF903XX USB-bridge + AF9033 demod 22:17 crope all DVB USB drivers we have consist of 2 parts (drivers). 1) USB-interface driver (aka DVB USB) 2) demodulator driver 3) tuner driver 22:17 crope all DVB USB drivers we have consist of 3 parts (drivers). 1) USB-interface driver (aka DVB USB) 2) demodulator driver 3) tuner driver -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
installing git://linuxtv.org/media_build.git with basci approach on Gentoo
Hi, while installing git://linuxtv.org/media_build.git i got the error: ERROR: please install lsdiff, otherwise, build won't work. I don't know distro Gentoo Base System release 2.0.1-r1. So, I can't provide you a hint with the package names. Be welcome to contribute with a patch for media-build, by submitting a distro-specific hint to linux-media@vger.kernel.org Build can't procceed as 1 dependency is missing at ./build line 172. If this error occurs on a Gentoo system emerge dev-util/patchutils helps. best regards Michael Abel -- 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: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On 24/08/11 21:12, Laurent Pinchart wrote: On Wednesday 24 August 2011 03:17:39 CJ wrote: On 23/08/11 19:47, Laurent Pinchart wrote: On Tuesday 23 August 2011 05:47:20 CJ wrote: On 22/08/11 22:15, Michael Jones wrote: I am trying to get the mt9p031 working from nand with a ubifs file system and I am having a few problems. /dev/media0 is not present unless I run: #mknod /dev/media0 c 251 0 #chown root:video /dev/media0 #media-ctl -p Enumerating entities media_open: Unable to enumerate entities for device /dev/media0 (Inappropriate ioctl for device) With the same rig/files it works fine running from EXT4 on an SD card. Any idea why this does not work on nand with ubifs? Is the OMAP3 ISP driver loaded ? Has it probed the device successfully ? Check the kernel log for OMAP3 ISP-related messages. Here is the version running from SD card: # dmesg | grep isp [0.265502] omap-iommu omap-iommu.0: isp registered [2.986541] omap3isp omap3isp: Revision 2.0 found [2.991577] omap-iommu omap-iommu.0: isp: version 1.1 [2.997406] omap3isp omap3isp: hist: DMA channel = 0 [3.006256] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 2160 Hz [3.011932] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz From NAND using UBIFS: # dmesg | grep isp [3.457061] omap3isp omap3isp: Revision 2.0 found [3.462036] omap-iommu omap-iommu.0: isp: version 1.1 [3.467620] omap3isp omap3isp: hist: DMA channel = 0 [3.472564] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 2160 Hz [3.478027] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz Seems to be missing: omap-iommu omap-iommu.0: isp registered Is that the issue? Why would this not work when running from NAND? I'm not sure, either, but I had a similar problem before using Laurent's patch below. IIRC, usually udev would create /dev/media0 from a cached list of /dev/*. Later modutils would come along and load the modules in the proper order (iommu, then omap3-isp) and everybody was happy. Occasionally, udev would fail to use the cached version of /dev/, and look through /sys/devices to re-create the devices in /dev/. When media0 was found, omap3-isp.ko would be loaded, but iommu had not yet been, presumably because it doesn't have an entry in /sys/devices/. So maybe udev is behaving differently for you on NAND than it did on the card? Either way, as I said, using Laurent's patch below did the job for me. I'm not sure why it doesn't work from NAND, but the iommu2 module needs to be loaded before the omap3-isp module. Alternatively you can compile the iommu2 module in the kernel with diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 49a4c75..3c87644 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -132,7 +132,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + bool config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS Thanks for the help! For some reason dmesg does not read early kernel stuff when in UBIFS from NAND. So when I went back and had a look the line I thought was not there is actually included. [0.276977] omap-iommu omap-iommu.0: isp registered So I guess everything is loading fine. I tried the patch and it didn't make a difference. Regarding what Michael said /dev/media0 is not created by udev when boot from NAND. I tried creating it manually with: #mknod /dev/media0 c 251 0 #chown root:video /dev/media0 But this does not work - outputs: # media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media_open: Unable to enumerate entities for device /dev/media0 (Inappropriate ioctl for device) So is there a problem with udev? There could be. What's the output of ls /sys/class/video4linux #ls /sys/class/video4linux v4l-subdev0 v4l-subdev3 v4l-subdev6 video0 video3 video6 v4l-subdev1 v4l-subdev4 v4l-subdev7 video1 video4 v4l-subdev2 v4l-subdev5 v4l-subdev8 video2 video5 Devices are correctly registered with the Linux kernel. Does 'ls /dev/v4l- subdev*' show the same entries ? If not you probably have a udev issue. Slightly different.. # ls /dev/v4l-subdev* /dev/v4l-subdev0 /dev/v4l-subdev3 /dev/v4l-subdev6 /dev/v4l-subdev1 /dev/v4l-subdev4 /dev/v4l-subdev7 /dev/v4l-subdev2 /dev/v4l-subdev5 /dev/v4l-subdev8 I probably should have said this earlier .. but I am using mdev not udev. It does work fine with exactly the same system running from the card in EXT4. Any other thoughts? Cheers, Chris -- 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 06/14] [media] cx18: Use current logging styles
On Wed, 2011-08-24 at 06:34 -0400, Andy Walls wrote: On Sun, 2011-08-21 at 15:56 -0700, Joe Perches wrote: Add pr_fmt. Convert printks to pr_level. Convert printks without KERN_level to appropriate pr_level. Removed embedded prefixes when pr_fmt was added. Use ##__VA_ARGS__ for variadic macros. Coalesce format strings. 1. It is important to preserve the per-card prefixes emitted by the driver: cx18-0, cx18-1, cx18-2, etc. With a quick skim, I think your change preserves the format of all output messages (except removing periods). Can you confirm this? Here's the output diff of strings built-in.o | grep ^. | sort new and old $ diff -u0 cx18.old cx18.new --- cx18.old2011-08-24 13:18:41.0 -0700 +++ cx18.new2011-08-24 14:04:10.0 -0700 @@ -1,2 +1,9 @@ -3cx18-alsa cx is NULL -3cx18-alsa: %s: struct v4l2_device * is NULL +3cx18_alsa: cx is NULL +3cx18_alsa: %s-alsa: %s: failed to create struct snd_cx18_card +3cx18_alsa: %s-alsa: %s: snd_card_create() failed with err %d +3cx18_alsa: %s-alsa: %s: snd_card_register() failed with err %d +3cx18_alsa: %s-alsa: %s: snd_cx18_card_create() failed with err %d +3cx18_alsa: %s-alsa: %s: snd_cx18_pcm_create() failed with err %d +3cx18_alsa: %s-alsa: %s: snd_cx18_pcm_create() failed with err %d +3cx18_alsa: %s-alsa: %s: struct snd_cx18_card * already exists +3cx18_alsa: %s: struct v4l2_device * is NULL @@ -17,7 +23,0 @@ -3%s-alsa: %s: failed to create struct snd_cx18_card -3%s-alsa: %s: snd_card_create() failed with err %d -3%s-alsa: %s: snd_card_register() failed with err %d -3%s-alsa: %s: snd_cx18_card_create() failed with err %d -3%s-alsa: %s: snd_cx18_pcm_create() failed with err %d -3%s-alsa: %s: snd_cx18_pcm_create() failed with err %d -3%s-alsa: %s: struct snd_cx18_card * already exists @@ -62 +62 @@ -3%s: Prefix your subject line with [UNKNOWN CX18 CARD]. +3%s: Prefix your subject line with [UNKNOWN CX18 CARD] @@ -80 +80 @@ -4%s-alsa: %s: struct snd_cx18_card * is NULL +4cx18_alsa: %s-alsa: %s: struct snd_cx18_card * is NULL @@ -82 +82 @@ -4%s: Could not register GPIO reset controllersubdevice; proceeding anyway. +4%s: Could not register GPIO reset controller subdevice; proceeding anyway. @@ -85 +85 @@ -4%s: MPEG Index stream cannot be claimed directly, but something tried. +4%s: MPEG Index stream cannot be claimed directly, but something tried @@ -99,12 +99,14 @@ -6cx18-alsa: module loading... -6cx18-alsa: module unload complete -6cx18-alsa: module unloading... -6cx18-alsa-pcm %s: Allocating vbuffer -6cx18-alsa-pcm %s: cx18 alsa announce ptr=%p data=%p num_bytes=%zd -6cx18-alsa-pcm %s: dma area was NULL - ignoring -6cx18-alsa-pcm %s: freeing pcm capture region -6cx18-alsa-pcm %s: runtime was NULL -6cx18-alsa-pcm %s: %s called -6cx18-alsa-pcm %s: %s: length was zero -6cx18-alsa-pcm %s: stride is zero -6cx18-alsa-pcm %s: substream was NULL +6cx18_alsa: module loading... +6cx18_alsa: module unload complete +6cx18_alsa: module unloading... +6cx18_alsa: %s: Allocating vbuffer +6cx18_alsa: %s: created cx18 ALSA interface instance +6cx18_alsa: %s: cx18 alsa announce ptr=%p data=%p num_bytes=%zd +6cx18_alsa: %s: dma area was NULL - ignoring +6cx18_alsa: %s: freeing pcm capture region +6cx18_alsa: %s: PCM stream for card is disabled - skipping +6cx18_alsa: %s: runtime was NULL +6cx18_alsa: %s: %s called +6cx18_alsa: %s: %s: length was zero +6cx18_alsa: %s: stride is zero +6cx18_alsa: %s: substream was NULL @@ -172 +174 @@ -6%s: info: dualwatch: change stereo flag from 0x%x to 0x%x. +6%s: info: dualwatch: change stereo flag from 0x%x to 0x%x @@ -188 +190 @@ -6%s: info: Preparing for firmware halt. +6%s: info: Preparing for firmware halt @@ -206 +208 @@ -6%s: info: Switching standard to %llx. +6%s: info: Switching standard to %llx @@ -236 +237,0 @@ -6%s: %s: created cx18 ALSA interface instance @@ -239 +239,0 @@ -6%s: %s: PCM stream for card is disabled - skipping 2. PLease don't add a pr_fmt() #define to exevry file. Just put one where all the other CX18_*() macros are defined. Every file picks those up. It's not the first #include of every file. printk.h has a default #define pr_fmt(fmt) fmt -- 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: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro,
On Sat, Aug 20, 2011 at 05:12:56AM -0700, Mauro Carvalho Chehab wrote:
Em 20-08-2011 04:27, Sylwester Nawrocki escreveu:
Hi Mauro,
On 08/17/2011 08:13 AM, Mauro Carvalho Chehab wrote:
It seems that there are too many miss understandings or maybe we're just
talking the same thing on different ways.
So, instead of answering again, let's re-start this discussion on a
different way.
One of the requirements that it was discussed a lot on both mailing
lists and on the Media Controllers meetings that we had (or, at least
in the ones where I've participated) is that:
A pure V4L2 userspace application, knowing about video device
nodes only, can still use the driver. Not all advanced features
will be available.
What does a term a pure V4L2 userspace application mean here ?
The above quotation are exactly the Laurent's words that I took from one
of his replies.
I would define this as an application which uses V4L2 but does not use Media
controller or the V4L2 subdev interfaces nor is aware of any particular
hardware device.
Does it also account an application which is linked to libv4l2 and uses
calls specific to a particular hardware which are included there?
That's a good question. We need to properly define what it means, to avoid
having libv4l abuses.
In other words, it seems ok to use libv4l to set pipelines via the MC API
at open(), but it isn't ok to have an open() binary only libv4l plugin that
will hook open and do the complete device initialization on userspace
(I remember that one vendor once proposed a driver like that).
Also, from my side, I'd like to see both libv4l and kernel drivers being
submitted together, if the new driver depends on a special libv4l support
for it to work.
I agree with the above.
I do favour using libv4l to do the pipeline setup using MC and V4L2 subdev
interfaces. This has the benefit that the driver provides just one interface
to access different aspects of it, be it pipeline setup (Media controller),
a control to change exposure time (V4L2 subdev) or queueing video buffer
(V4L2). This means more simple and more maintainable drivers and less bugs
in general.
Apart from what the drivers already provide on video nodea, to support a
general purpose V4L2 application, libv4l plugin can do is (not exhaustive
list):
- Perform pipeline setup using MC interface, possibly based on input
selected using S_INPUT so that e.g. multiple sensors can be supported and
- implement {S,G,TRY}_EXT_CTRLS and QUERYCTRL using V4L2 subdev nodes as
backend.
As the Media controller and V4L2 interfaces are standardised, I see no
reason why this plugin could not be fully generic: only the configuration is
device specific.
This configuration could be stored into a configuration file which is
selected based on the system type. On embedded systems (ARMs at least, but
anyway the vast majority is based on ARM) the board type is easily available
for the user space applications in /proc/cpuinfo --- this example is from
the Nokia N900:
---
Processor : ARMv7 Processor rev 3 (v7l)
BogoMIPS: 249.96
Features: swp half fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part: 0xc08
CPU revision: 3
Hardware: Nokia RX-51 board
Revision: 2101
Serial :
---
I think this would be a first step to support general purpose application on
embedded systems.
The question I still have on this is that how should the user know which
video node to access on an embedded system with a camera: the OMAP 3 ISP,
for example, contains some eight video nodes which have different ISP blocks
connected to them. Likely two of these nodes are useful for a general
purpose application based on which image format it requests. It would make
sense to provide generic applications information only on those devices they
may meaningfully use.
Later on, more functionality could be added to better support hardware which
supports e.g. different pixel formats, image sizes, scaling and crop. I'm
not entirely certain if all of this is fully generic --- but I think the
vast majority of it is --- at least converting from v4l2_mbus_framefmt
pixelcode to v4l2_format.fmt is often quite hardware specific which must be
taken into account by the generic plugin.
At that point many policy decisions must be made on how to use the hardware
the best way, and that must be also present in the configuration file.
But perhaps I'm going too far with this now; we don't yet have a generic
plugin providing basic functionality. We have the OMAP 3 ISP libv4l plugin
which might be a good staring point for this work.
--
Sakari Ailus
sakari.ai...@iki.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: Bug#639161: linux-image-3.0.0-1-686-pae: Upgrade 2.6.39 - 3.0.0 breaks playback on DiBcom 7000PC
Patrick, Please could you take a look at the following bug report on Linux 3.0 as packaged in Debian. Ben. On Wed, 2011-08-24 at 18:59 +0200, Soeren D. Schulze wrote: Package: linux-2.6 Version: 3.0.0-1 Severity: normal I usually use tzap/mplayer for TV playback. After the upgrade to Linux 3.0.0, tzap command line output still looks fine, but mplayer does not seem to receive any data (its cache does not fill up). syslog/dmesg output looks the same as in 2.6.39. On the first try to tune, dmesg receives: dib0700: tx buffer length is larger than 4. Not supported. (for which I find various non-Debian bug reports) But that does not seem to be the issue, because the same message appears in 2.6.39, where everything is fine. So I do not really have an idea what the problem is, but I certainly know that it's a regression, because simply booting Linux 2.6.39 rather than 3.0.0 on the same system avoids the problem. -- Package-specific info: ** Version: Linux version 3.0.0-1-686-pae (Debian 3.0.0-1) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-3) ) #1 SMP Sun Jul 24 14:27:32 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-3.0.0-1-686-pae root=UUID=3aa0a731-df46-486e-9c1e-258723e14f8f ro ** Not tainted ** Kernel log: [ 11.031446] saa7134: card=172 - RoverMedia TV Link Pro FM 19d1:0138 [ 11.031580] saa7134: card=173 - Zolid Hybrid TV Tuner PCI 1131:2004 [ 11.031713] saa7134: card=174 - Asus Europa Hybrid OEM 1043:4847 [ 11.031847] saa7134: card=175 - Leadtek Winfast DTV1000S 107d:6655 [ 11.031982] saa7134: card=176 - Beholder BeholdTV 505 RDS :5051 [ 11.032126] saa7134: card=177 - Hawell HW-404M7 [ 11.032217] saa7134: card=178 - Beholder BeholdTV H7 5ace:7190 [ 11.032351] saa7134: card=179 - Beholder BeholdTV A7 5ace:7090 [ 11.032485] saa7134: card=180 - Avermedia PCI M733A 1461:4155 1461:4255 [ 11.032656] saa7134: card=181 - TechoTrend TT-budget T-3000 13c2:2804 [ 11.032789] saa7134: card=182 - Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid 17de:b136 [ 11.032923] saa7134: card=183 - Compro VideoMate Vista M1F 185b:c900 [ 11.033057] saa7134: card=184 - Encore ENLTV-FM 3 1a7f:2108 [ 11.033192] saa7134: card=185 - MagicPro ProHDTV Pro2 DMB-TH/Hybrid 17de:d136 [ 11.033326] saa7134: card=186 - Beholder BeholdTV 501 5ace:5010 [ 11.033460] saa7134: card=187 - Beholder BeholdTV 503 FM 5ace:5030 [ 11.033596] saa7134[0]: subsystem: 1131:, board: UNKNOWN/GENERIC [card=0,autodetected] [ 11.075242] IR NEC protocol handler initialized [ 11.265597] saa7134[0]: board init: gpio is 10020 [ 11.368582] saa7134[0]: Huh, no eeprom present (err=-5)? [ 11.381924] saa7134[0]: registered device video0 [v4l2] [ 11.382055] saa7134[0]: registered device vbi0 [ 11.417515] IR RC5(x) protocol handler initialized [ 11.607051] cfg80211: Calling CRDA to update world regulatory domain [ 11.995773] IR RC6 protocol handler initialized [ 12.191500] IR JVC protocol handler initialized [ 12.263839] dib0700: loaded with support for 20 different device-types [ 12.264209] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. [ 12.265499] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 12.266158] DVB: registering new adapter (Hauppauge Nova-T Stick) [ 12.517093] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 12.609760] IR Sony protocol handler initialized [ 12.790869] DiB0070: successfully identified [ 12.907896] ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22 [ 12.907988] VIA 82xx Audio :00:11.5: PCI INT C - Link[ALKC] - GSI 22 (level, low) - IRQ 22 [ 12.908316] VIA 82xx Audio :00:11.5: setting latency timer to 64 [ 12.932675] saa7134 ALSA driver for DMA sound loaded [ 12.932807] saa7134[0]/alsa: saa7134[0] at 0xfdffc000 irq 16 registered as card -1 [ 12.948789] lirc_dev: IR Remote Control driver registered, major 249 [ 12.952109] IR LIRC bridge handler initialized [ 13.380033] Registered IR keymap rc-dib0700-rc5 [ 13.380514] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0/input6 [ 13.380749] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0 [ 13.382312] dvb-usb: schedule remote query interval to 50 msecs. [ 13.382385] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected. [ 13.382931] dib0700: rc submit urb failed [ 13.382935] [ 13.383099] usbcore: registered new interface driver dvb_usb_dib0700 [ 13.530512] ENS1371 :00:14.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 14.848088] usb 1-1.1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 [ 15.061785] ath9k_htc 1-1.1:1.0: ath9k_htc: HTC initialized with 33 credits
A S3/S4 issue about em28xx driver
Hi guys, I find an issue about the USB TV tuner, WinTV HVR950, which use em28xx driver. The linux can't going to S3/S4 when the device attach to USB2.0/USB3.0 ports. [Step] - Boot linux (either with or without x-windows) - Attach the HVR950 to USB port. - dmesg and lsusb to make sure the device driver has been load sucessfully - pm-suspend [--quirk-s3-bios] - the screen show black light and hung Then I do some research about it and find it seems caused by the em28xx-alsa module that can't implement some call back function about suspend and resume. After I make the em28xx-alsa.ko not installed by comment one line in em28xx-cards.c below. else if (dev-has_alsa_audio) // request_modules(em28xx-alsa); Then the linux can go into S3/S4. I uses kernel 3.1.0-rc1 on Scientific Linux 6.1 do the debug. The issue can be reproduce on Ubuntu10,04 too. I am not familiar with linux-media driver. Is there someone know this issue? Thanks, Alex He -- 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
