Re: [PATCH] mt9t031: preserve output format on VIDIOC_S_CROP
; + mt9t031-out_height = MT9T031_MAX_HEIGHT; + /* * Simulated autoexposure. If enabled, we calculate shutter width * ourselves in the driver based on vertical blanking and frame width --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEB3494, Station 9, CH-1015 Lausanne -- 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] mt9t031: use runtime pm support to restore ADDRESS_MODE registers
If the platform hooks are provided, soc_camera powers off the device
on close and powers it on on open. This resets the ADDRESS_MODE registers
which then can be different to the value the driver has computed for them.
This patch setups runtime pm usage for mt9t031 and uses the resume function
to write the ADDRESS_MODE registers in order to fix the above described
problem.
This patch depends the pm runtime management in soc_camera, provided in this
patch:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15686
Signed-off-by: Valentin Longchamp valentin.longch...@epfl.ch
---
drivers/media/video/mt9t031.c | 66 ++--
1 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index a9061bf..bc2ecd5 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -8,14 +8,16 @@
* published by the Free Software Foundation.
*/
-#include linux/videodev2.h
-#include linux/slab.h
+#include linux/device.h
#include linux/i2c.h
#include linux/log2.h
+#include linux/pm.h
+#include linux/slab.h
+#include linux/videodev2.h
-#include media/v4l2-subdev.h
-#include media/v4l2-chip-ident.h
#include media/soc_camera.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
/*
* mt9t031 i2c address 0x5d
@@ -681,12 +683,66 @@ static int mt9t031_s_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
}
/*
+ * Power Management:
+ * This function does nothing for now but must be present for pm to work
+ */
+static int mt9t031_runtime_suspend(struct device *dev)
+{
+ return 0;
+}
+
+/*
+ * Power Management:
+ * COLUMN_ADDRESS_MODE and ROW_ADDRESS_MODE are not rewritten if unchanged
+ * they are however changed at reset if the platform hook is present
+ * thus we rewrite them with the values stored by the driver
+ */
+static int mt9t031_runtime_resume(struct device *dev)
+{
+ struct video_device *vdev = to_video_device(dev);
+ struct soc_camera_device *icd = container_of(vdev-parent,
+ struct soc_camera_device, dev);
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct i2c_client *client = sd-priv;
+ struct mt9t031 *mt9t031 = to_mt9t031(client);
+
+ int ret;
+ u16 xbin, ybin;
+
+ xbin = min(mt9t031-xskip, (u16)3);
+ ybin = min(mt9t031-yskip, (u16)3);
+
+ ret = reg_write(client, MT9T031_COLUMN_ADDRESS_MODE,
+ ((xbin-1)4) | (mt9t031-xskip-1));
+ if (ret 0)
+ return ret;
+
+ ret = reg_write(client, MT9T031_ROW_ADDRESS_MODE,
+ ((ybin-1)4) | (mt9t031-yskip-1));
+ if (ret 0)
+ return ret;
+
+ return 0;
+}
+
+static struct dev_pm_ops mt9t031_dev_pm_ops = {
+ .runtime_suspend= mt9t031_runtime_suspend,
+ .runtime_resume = mt9t031_runtime_resume,
+};
+
+static struct device_type mt9t031_dev_type = {
+ .name = MT9T031,
+ .pm = mt9t031_dev_pm_ops,
+};
+
+/*
* 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 mt9t031_video_probe(struct i2c_client *client)
{
struct mt9t031 *mt9t031 = to_mt9t031(client);
+ struct video_device *vdev = soc_camera_i2c_to_vdev(client);
s32 data;
int ret;
@@ -712,6 +768,8 @@ static int mt9t031_video_probe(struct i2c_client *client)
ret = mt9t031_idle(client);
if (ret 0)
dev_err(client-dev, Failed to initialise the camera\n);
+ else
+ vdev-dev.type = mt9t031_dev_type;
/* mt9t031_idle() has reset the chip to default. */
mt9t031-exposure = 255;
--
1.6.3.3
--
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: soc-camera: patches for 2.6.34
Guennadi Liakhovetski wrote: Hi all Nothing exciting for soc-camera this time for a change, just a couple of small improvements. These patches are already in my local tree, waiting to be pushed up: Antonio Ospite (1): pxa_camera: remove init() callback Guennadi Liakhovetski (3): soc-camera: update mt9v022 to take into account board signal routing tw9910: use TABs for indentation soc-camera: adjust coding style to match V4L preferences Kuninori Morimoto (1): soc-camera: ov772x: Modify buswidth control Magnus Damm (1): soc-camera: return -ENODEV is sensor is missing Others on the radar: Kuninori Morimoto: MT9T031: write xskip and yskip at each set_params call * status: being discussed in PM context in: Well, the above one is from me, and I have posted the updated version for pm context this morning: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15897 (You certainly had noticed, but wanted to make sure). Guennadi Liakhovetski: soc-camera: add runtime pm support for subdevices * under discussion Németh Márton: soc_camera: match signedness of soc_camera_limit_side() * status: an updated patch has been proposed by me, waiting for confirmation Guennadi Liakhovetski: document new pixel formats * status: I still have to figure out how to combine git / hg for this one and actually do it... Kuninori Morimoto: [1/3] soc-camera: mt9t112: modify exiting conditions from standby mode [2/3] soc-camera: mt9t112: modify delay time after initialize [3/3] soc-camera: mt9t112: The flag which control camera-init is * status: at least patches 2 and 3 are still being discussed, waiting for results Any patches, that I've forgotten? Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEB3494, Station 9, CH-1015 Lausanne -- 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] MT9T031: write xskip and yskip at each set_params call
, }; Thank you in advance for your help. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEB3494, Station 9, CH-1015 Lausanne -- 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: [Q] udev and soc-camera
Kay Sievers wrote: On Thu, Jan 28, 2010 at 00:25, Valentin Longchamp valentin.longch...@epfl.ch wrote: I have a system that is built with OpenEmbedded where I use a mt9t031 camera with the soc-camera framework. The mt9t031 works ok with the current kernel and system. However, udev does not create the /dev/video0 device node. I have to create it manually with mknod and then it works well. If I unbind the device on the soc-camera bus (and then eventually rebind it), udev then creates the node correctly. This looks like a timing issue at coldstart. OpenEmbedded currently builds udev 141 and I am using kernel 2.6.33-rc5 (but this was already like that with earlier kernels). Is this problem something known or has at least someone already experienced that problem ? You need to run udevadm trigger as the bootstrap/coldplug step, after you stared udev. All the devices which are already there at that time, will not get created by udev, only new ones which udev will see events for. The trigger will tell the kernel to send all events again. Or just use the kernel's devtmpfs, and all this should work, even without udev, if you do not have any other needs than plain device nodes. Thanks a lot Kay, you pointed me exactly where I needed to watch. OpenEmbedded adds udevadm trigger a big list of --susbsystem-nomatch options as soon as you are not doing your first boot anymore and video4linux is among them. I either have to remove this option in the script or understand why my other /dev nodes are kept (ttys are doing fine with the same treatment for instance) and not video4linux ones (it looks like they are using DEVCACHE or something like this). But I would prefer the first alternative since cameras may be unplugged on some robots. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEB3494, Station 9, CH-1015 Lausanne -- 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
[Q] udev and soc-camera
Hello, I have a system that is built with OpenEmbedded where I use a mt9t031 camera with the soc-camera framework. The mt9t031 works ok with the current kernel and system. However, udev does not create the /dev/video0 device node. I have to create it manually with mknod and then it works well. If I unbind the device on the soc-camera bus (and then eventually rebind it), udev then creates the node correctly. This looks like a timing issue at coldstart. OpenEmbedded currently builds udev 141 and I am using kernel 2.6.33-rc5 (but this was already like that with earlier kernels). Is this problem something known or has at least someone already experienced that problem ? Thanks and best regards Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEB3494, Station 9, CH-1015 Lausanne -- 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] MT9T031: write xskip and yskip at each set_params call
Guennadi Liakhovetski wrote:
On Wed, 20 Jan 2010, Valentin Longchamp wrote:
This prevents the registers to be different to the computed values
the second time you open the same camera with the sames parameters.
The images were different between the first device open and the
second one with the same parameters.
But why they were different? Weren't xskip and yskip preserved from the
previous S_CROP / S_FMT configuration? If so, then, I am afraid, this is
the behaviour, mandated by the API, and as such shall not be changed. Or
have I misunderstood you?
Here are more details about what I debugged:
First more details about what I do with the camera: I open the device,
issue the S_CROP / S_FMT calls and read images, the behaviour is fine,
then close the device.
Then if I reopen the device, reissue the S_CROP / S_FMT calls with the
same params, but the images is not the sames because of different xskip
and yskip. From what I have debugged in the driver at the second S_CROP
/S_FMT, xskip and yskip are computed by mt9t031_skip (and have the same
value that the one stored in the mt9t031 struct) and thus with the
current code are not rewritten.
However, if I read the register values containing bin and skip values on
the camera chip they have been reset (does a open/close do some reset to
the cam ?) and thus different than the ones that should be written.
I hope this clarifies the problem that I am experiencing. I don't think
that the API wants you to get two different images when you open the
device and issue the same parameters twice.
Best Regards
Val
Thanks
Guennadi
Signed-off-by: Valentin Longchamp valentin.longch...@epfl.ch
---
drivers/media/video/mt9t031.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index a9061bf..e4a9095 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -17,6 +17,7 @@
#include media/v4l2-chip-ident.h
#include media/soc_camera.h
+
/*
* mt9t031 i2c address 0x5d
* The platform has to define i2c_board_info and link to it from
@@ -337,15 +338,13 @@ static int mt9t031_set_params(struct i2c_client *client,
if (ret = 0)
ret = reg_write(client, MT9T031_VERTICAL_BLANKING, vblank);
- if (yskip != mt9t031-yskip || xskip != mt9t031-xskip) {
- /* Binning, skipping */
- if (ret = 0)
- ret = reg_write(client, MT9T031_COLUMN_ADDRESS_MODE,
- ((xbin - 1) 4) | (xskip - 1));
- if (ret = 0)
- ret = reg_write(client, MT9T031_ROW_ADDRESS_MODE,
- ((ybin - 1) 4) | (yskip - 1));
- }
+ /* Binning, skipping */
+ if (ret = 0)
+ ret = reg_write(client, MT9T031_COLUMN_ADDRESS_MODE,
+ ((xbin - 1) 4) | (xskip - 1));
+ if (ret = 0)
+ ret = reg_write(client, MT9T031_ROW_ADDRESS_MODE,
+ ((ybin - 1) 4) | (yskip - 1));
dev_dbg(client-dev, new physical left %u, top %u\n,
rect-left, rect-top);
--
1.6.3.3
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longch...@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEB3494, Station 9, CH-1015 Lausanne
--
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] MT9T031: write xskip and yskip at each set_params call
This prevents the registers to be different to the computed values
the second time you open the same camera with the sames parameters.
The images were different between the first device open and the
second one with the same parameters.
Signed-off-by: Valentin Longchamp valentin.longch...@epfl.ch
---
drivers/media/video/mt9t031.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index a9061bf..e4a9095 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -17,6 +17,7 @@
#include media/v4l2-chip-ident.h
#include media/soc_camera.h
+
/*
* mt9t031 i2c address 0x5d
* The platform has to define i2c_board_info and link to it from
@@ -337,15 +338,13 @@ static int mt9t031_set_params(struct i2c_client *client,
if (ret = 0)
ret = reg_write(client, MT9T031_VERTICAL_BLANKING, vblank);
- if (yskip != mt9t031-yskip || xskip != mt9t031-xskip) {
- /* Binning, skipping */
- if (ret = 0)
- ret = reg_write(client, MT9T031_COLUMN_ADDRESS_MODE,
- ((xbin - 1) 4) | (xskip - 1));
- if (ret = 0)
- ret = reg_write(client, MT9T031_ROW_ADDRESS_MODE,
- ((ybin - 1) 4) | (yskip - 1));
- }
+ /* Binning, skipping */
+ if (ret = 0)
+ ret = reg_write(client, MT9T031_COLUMN_ADDRESS_MODE,
+ ((xbin - 1) 4) | (xskip - 1));
+ if (ret = 0)
+ ret = reg_write(client, MT9T031_ROW_ADDRESS_MODE,
+ ((ybin - 1) 4) | (yskip - 1));
dev_dbg(client-dev, new physical left %u, top %u\n,
rect-left, rect-top);
--
1.6.3.3
--
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 5/6] mx31moboard: camera support
Guennadi Liakhovetski wrote: On Tue, 3 Nov 2009, Valentin Longchamp wrote: Hi Guennadi, Valentin Longchamp wrote: Guennadi Liakhovetski wrote: 3. to support switching inputs, significant modifications to soc_camera.c would be required. I read Nate's argument before, that as long as clients can only be accessed one at a time, this should be presented by multiple inputs rather than multiple device nodes. Somebody else from the V4L folk has also confirmed this opinion. In principle I don't feel strongly either way. But currently soc-camera uses a one i2c client to one device node model, and I'm somewhat reluctant to change this before we're done with the v4l2-subdev conversion. Sure, one step at a time. So for now the switching is not possible with soc_camera. My problem is that both cameras have the same I2C address since they are the same. Would I need to declare 2 i2c_device with the same address (I'm not sure it would even work ...) used by two _client_ platform_devices or would I have to have the two platform devices pointing to the same i2c_device ? I've finally had time to test all this. My current problem with registering the two cameras is that they both have the same i2c address, and soc_camera calls v4l2_i2c_new_subdev_board where in my case the same address on the same i2c tries to be registered and of course fails. We would need a way in soc_camera not to register a new i2c client for device but use an existing one (but that's what you don't want to change for now as you state it in your above last sentence). I just want to point this out once more so that you know there is interest about this for the next soc_camera works. These are two separate issues: inability to work with two devices with the same i2c address, and arguably suboptimal choice of the way to switch between multiple mutually-exclusive clients (sensors) on a single interface. For multiple chips with the same adderess, in principle you could register one or more video devices yet before registering respective i2c devices. And then on the selected switching operation (either opening of one of the /dev/video* nodes, or selecting an input) you register the i2c device, probe it, etc. This would work, but looks seriously overengineered to me. And it would indeed require pretty fundamental changes to the soc-camera core. Yeah I had noticed that this was possible by not calling i2c_register_device (or some like that) is soc_camera.c and give the i2c device directly to the soc_camera client device init method, but since this requires changes in the soc_camera core code that you are currently heavily modifying, I did not find it usefull. Otherwise we could push this switching down into the driver / platform. We could just export only one camera from the platform code, implement a S_INPUT method in soc-camera, that would be delivered to the sensor driver, it would save context of the current sensor, call the platform hook to switch to another camera, and restore its configuration. In this case the soc-camera core and the host driver would not see two sensors, but just one, all the switching would be done internally in the sensor driver / platform callback. If we also decide to use S_INPUT to switch between different sensors on an interface, we would have to make a distinction between two cases in the core - whether the input we're switching to belongs to the same sensor or to another one. Leaving the the camera switch to platform code looks very important to me. Having only one camera exported looks fine to me, especially since I have both cameras the same (but I don't think it would be possible with two different sensors ?). But I don't know v4l2 API well enough to see when it would be used to switch to an input on the same physical sensor. So my current solution for mainline inclusion is to register only one camera device node without taking care of the cam mux for now. Yes, please, send me an updated version of the patch. I think, you haven't done that yet, right? I have the updated version, I have however forgotten to add you in the recipient list, have a look on the arm-mailing-list: http://article.gmane.org/gmane.linux.ports.arm.kernel/68123 Thanks for all your comments Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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 5/6] mx31moboard: camera support
Hi Guennadi, Valentin Longchamp wrote: Guennadi Liakhovetski wrote: 3. to support switching inputs, significant modifications to soc_camera.c would be required. I read Nate's argument before, that as long as clients can only be accessed one at a time, this should be presented by multiple inputs rather than multiple device nodes. Somebody else from the V4L folk has also confirmed this opinion. In principle I don't feel strongly either way. But currently soc-camera uses a one i2c client to one device node model, and I'm somewhat reluctant to change this before we're done with the v4l2-subdev conversion. Sure, one step at a time. So for now the switching is not possible with soc_camera. My problem is that both cameras have the same I2C address since they are the same. Would I need to declare 2 i2c_device with the same address (I'm not sure it would even work ...) used by two _client_ platform_devices or would I have to have the two platform devices pointing to the same i2c_device ? I've finally had time to test all this. My current problem with registering the two cameras is that they both have the same i2c address, and soc_camera calls v4l2_i2c_new_subdev_board where in my case the same address on the same i2c tries to be registered and of course fails. We would need a way in soc_camera not to register a new i2c client for device but use an existing one (but that's what you don't want to change for now as you state it in your above last sentence). I just want to point this out once more so that you know there is interest about this for the next soc_camera works. So my current solution for mainline inclusion is to register only one camera device node without taking care of the cam mux for now. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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 5/6] mx31moboard: camera support
Guennadi Liakhovetski wrote: On Wed, 21 Oct 2009, Valentin Longchamp wrote: Sascha Hauer wrote: On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote: Hi Guennadi, Guennadi Liakhovetski wrote: Hi On Thu, 15 Oct 2009, Valentin Longchamp wrote: We have two mt9t031 cameras that have a muxed bus on the robot. We can control which one we are using with gpio outputs. This currently is not optimal So, what prevents you from registering two platform devices for your two cameras? Is there a problem with that? The lack of time until now to do it properly. I sent those patches as initial RFC (and by the way thanks for your comment). I would like to have one video interface only and that I can switch between the two physical camera using a quite simple system call. Would that be compatible with registering the two platform devices ? Wouldn't it be better to have /dev/video[01] for two cameras? How do keep the registers synchron between both cameras otherwise? Well, from my experimentations, most initializations are done when you open the device. So if you close the device, switch camera and open it again, the registers are initialized with the need values. Of course there is a problem is you switch camera while the device is open. It could be ok with /dev/video[01], but I would need something that would prevent one device to be opened when the other already is open (a mutex, but where ?). Besides, I have read a slide from Dongsoo Kim (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFiledo=gettarget=Framework_for_digital_camera_in_linux-in_detail.ppt slides 41-47) and the cleanest solution would be to have the two chips enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call to switch from one device to each other ? How to link it with the kernel code that make the real hardware switching ? Ok, I don't have a definite answer to this, so, just my thoughts: 1. soc-camera currently registers one struct v4l2_device device per _host_ immediately upon its registration, and one struct video_device per _client_ platform device. Ok understood. 2. we currently have 1 or 2 boards in the mainline with two video client devices on one interface: arch/sh/boards/mach-migor/ and (unsure about) arch/sh/boards/board-ap325rxa.c. At least the first of them exports two platform devices and thus gets /dev/video[01]. Accesses are synchronised with a mutex (I don't actually like that, I'd prefer to get a -EBUSY back instead of hanging in D in open()), and a successful acquisition of the mutex switches the respective camera on. See code for details. So, this approach is supported and it works. In this case we have one v4l2_device and two video_device instances, don't know whether this matches how this is supposed to be done, but it works so far:-) I am going to stick to this approach since it works now. This would allow me to have code that could go now into mainline. 3. to support switching inputs, significant modifications to soc_camera.c would be required. I read Nate's argument before, that as long as clients can only be accessed one at a time, this should be presented by multiple inputs rather than multiple device nodes. Somebody else from the V4L folk has also confirmed this opinion. In principle I don't feel strongly either way. But currently soc-camera uses a one i2c client to one device node model, and I'm somewhat reluctant to change this before we're done with the v4l2-subdev conversion. Sure, one step at a time. So for now the switching is not possible with soc_camera. My problem is that both cameras have the same I2C address since they are the same. Would I need to declare 2 i2c_device with the same address (I'm not sure it would even work ...) used by two _client_ platform_devices or would I have to have the two platform devices pointing to the same i2c_device ? Thanks Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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 5/6] mx31moboard: camera support
Sascha Hauer wrote: On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote: Hi Guennadi, Guennadi Liakhovetski wrote: Hi On Thu, 15 Oct 2009, Valentin Longchamp wrote: We have two mt9t031 cameras that have a muxed bus on the robot. We can control which one we are using with gpio outputs. This currently is not optimal So, what prevents you from registering two platform devices for your two cameras? Is there a problem with that? The lack of time until now to do it properly. I sent those patches as initial RFC (and by the way thanks for your comment). I would like to have one video interface only and that I can switch between the two physical camera using a quite simple system call. Would that be compatible with registering the two platform devices ? Wouldn't it be better to have /dev/video[01] for two cameras? How do keep the registers synchron between both cameras otherwise? Well, from my experimentations, most initializations are done when you open the device. So if you close the device, switch camera and open it again, the registers are initialized with the need values. Of course there is a problem is you switch camera while the device is open. It could be ok with /dev/video[01], but I would need something that would prevent one device to be opened when the other already is open (a mutex, but where ?). Besides, I have read a slide from Dongsoo Kim (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFiledo=gettarget=Framework_for_digital_camera_in_linux-in_detail.ppt slides 41-47) and the cleanest solution would be to have the two chips enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call to switch from one device to each other ? How to link it with the kernel code that make the real hardware switching ? Thanks for your inputs. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] soc-camera: cleanup + scaling / cropping API fix
Guennadi Liakhovetski wrote: On Thu, 30 Jul 2009, Valentin Longchamp wrote: Hi Guennadi, Guennadi Liakhovetski wrote: Hi all here goes a new iteration of the soc-camera scaling / cropping API compliance fix. In fact, this is only the first _complete_ one, the previous version only converted one platform - i.MX31 and one camera driver - MT9T031. This patch converts all soc-camera drivers. The most difficult one is the SuperH driver, since it is currently the only host driver implementing own scaling and cropping on top of those of sensor drivers. The first three patches in the series are purely cosmetic, unifying device objects, used in dev_dbg, dev_info... functions. These patches extend the patch series uploaded at http://download.open-technology.de/soc-camera/20090701/ with the actual scaling / cropping patch still in http://download.open-technology.de/testing/. The series is still based on the git://git.pengutronix.de/git/imx/linux-2.6.git (now gone) for-rmk branch, but the i.MX31 patches, that my patch-series depends on, are now in the mainline, so, I will be rebasing the stack soon. In the meantime, I'm afraid, it might require some fiddling to test the stack. I'd love to give your patches a try. But the fiddling looks very hard for me ... patch 0010 does not apply correctly for me, and a 130K patch to do by hand is .. long. Ok, a rebased patch set is under http://download.open-technology.de/soc-camera/20090730/ now based on 2.6.31-rc4. Notice, all patches are now in the above directory, .../testing is empty again. Thanks a lot Guennadi, I should come back with some feedback soon. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] soc-camera: cleanup + scaling / cropping API fix
Hi Guennadi, Guennadi Liakhovetski wrote: Hi all here goes a new iteration of the soc-camera scaling / cropping API compliance fix. In fact, this is only the first _complete_ one, the previous version only converted one platform - i.MX31 and one camera driver - MT9T031. This patch converts all soc-camera drivers. The most difficult one is the SuperH driver, since it is currently the only host driver implementing own scaling and cropping on top of those of sensor drivers. The first three patches in the series are purely cosmetic, unifying device objects, used in dev_dbg, dev_info... functions. These patches extend the patch series uploaded at http://download.open-technology.de/soc-camera/20090701/ with the actual scaling / cropping patch still in http://download.open-technology.de/testing/. The series is still based on the git://git.pengutronix.de/git/imx/linux-2.6.git (now gone) for-rmk branch, but the i.MX31 patches, that my patch-series depends on, are now in the mainline, so, I will be rebasing the stack soon. In the meantime, I'm afraid, it might require some fiddling to test the stack. I'd love to give your patches a try. But the fiddling looks very hard for me ... patch 0010 does not apply correctly for me, and a 130K patch to do by hand is .. long. If someone could tell me how to get out of that hell, I could give it a try, otherwise, I will have to wait for a rebase (I'm using Sascha's mxc-master branch, currently based on 2.6.31-rc2): fatal: sha1 information is lacking or useless (drivers/media/video/mt9m001.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Thanks Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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 RFC] fix cropping and scaling for mx3-camera and mt9t031 drivers
soc_camera_device *icd, struct v4l2_crop *a)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ return v4l2_subdev_call(sd, video, s_crop, a);
+}
+
int soc_camera_host_register(struct soc_camera_host *ici)
{
struct soc_camera_host *ix;
@@ -1113,7 +1115,6 @@ int soc_camera_host_register(struct soc_camera_host *ici)
if (!ici || !ici-ops ||
!ici-ops-try_fmt ||
!ici-ops-set_fmt ||
- !ici-ops-set_crop ||
!ici-ops-set_bus_param ||
!ici-ops-querycap ||
!ici-ops-init_videobuf ||
@@ -1124,6 +1125,13 @@ int soc_camera_host_register(struct soc_camera_host *ici)
!ici-v4l2_dev.dev)
return -EINVAL;
+ if (!ici-ops-set_crop)
+ ici-ops-set_crop = default_s_crop;
+ if (!ici-ops-get_crop)
+ ici-ops-get_crop = default_g_crop;
+ if (!ici-ops-cropcap)
+ ici-ops-cropcap = default_cropcap;
+
mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
if (ix-nr == ici-nr) {
@@ -1323,6 +1331,9 @@ static int __devinit soc_camera_pdrv_probe(struct
platform_device *pdev)
if (ret 0)
goto escdevreg;
+ icd-user_width = DEFAULT_WIDTH;
+ icd-user_height= DEFAULT_HEIGHT;
+
return 0;
escdevreg:
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 344d899..cbd6654 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -22,8 +22,8 @@ struct soc_camera_device {
struct list_head list;
struct device dev;
struct device *pdev;/* Platform device */
- struct v4l2_rect rect_current; /* Current window */
- struct v4l2_rect rect_max; /* Maximum window */
+ s32 user_width;
+ s32 user_height;
unsigned short width_min;
unsigned short height_min;
unsigned short y_skip_top; /* Lines to skip at the top */
@@ -76,6 +76,8 @@ struct soc_camera_host_ops {
int (*get_formats)(struct soc_camera_device *, int,
struct soc_camera_format_xlate *);
void (*put_formats)(struct soc_camera_device *);
+ int (*cropcap)(struct soc_camera_device *, struct v4l2_cropcap *);
+ int (*get_crop)(struct soc_camera_device *, struct v4l2_crop *);
int (*set_crop)(struct soc_camera_device *, struct v4l2_crop *);
int (*set_fmt)(struct soc_camera_device *, struct v4l2_format *);
int (*try_fmt)(struct soc_camera_device *, struct v4l2_format *);
@@ -277,6 +279,21 @@ static inline unsigned long
soc_camera_bus_param_compatible(
common_flags;
}
+static inline void soc_camera_limit_side(unsigned int *start,
+ unsigned int *length, unsigned int start_min,
+ unsigned int length_min, unsigned int length_max)
+{
+ if (*length length_min)
+ *length = length_min;
+ else if (*length length_max)
+ *length = length_max;
+
+ if (*start start_min)
+ *start = start_min;
+ else if (*start + *length start_min + length_max)
+ *start = start_min + length_max - *length;
+}
+
extern unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
unsigned long flags);
--
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longch...@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne
--
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
mx31moboard MT9T031 camera support
Hi Guennadi, I am trying to follow your developments at porting soc-camera to v4l2-subdev. However, even if I understand quite correctly soc-camera, it is quite difficult for me to get all the subtleties in your work. That's why I am asking you for a little help: when do you think would be the best timing for me to add the mt9t031 camera support for mx31moboard within your current process ? I guess it should not be too difficult, I had done it before, and I can base myself on what you have done for pcm037: http://download.open-technology.de/soc-camera/20090617/0025-pcm037-add-MT9T031-camera-support.patch Now I have a second question. On our robot, we physically have two cameras (one looking to the front and one looking at a mirror) connected to the i.MX31 physical bus. We have one signal that allows us to control the multiplexer for the bus lines (video signals and I2C) through a GPIO. This now works with a single camera declared in software and choices to the multiplexer done when no image transfer is happening ( /dev/video is not open). What do you think should be the correct way of dealing with these two cameras with the current driver implementation (should I continue to declare only one camera in the software) ? And do you think it could be possible to hot-switch from one camera to the other ? My colleagues ask about it, I tell them that from my point of view this seems not possible without changing the drivers, and even the drivers would have to be changed quite heavily and it is not trivial. Best Regards Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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: mx31moboard MT9T031 camera support
Guennadi Liakhovetski wrote: On Thu, 18 Jun 2009, Valentin Longchamp wrote: Hi Guennadi, I am trying to follow your developments at porting soc-camera to v4l2-subdev. However, even if I understand quite correctly soc-camera, it is quite difficult for me to get all the subtleties in your work. That's why I am asking you for a little help: when do you think would be the best timing for me to add the mt9t031 camera support for mx31moboard within your current process ? You can do this now, based either on the v4l tree, or wait for Linus to pull it - a pull request has been sent ba Mauro yesterday, looks like Linus hasn't pulled yet. The way you add your platform is going to change, and the pull, that I'm referring to above makes it possible for both old style and new style board camera data to work. Of course, it would be best for you to implement the new style platform data. You can do this by either looking at my patches, which I've posted to the lists earlier, and which are also included in my patch stack, which I announced yesterday. Or you can wait a bit until I update my pcm037 patch (going to do this now) and post it to arm-kernel. I'll (try not to forget to) add you to cc, that should be quite easy to follow for you. I guess it should not be too difficult, I had done it before, and I can base myself on what you have done for pcm037: http://download.open-technology.de/soc-camera/20090617/0025-pcm037-add-MT9T031-camera-support.patch Yes, use this or wait a bit for an updated version. OK, thanks a lot. Since I am busy at other things at the moment, I am going to wait for you updated version and that things are stabilized a little bit with the 31-rc1. And I will use the new style platform data. Now I have a second question. On our robot, we physically have two cameras (one looking to the front and one looking at a mirror) connected to the i.MX31 physical bus. We have one signal that allows us to control the multiplexer for the bus lines (video signals and I2C) through a GPIO. This now works with a single camera declared in software and choices to the multiplexer done when no image transfer is happening ( /dev/video is not open). What do you think should be the correct way of dealing with these two cameras with the current driver implementation (should I continue to declare only one camera in the software) ? And do you think it could be possible to hot-switch from one camera to the other ? My colleagues ask about it, I tell them that from my point of view this seems not possible without changing the drivers, and even the drivers would have to be changed quite heavily and it is not trivial. Do the cameras use different i2c addresses? If they use the same address I don't think you'd be able to register them simultaneously. If they do use different addresses, you can register both of them and use platform .power() callback to switch between them using your multiplexer. See arch/sh/boards/mach-migor/setup.c for an example. There was also a proposal to use switching input to select a data source, but this is currently unsupported by soc-camera. The sensor chips both are mt9t031 so they have the same i2c address (I have looked at the datasheet, and I don't think this can be changed). So I cannot use them both at the same time. Now you talk about the .power() callback, I could use it so that the multiplexer is managed by it, using a similar mechanism as in mach-migor. If this could allow me one different /dev/video nod for each camera (that of course cannot be used at the same time), it would simplify a lot of things for my users. I will give it a try (hoping that this also works at driver registering ... we will see). Thanks for your answers. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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: i.MX31 Camera Sensor Interface support
Hi Guennadi, Valentin Longchamp wrote: Hi Guennadi, Guennadi Liakhovetski wrote: I uploaded my current patch-stack for the i.MX31 Camera Sensor Interface to http://gross-embedded.homelinux.org/~lyakh/i.MX31-20090124/ (to be submitted later, hopefully for 2.6.30). As stated in -base-unknown, these patches shall be used on top of the git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git tree upstream branch. I have tested your patchset on our mx31moboard system. However, I would like some precisions on how things should be registered. I am now able to register a camera device on the soc_camera bus with mx3_camera, I had not initialized well the bus_id for my platform device. After struggling with a few minor hardware bugs, I am now able to register a MT9T031 camera (actually we have a MT9T001 for testing, but they are very similar). So things seem to be working fine. I am testing it with the capture.c example from v4linux. But the mt9t031 only supports bayer format atm (I could try to work on it, but first I need to validate our hardware design by grabbing real images), could someone point me to an easy way of converting this bayer format to something readable (maybe a raw image for gimp, that's what I am trying to do now) ? By the way, Guennadi, if you want me to test something more extensively, don't hesitate to ask me about it. Thanks again for your patch. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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
