Chris Wilson [Wed, 22 Jan 2020 14:02:43 +0000 (14:02 +0000)]
drm/i915: Mark the removal of the i915_request from the sched.link
Keep the rq->fence.flags consistent with the status of the
rq->sched.link, and clear the associated bits when decoupling the link
on retirement (as we may wish to inspect those flags independent of
other state).
Chris Wilson [Wed, 22 Jan 2020 14:02:42 +0000 (14:02 +0000)]
drm/i915/execlists: Reclaim the hanging virtual request
If we encounter a hang on a virtual engine, as we process the hang the
request may already have been moved back to the virtual engine (we are
processing the hang on the physical engine). We need to reclaim the
request from the virtual engine so that the locking is consistent and
local to the real engine on which we will hold the request for error
state capturing.
v2: Pull the reclamation into execlists_hold() and assert that cannot be
called from outside of the reset (i.e. with the tasklet disabled).
v3: Added selftest
v4: Drop the reference owned by the virtual engine
Chris Wilson [Wed, 22 Jan 2020 14:02:41 +0000 (14:02 +0000)]
drm/i915/execlists: Take a reference while capturing the guilty request
Thanks to preempt-to-busy, we leave the request on the HW as we submit
the preemption request. This means that the request may complete at any
moment as we process HW events, and in particular the request may be
retired as we are planning to capture it for a preemption timeout.
Be more careful while obtaining the request to capture after a
preemption timeout, and check to see if it completed before we were able
to put it on the on-hold list. If we do see it did complete just before
we capture the request, proclaim the preemption-timeout a false positive
and pardon the reset as we should hit an arbitration point momentarily
and so be able to process the preemption.
Note that even after we move the request to be on hold it may be retired
(as the reset to stop the HW comes after), so we do require to hold our
own reference as we work on the request for capture (and all of the
peeking at state within the request needs to be carefully protected).
Chris Wilson [Thu, 16 Jan 2020 18:47:54 +0000 (18:47 +0000)]
drm/i915/execlists: Offline error capture
Currently, we skip error capture upon forced preemption. We apply forced
preemption when there is a higher priority request that should be
running but is being blocked, and we skip inline error capture so that
the preemption request is not further delayed by a user controlled
capture -- extending the denial of service.
However, preemption reset is also used for heartbeats and regular GPU
hangs. By skipping the error capture, we remove the ability to debug GPU
hangs.
In order to capture the error without delaying the preemption request
further, we can do an out-of-line capture by removing the guilty request
from the execution queue and scheduling a worker to dump that request.
When removing a request, we need to remove the entire context and all
descendants from the execution queue, so that they do not jump past.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/738 Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-3-chris@chris-wilson.co.uk
(cherry picked from commit 748317386afb235e11616098d2c7772e49776b58) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Thu, 16 Jan 2020 18:47:53 +0000 (18:47 +0000)]
drm/i915/gt: Allow temporary suspension of inflight requests
In order to support out-of-line error capture, we need to remove the
active request from HW and put it to one side while a worker compresses
and stores all the details associated with that request. (As that
compression may take an arbitrary user-controlled amount of time, we
want to let the engine continue running on other workloads while the
hanging request is dumped.) Not only do we need to remove the active
request, but we also have to remove its context and all requests that
were dependent on it (both in flight, queued and future submission).
Finally once the capture is complete, we need to be able to resubmit the
request and its dependents and allow them to execute.
v2: Replace stack recursion with a simple list.
v3: Check all the parents, not just the first, when searching for a
stuck ancestor!
Chris Wilson [Thu, 16 Jan 2020 18:47:52 +0000 (18:47 +0000)]
drm/i915: Keep track of request among the scheduling lists
If we keep track of when the i915_request.sched.link is on the HW
runlist, or in the priority queue we can simplify our interactions with
the request (such as during rescheduling). This also simplifies the next
patch where we introduce a new in-between list, for requests that are
ready but neither on the run list or in the queue.
v2: Update i915_sched_node.link explanation for current usage where it
is a link on both the queue and on the runlists.
Only the first and the last nodes were being added to
ref->preallocated_barriers.
Renaming variables to make it more easy to read.
Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200129232345.84512-1-jose.souza@intel.com
(cherry picked from commit d4c3c0b8221a72107eaf35c80c40716b81ca463e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 27 Jan 2020 15:28:29 +0000 (15:28 +0000)]
drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
Similar to commit ac0e331a628b ("drm/i915: Tighten atomicity of
i915_active_acquire vs i915_active_release") we have the same race of
trying to pin the context underneath a mutex while allowing the
decrement to be atomic outside of that mutex. This leads to the problem
where two threads may simultaneously try to pin the context and the
second not notice that they needed to repin the context.
Chris Wilson [Sun, 26 Jan 2020 10:23:43 +0000 (10:23 +0000)]
drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release
As we use a mutex to serialise the first acquire (as it may be a lengthy
operation), but only an atomic decrement for the release, we have to
be careful in case a second thread races and completes both
acquire/release as the first finishes its acquire.
So thread A has acquired the ref->active_count but since the ref was
still active at the time, it did not initialise it. By switching the
check inside the mutex to an atomic increment only if already active, we
close the race.
Chris Wilson [Thu, 23 Jan 2020 22:44:58 +0000 (22:44 +0000)]
drm/i915: Check activity on i915_vma after confirming pin_count==0
Only assert that the i915_vma is now idle if and only if no other pins
are present. If another user has the i915_vma pinned, they may submit
more work to the i915_vma skipping the vm->mutex used to serialise the
unbind. We need to wait again, if we want to continue and unbind this
vma.
However, if we own the i915_vma (we hold the vm->mutex for the unbind
and the pin_count is 0), we can assert that the vma remains idle as we
unbind.
Chris Wilson [Mon, 20 Jan 2020 10:49:22 +0000 (10:49 +0000)]
drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list
Currently we create a new mmap_offset for every call to
mmap_offset_ioctl. This exposes ourselves to an abusive client that may
simply create new mmap_offsets ad infinitum, which will exhaust physical
memory and the virtual address space. In addition to the exhaustion, a
very long linear list of mmap_offsets causes other clients using the
object to incur long list walks -- these long lists can also be
generated by simply having many clients generate their own mmap_offset.
However, we can simply use the drm_vma_node itself to manage the file
association (allow/revoke) dropping our need to keep an mmo per-file.
Then if we keep a small rbtree of per-type mmap_offsets, we can lookup
duplicate requests quickly.
Chris Wilson [Wed, 15 Jan 2020 17:58:29 +0000 (17:58 +0000)]
drm/i915/execlists: Leave resetting ring to intel_ring
We need to allow concurrent intel_context_unpin, which means avoiding
doing destructive operations like intel_ring_reset(). This was already
fixed for intel_ring_unpin() in commit 0725d9a31869 ("drm/i915/gt: Make
intel_ring_unpin() safe for concurrent pint"), but I overlooked that
execlists_context_unpin() also made the same mistake.
Reported-by: Matthew Brost <matthew.brost@intel.com> Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin")
References: 0725d9a31869 ("drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@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/20200115175829.2761329-1-chris@chris-wilson.co.uk
(cherry picked from commit f3c0efc9fe7a4e61544034f525348a3aa86ac5aa) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Fri, 10 Jan 2020 18:32:23 +0000 (20:32 +0200)]
drm/i915: Make a copy of the ggtt view for slave plane
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
it is present. We copy that from the master plane to the slave plane,
but we fail to copy the corresponding ggtt view. Thus when it comes time
to pin the slave plane's fb we use some stale ggtt view left over from
the last time the plane was used as a non-slave plane. If that previous
use involved 90/270 degree rotation or remapping we'll try to shuffle
the pages of the new fb around accordingingly. However the new
fb may be backed by a bo with less pages than what the ggtt view
rotation/remapped info requires, and so we we trip a GEM_BUG().
Steps to reproduce on icl:
1. plane 1: whatever
plane 6: largish !NV12 fb + 90 degree rotation
2. plane 1: smallish NV12 fb
plane 6: make invisible so it gets slaved to plane 1
3. GEM_BUG()
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/951 Fixes: 1f594b209fe1 ("drm/i915: Remove special case slave handling during hw programming, v3.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 103605e0d1e77cfb5d0f5a9e8aba7d97f1b49339) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 13 Jan 2020 15:45:55 +0000 (15:45 +0000)]
drm/i915/gem: Take local vma references for the parser
Take and hold a reference to each of the vma (and their objects) as we
process them with the cmdparser. This stops them being freed during the
work if the GEM execbuf is interrupted and the request we expected to
keep the objects alive is incomplete.
Chris Wilson [Tue, 14 Jan 2020 10:56:47 +0000 (10:56 +0000)]
drm/i915/pmu: Correct the rc6 offset upon enabling
The rc6 residency starts ticking from 0 from BIOS POST, but the kernel
starts measuring the time from its boot. If we start measuruing
I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from
0 and then upon first activity (park/unpark) add in all the rc6
residency since boot. After the first park with the sampler engaged, the
sleep/active counters are aligned.
Igor Druzhinin [Wed, 22 Jan 2020 20:10:24 +0000 (20:10 +0000)]
drm/i915/gvt: fix high-order allocation failure on late load
If the module happens to be loaded later at runtime there is a chance
memory is already fragmented enough to fail allocation of firmware
blob storage and consequently GVT init. Since it doesn't seem to be
necessary to have the blob contiguous, use vmalloc() instead to avoid
the issue.
Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
capture"), function 'i915_error_state_store' was defined and used with
only one parameter.
But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
with two parameter.
Vivek Kasireddy [Sat, 18 Jan 2020 00:58:48 +0000 (16:58 -0800)]
drm/i915/dsi: Ensure that the ACPI adapter lookup overrides the bus num
Remove the i2c_bus_num >= 0 check from the adapter lookup function
as this would prevent ACPI bus number override. This check was mainly
there to return early if the bus number has already been found but we
anyway return in the next line if the slave address does not match.
Fixes: 8cbf89db2941 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200118005848.20382-1-vivek.kasireddy@intel.com
(cherry picked from commit de409661c4c90d63cfc64579edbad0a6b10bd50d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Wed, 15 Jan 2020 19:08:09 +0000 (21:08 +0200)]
drm/i915: Fix post-fastset modeset check for port sync
The post-fastset "does anyone still need a full modeset?" for
port sync looks busted. The outer loop bails out of a full modeset
is still needed by the current crtc, and then we skip forcing
a full modeset on the related crtcs. That's totally the opposite
of what we want.
The MST path has the logic mostly the other way around so it
looks correct. To fix the port sync case let's follow the MST
logic for both. So, if the current crtc already needs a modeset
we do nothing. otherwise we check if any of the related crtcs
needs a modeset, and if so we force a full modeset for the
current crtc.
And while at let's change the else if to a plain if to so
we don't have needless coupling between the MST and port sync
checks.
Vivek Kasireddy [Wed, 15 Jan 2020 01:23:05 +0000 (17:23 -0800)]
drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y (v2)
Perform the i2c bus/adapter lookup from ACPI Namespace only if ACPI is
enabled in the kernel config. If ACPI is not enabled or if the lookup
fails, we'll fallback to using the VBT for identifying the i2c bus.
v2: Add fixes tag (Jani)
Fixes: 8cbf89db2941 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115012305.27395-1-vivek.kasireddy@intel.com
(cherry picked from commit 960287ca58fd549af9826ff1cb735fe17d031486) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Dave Airlie [Fri, 7 Feb 2020 02:29:35 +0000 (12:29 +1000)]
Merge tag 'amd-drm-next-5.6-2020-02-05' of git://people.freedesktop.org/~agd5f/linux into drm-next
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
Thierry Reding [Tue, 4 Feb 2020 13:59:25 +0000 (14:59 +0100)]
drm/tegra: Reuse IOVA mapping where possible
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).
Thierry Reding [Tue, 4 Feb 2020 13:59:24 +0000 (14:59 +0100)]
drm/tegra: Relax IOMMU usage criteria on old Tegra
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.
Lyude Paul [Fri, 24 Jan 2020 19:10:46 +0000 (14:10 -0500)]
drm/amd/dm/mst: Ignore payload update failures
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:
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 [Tue, 4 Feb 2020 14:07:19 +0000 (09:07 -0500)]
drm/amdgpu: update default voltage for boot od table for navi1x
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>
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>
Alex Deucher [Tue, 28 Jan 2020 19:39:45 +0000 (14:39 -0500)]
drm/amdgpu/display: handle multiple numbers of fclks in dcn_calcs.c (v2)
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>
Yong Zhao [Thu, 30 Jan 2020 00:55:47 +0000 (19:55 -0500)]
drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS mode
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>
drm/amd/display: Only enable cursor on pipes that need it
[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>
Ben Skeggs [Mon, 3 Feb 2020 08:37:07 +0000 (03:37 -0500)]
drm/nouveau/kms/gv100-: avoid sending a core update until the first modeset
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.
Ben Skeggs [Mon, 3 Feb 2020 08:36:30 +0000 (03:36 -0500)]
drm/nouveau/kms/gv100-: move window ownership setup into modesetting path
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.
Thierry Reding [Fri, 31 Jan 2020 16:59:10 +0000 (17:59 +0100)]
drm/tegra: sor: Initialize runtime PM before use
Commit fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM") replaced
the generic runtime PM usage by a host1x bus-specific implementation in
order to work around some assumptions baked into runtime PM that are in
conflict with the requirements in the Tegra DRM driver.
Unfortunately the new runtime PM callbacks are not setup yet at the time
when the SOR driver first needs to resume the device to register the SOR
pad clock, and accesses to register will cause the system to hang.
Note that this only happens on Tegra124 and Tegra210 because those are
the only SoCs where the SOR pad clock is registered from the SOR driver.
Later generations use a SOR pad clock provided by the BPMP.
Fix this by moving the registration of the SOR pad clock after the
host1x client has been registered. That's somewhat suboptimal because
this could potentially, though it's very unlikely, cause the Tegra DRM
to be probed if the SOR happens to be the last subdevice to register,
only to be immediately removed again if the SOR pad output clock fails
to register. That's just a minor annoyance, though, and doesn't justify
implementing a workaround.
Fixes: fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM") Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/amdgpu: Fix implicit enum conversion in gfx_v9_4_ras_error_inject
Clang warns:
../drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c:967:35: warning: implicit
conversion from enumeration type 'enum amdgpu_ras_block' to different
enumeration type 'enum ta_ras_block' [-Wenum-conversion]
block_info.block_id = info->head.block;
~ ~~~~~~~~~~~^~~~~
1 warning generated.
Use the function added in commit 828cfa29093f ("drm/amdgpu: Fix amdgpu
ras to ta enums conversion") that handles this conversion explicitly.
Fixes: 4c461d89db4f ("drm/amdgpu: add RAS support for the gfx block of Arcturus") Link: https://github.com/ClangBuiltLinux/linux/issues/849 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm: radeon: remove dead code and pointless local lut storage
v2: Also remove leftover local variable.
Cc: Peter Rosin <peda@axentia.se> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Zhan Liu [Tue, 28 Jan 2020 21:38:53 +0000 (16:38 -0500)]
drm/amd/display: Move drm_dp_mst_atomic_check() to the front of dc_validate_global_state()
[Why]
Need to do atomic check first, then validate global state.
If not, when connecting both MST and HDMI displays and
set a bad mode via xrandr, system will hang.
[How]
Move drm_dp_mst_atomic_check() to the front of
dc_validate_global_state().
Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Mikita Lipski <mikita.lipski@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
which for radeon had the side-effect of refactoring out a seemingly
redudant writing of the color palette.
10ms in a fairly slow modeset path feels like an acceptable form of
duct-tape, so maybe worth a shot and see what sticks.
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=198123 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Nirmoy Das [Tue, 21 Jan 2020 14:53:53 +0000 (15:53 +0100)]
drm/amdgpu: allocate entities on demand
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
v2: allocate memory for entity and fences together
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amdgpu: Enable DISABLE_BARRIER_WAITCNT for Arcturus
In previous gfx9 parts, S_BARRIER shader instructions are implicitly
S_WAITCNT 0 instructions as well. This setting turns off that
mechanism in Arcturus and beyond. With this, shaders must follow the
ISA guide insofar as putting in explicit S_WAITCNT operations even
after an S_BARRIER.
v2: Fix patch title to list component
Signed-off-by: Joseph Greathouse <Joseph.Greathouse@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Thu, 30 Jan 2020 05:18:33 +0000 (15:18 +1000)]
Merge branch 'linux-5.6' of git://github.com/skeggsb/linux into drm-next
A couple of OOPS fixes, fixes for TU1xx if firmware isn't available,
better behaviour in the face of GPU faults, and a patch to make HD
audio work again after runpm changes.
Ben Skeggs [Wed, 29 Jan 2020 01:29:05 +0000 (11:29 +1000)]
drm/nouveau/fb/gp102-: allow module to load even when scrubber binary is missing
Without relaxing this requirement, TU10x boards will fail to load without
an updated linux-firmware, and TU11x will completely fail to load because
FW isn't available yet.
Ben Skeggs [Tue, 28 Jan 2020 04:39:26 +0000 (14:39 +1000)]
drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
The implementations for most channel types contains a map of methods to
priv registers in order to provide debugging info when a disp exception
has been raised.
This info is missing from the implementation of PIO channels as they're
rather simplistic already, however, if an exception is raised by one of
them, we'd end up triggering a NULL-pointer deref. Not ideal...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Takashi Iwai [Mon, 13 Jan 2020 14:17:21 +0000 (15:17 +0100)]
drm/nouveau: Add HD-audio component notifier support
This patch adds the support for the notification of HD-audio hotplug
via the already existing drm_audio_component framework. This allows
us more reliable hotplug notification and ELD transfer without
accessing HD-audio bus; it's more efficient, and more importantly, it
works without waking up the runtime PM.
The implementation is rather simplistic: nouveau driver provides the
get_eld ops for HD-audio, and it notifies the audio hotplug via
pin_eld_notify callback upon each nv50_audio_enable() and _disable()
call. As the HD-audio pin assignment seems corresponding to the CRTC,
the crtc->index number is passed directly as the zero-based port
number.
The bind and unbind callbacks handle the device-link so that it
assures the PM call order.
Colin Ian King [Fri, 17 Jan 2020 13:33:05 +0000 (13:33 +0000)]
drm/amd/display: fix for-loop with incorrectly sized loop counter (v2)
A for-loop is iterating from 0 up to 1000 however the loop variable count
is a u8 and hence not large enough. Fix this by making count an int.
Also remove the redundant initialization of count since this is never used
and add { } on the loop statement make the loop block clearer.
v2: drop useless else (Walter Harms)
Addresses-Coverity: ("Operands don't affect result") Fixes: ed581a0ace44 ("drm/amd/display: wait for update when setting dpg test pattern") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dor Askayo [Sat, 4 Jan 2020 12:22:15 +0000 (14:22 +0200)]
drm/amd/display: do not allocate display_mode_lib unnecessarily
This allocation isn't required and can fail when resuming from suspend.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009 Signed-off-by: Dor Askayo <dor.askayo@gmail.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Thu, 16 Jan 2020 13:06:59 +0000 (14:06 +0100)]
drm/amdgpu: add coreboot workaround for KV/KB
Coreboot seems to have a problem correctly setting up access to the stolen VRAM
on KV/KB. Use the direct access only when necessary.
Signed-off-by: Christian König <christian.koenig@amd.com> Reported-and-tested-by: Fredrik Bruhn <fredrik.bruhn@unibap.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
This change was working around a regression that occured in this:
commit 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure")
With the fix to run verify_link_cap when the SINK_COUNT of
dongles becomes non-zero this change is no longer needed.
Cc: Louis Li <Ching-shih.Li@amd.com> Cc: Wenjing Liu <Wenjing.Liu@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Harry Wentland [Tue, 21 Jan 2020 21:12:45 +0000 (16:12 -0500)]
drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zero
[WHY]
Two years ago the patch referenced by the Fixes tag stopped running
dp_verify_link_cap_with_retries during DP detection when the reason
for the detection was a short-pulse interrupt. This effectively meant
that we were no longer doing the verify_link_cap training on active
dongles when their SINK_COUNT changed from 0 to 1.
A year ago this was partly remedied with:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")
This made sure that we trained the dongle on initial hotplug (without
connected downstream devices).
This is all fine and dandy if it weren't for the fact that there are
some dongles on the market that don't like link training when SINK_COUNT
is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately
after hotplug, even when a downstream device is connected, and then
trigger a shortpulse interrupt indicating a SINK_COUNT change to 1.
In order to play nicely we will need our policy to not link train an
active DP dongle when SINK_COUNT is 0 but ensure we train it when the
SINK_COUNT changes to 1.
[HOW]
Call dp_verify_link_cap_with_retries on detection even when the detection
is triggered from a short pulse interrupt.
With this change we can also revert this commit which we'll do in a separate
follow-up change:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")
Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure") Suggested-by: Louis Li <Ching-shih.Li@amd.com> Tested-by: Louis Li <Ching-shih.Li@amd.com> Cc: Wenjing Liu <Wenjing.Liu@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
zhengbin [Wed, 22 Jan 2020 07:53:11 +0000 (15:53 +0800)]
drm/amd/powerplay: use true, false for bool variable in smu7_hwmgr.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:723:2-50: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:733:3-52: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:747:3-51: WARNING: Assignment of 0/1 to bool variable
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Nirmoy Das [Wed, 22 Jan 2020 09:37:56 +0000 (10:37 +0100)]
drm/amdgpu: fix doc by clarifying sched_list definition
expand sched_list definition for better understanding.
Also fix a typo atleast -> at least
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Felix Kuehling [Sat, 18 Jan 2020 01:08:42 +0000 (20:08 -0500)]
drm/amdgpu: Use the correct flush_type in flush_gpu_tlb_pasid
The flush_type was incorrectly hard-coded to 0 when calling falling back
to MMIO-based invalidation in flush_gpu_tlb_pasid.
Fixes: ea930000a6dc ("drm/amdgpu: export function to flush TLB via pasid") Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Oak Zeng <Oak.Zeng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Felix Kuehling [Sat, 18 Jan 2020 00:54:45 +0000 (19:54 -0500)]
drm/amdgpu: Fix TLB invalidation request when using semaphore
Use a more meaningful variable name for the invalidation request
that is distinct from the tmp variable that gets overwritten when
acquiring the invalidation semaphore.
Fixes: 4ed8a03740d0 ("drm/amdgpu: invalidate mmhub semaphore workaround in gmc9/gmc10") Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Yong Zhao <Yong.Zhao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Wed, 22 Jan 2020 23:32:54 +0000 (09:32 +1000)]
Merge tag 'exynos-drm-next-for-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Change Exynos DRM specific callback function names
- it changes enable and disable callback functions names of
struct exynos_drm_crtc_ops to atomic_enable and atomic_disable
for consistency.
Modify "EXYNOS" prefix to "Exynos"
- "Exynos" name is a regular trademarked name promoted by its
manufacturer, Samsung Electronics Co., Ltd.. This patch
corrects the name.
Chen Zhou [Thu, 16 Jan 2020 12:50:10 +0000 (20:50 +0800)]
drm/nouveau: fix build error without CONFIG_IOMMU_API
If CONFIG_IOMMU_API is n, build fails:
vers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:9: error: implicit declaration of function dev_iommu_fwspec_get; did you mean iommu_fwspec_free? [-Werror=implicit-function-declaration]
spec = dev_iommu_fwspec_get(device->dev);
^~~~~~~~~~~~~~~~~~~~
iommu_fwspec_free
drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
spec = dev_iommu_fwspec_get(device->dev);
^
drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:39:17: error: struct iommu_fwspec has no member named ids
u32 sid = spec->ids[0] & 0xffff;
Seletc IOMMU_API under config DRM_NOUVEAU to fix this.
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
projects / linux.git / log