Hi all, On 28/03/2019 22:05, Jacopo Mondi wrote: > Hello, > new iteration of multiplexed stream support patch series. > > V3 available at: > https://patchwork.kernel.org/cover/10839889/ > > V2 sent by Niklas is available at: > https://patchwork.kernel.org/cover/10573817/ > > Series available at: > git://jmondi.org/linux v4l2-mux/media-master/v4 I'm trying to understand how these changes can be used with virtual channels and also with embedded data. I have an SoC with two CSI-2 RX ports, both of which connect to a processing block with 8 DMA engines. Each of the DMA engines can be programmed to handle a certain virtual channel and datatype. The board has a multiplexer, connected to 4 cameras, and the multiplexer connects to SoC's CSI-2 RX port. This board has just one multiplexer connected, but, of course, both RX ports could have a multiplexer, amounting to total 8 cameras. So, in theory, there could be 16 streams to be handled (4 pixel streams and 4 embedded data streams for both RX ports). With only 8 DMA engines available, the driver has to manage them dynamically, reserving a DMA engine when a stream is started. My confusion is with the /dev/video nodes. I think it would be logical to create 8 of them, one for each DMA engine (or less, if I know there is only, say, 1 camera connected, in which case 2 nodes would be enough). But in that case how does the user know what data is being received from that node? In other words, how to connect, say, /dev/video0 to second camera's embedded data stream? Another option would be to create 16 /dev/video nodes, and document that first one maps to virtual channel 0 + pixel data, second to virtual channel 0 + embedded data, and so on. And only allow 8 of them to be turned on at a time. But I don't like this idea much. The current driver architecture is such that the multiplexer is modeled with a subdev with 4 sink pads and one source pad, the SoC's RX ports are subdevs with a single sink and a single output pad, and then there are the video devices connected to RX's source pad. And while I can connect the video node's pad to the source pad on either of the RX ports, I don't think I have any way to define which stream it receives. Does that mean that each RX port subdev should instead have 8 source pads? Isn't a pad like a physical connection? There's really just one output from the RX port, with multiplexed streams, so 8 pads doesn't sound right. Tomi
