[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180717103124.GO5565@intel.com>
Date: Tue, 17 Jul 2018 13:31:24 +0300
From: Ville Syrjälä <ville.syrjala@...ux.intel.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: Lyude Paul <lyude@...hat.com>, nouveau@...ts.freedesktop.org,
Archit Taneja <architt@...eaurora.org>,
David Airlie <airlied@...ux.ie>,
dri-devel@...ts.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
linux-kernel@...r.kernel.org, Ben Skeggs <bskeggs@...hat.com>
Subject: Re: [Nouveau] [PATCH v2 2/3] drm/nouveau: Fix runtime PM leak in
nv50_disp_atomic_commit()
On Tue, Jul 17, 2018 at 09:33:52AM +0200, Lukas Wunner wrote:
> On Thu, Jul 12, 2018 at 01:02:53PM -0400, Lyude Paul wrote:
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -1878,7 +1878,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
> > nv50_disp_atomic_commit_tail(state);
> >
> > drm_for_each_crtc(crtc, dev) {
> > - if (crtc->state->enable) {
> > + if (crtc->state->active) {
> > if (!drm->have_disp_power_ref) {
> > drm->have_disp_power_ref = true;
> > return 0;
>
> Somewhat tangential comment on this older patch, since you
> continue to dig around in the runtime PM area:
>
> Whenever a crtc is activated or deactivated in nouveau, we iterate
> over all crtcs and acquire a runtime PM if a crtc is active and
> previously there was no active one, or we drop a ref if none is
> active and previously there was an active one.
>
> For a while now I've been thinking that it would be more straightforward
> to acquire a ref whenever a crtc is activated and drop one when a crtc
> is deactivated, i.e. hold one ref for every active crtc. That way the
> have_disp_power_ref variable as well as the iteration logic could be
> removed, leading to a simplification. Just a suggestion anyway.
The current code looks somewhat busted anyway. First problem is that
it's accessing crtc->state without the appropriate locks held (unless
something always pulls in all crtcs to every commit?). Second issue
is that the rpm_put() is called without waiting for nonblocking commits
to have finished so it looks like you can currentlly remove the power
before the hardware has been properly shut down.
--
Ville Syrjälä
Intel
Powered by blists - more mailing lists