Re: [PATCH v7 00/27] v4l: subdev internal routing and streams

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

On 24/05/2021 13:43, Tomi Valkeinen wrote:
> Hi,
> 
> This is v7 of the series, the previous one is:
> 
> https://lore.kernel.org/linux-media/20210427124523.990938-1-tomi.valkeinen@ideasonboard.com/
> 
> In this version I have changed the approach to multiplexed streams, and
> I went with the approach described in the RFC I sent:
> 
> https://lore.kernel.org/linux-media/20210507123558.146948-1-tomi.valkeinen@ideasonboard.com/
> 
> The main change is that in this series each pad+stream combination can
> have its own configuration, versus only pad having its own
> configuration. In other words, a pad with 4 streams will contain 4
> configurations.
> 
> The patches up to and including "v4l: Add stream to frame descriptor"
> are the same as previously, except changes done according to the review
> comments. After that, the new pad+stream approach is implemented.
> 
> This series is based on the subdev-wide state change:
> 
> https://lore.kernel.org/linux-media/20210519091558.562318-1-tomi.valkeinen@ideasonboard.com/

While working on a few prototype bridge and sensor drivers I realized 
that I had been missing one thing here. So far I had always used "stream 
pipelines" which start from the sensor and go to the capture device with 
1-to-1 routes. But I have a bridge which can "split" the input stream 
into two streams, which didn't work with the approach in this series.

The change was a very minor one, essentially just allowing a routing 
table like this:

(0, 0) -> (4, 0)
(0, 0) -> (4, 1)

In other words, stream 0 from pad 0 goes to pad 4 as both stream 0 and 
stream 1. What exactly that means is of course device specific. In my 
case it means that the bridge takes a full frame as input, but outputs 3 
first lines tagged with CSI-2 metadata datatype, and the rest of the 
frame as CSI-2 pixel data.

  Tomi