From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Aradhya Bhatia <a-bhatia1@ti.com>,
Devarsh Thakkar <devarsht@ti.com>, Jyri Sarha <jyri.sarha@iki.fi>,
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,
Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: [PATCH 02/10] drm/tidss: Use PM autosuspend
Date: Mon, 6 Nov 2023 00:53:30 +0200 [thread overview]
Message-ID: <20231105225330.GA15635@pendragon.ideasonboard.com> (raw)
In-Reply-To: <7395880d-36ba-471c-ba7c-745a0ec8e5de@ideasonboard.com>
Hi Tomi,
CC'ing Sakari for his expertise on runtime PM (I think he will soon
start wishing he would be ignorant in this area).
On Thu, Nov 02, 2023 at 08:34:45AM +0200, Tomi Valkeinen wrote:
> On 01/11/2023 15:54, Laurent Pinchart wrote:
> > On Wed, Nov 01, 2023 at 11:17:39AM +0200, Tomi Valkeinen wrote:
> >> Use runtime PM autosuspend feature, with 1s timeout, to avoid
> >> unnecessary suspend-resume cycles when, e.g. the userspace temporarily
> >> turns off the crtcs when configuring the outputs.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> >> ---
> >> drivers/gpu/drm/tidss/tidss_drv.c | 8 +++++++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
> >> index f403db11b846..64914331715a 100644
> >> --- a/drivers/gpu/drm/tidss/tidss_drv.c
> >> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> >> @@ -43,7 +43,9 @@ void tidss_runtime_put(struct tidss_device *tidss)
> >>
> >> dev_dbg(tidss->dev, "%s\n", __func__);
> >>
> >> - r = pm_runtime_put_sync(tidss->dev);
> >> + pm_runtime_mark_last_busy(tidss->dev);
> >> +
> >> + r = pm_runtime_put_autosuspend(tidss->dev);
> >> WARN_ON(r < 0);
> >> }
> >>
> >> @@ -144,6 +146,9 @@ static int tidss_probe(struct platform_device *pdev)
> >>
> >> pm_runtime_enable(dev);
> >>
> >> + pm_runtime_set_autosuspend_delay(dev, 1000);
> >> + pm_runtime_use_autosuspend(dev);
> >> +
> >> #ifndef CONFIG_PM
> >> /* If we don't have PM, we need to call resume manually */
> >> dispc_runtime_resume(tidss->dispc);
> >
> > By the way, there's a way to handle this without any ifdef:
> >
> > dispc_runtime_resume(tidss->dispc);
> >
> > pm_runtime_set_active(dev);
> > pm_runtime_get_noresume(dev);
> > pm_runtime_enable(dev);
> > pm_runtime_set_autosuspend_delay(dev, 1000);
> > pm_runtime_use_autosuspend(dev);
>
> I'm not sure I follow what you are trying to do here. The call to
> dispc_runtime_resume() would crash if we have PM, as the HW would not be
> enabled at that point.
Isn't dispc_runtime_resume() meant to enable the hardware ?
The idea is to enable the hardware, then enable runtime PM, and tell the
runtime PM framework that the device is enabled. If CONFIG_PM is not
set, the RPM calls will be no-ops, and the device will stay enable. If
CONFIG_PM is set, the device will be enabled, and will get disabled at
end of probe by a call to pm_runtime_put_autosuspend().
> And even if it wouldn't, we don't want to call dispc_runtime_resume()
> in probe when we have PM.
Don't you need to enable the device at probe time in order to reset it,
as done in later patches in the series ?
> > Then, in the error path,
> >
> > pm_runtime_dont_use_autosuspend(dev);
> > pm_runtime_disable(dev);
> > pm_runtime_put_noidle(dev);
> >
> > dispc_runtime_suspend(tidss->dispc);
> >
> > And in remove:
> >
> > pm_runtime_dont_use_autosuspend(dev);
> > pm_runtime_disable(dev);
> > if (!pm_runtime_status_suspended(dev))
> > dispc_runtime_suspend(tidss->dispc);
> > pm_runtime_set_suspended(dev);
> >
> > And yes, runtime PM is a horrible API.
> >
> >> @@ -215,6 +220,7 @@ static void tidss_remove(struct platform_device *pdev)
> >> /* If we don't have PM, we need to call suspend manually */
> >> dispc_runtime_suspend(tidss->dispc);
> >> #endif
> >> + pm_runtime_dont_use_autosuspend(dev);
> >
> > This also needs to be done in the probe error path.
>
> Oops. Right, I'll add that.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2023-11-05 22:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-01 9:17 [PATCH 00/10] drm/tidss: Probe related fixes and cleanups Tomi Valkeinen
2023-11-01 9:17 ` [PATCH 01/10] drm/tidss: Use pm_runtime_resume_and_get() Tomi Valkeinen
2023-11-01 13:47 ` Laurent Pinchart
2023-11-01 9:17 ` [PATCH 02/10] drm/tidss: Use PM autosuspend Tomi Valkeinen
2023-11-01 13:54 ` Laurent Pinchart
2023-11-02 6:34 ` Tomi Valkeinen
2023-11-05 22:53 ` Laurent Pinchart [this message]
2023-11-06 7:54 ` Tomi Valkeinen
2023-11-01 9:17 ` [PATCH 03/10] drm/tidss: Drop useless variable init Tomi Valkeinen
2023-11-01 13:54 ` Laurent Pinchart
2023-11-01 9:17 ` [PATCH 04/10] drm/tidss: Move reset to the end of dispc_init() Tomi Valkeinen
2023-11-01 13:57 ` Laurent Pinchart
2023-11-02 6:40 ` Tomi Valkeinen
2023-11-05 22:54 ` Laurent Pinchart
2023-11-06 11:56 ` Tomi Valkeinen
2023-11-01 9:17 ` [PATCH 05/10] drm/tidss: Return error value from from softreset Tomi Valkeinen
2023-11-01 13:59 ` Laurent Pinchart
2023-11-02 6:44 ` Tomi Valkeinen
2023-11-01 9:17 ` [PATCH 06/10] drm/tidss: Check for K2G in in dispc_softreset() Tomi Valkeinen
2023-11-01 14:22 ` Laurent Pinchart
2023-11-01 9:17 ` [PATCH 07/10] drm/tidss: Fix dss reset Tomi Valkeinen
2023-11-01 14:30 ` Laurent Pinchart
2023-11-02 7:33 ` Tomi Valkeinen
2023-11-02 14:54 ` Francesco Dolcini
2023-11-01 9:17 ` [PATCH 08/10] drm/tidss: Add dispc_is_idle() Tomi Valkeinen
2023-11-01 14:32 ` Laurent Pinchart
2023-11-02 7:03 ` Tomi Valkeinen
2023-11-01 9:17 ` [PATCH 09/10] drm/tidss: IRQ code cleanup Tomi Valkeinen
2023-11-01 14:52 ` Laurent Pinchart
2023-11-02 7:00 ` Tomi Valkeinen
2023-11-01 9:17 ` [PATCH 10/10] drm/tidss: Fix atomic_flush check Tomi Valkeinen
2023-11-01 14:56 ` Laurent Pinchart
2023-11-02 8:23 ` Tomi Valkeinen
2023-11-02 14:55 ` Francesco Dolcini
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=20231105225330.GA15635@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=a-bhatia1@ti.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=devarsht@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jyri.sarha@iki.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sakari.ailus@iki.fi \
--cc=tomi.valkeinen@ideasonboard.com \
--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®