summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-30Merge branch 'linux-5.6' of git://github.com/skeggsb/linux into drm-nextDave Airlie
A couple of OOPS fixes, fixes for TU1xx if firmware isn't available, better behaviour in the face of GPU faults, and a patch to make HD audio work again after runpm changes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv4xcLF6Ahh7UYEesn-wBEksd2da+ghusBAdODMrH7Sz2A@mail.gmail.com
2020-01-30drm/i915: add extra slice common debug registersLionel Landwerlin
Could be helpful for debugging purposes. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200129181638.1528150-1-lionel.g.landwerlin@intel.com
2020-01-30drm/i915/execlists: Ignore discrepancies in pending[] across resetsChris Wilson
When we reset the engine, we first remove the guilty request from the active list. If it so happens that there is a pending preemption event to process before we handle the reset, when we inspect that event we find ourselves a little confused as we have bent the rules slightly to perform the reset. Just ignore any discrepancies inside reset, we know we'll start again from scratch afterwards. <0>[ 536.940213] <idle>-0 6..s1 537441383us : execlists_reset: 0000:00:02.0 vcs0: reset for CS error <0>[ 536.940213] i915_sel-7302 2d..1 537441386us : trace_ports: 0000:00:02.0 vcs0: submit { 10c59:2*, 10c5a:2 } <0>[ 536.940213] <idle>-0 6d.s2 537471320us : __i915_request_unsubmit: 0000:00:02.0 vcs0: fence 10c59:2, current 1 <0>[ 536.940213] <idle>-0 6d.s2 537471321us : execlists_hold: 0000:00:02.0 vcs0: fence 10c59:2, current 1 on hold <0>[ 536.940213] <idle>-0 6.Ns1 537471328us : intel_engine_reset: 0000:00:02.0 vcs0: flags=10 <0>[ 536.940213] <idle>-0 6.Ns1 537471421us : execlists_reset_prepare: 0000:00:02.0 vcs0: depth<-1 <0>[ 536.940213] <idle>-0 6.Ns1 537471422us : intel_engine_stop_cs: 0000:00:02.0 vcs0: <0>[ 536.940213] <idle>-0 6.Ns1 537472424us : intel_engine_stop_cs: 0000:00:02.0 vcs0: timed out on STOP_RING -> IDLE <0>[ 536.940213] <idle>-0 6.Ns1 537472429us : __intel_gt_reset: 0000:00:02.0 engine_mask=4 <0>[ 536.940213] <idle>-0 6.Ns1 537472442us : execlists_reset_rewind: 0000:00:02.0 vcs0: <0>[ 536.940213] <idle>-0 6dNs2 537472443us : process_csb: 0000:00:02.0 vcs0: cs-irq head=4, tail=5 <0>[ 536.940213] <idle>-0 6dNs2 537472444us : process_csb: 0000:00:02.0 vcs0: csb[5]: status=0x00008002:0x20000060 <0>[ 536.940213] <idle>-0 6dNs2 537472464us : trace_ports: 0000:00:02.0 vcs0: preempted { 10c59:2*, 0:0 } <0>[ 536.940213] <idle>-0 6dNs2 537472465us : trace_ports: 0000:00:02.0 vcs0: promote { 10c59:2*, 10c5a:2 } <0>[ 536.940213] <idle>-0 6dNs2 537472706us : assert_pending_valid: assert_pending_valid:1417 GEM_BUG_ON(!i915_request_is_active(rq)) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200129165935.1266132-1-chris@chris-wilson.co.uk
2020-01-29drm/i915/gt: Hook up CS_MASTER_ERROR_INTERRUPTChris Wilson
Now that we have offline error capture and can reset an engine from inside an atomic context while also preserving the GPU state for post-mortem analysis, it is time to handle error interrupts thrown by the command parser. This provides a much, much faster mechanism for us to detect known problems than using heartbeats/hangchecks, and also provides a mechanism for when those are disabled. However, it is limited to problems the HW can detect in the CS and so not a complete solution for detecting lockups. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128204318.4182039-2-chris@chris-wilson.co.uk
2020-01-29drm/i915/execlist: Mark up racy read of execlists->pending[0]Chris Wilson
We write to execlists->pending[0] in process_csb() to acknowledge the completion of the ESLP update, outside of the main spinlock. When we check the current status of the previous submission in __execlists_submission_tasklet() we should therefore use READ_ONCE() to reflect and document the unsynchronized read. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128171614.3845825-1-chris@chris-wilson.co.uk
2020-01-29drm/i915/selftests/perf: measure memcpy bw between regionsMatthew Auld
Measure the memcpy bw between our CPU accessible regions, trying all supported mapping combinations(WC, WB) across various sizes. v2: use smaller sizes throw in memcpy32/memcpy64/memcpy_from_wc Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200129093343.194570-1-matthew.auld@intel.com
2020-01-29drm/i915/debugfs: remove i915_dpcd fileJani Nikula
We've long had the more generic /dev/drm_dp_auxN devices for the same purpose. Drop the redundant and limited DPCD debugfs file. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200117150551.9836-1-jani.nikula@intel.com
2020-01-29drm/i915/psr: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/652e16e6168691f89b5cb8c91278a0d960f8f1a9.1580149467.git.jani.nikula@intel.com
2020-01-29drm/i915/hdcp: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a58f536d25d9cd6da510da49663508cd264eee0f.1580149467.git.jani.nikula@intel.com
2020-01-29drm/i915/dp: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/abcb2d44fd4d6e5f995a3520b327f746ae90428a.1580149467.git.jani.nikula@intel.com
2020-01-29drm/i915/display_power: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/939ffbddf2879e21b9e449f1ae0b621640ecf7ff.1580149467.git.jani.nikula@intel.com
2020-01-29drm/i915/display: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/41b937d632edb59ca2ddecefd9ac613c2f998d58.1580149467.git.jani.nikula@intel.com
2020-01-29drm/i915/ddi: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2c6050201849484a7f4681ce6e2f69cb7cb26756.1580149467.git.jani.nikula@intel.com
2020-01-29drm/i915/combo_phy: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/48b61928049d3be6541a16789622b4479ea26a84.1580149467.git.jani.nikula@intel.com
2020-01-29drm/i915/icl_dsi: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0c3876a5beb5a33d8ab1c93e98dd16fd75339481.1580149467.git.jani.nikula@intel.com
2020-01-29drm/nouveau/fb/gp102-: allow module to load even when scrubber binary is missingBen Skeggs
Without relaxing this requirement, TU10x boards will fail to load without an updated linux-firmware, and TU11x will completely fail to load because FW isn't available yet. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau/acr: return error when registering LSF if ACR not supportedBen Skeggs
This fixes an oops on TU11x GPUs where SEC2 attempts to register its falcon, and triggers a NULL-pointer deref because ACR isn't yet supported. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau/disp/gv100-: not all channel types support reporting error codesBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau/disp/nv50-: prevent oops when no channel method map providedBen Skeggs
The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception is raised by one of them, we'd end up triggering a NULL-pointer deref. Not ideal... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau: support synchronous pushbuf submissionBen Skeggs
This is useful for debugging GPU hangs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau: signal pending fences when channel has been killedBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau: reject attempts to submit to dead channelsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau: zero vma pointer even if we only unreference it rather than freeBen Skeggs
I'm not sure this affects anything, but best be safe. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-29drm/nouveau: Add HD-audio component notifier supportTakashi Iwai
This patch adds the support for the notification of HD-audio hotplug via the already existing drm_audio_component framework. This allows us more reliable hotplug notification and ELD transfer without accessing HD-audio bus; it's more efficient, and more importantly, it works without waking up the runtime PM. The implementation is rather simplistic: nouveau driver provides the get_eld ops for HD-audio, and it notifies the audio hotplug via pin_eld_notify callback upon each nv50_audio_enable() and _disable() call. As the HD-audio pin assignment seems corresponding to the CRTC, the crtc->index number is passed directly as the zero-based port number. The bind and unbind callbacks handle the device-link so that it assures the PM call order. Link: https://lore.kernel.org/r/20190722143815.7339-3-tiwai@suse.de Reviewed-by: Lyude Paul <lyude@redhat.com> Cc: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-28drm/i915/selftests: Lock the drm_mm as we searchChris Wilson
Hold onto the vm->mutex (to lock the drm_mm) to ensure that the rbtree is stable as we search it for our scratch node. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128183458.3860022-1-chris@chris-wilson.co.uk
2020-01-28drm/i915/trace: i915_request.prio is a signed valueChris Wilson
Don't confuse the poor developer by writing a negative value as a very large positive, as the flow of requests is already complex enough. Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128151647.3820659-1-chris@chris-wilson.co.uk
2020-01-28drm/i915/gt: Lift set-wedged engine dumping out of user pathsChris Wilson
The user (e.g. gem_eio) can manipulate the driver into wedging itself, allowing the user to trigger voluminous logging of inconsequential details. If we lift the dump to direct calls to intel_gt_set_wedged(), out of the intel_reset failure handling, we keep the detail logging for what we expect are true HW or test failures without being tricked. Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200127231540.3302516-6-chris@chris-wilson.co.uk
2020-01-28drm/i915/gt: Tidy repetition in declaring gen8+ interruptsChris Wilson
We use the same interrupt mask for each engine, so define it once in a local and reuse. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200127231540.3302516-3-chris@chris-wilson.co.uk
2020-01-28drm/i915/gt: Reorganise gen8+ interrupt handlerChris Wilson
We always use a deferred bottom-half (either tasklet or irq_work) for processing the response to an interrupt which means we can recombine the GT irq ack+handler into one. This simplicity is important in later patches as we will need to handle and then ack multiple interrupt levels before acking the GT and master interrupts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200127231540.3302516-2-chris@chris-wilson.co.uk
2020-01-28drm/i915: Skip capturing errors from internal contextsChris Wilson
We don't want to report errors on the internal contexts to userspace, suppressing their own, so treat them as simulated errors. These mostly arise inside selftests and so are simulated anyway. For the rest, we can rely on the normal debug channels in CI. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128113426.3711294-1-chris@chris-wilson.co.uk
2020-01-27drm/amd/powerplay: fix spelling mistake "Attemp" -> "Attempt"Colin Ian King
There are several spelling mistakes in PP_ASSERT_WITH_CODE messages. Fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amd/display: fix for-loop with incorrectly sized loop counter (v2)Colin Ian King
A for-loop is iterating from 0 up to 1000 however the loop variable count is a u8 and hence not large enough. Fix this by making count an int. Also remove the redundant initialization of count since this is never used and add { } on the loop statement make the loop block clearer. v2: drop useless else (Walter Harms) Addresses-Coverity: ("Operands don't affect result") Fixes: ed581a0ace44 ("drm/amd/display: wait for update when setting dpg test pattern") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: enable GPU reset by default on renoirAlex Deucher
Everything is in place. Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: enable GPU reset by default on NaviAlex Deucher
Has been working fine for a while. Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amd/display: do not allocate display_mode_lib unnecessarilyDor Askayo
This allocation isn't required and can fail when resuming from suspend. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009 Signed-off-by: Dor Askayo <dor.askayo@gmail.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: add coreboot workaround for KV/KBChristian König
Coreboot seems to have a problem correctly setting up access to the stolen VRAM on KV/KB. Use the direct access only when necessary. Signed-off-by: Christian König <christian.koenig@amd.com> Reported-and-tested-by: Fredrik Bruhn <fredrik.bruhn@unibap.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27Revert "drm/amd/display: Don't skip link training for empty dongle"Harry Wentland
This reverts commit 80adaebd2d411b7d6872a097634848a71eb13d20. [WHY] This change was working around a regression that occured in this: commit 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure") With the fix to run verify_link_cap when the SINK_COUNT of dongles becomes non-zero this change is no longer needed. Cc: Louis Li <Ching-shih.Li@amd.com> Cc: Wenjing Liu <Wenjing.Liu@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zeroHarry Wentland
[WHY] Two years ago the patch referenced by the Fixes tag stopped running dp_verify_link_cap_with_retries during DP detection when the reason for the detection was a short-pulse interrupt. This effectively meant that we were no longer doing the verify_link_cap training on active dongles when their SINK_COUNT changed from 0 to 1. A year ago this was partly remedied with: commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle") This made sure that we trained the dongle on initial hotplug (without connected downstream devices). This is all fine and dandy if it weren't for the fact that there are some dongles on the market that don't like link training when SINK_COUNT is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately after hotplug, even when a downstream device is connected, and then trigger a shortpulse interrupt indicating a SINK_COUNT change to 1. In order to play nicely we will need our policy to not link train an active DP dongle when SINK_COUNT is 0 but ensure we train it when the SINK_COUNT changes to 1. [HOW] Call dp_verify_link_cap_with_retries on detection even when the detection is triggered from a short pulse interrupt. With this change we can also revert this commit which we'll do in a separate follow-up change: commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle") Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure") Suggested-by: Louis Li <Ching-shih.Li@amd.com> Tested-by: Louis Li <Ching-shih.Li@amd.com> Cc: Wenjing Liu <Wenjing.Liu@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: original raven doesn't support full asic resetAlex Deucher
So don't use it. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: attempt to enable gfxoff on more raven1 boards (v2)Alex Deucher
Switch to a blacklist so we can disable specific boards that are problematic. v2: make the blacklist non-raven specific. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amd/amdgpu: fix spelling mistake "to" -> "too"Colin Ian King
There is a spelling mistake in a DRM_ERROR message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amd/powerplay: use true, false for bool variable in smu7_hwmgr.czhengbin
Fixes coccicheck warning: drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:723:2-50: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:733:3-52: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:747:3-51: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: fix doc by clarifying sched_list definitionNirmoy Das
expand sched_list definition for better understanding. Also fix a typo atleast -> at least Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: initialize bo_va_list when add gws to processxinhui pan
bo_va_list is list_head, so initialize it. Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu/vcn: use inst_idx relacing instJames Zhu
Use inst_idx relacing inst in SOC15_DPG_MODE macro to avoid confusion. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu/vcn: fix typo errorJames Zhu
Fix typo error, should be inst_idx instead of inst. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu/vcn: fix vcn2.5 instance issueJames Zhu
Fix vcn2.5 instance issue, vcn0 and vcn1 have same register offset Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu/vcn2.5: fix a bug for the 2nd vcn instance (v2)James Zhu
Fix a bug for the 2nd vcn instance at start and stop. v2: squash in unused label removal. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu/vcn: Share vcn_v2_0_dec_ring_test_ring to vcn2.5James Zhu
Share vcn_v2_0_dec_ring_test_ring to vcn2.5 to support vcn software ring. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-27drm/amdgpu: Use the correct flush_type in flush_gpu_tlb_pasidFelix Kuehling
The flush_type was incorrectly hard-coded to 0 when calling falling back to MMIO-based invalidation in flush_gpu_tlb_pasid. Fixes: ea930000a6dc ("drm/amdgpu: export function to flush TLB via pasid") Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Oak Zeng <Oak.Zeng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 04:05:59 +0000