Hi! > > I agree, yes. I think the only way to solve this is to have a generic > > EEPROM API that allows the camera sensor to read data from it. If > > We have one already, and it's defined in Documentation/misc-devices/eeprom . > > > another vendor uses a different type of EEPROM, the sensor driver would > > remain the same, as it only reads data from the storage behind the > > phandle, not caring about the details. > > > > Same goes for the lens driver, and after thinking about it for awhile, > > I'd say it makes most sense to allow referencing a v4l2_subdev device > > through a phandle from another v4l2_subdev, and then offload certain > > commands such as V4L2_CID_FOCUS_ABSOLUTE to the device that does the > > actual work. Opinions? > > There are different kinds of lens systems and I don't think the sensor > drivers should be aware of them. The current approach is that the lens is a > separate sub-device --- the intent of the patchset I posted was to document > how the information on the related lens and eeprom components is conveyed to > the software. There's one such driver in the mainline kernel, ad5820. > > Unfortunately we don't right now have a good user space interface for > telling which sensor a lens device is related to. The struct > media_entity_desc does have a group_id field for grouping the sub-devices > but that's hardly a good way to describe this. Yeah, it would be good to get the corresponding patches to be merged to v4l-utils... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
