On 08/17/2011 07:43 PM, Guennadi Liakhovetski wrote: > On Wed, 17 Aug 2011, Sakari Ailus wrote: >> On Thu, Jul 28, 2011 at 07:04:11PM +0200, Sylwester Nawrocki wrote: ... >>> In order to let the host drivers query or configure subdevs with required >>> frame buffer size one of the following changes could be done at V4L2 API: >>> >>> 1. Add a 'sizeimage' field in struct v4l2_mbus_framefmt and make subdev >>> drivers optionally set/adjust it when setting or getting the format with >>> set_fmt/get_fmt pad level ops (and s/g_mbus_fmt ?) >>> There could be two situations: >>> - effective required frame buffer size is specified by the sensor and the >>> host driver relies on that value when allocating a buffer; >>> - the host driver forces some arbitrary buffer size and the sensor performs >>> any required action to limit transmitted amount of data to that amount >>> of data; >>> Both cases could be covered similarly as it's done with VIDIOC_S_FMT. >>> >>> Introducing 'sizeimage' field is making the media bus format struct looking >>> more similar to struct v4l2_pix_format and not quite in line with media bus >>> format meaning, i.e. describing data on a physical bus, not in the memory. >>> The other option I can think of is to create separate subdev video ops. >>> 2. Add new s/g_sizeimage subdev video operations ... >> I prefer this second approach over the first once since the maxiumu size of >> the image in bytes really isn't a property of the bus. > > Call that field framesamples and already it fits quite well with the > notion of data on the bus and not in memory. Wouldn't this work? Hmm...that might be exactly what we need. That was also an initial Hans' proposal when we recently discussed it. At least such an information should be sufficient for handling JPEG, where the effective buffer size might be calculated from a media bus pixel code and a number of samples per frame. -- Regards, Sylwester -- 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
