1. 19 7月, 2018 1 次提交
    • R
      drm/i915: Kill sink_crc for good · 5fd9df6a
      Rodrigo Vivi 提交于
      It was originally introduced following the VESA spec in order to validate PSR.
      
      However we found so many issues around sink_crc that instead of helping PSR
      development it only brought another layer of trouble to the table.
      
      So, sink_crc has been a black whole for us in question of time, effort and hope.
      
      First of the problems is that HW statement is clear: "Do not attempt to use
      aux communication with PSR enabled". So the main reason behind sink_crc is
      already compromised.
      
      For a while we had hope on the aux-mutex could workaround this problem on SKL+
      platforms, but that mutex was not reliable, not tested,
      and we shouldn't use according to HW engineers.
      
      Also, nor source, nor sink designed and implemented the sink_crc to be used like
      we are trying to use here.
      
      Well, the sink side of things is also apparently not prepared for this
      case. Each panel that we tried seemed to have a different behavior with same
      code and same source.
      
      So, for all the time we lost on trying to ducktape all these different issues
      I believe it is now time to move PSR to a more reliable validation.
      Maybe not a perfect one as we dreamed for this sink_crc, but at least more
      reliable.
      
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180705192528.30515-1-rodrigo.vivi@intel.com
      5fd9df6a
  2. 13 7月, 2018 1 次提交
  3. 09 7月, 2018 1 次提交
    • C
      drm/i915: Provide a timeout to i915_gem_wait_for_idle() · ec625fb9
      Chris Wilson 提交于
      Usually we have no idea about the upper bound we need to wait to catch
      up with userspace when idling the device, but in a few situations we
      know the system was idle beforehand and can provide a short timeout in
      order to very quickly catch a failure, long before hangcheck kicks in.
      
      In the following patches, we will use the timeout to curtain two overly
      long waits, where we know we can expect the GPU to complete within a
      reasonable time or declare it broken.
      
      In particular, with a broken GPU we expect it to fail during the initial
      GPU setup where do a couple of context switches to record the defaults.
      This is a task that takes a few milliseconds even on the slowest of
      devices, but we may have to wait 60s for hangcheck to give in and
      declare the machine inoperable. In this a case where any gpu hang is
      unacceptable, both from a timeliness and practical standpoint.
      
      The other improvement is that in selftests, we do not need to arm an
      independent timer to inject a wedge, as we can just limit the timeout on
      the wait directly.
      
      v2: Include the timeout parameter in the trace.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180709122044.7028-1-chris@chris-wilson.co.uk
      ec625fb9
  4. 06 7月, 2018 1 次提交
  5. 03 7月, 2018 1 次提交
  6. 29 6月, 2018 1 次提交
  7. 15 6月, 2018 3 次提交
    • C
      drm/i915: Keep the ctx workarounds tightly packed · 548764bb
      Chris Wilson 提交于
      For each platform, we have a few registers that are rewritten with
      different values -- they are not part of a sequence, just different parts
      of a masked register set at different times (e.g. platform and gen
      workarounds). Consolidate these into a single register write to keep the
      table compact, important since we are running of room in the current
      fixed sized buffer.
      
      While adjusting the construction of the wa table, make it non fatal so
      that the driver still loads but keeping the warning and extra details
      for inspection.
      
      Inspecting the changes for a Kabylake system,
      Before:
      	Address	val		mask		read
      	0x07014	0x20002000	0x00002000	0x00002100
      	0x0E194	0x01000100	0x00000100	0x00000114
      	0x0E4F0	0x81008100	0x00008100	0xFFFF8120
      	0x0E184	0x00200020	0x00000020	0x00000022
      	0x0E194	0x00140014	0x00000014	0x00000114
      	0x07004	0x00420042	0x00000042	0x000029C2
      	0x0E188	0x00080000	0x00000008	0x00008030
      	0x07300	0x80208020	0x00008020	0x00008830
      	0x07300	0x00100010	0x00000010	0x00008830
      	0x0E184	0x00020002	0x00000002	0x00000022
      	0x0E180	0x20002000	0x00002000	0x00002000
      	0x02580	0x00010000	0x00000001	0x00000004
      	0x02580	0x00060004	0x00000006	0x00000004
      	0x07014	0x01000100	0x00000100	0x00002100
      	0x0E100	0x00100010	0x00000010	0x00008050
      
      After:
      	Address	val		mask		read
      	0x02580	0x00070004	0x00000007	0x00000004
      	0x07004	0x00420042	0x00000042	0x000029C2
      	0x07014	0x21002100	0x00002100	0x00002100
      	0x07300	0x80308030	0x00008030	0x00008830
      	0x0E100	0x00100010	0x00000010	0x00008050
      	0x0E180	0x20002000	0x00002000	0x00002000
      	0x0E184	0x00220022	0x00000022	0x00000022
      	0x0E188	0x00080000	0x00000008	0x00008030
      	0x0E194	0x01140114	0x00000114	0x00000114
      	0x0E4F0	0x81008100	0x00008100	0xFFFF8120
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180615120207.13952-1-chris@chris-wilson.co.uk
      548764bb
    • C
      drm/i915: Declare the driver wedged if hangcheck makes no progress · 1fd00c0f
      Chris Wilson 提交于
      Hangcheck is our back up in case the GPU or the driver gets stuck. It
      detects when the GPU is not making any progress and issues a GPU reset.
      However, if the driver is failing to make any progress, we can get
      ourselves into a situation where we continually try resetting the GPU to
      no avail. Employ a second timeout such that if we continue to see the
      same seqno (the stalled engine has made no progress at all) over the
      course of several hangchecks, declare the driver wedged and attempt to
      start afresh.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180602104853.17140-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      1fd00c0f
    • R
      drm/i915/psr: Kill delays when activating psr back. · 5422b37c
      Rodrigo Vivi 提交于
      The immediate enabling was actually not an issue for the
      HW perspective for core platforms that have HW tracking.
      HW will wait few identical idle frames before transitioning
      to actual psr active anyways.
      
      Now that we removed VLV/CHV out of the picture completely
      we can safely remove any delays.
      
      Note that this patch also remove the delayed activation
      on HSW and BDW introduced by commit 'd0ac896a
      ("drm/i915: Delay first PSR activation.")'. This was
      introduced to fix a blank screen on VLV/CHV and also
      masked some frozen screens on other core platforms.
      Probably the same that we are now properly hunting and fixing.
      
      v2:(DK): Remove unnecessary WARN_ONs and make some other
               VLV | CHV more readable.
      v3: Do it regardless the timer rework.
      v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
      v5: Kill remaining items and fully rework activation functions.
      v6: Rebase on top of VLV/CHV clean-up and keep the reactivation
          on a regular non-delayed work to avoid extra delays on exit
          calls and allow us to add few more safety checks before
          real activation.
      
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180613192600.3955-1-rodrigo.vivi@intel.com
      5422b37c
  8. 12 6月, 2018 1 次提交
  9. 06 6月, 2018 1 次提交
  10. 01 6月, 2018 1 次提交
  11. 24 5月, 2018 1 次提交
  12. 22 5月, 2018 1 次提交
  13. 18 5月, 2018 2 次提交
  14. 08 5月, 2018 1 次提交
    • P
      drm/i915/icl: add basic support for the ICL clocks · c27e917e
      Paulo Zanoni 提交于
      This commit introduces the definitions for the ICL clocks and adds the
      basic functions to the shared DPLL framework. It adds code for the
      Enable and Disable sequences for some PLLs, but it does not have the
      code to compute the actual PLL values, which are marked as TODO
      comments and should be introduced as separate commits.
      
      Special thanks to James Ausmus for investigating and fixing a bug with
      the placement of icl_unmap_plls_to_ports() function.
      
      v2:
       - Rebase around dpll_lock changes.
      v3:
       - The spec now says what the timeouts should be.
       - Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
         the machine.
       - Checkpatch found a white space problem.
       - Small adjustments before upstreaming.
      v4:
       - Move the ICL checks out of the *map_plls_to_ports() functions
        (James)
       - Add extra encoder check (James)
       - Call icl_unmap_plls_to_ports() later (James)
      v5:
       - Rebase after the pll struct changes.
      v6:
       - Properly make the unmap function based on encoders_post_disable()
         with regarding to checks and iterators.
       - Address checkpatch comment on "min = max = x()".
      
      Cc: James Ausmus <james.ausmus@intel.com>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180427231436.9353-1-paulo.r.zanoni@intel.com
      c27e917e
  15. 30 4月, 2018 2 次提交
  16. 27 4月, 2018 1 次提交
  17. 25 4月, 2018 1 次提交
  18. 21 4月, 2018 2 次提交
  19. 15 4月, 2018 1 次提交
    • C
      drm/i915: Check whitelist registers across resets · f4ecfbfc
      Chris Wilson 提交于
      Add a selftest to ensure that we restore the whitelisted registers after
      rewrite the registers everytime they might be scrubbed, e.g. module
      load, reset and resume. For the other volatile workaround registers, we
      export their presence via debugfs and check in igt/gem_workarounds.
      However, we don't export the whitelist and rather than do so, let's test
      them directly in the kernel.
      
      The test we use is to read the registers back from the CS (this helps us
      be sure that the registers will be valid for MI_LRI etc). In order to
      generate the expected list, we split intel_whitelist_workarounds_emit
      into two phases, the first to build the list and the second to apply.
      Inside the test, we only build the list and then check that list against
      the hw.
      
      v2: Filter out pre-gen8 as they do not have RING_NONPRIV.
      v3: Drop unused engine parameter, no plans to use it now or future.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NOscar Mateo <oscar.mateo@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180414122754.569-1-chris@chris-wilson.co.uk
      f4ecfbfc
  20. 10 4月, 2018 1 次提交
  21. 06 4月, 2018 1 次提交
  22. 31 3月, 2018 1 次提交
  23. 28 3月, 2018 2 次提交
  24. 20 3月, 2018 1 次提交
  25. 19 3月, 2018 4 次提交
  26. 16 3月, 2018 1 次提交
  27. 15 3月, 2018 1 次提交
  28. 14 3月, 2018 1 次提交
  29. 13 3月, 2018 2 次提交
  30. 10 3月, 2018 1 次提交