On Fri, 1 Jan 2016, Guennadi Liakhovetski wrote: > Hi Laurent, > > On Sun, 27 Dec 2015, Laurent Pinchart wrote: > > > Hi Guennadi, > > > > On Thursday 24 December 2015 11:42:49 Guennadi Liakhovetski wrote: > > > Hi Laurent, > > > > > > Let me put this at the top: So far it looks like we converge on two > > > possibilities: > > > > > > (1) a separate video-device node with a separate queue. No user-space > > > visible changes are required apart from new FOURCC codes. In the kernel > > > we'd have to add some subdev API between the bridge and the sensor drivers > > > to let the sensor driver instruct the bridge driver to use some of the > > > data, arriving over the camera interface, as metadata. > > > > The interface should be more generic and allow describing how multiple > > channels (in terms of virtual channels and data types for CSI-2 for instance) > > are multiplexed over a single physical link. I'm not sure how to represent > > that at the media controller level, that's also one topic that needs to be > > researched. > > Sure, agree. How about an enumetation style method, something like > .enum_mbus_streams()? It now also occurs to me, that we currently configure pads with a single configuration - pixel format, resolution. However, a single CSI-2 interface can transfer different frame formats at the same time. So, such a sensor driver has to export multiple source pads? The bridge driver would export multiple sink pads, then we don't need any new API methods, we just configure each link separately, for which we have to add those fields to struct v4l2_mbus_framefmt? Thanks Guennadi -- 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
