From mboxrd@z Thu Jan 1 00:00:00 1970 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 9C448C5478C for ; Tue, 27 Feb 2024 12:05:51 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C626F10E11E; Tue, 27 Feb 2024 12:05:50 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=tq-group.com header.i=@tq-group.com header.b="p3eb9o76"; dkim-atps=neutral Received: from mx1.tq-group.com (mx1.tq-group.com [93.104.207.81]) by gabe.freedesktop.org (Postfix) with ESMTPS id F38CF10E11E for ; Tue, 27 Feb 2024 12:05:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1709035549; x=1740571549; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=7rzlTfcbQRbubGK+HCKREzYFqosifS4DbMNEYtHdvpc=; b=p3eb9o76bFayFw7yZFIsdCc542NhGgbFHNaCXvv0Wgj6q6Dmawfjefs0 SULV0LWmqsRvFjK9AOk+yxhwEgUup1xtFNr8zvnvBDmKC4GPHDWg6uG+q b1z5wdosKylwHL2e7meerfob+E18xXklK89PWiC3490CMz9o08Q1KhCpF W5ooVGDJorK8yKmYv2YOoSGkY3Y/tXgxYPFQ9nLH0HkcCHXvEbjEO6Phw A0zTypfdX3iQAcwjSg02bM5B9/uOEjAjYX6BcdfgMjxxrtkGAQnFIs3Wr XsYQgiXzOHCHSwTwGACpe1S3853iEOUaGFJGdrd4W/rppscLiGpEAGd6n A==; X-IronPort-AV: E=Sophos;i="6.06,187,1705359600"; d="scan'208";a="35617237" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 27 Feb 2024 13:05:46 +0100 Received: from steina-w.localnet (steina-w.tq-net.de [10.123.53.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by vtuxmail01.tq-net.de (Postfix) with ESMTPSA id BAB7D280075; Tue, 27 Feb 2024 13:05:45 +0100 (CET) From: Alexander Stein To: Luca Ceresoli Cc: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org Subject: Re: [PATCH 1/1] drm/bridge: ti-sn65dsi83: Fix enable error path Date: Tue, 27 Feb 2024 13:05:46 +0100 Message-ID: <1885005.tdWV9SEqCh@steina-w> Organization: TQ-Systems GmbH In-Reply-To: <20240222163637.12165adf@booty> References: <20230504065316.2640739-1-alexander.stein@ew.tq-group.com> <20240222163637.12165adf@booty> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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" Hi Luca, Am Donnerstag, 22. Februar 2024, 16:36:37 CET schrieb Luca Ceresoli: > Hello Alexander, >=20 > On Thu, 4 May 2023 08:53:16 +0200 > Alexander Stein wrote: >=20 > > If PLL locking failed, the regulator needs to be disabled again. > >=20 > > Fixes: 5664e3c907e2 ("drm/bridge: ti-sn65dsi83: Add vcc supply regulato= r support") > > Signed-off-by: Alexander Stein > > --- > > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 + > > 1 file changed, 1 insertion(+) > >=20 > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/br= idge/ti-sn65dsi83.c > > index 75286c9afbb9..1f5c07989e2b 100644 > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > > @@ -478,6 +478,7 @@ static void sn65dsi83_atomic_enable(struct drm_brid= ge *bridge, > > dev_err(ctx->dev, "failed to lock PLL, ret=3D%i\n", ret); > > /* On failure, disable PLL again and exit. */ > > regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00); > > + regulator_disable(ctx->vcc); > > return; > > } >=20 > I'm reviving this thread as I've been investigating a bug that appears > related to this patch. >=20 > Symptom: with a v6.8-rc5 kernel, if PLL fails locking, later on during > atomic disable I get: >=20 > [ 41.065198] ------------[ cut here ]------------ > [ 41.069823] unbalanced disables for DOCK_SYS_1V8 > [ 41.074482] WARNING: CPU: 0 PID: 58 at drivers/regulator/core.c:2999 _= regulator_disable+0xf8/0x1d8 > [ 41.083457] Modules linked in: smsc smsc95xx usbnet mii imx_cpufreq_dt= exc3000 imx8mm_thermal snd_soc_tlv320aic3x_spi snd_soc_tlv320aic3x_i2c snd= _soc_tlv320aic3x tmp103 snd_soc_simple_card snd_soc_simple_card_utils fsl_l= db rtc_snvs snvs_pwrkey snd_soc_fsl_sai imx8mp_interconnect snd_soc_fsl_uti= ls imx_interconnect imx_pcm_dma rtc_rs5c372 ti_sn65dsi83 pwm_imx27 st_press= ure_spi st_sensors_spi st_pressure_i2c st_pressure st_sensors_i2c industria= lio_triggered_buffer lm75 kfifo_buf st_sensors opt3001 panel_simple etnaviv= gpu_sched iio_hwmon governor_userspace imx_bus imx8mp_hdmi_tx dw_hdmi drm_= display_helper samsung_dsim imx_sdma imx_lcdif drm_dma_helper imx8mp_hdmi_p= vi drm_kms_helper drm drm_panel_orientation_quirks fsl_imx8_ddr_perf caam e= rror sbs_battery pwm_bl backlight ltc2497 ltc2497_core crct10dif_ce > [ 41.157281] CPU: 0 PID: 58 Comm: kworker/0:2 Not tainted 6.8.0-rc5+ #7 > [ 41.170339] Workqueue: events drm_mode_rmfb_work_fn [drm] > [ 41.175798] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYP= E=3D--) > [ 41.182762] pc : _regulator_disable+0xf8/0x1d8 > [ 41.187209] lr : _regulator_disable+0xf8/0x1d8 > [ 41.191654] sp : ffff800081aaba90 > [ 41.194967] x29: ffff800081aaba90 x28: 0000000000000000 x27: ffff00000= 2647e80 > [ 41.202109] x26: ffff000002d7a180 x25: ffff0000037858a0 x24: ffff80007= 9748ac8 > [ 41.209250] x23: ffff000002647ed8 x22: ffff00000263f800 x21: ffff00000= 373d000 > [ 41.216392] x20: ffff00000373d000 x19: ffff000001de6480 x18: 000000000= 0000006 > [ 41.223533] x17: 0000000000000000 x16: 1fffe000003423e1 x15: ffff80008= 1aab520 > [ 41.230674] x14: 0000000000000000 x13: 3856315f5359535f x12: 4b434f442= 0726f66 > [ 41.237815] x11: 2073656c62617369 x10: ffff8000814647a0 x9 : ffff80008= 01b10e0 > [ 41.244957] x8 : ffff8000814bc7a0 x7 : 0000000000017fe8 x6 : ffff80008= 14bc7a0 > [ 41.252098] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 000000000= 0000000 > [ 41.259239] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00000= 11b6600 > [ 41.266380] Call trace: > [ 41.268826] _regulator_disable+0xf8/0x1d8 > [ 41.272925] regulator_disable+0x4c/0x98 > [ 41.276850] sn65dsi83_atomic_disable+0x70/0xc0 [ti_sn65dsi83] > [ 41.282692] drm_atomic_bridge_chain_disable+0x78/0x110 [drm] > [ 41.288481] disable_outputs+0x100/0x350 [drm_kms_helper] > [ 41.293902] drm_atomic_helper_commit_tail_rpm+0x2c/0xb0 [drm_kms_help= er] > [ 41.300705] commit_tail+0xac/0x1a0 [drm_kms_helper] > [ 41.305685] drm_atomic_helper_commit+0x16c/0x188 [drm_kms_helper] > [ 41.311881] drm_atomic_commit+0xac/0xf0 [drm] > [ 41.316365] drm_framebuffer_remove+0x464/0x550 [drm] > [ 41.321458] drm_mode_rmfb_work_fn+0x84/0xb0 [drm] > [ 41.326291] process_one_work+0x148/0x3b8 > [ 41.330309] worker_thread+0x32c/0x450 > [ 41.334061] kthread+0x11c/0x128 > [ 41.337292] ret_from_fork+0x10/0x20 > [ 41.340873] ---[ end trace 0000000000000000 ]--- >=20 > The reason is clear from the code flow, which looks like this (after > removing unrelated code): >=20 > static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, > struct drm_bridge_state *old_brid= ge_state) > { > regulator_enable(ctx->vcc); >=20 > if (PLL failed locking) { > regulator_disable(ctx->vcc); > return; > } > } >=20 > static void sn65dsi83_atomic_disable(struct drm_bridge *bridge, > struct drm_bridge_state *old_bridge_= state) > { > regulator_disable(ctx->vcc); > } >=20 > So when the PLL fails locking, the vcc regulator is disable twice, > leading to "unbalanced disables". >=20 > I initially removed the regulator_disable() line in sn65dsi83_atomic_pre_= enable() > locally and it worked fine. Then I did some git log and found you added t= his line on > purpose (even though it was in sn65dsi83_atomic_enable() initially), so m= y question > is whether you can explain exactly what was wrong before your patch. I ha= ve been > working for a few weeks with the regulator_disable() line removed and fou= nd no issue. Unfortunately I' cant tell the details anymore, but I do remember hitting some bug regarding failed PLL lock. I do remember having a lock failure from time to time as well. I wont be able to test this bridge at the moment, but you seem to be right. On a general side, IMHO enabling the PLL in atomic_pre_enable is a bit late anyway, because you can't bail out if enabling fails. Best regards, Alexander > Best regards, > Luca >=20 >=20 =2D-=20 TQ-Systems GmbH | M=FChlstra=DFe 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht M=FCnchen, HRB 105018 Gesch=E4ftsf=FChrer: Detlef Schneider, R=FCdiger Stahl, Stefan Schneider http://www.tq-group.com/