Re: [RESEND] drm/i915: Interactive RPS mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Ville Syrjälä (2018-07-20 15:19:20)
> On Fri, Jul 20, 2018 at 03:03:09PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-07-20 14:50:25)
> > > On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> > > > Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > > > > Another question is what happens where there are parallel flips
> > > > > happening? One could undo the boost from the other AFAICS. But maybe
> > > > > we don't care enough to protect against that?
> > > > 
> > > > It's a counter, so the "interactive" mode remains high until all
> > > > concurrent flips are completed.
> > > 
> > > Ah. I guess the bool in the atomic state threw me off. I suppose that
> > > one is just an optimization to avoid calling the function more than
> > > once?
> > 
> > Yes, it's that I caught the RPS counter going negative. We have more
> > cleanup_plane than we prepared.... I believe that's from
> > find_initial_plane.
> 
> Hmm. I don't quite see how that could happen. I believe
> prepare_fb/cleanup_fb should be fully paired up within a single commit.

The way I read intel_find_initial_plane_obj() is that it writes the
current configuration into the current intel_crtc->base.primary->state.
I think that is where the initial mismatch comes from. Also we seem to
be quite adapt at not holding rps_interactive high after modeset
completion, which suggests to me that something sneaky is happening with
the plane_state duplication.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux