Re: [PATCH 0/2] drm: link status property and DP link training failure handling

From: Martin Peres <martin.peres@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/2] drm: link status property and DP link training failure handling
Date: Fri, 20 Jan 2017 18:27:29 +0200	[thread overview]
Message-ID: <35a03abf-df94-df8d-9e9b-41d026510626@linux.intel.com> (raw)
In-Reply-To: <20170119113412.GV31595@intel.com>

On 19/01/17 13:34, Ville Syrjälä wrote:
> On Wed, Jan 18, 2017 at 11:05:18PM +0200, Martin Peres wrote:
>> On 16/12/16 15:48, Daniel Vetter wrote:
>>> On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
>>>> The two remaining patches from [1], rebased.
>>>>
>>>> BR,
>>>> Jani.
>>>>
>>>>
>>>> [1] http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare@intel.com
>>>
>>> Just for the record, I think the only thing missing here is the Xorg
>>> review on the -modesetting patch. As soon as we have that I can vacuum
>>> this up (probably best through drm-misc, but not sure).
>>
>> Hey Daniel,
>>
>> I tested again on Monday -modesetting with the patch from Jani to inject
>> faults and did manage to get both the link-status BAD and a lower
>> resolution got select dynamically when running KDE. For the latter, I
>> however needed the following patch:
>> https://patchwork.kernel.org/patch/9491869/
>>
>> Now, that being said, Jani's patch just prevents a new modeset to work,
>> it does not tear down the current mode. This may be the reason why I do
>> not manage to get a black screen after > 3 failures (and already a
>> 1024x768 resolution).
>>
>> I however need to do more testing when running without a DE (straight X
>> + twm and xterm). Indeed, when I hotplug my DP screen, it gets to the
>> native resolution automatically without me asking for it using xrandr.
>> Also, the mode that is set does not seem to go through
>> intel_dp_start_link_train (what the heck?), so I do not get any failure
>> and I cannot induce one :s
>
> Presumably you're already pushing pixels out at the same resolution and
> the monitor just syncs up to it. I think depending on the monitor that
> might happen w/ or w/o link retraining.

Thanks a lot Ville, this is exactly what was going on!

I worked yesterday and today on a tool that would respond to randr 
events and perform a modeset to the highest mode available. As far as I 
can tell, it works exactly as expected!

I do not use the link-status much in -modesetting, aside from doing a 
fast-retraining in case of a BAD state, but I definitely proved that 
this kernel tree[0], this xserver patch[1] and this tool[2] are enough 
to handle gracefully link degradations and prune modes as they become 
unstable.

Please review the general idea and I will send the cleaned -modesetting 
patch as soon as we all agree. I will let Manasi do more testing with it 
and report back to us.

Thanks everyone for your help!

Martin

[0] https://cgit.freedesktop.org/~mperes/linux/log/?h=dp-compliance
[1] 
https://cgit.freedesktop.org/~mperes/xserver/commit/?h=dpcompliance&id=ce03d856c1121ca475cc88b9c64c2d2b95fa20bc
[2] https://cgit.freedesktop.org/~mperes/auto-randr
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx