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