From nobody Wed Apr 1 20:46:28 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 1C1FF3D904D; Mon, 9 Mar 2026 15:07:49 +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=1773068869; cv=none; b=sgpD1tLzurK1jNZ9zLlCdEIaPQvxL/9n7S7XK+GjZo3Zg+zFZAZ/+5BZZ/HbtQcGoFuF6D8pj7RSlxoEEK55WFMymLSqsGJI6l/kQ8NwmuTpq+f+h2ayrrLhhY5YByKdIEFpMRf1kbIMqqV8NEbot2T6tG6escWaGJjGxBV3phY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773068869; c=relaxed/simple; bh=CZwlq1EGcKoXJMDg7FmmTtw7+Ec/bhNt3jcf1ddiTqk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=aON4HpQVpINk8vGP7OwEfpPWF3JOPesk2c1aimyWO2eA87ueGW1hkUyiML5V2mnt5c9WKZZ11NIx7gMVeaCaJB35w22KfEJ8v41+G+ynFzdGEZKONevGLgc9iX1YcTWYVH93uHY+vywm6eRGExS2kGxCVN1yn1BJlf+IoXRCiU0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=J6UgEhyM; 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="J6UgEhyM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BCB7C2BC86; Mon, 9 Mar 2026 15:07:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773068869; bh=CZwlq1EGcKoXJMDg7FmmTtw7+Ec/bhNt3jcf1ddiTqk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=J6UgEhyM7hMuZZiLUV5ODzsdzcyh8vPV1lYDLJnX+5At5bwjDlYOFYmO2Bvxi7CM5 h1I9tc2wZhdVUc04wAZJRjoKoRwLMEIyqMju4L/xYFgwsH7wHZw07UesSZQ7As822S jLCapPbYe7rndqSLc8M0M0WTg9DHRCTycZwawntceWlkdt8mingdUbUys2oYiQ+72P V9H9OsfbCiRavdMPiL5dfAmHVeBmYzj5TeTBMM/daEWPEFAn+bzjtlOr70bhnxoC6h t/UPODP+vNxI3hMMRFaheevxpqZH9noUB1JCom8MzyUXZCvkE1jKS/Dhuoa+OLYf/w ccsVXwDAimzXA== From: Maxime Ripard Date: Mon, 09 Mar 2026 16:07:40 +0100 Subject: [PATCH v7 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: <20260309-csi-bgr-rgb-v7-1-fcee993b13d8@kernel.org> References: <20260309-csi-bgr-rgb-v7-0-fcee993b13d8@kernel.org> In-Reply-To: <20260309-csi-bgr-rgb-v7-0-fcee993b13d8@kernel.org> 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=2653; i=mripard@kernel.org; h=from:subject:message-id; bh=CZwlq1EGcKoXJMDg7FmmTtw7+Ec/bhNt3jcf1ddiTqk=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDJnrHtlZaSzyn71G5yGXmcZa2XzXd1XlzxtqXkZ/u5V3w nYaq8LGjqksDMKcDLJiiixPZMJOL29fXOVgv/IHzBxWJpAhDFycAjAR9zOMDY+28j34GJZekNvV uVYz/nf7qUa9aVJyrZO84lSfSRj76a+IWvO9/Jr7rxmHpxZvmXKYkbFhYvfsgOvGjd8296i4aez U/Ws/heXz/H+LbHN0IoyPMWevzFnq/EHmgstPl5kfND/c4vsLAA== X-Developer-Key: i=mripard@kernel.org; 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. Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard --- .../userspace-api/media/v4l/subdev-formats.rst | 20 ++++++++++++----= ---- 1 file changed, 12 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 896177c5334fe0f3526550b9852508f786e95652..c9999b929773b244290b16280b1= 80a9d4f0ff609 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -157,18 +157,22 @@ 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 bit orders from LSB to MSB 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 bit 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.53.0 From nobody Wed Apr 1 20:46:28 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 699653D904D; Mon, 9 Mar 2026 15:07:52 +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=1773068872; cv=none; b=YpqHkKMHW8czEqweLJk7vOyBvZpkxORm2U8bASUcs2F5qQWoly64QXzfKLuA4JUJ/mBuQJA3RHUxBmHoOvbTjuHkpAZTtWUof3fU1sd4Por9aLd4bflT2zAlgmmSYu+A/k8liminGffMOTBQUinU5iaqgJAPmLU69c9Uj73a1hI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773068872; c=relaxed/simple; bh=dP0IsHglcQ6dTUsG1KV+cQUMQBqUC70co6D60KK1tgk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=iNAgbb3WVKOk4s4NjfSR861AuiKYh56iBYNvlsWC3upRw1bmD8Uks4AiwQCGqvjbsNzfpWwOwwEJz0PRF2IpZer5729tMkvrxoEVD6Fobq+nNzTx1wYeTDSUo9shUDlKmW8AU4L3NUxOlPYEGMJXqgcr4GIE56BOiid/Y4ypsH4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k28Ig3qt; 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="k28Ig3qt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFBC7C4CEF7; Mon, 9 Mar 2026 15:07:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773068872; bh=dP0IsHglcQ6dTUsG1KV+cQUMQBqUC70co6D60KK1tgk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=k28Ig3qt5ryQeriln0WYd6BrZm8DPNDnmDLLxVyq3u74a5bb509cokeJzEpqI/hpz vj0oaF2xMbKulJBmjWzyuYOJ5Jbh0J6+HdmeU+f3HbiDjJUZZjB2llF9WRQj41I8vX 4lG1fe/C7jX8p7S5QUmNi0PmTmJfIkW0KQOtrwyd+B7LnVtYDcoSHIJ6R7MeaXvXEB xJvvvUlY6cohOQe0bbn0DTVAm3JNQT1Zpf0vGyHNgac0/FWtLhWygSRa4mc6cHvROX BMIT4CzxXz3Ys1pb6CIJjdi/5KD7llBlOeeYEUFZGe3Smj3Kg8P3jFaeNNeSHJ5sJS n5M1L5+gNbg1w== From: Maxime Ripard Date: Mon, 09 Mar 2026 16:07:41 +0100 Subject: [PATCH v7 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: <20260309-csi-bgr-rgb-v7-2-fcee993b13d8@kernel.org> References: <20260309-csi-bgr-rgb-v7-0-fcee993b13d8@kernel.org> In-Reply-To: <20260309-csi-bgr-rgb-v7-0-fcee993b13d8@kernel.org> 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=4368; i=mripard@kernel.org; h=from:subject:message-id; bh=8sVTwa7Od27sQ3Z6DtUhRhIovDZYi2OMVB5yjCX2V6Y=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDJnrHtn57rv8R5bhypVDnEVyCT02j23KipKOLqvivrjor d7GbcfdOqayMAhzMsiKKbI8kQk7vbx9cZWD/cofMHNYmUCGMHBxCsBE5q1lbHjZ8GuXfKanXaDQ Zp7l9lFiB75szdVZI3nC4MaS1B9sX66rnVbZdqH1uYDDd7Gu6AeH/zA2rNpitzbTzuZL4oQPNr2 5c89nzXfVmrqKafPKO13b9rFmsAT+6FnLcXdyrN8EV+OjnLf9AQ== X-Developer-Key: i=mripard@kernel.org; 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 | 41 ++++++++++++++++++--= ---- 1 file changed, 32 insertions(+), 9 deletions(-) diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/med= ia/platform/broadcom/bcm2835-unicam.c index 53a342853be6eeb99d62a777e2db41de8ce5da92..6710617f6e52c0f3716fd70c5b8= af06c2dce31da 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,49 @@ 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.53.0