[Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

Jani Nikula jani.nikula at intel.com
Wed Mar 1 17:39:21 UTC 2017


On Wed, 01 Mar 2017, Jani Nikula <jani.nikula at intel.com> wrote:
> On Wed, 01 Mar 2017, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
>>> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>>> 
>>> I assumed it's ok, but really should have double-checked - CI caught
>>> tons of fail :(
>
> Considering the velocity of drm-tip, I think any CI results for patches
> have a rather limited best before date. The patch should've been resent
> and gone through testing again before merging.
>
>> For the record, the failure comes from the error message in
>> intel_dp_get_link_train_fallback_values() as take the fallback path. As
>> userspace is informed, we don't need an *ERROR* at that point.
>>
>> The really interesting question is why we are seeing link-training
>> failures in CI at all, and whether igt should be checking and reporting
>> link-status=BAD.
>
> It's possible (I didn't check the logs) this pertains to the failure
> mode I've sometimes seen, where clock recovery fails, but as we continue
> with channel equalization anyway (without this patch), everything
> succeeds there. At worst we need to root cause and fix that issue
> first. :(

Also, possibly to "avoid noise" in CI, the relevant error messages in
intel_dp_link_training_clock_recovery() have been brushed under the
carpet by demoting them to DRM_DEBUG_KMS, so we don't really see this
happening unless we actually eyeball the logs.

>
> BR,
> Jani.

-- 
Jani Nikula, Intel Open Source Technology Center


More information about the Intel-gfx mailing list