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 373C9C5475B for ; Fri, 1 Mar 2024 10:45:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 64B4810EC86; Fri, 1 Mar 2024 10:45:32 +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="O1lxvAp5"; 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 0129510EC88 for ; Fri, 1 Mar 2024 10:45:29 +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=1709289930; x=1740825930; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8fAttGuq6JV7KCh912OsqiDJ7y6b001uDK7Vj5Gb8Qg=; b=O1lxvAp55Pq4Wz1wW68a38C+KiEm8zHIUB31PxgmvafUBpR4/cdAXLqr QHqtailF9SvNrEEZ01/BH/a0xJiLqsfUpHnqz/ruXBoZfrrDyEtNolPfS 48IQXieuFnJTyQRVK34xXA2WVNEmMQT+P0jJ+3yZEbvT0wsXfY+qtxsTF mo7+ulG9O27E1yau0UvSFnoyTmE/iw8x5OikpcDpu+u0YKBWo9FkHybmy Q2w19frWbqKeQoNCh+Uwnq2mgN/4uVy7BUlSdOrTHv9IIr5etjgqB5jR8 IJSnhAbHFG2qvOihquzqqUSV4YsrKkAklLCjQQKJqhdqXldO/h1IatXBP A==; X-IronPort-AV: E=Sophos;i="6.06,196,1705359600"; d="scan'208";a="35686776" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 01 Mar 2024 11:45:27 +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 B0634280071; Fri, 1 Mar 2024 11:45:27 +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: Fri, 01 Mar 2024 11:45:27 +0100 Message-ID: <5059768.aeNJFYEL58@steina-w> Organization: TQ-Systems GmbH In-Reply-To: <20240301111059.36e6def0@booty> References: <20230504065316.2640739-1-alexander.stein@ew.tq-group.com> <15244220.uLZWGnKmhe@steina-w> <20240301111059.36e6def0@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 Freitag, 1. M=E4rz 2024, 11:10:59 CET schrieb Luca Ceresoli: > Hello Alexander, >=20 > On Fri, 01 Mar 2024 10:57:37 +0100 > Alexander Stein wrote: >=20 > > Hi Luca, > >=20 > > Am Freitag, 1. M=E4rz 2024, 10:44:49 CET schrieb Luca Ceresoli: > > > Hello Alexander, > > >=20 > > > On Thu, 29 Feb 2024 12:11:23 +0100 > > > Alexander Stein wrote: > > > =20 > > > > Hi Luca, > > > >=20 > > > > Am Donnerstag, 29. Februar 2024, 10:47:23 CET schrieb Luca Ceresoli= : =20 > > > > > Hello Alexander, > > > > >=20 > > > > > On Wed, 28 Feb 2024 09:15:46 +0100 > > > > > Alexander Stein wrote: > > > > >=20 > > > > >=20 > > > > > [...] > > > > > =20 > > > > > > Oh I mistook this DSI-LVDS bridge with the DSI-DP bridge on a d= ifferent > > > > > > board, my bad. I hope I can provide some insights. My platform = is > > > > > > imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtb. > > > > > > I can easily cause a PLL lock failure by reducing the delay for= the > > > > > > enable-gpios 'gpio_delays'. This will result in a PLL lock faiu= re. > > > > > > On my platform the vcc-supply counters do look sane: =20 > > > > > > > /sys/kernel/debug/regulator/SN65DSI83_1V8/open_count:1 > > > > > > > /sys/kernel/debug/regulator/SN65DSI83_1V8/use_count:0 =20 > > > > >=20 > > > > > Interesting. Thanks for taking time to report your initial issue! > > > > > =20 > > > > > > Once I remove the ti_sn65dsi83 module, the open_count decrement= s to 0 as > > > > > > well. Looks sane to me. > > > > > >=20 > > > > > > If I revert commit c81cd8f7c774 ("Revert "drm/bridge: ti-sn65ds= i83: > > > > > > Fix enable error path""), vcc-supply counters are: =20 > > > > > > > /sys/kernel/debug/regulator/SN65DSI83_1V8/open_count:1 > > > > > > > /sys/kernel/debug/regulator/SN65DSI83_1V8/use_count:1 =20 > > > > > >=20 > > > > > > So in my case the use_count does not decrease! If I remove the = module > > > > > > ti_sn65dsi83, I get the WARN_ON (enable_count is still non-zero= ): =20 > > > > > > > WARNING: CPU: 2 PID: 402 at drivers/regulator/core.c:2398 _re= gulator_put+0x15c/0x164 =20 > > > > > >=20 > > > > > > This is on 6.8.0-rc6-next-20240228 with the following diff appl= ied: =20 > > > > > > --->8--- =20 > > > > > > diff --git a/arch/arm64/boot/dts/freescale/mba8mx.dtsi b/arch/a= rm64/boot/dts/freescale/mba8mx.dtsi > > > > > > index 427467df42bf..8461e1fd396f 100644 > > > > > > --- a/arch/arm64/boot/dts/freescale/mba8mx.dtsi > > > > > > +++ b/arch/arm64/boot/dts/freescale/mba8mx.dtsi > > > > > > @@ -285,7 +285,7 @@ &i2c3 { > > > > > > dsi_lvds_bridge: bridge@2d { > > > > > > compatible =3D "ti,sn65dsi84"; > > > > > > reg =3D <0x2d>; > > > > > > - enable-gpios =3D <&gpio_delays 0 130000 0>; > > > > > > + enable-gpios =3D <&gpio_delays 0 0 0>; > > > > > > vcc-supply =3D <®_sn65dsi83_1v8>; > > > > > > status =3D "disabled"; > > > > > > =20 > > > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gp= u/drm/bridge/ti-sn65dsi83.c > > > > > > index 4814b7b6d1fd..57a7ed13f996 100644 > > > > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > > > > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > > > > > > @@ -478,7 +478,6 @@ static void sn65dsi83_atomic_pre_enable(str= uct drm_bridge *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 > > > > > > --->8--- =20 > > > > > >=20 > > > > > > So my patch indeed did fix an actual problem. On the other hand= it seems > > > > > > sn65dsi83_atomic_disable is not called in my case for some reas= on. =20 > > > > >=20 > > > > > So you remove the module and atomic_disable is not called, after > > > > > having called atomic_pre_enable? =20 > > > >=20 > > > > Yes, that's the case. =20 > > >=20 > > > Ah, it's quite obvious looking at the code: removing the module will > > > call sn65dsi83_remove() > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge= /ti-sn65dsi83.c#L729 > > >=20 > > > which does just call drm_bridge_remove() > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_br= idge.c#L243 > > >=20 > > > which just removes the bridge from the list. > > >=20 > > > So maybe sn65dsi83_remove() should call regulator_disable() as a last > > > resort, but I'm not sure this is the correct solution and it would > > > involve some housekeeping to not disable the regulator more times than > > > it has been enabled. =20 > >=20 > > Actually I think removing the module should be prohibited while the bri= dge > > is enabled in the first place. > >=20 > > > What is the use case you have for removing the driver module? =20 > >=20 > > I was dealing the PLL lock failure myself, caused by some external dela= ys. > > For easy testing I was loading/unloading the module. >=20 > Ah, I see, so do you agree that we can say: > 1. there is no valid use case for rmmod while the pipeline is running > (I'm not counting debugging here) > 2. so the regulator_disable() in pre_enable is not needed > ? Yes, that seems reasonable. I'm wondering how 1. can actually prevented tho= ugh. Best regards, Alexander =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/