Hi Sakari, Thank you for the patch. On Wed, Mar 13, 2024 at 09:24:45AM +0200, Sakari Ailus wrote: > 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 s/hardware specific/hardware-specific/ > example on parallel bus this might not work on all cases. s/bus/buses/ > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > Reviewed-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> > --- > 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..a387e8a15b8d 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 the stream 0 on source end may be s/the stream 0 on source end/stream 0 of the source/ > +captured. There may be additional hardware specific limitations. s/hardware specific/hardware-specific/ Or maybe There may be additional limitations specific to the sink device. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx> > > Understanding streams > ^^^^^^^^^^^^^^^^^^^^^ -- Regards, Laurent Pinchart
