From: Lucas Stach <l.stach@pengutronix.de>
To: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: kernel@pengutronix.de, patchwork-lst@pengutronix.de,
etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Russell King <linux+etnaviv@armlinux.org.uk>
Subject: Re: [PATCH 3/8] drm/etnaviv: move runtime PM handling to events
Date: Thu, 15 Jun 2023 11:37:56 +0200 [thread overview]
Message-ID: <10d769fb8eb39b439b3cc793664a242e443261a7.camel@pengutronix.de> (raw)
In-Reply-To: <CAH9NwWfj0CKm3Q_bVjWi7PhhWfxQxeGfu1mo9bWdSe7xXrRW_w@mail.gmail.com>
Hi Christian,
Am Mittwoch, dem 14.06.2023 um 20:41 +0200 schrieb Christian Gmeiner:
> Hi Lucas
>
> >
> > Conceptually events are the right abstraction to handle the GPU
> > runtime PM state: as long as any event is pending the GPU can not
> > be idle. Events are also properly freed and reallocated when the
> > GPU has been reset after a hang.
> >
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_gem.h | 1 -
> > drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3 ---
> > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 27 ++++++++++++--------
> > 3 files changed, 16 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > index baa81cbf701a..a42d260cac2c 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > @@ -97,7 +97,6 @@ struct etnaviv_gem_submit {
> > struct list_head node; /* GPU active submit list */
> > struct etnaviv_cmdbuf cmdbuf;
> > struct pid *pid; /* submitting process */
> > - bool runtime_resumed;
> > u32 exec_state;
> > u32 flags;
> > unsigned int nr_pmrs;
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > index 45403ea38906..2416c526f9b0 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > @@ -362,9 +362,6 @@ static void submit_cleanup(struct kref *kref)
> > container_of(kref, struct etnaviv_gem_submit, refcount);
> > unsigned i;
> >
> > - if (submit->runtime_resumed)
> > - pm_runtime_put_autosuspend(submit->gpu->dev);
> > -
> > if (submit->cmdbuf.suballoc)
> > etnaviv_cmdbuf_free(&submit->cmdbuf);
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > index 4e18aa8566c6..54a1249c5bca 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > @@ -1139,7 +1139,8 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
> > unsigned int *events)
> > {
> > unsigned long timeout = msecs_to_jiffies(10 * 10000);
> > - unsigned i, acquired = 0;
> > + unsigned i, acquired = 0, rpm_count = 0;
>
> rpm is the short form of runtime power management?
>
Yes, it's used in this way in multiple places in the kernel. Do you
think it's clear enough from the code what's going on to keep it that
way or should I change it to a longer name?
Regards,
Lucas
> > + int ret;
> >
> > for (i = 0; i < nr_events; i++) {
> > unsigned long ret;
> > @@ -1148,6 +1149,7 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
> >
> > if (!ret) {
> > dev_err(gpu->dev, "wait_for_completion_timeout failed");
> > + ret = -EBUSY;
> > goto out;
> > }
> >
> > @@ -1167,13 +1169,23 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
> >
> > spin_unlock(&gpu->event_spinlock);
> >
> > + for (i = 0; i < nr_events; i++) {
> > + ret = pm_runtime_resume_and_get(gpu->dev);
> > + if (ret)
> > + goto out_rpm;
> > + rpm_count++;
> > + }
> > +
> > return 0;
> >
> > +out_rpm:
> > + for (i = 0; i < rpm_count; i++)
> > + pm_runtime_put_autosuspend(gpu->dev);
> > out:
> > for (i = 0; i < acquired; i++)
> > complete(&gpu->event_free);
> >
> > - return -EBUSY;
> > + return ret;
> > }
> >
> > static void event_free(struct etnaviv_gpu *gpu, unsigned int event)
> > @@ -1185,6 +1197,8 @@ static void event_free(struct etnaviv_gpu *gpu, unsigned int event)
> > clear_bit(event, gpu->event_bitmap);
> > complete(&gpu->event_free);
> > }
> > +
> > + pm_runtime_put_autosuspend(gpu->dev);
> > }
> >
> > /*
> > @@ -1327,15 +1341,6 @@ struct dma_fence *etnaviv_gpu_submit(struct etnaviv_gem_submit *submit)
> > unsigned int i, nr_events = 1, event[3];
> > int ret;
> >
> > - if (!submit->runtime_resumed) {
> > - ret = pm_runtime_get_sync(gpu->dev);
> > - if (ret < 0) {
> > - pm_runtime_put_noidle(gpu->dev);
> > - return NULL;
> > - }
> > - submit->runtime_resumed = true;
> > - }
> > -
> > /*
> > * if there are performance monitor requests we need to have
> > * - a sync point to re-configure gpu and process ETNA_PM_PROCESS_PRE
> > --
> > 2.39.2
> >
>
>
next prev parent reply other threads:[~2023-06-15 9:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 13:02 [PATCH 1/8] drm/etnaviv: move down etnaviv_gpu_recover_hang() in file Lucas Stach
2023-06-07 13:02 ` [PATCH 2/8] drm/etnaviv: free events the usual way in recover worker Lucas Stach
2023-06-14 18:39 ` Christian Gmeiner
2023-06-07 13:02 ` [PATCH 3/8] drm/etnaviv: move runtime PM handling to events Lucas Stach
2023-06-14 18:41 ` Christian Gmeiner
2023-06-15 9:37 ` Lucas Stach [this message]
2023-06-19 13:09 ` Christian Gmeiner
2023-06-07 13:02 ` [PATCH 4/8] drm/etnaviv: make clock handling symetric between runtime resume and suspend Lucas Stach
2023-06-14 18:42 ` Christian Gmeiner
2023-06-07 13:02 ` [PATCH 5/8] drm/etnaviv: avoid runtime PM usage in etnaviv_gpu_bind Lucas Stach
2023-06-19 13:12 ` Christian Gmeiner
2023-06-07 13:02 ` [PATCH 6/8] drm/etnaviv: better track GPU state Lucas Stach
2023-06-21 7:33 ` Christian Gmeiner
2023-06-07 13:02 ` [PATCH 7/8] drm/etnaviv: drop GPU initialized property Lucas Stach
2023-06-21 7:34 ` Christian Gmeiner
2023-06-07 13:02 ` [PATCH 8/8] drm/etnaviv: expedited MMU fault handling Lucas Stach
2023-06-21 7:35 ` Christian Gmeiner
2023-06-14 18:38 ` [PATCH 1/8] drm/etnaviv: move down etnaviv_gpu_recover_hang() in file Christian Gmeiner
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=10d769fb8eb39b439b3cc793664a242e443261a7.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=christian.gmeiner@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=kernel@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=patchwork-lst@pengutronix.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;
as well as URLs for NNTP newsgroup(s).