Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> writes:
> Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi escreveu:
>> After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
>> intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
>> error
>> message if we don't have a plane in the new state, which should make
>> the
>> test skip, but the test code doesn't catch that message and tries to
>
> What was the previous message that was making the test skip? I was not
> expecting that patch would affect kms_frontbuffer_tracking behavior.
The previous message was "FBC disabled: not enough stolen memory". You
got me wondering if we should even enter that function if
intel_fbc_alloc_cfb failed. The patch I mentioned starts triggering the
failure because it changes the error message even if we never enter the
for_each_new_plane_in_state loop in intel_fbc_choose_crtc.
Does that makes sense? Let me take another look at the code and see
what I can come up with.
>
>> execute the test, triggering a test failure.
>
> Anyway, I'm trying to understand the situation here. I'm not sure if
> this fix is correct, I'm wondering if it's a problem in how the Kernel
> sets the messages. Please explain in more details why this patch does
> what it does.
>
--
Gabriel Krisman Bertazi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
