When the support for serial busses was introduced in V4L2, it was decided to use the existing parallel bus media bus pixel codes to describe them. While this was a practical choice at the time, it necessitates choosing which one of the many parallel mbus pixel codes to use, for on the serial busses these formats are effectively all equivalent. The practice has always been to use the pixel code that describes a bus that transfers a single sample per clock. Document this. Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> --- Documentation/media/kapi/csi2.rst | 7 +++++++ Documentation/media/uapi/v4l/subdev-formats.rst | 4 ++++ 2 files changed, 11 insertions(+) diff --git a/Documentation/media/kapi/csi2.rst b/Documentation/media/kapi/csi2.rst index a7e75e2eba85a..c67736a15c45b 100644 --- a/Documentation/media/kapi/csi2.rst +++ b/Documentation/media/kapi/csi2.rst @@ -72,3 +72,10 @@ the transmitter up by using the :c:type:`v4l2_subdev_core_ops`->s_power() callback. This may take place either indirectly by using :c:func:`v4l2_pipeline_pm_use` or directly. + +Formats +------- + +The media bus pixel codes document parallel formats. Should the pixel data be +transported over a serial bus, the media bus pixel code that describes a +parallel format that transfers a sample on a single clock cycle is used. diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst index ab1a48a5ae80b..d6b8b86a6daad 100644 --- a/Documentation/media/uapi/v4l/subdev-formats.rst +++ b/Documentation/media/uapi/v4l/subdev-formats.rst @@ -85,6 +85,10 @@ formats in memory (a raw Bayer image won't be magically converted to JPEG just by storing it to memory), there is no one-to-one correspondence between them. +The media bus pixel codes document parallel formats. Should the pixel data be +transported over a serial bus, the media bus pixel code that describes a +parallel format that transfers a sample on a single clock cycle is used. + Packed RGB Formats ^^^^^^^^^^^^^^^^^^ -- 2.20.1
