Setting routing of v4l2 subdevice
Hi, I'm trying to get the camera working on our Android platform and I'm having some trouble understanding how to select the appropriate input. The platform specifics are: Analog camera (PAL-I) - TVP5150 TV decoder - iMX53 IPU/CSI Note: The TVP driver is not the one currently in the mainline kernel, I've had to modify it back to the old int-device format to be compatible with the Freescale IPU/CSI drivers. The TVP chip has 2 analog inputs which can be selected over the I2C interface. The driver includes a V4L2 ioctl (vidioc_int_s_video_routing_num) for selecting the required one. My question is how do I go about accessing this from userland. The closest thing I can see if the VIDIOC_S_INPUT ioctl, but this get picked up by the freescale CSI driver (mxc_v4l2_capture.c), which also has 2 possible input paths to select between (although we only ever use 1). I had initially hacked this ioctl in the freescale driver to pass the call to the TVP driver, but this doesn't feel right and I'm sure there must be a better way to handle this. Any suggestions welcome, Adam Plextek Limited Registered Address: London Road, Great Chesterford, Essex, CB10 1NY, UK Company Registration No. 2305889 VAT Registration No. GB 918 4425 15 Tel: +44 1799 533 200. Fax: +44 1799 533 201 Web:http://www.plextek.com Electronics Design and Consultancy -- 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: Changing frame size on the fly in SOC module
Hi Guennadi, Thanks for the response, it's good just to get confirmation that I was indeed interpreting the code properly. I guess the main reason this is more significant for me is the constraints I have on the hardware, i.e. it cannot handle the 640x480 at any reasonable frame rate so we need the camera hardware to provide the smaller image and second closing the camera powers the module down to conserve power, which means time from open to image capture is slow (particularly because I have to drop the first few frames with the auto white balance etc... settles). I had already assumed that streaming would need to be stopped before the size could be changed, really don't see a problem with that. I had used that approach with non-SOC style modules. I think the documentation in videobuf talks about requesting the MAX buffer size you will require from the start. So again I had already assumed I'd need to do that as well. I'm not sure I fully understand the concern about multiple simultaneous users. I certainly don't have that as a user case in my own requirements (device is a small handheld teaching aid) and I would have thought that if 2 users try to use the same camera module at the same time all hell would probably break out anyway. Have to admit I've never tried it before. Adam -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: 28 October 2010 20:01 To: Adam Sutton Cc: linux-media@vger.kernel.org Subject: Re: Changing frame size on the fly in SOC module Hi Adam On Thu, 28 Oct 2010, Adam Sutton wrote: Hi, Sometime ago I developed an SOC based camera driver for my platform (ov7675 on iMX25), for the most part it seems to be working well however at the time I couldn't manage to change the frame size on the fly (without closing / re-opening the device). The current problem I have is that my application needs to display a 320x240 preview image on screen, but to capture a static image at 640x480. I can do this as long as I close the device in between, unfortunately for power consumption reasons the camera device is put into a low power state whenever the device is released. This means that the image capture takes approx 1.5s (the requirement I have to meet is 1s). Now I could cheat and simply subsample (in software) the 640x480 image, but that puts additional burden on an already overworked MCU. Having been through the soc_camera and videobuf code and as far as I can tell this inability to change the frame size without closing the camera device appears to be a design decision. Yes, it is. What I'm really after is confirmation one way of the other. If it's not, what is the correct process to achieve the frame change without closing the device. And if it is, does anybody have any suggestions of possible workarounds? It has been decided that way, because we didn't have a good use-case for changing the frame format on-the-fly to develop for and to test with. You seem to have one now, so, go ahead;) There are a couple of issues to address though - videobuffer configuration is one of them, host reconfiguration is the other one, possible multiple simultaneous users is the third one (ok, only one of them will be actually streaming). This use case - different size preview and single shot capture has come up a couple of times before, but noone has brought it to a proper mainstream solution. One thing you'd still want to do, I think, is to stop streaming before reconfiguring, and restart it afterwards. So, maybe a viable solution would be: in soc_camera_s_fmt_vid_cap() check not just for icf-vb_vidq.bufs[0] != NULL, but rather for if streaming is not running, and then someone will certainly have to check for large enough buffers. So, you'd have to request max size buffers from the beginning even for preview. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Plextek Limited Registered Address: London Road, Great Chesterford, Essex, CB10 1NY, UK Company Registration No. 2305889 VAT Registration No. GB 918 4425 15 Tel: +44 1799 533 200. Fax: +44 1799 533 201 Web:http://www.plextek.com Electronics Design and Consultancy -- 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
Changing frame size on the fly in SOC module
Hi, Sometime ago I developed an SOC based camera driver for my platform (ov7675 on iMX25), for the most part it seems to be working well however at the time I couldn't manage to change the frame size on the fly (without closing / re-opening the device). The current problem I have is that my application needs to display a 320x240 preview image on screen, but to capture a static image at 640x480. I can do this as long as I close the device in between, unfortunately for power consumption reasons the camera device is put into a low power state whenever the device is released. This means that the image capture takes approx 1.5s (the requirement I have to meet is 1s). Now I could cheat and simply subsample (in software) the 640x480 image, but that puts additional burden on an already overworked MCU. Having been through the soc_camera and videobuf code and as far as I can tell this inability to change the frame size without closing the camera device appears to be a design decision. What I'm really after is confirmation one way of the other. If it's not, what is the correct process to achieve the frame change without closing the device. And if it is, does anybody have any suggestions of possible workarounds? Thanks Adam Plextek Limited Registered Address: London Road, Great Chesterford, Essex, CB10 1NY, UK Company Registration No. 2305889 VAT Registration No. GB 918 4425 15 Tel: +44 1799 533 200. Fax: +44 1799 533 201 Web:http://www.plextek.com Electronics Design and Consultancy -- 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
SOC camera port for ov7675/ov2640 on i.MX25
Hi,
I'm just beginning a Linux based project running on a Freescale i.MX25.
One of
my jobs is to write a camera driver for the sensor we're going to be
using
(Omnivision 7675). However at present I only have access to an ov2640
attached
to a Freescale 3stack development board. I thought it would be a useful
and
interesting exercise to port the driver provided by Freescale to the new
soc_camera framework.
I've written the ov2640 driver, using a variety of other drivers as
references
and I'm using the mx25_camera host driver (with a few mods) posted by
Arno
Euteneuer. After getting over some basic setup/config problems I've now
got as
far as the mx25_camera loading and this then auto loading the ov2640.
This
correctly probes the I2C and detects the sensor.
However I've now come up against a problem that I'm unsure of how to
solve and
I'm not sure whether its a case of my not properly following the current
framework. soc_camera_probe() is called and detects the the
soc_camera_link
object contains board information and therefore calls
soc_camera_init_i2c() this
in turn calls v4l2_i2c_new_subdev_board() which then attempts to create
a new
i2c_client (i2c_new_device()) and it is at this point things fail.
Because an i2c_client already exists (auto created from the static board
info
registered by the platform configuration), the one passed into the
probe()
routine of my chip driver, the i2c_new_device() call fails as it believe
the
device is busy as a client already exists for that I2C address.
I can only assume that there is something wrong with the way I've set
things up
/ used the framework. However I've compared it to several other modules
and
can't see any obvious faults (although its not obvious which drivers
represent
the current preferred approach).
I should say that I'm using a 2.6.31 based kernel (provided by
Freescale) into
which I've grafted the 2.6.33 media drivers (and obvious dependencies)
so I
guess something about this graft could be causing the problem. Though I
cannot
see what from looking at other changes.
I've pasted in the 4 files I think I relevant to what I'm doing:
drivers/media/video/mx25_camera.c
drivers/media/video/ov2640.c
arch/arm/mach-mx25/devices_merlin.c // extract only
arch/arm/mach-mx25/mx25_merlin.c // extract only
This is my first time posting to the mailing list so apologies if this
is not
the standard way of doing things.
I'd be grateful for any help.
Regards,
Adam
diff -Nuar a/devices_merlin.c b/devices_merlin.c
--- a/devices_merlin.c 1970-01-01 00:00:00.0 +
+++ b/devices_merlin.c 2010-03-24 11:16:22.0 +
@@ -0,0 +1,42 @@
+#if (defined CONFIG_VIDEO_MX25) || (defined CONFIG_VIDEO_MX25_MODULE)
+static u64 csi_dmamask = 0x;
+
+/* TODO: does this belong here or in the board spec?
+ * AND do we need a separate devices.c file? This doesn't seem to be
standard
practice?
+ */
+static struct mx25_camera_pdata camera_pdata = {
+ .flags = MX25_CAMERA_DATAWIDTH_8 | MX25_CAMERA_DATAWIDTH_10 |
MX25_CAMERA_DATAWIDTH_16,
+ .mclk_10khz = 2400,
+};
+
+static struct resource mx25_csi_resources[] = {
+ {
+ .start = 0x53FF8000,
+ .end = 0x53FFBFFF,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = 17,
+ .end = 17,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+struct platform_device mx25_csi_device = {
+ .name = mx25-camera,
+ .id = 0,
+ .dev = {
+ .coherent_dma_mask = 0x,
+ .dma_mask = csi_dmamask,
+ .platform_data = camera_pdata,
+ },
+ .num_resources = ARRAY_SIZE(mx25_csi_resources),
+ .resource = mx25_csi_resources,
+};
+static inline void mxc_init_csi(void)
+{
+ printk(%s: working\n, __func__);
+ if (platform_device_register(mx25_csi_device) 0)
+ dev_err(mx25_csi_device.dev,
+ Unable to register mx25 csi device\n);
+}
+#endif
diff -Nuar a/mx25_camera.c b/mx25_camera.c
--- a/mx25_camera.c 1970-01-01 00:00:00.0 +
+++ b/mx25_camera.c 2010-03-24 10:59:14.0 +
@@ -0,0 +1,1006 @@
+/*
+ * V4L2 Driver for i.MX25 camera (CSI) host
+ *
+ * Copyright (C) 2009, Arno Euteneuer arno.euteneuer at toptica.com
+ *
+ * Based on i.MXL/i.MXL camera (CSI) host driver
+ * Copyright (C) 2008, Paulius Zaleckas paulius.zaleckas at
teltonika.lt
+ * Copyright (C) 2009, Darius Augulis augulis.darius at gmail.com
+ *
+ * Based on PXA SoC camera driver
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski kernel at
pengutronix.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
