aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-01-22drm/i915/gem: Convert vm idr to xarrayChris Wilson2-56/+25
Replace the vm_idr + vm_idr_mutex to an XArray. The XArray data structure is now used to implement IDRs, and provides its own locking. We can simply remove the IDR wrapper and in the process also remove our extra mutex. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200122161531.508903-1-chris@chris-wilson.co.uk
2020-01-22drm/i915: Mark the removal of the i915_request from the sched.linkChris Wilson1-0/+2
Keep the rq->fence.flags consistent with the status of the rq->sched.link, and clear the associated bits when decoupling the link on retirement (as we may wish to inspect those flags independent of other state). Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests") References: https://gitlab.freedesktop.org/drm/intel/issues/997 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/20200122140243.495621-3-chris@chris-wilson.co.uk
2020-01-22drm/i915/execlists: Reclaim the hanging virtual requestChris Wilson2-0/+185
If we encounter a hang on a virtual engine, as we process the hang the request may already have been moved back to the virtual engine (we are processing the hang on the physical engine). We need to reclaim the request from the virtual engine so that the locking is consistent and local to the real engine on which we will hold the request for error state capturing. v2: Pull the reclamation into execlists_hold() and assert that cannot be called from outside of the reset (i.e. with the tasklet disabled). v3: Added selftest v4: Drop the reference owned by the virtual engine Fixes: 748317386afb ("drm/i915/execlists: Offline error capture") Testcase: igt/gem_exec_balancer/hang Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200122140243.495621-2-chris@chris-wilson.co.uk
2020-01-22drm/i915/execlists: Take a reference while capturing the guilty requestChris Wilson2-10/+32
Thanks to preempt-to-busy, we leave the request on the HW as we submit the preemption request. This means that the request may complete at any moment as we process HW events, and in particular the request may be retired as we are planning to capture it for a preemption timeout. Be more careful while obtaining the request to capture after a preemption timeout, and check to see if it completed before we were able to put it on the on-hold list. If we do see it did complete just before we capture the request, proclaim the preemption-timeout a false positive and pardon the reset as we should hit an arbitration point momentarily and so be able to process the preemption. Note that even after we move the request to be on hold it may be retired (as the reset to stop the HW comes after), so we do require to hold our own reference as we work on the request for capture (and all of the peeking at state within the request needs to be carefully protected). Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests") Closes: https://gitlab.freedesktop.org/drm/intel/issues/997 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/20200122140243.495621-1-chris@chris-wilson.co.uk
2020-01-22drm/i915/gt: Include a tell-tale for engine parkingChris Wilson1-2/+2
We have two trace messages that rely on the function name for distinction. However, if gcc inlines the function, the two traces end up with the same function name and are indistinguishable. Add a different message to each to clarify which one we hit, i.e. which phase of engine parking we are processing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200122124154.483444-1-chris@chris-wilson.co.uk
2020-01-22drm/i915: Make WARN* drm specific where uncore or stream ptr is availablePankaj Bharadiya4-50/+61
drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_uncore/i915_perf_stream struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @@ identifier func, T; @@ func(...) { ... struct intel_uncore *T = ...; <... ( -WARN( +drm_WARN(&T->i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->i915->drm, ...) ) ...> } @@ identifier func, T; @@ func(struct intel_uncore *T,...) { <... ( -WARN( +drm_WARN(&T->i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->i915->drm, ...) ) ...> } @@ identifier func, T; @@ func(struct i915_perf_stream *T,...) { +struct drm_i915_private *i915 = T->perf->i915; <+... ( -WARN( +drm_WARN(&i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&i915->drm, ...) ) ...+> } command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file <script> \ --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22drm/i915: Make WARN* drm specific where drm_priv ptr is availablePankaj Bharadiya9-92/+118
drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \ <script> --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22drm/i915/gt: Make WARN* drm specific where drm_priv ptr is availablePankaj Bharadiya8-24/+28
drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/gt \ --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-7-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22drm/i915/gem: Make WARN* drm specific where drm_priv ptr is availablePankaj Bharadiya4-13/+21
drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/gem \ --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-6-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22drm/i915/display: Make WARN* drm specific where encoder ptr is availablePankaj Bharadiya4-16/+20
Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_encoder struct pointer is available. The conversion was done automatically with below coccinelle semantic patch. @@ identifier func, T; @@ func(...) { ... struct intel_encoder *T = ...; <... ( -WARN( +drm_WARN(T->base.dev, ...) | -WARN_ON( +drm_WARN_ON(T->base.dev, ...) | -WARN_ONCE( +drm_WARN_ONCE(T->base.dev, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T->base.dev, ...) ) ...> } @@ identifier func, T; @@ func(struct intel_encoder *T,...) { <... ( -WARN( +drm_WARN(T->base.dev, ...) | -WARN_ON( +drm_WARN_ON(T->base.dev, ...) | -WARN_ONCE( +drm_WARN_ONCE(T->base.dev, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T->base.dev, ...) ) ...> } command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/display \ --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-5-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22drm/bridge: Add I2C based driver for ps8640 bridgeJitao Shi3-0/+360
This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> [uli: followed API changes, removed FW update feature] Signed-off-by: Ulrich Hecht <uli@fpond.eu> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191230090419.137141-3-enric.balletbo@collabora.com
2020-01-22drm/msm: Set dma maximum segment size for mdssSean Paul1-0/+8
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error: [ 12.078665] msm ae00000.mdss: DMA-API: mapping sg segment longer than device claims to support [len=3526656] [max=65536] [ 12.089870] WARNING: CPU: 6 PID: 334 at /mnt/host/source/src/third_party/kernel/v4.19/kernel/dma/debug.c:1301 debug_dma_map_sg+0x1dc/0x318 [ 12.102655] Modules linked in: joydev [ 12.106442] CPU: 6 PID: 334 Comm: frecon Not tainted 4.19.0 #2 [ 12.112450] Hardware name: Google Cheza (rev3+) (DT) [ 12.117566] pstate: 60400009 (nZCv daif +PAN -UAO) [ 12.122506] pc : debug_dma_map_sg+0x1dc/0x318 [ 12.126995] lr : debug_dma_map_sg+0x1dc/0x318 [ 12.131487] sp : ffffff800cc3ba80 [ 12.134913] x29: ffffff800cc3ba80 x28: 0000000000000000 [ 12.140395] x27: 0000000000000004 x26: 0000000000000004 [ 12.145868] x25: ffffff8008e55b18 x24: 0000000000000000 [ 12.151337] x23: 00000000ffffffff x22: ffffff800921c000 [ 12.156809] x21: ffffffc0fa75b080 x20: ffffffc0f7195090 [ 12.162280] x19: ffffffc0f1c53280 x18: 0000000000000000 [ 12.167749] x17: 0000000000000000 x16: 0000000000000000 [ 12.173218] x15: 0000000000000000 x14: 0720072007200720 [ 12.178689] x13: 0720072007200720 x12: 0720072007200720 [ 12.184161] x11: 0720072007200720 x10: 0720072007200720 [ 12.189641] x9 : ffffffc0f1fc6b60 x8 : 0000000000000000 [ 12.195110] x7 : ffffff8008132ce0 x6 : 0000000000000000 [ 12.200585] x5 : 0000000000000000 x4 : ffffff8008134734 [ 12.206058] x3 : ffffff800cc3b830 x2 : ffffffc0f1fc6240 [ 12.211532] x1 : 25045a74f48a7400 x0 : 25045a74f48a7400 [ 12.217006] Call trace: [ 12.219535] debug_dma_map_sg+0x1dc/0x318 [ 12.223671] get_pages+0x19c/0x20c [ 12.227177] msm_gem_fault+0x64/0xfc [ 12.230874] __do_fault+0x3c/0x140 [ 12.234383] __handle_mm_fault+0x70c/0xdb8 [ 12.238603] handle_mm_fault+0xac/0xc4 [ 12.242473] do_page_fault+0x1bc/0x3d4 [ 12.246342] do_translation_fault+0x54/0x88 [ 12.250652] do_mem_abort+0x60/0xf0 [ 12.254250] el0_da+0x20/0x24 [ 12.257317] irq event stamp: 67260 [ 12.260828] hardirqs last enabled at (67259): [<ffffff8008132d0c>] console_unlock+0x214/0x608 [ 12.269693] hardirqs last disabled at (67260): [<ffffff8008080e0c>] do_debug_exception+0x5c/0x178 [ 12.278820] softirqs last enabled at (67256): [<ffffff8008081664>] __do_softirq+0x4d4/0x520 [ 12.287510] softirqs last disabled at (67249): [<ffffff80080be574>] irq_exit+0xa8/0x100 [ 12.295742] ---[ end trace e63cfc40c313ffab ]--- The root of the problem is that the default segment size for sgt is (UINT_MAX & PAGE_MASK), and the default segment size for device dma is 64K. As such, if you compare the 2, you would deduce that the sg segment will overflow the device's capacity. In reality, the hardware can accommodate the larger sg segments, it's just not initializing its max segment properly. This patch initializes the max segment size for the mdss device, which gets rid of that pesky warning. Reported-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200121111813.REPOST.1.I92c66a35fb13f368095b05287bdabdbe88ca6922@changeid
2020-01-22drm/i915: Clear the GGTT_WRITE bit on unbinding the vmaChris Wilson1-2/+9
While we do flush writes to the vma before unbinding (to make sure they go through the right detiling register), we may also be concurrently poking at the GGTT_WRITE bit from set-domain, as we mark all GGTT vma associated with an object. We know this is for another vma, as we are currently unbinding this one -- so if this vma will be reused, it will be refaulted and have its dirty bit set before the next write. Closes: https://gitlab.freedesktop.org/drm/intel/issues/999 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/20200121222447.419489-1-chris@chris-wilson.co.uk
2020-01-22drm/ttm: flush the fence on the bo after we individualize the reservation objectxinhui pan1-1/+3
As we move the ttm_bo_individualize_resv() upwards, we need flush the copied fence too. Otherwise the driver keeps waiting for fence. run&Kill kfdtest, then perf top. 25.53% [ttm] [k] ttm_bo_delayed_delete 24.29% [kernel] [k] dma_resv_test_signaled_rcu 19.72% [kernel] [k] ww_mutex_lock Fix: 378e2d5b("drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more") Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/series/72339/ Signed-off-by: Christian König <christian.koenig@amd.com>
2020-01-22drm/drm_dp_mst:remove set but not used variable 'origlen'Bo YU1-2/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/drm_dp_mst_topology.c:3693:16: warning: variable ‘origlen’ set but not used [-Wunused-but-set-variable] int replylen, origlen, curreply; It looks like never use variable origlen after assign value to it. Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Signed-off-by: Bo YU <tsu.yubo@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200118080628.mxcx7bfwdas5m7un@kaowomen.cn
2020-01-22drm/i915: Don't use VBT for detecting DPCD backlight controlsLyude Paul1-4/+5
Despite the fact that the VBT appears to have a field for specifying that a system is equipped with a panel that supports standard VESA backlight controls over the DP AUX channel, so far every system we've spotted DPCD backlight control support on doesn't actually set this field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI. While we don't know the exact reason for this VBT misuse, talking with some vendors indicated that there's a good number of laptop panels out there that supposedly support both PWM backlight controls and DPCD backlight controls as a workaround until Intel supports DPCD backlight controls across platforms universally. This being said, the X1 Extreme 2nd Gen that I have here (note that Lenovo is not the hardware vendor that informed us of this) PWM backlight controls are advertised, but only DPCD controls actually function. I'm going to make an educated guess here and say that on systems like this one, it's likely that PWM backlight controls might have been intended to work but were never really tested by QA. Since we really need backlights to work without any extra module parameters, let's take the risk here and rely on the standard DPCD caps to tell us whether AUX backlight controls are supported or not. We still check the VBT, just so we can print a debugging message on systems that advertise DPCD backlight support on the panel but not in the VBT. Changes since v3: * Print a debugging message if we enable DPCD backlight control on a device which doesn't report DPCD backlight controls in it's VBT, instead of warning on custom panel backlight interfaces. Signed-off-by: Lyude Paul <lyude@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Perry Yuan <pyuan@redhat.com> Cc: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117232155.135579-1-lyude@redhat.com
2020-01-22drm/i915: drop alpha_support for good in favour of force_probeJani Nikula4-18/+0
It's been a long enough transition period since the DRM_I915_FORCE_PROBE config and i915.force_probe module parameter were introduced in commit 7ef5ef5cdead ("drm/i915: add force_probe module parameter to replace alpha_support"). Remove alpha support. Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121103020.26494-1-jani.nikula@intel.com
2020-01-21drm/i915: Don't show the blank process name for internal/simulated errorsChris Wilson1-1/+1
For a simulated preemption reset, we don't populate the request and so do not fill in the guilty context name. [ 79.991294] i915 0000:00:02.0: GPU HANG: ecode 9:1:e757fefe, in [0] Just don't mention the empty string in the logs! Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capture") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121132107.267709-1-chris@chris-wilson.co.uk
2020-01-21drm/panfrost: Add the panfrost_gem_mapping conceptBoris Brezillon9-74/+300
With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and opened in different context or if the dmabuf is self-imported. The current implementation does not take case into account, and attaches the mapping directly to the panfrost_gem_object. Let's create a panfrost_gem_mapping struct and allow multiple mappings per BO. The mappings are refcounted which helps solve another problem where mappings were torn down (GEM handle closed by userspace) while GPU jobs accessing those BOs were still in-flight. Jobs now keep a reference on the mappings they use. v2 (robh): - Minor review comment clean-ups from Steven - Use list_is_singular helper - Just WARN if we add a mapping when madvise state is not WILLNEED. With that, drop the use of object_name_lock. v3 (robh): - Revert returning list iterator in panfrost_gem_mapping_get() Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021554.15090-1-robh@kernel.org
2020-01-21drm/panfrost: Prefix interrupt handlers' namesEzequiel Garcia3-4/+6
Currently, the interrupt lines requested by Panfrost use unmeaningful names, which adds some obscurity to interrupt introspection (i.e. any tool based on procfs' interrupts file). In order to improve this, prefix each requested interrupt with the module name: panfrost-{gpu,job,mmu}. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191214045952.9452-1-ezequiel@collabora.com
2020-01-21drm/panfrost: Remove core stack power managementSteven Price1-5/+0
Explicit management of the GPU's core stacks is only necessary in the case of a broken integration with the PDC. Since there are no known platforms which have such a broken integration let's remove the explicit control from the driver since this apparently causes problems on other platforms and will have a small performance penality. The out of tree mali_kbase driver contains this text regarding controlling the core stack (CONFIGMALI_CORESTACK): Enabling this feature on supported GPUs will let the driver powering on/off the GPU core stack independently without involving the Power Domain Controller. This should only be enabled on platforms which integration of the PDC to the Mali GPU is known to be problematic. This feature is currently only supported on t-Six and t-HEx GPUs. If unsure, say N. Signed-off-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200109133104.11661-1-steven.price@arm.com
2020-01-21drm/i915/hdcp: Clean up local variablesVille Syrjälä1-29/+25
Eliminate the inconsistencies in the hdcp code local variables: - use dev_priv over dev - use to_i915() instead of dev->dev_private - initialize variables when declaring them - a bit of declaration suffling to appease ocd Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-10-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2020-01-21drm/i915: Rename conn_to_dig_port() to intel_attached_dig_port()Ville Syrjälä3-18/+18
Use the standard naming convention and rename conn_to_dig_port() to intel_attached_dig_port(). @@ @@ - conn_to_dig_port + intel_attached_dig_port (...) { ... } @@ expression C; @@ - conn_to_dig_port(C) + intel_attached_dig_port(C) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-9-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2020-01-21drm/i915: Use intel_attached_dp() instead of hand rolling itVille Syrjälä3-11/+11
Replace the hand rolled intel_attached_dp() with the real thing. @@ identifier F !~ "^intel_attached_dp$"; expression C; @@ F(...) { <... - enc_to_intel_dp(intel_attached_encoder(C)) + intel_attached_dp(C) ...> } v2: Regenerated Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-8-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2020-01-21drm/i915: Relocate intel_attached_dp()Ville Syrjälä2-5/+5
We have uses for intel_attached_dp() outside of intel_dp.c. Move it to a header. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-7-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2020-01-21drm/i915: Use intel_attached_encoder()Ville Syrjälä11-28/+28
It's easy to confuse the drm_connector->encoder (legacy state adjusted during modeset) and intel_connector->encoder (the statically (sans. MST) attached encoder of the connector). For the latter let's use intel_attached_encoder() consistently. @@ identifier F !~ "^intel_attached_encoder$"; struct intel_connector *C; expression E; @@ F(...) { <... ( C->encoder = E | - C->encoder + intel_attached_encoder(C) ) ...> } @@ identifier F !~ "^intel_attached_encoder$"; struct drm_connector *C; expression E; @@ F(...) { <... ( to_intel_connector(C)->encoder = E | - to_intel_connector(C)->encoder + intel_attached_encoder(to_intel_connector(C)) ) ...> } v2: Regenerated Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-6-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2020-01-21drm/i915/dp: debug log max vswing and pre-emphasisJani Nikula1-5/+8
Provide slightly more debugging help. 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/20200117150235.22471-1-jani.nikula@intel.com
2020-01-21drm/i915: use intel_bios_is_port_present()Jani Nikula1-2/+2
Don't access i915->vbt.ddi_port_info[] directly. 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/42544944ce505826335bab30cc76e135581229be.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: check DDI port presence based on child deviceJani Nikula1-3/+1
Report port presence based on port presence in VBT alone, relaxing the requirements on supported encoders (DP, DVI, or HDMI). The goal is to make future changes easier, however there is a small risk of reporting more ports present than before in case of dubious VBT. Regarding the current callers of intel_bios_is_port_present(), the potential issue might be caused by DVO_PORT_CRT being identified as port E in dvo_port_to_port(). Hopefully no VBT has that on SKL+ which support DP/DVI/HDMI on port E; the current CRT init code on HSW/BDW does not care. 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/4338a29e4ed49e69f859dff1490fd85f6ae6177e.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: add intel_bios_port_supports_*()Jani Nikula3-6/+37
Don't access i915->vbt.ddi_port_info[] directly. 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/21549ff74e8e5746917b0e2be4afbfb141e26657.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: add intel_bios_alternate_ddc_pin()Jani Nikula3-8/+16
Don't access i915->vbt.ddi_port_info[] directly. 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/9e4fcb625cec26ee88245aad7ae80bfe93b14e59.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: add intel_bios_dp_max_link_rate()Jani Nikula3-3/+11
Don't access i915->vbt.ddi_port_info[] directly. 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/8c30e1183afdd469c95b01f64ca0458b9e832404.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: intel_bios_hdmi_boost_level()Jani Nikula3-3/+10
Don't access i915->vbt.ddi_port_info[] directly. 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/6d61a5bc60c995d2ee812ef61d3c5c93b61453e7.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: intel_bios_dp_boost_level()Jani Nikula3-3/+10
Don't access i915->vbt.ddi_port_info[] directly. 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/fb8645cecadbc4ebeea1c0de94cb3116a769d9bf.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: add intel_bios_hdmi_level_shift()Jani Nikula3-8/+16
Don't access i915->vbt.ddi_port_info[] directly. 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/da8ca144020fe165af33992661568d0586a2fdeb.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915/bios: add intel_bios_max_tmds_encoder()Jani Nikula3-5/+12
Don't access i915->vbt.ddi_port_info[] directly. 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/c52c39df43374b51f56439daf8047079afae7749.1579270868.git.jani.nikula@intel.com
2020-01-21drm/i915: Align engine->uabi_class/instance with i915_drm.hTvrtko Ursulin2-8/+8
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200116134508.25211-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 0b3bd0cdc329a1e2e00995cffd61aacf58c87cb4) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-01-21drm/i915/userptr: fix size calculationMatthew Auld2-4/+7
If we create a rather large userptr object(e.g 1ULL << 32) we might shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT, resulting in a totally bogus sg_table, which fortunately will eventually manifest as: gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size) kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463! v2: more unsigned long prefer I915_GTT_PAGE_SIZE Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") 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/20200117132413.1170563-2-matthew.auld@intel.com (cherry picked from commit 8e78871bc1e5efec22c950d3fd24ddb63d4ff28a) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-01-21drm/exynos: Rename Exynos to lowercaseKrzysztof Kozlowski1-3/+3
Fix up inconsistent usage of upper and lowercase letters in "Exynos" name. "EXYNOS" is not an abbreviation but a regular trademarked name. Therefore it should be written with lowercase letters starting with capital letter. The lowercase "Exynos" name is promoted by its manufacturer Samsung Electronics Co., Ltd., in advertisement materials and on website. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2020-01-21drm/exynos: change callback namesInki Dae7-31/+31
This patch changes Exynos specific 'disable' and 'enable' callback names to 'atomic_disable/enable' for the consistency. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2020-01-20drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain listChris Wilson3-29/+85
Currently we create a new mmap_offset for every call to mmap_offset_ioctl. This exposes ourselves to an abusive client that may simply create new mmap_offsets ad infinitum, which will exhaust physical memory and the virtual address space. In addition to the exhaustion, a very long linear list of mmap_offsets causes other clients using the object to incur long list walks -- these long lists can also be generated by simply having many clients generate their own mmap_offset. However, we can simply use the drm_vma_node itself to manage the file association (allow/revoke) dropping our need to keep an mmo per-file. Then if we keep a small rbtree of per-type mmap_offsets, we can lookup duplicate requests quickly. 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> Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120104924.4000706-3-chris@chris-wilson.co.uk
2020-01-20drm/i915/sdvo: Consolidate SDVO HDMI force_dvi handlingVille Syrjälä1-5/+15
Move the force_dvi check to a single function that can be called from both mode validation and compute_config(). Note that currently we don't call it from mode validation, but that will change soon. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-01-20drm/i915: Consolidate HDMI force_dvi handlingVille Syrjälä1-23/+26
Move the force_dvi check to a single function that can be called from both mode validation and compute_config(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-01-20drm/i915/sdvo: Reduce the size of the on stack buffersVille Syrjälä1-11/+8
The strings we want to print to the on stack buffers should be no more than 8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61 bytes. So let's shrink the buffers down to 64 bytes. Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in my arithmentic. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-01-20drm/i915: Move encoder variable to tighter scopeVille Syrjälä1-4/+6
Let's not pollute the function scope with variables when they're only needed inside some loops. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-5-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20drm/i915: Use PIPE_CONF_CHECK_X() for sync_mode_slaves_maskVille Syrjälä1-1/+1
sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it so we get the mismatch printed in hex instead of decimal. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-4-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Manasi Navare <manasi.d.navare@intel.com>
2020-01-20drm/i915: Prefer to use the pipe to index the ddb entriesVille Syrjälä1-9/+11
Let's use the pipe rather than the silly 'i' iterator from for_each_oldnew_intel_crtc_in_state() for indexing the ddb entries array. Maybe one day we can assume c99 and hide the 'i' entirely from sight. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20drm/i915: Clear most of crtc state when disabling the crtcVille Syrjälä1-5/+3
Currently we don't call intel_crtc_prepare_cleared_state() for crtcs that are going to be entirely disabled (uapi.enable==false). That means such crtcs will leave stale junk lying around in their states and we have to sprinkle hw.enable checks all over before we can look at the states. Let's change that a bit so that we aways do the state clearing, even for fully disabled crtcs. Note that we still keep some parts of the old state (see intel_crtc_prepare_cleared_state() for the details) so probably can't trust things 100% when hw.enable==false. But at least there's less chance now that we end up looking at stale junk. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20drm/i915: Fix post-fastset modeset check for port syncVille Syrjälä1-26/+17
The post-fastset "does anyone still need a full modeset?" for port sync looks busted. The outer loop bails out of a full modeset is still needed by the current crtc, and then we skip forcing a full modeset on the related crtcs. That's totally the opposite of what we want. The MST path has the logic mostly the other way around so it looks correct. To fix the port sync case let's follow the MST logic for both. So, if the current crtc already needs a modeset we do nothing. otherwise we check if any of the related crtcs needs a modeset, and if so we force a full modeset for the current crtc. And while at let's change the else if to a plain if to so we don't have needless coupling between the MST and port sync checks. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 05a8e45136ca ("drm/i915/display: Use external dependency loop for port sync") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20drm/syncobj: Add documentation for timeline syncobjLionel Landwerlin1-13/+74
We've added a set of new APIs to manipulate syncobjs holding timelines of dma_fence. This adds a bit of documentation about how this works. v2: Small language nits (Lionel) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/348578/ Cc: Christian Koenig <Christian.Koenig@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: David(ChunMing) Zhou <David1.Zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.