Hi Hans,
On 11/10/2021 18:29, Hans Verkuil wrote:
Hi Tomi,
On 05/10/2021 10:57, Tomi Valkeinen wrote:
Hi,
This is v9 of the multiplexed streams series. v8 can be found from:
https://lore.kernel.org/all/20210830110116.488338-1-tomi.valkeinen@xxxxxxxxxxxxxxxx/
I have pushed my work branch to:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git multistream/work-v9
which contains the patches in this series, along with subdev drivers
using multiplexed streams.
As can be guessed from the work branch, I have been testing this series
with TI's FPDLink setup. I have also done a "backwards compatibility"
test by dropping all multiplexed streams patches from the CAL driver
(the CSI-2 RX on the TI SoC), and using the FPDLink drivers with
single-stream configuration.
I hope to look at this series this week (fingers crossed), but I was asked to
give some input w.r.t. testing of this series:
Thanks for the reviews! I'll start updating the series accordingly.
I think before this can be merged we need:
1) libcamera tests. Since libcamera would probably be the most active user of this
API, and you have HW for it, it makes a lot of sense that there are decent tests
for the supported HW in libcamera. That takes care of the real-world tests.
I agree, libcamera would be a good userspace test. Laurent has been
working on that.
2) obviously the existing utils in v4l-utils need to be adapted to understand any
new API elements.
Yes. I think it's "just" two things that are needed: ability to set a
routing table (that might be quite messy via the cmdline for larger
routing tables) and ability to set format and other parameters with a
(pad,stream) tuple, instead of just pad.
3) compliance tests in v4l2-compliance for the new API. After I did a review of the
series we can see to what extent this is possible.
One thing we have to fix are the problems caused by adding the 'stream'
field to many structs, but I think fixing that is trivial.
Actually testing routing and streams is a bit more difficult.
4) optionally (for now at least, I reserve the right to change my mind): it would
be very helpful if this can be added to vimc (or something similar), allowing for
testing the API without having real hardware, which is useful both for writing
the tests and for running regression tests regularly on a simple VM, without needing
special hardware.
I haven't studied the vimc code, but maybe a metadata stream would be an
easy addition.
Tomi