1. 11 6月, 2019 2 次提交
  2. 02 5月, 2019 1 次提交
  3. 17 4月, 2019 2 次提交
  4. 03 4月, 2019 1 次提交
  5. 24 3月, 2019 1 次提交
  6. 27 2月, 2019 1 次提交
  7. 20 2月, 2019 2 次提交
    • J
      drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set · 6a204bd5
      Joonas Lahtinen 提交于
      commit 2e7bd10e05afb866b5fb13eda25095c35d7a27cc upstream.
      
      Make sure the underlying VMA in the process address space is the
      same as it was during vm_mmap to avoid applying WC to wrong VMA.
      
      A more long-term solution would be to have vm_mmap_locked variant
      in linux/mmap.h for when caller wants to hold mmap_sem for an
      extended duration.
      
      v2:
      - Refactor the compare function
      
      Fixes: 1816f923 ("drm/i915: Support creation of unbound wc user mappings for objects")
      Reported-by: NAdam Zabrocki <adamza@microsoft.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.0+
      Cc: Akash Goel <akash.goel@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Adam Zabrocki <adamza@microsoft.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1
      Link: https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-1-joonas.lahtinen@linux.intel.com
      (cherry picked from commit 5c4604e757ba9b193b09768d75a7d2105a5b883f)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a204bd5
    • L
      drm/i915: Block fbdev HPD processing during suspend · 4631e0b4
      Lyude Paul 提交于
      commit e8a8fedd57fdcebf0e4f24ef0fc7e29323df8e66 upstream.
      
      When resuming, we check whether or not any previously connected
      MST topologies are still present and if so, attempt to resume them. If
      this fails, we disable said MST topologies and fire off a hotplug event
      so that userspace knows to reprobe.
      
      However, sending a hotplug event involves calling
      drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
      connector reprobe in the caller's thread - something we can't do at the
      point in which i915 calls drm_dp_mst_topology_mgr_resume() since
      hotplugging hasn't been fully initialized yet.
      
      This currently causes some rather subtle but fatal issues. For example,
      on my T480s the laptop dock connected to it usually disappears during a
      suspend cycle, and comes back up a short while after the system has been
      resumed. This guarantees pretty much every suspend and resume cycle,
      drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
      a connector hotplug will occur. Now it's Rute Goldberg time: when the
      connector hotplug occurs, i915 reprobes /all/ of the connectors,
      including eDP. However, eDP probing requires that we power on the panel
      VDD which in turn, grabs a wakeref to the appropriate power domain on
      the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
      things start breaking, since this all happens before
      intel_power_domains_enable() is called we end up leaking the wakeref
      that was acquired and never releasing it later. Come next suspend/resume
      cycle, this causes us to fail to shut down the GPU properly, which
      causes it not to resume properly and die a horrible complicated death.
      
      (as a note: this only happens when there's both an eDP panel and MST
      topology connected which is removed mid-suspend. One or the other seems
      to always be OK).
      
      We could try to fix the VDD wakeref leak, but this doesn't seem like
      it's worth it at all since we aren't able to handle hotplug detection
      while resuming anyway. So, let's go with a more robust solution inspired
      by nouveau: block fbdev from handling hotplug events until we resume
      fbdev. This allows us to still send sysfs hotplug events to be handled
      later by user space while we're resuming, while also preventing us from
      actually processing any hotplug events we receive until it's safe.
      
      This fixes the wakeref leak observed on the T480s and as such, also
      fixes suspend/resume with MST topologies connected on this machine.
      
      Changes since v2:
      * Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
        (Chris Wilson)
      * Don't call drm_fb_helper_hotplug_event() in
        intel_fbdev_output_poll_changed() under lock (Chris Wilson)
      * Always set ifbdev->hpd_waiting (Chris Wilson)
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: 0e32b39c ("drm/i915: add DP 1.2 MST support (v0.7)")
      Cc: Todd Previte <tprevite@gmail.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: <stable@vger.kernel.org> # v3.17+
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
      (cherry picked from commit fe5ec65668cdaa4348631d8ce1766eed43b33c10)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4631e0b4
  8. 15 2月, 2019 1 次提交
  9. 23 1月, 2019 1 次提交
    • Z
      drm/i915/gvt: Fix mmap range check · ac8b9e8e
      Zhenyu Wang 提交于
      commit 51b00d8509dc69c98740da2ad07308b630d3eb7d upstream.
      
      This is to fix missed mmap range check on vGPU bar2 region
      and only allow to map vGPU allocated GMADDR range, which means
      user space should support sparse mmap to get proper offset for
      mmap vGPU aperture. And this takes care of actual pgoff in mmap
      request as original code always does from beginning of vGPU
      aperture.
      
      Fixes: 659643f7 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
      Cc: "Monroy, Rodrigo Axel" <rodrigo.axel.monroy@intel.com>
      Cc: "Orrala Contreras, Alfredo" <alfredo.orrala.contreras@intel.com>
      Cc: stable@vger.kernel.org # v4.10+
      Reviewed-by: NHang Yuan <hang.yuan@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac8b9e8e
  10. 17 1月, 2019 1 次提交
  11. 20 12月, 2018 2 次提交
  12. 13 12月, 2018 1 次提交
  13. 01 12月, 2018 1 次提交
    • V
      drm/i915: Disable LP3 watermarks on all SNB machines · 382debd2
      Ville Syrjälä 提交于
      commit 21556350ade3cb5d7afecc8b3544e56431d21695 upstream.
      
      I have a Thinkpad X220 Tablet in my hands that is losing vblank
      interrupts whenever LP3 watermarks are used.
      
      If I nudge the latency value written to the WM3 register just
      by one in either direction the problem disappears. That to me
      suggests that the punit will not enter the corrsponding
      powersave mode (MPLL shutdown IIRC) unless the latency value
      in the register matches exactly what we read from SSKPD. Ie.
      it's not really a latency value but rather just a cookie
      by which the punit can identify the desired power saving state.
      On HSW/BDW this was changed such that we actually just write
      the WM level number into those bits, which makes much more
      sense given the observed behaviour.
      
      We could try to handle this by disallowing LP3 watermarks
      only when vblank interrupts are enabled but we'd first have
      to prove that only vblank interrupts are affected, which
      seems unlikely. Also we can't grab the wm mutex from the
      vblank enable/disable hooks because those are called with
      various spinlocks held. Thus we'd have to redesigne the
      watermark locking. So to play it safe and keep the code
      simple we simply disable LP3 watermarks on all SNB machines.
      
      To do that we simply zero out the latency values for
      watermark level 3, and we adjust the watermark computation
      to check for that. The behaviour now matches that of the
      g4x/vlv/skl wm code in the presence of a zeroed latency
      value.
      
      v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris)
      
      Cc: stable@vger.kernel.org
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrjala@linux.intel.com
      (cherry picked from commit 03981c6ebec4fc7056b9b45f847393aeac90d060)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      382debd2
  14. 27 11月, 2018 1 次提交
  15. 21 11月, 2018 21 次提交
  16. 03 10月, 2018 1 次提交