- 08 Feb, 2020 1 commit
-
-
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 <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Link: https://patchwork.freedesktop.org/patch/msgid/20200207211452.2860634-1-chris@chris-wilson.co.uk
-
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200207161602.2838218-1-chris@chris-wilson.co.uk
-
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 <mika.kuoppala@linux.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/20200207155138.30978-2-mika.kuoppala@linux.intel.com
-
Mika Kuoppala authored
Disable TEDOP clock gating flow by programming 0x20A0[19] = 1 References: HSDES#1407928979 Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20200207155138.30978-1-mika.kuoppala@linux.intel.com
-
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 <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/20200207125827.2787472-1-chris@chris-wilson.co.uk
-
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Wambui Karuga <wambui.karugax@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200207135048.2788199-1-chris@chris-wilson.co.uk
-
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 <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200207131938.2787828-1-chris@chris-wilson.co.ukSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200207110213.2734386-1-chris@chris-wilson.co.uk
-
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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204192823.111404-2-lyude@redhat.com
-
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 <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/20200206204915.2636606-2-chris@chris-wilson.co.uk
-
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: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: dc93c9b6 ("drm/i915/gt: Schedule request retirement when signaler idles") 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/20200206204915.2636606-1-chris@chris-wilson.co.uk
-
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: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv7=eP+Ai1ouoMyYyo1xMF0pTQki=owYjJkS=NpvKQd1fg@mail.gmail.com
-
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: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206172753.2185390-1-thierry.reding@gmail.com
-
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: Matthew Auld <matthew.auld@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/20200206170340.102613-1-matthew.auld@intel.com
-
- 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: José Roberto de Souza <jose.souza@intel.com> Reviewed-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: 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/20200206014439.2137800-2-chris@chris-wilson.co.uk
-
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: Dmitry Osipenko <digetx@gmail.com>
-
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: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
-
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: Thierry Reding <treding@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
-
- 05 Feb, 2020 13 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 <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205095441.1769599-1-chris@chris-wilson.co.uk
-
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205123757.1834947-1-chris@chris-wilson.co.uk
-
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: Matt Roper <matthew.d.roper@intel.com> Signed-off-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/20200202230630.8975-7-stanislav.lisovskiy@intel.com
-
Stanislav Lisovskiy authored
Start manipulating DBuf slices as a mask, but not as a total number, as current approach doesn't give us full control on all combinations of slices, which we might need(like enabling S2 only can't enabled by setting enabled_slices=1). Removed wrong code from intel_get_ddb_size as it doesn't match to BSpec. For now still just use DBuf slice until proper algorithm is implemented. Other minor code refactoring to get prepared for major DBuf assignment changes landed: - As now enabled slices contain a mask we still need some value which should reflect how much DBuf slices are supported by the platform, now device info contains num_supported_dbuf_slices. - Removed unneeded assertion as we are now manipulating slices in a more proper way. v2: Start using enabled_slices in dev_priv v3: "enabled_slices" is now "enabled_dbuf_slices_mask", as this now sits in dev_priv independently. v4: - Fixed debug print formatting to hex(Matt Roper) - Optimized dbuf slice updates to be used only if slice union is different from current conf(Matt Roper) - Fixed some functions to be static(Matt Roper) - Created a parameterized version for DBUF_CTL to simplify DBuf programming cycle(Matt Roper) - Removed unrequred field from GEN10_FEATURES(Matt Roper) v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä) - Started to use parameterized loop for hw readout to get slices (Ville Syrjälä) - Added back assertion checking amount of DBUF slices enabled after DC states 5/6 transition, also added new assertion as starting from ICL DMC seems to restore the last DBuf power state set, rather than power up all dbuf slices as assertion was previously expecting(Ville Syrjälä) v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä) - Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled back, as we really need to have a single unified assert here however currently enabling always slice 1 is enforced by BSpec, so we will have to OR enabled slices mask with 1 in order to be consistent with BSpec, that way we can unify that assertion and against the actual state from the driver, but not some hardcoded value.(concluded with Ville) - Remove parameterized DBUF_CTL version, to extract it to another patch.(Ville Syrjälä) v7: - Removed unneeded hardcoded return value for older gens from intel_enabled_dbuf_slices_mask - this now is handled in a unified manner since device info anyway returns max dbuf slices as 1 for older platforms(Matthew Roper) - Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead of intel_dbuf_max_slices function as it is trivial(Matthew Roper) v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä) v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä) - Now using power_domain mutex to protect from race condition, which can occur because intel_dbuf_slices_update might be running in parallel to gen9_dc_off_power_well_enable being called from intel_dp_detect for instance, which causes assertion triggered by race condition, as gen9_assert_dbuf_enabled might preempt this when registers were already updated, while dev_priv was not. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-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/20200202230630.8975-6-stanislav.lisovskiy@intel.com
-
Stanislav Lisovskiy authored
Now start using parameterized DBUF_CTL instead of hardcoded, this would allow shorter access functions when reading or storing entire state. Tried to implement it in a MMIO_PIPE manner, however DBUF_CTL1 address is higher than DBUF_CTL2, which implies that we have to now subtract from base rather than add. v2: - Removed unneeded DBUF_CTL_DIST and DBUF_CTL_ADDR macros. Started to use _PICK construct as suggested by Matt Roper. v3: - _DBUF_CTL_S* to DBUF_CTL_S*, changed X to "slice" in macro(Ville Syrjälä) - Introduced enum for enumerating DBUF slices(Ville Syrjälä) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-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/20200202230630.8975-5-stanislav.lisovskiy@intel.com
-
Stanislav Lisovskiy authored
During full modeset, global state(i.e dev_priv) is protected by locking the crtcs in state, otherwise global state is not serialized. Also if it is not a full modeset, we anyway don't need to change DBuf slice configuration as Pipe configuration doesn't change. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-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/20200202230630.8975-4-stanislav.lisovskiy@intel.com
-
Stanislav Lisovskiy authored
Current DBuf slices update wasn't done in proper place, especially its "post" part, which should disable those only once vblank had passed and all other changes are committed. v2: Fix to use dev_priv and intel_atomic_state instead of skl_ddb_values (to be nuked in Villes patch) v3: Renamed "enabled_slices" to "enabled_dbuf_slices_num" (Matt Roper) v4: - Rebase against drm-tip. - Move post_update closer to optimize_watermarks, to prevent unneeded noise from underrun reporting (Ville Syrjälä) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-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/20200202230630.8975-3-stanislav.lisovskiy@intel.com
-
Stanislav Lisovskiy authored
Current consensus that it is redundant as we already have skl_ddb_values struct out there, also this struct contains only single member which makes it unnecessary. v2: As dirty_pipes soon going to be nuked away from skl_ddb_values, evacuating enabled_slices to safer in dev_priv. v3: Changed "enabled_slices" to be "enabled_dbuf_slices_num" (Matt Roper) v4: - Wrapped the line getting number of dbuf slices(Matt Roper) - Removed indeed redundant skl_ddb_values declaration(Matt Roper) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-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/20200202230630.8975-2-stanislav.lisovskiy@intel.com
-
Chris Wilson authored
As only the display codes tries to pin its preallocated framebuffer into an exact location in the GGTT, remove the convenience function and make the pin management explicit in the display code. Then throughout the display management, we track the framebuffer and its plane->vma; with less single purpose code and ready for first class i915_vma. In doing so, this should fix the BUG_ON(vma->pages) on fi-kbl-soraka. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204094801.877288-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
I am about to stuff more objects into the plane_config and would like to have it clean up after itself. Move the current framebuffer release into a common function so it can be extended with the new object with relative ease. 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/20200204094801.877288-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
The DDI encoder code shouln't have to know about the guts of HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in intel_hdcp.c. No functional changes. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128163803.5954-1-jani.nikula@intel.com
-
Lyude Paul authored
Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 ------------[ cut here ]------------ WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ffffac428127f5b0 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8d1e166eee80 RCX: 0000000000000000 RDX: ffffac428127f668 RSI: ffff8d1e166eee80 RDI: ffffac428127f610 RBP: ffffac428127f640 R08: ffffffffc03d94a8 R09: 0000000000000000 R10: ffff8d1e24b02000 R11: ffffac428127f5b0 R12: ffff8d1e1b83d000 R13: ffff8d1e1bea0b08 R14: 0000000000000002 R15: 0000000000000002 FS: 00007fab23ffcd80(0000) GS:ffff8d1e28b40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f151f1711e8 CR3: 00000005997c0000 CR4: 00000000003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd045f9068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd045f90a0 RCX: 00007fab2121f87b RDX: 00007ffd045f90a0 RSI: 00000000c06864a2 RDI: 000000000000000b RBP: 00007ffd045f90a0 R08: 0000000000000000 R09: 000055dbd2985d10 R10: 000055dbd2196280 R11: 0000000000000246 R12: 00000000c06864a2 R13: 000000000000000b R14: 0000000000000000 R15: 000055dbd2196280 ---[ end trace 6ea888c24d2059cd ]--- Note as well, I have only been able to reproduce this on setups with 2 MST displays. Changes since v1: * Don't return false when part 1 or part 2 of updating the payloads fails, we don't want to abort at any step of the process even if things fail Reviewed-by: Mikita Lipski <Mikita.Lipski@amd.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
It needed to be updated as well so it will show the proper values if you reset to the defaults. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
- 04 Feb, 2020 6 commits
-
-
Chris Wilson authored
The current rc6 threshold is larger than the evaluation interval on Ivybridge; it never enters rc6. Remove the special casing so it behaves like the other gen6/gen7, and we see rc6 residencies before we manually park the system. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1114 Testcase: igt/i915_pm_rc6_residency/rc6-idle #ivb Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203202110.670209-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Add the missing comma after the last initialized element of the hpd[] arrays. Best not give people bad ideas. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121171100.4370-9-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
All the TMDS DVO chips have a sensible looking .detect(). Let's poll them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121171100.4370-8-ville.syrjala@linux.intel.comAcked-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
ns2501 has a builtin scaler so it doesn't need a fixed mode, but let's still mark it as LVDS instead of TMDS/DVI to make life less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121171100.4370-7-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Let's make sure encoder->hpd_pin and connector->polled are mirror images of each other (when we want to use polling). The other potentially polled connectors (sdvo and tv) already get this right. Also nuke the redundant force_hotplug_required initialization (the thing is kzalloc()ed). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121171100.4370-4-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Simplify the hotplug code connector->encoder->hpd_pin handling by introducing a helper for exactly this purpose. In the helper we can neatly deal with the potential lack of an attached encoder on fresh MST connectors leaving the rest of the hpd code oblivious to such details. Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121171100.4370-3-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-