Re: [PATCH v2] drm/msm/dpu: Correct dpu destroy and disable order

[Sean Paul <sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org>]

On Fri, Nov 09, 2018 at 11:37:17AM +0530, Rajendra Nayak wrote:
> 
> On 11/2/2018 6:19 PM, Jayant Shekhar wrote:
> > In case of msm drm bind failure, dpu_mdss_destroy is triggered.
> > In this function, resources are freed and pm runtime disable is
> > called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable,
> > driver tries to access a memory which is already freed. This
> > results in kernel panic. Fix this by ensuring proper sequence
> > of dpu destroy and disable calls.
> > 
> > Changes in v2:
> >     - Removed double spacings [Jeykumar]
> > 
> > Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org>
> 
> I was testing this patch out and in my setup I see that with this
> change, during a dsi probe defer case, a dpu_mdss_enable() is called
> followed by a dpu_mdss_destroy() but dpu_mdss_disable() is never called.
> 
> This results in a mismatch in clock usecount causing the mdp clocks to
> stay enabled even with display turned off.

This suggests an unmatched pm_runtime_get/put. I just audited the code and
nothing stuck out to me in the probe defer case, things seem to be well matched.
Could you instrument the pm_runtime_* calls in msm/dpu and see if there's a _get
without a _put?

Sean

> 
> localhost ~ # cat /sys/kernel/debug/clk/clk_summary | grep mdss
>  disp_cc_mdss_rscc_ahb_clk            0        0        0           0          0     0  50000
>  disp_cc_mdss_axi_clk                 0        0        0           0          0     0  50000
>  disp_cc_mdss_ahb_clk                 0        0        0           0          0     0  50000
>        disp_cc_mdss_mdp_clk_src       1        1        0    19200000          0     0  50000
>           disp_cc_mdss_mdp_lut_clk       0        0        0    19200000          0     0  50000
>           disp_cc_mdss_mdp_clk        1        1        0    19200000          0     0  50000
>        disp_cc_mdss_vsync_clk_src       0        0        0    19200000          0     0  50000
> 
> Also to note, on an older 4.14 kernel, I do not see any issue in the order in which
> these functions are called in the dsi probe defer case, i.e its an enable followed by
> a disable and then a destroy (and that's without this patch)
> 
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 +----
> >   1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> > index fd9c893..902bb4c 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> > @@ -156,18 +156,15 @@ static void dpu_mdss_destroy(struct drm_device *dev)
> >   	struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
> >   	struct dss_module_power *mp = &dpu_mdss->mp;
> > +	pm_runtime_disable(dev->dev);
> >   	_dpu_mdss_irq_domain_fini(dpu_mdss);
> > -
> >   	free_irq(platform_get_irq(pdev, 0), dpu_mdss);
> > -
> >   	msm_dss_put_clk(mp->clk_config, mp->num_clk);
> >   	devm_kfree(&pdev->dev, mp->clk_config);
> >   	if (dpu_mdss->mmio)
> >   		devm_iounmap(&pdev->dev, dpu_mdss->mmio);
> >   	dpu_mdss->mmio = NULL;
> > -
> > -	pm_runtime_disable(dev->dev);
> >   	priv->mdss = NULL;
> >   }
> > 
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno