From nobody Fri Apr 3 05:06:34 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