Re: [PATCH v3 01/29] media: v4l2-common: Add helper function media_bus_fmt_to_csi2_(bpp|dt)()

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

Hej Linus,

On Fri, Aug 28, 2026 at 12:29:36AM +0200, Linus Walleij wrote:
> Hi Sakari/Frank,
> 
> one more thing which might be a rookie mistake on my side though:
> 
> On Mon, Aug 24, 2026 at 2:14 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> 
> In this example:
> 
> > CSI2 data type is defined by MIPI Camera Serial Interface 2 Spec Ver4.1.
> > See section 9.4.
> >
> > Add helper function media_bus_fmt_to_csi2_dt() to convert media bus fmt to
> > MIPI defined data type and avoid below duplicated static array in each CSI2
> > drivers.
> >
> >         {
> >                 .code = MEDIA_BUS_FMT_UYVY8_1X16,
> >                 .data_type = MIPI_CSI2_DT_YUV422_8B,
> >         }
> 
> The way I read the CSI-2 spec YUV422 8bit has this byte order: U Y V Y
> (this is in section 11.2.4 in my copy of the spec, figure and all)
> so this looks correct if you just look at that string: UYVY no problem.
> 
> I tried to understand the MEDIA_BUS_FMT_* conventions...
> I looked here:
> https://docs.kernel.org/next/userspace-api/media/v4l/subdev-formats.html
> 
> And in the table in the docs:
> 
> Word 1: bit 15..8 is U, bits 7..0 is Y
> Word 2: bit 15..8 is V, bits 7..0 is Y
> 
> I *think* 1X16 should be understood as 2x16bit words (samples?) where
> each 16bit word is in LSB, MSB ("little endian") order, i.. bits 7..0 (Y)
> are transmitted *first* then bits 15..8 (U) correct me
> if I misunderstood!
> 
> Then UYVY8_1X16 becomes the *byte* order Y U Y V.
> 
> But YUYV on the other hand becomes U Y V Y !
> 
> Isn't this then MEDIA_BUS_FMT_YUYV8_1X16 ?
> 
> I'm reading the spec and Linux format codes until my eyes fall out...

Good question. The practice has been to use mbus codes ending _xXy, where y
is the pixel depth, to denote MIPI CSI-2 data types. Presumably, if a
driver uses these formats with CSI-2, then this is the MIPI CSI-2 data type
employed, even if the pixel order is different.

The entries are used to convert the mbus codes to MIPI CSI-2 data types, so
I expect no issues even if we have a data type for an mbus code that
doesn't have an exact match with the MIPI spec pixel order-wise.

> 
> It's there in the code though:
> 
> > +       { .code = MEDIA_BUS_FMT_UYVY8_1X16, .dt = MIPI_CSI2_DT_YUV422_8B, .bpp = 16 },
> > +       { .code = MEDIA_BUS_FMT_VYUY8_1X16, .dt = MIPI_CSI2_DT_YUV422_8B, .bpp = 16 },
> > +       { .code = MEDIA_BUS_FMT_YUYV8_1X16, .dt = MIPI_CSI2_DT_YUV422_8B, .bpp = 16 },
> > +       { .code = MEDIA_BUS_FMT_YVYU8_1X16, .dt = MIPI_CSI2_DT_YUV422_8B, .bpp = 16 },
> 
> all four of the related encodings, I don't know if this works in practice
> but it seems off. Three of them must be wrong since MIPI_CSI2_DT_YUV422_8B
> is very determined?
> 
> Obviously I didn't check the entire table like this, but if there is something
> to what I'm saying then we have to...

-- 
Med trevliga hälsningar,

Sakari Ailus