So... let's see if i got some things right, please let me now if you disagree: - I do want to use the omap34xxcam.c driver as it is for the newest framework and I get most support for it - The camera sensor driver must implement the v4l2-subdev and the new pad-level api. As the register list of mt9t031 and mt9p031 sensors are identical, I could copy the subdev-part. But the existing mt9t031 driver stacks on top of soc_camera. soc_camera creates a v4l2 device. omap34xxcam also creates a v4l2 dev. Obviously they are competing architectures. Guennadi wrote: > There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if > mt9t031 and mt9p031 are indeed similar enough, I think, the right way is > to join efforts to port soc-camera over to the new "pad-level" API and > re-use the driver. This confuses me a bit now. Guennadi, is your idea to update the soc_camera interface for pad-level support and port omap34xxcam to a soc_camera_omap34xxcam? I don't think I am capable of writing a new host bridge driver, so I would prefer touching only the sensor driver part. Or do you think it is better to remove the soc_camera dependency and fit the camera sensor driver to omap34xxcam directly? - If I do the later, I take Laurent's approach and look at his MT9T001 sensor driver for Sakari's omap34xxcam host driver and adapt it for my needs. I can look for more subdev pad-level examples in Vaibhav's repository. So long, thanks for all your help, Bastian -- 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
