1. 13 12月, 2018 2 次提交
  2. 07 12月, 2018 1 次提交
  3. 04 12月, 2018 1 次提交
  4. 29 11月, 2018 1 次提交
    • V
      drm/i915: Move ddb/wm programming into plane update/disable hooks on skl+ · ff43bc37
      Ville Syrjälä 提交于
      On SKL+ the plane WM/BUF_CFG registers are a proper part of each
      plane's register set. That means accessing them will cancel any
      pending plane update, and we would need a PLANE_SURF register write
      to arm the wm/ddb change as well.
      
      To avoid all the problems with that let's just move the wm/ddb
      programming into the plane update/disable hooks. Now all plane
      registers get written in one (hopefully atomic) operation.
      
      To make that feasible we'll move the plane ddb tracking into
      the crtc state. Watermarks were already tracked there.
      
      v2: Rebase due to input CSC
      v3: Split out a bunch of junk (Matt)
      v4: Add skl_wm_add_affected_planes() to deal with
          cursor special case and non-zero wm register reset value
      v5: Drop the unrelated for_each_intel_plane_mask() fix (Matt)
          Remove the redundant ddb memset() (Matt)
      
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v3
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181127165900.31298-1-ville.syrjala@linux.intel.com
      ff43bc37
  5. 23 11月, 2018 2 次提交
  6. 21 11月, 2018 2 次提交
    • A
    • J
      drm/i915/ilk: Fix warning when reading emon_status with no output · cab870b7
      José Roberto de Souza 提交于
      When there is no output no one will hold a runtime_pm reference
      causing a warning when trying to read emom_status in debugfs.
      
      [22.756480] ------------[ cut here ]------------
      [22.756489] RPM wakelock ref not held during HW access
      [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915]
      [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich
      [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1
      [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
      [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915]
      [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d
      [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282
      [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006
      [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57
      [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000
      [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001
      [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188
      [22.756651] FS:  00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000
      [22.756653] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0
      [22.756657] Call Trace:
      [22.756689]  i915_mch_val+0x1b/0x60 [i915]
      [22.756721]  i915_emon_status+0x45/0xd0 [i915]
      [22.756730]  seq_read+0xdb/0x3c0
      [22.756736]  ? lockdep_hardirqs_off+0x94/0xd0
      [22.756740]  ? __slab_free+0x24e/0x510
      [22.756746]  full_proxy_read+0x52/0x90
      [22.756752]  __vfs_read+0x31/0x170
      [22.756759]  ? do_sys_open+0x13b/0x240
      [22.756763]  ? rcu_read_lock_sched_held+0x6f/0x80
      [22.756766]  vfs_read+0x9e/0x140
      [22.756770]  ksys_read+0x50/0xc0
      [22.756775]  do_syscall_64+0x55/0x190
      [22.756781]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [22.756783] RIP: 0033:0x7f28781dc34e
      [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49
      [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e
      [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008
      [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020
      [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0
      [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000
      [22.756806] irq event stamp: 47950
      [22.756811] hardirqs last  enabled at (47949): [<ffffffff810fba74>] vprintk_emit+0x124/0x320
      [22.756813] hardirqs last disabled at (47950): [<ffffffff810019b0>] trace_hardirqs_off_thunk+0x1a/0x1c
      [22.756816] softirqs last  enabled at (47518): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9
      [22.756820] softirqs last disabled at (47479): [<ffffffff8108df29>] irq_exit+0xa9/0xc0
      [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915]
      [22.756860] ---[ end trace bf56fa7d6a3cbf7a ]
      Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.souza@intel.com
      cab870b7
  7. 08 11月, 2018 1 次提交
    • L
      drm/i915: Add short HPD IRQ storm detection for non-MST systems · 9a64c650
      Lyude Paul 提交于
      Unfortunately, it seems that the HPD IRQ storm problem from the early
      days of Intel GPUs was never entirely solved, only mostly. Within the
      last couple of days, I got a bug report from one of our customers who
      had been having issues with their machine suddenly booting up very
      slowly after having updated. The amount of time it took to boot went
      from around 30 seconds, to over 6 minutes consistently.
      
      After some investigation, I discovered that i915 was reporting massive
      amounts of short HPD IRQ spam on this system from the DisplayPort port,
      despite there not being anything actually connected. The symptoms would
      start with one "long" HPD IRQ being detected at boot:
      
      [    1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
      [    1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
      [    1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
      [    1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
      [    1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
      [    1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
      [    1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
      …
      
      followed by constant short IRQs afterwards:
      
      [    1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
      [    1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
      [    1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
      [    1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
      [    1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
      [    1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
      [    1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
      [    1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
      [    1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
      [    1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
      [    1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
      [    1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
      [    1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
      
      The customer's system in question has a GM45 GPU, which is apparently
      well known for hotplugging storms.
      
      So, workaround this impressively broken hardware by changing the default
      HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
      short IRQs count for 1. This makes it so that 5 long IRQs will trigger
      an HPD storm, and on systems with short HPD storm detection 50 short
      IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
      constant pulsing, which seems like a good middleground between being too
      sensitive and not being sensitive enough (which would cause visible
      stutters in userspace every time a storm occurs).
      
      And just to be extra safe: we don't enable this by default on systems
      with MST support. There's too high of a chance of MST support triggering
      storm detection, and systems that are new enough to support MST are a
      lot less likely to have issues with IRQ storms anyway.
      
      As a note: this patch was tested using a ThinkPad T450s and a Chamelium
      to simulate the short IRQ storms.
      
      Changes since v1:
      - Don't use two separate thresholds, just make long IRQs count for 10
        each and short IRQs count for 1. This simplifies the code a bit
        - Ville Syrjälä
      Changes since v2:
      - Document @long_hpd in intel_hpd_irq_storm_detect, no functional
        changes
      Changes since v4:
      - Remove !! in long_hpd assignment - Ville Syrjälä
      - queue_hp = true - Ville Syrjälä
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
      9a64c650
  8. 05 11月, 2018 1 次提交
  9. 01 11月, 2018 1 次提交
  10. 29 10月, 2018 1 次提交
  11. 24 10月, 2018 1 次提交
  12. 18 10月, 2018 2 次提交
  13. 17 10月, 2018 1 次提交
  14. 15 10月, 2018 1 次提交
  15. 13 10月, 2018 1 次提交
  16. 10 10月, 2018 1 次提交
  17. 05 10月, 2018 1 次提交
  18. 02 10月, 2018 1 次提交
  19. 07 9月, 2018 1 次提交
  20. 05 9月, 2018 1 次提交
    • C
      drm/i915: Reduce context HW ID lifetime · 288f1ced
      Chris Wilson 提交于
      Future gen reduce the number of bits we will have available to
      differentiate between contexts, so reduce the lifetime of the ID
      assignment from that of the context to its current active cycle (i.e.
      only while it is pinned for use by the HW, will it have a constant ID).
      This means that instead of a max of 2k allocated contexts (worst case
      before fun with bit twiddling), we instead have a limit of 2k in flight
      contexts (minus a few that have been pinned by the kernel or by perf).
      
      To reduce the number of contexts id we require, we allocate a context id
      on first and mark it as pinned for as long as the GEM context itself is,
      that is we keep it pinned it while active on each engine. If we exhaust
      our context id space, then we try to reclaim an id from an idle context.
      In the extreme case where all context ids are pinned by active contexts,
      we force the system to idle in order to recover ids.
      
      We cannot reduce the scope of an HW-ID to an engine (allowing the same
      gem_context to have different ids on each engine) as in the future we
      will need to preassign an id before we know which engine the
      context is being executed on.
      
      v2: Improved commentary (Tvrtko) [I tried at least]
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=107788Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180904153117.3907-1-chris@chris-wilson.co.uk
      288f1ced
  21. 03 9月, 2018 1 次提交
  22. 23 8月, 2018 1 次提交
  23. 22 8月, 2018 1 次提交
  24. 10 8月, 2018 1 次提交
    • M
      drm/i915: Allow control of PSR at runtime through debugfs, v6 · c44301fc
      Maarten Lankhorst 提交于
      Currently tests modify i915.enable_psr and then do a modeset cycle
      to change PSR. We can write a value to i915_edp_psr_debug to force
      a certain PSR mode without a modeset.
      
      To retain compatibility with older userspace, we also still allow
      the override through the module parameter, and add some tracking
      to check whether a debugfs mode is specified.
      
      Changes since v1:
      - Rename dev_priv->psr.enabled to .dp, and .hw_configured to .enabled.
      - Fix i915_psr_debugfs_mode to match the writes to debugfs.
      - Rename __i915_edp_psr_write to intel_psr_set_debugfs_mode, simplify
        it and move it to intel_psr.c. This keeps all internals in intel_psr.c
      - Perform an interruptible wait for hw completion outside of the psr
        lock, instead of being forced to trywait and return -EBUSY.
      Changes since v2:
      - Rebase on top of intel_psr changes.
      Changes since v3:
      - Assign psr.dp during init. (dhnkrn)
      - Add prepared bool, which should be used instead of relying on psr.dp. (dhnkrn)
      - Fix -EDEADLK handling in debugfs. (dhnkrn)
      - Clean up waiting for idle in intel_psr_set_debugfs_mode.
      - Print PSR mode when trying to enable PSR. (dhnkrn)
      - Move changing psr debug setting to i915_edp_psr_debug_set. (dhnkrn)
      Changes since v4:
      - Return error in _set() function.
      - Change flag values to make them easier to remember. (dhnkrn)
      - Only assign psr.dp once. (dhnkrn)
      - Only set crtc_state->has_psr on the crtc with psr.dp.
      - Fix typo. (dhnkrn)
      Changes since v5:
      - Only wait for PSR idle on the PSR connector correctly. (dhnkrn)
      - Reinstate WARN_ON(drrs.dp) in intel_psr_enable. (dhnkrn)
      - Remove stray comment. (dhnkrn)
      - Be silent in intel_psr_compute_config on wrong connector. (dhnkrn)
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180809142101.26155-1-maarten.lankhorst@linux.intel.comReviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      c44301fc
  25. 08 8月, 2018 1 次提交
  26. 07 8月, 2018 2 次提交
    • C
      drm/i915: Interactive RPS mode · 027063b1
      Chris Wilson 提交于
      RPS provides a feedback loop where we use the load during the previous
      evaluation interval to decide whether to up or down clock the GPU
      frequency. Our responsiveness is split into 3 regimes, a high and low
      plateau with the intent to keep the gpu clocked high to cover occasional
      stalls under high load, and low despite occasional glitches under steady
      low load, and inbetween. However, we run into situations like kodi where
      we want to stay at low power (video decoding is done efficiently
      inside the fixed function HW and doesn't need high clocks even for high
      bitrate streams), but just occasionally the pipeline is more complex
      than a video decode and we need a smidgen of extra GPU power to present
      on time. In the high power regime, we sample at sub frame intervals with
      a bias to upclocking, and conversely at low power we sample over a few
      frames worth to provide what we consider to be the right levels of
      responsiveness respectively. At low power, we more or less expect to be
      kicked out to high power at the start of a busy sequence by waitboosting.
      
      Prior to commit e9af4ea2 ("drm/i915: Avoid waitboosting on the active
      request") whenever we missed the frame or stalled, we would immediate go
      full throttle and upclock the GPU to max. But in commit e9af4ea2, we
      relaxed the waitboosting to only apply if the pipeline was deep to avoid
      over-committing resources for a near miss. Sadly though, a near miss is
      still a miss, and perceptible as jitter in the frame delivery.
      
      To try and prevent the near miss before having to resort to boosting
      after the fact, we use the pageflip queue as an indication that we are
      in an "interactive" regime and so should sample the load more frequently
      to provide power before the frame misses it vblank. This will make us
      more favorable to providing a small power increase (one or two bins) as
      required rather than going all the way to maximum and then having to
      work back down again. (We still keep the waitboosting mechanism around
      just in case a dramatic change in system load requires urgent uplocking,
      faster than we can provide in a few evaluation intervals.)
      
      v2: Reduce rps_set_interactive to a boolean parameter to avoid the
      confusion of what if they wanted a new power mode after pinning to a
      different mode (which to choose?)
      v3: Only reprogram RPS while the GT is awake, it will be set when we
      wake the GT, and while off warns about being used outside of rpm.
      v4: Fix deferred application of interactive mode
      v5: s/state/interactive/
      v6: Group the mutex with its principle in a substruct
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111
      Fixes: e9af4ea2 ("drm/i915: Avoid waitboosting on the active request")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk
      (cherry picked from commit 60548c554be2830d29d2533dad0ac8133347ee51)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      027063b1
    • R
      drm/i915: Fix psr sink status report. · 656921a5
      Rodrigo Vivi 提交于
      First of all don't try to read dpcd if PSR is not even supported.
      
      But also, if read failed return -EIO instead of reporting via a
      backchannel.
      
      v2: fix dev_priv: At this level m->private is the connector. (CI/DK)
          don't convert dpcd read errors to EIO. (DK)
      
      Fixes: 5b7b3086 ("drm/i915/psr: Split sink status into a separate debugfs node")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180720003155.16290-1-rodrigo.vivi@intel.com
      (cherry picked from commit 7a72c78bdd0a1ea1d879610542679cc680398220)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      656921a5
  27. 31 7月, 2018 1 次提交
    • C
      drm/i915: Interactive RPS mode · 60548c55
      Chris Wilson 提交于
      RPS provides a feedback loop where we use the load during the previous
      evaluation interval to decide whether to up or down clock the GPU
      frequency. Our responsiveness is split into 3 regimes, a high and low
      plateau with the intent to keep the gpu clocked high to cover occasional
      stalls under high load, and low despite occasional glitches under steady
      low load, and inbetween. However, we run into situations like kodi where
      we want to stay at low power (video decoding is done efficiently
      inside the fixed function HW and doesn't need high clocks even for high
      bitrate streams), but just occasionally the pipeline is more complex
      than a video decode and we need a smidgen of extra GPU power to present
      on time. In the high power regime, we sample at sub frame intervals with
      a bias to upclocking, and conversely at low power we sample over a few
      frames worth to provide what we consider to be the right levels of
      responsiveness respectively. At low power, we more or less expect to be
      kicked out to high power at the start of a busy sequence by waitboosting.
      
      Prior to commit e9af4ea2 ("drm/i915: Avoid waitboosting on the active
      request") whenever we missed the frame or stalled, we would immediate go
      full throttle and upclock the GPU to max. But in commit e9af4ea2, we
      relaxed the waitboosting to only apply if the pipeline was deep to avoid
      over-committing resources for a near miss. Sadly though, a near miss is
      still a miss, and perceptible as jitter in the frame delivery.
      
      To try and prevent the near miss before having to resort to boosting
      after the fact, we use the pageflip queue as an indication that we are
      in an "interactive" regime and so should sample the load more frequently
      to provide power before the frame misses it vblank. This will make us
      more favorable to providing a small power increase (one or two bins) as
      required rather than going all the way to maximum and then having to
      work back down again. (We still keep the waitboosting mechanism around
      just in case a dramatic change in system load requires urgent uplocking,
      faster than we can provide in a few evaluation intervals.)
      
      v2: Reduce rps_set_interactive to a boolean parameter to avoid the
      confusion of what if they wanted a new power mode after pinning to a
      different mode (which to choose?)
      v3: Only reprogram RPS while the GT is awake, it will be set when we
      wake the GT, and while off warns about being used outside of rpm.
      v4: Fix deferred application of interactive mode
      v5: s/state/interactive/
      v6: Group the mutex with its principle in a substruct
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111
      Fixes: e9af4ea2 ("drm/i915: Avoid waitboosting on the active request")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk
      60548c55
  28. 21 7月, 2018 1 次提交
  29. 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
  30. 13 7月, 2018 1 次提交
  31. 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
  32. 06 7月, 2018 1 次提交
  33. 03 7月, 2018 1 次提交
  34. 29 6月, 2018 1 次提交
  35. 15 6月, 2018 1 次提交
    • 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