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 > > <ch...@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 <ch...@chris-wilson.co.uk> > > > Cc: Michal Wajdeczko <michal.wajdec...@intel.com> > > > Cc: Sagar Arun Kamble <sagar.a.kam...@intel.com> > > > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > > > Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com> > > > Reviewed-by: Mika Kuoppala <mika.kuopp...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
