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@xxxxxxxxxxxxxxxx/
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@xxxxxxxxxxxxxxxx/
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@xxxxxxxxxxxxxxxx/
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
