From nobody Wed Apr 1 22:06:52 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