[Intel-gfx] [PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

Jani Nikula jani.nikula at linux.intel.com
Thu Jan 19 09:50:07 UTC 2017


On Wed, 18 Jan 2017, "Vivi, Rodrigo" <rodrigo.vivi at intel.com> wrote:
> On Wed, 2017-01-18 at 10:12 +0200, Jani Nikula wrote:
>> On Tue, 17 Jan 2017, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
>> > On Mon, Jan 16, 2017 at 2:04 AM, Jani Nikula
>> > <jani.nikula at linux.intel.com> wrote:
>> >> On Fri, 13 Jan 2017, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
>> >>> This and all the remaining patches on this series (6,7,8 and 9) got
>> >>> merged to dinq.
>> >>
>> >> Given that this patch series was not properly sent as a thread, I don't
>> >> think our CI ran it as a whole, and it should not have been pushed
>> >> before that.
>> >
>> > I assumed "[Intel-gfx] ✓ Fi.CI.BAT: success for enable psr2 for
>> > idle_screen on y-cordinate panel"
>> > was enough, giving the patches haven't drastically changed after.
>> 
>> The idea is to test the code that gets pushed...
>
> Yep, this makes sense, although I'm sure that BAT doesn't test any of
> the code touched...

Perhaps so. But the point of CI is more about ensuring you don't break
existing stuff and less about testing the stuff you submit.

> But this is another problem.
>
> Anyway, that won't happen again. But question: 
> should it be resent to mailing list or try-bot is fine?

Ideally we should test the patches that get pushed and push the patches
that were posted on the list. For transparency, our CI replies with
results to the series that were posted on the (intel-gfx) mailing list,
and we add a Link: tag back to the patches in the commit message. They
all tie in together.

Trybot tests patches that were posted to it privately, and if you apply
the patches that were tested by trybot, you apply patches that weren't
posted on the list. Or you apply patches that weren't tested.

I'd prefer the patches were posted both for testing and pushing.

BR,
Jani.



>
>> 
>> BR,
>> Jani.
>> 
>> 
>

-- 
Jani Nikula, Intel Open Source Technology Center


More information about the dri-devel mailing list