[Intel-gfx] [PATCH] drm/i915: Split out parking from the idle worker for reuse
Chris Wilson
chris at chris-wilson.co.uk
Fri Apr 6 15:25:09 UTC 2018
Quoting Chris Wilson (2018-04-06 16:21:04)
> Quoting Michal Wajdeczko (2018-04-06 16:18:53)
> > On Fri, 06 Apr 2018 16:33:39 +0200, Chris Wilson
> > <chris at chris-wilson.co.uk> wrote:
> >
> > > We will want to park GEM before disengaging the drive^W^W^W unwedging.
> > > Since we already do the work for idling, expose the guts as a new
> > > function that we can then reuse.
> > >
> > > v2: Just skip if already parked; makes it more forgiving to use by
> > > future callers.
> > >
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
> > > Cc: Sagar Arun Kamble <sagar.a.kamble at intel.com>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > > Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > > ---
> > > Even with the follow up patch on hold, I think this will be useful when
> > > we figure out the right order of operations in reset and stands by itself
> > > as an improvement.
> > >
> > > Any objections to pushing this by itself?
> > > -Chris
> >
> > I would only suggest to make this new function more symmetrical to
> > "mark_busy" from i915_request.c both in naming and location ;)
>
> Fine, we'll pull back unpark and export that as well!
The tricky part is trying to get the split correct; i915_request really
shouldn't be doing the GEM unpark itself, but that is, or at least was,
the convenient point to place it. The rationale for placing it there was
for autoenabling rps, but that can be rearranged now so maybe it will be
doable to push the mark_busy/unpark into the execbuf ioctl, i.e. back to
the GEM level.
Hmm.
-Chris
More information about the Intel-gfx
mailing list