Sandeep Raghuraman [Wed, 10 Jun 2020 20:06:26 +0000 (01:36 +0530)]
drm/amdgpu: Replace invalid device ID with a valid device ID
Initializes Powertune data for a specific Hawaii card by fixing what
looks like a typo in the code. The device ID 66B1 is not a supported
device ID for this driver, and is not mentioned elsewhere. 67B1 is a
valid device ID, and is a Hawaii Pro GPU.
I have tested on my R9 390 which has device ID 67B1, and it works
fine without problems.
Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Denis Efremov [Fri, 5 Jun 2020 17:37:44 +0000 (20:37 +0300)]
drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp()
Use kfree() instead of kvfree() to free rgb_user in
calculate_user_regamma_ramp() because the memory is allocated with
kcalloc().
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Denis Efremov [Fri, 5 Jun 2020 17:37:43 +0000 (20:37 +0300)]
drm/amd/display: Use kvfree() to free coeff in build_regamma()
Use kvfree() instead of kfree() to free coeff in build_regamma()
because the memory is allocated with kvzalloc().
Fixes:
e752058b8671 ("drm/amd/display: Optimize gamma calculations")
Cc: stable@vger.kernel.org
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Mon, 8 Jun 2020 01:59:56 +0000 (11:59 +1000)]
Merge tag 'drm-intel-next-fixes-2020-06-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Includes gvt-next-fixes-2020-05-28
- Use after free fix for display global state.
- Whitelisting context-local timestamp on Gen9
and two scheduler fixes with deps (Cc: stable)
- Removal of write flag from sysfs files where
ineffective
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200604150454.GA59322@jlahtine-desk.ger.corp.intel.com
Dave Airlie [Mon, 8 Jun 2020 01:55:33 +0000 (11:55 +1000)]
Merge tag 'amd-drm-fixes-5.8-2020-06-04' of git://people.freedesktop.org/~agd5f/linux into drm-next
amd-drm-fixes-5.8-2020-06-04
amdgpu:
- Prevent hwmon accesses while GPU is in reset
- CTF interrupt fix
- Backlight fix for renoir
- Fix for display sync groups
- Display bandwidth validation workaround
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200604181900.4609-1-alexander.deucher@amd.com
Dave Airlie [Mon, 8 Jun 2020 00:06:09 +0000 (10:06 +1000)]
Merge branch 'linux-5.8' of git://github.com/skeggsb/linux into drm-next
- HDMI/DP audio HDA fixes
- display hang fix for Volta/Turing
- GK20A regression fix.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <skeggsb@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/
Ben Skeggs [Thu, 4 Jun 2020 01:00:01 +0000 (11:00 +1000)]
drm/nouveau/kms/nv50-: clear SW state of disabled windows harder
The most innocuous result of not having done this is that we end up
sending unnecessary methods when we next enable the window.
However, interactions with the code handling skipping disables when
an update immediately follows, and window ownership assignment, can
lead to upsetting the display hardware on Volta and newer.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thierry Reding [Wed, 3 Jun 2020 14:20:02 +0000 (16:20 +0200)]
drm/nouveau: gr/gk20a: Use firmware version 0
Tegra firmware doesn't actually use any version numbers and passing -1
causes the existing firmware binaries not to be found. Use version 0 to
find the correct files.
Fixes:
ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation based on available FW")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 3 Jun 2020 02:51:03 +0000 (12:51 +1000)]
drm/nouveau/disp/gm200-: detect and potentially disable HDA support on some SORs
Some HDA pin widgets may be disabled by BIOS, and unavailable from a
SOR. Our SOR allocation policy uses this information to allocate an
appropriate SOR when HDA is supported by a display.
Thank you to NVIDIA for providing the information to determine this.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Thu, 4 Jun 2020 04:22:32 +0000 (14:22 +1000)]
drm/nouveau/disp/gp100: split SOR implementation from gm200
GP100 needs different HDA detection.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 3 Jun 2020 01:43:23 +0000 (11:43 +1000)]
drm/nouveau/disp: modify OR allocation policy to account for HDA requirements
Since GM200, SORs are no longer tied to a specific connector, and we
allocate them instead, with the assumption that all SORs are equally
capable.
However, there's a 1<->1 mapping between SOR and HDA pin widget, and
it turns out that it's possible for some widgets to be disabled...
In order to avoid picking a SOR without a valid pin widget, some new
rules need to be added.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 3 Jun 2020 01:40:47 +0000 (11:40 +1000)]
drm/nouveau/disp: split part of OR allocation logic into a function
No logical changes here, this is just moving the code to make the
changes in the next commit more obvious.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 3 Jun 2020 01:37:56 +0000 (11:37 +1000)]
drm/nouveau/disp: provide hint to OR allocation about HDA requirements
Will be used by a subsequent commit to influence SOR allocation policy.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Nicholas Kazlauskas [Wed, 3 Jun 2020 00:42:33 +0000 (20:42 -0400)]
drm/amd/display: Revalidate bandwidth before commiting DC updates
[Why]
Whenever we switch between tiled formats without also switching pixel
formats or doing anything else that recreates the DC plane state we
can run into underflow or hangs since we're not updating the
DML parameters before committing to the hardware.
[How]
If the update type is FULL then call validate_bandwidth again to update
the DML parmeters before committing the state.
This is basically just a workaround and protective measure against
update types being added DC where we could run into this issue in
the future.
We can only fully validate the state in advance before applying it to
the hardware if we recreate all the plane and stream states since
we can't modify what's currently in use.
The next step is to update DM to ensure that we're creating the plane
and stream states for whatever could potentially be a full update in
DC to pre-emptively recreate the state for DC global validation.
The workaround can stay until this has been fixed in DM.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 2 Jun 2020 21:22:48 +0000 (17:22 -0400)]
drm/amdgpu/display: use blanked rather than plane state for sync groups
We may end up with no planes set yet, depending on the ordering, but we
should have the proper blanking state which is either handled by either
DPG or TG depending on the hardware generation. Check both to determine
the proper blanked state.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/781
Fixes:
5fc0cbfad45648 ("drm/amd/display: determine if a pipe is synced by plane state")
Cc: nicholas.kazlauskas@amd.com
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Joonas Lahtinen [Tue, 2 Jun 2020 13:45:05 +0000 (16:45 +0300)]
Merge tag 'gvt-next-fixes-2020-05-28' of https://github.com/intel/gvt-linux into drm-intel-next-fixes
gvt-next-fixes-2020-05-28
- Fix one clang warning on debug only function (Nathan)
- Use ARRAY_SIZE for coccicheck warn (Aishwarya)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200528033559.GG23961@zhen-hp.sh.intel.com
Jani Nikula [Mon, 1 Jun 2020 21:55:09 +0000 (00:55 +0300)]
drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions
fake_lmem_start does not need to be mutable via module param sysfs. It's
only used during driver probe.
Fixes:
1629224324b6 ("drm/i915/lmem: add the fake lmem region")
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200601215510.18379-2-jani.nikula@intel.com
(cherry picked from commit
f322e851f20e534cf5305332a9ad5eefadb55d56)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Jani Nikula [Mon, 1 Jun 2020 21:55:08 +0000 (00:55 +0300)]
drm/i915/params: don't expose inject_probe_failure in debugfs
The parameter only makes sense as a module parameter only.
Fixes:
c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs")
Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200601215510.18379-1-jani.nikula@intel.com
(cherry picked from commit
dbf4081ffb68c0d9b518a34c715a8d8681658411)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Mon, 1 Jun 2020 16:19:42 +0000 (17:19 +0100)]
drm/i915: Whitelist context-local timestamp in the gen9 cmdparser
Allow batch buffers to read their own _local_ cumulative HW runtime of
their logical context.
Fixes:
0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200601161942.30854-1-chris@chris-wilson.co.uk
(cherry picked from commit
f9496520df11de00fbafc3cbd693b9570d600ab3)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Ville Syrjälä [Wed, 27 May 2020 20:02:45 +0000 (23:02 +0300)]
drm/i915: Fix global state use-after-frees with a refcount
While the current locking/serialization of the global state
suffices for protecting the obj->state access and the actual
hardware reprogramming, we do have a problem with accessing
the old/new states during nonblocking commits.
The state computation and swap will be protected by the crtc
locks, but the commit_tails can finish out of order, thus also
causing the atomic states to be cleaned up out of order. This
would mean the commit that started first but finished last has
had its new state freed as the no-longer-needed old state by the
other commit.
To fix this let's just refcount the states. obj->state amounts
to one reference, and the intel_atomic_state holds extra references
to both its new and old global obj states.
Fixes:
0ef1905ecf2e ("drm/i915: Introduce better global state handling")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200527200245.13184-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit
f8c86ffa2800adc80adc679c84c45e0c6b027374)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 29 May 2020 14:39:26 +0000 (15:39 +0100)]
drm/i915: Check for awaits on still currently executing requests
With the advent of preempt-to-busy, a request may still be on the GPU as
we unwind. And in the case of a unpreemptible [due to HW] request, that
request will remain indefinitely on the GPU even though we have
returned it back to our submission queue, and cleared the active bit.
We only run the execution callbacks on transferring the request from our
submission queue to the execution queue, but if this is a bonded request
that the HW is waiting for, we will not submit it (as we wait for a
fresh execution) even though it is still being executed.
As we know that there are always preemption points between requests, we
know that only the currently executing request may be still active even
though we have cleared the flag. However, we do not precisely know which
request is in ELSP[0] due to a delay in processing events, and
furthermore we only store the last request in a context in our state
tracker.
Fixes:
22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Testcase: igt/gem_exec_balancer/bonded-dual
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200529143926.3245-1-chris@chris-wilson.co.uk
(cherry picked from commit
b55230e5e800868961fc271b26d9ce53ae1f691e)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Tue, 26 May 2020 09:07:53 +0000 (10:07 +0100)]
drm/i915/gt: Do not schedule normal requests immediately along virtual
When we push a virtual request onto the HW, we update the rq->engine to
point to the physical engine. A request that is then submitted by the
user that waits upon the virtual engine, but along the physical engine
in use, will then see that it is due to be submitted to the same engine
and take a shortcut (and be queued without waiting for the completion
fence). However, the virtual request may be preempted (either by higher
priority users, or by timeslicing) and removed from the physical engine
to be migrated over to one of its siblings. The dependent normal request
however is oblivious to the removal of the virtual request and remains
queued to execute on HW, believing that once it reaches the head of its
queue all of its predecessors will have completed executing!
v2: Beware restriction of signal->execution_mask prior to submission.
Fixes:
6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Testcase: igt/gem_exec_balancer/sliced
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v5.3+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200526090753.11329-2-chris@chris-wilson.co.uk
(cherry picked from commit
511b6d9aed417739b6aa49d0b6b4354ad21020f1)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Tue, 26 May 2020 09:07:52 +0000 (10:07 +0100)]
drm/i915: Reorder await_execution before await_request
Reorder the code so that we can reuse the await_execution from a special
case in await_request in the next patch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200526090753.11329-1-chris@chris-wilson.co.uk
(cherry picked from commit
ffb0c600c240103f6f34e07892a7e0a75502b243)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Ben Skeggs [Fri, 29 May 2020 07:57:29 +0000 (17:57 +1000)]
drm/nouveau/kms/gt215-: fix race with audio driver runpm
The audio driver can call into nouveau right while we're in the middle
of re-fetching the EDID, and decide it no longer needs to be awake.
Stop depending on EDID in the audio component get_eld() callback, and
instead cache whether audio support is present from the prior modeset.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Fri, 29 May 2020 05:18:47 +0000 (15:18 +1000)]
drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection
This is a SOR register, and not indexed by the bound head.
Fixes display not coming up on high-bandwidth HDMI displays under a
number of configurations.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Harry Wentland [Thu, 28 May 2020 13:44:44 +0000 (09:44 -0400)]
Revert "drm/amd/display: disable dcn20 abm feature for bring up"
This reverts commit
96cb7cf13d8530099c256c053648ad576588c387.
This change was used for DCN2 bringup and is no longer desired.
In fact it breaks backlight on DCN2 systems.
Cc: Alexander Monakov <amonakov@ispras.ru>
Cc: Hersen Wu <hersenxs.wu@amd.com>
Cc: Anthony Koo <Anthony.Koo@amd.com>
Cc: Michael Chiu <Michael.Chiu@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reported-and-tested-by: Alexander Monakov <amonakov@ispras.ru>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Evan Quan [Tue, 12 May 2020 11:06:37 +0000 (19:06 +0800)]
drm/amd/powerplay: ack the SMUToHost interrupt on receive V2
There will be no further interrupt without proper ack
for current one.
V2: fix typo to really set ACK bit only
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Sun, 24 May 2020 06:46:53 +0000 (02:46 -0400)]
drm/amdgpu/pm: return an error during GPU reset or suspend (v2)
Return an error for sysfs and debugfs power interfaces during
gpu reset and suspend. Prevents access to the hw while it may
be in an unusable state.
v2: squash in fix to drop suspend check
Acked-by: Nirmoy Das <nirmoy.das@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Thu, 28 May 2020 06:10:16 +0000 (16:10 +1000)]
Merge tag 'amd-drm-next-5.8-2020-05-27' of git://people.freedesktop.org/~agd5f/linux into drm-next
amd-drm-next-5.8-2020-05-27:
amdgpu:
- SRIOV fixes
- RAS fixes
- VCN 2.5 DPG (Dynamic PowerGating) fixes
- FP16 updates for display
- CTF cleanups
- Display fixes
- Fix pcie bw sysfs handling
- Enable resizeable BAR support for gmc 10.x
- GFXOFF fixes for Raven
- PM sysfs handling fixes
amdkfd:
- Fix a race condition
- Warning fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200527231219.3930-1-alexander.deucher@amd.com
Dave Airlie [Thu, 28 May 2020 05:38:26 +0000 (15:38 +1000)]
Merge tag 'drm-misc-next-fixes-2020-05-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Short summary of fixes pull (less than what git shortlog provides):
There's a fix for panel brighness on Lenovo X13 Yoga devices and a fix for
-Wformat warnings on architectures where atomic-64 counters are not of
type unsigned long long.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200527080123.GA8186@linux-uq9g
Aric Cyr [Tue, 12 May 2020 15:48:48 +0000 (11:48 -0400)]
drm/amd/display: Fix potential integer wraparound resulting in a hang
[Why]
If VUPDATE_END is before VUPDATE_START the delay calculated can become
very large, causing a soft hang.
[How]
Take the absolute value of the difference between START and END.
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Simon Ser [Sat, 23 May 2020 11:53:41 +0000 (11:53 +0000)]
drm/amd/display: drop cursor position check in atomic test
get_cursor_position already handles the case where the cursor has
negative off-screen coordinates by not setting
dc_cursor_position.enabled.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes:
626bf90fe03f ("drm/amd/display: add basic atomic check for cursor plane")
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Kevin Wang [Fri, 22 May 2020 14:06:17 +0000 (22:06 +0800)]
drm/amdgpu: fix device attribute node create failed with multi gpu
the origin design will use varible of "attr->states" to save node
supported states on current gpu device, but for multi gpu device, when
probe second gpu device, the driver will check attribute node states
from previous gpu device wthether to create attribute node.
it will cause other gpu device create attribute node faild.
1. add member attr_list into amdgpu_device to link supported device attribute node.
2. add new structure "struct amdgpu_device_attr_entry{}" to track device attribute state.
3. drop member "states" from amdgpu_device_attr.
v2:
1. move "attr_list" into amdgpu_pm and rename to "pm_attr_list".
2. refine create & remove device node functions parameter.
fix:
drm/amdgpu: optimize amdgpu device attribute code
Signed-off-by: Kevin Wang <kevin1.wang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Tue, 26 May 2020 04:18:27 +0000 (14:18 +1000)]
drm/nouveau: use correct conflicting framebuffer API
nouveau was calling the fbdev API which has issues with modules
and built-ins. Call the correct API.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Fixes:
2dd4d163cd9c ("drm/nouveau: remove open-coded version of remove_conflicting_pci_framebuffers()")
Link: https://lore.kernel.org/lkml/21b52c28-3ace-cd13-d8ce-f38f2c6b2a96@infradead.org/T/#u
Signed-off-by: Dave Airlie <airlied@redhat.com>
Chris Wilson [Fri, 22 May 2020 13:27:06 +0000 (14:27 +0100)]
drm/i915/gem: Avoid iterating an empty list
Our __sgt_iter assumes that the scattergather list has at least one
element. But during construction we may fail in allocating the first
page, and so mark the first element as the terminator. This is
unexpected!
[22555.524752] RIP: 0010:shmem_get_pages+0x506/0x710 [i915]
[22555.524759] Code: 49 8b 2c 24 31 c0 66 89 44 24 40 48 85 ed 0f 84 62 01 00 00 4c 8b 75 00 8b 5d 08 44 8b 7d 0c 48 8b 0d 7e 34 07 e2 49 83 e6 fc <49> 8b 16 41 01 df 48 89 cf 48 89 d0 48 c1 e8 2d 48 85 c9 0f 84 c8
[22555.524765] RSP: 0018:
ffffc9000053f9d0 EFLAGS:
00010246
[22555.524770] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
ffff8881ffffa000
[22555.524774] RDX:
fffffffffffffff4 RSI:
ffffffffffffffff RDI:
ffffffff821efe00
[22555.524778] RBP:
ffff8881b099ab00 R08:
0000000000000000 R09:
00000000fffffff4
[22555.524782] R10:
0000000000000002 R11:
00000000ffec0a02 R12:
ffff8881cd3c8d60
[22555.524786] R13:
00000000fffffff4 R14:
0000000000000000 R15:
0000000000000000
[22555.524790] FS:
00007f4fbeb9b9c0(0000) GS:
ffff8881f8580000(0000) knlGS:
0000000000000000
[22555.524795] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[22555.524799] CR2:
0000000000000000 CR3:
00000001ec7f0004 CR4:
00000000001606e0
[22555.524803] Call Trace:
[22555.524919] __i915_gem_object_get_pages+0x4f/0x60 [i915]
Fixes:
85d1225ec066 ("drm/i915: Introduce & use new lightweight SGL iterators")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v4.8+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200522132706.5133-1-chris@chris-wilson.co.uk
(cherry picked from commit
957ad9a02be6faa87594c58ac09460cd3d190d0e)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Thu, 21 May 2020 14:06:17 +0000 (15:06 +0100)]
drm/i915: Avoid using rq->engine after free during i915_fence_release
In order to be valid to dereference during the i915_fence_release, after
retiring the fence and releasing its refererences, we assume that
rq->engine can only be a real engine (that stay intact until the device
is shutdown after all fences have been flushed). However, due to a quirk
of preempt-to-busy, we may retire a request that still belongs to a
virtual engine and so eventually free it with rq->engine being invalid.
To avoid dereferencing that invalid engine, we look at the
execution_mask which if it indicates it may be executed on more than one
engine, we know it originated on a virtual engine and may still be on
one.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906
Fixes:
43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200521140617.30015-2-chris@chris-wilson.co.uk
(cherry picked from commit
32a4605b38c30689a6a18f3f4c7d3133ac9d3277)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Thu, 21 May 2020 14:06:16 +0000 (15:06 +0100)]
drm/i915: Disable semaphore inter-engine sync without timeslicing
Since the removal of the no-semaphore boosting, we rely on timeslicing to
reorder passed inter-dependency hogs across the engines. However, we
require preemption to support timeslicing into user payloads, and not all
machine support preemption so we do not universally enable timeslicing,
even when it would correctly preempt our own inter-engine semaphores.
Since timeslicing and semaphore priority deboosting is now disabled on
Broadwell/Braswell, we have to follow suite and not use semaphores.
Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw
Fixes:
18e4af04d218 ("drm/i915: Drop no-semaphore boosting")
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: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200521140617.30015-1-chris@chris-wilson.co.uk
(cherry picked from commit
0eb670aac27b1d615004c29efec595616e3e091a)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Wed, 20 May 2020 07:30:48 +0000 (08:30 +0100)]
drm/i915/gt: Remove errant assertion in __intel_context_do_pin
This assertion was removed in commit
b412c63f1cba ("drm/i915/gt: Report
context-is-closed prior to pinning"), but accidentally restored by a
cherry-pick into drm-next and now has percolated back to
drm-intel-next-queued.
Fixes:
2e46a2a0b014 ("drm/i915: Use explicit flag to mark unreachable intel_context")
Fixes:
2b703bbda271 ("Merge drm/drm-next into drm-intel-next-queued")
References:
b412c63f1cba ("drm/i915/gt: Report context-is-closed prior to pinning")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200520073048.2394034-1-chris@chris-wilson.co.uk
(cherry picked from commit
f2c1061a3677b400a945d9238f17bf33d669acff)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Tue, 19 May 2020 06:31:12 +0000 (07:31 +0100)]
drm/i915: Don't set queue-priority hint when supressing the reschedule
We recorded the execlists->queue_priority_hint update for the inflight
request without kicking the tasklet. The next submitted request then
failed to be scheduled as it had a lower priority than the hint, leaving
the HW running with only the inflight request.
Fixes:
6cebcf746f3f ("drm/i915: Tweak scheduler's kick_submission()")
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/20200519063123.20673-1-chris@chris-wilson.co.uk
(cherry picked from commit
b86fc6e5e89e5645b43f57171c26740ef38f9f4a)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Lyude Paul [Thu, 21 May 2020 20:46:47 +0000 (16:46 -0400)]
drm/vblank: Fix -Wformat compile warnings on some arches
On some architectures like ppc64le and aarch64, compiling with
-Wformat=1 will throw the following warnings:
In file included from drivers/gpu/drm/drm_vblank.c:33:
drivers/gpu/drm/drm_vblank.c: In function 'drm_update_vblank_count':
drivers/gpu/drm/drm_vblank.c:273:16: warning: format '%llu' expects
argument of type 'long long unsigned int', but argument 4 has type
'long int' [-Wformat=]
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/drm/drm_print.h:407:22: note: in definition of macro
'DRM_DEBUG_VBL'
drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
^~~
drivers/gpu/drm/drm_vblank.c:274:22: note: format string is defined here
" current=%llu, diff=%u, hw=%u hw_last=%u\n",
~~~^
%lu
So, fix that with a typecast.
Co-developed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200521204647.2578479-1-lyude@redhat.com
Felix Kuehling [Wed, 20 May 2020 01:02:45 +0000 (21:02 -0400)]
drm/amdgpu: Sync with VM root BO when switching VM to CPU update mode
This fixes an intermittent bug where a root PD clear operation still in
progress could overwrite a PDE update done by the CPU, resulting in a
VM fault.
Fixes:
108b4d928c03 ("drm/amd/amdgpu: Update VM function pointer")
Reported-by: Jay Cornwall <Jay.Cornwall@amd.com>
Tested-by: Jay Cornwall <Jay.Cornwall@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Bhawanpreet Lakha [Mon, 11 May 2020 18:21:17 +0000 (14:21 -0400)]
drm/amd/display: Handle GPU reset for DC block
[Why]
Previously we used the s3 codepath for gpu reset. This can lead to issues in
certain case where we end of waiting for fences which will never come (because
parts of the hw are off due to gpu reset) and we end up waiting forever causing
a deadlock.
[How]
Handle GPU reset separately from normal s3 case. We essentially need to redo
everything we do in s3, but avoid any drm calls.
For GPU reset case
suspend:
-Acquire DC lock
-Cache current dc_state
-Commit 0 stream/planes to dc (this puts dc into a state where it can be
powered off)
-Disable interrupts
resume
-Edit cached state to force full update
-Commit cached state from suspend
-Build stream and plane updates from the cached state
-Commit stream/plane updates
-Enable interrupts
-Release DC lock
v2:
-Formatting
-Release dc_state
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 15 May 2020 18:18:29 +0000 (14:18 -0400)]
drm/amdgpu: add apu flags (v2)
Add some APU flags to simplify handling of different APU
variants. It's easier to understand the special cases
if we use names flags rather than checking device ids and
silicon revisions.
v2: rebase on latest code
Acked-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
chen gong [Thu, 21 May 2020 09:15:34 +0000 (17:15 +0800)]
drm/amd/powerpay: Disable gfxoff when setting manual mode on picasso and raven
[Problem description]
1. Boot up picasso platform, launches desktop, Don't do anything (APU enter into "gfxoff" state)
2. Remote login to platform using SSH, then type the command line:
sudo su -c "echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level"
sudo su -c "echo 2 > /sys/class/drm/card0/device/pp_dpm_sclk" (fix SCLK to 1400MHz)
3. Move the mouse around in Window
4. Phenomenon : The screen frozen
Tester will switch sclk level during glmark2 run time.
APU will enter "gfxoff" state intermittently during glmark2 run time.
The system got hanged if fix GFXCLK to 1400MHz when APU is in "gfxoff"
state.
[Debug]
1. Fix SCLK to X MHz
1400: screen frozen, screen black, then OS will reboot.
1300: screen frozen.
1200: screen frozen, screen black.
1100: screen frozen, screen black, then OS will reboot.
1000: screen frozen, screen black.
900: screen frozen, screen black, then OS will reboot.
800: Situation Nomal, issue disappear.
700: Situation Nomal, issue disappear.
2. SBIOS setting: AMD CBS --> SMU Debug Options -->SMU Debug --> "GFX DLDO Psm Margin Control":
50 : Situation Nomal, issue disappear.
45 : Situation Nomal, issue disappear.
40 : Situation Nomal, issue disappear.
35 : Situation Nomal, issue disappear.
30 : screen black.
25 : screen frozen, then blurred screen.
20 : screen frozen.
15 : screen black.
10 : screen frozen.
5 : screen frozen, then blurred screen.
3. Disable GFXOFF feature
Situation Nomal, issue disappear.
[Why]
Through a period of time debugging with Sys Eng team and SMU team, Sys
Eng team said this is voltage/frequency marginal issue not a F/W or H/W
bug. This experiment proves that default targetPsm [for f=1400MHz] is
not sufficient when GFXOFF is enabled on Picasso.
SMU team think it is an odd test conditions to force sclk="1400MHz" when
GPU is in "gfxoff" state,then wake up the GFX. SCLK should be in the
"lowest frequency" when gfxoff.
[How]
Disable gfxoff when setting manual mode.
Enable gfxoff when setting other mode(exiting manual mode) again.
By the way, from the user point of view, now that user switch to manual
mode and force SCLK Frequency, he don't want SCLK be controlled by
workload.It becomes meaningless to "switch to manual mode" if APU enter "gfxoff"
due to lack of workload at this point.
Tips: Same issue observed on Raven.
Signed-off-by: chen gong <curry.gong@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Thu, 21 May 2020 14:08:11 +0000 (10:08 -0400)]
drm/amdgpu: fix pm sysfs node handling (v2)
Fix typos that prevented them from showing up.
v2: switch other files in addition to pp_clk_voltage
Fixes:
4e01847c38f7a5 ("drm/amdgpu: optimize amdgpu device attribute code")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1150
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Evan Quan <evan.quan@amd.com>
Alex Deucher [Fri, 15 May 2020 18:04:17 +0000 (14:04 -0400)]
drm/amdgpu: move gpu_info parsing after common early init
We need to get the silicon revision id before we parse
the firmware in order to load the correct gpu info firmware
for raven2 variants.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1103
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 15 May 2020 18:00:11 +0000 (14:00 -0400)]
drm/amdgpu: move discovery gfx config fetching
Move it into the fw_info function since it's logically part
of the same functionality.
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Fri, 22 May 2020 03:17:05 +0000 (13:17 +1000)]
Merge branch 'linux-5.8' of git://github.com/skeggsb/linux into drm-next
- HD audio fixes on recent systems
- vGPU detection (fail probe if we're on one, for now)
- Interlaced mode fixes (mostly avoidance on Turing, which doesn't support it)
- SVM improvements/fixes
- NVIDIA format modifier support
- Misc other fixes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <skeggsb@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/
Dave Airlie [Fri, 22 May 2020 02:20:07 +0000 (12:20 +1000)]
Merge tag 'mediatek-drm-next-5.8' of https://git./linux/kernel/git/chunkuang.hu/linux into drm-next
Mediatek DRM Next for Linux 5.8
This include dpi pin mode swap, config mipi_tx current and impedance,
and some fixup.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200521014612.17175-1-chunkuang.hu@kernel.org
Dinghao Liu [Wed, 20 May 2020 10:47:48 +0000 (18:47 +0800)]
drm/nouveau/dispnv50: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Dinghao Liu [Wed, 20 May 2020 10:36:04 +0000 (18:36 +0800)]
drm/nouveau: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Dinghao Liu [Wed, 20 May 2020 10:25:49 +0000 (18:25 +0800)]
drm/nouveau: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Dinghao Liu [Wed, 20 May 2020 10:14:53 +0000 (18:14 +0800)]
drm/nouveau/debugfs: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ralph Campbell [Wed, 20 May 2020 18:36:52 +0000 (11:36 -0700)]
drm/nouveau/nouveau/hmm: fix migrate zero page to GPU
When calling OpenCL clEnqueueSVMMigrateMem() on a region of memory that
is backed by pte_none() or zero pages, migrate_vma_setup() will fill the
source PFN array with an entry indicating the source page is zero.
Use this to optimize migration to device private memory by allocating
GPU memory and zero filling it instead of failing to migrate the page.
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ralph Campbell [Tue, 21 Apr 2020 23:11:07 +0000 (16:11 -0700)]
drm/nouveau/nouveau/hmm: fix nouveau_dmem_chunk allocations
In nouveau_dmem_init(), a number of struct nouveau_dmem_chunk are allocated
and put on the dmem->chunk_empty list. Then in nouveau_dmem_pages_alloc(),
a nouveau_dmem_chunk is removed from the list and GPU memory is allocated.
However, the nouveau_dmem_chunk is never removed from the chunk_empty
list nor placed on the chunk_free or chunk_full lists. This results
in only one chunk ever being actually used (2MB) and quickly leads to
migration to device private memory failures.
Fix this by having just one list of free device private pages and if no
pages are free, allocate a chunk of device private pages and GPU memory.
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lyude Paul [Mon, 11 May 2020 22:41:27 +0000 (18:41 -0400)]
drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
minimum PBN against the MSTB's full PBN capabilities (remember-we don't
care about the current bw state here). Otherwise, all of the other code
can be shared.
So, we move all of the common mode validation in
nouveau_connector_mode_valid() into a separate helper,
nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lyude Paul [Mon, 11 May 2020 22:41:26 +0000 (18:41 -0400)]
drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes()
This just limits the BPC for MST connectors to a maximum of 8 from
nv50_mstc_get_modes(), instead of doing so during
nv50_msto_atomic_check(). This doesn't introduce any functional changes
yet (other then userspace now lying about the max bpc, but we can't
support that yet anyway so meh). But, we'll need this in a moment so
that we can share mode validation between SST and MST which will fix
some real world issues.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lyude Paul [Mon, 11 May 2020 22:41:25 +0000 (18:41 -0400)]
drm/nouveau/kms/gv100-: Add support for interlaced modes
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lyude Paul [Mon, 11 May 2020 22:41:24 +0000 (18:41 -0400)]
drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support
Right now, we make the mistake of allowing interlacing on all
connectors. Nvidia hardware does not always support interlacing with DP
though, so we need to make sure that we don't allow interlaced modes to
be set in such situations as otherwise we'll end up accidentally hanging
the display HW.
This fixes some hangs with Turing, which would be caused by attempting
to set an interlaced mode on hardware that doesn't support it. This
patch likely fixes other hardware hanging in the same way as well.
Note that we say we probe PIOR caps, but they don't actually have any
interlacing caps. So, the get_caps() function for PIORs just sets
interlacing support to true.
Changes since v1:
* Actually probe caps correctly this time, both on EVO and NVDisplay.
Changes since v2:
* Fix probing for < GF119
* Use vfunc table, in prep for adding more caps in the future.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lyude Paul [Mon, 11 May 2020 22:41:23 +0000 (18:41 -0400)]
drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create()
We'll need the core channel initialized and ready by the time that we
start creating modesetting objects, so that we can call the
NV507D_GET_CAPABILITIES method to make the hardware expose it's
modesetting capabilities for later probing.
So, when loading the driver prepare the core channel from within
nouveau_display_create(). Everywhere else, we initialize the core
channel during resume.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 6 May 2020 04:41:01 +0000 (14:41 +1000)]
drm/nouveau/disp/hda/gv100-: NV_PDISP_SF_AUDIO_CNTRL0 register moved
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 6 May 2020 04:40:58 +0000 (14:40 +1000)]
drm/nouveau/disp/hda/gf119-: select HDA device entry based on bound head
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 6 May 2020 04:40:56 +0000 (14:40 +1000)]
drm/nouveau/disp/hda/gf119-: add HAL for programming device entry in SF
Register has moved on GV100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 6 May 2020 04:40:52 +0000 (14:40 +1000)]
drm/nouveau/disp/hda/gt215-: pass head to nvkm_ior.hda.eld()
We're going to use the bound head to select HDA device entry.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 6 May 2020 04:40:45 +0000 (14:40 +1000)]
drm/nouveau/disp/nv50-: increase timeout on pio channel free() polling
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Takashi Iwai [Thu, 16 Apr 2020 07:54:28 +0000 (09:54 +0200)]
drm/nouveau/kms: Fix regression by audio component transition
Since the commit
742db30c4ee6 ("drm/nouveau: Add HD-audio component
notifier support"), the nouveau driver notifies and pokes the HD-audio
HPD and ELD via audio component, but this seems broken. The culprit
is the naive assumption that crtc->index corresponds to the HDA pin.
Actually this rather corresponds to the MST dev_id (alias "pipe" in
the audio component framework) while the actual port number is given
from the output ior id number.
This patch corrects the assignment of port and dev_id arguments in the
audio component ops to recover from the HDMI/DP audio regression.
Fixes:
742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Thu, 30 Apr 2020 04:08:53 +0000 (14:08 +1000)]
drm/nouveau/device: use regular PRI accessors in chipset detection
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Karol Herbst [Tue, 28 Apr 2020 16:54:04 +0000 (18:54 +0200)]
drm/nouveau/device: detect vGPUs
Using ENODEV as this prevents probe failed errors in dmesg.
v2: move check further down
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Karol Herbst [Tue, 28 Apr 2020 16:54:03 +0000 (18:54 +0200)]
drm/nouveau/device: detect if changing endianness failed
v2: relax the checks a little
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Karol Herbst [Tue, 28 Apr 2020 16:54:02 +0000 (18:54 +0200)]
drm/nouveau/device: rework mmio mapping code to get rid of second map
Fixes warnings on GPUs with smaller a smaller mmio region like vGPUs.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Zheng Bin [Fri, 24 Apr 2020 07:36:01 +0000 (15:36 +0800)]
drm/nouveau/mmu: Remove unneeded semicolon
Fixes coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded semicolon
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded semicolon
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Kai-Heng Feng [Thu, 23 Apr 2020 06:23:58 +0000 (14:23 +0800)]
drm/nouveau: Use generic helper to check _PR3 presence
Replace nouveau_pr3_present() in favor of a more generic one,
pci_pr3_present().
Also the presence of upstream bridge _PR3 doesn't need to go hand in
hand with device's _DSM, so check _PR3 before _DSM.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Zou Wei [Tue, 21 Apr 2020 12:37:31 +0000 (20:37 +0800)]
drm/nouveau/acr: Use kmemdup instead of kmalloc and memcpy
Fixes coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity for kmemdup
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity for kmemdup
Fixes:
22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Colin Ian King [Sat, 29 Feb 2020 00:53:07 +0000 (00:53 +0000)]
drm/nouveau/core/memory: remove redundant assignments to variable ret
The variable ret is being initialized with a value that is never
read and it is being updated later with a new value. The initialization
is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ralph Campbell [Wed, 4 Mar 2020 00:13:39 +0000 (16:13 -0800)]
drm/nouveau/svm: map pages after migration
When memory is migrated to the GPU, it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the same access permissions
as the source CPU page table entries. This preserves copy on write
semantics.
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 12 Feb 2020 23:39:34 +0000 (09:39 +1000)]
drm/nouveau/disp/gv100-: expose capabilities class
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 29 Jan 2020 08:27:39 +0000 (18:27 +1000)]
drm/nouveau/bios: move ACPI _ROM handling
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Sun, 2 Feb 2020 03:55:23 +0000 (13:55 +1000)]
drm/nouveau: remove open-coded version of remove_conflicting_pci_framebuffers()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Fri, 7 Feb 2020 02:39:25 +0000 (12:39 +1000)]
drm/nouveau/gr/gk20a: move MODULE_FIRMWARE firmware definitions
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Tue, 11 Feb 2020 07:36:49 +0000 (17:36 +1000)]
drm/nouveau/ibus: use nvkm_subdev_new_()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Tue, 11 Feb 2020 07:34:58 +0000 (17:34 +1000)]
drm/nouveau/core: add nvkm_subdev_new_() for bare subdevs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
James Jones [Mon, 10 Feb 2020 23:15:55 +0000 (15:15 -0800)]
drm/nouveau/kms: Support NVIDIA format modifiers
Allow setting the block layout of a nouveau FB
object using DRM format modifiers. When
specified, the format modifier block layout and
kind overrides the GEM buffer's implicit layout
and kind. The specified format modifier is
validated against the list of modifiers supported
by the target display hardware.
v2: Used Tesla family instead of NV50 chipset compare
v4: Do not cache kind, tile_mode in nouveau_framebuffer
v5: Resolved against nouveau_framebuffer cleanup
Signed-off-by: James Jones <jajones@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
James Jones [Mon, 10 Feb 2020 23:15:54 +0000 (15:15 -0800)]
drm/nouveau/kms: Check framebuffer size against bo
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
v3: Return EINVAL when creating FB against BO with
unsupported tiling
v5: Resolved against nouveau_framebuffer cleanup
Signed-off-by: James Jones <jajones@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
James Jones [Mon, 10 Feb 2020 23:15:53 +0000 (15:15 -0800)]
drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp
Advertise support for the full list of format
modifiers supported by each class of NVIDIA
desktop GPU display hardware. Stash the array
of modifiers in the nouveau_display struct for
use when validating userspace framebuffer
creation requests, which will be supportd in
a subsequent change.
Signed-off-by: James Jones <jajones@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Mon, 10 Feb 2020 22:45:04 +0000 (08:45 +1000)]
drm/nouveau/acr: ensure falcon providing acr functions is bootstrapped first
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thomas Zimmermann [Thu, 6 Feb 2020 10:19:42 +0000 (11:19 +0100)]
drm/nouveau/kms: Remove struct nouveau_framebuffer
After its cleanup, struct nouveau_framebuffer is only a wrapper around
struct drm_framebuffer. Use the latter directly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thomas Zimmermann [Thu, 6 Feb 2020 10:19:41 +0000 (11:19 +0100)]
drm/nouveau/kms: Remove field nvbo from struct nouveau_framebuffer
The buffer object stored in nvbo is also available GEM object in obj[0]
of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and
replace all references accordingly. This may require an additional cast.
With this change we can already replace nouveau_user_framebuffer_destroy()
and nouveau_user_framebuffer_create_handle() with generic GEM helpers.
Calls to nouveau_framebuffer_new() receive a GEM object.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thomas Zimmermann [Thu, 6 Feb 2020 10:19:40 +0000 (11:19 +0100)]
drm/nouveau/kms: Move struct nouveau_framebuffer.vma to struct nouveau_fbdev
The vma field of struct nouveau_framebuffer is a special field for the
the accelerated fbdev console. Hence there's at most one single instance
for the active console. Moving it into struct nouveau_fbdev makes struct
nouveau_framebuffer slightly smaller and brings it closer to struct
drm_framebuffer.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thomas Zimmermann [Thu, 6 Feb 2020 10:19:39 +0000 (11:19 +0100)]
drm/nouveau/kms: Remove unused fields from struct nouveau_framebuffer
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Wed, 29 Jan 2020 07:32:22 +0000 (17:32 +1000)]
drm/nouveau: fix out-of-tree module build
The $(srctree) addition a while back busted building the out-of-tree
version of the module, and I've been hacking it up ever since.
This allows us to work around the issue.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
James Jones [Wed, 11 Dec 2019 20:55:47 +0000 (12:55 -0800)]
drm: Generalized NV Block Linear DRM format mod
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "fields" to the
existing parameterized
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier
macro that allow fully defining a unique-across-
all-NVIDIA-hardware bit layout using a minimal
set of fields and values. The new modifier macro
DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D is
effectively backwards compatible with the existing
macro, introducing a superset of the previously
definable format modifiers.
Backwards compatibility has two quirks. First,
the zero value for the "kind" field, which is
implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK
macro, must be special cased in drivers and
assumed to map to the pre-Turing generic kind of
0xfe, since a kind of "zero" is reserved for
linear buffer layouts on all GPUs.
Second, it is assumed backwards compatibility
is only needed when running on Tegra GPUs, and
specifically Tegra GPUs prior to Xavier. This
is based on two assertions:
-Tegra GPUs prior to Xavier used a slightly
different raw bit layout than desktop GPUs,
making it impossible to directly share block
linear buffers between the two.
-Support for the existing block linear modifiers
was incomplete, making them useful only for
exporting buffers created by nouveau and
importing them to Tegra DRM as framebuffers for
scan out. There was no support for adding
framebuffers using format modifiers in nouveau,
nor importing dma-buf/PRIME GEM objects into
nouveau userspace drivers with modifiers in Mesa.
Hence it is assumed the prior modifiers were not
intended for use on desktop GPUs, and as a
corollary, were not intended to support sharing
block linear buffers across two different NVIDIA
GPUs.
v2:
- Added canonicalize helper function
v3:
- Added additional bit to compression field to
support Tesla (NV5x,G8x,G9x,GT1xx,GT2xx) class
chips.
Signed-off-by: James Jones <jajones@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Alan Swanson [Thu, 21 May 2020 20:29:30 +0000 (21:29 +0100)]
drm/amdgpu: resize VRAM BAR for CPU access on gfx10
Try to resize BAR0 to let CPU access all of VRAM on Navi. Syncs
code with previous gfx generations from commit
d6895ad39f3b39
("drm/amdgpu: resize VRAM BAR for CPU access v6").
Signed-off-by: Alan Swanson <reiver@improbability.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 19 May 2020 21:06:20 +0000 (17:06 -0400)]
drm/amdgpu: drop navi pcie bw callback
It's not implemented yet so just drop it so the sysfs
pcie bw file returns an appropriate error instead of
garbage.
Reviewed-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-By: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 19 May 2020 20:54:55 +0000 (16:54 -0400)]
drm/amdgpu: improve error handling in pcie_bw
1. Initialize the counters to 0 in case the callback
fails to initialize them.
2. The counters don't exist on APUs so return an error
for them.
3. Return an error if the callback doesn't exist.
Reviewed-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-By: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Philip Yang [Thu, 21 May 2020 13:56:58 +0000 (09:56 -0400)]
drm/amdkfd: fix restore worker race condition
In free memory of gpu path, remove bo from validate_list to make sure
restore worker don't access the BO any more, then unregister bo MMU
interval notifier. Otherwise, the restore worker will crash in the
middle of validating BO user pages if MMU interval notifer is gone.
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dan Carpenter [Wed, 20 May 2020 15:25:56 +0000 (18:25 +0300)]
drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling
This loop in the error handling code should start a "i - 1" and end at
"i == 0". Currently it starts a "i" and ends at "i == 1". The result
is that it removes one attribute that wasn't created yet, and leaks the
zeroeth attribute.
Fixes:
4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Gustavo A. R. Silva [Tue, 19 May 2020 22:55:45 +0000 (17:55 -0500)]
drm/amdgpu/smu10: Replace one-element array and use struct_size() helper
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.
Also, make use of the new struct_size() helper to properly calculate the
size of struct smu10_voltage_dependency_table.
This issue was found with the help of Coccinelle and, audited and fixed
_manually_.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Jinze Xu [Thu, 7 May 2020 07:19:37 +0000 (15:19 +0800)]
drm/amd/display: Set/Reset avmute when disable/enable stream
[Why]
When disconnect fe from be, something such as unstable clock may cause
garbage occurs.
[How]
Send set avmute at the beginning of disable stream and send reset avmute
at the end of enable stream.
Signed-off-by: Jinze Xu <jinze.xu@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Tony Cheng <Tony.Cheng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stylon Wang [Thu, 30 Apr 2020 08:40:09 +0000 (16:40 +0800)]
drm/amd/display: Fix incorrectly pruned modes with deep color
[Why]
When "max bpc" is set to enable deep color, some modes are removed from
the list if they fail validation on max bpc. These modes should be kept
if they validates fine with lower bpc.
[How]
- Retry with lower bpc in mode validation.
- Same in atomic commit to apply working bpc, not necessarily max bpc.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dmytro Laktyushkin [Mon, 4 May 2020 19:34:30 +0000 (15:34 -0400)]
drm/amd/display: correct rn NUM_VMID
Save the correct num vmid during resource creation and fix RN gpuvm
level from 1 to 16 vmid entries.
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Eric Bernstein <Eric.Bernstein@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>