Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function

["Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>]

On Tue, Sep 06, 2022 at 02:57:34PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 06, 2022 at 01:23:29PM +0300, Stanislav Lisovskiy wrote:
> > drm_dp_atomic_find_vcpi_slots no longer exists and needs
> > to be used as drm_dp_atomic_find_time_slots.
> > Also rename the function itself.
> > 
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to separate function")
> 
> The problem only exists in drm-tip. You need to revert the 
> bad merge from rerere-cache and redo it.
> 
> And please always test build drm-tip after solving merge conflicts!

I would really like to figure out how it did end like that.

Here is the sequence of what I've been doing:

1) There was a series supposed to be merged which had this new
   change already in place i.e using drm_dp_atomic_find_time_slots.
2) Then using dim tools I started pushing according to workflow:
   a) dim update-branches
   b) dim checkout drm-intel-next
   c) wget those series mbox and run dim apply-branch drm-intel-next
      Got conflict: it was complaining about those changes around
      drm_dp_atomic_find_time_slots and after some checking I figured
      out that drm_dp_atomic_find_time_slots doesn't exist anymore.
      Here probably was my bad, as I wrongly assumed that those changes
      were probably reverted as it was also mentioned, that there was
      regression because of those.
      
      So I resolved this conflict by putting drm_dp_atomic_find_vcpi_slots
      back instead of drm_dp_atomic_find_time_slots _and_ actually
      built it even.
   
   d) I run dim push-branch drm-intel-next, it did complain about merge
      conflict again with drm-intel-next which I fixed and results were
      pushed.
      I should have build at this moment as well probably. 
 
      Then I noticed that this function drm_dp_atomic_find_vcpi_slots
      doesn't exist in drm. So basically patches should have been pushed
      as they were initially, but why the conflict appeared initially - that is my
      question.

Stan

> 
> -- 
> Ville Syrjälä
> Intel