From nobody Thu Dec 18 01:19:34 2025 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 5AEE626980E; Mon, 13 Oct 2025 11:01:39 +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=1760353300; cv=none; b=BOtffSIxB54SYzDkbKZmH+fn/YH8DCbhHzsztTgThFcvAxg+2NChV20xQS1PR3JtKmJeomhRoEexKc4KpvDQlIbcePFEVR9tfIF2qhek2oExZZQBee0c2qyz9bu7wIN1Xa2uHFrwh4sbJc/oLa5WN4ljuC+thKr26eW+LmEkG7s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760353300; c=relaxed/simple; bh=+z+Ke/wL3drYAMEVfttRbXzJ7JvbhYEKSbH29MXPYEo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=UM6Fo3Lq0HwqETigxUnKVG/BZiyEPAm+f7AhQrV9OQULz7U4c2tRZwZolsm1vHAlVXreJDIHnIzPwFTKR00dnJXxGCZigZlcpERP972zsWHUEHvPOhpaKqXjWRT2O7KzrBGQgQtKY7MJIjMTvhSitpEscORQdUEI59CIjgQPc0U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nSkTTk3z; 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="nSkTTk3z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D7E2C4CEF8; Mon, 13 Oct 2025 11:01:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760353299; bh=+z+Ke/wL3drYAMEVfttRbXzJ7JvbhYEKSbH29MXPYEo=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=nSkTTk3zAQWigZKVt8rQnuwdU11zfpGq88gvYNwBbyR8d7H1VFf+uEXC7DRQtgc9i zWWpLPqj/GmIR/NyeaAXxE4bDY2JVnhCkp91lStD8jkfJW/iaXEN+CpNhKU+5vNou7 W+F3LmxPDx6/xhL2xepLgGs7Zt5JbE8QO4uiFQRlgj/cJPK9eMY9jVCTY5n/9l+LUf Q9kc22BcchQDewtStauRI0R3q/c/Ss9dm9yFj5TVDt2BNhdk6EQodP9PfwiezN5yfh Wix3UomvdJstet05ELiQfyb4pwSd5gJZ8EeyD4ijWZhln+z2z66bn+06hqdAdhoo2D Zo+6ahZ8N2QCw== From: Maxime Ripard Date: Mon, 13 Oct 2025 13:01:33 +0200 Subject: [PATCH v4 1/4] 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: <20251013-csi-bgr-rgb-v4-1-55eab2caa69f@kernel.org> References: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> In-Reply-To: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> To: Mauro Carvalho Chehab , Mats Randgaard , Alain Volmat , 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 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 --- Documentation/userspace-api/media/v4l/subdev-formats.rst | 14 ++++++++----= -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Doc= umentation/userspace-api/media/v4l/subdev-formats.rst index 2a94371448dc07e5c7097421bd82f42dcd7e21aa..8e92f784abd8123f9ea950f954a= 60af56ee76dbe 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -158,16 +158,18 @@ formats in memory (a raw Bayer image won't be magical= ly 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. +parallel format that transfers a sample on a single clock cycle is used. T= he +color component order used is the same used on the serial bus. For instanc= e, +both MEDIA_BUS_FMT_BGR888_1X24 and MEDIA_BUS_FMT_BGR888_3X8 are used on pa= rallel +busses for transferring an 8 bits per sample BGR data, whereas on serial b= usses +the data in this format is only referred to using MEDIA_BUS_FMT_BGR888_1X2= 4, +with BGR meaning that the blue component is transmitted first, then green,= then +red. This is because there is effectively only a single way to transport t= hat +format on the serial busses. =20 Packed RGB Formats ^^^^^^^^^^^^^^^^^^ =20 Those formats transfer pixel data as red, green and blue components. The --=20 2.51.0 From nobody Thu Dec 18 01:19:34 2025 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 29D522FE04B; Mon, 13 Oct 2025 11:01:42 +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=1760353303; cv=none; b=guxbc5Sm/GHab0+JZyfQ/viP+Wo1KZ1SKBA3GkoMNkxNnqX0An3D7qwFgvUuRakGC6Hq1kYSmfVTK9J+LsegtjLs2G+8IJjR/6fzepV5nCz67n4jV2N5zFU3rP2Aq+LH/In+0eIFt91fhTnOHzHSmqKIBlrnK26y2NAKjrJkjAY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760353303; c=relaxed/simple; bh=OSJKqhSnjtFatFa6KNC2h4Y0AyZr1O5YS3bNSMqBTYk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ZR+uOTaKTrduSS3Z/KSuKPCokN3wgLOM6Y+KD91IjdH2kLBp7C1e07zK02+Rq/aX/9inMHjtJ5JwksX8wu0lilhr9qH3282eZJVPHYjF4z3IjMXS4L+PacUPv0g72RYfIPCoaT6XIRpmnM1b8ZPTUUt3l2xnEXR611tkqYyqy90= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PkkKTSJL; 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="PkkKTSJL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48B7AC4CEF8; Mon, 13 Oct 2025 11:01:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760353302; bh=OSJKqhSnjtFatFa6KNC2h4Y0AyZr1O5YS3bNSMqBTYk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=PkkKTSJL8lXXA+pnGiIUVTTeouxHGklxQKwGHwVuErfeyzEhFLMBBf/ZfKAtpZm7C B2WR3P12xIIw/JPIxEhFC+EodH/AY59wENypW/fZUyOxBqsktFCs/w/Hs0xxbO2piv OcmxyRbNxQDrP3ts91u2QlO3YyeKEHV5A5v8nihnuja1slbD3t0Cz5K2Ggp/g4kFyA WEP7ng5ahPNoWeoSUtvE9eI1lMcE0ufXVO2g5Y1JVu/joQ7JjvMMoxQLUzCPBVv7J4 vtwj4GSB3b1Gyu5zelVGtwFYQfDKNT49/V21svhpkt4UQa3qZeiYqMnvny7rHXQIU2 EmaUFwMHldC+A== From: Maxime Ripard Date: Mon, 13 Oct 2025 13:01:34 +0200 Subject: [PATCH v4 2/4] media: uapi: Introduce MEDIA_BUS_FMT_BGR565_1X16 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: <20251013-csi-bgr-rgb-v4-2-55eab2caa69f@kernel.org> References: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> In-Reply-To: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> To: Mauro Carvalho Chehab , Mats Randgaard , Alain Volmat , 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 MIPI-CSI2 sends its RGB format on the wire with the blue component first, then green, then red. MIPI calls that format "RGB", but by v4l2 conventions it would be BGR. MIPI-CSI2 supports three RGB variants: 444, 555, 565, 666 and 888. We already have BGR666 and BGR888 media bus formats, we don't have any CSI transceivers using the 444 and 555 variants, but some transceivers use the CSI RGB565 format, while using the RGB565 media bus code. That's a mistake, but since we don't have a BGR565 media bus code we need to introduce one before fixing it. Signed-off-by: Maxime Ripard --- .../userspace-api/media/v4l/subdev-formats.rst | 37 ++++++++++++++++++= ++++ include/uapi/linux/media-bus-format.h | 3 +- 2 files changed, 39 insertions(+), 1 deletion(-) diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Doc= umentation/userspace-api/media/v4l/subdev-formats.rst index 8e92f784abd8123f9ea950f954a60af56ee76dbe..def0d24ef6cdb1a2ec9395af146= 8f56adf31a8de 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -625,10 +625,47 @@ The following tables list existing packed RGB formats. - b\ :sub:`4` - b\ :sub:`3` - b\ :sub:`2` - b\ :sub:`1` - b\ :sub:`0` + * .. _MEDIA-BUS-FMT-BGR565-1X16: + + - MEDIA_BUS_FMT_BGR565_1X16 + - 0x1028 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` * .. _MEDIA-BUS-FMT-BGR565-2X8-BE: =20 - MEDIA_BUS_FMT_BGR565_2X8_BE - 0x1005 - diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/med= ia-bus-format.h index ff62056feed5b6588bfcfdff178f5b68eecd3a26..a73d91876d31844bf8c2da91dde= a541181840bd2 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -32,17 +32,18 @@ * new pixel codes. */ =20 #define MEDIA_BUS_FMT_FIXED 0x0001 =20 -/* RGB - next is 0x1028 */ +/* RGB - next is 0x1029 */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE 0x1004 #define MEDIA_BUS_FMT_RGB565_1X16 0x1017 +#define MEDIA_BUS_FMT_BGR565_1X16 0x1028 #define MEDIA_BUS_FMT_BGR565_2X8_BE 0x1005 #define MEDIA_BUS_FMT_BGR565_2X8_LE 0x1006 #define MEDIA_BUS_FMT_RGB565_2X8_BE 0x1007 #define MEDIA_BUS_FMT_RGB565_2X8_LE 0x1008 #define MEDIA_BUS_FMT_RGB666_1X18 0x1009 --=20 2.51.0 From nobody Thu Dec 18 01:19:34 2025 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 52F6D2FE04B; Mon, 13 Oct 2025 11:01:45 +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=1760353306; cv=none; b=dE1iTUSVAyU4Th+2f2FHds+f6Hc4l8EG6Bg6HCgPuAab8yfLL2f6PyNpksKzRoMcl91ZZVjAehsix5mLPgyIfTf+IX6dI7YetTMuWOGmRjehW7vLbIIFIKAOC9r8YM7R53wdb3thoq+E91S1CCTo4ewo8XGQi0Khp+TByJ7twOQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760353306; c=relaxed/simple; bh=uAibvNMvVnfTLnJ52wJT1Y/7MsQaryuDWSeF/uvqKDk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DgD7YQemonwu5COdw5Ni7vlA1/e8FxYtc0pna3tZ2IXKsz1wjOJOcltpYIg/R3ZAhuzuPLbsKGBr/TSuErxtUE+eC0JB7qPffgWwon2+n2Hult1/Kog9n/LuXjLG9Nfy66HGXj1fKBU0ivRnQjh3EQZE+9WvILoPow2zpi38hdY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BVaZymAn; 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="BVaZymAn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B6C0C4CEF8; Mon, 13 Oct 2025 11:01:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760353305; bh=uAibvNMvVnfTLnJ52wJT1Y/7MsQaryuDWSeF/uvqKDk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=BVaZymAn8M170COO5FxCHAzbGasw4dvw2PBqv5JhOpdOcMHr8bxMKHv7+Uid2Rdgw uy7r+jbO5Bje1o4ESHKWtULgxrUoh7qTP4ebuO16+vG35tLV/YQExxeF80m2xWaA+m DjuLqOiW4zaG3Rv1PAtLIKpLcMqK3nmPq02szeUyJsbKjf85IP5Q9qiQiQy9gHPW0C CgWWM1gOx++123rUHfN6Pm0g0gVWVxYRNSPLC2SwENFDD84sI0qk+/Jl/1GWx/n1mm 5LcJNDW4GhyQLrTjK2aL56s1Qmsn+k+NNpJvCi7u0clBPMcZtH108vFMuZ6u4rVGPM 4s/x8tWItk3tw== From: Maxime Ripard Date: Mon, 13 Oct 2025 13:01:35 +0200 Subject: [PATCH v4 3/4] media: tc358743: Fix the RGB MBUS format 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: <20251013-csi-bgr-rgb-v4-3-55eab2caa69f@kernel.org> References: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> In-Reply-To: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> To: Mauro Carvalho Chehab , Mats Randgaard , Alain Volmat , 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 The tc358743 is an HDMI to MIPI-CSI2 bridge. It can output all three HDMI 1.4 video formats: RGB 4:4:4, YCbCr 4:2:2, and YCbCr 4:4:4. RGB 4:4:4 is converted to the MIPI-CSI2 RGB888 video format, and listed in the driver as MEDIA_BUS_FMT_RGB888_1X24. Most CSI2 receiver drivers then map MEDIA_BUS_FMT_RGB888_1X24 to V4L2_PIX_FMT_RGB24. 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. This essentially means that the R and B will be swapped compared to what V4L2_PIX_FMT_RGB24 defines. The proper MBUS format would be BGR888, so let's use that. Fixes: d32d98642de6 ("[media] Driver for Toshiba TC358743 HDMI to CSI-2 bri= dge") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Tested-by: Dave Stevenson --- drivers/media/i2c/tc358743.c | 53 ++++++++++++++++++++++++++++++++++++----= ---- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c index a0ca19359c43145988535d7816012ef607555b87..feb089d8de724dd25801a0fb621= c768542e05254 100644 --- a/drivers/media/i2c/tc358743.c +++ b/drivers/media/i2c/tc358743.c @@ -754,10 +754,11 @@ static void tc358743_set_ref_clk(struct v4l2_subdev *= sd) } =20 static void tc358743_set_csi_color_space(struct v4l2_subdev *sd) { struct tc358743_state *state =3D to_state(sd); + struct device *dev =3D &state->i2c_client->dev; =20 switch (state->mbus_fmt_code) { case MEDIA_BUS_FMT_UYVY8_1X16: v4l2_dbg(2, debug, sd, "%s: YCbCr 422 16-bit\n", __func__); i2c_wr8_and_or(sd, VOUT_SET2, @@ -769,11 +770,21 @@ static void tc358743_set_csi_color_space(struct v4l2_= subdev *sd) i2c_wr16_and_or(sd, CONFCTL, ~MASK_YCBCRFMT, MASK_YCBCRFMT_422_8_BIT); mutex_unlock(&state->confctl_mutex); break; case MEDIA_BUS_FMT_RGB888_1X24: - v4l2_dbg(2, debug, sd, "%s: RGB 888 24-bit\n", __func__); + /* + * The driver was initially introduced with RGB888 + * support, but CSI really means BGR. + * + * Since we might have applications that would have + * hard-coded the RGB888, let's support both. + */ + dev_warn_once(dev, "RGB format isn't actually supported by the hardware.= The application should be fixed to use BGR."); + fallthrough; + case MEDIA_BUS_FMT_BGR888_1X24: + v4l2_dbg(2, debug, sd, "%s: BGR 888 24-bit\n", __func__); i2c_wr8_and_or(sd, VOUT_SET2, ~(MASK_SEL422 | MASK_VOUT_422FIL_100) & 0xff, 0x00); i2c_wr8_and_or(sd, VI_REP, ~MASK_VOUT_COLOR_SEL & 0xff, MASK_VOUT_COLOR_RGB_FULL); @@ -1430,15 +1441,30 @@ static int tc358743_log_status(struct v4l2_subdev *= sd) (i2c_rd16(sd, CSI_STATUS) & MASK_S_RXACT) ? "yes" : "no"); v4l2_info(sd, "Stopped: %s\n", (i2c_rd16(sd, CSI_STATUS) & MASK_S_HLT) ? "yes" : "no"); - v4l2_info(sd, "Color space: %s\n", - state->mbus_fmt_code =3D=3D MEDIA_BUS_FMT_UYVY8_1X16 ? - "YCbCr 422 16-bit" : - state->mbus_fmt_code =3D=3D MEDIA_BUS_FMT_RGB888_1X24 ? - "RGB 888 24-bit" : "Unsupported"); + + switch (state->mbus_fmt_code) { + case MEDIA_BUS_FMT_BGR888_1X24: + /* + * The driver was initially introduced with RGB888 + * support, but CSI really means BGR. + * + * Since we might have applications that would have + * hard-coded the RGB888, let's support both. + */ + case MEDIA_BUS_FMT_RGB888_1X24: + v4l2_info(sd, "Color space: BGR 888 24-bit\n"); + break; + case MEDIA_BUS_FMT_UYVY8_1X16: + v4l2_info(sd, "Color space: YCbCr 422 16-bit\n"); + break; + default: + v4l2_info(sd, "Color space: Unsupported\n"); + break; + } =20 v4l2_info(sd, "-----%s status-----\n", is_hdmi(sd) ? "HDMI" : "DVI-D"); v4l2_info(sd, "HDCP encrypted content: %s\n", hdmi_sys_status & MASK_S_HDCP ? "yes" : "no"); v4l2_info(sd, "Input color space: %s %s range\n", @@ -1771,24 +1797,32 @@ static int tc358743_enum_mbus_code(struct v4l2_subd= ev *sd, struct v4l2_subdev_state *sd_state, struct v4l2_subdev_mbus_code_enum *code) { switch (code->index) { case 0: - code->code =3D MEDIA_BUS_FMT_RGB888_1X24; + code->code =3D MEDIA_BUS_FMT_BGR888_1X24; break; case 1: code->code =3D MEDIA_BUS_FMT_UYVY8_1X16; break; + case 2: + /* + * We need to keep RGB888 for backward compatibility, + * but we should list it last for userspace to pick BGR. + */ + code->code =3D MEDIA_BUS_FMT_RGB888_1X24; + break; default: return -EINVAL; } return 0; } =20 static u32 tc358743_g_colorspace(u32 code) { switch (code) { + case MEDIA_BUS_FMT_BGR888_1X24: case MEDIA_BUS_FMT_RGB888_1X24: return V4L2_COLORSPACE_SRGB; case MEDIA_BUS_FMT_UYVY8_1X16: return V4L2_COLORSPACE_SMPTE170M; default: @@ -1822,11 +1856,12 @@ static int tc358743_set_fmt(struct v4l2_subdev *sd, struct tc358743_state *state =3D to_state(sd); =20 u32 code =3D format->format.code; /* is overwritten by get_fmt */ int ret =3D tc358743_get_fmt(sd, sd_state, format); =20 - if (code =3D=3D MEDIA_BUS_FMT_RGB888_1X24 || + if (code =3D=3D MEDIA_BUS_FMT_BGR888_1X24 || + code =3D=3D MEDIA_BUS_FMT_RGB888_1X24 || code =3D=3D MEDIA_BUS_FMT_UYVY8_1X16) format->format.code =3D code; format->format.colorspace =3D tc358743_g_colorspace(format->format.code); =20 if (ret) @@ -2242,11 +2277,11 @@ static int tc358743_probe(struct i2c_client *client) sd->entity.function =3D MEDIA_ENT_F_VID_IF_BRIDGE; err =3D media_entity_pads_init(&sd->entity, 1, &state->pad); if (err < 0) goto err_hdl; =20 - state->mbus_fmt_code =3D MEDIA_BUS_FMT_RGB888_1X24; + state->mbus_fmt_code =3D MEDIA_BUS_FMT_BGR888_1X24; =20 sd->dev =3D &client->dev; =20 mutex_init(&state->confctl_mutex); =20 --=20 2.51.0 From nobody Thu Dec 18 01:19:34 2025 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 3D66930597C; Mon, 13 Oct 2025 11:01:48 +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=1760353309; cv=none; b=lszhDEz94mGNBLhgk5Lbra6dCxj9tOZ34j6RELY98qvYebjwqDVV1c6A4f0zyQtzL64pXUG3WhvQA/VB9f0UmRdnqFTw/Xka+3My+8BIeOWHbHrTfo4sLtj1xgnRPECFTTt6X9lcVJCbEIMZo1WfXYBv6l350Cxw3UrylsKXKnY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760353309; c=relaxed/simple; bh=iJSBhGjVFS2FVaaRfzW2soMJOd6n5yz2PYztK0cwd4o=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=IMYPnauaL2dgAEhcJc5SKtJ0mXNqKq+YZROrTlQs9D3QTDBypfbXrW+iTq3bGLXUQnNJgglAICBUjevD9KW6ijAS7I7k3R/KQUFlNXhiQILHHHV5YEUA7x7XoLi123vkCNdn0blTVfvLJnyiikE8coGT5xpxGnQOQqApvJJFIP0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qYHE+Ell; 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="qYHE+Ell" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DBE6C4CEE7; Mon, 13 Oct 2025 11:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760353308; bh=iJSBhGjVFS2FVaaRfzW2soMJOd6n5yz2PYztK0cwd4o=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=qYHE+EllJhmRU+D56qVc+dAOrylJIHOKGzpINrZEig247PthLBHRyUI4i9k9kTQ4a xSGGd0UBCiv+NLrmrhB53L9QD63R11IoUn7917laDAhtS1g/lLloAR59PbYKAqBSVi 8f6Y0OqTyhSQuai+GGiv/uYI+c8ea3NMX9AIQYaXf1Hg45gln+58dkvD6AmnepXEMl SWbxO6eD8sTcuXTf5n/UMpfK9mfUo87xCgcxjaKMb0SawmvScKWz/HBbl+L2oWxL9E o2C/3jVkRXLbA+t4sDZQ12zeSplEfdBOsE02bJo6ZX39XEotqyd2kt4OL4fTdvSgOB YV3cbGST/I72g== From: Maxime Ripard Date: Mon, 13 Oct 2025 13:01:36 +0200 Subject: [PATCH v4 4/4] media: gc2145: Fix the RGB MBUS format 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: <20251013-csi-bgr-rgb-v4-4-55eab2caa69f@kernel.org> References: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> In-Reply-To: <20251013-csi-bgr-rgb-v4-0-55eab2caa69f@kernel.org> To: Mauro Carvalho Chehab , Mats Randgaard , Alain Volmat , 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 The GalaxyCore GC2145 is an MIPI-CSI2 sensor. Among others, it support the MIPI-CSI2 RGB565 format, listed in the driver as MEDIA_BUS_FMT_RGB565_1X16. Most CSI2 receiver drivers then map MEDIA_BUS_FMT_RGB565_1X16 to V4L2_PIX_FMT_RGB565. However, V4L2_PIX_FMT_RGB565 is defined as having its color components in the R, G and B order, from left to right. MIPI-CSI2 however defines the RGB565 format with blue first. This essentially means that the R and B will be swapped compared to what V4L2_PIX_FMT_RGB565 defines. The proper MBUS format would be BGR565, so let's use that. Fixes: 03cc7fefbb09 ("media: i2c: gc2145: Galaxy Core GC2145 sensor support= ") Signed-off-by: Maxime Ripard --- drivers/media/i2c/gc2145.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/gc2145.c b/drivers/media/i2c/gc2145.c index b215963a2648b7423fc0ca42b300b6c586d2b994..3c179ccf19cd7ed016699d4de4e= b81271c1e11ab 100644 --- a/drivers/media/i2c/gc2145.c +++ b/drivers/media/i2c/gc2145.c @@ -579,11 +579,11 @@ static const struct gc2145_format supported_formats[]= =3D { .colorspace =3D V4L2_COLORSPACE_SRGB, .datatype =3D MIPI_CSI2_DT_YUV422_8B, .output_fmt =3D 0x03, }, { - .code =3D MEDIA_BUS_FMT_RGB565_1X16, + .code =3D MEDIA_BUS_FMT_BGR565_1X16, .colorspace =3D V4L2_COLORSPACE_SRGB, .datatype =3D MIPI_CSI2_DT_RGB565, .output_fmt =3D 0x06, .switch_bit =3D true, }, @@ -613,10 +613,25 @@ static const struct gc2145_format supported_formats[]= =3D { .colorspace =3D V4L2_COLORSPACE_RAW, .datatype =3D MIPI_CSI2_DT_RAW8, .output_fmt =3D 0x17, .row_col_switch =3D GC2145_SYNC_MODE_ROW_SWITCH, }, + { + /* + * The driver was initially introduced with RGB565 support, but + * CSI really means BGR. + * + * Since we might have applications that would have hard-coded + * the RGB565, let's support both, with RGB being last to make + * sure it's only a last resort. + */ + .code =3D MEDIA_BUS_FMT_RGB565_1X16, + .colorspace =3D V4L2_COLORSPACE_SRGB, + .datatype =3D MIPI_CSI2_DT_RGB565, + .output_fmt =3D 0x06, + .switch_bit =3D true, + }, }; =20 struct gc2145_ctrls { struct v4l2_ctrl_handler handler; struct v4l2_ctrl *pixel_rate; @@ -658,12 +673,17 @@ static inline struct v4l2_subdev *gc2145_ctrl_to_sd(s= truct v4l2_ctrl *ctrl) } =20 static const struct gc2145_format * gc2145_get_format_code(struct gc2145 *gc2145, u32 code) { + struct i2c_client *client =3D v4l2_get_subdevdata(&gc2145->sd); unsigned int i; =20 + if (code =3D=3D MEDIA_BUS_FMT_RGB565_1X16) + dev_warn_once(&client->dev, + "RGB format isn't actually supported by the hardware. The applica= tion should be fixed to use BGR."); + for (i =3D 0; i < ARRAY_SIZE(supported_formats); i++) { if (supported_formats[i].code =3D=3D code) break; } =20 @@ -696,11 +716,11 @@ static int gc2145_init_state(struct v4l2_subdev *sd, struct v4l2_rect *crop; =20 /* Initialize pad format */ format =3D v4l2_subdev_state_get_format(state, 0); gc2145_update_pad_format(gc2145, &supported_modes[0], format, - MEDIA_BUS_FMT_RGB565_1X16, + MEDIA_BUS_FMT_BGR565_1X16, V4L2_COLORSPACE_SRGB); =20 /* Initialize crop rectangle. */ crop =3D v4l2_subdev_state_get_crop(state, 0); *crop =3D supported_modes[0].crop; --=20 2.51.0