Re: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Mauro, Great news, please count me in. We are currently building a new ChromeOS graphics/media stack based on V4L2, vb2, dmabuf, DRM and GL. Synchronization/shared resource usage is one important topic for discussion, as well as, depending on interest, perhaps optimizations like CPU cache maintenance, dmabuf hint/caching sglists, sharing mappings between drivers, etc. Perhaps others would also have something to add to this list. Thanks! Pawel Osciak On Tue, Jul 17, 2012 at 10:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Thanks! Mauro Mensagem original Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 De: Theodore Ts'o ty...@mit.edu Para: James Bottomley james.bottom...@hansenpartnership.com CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel linux-ker...@vger.kernel.org On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: Hi All, We have set aside the second day of the kernel summit (Tuesday 28 August) as mini-summit day. So far we have only the PCI mini summit on this day, so if you can think of other topics, please send them to the kernel summit discuss list: ksummit-2012-disc...@lists.linux-foundation.org Looking at the available rooms, we think we can run about four or five mini summits. As an added incentive, mini summit organisers get to pick who they invite and all the people they pick will get an automatic invitation to the third day of the kernel summit (but not the core first day) and the evening events. OK, so far I believe I've heard concrete suggestions from identified (or fairly well identified :-) stuckees willing to organize mini-summits for: * ARM * Media * PCI * memcg I may have missed some, so if people could send a message to the discuss list with [MINI-SUMMIT] in the subbject line and the name of the proposed mini-summit, that would be really helpful. Please indicate whether you are volunteering to help organize the proposed mini-summit, or identify someone you think can be volunteered. :-) Things that we will be asking the mini-summit chars to determine, in addition to who should be given invites for Tuesday and Wednesday is an estimate of how much time you need, and a list of sub-topics (and who might lead the sub-topic discussion). We will be asking you to create a fairly well-defined schedule, with 30 and 60 minute slots, so that we can publish a schedule and so that people who might need to hop between mini-summits, have a chance to do so. So please start thinking about how long each of your sub-topics will need to be, and who might be needed for a particular sub-topic's discussion to be successful. There may be a number of developers, with fingers in multiple subsystem, where scheduling may become a bit of a challenge. Thanks!! - Ted ___ Ksummit-2012-discuss mailing list ksummit-2012-disc...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss -- 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 -- Best regards, Pawel Osciak -- 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 v3] media: coda: Add driver for Coda video codec.
Hi Pilipp,
On 16 July 2012 19:21, Philipp Zabel p.za...@pengutronix.de wrote:
Hi Javier,
I'm trying to use this driver (on i.MX53) with GStreamer, with two
buffers on the encoded bitstream side. I'm getting negative bytesused
values calculated in coda_isr().
The CODA_REG_BIT_WR_PTR address, which is initialized in
coda_start_streaming() only moves around in the first buffer (so far
attempts to set it from device_run() have failed). This causes negative
bytesused values to be calculated in coda_isr() if the second buffer
(which has a higher BB_START address than WR_PTR) is active.
I'll repeat my observations inline below.
Are you using just one buffer for encoded frames? Does your firmware
behave differently?
Apparently, it does; see an example where I am using two frames:
get_frame: (0) bytesused = 3579
get_frame: (1) bytesused = 3834
get_frame: (0) bytesused = 14925
get_frame: (1) bytesused = 4493
get_frame: (0) bytesused = 3977
get_frame: (1) bytesused = 3855
get_frame: (0) bytesused = 3853
get_frame: (1) bytesused = 3646
get_frame: (0) bytesused = 3797
get_frame: (1) bytesused = 3695
get_frame: (0) bytesused = 3653
get_frame: (1) bytesused = 3770
get_frame: (0) bytesused = 3418
get_frame: (1) bytesused = 3749
get_frame: (0) bytesused = 3621
get_frame: (1) bytesused = 3743
get_frame: (0) bytesused = 3506
get_frame: (1) bytesused = 3523
get_frame: (0) bytesused = 14844
As you can see I don't get any negative values. Furthermore, the
values seem rather correct since as gop_size is 16. There are 15
smaller P frames between two larger I frames.
I see there is a comment about the expected register setting not working
for CODA_REG_BIT_STREAM_CTRL in start_streaming(). Could this be
related?
I don't think so. This means that the following line:
coda_write(dev, (3 3), CODA_REG_BIT_STREAM_CTRL);
should be:
coda_write(dev, (CODADX6_STREAM_BUF_PIC_RESET |
CODADX6_STREAM_BUF_PIC_FLUSH), CODA_REG_BIT_STREAM_CTRL);
But the latter does not work.
Also, I've missed two problems with platform device removal and module
autoloading before, see below.
Fine.
Am Donnerstag, den 12.07.2012, 09:11 +0200 schrieb Javier Martin:
Coda is a range of video codecs from ChipsMedia that
support H.264, H.263, MPEG4 and other video standards.
Currently only support for the codadx6 included in the
i.MX27 SoC is added. H.264 and MPEG4 video encoding
are the only supported capabilities by now.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v2:
- Make hex constants lower case.
- Fix bytesperline.
- Make some functions and variables static.
- Fix logical
- Remove get_qops()
---
[...]
+static int vidioc_g_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+{
+ struct vb2_queue *vq;
+ struct coda_q_data *q_data;
+
+ vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
+ if (!vq)
+ return -EINVAL;
+
+ q_data = get_q_data(ctx, f-type);
+
+ f-fmt.pix.field= V4L2_FIELD_NONE;
+ f-fmt.pix.pixelformat = q_data-fmt-fourcc;
+ if (f-fmt.pix.pixelformat == V4L2_PIX_FMT_YUV420) {
+ f-fmt.pix.width= q_data-width;
+ f-fmt.pix.height = q_data-height;
+ f-fmt.pix.bytesperline = round_up(f-fmt.pix.width, 2);
+ } else { /* encoded formats h.264/mpeg4 */
+ f-fmt.pix.width= 0;
+ f-fmt.pix.height = 0;
+ f-fmt.pix.bytesperline = 0;
+ }
+ f-fmt.pix.sizeimage= q_data-sizeimage;
+
+ return 0;
+}
+
+static int vidioc_g_fmt_vid_out(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+ return vidioc_g_fmt(fh_to_ctx(priv), f);
+}
+
+static int vidioc_g_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+ return vidioc_g_fmt(fh_to_ctx(priv), f);
+}
+
+static int vidioc_try_fmt(struct coda_dev *dev, struct v4l2_format *f)
+{
+ enum v4l2_field field;
+
+ if (!find_format(dev, f))
+ return -EINVAL;
+
+ field = f-fmt.pix.field;
+ if (field == V4L2_FIELD_ANY)
+ field = V4L2_FIELD_NONE;
+ else if (V4L2_FIELD_NONE != field)
+ return -EINVAL;
+
+ /* V4L2 specification suggests the driver corrects the format struct
+ * if any of the dimensions is unsupported */
+ f-fmt.pix.field = field;
+
+ if (f-fmt.pix.pixelformat == V4L2_PIX_FMT_YUV420) {
+ v4l_bound_align_image(f-fmt.pix.width, MIN_W, MAX_W,
+ W_ALIGN, f-fmt.pix.height,
+ MIN_H, MAX_H, H_ALIGN, S_ALIGN);
+ f-fmt.pix.bytesperline = round_up(f-fmt.pix.width, 2);
+ f-fmt.pix.sizeimage = f-fmt.pix.height *
+ f-fmt.pix.bytesperline;
+ } else { /*encoded formats h.264/mpeg4 */
+ f-fmt.pix.bytesperline =
Re: [RFC/PATCH 06/13] media: s5p-fimc: Add device tree support for FIMC-LITE
Hi Sylwester On Tue, 17 Jul 2012, Sylwester Nawrocki wrote: On 07/16/2012 11:15 AM, Guennadi Liakhovetski wrote: --- a/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt @@ -39,6 +39,21 @@ Required properties: depends on the SoC revision. For S5PV210 valid values are: 0...2, for Exynos4x1x: 0...3. + +'fimc-lite' device node +--- + +Required properties: + +- compatible : should be one of: + samsung,exynos4212-fimc; + samsung,exynos4412-fimc; +- reg : physical base address and size of the device's memory mapped +registers; +- interrupts : should contain FIMC-LITE interrupt; +- cell-index : FIMC-LITE IP instance index; Same as in an earlier patch - not sure this is needed. It is needed for setting up a pipeline of multiple sub-device within a SoC. As I commented on patch 2/13 I'd like to replace this with proper entries in the aliases node. Some sub-devices have registers that these indexes need to be directly written to. Aha, so, these are not purely software indices, that you just use to identify your devices, these are actual hardware values? You really have to write, e.g., 1 into a resizer register to connect it to a certain capture engine? Ok, in this case it indeed might make sense to have these values in the DT. Not sure how best to call these properties, or whether aliases is the best solution, but that's already a detail. And btw, if you do decide to keep this as a property, maybe this is one of the cases, where you'd want to mark it with your hardware type, like fimc,cell-id or similar? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 05/13] media: s5p-fimc: Add device tree support for FIMC devices
On Tue, 17 Jul 2012, Sylwester Nawrocki wrote: On 07/16/2012 11:13 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Karol Lewandowskik.lewando...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com From the documentation below I think, I understand what it does, but why is it needed? It doesn't describe your video subsystem topology, right? How various subdevices are connected. It just lists them all in one node... A description for this patch would be very welcome IMHO and, maybe, such a node can be completely avoided? Sorry, I'll provide better description in next iteration. It's true it doesn't describe the topology in detail, as there are multiple one-to many possible connections between sub-devices. An exact topology is coded in the driver and can be changed through MC API. The samsung,camif-mux-id and video-bus-type properties at sensor nodes just specify to which physical SoC camera port an image sensor is connected. So, don't you think my media-link child nodes are a good solution for this? Originally the all camera devices were supposed to land under common 'camera' node. And a top level driver would be registering all platform devices. With this approach it would be possible to better control PM handling (which currently depends on an order of registering devices to the driver core). But then we discovered that we couldn't use OF_DEV_AUXDATA in such case, which was required to preserve platform device names, in order for the clock API to work. So I've moved some sub-devices out of 'camera' node and have added only a list of phandles to them in that node. This is rather a cheap workaround.. I think all camera sub-devices should be placed under common node, as there are some properties that don't belong to any sub-node: GPIO config, clocks, to name a few. Of course simpler devices might not need such a composite node. I think we can treat the sub-device interdependencies as an issue separate from a need for a common node. If some devices need to reflect the topology better, we probably could include in some nodes (a list of) phandles to other nodes. This could ease parsing the topology at the drivers, by using existing OF infrastructure. Ok, I think you have some good ideas in your RFC's, an interesting question now is - how to proceed. Do you think we'd be able to work out a combined RFC? Or would you prefer to make two versions and then see what others think? In either case it would be nice, I think, if you could try to separate what you see as common V4L DT bindings, then we could discuss that separately. Whereas what you think is private to your hardware, we can also look at for common ideas, or maybe even some of those properties we'll wake to make common too. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for 3.5] v4l2-dev: forgot to add VIDIOC_DV_TIMINGS_CAP.
Hi Linus, I'm sending the attached one-liner patch directly to you for inclusion in 3.5 as without it the new VIDIOC_DV_TIMINGS_CAP ioctl doesn't work. The cause was that for 3.5 two patch series were merged, one changing V4L2 core ioctl handling and one adding new functionality, and some of the new functionality wasn't handled by the new V4L2 core code. Mauro is still on a well-deserved vacation, so I'm sending it to you directly so it can be merged for 3.5 before it is released. Regards, Hans From 3a9fa27511a2ed13a24ed431879557ddb3ca406b Mon Sep 17 00:00:00 2001 Message-Id: 3a9fa27511a2ed13a24ed431879557ddb3ca406b.1342592537.git.hans.verk...@cisco.com From: Hans Verkuil hans.verk...@cisco.com Date: Wed, 11 Jul 2012 14:12:45 +0200 Subject: [PATCH 1/2] v4l2-dev: forgot to add VIDIOC_DV_TIMINGS_CAP. The VIDIOC_DV_TIMINGS_CAP ioctl check wasn't added to determine_valid_ioctls(). This caused this ioctl to always return -ENOTTY. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/v4l2-dev.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 83dbb2d..0cbada1 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -681,6 +681,7 @@ static void determine_valid_ioctls(struct video_device *vdev) SET_VALID_IOCTL(ops, VIDIOC_G_DV_TIMINGS, vidioc_g_dv_timings); SET_VALID_IOCTL(ops, VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings); SET_VALID_IOCTL(ops, VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings); + SET_VALID_IOCTL(ops, VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap); /* yes, really vidioc_subscribe_event */ SET_VALID_IOCTL(ops, VIDIOC_DQEVENT, vidioc_subscribe_event); SET_VALID_IOCTL(ops, VIDIOC_SUBSCRIBE_EVENT, vidioc_subscribe_event); -- 1.7.10.4
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Laurent On Wed, 18 Jul 2012, Laurent Pinchart wrote: Hi Guennadi, On Tuesday 17 July 2012 21:51:02 Guennadi Liakhovetski wrote: On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd love to attend, especially since, as you have seen, I've started doing some work on V4L DT bindings, As you already know, that's a topic I'm very interested in. DT bindings will likely involve rethinking how the V4L2 core and V4L2 drivers instantiate subdevices, a media summit would have been a good occasion to discuss that. However, we probably need an RFC to start with. You've certainly seen these two RFCs currently being discussed: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/50755 http://thread.gmane.org/gmane.linux.kernel.samsung-soc/11143 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: coda: Add driver for Coda video codec.
Hi Javier, Am Mittwoch, den 18.07.2012, 09:12 +0200 schrieb javier Martin: [...] I see there is a comment about the expected register setting not working for CODA_REG_BIT_STREAM_CTRL in start_streaming(). Could this be related? I don't think so. This means that the following line: coda_write(dev, (3 3), CODA_REG_BIT_STREAM_CTRL); should be: coda_write(dev, (CODADX6_STREAM_BUF_PIC_RESET | CODADX6_STREAM_BUF_PIC_FLUSH), CODA_REG_BIT_STREAM_CTRL); But the latter does not work. Looks to me like (3 3) == (CODA7_STREAM_BUF_PIC_RESET | CODA7_STREAM_BUF_PIC_FLUSH) could be the explanation. Maybe the documentation about CODADX6_STREAM_BUF_PIC_RESET | CODADX6_STREAM_BUF_PIC_FLUSH was outdated? Also, I've missed two problems with platform device removal and module autoloading before, see below. Fine. [...] I will send a new v4 with the 'platform' and 'bytesused' issues fixed. Regarding your i.MX53 problems I suppose they should be addressed conditionally in a patch on top of this one where i.MX53 support is added too. What do you think? Agreed. After fixing the issues in vidioc_try_fmt, MODULE_DEVICE_TABLE, and coda_remove, feel free to add a Reviewed-by: Philipp Zabel p.za...@pengutronix.de regards Philipp -- 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 v3] media: coda: Add driver for Coda video codec.
On 18 July 2012 10:35, Philipp Zabel p.za...@pengutronix.de wrote: Hi Javier, Am Mittwoch, den 18.07.2012, 09:12 +0200 schrieb javier Martin: [...] I see there is a comment about the expected register setting not working for CODA_REG_BIT_STREAM_CTRL in start_streaming(). Could this be related? I don't think so. This means that the following line: coda_write(dev, (3 3), CODA_REG_BIT_STREAM_CTRL); should be: coda_write(dev, (CODADX6_STREAM_BUF_PIC_RESET | CODADX6_STREAM_BUF_PIC_FLUSH), CODA_REG_BIT_STREAM_CTRL); But the latter does not work. Looks to me like (3 3) == (CODA7_STREAM_BUF_PIC_RESET | CODA7_STREAM_BUF_PIC_FLUSH) could be the explanation. You mean !=, don't you? Maybe the documentation about CODADX6_STREAM_BUF_PIC_RESET | CODADX6_STREAM_BUF_PIC_FLUSH was outdated? Maybe some of these two defines is wrong, I don't know exactly. Maybe when support for other coda versions is added we'll find out. To clarify my magic value (3 3) I decided to add a comment explaining that what I am doing is a reset and flush. Also, I've missed two problems with platform device removal and module autoloading before, see below. Fine. [...] I will send a new v4 with the 'platform' and 'bytesused' issues fixed. Regarding your i.MX53 problems I suppose they should be addressed conditionally in a patch on top of this one where i.MX53 support is added too. What do you think? Agreed. After fixing the issues in vidioc_try_fmt, MODULE_DEVICE_TABLE, and coda_remove, feel free to add a Reviewed-by: Philipp Zabel p.za...@pengutronix.de OK I expect to send v4 during the morning. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
[RFCv2 PATCH 3/7] v4l2-subdev: add support for the new edid ioctls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ioctl.c | 13 +
drivers/media/video/v4l2-subdev.c |6 ++
include/media/v4l2-subdev.h |2 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 70e0efb..b2aa957 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2099,6 +2099,19 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
break;
}
+ case VIDIOC_SUBDEV_G_EDID:
+ case VIDIOC_SUBDEV_S_EDID: {
+ struct v4l2_subdev_edid *edid = parg;
+
+ if (edid-blocks) {
+ *user_ptr = (void __user *)edid-edid;
+ *kernel_ptr = (void *)edid-edid;
+ *array_size = edid-blocks * 128;
+ ret = 1;
+ }
+ break;
+ }
+
case VIDIOC_S_EXT_CTRLS:
case VIDIOC_G_EXT_CTRLS:
case VIDIOC_TRY_EXT_CTRLS: {
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 9182f81..dced41c 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -348,6 +348,12 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
return v4l2_subdev_call(
sd, pad, set_selection, subdev_fh, sel);
}
+
+ case VIDIOC_SUBDEV_G_EDID:
+ return v4l2_subdev_call(sd, pad, get_edid, arg);
+
+ case VIDIOC_SUBDEV_S_EDID:
+ return v4l2_subdev_call(sd, pad, set_edid, arg);
#endif
default:
return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index c35a354..74c578f 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -476,6 +476,8 @@ struct v4l2_subdev_pad_ops {
struct v4l2_subdev_selection *sel);
int (*set_selection)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_selection *sel);
+ int (*get_edid)(struct v4l2_subdev *sd, struct v4l2_subdev_edid *edid);
+ int (*set_edid)(struct v4l2_subdev *sd, struct v4l2_subdev_edid *edid);
#ifdef CONFIG_MEDIA_CONTROLLER
int (*link_validate)(struct v4l2_subdev *sd, struct media_link *link,
struct v4l2_subdev_format *source_fmt,
--
1.7.10
--
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
[RFCv2 PATCH 1/7] v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
These new controls and two new ioctls make it possible to properly support
VGA, DVI-A/D/I, HDMI and DisplayPort connectors. All these controls and the
ioctls are all at the sub-device level. They are meant for V4L2 bridge/platform
drivers or to be accessed on embedded systems through /dev/v4l-subdev* device
nodes.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/v4l2-subdev.h | 10 ++
include/linux/videodev2.h | 23 +++
2 files changed, 33 insertions(+)
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
index 8c57ee9..a426a78 100644
--- a/include/linux/v4l2-subdev.h
+++ b/include/linux/v4l2-subdev.h
@@ -148,6 +148,14 @@ struct v4l2_subdev_selection {
__u32 reserved[8];
};
+struct v4l2_subdev_edid {
+ __u32 pad;
+ __u32 start_block;
+ __u32 blocks;
+ __u32 reserved[5];
+ __u8 __user *edid;
+};
+
#define VIDIOC_SUBDEV_G_FMT_IOWR('V', 4, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_S_FMT_IOWR('V', 5, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_G_FRAME_INTERVAL \
@@ -166,5 +174,7 @@ struct v4l2_subdev_selection {
_IOWR('V', 61, struct v4l2_subdev_selection)
#define VIDIOC_SUBDEV_S_SELECTION \
_IOWR('V', 62, struct v4l2_subdev_selection)
+#define VIDIOC_SUBDEV_G_EDID _IOWR('V', 63, struct v4l2_subdev_edid)
+#define VIDIOC_SUBDEV_S_EDID _IOWR('V', 64, struct v4l2_subdev_edid)
#endif
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5d78910..4285496 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1246,6 +1246,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_JPEG 0x009d/* JPEG-compression
controls */
#define V4L2_CTRL_CLASS_IMAGE_SOURCE 0x009e/* Image source
controls */
#define V4L2_CTRL_CLASS_IMAGE_PROC 0x009f /* Image processing controls */
+#define V4L2_CTRL_CLASS_DV 0x00a0 /* Digital Video controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1989,6 +1990,28 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
+/* DV-class control IDs defined by V4L2 */
+#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
+#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
+
+#defineV4L2_CID_DV_TX_HOTPLUG (V4L2_CID_DV_CLASS_BASE
+ 1)
+#defineV4L2_CID_DV_TX_RXSENSE (V4L2_CID_DV_CLASS_BASE
+ 2)
+#defineV4L2_CID_DV_TX_EDID_PRESENT (V4L2_CID_DV_CLASS_BASE
+ 3)
+#defineV4L2_CID_DV_TX_MODE (V4L2_CID_DV_CLASS_BASE
+ 4)
+enum v4l2_dv_tx_mode {
+ V4L2_DV_TX_MODE_DVI_D = 0,
+ V4L2_DV_TX_MODE_HDMI= 1,
+};
+#define V4L2_CID_DV_TX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 5)
+enum v4l2_dv_rgb_range {
+ V4L2_DV_RGB_RANGE_AUTO= 0,
+ V4L2_DV_RGB_RANGE_LIMITED = 1,
+ V4L2_DV_RGB_RANGE_FULL= 2,
+};
+
+#defineV4L2_CID_DV_RX_POWER_PRESENT(V4L2_CID_DV_CLASS_BASE
+ 100)
+#define V4L2_CID_DV_RX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 101)
+
/*
* T U N I N G
*/
--
1.7.10
--
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
[RFCv2 PATCH 0/7] Add adv7604/ad9389b drivers
Hi all, This is the second version of this patch series. The only changes since the first version are in the adv7604 and ad9389b drivers themselves: - adv7604: fixed some incorrect error codes (-1 instead of -EIO) - ad9389b+adv7604: fixed incorrect v4l2_ctrl_new_std_menu arguments. - ad9389b+adv7604: don't set v4l2_ctrl_ops for status controls, there is nothing to do for the ops. - ad9389b+adv7604: zero the reserved array of enum_dv_timings. - ad9389b: make DVI-D the default connector mode as that will also work if the HDMI connector is hooked up to a DVI-D connector through an adapter. The original text of this patch series follows below. If there are no more comments, then I want to make the final pull request early next week. Regards, Hans Text from the first version of the patch series: This RFC patch series builds on an earlier RFC patch series (posted only to linux-media) that adds support for DVI/HDMI/DP connectors to the V4L2 API. This earlier patch series is here: http://www.spinics.net/lists/linux-media/msg48529.html The first 3 patches are effectively unchanged compared to that patch series, patch 4 adds support for the newly defined controls to the V4L2 control framework and patch 5 adds helper functions to v4l2-common.c to help in detecting VESA CVT and GTF formats. Finally, two Analog Devices drivers are added to actually use this new API. The adv7604 is an HDMI/DVI receiver and the ad9389b is an HDMI transmitter. Another tree of mine also contains preliminary drivers for the adv7842 and adv7511: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/hdmi However, I want to start with adv7604 and ad9389b since those have had the most testing. As the commit message of says these drivers do not implement the full functionality of these devices, but that can be added later, either by Cisco or by others. A lot of work has been put into the V4L2 subsystem to reach this point, particularly the control framework, the VIDIOC_G/S/ENUM/QUERY_DV_TIMINGS ioctls, and the V4L2 event mechanism. So I'm very pleased to be able to finally post this code. Comments are welcome! Regards, Hans Verkuil -- 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
[RFCv2 PATCH 2/7] V4L2 spec: document the new DV controls and ioctls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/controls.xml | 149 +++ Documentation/DocBook/media/v4l/v4l2.xml |1 + .../DocBook/media/v4l/vidioc-subdev-g-edid.xml | 152 3 files changed, 302 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 43ca749..4ba5e76 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4269,4 +4269,153 @@ interface and may change in the future./para /table /section + +section id=dv-controls + titleDigital Video Control Reference/title + + note + titleExperimental/title + + paraThis is an link + linkend=experimentalexperimental/link interface and may + change in the future./para + /note + + para + The Digital Video control class is intended to control receivers + and transmitters for VGA, DVI, HDMI and DisplayPort. These controls + are generally expected to be private to the receiver or transmitter + subdevice that implements them, so they are only exposed on the + filename/dev/v4l-subdev*/filename device node. + /para + + paraNote that these devices can have multiple input or output pads which are + hooked up to e.g. HDMI connectors. Even though the subdevice will receive or + transmit video from/to only one of those pads, the other pads can still be + active when it comes to EDID and HDCP processing, allowing the device + to do the fairly slow EDID/HDCP handling in advance. This allows for quick + switching between connectors./para + + paraThese pads appear in several of the controls in this section as + bitmasks, one bit for each pad starting at bit 0. The maximum value of + the control is the set of valid pads./para + + table pgwide=1 frame=none id=dv-control-id + titleDigital Video Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* / + colspec colname=c2 colwidth=6* / + colspec colname=c3 colwidth=2* / + colspec colname=c4 colwidth=6* / + spanspec namest=c1 nameend=c2 spanname=id / + spanspec namest=c2 nameend=c4 spanname=descr / + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_DV_CLASS/constant/entry + entryclass/entry + /row + row + entry spanname=descrThe DV class descriptor./entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_HOTPLUG/constant/entry + entrybitmask/entry + /row + row + entry spanname=descrMany connectors have a hotplug pin which is high + if EDID information is available from the source. This control shows the + state of the hotplug pin as seen by the transmitter. + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + /entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_RXSENSE/constant/entry + entrybitmask/entry + /row + row + entry spanname=descrRx Sense is the detection of pull-ups on the TMDS +clock lines. This normally means that the sink has left/entered standby (i.e. + the transmitter can sense that the receiver is ready to receive video). + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to DVI-D and HDMI devices. + /entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_EDID_PRESENT/constant/entry + entrybitmask/entry + /row + row + entry spanname=descrWhen the transmitter sees the hotplug signal from the + receiver it will attempt to read the EDID. If set, then the transmitter has read + at least the first block (= 128 bytes). + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + /entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_MODE/constant/entry + entry id=v4l2-dv-tx-modeenum v4l2_dv_tx_mode/entry + /row + row + entry spanname=descrHDMI transmitters can transmit in DVI-D mode (just video) + or in HDMI mode (video + audio +
[RFCv2 PATCH 4/7] v4l2-ctrls.c: add support for the new DV controls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 9abd9ab..a664795 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -425,6 +425,18 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Gray,
NULL,
};
+ static const char * const dv_tx_mode[] = {
+ DVI-D,
+ HDMI,
+ NULL,
+ };
+ static const char * const dv_rgb_range[] = {
+ Automatic,
+ RGB limited range (16-235),
+ RGB full range (0-255),
+ NULL,
+ };
+
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +514,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DV_TX_MODE:
+ return dv_tx_mode;
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
+ return dv_rgb_range;
default:
return NULL;
@@ -733,6 +750,16 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_LINK_FREQ:return Link Frequency;
case V4L2_CID_PIXEL_RATE: return Pixel Rate;
+ /* DV controls */
+ case V4L2_CID_DV_CLASS: return Digital Video Controls;
+ case V4L2_CID_DV_TX_HOTPLUG:return Hotplug Present;
+ case V4L2_CID_DV_TX_RXSENSE:return RxSense Present;
+ case V4L2_CID_DV_TX_EDID_PRESENT: return EDID Present;
+ case V4L2_CID_DV_TX_MODE: return Transmit Mode;
+ case V4L2_CID_DV_TX_RGB_RANGE: return Tx RGB Quantization
Range;
+ case V4L2_CID_DV_RX_POWER_PRESENT: return Power Present;
+ case V4L2_CID_DV_RX_RGB_RANGE: return Rx RGB Quantization
Range;
+
default:
return NULL;
}
@@ -831,6 +858,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DV_TX_MODE:
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
@@ -852,6 +882,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_CLASS:
case V4L2_CID_IMAGE_SOURCE_CLASS:
case V4L2_CID_IMAGE_PROC_CLASS:
+ case V4L2_CID_DV_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -868,6 +899,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_ACTIVE_MARKER:
case V4L2_CID_3A_LOCK:
case V4L2_CID_AUTO_FOCUS_STATUS:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
@@ -932,6 +967,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FLASH_STROBE_STATUS:
case V4L2_CID_AUTO_FOCUS_STATUS:
case V4L2_CID_FLASH_READY:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
}
--
1.7.10
--
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
[RFCv2 PATCH 7/7] ad9389b: driver for the Analog Devices AD9389B video encoder.
Initial version of this driver.
The full datasheets are available from the Analog Devices website:
http://ez.analog.com/docs/DOC-1741
Not all features of the receiver are supported by this driver for various
reasons. Most notably:
- No CEC support (the CEC API needs a lot more discussion)
- No HDCP repeater support (we don't use that either)
I'm sure that there are more things missing, but this driver does work
well for our hardware.
Note that I am using the register addresses instead of register names: the
datasheet containing the register descriptions is organized by register
address. Using names would make the datasheet lookup very hard. An attempt
was made to try and document what is being done when registers are used
instead.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/Kconfig | 11 +
drivers/media/video/Makefile|1 +
drivers/media/video/ad9389b.c | 1328 +++
include/media/ad9389b.h | 49 ++
include/media/v4l2-chip-ident.h |3 +
5 files changed, 1392 insertions(+)
create mode 100644 drivers/media/video/ad9389b.c
create mode 100644 include/media/ad9389b.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 80f8472..f0c91c3 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -483,6 +483,17 @@ config VIDEO_ADV7393
To compile this driver as a module, choose M here: the
module will be called adv7393.
+config VIDEO_AD9389B
+ tristate Analog Devices AD9389B encoder
+ depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices AD9389B video encoder.
+
+ This is a Analog Devices HDMI transmitter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad9389b.
+
config VIDEO_AK881X
tristate AK8813/AK8814 video encoders
depends on I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 447cc7a..a1c326e 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/video/ad9389b.c b/drivers/media/video/ad9389b.c
new file mode 100644
index 000..c2886b6
--- /dev/null
+++ b/drivers/media/video/ad9389b.c
@@ -0,0 +1,1328 @@
+/*
+ * Analog Devices AD9389B/AD9889B video encoder driver
+ *
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/*
+ * References (c = chapter, p = page):
+ * REF_01 - Analog Devices, Programming Guide, AD9889B/AD9389B,
+ * HDMI Transitter, Rev. A, October 2010
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/videodev2.h
+#include linux/workqueue.h
+#include linux/v4l2-dv-timings.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+#include media/ad9389b.h
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+MODULE_DESCRIPTION(Analog Devices AD9389B/AD9889B video encoder driver);
+MODULE_AUTHOR(Hans Verkuil hans.verk...@cisco.com);
+MODULE_AUTHOR(Martin Bugge marbu...@cisco.com);
+MODULE_LICENSE(GPL);
+
+#define MASK_AD9389B_EDID_RDY_INT 0x04
+#define MASK_AD9389B_MSEN_INT 0x40
+#define MASK_AD9389B_HPD_INT0x80
+
+#define MASK_AD9389B_HPD_DETECT 0x40
+#define MASK_AD9389B_MSEN_DETECT0x20
+#define MASK_AD9389B_EDID_RDY 0x10
+
+#define EDID_MAX_RETRIES (8)
+#define EDID_DELAY 250
+#define EDID_MAX_SEGM 8
+
+/*
+**
+*
+* Arrays with configuration parameters for the AD9389B
+*
+**
+*/
+
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+};
+
+struct
[RFCv2 PATCH 5/7] v4l2-common: add CVT and GTF detection functions.
These two helper functions detect whether the analog video timings detected
by the video receiver match the VESA CVT or GTF standards.
They basically do the inverse of the CVT and GTF modeline calculations.
This patch also adds a helper function that will determine the aspect ratio
based on the provided EDID values. This aspect ratio can be given to the GTF
helper function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-common.c | 358 +
include/media/v4l2-common.h | 13 ++
2 files changed, 371 insertions(+)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1baec83..33e57d8 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -597,6 +597,364 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
}
EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info);
+/**
+ * v4l_match_dv_timings - check if two timings match
+ * @t1 - compare this v4l2_dv_timings struct...
+ * @t2 - with this struct.
+ * @pclock_delta - the allowed pixelclock deviation.
+ *
+ * Compare t1 with t2 with a given margin of error for the pixelclock.
+ */
+bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
+ const struct v4l2_dv_timings *t2,
+ unsigned pclock_delta)
+{
+ if (t1-type != t2-type || t1-type != V4L2_DV_BT_656_1120)
+ return false;
+ if (t1-bt.width == t2-bt.width
+ t1-bt.height == t2-bt.height
+ t1-bt.interlaced == t2-bt.interlaced
+ t1-bt.polarities == t2-bt.polarities
+ t1-bt.pixelclock = t2-bt.pixelclock - pclock_delta
+ t1-bt.pixelclock = t2-bt.pixelclock + pclock_delta
+ t1-bt.hfrontporch == t2-bt.hfrontporch
+ t1-bt.vfrontporch == t2-bt.vfrontporch
+ t1-bt.vsync == t2-bt.vsync
+ t1-bt.vbackporch == t2-bt.vbackporch
+ (!t1-bt.interlaced ||
+ (t1-bt.il_vfrontporch == t2-bt.il_vfrontporch
+t1-bt.il_vsync == t2-bt.il_vsync
+t1-bt.il_vbackporch == t2-bt.il_vbackporch)))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+
+/*
+ * CVT defines
+ * Based on Coordinated Video Timings Standard
+ * version 1.1 September 10, 2003
+ */
+
+#define CVT_PXL_CLK_GRAN 25 /* pixel clock granularity */
+
+/* Normal blanking */
+#define CVT_MIN_V_BPORCH 7 /* lines */
+#define CVT_MIN_V_PORCH_RND3 /* lines */
+#define CVT_MIN_VSYNC_BP 550 /* min time of vsync + back porch (us)
*/
+
+/* Normal blanking for CVT uses GTF to calculate horizontal blanking */
+#define CVT_CELL_GRAN 8 /* character cell granularity */
+#define CVT_M 600 /* blanking formula gradient */
+#define CVT_C 40 /* blanking formula offset */
+#define CVT_K 128 /* blanking formula scaling factor */
+#define CVT_J 20 /* blanking formula scaling factor */
+#define CVT_C_PRIME (((CVT_C - CVT_J) * CVT_K / 256) + CVT_J)
+#define CVT_M_PRIME (CVT_K * CVT_M / 256)
+
+/* Reduced Blanking */
+#define CVT_RB_MIN_V_BPORCH7 /* lines */
+#define CVT_RB_V_FPORCH3 /* lines */
+#define CVT_RB_MIN_V_BLANK 460 /* us */
+#define CVT_RB_H_SYNC 32 /* pixels */
+#define CVT_RB_H_BPORCH 80 /* pixels */
+#define CVT_RB_H_BLANK 160 /* pixels */
+
+/** v4l2_detect_cvt - detect if the given timings follow the CVT standard
+ * @frame_height - the total height of the frame (including blanking) in lines.
+ * @hfreq - the horizontal frequency in Hz.
+ * @vsync - the height of the vertical sync in lines.
+ * @polarities - the horizontal and vertical polarities (same as struct
+ * v4l2_bt_timings polarities).
+ * @fmt - the resulting timings.
+ *
+ * This function will attempt to detect if the given values correspond to a
+ * valid CVT format. If so, then it will return true, and fmt will be filled
+ * in with the found CVT timings.
+ */
+bool v4l2_detect_cvt(unsigned frame_height, unsigned hfreq, unsigned vsync,
+ u32 polarities, struct v4l2_dv_timings *fmt)
+{
+ int v_fp, v_bp, h_fp, h_bp, hsync;
+ int frame_width, image_height, image_width;
+ bool reduced_blanking;
+ unsigned pix_clk;
+
+ if (vsync 4 || vsync 7)
+ return false;
+
+ if (polarities == V4L2_DV_VSYNC_POS_POL)
+ reduced_blanking = false;
+ else if (polarities == V4L2_DV_HSYNC_POS_POL)
+ reduced_blanking = true;
+ else
+ return false;
+
+ /* Vertical */
+ if (reduced_blanking) {
+ v_fp = CVT_RB_V_FPORCH;
+ v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 99) / 100;
+ v_bp -= vsync + v_fp;
+
+
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Guennadi, On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. +- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601; If this is a boolean property, it cannot be required? Otherwise, as discussed in a different patch comment, this property might not be required, and if it is, I would use the same definition for both the camera interface and for sensors. Yeah, that's an omission, a leftover from previous versions. It should have been 'video-bus-type', for this series. Here is the updated binding documentation: 8-- Required properties: - compatible : samsung,s5k6aafx; - reg : base address of the device on I2C bus; - vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V); - vdda-supply : analog circuits voltage supply 2.8V (2.6V to 3.0V); - vdd_reg-supply : regulator input voltage supply 1.8V (1.7V to 1.9V) or 2.8V (2.6V to 3.0); - vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V) or 2.8V (2.5V to 3.1V); - video-bus-type : sensor video output bus type, must be one of: itu-601, mipi-csi2; - clock-frequency : the sensor's master clock frequency in Hz; Optional properties: - data-lanes : number of physical MIPI-CSI2 data lanes used (default is 2 when this property is not specified); - gpios : specifies gpios connected to the sensor's reset reset (RSTN) and standby (STBYN) pins, the order of gpios is: RSTN, STBYN; If any of these gpios is not used, its specifier shall be 0; - samsung,s5k6aa-gpio-lvls : this property (bits [1:0]) specifies an active state of the S5K6AAFX reset and stand-by signals; the meaning of bits is: bit[1:0] = [RST, STBY], e.g. bit[1] = 0 indicates the GPIO driving the S5K6AAFX's standby pin should be set to 1 to bring the sensor out from stand-by to normal operation state. - samsung,s5k6aa-hflip : sets the default horizontal image flipping; - samsung,s5k6aa-vflip : sets the default vertical image flipping; 8-- +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V); +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V); +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to 1.9V) + or 2.8V (2.6V to 3.0); I think, underscores in property names are generally frowned upon. Indeed, I felt something might be wrong here;) It's in this form because I just copied regulator supply names from the existing driver. And I didn't want to change them, to avoid updating them in all board files where they're used. Thanks for pointing it out, I'll fix that in next iteration. +- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V) + or 2.8V (2.5V to 3.1V); + +Optional properties: + +- clock-frequency : the IP's main (system bus) clock frequency in Hz, the default +value
Re: [PATCH v3] media: coda: Add driver for Coda video codec.
Hi Javier, Am Mittwoch, den 18.07.2012, 11:01 +0200 schrieb javier Martin: On 18 July 2012 10:35, Philipp Zabel p.za...@pengutronix.de wrote: Hi Javier, Am Mittwoch, den 18.07.2012, 09:12 +0200 schrieb javier Martin: [...] I see there is a comment about the expected register setting not working for CODA_REG_BIT_STREAM_CTRL in start_streaming(). Could this be related? I don't think so. This means that the following line: coda_write(dev, (3 3), CODA_REG_BIT_STREAM_CTRL); should be: coda_write(dev, (CODADX6_STREAM_BUF_PIC_RESET | CODADX6_STREAM_BUF_PIC_FLUSH), CODA_REG_BIT_STREAM_CTRL); But the latter does not work. Looks to me like (3 3) == (CODA7_STREAM_BUF_PIC_RESET | CODA7_STREAM_BUF_PIC_FLUSH) could be the explanation. You mean !=, don't you? I mean ==. coda.h contains: #define CODA7_STREAM_BUF_PIC_RESET (1 4) #define CODA7_STREAM_BUF_PIC_FLUSH (1 3) So maybe those are the correct bits for i.MX27 with the 2.2.5 firmware. If that is the case, you could do s/CODA7_STREAM_BUF_/CODA_STREAM_BUF_/ and drop the incorrect CODADX6_STREAM_BUF_ defines. regards Philipp -- 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 v3] media: coda: Add driver for Coda video codec.
On 18 July 2012 11:22, Philipp Zabel p.za...@pengutronix.de wrote: Hi Javier, Am Mittwoch, den 18.07.2012, 11:01 +0200 schrieb javier Martin: On 18 July 2012 10:35, Philipp Zabel p.za...@pengutronix.de wrote: Hi Javier, Am Mittwoch, den 18.07.2012, 09:12 +0200 schrieb javier Martin: [...] I see there is a comment about the expected register setting not working for CODA_REG_BIT_STREAM_CTRL in start_streaming(). Could this be related? I don't think so. This means that the following line: coda_write(dev, (3 3), CODA_REG_BIT_STREAM_CTRL); should be: coda_write(dev, (CODADX6_STREAM_BUF_PIC_RESET | CODADX6_STREAM_BUF_PIC_FLUSH), CODA_REG_BIT_STREAM_CTRL); But the latter does not work. Looks to me like (3 3) == (CODA7_STREAM_BUF_PIC_RESET | CODA7_STREAM_BUF_PIC_FLUSH) could be the explanation. You mean !=, don't you? I mean ==. coda.h contains: #define CODA7_STREAM_BUF_PIC_RESET (1 4) #define CODA7_STREAM_BUF_PIC_FLUSH (1 3) So maybe those are the correct bits for i.MX27 with the 2.2.5 firmware. If that is the case, you could do s/CODA7_STREAM_BUF_/CODA_STREAM_BUF_/ and drop the incorrect CODADX6_STREAM_BUF_ defines. Sorry, I didn't catch the 'CODA7' prefix in your defines. OK then, I'll do s/CODA7_STREAM_BUF_/CODA_STREAM_BUF_/ and remove the comment too. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
Problems with Asus My Cinema-U3000Hybrid tuner
Hello. I have an Asus My Cinema-U3000Hybrid tuner connected in Bus 002 Device 003: ID 0b05:1736 ASUSTek Computer, Inc. The modules associated with this device in the current linux kernel are: Module Used by rc_dib0700_rc5 12508 0 tuner_xc2028 31235 1 dvb_usb_dib0700 149125 0 dib0090 39179 1 dvb_usb_dib0700 dib7000p 43270 2 dvb_usb_dib0700 dib7000m 23489 1 dvb_usb_dib0700 dib0070 18511 1 dvb_usb_dib0700 dvb_usb 24540 1 dvb_usb_dib0700 dib8000 53374 1 dvb_usb_dib0700 dvb_core 111077 3 dib7000p,dvb_usb,dib8000 dib3000mc 23378 1 dvb_usb_dib0700 rc_core 26422 4 rc_dib0700_rc5,dvb_usb_dib0700,dvb_usb dibx000_common 18810 5 dvb_usb_dib0700,dib7000p,dib7000m,dib8000,dib3000mc issuing: $ uname -a I get Linux crisr-Satellite-A300 3.5.0-4-generic #4-Ubuntu SMP Tue Jul 10 04:58:52 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux everytime I try to play dvb-t the image gets distortions and pixelizations as well as the sound and image lag more than acceptable. Attached are readings from dmesg (at connection time first, and then while using the device) The second part of the file asus.log refers to the process of checking the tuning quality parameters at that moment with dvb_apps utility tzap. Its readings (tzap's) go below too: ~$ tzap RTP 1 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/crisr/.tzap/channels.conf' tuning to 75400 Hz video pid 0x0100, audio pid 0x0101 status 1f | signal a92a | snr 00bd | ber 001f | unc 0014 | FE_HAS_LOCK status 1f | signal a83a | snr 00b6 | ber | unc | FE_HAS_LOCK status 1f | signal a872 | snr 00b0 | ber | unc | FE_HAS_LOCK status 1f | signal a876 | snr 00b1 | ber | unc | FE_HAS_LOCK status 1f | signal a8a6 | snr 00b6 | ber | unc | FE_HAS_LOCK status 1f | signal a8bd | snr 00b2 | ber | unc | FE_HAS_LOCK status 1f | signal a8d0 | snr 00b5 | ber | unc | FE_HAS_LOCK status 1f | signal a8e9 | snr 00b3 | ber | unc | FE_HAS_LOCK status 1f | signal a903 | snr 00b7 | ber | unc | FE_HAS_LOCK status 1f | signal a916 | snr 00b5 | ber 0020 | unc | FE_HAS_LOCK status 1f | signal a90f | snr 00b3 | ber | unc | FE_HAS_LOCK status 1f | signal a927 | snr 00b2 | ber | unc | FE_HAS_LOCK status 1f | signal a937 | snr 00b6 | ber | unc | FE_HAS_LOCK status 1f | signal a93f | snr 00b6 | ber | unc | FE_HAS_LOCK status 1f | signal a940 | snr 00af | ber | unc | FE_HAS_LOCK status 1f | signal a95d | snr 00b7 | ber | unc | FE_HAS_LOCK status 1f | signal a971 | snr 00b3 | ber | unc | FE_HAS_LOCK status 1f | signal a977 | snr 00b9 | ber | unc | FE_HAS_LOCK status 1f | signal a984 | snr 00af | ber | unc | FE_HAS_LOCK status 1f | signal a980 | snr 00b7 | ber | unc | FE_HAS_LOCK status 1f | signal a991 | snr 00b2 | ber | unc | FE_HAS_LOCK status 1f | signal a998 | snr 00b0 | ber | unc | FE_HAS_LOCK status 1f | signal a9ad | snr 00b1 | ber | unc | FE_HAS_LOCK status 1f | signal a9c2 | snr 00b2 | ber | unc | FE_HAS_LOCK status 1f | signal a9b8 | snr 00b8 | ber | unc | FE_HAS_LOCK status 1f | signal a9de | snr 00b2 | ber | unc 0022 | FE_HAS_LOCK status 1f | signal a9cb | snr 00b4 | ber | unc | FE_HAS_LOCK status 1f | signal a9d5 | snr 00b5 | ber | unc 0015 | FE_HAS_LOCK status 1f | signal a9b4 | snr 00b3 | ber | unc | FE_HAS_LOCK status 1f | signal a9e2 | snr 00b1 | ber | unc | FE_HAS_LOCK status 1f | signal a9d7 | snr 00b2 | ber | unc | FE_HAS_LOCK status 1f | signal a9cc | snr 00b1 | ber 1450 | unc 004b | FE_HAS_LOCK status 1f | signal a9ec | snr 00b3 | ber | unc | FE_HAS_LOCK status 1f | signal a9e2 | snr 00b4 | ber 1a80 | unc 001d | FE_HAS_LOCK status 1f | signal aa0d | snr 00b3 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal a9fc | snr 00b2 | ber | unc | FE_HAS_LOCK status 1f | signal aa05 | snr 00b4 | ber 1650 | unc | FE_HAS_LOCK status 1f | signal aa13 | snr 00b0 | ber 0ca0 | unc 0020 | FE_HAS_LOCK status 1f | signal aa19 | snr 00b5 | ber 0250 | unc 0033 | FE_HAS_LOCK status 1f | signal aa38 | snr 00b2 | ber | unc | FE_HAS_LOCK ^C ~$ Hope there can be any solution to these problems. Finally I would like to say that with the same set up, in windows there are no such problems. I am trying a long time now to set this system up here in linux and I have strong reasons to do so: Besides becoming more and more fond of linux, I could also get to the point of its ability to use dvblast from vlc and therefore stream dvb-t
Re: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Manjunath, On Tuesday 17 July 2012 12:22:42 Hadli, Manjunath wrote: On Tue, Jul 17, 2012 at 17:25:42, Laurent Pinchart wrote: On Tuesday 17 July 2012 11:41:11 Hadli, Manjunath wrote: On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 171 include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml [snip] @@ -965,6 +1036,56 @@ entryysubscript1/subscript/entry entryysubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-UV8-1X8 That's a weird one. Just out of curiosity, what's the point of transferring chroma information without luma ? DM365 supports this format. Right, but what is it used for ? Sorry about that. The Resizer in Dm365 can take only chroma and resize the buffer. It can also take luma of course. In general it can take UV8, Y8 and also UYVY. So UV8 is used to resize an NV buffer in two passes (first Y8 then UV8) ? [snip] @@ -2415,6 +2536,56 @@ entryusubscript1/subscript/entry entryusubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-YDYC8-1X16 What is this beast ? We at least need a textual description, as I have no idea what the format corresponds to. This was discussed earlier over here http://patchwork.linuxtv.org/patch/8843/ My bad, I should have remembered that. Please add a textual description of the format, it's not clear from the name what D and C are. I see no description for individual MBUS formats but a collective para on everything together. Would you like me to add in the same or otherwise can you point to me where I can add this description? What about the following patch ? Note that I've renamed YDYC to YDYU, as we might later need a YDYV format. (Hans, Sakari, any opinion ?) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..47a485e 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -853,10 +853,15 @@ titlePacked YUV Formats/title paraThose data formats transfer pixel data as (possibly downsampled) Y, U - and V components. The format code is made of the following information. + and V components. Some formats include dummy bits in some of their samples + and are collectively referred to as YDYC (Y-Dummy-Y-Chroma) formats. + /para + + paraThe format code is made of the following information. itemizedlist listitemparaThe Y, U and V components order code, as transferred on the - bus. Possible values are YUYV, UYVY, YVYU and VYUY./para/listitem + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no + dummy bit, and YDYU, YDYV, YUYD and YVYD for YDYC formats./para/listitem listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem @@ -877,7 +882,21 @@ U, Y, V, Y order will be named constantV4L2_MBUS_FMT_UYVY8_2X8/constant. /para - paraThe following table lisst existing packet YUV formats./para + paraxref linkend=v4l2-mbus-pixelcode-yuv8/ list existing packet YUV + formats and describes the organization of each pixel data in each sample. + When a format pattern is split across multiple samples each of the samples + in the pattern is described./para + + paraThe role of each bit transferred over the bus is identified by one + of the following codes./para + + itemizedlist +listitemparaysubscriptx/subscript for luma component bit number x/para/listitem +listitemparausubscriptx/subscript for blue
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Palash, On Tuesday 17 July 2012 15:57:18 Palash Bandyopadhyay wrote: Count me in when we have this discussion as this is something we too are working on. Which one, the media controller library, or Android ? On Tuesday, July 17, 2012 3:47 PM Laurent Pinchart wrote: On Tuesday 17 July 2012 14:30:53 Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. Great news! The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Sakari and I will spend time on the long-awaited media controller library in a couple of weeks, I hope to have results to present during the summit. Depending on the audience, I would also be interested in getting feedback from SoC vendors who are not (yet) active in the V4L2 community on our approach and how we could best help them. This could include discussions about Android, as I believe we need to push V4L2 on that platform. Guennadi's recent work on an Android V4L2 camera library is a good first step in that direction. -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Guennadi, On Wednesday 18 July 2012 10:30:28 Guennadi Liakhovetski wrote: On Wed, 18 Jul 2012, Laurent Pinchart wrote: On Tuesday 17 July 2012 21:51:02 Guennadi Liakhovetski wrote: On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd love to attend, especially since, as you have seen, I've started doing some work on V4L DT bindings, As you already know, that's a topic I'm very interested in. DT bindings will likely involve rethinking how the V4L2 core and V4L2 drivers instantiate subdevices, a media summit would have been a good occasion to discuss that. However, we probably need an RFC to start with. You've certainly seen these two RFCs currently being discussed: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/50755 Sorry, I meant RFC patches. The devil (or part of it) will be in the details, solving race conditions and other similarly fun issues will require experimentation. http://thread.gmane.org/gmane.linux.kernel.samsung-soc/11143 I still need to review that one :-) -- 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 v3] media: coda: Add driver for Coda video codec.
On 18 July 2012 14:12, Philipp Zabel p.za...@pengutronix.de wrote: Am Mittwoch, den 18.07.2012, 11:26 +0200 schrieb javier Martin: On 18 July 2012 11:22, Philipp Zabel p.za...@pengutronix.de wrote: Hi Javier, Am Mittwoch, den 18.07.2012, 11:01 +0200 schrieb javier Martin: On 18 July 2012 10:35, Philipp Zabel p.za...@pengutronix.de wrote: Hi Javier, Am Mittwoch, den 18.07.2012, 09:12 +0200 schrieb javier Martin: [...] I see there is a comment about the expected register setting not working for CODA_REG_BIT_STREAM_CTRL in start_streaming(). Could this be related? I don't think so. This means that the following line: coda_write(dev, (3 3), CODA_REG_BIT_STREAM_CTRL); should be: coda_write(dev, (CODADX6_STREAM_BUF_PIC_RESET | CODADX6_STREAM_BUF_PIC_FLUSH), CODA_REG_BIT_STREAM_CTRL); But the latter does not work. Looks to me like (3 3) == (CODA7_STREAM_BUF_PIC_RESET | CODA7_STREAM_BUF_PIC_FLUSH) could be the explanation. You mean !=, don't you? I mean ==. coda.h contains: #define CODA7_STREAM_BUF_PIC_RESET (1 4) #define CODA7_STREAM_BUF_PIC_FLUSH (1 3) So maybe those are the correct bits for i.MX27 with the 2.2.5 firmware. If that is the case, you could do s/CODA7_STREAM_BUF_/CODA_STREAM_BUF_/ and drop the incorrect CODADX6_STREAM_BUF_ defines. Sorry, I didn't catch the 'CODA7' prefix in your defines. OK then, I'll do s/CODA7_STREAM_BUF_/CODA_STREAM_BUF_/ and remove the comment too. Hold on, I just read that there should be a ENC_DYN_BUFALLOC_EN bit ((1 5) on i.MX53, (1 4) on i.MX27) - so maybe the #defines are right after all, just that bit needs to be set for the dynamic buffer handling to work. Thanks Philipp, I'll take a look at it. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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 v4] media: coda: Add driver for Coda video codec.
Hi Hans,
thank you for your review.
On 18 July 2012 13:00, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Javier!
On Wed 18 July 2012 12:21:35 Javier Martin wrote:
Coda is a range of video codecs from ChipsMedia that
support H.264, H.263, MPEG4 and other video standards.
Currently only support for the codadx6 included in the
i.MX27 SoC is added. H.264 and MPEG4 video encoding
are the only supported capabilities by now.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
Reviewed-by: Philipp Zabel p.za...@pengutronix.de
I have a few comments, see below.
---
Changes since v3:
- s/CODA7_STREAM_BUF_/CODA_STREAM_BUF/
- Fix bytesused in vidioc_try_fmt()
- Fix MODULE_DEVICE_TABLE for device tree
- Fix 'coda_remove' for rmmod/insmod
---
drivers/media/video/Kconfig |9 +
drivers/media/video/Makefile |1 +
drivers/media/video/coda.c | 1852
++
drivers/media/video/coda.h | 212 +
4 files changed, 2074 insertions(+)
create mode 100644 drivers/media/video/coda.c
create mode 100644 drivers/media/video/coda.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 99937c9..9cebf7b 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1179,6 +1179,15 @@ config VIDEO_MEM2MEM_TESTDEV
This is a virtual test device for the memory-to-memory driver
framework.
+config VIDEO_CODA
+ tristate ChipsMedia Coda multi-standard codec IP
+ depends on VIDEO_DEV VIDEO_V4L2
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ ---help---
+Coda is a range of video codec IPs that supports
+H.264, MPEG-4, and other video formats.
+
config VIDEO_SAMSUNG_S5P_G2D
tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver
depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d209de0..a04c307 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -187,6 +187,7 @@ obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o
obj-$(CONFIG_VIDEO_ATMEL_ISI)+= atmel-isi.o
obj-$(CONFIG_VIDEO_MX2_EMMAPRP) += mx2_emmaprp.o
+obj-$(CONFIG_VIDEO_CODA) += coda.o
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
diff --git a/drivers/media/video/coda.c b/drivers/media/video/coda.c
new file mode 100644
index 000..9df712f
--- /dev/null
+++ b/drivers/media/video/coda.c
@@ -0,0 +1,1852 @@
+/*
+ * Coda multi-standard codec IP
[snip]
+ * V4L2 ioctl() operations.
+ */
+static int vidioc_querycap(struct file *file, void *priv,
+struct v4l2_capability *cap)
+{
+ strncpy(cap-driver, CODA_NAME, sizeof(cap-driver) - 1);
+ strncpy(cap-card, CODA_NAME, sizeof(cap-card) - 1);
+ cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT
+ | V4L2_CAP_STREAMING;
Please also set cap-device_caps. The code should be:
cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT
| V4L2_CAP_STREAMING;
cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
OK, I will change that.
+
+ return 0;
+}
+
+static int enum_fmt(void *priv, struct v4l2_fmtdesc *f,
+ enum coda_fmt_type type)
+{
+ struct coda_ctx *ctx = fh_to_ctx(priv);
+ struct coda_dev *dev = ctx-dev;
+ struct coda_fmt *formats = dev-devtype-formats;
+ struct coda_fmt *fmt;
+ int num_formats = dev-devtype-num_formats;
+ int i, num = 0;
+
+ for (i = 0; i num_formats; i++) {
+ if (formats[i].type == type) {
+ if (num == f-index)
+ break;
+ ++num;
+ }
+ }
+
+ if (i num_formats) {
+ fmt = formats[i];
+ strlcpy(f-description, fmt-name, sizeof(f-description) - 1);
+ f-pixelformat = fmt-fourcc;
+ return 0;
+ }
+
+ /* Format not found */
+ return -EINVAL;
+}
+
+static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
+struct v4l2_fmtdesc *f)
+{
+ return enum_fmt(priv, f, CODA_FMT_ENC);
+}
+
+static int vidioc_enum_fmt_vid_out(struct file *file, void *priv,
+struct v4l2_fmtdesc *f)
+{
+ return enum_fmt(priv, f, CODA_FMT_RAW);
+}
+
+static int vidioc_g_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+{
+ struct vb2_queue *vq;
+ struct coda_q_data *q_data;
+
+ vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
+ if (!vq)
+ return -EINVAL;
+
+ q_data = get_q_data(ctx, f-type);
+
+ f-fmt.pix.field= V4L2_FIELD_NONE;
+ f-fmt.pix.pixelformat = q_data-fmt-fourcc;
+ if
CX25821 driver in kernel 3.4.4 problem
Hello, I have upgraded my testing system with cx25821 based video capture card to system (OpenSuSE 12.1) with kernel 3.4.4 and driver for cx25821 doesn't work. Previous system was with kernel 2.6.37 (OpenSuSE 11.4) with this patch http://patchwork.linuxtv.org/patch/10056/ and manualy compiled module. With kernel 2.6.37 driver works properly. Now I can see, that driver is loaded, but no device in /dev/ are created. Please take a look for attached outputs: lspci -v 02:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f7c0 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [80] Power Management version 3 Capabilities: [90] Vital Product Data Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Advanced Error Reporting Capabilities: [200] Virtual Channel Kernel driver in use: cx25821 lsmod | grep cx cx25821 102052 1 videodev 95422 1 cx25821 videobuf_dma_sg18786 1 cx25821 videobuf_core 29505 2 cx25821,videobuf_dma_sg btcx_risc 13400 1 cx25821 tveeprom 17009 1 cx25821 ls /dev/vi* ls: cannot access /dev/vi*: No such file or directory dmesg [ 10.033013] Linux video capture interface: v2.00 [ 10.033637] cx25821: driver version 0.0.106 loaded [ 10.033667] cx25821: Athena pci enable ! [ 10.033668] cx25821: [ 10.033669] *** [ 10.033670] cx25821: cx25821 set up [ 10.033671] cx25821: *** [ 10.033672] [ 10.033678] BUG: unable to handle kernel paging request at f7bc1d94 [ 10.034398] IP: [c048a9a1] strcpy+0x11/0x30 [ 10.034894] *pdpt = 00b5e001 *pde = 33c3f067 *pte = 80011c129161 [ 10.035799] Oops: 0003 [#1] PREEMPT SMP [ 10.036282] Modules linked in: cx25821(+) videodev eeepc_wmi asus_wmi sparse_keymap rfkill hid_picolcd lcd fb_sys_fops sysimgblt sysfillrect videobuf_dma_sg videobuf_core btcx_risc acpi_cpufreq mperf coretemp syscopyarea tveeprom iTCO_wdt iTCO_vendor_support r8169 pci_hotplug serio_raw pcspkr edd mei(C) wmi sg i2c_i801 crc32c_intel microcode autofs4 i915 drm_kms_helper drm i2c_algo_bit button video fan processor thermal thermal_sys [ 10.041267] [ 10.041430] Pid: 403, comm: modprobe Tainted: G C 3.4.4-32-desktop #1 System manufacturer System Product Name/P8H61-M LX [ 10.042754] EIP: 0060:[c048a9a1] EFLAGS: 00010282 CPU: 0 [ 10.043347] EIP is at strcpy+0x11/0x30 [ 10.043752] EAX: f7bc1d75 EBX: f2dd2000 ECX: f7bc1d94 EDX: f7bc1bf0 [ 10.044428] ESI: f7bc1bf1 EDI: f7bc1d94 EBP: f2dd200c ESP: f2d79da4 [ 10.045103] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 10.045686] CR0: 8005003b CR2: f7bc1d94 CR3: 337e8000 CR4: 000407f0 [ 10.046364] DR0: DR1: DR2: DR3: [ 10.047041] DR6: 0ff0 DR7: 0400 [ 10.047456] Process modprobe (pid: 403, ti=f2d78000 task=f2d6e470 task.ti=f2d78000) [ 10.048279] Stack: [ 10.048498] f2dd34bc f3db7000 f7bc02ec f2dd34bc f7bc1be4 0001 0300 [ 10.049490] f2dd2000 f3db7000 f2dd2000 f3db7000 f2dd200c f7bc076f f7bc28b8 [ 10.050481] f2e83e48 f2e83e48 f2d79e3c f3dc2848 c03947cc c03945f2 0246 0246 [ 10.051473] Call Trace: [ 10.051748] [f7bc02ec] cx25821_dev_setup+0xaa/0x438 [cx25821] [ 10.052405] [f7bc076f] cx25821_initdev+0x7f/0x204 [cx25821] [ 10.053039] [c04a5c22] local_pci_probe+0x42/0xb0 [ 10.053569] [c04a70c9] __pci_device_probe+0xd9/0xe0 [ 10.054127] [c04a70f3] pci_device_probe+0x23/0x40 [ 10.054667] [c0541d96] really_probe+0x56/0x2e0 [ 10.055177] [c0542184] driver_probe_device+0x44/0xa0 [ 10.055743] [c0542259] __driver_attach+0x79/0x80 [ 10.056271] [c054063a] bus_for_each_dev+0x3a/0x60 [ 10.056809] [c0541a39] driver_attach+0x19/0x20 [ 10.057320] [c0541627] bus_add_driver+0x187/0x280 [ 10.057859] [c05426df] driver_register+0x5f/0x100 [ 10.058396] [c04a6e4c] __pci_register_driver+0x3c/0xa0 [ 10.058981] [c0201112] do_one_initcall+0x32/0x170 [ 10.059520] [c028f597] sys_init_module+0xa7/0x210 [ 10.060059] [c070ee2d] syscall_call+0x7/0xb [ 10.060541] [b770662e] 0xb770662d [ 10.060926] Code: 75 07 51 e8 12 b8 ff ff 59 c3 51 52 e8 b9 b7 ff ff 5a 59 c3 90 90 90 90 90 90 83 ec 08 89 c1 89 34 24 89 d6 89 7c 24 04 89 c7 ac aa 84 c0 75 fa 89 c8 8b 34 24 8b 7c 24 04 83 c4 08 c3 8d b6 00 [ 10.064231] EIP: [c048a9a1] strcpy+0x11/0x30 SS:ESP 0068:f2d79da4 [ 10.064947] CR2: f7bc1d94 [ 10.065308] ---[ end trace 31c669691362927a ]--- [ 10.066063] udevd[341]: '/sbin/modprobe -bv pci:v14F1d8210svsdbc04sc00i00' [403] terminated by signal 9 (Killed) Regards Radek Masin ra...@masin.eu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body
Re: [PATCH v4] media: coda: Add driver for Coda video codec.
On Wed 18 July 2012 14:42:00 javier Martin wrote: Hi Hans, thank you for your review. On 18 July 2012 13:00, Hans Verkuil hverk...@xs4all.nl wrote: snip Colorspace. But I don't know how to handle colorspace in this driver. Video encoder from samsung (http://lxr.linux.no/#linux+v3.4.5/drivers/media/video/s5p-mfc/s5p_mfc_enc.c#L844 ) does not handle it either. That's wrong too :-) This is a video encoder which gets an input video streaming (with its specific colorspace) and encodes it. I understand the sense of this field for a video source but for an encoder? An encoder should copy the colorspace of the video it receives to the output video format and default to V4L2_COLORSPACE_SMPTE170M (SDTV) or V4L2_COLORSPACE_REC709 (HDTV). So as long as userspace hasn't told the driver what the colorspace is of the video it will encode you can return a default colorspace. Once you know the actual colorspace, then that's what should be returned. This assumes that the encoder doesn't do any colorspace changes and just encodes as is. 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: CX25821 driver in kernel 3.4.4 problem
Hi Radek, On Wed, Jul 18, 2012 at 9:52 AM, Radek Mašín ra...@masin.eu wrote: Hello, I have upgraded my testing system with cx25821 based video capture card to system (OpenSuSE 12.1) with kernel 3.4.4 and driver for cx25821 doesn't work. Previous system was with kernel 2.6.37 (OpenSuSE 11.4) with this patch http://patchwork.linuxtv.org/patch/10056/ and manualy compiled module. With kernel 2.6.37 driver works properly. Now I can see, that driver is loaded, but no device in /dev/ are created. Please take a look for attached outputs: I'm preparing a patch for you against v3.4.4. Unfortunately, I can't test this. Would you mind testing it and letting me know? Thanks, Ezequiel. -- 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: CX25821 driver in kernel 3.4.4 problem
Radek, On Wed, Jul 18, 2012 at 10:14 AM, Ezequiel Garcia elezegar...@gmail.com wrote: Hi Radek, I think the attached patch will solve this issue. Please test and tell me if it did, Ezequiel. 0001-cx25821-Remove-bad-strcpy-to-read-only-char.patch Description: Binary data
[PATCH] Fix VIDIOC_TRY_EXT_CTRLS regression
Hi all,
This patch fixes an omission in the new v4l2_ioctls table: VIDIOC_TRY_EXT_CTRLS
must get the INFO_FL_CTRL flag, just like all the other control related ioctls.
Otherwise the ioctl core won't know it also has to check whether
v4l2_fh-ctrl_handler
is non-zero before it can decide that this ioctl is not implemented.
Caught by v4l2-compliance while I was testing the mem2mem_testdev driver.
Regards,
Hans
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 70e0efb..17dff31 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1900,7 +1900,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_LOG_STATUS, v4l_log_status, v4l_print_newline, 0),
IOCTL_INFO_FNC(VIDIOC_G_EXT_CTRLS, v4l_g_ext_ctrls,
v4l_print_ext_controls, INFO_FL_CTRL),
IOCTL_INFO_FNC(VIDIOC_S_EXT_CTRLS, v4l_s_ext_ctrls,
v4l_print_ext_controls, INFO_FL_PRIO | INFO_FL_CTRL),
- IOCTL_INFO_FNC(VIDIOC_TRY_EXT_CTRLS, v4l_try_ext_ctrls,
v4l_print_ext_controls, 0),
+ IOCTL_INFO_FNC(VIDIOC_TRY_EXT_CTRLS, v4l_try_ext_ctrls,
v4l_print_ext_controls, INFO_FL_CTRL),
IOCTL_INFO_STD(VIDIOC_ENUM_FRAMESIZES, vidioc_enum_framesizes,
v4l_print_frmsizeenum, INFO_FL_CLEAR(v4l2_frmsizeenum, pixel_format)),
IOCTL_INFO_STD(VIDIOC_ENUM_FRAMEINTERVALS, vidioc_enum_frameintervals,
v4l_print_frmivalenum, INFO_FL_CLEAR(v4l2_frmivalenum, height)),
IOCTL_INFO_STD(VIDIOC_G_ENC_INDEX, vidioc_g_enc_index,
v4l_print_enc_idx, 0),
--
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: CX25821 driver in kernel 3.4.4 problem
Hello, I can test it without problems. Please send me a patch. Regards Radek Masin ra...@masin.eu Dne St, 07/18/2012 03:14 odp., Ezequiel Garcia elezegar...@gmail.com napsal(a): Hi Radek, On Wed, Jul 18, 2012 at 9:52 AM, Radek Mašín ra...@masin.eu wrote: Hello, I have upgraded my testing system with cx25821 based video capture card to system (OpenSuSE 12.1) with kernel 3.4.4 and driver for cx25821 doesn't work. Previous system was with kernel 2.6.37 (OpenSuSE 11.4) with this patch http://patchwork.linuxtv.org/patch/10056/ and manualy compiled module. With kernel 2.6.37 driver works properly. Now I can see, that driver is loaded, but no device in /dev/ are created. Please take a look for attached outputs: I'm preparing a patch for you against v3.4.4. Unfortunately, I can't test this. Would you mind testing it and letting me know? Thanks, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CX25821 driver in kernel 3.4.4 problem
On Wed, Jul 18, 2012 at 10:45 AM, Radek Mašín ra...@masin.eu wrote: Hello, I can test it without problems. Please send me a patch. I already did :-) Please checkout my previous mail. Thanks, Ezequiel. -- 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 v3 1/9] soc-camera: Don't fail at module init time if no device is present
The soc-camera module exports functions that are needed by soc-camera
client drivers even when not running in soc-camera mode. Replace the
platform_driver_probe() with a platform_driver_register() call to avoid
module load failures if no soc-camera device is present.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 0421bf9..e7c6809 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1518,6 +1518,7 @@ static int __devexit soc_camera_pdrv_remove(struct
platform_device *pdev)
}
static struct platform_driver __refdata soc_camera_pdrv = {
+ .probe = soc_camera_pdrv_probe,
.remove = __devexit_p(soc_camera_pdrv_remove),
.driver = {
.name = soc-camera-pdrv,
@@ -1527,7 +1528,7 @@ static struct platform_driver __refdata soc_camera_pdrv =
{
static int __init soc_camera_init(void)
{
- return platform_driver_probe(soc_camera_pdrv, soc_camera_pdrv_probe);
+ return platform_driver_register(soc_camera_pdrv);
}
static void __exit soc_camera_exit(void)
--
1.7.8.6
--
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 v3 0/9] Miscellaneous soc-camera patches
Here's the third version of the miscellaneous soc-camera patches that try to improve the interoperability between soc-camera clients and non soc-camera hosts. As with the previous version, all patches have been compile-tested but not runtime-tested as I lack the necessary hardware. Changes compared to v2: - Properly log error conditions in soc_camera_power_off() and don't return success if an error occurs. - Refactor ov9740_s_power() to make the code flow more explicit. - Power off the MT9T031 in all error paths at probe time. Laurent Pinchart (9): soc-camera: Don't fail at module init time if no device is present soc-camera: Pass the physical device to the power operation ov2640: Don't access the device in the g_mbus_fmt operation ov772x: Don't access the device in the g_mbus_fmt operation tw9910: Don't access the device in the g_mbus_fmt operation soc_camera: Don't call .s_power() during probe soc-camera: Continue the power off sequence if one of the steps fails soc-camera: Add and use soc_camera_power_[on|off]() helper functions soc-camera: Push probe-time power management to drivers drivers/media/video/imx074.c | 30 ++- drivers/media/video/mt9m001.c | 26 ++- drivers/media/video/mt9m111.c | 116 ++-- drivers/media/video/mt9t031.c | 48 ++-- drivers/media/video/mt9t112.c | 21 +- drivers/media/video/mt9v022.c | 14 drivers/media/video/ov2640.c | 26 +-- drivers/media/video/ov5642.c | 31 ++-- drivers/media/video/ov6650.c | 28 ++-- drivers/media/video/ov772x.c | 31 ++-- drivers/media/video/ov9640.c | 27 ++- drivers/media/video/ov9740.c | 47 drivers/media/video/rj54n1cb0c.c | 27 ++- drivers/media/video/soc_camera.c | 111 +-- drivers/media/video/soc_camera_platform.c | 11 +++- drivers/media/video/tw9910.c | 29 ++-- include/media/soc_camera.h| 10 +++ 17 files changed, 437 insertions(+), 196 deletions(-) -- 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 v3 3/9] ov2640: Don't access the device in the g_mbus_fmt operation
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov2640.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ov2640.c b/drivers/media/video/ov2640.c
index 3c2c5d3..7c44d1f 100644
--- a/drivers/media/video/ov2640.c
+++ b/drivers/media/video/ov2640.c
@@ -837,10 +837,8 @@ static int ov2640_g_fmt(struct v4l2_subdev *sd,
if (!priv-win) {
u32 width = W_SVGA, height = H_SVGA;
- int ret = ov2640_set_params(client, width, height,
- V4L2_MBUS_FMT_UYVY8_2X8);
- if (ret 0)
- return ret;
+ priv-win = ov2640_select_win(width, height);
+ priv-cfmt_code = V4L2_MBUS_FMT_UYVY8_2X8;
}
mf-width = priv-win-width;
--
1.7.8.6
--
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 v3 4/9] ov772x: Don't access the device in the g_mbus_fmt operation
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 74e77d3..6d79b89 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -880,15 +880,11 @@ static int ov772x_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
static int ov772x_g_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
- struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
if (!priv-win || !priv-cfmt) {
- u32 width = VGA_WIDTH, height = VGA_HEIGHT;
- int ret = ov772x_set_params(client, width, height,
- V4L2_MBUS_FMT_YUYV8_2X8);
- if (ret 0)
- return ret;
+ priv-cfmt = ov772x_cfmts[0];
+ priv-win = ov772x_select_win(VGA_WIDTH, VGA_HEIGHT);
}
mf-width = priv-win-width;
--
1.7.8.6
--
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 v3 5/9] tw9910: Don't access the device in the g_mbus_fmt operation
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/tw9910.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 8768efb..9f53eac 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -699,11 +699,9 @@ static int tw9910_g_fmt(struct v4l2_subdev *sd,
struct tw9910_priv *priv = to_tw9910(client);
if (!priv-scale) {
- int ret;
- u32 width = 640, height = 480;
- ret = tw9910_set_frame(sd, width, height);
- if (ret 0)
- return ret;
+ priv-scale = tw9910_select_norm(priv-norm, 640, 480);
+ if (!priv-scale)
+ return -EINVAL;
}
mf-width = priv-scale-width;
--
1.7.8.6
--
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 v3 6/9] soc_camera: Don't call .s_power() during probe
The .s_power() call only covers the .g_mbus_fmt() operation call.
Several clients required to be powered on to retrieve the current mbus
format but have now been fixed. The .s_power() call is thus not needed
anymore and can be removed.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index b03ffec..55b981f 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1133,10 +1133,6 @@ static int soc_camera_probe(struct soc_camera_device
*icd)
if (ret 0)
goto evidstart;
- ret = v4l2_subdev_call(sd, core, s_power, 1);
- if (ret 0 ret != -ENOIOCTLCMD)
- goto esdpwr;
-
/* Try to improve our guess of a reasonable window format */
if (!v4l2_subdev_call(sd, video, g_mbus_fmt, mf)) {
icd-user_width = mf.width;
@@ -1153,8 +1149,6 @@ static int soc_camera_probe(struct soc_camera_device *icd)
return 0;
-esdpwr:
- video_unregister_device(icd-vdev);
evidstart:
mutex_unlock(icd-video_lock);
soc_camera_free_user_formats(icd);
--
1.7.8.6
--
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 v3 7/9] soc-camera: Continue the power off sequence if one of the steps fails
Powering off a device is a best effort task: failure to execute one of
the steps should not prevent the next steps to be executed. For
instance, an I2C communication error when putting the chip in stand-by
mode should not prevent the more agressive next step of turning the
chip's power supply off.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 55b981f..7bf21da 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -89,24 +89,30 @@ static int soc_camera_power_off(struct soc_camera_device
*icd,
struct soc_camera_link *icl)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- int ret = v4l2_subdev_call(sd, core, s_power, 0);
+ int ret = 0;
+ int err;
- if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV)
- return ret;
+ err = v4l2_subdev_call(sd, core, s_power, 0);
+ if (err 0 err != -ENOIOCTLCMD err != -ENODEV) {
+ dev_err(icd-pdev, Subdev failed to power-off the camera.\n);
+ ret = err;
+ }
if (icl-power) {
- ret = icl-power(icd-control, 0);
- if (ret 0) {
+ err = icl-power(icd-control, 0);
+ if (err 0) {
dev_err(icd-pdev,
Platform failed to power-off the camera.\n);
- return ret;
+ ret = ret ? : err;
}
}
- ret = regulator_bulk_disable(icl-num_regulators,
+ err = regulator_bulk_disable(icl-num_regulators,
icl-regulators);
- if (ret 0)
+ if (err 0) {
dev_err(icd-pdev, Cannot disable regulators\n);
+ ret = ret ? : err;
+ }
return ret;
}
--
1.7.8.6
--
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 v3 9/9] soc-camera: Push probe-time power management to drivers
Several client drivers access the hardware at probe time, for instance
to read the probe chip ID. Such chips need to be powered up when being
probed.
soc-camera handles this by powering chips up in the soc-camera probe
implementation. However, this will break with non soc-camera hosts that
don't perform the same operations.
Fix the problem by pushing the power up/down from the soc-camera core
down to individual drivers on a needs basis.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c | 21 --
drivers/media/video/mt9m001.c| 17 +++-
drivers/media/video/mt9m111.c| 80 +
drivers/media/video/mt9t031.c| 37 +++--
drivers/media/video/mt9t112.c| 12 +-
drivers/media/video/mt9v022.c|5 ++
drivers/media/video/ov2640.c | 11 -
drivers/media/video/ov5642.c | 21 --
drivers/media/video/ov6650.c | 19 ++---
drivers/media/video/ov772x.c | 14 ++-
drivers/media/video/ov9640.c | 17 ++--
drivers/media/video/ov9740.c | 23 +++
drivers/media/video/rj54n1cb0c.c | 18 ++--
drivers/media/video/soc_camera.c | 20 -
drivers/media/video/tw9910.c | 12 +-
15 files changed, 204 insertions(+), 123 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index ade1987..f8534ee 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -310,26 +310,33 @@ static struct v4l2_subdev_ops imx074_subdev_ops = {
static int imx074_video_probe(struct i2c_client *client)
{
+ struct v4l2_subdev *subdev = i2c_get_clientdata(client);
int ret;
u16 id;
+ ret = imx074_s_power(subdev, 1);
+ if (ret 0)
+ return ret;
+
/* Read sensor Model ID */
ret = reg_read(client, 0);
if (ret 0)
- return ret;
+ goto done;
id = ret 8;
ret = reg_read(client, 1);
if (ret 0)
- return ret;
+ goto done;
id |= ret;
dev_info(client-dev, Chip ID 0x%04x detected\n, id);
- if (id != 0x74)
- return -ENODEV;
+ if (id != 0x74) {
+ ret = -ENODEV;
+ goto done;
+ }
/* PLL Setting EXTCLK=24MHz, 22.5times */
reg_write(client, PLL_MULTIPLIER, 0x2D);
@@ -411,7 +418,11 @@ static int imx074_video_probe(struct i2c_client *client)
reg_write(client, GROUPED_PARAMETER_HOLD, 0x00);/* off */
- return 0;
+ ret = 0;
+
+done:
+ imx074_s_power(subdev, 0);
+ return ret;
}
static int imx074_probe(struct i2c_client *client,
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index cd71230..d85be41 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -490,6 +490,10 @@ static int mt9m001_video_probe(struct soc_camera_link *icl,
unsigned long flags;
int ret;
+ ret = mt9m001_s_power(mt9m001-subdev, 1);
+ if (ret 0)
+ return ret;
+
/* Enable the chip */
data = reg_write(client, MT9M001_CHIP_ENABLE, 1);
dev_dbg(client-dev, write: %d\n, data);
@@ -511,7 +515,8 @@ static int mt9m001_video_probe(struct soc_camera_link *icl,
default:
dev_err(client-dev,
No MT9M001 chip detected, register read %x\n, data);
- return -ENODEV;
+ ret = -ENODEV;
+ goto done;
}
mt9m001-num_fmts = 0;
@@ -540,11 +545,17 @@ static int mt9m001_video_probe(struct soc_camera_link
*icl,
data == 0x8431 ? C12STM : C12ST);
ret = mt9m001_init(client);
- if (ret 0)
+ if (ret 0) {
dev_err(client-dev, Failed to initialise the camera\n);
+ goto done;
+ }
/* mt9m001_init() has reset the chip, returning registers to defaults */
- return v4l2_ctrl_handler_setup(mt9m001-hdl);
+ ret = v4l2_ctrl_handler_setup(mt9m001-hdl);
+
+done:
+ mt9m001_s_power(mt9m001-subdev, 0);
+ return ret;
}
static void mt9m001_video_remove(struct soc_camera_link *icl)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index e555f77..938c5c3 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -796,41 +796,6 @@ static int mt9m111_init(struct mt9m111 *mt9m111)
return ret;
}
-/*
- * Interface active, can use i2c. If it fails, it can indeed mean, that
- * this wasn't our capture interface, so, we wait for the right one
- */
-static int mt9m111_video_probe(struct i2c_client *client)
-{
- struct mt9m111 *mt9m111 = to_mt9m111(client);
- s32 data;
- int ret;
-
- data = reg_read(CHIP_VERSION);
-
- switch (data) {
- case 0x143a: /* MT9M111 or
[PATCH v3 8/9] soc-camera: Add and use soc_camera_power_[on|off]() helper functions
Instead of forcing all soc-camera drivers to go through the mid-layer to
handle power management, create soc_camera_power_[on|off]() functions
that can be called from the subdev .s_power() operation to manage
regulators and platform-specific power handling. This allows non
soc-camera hosts to use soc-camera-aware clients.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c |9 +++
drivers/media/video/mt9m001.c |9 +++
drivers/media/video/mt9m111.c | 52 +-
drivers/media/video/mt9t031.c | 11 +++-
drivers/media/video/mt9t112.c |9 +++
drivers/media/video/mt9v022.c |9 +++
drivers/media/video/ov2640.c |9 +++
drivers/media/video/ov5642.c | 10 +++-
drivers/media/video/ov6650.c |9 +++
drivers/media/video/ov772x.c |9 +++
drivers/media/video/ov9640.c | 10 +++-
drivers/media/video/ov9740.c | 24 ++---
drivers/media/video/rj54n1cb0c.c |9 +++
drivers/media/video/soc_camera.c | 82 +
drivers/media/video/soc_camera_platform.c | 11 -
drivers/media/video/tw9910.c |9 +++
include/media/soc_camera.h| 10
17 files changed, 229 insertions(+), 62 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 351e9ba..ade1987 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -268,6 +268,14 @@ static int imx074_g_chip_ident(struct v4l2_subdev *sd,
return 0;
}
+static int imx074_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ return soc_camera_set_power(client-dev, icl, on);
+}
+
static int imx074_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
@@ -292,6 +300,7 @@ static struct v4l2_subdev_video_ops imx074_subdev_video_ops
= {
static struct v4l2_subdev_core_ops imx074_subdev_core_ops = {
.g_chip_ident = imx074_g_chip_ident,
+ .s_power= imx074_s_power,
};
static struct v4l2_subdev_ops imx074_subdev_ops = {
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 00583f5..cd71230 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -377,6 +377,14 @@ static int mt9m001_s_register(struct v4l2_subdev *sd,
}
#endif
+static int mt9m001_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ return soc_camera_set_power(client-dev, icl, on);
+}
+
static int mt9m001_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
struct mt9m001 *mt9m001 = container_of(ctrl-handler,
@@ -566,6 +574,7 @@ static struct v4l2_subdev_core_ops mt9m001_subdev_core_ops
= {
.g_register = mt9m001_g_register,
.s_register = mt9m001_s_register,
#endif
+ .s_power= mt9m001_s_power,
};
static int mt9m001_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 863d722..e555f77 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -831,10 +831,37 @@ static int mt9m111_video_probe(struct i2c_client *client)
return v4l2_ctrl_handler_setup(mt9m111-hdl);
}
+static int mt9m111_power_on(struct mt9m111 *mt9m111)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+ int ret;
+
+ ret = soc_camera_power_on(client-dev, icl);
+ if (ret 0)
+ return ret;
+
+ ret = mt9m111_resume(mt9m111);
+ if (ret 0) {
+ dev_err(client-dev, Failed to resume the sensor: %d\n, ret);
+ soc_camera_power_off(client-dev, icl);
+ }
+
+ return ret;
+}
+
+static void mt9m111_power_off(struct mt9m111 *mt9m111)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ mt9m111_suspend(mt9m111);
+ soc_camera_power_off(client-dev, icl);
+}
+
static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
{
struct mt9m111 *mt9m111 = container_of(sd, struct mt9m111, subdev);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret = 0;
mutex_lock(mt9m111-power_lock);
@@ -844,23 +871,18 @@ static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
* update the power state.
*/
if (mt9m111-power_count == !on) {
- if (on) {
- ret = mt9m111_resume(mt9m111);
-
[PATCH v3 2/9] soc-camera: Pass the physical device to the power operation
There will be no soc_camera_device instance with a soc-camera device is
used with a non soc-camera host, so we won't be able to pass the
soc_camera_device fake platform device to board code. Pass the physical
device instead.
The argument is currently not used by any board file so this is safe.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index e7c6809..b03ffec 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -62,7 +62,7 @@ static int soc_camera_power_on(struct soc_camera_device *icd,
}
if (icl-power) {
- ret = icl-power(icd-pdev, 1);
+ ret = icl-power(icd-control, 1);
if (ret 0) {
dev_err(icd-pdev,
Platform failed to power-on the camera.\n);
@@ -78,7 +78,7 @@ static int soc_camera_power_on(struct soc_camera_device *icd,
esdpwr:
if (icl-power)
- icl-power(icd-pdev, 0);
+ icl-power(icd-control, 0);
elinkpwr:
regulator_bulk_disable(icl-num_regulators,
icl-regulators);
@@ -95,7 +95,7 @@ static int soc_camera_power_off(struct soc_camera_device *icd,
return ret;
if (icl-power) {
- ret = icl-power(icd-pdev, 0);
+ ret = icl-power(icd-control, 0);
if (ret 0) {
dev_err(icd-pdev,
Platform failed to power-off the camera.\n);
--
1.7.8.6
--
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 v2 0/9] Miscellaneous ov772x cleanups and fixes
Hi,
Here's the second version of the ov772x cleanup and fixes patches. They apply
on top of my previous Miscellaneous soc-camera patches (v3) series.
Changes compared to v1:
- Dropped the Reorganize the code in sections patch.
- Use UINT_MAX instead of reinventing it (2/9)
- Add OV772X_DEFAULT_{WIDTH,HEIGHT} macros (8/9) instead of hardcoding values.
Laurent Pinchart (9):
ov772x: Fix memory leak in probe error path
ov772x: Select the default format at probe time
ov772x: Don't fail in s_fmt if the requested format isn't supported
ov772x: try_fmt must not default to the current format
ov772x: Make to_ov772x convert from v4l2_subdev to ov772x_priv
ov772x: Add ov772x_read() and ov772x_write() functions
ov772x: Add support for SBGGR10 format
ov772x: Compute window size registers at runtime
ov772x: Stop sensor readout right after reset
drivers/media/video/ov772x.c | 426 --
1 files changed, 207 insertions(+), 219 deletions(-)
--
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 v2 1/9] ov772x: Fix memory leak in probe error path
The control handler isn't freed if its initialization fails. Fix it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 641f6f4..0fede50d 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -1098,18 +1098,17 @@ static int ov772x_probe(struct i2c_client *client,
V4L2_CID_BAND_STOP_FILTER, 0, 256, 1, 0);
priv-subdev.ctrl_handler = priv-hdl;
if (priv-hdl.error) {
- int err = priv-hdl.error;
-
- kfree(priv);
- return err;
+ ret = priv-hdl.error;
+ goto done;
}
ret = ov772x_video_probe(client);
+
+done:
if (ret) {
v4l2_ctrl_handler_free(priv-hdl);
kfree(priv);
}
-
return ret;
}
--
1.7.8.6
--
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 v2 7/9] ov772x: Add support for SBGGR10 format
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 43 +++--
1 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 13f4688..3874dbc 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -275,6 +275,7 @@
#define SLCT_VGA0x00 /* 0 : VGA */
#define SLCT_QVGA 0x40 /* 1 : QVGA */
#define ITU656_ON_OFF 0x20 /* ITU656 protocol ON/OFF selection */
+#define SENSOR_RAW 0x10/* Sensor RAW */
/* RGB output format control */
#define FMT_MASK0x0c /* Mask of color format */
#define FMT_GBR422 0x00 /* 00 : GBR 4:2:2 */
@@ -338,6 +339,12 @@
#define CBAR_ON 0x20 /* ON */
#define CBAR_OFF0x00 /* OFF */
+/* DSP_CTRL4 */
+#define DSP_OFMT_YUV 0x00
+#define DSP_OFMT_RGB 0x00
+#define DSP_OFMT_RAW8 0x02
+#define DSP_OFMT_RAW10 0x03
+
/* HSTART */
#define HST_VGA 0x23
#define HST_QVGA0x3F
@@ -389,6 +396,7 @@ struct ov772x_color_format {
enum v4l2_mbus_pixelcode code;
enum v4l2_colorspace colorspace;
u8 dsp3;
+ u8 dsp4;
u8 com3;
u8 com7;
};
@@ -447,6 +455,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
.code = V4L2_MBUS_FMT_YUYV8_2X8,
.colorspace = V4L2_COLORSPACE_JPEG,
.dsp3 = 0x0,
+ .dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_YUV,
.com7 = OFMT_YUV,
},
@@ -454,6 +463,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
.code = V4L2_MBUS_FMT_YVYU8_2X8,
.colorspace = V4L2_COLORSPACE_JPEG,
.dsp3 = UV_ON,
+ .dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_YUV,
.com7 = OFMT_YUV,
},
@@ -461,6 +471,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
.code = V4L2_MBUS_FMT_UYVY8_2X8,
.colorspace = V4L2_COLORSPACE_JPEG,
.dsp3 = 0x0,
+ .dsp4 = DSP_OFMT_YUV,
.com3 = 0x0,
.com7 = OFMT_YUV,
},
@@ -468,6 +479,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
.code = V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
.colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
+ .dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_RGB,
.com7 = FMT_RGB555 | OFMT_RGB,
},
@@ -475,6 +487,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
.code = V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
.colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
+ .dsp4 = DSP_OFMT_YUV,
.com3 = 0x0,
.com7 = FMT_RGB555 | OFMT_RGB,
},
@@ -482,6 +495,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
.code = V4L2_MBUS_FMT_RGB565_2X8_LE,
.colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
+ .dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_RGB,
.com7 = FMT_RGB565 | OFMT_RGB,
},
@@ -489,9 +503,22 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
.code = V4L2_MBUS_FMT_RGB565_2X8_BE,
.colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
+ .dsp4 = DSP_OFMT_YUV,
.com3 = 0x0,
.com7 = FMT_RGB565 | OFMT_RGB,
},
+ {
+ /* Setting DSP4 to DSP_OFMT_RAW8 still gives 10-bit output,
+* regardless of the COM7 value. We can thus only support 10-bit
+* Bayer until someone figures it out.
+*/
+ .code = V4L2_MBUS_FMT_SBGGR10_1X10,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .dsp3 = 0x0,
+ .dsp4 = DSP_OFMT_RAW10,
+ .com3 = 0x0,
+ .com7 = SENSOR_RAW | OFMT_BRAW,
+ },
};
@@ -808,6 +835,13 @@ static int ov772x_set_params(struct ov772x_priv *priv,
goto ov772x_set_fmt_error;
}
+ /* DSP_CTRL4: AEC reference point and DSP output format. */
+ if (cfmt-dsp4) {
+ ret = ov772x_write(client, DSP_CTRL4, cfmt-dsp4);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+ }
+
[PATCH v2 3/9] ov772x: Don't fail in s_fmt if the requested format isn't supported
Select a default format instead.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 83 ++
1 files changed, 43 insertions(+), 40 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 3f6e4bf..c2bd087 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -581,11 +581,6 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
- if (!priv-win || !priv-cfmt) {
- dev_err(client-dev, norm or win select error\n);
- return -EPERM;
- }
-
ov772x_mask_set(client, COM2, SOFT_SLEEP_MODE, 0);
dev_dbg(client-dev, format %d, win %s\n,
@@ -710,31 +705,33 @@ static const struct ov772x_win_size
*ov772x_select_win(u32 width, u32 height)
return win;
}
-static int ov772x_set_params(struct i2c_client *client, u32 *width, u32
*height,
-enum v4l2_mbus_pixelcode code)
+static void ov772x_select_params(const struct v4l2_mbus_framefmt *mf,
+const struct ov772x_color_format **cfmt,
+const struct ov772x_win_size **win)
{
- struct ov772x_priv *priv = to_ov772x(client);
- int ret = -EINVAL;
- u8 val;
- int i;
+ unsigned int i;
+
+ /* Select the format format. */
+ *cfmt = ov772x_cfmts[0];
- /*
-* select format
-*/
- priv-cfmt = NULL;
for (i = 0; i ARRAY_SIZE(ov772x_cfmts); i++) {
- if (code == ov772x_cfmts[i].code) {
- priv-cfmt = ov772x_cfmts + i;
+ if (mf-code == ov772x_cfmts[i].code) {
+ *cfmt = ov772x_cfmts[i];
break;
}
}
- if (!priv-cfmt)
- goto ov772x_set_fmt_error;
- /*
-* select win
-*/
- priv-win = ov772x_select_win(*width, *height);
+ /* Select the window size. */
+ *win = ov772x_select_win(mf-width, mf-height);
+}
+
+static int ov772x_set_params(struct ov772x_priv *priv,
+const struct ov772x_color_format *cfmt,
+const struct ov772x_win_size *win)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(priv-subdev);
+ int ret;
+ u8 val;
/*
* reset hardware
@@ -791,14 +788,14 @@ static int ov772x_set_params(struct i2c_client *client,
u32 *width, u32 *height,
/*
* set size format
*/
- ret = ov772x_write_array(client, priv-win-regs);
+ ret = ov772x_write_array(client, win-regs);
if (ret 0)
goto ov772x_set_fmt_error;
/*
* set DSP_CTRL3
*/
- val = priv-cfmt-dsp3;
+ val = cfmt-dsp3;
if (val) {
ret = ov772x_mask_set(client,
DSP_CTRL3, UV_MASK, val);
@@ -809,7 +806,7 @@ static int ov772x_set_params(struct i2c_client *client, u32
*width, u32 *height,
/*
* set COM3
*/
- val = priv-cfmt-com3;
+ val = cfmt-com3;
if (priv-info-flags OV772X_FLAG_VFLIP)
val |= VFLIP_IMG;
if (priv-info-flags OV772X_FLAG_HFLIP)
@@ -827,7 +824,7 @@ static int ov772x_set_params(struct i2c_client *client, u32
*width, u32 *height,
/*
* set COM7
*/
- val = priv-win-com7_bit | priv-cfmt-com7;
+ val = win-com7_bit | cfmt-com7;
ret = ov772x_mask_set(client,
COM7, SLCT_MASK | FMT_MASK | OFMT_MASK,
val);
@@ -846,16 +843,11 @@ static int ov772x_set_params(struct i2c_client *client,
u32 *width, u32 *height,
goto ov772x_set_fmt_error;
}
- *width = priv-win-width;
- *height = priv-win-height;
-
return ret;
ov772x_set_fmt_error:
ov772x_reset(client);
- priv-win = NULL;
- priv-cfmt = NULL;
return ret;
}
@@ -899,18 +891,29 @@ static int ov772x_g_fmt(struct v4l2_subdev *sd,
return 0;
}
-static int ov772x_s_fmt(struct v4l2_subdev *sd,
- struct v4l2_mbus_framefmt *mf)
+static int ov772x_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf)
{
- struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
- int ret = ov772x_set_params(client, mf-width, mf-height,
- mf-code);
+ const struct ov772x_color_format *cfmt;
+ const struct ov772x_win_size *win;
+ int ret;
- if (!ret)
- mf-colorspace = priv-cfmt-colorspace;
+ ov772x_select_params(mf, cfmt, win);
- return ret;
+ ret = ov772x_set_params(priv, cfmt, win);
+ if (ret
[PATCH v2 6/9] ov772x: Add ov772x_read() and ov772x_write() functions
And use them instead of calling SMBus access functions directly.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 38 ++
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 2b95dd4..13f4688 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -530,13 +530,21 @@ static struct ov772x_priv *to_ov772x(struct v4l2_subdev
*sd)
return container_of(sd, struct ov772x_priv, subdev);
}
+static inline int ov772x_read(struct i2c_client *client, u8 addr)
+{
+ return i2c_smbus_read_byte_data(client, addr);
+}
+
+static inline int ov772x_write(struct i2c_client *client, u8 addr, u8 value)
+{
+ return i2c_smbus_write_byte_data(client, addr, value);
+}
+
static int ov772x_write_array(struct i2c_client*client,
const struct regval_list *vals)
{
while (vals-reg_num != 0xff) {
- int ret = i2c_smbus_write_byte_data(client,
- vals-reg_num,
- vals-value);
+ int ret = ov772x_write(client, vals-reg_num, vals-value);
if (ret 0)
return ret;
vals++;
@@ -544,24 +552,22 @@ static int ov772x_write_array(struct i2c_client
*client,
return 0;
}
-static int ov772x_mask_set(struct i2c_client *client,
- u8 command,
- u8 mask,
- u8 set)
+static int ov772x_mask_set(struct i2c_client *client, u8 command, u8 mask,
+ u8 set)
{
- s32 val = i2c_smbus_read_byte_data(client, command);
+ s32 val = ov772x_read(client, command);
if (val 0)
return val;
val = ~mask;
val |= set mask;
- return i2c_smbus_write_byte_data(client, command, val);
+ return ov772x_write(client, command, val);
}
static int ov772x_reset(struct i2c_client *client)
{
- int ret = i2c_smbus_write_byte_data(client, COM7, SCCB_RESET);
+ int ret = ov772x_write(client, COM7, SCCB_RESET);
msleep(1);
return ret;
}
@@ -656,7 +662,7 @@ static int ov772x_g_register(struct v4l2_subdev *sd,
if (reg-reg 0xff)
return -EINVAL;
- ret = i2c_smbus_read_byte_data(client, reg-reg);
+ ret = ov772x_read(client, reg-reg);
if (ret 0)
return ret;
@@ -674,7 +680,7 @@ static int ov772x_s_register(struct v4l2_subdev *sd,
reg-val 0xff)
return -EINVAL;
- return i2c_smbus_write_byte_data(client, reg-reg, reg-val);
+ return ov772x_write(client, reg-reg, reg-val);
}
#endif
@@ -946,8 +952,8 @@ static int ov772x_video_probe(struct ov772x_priv *priv)
/*
* check and show product ID and manufacturer ID
*/
- pid = i2c_smbus_read_byte_data(client, PID);
- ver = i2c_smbus_read_byte_data(client, VER);
+ pid = ov772x_read(client, PID);
+ ver = ov772x_read(client, VER);
switch (VERSION(pid, ver)) {
case OV7720:
@@ -970,8 +976,8 @@ static int ov772x_video_probe(struct ov772x_priv *priv)
devname,
pid,
ver,
-i2c_smbus_read_byte_data(client, MIDH),
-i2c_smbus_read_byte_data(client, MIDL));
+ov772x_read(client, MIDH),
+ov772x_read(client, MIDL));
ret = v4l2_ctrl_handler_setup(priv-hdl);
done:
--
1.7.8.6
--
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 v2 9/9] ov772x: Stop sensor readout right after reset
The sensor starts streaming video as soon as it gets powered or is
reset. Disable the output in the reset function.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index aa2ba9e..e78e0e1 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -537,9 +537,15 @@ static int ov772x_mask_set(struct i2c_client *client, u8
command, u8 mask,
static int ov772x_reset(struct i2c_client *client)
{
- int ret = ov772x_write(client, COM7, SCCB_RESET);
+ int ret;
+
+ ret = ov772x_write(client, COM7, SCCB_RESET);
+ if (ret 0)
+ return ret;
+
msleep(1);
- return ret;
+
+ return ov772x_mask_set(client, COM2, SOFT_SLEEP_MODE, SOFT_SLEEP_MODE);
}
/*
--
1.7.8.6
--
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 v2 8/9] ov772x: Compute window size registers at runtime
Instead of hardcoding register arrays, compute the values at runtime.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 162 +-
1 files changed, 65 insertions(+), 97 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 3874dbc..aa2ba9e 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -318,8 +318,15 @@
#define SGLF_ON_OFF 0x02 /* Single frame ON/OFF selection */
#define SGLF_TRIG 0x01 /* Single frame transfer trigger */
+/* HREF */
+#define HREF_VSTART_SHIFT 6 /* VSTART LSB */
+#define HREF_HSTART_SHIFT 4 /* HSTART 2 LSBs */
+#define HREF_VSIZE_SHIFT 2 /* VSIZE LSB */
+#define HREF_HSIZE_SHIFT 0 /* HSIZE 2 LSBs */
+
/* EXHCH */
-#define VSIZE_LSB 0x04 /* Vertical data output size LSB */
+#define EXHCH_VSIZE_SHIFT 2 /* VOUTSIZE LSB */
+#define EXHCH_HSIZE_SHIFT 0 /* HOUTSIZE 2 LSBs */
/* DSP_CTRL1 */
#define FIFO_ON 0x80 /* FIFO enable/disable selection */
@@ -345,30 +352,6 @@
#define DSP_OFMT_RAW8 0x02
#define DSP_OFMT_RAW10 0x03
-/* HSTART */
-#define HST_VGA 0x23
-#define HST_QVGA0x3F
-
-/* HSIZE */
-#define HSZ_VGA 0xA0
-#define HSZ_QVGA0x50
-
-/* VSTART */
-#define VST_VGA 0x07
-#define VST_QVGA0x03
-
-/* VSIZE */
-#define VSZ_VGA 0xF0
-#define VSZ_QVGA0x78
-
-/* HOUTSIZE */
-#define HOSZ_VGA0xA0
-#define HOSZ_QVGA 0x50
-
-/* VOUTSIZE */
-#define VOSZ_VGA0xF0
-#define VOSZ_QVGA 0x78
-
/* DSPAUTO (DSP Auto Function ON/OFF Control) */
#define AWB_ACTRL 0x80 /* AWB auto threshold control */
#define DENOISE_ACTRL 0x40 /* De-noise auto threshold control */
@@ -377,6 +360,9 @@
#define SCAL0_ACTRL 0x08 /* Auto scaling factor control */
#define SCAL1_2_ACTRL 0x04 /* Auto scaling factor control */
+#define OV772X_DEFAULT_WIDTH 640
+#define OV772X_DEFAULT_HEIGHT 480
+
/*
* ID
*/
@@ -387,10 +373,6 @@
/*
* struct
*/
-struct regval_list {
- unsigned char reg_num;
- unsigned char value;
-};
struct ov772x_color_format {
enum v4l2_mbus_pixelcode code;
@@ -403,10 +385,8 @@ struct ov772x_color_format {
struct ov772x_win_size {
char *name;
- __u32 width;
- __u32 height;
unsigned char com7_bit;
- const struct regval_list *regs;
+ struct v4l2_rect rect;
};
struct ov772x_priv {
@@ -422,31 +402,6 @@ struct ov772x_priv {
unsigned shortband_filter;
};
-#define ENDMARKER { 0xff, 0xff }
-
-/*
- * register setting for window size
- */
-static const struct regval_list ov772x_qvga_regs[] = {
- { HSTART, HST_QVGA },
- { HSIZE,HSZ_QVGA },
- { VSTART, VST_QVGA },
- { VSIZE,VSZ_QVGA },
- { HOUTSIZE, HOSZ_QVGA },
- { VOUTSIZE, VOSZ_QVGA },
- ENDMARKER,
-};
-
-static const struct regval_list ov772x_vga_regs[] = {
- { HSTART, HST_VGA },
- { HSIZE,HSZ_VGA },
- { VSTART, VST_VGA },
- { VSIZE,VSZ_VGA },
- { HOUTSIZE, HOSZ_VGA },
- { VOUTSIZE, VOSZ_VGA },
- ENDMARKER,
-};
-
/*
* supported color format list
*/
@@ -525,26 +480,26 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
/*
* window size list
*/
-#define VGA_WIDTH 640
-#define VGA_HEIGHT 480
-#define QVGA_WIDTH 320
-#define QVGA_HEIGHT 240
-#define MAX_WIDTH VGA_WIDTH
-#define MAX_HEIGHT VGA_HEIGHT
static const struct ov772x_win_size ov772x_win_sizes[] = {
{
.name = VGA,
- .width= VGA_WIDTH,
- .height = VGA_HEIGHT,
.com7_bit = SLCT_VGA,
- .regs = ov772x_vga_regs,
+ .rect = {
+ .left = 140,
+ .top = 14,
+ .width = 640,
+ .height = 480,
+ },
}, {
.name = QVGA,
- .width= QVGA_WIDTH,
- .height = QVGA_HEIGHT,
.com7_bit = SLCT_QVGA,
- .regs = ov772x_qvga_regs,
+ .rect = {
+ .left = 252,
+ .top = 6,
+ .width = 320,
+ .height = 240,
+ },
},
};
@@ -567,18 +522,6 @@ static inline int ov772x_write(struct i2c_client *client,
u8 addr, u8 value)
return i2c_smbus_write_byte_data(client, addr, value);
}
-static int ov772x_write_array(struct i2c_client*client,
- const struct regval_list *vals)
-{
- while (vals-reg_num != 0xff) {
- int ret = ov772x_write(client, vals-reg_num, vals-value);
-
[PATCH v2 5/9] ov772x: Make to_ov772x convert from v4l2_subdev to ov772x_priv
Conversion from i2c_client to ov772x_priv is only needed in a single
location, while conversion from v4l2_subdev to ov772x_priv is needed in
several locations. Perform the former manually, and use to_ov772x for
the later.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index be3dfb5..2b95dd4 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -525,10 +525,9 @@ static const struct ov772x_win_size ov772x_win_sizes[] = {
* general function
*/
-static struct ov772x_priv *to_ov772x(const struct i2c_client *client)
+static struct ov772x_priv *to_ov772x(struct v4l2_subdev *sd)
{
- return container_of(i2c_get_clientdata(client), struct ov772x_priv,
- subdev);
+ return container_of(sd, struct ov772x_priv, subdev);
}
static int ov772x_write_array(struct i2c_client*client,
@@ -574,7 +573,7 @@ static int ov772x_reset(struct i2c_client *client)
static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
+ struct ov772x_priv *priv = to_ov772x(sd);
if (!enable) {
ov772x_mask_set(client, COM2, SOFT_SLEEP_MODE, SOFT_SLEEP_MODE);
@@ -638,7 +637,7 @@ static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
static int ov772x_g_chip_ident(struct v4l2_subdev *sd,
struct v4l2_dbg_chip_ident *id)
{
- struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
+ struct ov772x_priv *priv = to_ov772x(sd);
id-ident= priv-model;
id-revision = 0;
@@ -880,7 +879,7 @@ static int ov772x_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
static int ov772x_g_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
- struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
+ struct ov772x_priv *priv = to_ov772x(sd);
mf-width = priv-win-width;
mf-height = priv-win-height;
@@ -893,7 +892,7 @@ static int ov772x_g_fmt(struct v4l2_subdev *sd,
static int ov772x_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf)
{
- struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
+ struct ov772x_priv *priv = to_ov772x(sd);
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
int ret;
@@ -933,9 +932,9 @@ static int ov772x_try_fmt(struct v4l2_subdev *sd,
return 0;
}
-static int ov772x_video_probe(struct i2c_client *client)
+static int ov772x_video_probe(struct ov772x_priv *priv)
{
- struct ov772x_priv *priv = to_ov772x(client);
+ struct i2c_client *client = v4l2_get_subdevdata(priv-subdev);
u8 pid, ver;
const char *devname;
int ret;
@@ -1078,7 +1077,7 @@ static int ov772x_probe(struct i2c_client *client,
goto done;
}
- ret = ov772x_video_probe(client);
+ ret = ov772x_video_probe(priv);
if (ret 0)
goto done;
@@ -1095,7 +1094,7 @@ done:
static int ov772x_remove(struct i2c_client *client)
{
- struct ov772x_priv *priv = to_ov772x(client);
+ struct ov772x_priv *priv = to_ov772x(i2c_get_clientdata(client));
v4l2_device_unregister_subdev(priv-subdev);
v4l2_ctrl_handler_free(priv-hdl);
--
1.7.8.6
--
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 v2 4/9] ov772x: try_fmt must not default to the current format
If the requested format isn't supported, return a fixed default format
instead of the current format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 36 +++-
1 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index c2bd087..be3dfb5 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -919,38 +919,16 @@ static int ov772x_s_fmt(struct v4l2_subdev *sd, struct
v4l2_mbus_framefmt *mf)
static int ov772x_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
- struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
+ const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
- int i;
-
- /*
-* select suitable win
-*/
- win = ov772x_select_win(mf-width, mf-height);
- mf-width = win-width;
- mf-height = win-height;
- mf-field = V4L2_FIELD_NONE;
-
- for (i = 0; i ARRAY_SIZE(ov772x_cfmts); i++)
- if (mf-code == ov772x_cfmts[i].code)
- break;
+ ov772x_select_params(mf, cfmt, win);
- if (i == ARRAY_SIZE(ov772x_cfmts)) {
- /* Unsupported format requested. Propose either */
- if (priv-cfmt) {
- /* the current one or */
- mf-colorspace = priv-cfmt-colorspace;
- mf-code = priv-cfmt-code;
- } else {
- /* the default one */
- mf-colorspace = ov772x_cfmts[0].colorspace;
- mf-code = ov772x_cfmts[0].code;
- }
- } else {
- /* Also return the colorspace */
- mf-colorspace = ov772x_cfmts[i].colorspace;
- }
+ mf-code = cfmt-code;
+ mf-width = win-width;
+ mf-height = win-height;
+ mf-field = V4L2_FIELD_NONE;
+ mf-colorspace = cfmt-colorspace;
return 0;
}
--
1.7.8.6
--
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 v2 2/9] ov772x: Select the default format at probe time
The format and window size are only initialized during the first g_fmt
call. This leaves the device in an inconsistent state after
initialization, which will cause problems when implementing pad
operations. Move the format and window size initialization to probe
time.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 64 +-
1 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 0fede50d..3f6e4bf 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -16,6 +16,7 @@
*/
#include linux/init.h
+#include linux/kernel.h
#include linux/module.h
#include linux/i2c.h
#include linux/slab.h
@@ -504,20 +505,20 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
#define MAX_WIDTH VGA_WIDTH
#define MAX_HEIGHT VGA_HEIGHT
-static const struct ov772x_win_size ov772x_win_vga = {
- .name = VGA,
- .width= VGA_WIDTH,
- .height = VGA_HEIGHT,
- .com7_bit = SLCT_VGA,
- .regs = ov772x_vga_regs,
-};
-
-static const struct ov772x_win_size ov772x_win_qvga = {
- .name = QVGA,
- .width= QVGA_WIDTH,
- .height = QVGA_HEIGHT,
- .com7_bit = SLCT_QVGA,
- .regs = ov772x_qvga_regs,
+static const struct ov772x_win_size ov772x_win_sizes[] = {
+ {
+ .name = VGA,
+ .width= VGA_WIDTH,
+ .height = VGA_HEIGHT,
+ .com7_bit = SLCT_VGA,
+ .regs = ov772x_vga_regs,
+ }, {
+ .name = QVGA,
+ .width= QVGA_WIDTH,
+ .height = QVGA_HEIGHT,
+ .com7_bit = SLCT_QVGA,
+ .regs = ov772x_qvga_regs,
+ },
};
/*
@@ -693,19 +694,18 @@ static int ov772x_s_power(struct v4l2_subdev *sd, int on)
static const struct ov772x_win_size *ov772x_select_win(u32 width, u32 height)
{
- __u32 diff;
- const struct ov772x_win_size *win;
-
- /* default is QVGA */
- diff = abs(width - ov772x_win_qvga.width) +
- abs(height - ov772x_win_qvga.height);
- win = ov772x_win_qvga;
-
- /* VGA */
- if (diff
- abs(width - ov772x_win_vga.width) +
- abs(height - ov772x_win_vga.height))
- win = ov772x_win_vga;
+ const struct ov772x_win_size *win = ov772x_win_sizes[0];
+ u32 best_diff = UINT_MAX;
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(ov772x_win_sizes); ++i) {
+ u32 diff = abs(width - ov772x_win_sizes[i].width)
++ abs(height - ov772x_win_sizes[i].height);
+ if (diff best_diff) {
+ best_diff = diff;
+ win = ov772x_win_sizes[i];
+ }
+ }
return win;
}
@@ -890,11 +890,6 @@ static int ov772x_g_fmt(struct v4l2_subdev *sd,
{
struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
- if (!priv-win || !priv-cfmt) {
- priv-cfmt = ov772x_cfmts[0];
- priv-win = ov772x_select_win(VGA_WIDTH, VGA_HEIGHT);
- }
-
mf-width = priv-win-width;
mf-height = priv-win-height;
mf-code= priv-cfmt-code;
@@ -1103,6 +1098,11 @@ static int ov772x_probe(struct i2c_client *client,
}
ret = ov772x_video_probe(client);
+ if (ret 0)
+ goto done;
+
+ priv-cfmt = ov772x_cfmts[0];
+ priv-win = ov772x_win_sizes[0];
done:
if (ret) {
--
1.7.8.6
--
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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tuesday 17 July 2012 21:41:18 Laurent Pinchart wrote: Hi Hans, On Tuesday 17 July 2012 21:32:22 Hans Verkuil wrote: On Tue July 17 2012 19:30:53 Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd like to have 30 minutes to discuss a few V4L2 API ambiguities or just plain weirdness, just like I did last year. I'll make an RFC issues to discuss beforehand. I might also have a short presentation/demo of v4l2-compliance, as I believe more people need to know about that utility. That's a good idea. On the topic of ambiguities, could you add VIDIOC_STREAMON and VIDIOC_STREAMOFF behaviour when the stream is already started/stopped respectively ? Another ambiguity for your list: what should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). -- 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] smiapp-core.c: remove duplicated include
Signed-off-by: Duan Jiong djduanji...@gmail.com --- drivers/media/video/smiapp/smiapp-core.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/video/smiapp/smiapp-core.c b/drivers/media/video/smiapp/smiapp-core.c index 9cf5bda..297acaf 100644 --- a/drivers/media/video/smiapp/smiapp-core.c +++ b/drivers/media/video/smiapp/smiapp-core.c @@ -33,7 +33,6 @@ #include linux/module.h #include linux/slab.h #include linux/regulator/consumer.h -#include linux/slab.h #include linux/v4l2-mediabus.h #include media/v4l2-device.h -- 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
Re: CX25821 driver in kernel 3.4.4 problem
Hello, with your patch driver is working properly. I see devices in /dev directory and in dmesg is attached output: [5.124858] cx25821: driver version 0.0.106 loaded [5.124890] cx25821: Athena pci enable ! [5.124891] cx25821: [5.124892] *** [5.124893] cx25821: cx25821 set up [5.124894] cx25821: *** [5.124895] [5.124897] cx25821: Athena Hardware device = 0x8210 [5.125165] cx25821: cx25821[1]: subsystem: :, board: CX25821 [card=1,autodetected] [5.125201] asus_wmi: ASUS WMI generic driver loaded [5.144539] asus_wmi: Initialization: 0x0 [5.144566] asus_wmi: BIOS WMI version: 0.9 [5.144616] asus_wmi: SFUN value: 0x0 [5.144906] input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input4 [5.151580] asus_wmi: Backlight controlled by ACPI video driver [5.307573] EXT4-fs (sda3): re-mounted. Opts: acl,user_xattr [5.345621] cx25821: (1): i2c register! bus-i2c_rc = 0 [5.424861] cx25821: cx25821_dev_checkrevision(): Hardware revision = 0x00 [5.424864] cx25821: (1): setup done! [5.424872] cx25821: cx25821[1]/0: found at :02:00.0, rev: 0, irq: 16, latency: 0, mmio: 0xf7c0 Regards Radek Masin ra...@masin.eu Dne St, 07/18/2012 03:24 odp., Ezequiel Garcia elezegar...@gmail.com napsal(a): Radek, On Wed, Jul 18, 2012 at 10:14 AM, Ezequiel Garcia elezegar...@gmail.com wrote: Hi Radek, I think the attached patch will solve this issue. Please test and tell me if it did, Ezequiel. -- 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] pms.c: remove duplicated include
Signed-off-by: Duan Jiong djduanji...@gmail.com --- drivers/media/video/pms.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/video/pms.c b/drivers/media/video/pms.c index b4c679b..77f9c92 100644 --- a/drivers/media/video/pms.c +++ b/drivers/media/video/pms.c @@ -30,7 +30,6 @@ #include linux/ioport.h #include linux/init.h #include linux/mutex.h -#include linux/slab.h #include linux/uaccess.h #include linux/isa.h #include asm/io.h -- 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
Re: [PATCH v4] media: coda: Add driver for Coda video codec.
On Wed 18 July 2012 15:10:41 Hans Verkuil wrote: On Wed 18 July 2012 14:42:00 javier Martin wrote: Hi Hans, thank you for your review. On 18 July 2012 13:00, Hans Verkuil hverk...@xs4all.nl wrote: snip Colorspace. But I don't know how to handle colorspace in this driver. Video encoder from samsung (http://lxr.linux.no/#linux+v3.4.5/drivers/media/video/s5p-mfc/s5p_mfc_enc.c#L844 ) does not handle it either. That's wrong too :-) This is a video encoder which gets an input video streaming (with its specific colorspace) and encodes it. I understand the sense of this field for a video source but for an encoder? An encoder should copy the colorspace of the video it receives to the output video format and default to V4L2_COLORSPACE_SMPTE170M (SDTV) or V4L2_COLORSPACE_REC709 (HDTV). So as long as userspace hasn't told the driver what the colorspace is of the video it will encode you can return a default colorspace. Once you know the actual colorspace, then that's what should be returned. This assumes that the encoder doesn't do any colorspace changes and just encodes as is. Look at my patches for mem2mem_testdev that are here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/m2m I think that the way I handle colorspace there is quite reasonable. Note that I just used V4L2_COLORSPACE_REC709 as the default. I think it is unnecessary to make a distinction between SDTV and HDTV colorspace. Note that I need to do a bit more work on v4l2-compliance so that it recognizes and correctly handles mem2mem devices. Some of the tests do not work correctly at the moment for such devices. 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Android -palash -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, July 18, 2012 4:37 AM To: Palash Bandyopadhyay Cc: workshop-2...@linuxtv.org; Linux Media Mailing List Subject: Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Hi Palash, On Tuesday 17 July 2012 15:57:18 Palash Bandyopadhyay wrote: Count me in when we have this discussion as this is something we too are working on. Which one, the media controller library, or Android ? On Tuesday, July 17, 2012 3:47 PM Laurent Pinchart wrote: On Tuesday 17 July 2012 14:30:53 Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. Great news! The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Sakari and I will spend time on the long-awaited media controller library in a couple of weeks, I hope to have results to present during the summit. Depending on the audience, I would also be interested in getting feedback from SoC vendors who are not (yet) active in the V4L2 community on our approach and how we could best help them. This could include discussions about Android, as I believe we need to push V4L2 on that platform. Guennadi's recent work on an Android V4L2 camera library is a good first step in that direction. -- Regards, Laurent Pinchart Conexant E-mail Firewall (Conexant.Com) made the following annotations - ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** - -- 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] pms.c: remove duplicated include
On Wed 18 July 2012 16:41:47 Duan Jiong wrote: Signed-off-by: Duan Jiong djduanji...@gmail.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks, Hans --- drivers/media/video/pms.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/video/pms.c b/drivers/media/video/pms.c index b4c679b..77f9c92 100644 --- a/drivers/media/video/pms.c +++ b/drivers/media/video/pms.c @@ -30,7 +30,6 @@ #include linux/ioport.h #include linux/init.h #include linux/mutex.h -#include linux/slab.h #include linux/uaccess.h #include linux/isa.h #include asm/io.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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Wed, Jul 18, 2012 at 10:00 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Another ambiguity for your list: what should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). Whatever gets decided in terms of eliminating the ambiguity, we should definitely do a v4l2-compliance test for this. I've seen drivers in the past that return -EINVAL if the requested format is not supported (which resulted in various userland apps inventing their own workarounds over the years). 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
[PATCH for 3.6] v4l: DocBook: VIDIOC_CREATE_BUFS: add hyperlink
Signed-off-by: Nicolas Thery nicolas.th...@st.com --- diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index 5e73b1c..a8cda1a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -64,7 +64,7 @@ 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 +v4l2-format; 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 required I/O method. The @@ -114,7 +114,7 @@ information./para //entry /row row - entrystructnbsp;v4l2_format/entry + entryv4l2-format;/entry entrystructfieldformat/structfield/entry entryFilled in by the application, preserved by the driver./entry /row-- 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/PATCH 04/13] devicetree: Add common video devices bindings documentation
Hi Guennadi, On 07/16/2012 11:09 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- Documentation/devicetree/bindings/video/video.txt | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/video.txt diff --git a/Documentation/devicetree/bindings/video/video.txt b/Documentation/devicetree/bindings/video/video.txt new file mode 100644 index 000..9f6a637 --- /dev/null +++ b/Documentation/devicetree/bindings/video/video.txt @@ -0,0 +1,10 @@ +Common properties of video data source devices (image sensor, video encoders, etc.) + +Video bus types +--- + +- video-bus-type : must be one of: + +- itu-601 : parallel bus with HSYNC and VSYNC - ITU-R BT.601; +- itu-656 : parallel bus with embedded synchronization - ITU-R BT.656; wikipedia tells me, that bt.601 is mostly a data encoding standard, it also defines bus-types, but recent versions also include serial busses. Hmm, indeed, I got slightly misled by the Samsung SoCs' User Manuals that used bt.601/bt.656 to distinguish between bus with sync signals and with embedded sync. +- mipi-csi2 : MIPI-CSI2 serial bus; In general: are these at all needed? Wouldn't it be better to specify pads on sensors and interfaces to differentiate between serial and parallel connections. As for whether HSYNC and VSYNC are used - I see 3 We have video buses and data receivers and transmitters attached to them. The pads concept doesn't quite fit here for me. Specifying possible links with character string tags might be a way to go, but I'd like to hear others' opinion on that. Do we have any bindings already that do something similar ? possibilities there: 1. real sync signals are used - the default. 2. embedded syncs shall be used, because sync signals are missing. This should (arguably) be derived from pinctrl - see this discussion: http://lkml.indiana.edu/hypermail/linux/kernel/1205.2/index.html#03893 Hmm, I'm not terribly familiar with pinctrl API, but wouldn't it be required to have two pin group names: (data + clock + sync) signals and (data + clock) (for embedded video synchronization) ? We would have to name these two configurations somehow anyway, wouldn't we ? Also, as Stephen pointed out, the control flow is supposed to be from drivers to pin controller, not the other way around. 3. sync signals are present, but cannot be used, because one of the partners doesn't support them - .g_mbus_config() can be used to retrieve this information. OK. 4. sync signals are available and supported by both peers, but for some reason the user prefers to use embedded sync data - is such a case feasible? Even if so, this should be run-time configurable then? I've never seen such a situation. I would expect that if sync signal wires are routed, they shall be used. Otherwise only embedded synchronization would be used, to save PCB area. So, maybe we don't need these at all. We need something that would let drivers distinguish which (serial/ parallel) bus is supported on a board. And what type of synchronization is used. I'm fine as long as this can be specified reliably in DT and drivers of the transmitters/receivers can configure their output/input interfaces. I'm not against dynamic configuration but static one also need to be supported. -- 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
Re: [RFC] media DT bindings
Hi Guennadi,
On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
[...]
On 07/11/2012 04:27 PM, Guennadi Liakhovetski wrote:
Hi all
Background
==
With ARM adoption of flat Device Trees a need arises to move platform
device descriptions and their data from platform files to DT. This has
also to be done for media devices, e.g., video capture and output
interfaces, data processing devices, camera sensors, TV decoders and
encoders. This RFC is trying to spawn a discussion to define standard V4L
DT bindings. The first version will concentrate on the capture path,
mostly taking care of simple capture-interface - camera sensor / TV
decoder configurations. Since the author is not working intensively yet
with the Media Controller API, pad-level configuration, these topics might
be underrepresented in this RFC. I hope others, actively working in these
areas, will fill me in on them.
We've done some work on device tree support for SoC camera interface
with driver based on the Media Controller API, I've posted some RFC
patches a few weeks ago:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg14769.html
But unfortunately didn't receive any comments,
You have now ;-)
:)
perhaps because the actual
bindings were not abstracted enough from a specific hardware support.
An updated version of these patch set can be found here:
https://github.com/snawrocki/linux/commits/camera-of-2
Of course we shouldn't be forgetting that underlying bindings need to
be the same, regardless of the drivers are based on soc_camera, Media
Controller/subdev pad-level frameworks, or something else.
Of course, the more properties are common - the better. I also made sure
not to introduce any soc-camera specific properties. But since I mostly
work with those systems, I am not fully aware of requirements, imposed by
other hardware types, so, I hope others will contribute to this work:-)
Anything linux specific in the bindings would be inappropriate.
Not sure what you mean here - which Linux specific bindings and why they
wouldn't be appropriate? Don't think our bindings would be used by any
other OS kernels.
The bindings should be OS agnostic, so they can be used by other operating
systems and bootloaders. That's one of fundamental FDT assumptions, AFAIU.
It is outlined in this presentation (slide 22):
http://events.linuxfoundation.org/images/stories/pdf/lf_elc12_abraham.pdf
Overview
As mentioned above, typical configurations, that we'll be dealing with
consist of a DMA data capture engine, one or more data sources like camera
sensors, possibly some data processing units. Data capture and processing
engines are usually platform devices, whereas data source devices are
typically I2C slaves. Apart from defining each device we'll also describe
connections between them as well as properties of those connections.
Capture devices
==
These are usually platform devices, integrated into respective SoCs. There
also exist external image processing devices, but they are rare. Obvious
differences between them and integrated devices include a different bus
attribution and a need to explicitly describe the connection to the SoC.
As far as capture devices are concerned, their configuration will
typically include a few device-specific bindings, as well as standard
ones. Standard bindings will include the usual reg, interrupts,
clock-frequency properties.
It is more complex to describe external links. We need to describe
configurations, used with various devices, attached to various pads. It is
proposed to describe such links as child nodes. Each such link will
reference a client pad, a local pad and specify the bus configuration. The
media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
proposed to describe both the bus-width in the parallel case and the
number of lanes in the serial case, using the standard bus-width
property.
On the parallel bus common properties include signal polarities, possibly
data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if lines 7:0),
protocol (e.g., BT.656). Additionally device-specific properties can be
defined.
A MIPI CSI-2 bus common properties would include, apart from the number of
lanes, routed to that client, the clock frequency, a channel number,
possibly CRC and ECC flags.
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg =0xfe91 0xa0;
interrupts =0x880;
bus-width =16;/* #lines routed on the board */
clock-frequency =5000;/* max clock */
#address-cells =1;
#size-cells =0;
...
ov772x-1 = {
reg =0;
This property might be redundant, we already have the client phandle
pointing to ov772x@0x21-0, which has all interesting properties
Re: CX25821 driver in kernel 3.4.4 problem
On Wed, Jul 18, 2012 at 11:38 AM, Radek Mašín ra...@masin.eu wrote: Hello, with your patch driver is working properly. I see devices in /dev directory and in dmesg is attached output: Great! That's good news. I'll send the patch to the list later. If you encounter any other problems, please let us know. Thanks for the report and for the testing, Ezequiel. -- 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/PATCH 12/13] media: s5p-fimc: Add device tree based sensors registration
On 07/16/2012 11:51 AM, Guennadi Liakhovetski wrote: [...] diff --git a/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt index b459da2..ffe09ac 100644 --- a/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt @@ -54,6 +54,28 @@ Required properties: - cell-index : FIMC-LITE IP instance index; +The 'sensor' nodes +-- + +Required properties: + + - i2c-client : a phandle to an image sensor I2C client device; + +Optional properties: + +- samsung,camif-mux-id : FIMC video multiplexer input index; for camera +port A, B, C the indexes are 0, 1, 0 respectively. +If this property is not specified a default 0 +value will be used by driver. Isn't it possible to have several clients connected to different mux inputs and switch between them at run-time? Even if only one of them can be active at any time? That's why I've introduced link nodes in my RFC to specify exactly which pads are connected. Yes, of course it is. For such a configuration there would be multiple 'sensor' nodes and each of them would contain a 'samsung,camif-mux-id' determining camera port the corresponding sensor/encoder is wired to. Then switching between the sensors would be possible by setting up a proper media link (or just through VIDIOC_S_INPUT ioctl, if that's feasible) and then writing the mux input index and the camera port type values to the control registers (in this specific case ports A,B (index 0, 1) are parallel and port C (index 0) is a serial port). Thus using only input index wouldn't be sufficient to do the sensors switch over. -- Thanks, 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
[PATCH] cx25821: Remove bad strcpy to read-only char*
The strcpy was being used to set the name of the board.
This was both wrong and redundant,
since the destination char* was read-only and
the name is set statically at compile time.
The type of the name field is changed to const char*
to prevent future errors.
Reported-by: Radek Masin ra...@masin.eu
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
Hi Mauro,
I believe without this patch cx25821 driver
is completely unusable.
So perhaps this patch should also go to stable tree?
I'm a bit unsure about this procedure.
Regards,
Ezequiel.
---
drivers/media/video/cx25821/cx25821-core.c |3 ---
drivers/media/video/cx25821/cx25821.h |2 +-
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/cx25821/cx25821-core.c
b/drivers/media/video/cx25821/cx25821-core.c
index 83c1aa6..f11f6f0 100644
--- a/drivers/media/video/cx25821/cx25821-core.c
+++ b/drivers/media/video/cx25821/cx25821-core.c
@@ -904,9 +904,6 @@ static int cx25821_dev_setup(struct cx25821_dev *dev)
list_add_tail(dev-devlist, cx25821_devlist);
mutex_unlock(cx25821_devlist_mutex);
- strcpy(cx25821_boards[UNKNOWN_BOARD].name, unknown);
- strcpy(cx25821_boards[CX25821_BOARD].name, cx25821);
-
if (dev-pci-device != 0x8210) {
pr_info(%s(): Exiting. Incorrect Hardware device = 0x%02x\n,
__func__, dev-pci-device);
diff --git a/drivers/media/video/cx25821/cx25821.h
b/drivers/media/video/cx25821/cx25821.h
index b9aa801..029f293 100644
--- a/drivers/media/video/cx25821/cx25821.h
+++ b/drivers/media/video/cx25821/cx25821.h
@@ -187,7 +187,7 @@ enum port {
};
struct cx25821_board {
- char *name;
+ const char *name;
enum port porta;
enum port portb;
enum port portc;
--
1.7.4.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
Re: [RFC/PATCH 06/13] media: s5p-fimc: Add device tree support for FIMC-LITE
Hi Guennadi, On 07/18/2012 09:57 AM, Guennadi Liakhovetski wrote: On Tue, 17 Jul 2012, Sylwester Nawrocki wrote: On 07/16/2012 11:15 AM, Guennadi Liakhovetski wrote: --- a/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt @@ -39,6 +39,21 @@ Required properties: depends on the SoC revision. For S5PV210 valid values are: 0...2, for Exynos4x1x: 0...3. + +'fimc-lite' device node +--- + +Required properties: + +- compatible : should be one of: + samsung,exynos4212-fimc; + samsung,exynos4412-fimc; +- reg : physical base address and size of the device's memory mapped + registers; +- interrupts : should contain FIMC-LITE interrupt; +- cell-index : FIMC-LITE IP instance index; Same as in an earlier patch - not sure this is needed. It is needed for setting up a pipeline of multiple sub-device within a SoC. As I commented on patch 2/13 I'd like to replace this with proper entries in the aliases node. Some sub-devices have registers that these indexes need to be directly written to. Aha, so, these are not purely software indices, that you just use to identify your devices, these are actual hardware values? You really have to write, e.g., 1 into a resizer register to connect it to a certain capture engine? Ok, in this case it indeed might make sense to have these Yes, that's more or less how it works. If I select input mux id = 0, then MIPI-CSIS0 have to be used for streaming. For this FIMC-LITE device there are some commands/registers within the device that sits after FIMC-LITE in the data pipeline (not yet mainlined). values in the DT. Not sure how best to call these properties, or whether aliases is the best solution, but that's already a detail. And btw, if you Yeah, the property seems more accurate. But I don't really mind, I could just use whatever is accepted in the mainline. do decide to keep this as a property, maybe this is one of the cases, where you'd want to mark it with your hardware type, like fimc,cell-id or similar? I'm not sure about that. cell-index has well defined semantics. So there should be no reason to use device specific property. I would have then to use samsung,fimc-cell-id, samsung,fimc-lite-cell-id and samsung,csis-cell-id, as all device specific bindings need to be prefixed with a manufacturer code. -- Thanks, 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
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:Wed Jul 18 19:00:17 CEST 2012 git hash:931efdf58bd83af8d0578a6cc53421675daf6d41 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-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-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-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-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS apps: 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: [RFC/PATCH 05/13] media: s5p-fimc: Add device tree support for FIMC devices
On 07/18/2012 10:17 AM, Guennadi Liakhovetski wrote: On Tue, 17 Jul 2012, Sylwester Nawrocki wrote: On 07/16/2012 11:13 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Karol Lewandowskik.lewando...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com From the documentation below I think, I understand what it does, but why is it needed? It doesn't describe your video subsystem topology, right? How various subdevices are connected. It just lists them all in one node... A description for this patch would be very welcome IMHO and, maybe, such a node can be completely avoided? Sorry, I'll provide better description in next iteration. It's true it doesn't describe the topology in detail, as there are multiple one-to many possible connections between sub-devices. An exact topology is coded in the driver and can be changed through MC API. The samsung,camif-mux-id and video-bus-type properties at sensor nodes just specify to which physical SoC camera port an image sensor is connected. So, don't you think my media-link child nodes are a good solution for this? Not quite yet ;) It would be good to see some example implementation and how it actually works. Originally the all camera devices were supposed to land under common 'camera' node. And a top level driver would be registering all platform devices. With this approach it would be possible to better control PM handling (which currently depends on an order of registering devices to the driver core). But then we discovered that we couldn't use OF_DEV_AUXDATA in such case, which was required to preserve platform device names, in order for the clock API to work. So I've moved some sub-devices out of 'camera' node and have added only a list of phandles to them in that node. This is rather a cheap workaround.. I think all camera sub-devices should be placed under common node, as there are some properties that don't belong to any sub-node: GPIO config, clocks, to name a few. Of course simpler devices might not need such a composite node. I think we can treat the sub-device interdependencies as an issue separate from a need for a common node. If some devices need to reflect the topology better, we probably could include in some nodes (a list of) phandles to other nodes. This could ease parsing the topology at the drivers, by using existing OF infrastructure. Ok, I think you have some good ideas in your RFC's, an interesting question now is - how to proceed. Do you think we'd be able to work out a combined RFC? Or would you prefer to make two versions and then see what others think? In either case it would be nice, I think, if you could try to separate what you see as common V4L DT bindings, then we could discuss that separately. Whereas what you think is private to your hardware, we can also look at for common ideas, or maybe even some of those properties we'll wake to make common too. I think we need a one combined RFC and continue discussions in one thread. Still, our proposals are quite different, but I believe we need something in between. I presume we should focus more to have common bindings for subdevs that are reused among different host/ISP devices, i.e. sensors and encoders. For simple host interfaces we can likely come up with common binding patterns, but more complex processing pipelines may require a sort of individual approach. The suspend/resume handling is still something I don't have an idea on how the solution for might look like.. Instantiating all devices from a top level driver could help, but it is only going to work when platforms are converted to the common clock framework and have their clocks instantiated from device tree. This week I'm out of office, and next one or two I have some pending assignments. So there might be some delay before I can dedicate some reasonable amount of time to carry on with that topic. I unfortunately won't be attending KS this time. I'll try to prepare some summary with topics that appear common. And also to restructure my RFC series to better separate new common features and specific H/W support. In the meantime we could possibly continue discussions in your RFC thread. -- 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
Re: libv4l2: error dequeuing buf: Resource temporarily unavailable
In Ubuntu it works. THANK YOU! Are you sure, that they have a problem with their ffmpeg or could it be a problem with their v4l as well? I would like to investigate further. Next I gonna test with an self-compiled ffmpeg. Again: thank you very much! I am trying to get some hints since weeks in ffmpeg lists as well as in fedora lists, nobody could help there. Regards -- Felix It means, your FFmpeg may not be installed properly or has dependency issue. To confirm it, use Ubuntu-10.04-LTS--LiveDVD (that can be downloaded from: http://cdimage.ubuntu.com/releases/lucid/release/ ) without installation, and run sudo apt-get install ffmpeg before running: $ modprobe -r saa7134 $ modprobe saa7134 card=8 $ ffmpeg -t 300 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-5min.mpg or $ ffmpeg -t 600 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-10min.avi The FFmpeg commands listed above had been proven working well, with Sensoray Model 811 (http://www.sensoray.com/products/811.htm), 911 (http://www.sensoray.com/products/911.htm), 614-NC (http://www.sensoray.com/products/614.htm), and 314-NC (http://www.sensoray.com/products/314.htm), which are all SAA7134-based frame/video capture boards. -Original Message- From: llar...@gmx.net [mailto:llar...@gmx.net] Sent: Tuesday, July 17, 2012 11:46 AM To: char...@sensoray.com Cc: linux-media@vger.kernel.org Subject: Re: libv4l2: error dequeuing buf: Resource temporarily unavailable Your driver load may not be quite right or got some conflicts. According to: http://www.kernel.org/doc/Documentation/video4linux/CARDLIST.saa713 4, the Terratec Cinergy 400 TV should be card=8. Have you tried: restart, modprobe -r saa7134, modprobe saa7134 card=8, dmesg | grep saa7134, and checked if the Terratec Cinergy 400 TV showed up correctly? If right, it should be Ok: ffmpeg -f video4linux2 -i /dev/video0 out.mpg ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg ffmpeg -t 60 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-60sec.avi ..., etc. Thanks a lot for your help. The card is loaded OK. I tried it with the card=8 parameter in a newly created file /etc/modprobe.d/saa7134.conf. It seems to be loaded properly: dmesg | grep saa7134 [ 24.978050] saa7134[0]: found at :04:01.0, rev: 1, irq: 17, latency: 32, mmio: 0xfe50 [ 24.978058] saa7134[0]: subsystem: 153b:1142, board: Terratec Cinergy 400 TV [card=8,insmod option] [ 24.978073] saa7134[0]: board init: gpio is 5 [ 25.053979] input: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0/input6 [ 25.054018] rc0: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0 [ 25.187509] saa7134[0]: i2c eeprom 00: 3b 15 42 11 ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187517] saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187523] saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187529] saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187535] saa7134[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187541] saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187547] saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187553] saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187559] saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187566] saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187571] saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187577] saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187583] saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187589] saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187595] saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187601] saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.716134] saa7134[0]: registered device video0 [v4l2] [ 25.716157] saa7134[0]: registered device vbi0 [ 25.998624] saa7134 ALSA driver for DMA sound loaded [ 25.998650] saa7134[0]/alsa: saa7134[0] at 0xfe50 irq 17 registered as card -1 ffmpeg -f video4linux2 -i /dev/video0 test.mpg gives still the error mentioned in the subject, ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg gives an I/O error while setting the framerate
Re: [PATCH 10/10] staging: solo6x10: Avoid extern declaration by reworking module parameter
On Thu, Jun 21, 2012 at 4:52 PM, Ezequiel Garcia elezegar...@gmail.com wrote: This patch moves video_nr module parameter to core.c and then passes that parameter as an argument to functions that need it. This way we avoid the extern declaration and parameter dependencies are better exposed. ... NACK. The changes to video_nr are supposed to be preserved. -- 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
