Hi Jacopo, I promised to write a bit about the routing problem I attempted to write on #v4l. It's a bit late, but here it is. Let me know if you share my understanding (and especially do so if you don't :)). A route is identified by the source and sink pads as well as the stream ID on the source and the sink pads. Its flags allow enabling or disabling a route. Most devices that function as transmitters (such as sensors) have a fixed number of routes they can support. These's no need to change them; enabling and disabling them will be enough for the user. For receivers this is different. What needs to be supported on the receiver side is directing any incoming stream (a 32-bit unsigned integer) to any source pad. This is because pads are not alike --- one may be connected to a block that further processes the image whereas the others may be connected to a DMA engine, just writing the data to memory. The receivers also may not make assumptions beyond the sub-device API: the stream is a 32-bit unsigned integer, there is currently no API requirement to have the stream IDs on a particular low integer range. In principle we could define that range, but I'd rather try to find better solutions than that: it's hard to come up with a number as it depends on the hardware. Some kind of an upper limit could be the number of CSI-2 channels multiplied by CSI-2 data types. That would be enough for CSI-2. 16 or 32 virtual channels and up to 64 data types would mean up to 2048 routes between a demultiplexer's sink pad and *each* of its source pads. And this comes with an assumption that the source pads only support a single stream... CSI-2 receivers support a number of simultaneous streams, and as the stream is demultiplexed there, this means there will be as many source pads as there are supported simultaneous streams. This heavily depends on the hardware, but the number could be e.g. 1, 4 or 8. Much smaller than 2048 in any case. Another option could be creating no routes at all at device init time, and letting the user create them. We could add a new flag for routes telling that a route is dynamic: disabling a dynamic route would simply delete it. Likewise, a SUBDEV_G_ROUTING returning no routes (but no error either) would also tell the user only dynamic routes are supported. We should document this and change the driver implementation accordingly. No API changes are needed (apart from adding the dynamic flag --- or rather call it "volatile", to avoid confusing with routes that can be enabled or disabled while streaming). -- Best regards, Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxx
