rect.height = MT9T031_MAX_HEIGHT;
+ mt9t031->out_width = MT9T031_MAX_WIDTH;
+ mt9t031->out_height = MT9T031_MAX_HEIGHT;
+
/*
* Simulated autoexposure. If enabled, we calculate shutter width
* ourselves in the driver based on vertical blanking and fram
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" i
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
---
drivers/media
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,
};
Thank you in advance for
Kay Sievers wrote:
On Thu, Jan 28, 2010 at 00:25, Valentin Longchamp
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
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
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
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
---
drivers/media/video
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 cl
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 mul
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
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
Hi Guennadi,
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
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
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, Phon
Guennadi Liakhovetski wrote:
On Wed, 1 Jul 2009, Valentin Longchamp wrote:
Guennadi Liakhovetski wrote:
While trying all possible skipping / binning combinations of mt9t031 I
came across a problem, that in some configurations the sensor produces
regular horizontal stripes. They depend on
ry(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
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
e 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
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, hopefull
13:52 subsystem ->
> ../../../bus/platform
> -rw-r--r--1 root root 4096 Oct 16 13:52 uevent
Is all this correct so far, and I would need further declarations in my
platform devices for the things to be registered together ? I have
attached you the file where I do the i
21 matches
Mail list logo
