From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Douglas Anderson <dianders@chromium.org>,
dri-devel@lists.freedesktop.org,
Maxime Ripard <mripard@kernel.org>
Cc: airlied@gmail.com, alim.akhtar@samsung.com, daniel@ffwll.ch,
inki.dae@samsung.com, krzysztof.kozlowski@linaro.org,
kyungmin.park@samsung.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
sw0312.kim@samsung.com
Subject: Re: [RFT PATCH v2 09/12] drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time
Date: Fri, 22 Sep 2023 07:55:07 +0200 [thread overview]
Message-ID: <fb9cd62b-6637-7bcc-e23d-37f3806f8460@samsung.com> (raw)
In-Reply-To: <20230921122641.RFT.v2.9.Iea33274908b6b258955f45a8aaf6f5bba24ad6cd@changeid>
On 21.09.2023 21:26, Douglas Anderson wrote:
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time
> and at driver unbind time. Among other things, this means that if a
> panel is in use that it won't be cleanly powered off at system
> shutdown time.
>
> The fact that we should call drm_atomic_helper_shutdown() in the case
> of OS shutdown/restart and at driver remove (or unbind) time comes
> straight out of the kernel doc "driver instance overview" in
> drm_drv.c.
>
> A few notes about this fix:
> - When adding drm_atomic_helper_shutdown() to the unbind path, I added
> it after drm_kms_helper_poll_fini() since that's when other drivers
> seemed to have it.
> - Technically with a previous patch, ("drm/atomic-helper:
> drm_atomic_helper_shutdown(NULL) should be a noop"), we don't
> actually need to check to see if our "drm" pointer is NULL before
> calling drm_atomic_helper_shutdown(). We'll leave the "if" test in,
> though, so that this patch can land without any dependencies. It
> could potentially be removed later.
> - This patch also makes sure to set the drvdata to NULL in the case of
> bind errors to make sure that shutdown can't access freed data.
>
> Suggested-by: Maxime Ripard <mripard@kernel.org>
> Reviewed-by: Maxime Ripard <mripard@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Seems to be working fine on all my test Exynos-based boards with display.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> This commit is only compile-time tested.
>
> (no changes since v1)
>
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 8399256cb5c9..5380fb6c55ae 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -300,6 +300,7 @@ static int exynos_drm_bind(struct device *dev)
> drm_mode_config_cleanup(drm);
> exynos_drm_cleanup_dma(drm);
> kfree(private);
> + dev_set_drvdata(dev, NULL);
> err_free_drm:
> drm_dev_put(drm);
>
> @@ -313,6 +314,7 @@ static void exynos_drm_unbind(struct device *dev)
> drm_dev_unregister(drm);
>
> drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
>
> component_unbind_all(drm->dev, drm);
> drm_mode_config_cleanup(drm);
> @@ -350,9 +352,18 @@ static int exynos_drm_platform_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static void exynos_drm_platform_shutdown(struct platform_device *pdev)
> +{
> + struct drm_device *drm = platform_get_drvdata(pdev);
> +
> + if (drm)
> + drm_atomic_helper_shutdown(drm);
> +}
> +
> static struct platform_driver exynos_drm_platform_driver = {
> .probe = exynos_drm_platform_probe,
> .remove = exynos_drm_platform_remove,
> + .shutdown = exynos_drm_platform_shutdown,
> .driver = {
> .name = "exynos-drm",
> .pm = &exynos_drm_pm_ops,
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2023-09-22 5:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 19:26 [RFT PATCH v2 00/12] drm: call drm_atomic_helper_shutdown() at the right times Douglas Anderson
2023-09-21 19:26 ` [RFT PATCH v2 01/12] drm/imx/dcss: Call drm_atomic_helper_shutdown() at shutdown time Douglas Anderson
2023-09-22 7:56 ` Laurentiu Palcu
2023-09-22 15:44 ` Doug Anderson
2023-09-25 5:47 ` Laurentiu Palcu
2023-09-25 22:53 ` Doug Anderson
2023-09-21 19:26 ` [RFT PATCH v2 02/12] drm/kmb: " Douglas Anderson
2023-09-21 19:26 ` [RFT PATCH v2 03/12] drm/mediatek: " Douglas Anderson
2023-09-21 19:26 ` [RFT PATCH v2 04/12] drm/nouveau: Call drm_atomic_helper_shutdown() or equiv " Douglas Anderson
2023-09-22 21:06 ` Lyude Paul
2023-11-17 23:00 ` Doug Anderson
2023-12-05 20:45 ` Doug Anderson
2023-12-06 8:14 ` Maxime Ripard
2023-09-21 19:26 ` [RFT PATCH v2 05/12] drm/tegra: Call drm_atomic_helper_shutdown() " Douglas Anderson
2023-09-21 19:26 ` [RFT PATCH v2 06/12] drm/arcpgu: " Douglas Anderson
2023-09-21 19:26 ` [RFT PATCH v2 07/12] drm/amdgpu: " Douglas Anderson
2023-09-25 15:56 ` Deucher, Alexander
2023-09-25 17:04 ` Doug Anderson
2023-09-21 19:26 ` [RFT PATCH v2 08/12] drm/sprd: Call drm_atomic_helper_shutdown() at remove time Douglas Anderson
2023-09-21 19:26 ` [RFT PATCH v2 09/12] drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time Douglas Anderson
2023-09-22 5:55 ` Marek Szyprowski [this message]
2023-10-06 2:19 ` Inki Dae
2023-10-06 13:50 ` Doug Anderson
2023-10-10 15:46 ` Inki Dae
2023-09-21 19:26 ` [RFT PATCH v2 10/12] drm/gma500: Call drm_helper_force_disable_all() at shutdown/remove time Douglas Anderson
2023-09-21 19:26 ` [RFT PATCH v2 11/12] drm/radeon: " Douglas Anderson
2023-09-25 15:49 ` Deucher, Alexander
2023-09-25 16:09 ` Doug Anderson
2023-09-21 19:26 ` [RFT PATCH v2 12/12] drm/renesas/shmobile: " Douglas Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb9cd62b-6637-7bcc-e23d-37f3806f8460@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=airlied@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=sw0312.kim@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®