Hi Laurent, > -----Original Message----- > From: Laurent Pinchart [mailto:laurent.pinchart@xxxxxxxxxxxxxxxx] > Sent: Thursday, August 26, 2010 10:36 AM > To: Aguirre, Sergio > Cc: linux-media@xxxxxxxxxxxxxxx; Nataraju, Kiran > Subject: Re: [omap3camera] How does a lens subdevice get powered up? > > Hi Sergio, > > On Thursday 26 August 2010 17:33:28 Aguirre, Sergio wrote: > > On Thursday, August 26, 2010 10:04 AM Laurent Pinchart wrote: > > > > > > Even if not part of the image pipeline, the lens controller is still > part > > > of the media device. I think it makes sense to expose it as an entity > and > > > a V4L2 subdevice. > > > > Hmm... I don't know what I was thinking... you're right. :) > > > > Now that I rethink what I just said vs your answer, I think you have a > > point, so I'll drop that thought... > > > > However, I think still there's something that could be done here... > > > > Imagine a scenario in which you have 2 sensors, each one with a > different > > Coil motor driver to control each sensor's lens position. > > > > Should we have a way to register some sort of association between > > Sensor and lens subdevices? That way, by querying the media device, an > app > > can know which lens is associated with what sensor, without any > hardcoding. > > > > That would be very similar to the case in which you would want to > associate > > an audio capturing subdev with a video capturing subdev. They are not > > technically sharing the same data, but they are related. > > > > Is this kind of association considered in the Media Controller framework > > implementation currently? > > It's implemented in the latest media controller RFC :-) > > Entities now have a group ID that the driver can set to report > associations > such as sensor-coil-flash or video-audio. Oh ok, I see. Perfect! Thanks for clarifying that. Regards, Sergio > > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html