On 05/10/2023 13:10, Hans Verkuil wrote:
On 03/10/2023 13:52, Sakari Ailus wrote:
Document how embedded data support should be implemented for camera
sensors, and when and how CCS embedded data format should be referenced.
Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
---
.../media/drivers/camera-sensor.rst | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/userspace-api/media/drivers/camera-sensor.rst b/Documentation/userspace-api/media/drivers/camera-sensor.rst
index 919a50e8b9d9..308f391c5ca1 100644
--- a/Documentation/userspace-api/media/drivers/camera-sensor.rst
+++ b/Documentation/userspace-api/media/drivers/camera-sensor.rst
@@ -102,3 +102,31 @@ register programming sequences shall initialize the :ref:`V4L2_CID_HFLIP
values programmed by the register sequences. The default values of these
controls shall be 0 (disabled). Especially these controls shall not be inverted,
independently of the sensor's mounting rotation.
+
+Embedded data
+-------------
+
+Many sensors, mostly raw sensors, support embedded data which is used to convey
+the sensor configuration for the captured frame back to the host. While CSI-2 is
+the most common bus used by such sensors, embedded data is not entirely limited
+to CSI-2 bus due to e.g. bridge devices.
I'm not quite sure what you mean with "embedded data is not entirely limited
to CSI-2 bus due to e.g. bridge devices": do you just want to say: "embedded data
can be available on other bus types as well."?
Right, nothing CSI-2 specific here. I have a parallel sensor that sends
embedded data as the last (or was it first?) few lines of the frame.
Also, is this about sensors only, and more specifically, about
generating the embedded data? If yes, why mention bridge devices (and
should the title be "Embedded data generation" or such)? If not, is it
about metadata in general, in which case bridges come into play?
+
+Embedded data support should use an internal source pad and route to the
should or shall/must?
Is the above necessary? I don't see anything wrong with, say, having a
sensor represented with multiple subdevs, and one subdev is used for the
embedded data generation.
Basically, anything that can be represented with internal pads can also
be done with multiple subdevs, although I think you don't want to go the
multiple subdev route unless absolutely necessary.
Regards,
Hans
+external pad. If embedded data output can be disabled in hardware, it should be
+possible to disable the embedded data route via ``VIDIOC_SUBDEV_S_ROUTING``
+IOCTL.
+
+In general, changing the embedded data format from the driver-configured values
+is not supported. The height of the metadata is hardware specific and the width
+is that (or less of that) of the image width, as configured on the pixel data
+stream.
+
+CCS and non-CCS embedded data
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Embedded data which is compliant with CCS definitions shall use ``CCS embedded
+data format <MEDIA-BUS-FMT-CCS-EMBEDDED>``. Device specific embedded data which
+is compliant up to MIPI CCS embedded data levels 1 or 2 only shall refer to CCS
+embedded data formats and document the level of conformance. The rest of the
+device specific embedded data format shall be documented in the context of the
+data format itself.
