[Intel-gfx] [PATCH v4 0/4] drm: Introduce struct drm_device based WARN* and use them in i915
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel include device information in the backtrace, so we know what device the warnings originate from. Similar to this, add new struct drm_device based drm_WARN* macros. These macros include device information in the backtrace, so we know what device the warnings originate from. Knowing the device specific information in the backtrace would be helpful in development all around. This patch series aims to convert calls of WARN(), WARN_ON(), WARN_ONCE() and WARN_ON_ONCE() in i915 driver to use the drm device-specific variants automatically wherever struct device pointer is available. To do this, this patch series - - introduces new struct drm_device based WARN* macros - automatically converts WARN* with device specific dev_WARN* variants using coccinelle semantic patch scripts. The goal is to convert all the calls of WARN* with drm_WARN* in i915, but there are still cases where device pointer is not readily available in some functions (or I missed them somehow) using WARN* hence some manual churning is needed. Handle such remaining cases separately later. changes since v3: - rebase pending unmerged patches on drm-tip (bc626bbb5b6e drm-tip: 2020y-01m-25d-14h-28m-41s UTC integration manifest) changes since v2: - rebase pending unmerged patches on drm-tip changes since v1: - Address Jani's review comments - Fix typo in comment of patch 0001 - Get rid of helper functions - Split patches by directory Changes since RFC at [1] - Introduce drm_WARN* macros and use them as suggested by Sam and Jani - Get rid of extra local variables [1] https://patchwork.freedesktop.org/series/71668/ Pankaj Bharadiya (4): drm/i915/display: Make WARN* drm specific where drm_device ptr is available drm/i915/display: Make WARN* drm specific where drm_priv ptr is available drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available drivers/gpu/drm/i915/display/icl_dsi.c| 14 +- drivers/gpu/drm/i915/display/intel_atomic.c | 6 +- drivers/gpu/drm/i915/display/intel_audio.c| 19 +- drivers/gpu/drm/i915/display/intel_bios.c | 10 +- drivers/gpu/drm/i915/display/intel_bw.c | 3 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 81 --- drivers/gpu/drm/i915/display/intel_color.c| 4 +- .../gpu/drm/i915/display/intel_combo_phy.c| 2 +- .../gpu/drm/i915/display/intel_connector.c| 3 +- drivers/gpu/drm/i915/display/intel_crt.c | 10 +- drivers/gpu/drm/i915/display/intel_ddi.c | 94 drivers/gpu/drm/i915/display/intel_display.c | 218 ++ .../drm/i915/display/intel_display_power.c| 167 -- drivers/gpu/drm/i915/display/intel_dp.c | 117 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 3 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 37 +-- drivers/gpu/drm/i915/display/intel_dsb.c | 6 +- .../i915/display/intel_dsi_dcs_backlight.c| 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 5 +- drivers/gpu/drm/i915/display/intel_fbc.c | 23 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 13 +- drivers/gpu/drm/i915/display/intel_gmbus.c| 3 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 21 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 51 ++-- drivers/gpu/drm/i915/display/intel_hotplug.c | 7 +- .../gpu/drm/i915/display/intel_lpe_audio.c| 2 +- drivers/gpu/drm/i915/display/intel_lvds.c | 7 +- drivers/gpu/drm/i915/display/intel_opregion.c | 7 +- drivers/gpu/drm/i915/display/intel_overlay.c | 12 +- drivers/gpu/drm/i915/display/intel_panel.c| 19 +- drivers/gpu/drm/i915/display/intel_pipe_crc.c | 7 +- drivers/gpu/drm/i915/display/intel_psr.c | 34 +-- drivers/gpu/drm/i915/display/intel_sdvo.c | 14 +- drivers/gpu/drm/i915/display/intel_sprite.c | 5 +- drivers/gpu/drm/i915/display/intel_tc.c | 17 +- drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +- drivers/gpu/drm/i915/display/vlv_dsi.c| 2 +- drivers/gpu/drm/i915/gvt/aperture_gm.c| 6 +- drivers/gpu/drm/i915/gvt/cfg_space.c | 23 +- drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 +- drivers/gpu/drm/i915/gvt/display.c| 6 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 4 +- drivers/gpu/drm/i915/gvt/edid.c | 19 +- drivers/gpu/drm/i915/gvt/gtt.c| 21 +- drivers/gpu/drm/i915/gvt/gvt.c| 4 +- drivers/gpu/drm/i915/gvt/handlers.c | 22 +- drivers/gpu/drm/i915/gvt/interrupt.c | 15 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 10 +- drivers/gpu/drm/i915/gvt/mmio.c | 30 ++- drivers/gpu/drm/i915/gvt/mmio_context.c | 8 +- drivers/gpu/drm/i915/gvt/scheduler.c | 6 +- driv
[Intel-gfx] [PATCH v4 1/4] drm/i915/display: Make WARN* drm specific where drm_device ptr is available
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
command: spatch --sp-file
[Intel-gfx] [PATCH v4 4/4] drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@@
identifier func, T;
@@
func(struct intel_vgpu *T,...) {
+struct drm_i915_private *i915 = T->gvt->dev_priv;
<+...
(
-WARN(
+drm_WARN(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>
}
command: spatch --sp-file
[Intel-gfx] [PATCH v4 2/4] drm/i915/display: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
command: spatch --sp-file
[Intel-gfx] [PATCH v4 3/4] drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
command: spatch --sp-file
Re: [Intel-gfx] [PATCH v3 0/4] drm: Introduce struct drm_device based WARN* and use them in i915
On Sat, Jan 25, 2020 at 04:51:08PM +0200, Jani Nikula wrote: > On Thu, 23 Jan 2020, Pankaj Bharadiya > wrote: > > changes since v2: > > - rebase pending unmerged patches on drm-tip > > Alas, these conflict already... please rebase. :/ Ahh :( ... Looks like other changes are merged before you touched this one. Submitted V4 now. Thanks, Pankaj > > BR, > Jani. > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915
On Thu, Jan 23, 2020 at 11:39:37AM +0200, Jani Nikula wrote: > On Thu, 23 Jan 2020, "Bharadiya,Pankaj" > wrote: > > Will rebase remaining patches and submit. > > Please also add a patch to convert MISSING_CASE(), Will do. > and another to remove > the WARN_ON/WARN_ON_ONCE "overrides" that we have in i915_utils.h. Still i915 driver wil have many calls to WARN_ON* after this patch series gets merged. Shall I remove WARN_ON/WARN_ON_ONCE "overrides" so that existing callers will fallback to original WARN_ON* implementation until complete conversion is done? Just want to double confirm on this before I submit a patch. Thanks, Pankaj > > Thanks, > Jani. > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_pipe_control_store_loop: Limit runtime
Use a runtime limit, not a fixed amount of work, so that it doesn't take
several hundred seconds on the slower machines.
Signed-off-by: Chris Wilson
---
tests/i915/gem_pipe_control_store_loop.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_pipe_control_store_loop.c
b/tests/i915/gem_pipe_control_store_loop.c
index b8a21d780..9330a47c8 100644
--- a/tests/i915/gem_pipe_control_store_loop.c
+++ b/tests/i915/gem_pipe_control_store_loop.c
@@ -62,13 +62,13 @@ uint32_t devid;
/* Like the store dword test, but we create new command buffers each time */
static void
-store_pipe_control_loop(bool preuse_buffer)
+store_pipe_control_loop(bool preuse_buffer, int timeout)
{
int i, val = 0;
uint32_t *buf;
drm_intel_bo *target_bo;
- for (i = 0; i < SLOW_QUICK(0x1, 4); i++) {
+ igt_until_timeout(timeout) {
/* we want to check tlb consistency of the pipe_control target,
* so get a new buffer every time around */
target_bo = drm_intel_bo_alloc(bufmgr, "target bo", 4096, 4096);
@@ -182,10 +182,10 @@ igt_main
}
igt_subtest("fresh-buffer")
- store_pipe_control_loop(false);
+ store_pipe_control_loop(false, 2);
igt_subtest("reused-buffer")
- store_pipe_control_loop(true);
+ store_pipe_control_loop(true, 2);
igt_fixture {
intel_batchbuffer_free(batch);
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 7/9] parisc/perf: open access for CAP_SYS_PERFMON privileged process
On 18.12.19 10:29, Alexey Budankov wrote: > > Open access to monitoring for CAP_SYS_PERFMON privileged processes. > For backward compatibility reasons access to the monitoring remains open > for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure > monitoring is discouraged with respect to CAP_SYS_PERFMON capability. > > Signed-off-by: Alexey Budankov Acked-by: Helge Deller > --- > arch/parisc/kernel/perf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/parisc/kernel/perf.c b/arch/parisc/kernel/perf.c > index 676683641d00..c4208d027794 100644 > --- a/arch/parisc/kernel/perf.c > +++ b/arch/parisc/kernel/perf.c > @@ -300,7 +300,7 @@ static ssize_t perf_write(struct file *file, const char > __user *buf, > else > return -EFAULT; > > - if (!capable(CAP_SYS_ADMIN)) > + if (!perfmon_capable()) > return -EACCES; > > if (count != sizeof(uint32_t)) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915
On Mon, 27 Jan 2020, "Bharadiya,Pankaj" wrote: > On Thu, Jan 23, 2020 at 11:39:37AM +0200, Jani Nikula wrote: >> On Thu, 23 Jan 2020, "Bharadiya,Pankaj" >> wrote: >> > Will rebase remaining patches and submit. >> >> Please also add a patch to convert MISSING_CASE(), > > Will do. > >> and another to remove >> the WARN_ON/WARN_ON_ONCE "overrides" that we have in i915_utils.h. > > Still i915 driver wil have many calls to WARN_ON* after this patch > series gets merged. > > Shall I remove WARN_ON/WARN_ON_ONCE "overrides" so that existing > callers will fallback to original WARN_ON* implementation until > complete conversion is done? Just want to double confirm on this > before I submit a patch. I think when you have most of them converted, we can throw away the "overrides". I'll let you be the judge. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros
On Sat, Jan 25, 2020 at 04:08:39PM +, Chris Wilson wrote: > Quoting Wambui Karuga (2020-01-22 12:57:48) > > This series is a part of the conversion to the new struct drm_device > > based logging macros in drm/i915. > > This series focuses on the drm/i915/gem directory and converts all > > straightforward instances of the printk based logging macros to the new > > macros. > > Overall, I'm not keen on this as it perpetuates the mistake of putting > client debug message in dmesg and now gives them even more an air of > being device driver debug messages. We need a mechanism by which we > report the details of what a client did wrong back to that client > (tracefs + context/client getparam to return an isolated debug fd is my > idea). Sean is working on that, but it's a global thing still. Well since it's tracefs should be easy to filter for a given process at least. We've had long discussion about how to expose that, big fear (especially with atomic) is that clients/compositors will start to look at random debug strings and make them uapi. But I think for stuff like igt we should be able to wire it up easily and get it dumped when things go wrong. Maybe similar when mesa gets an unexpected errno. -Daniel > > Wambui Karuga (2): > > drm/i915/gem: initial conversion to new logging macros using > > coccinelle. > > drm/i915/gem: manual conversion to struct drm_device logging macros. > > Still this is a necessary evil for the current situation, > Acked-by: Chris Wilson > -Chris -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/4] i915/gem_exec_nop: Reduce runtime
Reduce the upper timeout for stress tests from 150s to a mere 20s, and
quick tests to 2s.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_nop.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c
index dbedb3561..9a2efd32c 100644
--- a/tests/i915/gem_exec_nop.c
+++ b/tests/i915/gem_exec_nop.c
@@ -865,41 +865,41 @@ igt_main
}
igt_subtest("basic-series")
- series(device, handle, 5);
+ series(device, handle, 2);
igt_subtest("basic-parallel")
- parallel(device, handle, 5);
+ parallel(device, handle, 2);
igt_subtest("basic-sequential")
- sequential(device, handle, 0, 5);
+ sequential(device, handle, 0, 2);
for (e = intel_execution_engines; e->name; e++) {
igt_subtest_f("%s", e->name)
single(device, handle, eb_ring(e), e->name);
igt_subtest_f("signal-%s", e->name)
- fence_signal(device, handle, eb_ring(e), e->name, 5);
+ fence_signal(device, handle, eb_ring(e), e->name, 2);
}
igt_subtest("signal-all")
- fence_signal(device, handle, ALL_ENGINES, "all", 150);
+ fence_signal(device, handle, ALL_ENGINES, "all", 20);
igt_subtest("series")
- series(device, handle, 150);
+ series(device, handle, 20);
igt_subtest("parallel")
- parallel(device, handle, 150);
+ parallel(device, handle, 20);
igt_subtest("sequential")
- sequential(device, handle, 0, 150);
+ sequential(device, handle, 0, 20);
igt_subtest("forked-sequential")
- sequential(device, handle, FORKED, 150);
+ sequential(device, handle, FORKED, 20);
igt_subtest("chained-sequential")
- sequential(device, handle, FORKED | CHAINED, 150);
+ sequential(device, handle, FORKED | CHAINED, 20);
igt_subtest("context-sequential")
- sequential(device, handle, FORKED | CONTEXT, 150);
+ sequential(device, handle, FORKED | CONTEXT, 20);
igt_subtest_group {
igt_fixture {
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/4] i915/gem_sync: Reduce runtime
Reduce the upper timeout for stress tests from 150s to a mere 20s, and
quick tests to 2s.
Signed-off-by: Chris Wilson
---
tests/i915/gem_sync.c | 60 +--
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/tests/i915/gem_sync.c b/tests/i915/gem_sync.c
index 0010ac103..2ef55ecc0 100644
--- a/tests/i915/gem_sync.c
+++ b/tests/i915/gem_sync.c
@@ -1224,67 +1224,67 @@ igt_main
for (e = intel_execution_engines; e->name; e++) {
igt_subtest_f("%s", e->name)
- sync_ring(fd, eb_ring(e), 1, 150);
+ sync_ring(fd, eb_ring(e), 1, 20);
igt_subtest_f("idle-%s", e->name)
- idle_ring(fd, eb_ring(e), 150);
+ idle_ring(fd, eb_ring(e), 20);
igt_subtest_f("active-%s", e->name)
- active_ring(fd, eb_ring(e), 150);
+ active_ring(fd, eb_ring(e), 20);
igt_subtest_f("wakeup-%s", e->name)
- wakeup_ring(fd, eb_ring(e), 150, 1);
+ wakeup_ring(fd, eb_ring(e), 20, 1);
igt_subtest_f("active-wakeup-%s", e->name)
- active_wakeup_ring(fd, eb_ring(e), 150, 1);
+ active_wakeup_ring(fd, eb_ring(e), 20, 1);
igt_subtest_f("double-wakeup-%s", e->name)
- wakeup_ring(fd, eb_ring(e), 150, 2);
+ wakeup_ring(fd, eb_ring(e), 20, 2);
igt_subtest_f("store-%s", e->name)
- store_ring(fd, eb_ring(e), 1, 150);
+ store_ring(fd, eb_ring(e), 1, 20);
igt_subtest_f("switch-%s", e->name)
- switch_ring(fd, eb_ring(e), 1, 150);
+ switch_ring(fd, eb_ring(e), 1, 20);
igt_subtest_f("forked-switch-%s", e->name)
- switch_ring(fd, eb_ring(e), ncpus, 150);
+ switch_ring(fd, eb_ring(e), ncpus, 20);
igt_subtest_f("many-%s", e->name)
- store_many(fd, eb_ring(e), 150);
+ store_many(fd, eb_ring(e), 20);
igt_subtest_f("forked-%s", e->name)
- sync_ring(fd, eb_ring(e), ncpus, 150);
+ sync_ring(fd, eb_ring(e), ncpus, 20);
igt_subtest_f("forked-store-%s", e->name)
- store_ring(fd, eb_ring(e), ncpus, 150);
+ store_ring(fd, eb_ring(e), ncpus, 20);
}
igt_subtest("basic-each")
- sync_ring(fd, ALL_ENGINES, 1, 5);
+ sync_ring(fd, ALL_ENGINES, 1, 2);
igt_subtest("basic-store-each")
- store_ring(fd, ALL_ENGINES, 1, 5);
+ store_ring(fd, ALL_ENGINES, 1, 2);
igt_subtest("basic-many-each")
- store_many(fd, ALL_ENGINES, 5);
+ store_many(fd, ALL_ENGINES, 2);
igt_subtest("switch-each")
- switch_ring(fd, ALL_ENGINES, 1, 150);
+ switch_ring(fd, ALL_ENGINES, 1, 20);
igt_subtest("forked-switch-each")
- switch_ring(fd, ALL_ENGINES, ncpus, 150);
+ switch_ring(fd, ALL_ENGINES, ncpus, 20);
igt_subtest("forked-each")
- sync_ring(fd, ALL_ENGINES, ncpus, 150);
+ sync_ring(fd, ALL_ENGINES, ncpus, 20);
igt_subtest("forked-store-each")
- store_ring(fd, ALL_ENGINES, ncpus, 150);
+ store_ring(fd, ALL_ENGINES, ncpus, 20);
igt_subtest("active-each")
- active_ring(fd, ALL_ENGINES, 150);
+ active_ring(fd, ALL_ENGINES, 20);
igt_subtest("wakeup-each")
- wakeup_ring(fd, ALL_ENGINES, 150, 1);
+ wakeup_ring(fd, ALL_ENGINES, 20, 1);
igt_subtest("active-wakeup-each")
- active_wakeup_ring(fd, ALL_ENGINES, 150, 1);
+ active_wakeup_ring(fd, ALL_ENGINES, 20, 1);
igt_subtest("double-wakeup-each")
- wakeup_ring(fd, ALL_ENGINES, 150, 2);
+ wakeup_ring(fd, ALL_ENGINES, 20, 2);
igt_subtest("basic-all")
- sync_all(fd, 1, 5);
+ sync_all(fd, 1, 2);
igt_subtest("basic-store-all")
- store_all(fd, 1, 5);
+ store_all(fd, 1, 2);
igt_subtest("all")
- sync_all(fd, 1, 150);
+ sync_all(fd, 1, 20);
igt_subtest("store-all")
- store_all(fd, 1, 150);
+ store_all(fd, 1, 20);
igt_subtest("forked-all")
- sync_all(fd, ncpus, 150);
+ sync_all(fd, ncpus, 20);
igt_subtest("forked-store-all")
- store_all(fd, ncpus, 150);
+ store_all(fd, ncpus, 20);
igt_subtest_group {
igt_fixture {
@@ -1298,7 +1298,7 @@ igt_main
for (e = intel_exec
[Intel-gfx] [PATCH i-g-t 3/4] i915/gem_ctx_create: Reduce runtime
Reduce the upper timeout for stress tests from 150s to a mere 20s, and
quick tests to 2s.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_create.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_ctx_create.c b/tests/i915/gem_ctx_create.c
index 83da05690..d9a820e21 100644
--- a/tests/i915/gem_ctx_create.c
+++ b/tests/i915/gem_ctx_create.c
@@ -566,16 +566,16 @@ igt_main
maximum(fd, ncpus, CHECK_RAM | CHECK_SWAP);
igt_subtest("basic-files")
- files(fd, 5, 1);
+ files(fd, 2, 1);
igt_subtest("files")
- files(fd, 150, 1);
+ files(fd, 20, 1);
igt_subtest("forked-files")
- files(fd, 150, ncpus);
+ files(fd, 20, ncpus);
igt_subtest("active-all")
- active(fd, ALL_ENGINES, 120, 1);
+ active(fd, ALL_ENGINES, 20, 1);
igt_subtest("forked-active-all")
- active(fd, ALL_ENGINES, 120, ncpus);
+ active(fd, ALL_ENGINES, 20, ncpus);
for (const struct intel_execution_engine *e = intel_execution_engines;
e->name; e++) {
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/4] i915/gem_ctx_switch: Reduce runtime
Reduce the upper timeout for stress tests from 150s to a mere 20s, and
quick tests to 2s.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_switch.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_ctx_switch.c b/tests/i915/gem_ctx_switch.c
index 6bbd24972..2f94e326f 100644
--- a/tests/i915/gem_ctx_switch.c
+++ b/tests/i915/gem_ctx_switch.c
@@ -364,18 +364,18 @@ igt_main
}
igt_subtest_f("legacy-%s%s", e->name, p->name)
- single(fd, light, e2, p->flags, 1, 5);
+ single(fd, light, e2, p->flags, 1, 2);
igt_subtest_f("legacy-%s-heavy%s",
e->name, p->name)
- single(fd, heavy, e2, p->flags, 1, 5);
+ single(fd, heavy, e2, p->flags, 1, 2);
igt_subtest_f("legacy-%s-forked%s",
e->name, p->name)
single(fd, light, e2, p->flags, ncpus,
- 150);
+ 20);
igt_subtest_f("legacy-%s-forked-heavy%s",
e->name, p->name)
single(fd, heavy, e2, p->flags, ncpus,
- 150);
+ 20);
}
}
}
@@ -390,33 +390,33 @@ igt_main
}
igt_subtest_f("%s%s", e2->name, p->name)
- single(fd, light, e2, p->flags, 1, 5);
+ single(fd, light, e2, p->flags, 1, 2);
igt_subtest_f("%s-heavy%s", e2->name, p->name)
- single(fd, heavy, e2, p->flags, 1, 5);
+ single(fd, heavy, e2, p->flags, 1, 2);
igt_subtest_f("%s-forked%s", e2->name, p->name)
single(fd, light, e2, p->flags, ncpus,
- 150);
+ 20);
igt_subtest_f("%s-forked-heavy%s",
e2->name, p->name)
single(fd, heavy, e2, p->flags, ncpus,
- 150);
+ 20);
}
}
}
igt_subtest("all-light")
- all(fd, light, 0, 5);
+ all(fd, light, 0, 2);
igt_subtest("all-heavy")
- all(fd, heavy, 0, 5);
+ all(fd, heavy, 0, 2);
igt_subtest_group {
igt_fixture {
igt_require(gem_has_queues(fd));
}
igt_subtest("queue-light")
- all(fd, light, QUEUE, 5);
+ all(fd, light, QUEUE, 2);
igt_subtest("queue-heavy")
- all(fd, heavy, QUEUE, 5);
+ all(fd, heavy, QUEUE, 2);
}
igt_fixture {
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros
Quoting Daniel Vetter (2020-01-27 09:05:57) > On Sat, Jan 25, 2020 at 04:08:39PM +, Chris Wilson wrote: > > Quoting Wambui Karuga (2020-01-22 12:57:48) > > > This series is a part of the conversion to the new struct drm_device > > > based logging macros in drm/i915. > > > This series focuses on the drm/i915/gem directory and converts all > > > straightforward instances of the printk based logging macros to the new > > > macros. > > > > Overall, I'm not keen on this as it perpetuates the mistake of putting > > client debug message in dmesg and now gives them even more an air of > > being device driver debug messages. We need a mechanism by which we > > report the details of what a client did wrong back to that client > > (tracefs + context/client getparam to return an isolated debug fd is my > > idea). > > Sean is working on that, but it's a global thing still. Go look at how I suggest we can use tracefs in that thread :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros
On Mon, Jan 27, 2020 at 09:08:01AM +, Chris Wilson wrote: > Quoting Daniel Vetter (2020-01-27 09:05:57) > > On Sat, Jan 25, 2020 at 04:08:39PM +, Chris Wilson wrote: > > > Quoting Wambui Karuga (2020-01-22 12:57:48) > > > > This series is a part of the conversion to the new struct drm_device > > > > based logging macros in drm/i915. > > > > This series focuses on the drm/i915/gem directory and converts all > > > > straightforward instances of the printk based logging macros to the new > > > > macros. > > > > > > Overall, I'm not keen on this as it perpetuates the mistake of putting > > > client debug message in dmesg and now gives them even more an air of > > > being device driver debug messages. We need a mechanism by which we > > > report the details of what a client did wrong back to that client > > > (tracefs + context/client getparam to return an isolated debug fd is my > > > idea). > > > > Sean is working on that, but it's a global thing still. > > Go look at how I suggest we can use tracefs in that thread :) Hm I think we're a few threads further already? Steven Rostedt has jumped in now too ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
On Fri, Jan 24, 2020 at 06:39:26PM +, Chris Wilson wrote:
> Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47)
> > On 1/24/20 2:01 PM, Chris Wilson wrote:
> > > Since drm_global_mutex is a true global mutex across devices, we don't
> > > want to acquire it unless absolutely necessary. For maintaining the
> > > device local open_count, we can use atomic operations on the counter
> > > itself, except when making the transition to/from 0. Here, we tackle the
> > > easy portion of delaying acquiring the drm_global_mutex for the final
> > > release by using atomic_dec_and_mutex_lock(), leaving the global
> > > serialisation across the device opens.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Thomas Hellström (VMware)
> >
> > For the series:
> >
> > Reviewed-by: Thomas Hellström
>
> Now being opt-in, it is fairly limited in scope and will not randomly
> break others (touch wood) and the close() racing in BAT didn't throw
> anything up, so pushed to drm-misc-next. Thanks for the review and
> suggestions,
Yeah this version looks reasonable compared to the previous few (I'm
catching up on dri-devel). I've looked at getting rid of the global_mutex,
and all I have is a simple patch with a pile of notes. It's real nasty.
This one here is a neat trick that I missed, and I'm semi-convinced it's safe
:-)
> Next task is to suggest others might like to use it as well.
My idea for the opt-in was to look at whether ->load/->unload exists. And
ofc not bother with any of this for DRIVER_LEGACY. So maybe next step
would be to define a
drm_can_noglobal()
{
return !DRIVER_LEGACY && !->load && !->unload;
}
and inline the close helper again and see what breaks? At least from what
I've looked trying to duplicate paths and opt-in is going to be real tough
on the open side of things. Best I've done thus far is minor pushing of
the critical section.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Fix OA context id overlap with idle context id
On 27/01/2020 07:30, Umesh Nerlige Ramappa wrote:
On Sat, Jan 25, 2020 at 03:37:38AM +0200, Lionel Landwerlin wrote:
On 24/01/2020 03:37, Umesh Nerlige Ramappa wrote:
Engine context pinned in perf OA was set to same context id as
the idle context. Set the context id to an unused value.
Clear the sw context id field in lrc descriptor before ORing with
ce->tag (Chris)
Fixes: https://gitlab.freedesktop.org/drm/intel/issues/756
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a13a8c4b65ab..cf6c43bd540a 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1211,12 +1211,12 @@ __execlists_schedule_in(struct i915_request
*rq)
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
execlists_check_context(ce, engine);
+ ce->lrc_desc &= ~GENMASK_ULL(47, 37);
if (ce->tag) {
/* Use a fixed tag for OA and friends */
ce->lrc_desc |= (u64)ce->tag << 32;
} else {
/* We don't need a strict matching tag, just different
values */
- ce->lrc_desc &= ~GENMASK_ULL(47, 37);
I guess you can remove the line just above.
Not sure what you mean, the line is moved from here to above the if.
Oh sorry, Looking at the responding email, the '-' didn't appear :(
ce->lrc_desc |=
(u64)(++engine->context_tag % NUM_CONTEXT_TAG) <<
GEN11_SW_CTX_ID_SHIFT;
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 3c4647054557..5bd878c64504 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1323,7 +1323,12 @@ static int oa_get_render_ctx_id(struct
i915_perf_stream *stream)
case 12: {
stream->specific_ctx_id_mask =
((1U << GEN11_SW_CTX_ID_WIDTH) - 1) <<
(GEN11_SW_CTX_ID_SHIFT - 32);
- stream->specific_ctx_id = stream->specific_ctx_id_mask;
+ /* Pick an unused context id
+ * 0 - (NUM_CONTEXT_TAG - 1) are used by other contexts
+ * GEN12_MAX_CONTEXT_HW_ID (0x7ff) is used by idle context
+ */
+ stream->specific_ctx_id = (GEN12_MAX_CONTEXT_HW_ID - 1) <<
(GEN11_SW_CTX_ID_SHIFT - 32);
+ BUILD_BUG_ON((GEN12_MAX_CONTEXT_HW_ID - 1) < NUM_CONTEXT_TAG);
Arg yeah, we can't use an id that has all bits to 1 because that
matches the idle value in the OA reports :/
This also affects gen8-10 cases (afaik).
For gen8-10, I did not see a specific definition for an idle context
id. The from/to idle context switches are indicated by dedicated bits
in the CSB instead (from spec).
I meant that I remember the periodic OA reports when HW is idle to have
the contex_id=0x.
I could remember wrong :/
-Lionel
Thanks,
Umesh
Thanks for spotting this!
-Lionel
break;
}
@@ -1331,7 +1336,7 @@ static int oa_get_render_ctx_id(struct
i915_perf_stream *stream)
MISSING_CASE(INTEL_GEN(ce->engine->i915));
}
- ce->tag = stream->specific_ctx_id_mask;
+ ce->tag = stream->specific_ctx_id;
DRM_DEBUG_DRIVER("filtering on ctx_id=0x%x ctx_id_mask=0x%x\n",
stream->specific_ctx_id,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 6/6] drm/i915/pm: use intel de functions for forcewake register access
On Thu, 23 Jan 2020, Chris Wilson wrote: > Quoting Ville Syrjälä (2020-01-23 14:16:46) >> On Thu, Jan 23, 2020 at 04:00:04PM +0200, Jani Nikula wrote: >> > Move away from I915_READ_FW() and I915_WRITE_FW() in display code, and >> > switch to using intel_de_read_fw() and intel_de_write_fw(), >> > respectively. >> > >> > No functional changes. >> > >> > Signed-off-by: Jani Nikula >> >> Only a few oddities spotted. Overall series lgtm > > Concurred, checkpatch is going to have some very stern words regarding > some of those lines! > >> For all >> Reviewed-by: Ville Syrjälä > > +1 > Reviewed-by: Chris Wilson Thanks for the reviews, I pushed the ones *not* in display/ with hopes we'll do the mass conversion there (the other series). BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Release filp before global lock
On Fri, Jan 24, 2020 at 12:56:26PM +, Chris Wilson wrote:
> The file is not part of the global drm resource and can be released
> prior to take the global mutex to drop the open_count (and potentially
> close) the drm device. As the global mutex is indeed global, not only
> within the device but across devices, a slow file release mechanism can
> bottleneck the entire system.
>
> However, inside drm_close_helper() there are a number of dev->driver
> callbacks that take the drm_device as the first parameter... Worryingly
> some of those callbacks may be (implicitly) depending on the global
> mutex.
>
> v2: Drop the debug message for the open-count, it's included with the
> drm_file_free() debug message -- and for good measure make that up as
> reading outside of the mutex.
>
> v3: Separate the calling of the filp cleanup outside of
> drm_global_mutex into a new drm_release_noglobal() hook, so that we can
> phase the transition. drm/savage relies on the global mutex, and there
> may be more, so be cautious.
>
> Signed-off-by: Chris Wilson
> Cc: Thomas Hellström (VMware)
> Acked-by: Thomas Hellström (VMware)
> ---
> drivers/gpu/drm/drm_file.c | 36 -
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> include/drm/drm_file.h | 1 +
> 3 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 92d16724f949..e25306c49cc6 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -220,7 +220,7 @@ void drm_file_free(struct drm_file *file)
> DRM_DEBUG("pid = %d, device = 0x%lx, open_count = %d\n",
> task_pid_nr(current),
> (long)old_encode_dev(file->minor->kdev->devt),
> - dev->open_count);
> + READ_ONCE(dev->open_count));
>
> if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> dev->driver->preclose)
> @@ -455,6 +455,40 @@ int drm_release(struct inode *inode, struct file *filp)
> }
> EXPORT_SYMBOL(drm_release);
>
> +/**
> + * drm_release_noglobal - release method for DRM file
> + * @inode: device inode
> + * @filp: file pointer.
> + *
> + * This function may be used by drivers as their &file_operations.release
> + * method. It frees any resources associated with the open file prior to
> taking
> + * the drm_global_mutex, which then calls the &drm_driver.postclose driver
> + * callback. If this is the last open file for the DRM device also proceeds
> to
> + * call the &drm_driver.lastclose driver callback.
> + *
> + * RETURNS:
> + *
> + * Always succeeds and returns 0.
> + */
> +int drm_release_noglobal(struct inode *inode, struct file *filp)
> +{
> + struct drm_file *file_priv = filp->private_data;
> + struct drm_minor *minor = file_priv->minor;
> + struct drm_device *dev = minor->dev;
> +
> + drm_close_helper(filp);
> +
> + mutex_lock(&drm_global_mutex);
> + if (!--dev->open_count)
> + drm_lastclose(dev);
> + mutex_unlock(&drm_global_mutex);
btw my rough idea for lastclose is that we're just going to make it racy,
and then use the master lock and drm_client infrastructure to handle
fights between fbcon and a restarted compositor. That's already how that's
handled everywhere else. We might need to cut over drivers to the generic
fbcon stuff (or at least steal parts of the drm_client stuff I think), but
not sure.
-Daniel
> +
> + drm_minor_release(minor);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_release_noglobal);
> +
> /**
> * drm_read - read method for DRM file
> * @filp: file pointer
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e9b42e962032..5a5846d892f4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2673,7 +2673,7 @@ const struct dev_pm_ops i915_pm_ops = {
> static const struct file_operations i915_driver_fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> - .release = drm_release,
> + .release = drm_release_noglobal,
> .unlocked_ioctl = drm_ioctl,
> .mmap = i915_gem_mmap,
> .poll = drm_poll,
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 8b099b347817..19df8028a6c4 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -374,6 +374,7 @@ int drm_open(struct inode *inode, struct file *filp);
> ssize_t drm_read(struct file *filp, char __user *buffer,
>size_t count, loff_t *offset);
> int drm_release(struct inode *inode, struct file *filp);
> +int drm_release_noglobal(struct inode *inode, struct file *filp);
> __poll_t drm_poll(struct file *filp, struct poll_table_struct *wait);
> int drm_event_reserve_init_locked(struct drm_device *dev,
> struct drm_file *file_priv,
> --
> 2.25.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
Re: [Intel-gfx] [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros
On Sat, 25 Jan 2020, Chris Wilson wrote: > Quoting Wambui Karuga (2020-01-22 12:57:48) >> This series is a part of the conversion to the new struct drm_device >> based logging macros in drm/i915. >> This series focuses on the drm/i915/gem directory and converts all >> straightforward instances of the printk based logging macros to the new >> macros. > > Overall, I'm not keen on this as it perpetuates the mistake of putting > client debug message in dmesg and now gives them even more an air of > being device driver debug messages. We need a mechanism by which we > report the details of what a client did wrong back to that client > (tracefs + context/client getparam to return an isolated debug fd is my > idea). I don't disagree, but I also don't think this makes things (much) worse in that regard. > >> Wambui Karuga (2): >> drm/i915/gem: initial conversion to new logging macros using >> coccinelle. >> drm/i915/gem: manual conversion to struct drm_device logging macros. > > Still this is a necessary evil for the current situation, > Acked-by: Chris Wilson Thanks, pushed both. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI i-g-t 2/2] tests/i915/gem_exec_parallel:Set engine map to default context
From: Sreedhar Telukuntla
Set the potential engine map of the parent client's default
context to the newly created DRM client's default context.
Without doing so there is a mismatch between the intended
and actual engine used by the *-fds subtests.
v2: Fix FDS flags check
Tvrtko:
v3: Use new helper gem_context_copy_engines.
Signed-off-by: Sreedhar Telukuntla
Cc: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
tests/i915/gem_exec_parallel.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_exec_parallel.c b/tests/i915/gem_exec_parallel.c
index cfbe78070873..0d4d6c6283e0 100644
--- a/tests/i915/gem_exec_parallel.c
+++ b/tests/i915/gem_exec_parallel.c
@@ -83,10 +83,12 @@ static void *thread(void *data)
pthread_cond_wait(t->cond, t->mutex);
pthread_mutex_unlock(t->mutex);
- if (t->flags & FDS)
+ if (t->flags & FDS) {
fd = drm_open_driver(DRIVER_INTEL);
- else
+ gem_context_copy_engines(t->fd, 0, fd, 0);
+ } else {
fd = t->fd;
+ }
i = 0;
batch[i] = MI_STORE_DWORD_IMM | (t->gen < 6 ? 1 << 22 : 0);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI i-g-t 1/2] lib/i915: Add helper for copying engine maps from one context to another
From: Tvrtko Ursulin
We also need to support copying across file descriptors.
v2:
* Copy over even if src is unset. (Chris)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Sreedhar Telukuntla
Reviewed-by: Chris Wilson
---
lib/i915/gem_context.c | 30 ++
lib/i915/gem_context.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/lib/i915/gem_context.c b/lib/i915/gem_context.c
index 0b6a554dfe27..50dfee3d1030 100644
--- a/lib/i915/gem_context.c
+++ b/lib/i915/gem_context.c
@@ -462,3 +462,33 @@ bool gem_context_has_engine(int fd, uint32_t ctx, uint64_t
engine)
return __gem_execbuf(fd, &execbuf) == -ENOENT;
}
+
+/**
+ * gem_context_copy_engines:
+ * @src_fd: open i915 drm file descriptor where @src context belongs to
+ * @src: source engine map context id
+ * @dst_fd: open i915 drm file descriptor where @dst context belongs to
+ * @dst: destination engine map context id
+ *
+ * Special purpose helper for copying engine map from one context to another.
+ *
+ * In can be called regardless of whether the kernel supports context engine
+ * maps and is a no-op if not supported.
+ */
+void
+gem_context_copy_engines(int src_fd, uint32_t src, int dst_fd, uint32_t dst)
+{
+ I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, I915_EXEC_RING_MASK + 1);
+ struct drm_i915_gem_context_param param = {
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .ctx_id = src,
+ .size = sizeof(engines),
+ .value = to_user_pointer(&engines),
+ };
+
+ if (__gem_context_get_param(src_fd, ¶m))
+ return;
+
+ param.ctx_id = dst;
+ gem_context_set_param(dst_fd, ¶m);
+}
diff --git a/lib/i915/gem_context.h b/lib/i915/gem_context.h
index cf2ba33fee8f..15e5db281b79 100644
--- a/lib/i915/gem_context.h
+++ b/lib/i915/gem_context.h
@@ -42,6 +42,8 @@ uint32_t gem_context_clone(int i915,
uint32_t src, unsigned int share,
unsigned int flags);
uint32_t gem_context_clone_with_engines(int i915, uint32_t src);
+void gem_context_copy_engines(int src_fd, uint32_t src,
+ int dst_fd, uint32_t dst);
uint32_t gem_queue_create(int i915);
uint32_t gem_queue_clone_with_engines(int i915, uint32_t src);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915_pm_rps: Be wary if RP0 == RPn
Chris Wilson writes:
> If the HW min/max frequencies are the same, there is not much range to
> deal with and a couple of our invalid tests become confused as they are
> actually no-ops.
>
> Error reporting in i915_pm_rps is rudimentary and we deserve better.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1008
> Signed-off-by: Chris Wilson
> ---
> tests/i915/i915_pm_rps.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index b65eefb03..56c745a5b 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -397,9 +397,11 @@ static void min_max_config(void (*check)(void), bool
> load_gpu)
> writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0] + 1000);
> check();
>
> - igt_debug("\nDecrease max to RPn (invalid)...\n");
> - writeval_inval(sysfs_files[MAX].filp, origfreqs[RPn]);
> - check();
> + if (origfreqs[RPn] < origfreqs[RP0]) {
> + igt_debug("\nDecrease max to RPn (invalid)...\n");
> + writeval_inval(sysfs_files[MAX].filp, origfreqs[RPn]);
> + check();
> + }
>
> igt_debug("\nDecrease min to midpoint...\n");
> writeval(sysfs_files[MIN].filp, fmid);
> @@ -429,9 +431,11 @@ static void min_max_config(void (*check)(void), bool
> load_gpu)
> writeval_inval(sysfs_files[MAX].filp, 0);
> check();
>
> - igt_debug("\nIncrease min to RP0 (invalid)...\n");
> - writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0]);
> - check();
> + if (origfreqs[RP0] > origfreqs[RP0]) {
RPn?
-Mika
> + igt_debug("\nIncrease min to RP0 (invalid)...\n");
> + writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0]);
> + check();
> + }
>
> igt_debug("\nIncrease max to midpoint...\n");
> writeval(sysfs_files[MAX].filp, fmid);
> --
> 2.25.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix the timing parameters
On Fri, 24 Jan 2020, Jani Nikula wrote:
> On Fri, 24 Jan 2020, Vandita Kulkarni wrote:
>> Fix htotal and vtotal parameters derived from
>> DTD block of VBT.
>>
>> Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
>> Signed-off-by: Vandita Kulkarni
>
> Reviewed-by: Jani Nikula
And pushed, thanks for the patch. Amended the commit message to explain
that the total values were missing the back porch size.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/display/intel_bios.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index 1e675aa55938..942a073d5768 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -366,14 +366,16 @@ parse_generic_dtd(struct drm_i915_private *dev_priv,
>> panel_fixed_mode->hdisplay + dtd->hfront_porch;
>> panel_fixed_mode->hsync_end =
>> panel_fixed_mode->hsync_start + dtd->hsync;
>> -panel_fixed_mode->htotal = panel_fixed_mode->hsync_end;
>> +panel_fixed_mode->htotal =
>> +panel_fixed_mode->hdisplay + dtd->hblank;
>>
>> panel_fixed_mode->vdisplay = dtd->vactive;
>> panel_fixed_mode->vsync_start =
>> panel_fixed_mode->vdisplay + dtd->vfront_porch;
>> panel_fixed_mode->vsync_end =
>> panel_fixed_mode->vsync_start + dtd->vsync;
>> -panel_fixed_mode->vtotal = panel_fixed_mode->vsync_end;
>> +panel_fixed_mode->vtotal =
>> +panel_fixed_mode->vdisplay + dtd->vblank;
>>
>> panel_fixed_mode->clock = dtd->pixel_clock;
>> panel_fixed_mode->width_mm = dtd->width_mm;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_pipe_control_store_loop: Limit runtime
Chris Wilson writes:
> Use a runtime limit, not a fixed amount of work, so that it doesn't take
> several hundred seconds on the slower machines.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_pipe_control_store_loop.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/i915/gem_pipe_control_store_loop.c
> b/tests/i915/gem_pipe_control_store_loop.c
> index b8a21d780..9330a47c8 100644
> --- a/tests/i915/gem_pipe_control_store_loop.c
> +++ b/tests/i915/gem_pipe_control_store_loop.c
> @@ -62,13 +62,13 @@ uint32_t devid;
>
> /* Like the store dword test, but we create new command buffers each time */
> static void
> -store_pipe_control_loop(bool preuse_buffer)
> +store_pipe_control_loop(bool preuse_buffer, int timeout)
> {
> int i, val = 0;
> uint32_t *buf;
> drm_intel_bo *target_bo;
>
> - for (i = 0; i < SLOW_QUICK(0x1, 4); i++) {
> + igt_until_timeout(timeout) {
> /* we want to check tlb consistency of the pipe_control target,
>* so get a new buffer every time around */
> target_bo = drm_intel_bo_alloc(bufmgr, "target bo", 4096, 4096);
> @@ -182,10 +182,10 @@ igt_main
> }
>
> igt_subtest("fresh-buffer")
> - store_pipe_control_loop(false);
> + store_pipe_control_loop(false, 2);
>
> igt_subtest("reused-buffer")
> - store_pipe_control_loop(true);
> + store_pipe_control_loop(true, 2);
>
> igt_fixture {
> intel_batchbuffer_free(batch);
> --
> 2.25.0
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915_pm_rps: Be wary if RP0 == RPn
Quoting Mika Kuoppala (2020-01-27 09:54:25)
> Chris Wilson writes:
>
> > If the HW min/max frequencies are the same, there is not much range to
> > deal with and a couple of our invalid tests become confused as they are
> > actually no-ops.
> >
> > Error reporting in i915_pm_rps is rudimentary and we deserve better.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/issues/1008
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/i915_pm_rps.c | 16 ++--
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > index b65eefb03..56c745a5b 100644
> > --- a/tests/i915/i915_pm_rps.c
> > +++ b/tests/i915/i915_pm_rps.c
> > @@ -397,9 +397,11 @@ static void min_max_config(void (*check)(void), bool
> > load_gpu)
> > writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0] + 1000);
> > check();
> >
> > - igt_debug("\nDecrease max to RPn (invalid)...\n");
> > - writeval_inval(sysfs_files[MAX].filp, origfreqs[RPn]);
> > - check();
> > + if (origfreqs[RPn] < origfreqs[RP0]) {
> > + igt_debug("\nDecrease max to RPn (invalid)...\n");
> > + writeval_inval(sysfs_files[MAX].filp, origfreqs[RPn]);
> > + check();
> > + }
> >
> > igt_debug("\nDecrease min to midpoint...\n");
> > writeval(sysfs_files[MIN].filp, fmid);
> > @@ -429,9 +431,11 @@ static void min_max_config(void (*check)(void), bool
> > load_gpu)
> > writeval_inval(sysfs_files[MAX].filp, 0);
> > check();
> >
> > - igt_debug("\nIncrease min to RP0 (invalid)...\n");
> > - writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0]);
> > - check();
> > + if (origfreqs[RP0] > origfreqs[RP0]) {
>
> RPn?
if (RP0 > RPn)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/auth: Drop master_create/destroy hooks
vmwgfx stopped using them.
With the drm device model that we've slowly evolved over the past few
years master status essentially controls access to display resources,
and nothing else. Since that's a pure access permission check drivers
should have no need at all to track additional state on a per file
basis.
Aside: For cleanup and restoring kernel-internal clients the grand
plan is to move everyone over to drm_client and
drm_master_internal_acquire/release, like the generic fbdev code
already does. That should get rid of most ->lastclose implementations,
and I think also subsumes any processing vmwgfx does in
master_set/drop.
Cc: "Thomas Hellström (VMware)"
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 8
include/drm/drm_drv.h | 14 --
2 files changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index cc9acd986c68..531b876d0ed8 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -153,11 +153,6 @@ static int drm_new_set_master(struct drm_device *dev,
struct drm_file *fpriv)
return -ENOMEM;
}
- if (dev->driver->master_create) {
- ret = dev->driver->master_create(dev, fpriv->master);
- if (ret)
- goto out_err;
- }
fpriv->is_master = 1;
fpriv->authenticated = 1;
@@ -332,9 +327,6 @@ static void drm_master_destroy(struct kref *kref)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_lease_destroy(master);
- if (dev->driver->master_destroy)
- dev->driver->master_destroy(dev, master);
-
drm_legacy_master_rmmaps(dev, master);
idr_destroy(&master->magic_map);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index f3f3e10873af..77bc63de0a91 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -460,20 +460,6 @@ struct drm_driver {
*/
void (*irq_uninstall) (struct drm_device *dev);
- /**
-* @master_create:
-*
-* Called whenever a new master is created. Only used by vmwgfx.
-*/
- int (*master_create)(struct drm_device *dev, struct drm_master *master);
-
- /**
-* @master_destroy:
-*
-* Called whenever a master is destroyed. Only used by vmwgfx.
-*/
- void (*master_destroy)(struct drm_device *dev, struct drm_master
*master);
-
/**
* @master_set:
*
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/4] i915/gem_sync: Reduce runtime
Chris Wilson writes:
> Reduce the upper timeout for stress tests from 150s to a mere 20s, and
> quick tests to 2s.
>
> Signed-off-by: Chris Wilson
This and the rest of the series,
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_sync.c | 60 +--
> 1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/tests/i915/gem_sync.c b/tests/i915/gem_sync.c
> index 0010ac103..2ef55ecc0 100644
> --- a/tests/i915/gem_sync.c
> +++ b/tests/i915/gem_sync.c
> @@ -1224,67 +1224,67 @@ igt_main
>
> for (e = intel_execution_engines; e->name; e++) {
> igt_subtest_f("%s", e->name)
> - sync_ring(fd, eb_ring(e), 1, 150);
> + sync_ring(fd, eb_ring(e), 1, 20);
> igt_subtest_f("idle-%s", e->name)
> - idle_ring(fd, eb_ring(e), 150);
> + idle_ring(fd, eb_ring(e), 20);
> igt_subtest_f("active-%s", e->name)
> - active_ring(fd, eb_ring(e), 150);
> + active_ring(fd, eb_ring(e), 20);
> igt_subtest_f("wakeup-%s", e->name)
> - wakeup_ring(fd, eb_ring(e), 150, 1);
> + wakeup_ring(fd, eb_ring(e), 20, 1);
> igt_subtest_f("active-wakeup-%s", e->name)
> - active_wakeup_ring(fd, eb_ring(e), 150, 1);
> + active_wakeup_ring(fd, eb_ring(e), 20, 1);
> igt_subtest_f("double-wakeup-%s", e->name)
> - wakeup_ring(fd, eb_ring(e), 150, 2);
> + wakeup_ring(fd, eb_ring(e), 20, 2);
> igt_subtest_f("store-%s", e->name)
> - store_ring(fd, eb_ring(e), 1, 150);
> + store_ring(fd, eb_ring(e), 1, 20);
> igt_subtest_f("switch-%s", e->name)
> - switch_ring(fd, eb_ring(e), 1, 150);
> + switch_ring(fd, eb_ring(e), 1, 20);
> igt_subtest_f("forked-switch-%s", e->name)
> - switch_ring(fd, eb_ring(e), ncpus, 150);
> + switch_ring(fd, eb_ring(e), ncpus, 20);
> igt_subtest_f("many-%s", e->name)
> - store_many(fd, eb_ring(e), 150);
> + store_many(fd, eb_ring(e), 20);
> igt_subtest_f("forked-%s", e->name)
> - sync_ring(fd, eb_ring(e), ncpus, 150);
> + sync_ring(fd, eb_ring(e), ncpus, 20);
> igt_subtest_f("forked-store-%s", e->name)
> - store_ring(fd, eb_ring(e), ncpus, 150);
> + store_ring(fd, eb_ring(e), ncpus, 20);
> }
>
> igt_subtest("basic-each")
> - sync_ring(fd, ALL_ENGINES, 1, 5);
> + sync_ring(fd, ALL_ENGINES, 1, 2);
> igt_subtest("basic-store-each")
> - store_ring(fd, ALL_ENGINES, 1, 5);
> + store_ring(fd, ALL_ENGINES, 1, 2);
> igt_subtest("basic-many-each")
> - store_many(fd, ALL_ENGINES, 5);
> + store_many(fd, ALL_ENGINES, 2);
> igt_subtest("switch-each")
> - switch_ring(fd, ALL_ENGINES, 1, 150);
> + switch_ring(fd, ALL_ENGINES, 1, 20);
> igt_subtest("forked-switch-each")
> - switch_ring(fd, ALL_ENGINES, ncpus, 150);
> + switch_ring(fd, ALL_ENGINES, ncpus, 20);
> igt_subtest("forked-each")
> - sync_ring(fd, ALL_ENGINES, ncpus, 150);
> + sync_ring(fd, ALL_ENGINES, ncpus, 20);
> igt_subtest("forked-store-each")
> - store_ring(fd, ALL_ENGINES, ncpus, 150);
> + store_ring(fd, ALL_ENGINES, ncpus, 20);
> igt_subtest("active-each")
> - active_ring(fd, ALL_ENGINES, 150);
> + active_ring(fd, ALL_ENGINES, 20);
> igt_subtest("wakeup-each")
> - wakeup_ring(fd, ALL_ENGINES, 150, 1);
> + wakeup_ring(fd, ALL_ENGINES, 20, 1);
> igt_subtest("active-wakeup-each")
> - active_wakeup_ring(fd, ALL_ENGINES, 150, 1);
> + active_wakeup_ring(fd, ALL_ENGINES, 20, 1);
> igt_subtest("double-wakeup-each")
> - wakeup_ring(fd, ALL_ENGINES, 150, 2);
> + wakeup_ring(fd, ALL_ENGINES, 20, 2);
>
> igt_subtest("basic-all")
> - sync_all(fd, 1, 5);
> + sync_all(fd, 1, 2);
> igt_subtest("basic-store-all")
> - store_all(fd, 1, 5);
> + store_all(fd, 1, 2);
>
> igt_subtest("all")
> - sync_all(fd, 1, 150);
> + sync_all(fd, 1, 20);
> igt_subtest("store-all")
> - store_all(fd, 1, 150);
> + store_all(fd, 1, 20);
> igt_subtest("forked-all")
> - sync_all(fd, ncpus, 150);
> + sync_all(fd, ncpus, 20);
> igt_subtest("forked-store-all")
> - store_all(fd, ncpus, 150);
> + store_all(fd, ncpus, 20);
>
>
[Intel-gfx] [PATCH i-g-t v2] i915_pm_rps: Be wary if RP0 == RPn
If the HW min/max frequencies are the same, there is not much range to
deal with and a couple of our invalid tests become confused as they are
actually no-ops.
Error reporting in i915_pm_rps is rudimentary and we deserve better.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1008
Signed-off-by: Chris Wilson
---
tests/i915/i915_pm_rps.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
index b65eefb03..cb1500d2f 100644
--- a/tests/i915/i915_pm_rps.c
+++ b/tests/i915/i915_pm_rps.c
@@ -397,9 +397,11 @@ static void min_max_config(void (*check)(void), bool
load_gpu)
writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0] + 1000);
check();
- igt_debug("\nDecrease max to RPn (invalid)...\n");
- writeval_inval(sysfs_files[MAX].filp, origfreqs[RPn]);
- check();
+ if (origfreqs[RPn] < origfreqs[RP0]) {
+ igt_debug("\nDecrease max to RPn (invalid)...\n");
+ writeval_inval(sysfs_files[MAX].filp, origfreqs[RPn]);
+ check();
+ }
igt_debug("\nDecrease min to midpoint...\n");
writeval(sysfs_files[MIN].filp, fmid);
@@ -429,9 +431,11 @@ static void min_max_config(void (*check)(void), bool
load_gpu)
writeval_inval(sysfs_files[MAX].filp, 0);
check();
- igt_debug("\nIncrease min to RP0 (invalid)...\n");
- writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0]);
- check();
+ if (origfreqs[RP0] > origfreqs[RPn]) {
+ igt_debug("\nIncrease min to RP0 (invalid)...\n");
+ writeval_inval(sysfs_files[MIN].filp, origfreqs[RP0]);
+ check();
+ }
igt_debug("\nIncrease max to midpoint...\n");
writeval(sysfs_files[MAX].filp, fmid);
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove 'prefault_disable' modparam
On Fri, 24 Jan 2020, Chris Wilson wrote:
> The 'prefault_disable' modparam was used by IGT to prevent a few
> prefaulting operations to make fault handling under struct_mutex more
> prominent. With the removal of struct_mutex, this is not as important
> any more and we have almost completely stopped using the parameter. The
> remaining use in execbuf is now immaterial and can be dropped without
> affecting coverage.
I'll eagerly ack the removal of almost any module parameter!
Acked-by: Jani Nikula
> We must re-address the idea of fault injection though.
>
> Signed-off-by: Chris Wilson
> Cc: Antonio Argenziano
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 ---
> drivers/gpu/drm/i915/i915_params.c | 4
> drivers/gpu/drm/i915/i915_params.h | 1 -
> 3 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 60c984e10c4a..358141e1593c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1643,9 +1643,6 @@ static int eb_prefault_relocations(const struct
> i915_execbuffer *eb)
> const unsigned int count = eb->buffer_count;
> unsigned int i;
>
> - if (unlikely(i915_modparams.prefault_disable))
> - return 0;
> -
> for (i = 0; i < count; i++) {
> int err;
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 9c8257cf88d0..add00ec1f787 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -103,10 +103,6 @@ i915_param_named(fastboot, int, 0600,
> "(0=disabled, 1=enabled) "
> "Default: -1 (use per-chip default)");
>
> -i915_param_named_unsafe(prefault_disable, bool, 0600,
> - "Disable page prefaulting for pread/pwrite/reloc (default:false). "
> - "For developers only.");
> -
> i915_param_named_unsafe(load_detect_test, bool, 0600,
> "Force-enable the VGA load detect code for testing (default:false). "
> "For developers only.");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index ef4069645cb8..cb16410c2ada 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -71,7 +71,6 @@ struct drm_printer;
> param(unsigned long, fake_lmem_start, 0, 0400) \
> /* leave bools at the end to not create holes */ \
> param(bool, enable_hangcheck, true, 0600) \
> - param(bool, prefault_disable, false, 0600) \
> param(bool, load_detect_test, false, 0600) \
> param(bool, force_reset_modeset_test, false, 0600) \
> param(bool, error_capture, true, 0600) \
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Squelch kerneldoc complaints
On Sun, 26 Jan 2020, Chris Wilson wrote: > drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter > or member 'state' not described in 'intel_connector_needs_modeset' > drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter > or member 'connector' not described in 'intel_connector_needs_modeset' > > drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Function parameter or > member 'state' not described in 'intel_fbc_enable' > drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function > parameter 'crtc_state' description in 'intel_fbc_enable' > drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function > parameter 'plane_state' description in 'intel_fbc_enable' Reviewed-by: Jani Nikula Arek, what does it take to enable automated documentation builds and error reporting on CI? > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/display/intel_atomic.c | 2 ++ > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > drivers/gpu/drm/i915/display/intel_fbc.c | 3 +-- > 3 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c > b/drivers/gpu/drm/i915/display/intel_atomic.c > index c362eecdd414..9921b1fa4e70 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic.c > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c > @@ -178,6 +178,8 @@ intel_digital_connector_duplicate_state(struct > drm_connector *connector) > > /** > * intel_connector_needs_modeset - check if connector needs a modeset > + * @state: the atomic state corresponding to this modeset > + * @connector: the connector > */ > bool > intel_connector_needs_modeset(struct intel_atomic_state *state, > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 9c81576dc43e..aaef06e19828 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -15861,7 +15861,7 @@ static void fb_obj_bump_render_priority(struct > drm_i915_gem_object *obj) > > /** > * intel_prepare_plane_fb - Prepare fb for usage on plane > - * @plane: drm plane to prepare for > + * @_plane: drm plane to prepare for > * @_new_plane_state: the plane state being prepared > * > * Prepares a framebuffer for usage on a display plane. Generally this > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c > b/drivers/gpu/drm/i915/display/intel_fbc.c > index 88a9c2fea695..d3be6f619b31 100644 > --- a/drivers/gpu/drm/i915/display/intel_fbc.c > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c > @@ -,8 +,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private > *dev_priv, > /** > * intel_fbc_enable: tries to enable FBC on the CRTC > * @crtc: the CRTC > - * @crtc_state: corresponding &drm_crtc_state for @crtc > - * @plane_state: corresponding &drm_plane_state for the primary plane of > @crtc > + * @state: corresponding &drm_crtc_state for @crtc > * > * This function checks if the given CRTC was chosen for FBC, then enables > it if > * possible. Notice that it doesn't activate FBC. It is valid to call -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Lift set-wedged engine dumping out of user paths
The user (e.g. gem_eio) can manipulate the driver into wedging itself,
allowing the user to trigger voluminous logging of inconsequential
details. If we lift the dump to direct calls to intel_gt_set_wedged(),
out of the intel_reset failure handling, we keep the detail logging for
what we expect are true HW or test failures without being tricked.
Reported-by: Tomi Sarvela
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tomi Sarvela
---
drivers/gpu/drm/i915/gt/intel_reset.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index beee0cf89bce..48b42adaffbd 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -800,13 +800,6 @@ static void __intel_gt_set_wedged(struct intel_gt *gt)
if (test_bit(I915_WEDGED, >->reset.flags))
return;
- if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(gt)) {
- struct drm_printer p = drm_debug_printer(__func__);
-
- for_each_engine(engine, gt, id)
- intel_engine_dump(engine, &p, "%s\n", engine->name);
- }
-
GT_TRACE(gt, "start\n");
/*
@@ -845,10 +838,23 @@ void intel_gt_set_wedged(struct intel_gt *gt)
{
intel_wakeref_t wakeref;
+ if (test_bit(I915_WEDGED, >->reset.flags))
+ return;
+
+ wakeref = intel_runtime_pm_get(gt->uncore->rpm);
mutex_lock(>->reset.mutex);
- with_intel_runtime_pm(gt->uncore->rpm, wakeref)
- __intel_gt_set_wedged(gt);
+
+ if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(gt)) {
+ struct drm_printer p = drm_debug_printer(__func__);
+
+ for_each_engine(engine, gt, id)
+ intel_engine_dump(engine, &p, "%s\n", engine->name);
+ }
+
+ __intel_gt_set_wedged(gt);
+
mutex_unlock(>->reset.mutex);
+ intel_runtime_pm_put(gt->uncore->rpm, wakeref);
}
static bool __intel_gt_unset_wedged(struct intel_gt *gt)
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Stub out i915_gpu_coredump_put
Hi Chris,
On Fri, Jan 24, 2020 at 07:22:55PM +, Chris Wilson wrote:
> i915_gpu_coreddump_put is currently only defined if
> CONFIG_DRM_I915_CAPTURE_ERROR is enabled, provide a stub otherwise.
>
> Reported-by: Mike Lothian
> Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capture")
> Fixes: 748317386afb ("drm/i915/execlists: Offline error capture")
> Signed-off-by: Chris Wilson
> Cc: Mike Lothian
> Cc: Andi Shyti
right!
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] 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.
Bspec: 49333
Signed-off-by: Kai Vehmanen
---
drivers/gpu/drm/i915/display/intel_audio.c | 16 +---
drivers/gpu/drm/i915/i915_reg.h| 4
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index b18040793d9e..78f744d220da 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -148,6 +148,10 @@ static const struct {
{ 74250, AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 },
{ 148352, AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 },
{ 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
+ { 296703, AUD_CONFIG_PIXEL_CLOCK_HDMI_296703 },
+ { 297000, AUD_CONFIG_PIXEL_CLOCK_HDMI_297000 },
+ { 593407, AUD_CONFIG_PIXEL_CLOCK_HDMI_593407 },
+ { 594000, AUD_CONFIG_PIXEL_CLOCK_HDMI_594000 },
};
/* HDMI N/CTS table */
@@ -231,13 +235,19 @@ static const struct hdmi_aud_ncts hdmi_aud_ncts_36bpp[] =
{
};
/* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
-static u32 audio_config_hdmi_pixel_clock(const struct intel_crtc_state
*crtc_state)
+static u32 audio_config_hdmi_pixel_clock(struct drm_i915_private *dev_priv,
+const struct intel_crtc_state
*crtc_state)
{
const struct drm_display_mode *adjusted_mode =
&crtc_state->hw.adjusted_mode;
int i;
for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
+ if (INTEL_GEN(dev_priv) < 12 &&
+ hdmi_audio_clock[i].clock > 148500) {
+ i = ARRAY_SIZE(hdmi_audio_clock);
+ break;
+ }
if (adjusted_mode->crtc_clock == hdmi_audio_clock[i].clock)
break;
}
@@ -433,7 +443,7 @@ hsw_hdmi_audio_config_update(struct intel_encoder *encoder,
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
- tmp |= audio_config_hdmi_pixel_clock(crtc_state);
+ tmp |= audio_config_hdmi_pixel_clock(dev_priv, crtc_state);
n = audio_config_hdmi_get_n(crtc_state, rate);
if (n != 0) {
@@ -673,7 +683,7 @@ static void ilk_audio_codec_enable(struct intel_encoder
*encoder,
if (intel_crtc_has_dp_encoder(crtc_state))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
else
- tmp |= audio_config_hdmi_pixel_clock(crtc_state);
+ tmp |= audio_config_hdmi_pixel_clock(dev_priv, crtc_state);
I915_WRITE(aud_config, tmp);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6cc55c103f67..61d9d045b2ff 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9241,6 +9241,10 @@ enum {
#define AUD_CONFIG_PIXEL_CLOCK_HDMI_74250(7 << 16)
#define AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 (8 << 16)
#define AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 (9 << 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_296703 (10 << 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_297000 (11 << 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_593407 (12 << 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_594000 (13 << 16)
#define AUD_CONFIG_DISABLE_NCTS (1 << 3)
/* HSW Audio */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dsi: Enable dsi as part of encoder->enable
Enable the dsi transcoder, panel and backlight as part
of encoder->enable and not encoder->pre_enable.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 1186a5df057e..d40ee5951168 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1086,8 +1086,6 @@ static void gen11_dsi_pre_enable(struct intel_encoder
*encoder,
const struct intel_crtc_state *pipe_config,
const struct drm_connector_state *conn_state)
{
- struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
-
/* step3b */
gen11_dsi_map_pll(encoder, pipe_config);
@@ -1101,6 +1099,13 @@ static void gen11_dsi_pre_enable(struct intel_encoder
*encoder,
/* step6c: configure transcoder timings */
gen11_dsi_set_transcoder_timings(encoder, pipe_config);
+}
+
+static void gen11_dsi_enable(struct intel_encoder *encoder,
+const struct intel_crtc_state *pipe_config,
+const struct drm_connector_state *conn_state)
+{
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
/* step6d: enable dsi transcoder */
gen11_dsi_enable_transcoder(encoder);
@@ -1727,6 +1732,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
encoder->pre_pll_enable = gen11_dsi_pre_pll_enable;
encoder->pre_enable = gen11_dsi_pre_enable;
+ encoder->enable = gen11_dsi_enable;
encoder->disable = gen11_dsi_disable;
encoder->post_disable = gen11_dsi_post_disable;
encoder->port = port;
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/auth: Drop master_create/destroy hooks
Am 27.01.20 um 11:02 schrieb Daniel Vetter:
> vmwgfx stopped using them.
>
> With the drm device model that we've slowly evolved over the past few
> years master status essentially controls access to display resources,
> and nothing else. Since that's a pure access permission check drivers
> should have no need at all to track additional state on a per file
> basis.
>
> Aside: For cleanup and restoring kernel-internal clients the grand
> plan is to move everyone over to drm_client and
> drm_master_internal_acquire/release, like the generic fbdev code
> already does. That should get rid of most ->lastclose implementations,
> and I think also subsumes any processing vmwgfx does in
> master_set/drop.
>
> Cc: "Thomas Hellström (VMware)"
> Signed-off-by: Daniel Vetter
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_auth.c | 8
> include/drm/drm_drv.h | 14 --
> 2 files changed, 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index cc9acd986c68..531b876d0ed8 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -153,11 +153,6 @@ static int drm_new_set_master(struct drm_device *dev,
> struct drm_file *fpriv)
> return -ENOMEM;
> }
>
> - if (dev->driver->master_create) {
> - ret = dev->driver->master_create(dev, fpriv->master);
> - if (ret)
> - goto out_err;
> - }
> fpriv->is_master = 1;
> fpriv->authenticated = 1;
>
> @@ -332,9 +327,6 @@ static void drm_master_destroy(struct kref *kref)
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_lease_destroy(master);
>
> - if (dev->driver->master_destroy)
> - dev->driver->master_destroy(dev, master);
> -
> drm_legacy_master_rmmaps(dev, master);
>
> idr_destroy(&master->magic_map);
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index f3f3e10873af..77bc63de0a91 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -460,20 +460,6 @@ struct drm_driver {
>*/
> void (*irq_uninstall) (struct drm_device *dev);
>
> - /**
> - * @master_create:
> - *
> - * Called whenever a new master is created. Only used by vmwgfx.
> - */
> - int (*master_create)(struct drm_device *dev, struct drm_master *master);
> -
> - /**
> - * @master_destroy:
> - *
> - * Called whenever a master is destroyed. Only used by vmwgfx.
> - */
> - void (*master_destroy)(struct drm_device *dev, struct drm_master
> *master);
> -
> /**
>* @master_set:
>*
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Enable dsi as part of encoder->enable
On Mon, 27 Jan 2020, Vandita Kulkarni wrote:
> Enable the dsi transcoder, panel and backlight as part
> of encoder->enable and not encoder->pre_enable.
That's the *what*, and we can see that much from the patch.
But we need to know *why*, and why you think it was done like this
before, and why it's okay now, etc.
BR,
Jani.
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 1186a5df057e..d40ee5951168 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1086,8 +1086,6 @@ static void gen11_dsi_pre_enable(struct intel_encoder
> *encoder,
>const struct intel_crtc_state *pipe_config,
>const struct drm_connector_state *conn_state)
> {
> - struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> -
> /* step3b */
> gen11_dsi_map_pll(encoder, pipe_config);
>
> @@ -1101,6 +1099,13 @@ static void gen11_dsi_pre_enable(struct intel_encoder
> *encoder,
>
> /* step6c: configure transcoder timings */
> gen11_dsi_set_transcoder_timings(encoder, pipe_config);
> +}
> +
> +static void gen11_dsi_enable(struct intel_encoder *encoder,
> + const struct intel_crtc_state *pipe_config,
> + const struct drm_connector_state *conn_state)
> +{
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>
> /* step6d: enable dsi transcoder */
> gen11_dsi_enable_transcoder(encoder);
> @@ -1727,6 +1732,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
>
> encoder->pre_pll_enable = gen11_dsi_pre_pll_enable;
> encoder->pre_enable = gen11_dsi_pre_enable;
> + encoder->enable = gen11_dsi_enable;
> encoder->disable = gen11_dsi_disable;
> encoder->post_disable = gen11_dsi_post_disable;
> encoder->port = port;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/auth: Drop master_create/destroy hooks
On 1/27/20 11:02 AM, Daniel Vetter wrote: vmwgfx stopped using them. With the drm device model that we've slowly evolved over the past few years master status essentially controls access to display resources, and nothing else. Since that's a pure access permission check drivers should have no need at all to track additional state on a per file basis. Aside: For cleanup and restoring kernel-internal clients the grand plan is to move everyone over to drm_client and drm_master_internal_acquire/release, like the generic fbdev code already does. That should get rid of most ->lastclose implementations, and I think also subsumes any processing vmwgfx does in master_set/drop. Cc: "Thomas Hellström (VMware)" Signed-off-by: Daniel Vetter Reviewed-by: Thomas Hellstrom ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs
We [will] expose various per-engine scheduling controls. One of which,
'preempt_timeout_ms', defines how we wait for a preemption request to be
honoured by the currently executing context. If it fails to relieve the
GPU within the required timeout, the engine is reset and the miscreant
forcibly evicted.
Signed-off-by: Chris Wilson
---
lib/i915/gem_context.c | 41
lib/i915/gem_context.h | 2 +
lib/i915/gem_engine_topology.c | 48 +
lib/i915/gem_engine_topology.h | 3 +
tests/Makefile.sources | 3 +
tests/i915/sysfs_preempt_timeout.c | 309 +
tests/meson.build | 1 +
7 files changed, 407 insertions(+)
create mode 100644 tests/i915/sysfs_preempt_timeout.c
diff --git a/lib/i915/gem_context.c b/lib/i915/gem_context.c
index 0b6a554df..fc874a187 100644
--- a/lib/i915/gem_context.c
+++ b/lib/i915/gem_context.c
@@ -462,3 +462,44 @@ bool gem_context_has_engine(int fd, uint32_t ctx, uint64_t
engine)
return __gem_execbuf(fd, &execbuf) == -ENOENT;
}
+
+static int create_ext_ioctl(int i915,
+ struct drm_i915_gem_context_create_ext *arg)
+{
+ int err;
+
+ err = 0;
+ if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+uint32_t gem_context_create_for_engine(int i915, unsigned int class, unsigned
int inst)
+{
+ I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = {
+ .engines = { { .engine_class = class, .engine_instance = inst }
}
+ };
+ struct drm_i915_gem_context_create_ext_setparam p_engines = {
+ .base = {
+ .name = I915_CONTEXT_CREATE_EXT_SETPARAM,
+ .next_extension = 0, /* end of chain */
+ },
+ .param = {
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(&engines),
+ .size = sizeof(engines),
+ },
+ };
+ struct drm_i915_gem_context_create_ext create = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ .extensions = to_user_pointer(&p_engines),
+ };
+
+ igt_assert_eq(create_ext_ioctl(i915, &create), 0);
+ igt_assert_neq(create.ctx_id, 0);
+ return create.ctx_id;
+}
diff --git a/lib/i915/gem_context.h b/lib/i915/gem_context.h
index cf2ba33fe..ded75bb9c 100644
--- a/lib/i915/gem_context.h
+++ b/lib/i915/gem_context.h
@@ -34,6 +34,8 @@ int __gem_context_create(int fd, uint32_t *ctx_id);
void gem_context_destroy(int fd, uint32_t ctx_id);
int __gem_context_destroy(int fd, uint32_t ctx_id);
+uint32_t gem_context_create_for_engine(int fd, unsigned int class, unsigned
int inst);
+
int __gem_context_clone(int i915,
uint32_t src, unsigned int share,
unsigned int flags,
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index 058983123..81faf3c15 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -22,6 +22,8 @@
*/
#include
+#include
+#include
#include
#include "drmtest.h"
@@ -415,3 +417,49 @@ uint32_t gem_engine_mmio_base(int i915, const char *engine)
return mmio;
}
+
+void dyn_sysfs_engines(int i915, int engines, const char *file,
+ void (*test)(int, int))
+{
+ char buf[512];
+ int len;
+
+ lseek(engines, 0, SEEK_SET);
+ while ((len = syscall(SYS_getdents64, engines, buf, sizeof(buf))) > 0) {
+ void *ptr = buf;
+
+ while (len) {
+ struct linux_dirent64 {
+ ino64_td_ino;
+ off64_td_off;
+ unsigned short d_reclen;
+ unsigned char d_type;
+ char d_name[];
+ } *de = ptr;
+ char *name;
+ int engine;
+
+ ptr += de->d_reclen;
+ len -= de->d_reclen;
+
+ engine = openat(engines, de->d_name, O_RDONLY);
+ name = igt_sysfs_get(engine, "name");
+ if (!name) {
+ close(engine);
+ continue;
+ }
+
+ igt_dynamic(name) {
+ if (file) {
+ struct stat st;
+
+ igt_require(fstatat(engine, file, &st,
0) == 0);
+ }
+
+ test(i915, engine);
+ }
+
+ close(engine);
+ }
+ }
+}
diff
[Intel-gfx] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property
We [will] expose various per-engine scheduling controls. One of which,
'timeslice_duration_ms', defines the scheduling quantum. If a context
exhausts its timeslice, it will be preempted in favour of running one of
its compatriots.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources| 3 +
tests/i915/sysfs_timeslice_duration.c | 503 ++
tests/meson.build | 1 +
3 files changed, 507 insertions(+)
create mode 100644 tests/i915/sysfs_timeslice_duration.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index fd6f67a73..41682040d 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -108,6 +108,9 @@ sysfs_heartbeat_interval_SOURCES =
i915/sysfs_heartbeat_interval
TESTS_progs += sysfs_preempt_timeout
sysfs_preempt_timeout_SOURCES = i915/sysfs_preempt_timeout
+TESTS_progs += sysfs_timeslice_duration
+sysfs_timeslice_duration_SOURCES = i915/sysfs_timeslice_duration
+
TESTS_progs += gem_bad_reloc
gem_bad_reloc_SOURCES = i915/gem_bad_reloc.c
diff --git a/tests/i915/sysfs_timeslice_duration.c
b/tests/i915/sysfs_timeslice_duration.c
new file mode 100644
index 0..42fff43e2
--- /dev/null
+++ b/tests/i915/sysfs_timeslice_duration.c
@@ -0,0 +1,503 @@
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h" /* gem_quiescent_gpu()! */
+#include "i915/gem_engine_topology.h"
+#include "i915/gem_mman.h"
+#include "igt_dummyload.h"
+#include "igt_sysfs.h"
+#include "ioctl_wrappers.h" /* igt_require_gem()! */
+#include "intel_chipset.h"
+#include "intel_reg.h"
+#include "sw_sync.h"
+
+#define MI_SEMAPHORE_WAIT (0x1c << 23)
+#define MI_SEMAPHORE_POLL (1 << 15)
+#define MI_SEMAPHORE_SAD_GT_SDD (0 << 12)
+#define MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
+#define MI_SEMAPHORE_SAD_LT_SDD (2 << 12)
+#define MI_SEMAPHORE_SAD_LTE_SDD (3 << 12)
+#define MI_SEMAPHORE_SAD_EQ_SDD (4 << 12)
+#define MI_SEMAPHORE_SAD_NEQ_SDD (5 << 12)
+
+static bool __enable_hangcheck(int dir, bool state)
+{
+ return igt_sysfs_set(dir, "enable_hangcheck", state ? "1" : "0");
+}
+
+static bool enable_hangcheck(int i915, bool state)
+{
+ bool success;
+ int dir;
+
+ dir = igt_sysfs_open_parameters(i915);
+ if (dir < 0) /* no parameters, must be default! */
+ return false;
+
+ success = __enable_hangcheck(dir, state);
+ close(dir);
+
+ return success;
+}
+
+static void set_timeslice(int engine, unsigned int value)
+{
+ unsigned int delay;
+
+ igt_sysfs_printf(engine, "timeslice_duration_ms", "%u", value);
+ igt_sysfs_scanf(engine, "timeslice_duration_ms", "%u", &delay);
+ igt_assert_eq(delay, value);
+}
+
+static void test_idempotent(int i915, int engine)
+{
+ const unsigned int delays[] = { 0, 1, 1234, 654321 };
+ unsigned int saved;
+
+ /* Quick test to verify the kernel reports the same values as we write
*/
+
+ igt_assert(igt_sysfs_scanf(engine, "timeslice_duration_ms", "%u",
&saved) == 1);
+ igt_debug("Initial timeslice_duration_ms:%u\n", saved);
+
+ for (int i = 0; i < ARRAY_SIZE(delays); i++)
+ set_timeslice(engine, delays[i]);
+
+ set_timeslice(engine, saved);
+}
+
+static void test_invalid(int i915, int engine)
+{
+ unsigned int saved, delay;
+
+ /* Quick test that non-representable delays are rejected */
+
+ igt_assert(igt_sysfs_scanf(engine, "timeslice_duration_ms", "%u",
&saved) == 1);
+ igt_debug("Initial timeslice_duration_ms:%u\n", saved);
+
+ igt_sysfs_printf(engine, "timeslice_duration_ms", PRIu64, -1);
+ igt_sysfs_scanf(engine, "timeslice_duration_ms", "%u", &delay);
+ igt_assert_eq(d
[Intel-gfx] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls
We [will] expose various per-engine scheduling controls. One of which,
'heartbeat_duration_ms', defines how often we send a heartbeat down the
engine to check upon the health of the engine. If a heartbeat does not
complete within the interval (or two), the engine is declared hung.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources| 3 +
tests/i915/sysfs_heartbeat_interval.c | 466 ++
tests/meson.build | 1 +
3 files changed, 470 insertions(+)
create mode 100644 tests/i915/sysfs_heartbeat_interval.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index fc9e04e97..fd6f67a73 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -102,6 +102,9 @@ TESTS_progs = \
vgem_slow \
$(NULL)
+TESTS_progs += sysfs_heartbeat_interval
+sysfs_heartbeat_interval_SOURCES = i915/sysfs_heartbeat_interval
+
TESTS_progs += sysfs_preempt_timeout
sysfs_preempt_timeout_SOURCES = i915/sysfs_preempt_timeout
diff --git a/tests/i915/sysfs_heartbeat_interval.c
b/tests/i915/sysfs_heartbeat_interval.c
new file mode 100644
index 0..9ce7b7b85
--- /dev/null
+++ b/tests/i915/sysfs_heartbeat_interval.c
@@ -0,0 +1,466 @@
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h" /* gem_quiescent_gpu()! */
+#include "i915/gem_engine_topology.h"
+#include "igt_dummyload.h"
+#include "igt_sysfs.h"
+#include "ioctl_wrappers.h" /* igt_require_gem()! */
+#include "sw_sync.h"
+
+#include "igt_debugfs.h"
+
+static bool __enable_hangcheck(int dir, bool state)
+{
+ return igt_sysfs_set(dir, "enable_hangcheck", state ? "1" : "0");
+}
+
+static void enable_hangcheck(int i915, bool state)
+{
+ int dir;
+
+ dir = igt_sysfs_open_parameters(i915);
+ if (dir < 0) /* no parameters, must be default! */
+ return;
+
+ __enable_hangcheck(dir, state);
+ close(dir);
+}
+
+static void set_heartbeat(int engine, unsigned int value)
+{
+ unsigned int delay = ~value;
+
+ igt_sysfs_printf(engine, "heartbeat_interval_ms", "%u", value);
+ igt_sysfs_scanf(engine, "heartbeat_interval_ms", "%u", &delay);
+ igt_assert_eq(delay, value);
+}
+
+static void test_idempotent(int i915, int engine)
+{
+ unsigned int delays[] = { 1, 1000, 5000, 5, 123456789 };
+ unsigned int saved;
+
+ /* Quick test that the property reports the values we set */
+
+ igt_assert(igt_sysfs_scanf(engine, "heartbeat_interval_ms", "%u",
&saved) == 1);
+ igt_debug("Initial heartbeat_interval_ms:%u\n", saved);
+
+ for (int i = 0; i < ARRAY_SIZE(delays); i++)
+ set_heartbeat(engine, delays[i]);
+
+ set_heartbeat(engine, saved);
+}
+
+static void test_invalid(int i915, int engine)
+{
+ unsigned int saved, delay;
+
+ /* Quick test that we reject any unrepresentable intervals */
+
+ igt_assert(igt_sysfs_scanf(engine, "heartbeat_interval_ms", "%u",
&saved) == 1);
+ igt_debug("Initial heartbeat_interval_ms:%u\n", saved);
+
+ igt_sysfs_printf(engine, "heartbeat_interval_ms", PRIu64, -1);
+ igt_sysfs_scanf(engine, "heartbeat_interval_ms", "%u", &delay);
+ igt_assert_eq(delay, saved);
+
+ igt_sysfs_printf(engine, "heartbeat_interval_ms", PRIu64, 10ull << 32);
+ igt_sysfs_scanf(engine, "heartbeat_interval_ms", "%u", &delay);
+ igt_assert_eq(delay, saved);
+}
+
+static void set_unbannable(int i915, uint32_t ctx)
+{
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = ctx,
+ .param = I915_CONTEXT_PARAM_BANNABLE,
+ };
+
+ igt_assert_eq(__gem_context_set_param(i915, &p), 0);
+}
+
+static uint32_t create_context(int i915, unsigned int class, un
[Intel-gfx] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use
Several tests depend upon the implicit engine->mmio_base but have no
means of determining the physical layout. Since the kernel has started
providing this information, start putting it to use.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 84 ++
lib/i915/gem_engine_topology.h | 5 ++
tests/i915/gem_ctx_shared.c| 38 +--
tests/i915/gem_exec_latency.c | 17 ---
4 files changed, 111 insertions(+), 33 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index 43a99e0ff..058983123 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -21,7 +21,12 @@
* IN THE SOFTWARE.
*/
+#include
+#include
+
#include "drmtest.h"
+#include "igt_sysfs.h"
+#include "intel_chipset.h"
#include "ioctl_wrappers.h"
#include "i915/gem_engine_topology.h"
@@ -331,3 +336,82 @@ bool gem_engine_is_equal(const struct
intel_execution_engine2 *e1,
{
return e1->class == e2->class && e1->instance == e2->instance;
}
+
+static int descend(int dir, const char *path)
+{
+ int fd;
+
+ fd = openat(dir, path, O_RDONLY);
+ close(dir);
+
+ return fd;
+}
+
+int gem_engine_property_scanf(int i915, const char *engine, const char *attr,
+ const char *fmt, ...)
+{
+ FILE *file;
+ va_list ap;
+ int ret;
+ int fd;
+
+ fd = igt_sysfs_open(i915);
+ if (fd < 0)
+ return fd;
+
+ fd = descend(fd, "engine");
+ if (fd < 0)
+ return fd;
+
+ fd = descend(fd, engine);
+ if (fd < 0)
+ return fd;
+
+ fd = descend(fd, attr);
+ if (fd < 0)
+ return fd;
+
+ file = fdopen(fd, "r");
+ if (!file) {
+ close(fd);
+ return -1;
+ }
+
+ va_start(ap, fmt);
+ ret = vfscanf(file, fmt, ap);
+ va_end(ap);
+
+ fclose(file);
+ return ret;
+}
+
+uint32_t gem_engine_mmio_base(int i915, const char *engine)
+{
+ unsigned int mmio = 0;
+
+ if (gem_engine_property_scanf(i915, engine, "mmio_base",
+ "%x", &mmio) < 0) {
+ int gen = intel_gen(intel_get_drm_devid(i915));
+
+ /* The layout of xcs1+ is unreliable -- hence the property! */
+ if (!strcmp(engine, "rcs0")) {
+ mmio = 0x2000;
+ } else if (!strcmp(engine, "bcs0")) {
+ mmio = 0x22000;
+ } else if (!strcmp(engine, "vcs0")) {
+ if (gen < 6)
+ mmio = 0x4000;
+ else if (gen < 11)
+ mmio = 0x12000;
+ else
+ mmio = 0x1c;
+ } else if (!strcmp(engine, "vecs0")) {
+ if (gen < 11)
+ mmio = 0x1a000;
+ else
+ mmio = 0x1c8000;
+ }
+ }
+
+ return mmio;
+}
diff --git a/lib/i915/gem_engine_topology.h b/lib/i915/gem_engine_topology.h
index e40d7ec83..7a2e21f66 100644
--- a/lib/i915/gem_engine_topology.h
+++ b/lib/i915/gem_engine_topology.h
@@ -72,4 +72,9 @@ struct intel_execution_engine2
gem_eb_flags_to_engine(unsigned int flags);
((e__) = intel_get_current_physical_engine(&i__)); \
intel_next_engine(&i__))
+__attribute__((format(scanf, 4, 5)))
+int gem_engine_property_scanf(int i915, const char *engine, const char *attr,
+ const char *fmt, ...);
+uint32_t gem_engine_mmio_base(int i915, const char *engine);
+
#endif /* GEM_ENGINE_TOPOLOGY_H */
diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
index 30e37c3cc..6fc3f8cd8 100644
--- a/tests/i915/gem_ctx_shared.c
+++ b/tests/i915/gem_ctx_shared.c
@@ -38,6 +38,7 @@
#include
+#include "i915/gem_engine_topology.h"
#include "igt_rand.h"
#include "igt_vgem.h"
#include "sync_file.h"
@@ -548,6 +549,14 @@ static uint32_t store_timestamp(int i915,
return obj.handle;
}
+static uint32_t ring_base(int i915, unsigned ring)
+{
+ if (ring == I915_EXEC_DEFAULT)
+ ring = I915_EXEC_RENDER; /* XXX */
+
+ return gem_engine_mmio_base(i915, gem_eb_flags_to_engine(ring).name);
+}
+
static void independent(int i915, unsigned ring, unsigned flags)
{
const int TIMESTAMP = 1023;
@@ -555,33 +564,8 @@ static void independent(int i915, unsigned ring, unsigned
flags)
igt_spin_t *spin[MAX_ELSP_QLEN];
unsigned int mmio_base;
- /* XXX i915_query()! */
- switch (ring) {
- case I915_EXEC_DEFAULT:
- case I915_EXEC_RENDER:
- mmio_base = 0x2000;
- break;
-#if 0
- case I915_EXEC_BSD:
- mmio_base = 0x12000;
- break;
-#endif
- case I915_EXE
[Intel-gfx] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative registers
Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 164 -
1 file changed, 100 insertions(+), 64 deletions(-)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 8b72a16ad..5b472d693 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -70,6 +70,7 @@ static const struct named_register {
uint32_t ignore_bits;
uint32_t write_mask; /* some registers bits do not exist */
bool masked;
+ bool relative;
} nonpriv_registers[] = {
{ "NOPID", NOCTX, RCS0, 0x2094 },
{ "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
@@ -109,7 +110,6 @@ static const struct named_register {
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
{ "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
- { "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
{ "OACTXID", GEN8, RCS0, 0x2364 },
{ "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2, .write_mask = ~0x3 },
@@ -138,79 +138,56 @@ static const struct named_register {
{ "CTX_PREEMPT", NOCTX /* GEN10 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN11, RCS0, 0x2580, .masked = true },
- { "HDC_CHICKEN1", GEN_RANGE(10, 10), RCS0, 0x7304, .masked = true },
/* Privileged (enabled by w/a + FORCE_TO_NONPRIV) */
{ "CTX_PREEMPT", NOCTX /* GEN9 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x2580, .masked = true },
{ "COMMON_SLICE_CHICKEN2", GEN_RANGE(9, 9), RCS0, 0x7014, .masked =
true },
- { "HDC_CHICKEN1", GEN_RANGE(9, 9), RCS0, 0x7304, .masked = true },
+ { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x7304, .masked = true },
{ "SLICE_COMMON_ECO_CHICKEN1", GEN_RANGE(11, 11) /* + glk */, RCS0,
0x731c, .masked = true },
{ "L3SQREG4", NOCTX /* GEN9:skl,kbl */, RCS0, 0xb118, .write_mask =
~0x10 },
{ "HALF_SLICE_CHICKEN7", GEN_RANGE(11, 11), RCS0, 0xe194, .masked =
true },
{ "SAMPLER_MODE", GEN_RANGE(11, 11), RCS0, 0xe18c, .masked = true },
- { "BCS_GPR", GEN9, BCS0, 0x22600, 32 },
{ "BCS_SWCTRL", GEN8, BCS0, 0x22200, .write_mask = 0x3, .masked = true
},
{ "MFC_VDBOX1", NOCTX, VCS0, 0x12800, 64 },
{ "MFC_VDBOX2", NOCTX, VCS1, 0x1c800, 64 },
- { "VCS0_GPR", GEN_RANGE(9, 10), VCS0, 0x12600, 32 },
- { "VCS1_GPR", GEN_RANGE(9, 10), VCS1, 0x1c600, 32 },
- { "VECS_GPR", GEN_RANGE(9, 10), VECS0, 0x1a600, 32 },
-
- { "VCS0_GPR", GEN11, VCS0, 0x1c0600, 32 },
- { "VCS1_GPR", GEN11, VCS1, 0x1c4600, 32 },
- { "VCS2_GPR", GEN11, VCS2, 0x1d0600, 32 },
- { "VCS3_GPR", GEN11, VCS3, 0x1d4600, 32 },
- { "VECS_GPR", GEN11, VECS0, 0x1c8600, 32 },
+ { "xCS_GPR", GEN9, ALL, 0x600, 32, .relative = true },
{}
}, ignore_registers[] = {
{ "RCS timestamp", GEN6, ~0u, 0x2358 },
{ "BCS timestamp", GEN7, ~0u, 0x22358 },
- { "VCS0 timestamp", GEN_RANGE(7, 10), ~0u, 0x12358 },
- { "VCS1 timestamp", GEN_RANGE(7, 10), ~0u, 0x1c358 },
- { "VECS timestamp", GEN_RANGE(8, 10), ~0u, 0x1a358 },
-
- { "VCS0 timestamp", GEN11, ~0u, 0x1c0358 },
- { "VCS1 timestamp", GEN11, ~0u, 0x1c4358 },
- { "VCS2 timestamp", GEN11, ~0u, 0x1d0358 },
- { "VCS3 timestamp", GEN11, ~0u, 0x1d4358 },
- { "VECS timestamp", GEN11, ~0u, 0x1c8358 },
+ { "xCS timestamp", GEN8, ALL, 0x358, .relative = true },
/* huc read only */
- { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2000 },
- { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2014 },
- { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x23b0 },
-
- { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2000 },
- { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2014 },
- { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x23b0 },
-
- { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2000 },
- { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2014 },
- { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x23b0 },
-
- { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2000 },
- { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2014 },
- { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x23b0 },
+ { "BSD 0x2000", GEN11, ALL, 0x2000, .relative = true },
+ { "BSD 0x2014", GEN11, ALL, 0x2014, .relative = true },
+ { "BSD 0x23b0", GEN11, ALL, 0x23b0, .relative = true },
{}
};
-static const char *register_name(uint32_t offset, char *buf, size_t len)
+static const char *
+register_name(uint32_t offset, uint32_t mmio_base, char *buf, size_t len)
{
for (const struct named_register *r = nonpriv_registers; r->name; r++) {
unsigned int width = r->coun
Re: [Intel-gfx] [PATCH] drm/i915: Restore the kernel context after verifying the w/a
Chris Wilson writes: > As a safety net, flush the engine verifications and restore the kernel > context. > > Closes: https://gitlab.freedesktop.org/drm/intel/issues/971 > Signed-off-by: Chris Wilson Acked-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_gt.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > index da2b6e2ae692..88b6c904607c 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > @@ -538,6 +538,10 @@ static int __engines_verify_workarounds(struct intel_gt > *gt) > err = -EIO; > } > > + /* Flush and restore the kernel context for safety */ > + if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) == -ETIME) > + err = -EIO; > + > return err; > } > > -- > 2.25.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Enable second DBuf slice for ICL and TGL (rev21)
On 27/01/2020 09:48, Lisovskiy, Stanislav wrote: > Good morning :) > > > Yet another gem related issue not caused by this patch.. Thanks! Lakshmi reported the bug and I made the filing a little more generic and attached it to https://gitlab.freedesktop.org/drm/intel/issues/530. Thanks for sending us all these false positives! I queued a re-reporting of the results. Martin > > > Best Regards, > > Lisovskiy Stanislav > > Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 > Espoo > > *From:* Patchwork > *Sent:* Sunday, January 26, 2020 11:19:53 AM > *To:* Lisovskiy, Stanislav > *Cc:* intel-gfx@lists.freedesktop.org > *Subject:* ✗ Fi.CI.IGT: failure for Enable second DBuf slice for ICL and > TGL (rev21) > > == Series Details == > > Series: Enable second DBuf slice for ICL and TGL (rev21) > URL : https://patchwork.freedesktop.org/series/70059/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_7806_full -> Patchwork_16248_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_16248_full absolutely > need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_16248_full, please notify your bug team to > allow them > to document this new failure mode, which will reduce false positives > in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_16248_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive: > - shard-skl: [PASS][1] -> [INCOMPLETE][2] > [1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-skl1/igt@gem_persistent_rel...@forked-faulting-reloc-thrash-inactive.html > [2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-skl9/igt@gem_persistent_rel...@forked-faulting-reloc-thrash-inactive.html > > > Known issues > > > Here are the changes found in Patchwork_16248_full that come from > known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_busy@close-race: > - shard-hsw: [PASS][3] -> [TIMEOUT][4] ([fdo#112271]) > [3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-hsw8/igt@gem_b...@close-race.html > [4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-hsw2/igt@gem_b...@close-race.html > > * igt@gem_ctx_isolation@vcs1-dirty-create: > - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / > [fdo#112080]) +1 similar issue > [5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html > [6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb7/igt@gem_ctx_isolat...@vcs1-dirty-create.html > > * igt@gem_exec_schedule@pi-common-bsd: > - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) > [7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb5/igt@gem_exec_sched...@pi-common-bsd.html > [8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html > > * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd: > - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +1 > similar issue > [9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html > [10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb4/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html > > * igt@gem_exec_schedule@promotion-bsd1: > - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +6 > similar issues > [11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb1/igt@gem_exec_sched...@promotion-bsd1.html > [12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb5/igt@gem_exec_sched...@promotion-bsd1.html > > * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing: > - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([i915#530] / > [i915#61]) > [13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-hsw7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html > [14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-hsw7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html > - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#140]) > [15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb8/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html > [16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb8/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.ht
[Intel-gfx] [PATCH] drm/i915/selftests/perf: measure memcpy bw between regions
Measure the memcpy bw between our CPU accessible regions, trying all
supported mapping combinations(WC, WB) across various sizes.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
.../drm/i915/selftests/intel_memory_region.c | 164 ++
2 files changed, 165 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
index 5a577a1332f5..3bf7f53e9924 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
@@ -17,3 +17,4 @@
*/
selftest(engine_cs, intel_engine_cs_perf_selftests)
selftest(blt, i915_gem_object_blt_perf_selftests)
+selftest(region, intel_memory_region_perf_selftests)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index 3ef3620e0da5..6d493a198eb1 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "../i915_selftest.h"
@@ -572,6 +573,157 @@ static int igt_lmem_write_cpu(void *arg)
return err;
}
+static const char *stringify_map_type(u32 type)
+{
+ switch (type) {
+ case I915_MAP_WB:
+ return "WB";
+ case I915_MAP_WC:
+ return "WC";
+ }
+
+ return "";
+}
+
+static inline struct drm_i915_gem_object *
+create_region(struct intel_memory_region *mr, u64 size)
+{
+ struct drm_i915_gem_object *obj;
+
+ obj = i915_gem_object_create_region(mr, size, 0);
+ if (!IS_ERR(obj)) {
+ if (!i915_gem_object_type_has(obj,
+ I915_GEM_OBJECT_HAS_STRUCT_PAGE |
+ I915_GEM_OBJECT_HAS_IOMEM)) {
+ i915_gem_object_put(obj);
+ return ERR_PTR(-ENODEV);
+ }
+ }
+
+ return obj;
+}
+
+static int wrap_ktime_compare(const void *A, const void *B)
+{
+ const ktime_t *a = A, *b = B;
+
+ return ktime_compare(*a, *b);
+}
+
+int _perf_memcpy(struct intel_memory_region *src_mr,
+struct intel_memory_region *dst_mr,
+u64 size, u32 src_type, u32 dst_type)
+{
+ struct drm_i915_gem_object *src, *dst;
+ void *src_addr, *dst_addr;
+ ktime_t t[5];
+ int pass;
+ int ret = 0;
+
+ src = create_region(src_mr, size);
+ if (IS_ERR(src)) {
+ ret = PTR_ERR(src);
+ goto out;
+ }
+
+ src_addr = i915_gem_object_pin_map(src, src_type);
+ if (IS_ERR(src_addr)) {
+ ret = PTR_ERR(src_addr);
+ goto out_put_src;
+ }
+
+ dst = create_region(dst_mr, size);
+ if (IS_ERR(dst)) {
+ ret = PTR_ERR(dst);
+ goto out_unpin_src;
+ }
+
+ dst_addr = i915_gem_object_pin_map(dst, dst_type);
+ if (IS_ERR(dst_addr)) {
+ ret = PTR_ERR(dst_addr);
+ goto out_put_dst;
+ }
+
+ for (pass = 0; pass < ARRAY_SIZE(t); pass++) {
+ ktime_t t0, t1;
+
+ t0 = ktime_get();
+
+ memcpy(dst_addr, src_addr, size);
+
+ t1 = ktime_get();
+ t[pass] = ktime_sub(t1, t0);
+ }
+
+ sort(t, ARRAY_SIZE(t), sizeof(*t), wrap_ktime_compare, NULL);
+ pr_info("%s src(%s, %s) -> dst(%s, %s) memcpy %llu KiB copy: %lld
MiB/s\n",
+ __func__,
+ src_mr->name,
+ stringify_map_type(src_type),
+ dst_mr->name,
+ stringify_map_type(dst_type),
+ size >> 10,
+ div64_u64(mul_u32_u32(4 * size,
+ 1000 * 1000 * 1000),
+ t[1] + 2 * t[2] + t[3]) >> 20);
+
+ i915_gem_object_unpin_map(dst);
+ __i915_gem_object_put_pages(dst);
+out_put_dst:
+ i915_gem_object_put(dst);
+out_unpin_src:
+ i915_gem_object_unpin_map(src);
+ __i915_gem_object_put_pages(src);
+out_put_src:
+ i915_gem_object_put(src);
+out:
+ if (ret == -ENODEV || ret == -ENOMEM)
+ ret = 0;
+
+ return ret;
+}
+
+int perf_memcpy(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ static const u32 types[] = {
+ I915_MAP_WB,
+ I915_MAP_WC,
+ };
+ static const u32 sizes[] = {
+ SZ_4K,
+ SZ_64K,
+ SZ_2M,
+ SZ_64M,
+ };
+ struct intel_memory_region *src_mr, *dst_mr;
+ int src_id, dst_id;
+ int i, j, k;
+ int ret;
+
+ for_each_memory_region(src_mr, i915, src_id) {
+ for_each_memory_region(dst_mr, i915, dst_id) {
+ for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
+
[Intel-gfx] [PATCH] drm/i915/gt: Lift set-wedged engine dumping out of user paths
The user (e.g. gem_eio) can manipulate the driver into wedging itself,
allowing the user to trigger voluminous logging of inconsequential
details. If we lift the dump to direct calls to intel_gt_set_wedged(),
out of the intel_reset failure handling, we keep the detail logging for
what we expect are true HW or test failures without being tricked.
Reported-by: Tomi Sarvela
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tomi Sarvela
---
drivers/gpu/drm/i915/gt/intel_reset.c | 30 +++
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index beee0cf89bce..423a02506b2d 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -800,13 +800,6 @@ static void __intel_gt_set_wedged(struct intel_gt *gt)
if (test_bit(I915_WEDGED, >->reset.flags))
return;
- if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(gt)) {
- struct drm_printer p = drm_debug_printer(__func__);
-
- for_each_engine(engine, gt, id)
- intel_engine_dump(engine, &p, "%s\n", engine->name);
- }
-
GT_TRACE(gt, "start\n");
/*
@@ -845,10 +838,29 @@ void intel_gt_set_wedged(struct intel_gt *gt)
{
intel_wakeref_t wakeref;
+ if (test_bit(I915_WEDGED, >->reset.flags))
+ return;
+
+ wakeref = intel_runtime_pm_get(gt->uncore->rpm);
mutex_lock(>->reset.mutex);
- with_intel_runtime_pm(gt->uncore->rpm, wakeref)
- __intel_gt_set_wedged(gt);
+
+ if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(gt)) {
+ struct drm_printer p = drm_debug_printer(__func__);
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, gt, id) {
+ if (intel_engine_is_idle(engine))
+ continue;
+
+ intel_engine_dump(engine, &p, "%s\n", engine->name);
+ }
+ }
+
+ __intel_gt_set_wedged(gt);
+
mutex_unlock(>->reset.mutex);
+ intel_runtime_pm_put(gt->uncore->rpm, wakeref);
}
static bool __intel_gt_unset_wedged(struct intel_gt *gt)
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable second DBuf slice for ICL and TGL (rev21)
== Series Details == Series: Enable second DBuf slice for ICL and TGL (rev21) URL : https://patchwork.freedesktop.org/series/70059/ State : success == Summary == CI Bug Log - changes from CI_DRM_7806_full -> Patchwork_16248_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16248_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@close-race: - shard-hsw: [PASS][1] -> [TIMEOUT][2] ([fdo#112271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-hsw8/igt@gem_b...@close-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-hsw2/igt@gem_b...@close-race.html * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb7/igt@gem_ctx_isolat...@vcs1-dirty-create.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb5/igt@gem_exec_sched...@pi-common-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb4/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb1/igt@gem_exec_sched...@promotion-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb5/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#1028]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-skl1/igt@gem_persistent_rel...@forked-faulting-reloc-thrash-inactive.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-skl9/igt@gem_persistent_rel...@forked-faulting-reloc-thrash-inactive.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([i915#530] / [i915#61]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-hsw7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-hsw7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#140]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb8/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb8/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing: - shard-snb: [PASS][17] -> [FAIL][18] ([i915#520]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-snb5/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-snb2/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#109100] / [i915#140]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb6/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb3/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html * igt@gem_persistent_relocs@forked-interruptible-thrashing: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#530]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-skl6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-skl9/igt@gem_persistent_rel...@forked-interruptible-thrashing.html * igt@i915_pm_rps@reset: - shard-tglb: [PASS][23] -> [FAIL][24] ([i915#413]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-tglb6/igt@i915_pm_...@
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable second DBuf slice for ICL and TGL (rev21)
== Series Details == Series: Enable second DBuf slice for ICL and TGL (rev21) URL : https://patchwork.freedesktop.org/series/70059/ State : success == Summary == CI Bug Log - changes from CI_DRM_7806_full -> Patchwork_16248_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16248_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@close-race: - shard-hsw: [PASS][1] -> [TIMEOUT][2] ([fdo#112271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-hsw8/igt@gem_b...@close-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-hsw2/igt@gem_b...@close-race.html * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb7/igt@gem_ctx_isolat...@vcs1-dirty-create.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb5/igt@gem_exec_sched...@pi-common-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb4/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb1/igt@gem_exec_sched...@promotion-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb5/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#1028]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-skl1/igt@gem_persistent_rel...@forked-faulting-reloc-thrash-inactive.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-skl9/igt@gem_persistent_rel...@forked-faulting-reloc-thrash-inactive.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([i915#530] / [i915#61]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-hsw7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-hsw7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#140]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb8/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb8/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing: - shard-snb: [PASS][17] -> [FAIL][18] ([i915#520]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-snb5/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-snb2/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#109100] / [i915#140]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-iclb6/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-iclb3/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html * igt@gem_persistent_relocs@forked-interruptible-thrashing: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#530]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-skl6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16248/shard-skl9/igt@gem_persistent_rel...@forked-interruptible-thrashing.html * igt@i915_pm_rps@reset: - shard-tglb: [PASS][23] -> [FAIL][24] ([i915#413]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7806/shard-tglb6/igt@i915_pm_...@
Re: [Intel-gfx] [PATCH] drm/i915/selftests/perf: measure memcpy bw between regions
Quoting Matthew Auld (2020-01-27 12:56:26)
> Measure the memcpy bw between our CPU accessible regions, trying all
> supported mapping combinations(WC, WB) across various sizes.
>
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
> ---
> .../drm/i915/selftests/i915_perf_selftests.h | 1 +
> .../drm/i915/selftests/intel_memory_region.c | 164 ++
> 2 files changed, 165 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
> b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
> index 5a577a1332f5..3bf7f53e9924 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
> +++ b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
> @@ -17,3 +17,4 @@
> */
> selftest(engine_cs, intel_engine_cs_perf_selftests)
> selftest(blt, i915_gem_object_blt_perf_selftests)
> +selftest(region, intel_memory_region_perf_selftests)
> diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> index 3ef3620e0da5..6d493a198eb1 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> @@ -4,6 +4,7 @@
> */
>
> #include
> +#include
>
> #include "../i915_selftest.h"
>
> @@ -572,6 +573,157 @@ static int igt_lmem_write_cpu(void *arg)
> return err;
> }
>
> +static const char *stringify_map_type(u32 type)
Fwiw, I've begun using repr_foo(foo). Which do we prefer?
> +{
> + switch (type) {
> + case I915_MAP_WB:
> + return "WB";
> + case I915_MAP_WC:
> + return "WC";
> + }
> +
> + return "";
> +}
> +
> +static inline struct drm_i915_gem_object *
> +create_region(struct intel_memory_region *mr, u64 size)
> +{
> + struct drm_i915_gem_object *obj;
> +
> + obj = i915_gem_object_create_region(mr, size, 0);
> + if (!IS_ERR(obj)) {
> + if (!i915_gem_object_type_has(obj,
> + I915_GEM_OBJECT_HAS_STRUCT_PAGE
> |
> + I915_GEM_OBJECT_HAS_IOMEM)) {
Can we not tell from the mr what properties we would end up with?
I would suggest calling it something like create_region_for_mapping() as
I had to look around to see why the type_has() was justified.
Hmm. Perhaps better (more agnostic to the pin_map) would be to try and
fail to create the map and squash the -ENODEV error there.
> + i915_gem_object_put(obj);
> + return ERR_PTR(-ENODEV);
> + }
> + }
> +
> + return obj;
> +}
> +
> +static int wrap_ktime_compare(const void *A, const void *B)
> +{
> + const ktime_t *a = A, *b = B;
> +
> + return ktime_compare(*a, *b);
> +}
> +
> +int _perf_memcpy(struct intel_memory_region *src_mr,
> +struct intel_memory_region *dst_mr,
> +u64 size, u32 src_type, u32 dst_type)
> +{
> + struct drm_i915_gem_object *src, *dst;
> + void *src_addr, *dst_addr;
> + ktime_t t[5];
> + int pass;
> + int ret = 0;
> +
> + src = create_region(src_mr, size);
> + if (IS_ERR(src)) {
> + ret = PTR_ERR(src);
> + goto out;
> + }
> +
> + src_addr = i915_gem_object_pin_map(src, src_type);
> + if (IS_ERR(src_addr)) {
> + ret = PTR_ERR(src_addr);
> + goto out_put_src;
> + }
> +
> + dst = create_region(dst_mr, size);
> + if (IS_ERR(dst)) {
> + ret = PTR_ERR(dst);
> + goto out_unpin_src;
> + }
> +
> + dst_addr = i915_gem_object_pin_map(dst, dst_type);
> + if (IS_ERR(dst_addr)) {
> + ret = PTR_ERR(dst_addr);
> + goto out_put_dst;
> + }
> +
> + for (pass = 0; pass < ARRAY_SIZE(t); pass++) {
> + ktime_t t0, t1;
> +
> + t0 = ktime_get();
> +
> + memcpy(dst_addr, src_addr, size);
Fwiw, different sizes of memcpy() may prove important,
(memcpy32/memcpy64). As would memcpy_from_wc.
> +
> + t1 = ktime_get();
> + t[pass] = ktime_sub(t1, t0);
> + }
> +
> + sort(t, ARRAY_SIZE(t), sizeof(*t), wrap_ktime_compare, NULL);
> + pr_info("%s src(%s, %s) -> dst(%s, %s) memcpy %llu KiB copy: %lld
> MiB/s\n",
> + __func__,
> + src_mr->name,
> + stringify_map_type(src_type),
> + dst_mr->name,
> + stringify_map_type(dst_type),
> + size >> 10,
> + div64_u64(mul_u32_u32(4 * size,
> + 1000 * 1000 * 1000),
> + t[1] + 2 * t[2] + t[3]) >> 20);
> +
> + i915_gem_object_unpin_map(dst);
> + __i915_gem_object_put_pages(dst);
> +out_put_dst:
> + i915_gem_object_put(dst);
> +out_unpin_src:
> + i915_gem_object_unpin_map(src);
> + __i91
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix inconsistance between pfit.enable and scaler freeing (rev3)
== Series Details == Series: drm/i915: Fix inconsistance between pfit.enable and scaler freeing (rev3) URL : https://patchwork.freedesktop.org/series/72539/ State : success == Summary == CI Bug Log - changes from CI_DRM_7810_full -> Patchwork_16259_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16259_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +18 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-iclb1/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-iclb7/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@vcs1-queued: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-iclb4/igt@gem_ctx_persiste...@vcs1-queued.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-iclb8/igt@gem_ctx_persiste...@vcs1-queued.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-iclb7/igt@gem_exec_as...@concurrent-writes-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-iclb2/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_create@forked: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-glk5/igt@gem_exec_cre...@forked.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-glk2/igt@gem_exec_cre...@forked.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276]) +30 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_suspend@basic-s3: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-apl6/igt@gem_exec_susp...@basic-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-apl6/igt@gem_exec_susp...@basic-s3.html * igt@gem_pipe_control_store_loop@reused-buffer: - shard-hsw: [PASS][17] -> [FAIL][18] ([i915#874]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-hsw6/igt@gem_pipe_control_store_l...@reused-buffer.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-hsw1/igt@gem_pipe_control_store_l...@reused-buffer.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#644]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-kbl6/igt@gem_pp...@flink-and-close-vma-leak.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-kbl3/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][21] -> [INCOMPLETE][22] ([i915#58] / [k.org#198133]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-glk9/igt@gen9_exec_pa...@allowed-all.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-glk1/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#454]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-iclb4/igt@i915_pm...@dc6-psr.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-iclb8/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@live_blt: - shard-hsw: [PASS][25] -> [DMESG-FAIL][26] ([i915#725]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7810/shard-hsw7/igt@i915_selftest@live_blt.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16259/shard-hsw2/igt@i915_selftest@live_blt.html
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix inconsistance between pfit.enable and scaler freeing
Quoting Ville Syrjälä (2020-01-24 18:15:30) > On Fri, Jan 24, 2020 at 07:23:01PM +0200, Stanislav Lisovskiy wrote: > > Despite that during hw readout we seem to have scalers assigned > > to pipes, then call atomic_setup_scalers, at the commit stage in > > skl_update_scaler there is a check, that if we have fb src and > > dest of same size, we stage freeing of that scaler. > > > > However we don't update pfit.enabled flag then, which makes > > the state inconsistent, which in turn triggers a WARN_ON > > in skl_pfit_enable, because we have pfit enabled, > > but no assigned scaler. > > And the reason for not having updates pfit.enabled is that the > the modeset was forced by a cdclk change and thus the full state > recomputation never happened and we're left with the inherited > pfit.enabled. > > > > > To me this looks weird that we kind of do the decision > > to use or not use the scaler at skl_update_scaler stage > > but not in intel_atomic_setup_scalers, moreover > > not updating the whole state consistently. > > > > This fix is to not free the scaler if we have pfit.enabled > > flag set, so that the state is now consistent > > and the warnings are gone. > > > > v2: - Put pfit.enable check into crtc specific place > > (Ville Syrjälä) > > > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/577 > > Closes: ... Sigh, should have checked first. By special request of Tomi, Tested-by: Tomi Sarvela I pushed. Thanks for the patch, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add missing HDMI audio pixel clocks for gen12
On Mon, Jan 27, 2020 at 01:39:09PM +0200, Kai Vehmanen wrote:
> 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.
>
> Bspec: 49333
> Signed-off-by: Kai Vehmanen
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 16 +---
> drivers/gpu/drm/i915/i915_reg.h| 4
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index b18040793d9e..78f744d220da 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -148,6 +148,10 @@ static const struct {
> { 74250, AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 },
> { 148352, AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 },
> { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> + { 296703, AUD_CONFIG_PIXEL_CLOCK_HDMI_296703 },
> + { 297000, AUD_CONFIG_PIXEL_CLOCK_HDMI_297000 },
> + { 593407, AUD_CONFIG_PIXEL_CLOCK_HDMI_593407 },
> + { 594000, AUD_CONFIG_PIXEL_CLOCK_HDMI_594000 },
> };
>
> /* HDMI N/CTS table */
> @@ -231,13 +235,19 @@ static const struct hdmi_aud_ncts hdmi_aud_ncts_36bpp[]
> = {
> };
>
> /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> -static u32 audio_config_hdmi_pixel_clock(const struct intel_crtc_state
> *crtc_state)
> +static u32 audio_config_hdmi_pixel_clock(struct drm_i915_private *dev_priv,
> + const struct intel_crtc_state
> *crtc_state)
> {
> const struct drm_display_mode *adjusted_mode =
> &crtc_state->hw.adjusted_mode;
> int i;
>
> for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
> + if (INTEL_GEN(dev_priv) < 12 &&
> + hdmi_audio_clock[i].clock > 148500) {
Might be cleaner to do the check after the loop.
Reviewed-by: Ville Syrjälä
> + i = ARRAY_SIZE(hdmi_audio_clock);
> + break;
> + }
> if (adjusted_mode->crtc_clock == hdmi_audio_clock[i].clock)
> break;
> }
> @@ -433,7 +443,7 @@ hsw_hdmi_audio_config_update(struct intel_encoder
> *encoder,
> tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
> tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
> - tmp |= audio_config_hdmi_pixel_clock(crtc_state);
> + tmp |= audio_config_hdmi_pixel_clock(dev_priv, crtc_state);
>
> n = audio_config_hdmi_get_n(crtc_state, rate);
> if (n != 0) {
> @@ -673,7 +683,7 @@ static void ilk_audio_codec_enable(struct intel_encoder
> *encoder,
> if (intel_crtc_has_dp_encoder(crtc_state))
> tmp |= AUD_CONFIG_N_VALUE_INDEX;
> else
> - tmp |= audio_config_hdmi_pixel_clock(crtc_state);
> + tmp |= audio_config_hdmi_pixel_clock(dev_priv, crtc_state);
> I915_WRITE(aud_config, tmp);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6cc55c103f67..61d9d045b2ff 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9241,6 +9241,10 @@ enum {
> #define AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 (7 << 16)
> #define AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 (8 << 16)
> #define AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 (9 << 16)
> +#define AUD_CONFIG_PIXEL_CLOCK_HDMI_296703 (10 << 16)
> +#define AUD_CONFIG_PIXEL_CLOCK_HDMI_297000 (11 << 16)
> +#define AUD_CONFIG_PIXEL_CLOCK_HDMI_593407 (12 << 16)
> +#define AUD_CONFIG_PIXEL_CLOCK_HDMI_594000 (13 << 16)
> #define AUD_CONFIG_DISABLE_NCTS(1 << 3)
>
> /* HSW Audio */
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/33] drm/i915/display: mass conversion to intel_de_*() register accessors
Quoting Jani Nikula (2020-01-24 15:25:21) > Hey all, > > So I sent [1] to convert some forcewake register accessors... but what if we > just ripped off the bandage once and for all? It's going to hurt, a lot, but > we'd get it done. > > This completely rids us of the "dev_priv" dependency in display/. > > All the patches here are per-file and independent of each other. We could also > pick and apply the ones that are least likely to conflict. > > Opinions? Acked-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block
== Series Details == Series: series starting with [1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block URL : https://patchwork.freedesktop.org/series/72550/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16262_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16262_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16262_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16262_full: ### IGT changes ### Possible regressions * igt@gem_partial_pwrite_pread@reads: - shard-hsw: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-hsw7/igt@gem_partial_pwrite_pr...@reads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-hsw1/igt@gem_partial_pwrite_pr...@reads.html Known issues Here are the changes found in Patchwork_16262_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-none: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb2/igt@gem_ctx_isolat...@vcs1-none.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-iclb6/igt@gem_ctx_isolat...@vcs1-none.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb6/igt@gem_exec_sched...@in-order-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-iclb2/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_store@cachelines-vcs1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112080]) +7 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb2/igt@gem_exec_st...@cachelines-vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-iclb7/igt@gem_exec_st...@cachelines-vcs1.html * igt@gem_wait@write-busy-vcs0: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#109]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl4/igt@gem_w...@write-busy-vcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-skl6/igt@gem_w...@write-busy-vcs0.html * igt@i915_pm_dc@dc5-dpms: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl2/igt@i915_pm...@dc5-dpms.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-skl1/igt@i915_pm...@dc5-dpms.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#413]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb7/igt@i915_pm_...@waitboost.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-iclb1/igt@i915_pm_...@waitboost.html * igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#34]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-glk2/igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-glk2/igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16262/shard-skl2/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-kbl: [PASS][23] -> [DME
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Implement Wa_1606931601 (rev2)
== Series Details == Series: drm/i915/tgl: Implement Wa_1606931601 (rev2) URL : https://patchwork.freedesktop.org/series/72433/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16263_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16263_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16263_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16263_full: ### IGT changes ### Possible regressions * igt@gem_workarounds@suspend-resume: - shard-tglb: NOTRUN -> [FAIL][1] +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-tglb6/igt@gem_workarou...@suspend-resume.html * igt@i915_selftest@live_workarounds: - shard-tglb: NOTRUN -> [DMESG-FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-tglb7/igt@i915_selftest@live_workarounds.html * igt@prime_mmap_coherency@read: - shard-hsw: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-hsw7/igt@prime_mmap_cohere...@read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-hsw5/igt@prime_mmap_cohere...@read.html Known issues Here are the changes found in Patchwork_16263_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [fdo#112080]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb1/igt@gem_ctx_isolat...@vcs1-dirty-create.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-iclb5/igt@gem_ctx_isolat...@vcs1-dirty-create.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb4/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_create@forked: - shard-glk: [PASS][9] -> [INCOMPLETE][10] ([i915#58] / [k.org#198133]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-glk6/igt@gem_exec_cre...@forked.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-glk7/igt@gem_exec_cre...@forked.html * igt@gem_exec_create@madvise: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-glk6/igt@gem_exec_cre...@madvise.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-glk9/igt@gem_exec_cre...@madvise.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb6/igt@gem_exec_sched...@in-order-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-iclb2/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([i915#677]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-apl1/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-apl4/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][19] -> [FAIL][20] ([i915#413]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb7/igt@i915_pm_...@waitboost.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-iclb4/igt@i915_pm_...@waitboost.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-apl6/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16263/shard-apl4/igt@i915_susp...@sysfs-reader.html * igt@kms_color@pipe-a-ctm-0-75: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#109]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_781
Re: [Intel-gfx] [PATCH v3 00/12] drm/i915: Add support for HDCP 1.4 over MST connectors
On Fri, Jan 17, 2020 at 2:31 PM Sean Paul wrote: > > From: Sean Paul > > Hey all, > Here's v3, which addresses all review comments in v2. > Friendly ping Sean > Sean > > Sean Paul (12): > drm/i915: Fix sha_text population code > drm/i915: Clear the repeater bit on HDCP disable > drm/i915: WARN if HDCP signalling is enabled upon disable > drm/i915: Intercept Aksv writes in the aux hooks > drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP > signalling > drm/i915: Factor out hdcp->value assignments > drm/i915: Protect workers against disappearing connectors > drm/i915: Don't fully disable HDCP on a port if multiple pipes are > using it > drm/i915: Support DP MST in enc_to_dig_port() function > drm/i915: Use ddi_update_pipe in intel_dp_mst > drm/i915: Factor out HDCP shim functions from dp for use by dp_mst > drm/i915: Add HDCP 1.4 support for MST connectors > > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_ddi.c | 27 +- > drivers/gpu/drm/i915/display/intel_ddi.h | 2 + > .../drm/i915/display/intel_display_types.h| 27 +- > drivers/gpu/drm/i915/display/intel_dp.c | 619 +--- > drivers/gpu/drm/i915/display/intel_dp.h | 7 + > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 680 ++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + > drivers/gpu/drm/i915/display/intel_hdcp.c | 195 +++-- > drivers/gpu/drm/i915/display/intel_hdmi.c | 18 +- > include/drm/drm_hdcp.h| 3 + > 11 files changed, 932 insertions(+), 662 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c > > -- > Sean Paul, Software Engineer, Google / Chromium OS > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Check current i915_vma.pin_count status first on unbind (rev2)
== Series Details == Series: drm/i915: Check current i915_vma.pin_count status first on unbind (rev2) URL : https://patchwork.freedesktop.org/series/72529/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16264_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16264_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16264_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16264_full: ### IGT changes ### Possible regressions * igt@gem_caching@reads: - shard-hsw: [PASS][1] -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-hsw1/igt@gem_cach...@reads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-hsw1/igt@gem_cach...@reads.html Known issues Here are the changes found in Patchwork_16264_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@vcs1-queued: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb4/igt@gem_ctx_persiste...@vcs1-queued.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-iclb8/igt@gem_ctx_persiste...@vcs1-queued.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][7] -> [FAIL][8] ([i915#232]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-snb1/igt@gem_...@unwedge-stress.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb7/igt@gem_exec_sched...@preempt-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-iclb4/igt@gem_exec_sched...@preempt-bsd.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([i915#58] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-glk3/igt@gen9_exec_pa...@allowed-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-glk6/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#151] / [i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl9/igt@i915_pm_...@system-suspend-modeset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-skl5/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#413]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb7/igt@i915_pm_...@waitboost.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-iclb4/igt@i915_pm_...@waitboost.html * igt@kms_color@pipe-a-ctm-0-75: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#109]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl6/igt@kms_co...@pipe-a-ctm-0-75.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-skl4/igt@kms_co...@pipe-a-ctm-0-75.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#300]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16264/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([i915#69]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl2/i
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind
On 26/01/2020 10:23, Chris Wilson wrote:
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is
currently pinned, without waiting to see if the inflight operations may
unpin it. We see this problem with the shrinker trying to unbind the
active vma from inside its bind worker:
What is the actual problem? flush_work from a worker?
Regards,
Tvrtko
<6> [472.618968] Workqueue: events_unbound fence_work [i915]
<4> [472.618970] Call Trace:
<4> [472.618974] ? __schedule+0x2e5/0x810
<4> [472.618978] schedule+0x37/0xe0
<4> [472.618982] schedule_preempt_disabled+0xf/0x20
<4> [472.618984] __mutex_lock+0x281/0x9c0
<4> [472.618987] ? mark_held_locks+0x49/0x70
<4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60
<4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619122] i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915]
<4> [472.619208] i915_gem_shrink+0x328/0x660 [i915]
<4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915]
<4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80
<4> [472.619363] ? __alloc_pd+0xb/0x30 [i915]
<4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30
<4> [472.619368] ? __module_address+0x23/0xe0
<4> [472.619371] ? is_module_address+0x26/0x40
<4> [472.619374] ? static_obj+0x34/0x50
<4> [472.619376] ? lockdep_init_map+0x4d/0x1e0
<4> [472.619407] setup_page_dma+0xd/0x90 [i915]
<4> [472.619437] alloc_pd+0x29/0x50 [i915]
<4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915]
<4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915]
<4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915]
<4> [472.619577] __vma_bind+0x26/0x40 [i915]
<4> [472.619611] fence_work+0x1c/0x90 [i915]
<4> [472.619617] process_one_work+0x26a/0x620
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_vma.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 84e03da0d5f9..2ffc68e18dd0 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1190,18 +1190,6 @@ int __i915_vma_unbind(struct i915_vma *vma)
lockdep_assert_held(&vma->vm->mutex);
- /*
-* First wait upon any activity as retiring the request may
-* have side-effects such as unpinning or even unbinding this vma.
-*
-* XXX Actually waiting under the vm->mutex is a hinderance and
-* should be pipelined wherever possible. In cases where that is
-* unavoidable, we should lift the wait to before the mutex.
-*/
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
-
if (i915_vma_is_pinned(vma)) {
vma_print_allocator(vma, "is pinned");
return -EAGAIN;
@@ -1275,6 +1263,11 @@ int i915_vma_unbind(struct i915_vma *vma)
if (!drm_mm_node_allocated(&vma->node))
return 0;
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
+ return -EAGAIN;
+ }
+
if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
/* XXX not always required: nop_clear_range */
wakeref = intel_runtime_pm_get(&vm->i915->runtime_pm);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind
Quoting Tvrtko Ursulin (2020-01-27 14:15:57) > > On 26/01/2020 10:23, Chris Wilson wrote: > > Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is > > currently pinned, without waiting to see if the inflight operations may > > unpin it. We see this problem with the shrinker trying to unbind the > > active vma from inside its bind worker: > > What is the actual problem? flush_work from a worker? We hit the shrinker from the inside the worker (which is intended). But what is not intended is for the shrinker to wait on any of the workers, because of the potential recursion of waiting on one's self. The intention was that we avoid the shrinker waiting on the vma by keeping the vma pinned... But I only pinned the pages to prevent them being freed and not the worker to prevent the recursive wait. Heh. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release
On 26/01/2020 10:23, Chris Wilson wrote:
As we use a mutex to serialise the first acquire (as it may be a lengthy
operation), but only an atomic decrement for the release, we have to
be careful in case a second thread races and completes both
acquire/release as the first finishes its acquire.
Thread AThread B
i915_active_acquire i915_active_acquire
atomic_read() == 0 atomic_read() == 0
mutex_lock() mutex_lock()
atomic_read() == 0
ref->active();
atomic_inc()
mutex_unlock()
atomic_read() == 1
i915_active_release
atomic_dec_and_test() -> 0
ref->retire()
atomic_inc() -> 1
mutex_unlock()
So thread A has acquired the ref->active_count but since the ref was
still active at the time, it did not initialise it. By switching the
check inside the mutex to an atomic increment only if already active, we
close the race.
Fixes: c9ad602feabe ("drm/i915: Split i915_active.mutex into an irq-safe spinlock
for the rbtree")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index ace55d5d4ca7..9d6830885d2e 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -416,13 +416,15 @@ int i915_active_acquire(struct i915_active *ref)
if (err)
return err;
- if (!atomic_read(&ref->count) && ref->active)
- err = ref->active(ref);
- if (!err) {
- spin_lock_irq(&ref->tree_lock); /* vs __active_retire() */
- debug_active_activate(ref);
- atomic_inc(&ref->count);
- spin_unlock_irq(&ref->tree_lock);
+ if (likely(!i915_active_acquire_if_busy(ref))) {
+ if (ref->active)
+ err = ref->active(ref);
+ if (!err) {
+ spin_lock_irq(&ref->tree_lock); /* __active_retire() */
+ debug_active_activate(ref);
+ atomic_inc(&ref->count);
+ spin_unlock_irq(&ref->tree_lock);
+ }
}
mutex_unlock(&ref->mutex);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind
Quoting Chris Wilson (2020-01-27 14:20:21) > Quoting Tvrtko Ursulin (2020-01-27 14:15:57) > > > > On 26/01/2020 10:23, Chris Wilson wrote: > > > Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is > > > currently pinned, without waiting to see if the inflight operations may > > > unpin it. We see this problem with the shrinker trying to unbind the > > > active vma from inside its bind worker: > > > > What is the actual problem? flush_work from a worker? > > We hit the shrinker from the inside the worker (which is intended). But > what is not intended is for the shrinker to wait on any of the workers, > because of the potential recursion of waiting on one's self. The > intention was that we avoid the shrinker waiting on the vma by keeping > the vma pinned... But I only pinned the pages to prevent them being > freed and not the worker to prevent the recursive wait. > > Heh. Which then ties back into the whole i915_vma is not krefed, so to complete the destroy at the moment we need to sync with the workers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Suppress DC5/DC6 around DSB usage (rev2)
== Series Details == Series: drm/i915/tgl: Suppress DC5/DC6 around DSB usage (rev2) URL : https://patchwork.freedesktop.org/series/72549/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7811_full -> Patchwork_16265_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16265_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16265_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16265_full: ### IGT changes ### Possible regressions * igt@gem_partial_pwrite_pread@writes-after-reads-snoop: - shard-hsw: [PASS][1] -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-hsw6/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-hsw2/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html Warnings * igt@kms_prime@basic-crc: - shard-skl: [FAIL][3] ([i915#1031]) -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl10/igt@kms_pr...@basic-crc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-skl3/igt@kms_pr...@basic-crc.html Known issues Here are the changes found in Patchwork_16265_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-apl7/igt@gem_ctx_isolat...@vecs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-apl1/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_ctx_persistence@vcs1-queued: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb4/igt@gem_ctx_persiste...@vcs1-queued.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-iclb8/igt@gem_ctx_persiste...@vcs1-queued.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110854]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb4/igt@gem_exec_balan...@smoke.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-iclb8/igt@gem_exec_sched...@preempt-other-chain-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([i915#58] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-glk3/igt@gen9_exec_pa...@allowed-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-glk6/igt@gen9_exec_pa...@allowed-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#716]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl7/igt@gen9_exec_pa...@allowed-single.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#300]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@cursora-vs-flipa-legacy: - shard-snb: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/shard-snb1/igt@kms_cursor_leg...@cursora-vs-flipa-legacy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16265/shard-snb6/igt@kms_cursor_leg...@cursora-vs-flipa-legacy.html * igt@kms_draw_crc@draw-method-xrg
Re: [Intel-gfx] [PATCH 13/17] drm/i915: Introduce better global state handling
On Mon, Jan 20, 2020 at 07:47:24PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Our current global state handling is pretty ad-hoc. Let's try to
> make it better by imitating the standard drm core private object
> approach.
>
> The reason why we don't want to directly use the private objects
> is locking; Each private object has its own lock so if we
> introduce any global private objects we get serialized by that
> single lock across all pipes. The global state apporoach instead
> uses a read/write lock type of approach where each individual
> crtc lock counts as a read lock, and grabbing all the crtc locks
> allows one write access.
>
> Signed-off-by: Ville Syrjälä
Didn't spot any issues:
Reviewed-by: Imre Deak
Would be good to explain somewhere the difference between only locking
vs. serializing the state.
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_atomic.c | 7 +-
> drivers/gpu/drm/i915/display/intel_atomic.h | 4 +-
> drivers/gpu/drm/i915/display/intel_audio.c| 2 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c| 8 +-
> drivers/gpu/drm/i915/display/intel_display.c | 15 +-
> .../drm/i915/display/intel_display_types.h| 4 +
> .../gpu/drm/i915/display/intel_global_state.c | 223 ++
> .../gpu/drm/i915/display/intel_global_state.h | 87 +++
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> 10 files changed, 342 insertions(+), 12 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_global_state.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_global_state.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 3c88d7d8c764..787ffe669810 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -190,6 +190,7 @@ i915-y += \
> display/intel_fbc.o \
> display/intel_fifo_underrun.o \
> display/intel_frontbuffer.o \
> + display/intel_global_state.o \
> display/intel_hdcp.o \
> display/intel_hotplug.o \
> display/intel_lpe_audio.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 1c13423d4945..45842ebcdebd 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -37,6 +37,7 @@
> #include "intel_atomic.h"
> #include "intel_cdclk.h"
> #include "intel_display_types.h"
> +#include "intel_global_state.h"
> #include "intel_hdcp.h"
> #include "intel_psr.h"
> #include "intel_sprite.h"
> @@ -500,6 +501,7 @@ void intel_atomic_state_free(struct drm_atomic_state
> *_state)
> struct intel_atomic_state *state = to_intel_atomic_state(_state);
>
> drm_atomic_state_default_release(&state->base);
> + kfree(state->global_objs);
>
> i915_sw_fence_fini(&state->commit_ready);
>
> @@ -511,6 +513,7 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
> struct intel_atomic_state *state = to_intel_atomic_state(s);
>
> drm_atomic_state_default_clear(&state->base);
> + intel_atomic_clear_global_state(state);
>
> state->dpll_set = state->modeset = false;
> state->global_state_changed = false;
> @@ -530,7 +533,7 @@ intel_atomic_get_crtc_state(struct drm_atomic_state
> *state,
> return to_intel_crtc_state(crtc_state);
> }
>
> -int intel_atomic_lock_global_state(struct intel_atomic_state *state)
> +int _intel_atomic_lock_global_state(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> struct intel_crtc *crtc;
> @@ -549,7 +552,7 @@ int intel_atomic_lock_global_state(struct
> intel_atomic_state *state)
> return 0;
> }
>
> -int intel_atomic_serialize_global_state(struct intel_atomic_state *state)
> +int _intel_atomic_serialize_global_state(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> struct intel_crtc *crtc;
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
> b/drivers/gpu/drm/i915/display/intel_atomic.h
> index 88133eea0a17..11146292b06f 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> @@ -56,8 +56,8 @@ int intel_atomic_setup_scalers(struct drm_i915_private
> *dev_priv,
> struct intel_crtc *intel_crtc,
> struct intel_crtc_state *crtc_state);
>
> -int intel_atomic_lock_global_state(struct intel_atomic_state *state);
> +int _intel_atomic_lock_global_state(struct intel_atomic_state *state);
>
> -int intel_atomic_serialize_global_state(struct intel_atomic_state *state);
> +int _intel_atomic_serialize_global_state(struct intel_atomic_state *state);
>
> #endif /* __INTEL_ATOMIC_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 32e722
Re: [Intel-gfx] [PATCH 14/17] drm/i915: Convert bandwidth state to global state
On Mon, Jan 20, 2020 at 07:47:25PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we have the more formal global state thing let's
> use if for memory bandwidth tracking. No real difference
> to the current private object usage since we already
> tried to avoid taking the single serializing lock needlessly.
> But since we're going to roll the global state out to more
> things probably a good idea to unify the approaches a bit.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 31 +---
> drivers/gpu/drm/i915/display/intel_bw.h | 4 +--
> drivers/gpu/drm/i915/display/intel_display.c | 2 --
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 4 files changed, 17 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index b228671d5a5d..316abcf3e6a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -374,10 +374,9 @@ static struct intel_bw_state *
> intel_atomic_get_bw_state(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct drm_private_state *bw_state;
> + struct intel_global_state *bw_state;
>
> - bw_state = drm_atomic_get_private_obj_state(&state->base,
> - &dev_priv->bw_obj);
> + bw_state = intel_atomic_get_global_obj_state(state, &dev_priv->bw_obj);
> if (IS_ERR(bw_state))
> return ERR_CAST(bw_state);
>
> @@ -392,7 +391,7 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
> unsigned int data_rate, max_data_rate;
> unsigned int num_active_planes;
> struct intel_crtc *crtc;
> - int i;
> + int i, ret;
>
> /* FIXME earlier gens need some checks too */
> if (INTEL_GEN(dev_priv) < 11)
> @@ -433,6 +432,10 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
> if (!bw_state)
> return 0;
>
> + ret = intel_atomic_lock_global_state(&bw_state->base);
> + if (ret)
> + return ret;
> +
So getting the state already read locked it and the above will write
lock it. For clarity the above func could be named accordingly. Either
way:
Reviewed-by: Imre Deak
> data_rate = intel_bw_data_rate(dev_priv, bw_state);
> num_active_planes = intel_bw_num_active_planes(dev_priv, bw_state);
>
> @@ -449,7 +452,8 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
> return 0;
> }
>
> -static struct drm_private_state *intel_bw_duplicate_state(struct
> drm_private_obj *obj)
> +static struct intel_global_state *
> +intel_bw_duplicate_state(struct intel_global_obj *obj)
> {
> struct intel_bw_state *state;
>
> @@ -457,18 +461,16 @@ static struct drm_private_state
> *intel_bw_duplicate_state(struct drm_private_obj
> if (!state)
> return NULL;
>
> - __drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
> -
> return &state->base;
> }
>
> -static void intel_bw_destroy_state(struct drm_private_obj *obj,
> -struct drm_private_state *state)
> +static void intel_bw_destroy_state(struct intel_global_obj *obj,
> +struct intel_global_state *state)
> {
> kfree(state);
> }
>
> -static const struct drm_private_state_funcs intel_bw_funcs = {
> +static const struct intel_global_state_funcs intel_bw_funcs = {
> .atomic_duplicate_state = intel_bw_duplicate_state,
> .atomic_destroy_state = intel_bw_destroy_state,
> };
> @@ -481,13 +483,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
> if (!state)
> return -ENOMEM;
>
> - drm_atomic_private_obj_init(&dev_priv->drm, &dev_priv->bw_obj,
> - &state->base, &intel_bw_funcs);
> + intel_atomic_global_obj_init(dev_priv, &dev_priv->bw_obj,
> + &state->base, &intel_bw_funcs);
>
> return 0;
> }
> -
> -void intel_bw_cleanup(struct drm_i915_private *dev_priv)
> -{
> - drm_atomic_private_obj_fini(&dev_priv->bw_obj);
> -}
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index 20b9ad241802..a8aa7624c5aa 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -9,13 +9,14 @@
> #include
>
> #include "intel_display.h"
> +#include "intel_global_state.h"
>
> struct drm_i915_private;
> struct intel_atomic_state;
> struct intel_crtc_state;
>
> struct intel_bw_state {
> - struct drm_private_state base;
> + struct intel_global_state base;
>
> unsigned int data_rate[I915_MAX_PIPES];
> u8 num_active_planes[I915_MAX_PIPES];
> @@ -25,7 +26,6 @@ struct intel_bw_state {
>
> void intel_bw_init_hw(struct drm_i915_private *dev
Re: [Intel-gfx] [PATCH 15/17] drm/i915: Introduce intel_calc_active_pipes()
On Mon, Jan 20, 2020 at 07:47:26PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract a small helper to compute the active pipes bitmask
> based on the old bitmask + the crtcs in the atomic state.
> I want to decouple the cdclk state entirely from the current
> global state so I want to track the active pipes also inside
> the (to be introduced) full cdclk state.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 34
> drivers/gpu/drm/i915/display/intel_display.h | 3 ++
> 2 files changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f5396c5c00c6..dc767efffd9a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14359,26 +14359,32 @@ static int hsw_mode_set_planes_workaround(struct
> intel_atomic_state *state)
> return 0;
> }
>
> +u8 intel_calc_active_pipes(struct intel_atomic_state *state,
> +u8 active_pipes)
> +{
> + const struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> + int i;
> +
> + for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> + if (crtc_state->hw.active)
> + active_pipes |= BIT(crtc->pipe);
> + else
> + active_pipes &= ~BIT(crtc->pipe);
> + }
> +
> + return active_pipes;
> +}
> +
> static int intel_modeset_checks(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> - struct intel_crtc *crtc;
> - int ret, i;
> + int ret;
>
> state->modeset = true;
> - state->active_pipes = dev_priv->active_pipes;
> + state->active_pipes = intel_calc_active_pipes(state,
> dev_priv->active_pipes);
>
> - for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> - new_crtc_state, i) {
> - if (new_crtc_state->hw.active)
> - state->active_pipes |= BIT(crtc->pipe);
> - else
> - state->active_pipes &= ~BIT(crtc->pipe);
> -
> - if (old_crtc_state->hw.active != new_crtc_state->hw.active)
> - state->active_pipe_changes |= BIT(crtc->pipe);
> - }
> + state->active_pipe_changes = state->active_pipes ^
> dev_priv->active_pipes;
>
> if (state->active_pipe_changes) {
> ret = _intel_atomic_lock_global_state(state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 028aab728514..e2de0d9d22bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -44,6 +44,7 @@ struct drm_modeset_acquire_ctx;
> struct drm_plane;
> struct drm_plane_state;
> struct i915_ggtt_view;
> +struct intel_atomic_state;
> struct intel_crtc;
> struct intel_crtc_state;
> struct intel_digital_port;
> @@ -469,6 +470,8 @@ enum phy_fia {
>((connector) =
> to_intel_connector((__state)->base.connectors[__i].ptr), \
>(new_connector_state) =
> to_intel_digital_connector_state((__state)->base.connectors[__i].new_state),
> 1))
>
> +u8 intel_calc_active_pipes(struct intel_atomic_state *state,
> +u8 active_pipes);
> void intel_link_compute_m_n(u16 bpp, int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
Similar to commit ac0e331a628b ("drm/i915: Tighten atomicity of
i915_active_acquire vs i915_active_release") we have the same race of
trying to pin the context underneath a mutex while allowing the
decrement to be atomic outside of that mutex. This leads to the problem
where two threads may simultaneously try to pin the context and the
second not notice that they needed to repin the context.
<2> [198.669621] kernel BUG at drivers/gpu/drm/i915/gt/intel_timeline.c:387!
<4> [198.669703] invalid opcode: [#1] PREEMPT SMP PTI
<4> [198.669712] CPU: 0 PID: 1246 Comm: gem_exec_create Tainted: G U W
5.5.0-rc6-CI-CI_DRM_7755+ #1
<4> [198.669723] Hardware name: /NUC7i5BNB, BIOS
BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4> [198.669776] RIP: 0010:timeline_advance+0x7b/0xe0 [i915]
<4> [198.669785] Code: 00 48 c7 c2 10 f1 46 a0 48 c7 c7 70 1b 32 a0 e8 bb dd e7
e0 bf 01 00 00 00 e8 d1 af e7 e0 31 f6 bf 09 00 00 00 e8 35 ef d8 e0 <0f> 0b 48
c7 c1 48 fa 49 a0 ba 84 01 00 00 48 c7 c6 10 f1 46 a0 48
<4> [198.669803] RSP: 0018:c94c3a38 EFLAGS: 00010296
<4> [198.669810] RAX: 888270b35140 RBX: 88826f32ee00 RCX:
0006
<4> [198.669818] RDX: 17c5 RSI: RDI:
0009
<4> [198.669826] RBP: c94c3a64 R08: R09:
<4> [198.669834] R10: R11: R12:
88826f9b5980
<4> [198.669841] R13: 0cc0 R14: c94c3dc0 R15:
888253610068
<4> [198.669849] FS: 7f63e663fe40() GS:888276c0()
knlGS:
<4> [198.669857] CS: 0010 DS: ES: CR0: 80050033
<4> [198.669864] CR2: 7f171f8e39a8 CR3: 00026b1f6005 CR4:
003606f0
<4> [198.669872] Call Trace:
<4> [198.669924] intel_timeline_get_seqno+0x12/0x40 [i915]
<4> [198.669977] __i915_request_create+0x76/0x5a0 [i915]
<4> [198.670024] i915_request_create+0x86/0x1c0 [i915]
<4> [198.670068] i915_gem_do_execbuffer+0xbf2/0x2500 [i915]
<4> [198.670082] ? __lock_acquire+0x460/0x15d0
<4> [198.670128] i915_gem_execbuffer2_ioctl+0x11f/0x470 [i915]
<4> [198.670171] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
<4> [198.670181] drm_ioctl_kernel+0xa7/0xf0
<4> [198.670188] drm_ioctl+0x2e1/0x390
<4> [198.670233] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context
pin/unpin")
References: ac0e331a628b ("drm/i915: Tighten atomicity of i915_active_acquire
vs i915_active_release")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 46 ++---
drivers/gpu/drm/i915/i915_active.h | 6
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 23137b2a8689..57e8a051ddc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -67,21 +67,18 @@ static int intel_context_active_acquire(struct
intel_context *ce)
{
int err;
- err = i915_active_acquire(&ce->active);
- if (err)
- return err;
+ __i915_active_acquire(&ce->active);
+
+ if (intel_context_is_barrier(ce))
+ return 0;
/* Preallocate tracking nodes */
- if (!intel_context_is_barrier(ce)) {
- err = i915_active_acquire_preallocate_barrier(&ce->active,
- ce->engine);
- if (err) {
- i915_active_release(&ce->active);
- return err;
- }
- }
+ err = i915_active_acquire_preallocate_barrier(&ce->active,
+ ce->engine);
+ if (err)
+ i915_active_release(&ce->active);
- return 0;
+ return err;
}
static void intel_context_active_release(struct intel_context *ce)
@@ -101,13 +98,19 @@ int __intel_context_do_pin(struct intel_context *ce)
return err;
}
- if (mutex_lock_interruptible(&ce->pin_mutex))
- return -EINTR;
+ err = i915_active_acquire(&ce->active);
+ if (err)
+ return err;
+
+ if (mutex_lock_interruptible(&ce->pin_mutex)) {
+ err = -EINTR;
+ goto out_release;
+ }
- if (likely(!atomic_read(&ce->pin_count))) {
+ if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
err = intel_context_active_acquire(ce);
if (unlikely(err))
- goto err;
+ goto out_unlock;
err = ce->ops->pin(ce);
if (unlikely(err))
@@ -117,18 +120,19 @@ int __intel_context_do_pin(struct intel_context *ce)
ce->ring->head, ce->ring->tail);
smp_mb__before_atomic(); /* flush pin before it
Re: [Intel-gfx] [PATCH 4/6] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
On 26/01/2020 10:23, Chris Wilson wrote:
<0> [198.668822] gem_exec-12460 193899010us : timeline_advance:
timeline_advance:387 GEM_BUG_ON(!atomic_read(&tl->pin_count))
<0> [198.668859] -
<4> [198.669619] [ cut here ]
<2> [198.669621] kernel BUG at drivers/gpu/drm/i915/gt/intel_timeline.c:387!
<4> [198.669703] invalid opcode: [#1] PREEMPT SMP PTI
<4> [198.669712] CPU: 0 PID: 1246 Comm: gem_exec_create Tainted: G U W
5.5.0-rc6-CI-CI_DRM_7755+ #1
<4> [198.669723] Hardware name: /NUC7i5BNB, BIOS
BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4> [198.669776] RIP: 0010:timeline_advance+0x7b/0xe0 [i915]
<4> [198.669785] Code: 00 48 c7 c2 10 f1 46 a0 48 c7 c7 70 1b 32 a0 e8 bb dd e7 e0 bf
01 00 00 00 e8 d1 af e7 e0 31 f6 bf 09 00 00 00 e8 35 ef d8 e0 <0f> 0b 48 c7 c1 48 fa
49 a0 ba 84 01 00 00 48 c7 c6 10 f1 46 a0 48
<4> [198.669803] RSP: 0018:c94c3a38 EFLAGS: 00010296
<4> [198.669810] RAX: 888270b35140 RBX: 88826f32ee00 RCX:
0006
<4> [198.669818] RDX: 17c5 RSI: RDI:
0009
<4> [198.669826] RBP: c94c3a64 R08: R09:
<4> [198.669834] R10: R11: R12:
88826f9b5980
<4> [198.669841] R13: 0cc0 R14: c94c3dc0 R15:
888253610068
<4> [198.669849] FS: 7f63e663fe40() GS:888276c0()
knlGS:
<4> [198.669857] CS: 0010 DS: ES: CR0: 80050033
<4> [198.669864] CR2: 7f171f8e39a8 CR3: 00026b1f6005 CR4:
003606f0
<4> [198.669872] Call Trace:
<4> [198.669924] intel_timeline_get_seqno+0x12/0x40 [i915]
<4> [198.669977] __i915_request_create+0x76/0x5a0 [i915]
<4> [198.670024] i915_request_create+0x86/0x1c0 [i915]
<4> [198.670068] i915_gem_do_execbuffer+0xbf2/0x2500 [i915]
<4> [198.670082] ? __lock_acquire+0x460/0x15d0
<4> [198.670128] i915_gem_execbuffer2_ioctl+0x11f/0x470 [i915]
<4> [198.670171] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
<4> [198.670181] drm_ioctl_kernel+0xa7/0xf0
<4> [198.670188] drm_ioctl+0x2e1/0x390
<4> [198.670233] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context
pin/unpin")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 46 ++---
drivers/gpu/drm/i915/i915_active.h | 6
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 23137b2a8689..57e8a051ddc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -67,21 +67,18 @@ static int intel_context_active_acquire(struct
intel_context *ce)
{
int err;
- err = i915_active_acquire(&ce->active);
- if (err)
- return err;
+ __i915_active_acquire(&ce->active);
+
+ if (intel_context_is_barrier(ce))
+ return 0;
/* Preallocate tracking nodes */
- if (!intel_context_is_barrier(ce)) {
- err = i915_active_acquire_preallocate_barrier(&ce->active,
- ce->engine);
- if (err) {
- i915_active_release(&ce->active);
- return err;
- }
- }
+ err = i915_active_acquire_preallocate_barrier(&ce->active,
+ ce->engine);
+ if (err)
+ i915_active_release(&ce->active);
- return 0;
+ return err;
}
static void intel_context_active_release(struct intel_context *ce)
@@ -101,13 +98,19 @@ int __intel_context_do_pin(struct intel_context *ce)
return err;
}
- if (mutex_lock_interruptible(&ce->pin_mutex))
- return -EINTR;
+ err = i915_active_acquire(&ce->active);
+ if (err)
+ return err;
+
+ if (mutex_lock_interruptible(&ce->pin_mutex)) {
+ err = -EINTR;
+ goto out_release;
+ }
- if (likely(!atomic_read(&ce->pin_count))) {
+ if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
err = intel_context_active_acquire(ce);
if (unlikely(err))
- goto err;
+ goto out_unlock;
err = ce->ops->pin(ce);
if (unlikely(err))
@@ -117,18 +120,19 @@ int __intel_context_do_pin(struct intel_context *ce)
ce->ring->head, ce->ring->tail);
smp_mb__before_atomic(); /* flush pin before it is visible */
+ atomic_inc(&ce->pin_count);
}
- atomic_inc(&ce->pin_count);
GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
-
- mutex_unlock(&ce->pin_mutex);
- return 0;
+ GEM_BUG_ON(i915_active_is_idl
Re: [Intel-gfx] [PATCH 4/6] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
Quoting Tvrtko Ursulin (2020-01-27 15:33:44)
>
> On 26/01/2020 10:23, Chris Wilson wrote:
> > <0> [198.668822] gem_exec-12460 193899010us : timeline_advance:
> > timeline_advance:387 GEM_BUG_ON(!atomic_read(&tl->pin_count))
> > <0> [198.668859] -
> > <4> [198.669619] [ cut here ]
> > <2> [198.669621] kernel BUG at drivers/gpu/drm/i915/gt/intel_timeline.c:387!
> > <4> [198.669703] invalid opcode: [#1] PREEMPT SMP PTI
> > <4> [198.669712] CPU: 0 PID: 1246 Comm: gem_exec_create Tainted: G U W
> > 5.5.0-rc6-CI-CI_DRM_7755+ #1
> > <4> [198.669723] Hardware name: /NUC7i5BNB, BIOS
> > BNKBL357.86A.0054.2017.1025.1822 10/25/2017
> > <4> [198.669776] RIP: 0010:timeline_advance+0x7b/0xe0 [i915]
> > <4> [198.669785] Code: 00 48 c7 c2 10 f1 46 a0 48 c7 c7 70 1b 32 a0 e8 bb
> > dd e7 e0 bf 01 00 00 00 e8 d1 af e7 e0 31 f6 bf 09 00 00 00 e8 35 ef d8 e0
> > <0f> 0b 48 c7 c1 48 fa 49 a0 ba 84 01 00 00 48 c7 c6 10 f1 46 a0 48
> > <4> [198.669803] RSP: 0018:c94c3a38 EFLAGS: 00010296
> > <4> [198.669810] RAX: 888270b35140 RBX: 88826f32ee00 RCX:
> > 0006
> > <4> [198.669818] RDX: 17c5 RSI: RDI:
> > 0009
> > <4> [198.669826] RBP: c94c3a64 R08: R09:
> >
> > <4> [198.669834] R10: R11: R12:
> > 88826f9b5980
> > <4> [198.669841] R13: 0cc0 R14: c94c3dc0 R15:
> > 888253610068
> > <4> [198.669849] FS: 7f63e663fe40() GS:888276c0()
> > knlGS:
> > <4> [198.669857] CS: 0010 DS: ES: CR0: 80050033
> > <4> [198.669864] CR2: 7f171f8e39a8 CR3: 00026b1f6005 CR4:
> > 003606f0
> > <4> [198.669872] Call Trace:
> > <4> [198.669924] intel_timeline_get_seqno+0x12/0x40 [i915]
> > <4> [198.669977] __i915_request_create+0x76/0x5a0 [i915]
> > <4> [198.670024] i915_request_create+0x86/0x1c0 [i915]
> > <4> [198.670068] i915_gem_do_execbuffer+0xbf2/0x2500 [i915]
> > <4> [198.670082] ? __lock_acquire+0x460/0x15d0
> > <4> [198.670128] i915_gem_execbuffer2_ioctl+0x11f/0x470 [i915]
> > <4> [198.670171] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
> > <4> [198.670181] drm_ioctl_kernel+0xa7/0xf0
> > <4> [198.670188] drm_ioctl+0x2e1/0x390
> > <4> [198.670233] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
> >
> > Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context
> > pin/unpin")
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 46 ++---
> > drivers/gpu/drm/i915/i915_active.h | 6
> > 2 files changed, 31 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 23137b2a8689..57e8a051ddc2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -67,21 +67,18 @@ static int intel_context_active_acquire(struct
> > intel_context *ce)
> > {
> > int err;
> >
> > - err = i915_active_acquire(&ce->active);
> > - if (err)
> > - return err;
> > + __i915_active_acquire(&ce->active);
> > +
> > + if (intel_context_is_barrier(ce))
> > + return 0;
> >
> > /* Preallocate tracking nodes */
> > - if (!intel_context_is_barrier(ce)) {
> > - err = i915_active_acquire_preallocate_barrier(&ce->active,
> > - ce->engine);
> > - if (err) {
> > - i915_active_release(&ce->active);
> > - return err;
> > - }
> > - }
> > + err = i915_active_acquire_preallocate_barrier(&ce->active,
> > + ce->engine);
> > + if (err)
> > + i915_active_release(&ce->active);
> >
> > - return 0;
> > + return err;
> > }
> >
> > static void intel_context_active_release(struct intel_context *ce)
> > @@ -101,13 +98,19 @@ int __intel_context_do_pin(struct intel_context *ce)
> > return err;
> > }
> >
> > - if (mutex_lock_interruptible(&ce->pin_mutex))
> > - return -EINTR;
> > + err = i915_active_acquire(&ce->active);
> > + if (err)
> > + return err;
> > +
> > + if (mutex_lock_interruptible(&ce->pin_mutex)) {
> > + err = -EINTR;
> > + goto out_release;
> > + }
> >
> > - if (likely(!atomic_read(&ce->pin_count))) {
> > + if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
> > err = intel_context_active_acquire(ce);
> > if (unlikely(err))
> > - goto err;
> > + goto out_unlock;
> >
> > err = ce->ops->pin(ce);
> > if (unlikely(err))
> > @@ -117,1
Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
On 26/01/2020 10:23, Chris Wilson wrote:
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.
v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 ++
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 32 +++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 31 ---
drivers/gpu/drm/i915/i915_reg.h | 5 +++
4 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 92be41a6903c..58725024ffa4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -156,6 +156,15 @@ struct intel_engine_execlists {
*/
struct i915_priolist default_priolist;
+ /**
+* @yield: CCID at the time of the last semaphore-wait interrupt.
+*
+* Instead of leaving a semaphore busy-spinning on an engine, we would
+* like to switch to another ready context, i.e. yielding the semaphore
+* timeslice.
+*/
+ u32 yield;
+
/**
* @no_priolist: priority lists disabled
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f796bdf1ed30..6ae64a224b02 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -24,6 +24,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
{
bool tasklet = false;
+ if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
+ WRITE_ONCE(engine->execlists.yield,
+ ENGINE_READ_FW(engine, EXECLIST_CCID));
+ if (del_timer(&engine->execlists.timer))
+ tasklet = true;
What if it fires before timeslice timer has been set up and when we miss
to yield?
+ }
+
if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
tasklet = true;
@@ -210,7 +217,10 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
void gen11_gt_irq_postinstall(struct intel_gt *gt)
{
- const u32 irqs = GT_RENDER_USER_INTERRUPT | GT_CONTEXT_SWITCH_INTERRUPT;
+ const u32 irqs =
+ GT_RENDER_USER_INTERRUPT |
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
const u32 dmask = irqs << 16 | irqs;
const u32 smask = irqs << 16;
@@ -357,21 +367,15 @@ void gen8_gt_irq_postinstall(struct intel_gt *gt)
struct intel_uncore *uncore = gt->uncore;
/* These are interrupts we'll toggle with the ring mask register */
+ const u32 irqs =
+ GT_RENDER_USER_INTERRUPT |
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
u32 gt_interrupts[] = {
- (GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
-GT_CONTEXT_SWITCH_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
-GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT |
-GT_CONTEXT_SWITCH_INTERRUPT << GEN8_BCS_IRQ_SHIFT),
-
- (GT_RENDER_USER_INTERRUPT << GEN8_VCS0_IRQ_SHIFT |
-GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VCS0_IRQ_SHIFT |
-GT_RENDER_USER_INTERRUPT << GEN8_VCS1_IRQ_SHIFT |
-GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VCS1_IRQ_SHIFT),
-
+ irqs << GEN8_RCS_IRQ_SHIFT | irqs << GEN8_BCS_IRQ_SHIFT,
+ irqs << GEN8_VCS0_IRQ_SHIFT | irqs << GEN8_VCS1_IRQ_SHIFT,
0,
-
- (GT_RENDER_USER_INTERRUPT << GEN8_VECS_IRQ_SHIFT |
-GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VECS_IRQ_SHIFT)
+ irqs << GEN8_VECS_IRQ_SHIFT,
};
gt->pm_ier = 0x0;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a13a8c4b65ab..6ba5a634c6
Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
Quoting Tvrtko Ursulin (2020-01-27 15:52:51)
>
> On 26/01/2020 10:23, Chris Wilson wrote:
> > If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
> > user batch or in our own preamble, the engine raises a
> > GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
> > respond to a semaphore wait by yielding the timeslice, if we have
> > another context to yield to!
> >
> > The only real complication is that the interrupt is only generated for
> > the start of the semaphore wait, and is asynchronous to our
> > process_csb() -- that is, we may not have registered the timeslice before
> > we see the interrupt. To ensure we don't miss a potential semaphore
> > blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
> > the interrupt and apply it to the next timeslice regardless of whether it
> > was active at the time.
> >
> > v2: We use semaphores in preempt-to-busy, within the timeslicing
> > implementation itself! Ergo, when we do insert a preemption due to an
> > expired timeslice, the new context may start with the missed semaphore
> > flagged by the retired context and be yielded, ad infinitum. To avoid
> > this, read the context id at the time of the semaphore interrupt and
> > only yield if that context is still active.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 ++
> > drivers/gpu/drm/i915/gt/intel_gt_irq.c | 32 +++-
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 31 ---
> > drivers/gpu/drm/i915/i915_reg.h | 5 +++
> > 4 files changed, 59 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 92be41a6903c..58725024ffa4 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -156,6 +156,15 @@ struct intel_engine_execlists {
> >*/
> > struct i915_priolist default_priolist;
> >
> > + /**
> > + * @yield: CCID at the time of the last semaphore-wait interrupt.
> > + *
> > + * Instead of leaving a semaphore busy-spinning on an engine, we would
> > + * like to switch to another ready context, i.e. yielding the
> > semaphore
> > + * timeslice.
> > + */
> > + u32 yield;
> > +
> > /**
> >* @no_priolist: priority lists disabled
> >*/
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > index f796bdf1ed30..6ae64a224b02 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > @@ -24,6 +24,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
> > {
> > bool tasklet = false;
> >
> > + if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
> > + WRITE_ONCE(engine->execlists.yield,
> > +ENGINE_READ_FW(engine, EXECLIST_CCID));
> > + if (del_timer(&engine->execlists.timer))
> > + tasklet = true;
>
> What if it fires before timeslice timer has been set up and when we miss
> to yield?
We only set the timer after the HW ack, and we can legitimately hit a
semaphore in the user payload before we see the ack. That is
demonstrated aptly by live_timeslice_preempt.
> > + }
> > +
> > if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
> > tasklet = true;
> >
> > @@ -210,7 +217,10 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> >
> > void gen11_gt_irq_postinstall(struct intel_gt *gt)
> > {
> > - const u32 irqs = GT_RENDER_USER_INTERRUPT |
> > GT_CONTEXT_SWITCH_INTERRUPT;
> > + const u32 irqs =
> > + GT_RENDER_USER_INTERRUPT |
> > + GT_CONTEXT_SWITCH_INTERRUPT |
> > + GT_WAIT_SEMAPHORE_INTERRUPT;
> > struct intel_uncore *uncore = gt->uncore;
> > const u32 dmask = irqs << 16 | irqs;
> > const u32 smask = irqs << 16;
> > @@ -357,21 +367,15 @@ void gen8_gt_irq_postinstall(struct intel_gt *gt)
> > struct intel_uncore *uncore = gt->uncore;
> >
> > /* These are interrupts we'll toggle with the ring mask register */
> > + const u32 irqs =
> > + GT_RENDER_USER_INTERRUPT |
> > + GT_CONTEXT_SWITCH_INTERRUPT |
> > + GT_WAIT_SEMAPHORE_INTERRUPT;
> > u32 gt_interrupts[] = {
> > - (GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> > - GT_CONTEXT_SWITCH_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> > - GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT |
> > - GT_CONTEXT_SWITCH_INTERRUPT << GEN8_BCS_IRQ_SHIFT),
> > -
> > - (GT_RENDER_USER_INTERRUPT << GEN8_VCS0_IRQ_SHIFT |
> > - GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VCS0_IRQ_SHIFT |
> > - GT_RENDER_USER_INTERRUPT << GEN8_VCS1_IRQ_SHIFT |
> > -
Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
Quoting Chris Wilson (2020-01-27 16:03:11)
> Quoting Tvrtko Ursulin (2020-01-27 15:52:51)
> >
> > On 26/01/2020 10:23, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > > b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > > index f796bdf1ed30..6ae64a224b02 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> > > @@ -24,6 +24,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
> > > {
> > > bool tasklet = false;
> > >
> > > + if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
> > > + WRITE_ONCE(engine->execlists.yield,
> > > +ENGINE_READ_FW(engine, EXECLIST_CCID));
> > > + if (del_timer(&engine->execlists.timer))
> > > + tasklet = true;
> >
> > What if it fires before timeslice timer has been set up and when we miss
> > to yield?
>
> We only set the timer after the HW ack, and we can legitimately hit a
> semaphore in the user payload before we see the ack. That is
> demonstrated aptly by live_timeslice_preempt.
Hmm. I thought we would see the yield such that we would dequeue and
process the new timelice regardless of the previous timer.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Include the AUX CH name in the debug messages
On Thu, Jan 23, 2020 at 09:19:04AM -0800, Matt Roper wrote:
> On Thu, Jan 23, 2020 at 05:45:41PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To make it easier to figure out what caused a particular debug
> > message let's print out aux->name.
> >
> > Signed-off-by: Ville Syrjälä
>
> It might be worth adding commas to some of these messages too while
> we're at it (e.g., "not started, status"). But either way, this is a
> really helpful cleanup.
Good idea. The first one of these already uses
"%s: blah (status 0x%x)" as the format, so I went ahead and
converted the rest to follow the same style.
>
> Reviewed-by: Matt Roper
2-3 pushed to dinq. Thanks for the review.
>
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 19 +++
> > 1 file changed, 11 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 1795963e1866..941f0f6d55c1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1186,7 +1186,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> >
> > if (!done)
> > - DRM_ERROR("%s did not complete or timeout within %ums (status
> > 0x%08x)\n",
> > + DRM_ERROR("%s: did not complete or timeout within %ums (status
> > 0x%08x)\n",
> > intel_dp->aux.name, timeout_ms, status);
> > #undef C
> >
> > @@ -1373,8 +1373,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > const u32 status = intel_uncore_read(uncore, ch_ctl);
> >
> > if (status != intel_dp->aux_busy_last_status) {
> > - WARN(1, "dp_aux_ch not started status 0x%08x\n",
> > -status);
> > + WARN(1, "%s: not started status 0x%08x\n",
> > +intel_dp->aux.name, status);
> > intel_dp->aux_busy_last_status = status;
> > }
> >
> > @@ -1435,7 +1435,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > }
> >
> > if ((status & DP_AUX_CH_CTL_DONE) == 0) {
> > - DRM_ERROR("dp_aux_ch not done status 0x%08x\n", status);
> > + DRM_ERROR("%s: not done status 0x%08x\n",
> > + intel_dp->aux.name, status);
> > ret = -EBUSY;
> > goto out;
> > }
> > @@ -1445,7 +1446,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > * Timeouts occur when the sink is not connected
> > */
> > if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> > - DRM_ERROR("dp_aux_ch receive error status 0x%08x\n", status);
> > + DRM_ERROR("%s: receive error status 0x%08x\n",
> > + intel_dp->aux.name, status);
> > ret = -EIO;
> > goto out;
> > }
> > @@ -1453,7 +1455,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > /* Timeouts occur when the device isn't connected, so they're
> > * "normal" -- don't fill the kernel log with these */
> > if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR) {
> > - DRM_DEBUG_KMS("dp_aux_ch timeout status 0x%08x\n", status);
> > + DRM_DEBUG_KMS("%s: timeout status 0x%08x\n",
> > + intel_dp->aux.name, status);
> > ret = -ETIMEDOUT;
> > goto out;
> > }
> > @@ -1468,8 +1471,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > * drm layer takes care for the necessary retries.
> > */
> > if (recv_bytes == 0 || recv_bytes > 20) {
> > - DRM_DEBUG_KMS("Forbidden recv_bytes = %d on aux transaction\n",
> > - recv_bytes);
> > + DRM_DEBUG_KMS("%s: Forbidden recv_bytes = %d on aux
> > transaction\n",
> > + intel_dp->aux.name, recv_bytes);
> > ret = -EBUSY;
> > goto out;
> > }
> > --
> > 2.24.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
On 27/01/2020 15:28, Chris Wilson wrote:
Similar to commit ac0e331a628b ("drm/i915: Tighten atomicity of
i915_active_acquire vs i915_active_release") we have the same race of
trying to pin the context underneath a mutex while allowing the
decrement to be atomic outside of that mutex. This leads to the problem
where two threads may simultaneously try to pin the context and the
second not notice that they needed to repin the context.
<2> [198.669621] kernel BUG at drivers/gpu/drm/i915/gt/intel_timeline.c:387!
<4> [198.669703] invalid opcode: [#1] PREEMPT SMP PTI
<4> [198.669712] CPU: 0 PID: 1246 Comm: gem_exec_create Tainted: G U W
5.5.0-rc6-CI-CI_DRM_7755+ #1
<4> [198.669723] Hardware name: /NUC7i5BNB, BIOS
BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4> [198.669776] RIP: 0010:timeline_advance+0x7b/0xe0 [i915]
<4> [198.669785] Code: 00 48 c7 c2 10 f1 46 a0 48 c7 c7 70 1b 32 a0 e8 bb dd e7 e0 bf
01 00 00 00 e8 d1 af e7 e0 31 f6 bf 09 00 00 00 e8 35 ef d8 e0 <0f> 0b 48 c7 c1 48 fa
49 a0 ba 84 01 00 00 48 c7 c6 10 f1 46 a0 48
<4> [198.669803] RSP: 0018:c94c3a38 EFLAGS: 00010296
<4> [198.669810] RAX: 888270b35140 RBX: 88826f32ee00 RCX:
0006
<4> [198.669818] RDX: 17c5 RSI: RDI:
0009
<4> [198.669826] RBP: c94c3a64 R08: R09:
<4> [198.669834] R10: R11: R12:
88826f9b5980
<4> [198.669841] R13: 0cc0 R14: c94c3dc0 R15:
888253610068
<4> [198.669849] FS: 7f63e663fe40() GS:888276c0()
knlGS:
<4> [198.669857] CS: 0010 DS: ES: CR0: 80050033
<4> [198.669864] CR2: 7f171f8e39a8 CR3: 00026b1f6005 CR4:
003606f0
<4> [198.669872] Call Trace:
<4> [198.669924] intel_timeline_get_seqno+0x12/0x40 [i915]
<4> [198.669977] __i915_request_create+0x76/0x5a0 [i915]
<4> [198.670024] i915_request_create+0x86/0x1c0 [i915]
<4> [198.670068] i915_gem_do_execbuffer+0xbf2/0x2500 [i915]
<4> [198.670082] ? __lock_acquire+0x460/0x15d0
<4> [198.670128] i915_gem_execbuffer2_ioctl+0x11f/0x470 [i915]
<4> [198.670171] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
<4> [198.670181] drm_ioctl_kernel+0xa7/0xf0
<4> [198.670188] drm_ioctl+0x2e1/0x390
<4> [198.670233] ? i915_gem_execbuffer_ioctl+0x300/0x300 [i915]
Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context
pin/unpin")
References: ac0e331a628b ("drm/i915: Tighten atomicity of i915_active_acquire vs
i915_active_release")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 46 ++---
drivers/gpu/drm/i915/i915_active.h | 6
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 23137b2a8689..57e8a051ddc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -67,21 +67,18 @@ static int intel_context_active_acquire(struct
intel_context *ce)
{
int err;
- err = i915_active_acquire(&ce->active);
- if (err)
- return err;
+ __i915_active_acquire(&ce->active);
+
+ if (intel_context_is_barrier(ce))
+ return 0;
/* Preallocate tracking nodes */
- if (!intel_context_is_barrier(ce)) {
- err = i915_active_acquire_preallocate_barrier(&ce->active,
- ce->engine);
- if (err) {
- i915_active_release(&ce->active);
- return err;
- }
- }
+ err = i915_active_acquire_preallocate_barrier(&ce->active,
+ ce->engine);
+ if (err)
+ i915_active_release(&ce->active);
- return 0;
+ return err;
}
static void intel_context_active_release(struct intel_context *ce)
@@ -101,13 +98,19 @@ int __intel_context_do_pin(struct intel_context *ce)
return err;
}
- if (mutex_lock_interruptible(&ce->pin_mutex))
- return -EINTR;
+ err = i915_active_acquire(&ce->active);
+ if (err)
+ return err;
+
+ if (mutex_lock_interruptible(&ce->pin_mutex)) {
+ err = -EINTR;
+ goto out_release;
+ }
- if (likely(!atomic_read(&ce->pin_count))) {
+ if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
err = intel_context_active_acquire(ce);
if (unlikely(err))
- goto err;
+ goto out_unlock;
err = ce->ops->pin(ce);
if (unlikely(err))
@@ -117,18 +120,19 @@ int __intel_context_do_pin(struct intel_context *ce)
ce->ring->head, ce->ring->tail);
smp_mb__before_atomic(); /* flush p
Re: [Intel-gfx] [PATCH 17/17] drm/i915: Store active_pipes bitmask in cdclk state
On Mon, Jan 20, 2020 at 07:47:28PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's add a copy of the active_pipes bitmask into the cdclk_state.
> While this is duplicating a bit of information we may already
> have elsewhere, I think it's worth it to decopule the cdclk stuff
> from whatever else wants to use that bitmask. Also we want to get
> rid of all the old ad-hoc global state which is what the current
> bitmask is, so this removes one obstacle.
>
> The one extra thing we have to remember is write locking the cdclk
> state whenever the bitmask changes.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 20 +++-
> drivers/gpu/drm/i915/display/intel_cdclk.h | 3 +++
> drivers/gpu/drm/i915/display/intel_display.c | 8 +---
> 3 files changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index e14bda2bec71..f8e4510f4bd9 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2125,7 +2125,7 @@ static int vlv_modeset_calc_cdclk(struct
> intel_cdclk_state *cdclk_state)
> cdclk_state->logical.voltage_level =
> vlv_calc_voltage_level(dev_priv, cdclk);
>
> - if (!state->active_pipes) {
> + if (!cdclk_state->active_pipes) {
> cdclk = vlv_calc_cdclk(dev_priv, cdclk_state->force_min_cdclk);
>
> cdclk_state->actual.cdclk = cdclk;
> @@ -2140,7 +2140,6 @@ static int vlv_modeset_calc_cdclk(struct
> intel_cdclk_state *cdclk_state)
>
> static int bdw_modeset_calc_cdclk(struct intel_cdclk_state *cdclk_state)
> {
> - struct intel_atomic_state *state = cdclk_state->base.state;
> int min_cdclk, cdclk;
>
> min_cdclk = intel_compute_min_cdclk(cdclk_state);
> @@ -2157,7 +2156,7 @@ static int bdw_modeset_calc_cdclk(struct
> intel_cdclk_state *cdclk_state)
> cdclk_state->logical.voltage_level =
> bdw_calc_voltage_level(cdclk);
>
> - if (!state->active_pipes) {
> + if (!cdclk_state->active_pipes) {
> cdclk = bdw_calc_cdclk(cdclk_state->force_min_cdclk);
>
> cdclk_state->actual.cdclk = cdclk;
> @@ -2209,7 +2208,6 @@ static int skl_dpll0_vco(struct intel_cdclk_state
> *cdclk_state)
>
> static int skl_modeset_calc_cdclk(struct intel_cdclk_state *cdclk_state)
> {
> - struct intel_atomic_state *state = cdclk_state->base.state;
> int min_cdclk, cdclk, vco;
>
> min_cdclk = intel_compute_min_cdclk(cdclk_state);
> @@ -2229,7 +2227,7 @@ static int skl_modeset_calc_cdclk(struct
> intel_cdclk_state *cdclk_state)
> cdclk_state->logical.voltage_level =
> skl_calc_voltage_level(cdclk);
>
> - if (!state->active_pipes) {
> + if (!cdclk_state->active_pipes) {
> cdclk = skl_calc_cdclk(cdclk_state->force_min_cdclk, vco);
>
> cdclk_state->actual.vco = vco;
> @@ -2266,7 +2264,7 @@ static int bxt_modeset_calc_cdclk(struct
> intel_cdclk_state *cdclk_state)
> max_t(int, min_voltage_level,
> dev_priv->display.calc_voltage_level(cdclk));
>
> - if (!state->active_pipes) {
> + if (!cdclk_state->active_pipes) {
> cdclk = bxt_calc_cdclk(dev_priv, cdclk_state->force_min_cdclk);
> vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk);
>
> @@ -2402,6 +2400,9 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
> *state)
>
> old_cdclk_state = intel_atomic_get_old_cdclk_state(state);
>
> + new_cdclk_state->active_pipes =
> + intel_calc_active_pipes(state, old_cdclk_state->active_pipes);
> +
> ret = dev_priv->display.modeset_calc_cdclk(new_cdclk_state);
> if (ret)
> return ret;
> @@ -2415,7 +2416,8 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
> *state)
> ret =
> intel_atomic_serialize_global_state(&new_cdclk_state->base);
> if (ret)
> return ret;
> - } else if (intel_cdclk_changed(&old_cdclk_state->logical,
> + } else if (old_cdclk_state->active_pipes !=
> new_cdclk_state->active_pipes ||
> +intel_cdclk_changed(&old_cdclk_state->logical,
> &new_cdclk_state->logical)) {
> ret = intel_atomic_lock_global_state(&new_cdclk_state->base);
> if (ret)
> @@ -2424,14 +2426,14 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> return 0;
> }
>
> - if (is_power_of_2(state->active_pipes) &&
> + if (is_power_of_2(new_cdclk_state->active_pipes) &&
> intel_cdclk_can_cd2x_update(dev_priv,
> &old_cdclk_state->actual,
> &new_cdclk_state->actual)) {
> struct intel_crtc *crtc;
>
Re: [Intel-gfx] [PATCH] drm/i915: Add missing HDMI audio pixel clocks for gen12
Hi,
On Mon, 27 Jan 2020, Ville Syrjälä wrote:
> On Mon, Jan 27, 2020 at 01:39:09PM +0200, Kai Vehmanen wrote:
> > 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.
[...]
> > for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
> > + if (INTEL_GEN(dev_priv) < 12 &&
> > + hdmi_audio_clock[i].clock > 148500) {
>
> Might be cleaner to do the check after the loop.
hmm, you are right. I'll wait for the CI results to come in and if nothing
else found, I'll post V2 with the check moved outside the loop.
Thanks for the review Ville!
Br, Kai
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 16/17] drm/i915: Convert cdclk to global state
On Mon, Jan 27, 2020 at 07:03:01PM +0200, Imre Deak wrote:
> On Tue, Jan 21, 2020 at 04:03:53PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's convert cdclk_state to be a proper global state. That allows
> > us to use the regular atomic old vs. new state accessor, hopefully
> > making the code less confusing.
> >
> > We do have to deal with a few more error cases in case the cdclk
> > state duplication fails. But so be it.
> >
> > v2: Fix new plane min_cdclk vs. old crtc min_cdclk check
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic.c | 1 -
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 68 ---
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 5 +-
> > drivers/gpu/drm/i915/display/intel_audio.c| 39 +++-
> > drivers/gpu/drm/i915/display/intel_cdclk.c| 192 ++
> > drivers/gpu/drm/i915/display/intel_cdclk.h| 45 +++-
> > drivers/gpu/drm/i915/display/intel_display.c | 122 +++
> > .../drm/i915/display/intel_display_types.h| 3 -
> > drivers/gpu/drm/i915/i915_drv.h | 45 +---
> > 9 files changed, 316 insertions(+), 204 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 45842ebcdebd..b51ddf9a250f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -518,7 +518,6 @@ void intel_atomic_state_clear(struct drm_atomic_state
> > *s)
> > state->dpll_set = state->modeset = false;
> > state->global_state_changed = false;
> > state->active_pipes = 0;
> > - intel_cdclk_clear_state(state);
> > }
> >
> > struct intel_crtc_state *
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 563caec1d201..230d0e4f6169 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -37,6 +37,7 @@
> >
> > #include "i915_trace.h"
> > #include "intel_atomic_plane.h"
> > +#include "intel_cdclk.h"
> > #include "intel_display_types.h"
> > #include "intel_pm.h"
> > #include "intel_sprite.h"
> > @@ -155,44 +156,61 @@ unsigned int intel_plane_data_rate(const struct
> > intel_crtc_state *crtc_state,
> > return cpp * crtc_state->pixel_rate;
> > }
> >
> > -bool intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> > - struct intel_plane *plane)
> > +int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> > + struct intel_plane *plane,
> > + bool *need_cdclk_calc)
> > {
> > - struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > - const struct intel_cdclk_state *cdclk_state =
> > - &dev_priv->cdclk_state;
> > const struct intel_plane_state *plane_state =
> > intel_atomic_get_new_plane_state(state, plane);
> > struct intel_crtc *crtc = to_intel_crtc(plane_state->hw.crtc);
> > - struct intel_crtc_state *crtc_state;
> > + const struct intel_cdclk_state *cdclk_state;
> > + struct intel_crtc_state *new_crtc_state =
> > + intel_atomic_get_new_crtc_state(state, crtc);
> > + const struct intel_crtc_state *old_crtc_state =
> > + intel_atomic_get_old_crtc_state(state, crtc);
> >
> > if (!plane_state->uapi.visible || !plane->min_cdclk)
> > - return false;
> > + return 0;
> > +
> > + new_crtc_state->min_cdclk[plane->id] =
> > + plane->min_cdclk(new_crtc_state, plane_state);
> >
> > - crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
> > + /*
> > +* No need to check against the cdclk state if
> > +* the min cdclk for the plane doesn't increase.
> > +*
> > +* Ie. we only ever increase the cdclk due to plane
> > +* requirements. This can reduce back and forth
> > +* display blinking due to constant cdclk changes.
> > +*/
> > + if (new_crtc_state->min_cdclk[plane->id] <=
> > + old_crtc_state->min_cdclk[plane->id])
> > + return 0;
> >
> > - crtc_state->min_cdclk[plane->id] =
> > - plane->min_cdclk(crtc_state, plane_state);
> > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > + if (IS_ERR(cdclk_state))
> > + return PTR_ERR(cdclk_state);
> >
> > /*
> > -* Does the cdclk need to be bumbed up?
> > +* No need to recalculate the cdclk state if
> > +* the min cdclk for the pipe doesn't increase.
> > *
> > -* Note: we obviously need to be called before the new
> > -* cdclk frequency is calculated so state->cdclk.logical
> > -* hasn't been populated yet. Hence we look at the old
> > -* cdclk state under dev_priv->cdclk.logical. This is
> > -* safe as long we hold at least one crtc mutex (which
> > -* must be true since we have crtc_state).
> >
Re: [Intel-gfx] [PATCH v2 16/17] drm/i915: Convert cdclk to global state
On Tue, Jan 21, 2020 at 04:03:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's convert cdclk_state to be a proper global state. That allows
> us to use the regular atomic old vs. new state accessor, hopefully
> making the code less confusing.
>
> We do have to deal with a few more error cases in case the cdclk
> state duplication fails. But so be it.
>
> v2: Fix new plane min_cdclk vs. old crtc min_cdclk check
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 1 -
> .../gpu/drm/i915/display/intel_atomic_plane.c | 68 ---
> .../gpu/drm/i915/display/intel_atomic_plane.h | 5 +-
> drivers/gpu/drm/i915/display/intel_audio.c| 39 +++-
> drivers/gpu/drm/i915/display/intel_cdclk.c| 192 ++
> drivers/gpu/drm/i915/display/intel_cdclk.h| 45 +++-
> drivers/gpu/drm/i915/display/intel_display.c | 122 +++
> .../drm/i915/display/intel_display_types.h| 3 -
> drivers/gpu/drm/i915/i915_drv.h | 45 +---
> 9 files changed, 316 insertions(+), 204 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 45842ebcdebd..b51ddf9a250f 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -518,7 +518,6 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
> state->dpll_set = state->modeset = false;
> state->global_state_changed = false;
> state->active_pipes = 0;
> - intel_cdclk_clear_state(state);
> }
>
> struct intel_crtc_state *
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 563caec1d201..230d0e4f6169 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -37,6 +37,7 @@
>
> #include "i915_trace.h"
> #include "intel_atomic_plane.h"
> +#include "intel_cdclk.h"
> #include "intel_display_types.h"
> #include "intel_pm.h"
> #include "intel_sprite.h"
> @@ -155,44 +156,61 @@ unsigned int intel_plane_data_rate(const struct
> intel_crtc_state *crtc_state,
> return cpp * crtc_state->pixel_rate;
> }
>
> -bool intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> - struct intel_plane *plane)
> +int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> +struct intel_plane *plane,
> +bool *need_cdclk_calc)
> {
> - struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - const struct intel_cdclk_state *cdclk_state =
> - &dev_priv->cdclk_state;
> const struct intel_plane_state *plane_state =
> intel_atomic_get_new_plane_state(state, plane);
> struct intel_crtc *crtc = to_intel_crtc(plane_state->hw.crtc);
> - struct intel_crtc_state *crtc_state;
> + const struct intel_cdclk_state *cdclk_state;
> + struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
>
> if (!plane_state->uapi.visible || !plane->min_cdclk)
> - return false;
> + return 0;
> +
> + new_crtc_state->min_cdclk[plane->id] =
> + plane->min_cdclk(new_crtc_state, plane_state);
>
> - crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
> + /*
> + * No need to check against the cdclk state if
> + * the min cdclk for the plane doesn't increase.
> + *
> + * Ie. we only ever increase the cdclk due to plane
> + * requirements. This can reduce back and forth
> + * display blinking due to constant cdclk changes.
> + */
> + if (new_crtc_state->min_cdclk[plane->id] <=
> + old_crtc_state->min_cdclk[plane->id])
> + return 0;
>
> - crtc_state->min_cdclk[plane->id] =
> - plane->min_cdclk(crtc_state, plane_state);
> + cdclk_state = intel_atomic_get_cdclk_state(state);
> + if (IS_ERR(cdclk_state))
> + return PTR_ERR(cdclk_state);
>
> /*
> - * Does the cdclk need to be bumbed up?
> + * No need to recalculate the cdclk state if
> + * the min cdclk for the pipe doesn't increase.
>*
> - * Note: we obviously need to be called before the new
> - * cdclk frequency is calculated so state->cdclk.logical
> - * hasn't been populated yet. Hence we look at the old
> - * cdclk state under dev_priv->cdclk.logical. This is
> - * safe as long we hold at least one crtc mutex (which
> - * must be true since we have crtc_state).
> + * Ie. we only ever increase the cdclk due to plane
> + * requirements. This can reduce back and forth
> + * display blinking due to constant cdclk changes.
>*/
Re: [Intel-gfx] [PATCH v2 16/17] drm/i915: Convert cdclk to global state
On Mon, Jan 27, 2020 at 07:15:06PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 27, 2020 at 07:03:01PM +0200, Imre Deak wrote:
> > On Tue, Jan 21, 2020 at 04:03:53PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Let's convert cdclk_state to be a proper global state. That allows
> > > us to use the regular atomic old vs. new state accessor, hopefully
> > > making the code less confusing.
> > >
> > > We do have to deal with a few more error cases in case the cdclk
> > > state duplication fails. But so be it.
> > >
> > > v2: Fix new plane min_cdclk vs. old crtc min_cdclk check
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_atomic.c | 1 -
> > > .../gpu/drm/i915/display/intel_atomic_plane.c | 68 ---
> > > .../gpu/drm/i915/display/intel_atomic_plane.h | 5 +-
> > > drivers/gpu/drm/i915/display/intel_audio.c| 39 +++-
> > > drivers/gpu/drm/i915/display/intel_cdclk.c| 192 ++
> > > drivers/gpu/drm/i915/display/intel_cdclk.h| 45 +++-
> > > drivers/gpu/drm/i915/display/intel_display.c | 122 +++
> > > .../drm/i915/display/intel_display_types.h| 3 -
> > > drivers/gpu/drm/i915/i915_drv.h | 45 +---
> > > 9 files changed, 316 insertions(+), 204 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > index 45842ebcdebd..b51ddf9a250f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > @@ -518,7 +518,6 @@ void intel_atomic_state_clear(struct drm_atomic_state
> > > *s)
> > > state->dpll_set = state->modeset = false;
> > > state->global_state_changed = false;
> > > state->active_pipes = 0;
> > > - intel_cdclk_clear_state(state);
> > > }
> > >
> > > struct intel_crtc_state *
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > index 563caec1d201..230d0e4f6169 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > @@ -37,6 +37,7 @@
> > >
> > > #include "i915_trace.h"
> > > #include "intel_atomic_plane.h"
> > > +#include "intel_cdclk.h"
> > > #include "intel_display_types.h"
> > > #include "intel_pm.h"
> > > #include "intel_sprite.h"
> > > @@ -155,44 +156,61 @@ unsigned int intel_plane_data_rate(const struct
> > > intel_crtc_state *crtc_state,
> > > return cpp * crtc_state->pixel_rate;
> > > }
> > >
> > > -bool intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> > > - struct intel_plane *plane)
> > > +int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> > > +struct intel_plane *plane,
> > > +bool *need_cdclk_calc)
> > > {
> > > - struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > > - const struct intel_cdclk_state *cdclk_state =
> > > - &dev_priv->cdclk_state;
> > > const struct intel_plane_state *plane_state =
> > > intel_atomic_get_new_plane_state(state, plane);
> > > struct intel_crtc *crtc = to_intel_crtc(plane_state->hw.crtc);
> > > - struct intel_crtc_state *crtc_state;
> > > + const struct intel_cdclk_state *cdclk_state;
> > > + struct intel_crtc_state *new_crtc_state =
> > > + intel_atomic_get_new_crtc_state(state, crtc);
> > > + const struct intel_crtc_state *old_crtc_state =
> > > + intel_atomic_get_old_crtc_state(state, crtc);
> > >
> > > if (!plane_state->uapi.visible || !plane->min_cdclk)
> > > - return false;
> > > + return 0;
> > > +
> > > + new_crtc_state->min_cdclk[plane->id] =
> > > + plane->min_cdclk(new_crtc_state, plane_state);
> > >
> > > - crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
> > > + /*
> > > + * No need to check against the cdclk state if
> > > + * the min cdclk for the plane doesn't increase.
> > > + *
> > > + * Ie. we only ever increase the cdclk due to plane
> > > + * requirements. This can reduce back and forth
> > > + * display blinking due to constant cdclk changes.
> > > + */
> > > + if (new_crtc_state->min_cdclk[plane->id] <=
> > > + old_crtc_state->min_cdclk[plane->id])
> > > + return 0;
> > >
> > > - crtc_state->min_cdclk[plane->id] =
> > > - plane->min_cdclk(crtc_state, plane_state);
> > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > > + if (IS_ERR(cdclk_state))
> > > + return PTR_ERR(cdclk_state);
> > >
> > > /*
> > > - * Does the cdclk need to be bumbed up?
> > > + * No need to recalculate the cdclk state if
> > > + * the min cdclk for the pipe doesn't increase.
> > >*
> > > - * Note: we obviously need to be called before the new
> > > - * cdclk frequency is calculated so state->cdclk.logical
> > > - * hasn't been populated yet. Hence we look at the
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: Fix OA context id overlap with idle context id (rev2)
== Series Details == Series: drm/i915/perf: Fix OA context id overlap with idle context id (rev2) URL : https://patchwork.freedesktop.org/series/72505/ State : success == Summary == CI Bug Log - changes from CI_DRM_7814_full -> Patchwork_16269_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16269_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@vcs1-mixed-process: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-iclb2/igt@gem_ctx_persiste...@vcs1-mixed-process.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-iclb7/igt@gem_ctx_persiste...@vcs1-mixed-process.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112146]) +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-iclb5/igt@gem_exec_sched...@in-order-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_fence_thrash@bo-write-verify-threaded-y: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([CI#80] / [fdo#103927]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-apl8/igt@gem_fence_thr...@bo-write-verify-threaded-y.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-apl8/igt@gem_fence_thr...@bo-write-verify-threaded-y.html * igt@gem_userptr_blits@sync-unmap-after-close: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([fdo#111870] / [i915#836]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-skl10/igt@gem_userptr_bl...@sync-unmap-after-close.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-skl10/igt@gem_userptr_bl...@sync-unmap-after-close.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][11] -> [INCOMPLETE][12] ([i915#58] / [k.org#198133]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-glk3/igt@gen9_exec_pa...@allowed-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-glk5/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_rps@min-max-config-loaded: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#39]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-skl1/igt@i915_pm_...@min-max-config-loaded.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-skl1/igt@i915_pm_...@min-max-config-loaded.html * igt@i915_selftest@live_blt: - shard-hsw: [PASS][15] -> [DMESG-FAIL][16] ([i915#725]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-hsw5/igt@i915_selftest@live_blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-hsw7/igt@i915_selftest@live_blt.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#300]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-glk: [PASS][23] -> [FAIL][24] ([IGT#5] / [i915#697]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7814/shard-glk1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16269/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms
[Intel-gfx] [PATCH v2] drm/hdcp: optimizing the srm handling
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
Signed-off-by: Ramalingam C
Suggested-by: Sean Paul
---
drivers/gpu/drm/drm_hdcp.c | 144 -
drivers/gpu/drm/drm_internal.h | 4 -
drivers/gpu/drm/drm_sysfs.c| 2 -
include/drm/drm_hdcp.h | 4 +-
4 files changed, 55 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 9191633a3c43..30749a13108e 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -23,14 +23,6 @@
#include "drm_internal.h"
-static struct hdcp_srm {
- u32 revoked_ksv_cnt;
- u8 *revoked_ksv_list;
-
- /* Mutex to protect above struct member */
- struct mutex mutex;
-} *srm_data;
-
static inline void drm_hdcp_print_ksv(const u8 *ksv)
{
DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
@@ -91,7 +83,8 @@ static inline u32 get_vrl_length(const u8 *buf)
return drm_hdcp_be24_to_cpu(buf);
}
-static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count)
+static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count,
+ u8 *revoked_ksv_list, u32 *revoked_ksv_cnt)
{
struct hdcp_srm_header *header;
u32 vrl_length, ksv_count;
@@ -131,29 +124,28 @@ static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t
count)
ksv_count = drm_hdcp_get_revoked_ksv_count(buf, vrl_length);
if (!ksv_count) {
DRM_DEBUG("Revoked KSV count is 0\n");
- return count;
+ return 0;
}
- kfree(srm_data->revoked_ksv_list);
- srm_data->revoked_ksv_list = kcalloc(ksv_count, DRM_HDCP_KSV_LEN,
-GFP_KERNEL);
- if (!srm_data->revoked_ksv_list) {
+ revoked_ksv_list = kcalloc(ksv_count, DRM_HDCP_KSV_LEN, GFP_KERNEL);
+ if (!revoked_ksv_list) {
DRM_ERROR("Out of Memory\n");
return -ENOMEM;
}
- if (drm_hdcp_get_revoked_ksvs(buf, srm_data->revoked_ksv_list,
+ if (drm_hdcp_get_revoked_ksvs(buf, revoked_ksv_list,
vrl_length) != ksv_count) {
- srm_data->revoked_ksv_cnt = 0;
- kfree(srm_data->revoked_ksv_list);
+ *revoked_ksv_cnt = 0;
+ kfree(revoked_ksv_list);
return -EINVAL;
}
- srm_data->revoked_ksv_cnt = ksv_count;
- return count;
+ *revoked_ksv_cnt = ksv_count;
+ return 0;
}
-static int drm_hdcp_parse_hdcp2_srm(const u8 *buf, size_t count)
+static int drm_hdcp_parse_hdcp2_srm(const u8 *buf, size_t count,
+ u8 *revoked_ksv_list, u32 *revoked_ksv_cnt)
{
struct hdcp_srm_header *header;
u32 vrl_length, ksv_count, ksv_sz;
@@ -195,13 +187,11 @@ static int drm_hdcp_parse_hdcp2_srm(const u8 *buf, size_t
count)
ksv_count = (*buf << 2) | DRM_HDCP_2_KSV_COUNT_2_LSBITS(*(buf + 1));
if (!ksv_count) {
DRM_DEBUG("Revoked KSV count is 0\n");
- return count;
+ return 0;
}
- kfree(srm_data->revoked_ksv_list);
- srm_data->revoked_ksv_list = kcalloc(ksv_count, DRM_HDCP_KSV_LEN,
-GFP_KERNEL);
- if (!srm_data->revoked_ksv_list) {
+ revoked_ksv_list = kcalloc(ksv_count, DRM_HDCP_KSV_LEN, GFP_KERNEL);
+ if (!revoked_ksv_list) {
DRM_ERROR("Out of Memory\n");
return -ENOMEM;
}
@@ -210,10 +200,10 @@ static int drm_hdcp_parse_hdcp2_srm(const u8 *buf, size_t
count)
buf += DRM_HDCP_2_NO_OF_DEV_PLUS_RESERVED_SZ;
DRM_DEBUG("Revoked KSVs: %d\n", ksv_count);
- memcpy(srm_data->revoked_ksv_list, buf, ksv_sz);
+ memcpy(revoked_ksv_list, buf, ksv_sz);
- srm_data->revoked_ksv_cnt = ksv_count;
- return count;
+ *revoked_ksv_cnt = ksv_count;
+ return 0;
}
static inline bool is_srm_version_hdcp1(const u8 *buf)
@@ -226,18 +216,22 @@ static inline bool is_srm_version_hdcp2(const u8 *buf)
return *buf == (u8)(DRM_HDCP_2_SRM_ID << 4 | DRM_HDCP_2_INDICATOR);
}
-static void drm_hdcp_srm_update(const u8 *buf, size_t count)
+static void drm_hdcp_srm_update(const u8 *buf, size_t count,
+ u8 *revoked_ksv_list, u32 *revoked_ksv_cnt)
{
if (count < sizeof(struct hdcp_srm_header))
return;
if (is_srm_version_hdcp1(buf))
- drm_hdcp_parse_hdcp1_srm(buf, count);
+ drm_hdcp_parse_hdcp1_srm(buf, count, revoked_ksv_list,
+revoked_ksv_cnt);
else if (is_srm_version_hdcp2(buf))
- drm_hd
[Intel-gfx] [PATCH i-g-t v2 1/2] i915/gem_ctx_isolation: use the gem_engine_topology library, part 1
From: Ramalingam C
Call function gem_class_can_store_dword instead of legacy function
gem_can_store_dword. This requires that e->class be available in the
calling function.
Instead of passing "engine" (== "e->flags") to functions, pass "e".
This makes e->class available where it is needed.
This commit is being kept separate from "part 2" in order to ensure
proper attribution to the author. The code associated with this
commit was written by Ramalingam C .
Since then, slight modifications have been done due to upstream
changes.
Signed-off-by: Ramalingam C .
X-Original-Author: Ramalingam C
Signed-off-by: Dale B Stimson
---
tests/i915/gem_ctx_isolation.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 8b72a16ad..c45617456 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -575,7 +575,6 @@ static void nonpriv(int fd,
0x0505c0c0,
0xdeadbeef
};
- unsigned int engine = e->flags;
unsigned int num_values = ARRAY_SIZE(values);
/* Sigh -- hsw: we need cmdparser access to our own registers! */
@@ -593,7 +592,7 @@ static void nonpriv(int fd,
tmpl_regs(fd, ctx, e, tmpl, values[v]);
- spin = igt_spin_new(fd, .ctx = ctx, .engine = engine);
+ spin = igt_spin_new(fd, .ctx = ctx, .engine = e->flags);
igt_debug("%s[%d]: Setting all registers to 0x%08x\n",
__func__, v, values[v]);
@@ -606,12 +605,12 @@ static void nonpriv(int fd,
/* Explicit sync to keep the switch between write/read
*/
syncpt = igt_spin_new(fd,
.ctx = ctx,
- .engine = engine,
+ .engine = e->flags,
.flags = IGT_SPIN_FENCE_OUT);
dirt = igt_spin_new(fd,
.ctx = sw,
- .engine = engine,
+ .engine = e->flags,
.fence = syncpt->out_fence,
.flags = (IGT_SPIN_FENCE_IN |
IGT_SPIN_FENCE_OUT));
@@ -619,7 +618,7 @@ static void nonpriv(int fd,
syncpt = igt_spin_new(fd,
.ctx = ctx,
- .engine = engine,
+ .engine = e->flags,
.fence = dirt->out_fence,
.flags = IGT_SPIN_FENCE_IN);
igt_spin_free(fd, dirt);
@@ -660,7 +659,6 @@ static void isolation(int fd,
0x,
0xdeadbeef
};
- unsigned int engine = e->flags;
unsigned int num_values =
flags & (DIRTY1 | DIRTY2) ? ARRAY_SIZE(values) : 1;
@@ -673,7 +671,7 @@ static void isolation(int fd,
ctx[0] = gem_context_create(fd);
regs[0] = read_regs(fd, ctx[0], e, flags);
- spin = igt_spin_new(fd, .ctx = ctx[0], .engine = engine);
+ spin = igt_spin_new(fd, .ctx = ctx[0], .engine = e->flags);
if (flags & DIRTY1) {
igt_debug("%s[%d]: Setting all registers of ctx 0 to
0x%08x\n",
@@ -726,11 +724,11 @@ static void isolation(int fd,
#define S4 (4 << 8)
#define SLEEP_MASK (0xf << 8)
-static void inject_reset_context(int fd, unsigned int engine)
+static void inject_reset_context(int fd, const struct intel_execution_engine2
*e)
{
struct igt_spin_factory opts = {
.ctx = gem_context_create(fd),
- .engine = engine,
+ .engine = e->flags,
.flags = IGT_SPIN_FAST,
};
igt_spin_t *spin;
@@ -741,7 +739,7 @@ static void inject_reset_context(int fd, unsigned int
engine)
* HW for screwing up if the context was already broken.
*/
- if (gem_can_store_dword(fd, engine))
+ if (gem_class_can_store_dword(fd, e->class))
opts.flags |= IGT_SPIN_POLL_RUN;
spin = __igt_spin_factory(fd, &opts);
@@ -771,7 +769,6 @@ static void preservation(int fd,
0xdeadbeef
};
const unsigned int num_values = ARRAY_SIZE(values);
- unsigned int engine = e->flags;
uint32_t ctx[num_values +1 ];
uint32_t regs[num_values + 1][2];
igt_spin_t *spin;
@@ -779,7 +776,7 @@ static void preservation(int fd,
gem_quiescent_gpu(fd);
ctx[num_values] = gem_context_create(fd);
- spin = igt_spin_new(fd, .ctx
[Intel-gfx] [PATCH i-g-t v2 0/2] i915/gem_ctx_isolation: __for_each_physical_engine + engine mapping
i915/gem_ctx_isolation: __for_each_physical_engine and gem_engine_topology V2: Use new function gem_context_clone_with_engines Use __for_each_physical_engine with gem_engine_topology. Iterates through the definitive list of all engines present. Patch 1 was originally posted by Ramalingam C . Since then, slight modifications have been done to it due to upstream changes. Patch 1 is being kept separate from patch 2 in order to assure proper attribution to the author. Dale B Stimson (1): i915/gem_ctx_isolation: use the gem_engine_topology library, part 2 Ramalingam C (1): i915/gem_ctx_isolation: use the gem_engine_topology library, part 1 tests/i915/gem_ctx_isolation.c | 44 +- 1 file changed, 22 insertions(+), 22 deletions(-) -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/8] drm/i915/display: mass conversion to intel_de_*() register accessors
Rebase of the patches from [1] that failed to apply. BR, Jani. [1] https://patchwork.freedesktop.org/series/72533/ Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Joonas Lahtinen Jani Nikula (8): drm/i915/icl_dsi: use intel_de_*() functions for register access drm/i915/combo_phy: use intel_de_*() functions for register access drm/i915/ddi: use intel_de_*() functions for register access drm/i915/display: use intel_de_*() functions for register access drm/i915/display_power: use intel_de_*() functions for register access drm/i915/dp: use intel_de_*() functions for register access drm/i915/hdcp: use intel_de_*() functions for register access drm/i915/psr: use intel_de_*() functions for register access drivers/gpu/drm/i915/display/icl_dsi.c| 271 ++-- .../gpu/drm/i915/display/intel_combo_phy.c| 66 +- drivers/gpu/drm/i915/display/intel_ddi.c | 464 +++ drivers/gpu/drm/i915/display/intel_display.c | 1171 + .../drm/i915/display/intel_display_power.c| 292 ++-- drivers/gpu/drm/i915/display/intel_dp.c | 234 ++-- drivers/gpu/drm/i915/display/intel_hdcp.c | 142 +- drivers/gpu/drm/i915/display/intel_psr.c |4 +- 8 files changed, 1397 insertions(+), 1247 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/8] drm/i915/ddi: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson
Acked-by: Rodrigo Vivi
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 464 ---
1 file changed, 240 insertions(+), 224 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b1100950dd0d..c96f629cddc3 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -846,7 +846,7 @@ bxt_get_buf_trans_hdmi(struct drm_i915_private *dev_priv,
int *n_entries)
static const struct cnl_ddi_buf_trans *
cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv, int *n_entries)
{
- u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+ u32 voltage = intel_de_read(dev_priv, CNL_PORT_COMP_DW3) &
VOLTAGE_INFO_MASK;
if (voltage == VOLTAGE_INFO_0_85V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_85V);
@@ -867,7 +867,7 @@ cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv,
int *n_entries)
static const struct cnl_ddi_buf_trans *
cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
{
- u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+ u32 voltage = intel_de_read(dev_priv, CNL_PORT_COMP_DW3) &
VOLTAGE_INFO_MASK;
if (voltage == VOLTAGE_INFO_0_85V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_85V);
@@ -888,7 +888,7 @@ cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int
*n_entries)
static const struct cnl_ddi_buf_trans *
cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
{
- u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+ u32 voltage = intel_de_read(dev_priv, CNL_PORT_COMP_DW3) &
VOLTAGE_INFO_MASK;
if (dev_priv->vbt.edp.low_vswing) {
if (voltage == VOLTAGE_INFO_0_85V) {
@@ -1026,10 +1026,10 @@ static void intel_prepare_dp_ddi_buffers(struct
intel_encoder *encoder,
iboost_bit = DDI_BUF_BALANCE_LEG_ENABLE;
for (i = 0; i < n_entries; i++) {
- I915_WRITE(DDI_BUF_TRANS_LO(port, i),
- ddi_translations[i].trans1 | iboost_bit);
- I915_WRITE(DDI_BUF_TRANS_HI(port, i),
- ddi_translations[i].trans2);
+ intel_de_write(dev_priv, DDI_BUF_TRANS_LO(port, i),
+ ddi_translations[i].trans1 | iboost_bit);
+ intel_de_write(dev_priv, DDI_BUF_TRANS_HI(port, i),
+ ddi_translations[i].trans2);
}
}
@@ -1059,10 +1059,10 @@ static void intel_prepare_hdmi_ddi_buffers(struct
intel_encoder *encoder,
iboost_bit = DDI_BUF_BALANCE_LEG_ENABLE;
/* Entry 9 is for HDMI: */
- I915_WRITE(DDI_BUF_TRANS_LO(port, 9),
- ddi_translations[level].trans1 | iboost_bit);
- I915_WRITE(DDI_BUF_TRANS_HI(port, 9),
- ddi_translations[level].trans2);
+ intel_de_write(dev_priv, DDI_BUF_TRANS_LO(port, 9),
+ ddi_translations[level].trans1 | iboost_bit);
+ intel_de_write(dev_priv, DDI_BUF_TRANS_HI(port, 9),
+ ddi_translations[level].trans2);
}
static void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
@@ -1073,7 +1073,7 @@ static void intel_wait_ddi_buf_idle(struct
drm_i915_private *dev_priv,
for (i = 0; i < 16; i++) {
udelay(1);
- if (I915_READ(reg) & DDI_BUF_IS_IDLE)
+ if (intel_de_read(dev_priv, reg) & DDI_BUF_IS_IDLE)
return;
}
DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n", port_name(port));
@@ -1164,70 +1164,64 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
*
* WaFDIAutoLinkSetTimingOverrride:hsw
*/
- I915_WRITE(FDI_RX_MISC(PIPE_A), FDI_RX_PWRDN_LANE1_VAL(2) |
- FDI_RX_PWRDN_LANE0_VAL(2) |
- FDI_RX_TP1_TO_TP2_48 | FDI_RX_FDI_DELAY
[Intel-gfx] [PATCH v2 4/8] drm/i915/display: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson
Acked-by: Rodrigo Vivi
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 1171 ++
1 file changed, 622 insertions(+), 549 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7f94d5ca4207..c0e5002ce64c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -519,13 +519,11 @@ static void
skl_wa_827(struct drm_i915_private *dev_priv, enum pipe pipe, bool enable)
{
if (enable)
- I915_WRITE(CLKGATE_DIS_PSL(pipe),
- I915_READ(CLKGATE_DIS_PSL(pipe)) |
- DUPS1_GATING_DIS | DUPS2_GATING_DIS);
+ intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
+ intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
DUPS1_GATING_DIS | DUPS2_GATING_DIS);
else
- I915_WRITE(CLKGATE_DIS_PSL(pipe),
- I915_READ(CLKGATE_DIS_PSL(pipe)) &
- ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
+ intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
+ intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
}
/* Wa_2006604312:icl */
@@ -534,11 +532,11 @@ icl_wa_scalerclkgating(struct drm_i915_private *dev_priv,
enum pipe pipe,
bool enable)
{
if (enable)
- I915_WRITE(CLKGATE_DIS_PSL(pipe),
- I915_READ(CLKGATE_DIS_PSL(pipe)) | DPFR_GATING_DIS);
+ intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
+ intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
DPFR_GATING_DIS);
else
- I915_WRITE(CLKGATE_DIS_PSL(pipe),
- I915_READ(CLKGATE_DIS_PSL(pipe)) & ~DPFR_GATING_DIS);
+ intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
+ intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
~DPFR_GATING_DIS);
}
static bool
@@ -1050,9 +1048,9 @@ static bool pipe_scanline_is_moving(struct
drm_i915_private *dev_priv,
else
line_mask = DSL_LINEMASK_GEN3;
- line1 = I915_READ(reg) & line_mask;
+ line1 = intel_de_read(dev_priv, reg) & line_mask;
msleep(5);
- line2 = I915_READ(reg) & line_mask;
+ line2 = intel_de_read(dev_priv, reg) & line_mask;
return line1 != line2;
}
@@ -1105,7 +1103,7 @@ void assert_pll(struct drm_i915_private *dev_priv,
u32 val;
bool cur_state;
- val = I915_READ(DPLL(pipe));
+ val = intel_de_read(dev_priv, DPLL(pipe));
cur_state = !!(val & DPLL_VCO_ENABLE);
I915_STATE_WARN(cur_state != state,
"PLL state assertion failure (expected %s, current %s)\n",
@@ -1141,10 +1139,11 @@ static void assert_fdi_tx(struct drm_i915_private
*dev_priv,
* so pipe->transcoder cast is fine here.
*/
enum transcoder cpu_transcoder = (enum transcoder)pipe;
- u32 val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
+ u32 val = intel_de_read(dev_priv,
+ TRANS_DDI_FUNC_CTL(cpu_transcoder));
cur_state = !!(val & TRANS_DDI_FUNC_ENABLE);
} else {
- u32 val = I915_READ(FDI_TX_CTL(pipe));
+ u32 val = intel_de_read(dev_priv, FDI_TX_CTL(pipe));
cur_state = !!(val & FDI_TX_ENABLE);
}
I915_STATE_WARN(cur_state != state,
@@ -1160,7 +1159,7 @@ static void assert_fdi_rx(struct drm_i915_private
*dev_priv,
u32 val;
bool cur_state;
- val = I915_READ(FDI_RX_CTL(pipe));
+ val = intel_de_read(dev_priv, FDI_RX_CTL(pipe));
cur_state = !!(val & FDI_RX_ENABLE);
I915_STATE_WARN(cur_state != state,
"FDI RX state assertion failure (expected %s, current %s)\n",
@@ -1182,7 +1181,7 @@ static void as
[Intel-gfx] [PATCH v2 8/8] drm/i915/psr: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson Acked-by: Rodrigo Vivi Acked-by: Joonas Lahtinen Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_psr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index b9dd9763c0f7..e41ed962aa80 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -832,11 +832,11 @@ static void intel_psr_enable_source(struct intel_dp *intel_dp, * TODO: if future platforms supports DC3CO in more than one * transcoder, EXITLINE will need to be unset when disabling PSR */ - val = I915_READ(EXITLINE(cpu_transcoder)); + val = intel_de_read(dev_priv, EXITLINE(cpu_transcoder)); val &= ~EXITLINE_MASK; val |= crtc_state->dc3co_exitline << EXITLINE_SHIFT; val |= EXITLINE_ENABLE; - I915_WRITE(EXITLINE(cpu_transcoder), val); + intel_de_write(dev_priv, EXITLINE(cpu_transcoder), val); } } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/8] drm/i915/dp: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson
Acked-by: Rodrigo Vivi
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 234
1 file changed, 119 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index e21bc339cb29..f4dede6253f8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -267,7 +267,7 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
enum port port = dig_port->base.port;
- u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+ u32 voltage = intel_de_read(dev_priv, CNL_PORT_COMP_DW3) &
VOLTAGE_INFO_MASK;
/* Low voltage SKUs are limited to max of 5.4G */
if (voltage == VOLTAGE_INFO_0_85V)
@@ -756,7 +756,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
enum dpio_channel ch = vlv_pipe_to_channel(pipe);
u32 DP;
- if (WARN(I915_READ(intel_dp->output_reg) & DP_PORT_EN,
+ if (WARN(intel_de_read(dev_priv, intel_dp->output_reg) & DP_PORT_EN,
"skipping pipe %c power sequencer kick due to [ENCODER:%d:%s]
being active\n",
pipe_name(pipe), intel_dig_port->base.base.base.id,
intel_dig_port->base.base.name))
@@ -770,7 +770,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
/* Preserve the BIOS-computed detected bit. This is
* supposed to be read-only.
*/
- DP = I915_READ(intel_dp->output_reg) & DP_DETECTED;
+ DP = intel_de_read(dev_priv, intel_dp->output_reg) & DP_DETECTED;
DP |= DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
DP |= DP_PORT_WIDTH(1);
DP |= DP_LINK_TRAIN_PAT_1;
@@ -780,7 +780,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
else
DP |= DP_PIPE_SEL(pipe);
- pll_enabled = I915_READ(DPLL(pipe)) & DPLL_VCO_ENABLE;
+ pll_enabled = intel_de_read(dev_priv, DPLL(pipe)) & DPLL_VCO_ENABLE;
/*
* The DPLL for the pipe must be enabled for this to work.
@@ -805,14 +805,14 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
* to make this power sequencer lock onto the port.
* Otherwise even VDD force bit won't work.
*/
- I915_WRITE(intel_dp->output_reg, DP);
- POSTING_READ(intel_dp->output_reg);
+ intel_de_write(dev_priv, intel_dp->output_reg, DP);
+ intel_de_posting_read(dev_priv, intel_dp->output_reg);
- I915_WRITE(intel_dp->output_reg, DP | DP_PORT_EN);
- POSTING_READ(intel_dp->output_reg);
+ intel_de_write(dev_priv, intel_dp->output_reg, DP | DP_PORT_EN);
+ intel_de_posting_read(dev_priv, intel_dp->output_reg);
- I915_WRITE(intel_dp->output_reg, DP & ~DP_PORT_EN);
- POSTING_READ(intel_dp->output_reg);
+ intel_de_write(dev_priv, intel_dp->output_reg, DP & ~DP_PORT_EN);
+ intel_de_posting_read(dev_priv, intel_dp->output_reg);
if (!pll_enabled) {
vlv_force_pll_off(dev_priv, pipe);
@@ -934,13 +934,13 @@ typedef bool (*vlv_pipe_check)(struct drm_i915_private
*dev_priv,
static bool vlv_pipe_has_pp_on(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
- return I915_READ(PP_STATUS(pipe)) & PP_ON;
+ return intel_de_read(dev_priv, PP_STATUS(pipe)) & PP_ON;
}
static bool vlv_pipe_has_vdd_on(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
- return I915_READ(PP_CONTROL(pipe)) & EDP_FORCE_VDD;
+ return intel_de_read(dev_priv, PP_CONTROL(pipe)) & EDP_FORCE_VDD;
}
static bool vlv_pipe_any(struct drm_i915_private *dev_priv,
@@ -957,7 +957,7 @@ vlv_initial_pps_pipe(struct drm_i915_private *dev_priv,
enum pipe pipe;
for (pipe = PIPE_A; pipe <= PIPE_B; pipe++) {
- u32 port_sel = I915_READ(PP_ON_DELAYS(pipe)) &
+ u32 port_sel = intel_de_read(dev_priv, PP_ON
[Intel-gfx] [PATCH v2 2/8] drm/i915/combo_phy: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson
Acked-by: Rodrigo Vivi
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_combo_phy.c| 66 +--
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index ec63c2657923..11f80f15cb4d 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -48,7 +48,7 @@ cnl_get_procmon_ref_values(struct drm_i915_private *dev_priv,
enum phy phy)
const struct cnl_procmon *procmon;
u32 val;
- val = I915_READ(ICL_PORT_COMP_DW3(phy));
+ val = intel_de_read(dev_priv, ICL_PORT_COMP_DW3(phy));
switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
default:
MISSING_CASE(val);
@@ -81,20 +81,20 @@ static void cnl_set_procmon_ref_values(struct
drm_i915_private *dev_priv,
procmon = cnl_get_procmon_ref_values(dev_priv, phy);
- val = I915_READ(ICL_PORT_COMP_DW1(phy));
+ val = intel_de_read(dev_priv, ICL_PORT_COMP_DW1(phy));
val &= ~((0xff << 16) | 0xff);
val |= procmon->dw1;
- I915_WRITE(ICL_PORT_COMP_DW1(phy), val);
+ intel_de_write(dev_priv, ICL_PORT_COMP_DW1(phy), val);
- I915_WRITE(ICL_PORT_COMP_DW9(phy), procmon->dw9);
- I915_WRITE(ICL_PORT_COMP_DW10(phy), procmon->dw10);
+ intel_de_write(dev_priv, ICL_PORT_COMP_DW9(phy), procmon->dw9);
+ intel_de_write(dev_priv, ICL_PORT_COMP_DW10(phy), procmon->dw10);
}
static bool check_phy_reg(struct drm_i915_private *dev_priv,
enum phy phy, i915_reg_t reg, u32 mask,
u32 expected_val)
{
- u32 val = I915_READ(reg);
+ u32 val = intel_de_read(dev_priv, reg);
if ((val & mask) != expected_val) {
DRM_DEBUG_DRIVER("Combo PHY %c reg %08x state mismatch: "
@@ -127,8 +127,8 @@ static bool cnl_verify_procmon_ref_values(struct
drm_i915_private *dev_priv,
static bool cnl_combo_phy_enabled(struct drm_i915_private *dev_priv)
{
- return !(I915_READ(CHICKEN_MISC_2) & CNL_COMP_PWR_DOWN) &&
- (I915_READ(CNL_PORT_COMP_DW0) & COMP_INIT);
+ return !(intel_de_read(dev_priv, CHICKEN_MISC_2) & CNL_COMP_PWR_DOWN) &&
+ (intel_de_read(dev_priv, CNL_PORT_COMP_DW0) & COMP_INIT);
}
static bool cnl_combo_phy_verify_state(struct drm_i915_private *dev_priv)
@@ -151,20 +151,20 @@ static void cnl_combo_phys_init(struct drm_i915_private
*dev_priv)
{
u32 val;
- val = I915_READ(CHICKEN_MISC_2);
+ val = intel_de_read(dev_priv, CHICKEN_MISC_2);
val &= ~CNL_COMP_PWR_DOWN;
- I915_WRITE(CHICKEN_MISC_2, val);
+ intel_de_write(dev_priv, CHICKEN_MISC_2, val);
/* Dummy PORT_A to get the correct CNL register from the ICL macro */
cnl_set_procmon_ref_values(dev_priv, PHY_A);
- val = I915_READ(CNL_PORT_COMP_DW0);
+ val = intel_de_read(dev_priv, CNL_PORT_COMP_DW0);
val |= COMP_INIT;
- I915_WRITE(CNL_PORT_COMP_DW0, val);
+ intel_de_write(dev_priv, CNL_PORT_COMP_DW0, val);
- val = I915_READ(CNL_PORT_CL1CM_DW5);
+ val = intel_de_read(dev_priv, CNL_PORT_CL1CM_DW5);
val |= CL_POWER_DOWN_ENABLE;
- I915_WRITE(CNL_PORT_CL1CM_DW5, val);
+ intel_de_write(dev_priv, CNL_PORT_CL1CM_DW5, val);
}
static void cnl_combo_phys_uninit(struct drm_i915_private *dev_priv)
@@ -174,9 +174,9 @@ static void cnl_combo_phys_uninit(struct drm_i915_private
*dev_priv)
if (!cnl_combo_phy_verify_state(dev_priv))
DRM_WARN("Combo PHY HW state changed unexpectedly.\n");
- val = I915_READ(CHICKEN_MISC_2);
+ val = intel_de_read(dev_priv, CHICKEN_MISC_2);
val |= CNL_COMP_PWR_DOWN;
- I915_WRITE(CHICKEN_MISC_2, val);
+ intel_de_write(dev_priv, CHICKEN_MISC_2, val);
}
static bool icl_combo_phy_enabled(struct drm_i915_private *dev_priv,
@@ -184,11 +184,11 @@ static bool icl_combo_phy_enabled(struct
Re: [Intel-gfx] [RFC 00/33] drm/i915/display: mass conversion to intel_de_*() register accessors
On Sat, 25 Jan 2020, Jani Nikula wrote: > On Fri, 24 Jan 2020, Rodrigo Vivi wrote: >> On Fri, Jan 24, 2020 at 01:54:58PM +, Chris Wilson wrote: >>> Quoting Jani Nikula (2020-01-24 13:25:21) >>> > Hey all, >>> > >>> > So I sent [1] to convert some forcewake register accessors... but what if >>> > we >>> > just ripped off the bandage once and for all? It's going to hurt, a lot, >>> > but >>> > we'd get it done. >>> > >>> > This completely rids us of the "dev_priv" dependency in display/. >>> > >>> > All the patches here are per-file and independent of each other. We could >>> > also >>> > pick and apply the ones that are least likely to conflict. >>> > >>> > Opinions? >>> > >>> > >>> > BR, >>> > Jani. >>> > >>> > >>> > PS. I didn't bother looking at the checkpatch warnings this may generate >>> > at this >>> > point. I just used the --linux-spacing option for spatch, and closed my >>> > eyes. I >>> > completely scripted the generation of the series, apart from just a >>> > couple of >>> > build fixes. >>> >>> Yup. Suck it all in, clean up with the usual code refreshes. >>> Schadenfreude-by: Chris Wilson >>> >>> I've looked at a couple of patches to confirm that it does appear purely >>> mechanical, >>> Acked-by: Chris Wilson >> >> Since it is purely mechanical with coccinelle, why not to make in only one >> patch? > > Because such a mega patch would conflict before being able to > merge. You'd have to block everything else. I don't think I'd be able to > merge these in one go either even if we wanted to. Indeed, I started pushing the patches, pushed all that applied, and eight will need a rebase. Thanks for the acks. BR, Jani. > >> Anyway: >> Acked-by: Rodrigo Vivi > > Thanks, > Jani. > >> >>> -Chris >>> ___ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 05/33] drm/i915/combo_phy: use intel_de_*() functions for register access
On Fri, 24 Jan 2020, Matt Roper wrote:
> On Fri, Jan 24, 2020 at 03:25:26PM +0200, Jani Nikula wrote:
>> @@ -151,20 +151,20 @@ static void cnl_combo_phys_init(struct
>> drm_i915_private *dev_priv)
>> {
>> u32 val;
>>
>> -val = I915_READ(CHICKEN_MISC_2);
>> +val = intel_de_read(dev_priv, CHICKEN_MISC_2);
>> val &= ~CNL_COMP_PWR_DOWN;
>> -I915_WRITE(CHICKEN_MISC_2, val);
>> +intel_de_write(dev_priv, CHICKEN_MISC_2, val);
>>
>> /* Dummy PORT_A to get the correct CNL register from the ICL macro */
>> cnl_set_procmon_ref_values(dev_priv, PHY_A);
>>
>> -val = I915_READ(CNL_PORT_COMP_DW0);
>> +val = intel_de_read(dev_priv, CNL_PORT_COMP_DW0);
>> val |= COMP_INIT;
>> -I915_WRITE(CNL_PORT_COMP_DW0, val);
>> +intel_de_write(dev_priv, CNL_PORT_COMP_DW0, val);
>
> Drive by comment...could some fancier coccinelle usage change these to
> intel_de_rmw() instead? We have a lot of rmw behavior for PHY
> registers, and I believe some for pre-ilk watermarks and clock gating
> workarounds in intel_pm.c too.
I decided I wanted to get these merged, as folks seemed to agree with
the approach. The fancy cocci would take a while to figure out. But I'll
look into it as a follow-up.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2 2/2] i915/gem_ctx_isolation: use the gem_engine_topology library, part 2
Switch from simple iteration over all potential engines to using
macro __for_each_physical_engine which only returns engines that are
actually present.
For each context (as it is created) call gem_context_set_all_engines
so that execbuf will interpret the engine specification in the new way.
Signed-off-by: Dale B Stimson
---
tests/i915/gem_ctx_isolation.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index c45617456..1b66fec11 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -586,7 +586,8 @@ static void nonpriv(int fd,
igt_spin_t *spin = NULL;
uint32_t ctx, regs[2], tmpl;
- ctx = gem_context_create(fd);
+ ctx = gem_context_clone_with_engines(fd, 0);
+
tmpl = read_regs(fd, ctx, e, flags);
regs[0] = read_regs(fd, ctx, e, flags);
@@ -599,7 +600,7 @@ static void nonpriv(int fd,
write_regs(fd, ctx, e, flags, values[v]);
if (flags & DIRTY2) {
- uint32_t sw = gem_context_create(fd);
+ uint32_t sw = gem_context_clone_with_engines(fd, 0);
igt_spin_t *syncpt, *dirt;
/* Explicit sync to keep the switch between write/read
*/
@@ -668,7 +669,7 @@ static void isolation(int fd,
igt_spin_t *spin = NULL;
uint32_t ctx[2], regs[2], tmp;
- ctx[0] = gem_context_create(fd);
+ ctx[0] = gem_context_clone_with_engines(fd, 0);
regs[0] = read_regs(fd, ctx[0], e, flags);
spin = igt_spin_new(fd, .ctx = ctx[0], .engine = e->flags);
@@ -687,7 +688,7 @@ static void isolation(int fd,
* the default values from this context, but if goes badly we
* see the corruption from the previous context instead!
*/
- ctx[1] = gem_context_create(fd);
+ ctx[1] = gem_context_clone_with_engines(fd, 0);
regs[1] = read_regs(fd, ctx[1], e, flags);
if (flags & DIRTY2) {
@@ -727,7 +728,7 @@ static void isolation(int fd,
static void inject_reset_context(int fd, const struct intel_execution_engine2
*e)
{
struct igt_spin_factory opts = {
- .ctx = gem_context_create(fd),
+ .ctx = gem_context_clone_with_engines(fd, 0),
.engine = e->flags,
.flags = IGT_SPIN_FAST,
};
@@ -775,11 +776,11 @@ static void preservation(int fd,
gem_quiescent_gpu(fd);
- ctx[num_values] = gem_context_create(fd);
+ ctx[num_values] = gem_context_clone_with_engines(fd, 0);
spin = igt_spin_new(fd, .ctx = ctx[num_values], .engine = e->flags);
regs[num_values][0] = read_regs(fd, ctx[num_values], e, flags);
for (int v = 0; v < num_values; v++) {
- ctx[v] = gem_context_create(fd);
+ ctx[v] = gem_context_clone_with_engines(fd, 0);
write_regs(fd, ctx[v], e, flags, values[v]);
regs[v][0] = read_regs(fd, ctx[v], e, flags);
@@ -874,7 +875,9 @@ igt_main
igt_skip_on(gen > LAST_KNOWN_GEN);
}
- __for_each_static_engine(e) {
+ /* __for_each_physical_engine switches context to all engines. */
+
+ __for_each_physical_engine(fd, e) {
igt_subtest_group {
igt_fixture {
igt_require(has_context_isolation & (1 <<
e->class));
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/8] drm/i915/hdcp: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson
Acked-by: Rodrigo Vivi
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 142 --
1 file changed, 79 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 33dc40a63fce..2d25244f38df 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -112,7 +112,8 @@ static inline
bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
enum transcoder cpu_transcoder, enum port port)
{
- return I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
+ return intel_de_read(dev_priv,
+HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
HDCP_STATUS_ENC;
}
@@ -120,7 +121,8 @@ static inline
bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
enum transcoder cpu_transcoder, enum port port)
{
- return I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
+ return intel_de_read(dev_priv,
+HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
LINK_ENCRYPTION_STATUS;
}
@@ -184,9 +186,9 @@ static bool hdcp_key_loadable(struct drm_i915_private
*dev_priv)
static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
{
- I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
- I915_WRITE(HDCP_KEY_STATUS, HDCP_KEY_LOAD_DONE | HDCP_KEY_LOAD_STATUS |
- HDCP_FUSE_IN_PROGRESS | HDCP_FUSE_ERROR | HDCP_FUSE_DONE);
+ intel_de_write(dev_priv, HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
+ intel_de_write(dev_priv, HDCP_KEY_STATUS,
+ HDCP_KEY_LOAD_DONE | HDCP_KEY_LOAD_STATUS |
HDCP_FUSE_IN_PROGRESS | HDCP_FUSE_ERROR | HDCP_FUSE_DONE);
}
static int intel_hdcp_load_keys(struct drm_i915_private *dev_priv)
@@ -194,7 +196,7 @@ static int intel_hdcp_load_keys(struct drm_i915_private
*dev_priv)
int ret;
u32 val;
- val = I915_READ(HDCP_KEY_STATUS);
+ val = intel_de_read(dev_priv, HDCP_KEY_STATUS);
if ((val & HDCP_KEY_LOAD_DONE) && (val & HDCP_KEY_LOAD_STATUS))
return 0;
@@ -203,7 +205,7 @@ static int intel_hdcp_load_keys(struct drm_i915_private
*dev_priv)
* out of reset. So if Key is not already loaded, its an error state.
*/
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
- if (!(I915_READ(HDCP_KEY_STATUS) & HDCP_KEY_LOAD_DONE))
+ if (!(intel_de_read(dev_priv, HDCP_KEY_STATUS) &
HDCP_KEY_LOAD_DONE))
return -ENXIO;
/*
@@ -223,7 +225,7 @@ static int intel_hdcp_load_keys(struct drm_i915_private
*dev_priv)
return ret;
}
} else {
- I915_WRITE(HDCP_KEY_CONF, HDCP_KEY_LOAD_TRIGGER);
+ intel_de_write(dev_priv, HDCP_KEY_CONF, HDCP_KEY_LOAD_TRIGGER);
}
/* Wait for the keys to load (500us) */
@@ -236,7 +238,7 @@ static int intel_hdcp_load_keys(struct drm_i915_private
*dev_priv)
return -ENXIO;
/* Send Aksv over to PCH display for use in authentication */
- I915_WRITE(HDCP_KEY_CONF, HDCP_AKSV_SEND_TRIGGER);
+ intel_de_write(dev_priv, HDCP_KEY_CONF, HDCP_AKSV_SEND_TRIGGER);
return 0;
}
@@ -244,7 +246,7 @@ static int intel_hdcp_load_keys(struct drm_i915_private
*dev_priv)
/* Returns updated SHA-1 index */
static int intel_write_sha_text(struct drm_i915_private *dev_priv, u32
sha_text)
{
- I915_WRITE(HDCP_SHA_TEXT, sha_text);
+ intel_de_write(dev_priv, HDCP_SHA_TEXT, sha_text);
if (intel_de_wait_for_set(dev_priv, HDCP_REP_CTL, HDCP_SHA1_READY, 1)) {
drm_err(&dev_priv->drm, "Timed out waiting for SHA1 ready\n");
return -ETIMEDOUT;
@@ -311,7 +313,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
ret = shim->read_v_prime_part(intel_dig_port, i, &vprim
[Intel-gfx] [PATCH v2 1/8] drm/i915/icl_dsi: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson
Acked-by: Rodrigo Vivi
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 271 +
1 file changed, 145 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 1186a5df057e..f553ba4c63c7 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -39,14 +39,14 @@
static inline int header_credits_available(struct drm_i915_private *dev_priv,
enum transcoder dsi_trans)
{
- return (I915_READ(DSI_CMD_TXCTL(dsi_trans)) & FREE_HEADER_CREDIT_MASK)
+ return (intel_de_read(dev_priv, DSI_CMD_TXCTL(dsi_trans)) &
FREE_HEADER_CREDIT_MASK)
>> FREE_HEADER_CREDIT_SHIFT;
}
static inline int payload_credits_available(struct drm_i915_private *dev_priv,
enum transcoder dsi_trans)
{
- return (I915_READ(DSI_CMD_TXCTL(dsi_trans)) & FREE_PLOAD_CREDIT_MASK)
+ return (intel_de_read(dev_priv, DSI_CMD_TXCTL(dsi_trans)) &
FREE_PLOAD_CREDIT_MASK)
>> FREE_PLOAD_CREDIT_SHIFT;
}
@@ -110,7 +110,7 @@ static void wait_for_cmds_dispatched_to_panel(struct
intel_encoder *encoder)
/* wait for LP TX in progress bit to be cleared */
for_each_dsi_port(port, intel_dsi->ports) {
dsi_trans = dsi_port_to_transcoder(port);
- if (wait_for_us(!(I915_READ(DSI_LP_MSG(dsi_trans)) &
+ if (wait_for_us(!(intel_de_read(dev_priv,
DSI_LP_MSG(dsi_trans)) &
LPTX_IN_PROGRESS), 20))
drm_err(&dev_priv->drm, "LPTX bit not cleared\n");
}
@@ -138,7 +138,7 @@ static bool add_payld_to_queue(struct intel_dsi_host *host,
const u8 *data,
for (j = 0; j < min_t(u32, len - i, 4); j++)
tmp |= *data++ << 8 * j;
- I915_WRITE(DSI_CMD_TXPYLD(dsi_trans), tmp);
+ intel_de_write(dev_priv, DSI_CMD_TXPYLD(dsi_trans), tmp);
}
return true;
@@ -161,7 +161,7 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host *host,
return -1;
}
- tmp = I915_READ(DSI_CMD_TXHDR(dsi_trans));
+ tmp = intel_de_read(dev_priv, DSI_CMD_TXHDR(dsi_trans));
if (pkt.payload)
tmp |= PAYLOAD_PRESENT;
@@ -178,7 +178,7 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host *host,
tmp |= ((pkt.header[0] & DT_MASK) << DT_SHIFT);
tmp |= (pkt.header[1] << PARAM_WC_LOWER_SHIFT);
tmp |= (pkt.header[2] << PARAM_WC_UPPER_SHIFT);
- I915_WRITE(DSI_CMD_TXHDR(dsi_trans), tmp);
+ intel_de_write(dev_priv, DSI_CMD_TXHDR(dsi_trans), tmp);
return 0;
}
@@ -215,53 +215,55 @@ static void dsi_program_swing_and_deemphasis(struct
intel_encoder *encoder)
* Program voltage swing and pre-emphasis level values as per
* table in BSPEC under DDI buffer programing
*/
- tmp = I915_READ(ICL_PORT_TX_DW5_LN0(phy));
+ tmp = intel_de_read(dev_priv, ICL_PORT_TX_DW5_LN0(phy));
tmp &= ~(SCALING_MODE_SEL_MASK | RTERM_SELECT_MASK);
tmp |= SCALING_MODE_SEL(0x2);
tmp |= TAP2_DISABLE | TAP3_DISABLE;
tmp |= RTERM_SELECT(0x6);
- I915_WRITE(ICL_PORT_TX_DW5_GRP(phy), tmp);
+ intel_de_write(dev_priv, ICL_PORT_TX_DW5_GRP(phy), tmp);
- tmp = I915_READ(ICL_PORT_TX_DW5_AUX(phy));
+ tmp = intel_de_read(dev_priv, ICL_PORT_TX_DW5_AUX(phy));
tmp &= ~(SCALING_MODE_SEL_MASK | RTERM_SELECT_MASK);
tmp |= SCALING_MODE_SEL(0x2);
tmp |= TAP2_DISABLE | TAP3_DISABLE;
tmp |= RTERM_SELECT(0x6);
- I915_WRITE(ICL_PORT_TX_DW5_AUX(phy), tmp);
+ intel_de_write(dev_priv, ICL_PORT_TX_DW5_AUX(phy), tmp);
- tmp = I915_READ(ICL_PORT_TX_DW2_LN0(phy
[Intel-gfx] [PATCH v2 5/8] drm/i915/display_power: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson
Acked-by: Rodrigo Vivi
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_power.c| 292 ++
1 file changed, 157 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 18d8bfdcb086..b24f2b041d99 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -304,11 +304,11 @@ static u32 hsw_power_well_requesters(struct
drm_i915_private *dev_priv,
u32 req_mask = HSW_PWR_WELL_CTL_REQ(pw_idx);
u32 ret;
- ret = I915_READ(regs->bios) & req_mask ? 1 : 0;
- ret |= I915_READ(regs->driver) & req_mask ? 2 : 0;
+ ret = intel_de_read(dev_priv, regs->bios) & req_mask ? 1 : 0;
+ ret |= intel_de_read(dev_priv, regs->driver) & req_mask ? 2 : 0;
if (regs->kvmr.reg)
- ret |= I915_READ(regs->kvmr) & req_mask ? 4 : 0;
- ret |= I915_READ(regs->debug) & req_mask ? 8 : 0;
+ ret |= intel_de_read(dev_priv, regs->kvmr) & req_mask ? 4 : 0;
+ ret |= intel_de_read(dev_priv, regs->debug) & req_mask ? 8 : 0;
return ret;
}
@@ -330,7 +330,7 @@ static void hsw_wait_for_power_well_disable(struct
drm_i915_private *dev_priv,
* Skip the wait in case any of the request bits are set and print a
* diagnostic message.
*/
- wait_for((disabled = !(I915_READ(regs->driver) &
+ wait_for((disabled = !(intel_de_read(dev_priv, regs->driver) &
HSW_PWR_WELL_CTL_STATE(pw_idx))) ||
(reqs = hsw_power_well_requesters(dev_priv, regs, pw_idx)), 1);
if (disabled)
@@ -373,17 +373,18 @@ static void hsw_power_well_enable(struct drm_i915_private
*dev_priv,
gen9_wait_for_power_well_fuses(dev_priv, SKL_PG0);
}
- val = I915_READ(regs->driver);
- I915_WRITE(regs->driver, val | HSW_PWR_WELL_CTL_REQ(pw_idx));
+ val = intel_de_read(dev_priv, regs->driver);
+ intel_de_write(dev_priv, regs->driver,
+ val | HSW_PWR_WELL_CTL_REQ(pw_idx));
hsw_wait_for_power_well_enable(dev_priv, power_well);
/* Display WA #1178: cnl */
if (IS_CANNONLAKE(dev_priv) &&
pw_idx >= GLK_PW_CTL_IDX_AUX_B &&
pw_idx <= CNL_PW_CTL_IDX_AUX_F) {
- val = I915_READ(CNL_AUX_ANAOVRD1(pw_idx));
+ val = intel_de_read(dev_priv, CNL_AUX_ANAOVRD1(pw_idx));
val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
- I915_WRITE(CNL_AUX_ANAOVRD1(pw_idx), val);
+ intel_de_write(dev_priv, CNL_AUX_ANAOVRD1(pw_idx), val);
}
if (wait_fuses)
@@ -404,8 +405,9 @@ static void hsw_power_well_disable(struct drm_i915_private
*dev_priv,
hsw_power_well_pre_disable(dev_priv,
power_well->desc->hsw.irq_pipe_mask);
- val = I915_READ(regs->driver);
- I915_WRITE(regs->driver, val & ~HSW_PWR_WELL_CTL_REQ(pw_idx));
+ val = intel_de_read(dev_priv, regs->driver);
+ intel_de_write(dev_priv, regs->driver,
+ val & ~HSW_PWR_WELL_CTL_REQ(pw_idx));
hsw_wait_for_power_well_disable(dev_priv, power_well);
}
@@ -422,12 +424,14 @@ icl_combo_phy_aux_power_well_enable(struct
drm_i915_private *dev_priv,
WARN_ON(!IS_ICELAKE(dev_priv));
- val = I915_READ(regs->driver);
- I915_WRITE(regs->driver, val | HSW_PWR_WELL_CTL_REQ(pw_idx));
+ val = intel_de_read(dev_priv, regs->driver);
+ intel_de_write(dev_priv, regs->driver,
+ val | HSW_PWR_WELL_CTL_REQ(pw_idx));
if (INTEL_GEN(dev_priv) < 12) {
- val = I915_READ(ICL_PORT_CL_DW12(phy));
- I915_WRITE(ICL_PORT_CL_DW12(phy), val | ICL_LANE_ENABLE_AUX);
+ val = intel_de_read(dev_priv, ICL_PORT_CL_DW12(phy));
+ intel_de_write(dev_priv, ICL_PORT_CL_DW12(phy),
+
Re: [Intel-gfx] [RFC 00/33] drm/i915/display: mass conversion to intel_de_*() register accessors
On Fri, 24 Jan 2020, Matt Roper wrote: > There's a lot of display (watermark) code in intel_pm.c as well, even > though it doesn't live in the display/ directory. We should probably > pull the watermark stuff out into a separate display/intel_wm.c or > something soon, but in the meantime we'll probably want to switch a > bunch of that code over to using these new functions. But I guess you > can't do that with coccinelle though since there are parts of the file > that aren't display-related and shouldn't use the same display helpers. Yeah, display/ was a clear-cut line. I may have already pushed some patches using intel_de_*_fw from the top level code, but I think it would be better to move all large chunks of code that do display uncore stuff under display/. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check current i915_vma.pin_count status first on unbind
On 26/01/2020 10:23, Chris Wilson wrote:
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is
currently pinned, without waiting to see if the inflight operations may
unpin it. We see this problem with the shrinker trying to unbind the
active vma from inside its bind worker:
<6> [472.618968] Workqueue: events_unbound fence_work [i915]
<4> [472.618970] Call Trace:
<4> [472.618974] ? __schedule+0x2e5/0x810
<4> [472.618978] schedule+0x37/0xe0
<4> [472.618982] schedule_preempt_disabled+0xf/0x20
<4> [472.618984] __mutex_lock+0x281/0x9c0
<4> [472.618987] ? mark_held_locks+0x49/0x70
<4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60
<4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619122] i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915]
<4> [472.619208] i915_gem_shrink+0x328/0x660 [i915]
<4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915]
<4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80
<4> [472.619363] ? __alloc_pd+0xb/0x30 [i915]
<4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30
<4> [472.619368] ? __module_address+0x23/0xe0
<4> [472.619371] ? is_module_address+0x26/0x40
<4> [472.619374] ? static_obj+0x34/0x50
<4> [472.619376] ? lockdep_init_map+0x4d/0x1e0
<4> [472.619407] setup_page_dma+0xd/0x90 [i915]
<4> [472.619437] alloc_pd+0x29/0x50 [i915]
<4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915]
<4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915]
<4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915]
<4> [472.619577] __vma_bind+0x26/0x40 [i915]
<4> [472.619611] fence_work+0x1c/0x90 [i915]
<4> [472.619617] process_one_work+0x26a/0x620
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_vma.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 84e03da0d5f9..2ffc68e18dd0 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1190,18 +1190,6 @@ int __i915_vma_unbind(struct i915_vma *vma)
lockdep_assert_held(&vma->vm->mutex);
- /*
-* First wait upon any activity as retiring the request may
-* have side-effects such as unpinning or even unbinding this vma.
-*
-* XXX Actually waiting under the vm->mutex is a hinderance and
-* should be pipelined wherever possible. In cases where that is
-* unavoidable, we should lift the wait to before the mutex.
-*/
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
-
if (i915_vma_is_pinned(vma)) {
vma_print_allocator(vma, "is pinned");
return -EAGAIN;
@@ -1275,6 +1263,11 @@ int i915_vma_unbind(struct i915_vma *vma)
if (!drm_mm_node_allocated(&vma->node))
return 0;
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
+ return -EAGAIN;
+ }
+
if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
/* XXX not always required: nop_clear_range */
wakeref = intel_runtime_pm_get(&vm->i915->runtime_pm);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Adding YUV444 packed format support for skl+ (V13)
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
labels.
v5: Started to use XYUV instead of AYUV, as we don't use alpha.
v6: Removed unneeded initializer for new XYUV format.
v7: Added scaling support for DRM_FORMAT_XYUV
v8: Edited commit message to be more clear about skl+, renamed
PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
doesn't support per-pixel alpha. Fixed minor code issues.
v9: Moved DRM format check to proper place in intel_framebuffer_init.
v10: Added missing XYUV format to sprite planes for skl+.
v11: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV.
v12: Fixed rebase conflicts
V13: Rebased.
Added format to ICL format lists.
v12:
Reviewed-by: Ville Syrjälä
Reviewed-by: Matt Roper
Signed-off-by: Stanislav Lisovskiy
Signed-off-by: Bob Paauwe
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +
drivers/gpu/drm/i915/display/intel_sprite.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7f94d5ca4207..b9f993769a4a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3328,6 +3328,8 @@ int skl_format_to_fourcc(int format, bool rgb_order, bool
alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_XYUV:
+ return DRM_FORMAT_XYUV;
case PLANE_CTL_FORMAT_P010:
return DRM_FORMAT_P010;
case PLANE_CTL_FORMAT_P012:
@@ -4538,6 +4540,8 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
case DRM_FORMAT_XRGB16161616F:
case DRM_FORMAT_ARGB16161616F:
return PLANE_CTL_FORMAT_XRGB_16161616F;
+ case DRM_FORMAT_XYUV:
+ return PLANE_CTL_FORMAT_XYUV;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -6147,6 +6151,7 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 2f277d1fc6f1..aafe04b29a61 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2470,6 +2470,7 @@ static const u32 skl_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+ DRM_FORMAT_XYUV,
};
static const u32 skl_planar_formats[] = {
@@ -2488,6 +2489,7 @@ static const u32 skl_planar_formats[] = {
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
DRM_FORMAT_NV12,
+ DRM_FORMAT_XYUV,
};
static const u32 glk_planar_formats[] = {
@@ -2559,6 +2561,7 @@ static const u32 icl_sdr_uv_plane_formats[] = {
DRM_FORMAT_XVYU2101010,
DRM_FORMAT_XVYU12_16161616,
DRM_FORMAT_XVYU16161616,
+ DRM_FORMAT_XYUV,
};
static const u32 icl_hdr_plane_formats[] = {
@@ -2590,6 +2593,7 @@ static const u32 icl_hdr_plane_formats[] = {
DRM_FORMAT_XVYU2101010,
DRM_FORMAT_XVYU12_16161616,
DRM_FORMAT_XVYU16161616,
+ DRM_FORMAT_XYUV,
};
static const u64 skl_plane_format_modifiers_noccs[] = {
@@ -2757,6 +2761,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b93c4c18f05c..b3848e73de29 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6764,7 +6764,7 @@ enum {
#define PLANE_CTL_FORMAT_P012(5 << 24)
#define PLANE_CTL_FORMAT_XRGB_16161616F (6 << 24)
#define PLANE_CTL_FORMAT_P016(7 << 24)
-#define PLANE_CTL_FORMAT_AYUV(8 << 24)
+#define PLANE_CTL_FORMAT_XYUV(8 << 24)
#define PLANE_CTL_FORMAT_INDEXED (12 << 24)
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lis
