On Tue, 3 Nov 2009, Valentin Longchamp wrote:

Hi Guennadi,

Valentin Longchamp wrote:

quoted

Guennadi Liakhovetski wrote:

quoted

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.

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.

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?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/