Re: [PATCH 1/6] v4l: omap4iss: Add support for OMAP4 camera interface - Core
A few small comments below... On 10/03/2013 01:55 AM, Laurent Pinchart wrote: From: Sergio Aguirre sergio.a.agui...@gmail.com This adds a very simplistic driver to utilize the CSI2A interface inside the ISS subsystem in OMAP4, and dump the data to memory. Check Documentation/video4linux/omap4_camera.txt for details. This commit adds the driver core, registers definitions and documentation. Signed-off-by: Sergio Aguirre sergio.a.agui...@gmail.com [Port the driver to v3.12-rc3, including the following changes - Don't include plat/ headers - Don't use cpu_is_omap44xx() macro - Don't depend on EXPERIMENTAL - Fix s_crop operation prototype - Update link_notify prototype - Rename media_entity_remote_source to media_entity_remote_pad] Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/video4linux/omap4_camera.txt | 63 ++ drivers/staging/media/omap4iss/iss.c | 1477 drivers/staging/media/omap4iss/iss.h | 153 +++ drivers/staging/media/omap4iss/iss_regs.h | 883 + include/media/omap4iss.h | 65 ++ 5 files changed, 2641 insertions(+) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 drivers/staging/media/omap4iss/iss.c create mode 100644 drivers/staging/media/omap4iss/iss.h create mode 100644 drivers/staging/media/omap4iss/iss_regs.h create mode 100644 include/media/omap4iss.h diff --git a/Documentation/video4linux/omap4_camera.txt b/Documentation/video4linux/omap4_camera.txt new file mode 100644 index 000..2ebbd1d --- /dev/null +++ b/Documentation/video4linux/omap4_camera.txt @@ -0,0 +1,63 @@ + OMAP4 ISS Driver + + +Introduction + + +The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS), +Which contains several components that can be categorized in 3 big groups: + +- Interfaces (2 Interfaces: CSI2-A CSI2-B/CCP2) +- ISP (Image Signal Processor) +- SIMCOP (Still Image Coprocessor) + +For more information, please look in [1] for latest version of: + OMAP4430 Multimedia Device Silicon Revision 2.x + +As of Revision AB, the ISS is described in detail in section 8. + +This driver is supporting _only_ the CSI2-A/B interfaces for now. + +It makes use of the Media Controller framework [2], and inherited most of the +code from OMAP3 ISP driver (found under drivers/media/video/omap3isp/*), except Update the omap3isp path. +that it doesn't need an IOMMU now for ISS buffers memory mapping. + +Supports usage of MMAP buffers only (for now). + +IMPORTANT: It is recommended to have this patchset: + Contiguous Memory Allocator (v22) [3]. This note can be removed as CMA has been merged. + +Tested platforms + + +- OMAP4430SDP, w/ ES2.1 GP SEVM4430-CAM-V1-0 (Contains IMX060 OV5640, in + which only the last one is supported, outputting YUV422 frames). + +- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 2 OV5650 sensors, in + which only the OV5650 are supported, outputting RAW10 frames). + +- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP OV adapter board, tested with + following sensors: + * OV5640 + * OV5650 + +- Tested on mainline kernel: + + http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary + + Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7) + +File list +- +drivers/media/video/omap4iss/ Wrong path. +include/media/omap4iss.h + +References +-- + +[1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037templateId=6123#62 +[2] http://lwn.net/Articles/420485/ +[3] http://www.spinics.net/lists/linux-media/msg44370.html +-- +Author: Sergio Aguirre sergio.a.agui...@gmail.com +Copyright (C) 2012, Texas Instruments diff --git a/drivers/staging/media/omap4iss/iss.c b/drivers/staging/media/omap4iss/iss.c new file mode 100644 index 000..d054d9b --- /dev/null +++ b/drivers/staging/media/omap4iss/iss.c @@ -0,0 +1,1477 @@ +/* + * TI OMAP4 ISS V4L2 Driver + * + * Copyright (C) 2012, Texas Instruments + * + * Author: Sergio Aguirre sergio.a.agui...@gmail.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/device.h +#include linux/dma-mapping.h +#include linux/i2c.h +#include linux/interrupt.h +#include linux/module.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/sched.h +#include linux/vmalloc.h + +#include media/v4l2-common.h +#include media/v4l2-device.h +#include media/v4l2-ctrls.h + +#include iss.h
Re: [PATCH 2/6] v4l: omap4iss: Add support for OMAP4 camera interface - Video devices
On 10/03/2013 01:55 AM, Laurent Pinchart wrote:
From: Sergio Aguirre sergio.a.agui...@gmail.com
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds video devices support.
Signed-off-by: Sergio Aguirre sergio.a.agui...@gmail.com
[Port the driver to v3.12-rc3, including the following changes
- Don't include plat/ headers
- Don't use cpu_is_omap44xx() macro
- Don't depend on EXPERIMENTAL
- Fix s_crop operation prototype
- Update link_notify prototype
- Rename media_entity_remote_source to media_entity_remote_pad]
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/media/omap4iss/iss_video.c | 1129
drivers/staging/media/omap4iss/iss_video.h | 201 +
2 files changed, 1330 insertions(+)
create mode 100644 drivers/staging/media/omap4iss/iss_video.c
create mode 100644 drivers/staging/media/omap4iss/iss_video.h
diff --git a/drivers/staging/media/omap4iss/iss_video.c
b/drivers/staging/media/omap4iss/iss_video.c
new file mode 100644
index 000..31f1b88
--- /dev/null
+++ b/drivers/staging/media/omap4iss/iss_video.c
snip
+/*
-
+ * V4L2 ioctls
+ */
+
+static int
+iss_video_querycap(struct file *file, void *fh, struct v4l2_capability *cap)
+{
+ struct iss_video *video = video_drvdata(file);
+
+ strlcpy(cap-driver, ISS_VIDEO_DRIVER_NAME, sizeof(cap-driver));
+ strlcpy(cap-card, video-video.name, sizeof(cap-card));
+ strlcpy(cap-bus_info, media, sizeof(cap-bus_info));
+
+ if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ else
+ cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
Set device_caps instead of capabilities and add:
cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+
+ return 0;
+}
+
+static int
+iss_video_get_format(struct file *file, void *fh, struct v4l2_format *format)
+{
+ struct iss_video_fh *vfh = to_iss_video_fh(fh);
+ struct iss_video *video = video_drvdata(file);
+
+ if (format-type != video-type)
+ return -EINVAL;
+
+ mutex_lock(video-mutex);
+ *format = vfh-format;
+ mutex_unlock(video-mutex);
+
+ return 0;
+}
+
+static int
+iss_video_set_format(struct file *file, void *fh, struct v4l2_format *format)
+{
+ struct iss_video_fh *vfh = to_iss_video_fh(fh);
+ struct iss_video *video = video_drvdata(file);
+ struct v4l2_mbus_framefmt fmt;
+
+ if (format-type != video-type)
+ return -EINVAL;
+
+ mutex_lock(video-mutex);
+
+ /* Fill the bytesperline and sizeimage fields by converting to media bus
+ * format and back to pixel format.
+ */
+ iss_video_pix_to_mbus(format-fmt.pix, fmt);
+ iss_video_mbus_to_pix(video, fmt, format-fmt.pix);
+
+ vfh-format = *format;
+
+ mutex_unlock(video-mutex);
+ return 0;
+}
+
+static int
+iss_video_try_format(struct file *file, void *fh, struct v4l2_format *format)
+{
+ struct iss_video *video = video_drvdata(file);
+ struct v4l2_subdev_format fmt;
+ struct v4l2_subdev *subdev;
+ u32 pad;
+ int ret;
+
+ if (format-type != video-type)
+ return -EINVAL;
+
+ subdev = iss_video_remote_subdev(video, pad);
+ if (subdev == NULL)
+ return -EINVAL;
+
+ iss_video_pix_to_mbus(format-fmt.pix, fmt.format);
+
+ fmt.pad = pad;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt);
+ if (ret)
+ return ret == -ENOIOCTLCMD ? -EINVAL : ret;
Return ENOTTY instead of EINVAL. Even better, use v4l2_subdev_has_op() +
v4l2_disable_ioctl()
to just disable ioctls based on the available subdev ops in probe().
+
+ iss_video_mbus_to_pix(video, fmt.format, format-fmt.pix);
+ return 0;
+}
+
+static int
+iss_video_cropcap(struct file *file, void *fh, struct v4l2_cropcap *cropcap)
+{
+ struct iss_video *video = video_drvdata(file);
+ struct v4l2_subdev *subdev;
+ int ret;
+
+ subdev = iss_video_remote_subdev(video, NULL);
+ if (subdev == NULL)
+ return -EINVAL;
+
+ mutex_lock(video-mutex);
+ ret = v4l2_subdev_call(subdev, video, cropcap, cropcap);
+ mutex_unlock(video-mutex);
+
+ return ret == -ENOIOCTLCMD ? -EINVAL : ret;
+}
+
+static int
+iss_video_get_crop(struct file *file, void *fh, struct v4l2_crop *crop)
+{
+ struct iss_video *video = video_drvdata(file);
+ struct v4l2_subdev_format format;
+ struct v4l2_subdev *subdev;
+ u32 pad;
+ int ret;
+
+ subdev =
Re: [PATCH 0/6] OMAP4 ISS driver
Hi Laurent, On 10/03/2013 01:55 AM, Laurent Pinchart wrote: Hello, The OMAP4 ISS driver has lived out of tree for more than two years now. This situation is both sad and resource-wasting, as the driver has been used (and thus) hacked since then with nowhere to send patches to. Time has come to fix the problem. As the code is mostly, but not quite ready for prime time, I'd like to request its addition to drivers/staging/. I've added a (pretty small) TODO file and I commit to cleaning up the code and get it to drivers/media/ where it belongs. I've split the driver in six patches to avoid getting caught in vger's size and to make review slightly easier. Sergio Aguirre is the driver author (huge thanks for that!), I've thus kept his authorship on patches 1/6 to 5/6. I don't have much else to add here, let's get this beast to mainline and allow other developers to use the driver and contribute patches. Thanks for the patch series! Much appreciated. For this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com I've posted a few comments for the first two patches (nothing jumped out to me for the other patches) that you may want to address in a follow-up patch, particularly the missing timestamp_type for vb2_queue will give a lot of WARN_ON messages in the kernel log. Regards, Hans Laurent Pinchart (1): v4l: omap4iss: Add support for OMAP4 camera interface - Build system Sergio Aguirre (5): v4l: omap4iss: Add support for OMAP4 camera interface - Core v4l: omap4iss: Add support for OMAP4 camera interface - Video devices v4l: omap4iss: Add support for OMAP4 camera interface - CSI receivers v4l: omap4iss: Add support for OMAP4 camera interface - IPIPE(IF) v4l: omap4iss: Add support for OMAP4 camera interface - Resizer Documentation/video4linux/omap4_camera.txt | 63 ++ drivers/staging/media/Kconfig|2 + drivers/staging/media/Makefile |1 + drivers/staging/media/omap4iss/Kconfig | 12 + drivers/staging/media/omap4iss/Makefile |6 + drivers/staging/media/omap4iss/TODO |4 + drivers/staging/media/omap4iss/iss.c | 1477 ++ drivers/staging/media/omap4iss/iss.h | 153 +++ drivers/staging/media/omap4iss/iss_csi2.c| 1368 drivers/staging/media/omap4iss/iss_csi2.h| 156 +++ drivers/staging/media/omap4iss/iss_csiphy.c | 278 + drivers/staging/media/omap4iss/iss_csiphy.h | 51 + drivers/staging/media/omap4iss/iss_ipipe.c | 581 ++ drivers/staging/media/omap4iss/iss_ipipe.h | 67 ++ drivers/staging/media/omap4iss/iss_ipipeif.c | 847 +++ drivers/staging/media/omap4iss/iss_ipipeif.h | 92 ++ drivers/staging/media/omap4iss/iss_regs.h| 883 +++ drivers/staging/media/omap4iss/iss_resizer.c | 905 drivers/staging/media/omap4iss/iss_resizer.h | 75 ++ drivers/staging/media/omap4iss/iss_video.c | 1129 drivers/staging/media/omap4iss/iss_video.h | 201 include/media/omap4iss.h | 65 ++ 22 files changed, 8416 insertions(+) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 drivers/staging/media/omap4iss/Kconfig create mode 100644 drivers/staging/media/omap4iss/Makefile create mode 100644 drivers/staging/media/omap4iss/TODO create mode 100644 drivers/staging/media/omap4iss/iss.c create mode 100644 drivers/staging/media/omap4iss/iss.h create mode 100644 drivers/staging/media/omap4iss/iss_csi2.c create mode 100644 drivers/staging/media/omap4iss/iss_csi2.h create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.c create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.h create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.c create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.h create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.c create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.h create mode 100644 drivers/staging/media/omap4iss/iss_regs.h create mode 100644 drivers/staging/media/omap4iss/iss_resizer.c create mode 100644 drivers/staging/media/omap4iss/iss_resizer.h create mode 100644 drivers/staging/media/omap4iss/iss_video.c create mode 100644 drivers/staging/media/omap4iss/iss_video.h create mode 100644 include/media/omap4iss.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] media: Add pad flag MEDIA_PAD_FL_MUST_CONNECT
Hi Sylwester, On Thu, Oct 03, 2013 at 11:16:59AM +0900, Sylwester Nawrocki wrote: Hi Sakari, On 10/03/2013 08:29 AM, Laurent Pinchart wrote: Hi Sakari, Thank you for the patch. On Thursday 03 October 2013 02:17:50 Sakari Ailus wrote: Pads that set this flag must be connected by an active link for the entity to stream. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Looks good, I would just like to ask for changing my e-mail address on those patches to s.nawro...@samsung.com, sorry for not mentioning it earlier. Just one doubt below regarding name of the flag. Will do. --- Documentation/DocBook/media/v4l/media-ioc-enum-links.xml | 10 ++ include/uapi/linux/media.h |1 + 2 files changed, 11 insertions(+) diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index 355df43..e357dc9 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -134,6 +134,16 @@ entryOutput pad, relative to the entity. Output pads source data and are origins of links./entry /row +row + entryconstantMEDIA_PAD_FL_MUST_CONNECT/constant/entry + entryIf this flag is set and the pad is linked to any other + pad, then at least one of those links must be enabled for the + entity to be able to stream. There could be temporary reasons + (e.g. device configuration dependent) for the pad to need + enabled links even when this flag isn't set; the absence of the + flag doesn't imply there is none. The flag has no effect on pads + without connected links./entry Probably MEDIA_PAD_FL_MUST_CONNECT name is fine, but isn't it more something like MEDIA_PAD_FL_NEED_ACTIVE_LINK ? Or presumably MEDIA_PAD_FL_MUST_CONNECT just doesn't make sense on pads without connected links and should never be set on such pads ? From the last sentence it feels the situation where a pad without a connected link has this flags set is allowed and a valid configuration. Perhaps the last sentence should be something like: The flag should not be used on pads without connected links and has no effect on such pads. Hmm. Good question. My assumption was that such cases might appear when an external entity could be connected to the pad, but receivers typically have just a single pad. So streaming would be out of question in such case anyway. But my thought was that we shouldn't burden drivers by forcing them to unset the flag if there happens to be nothing connected to an entity. How about just that I remove the last sentence, and s/ and the pad is linked to any other pad, then at least one of those links must be enabled/, the pad must be connected by an enabled link/? :-) The purpose is two-fold: to allow automated pipeline validation and also hint the user what are the conditions for that configuration. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP4 ISS driver
Hi Hans, On Thursday 03 October 2013 09:00:07 Hans Verkuil wrote: On 10/03/2013 01:55 AM, Laurent Pinchart wrote: Hello, The OMAP4 ISS driver has lived out of tree for more than two years now. This situation is both sad and resource-wasting, as the driver has been used (and thus) hacked since then with nowhere to send patches to. Time has come to fix the problem. As the code is mostly, but not quite ready for prime time, I'd like to request its addition to drivers/staging/. I've added a (pretty small) TODO file and I commit to cleaning up the code and get it to drivers/media/ where it belongs. I've split the driver in six patches to avoid getting caught in vger's size and to make review slightly easier. Sergio Aguirre is the driver author (huge thanks for that!), I've thus kept his authorship on patches 1/6 to 5/6. I don't have much else to add here, let's get this beast to mainline and allow other developers to use the driver and contribute patches. Thanks for the patch series! Much appreciated. For this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com I've posted a few comments for the first two patches (nothing jumped out to me for the other patches) that you may want to address in a follow-up patch, particularly the missing timestamp_type for vb2_queue will give a lot of WARN_ON messages in the kernel log. Sure, I'll fix those. I wanted to send the code in with as little modifications as possible (I've only made sure that it would compile, as that's the main staging criteria nowadays), I'll tell send follow-up patches to clean the driver and fix problems before moving it to drivers/media/ Laurent Pinchart (1): v4l: omap4iss: Add support for OMAP4 camera interface - Build system Sergio Aguirre (5): v4l: omap4iss: Add support for OMAP4 camera interface - Core v4l: omap4iss: Add support for OMAP4 camera interface - Video devices v4l: omap4iss: Add support for OMAP4 camera interface - CSI receivers v4l: omap4iss: Add support for OMAP4 camera interface - IPIPE(IF) v4l: omap4iss: Add support for OMAP4 camera interface - Resizer Documentation/video4linux/omap4_camera.txt | 63 ++ drivers/staging/media/Kconfig|2 + drivers/staging/media/Makefile |1 + drivers/staging/media/omap4iss/Kconfig | 12 + drivers/staging/media/omap4iss/Makefile |6 + drivers/staging/media/omap4iss/TODO |4 + drivers/staging/media/omap4iss/iss.c | 1477 + drivers/staging/media/omap4iss/iss.h | 153 +++ drivers/staging/media/omap4iss/iss_csi2.c| 1368 + drivers/staging/media/omap4iss/iss_csi2.h| 156 +++ drivers/staging/media/omap4iss/iss_csiphy.c | 278 + drivers/staging/media/omap4iss/iss_csiphy.h | 51 + drivers/staging/media/omap4iss/iss_ipipe.c | 581 ++ drivers/staging/media/omap4iss/iss_ipipe.h | 67 ++ drivers/staging/media/omap4iss/iss_ipipeif.c | 847 +++ drivers/staging/media/omap4iss/iss_ipipeif.h | 92 ++ drivers/staging/media/omap4iss/iss_regs.h| 883 +++ drivers/staging/media/omap4iss/iss_resizer.c | 905 drivers/staging/media/omap4iss/iss_resizer.h | 75 ++ drivers/staging/media/omap4iss/iss_video.c | 1129 drivers/staging/media/omap4iss/iss_video.h | 201 include/media/omap4iss.h | 65 ++ 22 files changed, 8416 insertions(+) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 drivers/staging/media/omap4iss/Kconfig create mode 100644 drivers/staging/media/omap4iss/Makefile create mode 100644 drivers/staging/media/omap4iss/TODO create mode 100644 drivers/staging/media/omap4iss/iss.c create mode 100644 drivers/staging/media/omap4iss/iss.h create mode 100644 drivers/staging/media/omap4iss/iss_csi2.c create mode 100644 drivers/staging/media/omap4iss/iss_csi2.h create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.c create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.h create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.c create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.h create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.c create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.h create mode 100644 drivers/staging/media/omap4iss/iss_regs.h create mode 100644 drivers/staging/media/omap4iss/iss_resizer.c create mode 100644 drivers/staging/media/omap4iss/iss_resizer.h create mode 100644 drivers/staging/media/omap4iss/iss_video.c create mode 100644 drivers/staging/media/omap4iss/iss_video.h create mode 100644 include/media/omap4iss.h -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: [RFC v2 4/4] v4l: events: Don't sleep in dequeue if none are subscribed
On 10/02/13 16:45, Sakari Ailus wrote:
Hi Hans,
Hans Verkuil wrote:
On 10/02/13 16:18, Sakari Ailus wrote:
Hi Hans,
Thanks for the comments!
Hans Verkuil wrote:
On 10/02/13 15:45, Sakari Ailus wrote:
Dequeueing events was is entirely possible even if none are subscribed,
leading to sleeping indefinitely. Fix this by returning -ENOENT when no
events are subscribed.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/v4l2-core/v4l2-event.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c
index b53897e..553a800 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -77,10 +77,17 @@ int v4l2_event_dequeue(struct v4l2_fh *fh, struct
v4l2_event *event,
mutex_unlock(fh-vdev-lock);
do {
-ret = wait_event_interruptible(fh-wait,
- fh-navailable != 0);
+bool subscribed;
Can you add an empty line here?
Sure.
+ret = wait_event_interruptible(
+fh-wait,
+fh-navailable != 0 ||
+!(subscribed = v4l2_event_has_subscribed(fh)));
if (ret 0)
break;
+if (!subscribed) {
+ret = -EIO;
Shouldn't this be -ENOENT?
If I use -ENOENT, having no events subscribed is indistinguishable
form no events pending condition. Combine that with using select(2),
and you can no longer distinguish having no events subscribed from
the case where you got an event but someone else (another thread or
process) dequeued it.
OK, but then your commit message is out of sync with the actual patch since
the commit log says ENOENT.
Right. The error code was the last thing I changed before sending the
patch, and I ignored it was also present in the commit message. :-P
-EIO makes that explicit --- this also mirrors the behaviour of
VIDIOC_DQBUF. (And it must be documented as well, which is missing
from the patch currently.)
I don't like using EIO for this. EIO generally is returned if a hardware
error or an unexpected hardware condition occurs. How about -ENOMSG? Or
perhaps EPIPE? (As in: the pipe containing events is gone).
There is no pipe (or at least wasn't; it's a queue or rather is
implemented as a fifo :)) so of the two I prefer -ENOMSG. What would
you think of -ENODATA or -EPERM (which is used e.g. when writing
read-only controls)?
I don't like ENODATA, mostly because it is so close in meaning to ENOENT.
EPERM would work for me. It's probably a bit better than ENOMSG.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] media: Add pad flag MEDIA_PAD_FL_MUST_CONNECT
On Thursday 03 October 2013 11:43:01 Sakari Ailus wrote: On Thu, Oct 03, 2013 at 11:16:59AM +0900, Sylwester Nawrocki wrote: On 10/03/2013 08:29 AM, Laurent Pinchart wrote: On Thursday 03 October 2013 02:17:50 Sakari Ailus wrote: Pads that set this flag must be connected by an active link for the entity to stream. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Looks good, I would just like to ask for changing my e-mail address on those patches to s.nawro...@samsung.com, sorry for not mentioning it earlier. Just one doubt below regarding name of the flag. Will do. --- Documentation/DocBook/media/v4l/media-ioc-enum-links.xml | 10 ++ include/uapi/linux/media.h |1 + 2 files changed, 11 insertions(+) diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index 355df43..e357dc9 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -134,6 +134,16 @@ entryOutput pad, relative to the entity. Output pads source data and are origins of links./entry /row + row + entryconstantMEDIA_PAD_FL_MUST_CONNECT/constant/entry +entryIf this flag is set and the pad is linked to any other +pad, then at least one of those links must be enabled for the +entity to be able to stream. There could be temporary reasons +(e.g. device configuration dependent) for the pad to need +enabled links even when this flag isn't set; the absence of the +flag doesn't imply there is none. The flag has no effect on pads +without connected links./entry Probably MEDIA_PAD_FL_MUST_CONNECT name is fine, but isn't it more something like MEDIA_PAD_FL_NEED_ACTIVE_LINK ? Or presumably MEDIA_PAD_FL_MUST_CONNECT just doesn't make sense on pads without connected links and should never be set on such pads ? From the last sentence it feels the situation where a pad without a connected link has this flags set is allowed and a valid configuration. If I'm not mistaken, that's a valid configuration. The flag merely says that, if a pad has any link, then one of them must be active (Sakari, please correct me if I'm wrong). Perhaps the last sentence should be something like: The flag should not be used on pads without connected links and has no effect on such pads. Hmm. Good question. My assumption was that such cases might appear when an external entity could be connected to the pad, but receivers typically have just a single pad. So streaming would be out of question in such case anyway. But my thought was that we shouldn't burden drivers by forcing them to unset the flag if there happens to be nothing connected to an entity. How about just that I remove the last sentence, and s/ and the pad is linked to any other pad, then at least one of those links must be enabled/, the pad must be connected by an enabled link/? :-) The purpose is two-fold: to allow automated pipeline validation and also hint the user what are the conditions for that configuration. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 4/4] v4l: events: Don't sleep in dequeue if none are subscribed
On 10/02/13 16:49, Sakari Ailus wrote:
Hans Verkuil wrote:
...
+if (!subscribed) {
+ret = -EIO;
Shouldn't this be -ENOENT?
If I use -ENOENT, having no events subscribed is indistinguishable
form no events pending condition. Combine that with using select(2),
and you can no longer distinguish having no events subscribed from
the case where you got an event but someone else (another thread or
process) dequeued it.
OK, but then your commit message is out of sync with the actual patch since
the commit log says ENOENT.
-EIO makes that explicit --- this also mirrors the behaviour of
VIDIOC_DQBUF. (And it must be documented as well, which is missing
from the patch currently.)
I don't like using EIO for this. EIO generally is returned if a hardware
error or an unexpected hardware condition occurs. How about -ENOMSG? Or
perhaps EPIPE? (As in: the pipe containing events is gone).
Thinking about this some more, -ENOENT is probably what we should
return. *But* when there are no events to dequeue, we should instead
return -EAGAIN (i.e. EWOULDBLOCK) which VIDIOC_DQBUF also uses.
However I'm not sure if anything depends on -ENOENT currently
(probably not really) so changing this might require some
consideration. No error codes are currently defined for
VIDIOC_DQEVENT; was planning to fix that while we're at this.
Urgh, this is messy. In non-blocking mode DQEVENT should indeed return
-EAGAIN if you have subscribed events but no events are pending.
If you have no subscribed events, then -ENOENT would be IMHO the most
suitable return value.
This means that DQEVENT's behavior changes in the non-blocking case.
On the other hand, this is actually what you would expect based on the
EAGAIN description in the spec: It is also returned when the ioctl
would need to wait for an event, but the device was opened in non-blocking
mode.
That said, I don't think we can change it. It's been around for too long
and you have no idea how it is used in embedded systems that are out there
(and that's where you would see this used in practice).
I would just document the ENOENT error code (perhaps with a note that it
should have been EAGAIN) and add a new error (EPERM?) for when no events
are subscribed.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] dvb-usb: fix error handling in ttusb_dec_probe()
The following changes since commit b4559ace2ca8c88666584279f582b998c6591fb0: [media] ts2020: keep 1.06 MHz as default value for frequency_div (2013-10-02 06:48:15 -0300) are available in the git repository at: git://linuxtv.org/mkrufky/dvb ttusb for you to fetch changes up to 6f0be418ace3bf7ebb19434a8308cea2223fe6e4: dvb-usb: fix error handling in ttusb_dec_probe() (2013-10-02 12:00:26 -0400) Alexey Khoroshilov (1): dvb-usb: fix error handling in ttusb_dec_probe() drivers/media/usb/ttusb-dec/ttusb_dec.c | 152 -- 1 file changed, 82 insertions(+), 70 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Adding support for the cx24117 frontend with tbs6980 or tbs6981
The following changes since commit ed94e614c82b4d41d92c82052e915d99614d8b5c: dib9000: fix typo in spelling the word empty (2013-09-30 12:24:48 -0400) are available in the git repository at: git://linuxtv.org/mkrufky/dvb cx24117 for you to fetch changes up to 5dfa5d28c8e636ddb6468defc7e5e7ed07af6945: cx24117: use hybrid_tuner_request/release_state to share state between multiple instances (2013-10-03 07:39:17 -0400) Luis Alves (3): dvb: add cx24117 frontend cx23885: add support for cx24117 with tbs6980 or tbs6981 cx24117: use hybrid_tuner_request/release_state to share state between multiple instances drivers/media/dvb-frontends/Kconfig |7 + drivers/media/dvb-frontends/Makefile |1 + drivers/media/dvb-frontends/cx24117.c | 1651 drivers/media/dvb-frontends/cx24117.h | 47 + drivers/media/pci/cx23885/Kconfig |1 + drivers/media/pci/cx23885/cx23885-cards.c | 67 +++ drivers/media/pci/cx23885/cx23885-dvb.c | 24 +++ drivers/media/pci/cx23885/cx23885-input.c | 12 ++ drivers/media/pci/cx23885/cx23885.h |2 + 9 files changed, 1812 insertions(+) create mode 100644 drivers/media/dvb-frontends/cx24117.c create mode 100644 drivers/media/dvb-frontends/cx24117.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Suspected cache coherency problem on V4L2 and AR7100 CPU
Hi,
I'm debugging a problem with a SOLO6110-based H.264 PCI video encoder on
Atheros AR7100-based (MIPS, big-endian) platform.
The problem manifests itself with stale data being returned by the
driver (using ioctl VIDIOC_DQBUF). The stale date always starts and ends
on 32-byte cache line boundary.
The driver is drivers/staging/media/solo6x10.
Initially I thought the encoder hardware is at fault (though it works on
i686 and on (both endians) ARM). But I've eliminated actual DMA accesses
from the driver and the problems still persists.
The control flow is now basically the following:
- userspace program initializes the adapter and allocates 192 KB long
buffers (at least 2 of them):
open(/dev/video1);
various ioctl() calls
for (cnt = 0; cnt buffer_count; cnt++) {
struct v4l2_buffer buf = {
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
.memory = V4L2_MEMORY_MMAP,
.index = cnt,
};
ioctl(stream-fd, VIDIOC_QUERYBUF, buf);
mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED,
stream-fd, buf.m.offset);
}
and then:
for (cnt = 0; cnt buffer_count; cnt++) {
struct v4l2_buffer buf = {
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
.memory = V4L2_MEMORY_MMAP,
.index = cnt,
ioctl(stream-fd, VIDIOC_QBUF, buf);
}
The buffers are now queued. The driver (upon receiving an encoded frame)
now mostly does:
various spin_lock() etc.
vb = list_first_entry(solo_enc-vidq_active, struct solo_vb2_buf,
list);
list_del(vb-list);
struct vb2_dma_sg_desc *vbuf = vb2_dma_sg_plane_desc(vb, 0);
/* now we have vbuf-sglist which corresponds to a single
userspace 192-KB buffer */
vb2_set_plane_payload(vb, 0, 1024 /* bytes */);
static u32 n = 0; /* a counter to mark each buffer */
/* the following is normally done using dma_map_sg() and DMA,
and also with sg_copy_from_buffer() - eliminated for now */
/* I do the following instead */
struct page *page = sg_page(vbuf-sglist);
u32 *addr = kmap_atomic(page);
/* 4 times as large, I know, the buffer is much longer though */
for (i = 0; i 1024; i++)
addr[i] = n;
flush_dcache_page(page); /* and/or */
flush_kernel_dcache_page(page);
kunmap_atomic(addr);
vb-v4l2_buf.sequence = solo_enc-sequence++;
vb-v4l2_buf.timestamp.tv_sec = vop_sec(vh);
vb-v4l2_buf.timestamp.tv_usec = vop_usec(vh);
vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
The userspace server now does ioctl(VIDIOC_DQBUF), sends it using UDP,
and populates buffer pool again with ioctl(VIDIOC_QBUF).
The driver uses directly-mapped cached (kernel) pointers to access the
buffers (0x8000-0x9FFF kseg0 region) while (obviously)
userspace uses TLB-mapped pointers.
I have verified with a JTAG-based debugger (OpenOCD) that the buffers
are flushed to DRAM (0xAxxx uncached directly-mapped region has
valid data), however the userspace TLB-mapped buffers (which correspond
to the same physical DRAM addresses) partially contain old cached data
(from previous iterations).
The question is which part of the code is at fault, and how do I fix it.
I understand invalidating (and perhaps first flushing) userspace buffers
(cache) should generally fix the problem.
This could also be a simple bug rather than API/platform incompatibility
because usually (though not always) only 1 of the buffers gets corrupted
(the second one of two).
It looks like this - valid buffer, counter n = 0x499, a fragment
of actual UDP packet:
0x0030: 0499 0499 0499 0499
0x0040: 0499 0499 0499 0499
0x0050: 0499 0499 0499 0499
0x0060: 0499 0499 0499 0499
0x0070: 0499 0499 0499 0499
0x0080: 0499 0499 0499 0499
0x0090: 0499 0499 0499 0499
0x00a0: 0499 0499 0499 0499
0x00b0: 0499 0499 0499 0499
next buffer is corrupted, n = 0x49A:
0x0030: 049a 049a 049a 049a
0x0040: 049a 0468 0468 0468 ...h...h...h
0x0050: 0468 0468 0468 0468 ...h...h...h...h
0x0060: 0468 049a 049a 049a ...h
0x0070: 049a 049a 049a 049a
0x0080: 049a 049a 049a 049a
0x0090:
Re: [PATCH v2 1/4] media: Add pad flag MEDIA_PAD_FL_MUST_CONNECT
Hi, On 10/03/2013 11:40 AM, Laurent Pinchart wrote: Documentation/DocBook/media/v4l/media-ioc-enum-links.xml | 10 ++ include/uapi/linux/media.h |1 + 2 files changed, 11 insertions(+) diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index 355df43..e357dc9 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -134,6 +134,16 @@ entryOutput pad, relative to the entity. Output pads source data and are origins of links./entry /row + row + entryconstantMEDIA_PAD_FL_MUST_CONNECT/constant/entry + entryIf this flag is set and the pad is linked to any other + pad, then at least one of those links must be enabled for the + entity to be able to stream. There could be temporary reasons + (e.g. device configuration dependent) for the pad to need + enabled links even when this flag isn't set; the absence of the + flag doesn't imply there is none. The flag has no effect on pads + without connected links./entry Probably MEDIA_PAD_FL_MUST_CONNECT name is fine, but isn't it more something like MEDIA_PAD_FL_NEED_ACTIVE_LINK ? Or presumably MEDIA_PAD_FL_MUST_CONNECT just doesn't make sense on pads without connected links and should never be set on such pads ? From the last sentence it feels the situation where a pad without a connected link has this flags set is allowed and a valid configuration. If I'm not mistaken, that's a valid configuration. The flag merely says that, if a pad has any link, then one of them must be active (Sakari, please correct me if I'm wrong). It may be valid but it just sounds odd to me. Since the pad without a link cannot be connected to anything, how could setting MUST_CONNECT flag on it be logical ? :) I think it's more about name of the flag, since its semantics seems very well described. Perhaps the last sentence should be something like: The flag should not be used on pads without connected links and has no effect on such pads. Hmm. Good question. My assumption was that such cases might appear when an external entity could be connected to the pad, but receivers typically have just a single pad. So streaming would be out of question in such case anyway. But my thought was that we shouldn't burden drivers by forcing them to unset the flag if there happens to be nothing connected to an entity. How about just that I remove the last sentence, and s/ and the pad is linked to any other pad, then at least one of those links must be enabled/, the pad must be connected by an enabled link/?:-) I guess removing the last sentence could be enough, IMHO it's pretty clear also without this sentence the MEDIA_PAD_FL_MUST_CONNECT flag is meaningless on a pad without links. The purpose is two-fold: to allow automated pipeline validation and also hint the user what are the conditions for that configuration. Regards, Sylwester -- 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
looking for loan
Do you have a firm or company that need loan to start up a business or need,personal loan, Debt consolidation? For more information,Contact us now for a guarantee loan with low interest rate. We will provide you with loan to meet your needs. For more information contact us with the following information's. Full name: country: Address: Phone Number: Amount needed: Duration of loan: sg.loan...@outlook.com Kind regards -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] i2c: Remove redundant driver field from the i2c_client struct
On Sun, Sep 29, 2013 at 10:50:58AM +0200, Lars-Peter Clausen wrote: Hi, This series removes the redundant driver field from the i2c_client struct. The field is redundant since the same pointer can be accessed through to_i2c_driver(client-dev.driver). The commit log suggests that the field has been around since forever (since before v2.6.12-rc2) and it looks as if it was simply forgotten to remove it during the conversion of the i2c framework to the generic device driver model. Applied to for-next with great pleasure, thanks! signature.asc Description: Digital signature
[PATCH] v4l2-fh: Add forward declaration for struct file
Pointers to struct file are used as function arguments, but the structure isn't declared. Add a forward declaration. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- include/media/v4l2-fh.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h index a62ee18..76aeec7 100644 --- a/include/media/v4l2-fh.h +++ b/include/media/v4l2-fh.h @@ -28,6 +28,7 @@ #include linux/list.h +struct file; struct video_device; struct v4l2_ctrl_handler; -- 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] v4l2-fh: Add forward declaration for struct file
On Thursday 03 October 2013 23:48:56 Laurent Pinchart wrote: Pointers to struct file are used as function arguments, but the structure isn't declared. Add a forward declaration. Scratch this, I've sent the patch too soon. struct file is dereferenced in v4l2-fh.h, it does need to be properly defined. I'll send the correct patch. Sorry for the noise. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- include/media/v4l2-fh.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h index a62ee18..76aeec7 100644 --- a/include/media/v4l2-fh.h +++ b/include/media/v4l2-fh.h @@ -28,6 +28,7 @@ #include linux/list.h +struct file; struct video_device; struct v4l2_ctrl_handler; -- 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] v4l2-fh: Include linux/fs.h for struct file definition
v4l2-fh.h dereferences struct file, the structure must thus be defined. Pull in its definition by including linux/fs.h. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- include/media/v4l2-fh.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h index a62ee18..0d92208 100644 --- a/include/media/v4l2-fh.h +++ b/include/media/v4l2-fh.h @@ -26,6 +26,7 @@ #ifndef V4L2_FH_H #define V4L2_FH_H +#include linux/fs.h #include linux/list.h struct video_device; -- 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] v4l2-fh: Include linux/videodev2.h for enum v4l2_priority definition
struct v4l2_fh has an enum v4l2_priority field. Make sure the enum definition is available by including linux/videodev2.h. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- include/media/v4l2-fh.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h index 0d92208..528cdaf 100644 --- a/include/media/v4l2-fh.h +++ b/include/media/v4l2-fh.h @@ -28,6 +28,7 @@ #include linux/fs.h #include linux/list.h +#include linux/videodev2.h struct video_device; struct v4l2_ctrl_handler; -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Oct 4 04:00:23 CEST 2013 git branch: test git hash: d10e8280c4c2513d3e7350c27d8e6f0fa03a5f71 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API 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
[PATCH] [media] s5p-mfc: Adjust the default values of some encoder params
The patch sets the default values of MAX_QP and GOP size encoder
parameters to some firmware recommended default values. This enables
the applications to get a better encoded output using the default
settings itself.
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 41f5a3c..4ff3b6c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -113,7 +113,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = (1 16) - 1,
.step = 1,
- .default_value = 0,
+ .default_value = 12,
},
{
.id = V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE,
@@ -356,7 +356,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = 51,
.step = 1,
- .default_value = 1,
+ .default_value = 51,
},
{
.id = V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP,
@@ -399,7 +399,7 @@ static struct mfc_control controls[] = {
.minimum = 1,
.maximum = 31,
.step = 1,
- .default_value = 1,
+ .default_value = 31,
},
{
.id = V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP,
@@ -444,7 +444,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = 51,
.step = 1,
- .default_value = 1,
+ .default_value = 51,
},
{
.id = V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP,
--
1.7.9.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] [media] s5p-mfc: call wake_up_dev if in suspend mode
From: Prathyush K prathyus...@samsung.com
If a frame is still decoding when system enters suspend mode, we wait
on the device queue for a interrupt condition. This sometimes leads to a
timeout because the device queue might not be woken up everytime.
Usually, the context queue gets woken up when that context's frame gets
decoded. This patch adds a condition to wake up the device queue along
with the context queue when the system is in suspend mode.
Since the device queue is now woken up, we don't have to check the
context's int_cond flag while waiting. Also, we can skip calling try_run
after waking up the device queue to ensure that we don't have to wait
for more than one frame to be processed.
Signed-off-by: Prathyush K prathyus...@samsung.com
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 084263d..bec0f61 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -404,7 +404,11 @@ leave_handle_frame:
if (test_and_clear_bit(0, dev-hw_lock) == 0)
BUG();
s5p_mfc_clock_off();
- s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
+ /* if suspending, wake up device and do not try_run again*/
+ if (test_bit(0, dev-enter_suspend))
+ wake_up_dev(dev, reason, err);
+ else
+ s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
}
/* Error handling for interrupt */
@@ -1286,9 +1290,7 @@ static int s5p_mfc_suspend(struct device *dev)
/* Try and lock the HW */
/* Wait on the interrupt waitqueue */
ret = wait_event_interruptible_timeout(m_dev-queue,
- m_dev-int_cond ||
m_dev-ctx[m_dev-curr_ctx]-int_cond,
- msecs_to_jiffies(MFC_INT_TIMEOUT));
-
+ m_dev-int_cond, msecs_to_jiffies(MFC_INT_TIMEOUT));
if (ret == 0) {
mfc_err(Waiting for hardware to finish timed out\n);
return -EIO;
--
1.7.9.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
