- The Frame Interval Monitor could be exported to v4l2-core for general use. - The CSI subdevice parses its nearest upstream neighbor's device-tree bus config in order to setup the CSI. Laurent Pinchart argues that instead the CSI subdev should call its neighbor's g_mbus_config op (which should be propagated if necessary) to get this info. However Hans Verkuil is planning to remove the g_mbus_config op. For now this driver uses the parsed DT bus config method until this issue is resolved. - This media driver supports inheriting V4L2 controls to the video capture devices, from the subdevices in the capture device's pipeline. The controls for each capture device are updated in the link_notify callback when the pipeline is modified. It should be decided whether this feature is useful enough to make it generally available by exporting to v4l2-core. - After all async subdevices have been bound, v4l2_fwnode_parse_link() is used to form the media links between the devices discovered in the OF graph. While this approach allows support for arbitrary OF graphs, there are some assumptions for this to work: 1. If a port owned by a device in the graph has endpoint nodes, the port is treated as a media pad. This presents problems for devices that don't make this port = pad assumption. Examples are SMIAPP compatible cameras which define only a single output port node, but which define multiple pads owned by multiple subdevices (pixel-array, binner, scaler). Or video decoders (entity function MEDIA_ENT_F_ATV_DECODER), which also define only a single output port node, but define multiple pads for video, VBI, and audio out. A workaround at present is to set the port reg properties to correspond to the media pad index that the port represents. A possible long-term solution is to implement a subdev API that maps a port id to a media pad index. 2. Every endpoint of a port owned by a device in the graph is treated as a media link. Which means a port must not contain mixed-use endpoints, they must all refer to media links between V4L2 subdevices. - i.MX7: all of the above, since it uses the imx media core - i.MX7: use Frame Interval Monitor - i.MX7: runtime testing with parallel sensor, links setup and streaming - i.MX7: runtime testing with different formats, for the time only 10-bit bayer is tested