Hi,
On 03/08/2022 12:03, Milen Mitkov (Consultant) wrote:
Hey Tomi,
thank you for providing v12 of the routing and streams support patches!
We are using v11 of these to add CSI virtual channels support to the
Qualcomm Titan platform (a.k.a qcom-camss driver) and will be moving to
the brand new fresh v12 now.
I ponder several questions with regards to this newly added
functionality (not just v12, but all versions in general):
1. What are the main benefits of having multiple streams, that can be
enabled/disabled/configured, on the same pad vs. say having multiple
pads, each of which can be enabled/disabled/configured?
The streams and pads are kind of similar, but also different.
One difference is a conceptual one, that a pad represents some kind of
physical connector, streams are logical "virtual" pads or connectors.
But perhaps the main practical difference is that you had a hardcoded
amount of pads, but the amount of streams is dynamic, adjusted based on
the routing table.
As far as I understood, in the user-space world each stream on the end
of the pipeline gets exposed as a /dev/video%d node. Each node
corresponds to a videodev which is wrapped in a media entity that has a
Yes.
It would be nice to have a videodev that supports multiple streams, but
at the moment there's no API for that kind of thing. Perhaps in the future.
single sink pad. So in the end, all streams end up as multiple "stream
-> pad" correspondences. I am sure there is some benefit of having
multiple streams vs having multiple pads, but I am struggling to put it
into exact words.
Consider a bridge device with, say, 2 CSI2 inputs and 2 CSI2 outputs.
The device can route streams from either input to either output, and
possibly modify them (say, change virtual channel number).
How many pads would have there? You would need a predefined amount of
pads, one for each stream. So how many streams? What's a stream? With
CSI2, we can easily define at least that we can have streams identified
with the VC and the DT. So, 4 VCs at max, but there can be many DTs. I
don't remember how wide the DT field is, but lets say 10 DTs. That would
be max 40 streams per input.
So the above device would need to have 40 * 4 pads to cover "all"
possible uses. I say "all", because it's not clear how to define a
stream. If the device in question can, say, split the incoming frame per
line, and somehow output each of those lines separately, then,
effectively, there would be as many streams as there are lines. That's a
silly example, but I just want to highlight the dynamic nature of streams.
2. What is your userspace modus operandi with regards to testing these
I have my own python scripts built on top of kms++. They're really not
in such a condition that I could share them to others. Maybe I'll at
some point find the time to clean them up...
changes? For example, I figured out this much with regards to media-ctl:
Yes, it should be all doable with media-ctl, v4l2-ctl.
media-ctl -R '"msm_csid0"[0/0->1/0[0x1],0/0->1/1[0x1]]'
If I want to configure the CSI decoder subdev (msm_csid0) to receive 1
stream on the sink pad and route it to 2 streams on its source pad. Is
my thinking correct?
Yes, if your HW can do that. I don't have HW that can split (or clone) a
stream, so it's possible that the use case doesn't work.
And I also wonder what is your preferred method to open each /dev/video
node in userspace concurrently? Are you, say, running 2 or more parallel
instances of yavta?
I do it with my script, but yes, I think running multiple yavtas should
do the trick.
3. I assume, that with these changes, it's _strongly_ preferred that the
subdevice's active state management is left to the V4L2 API and not kept
internally like older drivers do?
A subdev that uses routing/streams _must_ use the subdev active state.
Tomi
