Hello, On Friday, 19 January 2018 13:19:18 EET Sakari Ailus wrote: > On Fri, Jan 19, 2018 at 11:47:33AM +0100, Hans Verkuil wrote: > > On 01/19/18 11:24, Hans Verkuil wrote: > >> On 01/16/18 22:44, Jacopo Mondi wrote: > >>> Remove soc_camera framework dependencies from ov772x sensor driver. > >>> - Handle clock and gpios > >>> - Register async subdevice > >>> - Remove soc_camera specific g/s_mbus_config operations > >>> - Change image format colorspace from JPEG to SRGB as the two use the > >>> same colorspace information but JPEG makes assumptions on color > >>> components quantization that do not apply to the sensor > >>> - Remove sizes crop from get_selection as driver can't scale > >>> - Add kernel doc to driver interface header file > >>> - Adjust build system > >>> > >>> This commit does not remove the original soc_camera based driver as > >>> long as other platforms depends on soc_camera-based CEU driver. > >>> > >>> Signed-off-by: Jacopo Mondi <jacopo+renesas@xxxxxxxxxx> > >>> Reviewed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > >> > >> Acked-by: Hans Verkuil <hans.verkuil@xxxxxxxxx> > > > > Un-acked. > > > > I just noticed that this sensor driver has no enum_frame_interval and > > g/s_parm support. How would a driver ever know the frame rate of the > > sensor without that? > > s/_parm/_frame_interval/ ? > > We should have wrappers for this or rather to convert g/s_parm users to > g/s_frame_interval so drivers don't need to implement both. There are two ways to set the frame interval, either explicitly through the s_frame_interval operation, or implicitly through control of the pixel clock, horizontal blanking and vertical blanking (which in turn can be influenced by the exposure time). Having two ways to perform the same operation seems sub-optimal to me, but I could understand if they covered different use cases. As far as I know we don't document the use cases for those methods. What's your opinion on that ? -- Regards, Laurent Pinchart
