| Message ID | 20230505215257.60704-4-sakari.ailus@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | Generic line based metadata support, internal pads | expand |
On 06/05/2023 00:52, Sakari Ailus wrote: > Document how internal pads are used on source routes. > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > .../userspace-api/media/v4l/dev-subdev.rst | 18 ++++++++++++++++++ > .../media/v4l/vidioc-subdev-g-routing.rst | 5 +++++ > include/uapi/linux/v4l2-subdev.h | 6 +++++- > 3 files changed, 28 insertions(+), 1 deletion(-) > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst > index a4f1df7093e8..395e06d2f0f2 100644 > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst > @@ -551,6 +551,24 @@ A stream at a specific point in the media pipeline is identified by the > sub-device and a (pad, stream) pair. For sub-devices that do not support > multiplexed streams the 'stream' field is always 0. > > +.. _v4l2-subdev-source-routes: > + > +Source routes > +^^^^^^^^^^^^^ > + > +Cases where a single sub-device pad is a source of multiple streams are special > +as there is no sink pad for such a route. In those cases, an internal pad is > +used as the sink pad. Such pads have the :ref:`MEDIA_PAD_FL_INTERNAL_SOURCE > +<MEDIA-PAD-FL-INTERNAL-SOURCE>` flag set. > + > +Internal pads have all the properties of a sink pad in such case, including > +formats and selections. The format in this case is the source format of the > +stream. An internal pad always has a single stream only (0). > + > +Generally source routes are not modifiable but they can be activated and > +inactivated using the :ref:`V4L2_SUBDEV_ROUTE_FL_ACTIVE > +<v4l2-subdev-routing-flags>` flag, depending on driver capabilities. > + I find the above chapter a bit difficult to read, but I think we need to conclude on the internal-pad vs internal-source-pad discussion first. However, one point/question: You write that there's only one stream in an internal pad. I wonder if that's a good or a necessary limitation... Do you see that allowing multiple streams brings extra complexity? It's still up to each driver to decide how many streams they support (most would just support a single one), so each driver can easily enforce that limit. I'm fine with starting with only single-stream support, but if we later need to loosen that restriction, I wonder if it'll be difficult if we have specified that there can be only one stream. I.e. will the drivers and the userspace depend on that limit. Tomi
Moi, On Mon, May 08, 2023 at 01:33:24PM +0300, Tomi Valkeinen wrote: > On 06/05/2023 00:52, Sakari Ailus wrote: > > Document how internal pads are used on source routes. > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > --- > > .../userspace-api/media/v4l/dev-subdev.rst | 18 ++++++++++++++++++ > > .../media/v4l/vidioc-subdev-g-routing.rst | 5 +++++ > > include/uapi/linux/v4l2-subdev.h | 6 +++++- > > 3 files changed, 28 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > index a4f1df7093e8..395e06d2f0f2 100644 > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > @@ -551,6 +551,24 @@ A stream at a specific point in the media pipeline is identified by the > > sub-device and a (pad, stream) pair. For sub-devices that do not support > > multiplexed streams the 'stream' field is always 0. > > +.. _v4l2-subdev-source-routes: > > + > > +Source routes > > +^^^^^^^^^^^^^ > > + > > +Cases where a single sub-device pad is a source of multiple streams are special > > +as there is no sink pad for such a route. In those cases, an internal pad is > > +used as the sink pad. Such pads have the :ref:`MEDIA_PAD_FL_INTERNAL_SOURCE > > +<MEDIA-PAD-FL-INTERNAL-SOURCE>` flag set. > > + > > +Internal pads have all the properties of a sink pad in such case, including > > +formats and selections. The format in this case is the source format of the > > +stream. An internal pad always has a single stream only (0). > > + > > +Generally source routes are not modifiable but they can be activated and > > +inactivated using the :ref:`V4L2_SUBDEV_ROUTE_FL_ACTIVE > > +<v4l2-subdev-routing-flags>` flag, depending on driver capabilities. > > + > > I find the above chapter a bit difficult to read, but I think we need to > conclude on the internal-pad vs internal-source-pad discussion first. > However, one point/question: > > You write that there's only one stream in an internal pad. I wonder if > that's a good or a necessary limitation... Do you see that allowing multiple > streams brings extra complexity? It's still up to each driver to decide how > many streams they support (most would just support a single one), so each > driver can easily enforce that limit. Good question. As we don't seem to have a tangible reason to allow it, I'd deny it until there's a use case. Or did you have a use case in mind? I thought indicating which streams will be bound together (i.e. either are all disabled or enabled) could be one, but I'm not sure we need that at the moment at least. > > I'm fine with starting with only single-stream support, but if we later need > to loosen that restriction, I wonder if it'll be difficult if we have > specified that there can be only one stream. I.e. will the drivers and the > userspace depend on that limit. We can always allow what wasn't allowed previously so that's a non-issue, really. But it needs to bring new functionality, otherwise there's no reason to do that.
On 08/05/2023 19:26, Sakari Ailus wrote: > Moi, > > On Mon, May 08, 2023 at 01:33:24PM +0300, Tomi Valkeinen wrote: >> On 06/05/2023 00:52, Sakari Ailus wrote: >>> Document how internal pads are used on source routes. >>> >>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> >>> --- >>> .../userspace-api/media/v4l/dev-subdev.rst | 18 ++++++++++++++++++ >>> .../media/v4l/vidioc-subdev-g-routing.rst | 5 +++++ >>> include/uapi/linux/v4l2-subdev.h | 6 +++++- >>> 3 files changed, 28 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst >>> index a4f1df7093e8..395e06d2f0f2 100644 >>> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst >>> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst >>> @@ -551,6 +551,24 @@ A stream at a specific point in the media pipeline is identified by the >>> sub-device and a (pad, stream) pair. For sub-devices that do not support >>> multiplexed streams the 'stream' field is always 0. >>> +.. _v4l2-subdev-source-routes: >>> + >>> +Source routes >>> +^^^^^^^^^^^^^ >>> + >>> +Cases where a single sub-device pad is a source of multiple streams are special >>> +as there is no sink pad for such a route. In those cases, an internal pad is >>> +used as the sink pad. Such pads have the :ref:`MEDIA_PAD_FL_INTERNAL_SOURCE >>> +<MEDIA-PAD-FL-INTERNAL-SOURCE>` flag set. >>> + >>> +Internal pads have all the properties of a sink pad in such case, including >>> +formats and selections. The format in this case is the source format of the >>> +stream. An internal pad always has a single stream only (0). >>> + >>> +Generally source routes are not modifiable but they can be activated and >>> +inactivated using the :ref:`V4L2_SUBDEV_ROUTE_FL_ACTIVE >>> +<v4l2-subdev-routing-flags>` flag, depending on driver capabilities. >>> + >> >> I find the above chapter a bit difficult to read, but I think we need to >> conclude on the internal-pad vs internal-source-pad discussion first. >> However, one point/question: >> >> You write that there's only one stream in an internal pad. I wonder if >> that's a good or a necessary limitation... Do you see that allowing multiple >> streams brings extra complexity? It's still up to each driver to decide how >> many streams they support (most would just support a single one), so each >> driver can easily enforce that limit. > > Good question. As we don't seem to have a tangible reason to allow it, I'd > deny it until there's a use case. > > Or did you have a use case in mind? > > I thought indicating which streams will be bound together (i.e. either are > all disabled or enabled) could be one, but I'm not sure we need that at the > moment at least. I don't have nothing concrete in mind. Maybe a TPG which also generates some kind of metadata. But that could be implemented as two internal pads. >> I'm fine with starting with only single-stream support, but if we later need >> to loosen that restriction, I wonder if it'll be difficult if we have >> specified that there can be only one stream. I.e. will the drivers and the >> userspace depend on that limit. > > We can always allow what wasn't allowed previously so that's a non-issue, > really. But it needs to bring new functionality, otherwise there's no > reason to do that. It's not always that easy. If the drivers and the userspace expect that there's a single route with ID 0, and then with a new kernel there are more streams or the single stream is ID 1, things could go wrong. Tomi
Moi, On Mon, May 08, 2023 at 07:35:04PM +0300, Tomi Valkeinen wrote: > On 08/05/2023 19:26, Sakari Ailus wrote: > > Moi, > > > > On Mon, May 08, 2023 at 01:33:24PM +0300, Tomi Valkeinen wrote: > > > On 06/05/2023 00:52, Sakari Ailus wrote: > > > > Document how internal pads are used on source routes. > > > > > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > > > --- > > > > .../userspace-api/media/v4l/dev-subdev.rst | 18 ++++++++++++++++++ > > > > .../media/v4l/vidioc-subdev-g-routing.rst | 5 +++++ > > > > include/uapi/linux/v4l2-subdev.h | 6 +++++- > > > > 3 files changed, 28 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > > > index a4f1df7093e8..395e06d2f0f2 100644 > > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst > > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > > > @@ -551,6 +551,24 @@ A stream at a specific point in the media pipeline is identified by the > > > > sub-device and a (pad, stream) pair. For sub-devices that do not support > > > > multiplexed streams the 'stream' field is always 0. > > > > +.. _v4l2-subdev-source-routes: > > > > + > > > > +Source routes > > > > +^^^^^^^^^^^^^ > > > > + > > > > +Cases where a single sub-device pad is a source of multiple streams are special > > > > +as there is no sink pad for such a route. In those cases, an internal pad is > > > > +used as the sink pad. Such pads have the :ref:`MEDIA_PAD_FL_INTERNAL_SOURCE > > > > +<MEDIA-PAD-FL-INTERNAL-SOURCE>` flag set. > > > > + > > > > +Internal pads have all the properties of a sink pad in such case, including > > > > +formats and selections. The format in this case is the source format of the > > > > +stream. An internal pad always has a single stream only (0). > > > > + > > > > +Generally source routes are not modifiable but they can be activated and > > > > +inactivated using the :ref:`V4L2_SUBDEV_ROUTE_FL_ACTIVE > > > > +<v4l2-subdev-routing-flags>` flag, depending on driver capabilities. > > > > + > > > > > > I find the above chapter a bit difficult to read, but I think we need to > > > conclude on the internal-pad vs internal-source-pad discussion first. > > > However, one point/question: > > > > > > You write that there's only one stream in an internal pad. I wonder if > > > that's a good or a necessary limitation... Do you see that allowing multiple > > > streams brings extra complexity? It's still up to each driver to decide how > > > many streams they support (most would just support a single one), so each > > > driver can easily enforce that limit. > > > > Good question. As we don't seem to have a tangible reason to allow it, I'd > > deny it until there's a use case. > > > > Or did you have a use case in mind? > > > > I thought indicating which streams will be bound together (i.e. either are > > all disabled or enabled) could be one, but I'm not sure we need that at the > > moment at least. > > I don't have nothing concrete in mind. Maybe a TPG which also generates some > kind of metadata. But that could be implemented as two internal pads. > > > > I'm fine with starting with only single-stream support, but if we later need > > > to loosen that restriction, I wonder if it'll be difficult if we have > > > specified that there can be only one stream. I.e. will the drivers and the > > > userspace depend on that limit. > > > > We can always allow what wasn't allowed previously so that's a non-issue, > > really. But it needs to bring new functionality, otherwise there's no > > reason to do that. > > It's not always that easy. If the drivers and the userspace expect that > there's a single route with ID 0, and then with a new kernel there are more > streams or the single stream is ID 1, things could go wrong. Other drivers are a non-issue IMO as this isn't visible to other drivers. I think for user space this could be an issue if it were entirely generic. But that's probably not going to be the case, is it? I don't mean test programs.
Hello, On Mon, May 08, 2023 at 07:35:04PM +0300, Tomi Valkeinen wrote: > On 08/05/2023 19:26, Sakari Ailus wrote: > > On Mon, May 08, 2023 at 01:33:24PM +0300, Tomi Valkeinen wrote: > >> On 06/05/2023 00:52, Sakari Ailus wrote: > >>> Document how internal pads are used on source routes. > >>> > >>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > >>> --- > >>> .../userspace-api/media/v4l/dev-subdev.rst | 18 ++++++++++++++++++ > >>> .../media/v4l/vidioc-subdev-g-routing.rst | 5 +++++ > >>> include/uapi/linux/v4l2-subdev.h | 6 +++++- > >>> 3 files changed, 28 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst > >>> index a4f1df7093e8..395e06d2f0f2 100644 > >>> --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst > >>> +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst > >>> @@ -551,6 +551,24 @@ A stream at a specific point in the media pipeline is identified by the > >>> sub-device and a (pad, stream) pair. For sub-devices that do not support > >>> multiplexed streams the 'stream' field is always 0. > >>> +.. _v4l2-subdev-source-routes: > >>> + > >>> +Source routes > >>> +^^^^^^^^^^^^^ > >>> + > >>> +Cases where a single sub-device pad is a source of multiple streams are special > >>> +as there is no sink pad for such a route. In those cases, an internal pad is > >>> +used as the sink pad. Such pads have the :ref:`MEDIA_PAD_FL_INTERNAL_SOURCE > >>> +<MEDIA-PAD-FL-INTERNAL-SOURCE>` flag set. > >>> + > >>> +Internal pads have all the properties of a sink pad in such case, including > >>> +formats and selections. The format in this case is the source format of the > >>> +stream. An internal pad always has a single stream only (0). > >>> + > >>> +Generally source routes are not modifiable but they can be activated and > >>> +inactivated using the :ref:`V4L2_SUBDEV_ROUTE_FL_ACTIVE > >>> +<v4l2-subdev-routing-flags>` flag, depending on driver capabilities. > >>> + > >> > >> I find the above chapter a bit difficult to read, but I think we need to > >> conclude on the internal-pad vs internal-source-pad discussion first. > >> However, one point/question: Agreed, it's far from being clear :-( Even the first sentence, "Cases where a single sub-device pad is a source of multiple streams are special" is confusing, having a subdev source pad carrying multiple streams isn't special, it is found in, for instance, FPD-Link or GMSL receivers that transmit multiple streams from different cameras over a single CSI-2 output. This may not be what Sakari meant here, but it can be understood that way. We need more than 3 paragraphs here, and we need a very clear example with a diagram. I'd recommend using a camera sensor that produces image data and embedded data for the example, as that's a common real-life use case. The text should present the example, explain what the problem is, and then explain how internal pads fix it. Then it can expand on the features and usage of internal pads in a more generic way. > >> You write that there's only one stream in an internal pad. I wonder if > >> that's a good or a necessary limitation... Do you see that allowing multiple > >> streams brings extra complexity? It's still up to each driver to decide how > >> many streams they support (most would just support a single one), so each > >> driver can easily enforce that limit. > > > > Good question. As we don't seem to have a tangible reason to allow it, I'd > > deny it until there's a use case. > > > > Or did you have a use case in mind? > > > > I thought indicating which streams will be bound together (i.e. either are > > all disabled or enabled) could be one, but I'm not sure we need that at the > > moment at least. > > I don't have nothing concrete in mind. Maybe a TPG which also generates > some kind of metadata. But that could be implemented as two internal pads. > > >> I'm fine with starting with only single-stream support, but if we later need > >> to loosen that restriction, I wonder if it'll be difficult if we have > >> specified that there can be only one stream. I.e. will the drivers and the > >> userspace depend on that limit. > > > > We can always allow what wasn't allowed previously so that's a non-issue, > > really. But it needs to bring new functionality, otherwise there's no > > reason to do that. > > It's not always that easy. If the drivers and the userspace expect that > there's a single route with ID 0, and then with a new kernel there are > more streams or the single stream is ID 1, things could go wrong. I agree with Tomi here. On the kernel side it should be fine (with an unknown amount of pain), but I'd consider this as a userspace API breakage. If the specifications indicates that only a single stream can be used, applications may rely on that, and things could go wrong if new streams are added. We can restrict the kernel implementation to a single stream, but the userspace API has to indicate that multiple streams can co-exist if we want to allow that in the future.
On Mon, May 08, 2023 at 08:41:42PM +0300, Sakari Ailus wrote: > On Mon, May 08, 2023 at 07:35:04PM +0300, Tomi Valkeinen wrote: > > On 08/05/2023 19:26, Sakari Ailus wrote: > > > On Mon, May 08, 2023 at 01:33:24PM +0300, Tomi Valkeinen wrote: > > > > On 06/05/2023 00:52, Sakari Ailus wrote: > > > > > Document how internal pads are used on source routes. > > > > > > > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > > > > --- > > > > > .../userspace-api/media/v4l/dev-subdev.rst | 18 ++++++++++++++++++ > > > > > .../media/v4l/vidioc-subdev-g-routing.rst | 5 +++++ > > > > > include/uapi/linux/v4l2-subdev.h | 6 +++++- > > > > > 3 files changed, 28 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > > > > index a4f1df7093e8..395e06d2f0f2 100644 > > > > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst > > > > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > > > > @@ -551,6 +551,24 @@ A stream at a specific point in the media pipeline is identified by the > > > > > sub-device and a (pad, stream) pair. For sub-devices that do not support > > > > > multiplexed streams the 'stream' field is always 0. > > > > > +.. _v4l2-subdev-source-routes: > > > > > + > > > > > +Source routes > > > > > +^^^^^^^^^^^^^ > > > > > + > > > > > +Cases where a single sub-device pad is a source of multiple streams are special > > > > > +as there is no sink pad for such a route. In those cases, an internal pad is > > > > > +used as the sink pad. Such pads have the :ref:`MEDIA_PAD_FL_INTERNAL_SOURCE > > > > > +<MEDIA-PAD-FL-INTERNAL-SOURCE>` flag set. > > > > > + > > > > > +Internal pads have all the properties of a sink pad in such case, including > > > > > +formats and selections. The format in this case is the source format of the > > > > > +stream. An internal pad always has a single stream only (0). > > > > > + > > > > > +Generally source routes are not modifiable but they can be activated and > > > > > +inactivated using the :ref:`V4L2_SUBDEV_ROUTE_FL_ACTIVE > > > > > +<v4l2-subdev-routing-flags>` flag, depending on driver capabilities. > > > > > + > > > > > > > > I find the above chapter a bit difficult to read, but I think we need to > > > > conclude on the internal-pad vs internal-source-pad discussion first. > > > > However, one point/question: > > > > > > > > You write that there's only one stream in an internal pad. I wonder if > > > > that's a good or a necessary limitation... Do you see that allowing multiple > > > > streams brings extra complexity? It's still up to each driver to decide how > > > > many streams they support (most would just support a single one), so each > > > > driver can easily enforce that limit. > > > > > > Good question. As we don't seem to have a tangible reason to allow it, I'd > > > deny it until there's a use case. > > > > > > Or did you have a use case in mind? > > > > > > I thought indicating which streams will be bound together (i.e. either are > > > all disabled or enabled) could be one, but I'm not sure we need that at the > > > moment at least. > > > > I don't have nothing concrete in mind. Maybe a TPG which also generates some > > kind of metadata. But that could be implemented as two internal pads. > > > > > > I'm fine with starting with only single-stream support, but if we later need > > > > to loosen that restriction, I wonder if it'll be difficult if we have > > > > specified that there can be only one stream. I.e. will the drivers and the > > > > userspace depend on that limit. > > > > > > We can always allow what wasn't allowed previously so that's a non-issue, > > > really. But it needs to bring new functionality, otherwise there's no > > > reason to do that. > > > > It's not always that easy. If the drivers and the userspace expect that > > there's a single route with ID 0, and then with a new kernel there are more > > streams or the single stream is ID 1, things could go wrong. > > Other drivers are a non-issue IMO as this isn't visible to other drivers. > > I think for user space this could be an issue if it were entirely generic. > But that's probably not going to be the case, is it? I don't mean test > programs. I could imagine this breaking libcamera for instance.
diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst index a4f1df7093e8..395e06d2f0f2 100644 --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst @@ -551,6 +551,24 @@ A stream at a specific point in the media pipeline is identified by the sub-device and a (pad, stream) pair. For sub-devices that do not support multiplexed streams the 'stream' field is always 0. +.. _v4l2-subdev-source-routes: + +Source routes +^^^^^^^^^^^^^ + +Cases where a single sub-device pad is a source of multiple streams are special +as there is no sink pad for such a route. In those cases, an internal pad is +used as the sink pad. Such pads have the :ref:`MEDIA_PAD_FL_INTERNAL_SOURCE +<MEDIA-PAD-FL-INTERNAL-SOURCE>` flag set. + +Internal pads have all the properties of a sink pad in such case, including +formats and selections. The format in this case is the source format of the +stream. An internal pad always has a single stream only (0). + +Generally source routes are not modifiable but they can be activated and +inactivated using the :ref:`V4L2_SUBDEV_ROUTE_FL_ACTIVE +<v4l2-subdev-routing-flags>` flag, depending on driver capabilities. + Interaction between routes, streams, formats and selections ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst index 68ca343c3b44..e00622071b64 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst @@ -94,6 +94,11 @@ for all the route entries and call ``VIDIOC_SUBDEV_G_ROUTING`` again. * - __u32 - ``sink_pad`` - Sink pad number. + * - __u32 + - ``internal_source_pad`` + - Internal source pad number. For pads with :ref:`internal source pad flag + <MEDIA-PAD-FL-INTERNAL-SOURCE>`, for use with :ref:`source routes + <v4l2-subdev-source-routes>`. * - __u32 - ``sink_stream`` - Sink pad stream number. diff --git a/include/uapi/linux/v4l2-subdev.h b/include/uapi/linux/v4l2-subdev.h index 4a195b68f28f..703e3a1f199b 100644 --- a/include/uapi/linux/v4l2-subdev.h +++ b/include/uapi/linux/v4l2-subdev.h @@ -203,6 +203,7 @@ struct v4l2_subdev_capability { * struct v4l2_subdev_route - A route inside a subdev * * @sink_pad: the sink pad index + * @internal_source_pad: the internal source pad * @sink_stream: the sink stream identifier * @source_pad: the source pad index * @source_stream: the source stream identifier @@ -210,7 +211,10 @@ struct v4l2_subdev_capability { * @reserved: drivers and applications must zero this array */ struct v4l2_subdev_route { - __u32 sink_pad; + union { + __u32 sink_pad; + __u32 internal_source_pad; + }; __u32 sink_stream; __u32 source_pad; __u32 source_stream;
Document how internal pads are used on source routes. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- .../userspace-api/media/v4l/dev-subdev.rst | 18 ++++++++++++++++++ .../media/v4l/vidioc-subdev-g-routing.rst | 5 +++++ include/uapi/linux/v4l2-subdev.h | 6 +++++- 3 files changed, 28 insertions(+), 1 deletion(-)