From: Paul Cercueil <paul@crapouillou.net>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Russell King <linux+etnaviv@armlinux.org.uk>,
Christian Gmeiner <christian.gmeiner@gmail.com>,
etnaviv@lists.freedesktop.org
Subject: Re: [PATCH 12/26] drm: etnaviv: Remove #ifdef guards for PM related functions
Date: Mon, 07 Nov 2022 21:03:22 +0000 [thread overview]
Message-ID: <M5XZKR.3DW6QGFX6KVP1@crapouillou.net> (raw)
In-Reply-To: <d63e2214c464b029a15967d81968c27a5a4a88d4.camel@pengutronix.de>
Hi Lucas,
Le lun. 7 nov. 2022 à 19:07:32 +0100, Lucas Stach
<l.stach@pengutronix.de> a écrit :
> Am Montag, dem 07.11.2022 um 17:52 +0000 schrieb Paul Cercueil:
>> Use the RUNTIME_PM_OPS() and pm_ptr() macros to handle the
>> .runtime_suspend/.runtime_resume callbacks.
>>
>> These macros allow the suspend and resume functions to be
>> automatically
>> dropped by the compiler when CONFIG_PM is disabled, without having
>> to use #ifdef guards.
>>
>> This has the advantage of always compiling these functions in,
>> independently of any Kconfig option. Thanks to that, bugs and other
>> regressions are subsequently easier to catch.
>>
>> Some #ifdef CONFIG_PM guards were protecting simple statements, and
>> were
>> also converted to "if (IS_ENABLED(CONFIG_PM))".
>>
> Reasoning and the change itself look good.
That's an ack? :)
>> Note that this driver should probably use the
>> DEFINE_RUNTIME_DEV_PM_OPS() macro instead, which will provide
>> .suspend/.resume callbacks, pointing to pm_runtime_force_suspend()
>> and
>> pm_runtime_force_resume() respectively; unless those callbacks
>> really
>> aren't needed.
>
> This however isn't true, specifically this driver can _not_ use
> pm_runtime_force_suspend, as the GPU can't be forced into suspend by
> calling the rpm callback. A real suspend implementation would first
> need to make sure the GPU finished working on the current queued jobs,
> only then it would be able to power it down via the rpm suspend
> callback.
Understood. I'll remove this paragraph if I have to V2.
Cheers,
-Paul
>>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> ---
>> Cc: Lucas Stach <l.stach@pengutronix.de>
>> Cc: Russell King <linux+etnaviv@armlinux.org.uk>
>> Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
>> Cc: etnaviv@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 30
>> +++++++++++----------------
>> 1 file changed, 12 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index 37018bc55810..e9a5444ec1c7 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -1605,7 +1605,6 @@ static int etnaviv_gpu_hw_suspend(struct
>> etnaviv_gpu *gpu)
>> return etnaviv_gpu_clk_disable(gpu);
>> }
>>
>> -#ifdef CONFIG_PM
>> static int etnaviv_gpu_hw_resume(struct etnaviv_gpu *gpu)
>> {
>> int ret;
>> @@ -1621,7 +1620,6 @@ static int etnaviv_gpu_hw_resume(struct
>> etnaviv_gpu *gpu)
>>
>> return 0;
>> }
>> -#endif
>>
>> static int
>> etnaviv_gpu_cooling_get_max_state(struct thermal_cooling_device
>> *cdev,
>> @@ -1689,11 +1687,10 @@ static int etnaviv_gpu_bind(struct device
>> *dev, struct device *master,
>> if (ret)
>> goto out_workqueue;
>>
>> -#ifdef CONFIG_PM
>> - ret = pm_runtime_get_sync(gpu->dev);
>> -#else
>> - ret = etnaviv_gpu_clk_enable(gpu);
>> -#endif
>> + if (IS_ENABLED(CONFIG_PM))
>> + ret = pm_runtime_get_sync(gpu->dev);
>> + else
>> + ret = etnaviv_gpu_clk_enable(gpu);
>> if (ret < 0)
>> goto out_sched;
>>
>> @@ -1737,12 +1734,12 @@ static void etnaviv_gpu_unbind(struct
>> device *dev, struct device *master,
>>
>> etnaviv_sched_fini(gpu);
>>
>> -#ifdef CONFIG_PM
>> - pm_runtime_get_sync(gpu->dev);
>> - pm_runtime_put_sync_suspend(gpu->dev);
>> -#else
>> - etnaviv_gpu_hw_suspend(gpu);
>> -#endif
>> + if (IS_ENABLED(CONFIG_PM)) {
>> + pm_runtime_get_sync(gpu->dev);
>> + pm_runtime_put_sync_suspend(gpu->dev);
>> + } else {
>> + etnaviv_gpu_hw_suspend(gpu);
>> + }
>>
>> if (gpu->mmu_context)
>> etnaviv_iommu_context_put(gpu->mmu_context);
>> @@ -1856,7 +1853,6 @@ static int etnaviv_gpu_platform_remove(struct
>> platform_device *pdev)
>> return 0;
>> }
>>
>> -#ifdef CONFIG_PM
>> static int etnaviv_gpu_rpm_suspend(struct device *dev)
>> {
>> struct etnaviv_gpu *gpu = dev_get_drvdata(dev);
>> @@ -1899,18 +1895,16 @@ static int etnaviv_gpu_rpm_resume(struct
>> device *dev)
>>
>> return 0;
>> }
>> -#endif
>>
>> static const struct dev_pm_ops etnaviv_gpu_pm_ops = {
>> - SET_RUNTIME_PM_OPS(etnaviv_gpu_rpm_suspend,
>> etnaviv_gpu_rpm_resume,
>> - NULL)
>> + RUNTIME_PM_OPS(etnaviv_gpu_rpm_suspend, etnaviv_gpu_rpm_resume,
>> NULL)
>> };
>>
>> struct platform_driver etnaviv_gpu_driver = {
>> .driver = {
>> .name = "etnaviv-gpu",
>> .owner = THIS_MODULE,
>> - .pm = &etnaviv_gpu_pm_ops,
>> + .pm = pm_ptr(&etnaviv_gpu_pm_ops),
>> .of_match_table = etnaviv_gpu_match,
>> },
>> .probe = etnaviv_gpu_platform_probe,
>
>
next prev parent reply other threads:[~2022-11-07 21:03 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 17:50 [PATCH 00/26] drm: Get rid of #ifdef CONFIG_PM* guards Paul Cercueil
2022-11-07 17:50 ` [PATCH 01/26] drm: modeset-helper: Export dev_pm_ops for simple drivers Paul Cercueil
2022-11-08 12:10 ` Thomas Zimmermann
2022-11-08 12:33 ` Paul Cercueil
2022-11-07 17:50 ` [PATCH 02/26] drm: bochs: Use the dev_pm_ops provided by modeset helper Paul Cercueil
2022-11-07 17:50 ` [PATCH 03/26] drm: imx: " Paul Cercueil
2022-11-07 17:50 ` [PATCH 04/26] drm: rockchip: " Paul Cercueil
2022-11-07 17:50 ` [PATCH 05/26] drm: tegra: " Paul Cercueil
2022-11-07 17:50 ` [PATCH 06/26] drm: sun4i: " Paul Cercueil
2022-11-14 0:34 ` Samuel Holland
2022-11-07 17:50 ` [PATCH 07/26] drm: msxfb: " Paul Cercueil
2022-11-07 17:50 ` [PATCH 08/26] drm: atmel-hlcdc: Remove #ifdef guards for PM related functions Paul Cercueil
2022-11-07 17:53 ` Sam Ravnborg
2022-11-10 15:28 ` Claudiu.Beznea
2022-11-07 17:50 ` [PATCH 09/26] drm: exynos: " Paul Cercueil
2022-11-21 4:25 ` Inki Dae
2022-11-07 17:50 ` [PATCH 10/26] drm: imx/dcss: " Paul Cercueil
2022-11-11 14:27 ` Laurentiu Palcu
2022-11-07 17:52 ` [PATCH 11/26] drm: bridge/dw-hdmi: " Paul Cercueil
2022-11-07 17:52 ` [PATCH 12/26] drm: etnaviv: " Paul Cercueil
2022-11-07 18:07 ` Lucas Stach
2022-11-07 21:03 ` Paul Cercueil [this message]
2022-11-07 17:52 ` [PATCH 13/26] drm: fsl-dcu: " Paul Cercueil
2022-11-07 17:52 ` [PATCH 14/26] drm: mediatek: " Paul Cercueil
2022-11-07 17:52 ` [PATCH 15/26] drm: omap: " Paul Cercueil
2022-11-07 17:52 ` [PATCH 16/26] drm: panfrost: " Paul Cercueil
2022-11-09 15:16 ` Steven Price
2022-11-07 17:52 ` [PATCH 17/26] drm: rcar-du: " Paul Cercueil
2022-11-16 13:41 ` Kieran Bingham
2022-11-07 17:52 ` [PATCH 18/26] drm: rockchip: " Paul Cercueil
2022-11-07 17:52 ` [PATCH 19/26] drm: shmobile: " Paul Cercueil
2022-11-16 13:41 ` Kieran Bingham
2022-11-07 17:52 ` [PATCH 20/26] drm: tegra: " Paul Cercueil
2022-11-07 17:52 ` [PATCH 21/26] drm: tilcdc: " Paul Cercueil
2022-11-07 17:52 ` [PATCH 22/26] drm: vboxvideo: " Paul Cercueil
2022-11-07 19:43 ` Hans de Goede
2022-11-07 17:52 ` [PATCH 23/26] drm: vc4: " Paul Cercueil
2022-11-07 20:27 ` [PATCH 21/26] drm: tilcdc: " sarha
2022-11-07 17:55 ` [PATCH 24/26] drm: gm12u320: " Paul Cercueil
2022-11-07 17:55 ` [PATCH 25/26] drm: tidss: " Paul Cercueil
2022-11-07 17:55 ` [PATCH 26/26] drm/i915/gt: " Paul Cercueil
2022-11-07 20:31 ` Rodrigo Vivi
2022-11-07 20:59 ` Paul Cercueil
2022-11-07 19:43 ` [PATCH 24/26] drm: gm12u320: " Hans de Goede
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=M5XZKR.3DW6QGFX6KVP1@crapouillou.net \
--to=paul@crapouillou.net \
--cc=airlied@gmail.com \
--cc=christian.gmeiner@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=l.stach@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=tzimmermann@suse.de \
/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®