Hi Laurent,
On Fri, Oct 27, 2023 at 05:47:42PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
Thanks for the review!
>
> On Tue, Oct 03, 2023 at 02:52:30PM +0300, Sakari Ailus wrote:
> > Add generic serial metadata mbus formats. These formats describe data
> > width and packing but not the content itself. The reason for specifying
> > such formats is that the formats as such are fairly device specific but
> > they are still handled by CSI-2 receiver drivers that should not be aware
> > of device specific formats. What makes generic metadata formats possible
> > is that these formats are parsed by software only, after capturing the
> > data to system memory.
> >
> > Also add a definition for "Data unit" to cover what is essentially a pixel
> > but is not image data.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
> > ---
> > .../userspace-api/media/glossary.rst | 8 +
> > .../media/v4l/subdev-formats.rst | 258 ++++++++++++++++++
> > include/uapi/linux/media-bus-format.h | 9 +
> > 3 files changed, 275 insertions(+)
> >
> > diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst
> > index f7b99a4527c7..65217b8a44cc 100644
> > --- a/Documentation/userspace-api/media/glossary.rst
> > +++ b/Documentation/userspace-api/media/glossary.rst
> > @@ -25,6 +25,14 @@ Glossary
> >
> > See :ref:`cec`.
> >
> > +.. _media-glossary-data-unit:
> > +
> > + Data unit
> > +
> > + Unit of data transported by a bus. On parallel buses, this is called a
> > + sample while on serial buses the data unit is logical. If the data unit
> > + is image data, it may also be called a pixel.
>
> I don't think this is correct. There are parallel formats that transmit
> multiple pixels per sample (e.g. UYYVYY8_0_5X24), or use multiple
> samples to transmit on pixel (e.g. YUYV8_2X8).
The text needs to be adjusted for parallel buses. How about:
Unit of data transported on a bus. On parallel buses, a data unit
consists of one or more samples that together form a single logical
unit of data while on serial buses a data unit is purely logical.
If a data unit is image data, it may also be called a pixel.
> > diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
> > index a03c543cb072..9ee031397372 100644
> > --- a/include/uapi/linux/media-bus-format.h
> > +++ b/include/uapi/linux/media-bus-format.h
> > @@ -173,4 +173,13 @@
> > */
> > #define MEDIA_BUS_FMT_METADATA_FIXED 0x7001
> >
> > +/* Generic line based metadata formats for serial buses. Next is 0x8008. */
> > +#define MEDIA_BUS_FMT_META_8 0x8001
> > +#define MEDIA_BUS_FMT_META_10 0x8002
> > +#define MEDIA_BUS_FMT_META_12 0x8003
> > +#define MEDIA_BUS_FMT_META_14 0x8004
> > +#define MEDIA_BUS_FMT_META_16 0x8005
> > +#define MEDIA_BUS_FMT_META_20 0x8006
> > +#define MEDIA_BUS_FMT_META_24 0x8007
>
> One thing I'd like to do at some point is to fix the historical mistake
> we make when adding raw image formats that encode the CFA pattern in the
> format itself. While this isn't on-topic for this series, I will then
> need to add RAW_{8,10,12,...} media bus codes, which will essentially
> describe the same format as the above formats. Could we already unify
> them, and add CSI-2 RAW formats instead of metadata-specific formats
> here ?
Am I right if my understanding of your view is RAW_* formats would only
include raw image formats of various colour components, on different pixel
orders, and non-raw image formats would have similar arrangements?
I'd say still metadata formats should be separate so you can distinguish
the type of the data (non-image data).
Ultimately the question is what we want to specify and where, but there
appear to be at least three things:
- Pixel depth
- Type of format (raw, yuv, metadata...)
- Colour components
- Pixel order for raw formats or order of transmission for non-raw formats
We've used the mbus code to describe all three. At least my hunch is now
that we'd use mbus code and format to denote the two first at least.
--
Regards,
Sakari Ailus
