drm/msm/dpu: Correct dpu destroy and disable order
PATCH v2 1/1 drm/msm/dpu: Correct dpu destroy and disable order
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]
--- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +1 -4
@@ -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 ; }
Signature · 7 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ Freedreno mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/freedreno
A message that is not in the archive (sent off-list or not yet received): 1541162957-12796-1-git-send-email-jshekhar-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Sean Paul
Reviewed-byQuoted 11 lines · Jayant Shekhar
In case of msm drm bind failure,
dpu_mdss_destroyis triggered. In this function, resources are freed and pm runtime disable is called, which triggersdpu_mdss_disable. Now indpu_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 <[email protected]>
Quoted 32 lines
--- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +1
-4@@ -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 ; }Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Signature · 5 lines
Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ Freedreno mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/freedreno
Quoted 6 lines · Jayant Shekhar
In case of msm drm bind failure,
dpu_mdss_destroyis triggered. In this function, resources are freed and pm runtime disable is called, which triggersdpu_mdss_disable. Now indpu_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.
Since you are in this specific area, I noticed we also had some memory leaks on bind "failure" and I just sent out a patch for that.
Jordan
Signature · 6 lines
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ Freedreno mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/freedreno
Doug Anderson
Tested-by Douglas AndersonHi,
Quoted 8 lines · Jayant Shekhar
In case of msm drm bind failure,
dpu_mdss_destroyis triggered. In this function, resources are freed and pm runtime disable is called, which triggersdpu_mdss_disable. Now indpu_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.
Quoted 7 lines
Changes in v2:
- Removed double spacings [Jeykumar]Signed-off-by Jayant Shekhar <[email protected]>--- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
I can confirm that this fixes a crash I was running into. Specifically it looked like this:
---
msm_dsi ae94000.dsi: ae94000.dsi supply gdsc not found, using dummy regulator msm_dsi ae94000.dsi: Linked as a consumer to regulator.0msm_dsi ae94000.dsi: Dropping the link to regulator.0msm_dsi ae94000.dsi: Linked as a consumer to regulator.35msm_dsi_manager_register: failed to register mipi dsi host for DSI 0 msm_dsi ae94000.dsi: Dropping the link to regulator.35
msm ae00000.mdss: failed to bind ae94000.dsi (ops dsi_ops): -517
Unable to handle kernel paging request at virtual address 006b6b6b6b6b6b6b ... Workqueue: pm pm_runtime_work ... Call trace: clk_disable+0x24/0x4c msm_dss_enable_clk+0xec/0x164 dpu_mdss_disable+0x2c/0x84 msm_runtime_suspend+0x50/0x5c pm_generic_runtime_suspend+0x3c/0x48 genpd_runtime_suspend+0xf4/0x1cc __rpm_callback+0x128/0x1a4 rpm_callback+0x70/0x90 rpm_suspend+0x2f4/0x564 rpm_idle+0x3c0/0x3d8 pm_runtime_work+0x6c/0xa0 process_one_work+0x38c/0x634 worker_thread+0x218/0x360 kthread+0x130/0x138 ret_from_fork+0x10/0x18
---
Thus:
Quoted 26 lines
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +1
-5@@ -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 ; } --
Quoted 3 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/freedreno
Quoted 11 lines · Jayant Shekhar
In case of msm drm bind failure,
dpu_mdss_destroyis triggered. In this function, resources are freed and pm runtime disable is called, which triggersdpu_mdss_disable. Now indpu_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 <[email protected]>
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.
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 50000Also 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)
Quoted 19 lines
--- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +1
-2@@ -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);
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c static void dpu_mdss_destroy(struct drm_device *dev) · line 170
Quoted 10 lines
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +0
-2devm_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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/freedreno
A message that is not in the archive (sent off-list or not yet received): a2c1906e-f61d-3da2-45a4-3bc14c4201dd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Quoted 12 lines · Rajendra Nayak
Quoted 10 lines · Jayant Shekhar
In case of msm drm bind failure,
dpu_mdss_destroyis triggered. In this function, resources are freed and pm runtime disable is called, which triggersdpu_mdss_disable. Now indpu_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]
Quoted 8 lines
Quoted 1 line
Signed-off-by Jayant Shekhar <[email protected]>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 adpu_mdss_destroy()butdpu_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
Quoted 44 lines
localhost ~ # cat
/sys/kernel/debug/clk/clk_summary| grep mdssdisp_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 50000Also 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)
Quoted 16 lines
--- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +1
-2@@ -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); -drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c static void dpu_mdss_destroy(struct drm_device *dev) · line 168
Quoted 10 lines
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +0
-2msm_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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/freedreno
Signature · 5 lines
Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ Freedreno mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/freedreno