- 11 Feb, 2020 1 commit
-
-
Chris Wilson authored
dma-bufs are device coherent, with explicit CPU synchronisation provided via the begin/end cpu access ioctls. As the coherency of the dma-buf is explicitly defined to be under user control, flushing any caches on attach/detach of the dma-buf is additional work that doesn't aide the user in the slightest. Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Dongwon Kim <dongwon.kim@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171130180702.29357-1-chris@chris-wilson.co.uk
-
- 10 Feb, 2020 9 commits
-
-
Chris Wilson authored
Reduce the amount of work we do to verify client blt correctness as currently our 0.5s subtests takes about 15s on slower devices! v2: Grow the maximum block size until we run out of time Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200210231047.810929-1-chris@chris-wilson.co.uk
-
Matt Roper authored
A recent bspec update added an extra voltage level that we didn't have on ICL and new criteria for selecting the level. Bspec: 49208 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200207001417.1229251-2-matthew.d.roper@intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
Matt Roper authored
Voltage level depends not only on the cdclk, but also on the DDI clock. Last time the bspec voltage level table for EHL was updated, we only updated the cdclk requirements, but forgot to account for the new port clock criteria. Bspec: 21809 Fixes: d1474838 ("drm/i915/ehl: Update voltage level checks") Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Add a basic description about how DC3CO works to help people not familiar with it. While at it, I also improved the delayed work handle and function names and removed a debug message that is ambiguous and not much useful, no changes in behavior here. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205214945.131012-1-jose.souza@intel.com
-
Chris Wilson authored
live_preempt_hang's use of hang injection has been superseded by live_preempt_reset's use of an non-preemptible spinner. The latter does not require intrusive hacks into the code. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200209230838.361154-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
When we are forcing the error for a selftest, we don't need to capture the GPU state (typically). Signed-off-by:
-
José Roberto de Souza authored
EHL only differs from ICL on the voltage swing table for HBR2 and HBR3. BSpec: 21257 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jani Nikula authored
Make future work slightly easier. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204135217.21974-1-jani.nikula@intel.com
-
Jani Nikula authored
Commit 21fd23ac ("drm/i915: move pipe, pch and vblank enable to encoders on DDI platforms") pushed pipe and vblank enable to encoders on DDI platforms, however it missed the DP MST encoder. Fix it. Fixes: 21fd23ac ("drm/i915: move pipe, pch and vblank enable to encoders on DDI platforms") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reported-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
- 09 Feb, 2020 3 commits
-
-
Chris Wilson authored
On an allocation error path for live_hwsp_alternate, we dropped the engine wakeref before we had even acquired it. Signed-off-by:
-
Chris Wilson authored
Recording the frequent inspection of CSB head/tail when there is expected to be no update adds noise to the debug trace. (Not entirely useless, but since we know the sequence of function calls, we can surmise the function was called -- so redundant.) Signed-off-by:
-
Chris Wilson authored
In eliminating the recursion from walking the tree of signalers/waiters for processing the hold/unhold operations, a crucial error crept in where we looked at the parent request and not the list element when processing the list. Brown paper bag, much? Closes: https://gitlab.freedesktop.org/drm/intel/issues/1166 Fixes: 32ff621f ("drm/i915/gt: Allow temporary suspension of inflight requests") Fixes: 74831738 ("drm/i915/execlists: Offline error capture") Signed-off-by:
-
- 08 Feb, 2020 4 commits
-
-
Mika Kuoppala authored
We have switched from tail manipulation to forced context restore to implement WaIdleLiteRestore. Remove the old defines and comments. Note: we still do emit the WA tail, and use it as our first attempt to avoid forcing a full-restore instead of a lite-restore, we just have a much stronger backup mechanism for repeated preemptions. References: f26a9e95 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Janusz Krzysztofik authored
Commit 4f2a572e ("drm/i915/userptr: Never allow userptr into the mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when attempted on a userptr object in order to protect from a lockdep splat. Later on, new mapping types were introduced by commit cc662126 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET"). Those new mapping types suffer from the same lockdep splat issue but they now succeed when tried on top of a userptr object. Fix it. v2: Don't play with the -ENODEV driver response (Chris) Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Tvrtko Ursulin authored
Last IGT user (intel_gpu_overlay) stopped using it in October 2019 so we are good to remove the file. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Moving the base forward since this one was so old. New base contains fixes that we needed. Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 07 Feb, 2020 15 commits
-
-
Chris Wilson authored
If we rewind the RING_TAIL on a context, due to a preemption event, we must force the context restore for the RING_TAIL update to be properly handled. Rather than note which preemption events may cause us to rewind the tail, compare the new request's tail with the previously submitted RING_TAIL, as it turns out that timeslicing was causing unexpected rewinds. <idle>-0 0d.s2 1280851190us : __execlists_submission_tasklet: 0000:00:02.0 rcs0: expired last=130:4698, prio=3, hint=3 <idle>-0 0d.s2 1280851192us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 66:119966, current 119964 <idle>-0 0d.s2 1280851195us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4698, current 4695 <idle>-0 0d.s2 1280851198us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4696, current 4695 ^---- Note we unwind 2 requests from the same context <idle>-0 0d.s2 1280851208us : __i915_request_submit: 0000:00:02.0 rcs0: fence 130:4696, current 4695 <idle>-0 0d.s2 1280851213us : __i915_request_submit: 0000:00:02.0 rcs0: fence 134:1508, current 1506 ^---- But to apply the new timeslice, we have to replay the first request before the new client can start -- the unexpected RING_TAIL rewind <idle>-0 0d.s2 1280851219us : trace_ports: 0000:00:02.0 rcs0: submit { 130:4696*, 134:1508 } synmark2-5425 2..s. 1280851239us : process_csb: 0000:00:02.0 rcs0: cs-irq head=5, tail=0 synmark2-5425 2..s. 1280851240us : process_csb: 0000:00:02.0 rcs0: csb[0]: status=0x00008002:0x00000000 ^---- Preemption event for the ELSP update; note the lite-restore synmark2-5425 2..s. 1280851243us : trace_ports: 0000:00:02.0 rcs0: preempted { 130:4698, 66:119966 } synmark2-5425 2..s. 1280851246us : trace_ports: 0000:00:02.0 rcs0: promote { 130:4696*, 134:1508 } synmark2-5425 2.... 1280851462us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4700, current 4695 synmark2-5425 2.... 1280852111us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4702, current 4695 synmark2-5425 2.Ns1 1280852296us : process_csb: 0000:00:02.0 rcs0: cs-irq head=0, tail=2 synmark2-5425 2.Ns1 1280852297us : process_csb: 0000:00:02.0 rcs0: csb[1]: status=0x00000814:0x00000000 synmark2-5425 2.Ns1 1280852299us : trace_ports: 0000:00:02.0 rcs0: completed { 130:4696!, 134:1508 } synmark2-5425 2.Ns1 1280852301us : process_csb: 0000:00:02.0 rcs0: csb[2]: status=0x00000818:0x00000040 synmark2-5425 2.Ns1 1280852302us : trace_ports: 0000:00:02.0 rcs0: completed { 134:1508, 0:0 } synmark2-5425 2.Ns1 1280852313us : process_csb: process_csb:2336 GEM_BUG_ON(!i915_request_completed(*execlists->active) && !reset_in_progress(execlists)) Fixes: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") Referenecs: 82c69bf5 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore") Signed-off-by: -
Chris Wilson authored
If a request is being re-run after an innocent reset, it is marked as -EAGAIN. So only skip an engine reset if the request is marked as -EIO. Testcase: igt/gem_ctx_exec/basic-nohangcheck Signed-off-by:
-
Mika Kuoppala authored
SIMD16 with Src0 scalar might conflict between Src1/Src2 and cause GRF read issue. Workaround this issue by setting bit 14 in 0xe4f4 which will disable early read/src swap of Src0. Signed-off-by:
-
Mika Kuoppala authored
Disable TEDOP clock gating flow by programming 0x20A0[19] = 1 References: HSDES#1407928979 Signed-off-by:
-
Chris Wilson authored
We set up a dummy ring in order to measure the size we require for our breadcrumb emission, so that we don't have to manually count dwords! We can pass in the kernel_context to use for this so that if required it is known for the breadcrumb emitter, and we can reuse some details from the kernel_context to reduce the number of temporaries we have to mock. Signed-off-by:
-
Chris Wilson authored
Do not try and dereference the i915 private before it has been allocated and attached to the drvdata! Fixes: 7daac72e ("drm/i915/pci: conversion to drm_device based logging macros.") Signed-off-by:
-
Michal Wajdeczko authored
We are sanitizing firmware status and old mmio message, but we forget to sanitize CT status. Fixes: e85de177 ("drm/i915/guc: Introduce guc_is_ready") Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Chris Wilson authored
As we may add new waiters to a request as it is being run, we need to mark the list iteration as being safe for concurrent addition. v2: Mika spotted that we used the same trick for signalers_list, so warn the compiler about the lockless walk there as well. Fixes: 32ff621f ("drm/i915/gt: Allow temporary suspension of inflight requests") Signed-off-by:
-
Lyude Paul authored
This reverts commit d2a4bb6f. So, turns out that this ended up just breaking things. While many laptops incorrectly advertise themselves as supporting PWM backlight controls, they actually will only work with DPCD backlight controls. Unfortunately, it also seems there are a number of systems which advertise DPCD backlight controls in their eDP DPCD but don't actually support them. Talking with some laptop manufacturers has shown it might be possible to probe this support via the EDID (!?!?) but I haven't been able to confirm that this would work on any other manufacturer's systems. So in the mean time, we'll just revert this commit for now and go back to the old way of doing things. Fixes: d2a4bb6f ("drm/i915: Don't use VBT for detecting DPCD backlight controls") Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
Mika spotted <4>[17436.705441] general protection fault: 0000 [#1] PREEMPT SMP PTI <4>[17436.705447] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.5.0+ #1 <4>[17436.705449] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 3805 05/16/2018 <4>[17436.705512] RIP: 0010:__execlists_submission_tasklet+0xc4d/0x16e0 [i915] <4>[17436.705516] Code: c5 4c 8d 60 e0 75 17 e9 8c 07 00 00 49 8b 44 24 20 49 39 c5 4c 8d 60 e0 0f 84 7a 07 00 00 49 8b 5c 24 08 49 8b 87 80 00 00 00 <48> 39 83 d8 fe ff ff 75 d9 48 8b 83 88 fe ff ff a8 01 0f 84 b6 05 <4>[17436.705518] RSP: 0018:ffffc9000012ce80 EFLAGS: 00010083 <4>[17436.705521] RAX: ffff88822ae42000 RBX: 5a5a5a5a5a5a5a5a RCX: dead000000000122 <4>[17436.705523] RDX: ffff88822ae42588 RSI: ffff8881e32a7908 RDI: ffff8881c429fd48 <4>[17436.705525] RBP: ffffc9000012cf00 R08: ffff88822ae42588 R09: 00000000fffffffe <4>[17436.705527] R10: ffff8881c429fb80 R11: 00000000a677cf08 R12: ffff8881c42a0aa8 <4>[17436.705529] R13: ffff8881c429fd38 R14: ffff88822ae42588 R15: ffff8881c429fb80 <4>[17436.705532] FS: 0000000000000000(0000) GS:ffff88822ed00000(0000) knlGS:0000000000000000 <4>[17436.705534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[17436.705536] CR2: 00007f858c76d000 CR3: 0000000005610003 CR4: 00000000003606e0 <4>[17436.705538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4>[17436.705540] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 <4>[17436.705542] Call Trace: <4>[17436.705545] <IRQ> <4>[17436.705603] execlists_submission_tasklet+0xc0/0x130 [i915] which is us consuming a partially initialised new waiter in defer_requests(). We can prevent this by initialising the i915_dependency prior to making it visible, and since we are using a concurrent list_add/iterator mark them up to the compiler. Fixes: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by:
-
Chris Wilson authored
Virtual engines are fleeting. They carry a reference count and may be freed when their last request is retired. This makes them unsuitable for the task of housing engine->retire.work so assert that it is not used. Tvrtko tracked down an instance where we did indeed violate this rule. In virtual_submit_request, we flush a completed request directly with __i915_request_submit and this causes us to queue that request on the veng's breadcrumb list and signal it. Leading us down a path where we should not attach the retire. Reported-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.6-2020-02-05: amdgpu: - EDC fixes for Arcturus - GDDR6 memory training fixe - Fix for reading gfx clockgating registers while in GFXOFF state - i2c freq fixes - Misc display fixes - TLB invalidation fix when using semaphores - VCN 2.5 instancing fixes - Switch raven1 gfxoff to a blacklist - Coreboot workaround for KV/KB - Root cause dongle fixes for display and revert workaround - Enable GPU reset for renoir and navi - Navi overclocking fixes - Fix up confusing warnings in display clock validation on raven amdkfd: - SDMA fix radeon: - Misc LUT fixes Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206035458.3894-1-alexander.deucher@amd.com
-
git://github.com/skeggsb/linuxDave Airlie authored
Just a couple of fixes to Volta/Turing modesetting on some systems. Signed-off-by:
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Fixes for v5.6-rc1 These are a couple of quick fixes for regressions that were found during the first two weeks of the merge window. Signed-off-by:
-
Matthew Auld authored
We already have tests that exhaustively exercise the most interesting page-size combinations, along with tests that offer randomisation, and so we should already be testing objects(local, system) with a varying mix of page-sizes, which leaves igt_ppgtt_exhaust_huge providing not much in terms of extra coverage. Signed-off-by:
-
- 06 Feb, 2020 5 commits
-
-
José Roberto de Souza authored
TGL is suffering of timeouts and fifo underruns when disabling transcoder in MST mode, this is fixed by set TRANS_DDI_MODE_SELECT to 0(HDMI mode) when clearing DDI select. Although BSpec disable sequence don't require this step, it is a harmless change and it is also done by Windows driver. Anyhow HW team was notified about that but it can take some time to documentation to be updated. A case that always lead to those issues is: - do a modeset enabling pipe A and pipe B in the same MST stream leaving A as master - disable pipe A, promote B as master doing a full modeset in A - enable pipe A, changing the master transcoder back to A(doing a full modeset in B) - Pow: underruns and timeouts The transcoders involved will only work again when complete disabled and their power wells turned off causing a reset in their registers. v2: Setting TRANS_DDI_MODE_SELECT to default when clearing DDI select not anymore when disabling TRANS_DDI, both work but this one looks more safe. (Ville comment) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203225549.152301-1-jose.souza@intel.com
-
Chris Wilson authored
Always prime the page table registers before starting the ring. Even though we will update these to the per-context page tables during dispatch, it is prudent to ensure that the registers always point to a valid PD. Signed-off-by:
-
Thierry Reding authored
The DMA direction is only used by the DMA API, so there is no use in setting it when a buffer object isn't mapped with the DMA API. Signed-off-by:
Thierry Reding <treding@nvidia.com> Tested-by:
Dmitry Osipenko <digetx@gmail.com> Reviewed-by:
-
Thierry Reding authored
This partially reverts the DMA API support that was recently merged because it was causing performance regressions on older Tegra devices. Unfortunately, the cache maintenance performed by dma_map_sg() and dma_unmap_sg() causes performance to drop by a factor of 10. The right solution for this would be to cache mappings for buffers per consumer device, but that's a bit involved. Instead, we simply revert to the old behaviour of sharing IOVA mappings when we know that devices can do so (i.e. they share the same IOMMU domain). Cc: <stable@vger.kernel.org> # v5.5 Reported-by:
-
Thierry Reding authored
Older Tegra devices only allow addressing 32 bits of memory, so whether or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU attachment is only needed on devices that can address memory beyond the 32-bit boundary and where the host1x doesn't support the wide GATHER opcode that allows it to access buffers at higher addresses. Cc: <stable@vger.kernel.org> # v5.5 Signed-off-by:
-
- 05 Feb, 2020 3 commits
-
-
Chris Wilson authored
Rather than flushing the submission tasklets just before we sleep, flush before we check the request status. Ideally this gives us a moment to process the tasklets after sleeping just before we timeout. v2: Compromise by pushing the flush prior to the timeout, but after the check on completion so that we do not further delay the ready client. Signed-off-by:
-
Chris Wilson authored
We have been using '-1' to mean the maximum i915.reset level in the belief that it was unsigned... This turns out to have been a grave error, and instead of setting the default reset mechanism in igt, we have been disabling reset! Signed-off-by:
-
Stanislav Lisovskiy authored
Added proper DBuf slice mapping to correspondent pipes, depending on pipe configuration as stated in BSpec. v2: - Remove unneeded braces - Stop using macro for DBuf assignments as it seems to reduce readability. v3: Start using enabled slices mask in dev_priv v4: Renamed "enabled_slices" used in dev_priv to "enabled_dbuf_slices_mask"(Matt Roper) v5: - Removed redundant parameters from intel_get_ddb_size function.(Matt Roper) - Made i915_possible_dbuf_slices static(Matt Roper) - Renamed total_width into total_width_in_range so that it now reflects that this is not a total pipe width but the one in current dbuf slice allowed range for pipe.(Matt Roper) - Removed 4th pipe for ICL in DBuf assignment table(Matt Roper) - Fixed wrong DBuf slice in DBuf table for TGL (Matt Roper) - Added comment regarding why we currently not using pipe ratio for DBuf assignment for ICL v6: - Changed u32 to unsigned int in icl_get_first_dbuf_slice_offset function signature (Ville Syrjälä) - Changed also u32 to u8 in dbuf slice mask structure (Ville Syrjälä) - Switched from DBUF_S1_BIT to enum + explicit BIT(DBUF_S1) access(Ville Syrjälä) - Switched to named initializers in DBuf assignment arrays(Ville Syrjälä) - DBuf assignment arrays now use autogeneration tool from https://patchwork.freedesktop.org/series/70493/ to avoid typos. - Renamed i915_find_pipe_conf to *_compute_dbuf_slices (Ville Syrjälä) - Changed platforms ordering in skl_compute_dbuf_slices to be from newest to oldest(Ville Syrjälä) v7: - Now ORing assigned DBuf slice config always with DBUF_S1 because slice 1 has to be constantly powered on. (Ville Syrjälä) v8: - Added pipe_name for neater printing(Ville Syrjälä) - Renamed width_before_pipe to width_before_pipe_in_range, to better reflect that now all the calculations are happening inside DBuf range allowed by current pipe configuration mask (Ville Syrjälä) - Shortened FIXME comment message, regarding constant ORing with DBUF_S1(Ville Syrjälä) - Added .dbuf_mask named initializer to pipe assignment array (Ville Syrjälä) - Edited pipe assignment array to use only single DBuf slice for gen11 single pipe configurations, until "pipe ratio" thing is finally sorted out(Ville Syrjälä) - Removed unused parameter crtc_state for now(Ville Syrjälä) from icl/tgl_compute_dbuf_slices function Reviewed-by:
-
