media: bcm2835-unicam: Fix RGB format / mbus code association

The Unicam driver is a MIPI-CSI2 Receiver, that can capture RGB 4:4:4,
YCbCr 4:2:2, and raw formats.

RGB 4:4:4 is converted to the MIPI-CSI2 RGB888 video format, and
associated to the MEDIA_BUS_FMT_RGB888_1X24 media bus code.

However, V4L2_PIX_FMT_RGB24 is defined as having its color components in
the R, G and B order, from left to right. MIPI-CSI2 however defines the
RGB888 format with blue first, and that's what MEDIA_BUS_FMT_RGB888_1X24
defines too.

This essentially means that the R and B will be swapped compared to what
V4L2_PIX_FMT_RGB24 defines. The same situation occurs with
V4L2_PIX_FMT_BGR24 being associated to MEDIA_BUS_FMT_BGR888_1X24.

In order to fix the swapped components, we need to change the
association of V4L2_PIX_FMT_BGR24 to MEDIA_BUS_FMT_RGB888_1X24, and of
V4L2_PIX_FMT_RGB24 to MEDIA_BUS_FMT_BGR888_1X24.

Since the media bus code is exposed to userspace, and validated by
unicam's link_validate implementation, we need to explicitly accept (and
warn) the old association still to preserve backward compatibility.

Signed-off-by: Maxime Ripard <mripard@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>

authored by

Maxime Ripard and committed by

Hans Verkuil 2 months ago 08f9794d 7b0288bc

+32 -9

1 changed file

expand all

drivers

media

platform

broadcom

bcm2835-unicam.c

+32 -9

drivers/media/platform/broadcom/bcm2835-unicam.c

··· 338 338 .csi_dt = MIPI_CSI2_DT_RGB565, 339 339 }, { 340 340 .fourcc = V4L2_PIX_FMT_RGB24, /* rgb */ 341 - .code = MEDIA_BUS_FMT_RGB888_1X24, 341 + .code = MEDIA_BUS_FMT_BGR888_1X24, 342 342 .depth = 24, 343 343 .csi_dt = MIPI_CSI2_DT_RGB888, 344 344 }, { 345 345 .fourcc = V4L2_PIX_FMT_BGR24, /* bgr */ 346 - .code = MEDIA_BUS_FMT_BGR888_1X24, 346 + .code = MEDIA_BUS_FMT_RGB888_1X24, 347 347 .depth = 24, 348 348 .csi_dt = MIPI_CSI2_DT_RGB888, 349 349 }, { ··· 2144 2144 const struct v4l2_pix_format *fmt = &node->fmt.fmt.pix; 2145 2145 const struct unicam_format_info *fmtinfo; 2146 2146 2147 - fmtinfo = unicam_find_format_by_fourcc(fmt->pixelformat, 2148 - UNICAM_SD_PAD_SOURCE_IMAGE); 2147 + fmtinfo = unicam_find_format_by_code(format->code, 2148 + UNICAM_SD_PAD_SOURCE_IMAGE); 2149 2149 if (WARN_ON(!fmtinfo)) { 2150 2150 ret = -EPIPE; 2151 2151 goto out; 2152 2152 } 2153 2153 2154 - if (fmtinfo->code != format->code || 2155 - fmt->height != format->height || 2154 + /* 2155 + * Unicam initially associated BGR24 to BGR888_1X24 and RGB24 to 2156 + * RGB888_1X24. 2157 + * 2158 + * In order to allow the applications using the old behaviour to 2159 + * run, let's accept the old combination, but warn about it. 2160 + */ 2161 + if (fmtinfo->fourcc != fmt->pixelformat) { 2162 + if ((fmt->pixelformat == V4L2_PIX_FMT_BGR24 && 2163 + format->code == MEDIA_BUS_FMT_BGR888_1X24) || 2164 + (fmt->pixelformat == V4L2_PIX_FMT_RGB24 && 2165 + format->code == MEDIA_BUS_FMT_RGB888_1X24)) { 2166 + dev_warn_once(node->dev->dev, 2167 + "Incorrect pixel format %p4cc for 0x%04x. Fix your application to use %p4cc.\n", 2168 + &fmt->pixelformat, format->code, &fmtinfo->fourcc); 2169 + } else { 2170 + dev_dbg(node->dev->dev, 2171 + "image: format mismatch: 0x%04x <=> %p4cc\n", 2172 + format->code, &fmt->pixelformat); 2173 + ret = -EPIPE; 2174 + goto out; 2175 + } 2176 + } 2177 + 2178 + if (fmt->height != format->height || 2156 2179 fmt->width != format->width || 2157 2180 fmt->field != format->field) { 2158 2181 dev_dbg(node->dev->dev, 2159 - "image: (%u x %u) 0x%08x %s != (%u x %u) 0x%08x %s\n", 2160 - fmt->width, fmt->height, fmtinfo->code, 2182 + "image: (%u x %u) %s != (%u x %u) %s\n", 2183 + fmt->width, fmt->height, 2161 2184 v4l2_field_names[fmt->field], 2162 - format->width, format->height, format->code, 2185 + format->width, format->height, 2163 2186 v4l2_field_names[format->field]); 2164 2187 ret = -EPIPE; 2165 2188 }

Configure Feed

Configure Feed