Re: [PATCH 1/1] drm/bridge: ti-sn65dsi83: Fix enable error path

[Alexander Stein <alexander.stein@ew.tq-group.com>]

Hi Luca,

Am Donnerstag, 22. Februar 2024, 16:36:37 CET schrieb Luca Ceresoli:
> Hello Alexander,
> 
> On Thu,  4 May 2023 08:53:16 +0200
> Alexander Stein <alexander.stein@ew.tq-group.com> wrote:
> 
> > If PLL locking failed, the regulator needs to be disabled again.
> > 
> > Fixes: 5664e3c907e2 ("drm/bridge: ti-sn65dsi83: Add vcc supply regulator support")
> > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > ---
> >  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/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_bridge *bridge,
> >  		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;
> >  	}
> 
> I'm reviving this thread as I've been investigating a bug that appears
> related to this patch.
> 
> Symptom: with a v6.8-rc5 kernel, if PLL fails locking, later on during
> atomic disable I get:
> 
> [   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_ldb rtc_snvs snvs_pwrkey snd_soc_fsl_sai imx8mp_interconnect snd_soc_fsl_utils imx_interconnect imx_pcm_dma rtc_rs5c372 ti_sn65dsi83 pwm_imx27 st_pressure_spi st_sensors_spi st_pressure_i2c st_pressure st_sensors_i2c industrialio_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_pvi drm_kms_helper drm drm_panel_orientation_quirks fsl_imx8_ddr_perf caam error 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 BTYPE=--)
> [   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: ffff000002647e80
> [   41.202109] x26: ffff000002d7a180 x25: ffff0000037858a0 x24: ffff800079748ac8
> [   41.209250] x23: ffff000002647ed8 x22: ffff00000263f800 x21: ffff00000373d000
> [   41.216392] x20: ffff00000373d000 x19: ffff000001de6480 x18: 0000000000000006
> [   41.223533] x17: 0000000000000000 x16: 1fffe000003423e1 x15: ffff800081aab520
> [   41.230674] x14: 0000000000000000 x13: 3856315f5359535f x12: 4b434f4420726f66
> [   41.237815] x11: 2073656c62617369 x10: ffff8000814647a0 x9 : ffff8000801b10e0
> [   41.244957] x8 : ffff8000814bc7a0 x7 : 0000000000017fe8 x6 : ffff8000814bc7a0
> [   41.252098] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> [   41.259239] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000011b6600
> [   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_helper]
> [   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 ]---
> 
> The reason is clear from the code flow, which looks like this (after
> removing unrelated code):
> 
> static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
>                                         struct drm_bridge_state *old_bridge_state)
> {
>         regulator_enable(ctx->vcc);
> 
>         if (PLL failed locking) {
>                 regulator_disable(ctx->vcc);
>                 return;
>         }
> }
> 
> static void sn65dsi83_atomic_disable(struct drm_bridge *bridge,
>                                      struct drm_bridge_state *old_bridge_state)
> {
>         regulator_disable(ctx->vcc);
> }
> 
> So when the PLL fails locking, the vcc regulator is disable twice,
> leading to "unbalanced disables".
> 
> 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 this line on
> purpose (even though it was in sn65dsi83_atomic_enable() initially), so my question
> is whether you can explain exactly what was wrong before your patch. I have been
> working for a few weeks with the regulator_disable() line removed and found 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
> 
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/