2014-02-11 13:44 GMT-02:00 Daniel Vetter <daniel@xxxxxxxx>: > On Tue, Feb 11, 2014 at 4:23 PM, Paulo Zanoni <przanoni@xxxxxxxxx> wrote: >> >> 2014-02-10 15:23 GMT-02:00 Daniel Vetter <daniel@xxxxxxxx>: >>> On Mon, Feb 10, 2014 at 02:17:03PM +0000, Damien Lespiau wrote: >>>> On Fri, Jan 17, 2014 at 01:51:09PM -0200, Paulo Zanoni wrote: >>>> > From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> >>>> > >>>> > We want to remove those 3 boolean arguments. This is the first step. >>>> > The "pipe" passed as the argument is always intel_crtc->pipe. >>>> > >>>> > Also adjust the function documentation. >>>> > >>>> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> >>>> >>>> Reviewed-by: Damien Lespiau <damien.lespiau@xxxxxxxxx> >>> >>> Ok, I've pulled in the entire series, but a bunch of things changed so had >>> to resolve some (minor) conflicts. Please double-check that I didn't botch >>> things up too badly. >> >> You forgot to apply patch 2, and this is probably the reason why every >> subsequent patch gave you a conflict. > > The conflicts where actually with one of Ville's patches to move the > plane enabling around. I've fixed those up but apparently then missed > the other conflict hidden underneath those. > >> You also applied patch 3 twice: once for Ironlake and once for >> Haswell. You shouldn't change the Ironlake function. >> >> Do you plan to rebase or do I need to submit patches on top? > > I've applied the missing patched and dropped the ironlake patch of the > double-merged one. So if the new tree looks ok no need to resend > anything. > >> IMHO if a series starts getting messy to apply, I think you should >> probably just ask the author to rebase and resend the final stuff. >> Maybe with this we would be able to reduce the amount of bad merges, >> which is becoming a very common problem, at least for my patches. > > The problem is that small conflicts are really common, both because I > want people to submit against drm-intel-nightly (so that I can do the > backmerging and branch shuffling correctly) and because of our > development speed. I don't think me asking for rebases in all these > cases is the better option. I tend to poke people to double-check when > I screw things up, but I guess it's just been bad luck that recently > the conflict fallout has always hit your patches :( > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
