[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

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.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne