From nobody Tue Sep 29 07:00:06 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 D8EE3411A08; Tue, 11 Aug 2026 09:17:14 +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=1786439834; cv=none; b=aOb7OnDkHGRXTJ+6bzq2gXD2SvS9GBd/fPbtCr/+Jn2aA0lA2kVd3GU/h8Lg+sxLwxysr5Fc7nf6At07F4VpjP6ePGihQrM53DDddC1FgLcCFDUZTQDwj+rBAskSkJFR2BZQpcaJJSXIPp8JOx5bdva+2S0Wzokd7t6XPsIfalI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786439834; c=relaxed/simple; bh=DWJSKzFD6cakpJcZ646iHbt5JA/PgGMBrolZ4fqvzIg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=X6nNTjuUZ2dpgKIJHoGCe+li+1yH5LhKd+67GcioHJNpARPzFRIRNbrG8/xn4C70eT9x8w2cZICwsum1G1jVLXyqWxMvF26c9DNyQcRQABa96gq256u7gbTQFwA08BtY0I9eIB1fFJPezOOGgiL4qhbf98Q/d7XI/xB1qpocb0Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nXD7k50P; 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="nXD7k50P" Received: by smtp.kernel.org (Postfix) with ESMTPS id 5C00CC2BCF4; Tue, 11 Aug 2026 09:17:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786439834; bh=DWJSKzFD6cakpJcZ646iHbt5JA/PgGMBrolZ4fqvzIg=; h=From:Date:Subject:To:Cc:Reply-To:From; b=nXD7k50PLScODjY6lMjbfASFHhsxr/d8ksu1HCUzP0etYjD56BJ6T1shqcZ3eC6u6 zsM77uHQHkzK3F9lBr/lGWPGaxYn9Pw8UJTie9Bu1okEmTIh4mcWqUEjNAVsX7ZxC+ /JtXiY/S17on0+lwaQQmRoUzgPcH/Tvuk1dBjRDabVmlSHtdolCsvK7QlpNx0Emw0s 9XC9aGt70lixTbMmjtzpqoviWVNoFCCTqycDlin8RCAoFyUzFcMFWmlULpLcT90W5Z 1qLvUuCLsn3kglg8tGPOhsE7efY6HbQ2PngChaHVHk4A7pRtVJ07a3ewPXTLvcE+F2 tGn8YHLvErlIQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48AB1C5CFC1; Tue, 11 Aug 2026 09:17:14 +0000 (UTC) From: Jason Yang via B4 Relay Date: Tue, 11 Aug 2026 17:17:13 +0800 Subject: [PATCH v4] media: ov5640: select the MIPI lane mode from the endpoint lane count 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: <20260811-ov5640-1lane-v1-v4-1-c4a05d4c1b32@gmail.com> X-B4-Tracking: v=1; b=H4sIAJjoemoC/4XNTQqDMBAF4KtI1k3Jf7Sr3qN0EeNEA2pKUkKLe PdGV6VQhNm8B9+bBSWIHhK6VAuKkH3yYS5BnCpkBzP3gH1XMmKEKVJTikOWShBMRzMDzhS3xAH XYFrR1aioRwTnX/vi7V7y4NMzxPf+INOt/b9VjmLdqKYRUlug/NpPxo9nGya0bWV24FnxSjIiD dTKQfvr+YHnxRsQWoFxkjDx7dd1/QCz0QtHLgEAAA== To: Steve Longerbeam , Sakari Ailus , Mauro Carvalho Chehab Cc: Hans Verkuil , Jacopo Mondi , Kieran Bingham , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Jason Yang X-Mailer: b4 0.13.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1786439833; l=4169; i=jason98166@gmail.com; s=20260721; h=from:subject:message-id; bh=PfLhiPr2yUVO8SISKIeOPSSSLsQZ2XmMhRZ2vtARP8M=; b=EblIwyv8nL4KOhfFsYbHzg/6PSpCqoDi2yJ2ZuJsKCDSXmCcpuzLKOwuNW3JrWaleLzU12cF0 T4+xnHGgwPLC+8U2cO+ZSshx+0PmBNxL+qNksLw+ceRUF0R9E/nWS0c X-Developer-Key: i=jason98166@gmail.com; a=ed25519; pk=xQmD001Q/ooHl39PxyQtusbUQmgbOsSfpFryRVWZ/k4= X-Endpoint-Received: by B4 Relay for jason98166@gmail.com/20260721 with auth_id=887 X-Original-From: Jason Yang Reply-To: jason98166@gmail.com From: Jason Yang ov5640_set_stream_mipi() always programs IO_MIPI_CTRL00 with 0x45, which selects the two data lane mode: the number of data lanes described in the devicetree endpoint only feeds the sensor's clock tree computations, so a module wired with one data lane starts streaming in two lane mode and the receiver never assembles a frame. Take the lane mode from the endpoint instead. The field encodes the lane count directly - 001 for one lane, 010 for two - per the current sensor manual (version 2.33). The 2.03 manual documented 000/001 for one/two lanes; OmniVision corrected the table in version 2.1, which is why the long-standing comment here found 001 unusable for two lanes and validated 010 instead. The power-up path also programs a two data lane mode, but that value is overwritten when streaming starts, so it is left alone. Tested with a single data lane module on an i.MX8MP board (imx-mipi-csis receiver), where the unpatched value produces no frames at all, and on an RK3588 board. Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Jason Yang Assisted-by: Claude:claude-opus-5 --- Changes in v4: - Keep the lane count programmed also while the interface is disabled, toggling only the enable bits (Hans Verkuil); with one data lane the disable value becomes 0x20 instead of 0x40. - Link to v3: https://lore.kernel.org/r/20260811-ov5640-1lane-v1-v3-1-ae476= eaf5024@gmail.com Changes in v3: - Inline the lane count in the write instead of going through a local variable (Sakari Ailus). - Link to v2: https://lore.kernel.org/r/20260811-ov5640-1lane-v1-v2-1-65205= ae86feb@gmail.com Changes in v2: - Compute the register value from the lane count in the single write instead of branching on it (Sakari Ailus), with the count in a local variable to stay within 80 columns; the programmed values are unchanged, 0x25 for one lane and 0x45 for two. - Request a normal stable backport rather than opting out of AUTOSEL (Sakari Ailus). - Drop the quotes around the function name in the reference from ov5640_set_power_mipi() (Sakari Ailus). - Link to v1: https://lore.kernel.org/r/20260811-ov5640-1lane-v1-v1-1-79699= 457ce13@gmail.com --- drivers/media/i2c/ov5640.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 8deb5f5501fa..a99e4edb6a75 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -1831,22 +1831,16 @@ static int ov5640_set_stream_mipi(struct ov5640_dev= *sensor, bool on) /* * Enable/disable the MIPI interface * - * 0x300e =3D on ? 0x45 : 0x40 - * - * FIXME: the sensor manual (version 2.03) reports - * [7:5] =3D 000 : 1 data lane mode - * [7:5] =3D 001 : 2 data lanes mode - * But this settings do not work, while the following ones - * have been validated for 2 data lanes mode. - * - * [7:5] =3D 010 : 2 data lanes mode + * [7:5] : data lane count, 001 for one lane and 010 for two, + * per version 2.33 of the sensor manual * [4] =3D 0 : Power up MIPI HS Tx * [3] =3D 0 : Power up MIPI LS Rx * [2] =3D 1/0 : MIPI interface enable/disable * [1:0] =3D 01/00: FIXME: 'debug' */ ret =3D ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00, - on ? 0x45 : 0x40); + sensor->ep.bus.mipi_csi2.num_data_lanes << 5 | + (on ? 0x05 : 0x0)); if (ret) return ret; =20 @@ -2535,8 +2529,8 @@ static int ov5640_set_power_mipi(struct ov5640_dev *s= ensor, bool on) * Power up MIPI HS Tx and LS Rx; 2 data lanes mode * * 0x300e =3D 0x40 - * [7:5] =3D 010 : 2 data lanes mode (see FIXME note in - * "ov5640_set_stream_mipi()") + * [7:5] =3D 010 : 2 data lanes mode (see the note in + * ov5640_set_stream_mipi()) * [4] =3D 0 : Power up MIPI HS Tx * [3] =3D 0 : Power up MIPI LS Rx * [2] =3D 1 : MIPI interface enabled --- base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f change-id: 20260811-ov5640-1lane-v1-b0fe37eab4d8 Best regards, --=20 Jason Yang