From patchwork Wed Mar 6 12:39:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luca Ceresoli X-Patchwork-Id: 13584019 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1475FC5475B for ; Wed, 6 Mar 2024 12:39:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3066410E0FA; Wed, 6 Mar 2024 12:39:28 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.b="WcGASoc1"; dkim-atps=neutral Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by gabe.freedesktop.org (Postfix) with ESMTPS id 77A0410E0FA for ; Wed, 6 Mar 2024 12:39:26 +0000 (UTC) Received: by mail.gandi.net (Postfix) with ESMTPSA id 4E34940008; Wed, 6 Mar 2024 12:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709728764; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=elkd8DsFZS5LmKpv07wv9/YlAnCVft4QUXCwGUZen9k=; b=WcGASoc1KG0VbPwmMfiT95+0rpCtDVoXHW6AJ82VN7BMBrhC0n0M0ft/A5ZE91It8UhKsr 4PEuag7MjK0qJjoCnqoUEcGAL8eF0axOME4/bJe2SaiTDeM/tnPn+jlow/uN37ta/sNlkz MsCKorGBGR/SrP8+FZm5Y386BgqIQn9G44GIPw6O9OxPMjBcPHashdFxBOJWN/ohM06hrl 4iwT+Q//4XCfbzPAvkGllT6wcFxkiB1d7dxy2MlXIuER/KnArACdYph/Ac787FvLyqRy9Y YZ9Rg5C5piEiVvjvIsoit5FmWw7TsvEasEvOHVmmd4OOHoNVQyUhROBxEiqE4g== From: Luca Ceresoli Date: Wed, 06 Mar 2024 13:39:20 +0100 Subject: [PATCH] Revert "drm/bridge: ti-sn65dsi83: Fix enable error path" MIME-Version: 1.0 Message-Id: <20240306-ti-sn65dsi83-regulator-imbalance-v1-1-a3cea5f3e5b3@bootlin.com> X-B4-Tracking: v=1; b=H4sIAPdj6GUC/x3NwQqDMAyA4VeRnBdI202HrzI8dG3UgKuSuDEQ3 31lx+/y/wcYq7BB3xyg/BGTtVS4SwNpjmVilFwNnvyVArW4C1ppb9nkHlB5ei9xXxXl9YxLLIn REXvXjTmQT1Azm/Io3//iMZznDzvwTRRyAAAA To: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Alexander Stein Cc: Thomas Petazzoni , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Luca Ceresoli X-Mailer: b4 0.13.0 X-GND-Sasl: luca.ceresoli@bootlin.com X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f. The regulator_disable() added by the original commit solves one kind of regulator imbalance but adds another one as it allows the regulator to be disabled one more time than it is enabled in the following scenario: 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable 2. PLL lock fails -> regulator_disable 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable The reason is clear from the code flow, which looks like this (after removing unrelated code): static void sn65dsi83_atomic_pre_enable() { regulator_enable(ctx->vcc); if (PLL failed locking) { regulator_disable(ctx->vcc); <---- added by patch being reverted return; } } static void sn65dsi83_atomic_disable() { regulator_disable(ctx->vcc); } The use case for introducing the additional regulator_disable() was removing the module for debugging (see link below for the discussion). If the module is removed after a .atomic_pre_enable, i.e. with an active pipeline from the DRM point of view, .atomic_disable is not called and thus the regulator would not be disabled. According to the discussion however there is no actual use case for removing the module with an active pipeline, except for debugging/development. On the other hand, the occurrence of a PLL lock failure is possible due to any physical reason (e.g. a temporary hardware failure for electrical reasons) so handling it gracefully should be supported. As there is no way for .atomic[_pre]_enable to report an error to the core, the only clean way to support it is calling regulator_disabled() only in .atomic_disable, unconditionally, as it was before. Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/ Fixes: 8a91b29f1f50 ("drm/bridge: ti-sn65dsi83: Fix enable error path") Signed-off-by: Luca Ceresoli Reviewed-by: Alexander Stein --- Many thanks to Alexander for the discussion. --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 - 1 file changed, 1 deletion(-) --- base-commit: a71e4adac20bfe852d269addfef340923ce23a4c change-id: 20240306-ti-sn65dsi83-regulator-imbalance-10e217fd302c Best regards, diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index e3501608aef9..12fb22d4cd23 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -499,7 +499,6 @@ printk(KERN_ERR "%s: LVDS in fallback (24/SPWG)\n", __func__); dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret); /* On failure, disable PLL again and exit. */ regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00); - regulator_disable(ctx->vcc); return; }