From nobody Fri Apr 3 03:15:14 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 4EFDB3EBF07; Tue, 17 Feb 2026 08:39:05 +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=1771317546; cv=none; b=ReoepZKweJM70vGKno1wJ2vqXPbqeYDuxdst7/mEDTyhKN9FEtuIRi4V7AyartTKbtXTM3QHmcWRno+q+zAVUytbDrIcfpOo7wbPGeMbtMtDFxRNx21XBvku3qKnV+r5RdhORyHD7utarW34qPbNtMbTrRahKV7plaW9aky3cSo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771317546; c=relaxed/simple; bh=rCXW6thZ22OoTYS2shR13ipLTwJKjj/uhfp7FYURAYU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=lzmr6R2z4CJ/m1iPcOK+VNtNWwrQQjYcGOsaXW8liqo4VPA84GJmoDolQ+7rw4ZILuGGdgg+E8Ahst0ptwuQhgAr9FbJhpZsEc1aeA5t++blNjqYQ4QqC56GzAIo7ZY2RLNtNGtWs3Oya3Vwtdu1BJvAwrHkA7/w9FMdSrjUE5I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bge9PSNe; 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="bge9PSNe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82ADBC4CEF7; Tue, 17 Feb 2026 08:39:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771317545; bh=rCXW6thZ22OoTYS2shR13ipLTwJKjj/uhfp7FYURAYU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=bge9PSNeoUwH3EtFvpPagNvm5FCvIyQGqhVzeXyLDoShBMfdAFjTxOmap8Vr1/6o5 qEP3xRuIhk+srx0pDjyZZXSpm6M4Bh3ZshC6cPTAnJG3W5zrgiqca/8VupUKS/I5JY gqoKTSAofEd4H32ca6yhGJ/3nBRMgA+ord2a6xK2x21Ucy/GB1GHffkwEVK4ISao7C Igtvu1yNm48OBUv3Yvk2NgEaC223odXmqmPZhLJkA8jUATSwnuTqJbESZuKmYB6gNI T12wVbDegb0pAQsQTwDHlSObtDAQ1sF3YdX3JxOHV2LT8vE9Q1YFNGIa8HKDs0aSOQ aoE29pw3WUMeQ== From: Maxime Ripard Date: Tue, 17 Feb 2026 09:38:57 +0100 Subject: [PATCH v6 1/2] media: uapi: Clarify MBUS color component order for serial buses 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-1-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=2565; i=mripard@redhat.com; h=from:subject:message-id; bh=rCXW6thZ22OoTYS2shR13ipLTwJKjj/uhfp7FYURAYU=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDJlTNJUf3uBUf/ZVpGp36oP9V93X8eo4du8NnhvCf0HL6 pWTj8uvjqksDMKcDLJiiixPZMJOL29fXOVgv/IHzBxWJpAhDFycAjCRzlzGWrlfa27bt1umV2Wz FfBlNb9MWhcfufzjtoVWrLmxMx6a6/LmRc1bZ7dl3Srxo9M4kgVTGBuOPFOf+pqR68Tui6eEmdp rt28Xlr4ikrN/C5OngqdL+uEsk2U1R7rKbxwzOlKQHDX/ayIA X-Developer-Key: i=mripard@redhat.com; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D The subdev format documentation has a subsection describing how to use the media bus pixel codes for serial buses. While it describes the sampling part well, it doesn't really describe the current convention used for the components order. Let's improve that. Signed-off-by: Maxime Ripard Reviewed-by: Laurent Pinchart --- .../userspace-api/media/v4l/subdev-formats.rst | 19 +++++++++++----= ---- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Doc= umentation/userspace-api/media/v4l/subdev-formats.rst index cf970750dd4c6ab32274f75453390eb8148ef3c6..6d57c325ffa506fd57dad0845c9= a742fd199a6f0 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -157,18 +157,21 @@ memory. While there is a relationship between image formats on buses and image 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. =20 -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. F= or -instance, both MEDIA_BUS_FMT_BGR888_1X24 and MEDIA_BUS_FMT_BGR888_3X8 are = used -on parallel busses for transferring an 8 bits per sample BGR data, whereas= on -serial busses the data in this format is only referred to using -MEDIA_BUS_FMT_BGR888_1X24. This is because there is effectively only a sin= gle -way to transport that format on the serial busses. +While the media bus pixel codes are named based on how pixels are +transmitted on parallel buses, serial buses do not define separate +codes. By convention, they use the codes that transfer a sample on a +single clock cycle. and whose names correspond to the order in which +colour components are transmitted on the serial bus. For instance, the +MIPI CSI-2 24-bit RGB (RGB888) format uses the MEDIA_BUS_FMT_RGB888_1X24 +media bus code because CSI-2 transmits the blue colour component first, +followed by green and red, and MEDIA_BUS_FMT_RGB888_1X24 defines the +first bit of blue at index 0. While used for 24-bit RGB data on parallel +buses, the MEDIA_BUS_FMT_RGB888_3X8 or MEDIA_BUS_FMT_BGR888_1X24 codes +must not be used for CSI-2. =20 Packed RGB Formats ^^^^^^^^^^^^^^^^^^ =20 Those formats transfer pixel data as red, green and blue components. The --=20 2.52.0 From nobody Fri Apr 3 03:15:14 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