[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62426006-b5a1-cbe7-9c3a-16f94334208f@quicinc.com>
Date: Wed, 4 May 2022 16:29:05 -0700
From: Abhinav Kumar <quic_abhinavk@...cinc.com>
To: Douglas Anderson <dianders@...omium.org>,
Rob Clark <robdclark@...il.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Stephen Boyd <swboyd@...omium.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...ainline.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>, Lv Ruyi <lv.ruyi@....com.cn>,
Sean Paul <sean@...rly.run>,
Vinod Polimera <quic_vpolimer@...cinc.com>,
Xu Wang <vulab@...as.ac.cn>, <dri-devel@...ts.freedesktop.org>,
<freedreno@...ts.freedesktop.org>, <linux-arm-msm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm: Fix shutdown
On 5/4/2022 3:49 PM, Douglas Anderson wrote:
> When rebooting on my sc7280-herobrine based device, I got a
> crash. Upon debugging, I found that I was in msm_drv_shutdown() and my
> "pdev" was the one associated with mdss_probe().
>
> From source, I found that mdss_probe() has the line:
> platform_set_drvdata(pdev, mdss);
> ...where "mdss" is of type "struct msm_mdss *".
>
> Also from source, I saw that in msm_drv_shutdown() we have the line:
> struct msm_drm_private *priv = platform_get_drvdata(pdev);
>
> This is a mismatch and is the root of the problem.
>
> Further digging made it apparent that msm_drv_shutdown() is only
> supposed to be used for parts of the msm display framework that also
> call msm_drv_probe() but mdss_probe() doesn't call
> msm_drv_probe(). Let's remove the shutdown functon from msm_mdss.c.
>
> Digging a little further, code inspection found that two drivers that
> use msm_drv_probe() weren't calling msm_drv_shutdown(). Let's add it
> to them.
>
> Fixes: ecb23f2e3009 ("drm/msm: split the main platform driver")
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
Makes sense to me, and issue should happen everytime we shutdown so not
sure how it didnt hit?
> ---
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 1 +
> drivers/gpu/drm/msm/msm_mdss.c | 1 -
> 3 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 143d6643be53..2b9d931474e0 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1350,6 +1350,7 @@ MODULE_DEVICE_TABLE(of, dpu_dt_match);
> static struct platform_driver dpu_driver = {
> .probe = dpu_dev_probe,
> .remove = dpu_dev_remove,
> + .shutdown = msm_drv_shutdown,
> .driver = {
> .name = "msm_dpu",
> .of_match_table = dpu_dt_match,
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 9b7bbc3adb97..3d5621a68f85 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -1009,6 +1009,7 @@ MODULE_DEVICE_TABLE(of, mdp5_dt_match);
> static struct platform_driver mdp5_driver = {
> .probe = mdp5_dev_probe,
> .remove = mdp5_dev_remove,
> + .shutdown = msm_drv_shutdown,
> .driver = {
> .name = "msm_mdp",
> .of_match_table = mdp5_dt_match,
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 20f154dda9cf..0454a571adf7 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -397,7 +397,6 @@ MODULE_DEVICE_TABLE(of, mdss_dt_match);
> static struct platform_driver mdss_platform_driver = {
> .probe = mdss_probe,
> .remove = mdss_remove,
> - .shutdown = msm_drv_shutdown,
Question to doug/dmitry:
Now that we removed msm_drv_shutdown, perhaps we should have a
mdss_shutdown instead and call msm_mdss_destroy() internally?
> .driver = {
> .name = "msm-mdss",
> .of_match_table = mdss_dt_match,
Powered by blists - more mailing lists