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.longch...@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
