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
next prev parent reply other threads:[~2009-11-03 11:31 UTC|newest]
Thread overview: 24+ 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-23 23:45 ` Guennadi Liakhovetski
2009-10-28 14:32 ` Valentin Longchamp
2009-11-03 11:31 ` Valentin Longchamp [this message]
2009-11-04 18:22 ` Guennadi Liakhovetski
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).