Hello Hans, Laurent, Sakari, On Fri, Jan 19, 2018 at 02:23:21PM +0200, Laurent Pinchart wrote: > 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? Does it make any difference if I point out that this series hasn't removed any of that code, and the driver was not supporting that already? Or was it handled through soc_camera? > > > > 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 ? > -If- I have to implement that in this series to have it accepted, please let me know which one of the two is the preferred one :) Thanks j > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
