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