1. 01 1月, 2020 1 次提交
  2. 29 12月, 2019 2 次提交
  3. 28 12月, 2019 2 次提交
  4. 23 12月, 2019 1 次提交
  5. 17 12月, 2019 1 次提交
  6. 09 12月, 2019 1 次提交
  7. 04 12月, 2019 1 次提交
  8. 30 11月, 2019 1 次提交
  9. 20 11月, 2019 1 次提交
  10. 16 11月, 2019 1 次提交
  11. 14 11月, 2019 1 次提交
  12. 06 11月, 2019 2 次提交
    • I
      drm/i915/gen8+: Add RC6 CTX corruption WA · 7e34f4e4
      Imre Deak 提交于
      In some circumstances the RC6 context can get corrupted. We can detect
      this and take the required action, that is disable RC6 and runtime PM.
      The HW recovers from the corrupted state after a system suspend/resume
      cycle, so detect the recovery and re-enable RC6 and runtime PM.
      
      v2: rebase (Mika)
      v3:
      - Move intel_suspend_gt_powersave() to the end of the GEM suspend
        sequence.
      - Add commit message.
      v4:
      - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API
        change.
      v5: rebased on gem/gt split (Mika)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      7e34f4e4
    • U
      drm/i915: Lower RM timeout to avoid DSI hard hangs · 1d85a299
      Uma Shankar 提交于
      In BXT/APL, device 2 MMIO reads from MIPI controller requires its PLL
      to be turned ON. When MIPI PLL is turned off (MIPI Display is not
      active or connected), and someone (host or GT engine) tries to read
      MIPI registers, it causes hard hang. This is a hardware restriction
      or limitation.
      
      Driver by itself doesn't read MIPI registers when MIPI display is off.
      But any userspace application can submit unprivileged batch buffer for
      execution. In that batch buffer there can be mmio reads. And these
      reads are allowed even for unprivileged applications. If these
      register reads are for MIPI DSI controller and MIPI display is not
      active during that time, then the MMIO read operation causes system
      hard hang and only way to recover is hard reboot. A genuine
      process/application won't submit batch buffer like this and doesn't
      cause any issue. But on a compromised system, a malign userspace
      process/app can generate such batch buffer and can trigger system
      hard hang (denial of service attack).
      
      The fix is to lower the internal MMIO timeout value to an optimum
      value of 950us as recommended by hardware team. If the timeout is
      beyond 1ms (which will hit for any value we choose if MMIO READ on a
      DSI specific register is performed without PLL ON), it causes the
      system hang. But if the timeout value is lower than it will be below
      the threshold (even if timeout happens) and system will not get into
      a hung state. This will avoid a system hang without losing any
      programming or GT interrupts, taking the worst case of lowest CDCLK
      frequency and early DC5 abort into account.
      Signed-off-by: NUma Shankar <uma.shankar@intel.com>
      Reviewed-by: NJon Bloomfield <jon.bloomfield@intel.com>
      1d85a299
  13. 01 11月, 2019 5 次提交
  14. 27 10月, 2019 1 次提交
  15. 25 10月, 2019 1 次提交
  16. 21 10月, 2019 1 次提交
  17. 18 10月, 2019 3 次提交
  18. 11 10月, 2019 2 次提交
  19. 10 10月, 2019 2 次提交
  20. 27 9月, 2019 1 次提交
  21. 25 9月, 2019 1 次提交
  22. 16 9月, 2019 1 次提交
  23. 12 9月, 2019 1 次提交
  24. 11 9月, 2019 1 次提交
  25. 07 9月, 2019 1 次提交
  26. 05 9月, 2019 1 次提交
  27. 24 8月, 2019 3 次提交