Re: [RFC v5 04/15] media: Documentation: Add subdev configuration models, raw sensor model

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Mirela,

On Wed, Feb 26, 2025 at 11:17:43AM +0200, Mirela Rabulea wrote:
> Hi Sakari,
> 
> On 09.02.2025 17:42, Mirela Rabulea wrote:
> > Hi Sakari,
> > 
> > Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
> > 
> > Regards,
> > 
> > Mirela
> > 
> > On 03.02.2025 10:58, Sakari Ailus wrote:
> > > Sub-device configuration models define what V4L2 API elements are
> > > available on a compliant sub-device and how do they behave.
> > > 
> > > The patch also adds a model for common raw sensors.
> > > 
> > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > > ---
> > >   .../media/drivers/camera-sensor.rst           |   4 +
> > >   .../media/v4l/common-raw-sensor.dia           | 441 ++++++++++++++++++
> > >   .../media/v4l/common-raw-sensor.svg           | 134 ++++++
> > >   .../userspace-api/media/v4l/dev-subdev.rst    |   2 +
> > >   .../media/v4l/subdev-config-model.rst         | 209 +++++++++
> > >   5 files changed, 790 insertions(+)
> > >   create mode 100644
> > > Documentation/userspace-api/media/v4l/common-raw-sensor.dia
> > >   create mode 100644
> > > Documentation/userspace-api/media/v4l/common-raw-sensor.svg
> > >   create mode 100644
> > > Documentation/userspace-api/media/v4l/subdev-config-model.rst
> > > 
> > > ...
> 
> > > +
> > > +Common raw camera sensor model
> > > +------------------------------
> > > +
> > > +The common raw camera sensor model defines a set of enumeration and
> > > +configuration interfaces (formats, selections etc.) that cover the
> > > vast majority
> > > +of functionality of raw camera sensors. Not all of the interfaces are
> > > +necessarily offered by all drivers.
> > > +
> > > +A sub-device complies with the common raw sensor model if the
> > > +``V4L2_CONFIG_MODEL_COMMON_RAW`` bit is set in the
> > > ``V4L2_CID_CONFIG_MODEL``
> > > +control of the sub-device.
> > > +
> > > +The common raw camera sensor model is aligned with
> > > +:ref:`media_using_camera_sensor_drivers`. Please refer to that
> > > regarding aspects
> > > +not specified here.
> > > +
> > > +Each camera sensor implementing the common raw sensor model exposes
> > > a single
> > > +V4L2 sub-device. The sub-device contains a single source pad (0)
> > > and two or more
> > > +internal pads: an image data internal pad (1) and optionally an
> > > embedded data
> > > +pad (2). Additionally, further internal pads may be supported for other
> > > +features, in which case they are documented separately for the
> > > given device.
> 
> One more question here, to be sure I understand correctly. So, in order to
> be compliant with the common raw camera sensor model, in case a raw sensor
> will need more than 2 internal pads, the expectation is to keep image on pad
> 0, edata on pad 1, and add more needed pads? Or is it acceptable that a
> driver completely changes the pad numbering according to it's needs, as long
> as it is documented?
> 
> The case I am targeting is os08a20 hdr sensor, with: pad1-image long
> exposure, pad2-edata, pad3-image short exposure. So far, so good, I guess.
> 
> I don't know if there will be such a case for a sensor driver which does not
> support embedded data, but will need to support other internal pads, and in
> such a case, how should pad numbering look like?

Good question.

I think we could change the common raw sensor model in such a way that the
embedded data internal pad is the first one using a metadata mbus code,
instead of using a plain number.

Laurent, any thoughts?

-- 
Kind regards,

Sakari Ailus