1. 27 4月, 2016 1 次提交
    • I
      drm/i915: Fix system resume if PCI device remained enabled · dab9a266
      Imre Deak 提交于
      During system resume we depended on pci_enable_device() also putting the
      device into PCI D0 state. This won't work if the PCI device was already
      enabled but still in D3 state. This is because pci_enable_device() is
      refcounted and will not change the HW state if called with a non-zero
      refcount. Leaving the device in D3 will make all subsequent device
      accesses fail.
      
      This didn't cause a problem most of the time, since we resumed with an
      enable refcount of 0. But it fails at least after module reload because
      after that we also happen to leak a PCI device enable reference: During
      probing we call drm_get_pci_dev() which will enable the PCI device, but
      during device removal drm_put_dev() won't disable it. This is a bug of
      its own in DRM core, but without much harm as it only leaves the PCI
      device enabled. Fixing it is also a bit more involved, due to DRM
      mid-layering and because it affects non-i915 drivers too. The fix in
      this patch is valid regardless of the problem in DRM core.
      
      v2:
      - Add a code comment about the relation of this fix to the freeze/thaw
        vs. the suspend/resume phases. (Ville)
      - Add a code comment about the inconsistent ordering of set power state
        and device enable calls. (Chris)
      
      CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: stable@vger.kernel.org
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit 44410cd0)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      dab9a266
  2. 22 4月, 2016 4 次提交
  3. 19 4月, 2016 3 次提交
  4. 15 4月, 2016 3 次提交
  5. 14 4月, 2016 2 次提交
  6. 07 4月, 2016 1 次提交
  7. 05 4月, 2016 1 次提交
  8. 31 3月, 2016 1 次提交
  9. 30 3月, 2016 2 次提交
    • D
      vgacon: dummy implementation for vgacon_text_force · 44debe7a
      Daniel Vetter 提交于
      This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
      drivers.
      
      v2: Make the dummy function actually return a sane value, spotted by
      Ville.
      
      v3: Because the patch is still in limbo there's no more drivers to
      convert, noticed by Emil.
      
      v4: Rebase once more, because hooray. I'll just go ahead an apply this
      one later on to drm-misc.
      
      Cc: Emil Velikov <emil.l.velikov@gmail.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      44debe7a
    • L
      drm/i915: Call intel_dp_mst_resume() before resuming displays · a16b7658
      Lyude 提交于
      Since we need MST devices ready before we try to resume displays,
      calling this after intel_display_resume() can result in some issues with
      various laptop docks where the monitor won't turn back on after
      suspending the system.
      
      This order was originally changed in
      
      	commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state")
      
      In order to fix some unclaimed register errors, however the actual cause
      of those has since been fixed.
      
      CC: stable@vger.kernel.org
      Signed-off-by: NLyude <cpaul@redhat.com>
      [danvet: Resolve conflicts with locking changes.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a16b7658
  10. 22 3月, 2016 2 次提交
  11. 21 3月, 2016 1 次提交
  12. 17 3月, 2016 1 次提交
  13. 16 2月, 2016 1 次提交
  14. 09 2月, 2016 1 次提交
  15. 29 1月, 2016 2 次提交
  16. 21 1月, 2016 1 次提交
  17. 14 1月, 2016 1 次提交
  18. 12 1月, 2016 2 次提交
  19. 08 1月, 2016 1 次提交
  20. 17 12月, 2015 1 次提交
    • I
      drm/i915: add support for checking if we hold an RPM reference · 1f814dac
      Imre Deak 提交于
      Atm, we assert that the device is not suspended until the point when the
      device is truly put to a suspended state. This is fine, but we can catch
      more problems if we check that RPM refcount is non-zero. After that one
      drops to zero we shouldn't access the device any more, even if the actual
      device suspend may be delayed. Change assert_rpm_wakelock_held()
      accordingly to check for a non-zero RPM refcount in addition to the
      current device-not-suspended check.
      
      For the new asserts to work we need to annotate every place explicitly in
      the code where we expect that the device is powered. The places where we
      only assume this, but may not hold an RPM reference:
      - driver load
        We assume the device to be powered until we enable RPM. Make this
        explicit by taking an RPM reference around the load function.
      - system and runtime sudpend/resume handlers
        These handlers are called when the RPM reference becomes 0 and know the
        exact point after which the device can get powered off. Disable the
        RPM-reference-held check for their duration.
      - the IRQ, hangcheck and RPS work handlers
        These handlers are flushed in the system/runtime suspend handler
        before the device is powered off, so it's guaranteed that they won't
        run while the device is powered off even though they don't hold any
        RPM reference. Disable the RPM-reference-held check for their duration.
      
      In all these cases we still check that the device is not suspended.
      These explicit annotations also have the positive side effect of
      documenting our assumptions better.
      
      This caught additional WARNs from the atomic modeset path, those should
      be fixed separately.
      
      v2:
      - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville)
      v3:
      - use a new dedicated RPM wakelock refcount to also catch cases where
        our own RPM get/put functions were not called (Chris)
      - assert also that the new RPM wakelock refcount is 0 in the RPM
        suspend handler (Chris)
      - change the assert error message to be more meaningful (Chris)
      - prevent false assert errors and check that the RPM wakelock is 0 in
        the RPM resume handler too
      - prevent false assert errors in the hangcheck work too
      - add a device not suspended assert check to the hangcheck work
      v4:
      - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts
        and wakelock_count to wakeref_count
      - disable the wakeref asserts in the IRQ handlers and RPS work too
      - update/clarify commit message
      v5:
      - mark places we plan to change to use proper RPM refcounting with
        separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1450227139-13471-1-git-send-email-imre.deak@intel.com
      1f814dac
  21. 16 12月, 2015 1 次提交
  22. 10 12月, 2015 2 次提交
  23. 05 12月, 2015 1 次提交
  24. 04 12月, 2015 2 次提交
  25. 26 11月, 2015 1 次提交
  26. 23 11月, 2015 1 次提交