[Intel-gfx] [PATCH 4/3] drm/i915: pass intel_crtc as argument for intel_enable_pipe
Paulo Zanoni
przanoni at gmail.com
Tue Feb 11 18:09:47 CET 2014
2014-02-11 13:44 GMT-02:00 Daniel Vetter <daniel at ffwll.ch>:
> On Tue, Feb 11, 2014 at 4:23 PM, Paulo Zanoni <przanoni at gmail.com> wrote:
>>
>> 2014-02-10 15:23 GMT-02:00 Daniel Vetter <daniel at ffwll.ch>:
>>> 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 at intel.com>
>>>> >
>>>> > 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 at intel.com>
>>>>
>>>> Reviewed-by: Damien Lespiau <damien.lespiau at intel.com>
>>>
>>> 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
More information about the Intel-gfx
mailing list