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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx

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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux