Re: [PATCH 02/24] drm/i915: Add some more tracked state to intel_pipe_wm

Daniel Vetter
2014-04-29T13:57:37Z

On Tue, Apr 29, 2014 at 09:34:28AM -0300, Paulo Zanoni wrote:
> 2014-04-29 8:20 GMT-03:00 Daniel Vetter <daniel@ffwll.ch>:
> > On Tue, Apr 29, 2014 at 01:18:50PM +0200, Daniel Vetter wrote:
> >> On Mon, Apr 07, 2014 at 11:14:05AM -0300, Paulo Zanoni wrote:
> >> > 2014-03-07 13:32 GMT-03:00 <ville.syrjala@linux.intel.com>:
> >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> > >
> >> > > intel_pipe_wm will be used to track the state in different stages
> >> > > of the watermark update process. For that we need to keep a bit
> >> > > more state in intel_pipe_wm.
> >> > >
> >> > > We also need to separate the multi-pipe intel_wm_config computation
> >> > > from ilk_compute_wm_parameters() as that one deals with the future
> >> > > state, and we need the intel_wm_config to match the current hardware
> >> > > state at the time we do the watermark merging for multiple pipes.
> >> > >
> >> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >
> >> > Needs minor rebase, but looks correct.
> >>
> >> Ok in my eyes this conflict looks a bit tricky, and since I lack the
> >> insight of you two for the watermark code I'd prefer a rebased version.
> >
> > Or is this just because dinq is a bit out of sync with -nightly? In that
> > case I'm stalling on Dave to open up drm-next so that I can rebase the
> > entire shebang ...
>
> I believe you have already applied patches 1-4 a few weeks ago. Maybe
> you're getting conflicts because you're applying already-applied
> patches? :)

Ah, that might indeed explain why the conflict looks so funny ;-)

/me puts on the idiot hat

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch