Hi Mirela, On Wed, Feb 26, 2025 at 11:16:36AM +0200, Mirela Rabulea wrote: > Hi Sakari and Laurent, > > On 16.04.2024 22:32, Sakari Ailus wrote: > > Document internal sink pads, pads that have both SINK and INTERNAL flags > > set. Use the IMX219 camera sensor as an example. > > > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > > Reviewed-by Julien Massot <julien.massot@xxxxxxxxxxxxx> > > --- > > .../userspace-api/media/v4l/dev-subdev.rst | 145 ++++++++++++++++++ > > 1 file changed, 145 insertions(+) > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > index b76e02e54512..d30dcb9e2537 100644 > > --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst > > +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst > > @@ -553,6 +553,27 @@ 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-internal-source-pads: > > + > > +Internal sink pads and routing > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +Cases where a single sub-device source pad is traversed by multiple streams, one > > +or more of which originate from within the sub-device itself, are special as > > +there is no external sink pad for such routes. In those cases, the sources of > > +the internally generated streams are represented by internal sink pads, which > > +are sink pads that have the :ref:`MEDIA_PAD_FL_INTERNAL <MEDIA-PAD-FL-INTERNAL>` > > +pad flag set. > > + > > +Internal pads have all the properties of an external pad, 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). > > For me, it is not clear what is allowed/expected regarding the formats on > the internal sink pads. > > What "The format in this case is the source format of the stream" means? > > I suppose the format on the internal pads will never be set by the user, but > be static or propagated? It depends on the device, in fact. On sensors I'd use the highest supported bit depth on the internal pad whereas on the external pad this could be configurable. I'll add this to the common raw sensor model. > > A glimpse into the future shows that libcamera makes some assumptions in > src/libcamera/sensor/camera_sensor_raw.cpp: > > https://lists.libcamera.org/pipermail/libcamera-devel/2024-March/041006.html ; > > /* > * Get the native sensor CFA pattern. It is simpler to retrieve it from > * the internal image sink pad as it is guaranteed to expose a single > * format, and is not affected by flips. > */ > > I think it would be good to have a more clear documentation in the kernel, > for both the driver developers and user applications to know what behavior > to expect. If a "native" format is always expected on the internal sink > pads, let it be documented, or if the internal sink pads format should be > propagated from the source pad format (presumably set by the user, and > contrary to the general recommendation to propagate the format from sink to > source). The intention originally was to use existing raw formats on internal sink pads to express the native format of the sensor. I later on switched to generic (greyscale) formats and the colour pattern control after discussing the matter with Laurent. > > Also, if there is a guarantee to have a single format exposed, as stated in > libcamera, it would be good to have that also documented in the kernel. > > I assume some things will change in libcamera after the common raw sensor > model addition in the kernel, I don't fully envision how. > > I am working on adding internal pads and streams for os08a20 hdr sensor, and > also looked at the changes made to imx219, to give some context to my > questions. Regarding the GRBIR sensor -- I'm suggesting to use greyscale mbus codes and then the colour pattern control. We could merge those patches before the common raw sensor model. -- Kind regards, Sakari Ailus
