From: valentin.longchamp@epfl.ch (Valentin Longchamp)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] mx31moboard: camera support
Date: Tue, 03 Nov 2009 12:31:01 +0100 [thread overview]
Message-ID: <4AF01475.1010704@epfl.ch> (raw)
In-Reply-To: <4AE855E4.1040705@epfl.ch>
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.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne
WARNING: multiple messages have this Message-ID (diff)
From: Valentin Longchamp <valentin.longchamp@epfl.ch>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 5/6] mx31moboard: camera support
Date: Tue, 03 Nov 2009 12:31:01 +0100 [thread overview]
Message-ID: <4AF01475.1010704@epfl.ch> (raw)
In-Reply-To: <4AE855E4.1040705@epfl.ch>
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.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne
next prev parent reply other threads:[~2009-11-03 11:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 9:42 [RFC] mx31moboard: patches for next merge window Valentin Longchamp
2009-10-15 9:42 ` [PATCH 1/6] mx31: various pins used for mx31moboard Valentin Longchamp
2009-10-15 9:42 ` [PATCH 2/6] mx31moboard: serial port fix Valentin Longchamp
2009-10-15 9:42 ` [PATCH 3/6] mx31moboard: support for pin linked for battery presence check Valentin Longchamp
2009-10-15 9:42 ` [PATCH 4/6] mx31moboard: initialize ipu device for all the boards Valentin Longchamp
2009-10-15 9:42 ` [PATCH 5/6] mx31moboard: camera support Valentin Longchamp
2009-10-15 9:43 ` [PATCH 6/6] mx31moboard: SPI and MC13783 votage regulator support Valentin Longchamp
2009-10-16 8:18 ` Uwe Kleine-König
2009-10-16 18:35 ` [PATCH 5/6] mx31moboard: camera support Russell King - ARM Linux
2009-10-16 21:09 ` Guennadi Liakhovetski
2009-10-19 16:41 ` Valentin Longchamp
2009-10-20 8:09 ` Sascha Hauer
2009-10-21 17:11 ` Valentin Longchamp
2009-10-21 17:11 ` Valentin Longchamp
2009-10-23 23:45 ` Guennadi Liakhovetski
2009-10-23 23:45 ` Guennadi Liakhovetski
2009-10-28 14:32 ` Valentin Longchamp
2009-10-28 14:32 ` Valentin Longchamp
2009-11-03 11:31 ` Valentin Longchamp [this message]
2009-11-03 11:31 ` Valentin Longchamp
2009-11-04 18:22 ` Guennadi Liakhovetski
2009-11-04 18:22 ` Guennadi Liakhovetski
2009-11-04 21:37 ` Valentin Longchamp
2009-11-04 21:37 ` Valentin Longchamp
2009-10-23 22:56 ` Guennadi Liakhovetski
2009-10-28 14:36 ` Valentin Longchamp
2009-10-15 22:14 ` [RFC] mx31moboard: patches for next merge window Sascha Hauer
2009-10-16 8:17 ` Uwe Kleine-König
2009-10-16 9:02 ` Valentin Longchamp
2009-10-24 8:25 ` Uwe Kleine-König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AF01475.1010704@epfl.ch \
--to=valentin.longchamp@epfl.ch \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.