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

[Daniel Vetter]

On Sat, Dec 17, 2016 at 05:47:56AM +0000, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> > On Fri, 16 Dec 2016, Daniel Vetter <daniel at ffwll.ch> 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).
> > 
> > Yeah I rebased this (and provided a debug hack privately) so Martin can
> > test the modesetting changes.
> > 
> > BR,
> > Jani.
> > 
> > 
> 
> I tested the -modesetting patch, which Martin had provided to Manasi,
> with a compliance testing device (DPR-120) that can simulate link
> training failure. The link rate correctly lowered after the link_status
> property was set to BAD by the kernel and the userspace responded with a
> modeset. 
> 
> One thing that was not straight forward to figure out was I had to boot
> with i915.nuclear_pageflip=1. Is it documented somewhere that the
> property needs DRIVER_ATOMIC to be set, or is it implicit?

It should work without DRIVER_ATOMIC. At least the property should be
exposed ... If this does only work with DRIVER_ATOMIC set then we have a
bug somewhere. Can you pls try to figure out why it doesn't work?

> The other thing I had trouble with -modesetting was, there was no
> modeset following a long pulse from the sink at the begging of the test.
> I had to force a modeset by changing the resolution so that the link
> training path is executed. However, the link training failure induced a
> modeset without any intervention.

Sounds roughly like how it's supposed to work. For real mode configuration
changes the desktop environment is supposed to set the mode it wants, by
listening to the xrandr hotplug event. That's not the same as the udev
hotplug event. You can listen for the xrandr hotplug event using

$ xev -event randr

Cheers, Daniel

> 
> -DK
> 
> 
> > > -Daniel
> > >
> > >> 
> > >> 
> > >> Manasi Navare (2):
> > >>   drm: Add a new connector atomic property for link status
> > >>   drm/i915: Implement Link Rate fallback on Link training failure
> > >> 
> > >>  drivers/gpu/drm/drm_atomic.c                  | 16 +++++++++
> > >>  drivers/gpu/drm/drm_atomic_helper.c           | 15 ++++++++
> > >>  drivers/gpu/drm/drm_connector.c               | 52 +++++++++++++++++++++++++++
> > >>  drivers/gpu/drm/i915/intel_dp.c               | 27 ++++++++++++++
> > >>  drivers/gpu/drm/i915/intel_dp_link_training.c | 22 ++++++++++--
> > >>  drivers/gpu/drm/i915/intel_drv.h              |  3 ++
> > >>  include/drm/drm_connector.h                   | 19 ++++++++++
> > >>  include/drm/drm_mode_config.h                 |  5 +++
> > >>  include/uapi/drm/drm_mode.h                   |  4 +++
> > >>  9 files changed, 161 insertions(+), 2 deletions(-)
> > >> 
> > >> -- 
> > >> 2.1.4
> > >> 
> > >> _______________________________________________
> > >> dri-devel mailing list
> > >> dri-devel at lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch