From nobody Fri Apr 3 05:04:01 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E7652D97AA; Tue, 17 Feb 2026 08:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771317549; cv=none; b=Ri1ZAwODwcQiz9N1asNokX91gmLuKuY7nG8x1ToiTvkvuGPxz02vH4V7MYKSdm1/NTG5/F8CiNLz+U4HYdSs+GdZScnfN7gf+TlEeqZchuDqbhFM7IKQyhIYgW3PIYPe2p9Jsv3gzs6nOuZwBqQ4LNurwVZHgIa80iSHjKoLI5Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771317549; c=relaxed/simple; bh=Tp91x9TqhD35zOegm+OJH/4SKa8jd4LWFafw1/btbJc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=hZy5glZDT03U3YyhyabVjMU2sLgOxAQziOzLXTz9QRjxq4OEKp33lLgka4deg4YpO0rIEZnn5mpXMAsZU/+xtTmQEQqv7GU3xVepbTYRXfJSSstLI2vnAobggCI//xkrAunHG6bP13wzcYpKaEuLdULb+luSUD4Gjh+0sApDNdU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SqDgC4MC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SqDgC4MC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBD21C2BC86; Tue, 17 Feb 2026 08:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771317549; bh=Tp91x9TqhD35zOegm+OJH/4SKa8jd4LWFafw1/btbJc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=SqDgC4MCziDbBeXMmftaofkJFKELatSa5v38gJekRirjMNg3/Wa4rWp5ADCruX2Is Ub7PCkoiCIpmWQJE4Ye0eNZfcKDXzCZfZIv48gBLG8/DF7m+TPRP/6VAWynLnXpn2I y0FAsm+vrXlNK2zooKzvWTBH9HO/grGtrsyB8MBhNAKOKIrVOwuGDJt7J9SUeqEwaj ctKjrdnoljallYAOcAwjHmZXtIDuQI8F/Kf5FZb8zHyNpIGPEq5RAw/5p1WueN9nln 1l6ghHH29F68xpyKLnr6oK5+AWbL/t3ufyRwgaNlNWgGhpODs9DJVwSGjwqwlMSajy S2qh5+xYimLFw== From: Maxime Ripard Date: Tue, 17 Feb 2026 09:38:58 +0100 Subject: [PATCH v6 2/2] media: bcm2835-unicam: Fix RGB format / mbus code association Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260217-csi-bgr-rgb-v6-2-064607effe42@redhat.com> References: <20260217-csi-bgr-rgb-v6-0-064607effe42@redhat.com> In-Reply-To: <20260217-csi-bgr-rgb-v6-0-064607effe42@redhat.com> To: Mauro Carvalho Chehab , Sakari Ailus , Hans Verkuil , Laurent Pinchart Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Hans Verkuil , Dave Stevenson , Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4311; i=mripard@redhat.com; h=from:subject:message-id; bh=7vE1azt3GG4cI62AESkJAWUjyKm6TXjOqPzm/WP2EhM=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDJlTNJVvPlqx0j9P9OjfC5aP1z7edWvPqZm9K0RfvPP6Z /Zsw5H6yR1TWRiEORlkxRRZnsiEnV7evrjKwX7lD5g5rEwgQxi4OAVgIuuWMzZ8zjDam2y1N/qO o3CaykaluLeO05KEjpkG9Thuf9Xye9631YZnjvfVzOGWm2bkE+igwMPYsChUdlrxs5T9OrknH90 V3W+ksjPgnrjleqnAALeiuCrrz+tO3Xr+dZI2n1znWhVuH85rAA== X-Developer-Key: i=mripard@redhat.com; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D From: Maxime Ripard 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 Reviewed-by: Laurent Pinchart --- drivers/media/platform/broadcom/bcm2835-unicam.c | 43 +++++++++++++++++++-= ---- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/med= ia/platform/broadcom/bcm2835-unicam.c index f10064107d543caf867249d0566a0f42d6d8c4c6..648d81b741e258cc24075d5f959= 03ee748280695 100644 --- a/drivers/media/platform/broadcom/bcm2835-unicam.c +++ b/drivers/media/platform/broadcom/bcm2835-unicam.c @@ -340,16 +340,16 @@ static const struct unicam_format_info unicam_image_f= ormats[] =3D { .code =3D MEDIA_BUS_FMT_RGB565_1X16, .depth =3D 16, .csi_dt =3D MIPI_CSI2_DT_RGB565, }, { .fourcc =3D V4L2_PIX_FMT_RGB24, /* rgb */ - .code =3D MEDIA_BUS_FMT_RGB888_1X24, + .code =3D MEDIA_BUS_FMT_BGR888_1X24, .depth =3D 24, .csi_dt =3D MIPI_CSI2_DT_RGB888, }, { .fourcc =3D V4L2_PIX_FMT_BGR24, /* bgr */ - .code =3D MEDIA_BUS_FMT_BGR888_1X24, + .code =3D MEDIA_BUS_FMT_RGB888_1X24, .depth =3D 24, .csi_dt =3D MIPI_CSI2_DT_RGB888, }, { /* Bayer Formats */ .fourcc =3D V4L2_PIX_FMT_SBGGR8, @@ -2146,26 +2146,51 @@ static int unicam_video_link_validate(struct media_= link *link) =20 if (is_image_node(node)) { const struct v4l2_pix_format *fmt =3D &node->fmt.fmt.pix; const struct unicam_format_info *fmtinfo; =20 - fmtinfo =3D unicam_find_format_by_fourcc(fmt->pixelformat, - UNICAM_SD_PAD_SOURCE_IMAGE); + fmtinfo =3D unicam_find_format_by_code(format->code, + UNICAM_SD_PAD_SOURCE_IMAGE); if (WARN_ON(!fmtinfo)) { ret =3D -EPIPE; goto out; } =20 - if (fmtinfo->code !=3D format->code || - fmt->height !=3D format->height || + /* + * Unicam initially associated BGR24 to BGR888_1X24 and + * RGB24 to RGB888_1X24. + * + * In order to allow the applications using the old + * behaviour to run, let's accept the old combination, + * but warn about it. + */ + if (fmtinfo->fourcc !=3D fmt->pixelformat) { + if ((fmt->pixelformat =3D=3D V4L2_PIX_FMT_BGR24 && + format->code =3D=3D MEDIA_BUS_FMT_BGR888_1X24) || + (fmt->pixelformat =3D=3D V4L2_PIX_FMT_RGB24 && + format->code =3D=3D MEDIA_BUS_FMT_RGB888_1X24)) { + dev_warn_once(node->dev->dev, + "Incorrect pixel format %p4cc for 0x%04x. Fix your application = to use %p4cc.\n", + &fmt->pixelformat, format->code, &fmtinfo->fourcc); + } else { + dev_dbg(node->dev->dev, + "image: format mismatch: 0x%04x <=3D> %p4cc\n", + format->code, &fmt->pixelformat); + ret =3D -EPIPE; + goto out; + } + } + + + if (fmt->height !=3D format->height || fmt->width !=3D format->width || fmt->field !=3D format->field) { dev_dbg(node->dev->dev, - "image: (%u x %u) 0x%08x %s !=3D (%u x %u) 0x%08x %s\n", - fmt->width, fmt->height, fmtinfo->code, + "image: (%u x %u) %s !=3D (%u x %u) %s\n", + fmt->width, fmt->height, v4l2_field_names[fmt->field], - format->width, format->height, format->code, + format->width, format->height, v4l2_field_names[format->field]); ret =3D -EPIPE; } } else { const struct v4l2_meta_format *fmt =3D &node->fmt.fmt.meta; --=20 2.52.0