summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)Author
2020-01-31drm/i915: Polish WM_LINETIME register stuffVille Syrjälä
Let's store the normal and IPS linetime watermarks individually, and while at it we'll pimp the register definitions as well. v2: Deal with gvt Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-2-ville.syrjala@linux.intel.com
2020-01-31drm/i915: move intel_dp_set_m_n() to encoder for DDI platformsJani Nikula
intel_dp_set_m_n() has a clear place in the DDI DP specific pre-enable hook. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128162850.8660-3-jani.nikula@intel.com
2020-01-31drm/i915/dsi: Enable ICL DSI transcoder as part of encoder->enableVandita Kulkarni
Enable the dsi transcoder, panel and backlight as part of encoder->enable and not encoder->pre_enable. We need to have pipe src size, among other things, set before enabling the transcoder, to avoid FIFO underruns and possibly other issues. v2 by Jani: - Rebase on the crtc enable sequence update Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128162850.8660-2-jani.nikula@intel.com
2020-01-31drm/i915: move pipe, pch and vblank enable to encoders on DDI platformsJani Nikula
To allow better flexibility for encoder specific code, push intel_enable_pipe(), lpt_pch_enable() and intel_crtc_vblank_on() down to the encoders from hsw_crtc_enable(). There's slight duplication, but also more clarity with the reduced conditional statements. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128162850.8660-1-jani.nikula@intel.com
2020-01-31drm/i915/debugfs: remove VBT data about DRRSJani Nikula
The debugfs is not the place to print duplicated info about VBT data. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128151942.2590-1-jani.nikula@intel.com
2020-01-30drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutexChris Wilson
On Braswell and Broxton (also known as Valleyview and Apollolake), we need to serialise updates of the GGTT using the big stop_machine() hammer. This has the side effect of appearing to lockdep as a possible reclaim (since it uses the cpuhp mutex and that is tainted by per-cpu allocations). However, we want to use vm->mutex (including ggtt->mutex) from within the shrinker and so must avoid such possible taints. For this purpose, we introduced the asynchronous vma binding and we can apply it to the PIN_GLOBAL so long as take care to add the necessary waits for the worker afterwards. Closes: https://gitlab.freedesktop.org/drm/intel/issues/211 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/20200130181710.2030251-3-chris@chris-wilson.co.uk
2020-01-30drm/i915/gt: Rename i915_gem_restore_ggtt_mappings() for its new placementChris Wilson
The i915_ggtt now sits beneath gt/ outside of the auspices of gem/ and should be given a fresh name to reflect that. We also want to give it a name that reflects its role in the system suspend/resume, with the intention of pulling together all the GGTT operations (e.g. restoring the fence registers once they are pulled under gt/intel_ggtt_detiler.c) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Rreviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200130181710.2030251-2-chris@chris-wilson.co.uk
2020-01-30drm/i915/gem: Tighten checks and acquiring the mmap objectChris Wilson
Make sure we hold the rcu lock as we acquire the rcu protected reference of the object when looking it up from the associated mmap vma. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1083 Fixes: cc662126b413 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200130143931.1906301-1-chris@chris-wilson.co.uk
2020-01-30drm/i915/fbc: __intel_fbc_cleanup_cfb() may be called multiple timesChris Wilson
Avoid releasing the same stolen nodes causing a use-after-free and/or explosions as the self-checks fail, as __intel_fbc_cleanup_cfb() may be called multiple times during module unload. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200130135136.1878646-1-chris@chris-wilson.co.uk
2020-01-30drm/i915/gt: Skip global serialisation of clear_range for bxt vtdChris Wilson
VT'd on Broxton and on Braswell require serialisation of GGTT updates. However, it seems to only be required for insertion, so drop the complication and heavyweight stop_machine() for clears. The range will be serialised again before use. 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/20200130092239.1743672-1-chris@chris-wilson.co.uk
2020-01-30drm/i915/ring: convert to new logging macros in gt/intel_ring_submission.cWambui Karuga
Manually convert the remaining instance of the printk based drm logging macros to the struct drm_device based logging macros in i915/gt/intel_ring_submission.c Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128071437.9284-8-wambui.karugax@gmail.com
2020-01-30drm/i915/gt: convert to new logging macros in gt/intel_gt.cWambui Karuga
Convert remaining instances of the printk based logging macros in i915/gt/intel_gt to the struct drm_device based logging macros. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128071437.9284-7-wambui.karugax@gmail.com
2020-01-30drm/i915/engine_cs: use new drm logging macros in gt/intel_engine_cs.cWambui Karuga
Conversion of the remaining printk based drm logging macros to the new struct drm_device based logging macros in i915/gt/intel_engine_cs.c. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128071437.9284-5-wambui.karugax@gmail.com
2020-01-30drm/i915/reset: conversion to new drm logging macros in gt/intel_reset.cWambui Karuga
This converts most instances of the printk based drm logging macros in i915/gt/intel_resect.c to the new struct drm_based logging macros. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128071437.9284-4-wambui.karugax@gmail.com
2020-01-30drm/i915/ggtt: use new drm logging macros in gt/intel_ggtt.cWambui Karuga
Manual conversion of the printk based logging macros to the new struct drm_based logging macros in drm/i915/gt/intel_ggtt.c. Also includes extracting the struct drm_i915_private device from various intel types to use in the new macros. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128071437.9284-3-wambui.karugax@gmail.com
2020-01-30drm/i915: Fix preallocated barrier list appendJosé Roberto de Souza
Only the first and the last nodes were being added to ref->preallocated_barriers. Renaming variables to make it more easy to read. Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@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/20200129232345.84512-1-jose.souza@intel.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-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/i915/perf: Fix OA context id overlap with idle context idUmesh Nerlige Ramappa
Engine context pinned in perf OA was set to same context id as the idle context. Set the context id to an unused value. Clear the sw context id field in lrc descriptor before ORing with ce->tag (Chris) Closes: https://gitlab.freedesktop.org/drm/intel/issues/756 Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@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/20200124013701.40609-1-umesh.nerlige.ramappa@intel.com
2020-01-27drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutexChris Wilson
Similar to commit ac0e331a628b ("drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release") we have the same race of trying to pin the context underneath a mutex while allowing the decrement to be atomic outside of that mutex. This leads to the problem where two threads may simultaneously try to pin the context and the second not notice that they needed to repin the context. <2> [198.669621] kernel BUG at drivers/gpu/drm/i915/gt/intel_timeline.c:387! <4> [198.669703] invalid opcode: 0000 [#1] PREEMPT SMP PTI <4> [198.669712] CPU: 0 PID: 1246 Comm: gem_exec_create Tainted: G U W 5.5.0-rc6-CI-CI_DRM_7755+ #1 <4> [198.669723] Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017 <4> [198.669776] RIP: 0010:timeline_advance+0x7b/0xe0 [i915] <4> [198.669785] Code: 00 48 c7 c2 10 f1 46 a0 48 c7 c7 70 1b 32 a0 e8 bb dd e7 e0 bf 01 00 00 00 e8 d1 af e7 e0 31 f6 bf 09 00 00 00 e8 35 ef d8 e0 <0f> 0b 48 c7 c1 48 fa 49 a0 ba 84 01 00 00 48 c7 c6 10 f1 46 a0 48 <4> [198.669803] RSP: 0018:ffffc900004c3a38 EFLAGS: 00010296 <4> [198.669810] RAX: ffff888270b35140 RBX: ffff88826f32ee00 RCX: 0000000000000006 <4> [198.669818] RDX: 00000000000017c5 RSI: 0000000000000000 RDI: 0000000000000009 <4> [198.669826] RBP: ffffc900004c3a64 R08: 0000000000000000 R09: 0000000000000000 <4> [198.669834] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88826f9b5980 <4> [198.669841] R13: 0000000000000cc0 R14: ffffc900004c3dc0 R15: ffff888253610068 <4> [198.669849] FS: 00007f63e663fe40(0000) GS:ffff888276c00000(0000) knlGS:0000000000000000 <4> [198.669857] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [198.669864] CR2: 00007f171f8e39a8 CR3: 000000026b1f6005 CR4: 00000000003606f0 <4> [198.669872] Call Trace: <4> [198.669924] intel_timeline_get_seqno+0x12/0x40 [i915] <4> [198.669977] __i915_request_create+0x76/0x5a0 [i915] <4> [198.670024] i915_request_create+0x86/0x1c0 [i915] <4> [198.670068] i915_gem_do_execbuffer+0xbf2/0x2500 [i915] <4> [198.670082] ? __lock_acquire+0x460/0x15d0 <4> [198.670128] i915_gem_execbuffer2_ioctl+0x11f/0x470 [i915] <4> [198.670171] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915] <4> [198.670181] drm_ioctl_kernel+0xa7/0xf0 <4> [198.670188] drm_ioctl+0x2e1/0x390 <4> [198.670233] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915] Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") References: ac0e331a628b ("drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release") 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/20200127152829.2842149-1-chris@chris-wilson.co.uk
2020-01-27drm/i915: Restore the kernel context after verifying the w/aChris Wilson
As a safety net, flush the engine verifications and restore the kernel context. Closes: https://gitlab.freedesktop.org/drm/intel/issues/971 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200126194618.2131078-1-chris@chris-wilson.co.uk
2020-01-27drm/i915/vlv_dsi_pll: 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/3a89bf4c8b312c233e6b219e9c73203608c3eaec.1579871655.git.jani.nikula@intel.com
2020-01-27drm/i915/vlv_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/436e4267529dc11cc7850d0a4f0703caa81b8c80.1579871655.git.jani.nikula@intel.com
2020-01-27drm/i915/vdsc: 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/735389bfa1f9c4be8080f3187ea1dbde308d1ce2.1579871655.git.jani.nikula@intel.com
2020-01-27drm/i915/sprite: 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/722f73a4529808ef7dad51c03c0a3775d8c5b052.1579871655.git.jani.nikula@intel.com
2020-01-27drm/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/b7865c858374e9ab04cf2bc4ceb3d7d89c27db83.1579871655.git.jani.nikula@intel.com
2020-01-27drm/i915/pipe_crc: 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/0af05f6035046a515097da398de8722c0ca23e56.1579871655.git.jani.nikula@intel.com
2020-01-27drm/i915: Give aux channels a better nameVille Syrjälä
The aux ch is used for more than DDC, so let's give it a better name. For maximum ease let's include both the AUX ch identifier and the port identifier (for cases where the VBT has redefined the relationship of the two). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123154542.12271-3-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2020-01-27drm/i915: Include the AUX CH name in the debug messagesVille Syrjälä
To make it easier to figure out what caused a particular debug message let's print out aux->name. v2: Rebase for drm_err() & co. Add some punctuation to the messages (Matt) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123154542.12271-2-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2020-01-27drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_releaseChris Wilson
As we use a mutex to serialise the first acquire (as it may be a lengthy operation), but only an atomic decrement for the release, we have to be careful in case a second thread races and completes both acquire/release as the first finishes its acquire. Thread A Thread B i915_active_acquire i915_active_acquire atomic_read() == 0 atomic_read() == 0 mutex_lock() mutex_lock() atomic_read() == 0 ref->active(); atomic_inc() mutex_unlock() atomic_read() == 1 i915_active_release atomic_dec_and_test() -> 0 ref->retire() atomic_inc() -> 1 mutex_unlock() So thread A has acquired the ref->active_count but since the ref was still active at the time, it did not initialise it. By switching the check inside the mutex to an atomic increment only if already active, we close the race. Fixes: c9ad602feabe ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200126102346.1877661-3-chris@chris-wilson.co.uk
2020-01-27drm/i915/vga: 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/ad357e65ddb85e7341416f0d7890661a3ef99298.1579871655.git.jani.nikula@intel.com
2020-01-27drm/i915/tv: 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/6e6238e75f5a4155b1021736937b1fd7a0756a00.1579871655.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-12 05:52:21 +0000