Commit 21fd23ac22 ("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: 21fd23ac22 ("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: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Tested-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200205082959.31317-1-jani.nikula@intel.com
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 <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/20200209131922.180287-2-chris@chris-wilson.co.uk
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: 32ff621fd7 ("drm/i915/gt: Allow temporary suspension of inflight requests")
Fixes: 748317386a ("drm/i915/execlists: Offline error capture")
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: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200209131922.180287-1-chris@chris-wilson.co.uk
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: f26a9e959a ("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: 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/20200203163312.15475-1-mika.kuoppala@linux.intel.com
Commit 4f2a572eda ("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 cc662126b4
("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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204162302.1299516-1-chris@chris-wilson.co.uk
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: 8ee36e048c ("drm/i915/execlists: Minimalistic timeslicing")
Referenecs: 82c69bf586 ("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
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
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
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
Do not try and dereference the i915 private before it has been allocated
and attached to the drvdata!
Fixes: 7daac72e9a ("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
We are sanitizing firmware status and old mmio message, but
we forget to sanitize CT status.
Fixes: e85de17703 ("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.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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: 32ff621fd7 ("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
This reverts commit d2a4bb6f8b.
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: d2a4bb6f8b ("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
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: dc93c9b693 ("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
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
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
These are a couple of quick fixes for regressions that were found during
the first two weeks of the merge window.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl48S+kTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zodLzD/sGXZVXj2Y/IH2gLv2soU9PIsy43xr7
y6D4kZIWPgGuQD+GNbU7I0k5zMQffJ3fWogXLnWyMhxj/RgjX1O0h6WWspBmWXlS
zUtv9u4wkn2eVrKoRUyV694RJFqG3wmppYwPnWrx0UJFBQptUhp98XTUIXD634Vp
FwM4ya+Yc0ucBc982XmZ/hkPZYnduQF9eZTnR0xbA/xZj4G3s9unNy/2mjVDrpZM
MjYDzfXSMiVHL1ROLZLCsQVrfUMYoUgB8ill0o0DxE5kHL6KpA55j28WzxBwbZQQ
iSxDbjtNPnQV3pR5/sBLpLP1CeYJ1dY9TVUcy+6u+f3SFcJUhM6LEsi5W2EgcBKT
j+0Tag0i12cFvEDo1NbK4SGCp3OmeuFB0nAPT7OGtUMByWC+uhgspCQn0ZqVjEB6
Iy4EGrhPqbUCEsF72VR6amgi0sd2lkyGaCY1F3Do2hrHs/EgrFN3bKDRhM63oAGT
y9vH5eV92Q0CDAFpu+V6kBLOLod6dmyKhYexZdDfiA24BLsDoDeUafFlSi8luQmj
3bwX7agPmvtaIyBakmLG7nRHK0EhNaP82EpxyZ/a3PHH9CWUa+jC3CsqlO3tvbBZ
02mkmvXnYCyrL+qdh/abHfPktKQ49QM5JrHCp96hNLc27qyqyfzbC4FYtgA/3JCo
Fn8pINhC7Mc/dg==
=W1SC
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-5.6-rc1-fixes' of git://anongit.freedesktop.org/tegra/linux into drm-next
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
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
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
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
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>
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>
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
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
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
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
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
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
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
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
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
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
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
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/1020
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
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.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cull out 0 clocks to avoid a warning in DC.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Only send non-0 clocks to DC for validation. This mirrors
what the windows driver does.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We might get different numbers of clocks from powerplay depending
on what the OEM has populated.
v2: add assert for at least one level
Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ask the SMU for the default VDDC curve voltage values. This
properly reports the VDDC values in the OD interface.
v2: only update if the original values are 0
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.5.x
Previously, the syfs functionality for restoring the default powerplay
table was sourcing it's information from the currently-staged powerplay
table.
This patch adds a step to cache the first overdrive table that we see on
boot, so that it can be used later to "restore" the powerplay table
v2: sqaush my original with Matt's fix
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020
Signed-off-by: Matt Coffin <mcoffin13@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.5.x
[Why]
When we disable a connector we don't explicitly remove it from the module so the
display is still cached(SW) in the hdcp_module.
SST: no issues because we can only have 1 display per link
MST: We have x displays per link, now if we disable 1 we don't remove it from the
module so the module has x display cached(SW).
If we try to enable HDCP, psp verification will fail because we are reporting x
displays while the HW only has x-1 display enabled
[How]
Check the callback for when we disable stream and call remove display.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Remove a backslash symbol accidentally left in increase bpp function
when computing mst dsc configuration.
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Zhan Liu <zhan.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This workaround is needed only for Navi10 12 Gbps SKUs.
V2: added SMU firmware version guard
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The sdma_queue_count increment should be done before
execute_queues_cpsch(), which calls pm_calc_rlib_size() where
sdma_queue_count is used to calculate whether over_subscription is
triggered.
With the previous code, when a SDMA queue is created,
compute_queue_count in pm_calc_rlib_size() is one more than the
actual compute queue number, because the queue_count has been
incremented while sdma_queue_count has not. This patch fixes that.
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
In current code we're essentially drawing the cursor on every pipe
that contains it. This only works when the planes have the same
scaling for src to dest rect, otherwise we'll get "double cursor" where
one cursor is incorrectly filtered and offset from the real position.
[How]
Without dedicated cursor planes on DCN we require at least one pipe
that matches the scaling of the current timing.
This is an optimization and workaround for the most common case where
the top-most plane is not scaled but the bottom-most plane is scaled.
Whenever a pipe has a parent pipe in the blending tree whose recout
fully contains the current pipe we can disable the pipe.
This only applies when the pipe is actually visible of course.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm_pci_alloc and drm_pci_free are just very thin wrappers around
dma_alloc_coherent, with a note that we should be removing them.
Furthermore since
commit de09d31dd3
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Fri Jan 15 16:51:42 2016 -0800
page-flags: define PG_reserved behavior on compound pages
As far as I can see there's no users of PG_reserved on compound pages.
Let's use PF_NO_COMPOUND here.
drm_pci_alloc has been declared broken since it mixes GFP_COMP and
SetPageReserved. Avoid this conflict by weaning ourselves off using the
abstraction and using the dma functions directly.
Reported-by: Taketo Kabe
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1027
Fixes: de09d31dd3 ("page-flags: define PG_reserved behavior on compound pages")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.5+
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200202153934.3899472-1-chris@chris-wilson.co.uk
Shrink the strncpy bounds to ensure the NUL-terminator can fit within
the embedded array:
In file included from drivers/gpu/drm/i915/gem/i915_gem_context.c:2475:
drivers/gpu/drm/i915/gem/selftests/mock_context.c: In function ‘mock_context’:
drivers/gpu/drm/i915/gem/selftests/mock_context.c:40:3: error: ‘strncpy’ specified bound 24 equals destination size [-Werror=stringop-truncation]
40 | strncpy(ctx->name, name, sizeof(ctx->name));
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/20200203181625.589118-1-chris@chris-wilson.co.uk
Exercise the seqno wrap paths on the kernel context to provide a small
amount of sanity checking and ensure that they are visible to lockdep.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204094102.876636-1-chris@chris-wilson.co.uk
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Instances of the DRM_DEBUG macro were not converted due to lack of a
consensus of an analogous struct drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
The OR routing logic in NVKM does not expect to receive supervisor
interrupts until the DD has provided consistent information on the
ORs it's using and the EVO/NVD assembly state to match.
The combination of changing window ownership + core channel update
during display init triggered a situation where we'd disconnect an
OR from the pad it was meant to still be driving on some systems.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
For various complicated reasons, we need to avoid sending a core update
method during display init. Something, which we've been required to do
on GV100 and up because we've been assigning windows to heads there and
the HW is rather picky about when that's allowed.
This moves window assignment into the modesetting path at a point where
it's much safer to send our first update methods to NVDisplay.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On seqno rollover, we need to allocate ourselves a new cacheline. This
might incur grabbing a new page and pinning it into the GGTT, with some
rather unfortunate lockdep implications.
To avoid a mutex, and more specifically pinning in the GGTT from inside
the kernel context being used to flush the GGTT in emergencies, we will
likely need to lift the next-cacheline allocation to a pre-reservation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200203094152.4150550-3-chris@chris-wilson.co.uk
Inside the intel_timeline_get_seqno(), we currently track the retirement
of the old cachelines by listening to the new request. This requires
that the new request is ready to be used and so requires a minimum bit
of initialisation prior to getting the new seqno.
Fixes: b1e3177bd1 ("drm/i915: Coordinate i915_active with its own mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200203094152.4150550-2-chris@chris-wilson.co.uk
Take a reference to the previous exclusive fence on the i915_active, as
we wish to add an await to it in the caller (and so must prevent it from
being freed until we have completed that task).
Fixes: e3793468b4 ("drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200203094152.4150550-1-chris@chris-wilson.co.uk
