On Wed, Jun 18, 2014 at 02:41:34PM +0200, Daniel Vetter wrote: > On Wed, Jun 18, 2014 at 01:27:06PM +0100, Chris Wilson wrote: > > On Wed, Jun 18, 2014 at 01:59:10PM +0200, Daniel Vetter wrote: > > > We need to make sure that no one else is using this in the > > > enable function and also that the work item hasn't raced > > > with the disabled function. > > > > > > v2: Improve bisectability by moving one hunk to an earlier patch. > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > --- > > > drivers/gpu/drm/i915/intel_dp.c | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > > > index 910f73de3a92..870219ff1187 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > @@ -1844,6 +1844,11 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp) > > > return; > > > } > > > > Is this the tail of a HAS_PSR() now made obsolete? > > Yeah, we have a bit of redundancy here now I think. Otoh once we have > locking they make sense again since HAS_PSR can be checked without > grabbing the psr lock, while psr.enabled can't. So I think it makes sense > to keep them. We do try to encourage the idiom of checking compatibility once at init, then checking state at runtime. If the lock becomes burdensome we can mitigate it. Hmm, such as frontbuffer_bits &= ~fb_tracking.busy_bits; /* only notify us for changes in state */ Further promoting the idea of refactoring cpu/gpu/flip tracking. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
