Dave Airlie [Thu, 19 Mar 2020 00:39:27 +0000 (10:39 +1000)]
Merge tag 'drm-intel-next-2020-03-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
UAPI Changes:
On i915 we have a new UAPI to allow userspace to specify CS ring buffer size on
construction (I915_CONTEXT_PARAM_RINGSIZE) and also new sysfs entries exposing
various engine properties
GVT Changes:
VFIO edid getting expanded to all platforms and a big cleanup around attr
group, unused vblank complete, kvmgt, Intel engine and dev_priv usages.
i915 Changes:
- new UAPI to allow userspace to specify CS ring buffer size on construction
(I915_CONTEXT_PARAM_RINGSIZE) - (Chris)
- New sysfs entries exposing various engine properties (Chris)
- Tiger Lake is out of require_force_probe protection (Jose)
- Changes in many places around active requests, reset and heartbeat (Chris)
- Stop assigning drm-dev_private pointer (Jani)
- Many code refactor in many places, including intel_modeset_init,
increasing use of intel_uncore_*, vgpu, and gvt stuff (Jani)
- Fixes around display pipe iterators (Anshuman)
- Tigerlake enabling work (Matt Ropper, Matt Atwood, Ville, Lucas, Daniele,
Jose, Anusha, Vivek, Swathi, Caz. Kai)
- Code clean-up like reducing use of drm/i915_drv.h, removing unused
registers, removing garbage warns, and some other code polishing (Jani, Lucas,
Ville)
- Selftests fixes, improvements and additions (Chris, Dan, Aditya, Matt Auld)
- Fix plane possible_crtcs bit mask (Anshuman)
- Fixes and cleanup on GLK pre production identification and w/a (Ville)
- Fix display orientation on few cases (Hans, Ville)
- dbuf clean-up and improvements for slice arrays handling (Ville)
- Improvement around min cdclk calculation (Stanislav)
- Fixes and refactor around display PLLs (Imre)
- Other execlists and perf fixes (Chris)
- Documentation fixes (Jani, Chris)
- Fix build issue (Anshuman)
- Many more fixes around the locking mechanisms (Chris)
- Other fixes and debugability info around preemption (Chris, Tvrtko)
- Add mechanism to submit a context WA on ring submission (Mika)
- Clear all Eu/L3 resitual context (Prathap)
- More changes around local memory (Abdiel, Matt, Chris)
- Fix RPS (Chris)
- DP MST fix (Lyude)
- Display FBC fixes (Jose, RK)
- debugfs cleanup (Tvrtko)
- More convertion towards drm_debive based loggin (Wambui, Ram)
- Avoid potential buffer overflow (Takashi)
- Ice Lake and Elkhart Lake workarounds (Matt Roper)
Gustavo A. R. Silva [Thu, 5 Mar 2020 10:58:42 +0000 (04:58 -0600)]
drm/vmwgfx: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, 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.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
We have a few TGL machines in our CI and it is mostly green with
failures in tests that will not impact future Linux installations.
Also there is no warnings, errors, flickering or any visual defects
while doing ordinary tasks like browsing and editing documents in a
dual monitor setup.
As a reminder i915.require_force_probe was created to protect
future Linux installation's iso images that might contain a
kernel from the enabling time of the new platform. Without this
protection most of linux installation was recommending
nomodeset option during installation that was getting stick
there after installation.
Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-tgl-u.html
Reference: https://intel-gfx-ci.01.org/tree/drm-tip/shard-tglb.html Cc: James Ausmus <james.ausmus@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218230822.66801-1-jose.souza@intel.com
Dmitry Osipenko [Thu, 12 Mar 2020 15:04:32 +0000 (18:04 +0300)]
drm/tegra: hdmi: Silence deferred-probe error
Driver fails to probe with -EPROBE_DEFER, which produces a bit noisy error
message in KMSG during kernel's boot up. This happens because voltage
regulators tend to be probed later than the DRM driver.
Driver fails to probe with -EPROBE_DEFER if display output isn't ready
yet. This produces a bit noisy error message in KMSG during kernel's boot
up on Tegra20 and Tegra30 because RGB output tends to be probed earlier
than a corresponding voltage regulator driver.
Matt Roper [Wed, 11 Mar 2020 16:23:00 +0000 (09:23 -0700)]
drm/i915: Add Wa_1605460711 / Wa_1408767742 to ICL and EHL
This workaround appears under two different numbers (and with somewhat
confused stepping applicability on ICL). Ultimately it appears we
should just implement this for all stepping of ICL and EHL.
Note that this is identical to Wa_1407928979:tgl that already exists in
our driver too...yet another number referencing the same actual
workaround.
Matt Roper [Wed, 11 Mar 2020 16:22:59 +0000 (09:22 -0700)]
drm/i915: Apply Wa_1406680159:icl,ehl as an engine workaround
The register this workaround updates is a render engine register in the
MCR range, so we should initialize this in rcs_engine_wa_init() rather
than gt_wa_init().
Matt Roper [Wed, 11 Mar 2020 16:22:57 +0000 (09:22 -0700)]
drm/i915: Add Wa_1604278689:icl,ehl
The bspec description for this workaround tells us to program
0xFFFF_FFFF into both FBC_RT_BASE_ADDR_REGISTER_* registers, but we've
previously found that this leads to failures in CI. Our suspicion is
that the failures are caused by this valid turning on the "address valid
bit" even though we're intentionally supplying an invalid address.
Experimentation has shown that setting all bits _except_ for the
RT_VALID bit seems to avoid these failures.
v2:
- Mask off the RT_VALID bit. Experimentation with CI trybot indicates
that this is necessary to avoid reset failures on BCS.
v3:
- Program RT_BASE before RT_BASE_UPPER so that the valid bit is turned
off by the first write. (Chris)
Matt Roper [Wed, 11 Mar 2020 16:22:56 +0000 (09:22 -0700)]
drm/i915: Add Wa_1209644611:icl,ehl
On gen11 the XY_FAST_COPY_BLT command has some size restrictions on its
usage. Although this instruction is mainly used by userspace, i915 also
uses it to copy object contents during some selftests, so let's ensure
the restrictions are followed.
Dave Airlie [Thu, 12 Mar 2020 23:09:11 +0000 (09:09 +1000)]
Merge tag 'amd-drm-next-5.7-2020-03-10' of git://people.freedesktop.org/~agd5f/linux into drm-next
amd-drm-next-5.7-2020-03-10:
amdgpu:
- SR-IOV fixes
- Fix up fallout from drm load/unload callback removal
- Navi, renoir power management watermark fixes
- Refactor smu parameter handling
- Display FEC fixes
- Display DCC fixes
- HDCP fixes
- Add support for USB-C PD firmware updates
- Pollock detection fix
- Rework compute ring priority handling
- RAS fixes
- Misc cleanups
amdkfd:
- Consolidate more gfx config details in amdgpu
- Consolidate bo alloc flags
- Improve code comments
- SDMA MQD fixes
- Misc cleanups
gpu scheduler:
- Add suport for modifying the sched list
uapi:
- Clarify comments about GEM_CREATE flags that are not used by userspace.
The kernel driver has always prevented userspace from using these.
They are only used internally in the kernel driver.
Chris Wilson [Thu, 12 Mar 2020 11:53:07 +0000 (11:53 +0000)]
drm/i915/gt: Wait for RCUs frees before asserting idle on unload
During driver unload, we have many asserts that we have released our
bookkeeping structs and are idle. In some cases, these struct are
protected by RCU and we do not release them until after an RCU grace
period.
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 130a95e9098e ("drm/i915/gem: Consolidate ctx->engines[] release") 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> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200312115307.16460-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 11 Mar 2020 16:03:10 +0000 (16:03 +0000)]
drm/i915/gem: Drop relocation slowpath
Since the relocations are no longer performed under a global
struct_mutex, or any other lock, that is also held by pagefault handlers,
we can relax and allow our fast path to take a fault. As we no longer
need to abort the fast path for lock avoidance, we no longer need the
slow path handling at all.
Sebastian Andrzej Siewior [Mon, 2 Mar 2020 09:35:10 +0000 (10:35 +0100)]
drm/vmwgfx: Remove a few unused functions
I noticed that there is a prototype for vmw_fifo_ping_host_locked() but
no function. Then I looked further and noticed more functions which are
not used anymore or functions protoypes which remained after the
function was removed.
Remove unused function (prototypes).
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Sebastian Andrzej Siewior [Mon, 24 Feb 2020 14:07:25 +0000 (15:07 +0100)]
drm/vmwgfx: Drop preempt_disable() in vmw_fifo_ping_host()
vmw_fifo_ping_host() disables preemption around a test and a register
write via vmw_write(). The write function acquires a spinlock_t typed
lock which is not allowed in a preempt_disable()ed section on
PREEMPT_RT. This has been reported in the bugzilla.
It has been explained by Thomas Hellstrom that this preempt_disable()ed
section is not required for correctness.
Tvrtko Ursulin [Thu, 12 Mar 2020 11:57:48 +0000 (11:57 +0000)]
drm/i915/gen12: Disable preemption timeout
Allow super long OpenCL workloads which cannot be preempted within
the default timeout to run out of the box.
v2:
* Make it stick out more and apply only to RCS. (Chris)
v3:
* Mention platform override in kconfig. (Joonas)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Michal Mrozek <Michal.mrozek@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200312115748.29970-1-tvrtko.ursulin@linux.intel.com
Thomas Hellstrom [Wed, 15 Jan 2020 20:48:19 +0000 (21:48 +0100)]
drm/vmwgfx: Refuse DMA operation when SEV encryption is active
TTM doesn't yet fully support mapping of DMA memory when SEV is active,
so in that case, refuse DMA operation. For guest-backed object operation
this means 3D acceleration will be disabled. For host-backed, VRAM will be
used for data transfer between the guest and the device.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
Thomas Hellstrom [Wed, 15 Jan 2020 20:48:19 +0000 (21:48 +0100)]
drm/vmwgfx: Fix the refuse_dma mode when using guest-backed objects
When we refuse DMA from system pages for whatever reason, we don't
handle that correctly when guest-backed objects was enabled.
Since guest-backed objects by definition require DMA to and from
system pages, disable all functionality that relies on them.
That basically amounts to 3D acceleration and screen targets.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
Chris Wilson [Wed, 11 Mar 2020 22:17:39 +0000 (22:17 +0000)]
drm/i915/gem: Take a copy of the engines for context_barrier_task
When applying the context-barrier, we only care about the current
engines, as the next set of engines will be naturally after the barrier.
So we can skip holding the ctx->engines_mutex while constructing the
request by taking a sneaky reference to the i915_gem_engines instead.
Chris Wilson [Wed, 11 Mar 2020 22:17:38 +0000 (22:17 +0000)]
drm/i915/gem: Mark up sw-fence notify function
The sw-fence notify function requires to be at least 4-byte aligned so
that we can use the low bits in the function pointer for internal fence
flags. Make it so.
References: https://gitlab.freedesktop.org/drm/intel/issues/1433 Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests on changing engines") 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/20200311221739.30375-1-chris@chris-wilson.co.uk
Kai Vehmanen [Tue, 10 Mar 2020 16:23:38 +0000 (18:23 +0200)]
drm/i915: Add missing HDMI audio pixel clocks for gen12
Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz
and 593.4/594Mhz. Add the missing rates and add logic to ignore
them if running on older hardware.
Chris Wilson [Wed, 11 Mar 2020 09:26:22 +0000 (09:26 +0000)]
drm/i915/gt: Pull checking rps->pm_events under the irq_lock
Avoid angering kcsan by serialising the read of the pm_events with the
write in rps_disable_interrupts.
[ 6268.713419] BUG: KCSAN: data-race in intel_rps_park [i915] / rps_work [i915]
[ 6268.713437]
[ 6268.713449] write to 0xffff8881eda8efac of 4 bytes by task 1127 on cpu 3:
[ 6268.713680] intel_rps_park+0x136/0x260 [i915]
[ 6268.713905] __gt_park+0x61/0xa0 [i915]
[ 6268.714128] ____intel_wakeref_put_last+0x42/0x90 [i915]
[ 6268.714352] __intel_wakeref_put_work+0xd3/0xf0 [i915]
[ 6268.714369] process_one_work+0x3b1/0x690
[ 6268.714384] worker_thread+0x80/0x670
[ 6268.714398] kthread+0x19a/0x1e0
[ 6268.714412] ret_from_fork+0x1f/0x30
[ 6268.714423]
[ 6268.714435] read to 0xffff8881eda8efac of 4 bytes by task 950 on cpu 2:
[ 6268.714664] rps_work+0xc2/0x680 [i915]
[ 6268.714679] process_one_work+0x3b1/0x690
[ 6268.714693] worker_thread+0x80/0x670
[ 6268.714707] kthread+0x19a/0x1e0
[ 6268.714720] ret_from_fork+0x1f/0x30
v2: Mark all reads and writes of rpm->pm_events.
The flow of enabling/disabling rps is stronly ordered, so the writes and
interrupt generation are also strongly ordered -- just this may not be
visible to the compiler, so provide annotations.
Takashi Iwai [Wed, 11 Mar 2020 07:32:56 +0000 (08:32 +0100)]
drm/i915/gt: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Wambui Karuga [Tue, 10 Mar 2020 08:52:49 +0000 (10:52 +0200)]
drm/i915/overlay: convert to drm_device based logging.
Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_overlay.c.
This transformation was achieved using the following coccinelle script:
@@
identifier fn, T;
@@
Wambui Karuga [Tue, 10 Mar 2020 08:52:48 +0000 (10:52 +0200)]
drm/i915/lvds: convert to drm_device based logging macros.
Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_lvds.c.
This transformation was done by the following coccinelle script that
matches based on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@
Wambui Karuga [Tue, 10 Mar 2020 08:52:46 +0000 (10:52 +0200)]
drm/i915/hotplug: convert to drm_device based logging.
Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_hotplug.c.
In some cases, this involves extracting the drm_i915_private pointer from
the drm_device struct to be used in the logging macros.
Wambui Karuga [Tue, 10 Mar 2020 08:52:44 +0000 (10:52 +0200)]
drm/i915/gmbus: convert to drm_device based logging,
Conversion instances of printk based drm logging macros to use the
struct drm_device based logging macros in i915/display/intel_gmbus.c.
This was done using the following coccinelle semantic patch that
transforms based on the existence of an existing drm_i915_private
device:
@@
identifier fn, T;
@@
Wambui Karuga [Tue, 10 Mar 2020 08:52:43 +0000 (10:52 +0200)]
drm/i915/fifo_underrun: convert to drm_device based logging.
Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros in
i915/display/intel_fifo_underrun.c.
This was done using the following coccinelle script:
@@
identifier fn, T;
@@
Wambui Karuga [Mon, 9 Mar 2020 15:12:41 +0000 (17:12 +0200)]
drm/i915/dsb: convert to drm_device based logging macros.
This converts uses of the printk based drm logging macros to the struct
drm_device logging macros in i915/display/intel_dsb.c. This was done
using the following coccinelle script:
@@
identifier fn, T;
@@
Tvrtko Ursulin [Tue, 10 Mar 2020 16:47:33 +0000 (16:47 +0000)]
drm/i915: Remove debugfs i915_drpc_info and i915_forcewake_domains
The two files have been duplicated under the gt/ subdir and since there
are not apparent users looking for them at the old location lets simply
remove them and duplicated code.
Chris Wilson [Tue, 10 Mar 2020 14:24:03 +0000 (14:24 +0000)]
drm/i915: Mark up racy read of active rq->engine
As a virtual engine may change the rq->engine to point to the active
request in flight, we need to warn the compiler that an active request's
engine is volatile.
Chris Wilson [Tue, 10 Mar 2020 14:13:18 +0000 (14:13 +0000)]
drm/i915/gt: Mark up racy reads for intel_context.inflight
When being used across multiple real engines inside a virtual engine,
the intel_context.inflight is updated atomically, and so we must
annotate the racy read from outside the owning context.
[11142.482846] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] / __execlists_submission_tasklet [i915]
[11142.482867]
[11142.482878] write (marked) to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 2:
[11142.483107] __execlists_submission_tasklet+0x1d33/0x2120 [i915]
[11142.483336] execlists_submission_tasklet+0xd3/0x170 [i915]
[11142.483355] tasklet_action_common.isra.0+0x42/0xa0
[11142.483371] __do_softirq+0xd7/0x2cd
[11142.483384] irq_exit+0xbe/0xe0
[11142.483401] do_IRQ+0x51/0x100
[11142.483424] ret_from_intr+0x0/0x1c
[11142.483446] do_idle+0x133/0x1f0
[11142.483465] cpu_startup_entry+0x14/0x16
[11142.483483] start_secondary+0x120/0x180
[11142.483498] secondary_startup_64+0xa4/0xb0
[11142.483512]
[11142.483528] read to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 1:
[11142.483755] __execlists_submission_tasklet+0x14e/0x2120 [i915]
[11142.483981] execlists_submission_tasklet+0xd3/0x170 [i915]
[11142.483999] tasklet_action_common.isra.0+0x42/0xa0
[11142.484014] __do_softirq+0xd7/0x2cd
[11142.484028] do_softirq_own_stack+0x2a/0x40
[11142.484046] do_softirq.part.0+0x26/0x30
[11142.484071] __local_bh_enable_ip+0x46/0x50
[11142.484299] i915_gem_do_execbuffer+0x39c1/0x4e50 [i915]
[11142.484528] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[11142.484546] drm_ioctl_kernel+0xe4/0x120
[11142.484559] drm_ioctl+0x297/0x4c7
[11142.484572] ksys_ioctl+0x89/0xb0
[11142.484586] __x64_sys_ioctl+0x42/0x60
[11142.484610] do_syscall_64+0x6e/0x2c0
[11142.484627] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Chris Wilson [Tue, 10 Mar 2020 11:59:47 +0000 (11:59 +0000)]
drm/i915: Tweak scheduler's kick_submission()
Skip useless priority bumping on adding a new dependency by making sure
that we do update the priority if we would have rescheduled the active
cotnext.
Chris Wilson [Tue, 10 Mar 2020 10:17:20 +0000 (10:17 +0000)]
drm/i915: Defer semaphore priority bumping to a workqueue
Since the semaphore fence may be signaled from inside an interrupt
handler from inside a request holding its request->lock, we cannot then
enter into the engine->active.lock for processing the semaphore priority
bump as we may traverse our call tree and end up on another held
request.
José Roberto de Souza [Fri, 6 Mar 2020 18:58:32 +0000 (10:58 -0800)]
drm/i915/display: Deactive FBC in fastsets when disabled by parameter
Most of the kms_frontbuffer_tracking tests disables the feature being
tested, draw, get the CRC then enable the feature, draw again, get the
CRC and check if it matches.
Some times it is able to do that with a fastset, so
intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was
not checking if FBC is now enabled in this CRTC leaving FBC active and
causing the warning bellow in __intel_fbc_disable()
i915 can enable aux device nodes for DP MST by calling
drm_dp_mst_connector_late_register()/
drm_dp_mst_connector_early_unregister(),
so let's hook that up.
Changes since v1:
* Call intel_connector_register/unregister() from
intel_dp_mst_connector_late_register/unregister() so we don't lose
error injection - Ville Syrjälä
Changes since v2:
* Don't forget to clean up if intel_connector_register() fails - Ville
Tao Zhou [Fri, 6 Mar 2020 04:24:06 +0000 (12:24 +0800)]
drm/amdgpu: call ras_debugfs_create_all in debugfs_init
and remove each ras IP's own debugfs creation
this is required to fix ras when the driver does not use the drm load
and unload callbacks due to ordering issues with the drm device node.
Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Tao Zhou [Fri, 6 Mar 2020 03:59:16 +0000 (11:59 +0800)]
drm/amdgpu: add function to creat all ras debugfs node
centralize all debugfs creation in one place for ras
this is required to fix ras when the driver does not use the drm load
and unload callbacks due to ordering issues with the drm device node.
Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
xinhui pan [Mon, 9 Mar 2020 14:28:01 +0000 (22:28 +0800)]
drm/amdgpu: Correct the condition of warning while bo release
Only kernel bo has kfd eviction fence.
This warning is to give a notice that kfd only remove eviction fence on
individual bos.
Tested-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: xinhui pan <xinhui.pan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yong Zhao [Wed, 4 Mar 2020 17:38:59 +0000 (12:38 -0500)]
drm/amdkfd: Consolidate duplicated bo alloc flags
ALLOC_MEM_FLAGS_* used are the same as the KFD_IOC_ALLOC_MEM_FLAGS_*,
but they are interweavedly used in kernel driver, resulting in bad
readability. For example, KFD_IOC_ALLOC_MEM_FLAGS_COHERENT is not
referenced in kernel, and it functions implicitly in kernel through
ALLOC_MEM_FLAGS_COHERENT, causing unnecessary confusion.
Replace all occurrences of ALLOC_MEM_FLAGS_* with
KFD_IOC_ALLOC_MEM_FLAGS_* to solve the problem.
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>
Nirmoy Das [Tue, 10 Mar 2020 12:15:56 +0000 (13:15 +0100)]
drm/amdgpu: do not set nil entry in compute_prio_sched
If there are no high priority compute queues available then set normal
priority sched array to compute_prio_sched[AMDGPU_GFX_PIPE_PRIO_HIGH]
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>
Chris Wilson [Fri, 6 Mar 2020 13:38:38 +0000 (13:38 +0000)]
drm/i915: Improve the start alignment of bonded pairs
Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting on the semaphore used to synchronise the start of the
bonded payload.
Ville Syrjälä [Mon, 2 Mar 2020 17:44:42 +0000 (19:44 +0200)]
drm/i915: Lock gmbus/aux mutexes while changing cdclk
gmbus/aux may be clocked by cdclk, thus we should make sure no
transfers are ongoing while the cdclk frequency is being changed.
We do that by simply grabbing all the gmbus/aux mutexes. No one
else should be holding any more than one of those at a time so
the lock ordering here shouldn't matter.
Ville Syrjälä [Tue, 3 Mar 2020 17:33:13 +0000 (19:33 +0200)]
drm/i915: Pass the crtc to the low level read_lut() funcs
The low level read_lut() functions don't need the entire crtc state
as they know exactly what they're reading. Just need to pass in the
crtc to get at the pipe. This now neatly mirrors the load_lut()
direction.
Ville Syrjälä [Tue, 3 Mar 2020 17:33:12 +0000 (19:33 +0200)]
drm/i915: Fix readout of PIPEGCMAX
PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can
represent a value of 1.0 when the maximum we can store in the
software LUT is 0.ffff. Clamp the value so that it gets
saturated to the max the uapi supports.
Ville Syrjälä [Tue, 3 Mar 2020 17:33:11 +0000 (19:33 +0200)]
drm/i915: Refactor LUT read functions
Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.
Ville Syrjälä [Tue, 3 Mar 2020 17:33:10 +0000 (19:33 +0200)]
drm/i915: Clean up integer types in color code
A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which generally provide the loop end codition
for 'i'.
Ville Syrjälä [Tue, 3 Mar 2020 17:33:09 +0000 (19:33 +0200)]
drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/
chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().
Ville Syrjälä [Tue, 3 Mar 2020 17:33:07 +0000 (19:33 +0200)]
drm/i915: Split i9xx_read_lut_8() to gmch vs. ilk variants
To mirror the load_luts path let's clone an ilk+ version
from i9xx_read_lut_8(). I guess the extra branch isn't a huge
issue but feels better to make a clean split.
Ville Syrjälä [Tue, 3 Mar 2020 17:33:05 +0000 (19:33 +0200)]
drm/i915: Polish CHV CGM CSC loading
Only load the CGM CSC based on the cgm_mode bit like we
do with the gamma/degamma LUTs. And make the function
naming and arguments consistent as well.
TODO: the code to convert the coefficients look totally
bogus. IIRC CHV uses two's complement format but the code
certainly doesn't generate that, so probably negative
coefficients are totally busted.
Chris Wilson [Mon, 9 Mar 2020 11:09:30 +0000 (11:09 +0000)]
drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
During i915_request_retire() we decouple the i915_request.hwsp_seqno
from the intel_timeline so that it may be freed before the request is
released. However, we need to warn the compiler that the pointer may
update under its nose.
[ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fence [i915] / i915_request_retire [i915]
[ 171.438920]
[ 171.438932] write to 0xffff8881e7e28ce0 of 8 bytes by task 148 on cpu 2:
[ 171.439174] i915_request_retire+0x1ea/0x660 [i915]
[ 171.439408] retire_requests+0x7a/0xd0 [i915]
[ 171.439640] engine_retire+0xa1/0xe0 [i915]
[ 171.439657] process_one_work+0x3b1/0x690
[ 171.439671] worker_thread+0x80/0x670
[ 171.439685] kthread+0x19a/0x1e0
[ 171.439701] ret_from_fork+0x1f/0x30
[ 171.439721]
[ 171.439739] read to 0xffff8881e7e28ce0 of 8 bytes by task 696 on cpu 1:
[ 171.439990] i915_request_await_dma_fence+0x162/0x520 [i915]
[ 171.440230] i915_request_await_object+0x2fe/0x470 [i915]
[ 171.440467] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[ 171.440704] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 171.440722] drm_ioctl_kernel+0xe4/0x120
[ 171.440736] drm_ioctl+0x297/0x4c7
[ 171.440750] ksys_ioctl+0x89/0xb0
[ 171.440766] __x64_sys_ioctl+0x42/0x60
[ 171.440788] do_syscall_64+0x6e/0x2c0
[ 171.440802] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Nirmoy Das [Thu, 27 Feb 2020 17:26:15 +0000 (18:26 +0100)]
drm/amdgpu: remove unused functions
AMDGPU statically sets priority for compute queues
at initialization so remove all the functions
responsible for changing compute queue priority dynamically.
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>
Nirmoy Das [Thu, 27 Feb 2020 17:18:22 +0000 (18:18 +0100)]
drm/amdgpu: change hw sched list on ctx priority override
Switch to appropriate sched list for an entity on priority override.
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>
Nirmoy Das [Thu, 27 Feb 2020 14:34:15 +0000 (15:34 +0100)]
drm/scheduler: implement a function to modify sched list
Implement drm_sched_entity_modify_sched() which modifies existing
sched_list with a different one. This is going to be helpful when
userspace changes priority of a ctx/entity then the driver can switch
to the corresponding HW scheduler list for that priority.
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>
Nirmoy Das [Thu, 27 Feb 2020 12:59:08 +0000 (13:59 +0100)]
drm/amdgpu: set compute queue priority at mqd_init
We were changing compute ring priority while rings were being used
before every job submission which is not recommended. This patch
sets compute queue priority at mqd initialization for gfx8, gfx9 and
gfx10.
Policy: make queue 0 of each pipe as high priority compute queue
High/normal priority compute sched lists are generated from set of high/normal
priority compute queues. At context creation, entity of compute queue
get a sched list from high or normal priority depending on ctx->priority
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Aly-Tawfik [Tue, 25 Feb 2020 20:01:28 +0000 (15:01 -0500)]
drm/amdgpu/display: Fix Pollock Variant Detection
Problem Description:
Currently we are checking internal fused rev id with pci rev id. However, fused
internal rev id is the same on all raven2 parts (in which Dali and Pollock were
based on too), thus Pollock detection fails
Fix:
use the pci rev to preform the detection for bandwidth calculations.
Wenjing Liu [Mon, 24 Feb 2020 22:19:02 +0000 (17:19 -0500)]
drm/amd/display: separate FEC capability from fec debug flag
[why]
FEC capability query should not be affected by debugging decision on
whether to disable FEC. We should not determine if display supports FEC
by checking debug option.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Martin Leung [Thu, 27 Feb 2020 19:41:39 +0000 (14:41 -0500)]
drm/amd/display: writing stereo polarity register if swapped
[why]
on some displays that prefer swapped polarity we were seeing L/R images
swapped because OTG_STEREO_SYNC_OUTPUT_POLARITY would always be mapped
to 0
[how]
fix initial dal3 implementation to properly update the polarity field
according to the crtc_stereo_flags (same as
OTG_STEREO_EYE_FLAG_POLARITY)
Signed-off-by: Martin Leung <martin.leung@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rodrigo Siqueira [Mon, 24 Feb 2020 15:13:37 +0000 (10:13 -0500)]
drm/amd/display: Stop if retimer is not available
Raven provides retimer feature support that requires i2c interaction in
order to make it work well, all settings required for this configuration
are loaded from the Atom bios which include the i2c address. If the
retimer feature is not available, we should abort the attempt to set
this feature, otherwise, it makes the following line return
I2C_CHANNEL_OPERATION_NO_RESPONSE:
i2c_success = i2c_write(pipe_ctx, slave_address, buffer, sizeof(buffer));
...
if (!i2c_success)
ASSERT(i2c_success);
This ends up causing problems with hotplugging HDMI displays on Raven,
and causes retimer settings to warn like so:
This commit reworks the way that we handle i2c write for retimer in the
way that we abort this configuration if the feature is not available in
the device. For debug sake, we kept a simple log message in case the
retimer is not available.
Wenjing Liu [Tue, 25 Feb 2020 19:23:01 +0000 (14:23 -0500)]
drm/amd/display: fix a minor HDCP logging error
[why]
In HDCP Uninitialzed State, a CPIRQ event would cause log output
internal policy error because the CPIRQ event is not recognized as
unexpected event.
[how]
CPIRQ is issued in HDCP uninitialized state is unexpected. We should
set unexpected event flag in event ctx.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wenjing Liu [Tue, 25 Feb 2020 21:37:32 +0000 (16:37 -0500)]
drm/amd/display: determine rx id list bytes to read based on device count
[why]
Some RX doesn't like us to read rx id list upto max rx id list size. As
discussed, we decided to read rx id list based on device count.
[how]
According to HDCP specs the actual size of rx id list is calculated as
rx id list size = 2+3+16+5*device_count. We will read 16 bytes at a
time until it reached or exceeded rx id list size.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Nikola Cornij [Wed, 26 Feb 2020 19:53:54 +0000 (14:53 -0500)]
drm/amd/display: Program DSC during timing programming
[why]
Link or DIG BE can't be exposed to a higher stream bandwidth than they
can handle. When DSC is required to fit the stream into the link
bandwidth, DSC has to be programmed during timing programming to ensure
this. Without it, intermittent issues such as black screen after S3 or a
hot-plug can be seen.
[how]
Move DSC programming from enabling stream on link to timing setup.
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yongqiang Sun [Wed, 26 Feb 2020 19:25:29 +0000 (14:25 -0500)]
drm/amd/display: Not check wm and clk change flag in optimized bandwidth.
[Why]
System isn't able to enter S0i3 due to not send display count 0 to smu.
When dpms off, clk changed flag is cleared alreay, and it is checked
when doing optimized bandwidth, and update clocks is bypassed due to the
flag is unset.
[How]
Remove check flag incide the function since watermark values and clocks
values are checked during update to determine whether to perform it, no
need to check it again outside the function.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wenjing Liu [Mon, 24 Feb 2020 22:22:36 +0000 (17:22 -0500)]
drm/amd/display: determine is mst hdcp based on stream instead of sink signal
[why]
It is possible even if sink signal is MST but driver enables SST stream.
We should not determine if we should do MST authentication based on
sink's capability.
Instead we should determine whether to do MST authentication based on
what we have enabled in stream.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Martin Leung [Mon, 24 Feb 2020 19:07:23 +0000 (14:07 -0500)]
drm/amd/display: update soc bb for nv14
[why]
nv14 previously inherited soc bb from generic dcn 2, did not match
watermark values according to memory team
[how]
add nv14 specific soc bb: copy nv2 generic that it was
using from before, but changed num channels to 8
Signed-off-by: Martin Leung <martin.leung@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
projects / users / jedix / linux-maple.git / log