Gabriel Krisman Bertazi <krisman@xxxxxxxxxxxxxxx> writes: > If the atomic commit doesn't include any new plane, there is no need to > choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out > early. Although, if the FBC setup failed in the previous commit, if the > current commit doesn't include new plane update, it tries to overwrite > no_fbc_reason to "no suitable CRTC for FBC". For that scenario, it is > better that we simply keep the old message in-place to make debugging > easier. > > A scenario where this happens is with the > igt@kms_frontbuffer_tracking@fbc-suspend testcase when executed on a > Haswell system with not enough stolen memory. When enabling the CRTC, > the FBC setup will be correctly initialized to a specific CRTC, but > won't be enabled, since there is not enough memory. The testcase will > then enable CRC checking, which requires a quirk for Haswell, which > issues a new atomic commit that doesn't update the planes. Since that > update doesn't include any new planes (and the FBC wasn't enabled), > intel_fbc_choose_crtc() will not find any suitable CRTC, but update the > error message, hiding the lack of memory information, which is the > actual cause of the initialization failure. As a result, this causes > that test, which should skip, to fail on Haswell. > > Changes since v1: > - Update commit message (Manasi) > Hi Manasi, (Resending this message, cause I think it bounced) Unless there are other concerns about this one, can you help me get it pushed? I don't have the commit rights. Thanks! -- Gabriel Krisman Bertazi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
