On Monday 17 August 2009 12:09:12 Guennadi Liakhovetski wrote: > Hi Hans, all > > In soc-camera since its first version we have a parameter "y_skip_top", > which the sensor uses to tell the host (bridge) driver "I am sending you > that many lines more than what is requested, and you should drop those > lines from the top of the image." I never investigated this in detail, > originally this was a "strong tip" that the top line is always corrupted. > Now I did investigate it a bit by setting this parameter to 0 and looking > what the sensors actually produce. I am working with four sensor: mt9m001, > mt9v022, mt9t031 and ov7725, of which only the first two had that > parameter set to 1 from the beginning, the others didn't have it and also > showed no signs of a problem. mt9m001 (monochrome) doesn't have the > problem either, but mt9v022 does. It does indeed deliver the first line > with "randomly" coloured pixels. Notice - this is not the top line of the > sensor, this is the first read-out line, independent of the cropping > position. So, it seems we do indeed need a way to handle such sensors. Do > you have a suggestion for a meaningful v4l2-subdev API for this? Hmm, I think that the best way is to make a struct v4l2_subdev_sensor_ops, move the enum_framesizes/intervals from the video_ops to the sensor_ops (since these are only used by sensors AFAIK), and add a new op to sensor_ops: int (*skip_top_lines)(struct v4l2_subdev *sd, u32 *lines). When we add the op to set the bus_params, then that can be added to sensor_ops as well. I've always thought that we need sensor-specifc ops eventually and this is a good reason to do so. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
