1. 09 11月, 2017 1 次提交
  2. 02 11月, 2017 1 次提交
    • M
      drm/i915: Use fallback forcewake if primary ack missing · 71306303
      Mika Kuoppala 提交于
      There is a possibility on gen9 hardware to miss the forcewake ack
      message. The recommended workaround is to use another free
      bit and toggle it until original bit is successfully acknowledged.
      
      Some future gen9 revs might or might not fix the underlying issue but
      using fallback forcewake bit dance can be considered as harmless:
      without the ack timeout we never reach the fallback bit forcewake.
      Thus as of now we adopt a blanket approach for all gen9 and leave
      the bypassing the fallback bit approach for future patches if
      corresponding hw revisions do appear.
      
      Commit 83e33372 ("drm/i915: Increase maximum polling time to 50ms
      for forcewake request/clear ack") did increase the forcewake timeout.
      If the issue was a delayed ack, future work could include finding
      a suitable timeout value both for primary ack and reserve toggle
      to reduce the worst case latency.
      
      v2: use bit 15, naming, comment (Chris), only wait fallback ack
      v3: fix return on fallback, backoff after fallback write (Chris)
      v4: udelay on first pass, grammar (Chris)
      v4: s/reserve/fallback
      
      References: HSDES #1604254524
      References: https://bugs.freedesktop.org/show_bug.cgi?id=102051
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171102094836.2506-1-mika.kuoppala@linux.intel.com
      71306303
  3. 27 10月, 2017 1 次提交
    • R
      drm/i915/cnl: Fix SSEU Device Status. · f8c3dcf9
      Rodrigo Vivi 提交于
      CNL adds an extra register for slice/subslice information.
      Although no SKU is planed with an extra slice let's already
      handle this extra piece of information so we don't have the
      risk in future of getting a part that might have chosen this
      part of the die instead of other slices or anything like that.
      
      Also if subslice is disabled the information of eu ack for that
      is garbage, so let's skip checks for eu if subslice is disabled
      as we skip the subslice if slice is disabled.
      
      The rest is pretty much like gen9.
      
      v2: Remove IS_CANNONLAKE from gen9 status function.
      
      v3: Consider s_max = 6 and ss_max=4 to run over all possible
          slices and subslices possible by spec. Although no real
          hardware will have that many slices/subslices.
          To match with sseu info init.
      v4: Fix offset calculation for slices 4 and 5.
          Removed Oscar's rv-b since this change also needs review.
      v5: Let's consider only valid bits for SLICE*_PGCTL_ACK.
          This looks like wrong in Spec, but seems to be enough
          for now. Whenever Spec gets updated and fixed we come
          back and properly update the masks. Also add a FIXME,
          so we can revisit this later when we find some strange
          info on debugfs or when we noitce spec got updated.
      
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171026001546.28203-1-rodrigo.vivi@intel.com
      f8c3dcf9
  4. 25 10月, 2017 1 次提交
  5. 18 10月, 2017 1 次提交
  6. 13 10月, 2017 1 次提交
  7. 10 10月, 2017 2 次提交
  8. 07 10月, 2017 1 次提交
  9. 05 10月, 2017 1 次提交
  10. 03 10月, 2017 1 次提交
  11. 29 9月, 2017 1 次提交
  12. 27 9月, 2017 1 次提交
  13. 26 9月, 2017 1 次提交
    • U
      drm/i915: Enable scanline read based on frame timestamps · aec0246f
      Uma Shankar 提交于
      For certain platforms on certain encoders, timings are driven
      from port instead of pipe. Thus, we can't rely on pipe scanline
      registers to get the timing information. Some cases scanline
      register read will not be functional.
      This is causing vblank evasion logic to fail since it relies on
      scanline, causing atomic update failure warnings.
      
      This patch uses pipe framestamp and current timestamp registers
      to calculate scanline. This is an indirect way to get the scanline.
      It helps resolve atomic update failure for gen9 dsi platforms.
      
      v2: Addressed Ville and Daniel's review comments. Updated the
      register MACROs, handled race condition for register reads,
      extracted timings from the hwmode. Removed the dependency on
      crtc->config to get the encoder type.
      
      v3: Made get scanline function generic
      
      v4: Addressed Ville's review comments. Added a flag to decide timestamp
      based scanline reporting. Changed 64bit variables to u32
      
      v5: Adressed Ville's review comments. Put the scanline compute function
      at the place of caller. Removed hwmode flags from uapi and used a local
      i915 data structure instead.
      
      v6: Used vblank hwmode to get the timings.
      
      v7: Fixed sparse warnings, indentation and minor review comments.
      
      v8: Limited this only for Gen9 DSI.
      
      Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NUma Shankar <uma.shankar@intel.com>
      Signed-off-by: NChandra Konduru <chandra.konduru@intel.com>
      Signed-off-by: NVidya Srinivas <vidya.srinivas@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1506347761-4201-1-git-send-email-vidya.srinivas@intel.com
      aec0246f
  14. 20 9月, 2017 1 次提交
  15. 15 9月, 2017 1 次提交
  16. 14 9月, 2017 1 次提交
  17. 13 9月, 2017 2 次提交
  18. 09 9月, 2017 1 次提交
  19. 07 9月, 2017 3 次提交
  20. 06 9月, 2017 1 次提交
  21. 31 8月, 2017 2 次提交
  22. 26 8月, 2017 1 次提交
  23. 24 8月, 2017 2 次提交
  24. 19 8月, 2017 2 次提交
  25. 16 8月, 2017 1 次提交
  26. 15 8月, 2017 1 次提交
  27. 11 8月, 2017 3 次提交
  28. 10 8月, 2017 1 次提交
  29. 04 8月, 2017 2 次提交
  30. 27 7月, 2017 1 次提交