On 13/10/2021 10:17, Hans Verkuil wrote:
On 05/10/2021 10:57, Tomi Valkeinen wrote:
Add support to manage configurations (format, crop, compose) per stream,
Isn't that 'pad+stream'? This sentence suggests that 'stream' replaces 'pad',
but it is 'in addition to', right?
To configure a stream, or rather a specific "endpoint" along the stream,
you need the subdev, pad id and stream id. But I don't think we need to
mention subdev+pad+stream every time, as a stream is unique and it
should usually be obvious what is meant.
Then again, "a stream" might mean the whole stream, starting from the
source subdev and going to the final sink subdev. So perhaps we're
missing some vocabulary here.
instead of per pad. This is accomplished with data structures that hold
an array of all subdev's stream configurations.
The number of streams can vary at runtime based on routing. Every time
the routing is changed, the stream configurations need to be
re-initialized.
Is this documented? I can't remember reading this, but I may have missed this.
No, it isn't. I've added some docs now.
And what if the new routing leaves one stream unchanged, and changes a second,
does that still mean that both stream configurations need to be re-initialized,
or just that of the changed stream?
It is the subdev driver that handles this, but I think (and what my
drivers do) all streams for that subdev need to be re-configured.
Preserving (some) configs when setting new routing is possible, but I
think it can be difficult to define exactly how set-route should behave
and we should define the behavior very clearly so that the userspace can
depend on it. Also, this needs to be implemented separately for each
subdev driver, and it can be very easy to make mistakes with it in the
driver code.
Consider e.g. changing the sink side of a route, but keeping source side
unchanged. It would make sense to keep the source side config intact.
But that config may no longer be valid as the sink side changes.
Or maybe the first route is unchanged, but changing the second route
(perhaps the second route now starts or ends at the same pad used in the
first route) might cause the first route to not be valid anymore.
So, all in all, I think it's much easier for both the kernel to reset
the configs and for the userspace re-configure everything. But I'm open
to other opinions =).
If changing the routing, even if the route of an existing stream stays unchanged,
will require this re-initialization, then that has to be documented clearly, including
in the affected ioctls.
Yes, I'll add this to docs.
Tomi
