Hi Sakari,
On 09.02.2025 17:42, Mirela Rabulea wrote:
Hi Sakari,
Reviewed-by: Mirela Rabulea <mirela.rabulea@xxxxxxx>
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@xxxxxxxxxxxxxxx>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>
---
.../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?
Thanks,
Mirela
