On Fri, Jan 20, 2017 at 06:27:29PM +0200, Martin Peres wrote: > 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 Thanks for the modesetting patch and the tool that listens to the hotplug events. I testing this whole setup with Xserver and KDE desktop environment with this tool running and verified that the DPR 120 link rate degradation test passes. From the dmesg logs, I verified that the link training fails first time, it sends the hotplug sets the Link status to BAD, Xserver handles this BAD link status by redoing a modeset and retrain the link at lower link rate. In this it kept the resolution same with lower (18) bpp. So the link status property is working as expected with modesetting driver. The tool was only required to respond with a modeset to the first hotplug event sent at the beginning of the test. This validates the pending two patches for link status: https://patchwork.freedesktop.org/series/16912/ Regards Manasi > > [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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
