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

[Jani Nikula]

On Tue, 06 Sep 2022, "Lisovskiy, Stanislav" <stanislav.lisovskiy at intel.com> wrote:
> 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 at 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.

The rule of thumb is, don't resolve conflicts while applying
patches. Apply the patches as they were posted to the mailing list.

If your patches apply to drm-tip but not to drm-intel-next, you'll know
there's stuff in other branches that affect the lines. You'll end up
with problems both at patch apply and drm-tip rebuild if you don't get
the baseline right first.

>From the committer guidelines:

* As a general rule, do not modify the patches while applying, apart from the
  commit message. If the patch conflicts, or needs to be changed due to review,
  have the author rebase, update and resend. Any change at this stage is a
  potential issue bypassing CI.

BR,
Jani.

>    
>    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

-- 
Jani Nikula, Intel Open Source Graphics Center