1. 13 Apr, 2017 3 commits
    • Manasi Navare's avatar
      drm/i915: Implement Link Rate fallback on Link training failure · 9301397a
      Manasi Navare authored
      If link training at a link rate optimal for a particular
      mode fails during modeset's atomic commit phase, then we
      let the modeset complete and then retry. We save the link rate
      value at which link training failed, update the link status property
      to "BAD" and use a lower link rate to prune the modes. It will redo
      the modeset on the current mode at lower link rate or if the current
      mode gets pruned due to lower link constraints then, it will send a
      hotplug uevent for userspace to handle it.
      
      This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
      4.3.1.6.
      
      This patch is a resend of the original commit id (233ce881
      "drm/i915: Implement Link Rate fallback on Link training failure")
      which got reverted in this commit id (afc1ebf4 Revert
      "drm/i915: Implement Link Rate fallback on Link training failure")
      due to CI failures.
      
      After investigating the CI failures it was found that these
      were essentially the failures which were always there but hidden because
      they used to be DRM_DEBUG_KMS messages for link failures so never got
      caught by CI. But now this patch actually throws DRM_ERROR if the link
      training fails at RBR and 1 lane. So it caught these link train failures.
      
      There were two failures:
      1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
      without eDP on Port A. But our VBT initialization code in the driver writes
      VBT defaults in a way that it always sets DP flag on Port A and this does
      not get cleared after parsing the VBT outputs. This has been fixed in
      commit id (bb1d1329 "drm/i915/vbt: split out defaults that are set
      when there is no VBT) and (66578857 "drm/i915/vbt: don't propagate
      errors from intel_bios_init())
      
      2. On ILK-650 desktop - This was happening because of a bad monitor desktop
      combination. I switched the monitor in the CI lab and that helped get rid
      of the link failures on ILK system.
      
      v10:
      * Rebase on drm-tip and resend after revert
      v9:
      * Use the trimmed max values of link rate/lane count based on
      link train fallback (Daniel Vetter)
      v8:
      * Set link_status to BAD first and then call mode_valid (Jani Nikula)
      v7:
      Remove the redundant variable in previous patch itself
      v6:
      * Obtain link rate index from fallback_link_rate using
      the helper intel_dp_link_rate_index (Jani Nikula)
      * Include fallback within intel_dp_start_link_train (Jani Nikula)
      v5:
      * Move set link status to drm core (Daniel Vetter, Jani Nikula)
      v4:
      * Add fallback support for non DDI platforms too
      * Set connector->link status inside set_link_status function
      (Jani Nikula)
      v3:
      * Set link status property to BAd unconditionally (Jani Nikula)
      * Dont use two separate variables link_train_failed and link_status
      to indicate same thing (Jani Nikula)
      v2:
      * Squashed a few patches (Jani Nikula)
      Acked-by: default avatarTony Cheng <tony.cheng@amd.com>
      Acked-by: default avatarHarry Wentland <Harry.wentland@amd.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
      9301397a
    • Ville Syrjälä's avatar
      drm/i915: Perform link quality check unconditionally during long pulse · 1a36147b
      Ville Syrjälä authored
      Apparently some DP sinks are a little nuts and cause HPD to drop
      intermittently during modesets. This happens eg. on an ASUS PB287Q.
      In oder to recover from this we can't really use the previous
      connector status to determine if the link needs retraining, so let's
      just ignore that piece of information and do the retrain
      unconditionally. We do of course still check whether the link is
      supposed to be running or not.
      
      To actually get read out the EDID and update things properly we
      also need to nuke the goto out added by commit 7d23e3c3
      ("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
      why that was there. Perhaps to avoid an EDID read if the connector
      status didn't appear to change, but that sort of thing is quite racy
      and would have failed anyway if we failed to keep up with the
      hotplugs (if we missed the HPD down in between two HPD ups). And
      now that we take this codepath unconditionally we definitely need
      to drop the goto as otherwise we would never do the EDID read.
      
      v2: Drop the goto that made us skip EDID reads entirely. Doh!
      v3: Rebase due to locking changes
          s/apparely/apparently/ in the comment (Chris)
      
      Cc: stable@vger.kernel.org
      Cc: Manasi Navare <manasi.d.navare@intel.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Reported-by: default avatarPalmer Dabbelt <palmer@dabbelt.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
      References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.htmlSigned-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
      1a36147b
    • daniele.ceraolospurio@intel.com's avatar
      drm/i915/guc: write wopcm related register once during uc init · 13f6c719
      daniele.ceraolospurio@intel.com authored
      The wopcm registers are write-once, so any write after the first one
      will just be ignored. The registers survive a GPU reset but not
      always a suspend/resume cycle, so to keep things simple keep the
      writes in the intel_uc_init_hw function instead of moving it earlier
      to make sure we attempt them every time we try to load GuC.
      
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Signed-off-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1491524332-23860-1-git-send-email-daniele.ceraolospurio@intel.com
      13f6c719
  2. 12 Apr, 2017 17 commits
  3. 11 Apr, 2017 20 commits