From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: linux-media@vger.kernel.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com,
hongju.wang@intel.com, hverkuil@xs4all.nl,
Andrey Konovalov <andrey.konovalov@linaro.org>,
Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
Dmitry Perchanov <dmitry.perchanov@intel.com>,
"Ng, Khai Wen" <khai.wen.ng@intel.com>,
Alain Volmat <alain.volmat@foss.st.com>
Subject: [PATCH v3 08/14] media: Documentation: Additional streams generally don't harm capture
Date: Fri, 26 Apr 2024 11:50:32 +0300 [thread overview]
Message-ID: <20240426085038.943733-9-sakari.ailus@linux.intel.com> (raw)
In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com>
Having extra streams on the source end of the link that cannot be captured
by the sink sub-device generally are not an issue, at least not on CSI-2
bus. Still document that there may be hardware-specific limitations. For
example on parallel bus this might not work on all cases.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
Documentation/userspace-api/media/v4l/dev-subdev.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst
index f375b820ab68..b76e02e54512 100644
--- a/Documentation/userspace-api/media/v4l/dev-subdev.rst
+++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst
@@ -529,9 +529,9 @@ the its sink pad and allows to route them individually to one of its source
pads.
Subdevice drivers that support multiplexed streams are compatible with
-non-multiplexed subdev drivers, but, of course, require a routing configuration
-where the link between those two types of drivers contains only a single
-stream.
+non-multiplexed subdev drivers. However, if the driver at the sink end of a link
+does not support streams, then only stream 0 of source end may be captured.
+There may be additional limitations specific to the sink device.
Understanding streams
^^^^^^^^^^^^^^^^^^^^^
--
2.39.2
next prev parent reply other threads:[~2024-04-26 8:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 8:50 [PATCH v3 00/14] Generic line based metadata, without sensor API changes Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 01/14] media: v4l2-subdev: Clearly document that the crop API won't be extended Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 02/14] media: Documentation: Add "stream" into glossary Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 03/14] media: uapi: Add generic serial metadata mbus formats Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 04/14] media: uapi: Document which mbus format fields are valid for metadata Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 05/14] media: uapi: v4l: Add generic 8-bit metadata format definitions Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 06/14] media: v4l: Support line-based metadata capture Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 07/14] media: v4l: Set line based metadata flag in V4L2 core Sakari Ailus
2024-04-26 8:50 ` Sakari Ailus [this message]
2024-04-26 8:50 ` [PATCH v3 09/14] media: Documentation: Document S_ROUTING behaviour Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 10/14] media: v4l: subdev: Add a function to lock two sub-device states, use it Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 11/14] media: v4l: subdev: Copy argument back to user also for S_ROUTING Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 12/14] media: v4l: subdev: Add len_routes field to struct v4l2_subdev_routing Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 13/14] media: v4l: subdev: Return routes set using S_ROUTING Sakari Ailus
2024-04-26 8:50 ` [PATCH v3 14/14] media: v4l: subdev: Add trivial set_routing support Sakari Ailus
2024-04-26 15:33 ` [PATCH] media: uapi: v4l: Don't expose generic metadata formats to userspace Laurent Pinchart
2024-04-29 7:05 ` Tomi Valkeinen
2024-04-29 8:33 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240426085038.943733-9-sakari.ailus@linux.intel.com \
--to=sakari.ailus@linux.intel.com \
--cc=alain.volmat@foss.st.com \
--cc=andrey.konovalov@linaro.org \
--cc=bingbu.cao@intel.com \
--cc=dmitry.perchanov@intel.com \
--cc=hongju.wang@intel.com \
--cc=hverkuil@xs4all.nl \
--cc=jacopo.mondi@ideasonboard.com \
--cc=khai.wen.ng@intel.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=tomi.valkeinen@ideasonboard.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox