Re: [Intel-gfx] [PATCH] drm/i915/perf: Invalidate OA TLB on when closing perf stream
On Mon, Mar 09, 2020 at 10:45:47PM +, Chris Wilson wrote: Quoting Umesh Nerlige Ramappa (2020-03-09 21:10:57) On running several back to back perf capture sessions involving closing and opening the perf stream, invalid OA reports are seen in the beginning of the OA buffer in some sessions. Fix this by invalidating OA TLB when the perf stream is closed or disabled on gen12. Signed-off-by: Umesh Nerlige Ramappa Testcase? Issue occurs if all perf tests are run on TGL, but I guess a single subtest should do it too. Here it is - https://patchwork.freedesktop.org/patch/356973/ Thanks, Umesh -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Gen11 workarounds
== Series Details ==
Series: Gen11 workarounds
URL : https://patchwork.freedesktop.org/series/74475/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a627f7908723 drm/i915: Handle all MCR ranges
0d45ae1b23d2 drm/i915: Add Wa_1207131216:icl,ehl
ac72d609fb43 drm/i915: Add Wa_1604278689:icl,ehl
0ae22805c1e6 drm/i915: Add Wa_1406306137:icl,ehl
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 16 lines checked
4c3c07b8545b drm/i915: Apply Wa_1406680159:icl, ehl as an engine workaround
e92df8bf04c0 drm/i915: Add Wa_1605460711 / Wa_1408767742 to ICL and EHL
dff1210436d4 drm/i915: Add Wa_1409178092:icl,ehl
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit f545425a0145 ("drm/i915/icl:
Remove Wa_1604302699")'
#14:
References: f545425a0145 ("drm/i915/icl: Remove Wa_1604302699")
total: 1 errors, 0 warnings, 0 checks, 10 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: Add Wa_1207131216:icl,ehl
On gen11 the XY_FAST_COPY_BLT command has some size restrictions on its
usage. Although this instruction is mainly used by userspace, i915 also
uses it to copy object contents during some selftests, so let's ensure
the restrictions are followed.
Bspec: 6544
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index 39b8a055d80a..e00792158f13 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -196,6 +196,17 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
return err;
}
+/* Wa_1209644611:icl,ehl */
+static bool wa_1209644611_applies(struct drm_i915_private *i915, u32 size)
+{
+ u32 height = size >> PAGE_SHIFT;
+
+ if (!IS_GEN(i915, 11))
+ return false;
+
+ return height % 4 == 3 && height <= 8;
+}
+
struct i915_vma *intel_emit_vma_copy_blt(struct intel_context *ce,
struct i915_vma *src,
struct i915_vma *dst)
@@ -237,7 +248,8 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
intel_context *ce,
size = min_t(u64, rem, block_size);
GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
- if (INTEL_GEN(i915) >= 9) {
+ if (INTEL_GEN(i915) >= 9 &&
+ !wa_1209644611_applies(i915, size)) {
*cmd++ = GEN9_XY_FAST_COPY_BLT_CMD | (10 - 2);
*cmd++ = BLT_DEPTH_32 | PAGE_SIZE;
*cmd++ = 0;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Handle all MCR ranges
The bspec documents multiple MCR ranges; make sure they're all captured
by the driver.
Bspec: 13991, 52079
Fixes: 592a7c5e082e ("drm/i915: Extend non readable mcr range")
Cc: Mika Kuoppala
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 391f39b1fb26..3e352e2a5b79 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1648,15 +1648,34 @@ create_scratch(struct i915_address_space *vm, int count)
return ERR_PTR(err);
}
+static const struct {
+ u32 start;
+ u32 end;
+} mcr_ranges_gen8[] = {
+ { .start = 0x5500, .end = 0x55ff },
+ { .start = 0x7000, .end = 0x7fff },
+ { .start = 0x9400, .end = 0x97ff },
+ { .start = 0xb000, .end = 0xb3ff },
+ { .start = 0xe000, .end = 0xe7ff },
+ {},
+};
+
static bool mcr_range(struct drm_i915_private *i915, u32 offset)
{
+ int i;
+
+ if (INTEL_GEN(i915) < 8)
+ return false;
+
/*
-* Registers in this range are affected by the MCR selector
+* Registers in these ranges are affected by the MCR selector
* which only controls CPU initiated MMIO. Routing does not
* work for CS access so we cannot verify them on this path.
*/
- if (INTEL_GEN(i915) >= 8 && (offset >= 0xb000 && offset <= 0xb4ff))
- return true;
+ for (i = 0; mcr_ranges_gen8[i].start; i++)
+ if (offset >= mcr_ranges_gen8[i].start &&
+ offset <= mcr_ranges_gen8[i].end)
+ return true;
return false;
}
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Add Wa_1409178092:icl,ehl
Note that we used to have this implemented on ICL under a different
number (Wa_1604302699), but it was removed because it vanished from the
bspec and the register update didn't seem to be sticking. However the
initial implementation of the workaround appears to have been in the
wrong place (not handled as an engine workaround) and might behave
better now that we've had various other updates to our multicast
register handling.
References: f545425a0145 ("drm/i915/icl: Remove Wa_1604302699")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a539157dd571..5e009ee070dc 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1495,6 +1495,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal,
GEN7_FF_THREAD_MODE,
GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
+
+ /* Wa_1409178092:icl,ehl */
+ wa_write_or(wal, GEN10_L3_CHICKEN_MODE_REGISTER,
+ GEN11_I2M_WRITE_DISABLE);
}
if (IS_GEN_RANGE(i915, 9, 12)) {
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915: Apply Wa_1406680159:icl, ehl as an engine workaround
The register this workaround updates is a render engine register in the
MCR range, so we should initialize this in rcs_engine_wa_init() rather
than gt_wa_init().
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1222
Fixes: 36204d80bacb ("drm/i915/icl: Wa_1406680159")
Cc: Mika Kuoppala
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index bd90dc5fb35d..700cb6d1f45e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -917,11 +917,6 @@ icl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
SLICE_UNIT_LEVEL_CLKGATE,
MSCUNIT_CLKGATE_DIS);
- /* Wa_1406680159:icl */
- wa_write_or(wal,
- SUBSLICE_UNIT_LEVEL_CLKGATE,
- GWUNIT_CLKGATE_DIS);
-
/* Wa_1406838659:icl (pre-prod) */
if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_B0))
wa_write_or(wal,
@@ -1487,6 +1482,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
/* Wa_1406306137:icl,ehl */
wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN11_DIS_PICK_2ND_EU);
+
+ /* Wa_1406680159:icl,ehl */
+ wa_write_or(wal,
+ SUBSLICE_UNIT_LEVEL_CLKGATE,
+ GWUNIT_CLKGATE_DIS);
}
if (IS_GEN_RANGE(i915, 9, 12)) {
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Add Wa_1605460711 / Wa_1408767742 to ICL and EHL
This workaround appears under two different numbers (and with somewhat
confused stepping applicability on ICL). Ultimately it appears we
should just implement this for all stepping of ICL and EHL.
Note that this is identical to Wa_1407928979:tgl that already exists in
our driver too...yet another number referencing the same actual
workaround.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 700cb6d1f45e..a539157dd571 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1487,6 +1487,14 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal,
SUBSLICE_UNIT_LEVEL_CLKGATE,
GWUNIT_CLKGATE_DIS);
+
+ /*
+* Wa_1408767742:icl[a2..forever],ehl[all]
+* Wa_1605460711:icl[a0..c0]
+*/
+ wa_write_or(wal,
+ GEN7_FF_THREAD_MODE,
+ GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
}
if (IS_GEN_RANGE(i915, 9, 12)) {
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Add Wa_1406306137:icl,ehl
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 1cf931dde0ca..bd90dc5fb35d 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1484,6 +1484,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
/* Wa_1407352427:icl,ehl */
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
PSDUNIT_CLKGATE_DIS);
+
+ /* Wa_1406306137:icl,ehl */
+ wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN11_DIS_PICK_2ND_EU);
}
if (IS_GEN_RANGE(i915, 9, 12)) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 92ae96cf5b64..b6941da3b588 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9151,6 +9151,7 @@ enum {
#define GEN9_ROW_CHICKEN4 _MMIO(0xe48c)
#define GEN12_DISABLE_TDL_PUSH REG_BIT(9)
+#define GEN11_DIS_PICK_2ND_EUREG_BIT(7)
#define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
#define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: Add Wa_1604278689:icl,ehl
The bspec description for this workaround tells us to program 0x_ into both FBC_RT_BASE_ADDR_REGISTER_* registers, but we've previously found that this leads to failures in CI. Our suspicion is that the failures are caused by this valid turning on the "address valid bit" even though we're intentionally supplying an invalid address. Experimentation has shown that setting all bits _except_ for the RT_VALID bit seems to avoid these failures. v2: - Mask off the RT_VALID bit. Experimentation with CI trybot indicates that this is necessary to avoid reset failures on BCS. Bspec: 11388 Bspec: 33451 Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ drivers/gpu/drm/i915/i915_reg.h | 1 + 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 3e352e2a5b79..1cf931dde0ca 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -575,6 +575,12 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs *engine, /* allow headerless messages for preemptible GPGPU context */ WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE, GEN11_SAMPLER_ENABLE_HEADLESS_MSG); + + /* Wa_1604278689:icl,ehl */ + wa_write_masked_or(wal, IVB_FBC_RT_BASE_UPPER, + 0, /* write-only register; skip validation */ + 0x); + wa_write(wal, IVB_FBC_RT_BASE, 0x & ~ILK_FBC_RT_VALID); } static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine, diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 79ae9654dac9..92ae96cf5b64 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3285,6 +3285,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) /* Framebuffer compression for Ivybridge */ #define IVB_FBC_RT_BASE_MMIO(0x7020) +#define IVB_FBC_RT_BASE_UPPER _MMIO(0x7024) #define IPS_CTL_MMIO(0x43408) #define IPS_ENABLE (1 << 31) -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Gen11 workarounds
The first patch here technically impacts all gen8+ platforms, but the rest of these are specifically for ICL and EHL. Matt Roper (7): drm/i915: Handle all MCR ranges drm/i915: Add Wa_1207131216:icl,ehl drm/i915: Add Wa_1604278689:icl,ehl drm/i915: Add Wa_1406306137:icl,ehl drm/i915: Apply Wa_1406680159:icl,ehl as an engine workaround drm/i915: Add Wa_1605460711 / Wa_1408767742 to ICL and EHL drm/i915: Add Wa_1409178092:icl,ehl .../gpu/drm/i915/gem/i915_gem_object_blt.c| 14 - drivers/gpu/drm/i915/gt/intel_workarounds.c | 56 --- drivers/gpu/drm/i915/i915_reg.h | 2 + 3 files changed, 63 insertions(+), 9 deletions(-) -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 4/4] drm/i915: Add support for integrated privacy screen
Hi Jani,
I have 1 question / need 1 help about this patch:
On Mon, Mar 9, 2020 at 5:06 PM Rajat Jain wrote:
>
> Add support for an ACPI based integrated privacy screen that is
> available on some systems.
>
> Signed-off-by: Rajat Jain
> ---
> v7: * Move the privacy-screen property back into drm core.
> * Do the actual HW EPS toggling at commit time.
> * Provide a sample ACPI node for reference in comments.
> v6: Always initialize prop in intel_attach_privacy_screen_property()
> v5: fix a cosmetic checkpatch warning
> v4: Fix a typo in intel_privacy_screen.h
> v3: * Change license to GPL-2.0 OR MIT
> * Move privacy screen enum from UAPI to intel_display_types.h
> * Rename parameter name and some other minor changes.
> v2: Formed by splitting the original patch into multiple patches.
> - All code has been moved into i915 now.
> - Privacy screen is a i915 property
> - Have a local state variable to store the prvacy screen. Don't read
> it from hardware.
>
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 30 ++-
> .../drm/i915/display/intel_privacy_screen.c | 175 ++
> .../drm/i915/display/intel_privacy_screen.h | 27 +++
> 5 files changed, 234 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 9f887a86e555d..da42389107f9c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -209,7 +209,8 @@ i915-y += \
> display/intel_vga.o
> i915-$(CONFIG_ACPI) += \
> display/intel_acpi.o \
> - display/intel_opregion.o
> + display/intel_opregion.o \
> + display/intel_privacy_screen.o
> i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
> display/intel_fbdev.o
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index d043057d2fa03..fc6264b4a7f73 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -150,6 +150,7 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> new_conn_state->base.picture_aspect_ratio !=
> old_conn_state->base.picture_aspect_ratio ||
> new_conn_state->base.content_type !=
> old_conn_state->base.content_type ||
> new_conn_state->base.scaling_mode !=
> old_conn_state->base.scaling_mode ||
> + new_conn_state->base.privacy_screen_status !=
> old_conn_state->base.privacy_screen_status ||
> !blob_equal(new_conn_state->base.hdr_output_metadata,
> old_conn_state->base.hdr_output_metadata))
> crtc_state->mode_changed = true;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 41c623b029464..a39b0c420b50a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -62,6 +62,7 @@
> #include "intel_lspcon.h"
> #include "intel_lvds.h"
> #include "intel_panel.h"
> +#include "intel_privacy_screen.h"
> #include "intel_psr.h"
> #include "intel_sideband.h"
> #include "intel_tc.h"
> @@ -5886,6 +5887,12 @@ intel_dp_connector_register(struct drm_connector
> *connector)
> dev_priv->acpi_scan_done = true;
> }
>
> + /* Check for integrated Privacy screen support */
> + if (intel_privacy_screen_present(to_intel_connector(connector)))
> + drm_connector_attach_privacy_screen_property(connector);
> + else
> + drm_connector_destroy_privacy_screen_property(connector);
> +
> DRM_DEBUG_KMS("registering %s bus for %s\n",
> intel_dp->aux.name, connector->kdev->kobj.name);
>
> @@ -6881,9 +6888,30 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> drm_connector_attach_scaling_mode_property(connector,
> allowed_scalers);
>
> connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
> +
> + drm_connector_create_privacy_screen_property(connector);
> }
> }
>
> +static void intel_dp_update_privacy_screen(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + const struct drm_connector_state *conn_state)
> +{
> + struct drm_connector *connector = conn_state->connector;
> +
> + if (connector->privacy_screen_property)
> + intel_privacy_screen_set_val(to_intel_connector(connector),
> +
> conn_state->privacy_screen_status);
> +}
> +
> +static void intel_dp_update_pipe(struct intel_encoder *encoder,
> +
Re: [Intel-gfx] [RFC 01/12] drm/i915: Expose list of clients in sysfs
Quoting Tvrtko Ursulin (2020-03-09 23:26:34)
>
> On 09/03/2020 21:34, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-03-09 18:31:18)
> >> +struct i915_drm_client *
> >> +i915_drm_client_add(struct i915_drm_clients *clients, struct task_struct
> >> *task)
> >> +{
> >> + struct i915_drm_client *client;
> >> + int ret;
> >> +
> >> + client = kzalloc(sizeof(*client), GFP_KERNEL);
> >> + if (!client)
> >> + return ERR_PTR(-ENOMEM);
> >> +
> >> + kref_init(>kref);
> >> + client->clients = clients;
> >> +
> >> + ret = mutex_lock_interruptible(>lock);
> >> + if (ret)
> >> + goto err_id;
> >> + ret = xa_alloc_cyclic(>xarray, >id, client,
> >> + xa_limit_32b, >next_id, GFP_KERNEL);
> >
> > So what's next_id used for that explains having the over-arching mutex?
>
> It's to give out client id's "cyclically" - before I apparently
> misunderstood what xa_alloc_cyclic is supposed to do - I thought after
> giving out id 1 it would give out 2 next, even if 1 was returned to the
> pool in the meantime. But it doesn't, I need to track the start point
> for the next search with "next".
Ok. A requirement of the API for the external counter.
> I want this to make intel_gpu_top's life easier, so it doesn't have to
> deal with id recycling for all practical purposes.
Fair enough. I only worry about the radix nodes and sparse ids :)
> And a peek into xa implementation told me the internal lock is not
> protecting "next.
See xa_alloc_cyclic(), seems to cover __xa_alloc_cycle (where *next is
manipulated) under the xa_lock.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add support for integrated privacy screen
== Series Details == Series: drm: Add support for integrated privacy screen URL : https://patchwork.freedesktop.org/series/74473/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4d85b0afcb69 intel_acpi: Rename drm_dev local variable to dev 8f19bae8d1da drm/connector: Add support for privacy-screen property ad4ee254fd45 drm/i915: Lookup and attach ACPI device node for connectors 4d56cad4f624 drm/i915: Add support for integrated privacy screen -:33: WARNING:LONG_LINE: line over 100 characters #33: FILE: drivers/gpu/drm/i915/display/intel_atomic.c:153: + new_conn_state->base.privacy_screen_status != old_conn_state->base.privacy_screen_status || -:72: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #72: FILE: drivers/gpu/drm/i915/display/intel_dp.c:6897: +static void intel_dp_update_privacy_screen(struct intel_encoder *encoder, + const struct intel_crtc_state *crtc_state, -:103: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #103: new file mode 100644 total: 0 errors, 2 warnings, 1 checks, 275 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 4/4] drm/i915: Add support for integrated privacy screen
Add support for an ACPI based integrated privacy screen that is
available on some systems.
Signed-off-by: Rajat Jain
---
v7: * Move the privacy-screen property back into drm core.
* Do the actual HW EPS toggling at commit time.
* Provide a sample ACPI node for reference in comments.
v6: Always initialize prop in intel_attach_privacy_screen_property()
v5: fix a cosmetic checkpatch warning
v4: Fix a typo in intel_privacy_screen.h
v3: * Change license to GPL-2.0 OR MIT
* Move privacy screen enum from UAPI to intel_display_types.h
* Rename parameter name and some other minor changes.
v2: Formed by splitting the original patch into multiple patches.
- All code has been moved into i915 now.
- Privacy screen is a i915 property
- Have a local state variable to store the prvacy screen. Don't read
it from hardware.
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 30 ++-
.../drm/i915/display/intel_privacy_screen.c | 175 ++
.../drm/i915/display/intel_privacy_screen.h | 27 +++
5 files changed, 234 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9f887a86e555d..da42389107f9c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,7 +209,8 @@ i915-y += \
display/intel_vga.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
- display/intel_opregion.o
+ display/intel_opregion.o \
+ display/intel_privacy_screen.o
i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
display/intel_fbdev.o
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index d043057d2fa03..fc6264b4a7f73 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -150,6 +150,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode ||
+ new_conn_state->base.privacy_screen_status !=
old_conn_state->base.privacy_screen_status ||
!blob_equal(new_conn_state->base.hdr_output_metadata,
old_conn_state->base.hdr_output_metadata))
crtc_state->mode_changed = true;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 41c623b029464..a39b0c420b50a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -62,6 +62,7 @@
#include "intel_lspcon.h"
#include "intel_lvds.h"
#include "intel_panel.h"
+#include "intel_privacy_screen.h"
#include "intel_psr.h"
#include "intel_sideband.h"
#include "intel_tc.h"
@@ -5886,6 +5887,12 @@ intel_dp_connector_register(struct drm_connector
*connector)
dev_priv->acpi_scan_done = true;
}
+ /* Check for integrated Privacy screen support */
+ if (intel_privacy_screen_present(to_intel_connector(connector)))
+ drm_connector_attach_privacy_screen_property(connector);
+ else
+ drm_connector_destroy_privacy_screen_property(connector);
+
DRM_DEBUG_KMS("registering %s bus for %s\n",
intel_dp->aux.name, connector->kdev->kobj.name);
@@ -6881,9 +6888,30 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
drm_connector_attach_scaling_mode_property(connector,
allowed_scalers);
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
+
+ drm_connector_create_privacy_screen_property(connector);
}
}
+static void intel_dp_update_privacy_screen(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
+{
+ struct drm_connector *connector = conn_state->connector;
+
+ if (connector->privacy_screen_property)
+ intel_privacy_screen_set_val(to_intel_connector(connector),
+conn_state->privacy_screen_status);
+}
+
+static void intel_dp_update_pipe(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state *conn_state)
+{
+ intel_dp_update_privacy_screen(encoder, crtc_state, conn_state);
+ intel_panel_update_backlight(encoder, crtc_state, conn_state);
+}
+
static void
Re: [Intel-gfx] [RFC 0/7] Asynchronous flip implementation for i915
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu: > Without async flip support in the kernel, fullscreen apps where game > resolution is equal to the screen resolution, must perform an extra blit > per frame prior to flipping. > > Asynchronous page flips will also boost the FPS of Mesa benchmarks. Thanks a lot for doing this work! I did some quick smoke tests on a Gemini Lake and while this appears to be working fine with xf86-video-modesetting, the "pageflip.c" program I shared previously breaks when you launch it as "./pageflip -n": this argument makes the program *not* request for page flip events (by not setting DRM_MODE_PAGE_FLIP_EVENT) and just try to flip as fast as it can. I didn't investigate why this breaks, but it's probably some corner case the series is forgetting. Also, doesn't async pageflip interact with some other display features? Don't we need to disable at least one of FBC, PSR and/or render compression when using async page flips? Ville mentioned some possible interactions with SURF/OFFSET tracking too (framebuffers not being at the start of the bo), which doesn't seem to be covered by the series. Thanks, Paulo > > Karthik B S (7): > drm/i915: Define flip done functions and enable IER > drm/i915: Add support for async flips in I915 > drm/i915: Make commit call blocking in case of async flips > drm/i915: Add checks specific to async flips > drm/i915: Add flip_done_handler definition > drm/i915: Enable and handle flip done interrupt > drm/i915: Do not call drm_crtc_arm_vblank_event in async flips > > drivers/gpu/drm/i915/display/intel_display.c | 55 +-- > drivers/gpu/drm/i915/display/intel_sprite.c | 12 ++-- > drivers/gpu/drm/i915/i915_irq.c | 58 +++- > drivers/gpu/drm/i915/i915_irq.h | 2 + > drivers/gpu/drm/i915/i915_reg.h | 1 + > 5 files changed, 117 insertions(+), 11 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/12] Per client engine busyness
On 09/03/2020 22:02, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-03-09 18:31:17) From: Tvrtko Ursulin Another re-spin of the per-client engine busyness series. Highlights from this version: * Different way of tracking runtime of exited/unreachable context. This time round I accumulate those per context/client and engine class, but active contexts are kept in a list and tallied on sysfs reads. * I had to do a small tweak in the engine release code since I needed the GEM context for a bit longer. (So I can accumulate the intel_context runtime into it as it is getting freed, because context complete can be late.) * PPHWSP method is back and even comes first in the series this time. It still can't show the currently running workloads but the software tracking method suffers from the CSB processing delay with high frequency and very short batches. I bet it's ksoftirqd, but this could be quite problematic for us. gem_exec_nop/foo? I wonder if this also ties into how much harder it is to saturate the GPU with nops from userspace than it is from the kernel. At least disappointing, or even problematic yes. I had a cunning plan though, to report back max(sw_runtimetime, pphwsp_runtime). Apart from it not being that cunning when things start to systematically drift. Then it effectively becomes pphwsp runtime. Oh well, don't know at the moment, might have to live with pphwsp only. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 01/12] drm/i915: Expose list of clients in sysfs
On 09/03/2020 21:34, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-09 18:31:18)
+struct i915_drm_client *
+i915_drm_client_add(struct i915_drm_clients *clients, struct task_struct *task)
+{
+ struct i915_drm_client *client;
+ int ret;
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return ERR_PTR(-ENOMEM);
+
+ kref_init(>kref);
+ client->clients = clients;
+
+ ret = mutex_lock_interruptible(>lock);
+ if (ret)
+ goto err_id;
+ ret = xa_alloc_cyclic(>xarray, >id, client,
+ xa_limit_32b, >next_id, GFP_KERNEL);
So what's next_id used for that explains having the over-arching mutex?
It's to give out client id's "cyclically" - before I apparently
misunderstood what xa_alloc_cyclic is supposed to do - I thought after
giving out id 1 it would give out 2 next, even if 1 was returned to the
pool in the meantime. But it doesn't, I need to track the start point
for the next search with "next".
I want this to make intel_gpu_top's life easier, so it doesn't have to
deal with id recycling for all practical purposes.
And a peek into xa implementation told me the internal lock is not
protecting "next.
I could stick with one lock and not use the internal one if I used it on
release path as well.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 5/7] drm/i915: Add flip_done_handler definition
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Send the flip done event in the handler and disable the interrupt.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/i915_irq.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 5955e737a45d..1feda9aecf4a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1243,6 +1243,24 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
The compiler is going to complain that we added a static function with
no caller.
See my comment on commit 1: please squash this patch with the one that
makes use of the new function.
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_device *dev = _priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>event_lock, irqflags);
> +
> + if (crtc_state->event->base.event->type == DRM_EVENT_FLIP_COMPLETE) {
> + drm_crtc_send_vblank_event(>base, crtc_state->event);
> + crtc_state->event = NULL;
> + }
> +
> + spin_unlock_irqrestore(>event_lock, irqflags);
> + icl_disable_flip_done(>base);
> +}
>
> static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Add checks specific to async flips
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Support added only for async flips on primary plane.
> If flip is requested on any other plane, reject it.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 29
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 25fad5d01e67..a8de08c3773e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14732,6 +14732,31 @@ static bool
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
> return false;
> }
>
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> + int i, j;
> +
> + /*FIXME: Async flip is only supported for primary plane currently
> + * Support for overlays to be added.
> + */
> + for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> + if (crtc_state->uapi.async_flip) {
> + for_each_new_plane_in_state(>base,
> + plane, plane_state, j) {
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> + DRM_ERROR("Async flips is NOT supported
> for non-primary plane\n");
My understanding is that this is not a case of DRM_ERROR, since it's
just user space doing something it shouldn't.
Have we checked if xf86-video-modesetting or some other current user
space is going to try these calls on non-primary when async_flips are
enabled? Specifically, how does it react when it gets the EINVAL? We
should try to avoid the case where we release a Kernel that current
user space is not prepared for (even if it's not the Kernel's fault).
> + return -EINVAL;
> + }
> + }
> + }
> + }
> + return 0;
> +}
> +
> /**
> * intel_atomic_check - validate state object
> * @dev: drm device
> @@ -14760,6 +14785,10 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> + ret = intel_atomic_check_async(state);
> + if (ret)
> + goto fail;
> +
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> if (!needs_modeset(new_crtc_state)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/7] drm/i915: Add support for async flips in I915
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Enable support for async flips in I915.
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index dd47eb65b563..4ce9897f5c58 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4756,6 +4756,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state
> *crtc_state,
> plane_ctl |= PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE;
> }
>
> + if (crtc_state->uapi.async_flip)
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;
> +
> plane_ctl |= skl_plane_ctl_format(fb->format->format);
> plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
> plane_ctl |= skl_plane_ctl_rotate(rotation & DRM_MODE_ROTATE_MASK);
> @@ -17738,6 +17741,7 @@ static void intel_mode_config_init(struct
> drm_i915_private *i915)
>
> mode_config->funcs = _mode_funcs;
>
> + mode_config->async_page_flip = true;
We should only enable the feature to user space after it has been fully
implemented inside the Kernel. Think about the case where git-bisect
decides to land at exactly this commit when someone is debugging a
failure unrelated to async vblanks.
Also, when features have trivial on/off switches like the line above,
it's better if the patch that enables the feature only contains the
line that toggles the on/off switch. This way, if a revert is needed,
we can just switch it to off without removing more code. Also, it
enables us to land the rest of the code while keeping the feature off
for stabilization.
Also, the line above is enabling the feature for every platform, which
is probably not a goal of this series.
> /*
>* Maximum framebuffer dimensions, chosen to match
>* the maximum render engine surface size on gen4+.
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 80cf02a6eec1..42037aee9b78 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6794,6 +6794,7 @@ enum {
> #define PLANE_CTL_TILED_X (1 << 10)
> #define PLANE_CTL_TILED_Y (4 << 10)
> #define PLANE_CTL_TILED_YF (5 << 10)
> +#define PLANE_CTL_ASYNC_FLIP (1 << 9)
> #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8)
> #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
> #define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/7] drm/i915: Define flip done functions and enable IER
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and enable
> the flip done interrupt in IER.
>
> Flip done interrupt is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/i915_irq.c | 37 -
> drivers/gpu/drm/i915/i915_irq.h | 2 ++
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ecf07b0faad2..5955e737a45d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2626,6 +2626,27 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
> return 0;
> }
>
> +void icl_enable_flip_done(struct drm_crtc *crtc)
Platform prefixes indicate the first platform that is able to run this
function. In this case I can't even see which platforms will run the
function because it's only later in the series that this function will
get called. I'm not a fan of this patch splitting style where a
function gets added in patch X and then used in patch X+Y. IMHO
functions should only be introduced in patches where they are used.
This makes the code much easier to review.
So, shouldn't this be skl_enable_flip_done()?
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + struct drm_vblank_crtc *vblank = _priv->drm.vblank[pipe];
> + unsigned long irqflags;
> +
> + /* Make sure that vblank is not enabled, as we are already sending
> + * the page flip event in the flip_done_handler.
> + */
> + if (atomic_read(>refcount) != 0)
> + drm_crtc_vblank_put(crtc);
This is the kind of thing that will be much easier to review when this
patch gets squashed in the one that makes use of these functions.
Even after reading the whole series, this put() doesn't seem correct to
me. What is the problem with having vblanks enabled? Is it because we
were sending duplicate vblank events without these lines? Where is the
get() that triggers this put()? Please help me understand this.
> +
> + spin_lock_irqsave(_priv->irq_lock, irqflags);
> +
> + bdw_enable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> +
> +}
> +
> /* Called from drm generic code, passed 'crtc' which
> * we use as a pipe index
> */
> @@ -2686,6 +2707,20 @@ void bdw_disable_vblank(struct drm_crtc *crtc)
> spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> }
>
> +
> +void icl_disable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(_priv->irq_lock, irqflags);
> +
> + bdw_disable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> +}
> +
> static void ibx_irq_reset(struct drm_i915_private *dev_priv)
> {
> struct intel_uncore *uncore = _priv->uncore;
> @@ -3375,7 +3410,7 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> de_port_masked |= CNL_AUX_CHANNEL_F;
>
> de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> -GEN8_PIPE_FIFO_UNDERRUN;
> + GEN8_PIPE_FIFO_UNDERRUN | GEN9_PIPE_PLANE1_FLIP_DONE;
This is going to set this bit for gen8 too, which is something we
probably don't want since it doesn't exist there.
The patch also does not add the handler for the interrupt, which
doesn't make sense (see my point above).
Also, don't we want to do like GEN8_PIPE_VBLANK and also set it on the
power_well_post_enable hook? If not, why? This is probably a case we
should write an IGT subtest for.
>
> de_port_enables = de_port_masked;
> if (IS_GEN9_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
> index 812c47a9c2d6..6fc319980dd3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.h
> +++ b/drivers/gpu/drm/i915/i915_irq.h
> @@ -114,11 +114,13 @@ int i915gm_enable_vblank(struct drm_crtc *crtc);
> int i965_enable_vblank(struct drm_crtc *crtc);
> int ilk_enable_vblank(struct drm_crtc *crtc);
> int bdw_enable_vblank(struct drm_crtc *crtc);
> +void icl_enable_flip_done(struct drm_crtc *crtc);
> void i8xx_disable_vblank(struct drm_crtc *crtc);
> void i915gm_disable_vblank(struct drm_crtc *crtc);
> void i965_disable_vblank(struct drm_crtc *crtc);
> void ilk_disable_vblank(struct drm_crtc *crtc);
> void bdw_disable_vblank(struct drm_crtc *crtc);
> +void icl_disable_flip_done(struct drm_crtc *crtc);
>
> void gen2_irq_reset(struct intel_uncore *uncore);
> void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
Re: [Intel-gfx] [PATCH v4] drm/i915/gt: allow setting generic data pointer
On 3/9/20 3:38 PM, Andi Shyti wrote:
Hi Daniele,
Quoting Andi Shyti (2020-03-06 23:03:44)
-void debugfs_gt_register_files(struct intel_gt *gt,
- struct dentry *root,
- const struct debugfs_gt_file *files,
- unsigned long count)
+void intel_gt_debugfs_register_files(struct dentry *root,
+const struct debugfs_gt_file *files,
+unsigned long count, void *data)
{
while (count--) {
- if (!files->eval || files->eval(gt))
+ if (!files->eval || files->eval(data))
debugfs_create_file(files->name,
- 0444, root, gt,
+ 0444, root, data,
files->fops);
And now we are not a intel_gt routine, you'll want to move again :)
i915_debugfs_utils.c ? :)
Actually, this is what it came to and this was the first
discussion I had with Daniele and that's also why I was loyal to
th "_gt_" wrappers until the end. But I had to agree that this
was becoming more a limitation.
The biggest difference left, which by the way is the real
distinguishing factor other than the *gt pointer, is that we
create files under gt directory, instead of having the root
imposed by the drm (even though the caller can eventually choose
different roots).
We could perhaps store the root pointer in the intel_gt
structure so that this function stays de facto an intel_gt
routine and the caller doesn't need to care where the files will
be generated. This is what we planned to do with sysfs as well.
What do you think?
I thought we were passing along the root. If not I think we should, more
of a debugfs constructor context?
What do you mean with debugfs constructor context? Is it a
gt->debugfs_root pointer like the gt->sysfs_root?
Getting the root pointer internally from gt wouldn't work well for
subfolders, like the gt/uc/ folder I want to add for GuC/HuC files.
this was not my idea, actually I was thinking the opposite.
When in this case you call "intel_gt_debugfs_register_files", you
would provide "gt" pointer where the funcion extracts and handles
by its own the debugfs_root. The caller doesn't need to care
about it.
Another idea could be to use contexts, e.g. guc or pm or whatever
comes to mind, and the intel_gt_debugfs handles everything
including subdirectories.
I think extracting this generic helper to a common file, possibly as a follow-up
step, isn't a bad idea, also considering that there is at least 1 more
use-case in i915_debugfs_register(). Maybe we can generalize as something
like:
struct i915_debugfs_files {
const char *name;
const struct file_operations *fops;
bool (*eval)(void *data);
}
void i915_debugfs_register_files(struct dentry *root,
const struct i915_debugfs_files *files,
unsigned long count, void *data)
{
while (count--) {
umode_t mode = files->fops->write ? 0644 : 0444;
if (!files->eval || files->eval(data))
debugfs_create_file(files->name,
mode, root, data,
files->fops);
}
}
apart from the mode, isn't this the same as the latest patch you
actually reviewed?
Yes, but by adding the mode and making the naming generic we can re-use
it outside the GT code, e.g. in i915_debugfs_connector_add() and to
replace the loop in i915_debugfs_register(). I was reconnecting to
Chris' proposal of having a common function in i915_debugfs_utils.c (or
even just in i915_debugfs.c ?).
void i915_debugfs_register_files(struct dentry *root,
based on my proposal, root would point, in your case, to the
"guc/" directory that will be created under the "gt/". NULL if
you want the file to be created in the main "gt/" directory.
If I'm understanding correctly, you're proposing to pass both struct
intel_gt *gt and struct dentry *root, with the latter being set only if
we want a folder different that gt/ ? What would that gain us compared
to just passing the desired root every time like we currently do?
While if we want to go by context, we could do something like:
struct i915_debugfs_files {
const char *name;
const struct file_operations *fops;
bool (*eval)(void *data);
enum intel_gt_context context;
This seems overkill, also because you'd have to save all the roots
inside of the gt struct to allow accessing them from within the
register_files function.
}
and the gt handles everything.
Maybe I'm misunderstanding your proposal, but it feels like you're
trying to find a use for a gt variable we don't really need just to keep
this as a gt routine.
Daniele
Andi
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Mark up the racy access to switch_priority_hint
== Series Details == Series: drm/i915/execlists: Mark up the racy access to switch_priority_hint URL : https://patchwork.freedesktop.org/series/74457/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16883_full Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16883/index.html Changes --- No changes found Participating hosts (10 -> 8) -- Missing(2): pig-skl-6260u pig-glk-j5005 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8097 -> Patchwork_16883 * Piglit: piglit_4509 -> None CI-20190529: 20190529 CI_DRM_8097: 2e46e269a2843c5d0b6c72bfb7fa9d9913c15415 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5499: 2e23cf6f63fc6ba1d9543f8327698d6f21813cec @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16883: c44455523ac832672d86d46d40d2a71a550c6536 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16883/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/gt: allow setting generic data pointer
Hi Daniele,
> > > > > Quoting Andi Shyti (2020-03-06 23:03:44)
> > > > > > -void debugfs_gt_register_files(struct intel_gt *gt,
> > > > > > - struct dentry *root,
> > > > > > - const struct debugfs_gt_file *files,
> > > > > > - unsigned long count)
> > > > > > +void intel_gt_debugfs_register_files(struct dentry *root,
> > > > > > +const struct debugfs_gt_file
> > > > > > *files,
> > > > > > +unsigned long count, void
> > > > > > *data)
> > > > > > {
> > > > > > while (count--) {
> > > > > > - if (!files->eval || files->eval(gt))
> > > > > > + if (!files->eval || files->eval(data))
> > > > > > debugfs_create_file(files->name,
> > > > > > - 0444, root, gt,
> > > > > > + 0444, root, data,
> > > > > > files->fops);
> > > > >
> > > > > And now we are not a intel_gt routine, you'll want to move again :)
> > > > > i915_debugfs_utils.c ? :)
> > > >
> > > > Actually, this is what it came to and this was the first
> > > > discussion I had with Daniele and that's also why I was loyal to
> > > > th "_gt_" wrappers until the end. But I had to agree that this
> > > > was becoming more a limitation.
> > > >
> > > > The biggest difference left, which by the way is the real
> > > > distinguishing factor other than the *gt pointer, is that we
> > > > create files under gt directory, instead of having the root
> > > > imposed by the drm (even though the caller can eventually choose
> > > > different roots).
> > > >
> > > > We could perhaps store the root pointer in the intel_gt
> > > > structure so that this function stays de facto an intel_gt
> > > > routine and the caller doesn't need to care where the files will
> > > > be generated. This is what we planned to do with sysfs as well.
> > > >
> > > > What do you think?
> > >
> > > I thought we were passing along the root. If not I think we should, more
> > > of a debugfs constructor context?
> >
> > What do you mean with debugfs constructor context? Is it a
> > gt->debugfs_root pointer like the gt->sysfs_root?
> >
> Getting the root pointer internally from gt wouldn't work well for
> subfolders, like the gt/uc/ folder I want to add for GuC/HuC files.
this was not my idea, actually I was thinking the opposite.
When in this case you call "intel_gt_debugfs_register_files", you
would provide "gt" pointer where the funcion extracts and handles
by its own the debugfs_root. The caller doesn't need to care
about it.
Another idea could be to use contexts, e.g. guc or pm or whatever
comes to mind, and the intel_gt_debugfs handles everything
including subdirectories.
> I think extracting this generic helper to a common file, possibly as a
> follow-up
> step, isn't a bad idea, also considering that there is at least 1 more
> use-case in i915_debugfs_register(). Maybe we can generalize as something
> like:
>
> struct i915_debugfs_files {
> const char *name;
> const struct file_operations *fops;
> bool (*eval)(void *data);
> }
>
> void i915_debugfs_register_files(struct dentry *root,
>const struct i915_debugfs_files *files,
>unsigned long count, void *data)
> {
> while (count--) {
> umode_t mode = files->fops->write ? 0644 : 0444;
> if (!files->eval || files->eval(data))
> debugfs_create_file(files->name,
> mode, root, data,
> files->fops);
> }
> }
apart from the mode, isn't this the same as the latest patch you
actually reviewed?
> void i915_debugfs_register_files(struct dentry *root,
based on my proposal, root would point, in your case, to the
"guc/" directory that will be created under the "gt/". NULL if
you want the file to be created in the main "gt/" directory.
While if we want to go by context, we could do something like:
struct i915_debugfs_files {
const char *name;
const struct file_operations *fops;
bool (*eval)(void *data);
enum intel_gt_context context;
}
and the gt handles everything.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Invalidate OA TLB on when closing perf stream
Quoting Umesh Nerlige Ramappa (2020-03-09 21:10:57) > On running several back to back perf capture sessions involving closing > and opening the perf stream, invalid OA reports are seen in the > beginning of the OA buffer in some sessions. Fix this by invalidating OA > TLB when the perf stream is closed or disabled on gen12. > > Signed-off-by: Umesh Nerlige Ramappa Testcase? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Mark racy read of intel_engine_cs.saturated
== Series Details == Series: drm/i915: Mark racy read of intel_engine_cs.saturated URL : https://patchwork.freedesktop.org/series/74455/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16882_full Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/index.html Changes --- No changes found Participating hosts (10 -> 8) -- Missing(2): pig-skl-6260u pig-glk-j5005 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8097 -> Patchwork_16882 * Piglit: piglit_4509 -> None CI-20190529: 20190529 CI_DRM_8097: 2e46e269a2843c5d0b6c72bfb7fa9d9913c15415 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5499: 2e23cf6f63fc6ba1d9543f8327698d6f21813cec @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16882: 4b47cb86aa9e39ac563cf958a514f0949e63a901 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/gt: allow setting generic data pointer
On 3/7/20 2:19 PM, Andi Shyti wrote:
Hi Chris,
Quoting Andi Shyti (2020-03-06 23:03:44)
-void debugfs_gt_register_files(struct intel_gt *gt,
- struct dentry *root,
- const struct debugfs_gt_file *files,
- unsigned long count)
+void intel_gt_debugfs_register_files(struct dentry *root,
+const struct debugfs_gt_file *files,
+unsigned long count, void *data)
{
while (count--) {
- if (!files->eval || files->eval(gt))
+ if (!files->eval || files->eval(data))
debugfs_create_file(files->name,
- 0444, root, gt,
+ 0444, root, data,
files->fops);
And now we are not a intel_gt routine, you'll want to move again :)
i915_debugfs_utils.c ? :)
Actually, this is what it came to and this was the first
discussion I had with Daniele and that's also why I was loyal to
th "_gt_" wrappers until the end. But I had to agree that this
was becoming more a limitation.
The biggest difference left, which by the way is the real
distinguishing factor other than the *gt pointer, is that we
create files under gt directory, instead of having the root
imposed by the drm (even though the caller can eventually choose
different roots).
We could perhaps store the root pointer in the intel_gt
structure so that this function stays de facto an intel_gt
routine and the caller doesn't need to care where the files will
be generated. This is what we planned to do with sysfs as well.
What do you think?
I thought we were passing along the root. If not I think we should, more
of a debugfs constructor context?
What do you mean with debugfs constructor context? Is it a
gt->debugfs_root pointer like the gt->sysfs_root?
Getting the root pointer internally from gt wouldn't work well for
subfolders, like the gt/uc/ folder I want to add for GuC/HuC files. I
think extracting this generic helper to a common file, possibly as a
follow-up step, isn't a bad idea, also considering that there is at
least 1 more use-case in i915_debugfs_register(). Maybe we can
generalize as something like:
struct i915_debugfs_files {
const char *name;
const struct file_operations *fops;
bool (*eval)(void *data);
}
void i915_debugfs_register_files(struct dentry *root,
const struct i915_debugfs_files *files,
unsigned long count, void *data)
{
while (count--) {
umode_t mode = files->fops->write ? 0644 : 0444;
if (!files->eval || files->eval(data))
debugfs_create_file(files->name,
mode, root, data,
files->fops);
}
}
Daniele
The main thing of course is not to overengineer and do the minimal
necessary for the immediate users we have. We can always extend and
refactor for a third user, etc, etc.
So if this works for gt + children, go for it and worry about tomorrow,
tomorrow. Trusting our good practice for "a stitch in time saves nine".
this came after Daniele's guc patches where he preferred to
define his own functions instead of using this one that is meant
to be used in that situation.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/12] Per client engine busyness
Quoting Tvrtko Ursulin (2020-03-09 18:31:17) > From: Tvrtko Ursulin > > Another re-spin of the per-client engine busyness series. Highlights from this > version: > > * Different way of tracking runtime of exited/unreachable context. This time >round I accumulate those per context/client and engine class, but active >contexts are kept in a list and tallied on sysfs reads. > * I had to do a small tweak in the engine release code since I needed the >GEM context for a bit longer. (So I can accumulate the intel_context > runtime >into it as it is getting freed, because context complete can be late.) > * PPHWSP method is back and even comes first in the series this time. It > still >can't show the currently running workloads but the software tracking method >suffers from the CSB processing delay with high frequency and very short >batches. I bet it's ksoftirqd, but this could be quite problematic for us. gem_exec_nop/foo? I wonder if this also ties into how much harder it is to saturate the GPU with nops from userspace than it is from the kernel. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/2] drm/edid: Name the detailed monitor range flags
This patch adds defines for the detailed monitor
range flags as per the EDID specification.
v2:
* Rename the flags with DRM_EDID_ (Jani N)
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Clinton A Taylor
Cc: Kazlauskas Nicholas
Cc: Jani Nikula
Signed-off-by: Manasi Navare
Reviewed-by: Nicholas Kazlauskas
---
include/drm/drm_edid.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index f0b03d401c27..34b15e3d070c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -91,6 +91,11 @@ struct detailed_data_string {
u8 str[13];
} __attribute__((packed));
+#define DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG 0x00
+#define DRM_EDID_RANGE_LIMITS_ONLY_FLAG 0x01
+#define DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02
+#define DRM_EDID_CVT_SUPPORT_FLAG 0x04
+
struct detailed_data_monitor_range {
u8 min_vfreq;
u8 max_vfreq;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_freesync_caps() to make it generic and be used
across all DRM drivers
v5:
* Use the renamed flags
v4:
* Use is_display_descriptor() (Ville)
* Name the monitor range flags (Ville)
v3:
* Remove the edid parsing restriction for just DP (Nicholas)
* Use drm_for_each_detailed_block (Ville)
* Make the drm_get_adaptive_sync_range function static (Harry, Jani)
v2:
* Change vmin and vmax to use u8 (Ville)
* Dont store pixel clock since that is just a max dotclock
and not related to VRR mode (Manasi)
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Clinton A Taylor
Cc: Kazlauskas Nicholas
Signed-off-by: Manasi Navare
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/drm_edid.c | 44 +
include/drm/drm_connector.h | 22 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ad41764a4ebe..24b76ae58fdd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
}
}
+static
+void get_adaptive_sync_range(struct detailed_timing *timing,
+void *info_adaptive_sync)
+{
+ struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
+ const struct detailed_non_pixel *data = >data.other_data;
+ const struct detailed_data_monitor_range *range = >data.range;
+
+ if (!is_display_descriptor((const u8 *)timing,
EDID_DETAIL_MONITOR_RANGE))
+ return;
+
+ /*
+* Check for flag range limits only. If flag == 1 then
+* no additional timing information provided.
+* Default GTF, GTF Secondary curve and CVT are not
+* supported
+*/
+ if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
+ return;
+
+ adaptive_sync->min_vfreq = range->min_vfreq;
+ adaptive_sync->max_vfreq = range->max_vfreq;
+}
+
+static
+void drm_get_adaptive_sync_range(struct drm_connector *connector,
+const struct edid *edid)
+{
+ struct drm_display_info *info = >display_info;
+
+ if (!version_greater(edid, 1, 1))
+ return;
+
+ drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
+ >adaptive_sync);
+
+ DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
+ info->adaptive_sync.min_vfreq,
+ info->adaptive_sync.max_vfreq);
+}
+
/* A connector has no EDID information, so we've got no EDID to compute quirks
from. Reset
* all of the values which would have been set from EDID
*/
@@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
memset(>hdmi, 0, sizeof(info->hdmi));
info->non_desktop = 0;
+ memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
}
u32 drm_add_display_info(struct drm_connector *connector, const struct edid
*edid)
@@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector *connector,
const struct edid *edi
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
+ drm_get_adaptive_sync_range(connector, edid);
+
DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
if (edid->revision < 3)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 0df7a95ca5d9..2b22c0fa42c4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -254,6 +254,23 @@ enum drm_panel_orientation {
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+/**
+ * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
+ * _display_info
+ *
+ * This struct is used to store a Panel's Adaptive Sync capabilities
+ * as parsed from EDID's detailed monitor range descriptor block.
+ *
+ * @min_vfreq: This is the min supported refresh rate in Hz from
+ * EDID's detailed monitor range.
+ * @max_vfreq: This is the max supported refresh rate in Hz from
+ * EDID's detailed monitor range
+ */
+struct drm_adaptive_sync_info {
+ u8 min_vfreq;
+ u8 max_vfreq;
+};
+
/*
* This is a consolidated colorimetry list supported by HDMI and
* DP protocol standard. The respective connectors will register
@@ -473,6 +490,11 @@ struct drm_display_info {
* @non_desktop: Non desktop display (HMD).
*/
bool non_desktop;
+
+ /**
+* @adaptive_sync: Adaptive Sync capabilities of the DP/eDP sink
+*/
+ struct drm_adaptive_sync_info adaptive_sync;
};
int drm_display_info_set_bus_formats(struct drm_display_info *info,
--
2.19.1
Re: [Intel-gfx] [RFC 01/12] drm/i915: Expose list of clients in sysfs
Quoting Tvrtko Ursulin (2020-03-09 18:31:18)
> +struct i915_drm_client *
> +i915_drm_client_add(struct i915_drm_clients *clients, struct task_struct
> *task)
> +{
> + struct i915_drm_client *client;
> + int ret;
> +
> + client = kzalloc(sizeof(*client), GFP_KERNEL);
> + if (!client)
> + return ERR_PTR(-ENOMEM);
> +
> + kref_init(>kref);
> + client->clients = clients;
> +
> + ret = mutex_lock_interruptible(>lock);
> + if (ret)
> + goto err_id;
> + ret = xa_alloc_cyclic(>xarray, >id, client,
> + xa_limit_32b, >next_id, GFP_KERNEL);
So what's next_id used for that explains having the over-arching mutex?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/mm: Allow drm_mm_initialized() to be used outside of the locks
== Series Details == Series: drm/mm: Allow drm_mm_initialized() to be used outside of the locks URL : https://patchwork.freedesktop.org/series/74451/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16881_full Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16881/index.html Changes --- No changes found Participating hosts (10 -> 8) -- Missing(2): pig-skl-6260u pig-glk-j5005 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8097 -> Patchwork_16881 * Piglit: piglit_4509 -> None CI-20190529: 20190529 CI_DRM_8097: 2e46e269a2843c5d0b6c72bfb7fa9d9913c15415 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5499: 2e23cf6f63fc6ba1d9543f8327698d6f21813cec @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16881: a8b46b0eb5da1475b70b45365bf57ffa75ed3787 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16881/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl
On Wed, Mar 04, 2020 at 09:56:28PM -0800, Dixit, Ashutosh wrote:
On Wed, 04 Mar 2020 00:52:34 -0800, Lionel Landwerlin wrote:
On 04/03/2020 07:48, Dixit, Ashutosh wrote:
> On Tue, 03 Mar 2020 14:19:05 -0800, Umesh Nerlige Ramappa wrote:
>> From: Lionel Landwerlin
>>
>> With the currently available parameters for the i915-perf stream,
>> there are still situations that are not well covered :
>>
>> If an application opens the stream with polling disable or at very low
>> frequency and OA interrupt enabled, no data will be available even
>> though somewhere between nothing and half of the OA buffer worth of
>> data might have landed in memory.
>>
>> To solve this issue we have a new flush ioctl on the perf stream that
>> forces the i915-perf driver to look at the state of the buffer when
>> called and makes any data available through both poll() & read() type
>> syscalls.
>>
>> v2: Version the ioctl (Joonas)
>> v3: Rebase (Umesh)
>>
>> Signed-off-by: Lionel Landwerlin
>> Signed-off-by: Umesh Nerlige Ramappa
> [snip]
>
>> +/**
>> + * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
>> + * @stream: An enabled i915 perf stream
>> + *
>> + * The intention is to flush all the data available for reading from the OA
>> + * buffer
>> + */
>> +static void i915_perf_flush_data(struct i915_perf_stream *stream)
>> +{
>> + stream->pollin = oa_buffer_check(stream, true);
>> +}
> Since this function doesn't actually wake up any thread (which anyway can
> be done by sending a signal to the blocked thread), is the only purpose of
> this function to update OA buffer head/tail? But in that it is not clear
> why a separate ioctl should be created for this, can't the read() call
> itself call oa_buffer_check() to update the OA buffer head/tail?
>
> Again just trying to minimize uapi changes if possible.
Most applications will call read() after being notified by poll()/select()
that some data is available.
Correct this is the standard non blocking read behavior.
Changing that behavior will break some of the existing perf tests .
I am not suggesting changing that (that standard non blocking read
behavior).
If any data is available, this new ioctl will wake up existing waiters on
poll()/select().
The issue is we are not calling wake_up() in the above function to wake up
any blocked waiters. The ioctl will just update the OA buffer head/tail so
that (a) a subsequent blocking read will not block, or (b) a subsequent non
blocking read will return valid data (not -EAGAIN), or (c) a poll/select
will not block but return immediately saying data is available.
That is why it seems to me the ioctl is not required, updating the OA
buffer head/tail can be done as part of the read() (and the poll/select)
calls themselves.
We will investigate if this can be done and update the patches in the next
revision accordingly. Thanks!
resending (cc: Lionel)..
In this case, where we are trying to determine if there is any data in
the oa buffer before the next interrupt has fired, user could call poll
with a reasonable timeout to determine if data is available or not.
That would eliminate the need for the flush ioctl. Thoughts?
Thanks,
Umesh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: Invalidate OA TLB on when closing perf stream
On running several back to back perf capture sessions involving closing and opening the perf stream, invalid OA reports are seen in the beginning of the OA buffer in some sessions. Fix this by invalidating OA TLB when the perf stream is closed or disabled on gen12. Signed-off-by: Umesh Nerlige Ramappa --- drivers/gpu/drm/i915/i915_perf.c | 8 drivers/gpu/drm/i915/i915_reg.h | 2 ++ 2 files changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 1b074bb4a7fe..551be589d6f4 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -2700,6 +2700,14 @@ static void gen12_oa_disable(struct i915_perf_stream *stream) 50)) drm_err(>perf->i915->drm, "wait for OA to be disabled timed out\n"); + + intel_uncore_write(uncore, GEN12_OA_TLB_INV_CR, 1); + if (intel_wait_for_register(uncore, + GEN12_OA_TLB_INV_CR, + 1, 0, + 50)) + drm_err(>perf->i915->drm, + "wait for OA tlb invalidate timed out\n"); } /** diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 79ae9654dac9..95725e61d9f1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -693,6 +693,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define OABUFFER_SIZE_8M(6 << 3) #define OABUFFER_SIZE_16M (7 << 3) +#define GEN12_OA_TLB_INV_CR _MMIO(0xceec) + /* Gen12 OAR unit */ #define GEN12_OAR_OACONTROL _MMIO(0x2960) #define GEN12_OAR_OACONTROL_COUNTER_FORMAT_SHIFT 1 -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] Cleanup drm_dp_mst_topology_cbs hooks
On Mon, Mar 9, 2020 at 4:27 PM Lyude Paul wrote: > > On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote: > > drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical > > amongst every driver and don't do anything other than calling > > drm_connector_register(). > > drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical > > amongst every driver and don't do anything other than cleaning up the > > connector((drm_connector_unregister()/drm_connector_put())) except for > > amdgpu_dm driver where some amdgpu_dm specific code in there. > > Yeah that amdgpu destruction code kinda stinks a little bit :\. I think we can > just drop some of it and move the rest into their connector destruction > callbacks. > > For the whole series: > Reviewed-by: Lyude Paul > > I'm going to go ahead and let the maintainers know I'm going to push this > (since there's some minor changes here outside of drm-misc), and push this to > drm-misc-next. Then I'll go and write some patches to remove the leftover amd > bits and drop the callback for good (I'll cc it to you as well). Series is: Reviewed-by: Alex Deucher > > > > > This series aims to cleaup these drm_dp_mst_topology_mgr_cbs hooks. > > > > Pankaj Bharadiya (5): > > drm: Register connector instead of calling register_connector callback > > drm: Remove dp mst register connector callbacks > > drm/dp_mst: Remove register_connector callback > > drm: Add drm_dp_destroy_connector helper and use it > > drm: Remove drm dp mst destroy_connector callbacks > > > > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 -- > > drivers/gpu/drm/drm_dp_mst_topology.c | 18 +++--- > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 19 --- > > drivers/gpu/drm/radeon/radeon_dp_mst.c| 17 - > > include/drm/drm_dp_mst_helper.h | 1 - > > 6 files changed, 15 insertions(+), 62 deletions(-) > > > -- > Cheers, > Lyude Paul (she/her) > Associate Software Engineer at Red Hat > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/edid: Name the detailed monitor range flags
On Mon, Mar 09, 2020 at 10:35:52AM +0200, Jani Nikula wrote:
> On Fri, 06 Mar 2020, Manasi Navare wrote:
> > On Fri, Mar 06, 2020 at 12:30:46PM +0200, Jani Nikula wrote:
> >> On Thu, 05 Mar 2020, Manasi Navare wrote:
> >> > This patch adds defines for the detailed monitor
> >> > range flags as per the EDID specification.
> >> >
> >> > Suggested-by: Ville Syrjälä
> >> > Cc: Ville Syrjälä
> >> > Cc: Harry Wentland
> >> > Cc: Clinton A Taylor
> >> > Cc: Kazlauskas Nicholas
> >> > Signed-off-by: Manasi Navare
> >> > ---
> >> > include/drm/drm_edid.h | 5 +
> >> > 1 file changed, 5 insertions(+)
> >> >
> >> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> >> > index f0b03d401c27..f89c97623845 100644
> >> > --- a/include/drm/drm_edid.h
> >> > +++ b/include/drm/drm_edid.h
> >> > @@ -91,6 +91,11 @@ struct detailed_data_string {
> >> > u8 str[13];
> >> > } __attribute__((packed));
> >> >
> >> > +#define EDID_DEFAULT_GTF_SUPPORT_FLAG 0x00
> >> > +#define EDID_RANGE_LIMITS_ONLY_FLAG 0x01
> >> > +#define EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02
> >> > +#define EDID_CVT_SUPPORT_FLAG 0x04
> >>
> >> Bikeshed for consideration:
> >>
> >> drm_edid.h has some macros with DRM_EDID_ prefix, some with EDID_
> >> prefix, and then some with no prefix at all really. Should we start
> >> consolidating on something when we add more?
> >>
> >
> > Yes Jani I did notice the same thing and didnt know which convention
> > to continue to follow but I noticed that majority of the defines were
> > just EDID_ so just used that for these new defines.
>
> Ah, look again, DRM_EDID_ trumps EDID_ 51 to 15.
>
> > Is there a particular way you wish to consolidate this and use a specific
> > convention for #defines?
> >
> > I can atleast change these new defines based on a preferred convention and
> > then
> > separate patches to change the rest in .h and corresponding usages in .c
> > files.
>
> I'd suggest DRM_EDID_ for new ones, perhaps eventually rename old ones.
Okay cool, I will rename this to be DRM_EDID_ and then work on renaming others
later
Thanks for pointing this out.
Regards
Manasi
>
> BR,
> Jani.
>
>
> >
> > Regards
> > Manasi
> >
> >> BR,
> >> Jani.
> >>
> >>
> >> > +
> >> > struct detailed_data_monitor_range {
> >> > u8 min_vfreq;
> >> > u8 max_vfreq;
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
>
> --
> 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] ✓ Fi.CI.IGT: success for drm: Mark up racy check of drm_gem_object.handle_count
== Series Details == Series: drm: Mark up racy check of drm_gem_object.handle_count URL : https://patchwork.freedesktop.org/series/74450/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16880_full Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16880/index.html Changes --- No changes found Participating hosts (10 -> 8) -- Missing(2): pig-skl-6260u pig-glk-j5005 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8097 -> Patchwork_16880 * Piglit: piglit_4509 -> None CI-20190529: 20190529 CI_DRM_8097: 2e46e269a2843c5d0b6c72bfb7fa9d9913c15415 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5499: 2e23cf6f63fc6ba1d9543f8327698d6f21813cec @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16880: c782f13d5ca005769575d4fc7985995da66a0f6c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16880/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] Cleanup drm_dp_mst_topology_cbs hooks
On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote: > drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical > amongst every driver and don't do anything other than calling > drm_connector_register(). > drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical > amongst every driver and don't do anything other than cleaning up the > connector((drm_connector_unregister()/drm_connector_put())) except for > amdgpu_dm driver where some amdgpu_dm specific code in there. Yeah that amdgpu destruction code kinda stinks a little bit :\. I think we can just drop some of it and move the rest into their connector destruction callbacks. For the whole series: Reviewed-by: Lyude Paul I'm going to go ahead and let the maintainers know I'm going to push this (since there's some minor changes here outside of drm-misc), and push this to drm-misc-next. Then I'll go and write some patches to remove the leftover amd bits and drop the callback for good (I'll cc it to you as well). > > This series aims to cleaup these drm_dp_mst_topology_mgr_cbs hooks. > > Pankaj Bharadiya (5): > drm: Register connector instead of calling register_connector callback > drm: Remove dp mst register connector callbacks > drm/dp_mst: Remove register_connector callback > drm: Add drm_dp_destroy_connector helper and use it > drm: Remove drm dp mst destroy_connector callbacks > > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 -- > drivers/gpu/drm/drm_dp_mst_topology.c | 18 +++--- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 > drivers/gpu/drm/nouveau/dispnv50/disp.c | 19 --- > drivers/gpu/drm/radeon/radeon_dp_mst.c| 17 - > include/drm/drm_dp_mst_helper.h | 1 - > 6 files changed, 15 insertions(+), 62 deletions(-) > -- Cheers, Lyude Paul (she/her) Associate Software Engineer at Red Hat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/9] drm/i915: Gamma cleanups
On Fri, Mar 06, 2020 at 09:10:56PM +0530, Sharma, Swati2 wrote:
>
>
> On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Remainder of my earlier gamma cleanups, rebased due to
> > hw vs. uapi split and intel_de_{read,write}().
>
> I didn't get patch#8. Everything looks good to me.
> There is BAT failure https://patchwork.freedesktop.org/series/69136/
> Please check that.
>
> Reviewed-by: Swati Sharma
Series pushed to dinq. Thanks for the review.
> >
> > Ville Syrjälä (9):
> >drm/i915: Polish CHV CGM CSC loading
> >drm/i915: Clean up i9xx_load_luts_internal()
> >drm/i915: Split i9xx_read_lut_8() to gmch vs. ilk variants
> >drm/i915: s/blob_data/lut/
> >drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/
> >drm/i915: Clean up integer types in color code
> >drm/i915: Refactor LUT read functions
> >drm/i915: Fix readout of PIPEGCMAX
> >drm/i915: Pass the crtc to the low level read_lut() funcs
> >
> > drivers/gpu/drm/i915/display/intel_color.c | 407 -
> > drivers/gpu/drm/i915/i915_reg.h| 1 -
> > 2 files changed, 225 insertions(+), 183 deletions(-)
> >
>
> --
> ~Swati Sharma
--
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 7/7] drm/i915/perf: add flushing ioctl
On Wed, Mar 04, 2020 at 09:56:28PM -0800, Dixit, Ashutosh wrote:
On Wed, 04 Mar 2020 00:52:34 -0800, Lionel Landwerlin wrote:
On 04/03/2020 07:48, Dixit, Ashutosh wrote:
> On Tue, 03 Mar 2020 14:19:05 -0800, Umesh Nerlige Ramappa wrote:
>> From: Lionel Landwerlin
>>
>> With the currently available parameters for the i915-perf stream,
>> there are still situations that are not well covered :
>>
>> If an application opens the stream with polling disable or at very low
>> frequency and OA interrupt enabled, no data will be available even
>> though somewhere between nothing and half of the OA buffer worth of
>> data might have landed in memory.
>>
>> To solve this issue we have a new flush ioctl on the perf stream that
>> forces the i915-perf driver to look at the state of the buffer when
>> called and makes any data available through both poll() & read() type
>> syscalls.
>>
>> v2: Version the ioctl (Joonas)
>> v3: Rebase (Umesh)
>>
>> Signed-off-by: Lionel Landwerlin
>> Signed-off-by: Umesh Nerlige Ramappa
> [snip]
>
>> +/**
>> + * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
>> + * @stream: An enabled i915 perf stream
>> + *
>> + * The intention is to flush all the data available for reading from the OA
>> + * buffer
>> + */
>> +static void i915_perf_flush_data(struct i915_perf_stream *stream)
>> +{
>> + stream->pollin = oa_buffer_check(stream, true);
>> +}
> Since this function doesn't actually wake up any thread (which anyway can
> be done by sending a signal to the blocked thread), is the only purpose of
> this function to update OA buffer head/tail? But in that it is not clear
> why a separate ioctl should be created for this, can't the read() call
> itself call oa_buffer_check() to update the OA buffer head/tail?
>
> Again just trying to minimize uapi changes if possible.
Most applications will call read() after being notified by poll()/select()
that some data is available.
Correct this is the standard non blocking read behavior.
Changing that behavior will break some of the existing perf tests .
I am not suggesting changing that (that standard non blocking read
behavior).
If any data is available, this new ioctl will wake up existing waiters on
poll()/select().
The issue is we are not calling wake_up() in the above function to wake up
any blocked waiters. The ioctl will just update the OA buffer head/tail so
that (a) a subsequent blocking read will not block, or (b) a subsequent non
blocking read will return valid data (not -EAGAIN), or (c) a poll/select
will not block but return immediately saying data is available.
That is why it seems to me the ioctl is not required, updating the OA
buffer head/tail can be done as part of the read() (and the poll/select)
calls themselves.
We will investigate if this can be done and update the patches in the next
revision accordingly. Thanks!
In this case, where we are trying to determine if there is any data in
the oa buffer before the next interrupt has fired, user could call poll
with a reasonable timeout to determine if data is available or not.
That would eliminate the need for the flush ioctl. Thoughts?
Thanks,
Umesh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Gamma cleanups (rev4)
== Series Details == Series: drm/i915: Gamma cleanups (rev4) URL : https://patchwork.freedesktop.org/series/69136/ State : success == Summary == CI Bug Log - changes from CI_DRM_8087_full -> Patchwork_16866_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_16866_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16866_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_16866_full: ### IGT changes ### Warnings * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-kbl: [INCOMPLETE][1] ([fdo#103665]) -> [INCOMPLETE][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html Known issues Here are the changes found in Patchwork_16866_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-kbl: [PASS][3] -> [INCOMPLETE][4] ([i915#1402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-kbl1/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-kbl6/igt@gem_ctx_persiste...@close-replace-race.html - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb6/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb8/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +23 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb8/igt@gem_exec_sched...@pi-userfault-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb2/igt@gem_exec_sched...@pi-userfault-bsd.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb3/igt@gem_exec_sched...@preempt-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb4/igt@gem_exec_sched...@preempt-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-kbl3/igt@gem_exec_susp...@basic-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-kbl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-hsw: [PASS][17] -> [INCOMPLETE][18] ([i915#61]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-hsw6/igt@gem_exec_whis...@basic-contexts-forked.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-hsw7/igt@gem_exec_whis...@basic-contexts-forked.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_atomic_transition@2x-modeset-transitions-fencing: - shard-hsw: [PASS][21] -> [DMESG-FAIL][22] ([i915#44]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-hsw8/igt@kms_atomic_transit...@2x-modeset-transitions-fencing.html [22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Mark up intel_rps.active for racy reads
== Series Details == Series: drm/i915/gt: Mark up intel_rps.active for racy reads URL : https://patchwork.freedesktop.org/series/74448/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16879_full Summary --- **SUCCESS** No regressions found. Changes --- No changes found Participating hosts (10 -> 8) -- Missing(2): pig-skl-6260u pig-glk-j5005 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8097 -> Patchwork_16879 CI-20190529: 20190529 CI_DRM_8097: 2e46e269a2843c5d0b6c72bfb7fa9d9913c15415 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5499: 2e23cf6f63fc6ba1d9543f8327698d6f21813cec @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16879: e3fe3d282bea9e1aff79c4bf0c0e2c513f94cbe6 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16879/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Defend against concurrent updates to execlists->active
== Series Details == Series: drm/i915/gt: Defend against concurrent updates to execlists->active URL : https://patchwork.freedesktop.org/series/74447/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16878_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16878_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +12 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-iclb6/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb6/igt@gem_exec_sched...@pi-common-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb5/igt@gem_exec_sched...@wide-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#644]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-apl3/igt@gem_pp...@flink-and-close-vma-leak.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-apl3/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_userptr_blits@sync-unmap-after-close: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#111870] / [i915#211] / [i915#836]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-apl7/igt@gem_userptr_bl...@sync-unmap-after-close.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-apl3/igt@gem_userptr_bl...@sync-unmap-after-close.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#72]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-apl8/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-apl4/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_psr@psr2_sprite_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb2/igt@kms_psr@psr2_sprite_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-iclb3/igt@kms_psr@psr2_sprite_render.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109276]) +12 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb1/igt@prime_b...@hang-bsd2.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-iclb3/igt@prime_b...@hang-bsd2.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-kbl: [INCOMPLETE][21] ([i915#155]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-kbl3/igt@gem_...@in-flight-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-kbl7/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [SKIP][23] ([fdo#109276] / [i915#677]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16878/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [SKIP][25] ([fdo#112146]) ->
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Gamma cleanups (rev4)
== Series Details == Series: drm/i915: Gamma cleanups (rev4) URL : https://patchwork.freedesktop.org/series/69136/ State : success == Summary == CI Bug Log - changes from CI_DRM_8087_full -> Patchwork_16866_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_16866_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16866_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_16866_full: ### IGT changes ### Warnings * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-kbl: [INCOMPLETE][1] ([fdo#103665]) -> [INCOMPLETE][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html Known issues Here are the changes found in Patchwork_16866_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-kbl: [PASS][3] -> [INCOMPLETE][4] ([i915#1402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-kbl1/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-kbl6/igt@gem_ctx_persiste...@close-replace-race.html - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb6/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb8/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +23 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb8/igt@gem_exec_sched...@pi-userfault-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb2/igt@gem_exec_sched...@pi-userfault-bsd.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-iclb3/igt@gem_exec_sched...@preempt-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-iclb4/igt@gem_exec_sched...@preempt-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-kbl3/igt@gem_exec_susp...@basic-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-kbl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-hsw: [PASS][17] -> [INCOMPLETE][18] ([i915#61]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-hsw6/igt@gem_exec_whis...@basic-contexts-forked.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-hsw7/igt@gem_exec_whis...@basic-contexts-forked.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16866/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_atomic_transition@2x-modeset-transitions-fencing: - shard-hsw: [PASS][21] -> [DMESG-FAIL][22] ([i915#44]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8087/shard-hsw8/igt@kms_atomic_transit...@2x-modeset-transitions-fencing.html [22]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per client engine busyness (rev5)
== Series Details == Series: Per client engine busyness (rev5) URL : https://patchwork.freedesktop.org/series/70977/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915: Expose list of clients in sysfs Okay! Commit: drm/i915: Update client name on context create +drivers/gpu/drm/i915/i915_drm_client.c:102:23:expected struct pid *pid +drivers/gpu/drm/i915/i915_drm_client.c:102:23:got struct pid [noderef] *pid +drivers/gpu/drm/i915/i915_drm_client.c:102:23: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/i915_drm_client.c:211:17: error: incompatible types in comparison expression (different address spaces) Commit: drm/i915: Make GEM contexts track DRM clients Okay! Commit: drm/i915: Use explicit flag to mark unreachable intel_context +drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2551:24: error: incompatible types in comparison expression (different address spaces) Commit: drm/i915: Track runtime spent in unreachable intel_contexts Okay! Commit: drm/i915: Track runtime spent in closed GEM contexts Okay! Commit: drm/i915: Track all user contexts per client Okay! Commit: drm/i915: Expose per-engine client busyness Okay! Commit: drm/i915: Track per-context engine busyness Okay! Commit: drm/i915: Carry over past software tracked context runtime Okay! Commit: drm/i915: Prefer software tracked context busyness Okay! Commit: compare runtimes Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per client engine busyness (rev5)
== Series Details ==
Series: Per client engine busyness (rev5)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a60fd0a6e3d1 drm/i915: Expose list of clients in sysfs
-:68: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#68:
new file mode 100644
-:73: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#73: FILE: drivers/gpu/drm/i915/i915_drm_client.c:1:
+/*
-:74: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#74: FILE: drivers/gpu/drm/i915/i915_drm_client.c:2:
+ * SPDX-License-Identifier: MIT
-:234: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#234: FILE: drivers/gpu/drm/i915/i915_drm_client.h:1:
+/*
-:235: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#235: FILE: drivers/gpu/drm/i915/i915_drm_client.h:2:
+ * SPDX-License-Identifier: MIT
-:252: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#252: FILE: drivers/gpu/drm/i915/i915_drm_client.h:19:
+ struct mutex lock;
total: 0 errors, 5 warnings, 1 checks, 348 lines checked
c517889b70f2 drm/i915: Update client name on context create
-:174: ERROR:OPEN_BRACE: open brace '{' following struct go on the same line
#174: FILE: drivers/gpu/drm/i915/i915_drm_client.c:174:
+struct client_update_free
+{
-:216: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#216: FILE: drivers/gpu/drm/i915/i915_drm_client.c:216:
+ if (!name) {
+ drm_notice(>drm,
-:258: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#258: FILE: drivers/gpu/drm/i915/i915_drm_client.h:32:
+ struct mutex update_lock;
total: 1 errors, 1 warnings, 1 checks, 219 lines checked
3867321c33f3 drm/i915: Make GEM contexts track DRM clients
eb5a71b451e7 drm/i915: Use explicit flag to mark unreachable intel_context
-:20: WARNING:MEMORY_BARRIER: memory barrier without comment
#20: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:571:
+ smp_store_mb(ce->closed, true);
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
5d9fea699f4f drm/i915: Track runtime spent in unreachable intel_contexts
555e43ccead3 drm/i915: Track runtime spent in closed GEM contexts
b1460e0c42ea drm/i915: Track all user contexts per client
-:89: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#89: FILE: drivers/gpu/drm/i915/i915_drm_client.h:43:
+ spinlock_t ctx_lock;
total: 0 errors, 0 warnings, 1 checks, 59 lines checked
23836735df75 drm/i915: Expose per-engine client busyness
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
Render/3D/0 63.73% |███ | 3% 0%
-:114: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should
probably be static const char * const
#114: FILE: drivers/gpu/drm/i915/i915_drm_client.c:94:
+static const char *uabi_class_names[] = {
total: 0 errors, 2 warnings, 0 checks, 150 lines checked
2bd7560f3275 drm/i915: Track per-context engine busyness
20e5180a4335 drm/i915: Carry over past software tracked context runtime
8c5b89e058b5 drm/i915: Prefer software tracked context busyness
c090e12915a4 compare runtimes
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:31: WARNING:PRINTK_WITHOUT_KERN_LEVEL: printk() should include KERN_
facility level
#31: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:279:
+ printk("%p class%u %llums vs %llums\n",
total: 0 errors, 2 warnings, 0 checks, 25 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t 1/1] intel-gpu-top: Support for client stats
From: Tvrtko Ursulin
Adds support for per-client engine busyness stats i915 exports in sysfs
and produces output like the below:
==
intel-gpu-top - 935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s
IMC reads: 1401 MiB/s
IMC writes:4 MiB/s
ENGINE BUSY MI_SEMA MI_WAIT
Render/3D/0 63.73% |███ | 3% 0%
Blitter/09.53% |██▊ | 6% 0%
Video/0 39.32% |███▊ | 16% 0%
Video/1 15.62% |▋ | 0% 0%
VideoEnhance/00.00% | | 0% 0%
PIDNAME RCS BCS VCS VECS
4084gem_wsim |█▌ ||█ || || |
4086gem_wsim |█▌ || ||███|| |
==
Apart from the existing physical engine utilization it now also shows
utilization per client and per engine class.
v2:
* Version to match removal of global enable_stats toggle.
* Plus various fixes.
v3:
* Support brief backward jumps in client stats.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 539 +-
1 file changed, 528 insertions(+), 11 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 8197482dd6c2..3f8e14f4e8a9 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -659,23 +659,347 @@ static void pmu_sample(struct engines *engines)
}
}
+enum client_status {
+ FREE = 0, /* mbz */
+ ALIVE,
+ PROBE
+};
+
+struct clients;
+
+struct client {
+ struct clients *clients;
+
+ enum client_status status;
+ unsigned int id;
+ unsigned int pid;
+ char name[128];
+ unsigned int samples;
+ unsigned long total;
+ struct engines *engines;
+ unsigned long *val;
+ uint64_t *last;
+};
+
+struct engine_class {
+ unsigned int class;
+ const char *name;
+ unsigned int num_engines;
+};
+
+struct clients {
+ unsigned int num_classes;
+ struct engine_class *class;
+
+ unsigned int num_clients;
+ struct client *client;
+};
+
+#define for_each_client(clients, c, tmp) \
+ for ((tmp) = (clients)->num_clients, c = (clients)->client; \
+(tmp > 0); (tmp)--, (c)++)
+
+static struct clients *init_clients(void)
+{
+ struct clients *clients = malloc(sizeof(*clients));
+
+ return memset(clients, 0, sizeof(*clients));
+}
+
+#define SYSFS_CLIENTS "/sys/class/drm/card0/clients"
+
+static uint64_t read_client_busy(unsigned int id, unsigned int class)
+{
+ char buf[256];
+ ssize_t ret;
+
+ ret = snprintf(buf, sizeof(buf),
+ SYSFS_CLIENTS "/%u/busy/%u",
+ id, class);
+ assert(ret > 0 && ret < sizeof(buf));
+ if (ret <= 0 || ret == sizeof(buf))
+ return 0;
+
+ return filename_to_u64(buf, 10);
+}
+
+static struct client *
+find_client(struct clients *clients, enum client_status status, unsigned int
id)
+{
+ struct client *c;
+ int tmp;
+
+ for_each_client(clients, c, tmp) {
+ if ((status == FREE && c->status == FREE) ||
+ (status == c->status && c->id == id))
+ return c;
+ }
+
+ return NULL;
+}
+
+static void update_client(struct client *c, unsigned int pid, char *name)
+{
+ uint64_t val[c->clients->num_classes];
+ unsigned int i;
+
+ if (c->pid != pid)
+ c->pid = pid;
+
+ if (strcmp(c->name, name))
+ strncpy(c->name, name, sizeof(c->name) - 1);
+
+ for (i = 0; i < c->clients->num_classes; i++)
+ val[i] = read_client_busy(c->id, c->clients->class[i].class);
+
+ c->total = 0;
+
+ for (i = 0; i < c->clients->num_classes; i++) {
+ if (val[i] < c->last[i])
+ continue; /* It will catch up soon. */
+
+ c->val[i] = val[i] - c->last[i];
+ c->total += c->val[i];
+ c->last[i] = val[i];
+ }
+
+ c->samples++;
+ c->status = ALIVE;
+}
+
+static int class_cmp(const void *_a, const void *_b)
+{
+ const struct engine_class *a = _a;
+ const struct engine_class *b = _b;
+
+ return a->class - b->class;
+}
+
+static void scan_classes(struct clients *clients, unsigned int id)
+{
+ struct engine_class *classes;
+ unsigned int num, i;
+ struct dirent *dent;
+ char buf[256];
+ int ret;
+ DIR *d;
+
+ ret = snprintf(buf, sizeof(buf), SYSFS_CLIENTS "/%u/busy", id);
+ assert(ret > 0 && ret < sizeof(buf));
+ if (ret <= 0 || ret
[Intel-gfx] [RFC i-g-t 0/1] Per client intel_gpu_top
From: Tvrtko Ursulin Just a demo to follow the the i915 feature. Tvrtko Ursulin (1): intel-gpu-top: Support for client stats tools/intel_gpu_top.c | 539 +- 1 file changed, 528 insertions(+), 11 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 05/12] drm/i915: Track runtime spent in unreachable intel_contexts
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index abc3a3e2fcf1..5f6861a36655 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -257,7 +257,19 @@ static void free_engines_rcu(struct rcu_head *rcu)
{
struct i915_gem_engines *engines =
container_of(rcu, struct i915_gem_engines, rcu);
+ struct i915_gem_context *ctx = engines->ctx;
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ /* Transfer accumulated runtime to the parent GEM context. */
+ for_each_gem_engine(ce, engines, it) {
+ unsigned int class = ce->engine->uabi_class;
+ GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
+ atomic64_add(ce->runtime.total, >past_runtime[class]);
+ }
+
+ i915_gem_context_put(ctx);
i915_sw_fence_fini(>fence);
free_engines(engines);
}
@@ -540,7 +552,6 @@ static int engines_notify(struct i915_sw_fence *fence,
list_del(>link);
spin_unlock_irqrestore(>stale.lock, flags);
}
- i915_gem_context_put(engines->ctx);
break;
case FENCE_FREE:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index b0e03380c690..f0d7441aafc8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -177,6 +177,11 @@ struct i915_gem_context {
spinlock_t lock;
struct list_head engines;
} stale;
+
+ /**
+* @past_runtime: Accumulation of freed intel_context pphwsp runtimes.
+*/
+ atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
};
#endif /* __I915_GEM_CONTEXT_TYPES_H__ */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 00/12] Per client engine busyness
From: Tvrtko Ursulin Another re-spin of the per-client engine busyness series. Highlights from this version: * Different way of tracking runtime of exited/unreachable context. This time round I accumulate those per context/client and engine class, but active contexts are kept in a list and tallied on sysfs reads. * I had to do a small tweak in the engine release code since I needed the GEM context for a bit longer. (So I can accumulate the intel_context runtime into it as it is getting freed, because context complete can be late.) * PPHWSP method is back and even comes first in the series this time. It still can't show the currently running workloads but the software tracking method suffers from the CSB processing delay with high frequency and very short batches. Internally we track time spent on engines for each struct intel_context. This can serve as a building block for several features from the want list: smarter scheduler decisions, getrusage(2)-like per-GEM-context functionality wanted by some customers, cgroups controller, dynamic SSEU tuning,... Externally, in sysfs, we expose time spent on GPU per client and per engine class. Sysfs interface enables us to implement a "top-like" tool for GPU tasks. Or with a "screenshot": intel-gpu-top - 906/ 955 MHz;0% RC6; 5.30 Watts; 933 irqs/s IMC reads: 4414 MiB/s IMC writes: 3805 MiB/s ENGINE BUSY MI_SEMA MI_WAIT Render/3D/0 93.46% |▋ | 0% 0% Blitter/00.00% | | 0% 0% Video/00.00% | | 0% 0% VideoEnhance/00.00% | | 0% 0% PIDNAME Render/3D BlitterVideo VideoEnhance 2733 neverball |██▌ ||||||| 2047Xorg |███▊||||||| 2737glxgears |█▍ ||||||| 2128 xfwm4 |||||||| 2047Xorg |||||||| Implementation wise we add a a bunch of files in sysfs like: # cd /sys/class/drm/card0/clients/ # tree . ├── 7 │ ├── busy │ │ ├── 0 │ │ ├── 1 │ │ ├── 2 │ │ └── 3 │ ├── name │ └── pid ├── 8 │ ├── busy │ │ ├── 0 │ │ ├── 1 │ │ ├── 2 │ │ └── 3 │ ├── name │ └── pid └── 9 ├── busy │ ├── 0 │ ├── 1 │ ├── 2 │ └── 3 ├── name └── pid Files in 'busy' directories are numbered using the engine class ABI values and they contain accumulated nanoseconds each client spent on engines of a respective class. It is stil a RFC since it misses dedicated test cases to ensure things really work as advertised. Tvrtko Ursulin (12): drm/i915: Expose list of clients in sysfs drm/i915: Update client name on context create drm/i915: Make GEM contexts track DRM clients drm/i915: Use explicit flag to mark unreachable intel_context drm/i915: Track runtime spent in unreachable intel_contexts drm/i915: Track runtime spent in closed GEM contexts drm/i915: Track all user contexts per client drm/i915: Expose per-engine client busyness drm/i915: Track per-context engine busyness drm/i915: Carry over past software tracked context runtime drm/i915: Prefer software tracked context busyness compare runtimes drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 83 +++- .../gpu/drm/i915/gem/i915_gem_context_types.h | 26 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +- drivers/gpu/drm/i915/gt/intel_context.c | 20 + drivers/gpu/drm/i915/gt/intel_context.h | 13 + drivers/gpu/drm/i915/gt/intel_context_types.h | 10 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 15 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +- drivers/gpu/drm/i915/i915_debugfs.c | 31 +- drivers/gpu/drm/i915/i915_drm_client.c| 413 ++ drivers/gpu/drm/i915/i915_drm_client.h| 100 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 37 +- drivers/gpu/drm/i915/i915_gpu_error.c | 21 +- drivers/gpu/drm/i915/i915_sysfs.c | 8 + 16 files changed, 767 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode
[Intel-gfx] [RFC 12/12] compare runtimes
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index abf8c777041d..1c41079dcf17 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -264,13 +264,22 @@ static void free_engines_rcu(struct rcu_head *rcu)
/* Transfer accumulated runtime to the parent GEM context. */
for_each_gem_engine(ce, engines, it) {
unsigned int class = ce->engine->uabi_class;
+ u64 runtime[2];
GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
- atomic64_add(ce->runtime.total, >past_runtime[class]);
+ runtime[0] = ce->runtime.total;
+ atomic64_add(runtime[0], >past_runtime[class]);
+ runtime[0] *= RUNTIME_INFO(ctx->i915)->cs_timestamp_period_ns;
GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_sw_runtime));
- atomic64_add(ktime_to_ns(intel_context_get_busy_time(ce)),
->past_sw_runtime[class]);
+ runtime[1] = ktime_to_ns(intel_context_get_busy_time(ce));
+ atomic64_add(runtime[1], >past_sw_runtime[class]);
+
+ if (runtime[0] || runtime[1])
+ printk("%p class%u %llums vs %llums\n",
+ ce, class,
+ runtime[0] / 100,
+ runtime[1] / 100);
}
i915_gem_context_put(ctx);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 08/12] drm/i915: Expose per-engine client busyness
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing on the GPU.
This enables userspace to create a top-like tool for GPU utilization:
==
intel-gpu-top - 935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s
IMC reads: 1401 MiB/s
IMC writes:4 MiB/s
ENGINE BUSY MI_SEMA MI_WAIT
Render/3D/0 63.73% |███ | 3% 0%
Blitter/09.53% |██▊ | 6% 0%
Video/0 39.32% |███▊ | 16% 0%
Video/1 15.62% |▋ | 0% 0%
VideoEnhance/00.00% | | 0% 0%
PIDNAME RCS BCS VCS VECS
4084gem_wsim |█▌ ||█ || || |
4086gem_wsim |█▌ || ||███|| |
==
v2: Use intel_context_engine_get_busy_time.
v3: New directory structure.
v4: Rebase.
v5: sysfs_attr_init.
v6: Small tidy in i915_gem_add_client.
v7: Rebase to be engine class based.
v8:
* Always enable stats.
* Walk all client contexts.
v9:
* Skip unsupported engine classes. (Chris)
* Use scheduler caps. (Chris)
v10:
* Use pphwsp runtime only.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drm_client.c | 90 +-
drivers/gpu/drm/i915/i915_drm_client.h | 11
2 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index c9a510c6c6d4..6df5a21f5d4e 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -10,8 +10,13 @@
#include
+#include
+
#include "i915_drv.h"
#include "i915_drm_client.h"
+#include "gem/i915_gem_context.h"
+#include "gt/intel_engine_user.h"
+#include "i915_drv.h"
#include "i915_gem.h"
#include "i915_utils.h"
@@ -47,13 +52,61 @@ show_client_pid(struct device *kdev, struct
device_attribute *attr, char *buf)
return ret;
}
+static u64
+pphwsp_busy_add(struct i915_gem_context *ctx, unsigned int class)
+{
+ struct i915_gem_engines *engines = rcu_dereference(ctx->engines);
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ u64 total = 0;
+
+ for_each_gem_engine(ce, engines, it) {
+ if (ce->engine->uabi_class == class)
+ total += ce->runtime.total;
+ }
+
+ return total;
+}
+
+static ssize_t
+show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_engine_busy_attribute *i915_attr =
+ container_of(attr, typeof(*i915_attr), attr);
+ unsigned int class = i915_attr->engine_class;
+ struct i915_drm_client *client = i915_attr->client;
+ u64 total = atomic64_read(>past_runtime[class]);
+ struct list_head *list = >ctx_list;
+ struct i915_gem_context *ctx;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ctx, list, client_link) {
+ total += atomic64_read(>past_runtime[class]);
+ total += pphwsp_busy_add(ctx, class);
+ }
+ rcu_read_unlock();
+
+ total *= RUNTIME_INFO(i915_attr->i915)->cs_timestamp_period_ns;
+
+ return snprintf(buf, PAGE_SIZE, "%llu\n", total);
+}
+
+static const char *uabi_class_names[] = {
+ [I915_ENGINE_CLASS_RENDER] = "0",
+ [I915_ENGINE_CLASS_COPY] = "1",
+ [I915_ENGINE_CLASS_VIDEO] = "2",
+ [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "3",
+};
+
static int
__i915_drm_client_register(struct i915_drm_client *client,
struct task_struct *task)
{
struct i915_drm_clients *clients = client->clients;
+ struct drm_i915_private *i915 =
+ container_of(clients, typeof(*i915), clients);
struct device_attribute *attr;
- int ret = -ENOMEM;
+ int i, ret = -ENOMEM;
char idstr[32];
char *name;
@@ -92,8 +145,42 @@ __i915_drm_client_register(struct i915_drm_client *client,
if (ret)
goto err_attr;
+ if (HAS_LOGICAL_RING_CONTEXTS(i915)) {
+ client->busy_root =
+ kobject_create_and_add("busy", client->root);
+ if (!client->busy_root)
+ goto err_attr;
+
+ for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) {
+ struct i915_engine_busy_attribute *i915_attr =
+ >attr.busy[i];
+
+
[Intel-gfx] [RFC 11/12] drm/i915: Prefer software tracked context busyness
From: Tvrtko Ursulin
When available prefer context tracked context busyness because it provides
visibility into currently executing contexts as well.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drm_client.c | 83 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +
2 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 6df5a21f5d4e..c6b463650ba2 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -91,6 +91,46 @@ show_client_busy(struct device *kdev, struct
device_attribute *attr, char *buf)
return snprintf(buf, PAGE_SIZE, "%llu\n", total);
}
+static u64
+sw_busy_add(struct i915_gem_context *ctx, unsigned int class)
+{
+ struct i915_gem_engines *engines = rcu_dereference(ctx->engines);
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ ktime_t total = 0;
+
+ for_each_gem_engine(ce, engines, it) {
+ if (ce->engine->uabi_class == class)
+ total = ktime_add(total,
+ intel_context_get_busy_time(ce));
+ }
+
+ return ktime_to_ns(total);
+}
+
+static ssize_t
+show_client_sw_busy(struct device *kdev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct i915_engine_busy_attribute *i915_attr =
+ container_of(attr, typeof(*i915_attr), attr);
+ unsigned int class = i915_attr->engine_class;
+ struct i915_drm_client *client = i915_attr->client;
+ u64 total = atomic64_read(>past_sw_runtime[class]);
+ struct list_head *list = >ctx_list;
+ struct i915_gem_context *ctx;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ctx, list, client_link) {
+ total += atomic64_read(>past_sw_runtime[class]);
+ total += sw_busy_add(ctx, class);
+ }
+ rcu_read_unlock();
+
+ return snprintf(buf, PAGE_SIZE, "%llu\n", total);
+}
+
static const char *uabi_class_names[] = {
[I915_ENGINE_CLASS_RENDER] = "0",
[I915_ENGINE_CLASS_COPY] = "1",
@@ -146,11 +186,39 @@ __i915_drm_client_register(struct i915_drm_client *client,
goto err_attr;
if (HAS_LOGICAL_RING_CONTEXTS(i915)) {
+ struct intel_engine_cs *engine;
+ bool sw_stats = true;
+
client->busy_root =
kobject_create_and_add("busy", client->root);
if (!client->busy_root)
goto err_attr;
+ /* Enable busy stats on all engines. */
+ i = 0;
+ for_each_uabi_engine(engine, i915) {
+ ret = intel_enable_engine_stats(engine);
+ if (ret) {
+ int j;
+
+ /* Unwind if not available. */
+ j = 0;
+ for_each_uabi_engine(engine, i915) {
+ if (j++ == i)
+ break;
+
+ intel_disable_engine_stats(engine);
+ }
+
+ sw_stats = false;
+ dev_notice_once(i915->drm.dev,
+ "Engine busy stats not
available! (%d)",
+ ret);
+ break;
+ }
+ i++;
+ }
+
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) {
struct i915_engine_busy_attribute *i915_attr =
>attr.busy[i];
@@ -168,13 +236,17 @@ __i915_drm_client_register(struct i915_drm_client *client,
attr->attr.name = uabi_class_names[i];
attr->attr.mode = 0444;
- attr->show = show_client_busy;
+ attr->show = sw_stats ?
+show_client_sw_busy :
+show_client_busy;
ret = sysfs_create_file(client->busy_root,
(struct attribute *)attr);
if (ret)
goto err_busy;
}
+
+ client->sw_busy = sw_stats;
}
return 0;
@@ -200,6 +272,15 @@ __i915_drm_client_unregister(struct i915_drm_client
*client)
if (!client->root)
return; /* fbdev client or error during drm open */
+ if (client->busy_root && client->sw_busy) {
+ struct drm_i915_private *i915 =
+ container_of(client->clients, typeof(*i915), clients);
+ struct
[Intel-gfx] [RFC 10/12] drm/i915: Carry over past software tracked context runtime
From: Tvrtko Ursulin
Accumulate software tracked runtime from abandoned engines and destroyed
contexts (same as we previously did for pphwsp runtimes).
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
drivers/gpu/drm/i915/i915_drm_client.h| 5 +
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d3887712f8c3..abf8c777041d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -267,6 +267,10 @@ static void free_engines_rcu(struct rcu_head *rcu)
GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
atomic64_add(ce->runtime.total, >past_runtime[class]);
+
+ GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_sw_runtime));
+ atomic64_add(ktime_to_ns(intel_context_get_busy_time(ce)),
+>past_sw_runtime[class]);
}
i915_gem_context_put(ctx);
@@ -326,9 +330,14 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
/* Transfer accumulated runtime to the parent drm client. */
BUILD_BUG_ON(ARRAY_SIZE(client->past_runtime) !=
ARRAY_SIZE(ctx->past_runtime));
- for (i = 0; i < ARRAY_SIZE(client->past_runtime); i++)
+ BUILD_BUG_ON(ARRAY_SIZE(client->past_sw_runtime) !=
+ARRAY_SIZE(ctx->past_sw_runtime));
+ for (i = 0; i < ARRAY_SIZE(client->past_runtime); i++) {
atomic64_add(atomic64_read(>past_runtime[i]),
>past_runtime[i]);
+ atomic64_add(atomic64_read(>past_sw_runtime[i]),
+>past_sw_runtime[i]);
+ }
i915_drm_client_put(client);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 255fcc469d9b..fac11b208ea9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -185,6 +185,11 @@ struct i915_gem_context {
* @past_runtime: Accumulation of freed intel_context pphwsp runtimes.
*/
atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
+
+ /**
+* @past_sw_runtime: Accumulation of freed intel_context runtimes.
+*/
+ atomic64_t past_sw_runtime[MAX_ENGINE_CLASS + 1];
};
#endif /* __I915_GEM_CONTEXT_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index da83259170e7..aa1e446d0376 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -66,6 +66,11 @@ struct i915_drm_client {
* @past_runtime: Accumulation of pphwsp runtimes from closed contexts.
*/
atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
+
+ /**
+* @past_sw_runtime: Accumulation of runtimes from closed contexts.
+*/
+ atomic64_t past_sw_runtime[MAX_ENGINE_CLASS + 1];
};
static inline struct i915_drm_client *
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 06/12] drm/i915: Track runtime spent in closed GEM contexts
From: Tvrtko Ursulin
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +++-
drivers/gpu/drm/i915/i915_drm_client.h | 7 +++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5f6861a36655..d99143dca0ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -316,8 +316,18 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
- if (client)
+ if (client) {
+ unsigned int i;
+
+ /* Transfer accumulated runtime to the parent drm client. */
+ BUILD_BUG_ON(ARRAY_SIZE(client->past_runtime) !=
+ARRAY_SIZE(ctx->past_runtime));
+ for (i = 0; i < ARRAY_SIZE(client->past_runtime); i++)
+ atomic64_add(atomic64_read(>past_runtime[i]),
+>past_runtime[i]);
+
i915_drm_client_put(client);
+ }
spin_lock(>i915->gem.contexts.lock);
list_del(>link);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 7825df32798d..10752107e8c7 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -16,6 +16,8 @@
#include
#include
+#include "gt/intel_engine_types.h"
+
struct i915_drm_clients {
struct mutex lock;
struct xarray xarray;
@@ -43,6 +45,11 @@ struct i915_drm_client {
struct device_attribute pid;
struct device_attribute name;
} attr;
+
+ /**
+* @past_runtime: Accumulation of pphwsp runtimes from closed contexts.
+*/
+ atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
};
static inline struct i915_drm_client *
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 03/12] drm/i915: Make GEM contexts track DRM clients
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 23 +++---
.../gpu/drm/i915/gem/i915_gem_context_types.h | 13 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 31 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 21 +++--
4 files changed, 48 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 2c3fd9748d39..0f4150c8d7fe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -300,8 +300,13 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
static void i915_gem_context_free(struct i915_gem_context *ctx)
{
+ struct i915_drm_client *client = ctx->client;
+
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+ if (client)
+ i915_drm_client_put(client);
+
spin_lock(>i915->gem.contexts.lock);
list_del(>link);
spin_unlock(>i915->gem.contexts.lock);
@@ -311,7 +316,6 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
if (ctx->timeline)
intel_timeline_put(ctx->timeline);
- put_pid(ctx->pid);
mutex_destroy(>mutex);
kfree_rcu(ctx, rcu);
@@ -899,6 +903,7 @@ static int gem_context_register(struct i915_gem_context
*ctx,
struct drm_i915_file_private *fpriv,
u32 *id)
{
+ struct i915_drm_client *client;
struct i915_address_space *vm;
int ret;
@@ -910,15 +915,25 @@ static int gem_context_register(struct i915_gem_context
*ctx,
WRITE_ONCE(vm->file, fpriv); /* XXX */
mutex_unlock(>mutex);
- ctx->pid = get_task_pid(current, PIDTYPE_PID);
+ client = i915_drm_client_get(fpriv->client);
+
+ rcu_read_lock();
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
-current->comm, pid_nr(ctx->pid));
+rcu_dereference(client->name),
+pid_nr(rcu_dereference(client->pid)));
+ rcu_read_unlock();
/* And finally expose ourselves to userspace via the idr */
ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
if (ret)
- put_pid(fetch_and_zero(>pid));
+ goto err;
+
+ ctx->client = client;
+ return 0;
+
+err:
+ i915_drm_client_put(client);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..b0e03380c690 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -96,20 +96,13 @@ struct i915_gem_context {
*/
struct i915_address_space __rcu *vm;
- /**
-* @pid: process id of creator
-*
-* Note that who created the context may not be the principle user,
-* as the context may be shared across a local socket. However,
-* that should only affect the default context, all contexts created
-* explicitly by the client are expected to be isolated.
-*/
- struct pid *pid;
-
/** link: place with _i915_private.context_list */
struct list_head link;
struct llist_node free_link;
+ /** client: struct i915_drm_client */
+ struct i915_drm_client *client;
+
/**
* @ref: reference count
*
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8f2525e4ce0f..0655f1e7527d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -330,17 +330,17 @@ static void print_context_stats(struct seq_file *m,
.vm = rcu_access_pointer(ctx->vm),
};
struct drm_file *file = ctx->file_priv->file;
- struct task_struct *task;
char name[80];
rcu_read_lock();
+
idr_for_each(>object_idr, per_file_stats, );
- rcu_read_unlock();
- rcu_read_lock();
- task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
snprintf(name, sizeof(name), "%s",
-task ? task->comm : "");
+I915_SELFTEST_ONLY(!ctx->client) ?
+"[kernel]" :
+rcu_dereference(ctx->client->name));
+
rcu_read_unlock();
print_file_stats(m, name, stats);
@@ -1273,19 +1273,16 @@
[Intel-gfx] [RFC 02/12] drm/i915: Update client name on context create
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
patches, we also make these fields rcu protected. In this way asynchronous
code paths where both contexts which remain after the client exit, and
access to client name and pid as they are getting updated due context
creation running in parallel with name/pid queries.
v2:
* Do not leak the pid reference and borrow context idr_lock. (Chris)
v3:
* More avoiding leaks. (Chris)
v4:
* Move update completely to drm client. (Chris)
* Do not lose previous client data on failure to re-register and simplify
update to only touch what it needs.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +-
drivers/gpu/drm/i915/i915_drm_client.c | 110 +---
drivers/gpu/drm/i915/i915_drm_client.h | 10 +-
3 files changed, 113 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index cb6b6be48978..2c3fd9748d39 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -74,6 +74,7 @@
#include "gt/intel_engine_user.h"
#include "gt/intel_ring.h"
+#include "i915_drm_client.h"
#include "i915_gem_context.h"
#include "i915_globals.h"
#include "i915_trace.h"
@@ -2294,6 +2295,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
{
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_context_create_ext *args = data;
+ struct drm_i915_file_private *file_priv = file->driver_priv;
struct create_ext ext_data;
int ret;
u32 id;
@@ -2308,7 +2310,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ext_data.fpriv = file->driver_priv;
+ ext_data.fpriv = file_priv;
if (client_is_banned(ext_data.fpriv)) {
drm_dbg(>drm,
"client %s[%d] banned from creating ctx\n",
@@ -2316,6 +2318,10 @@ int i915_gem_context_create_ioctl(struct drm_device
*dev, void *data,
return -EIO;
}
+ ret = i915_drm_client_update(file_priv->client, current);
+ if (ret)
+ return ret;
+
ext_data.ctx = i915_gem_create_context(i915, args->flags);
if (IS_ERR(ext_data.ctx))
return PTR_ERR(ext_data.ctx);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index fbba9667aa7e..a3de02cc3e6b 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -8,6 +8,9 @@
#include
#include
+#include
+
+#include "i915_drv.h"
#include "i915_drm_client.h"
#include "i915_gem.h"
#include "i915_utils.h"
@@ -17,10 +20,15 @@ show_client_name(struct device *kdev, struct
device_attribute *attr, char *buf)
{
struct i915_drm_client *client =
container_of(attr, typeof(*client), attr.name);
+ int ret;
- return snprintf(buf, PAGE_SIZE,
- client->closed ? "<%s>" : "%s",
- client->name);
+ rcu_read_lock();
+ ret = snprintf(buf, PAGE_SIZE,
+ client->closed ? "<%s>" : "%s",
+ rcu_dereference(client->name));
+ rcu_read_unlock();
+
+ return ret;
}
static ssize_t
@@ -28,10 +36,15 @@ show_client_pid(struct device *kdev, struct
device_attribute *attr, char *buf)
{
struct i915_drm_client *client =
container_of(attr, typeof(*client), attr.pid);
+ int ret;
+
+ rcu_read_lock();
+ ret = snprintf(buf, PAGE_SIZE,
+ client->closed ? "<%u>" : "%u",
+ pid_nr(rcu_dereference(client->pid)));
+ rcu_read_unlock();
- return snprintf(buf, PAGE_SIZE,
- client->closed ? "<%u>" : "%u",
- pid_nr(client->pid));
+ return ret;
}
static int
@@ -42,12 +55,14 @@ __i915_drm_client_register(struct i915_drm_client *client,
struct device_attribute *attr;
int ret = -ENOMEM;
char idstr[32];
+ char *name;
- client->pid = get_task_pid(task, PIDTYPE_PID);
+ rcu_assign_pointer(client->pid, get_task_pid(task, PIDTYPE_PID));
- client->name = kstrdup(task->comm, GFP_KERNEL);
- if (!client->name)
+ name = kstrdup(task->comm, GFP_KERNEL);
+ if (!name)
goto err_name;
+ rcu_assign_pointer(client->name, name);
if (!clients->root)
return 0; /* intel_fbdev_init registers a client before sysfs */
@@ -82,7 +97,7 @@ __i915_drm_client_register(struct i915_drm_client
[Intel-gfx] [RFC 07/12] drm/i915: Track all user contexts per client
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++
drivers/gpu/drm/i915/i915_drm_client.c| 3 +++
drivers/gpu/drm/i915/i915_drm_client.h| 5 +
4 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d99143dca0ab..d3887712f8c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -319,6 +319,10 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
if (client) {
unsigned int i;
+ spin_lock(>ctx_lock);
+ list_del_rcu(>client_link);
+ spin_unlock(>ctx_lock);
+
/* Transfer accumulated runtime to the parent drm client. */
BUILD_BUG_ON(ARRAY_SIZE(client->past_runtime) !=
ARRAY_SIZE(ctx->past_runtime));
@@ -952,6 +956,10 @@ static int gem_context_register(struct i915_gem_context
*ctx,
ctx->client = client;
+ spin_lock(>ctx_lock);
+ list_add_tail_rcu(>client_link, >ctx_list);
+ spin_unlock(>ctx_lock);
+
return 0;
err:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index f0d7441aafc8..255fcc469d9b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -103,6 +103,9 @@ struct i915_gem_context {
/** client: struct i915_drm_client */
struct i915_drm_client *client;
+ /** link: _client.context_list */
+ struct list_head client_link;
+
/**
* @ref: reference count
*
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index a3de02cc3e6b..c9a510c6c6d4 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -128,6 +128,9 @@ i915_drm_client_add(struct i915_drm_clients *clients,
struct task_struct *task)
kref_init(>kref);
mutex_init(>update_lock);
+ spin_lock_init(>ctx_lock);
+ INIT_LIST_HEAD(>ctx_list);
+
client->clients = clients;
ret = mutex_lock_interruptible(>lock);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 10752107e8c7..0a9f2c0c12dd 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -10,10 +10,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include "gt/intel_engine_types.h"
@@ -38,6 +40,9 @@ struct i915_drm_client {
char __rcu *name;
bool closed;
+ spinlock_t ctx_lock;
+ struct list_head ctx_list;
+
struct i915_drm_clients *clients;
struct kobject *root;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 04/12] drm/i915: Use explicit flag to mark unreachable intel_context
From: Tvrtko Ursulin
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 0f4150c8d7fe..abc3a3e2fcf1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -568,7 +568,8 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
int err = 0;
/* serialises with execbuf */
- RCU_INIT_POINTER(ce->gem_context, NULL);
+ smp_store_mb(ce->closed, true);
+
if (!intel_context_pin_if_active(ce))
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 0893ce781a84..0302757396d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2547,8 +2547,8 @@ static void eb_request_add(struct i915_execbuffer *eb)
prev = __i915_request_commit(rq);
/* Check that the context wasn't destroyed before submission */
- if (likely(rcu_access_pointer(eb->context->gem_context))) {
- attr = eb->gem_context->sched;
+ if (likely(!READ_ONCE(eb->context->closed))) {
+ attr = rcu_dereference(eb->gem_context)->sched;
/*
* Boost actual workloads past semaphores!
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 11278343b9b5..c60490e756f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -50,6 +50,7 @@ struct intel_context {
struct i915_address_space *vm;
struct i915_gem_context __rcu *gem_context;
+ bool closed;
struct list_head signal_link;
struct list_head signals;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 01/12] drm/i915: Expose list of clients in sysfs
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For instance:
/sys/class/drm/card0/clients/3/name: Xorg
/sys/class/drm/card0/clients/3/pid: 5664
v2:
Chris Wilson:
* Enclose new members into dedicated structs.
* Protect against failed sysfs registration.
v3:
* sysfs_attr_init.
v4:
* Fix for internal clients.
v5:
* Use cyclic ida for client id. (Chris)
* Do not leak pid reference. (Chris)
* Tidy code with some locals.
v6:
* Use xa_alloc_cyclic to simplify locking. (Chris)
* No need to unregister individial sysfs files. (Chris)
* Rebase on top of fpriv kref.
* Track client closed status and reflect in sysfs.
v7:
* Make drm_client more standalone concept.
v8:
* Simplify sysfs show. (Chris)
* Always track name and pid.
v9:
* Fix cyclic id assignment.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drm_client.c | 155 +
drivers/gpu/drm/i915/i915_drm_client.h | 64 ++
drivers/gpu/drm/i915/i915_drv.h| 5 +
drivers/gpu/drm/i915/i915_gem.c| 37 --
drivers/gpu/drm/i915/i915_sysfs.c | 8 ++
6 files changed, 264 insertions(+), 8 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9f887a86e555..c6fc0f258ce3 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -36,7 +36,8 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
# core driver code
-i915-y += i915_drv.o \
+i915-y += i915_drm_client.o \
+ i915_drv.o \
i915_irq.o \
i915_getparam.o \
i915_params.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..fbba9667aa7e
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,155 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+static ssize_t
+show_client_name(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_drm_client *client =
+ container_of(attr, typeof(*client), attr.name);
+
+ return snprintf(buf, PAGE_SIZE,
+ client->closed ? "<%s>" : "%s",
+ client->name);
+}
+
+static ssize_t
+show_client_pid(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_drm_client *client =
+ container_of(attr, typeof(*client), attr.pid);
+
+ return snprintf(buf, PAGE_SIZE,
+ client->closed ? "<%u>" : "%u",
+ pid_nr(client->pid));
+}
+
+static int
+__i915_drm_client_register(struct i915_drm_client *client,
+ struct task_struct *task)
+{
+ struct i915_drm_clients *clients = client->clients;
+ struct device_attribute *attr;
+ int ret = -ENOMEM;
+ char idstr[32];
+
+ client->pid = get_task_pid(task, PIDTYPE_PID);
+
+ client->name = kstrdup(task->comm, GFP_KERNEL);
+ if (!client->name)
+ goto err_name;
+
+ if (!clients->root)
+ return 0; /* intel_fbdev_init registers a client before sysfs */
+
+ snprintf(idstr, sizeof(idstr), "%u", client->id);
+ client->root = kobject_create_and_add(idstr, clients->root);
+ if (!client->root)
+ goto err_client;
+
+ attr = >attr.name;
+ sysfs_attr_init(>attr);
+ attr->attr.name = "name";
+ attr->attr.mode = 0444;
+ attr->show = show_client_name;
+
+ ret = sysfs_create_file(client->root, (struct attribute *)attr);
+ if (ret)
+ goto err_attr;
+
+ attr = >attr.pid;
+ sysfs_attr_init(>attr);
+ attr->attr.name = "pid";
+ attr->attr.mode = 0444;
+ attr->show = show_client_pid;
+
+ ret = sysfs_create_file(client->root, (struct attribute *)attr);
+ if (ret)
+ goto err_attr;
+
+ return 0;
+
+err_attr:
+ kobject_put(client->root);
+err_client:
+ kfree(client->name);
+err_name:
+ put_pid(client->pid);
+
+ return ret;
+}
+
+static void
+__i915_drm_client_unregister(struct i915_drm_client *client)
+{
+ put_pid(fetch_and_zero(>pid));
+ kfree(fetch_and_zero(>name));
+
+ if (!client->root)
+ return; /* fbdev client or error during drm open */
+
+ kobject_put(fetch_and_zero(>root));
+}
+
+struct i915_drm_client *
[Intel-gfx] [RFC 09/12] drm/i915: Track per-context engine busyness
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.
v2: Fix accounting for tail updates.
v3: Rebase.
v4: Mark currently running contexts as active on stats enable.
v5: Include some headers to fix the build.
v6: Added fine grained lock.
v7: Convert to seqlock. (Chris Wilson)
v8: Rebase and tidy with helpers.
v9: Refactor.
v10: Move recording start to promotion. (Chris)
v11: Consolidate duplicated code. (Chris)
v12: execlists->active cannot be NULL. (Chris)
v13: Move start to set_timeslice. (Chris)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++
drivers/gpu/drm/i915/gt/intel_context.h | 13 +++
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 15 ++--
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 ++-
5 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 01474d3a558b..c09b5fe7f61d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -296,6 +296,7 @@ intel_context_init(struct intel_context *ce,
INIT_LIST_HEAD(>signals);
mutex_init(>pin_mutex);
+ seqlock_init(>stats.lock);
i915_active_init(>active,
__intel_context_active, __intel_context_retire);
@@ -390,6 +391,25 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
return rq;
}
+ktime_t intel_context_get_busy_time(struct intel_context *ce)
+{
+ unsigned int seq;
+ ktime_t total;
+
+ do {
+ seq = read_seqbegin(>stats.lock);
+
+ total = ce->stats.total;
+
+ if (ce->stats.active)
+ total = ktime_add(total,
+ ktime_sub(ktime_get(),
+ ce->stats.start));
+ } while (read_seqretry(>stats.lock, seq));
+
+ return total;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_context.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 18efad255124..b18b0012cb40 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -244,4 +244,17 @@ static inline u64 intel_context_get_avg_runtime_ns(struct
intel_context *ce)
return mul_u32_u32(ewma_runtime_read(>runtime.avg), period);
}
+static inline void
+__intel_context_stats_start(struct intel_context *ce, ktime_t now)
+{
+ struct intel_context_stats *stats = >stats;
+
+ if (!stats->active) {
+ stats->start = now;
+ stats->active = true;
+ }
+}
+
+ktime_t intel_context_get_busy_time(struct intel_context *ce);
+
#endif /* __INTEL_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index c60490e756f9..120532ddd6fa 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "i915_active_types.h"
#include "i915_utils.h"
@@ -96,6 +97,14 @@ struct intel_context {
/** sseu: Control eu/slice partitioning */
struct intel_sseu sseu;
+
+ /** stats: Context GPU engine busyness tracking. */
+ struct intel_context_stats {
+ seqlock_t lock;
+ bool active;
+ ktime_t start;
+ ktime_t total;
+ } stats;
};
#endif /* __INTEL_CONTEXT_TYPES__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 53ac3f00909a..3845093b41ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1594,8 +1594,19 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
engine->stats.enabled_at = ktime_get();
- /* XXX submission method oblivious? */
- for (port = execlists->active; (rq = *port); port++)
+ /*
+* Mark currently running context as active.
+* XXX submission method oblivious?
+*/
+
+ rq = NULL;
+ port = execlists->active;
+ rq = *port;
+ if (rq)
+ __intel_context_stats_start(rq->context,
+ engine->stats.enabled_at);
+
+ for (; (rq = *port); port++)
engine->stats.active++;
for (port = execlists->pending;
Re: [Intel-gfx] PR - i915 firmware updates (TGL HuC 7.0.12 and DMC 2.06)
On Wed, Mar 4, 2020 at 4:36 PM Daniele Ceraolo Spurio wrote: > > Hi, > > Kindly add the below i915 changes to linux-firmware.git > > The following changes since commit 0148cfefcbf98898ca65bb26d9d7d638b30e211d: > > Merge https://github.com/rjliao-qca/qca-btfw (2020-03-02 08:08:15 -0500) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-firmware tgl_huc_7.0.12_dmc_2.06 Pulled and pushed out. josh > > for you to fetch changes up to fb83402c757034fd9adef083047390b3b2f54cb4: > > i915: Add DMC firmware v2.06 for TGL (2020-03-04 13:19:07 -0800) > > > Daniele Ceraolo Spurio (1): > i915: add HuC firmware v7.0.12 for TGL > > José Roberto de Souza (1): > i915: Add DMC firmware v2.06 for TGL > > WHENCE | 6 ++ > i915/tgl_dmc_ver2_06.bin | Bin 0 -> 18660 bytes > i915/tgl_huc_7.0.12.bin | Bin 0 -> 530368 bytes > 3 files changed, 6 insertions(+) > create mode 100644 i915/tgl_dmc_ver2_06.bin > create mode 100644 i915/tgl_huc_7.0.12.bin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Defend against concurrent updates to execlists->active
Chris Wilson writes:
> [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
> [ 206.875654]
> [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
> bytes by task 703 on cpu 3:
> [ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
> [ 206.876130] __bump_priority+0x63/0x80 [i915]
> [ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915]
> [ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915]
> [ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915]
> [ 206.877057] i915_request_await_object+0x2fe/0x470 [i915]
> [ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
> [ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 206.877535] drm_ioctl_kernel+0xe4/0x120
> [ 206.877549] drm_ioctl+0x297/0x4c7
> [ 206.877563] ksys_ioctl+0x89/0xb0
> [ 206.877577] __x64_sys_ioctl+0x42/0x60
> [ 206.877591] do_syscall_64+0x6e/0x2c0
> [ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> v2: Be safe and include mb
>
> References: https://gitlab.freedesktop.org/drm/intel/issues/1318
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 15 ++-
> drivers/gpu/drm/i915/gt/intel_lrc.c| 12 +++-
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 29c8c03c5caa..3644fd2b8877 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -107,7 +107,20 @@ execlists_num_ports(const struct intel_engine_execlists
> * const execlists)
> static inline struct i915_request *
> execlists_active(const struct intel_engine_execlists *execlists)
> {
> - return *READ_ONCE(execlists->active);
> + struct i915_request * const *cur, * const *old, *active;
> +
> + cur = READ_ONCE(execlists->active);
> + smp_rmb(); /* pairs with overwrite protection in process_csb() */
> + do {
> + old = cur;
> +
> + active = READ_ONCE(*cur);
> + cur = READ_ONCE(execlists->active);
> +
> + smp_rmb(); /* and complete the seqlock retry */
> + } while (cur != old);
> +
> + return active;
> }
>
> static inline void
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 3eb7adc4e057..f4b7fdfa2d63 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2389,6 +2389,7 @@ static void process_csb(struct intel_engine_cs *engine)
>
> /* Point active to the new ELSP; prevent overwriting */
> WRITE_ONCE(execlists->active, execlists->pending);
> + smp_wmb(); /* notify execlists_active() */
>
> /* cancel old inflight, prepare for switch */
> trace_ports(execlists, "preempted", old);
> @@ -2396,11 +2397,12 @@ static void process_csb(struct intel_engine_cs
> *engine)
> execlists_schedule_out(*old++);
>
> /* switch pending to inflight */
> - WRITE_ONCE(execlists->active,
> -memcpy(execlists->inflight,
> - execlists->pending,
> - execlists_num_ports(execlists) *
> - sizeof(*execlists->pending)));
> + memcpy(execlists->inflight,
> +execlists->pending,
> +execlists_num_ports(execlists) *
> +sizeof(*execlists->pending));
> + smp_wmb(); /* complete the seqlock */
> + WRITE_ONCE(execlists->active, execlists->inflight);
Now the memcpy bit is nicely in order,
Reviewed-by: Mika Kuoppala
>
> WRITE_ONCE(execlists->pending[0], NULL);
> } else {
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/display: Deactive FBC in fastsets when disabled by parameter (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915/display: Deactive FBC in fastsets when disabled by parameter (rev2) URL : https://patchwork.freedesktop.org/series/74401/ State : warning == Summary == $ dim checkpatch origin/drm-tip 80e3e1bd274b drm/i915/display: Deactive FBC in fastsets when disabled by parameter -:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #20: i915 :00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f total: 0 errors, 1 warnings, 0 checks, 65 lines checked ea3ac6c5922d drm/i915/display: Do not write in removed FBC fence registers ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: Defend against concurrent updates to execlists->active
[ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
[ 206.875654]
[ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
bytes by task 703 on cpu 3:
[ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
[ 206.876130] __bump_priority+0x63/0x80 [i915]
[ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915]
[ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915]
[ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915]
[ 206.877057] i915_request_await_object+0x2fe/0x470 [i915]
[ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 206.877535] drm_ioctl_kernel+0xe4/0x120
[ 206.877549] drm_ioctl+0x297/0x4c7
[ 206.877563] ksys_ioctl+0x89/0xb0
[ 206.877577] __x64_sys_ioctl+0x42/0x60
[ 206.877591] do_syscall_64+0x6e/0x2c0
[ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9
v2: Be safe and include mb
References: https://gitlab.freedesktop.org/drm/intel/issues/1318
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine.h | 15 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c| 12 +++-
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 29c8c03c5caa..3644fd2b8877 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -107,7 +107,20 @@ execlists_num_ports(const struct intel_engine_execlists *
const execlists)
static inline struct i915_request *
execlists_active(const struct intel_engine_execlists *execlists)
{
- return *READ_ONCE(execlists->active);
+ struct i915_request * const *cur, * const *old, *active;
+
+ cur = READ_ONCE(execlists->active);
+ smp_rmb(); /* pairs with overwrite protection in process_csb() */
+ do {
+ old = cur;
+
+ active = READ_ONCE(*cur);
+ cur = READ_ONCE(execlists->active);
+
+ smp_rmb(); /* and complete the seqlock retry */
+ } while (cur != old);
+
+ return active;
}
static inline void
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3eb7adc4e057..f4b7fdfa2d63 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2389,6 +2389,7 @@ static void process_csb(struct intel_engine_cs *engine)
/* Point active to the new ELSP; prevent overwriting */
WRITE_ONCE(execlists->active, execlists->pending);
+ smp_wmb(); /* notify execlists_active() */
/* cancel old inflight, prepare for switch */
trace_ports(execlists, "preempted", old);
@@ -2396,11 +2397,12 @@ static void process_csb(struct intel_engine_cs *engine)
execlists_schedule_out(*old++);
/* switch pending to inflight */
- WRITE_ONCE(execlists->active,
- memcpy(execlists->inflight,
- execlists->pending,
- execlists_num_ports(execlists) *
- sizeof(*execlists->pending)));
+ memcpy(execlists->inflight,
+ execlists->pending,
+ execlists_num_ports(execlists) *
+ sizeof(*execlists->pending));
+ smp_wmb(); /* complete the seqlock */
+ WRITE_ONCE(execlists->active, execlists->inflight);
WRITE_ONCE(execlists->pending[0], NULL);
} else {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/execlsts: Mark up racy inspection of current i915_request priority
Chris Wilson writes:
> [ 120.176548] BUG: KCSAN: data-race in __i915_schedule [i915] /
> effective_prio [i915]
> [ 120.176566]
> [ 120.176577] write to 0x8881e35e6540 of 4 bytes by task 730 on cpu 3:
> [ 120.176792] __i915_schedule+0x63e/0x920 [i915]
> [ 120.177007] __bump_priority+0x63/0x80 [i915]
> [ 120.177220] __i915_sched_node_add_dependency+0x258/0x300 [i915]
> [ 120.177438] i915_sched_node_add_dependency+0x50/0xa0 [i915]
> [ 120.177654] i915_request_await_dma_fence+0x1da/0x530 [i915]
> [ 120.177867] i915_request_await_object+0x2fe/0x470 [i915]
> [ 120.178081] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
> [ 120.178292] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 120.178309] drm_ioctl_kernel+0xe4/0x120
> [ 120.178322] drm_ioctl+0x297/0x4c7
> [ 120.178335] ksys_ioctl+0x89/0xb0
> [ 120.178348] __x64_sys_ioctl+0x42/0x60
> [ 120.178361] do_syscall_64+0x6e/0x2c0
> [ 120.178375] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 120.178387]
> [ 120.178397] read to 0x8881e35e6540 of 4 bytes by interrupt on cpu 2:
> [ 120.178606] effective_prio+0x25/0xc0 [i915]
> [ 120.178812] process_csb+0xe8b/0x10a0 [i915]
> [ 120.179021] execlists_submission_tasklet+0x30/0x170 [i915]
> [ 120.179038] tasklet_action_common.isra.0+0x42/0xa0
> [ 120.179053] __do_softirq+0xd7/0x2cd
> [ 120.179066] irq_exit+0xbe/0xe0
> [ 120.179078] do_IRQ+0x51/0x100
> [ 120.179090] ret_from_intr+0x0/0x1c
> [ 120.179104] cpuidle_enter_state+0x1b8/0x5d0
> [ 120.179117] cpuidle_enter+0x50/0x90
> [ 120.179131] do_idle+0x1a1/0x1f0
> [ 120.179145] cpu_startup_entry+0x14/0x16
> [ 120.179158] start_secondary+0x120/0x180
> [ 120.179172] secondary_startup_64+0xa4/0xb0
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> drivers/gpu/drm/i915/i915_scheduler.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 20dd3c2cfa2f..3eb7adc4e057 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -293,7 +293,7 @@ static inline struct i915_priolist *to_priolist(struct
> rb_node *rb)
>
> static inline int rq_prio(const struct i915_request *rq)
> {
> - return rq->sched.attr.priority;
> + return READ_ONCE(rq->sched.attr.priority);
> }
>
> static int effective_prio(const struct i915_request *rq)
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 52f71e83e088..af51810dc78c 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -321,7 +321,7 @@ static void __i915_schedule(struct i915_sched_node *node,
>
> GEM_BUG_ON(node_to_request(node)->engine != engine);
>
> - node->attr.priority = prio;
> + WRITE_ONCE(node->attr.priority, prio);
Ah the symmetry,
Reviewed-by: Mika Kuoppala
>
> /*
>* Once the request is ready, it will be placed into the
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Mark up the racy access to switch_priority_hint
Chris Wilson writes:
> [ 7534.150687] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915]
> / process_csb [i915]
> [ 7534.150706]
> [ 7534.150717] write to 0x8881f1bc24b4 of 4 bytes by task 24404 on cpu 3:
> [ 7534.150925] __execlists_submission_tasklet+0x1158/0x2780 [i915]
> [ 7534.151133] execlists_submit_request+0x2e8/0x2f0 [i915]
> [ 7534.151348] submit_notify+0x8f/0xc0 [i915]
> [ 7534.151549] __i915_sw_fence_complete+0x5d/0x3e0 [i915]
> [ 7534.151753] i915_sw_fence_complete+0x58/0x80 [i915]
> [ 7534.151963] i915_sw_fence_commit+0x16/0x20 [i915]
> [ 7534.152179] __i915_request_queue+0x60/0x70 [i915]
> [ 7534.152388] i915_gem_do_execbuffer+0x3997/0x4c20 [i915]
> [ 7534.152598] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 7534.152615] drm_ioctl_kernel+0xe4/0x120
> [ 7534.152629] drm_ioctl+0x297/0x4c7
> [ 7534.152642] ksys_ioctl+0x89/0xb0
> [ 7534.152654] __x64_sys_ioctl+0x42/0x60
> [ 7534.152667] do_syscall_64+0x6e/0x2c0
> [ 7534.152681] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 7534.152693]
> [ 7534.152703] read to 0x8881f1bc24b4 of 4 bytes by interrupt on cpu 2:
> [ 7534.152914] process_csb+0xe7c/0x10a0 [i915]
> [ 7534.153120] execlists_submission_tasklet+0x30/0x170 [i915]
> [ 7534.153138] tasklet_action_common.isra.0+0x42/0xa0
> [ 7534.153153] __do_softirq+0xd7/0x2cd
> [ 7534.153166] run_ksoftirqd+0x15/0x20
> [ 7534.153180] smpboot_thread_fn+0x1ab/0x300
> [ 7534.153194] kthread+0x19a/0x1e0
> [ 7534.153207] ret_from_fork+0x1f/0x30
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 3eb7adc4e057..9890d248749e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1792,12 +1792,13 @@ timeslice(const struct intel_engine_cs *engine)
> static unsigned long
> active_timeslice(const struct intel_engine_cs *engine)
> {
> - const struct i915_request *rq = *engine->execlists.active;
> + const struct intel_engine_execlists *execlists = >execlists;
> + const struct i915_request *rq = *execlists->active;
>
> if (!rq || i915_request_completed(rq))
> return 0;
>
> - if (engine->execlists.switch_priority_hint < effective_prio(rq))
> + if (READ_ONCE(execlists->switch_priority_hint) < effective_prio(rq))
> return 0;
>
> return timeslice(engine);
> @@ -1814,8 +1815,11 @@ static void set_timeslice(struct intel_engine_cs
> *engine)
> static void start_timeslice(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlists *execlists = >execlists;
> + int prio = queue_prio(execlists);
const would have suited in here.
Reviewed-by: Mika Kuoppala
>
> - execlists->switch_priority_hint = execlists->queue_priority_hint;
> + WRITE_ONCE(execlists->switch_priority_hint, prio);
> + if (prio == INT_MIN)
> + return;
>
> if (timer_pending(>timer))
> return;
> @@ -5342,10 +5346,10 @@ void intel_execlists_show_requests(struct
> intel_engine_cs *engine,
>
> if (execlists->switch_priority_hint != INT_MIN)
> drm_printf(m, "\t\tSwitch priority hint: %d\n",
> -execlists->switch_priority_hint);
> +READ_ONCE(execlists->switch_priority_hint));
> if (execlists->queue_priority_hint != INT_MIN)
> drm_printf(m, "\t\tQueue priority hint: %d\n",
> -execlists->queue_priority_hint);
> +READ_ONCE(execlists->queue_priority_hint));
>
> last = NULL;
> count = 0;
> --
> 2.20.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
Re: [Intel-gfx] [PATCH] drm/i915/tgl: WaDisableGPGPUMidThreadPreemption
>>But he asked whether it's possible for Media and OpenCL drivers to also >>disable mid-thread preemption through the INTERFACE_DESCRIPTOR_DATA, instead >>of from the >>kernel side, so we could try to experiment with it in the >>future. Interface Descriptor setting only switches the preemption from mid thread to thread group. It doesn't allow to disable it completely and there are cases where this is required (i.e. VME). For that we need mmio whitelist. Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Defend against concurrent updates to execlists->active
Quoting Mika Kuoppala (2020-03-09 16:38:49)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-03-09 15:34:40)
> >> Chris Wilson writes:
> >>
> >> > [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930
> >> > [i915]
> >> > [ 206.875654]
> >> > [ 206.875666] race at unknown origin, with read to 0x8881f7644480
> >> > of 8 bytes by task 703 on cpu 3:
> >> > [ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
> >> > [ 206.876130] __bump_priority+0x63/0x80 [i915]
> >> > [ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915]
> >> > [ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915]
> >> > [ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915]
> >> > [ 206.877057] i915_request_await_object+0x2fe/0x470 [i915]
> >> > [ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
> >> > [ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> >> > [ 206.877535] drm_ioctl_kernel+0xe4/0x120
> >> > [ 206.877549] drm_ioctl+0x297/0x4c7
> >> > [ 206.877563] ksys_ioctl+0x89/0xb0
> >> > [ 206.877577] __x64_sys_ioctl+0x42/0x60
> >> > [ 206.877591] do_syscall_64+0x6e/0x2c0
> >> > [ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >> >
> >> > References: https://gitlab.freedesktop.org/drm/intel/issues/1318
> >> > Signed-off-by: Chris Wilson
> >> > ---
> >> > drivers/gpu/drm/i915/gt/intel_engine.h | 12 +++-
> >> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> >> > b/drivers/gpu/drm/i915/gt/intel_engine.h
> >> > index 29c8c03c5caa..f267f51c457c 100644
> >> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> >> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> >> > @@ -107,7 +107,17 @@ execlists_num_ports(const struct
> >> > intel_engine_execlists * const execlists)
> >> > static inline struct i915_request *
> >> > execlists_active(const struct intel_engine_execlists *execlists)
> >> > {
> >> > - return *READ_ONCE(execlists->active);
> >> > + struct i915_request * const *cur = READ_ONCE(execlists->active);
> >> > + struct i915_request * const *old;
> >> > + struct i915_request *active;
> >> > +
> >> > + do {
> >> > + old = cur;
> >> > + active = READ_ONCE(*cur);
> >> > + cur = READ_ONCE(execlists->active);
> >> > + } while (cur != old);
> >> > +
> >> > + return active;
> >>
> >> The updated side is scary. We are updating the execlists->active
> >> in two phases and handling the array copying in between.
> >>
> >> as WRITE_ONCE only guarantees ordering inside one context, due to
> >> it is for compiler only, it makes me very suspicious about
> >> how the memcpy of pending->inflight might unravel between two cpus.
> >>
> >> smb_store_mb(execlists->active, execlists->pending);
> >> memcpy(inflight, pending)
> >> smb_wmb();
> >> smb_store_mb(execlists->active, execlists->inflight);
> >> smb_store_mb(execlists->pending[0], NULL);
> >
> > Not quite. You've overkill on the mb there.
> >
> > If you want to be pedantic,
> >
> > WRITE_ONCE(active, pending);
> > smp_wmb();
> >
> > memcpy(inflight, pending);
> > smp_wmb();
> > WRITE_ONCE(active, inflight);
>
> This is the crux of it, needing rmb counterpart.
I suspect this is overkill, but if we really do want the change in
active to be visible before the memcpy, that wmb is strictly required.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/execlists: Mark up read of i915_request.fence.flags
Chris Wilson writes:
> [ 145.927961] BUG: KCSAN: data-race in can_merge_rq [i915] / signal_irq_work
> [i915]
> [ 145.927980]
> [ 145.927992] write (marked) to 0x8881e513fab0 of 8 bytes by interrupt
> on cpu 2:
> [ 145.928250] signal_irq_work+0x134/0x640 [i915]
> [ 145.928268] irq_work_run_list+0xd7/0x120
> [ 145.928283] irq_work_run+0x1d/0x50
> [ 145.928300] smp_irq_work_interrupt+0x21/0x30
> [ 145.928328] irq_work_interrupt+0xf/0x20
> [ 145.928356] _raw_spin_unlock_irqrestore+0x34/0x40
> [ 145.928596] execlists_submission_tasklet+0xde/0x170 [i915]
> [ 145.928616] tasklet_action_common.isra.0+0x42/0xa0
> [ 145.928632] __do_softirq+0xd7/0x2cd
> [ 145.928646] irq_exit+0xbe/0xe0
> [ 145.928665] do_IRQ+0x51/0x100
> [ 145.928684] ret_from_intr+0x0/0x1c
> [ 145.928699] schedule+0x0/0xb0
> [ 145.928719] worker_thread+0x194/0x670
> [ 145.928743] kthread+0x19a/0x1e0
> [ 145.928765] ret_from_fork+0x1f/0x30
> [ 145.928784]
> [ 145.928796] read to 0x8881e513fab0 of 8 bytes by task 738 on cpu 1:
> [ 145.929046] can_merge_rq+0xb1/0x100 [i915]
> [ 145.929282] __execlists_submission_tasklet+0x866/0x25a0 [i915]
> [ 145.929518] execlists_submit_request+0x2a4/0x2b0 [i915]
> [ 145.929758] submit_notify+0x8f/0xc0 [i915]
> [ 145.929989] __i915_sw_fence_complete+0x5d/0x3e0 [i915]
> [ 145.930221] i915_sw_fence_complete+0x58/0x80 [i915]
> [ 145.930453] i915_sw_fence_commit+0x16/0x20 [i915]
> [ 145.930698] __i915_request_queue+0x60/0x70 [i915]
> [ 145.930935] i915_gem_do_execbuffer+0x3997/0x4c20 [i915]
> [ 145.931175] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 145.931194] drm_ioctl_kernel+0xe4/0x120
> [ 145.931208] drm_ioctl+0x297/0x4c7
> [ 145.931222] ksys_ioctl+0x89/0xb0
> [ 145.931238] __x64_sys_ioctl+0x42/0x60
> [ 145.931260] do_syscall_64+0x6e/0x2c0
> [ 145.931275] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index a9d77b0e4e27..20dd3c2cfa2f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1597,6 +1597,11 @@ static bool can_merge_ctx(const struct intel_context
> *prev,
> return true;
> }
>
> +static unsigned long i915_request_flags(const struct i915_request *rq)
> +{
> + return READ_ONCE(rq->fence.flags);
Bitmasks and atomicity through read/write once is bad idea.
But the write side was by atomic bitops.
Race between comparing two requests is still there tho.
The flags compared against tho are well established
apriori request queueing.
Reviewed-by: Mika Kuoppala
> +}
> +
> static bool can_merge_rq(const struct i915_request *prev,
>const struct i915_request *next)
> {
> @@ -1614,7 +1619,7 @@ static bool can_merge_rq(const struct i915_request
> *prev,
> if (i915_request_completed(next))
> return true;
>
> - if (unlikely((prev->fence.flags ^ next->fence.flags) &
> + if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) &
>(BIT(I915_FENCE_FLAG_NOPREEMPT) |
> BIT(I915_FENCE_FLAG_SENTINEL
> return false;
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Refactor Gen11+ SAGV support
== Series Details == Series: Refactor Gen11+ SAGV support URL : https://patchwork.freedesktop.org/series/74461/ State : warning == Summary == $ dim checkpatch origin/drm-tip e5a587535617 drm/i915: Start passing latency as parameter 33f087f7ad33 drm/i915: Introduce skl_plane_wm_level accessor. 187985037fe5 drm/i915: Add intel_bw_get_*_state helpers 0d3043296dee drm/i915: Refactor intel_can_enable_sagv -:113: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #113: check and also there seems to be no need for checking ddb_state_changes total: 0 errors, 1 warnings, 0 checks, 548 lines checked 6bef05bea7fe drm/i915: Added required new PCode commands 794d317f4d58 drm/i915: Rename bw_state to new_bw_state cf60e64c735d drm/i915: Restrict qgv points which don't have enough bandwidth. 0f8277c857a7 drm/i915: Enable SAGV support for Gen12 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Defend against concurrent updates to execlists->active
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-03-09 15:34:40)
>> Chris Wilson writes:
>>
>> > [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
>> > [ 206.875654]
>> > [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of
>> > 8 bytes by task 703 on cpu 3:
>> > [ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
>> > [ 206.876130] __bump_priority+0x63/0x80 [i915]
>> > [ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915]
>> > [ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915]
>> > [ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915]
>> > [ 206.877057] i915_request_await_object+0x2fe/0x470 [i915]
>> > [ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
>> > [ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
>> > [ 206.877535] drm_ioctl_kernel+0xe4/0x120
>> > [ 206.877549] drm_ioctl+0x297/0x4c7
>> > [ 206.877563] ksys_ioctl+0x89/0xb0
>> > [ 206.877577] __x64_sys_ioctl+0x42/0x60
>> > [ 206.877591] do_syscall_64+0x6e/0x2c0
>> > [ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> >
>> > References: https://gitlab.freedesktop.org/drm/intel/issues/1318
>> > Signed-off-by: Chris Wilson
>> > ---
>> > drivers/gpu/drm/i915/gt/intel_engine.h | 12 +++-
>> > 1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
>> > b/drivers/gpu/drm/i915/gt/intel_engine.h
>> > index 29c8c03c5caa..f267f51c457c 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
>> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
>> > @@ -107,7 +107,17 @@ execlists_num_ports(const struct
>> > intel_engine_execlists * const execlists)
>> > static inline struct i915_request *
>> > execlists_active(const struct intel_engine_execlists *execlists)
>> > {
>> > - return *READ_ONCE(execlists->active);
>> > + struct i915_request * const *cur = READ_ONCE(execlists->active);
>> > + struct i915_request * const *old;
>> > + struct i915_request *active;
>> > +
>> > + do {
>> > + old = cur;
>> > + active = READ_ONCE(*cur);
>> > + cur = READ_ONCE(execlists->active);
>> > + } while (cur != old);
>> > +
>> > + return active;
>>
>> The updated side is scary. We are updating the execlists->active
>> in two phases and handling the array copying in between.
>>
>> as WRITE_ONCE only guarantees ordering inside one context, due to
>> it is for compiler only, it makes me very suspicious about
>> how the memcpy of pending->inflight might unravel between two cpus.
>>
>> smb_store_mb(execlists->active, execlists->pending);
>> memcpy(inflight, pending)
>> smb_wmb();
>> smb_store_mb(execlists->active, execlists->inflight);
>> smb_store_mb(execlists->pending[0], NULL);
>
> Not quite. You've overkill on the mb there.
>
> If you want to be pedantic,
>
> WRITE_ONCE(active, pending);
> smp_wmb();
>
> memcpy(inflight, pending);
> smp_wmb();
> WRITE_ONCE(active, inflight);
This is the crux of it, needing rmb counterpart.
-Mika
>
> The update of pending is not part of this sequence.
>
> But do we need that, and I still think we do not.
>
>> This in paired with:
>>
>> active = READ_ONCE(*cur);
>> smb_rmb();
>> cur = READ_ONCE(execlists->active);
>>
>> With this, it should not matter at which point the execlists->active
>> is sampled as the pending would be guaranteed to be
>> immutable if it sampled early and inflight immutable if it
>> sampled late?
>
> Simply because we don't care about the sampling, just that the read
> dependency gives us a valid pointer. (We are not looking at a snapshot
> of several reads, but a _single_ read and the data dependency from
> that.)
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/17] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2. (rev2)
== Series Details == Series: series starting with [01/17] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2. (rev2) URL : https://patchwork.freedesktop.org/series/74387/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16884 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16884 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16884, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16884: ### IGT changes ### Possible regressions * igt@gem_close_race@basic-process: - fi-ivb-3770:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-ivb-3770/igt@gem_close_r...@basic-process.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-ivb-3770/igt@gem_close_r...@basic-process.html - fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-hsw-4770/igt@gem_close_r...@basic-process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-hsw-4770/igt@gem_close_r...@basic-process.html - fi-hsw-peppy: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-hsw-peppy/igt@gem_close_r...@basic-process.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-hsw-peppy/igt@gem_close_r...@basic-process.html * igt@gem_exec_fence@basic-await@rcs0: - fi-blb-e6850: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html - fi-elk-e7500: NOTRUN -> [DMESG-WARN][9] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html - fi-ilk-650: [PASS][10] -> [DMESG-WARN][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-ilk-650/igt@gem_exec_fence@basic-aw...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-ilk-650/igt@gem_exec_fence@basic-aw...@rcs0.html * igt@gem_exec_fence@basic-await@vcs0: - fi-ilk-650: [PASS][12] -> [INCOMPLETE][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-ilk-650/igt@gem_exec_fence@basic-aw...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-ilk-650/igt@gem_exec_fence@basic-aw...@vcs0.html * igt@i915_selftest@live@mman: - fi-bwr-2160:[PASS][14] -> [DMESG-WARN][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-bwr-2160/igt@i915_selftest@l...@mman.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-bwr-2160/igt@i915_selftest@l...@mman.html - fi-kbl-r: [PASS][16] -> [DMESG-WARN][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-kbl-r/igt@i915_selftest@l...@mman.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-kbl-r/igt@i915_selftest@l...@mman.html - fi-icl-guc: [PASS][18] -> [DMESG-WARN][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-icl-guc/igt@i915_selftest@l...@mman.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-icl-guc/igt@i915_selftest@l...@mman.html - fi-skl-6770hq: [PASS][20] -> [DMESG-WARN][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-skl-6770hq/igt@i915_selftest@l...@mman.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-skl-6770hq/igt@i915_selftest@l...@mman.html - fi-kbl-8809g: [PASS][22] -> [DMESG-WARN][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-kbl-8809g/igt@i915_selftest@l...@mman.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-kbl-8809g/igt@i915_selftest@l...@mman.html - fi-skl-lmem:[PASS][24] -> [DMESG-WARN][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-skl-lmem/igt@i915_selftest@l...@mman.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-skl-lmem/igt@i915_selftest@l...@mman.html - fi-cfl-8109u: [PASS][26] -> [DMESG-WARN][27] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-cfl-8109u/igt@i915_selftest@l...@mman.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16884/fi-cfl-8109u/igt@i915_selftest@l...@mman.html - fi-cml-u2: [PASS][28] -> [DMESG-WARN][29]
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Don't treat unslice registers as masked (rev3)
On Sun, Mar 08, 2020 at 03:32:32AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/tgl: Don't treat unslice registers as masked (rev3) > URL : https://patchwork.freedesktop.org/series/74351/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_8090_full -> Patchwork_16875_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_16875_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_16875_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_16875_full: > > ### IGT changes ### > > Possible regressions > > * igt@runner@aborted: > - shard-tglb: NOTRUN -> [FAIL][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-tglb3/igt@run...@aborted.html This appears to be some kind of mutex deadlock. I believe it's the same issue reported in https://gitlab.freedesktop.org/drm/intel/issues/1402 ; not related to this patch. Patch applied to dinq. Thanks Nick for reporting/testing and Jose for reviewing. Matt > > > Warnings > > * igt@gem_ctx_persistence@close-replace-race: > - shard-tglb: [TIMEOUT][2] -> [INCOMPLETE][3] >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-tglb3/igt@gem_ctx_persiste...@close-replace-race.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-tglb3/igt@gem_ctx_persiste...@close-replace-race.html > > > Known issues > > > Here are the changes found in Patchwork_16875_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_busy@busy-vcs1: > - shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#112080]) +7 similar > issues >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-iclb1/igt@gem_b...@busy-vcs1.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-iclb8/igt@gem_b...@busy-vcs1.html > > * igt@gem_ctx_isolation@vecs0-s3: > - shard-apl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-apl2/igt@gem_ctx_isolat...@vecs0-s3.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-apl6/igt@gem_ctx_isolat...@vecs0-s3.html > > * igt@gem_ctx_shared@exec-single-timeline-bsd: > - shard-iclb: [PASS][8] -> [SKIP][9] ([fdo#110841]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html > > * igt@gem_exec_balancer@smoke: > - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#110854]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-iclb4/igt@gem_exec_balan...@smoke.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-iclb3/igt@gem_exec_balan...@smoke.html > > * igt@gem_exec_schedule@deep-bsd: > - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#112146]) +2 similar > issues >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-iclb7/igt@gem_exec_sched...@deep-bsd.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-iclb4/igt@gem_exec_sched...@deep-bsd.html > > * igt@gem_exec_schedule@implicit-read-write-bsd1: > - shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#109276] / [i915#677]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd1.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-iclb6/igt@gem_exec_sched...@implicit-read-write-bsd1.html > > * igt@gem_ppgtt@flink-and-close-vma-leak: > - shard-apl: [PASS][16] -> [FAIL][17] ([i915#644]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-apl8/igt@gem_pp...@flink-and-close-vma-leak.html > > * igt@gen9_exec_parse@allowed-all: > - shard-glk: [PASS][18] -> [DMESG-WARN][19] ([i915#716]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8090/shard-glk4/igt@gen9_exec_pa...@allowed-all.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16875/shard-glk7/igt@gen9_exec_pa...@allowed-all.html > > * igt@gen9_exec_parse@allowed-single: > - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#716]) >
Re: [Intel-gfx] [PATCH] drm/i915/gt: Defend against concurrent updates to execlists->active
Quoting Mika Kuoppala (2020-03-09 15:34:40)
> Chris Wilson writes:
>
> > [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
> > [ 206.875654]
> > [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
> > bytes by task 703 on cpu 3:
> > [ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
> > [ 206.876130] __bump_priority+0x63/0x80 [i915]
> > [ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915]
> > [ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915]
> > [ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915]
> > [ 206.877057] i915_request_await_object+0x2fe/0x470 [i915]
> > [ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
> > [ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> > [ 206.877535] drm_ioctl_kernel+0xe4/0x120
> > [ 206.877549] drm_ioctl+0x297/0x4c7
> > [ 206.877563] ksys_ioctl+0x89/0xb0
> > [ 206.877577] __x64_sys_ioctl+0x42/0x60
> > [ 206.877591] do_syscall_64+0x6e/0x2c0
> > [ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > References: https://gitlab.freedesktop.org/drm/intel/issues/1318
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine.h | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > index 29c8c03c5caa..f267f51c457c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > @@ -107,7 +107,17 @@ execlists_num_ports(const struct
> > intel_engine_execlists * const execlists)
> > static inline struct i915_request *
> > execlists_active(const struct intel_engine_execlists *execlists)
> > {
> > - return *READ_ONCE(execlists->active);
> > + struct i915_request * const *cur = READ_ONCE(execlists->active);
> > + struct i915_request * const *old;
> > + struct i915_request *active;
> > +
> > + do {
> > + old = cur;
> > + active = READ_ONCE(*cur);
> > + cur = READ_ONCE(execlists->active);
> > + } while (cur != old);
> > +
> > + return active;
>
> The updated side is scary. We are updating the execlists->active
> in two phases and handling the array copying in between.
>
> as WRITE_ONCE only guarantees ordering inside one context, due to
> it is for compiler only, it makes me very suspicious about
> how the memcpy of pending->inflight might unravel between two cpus.
>
> smb_store_mb(execlists->active, execlists->pending);
> memcpy(inflight, pending)
> smb_wmb();
> smb_store_mb(execlists->active, execlists->inflight);
> smb_store_mb(execlists->pending[0], NULL);
Not quite. You've overkill on the mb there.
If you want to be pedantic,
WRITE_ONCE(active, pending);
smp_wmb();
memcpy(inflight, pending);
smp_wmb();
WRITE_ONCE(active, inflight);
The update of pending is not part of this sequence.
But do we need that, and I still think we do not.
> This in paired with:
>
> active = READ_ONCE(*cur);
> smb_rmb();
> cur = READ_ONCE(execlists->active);
>
> With this, it should not matter at which point the execlists->active
> is sampled as the pending would be guaranteed to be
> immutable if it sampled early and inflight immutable if it
> sampled late?
Simply because we don't care about the sampling, just that the read
dependency gives us a valid pointer. (We are not looking at a snapshot
of several reads, but a _single_ read and the data dependency from
that.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v19 8/8] drm/i915: Enable SAGV support for Gen12
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4ec4dbba022f..a8a01a980b8f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3638,10 +3638,6 @@ static bool skl_needs_memory_bw_wa(struct
drm_i915_private *dev_priv)
bool
intel_has_sagv(struct drm_i915_private *dev_priv)
{
- /* HACK! */
- if (IS_GEN(dev_priv, 12))
- return false;
-
return (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) &&
dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
}
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v19 6/8] drm/i915: Rename bw_state to new_bw_state
That is a preparation patch before next one where we
introduce old_bw_state and a bunch of other changes
as well.
In a review comment it was suggested to split out
at least that renaming into a separate patch, what
is done here.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index bdad7476dc7b..256c9322636c 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -418,7 +418,7 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
- struct intel_bw_state *bw_state = NULL;
+ struct intel_bw_state *new_bw_state = NULL;
unsigned int data_rate, max_data_rate;
unsigned int num_active_planes;
struct intel_crtc *crtc;
@@ -447,29 +447,29 @@ int intel_bw_atomic_check(struct intel_atomic_state
*state)
old_active_planes == new_active_planes)
continue;
- bw_state = intel_bw_get_state(state);
- if (IS_ERR(bw_state))
- return PTR_ERR(bw_state);
+ new_bw_state = intel_bw_get_state(state);
+ if (IS_ERR(new_bw_state))
+ return PTR_ERR(new_bw_state);
- bw_state->data_rate[crtc->pipe] = new_data_rate;
- bw_state->num_active_planes[crtc->pipe] = new_active_planes;
+ new_bw_state->data_rate[crtc->pipe] = new_data_rate;
+ new_bw_state->num_active_planes[crtc->pipe] = new_active_planes;
drm_dbg_kms(_priv->drm,
"pipe %c data rate %u num active planes %u\n",
pipe_name(crtc->pipe),
- bw_state->data_rate[crtc->pipe],
- bw_state->num_active_planes[crtc->pipe]);
+ new_bw_state->data_rate[crtc->pipe],
+ new_bw_state->num_active_planes[crtc->pipe]);
}
- if (!bw_state)
+ if (!new_bw_state)
return 0;
- ret = intel_atomic_lock_global_state(_state->base);
+ ret = intel_atomic_lock_global_state(_bw_state->base);
if (ret)
return ret;
- data_rate = intel_bw_data_rate(dev_priv, bw_state);
- num_active_planes = intel_bw_num_active_planes(dev_priv, bw_state);
+ data_rate = intel_bw_data_rate(dev_priv, new_bw_state);
+ num_active_planes = intel_bw_num_active_planes(dev_priv, new_bw_state);
max_data_rate = intel_max_data_rate(dev_priv, num_active_planes);
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v19 5/8] drm/i915: Added required new PCode commands
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_sideband.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 80cf02a6eec1..ba35ff190bb9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8992,6 +8992,7 @@ enum {
#define GEN7_PCODE_ILLEGAL_DATA0x3
#define GEN11_PCODE_ILLEGAL_SUBCOMMAND 0x4
#define GEN11_PCODE_LOCKED 0x6
+#define GEN11_PCODE_REJECTED 0x11
#define GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE 0x10
#define GEN6_PCODE_WRITE_RC6VIDS 0x4
#define GEN6_PCODE_READ_RC6VIDS 0x5
@@ -9013,6 +9014,7 @@ enum {
#define ICL_PCODE_MEM_SUBSYSYSTEM_INFO 0xd
#define ICL_PCODE_MEM_SS_READ_GLOBAL_INFO (0x0 << 8)
#define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)(((point) <<
16) | (0x1 << 8))
+#define ICL_PCODE_SAGV_DE_MEM_SS_CONFIG 0xe
#define GEN6_PCODE_READ_D_COMP 0x10
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
@@ -9025,6 +9027,8 @@ enum {
#define GEN9_SAGV_IS_DISABLED 0x1
#define GEN9_SAGV_ENABLE 0x3
#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
+#define GEN11_PCODE_POINTS_RESTRICTED 0x0
+#define GEN11_PCODE_POINTS_RESTRICTED_MASK 0x1
#define GEN6_PCODE_DATA_MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 1447e7516cb7..1e7dd6b6f103 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -370,6 +370,8 @@ static inline int gen7_check_mailbox_status(u32 mbox)
return -ENXIO;
case GEN11_PCODE_LOCKED:
return -EBUSY;
+ case GEN11_PCODE_REJECTED:
+ return -EACCES;
case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
return -EOVERFLOW;
default:
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v19 2/8] drm/i915: Introduce skl_plane_wm_level accessor.
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be changed
in next coming patches from this series.
v2: - plane_id -> plane->id(Ville Syrjälä)
- Moved wm_level var to have more local scope
(Ville Syrjälä)
- Renamed yuv to color_plane(Ville Syrjälä) in
skl_plane_wm_level
v3: - plane->id -> plane_id(this time for real, Ville Syrjälä)
- Changed colorplane id type from boolean to int as index
(Ville Syrjälä)
- Moved crtc_state param so that it is first now
(Ville Syrjälä)
- Moved wm_level declaration to tigher scope in
skl_write_plane_wm(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 85 ++---
1 file changed, 67 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c7928c870b0a..c72fa59a8302 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4547,6 +4547,18 @@ icl_get_total_relative_data_rate(struct intel_crtc_state
*crtc_state,
return total_data_rate;
}
+static const struct skl_wm_level *
+skl_plane_wm_level(const struct intel_crtc_state *crtc_state,
+ enum plane_id plane_id,
+ int level,
+ int color_plane)
+{
+ const struct skl_plane_wm *wm =
+ _state->wm.skl.optimal.planes[plane_id];
+
+ return color_plane == 0 ? >wm[level] : >uv_wm[level];
+}
+
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
{
@@ -4606,22 +4618,29 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
*crtc_state)
*/
for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
blocks = 0;
+
for_each_plane_id_on_crtc(crtc, plane_id) {
- const struct skl_plane_wm *wm =
- _state->wm.skl.optimal.planes[plane_id];
+ const struct skl_wm_level *wm_level;
+ const struct skl_wm_level *wm_uv_level;
+ int color_plane = 0;
+
+ wm_level = skl_plane_wm_level(crtc_state, plane_id,
+ level, color_plane);
+ wm_uv_level = skl_plane_wm_level(crtc_state, plane_id,
+level, color_plane +
1);
if (plane_id == PLANE_CURSOR) {
- if (wm->wm[level].min_ddb_alloc >
total[PLANE_CURSOR]) {
+ if (wm_level->min_ddb_alloc >
total[PLANE_CURSOR]) {
drm_WARN_ON(_priv->drm,
- wm->wm[level].min_ddb_alloc
!= U16_MAX);
+ wm_level->min_ddb_alloc !=
U16_MAX);
blocks = U32_MAX;
break;
}
continue;
}
- blocks += wm->wm[level].min_ddb_alloc;
- blocks += wm->uv_wm[level].min_ddb_alloc;
+ blocks += wm_level->min_ddb_alloc;
+ blocks += wm_uv_level->min_ddb_alloc;
}
if (blocks <= alloc_size) {
@@ -4644,10 +4663,16 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
*crtc_state)
* proportional to its relative data rate.
*/
for_each_plane_id_on_crtc(crtc, plane_id) {
- const struct skl_plane_wm *wm =
- _state->wm.skl.optimal.planes[plane_id];
+ const struct skl_wm_level *wm_level;
+ const struct skl_wm_level *wm_uv_level;
u64 rate;
u16 extra;
+ int color_plane = 0;
+
+ wm_level = skl_plane_wm_level(crtc_state, plane_id,
+ level, color_plane);
+ wm_uv_level = skl_plane_wm_level(crtc_state, plane_id,
+level, color_plane + 1);
if (plane_id == PLANE_CURSOR)
continue;
@@ -4663,7 +4688,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
extra = min_t(u16, alloc_size,
DIV64_U64_ROUND_UP(alloc_size * rate,
total_data_rate));
- total[plane_id] = wm->wm[level].min_ddb_alloc + extra;
+ total[plane_id] = wm_level->min_ddb_alloc + extra;
alloc_size -= extra;
[Intel-gfx] [PATCH v19 7/8] drm/i915: Restrict qgv points which don't have enough bandwidth.
According to BSpec 53998, we should try to restrict qgv points, which can't provide enough bandwidth for desired display configuration. Currently we are just comparing against all of those and take minimum(worst case). v2: Fixed wrong PCode reply mask, removed hardcoded values. v3: Forbid simultaneous legacy SAGV PCode requests and restricting qgv points. Put the actual restriction to commit function, added serialization(thanks to Ville) to prevent commit being applied out of order in case of nonblocking and/or nomodeset commits. v4: - Minor code refactoring, fixed few typos(thanks to James Ausmus) - Change the naming of qgv point masking/unmasking functions(James Ausmus). - Simplify the masking/unmasking operation itself, as we don't need to mask only single point per request(James Ausmus) - Reject and stick to highest bandwidth point if SAGV can't be enabled(BSpec) v5: - Add new mailbox reply codes, which seems to happen during boot time for TGL and indicate that QGV setting is not yet available. v6: - Increase number of supported QGV points to be in sync with BSpec. v7: - Rebased and resolved conflict to fix build failure. - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus) v8: - Don't report an error if we can't restrict qgv points, as SAGV can be disabled by BIOS, which is completely legal. So don't make CI panic. Instead if we detect that there is only 1 QGV point accessible just analyze if we can fit the required bandwidth requirements, but no need in restricting. v9: - Fix wrong QGV transition if we have 0 planes and no SAGV simultaneously. v10: - Fix CDCLK corruption, because of global state getting serialized without modeset, which caused copying of non-calculated cdclk to be copied to dev_priv(thanks to Ville for the hint). v11: - Remove unneeded headers and spaces(Matthew Roper) - Remove unneeded intel_qgv_info qi struct from bw check and zero out the needed one(Matthew Roper) - Changed QGV error message to have more clear meaning(Matthew Roper) - Use state->modeset_set instead of any_ms(Matthew Roper) - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used - Keep using crtc_state->hw.active instead of .enable(Matthew Roper) - Moved unrelated changes to other patch(using latency as parameter for plane wm calculation, moved to SAGV refactoring patch) v12: - Fix rebase conflict with own temporary SAGV/QGV fix. - Remove unnecessary mask being zero check when unmasking qgv points as this is completely legal(Matt Roper) - Check if we are setting the same mask as already being set in hardware to prevent error from PCode. - Fix error message when restricting/unrestricting qgv points to "mask/unmask" which sounds more accurate(Matt Roper) - Move sagv status setting to icl_get_bw_info from atomic check as this should be calculated only once.(Matt Roper) - Edited comments for the case when we can't enable SAGV and use only 1 QGV point with highest bandwidth to be more understandable.(Matt Roper) v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä) - Changed comment for zero new_mask in qgv points masking function to better reflect reality(Ville Syrjälä) - Simplified bit mask operation in qgv points masking function (Ville Syrjälä) - Moved intel_qgv_points_mask closer to gen11 SAGV disabling, however this still can't be under modeset condition(Ville Syrjälä) - Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask (Ville Syrjälä) - Extracted PCode changes to separate patch.(Ville Syrjälä) - Now treat num_planes 0 same as 1 to avoid confusion and returning max_bw as 0, which would prevent choosing QGV point having max bandwidth in case if SAGV is not allowed, as per BSpec(Ville Syrjälä) - Do the actual qgv_points_mask swap in the same place as all other global state parts like cdclk are swapped. In the next patch, this all will be moved to bw state as global state, once new global state patch series from Ville lands v14: - Now using global state to serialize access to qgv points - Added global state locking back, otherwise we seem to read bw state in a wrong way. v15: - Added TODO comment for near atomic global state locking in bw code. v16: - Fixed intel_atomic_bw_* functions to be intel_bw_* as discussed with Jani Nikula. - Take bw_state_changed flag into use. v17: - Moved qgv point related manipulations next to SAGV code, as those are semantically related(Ville Syrjälä) - Renamed those into intel_sagv_(pre)|(post)_plane_update (Ville Syrjälä) Signed-off-by: Stanislav Lisovskiy Cc: Ville Syrjälä Cc: James Ausmus ---
[Intel-gfx] [PATCH v19 0/8] Refactor Gen11+ SAGV support
For Gen11+ platforms BSpec suggests disabling specific QGV points separately, depending on bandwidth limitations and current display configuration. Thus it required adding a new PCode request for disabling QGV points and some refactoring of already existing SAGV code. Also had to refactor intel_can_enable_sagv function, as current seems to be outdated and using skl specific workarounds, also not following BSpec for Gen11+. v17: Had to rebase the whole series. v19: Added some new patches in between, rebased Stanislav Lisovskiy (8): drm/i915: Start passing latency as parameter drm/i915: Introduce skl_plane_wm_level accessor. drm/i915: Add intel_bw_get_*_state helpers drm/i915: Refactor intel_can_enable_sagv drm/i915: Added required new PCode commands drm/i915: Rename bw_state to new_bw_state drm/i915: Restrict qgv points which don't have enough bandwidth. drm/i915: Enable SAGV support for Gen12 drivers/gpu/drm/i915/display/intel_bw.c | 202 +-- drivers/gpu/drm/i915/display/intel_bw.h | 36 ++ drivers/gpu/drm/i915/display/intel_display.c | 33 +- .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_pm.c | 516 -- drivers/gpu/drm/i915/intel_pm.h | 4 + drivers/gpu/drm/i915/intel_sideband.c | 2 + 8 files changed, 689 insertions(+), 114 deletions(-) -- 2.24.1.485.gad05a3d8e5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v19 4/8] drm/i915: Refactor intel_can_enable_sagv
Currently intel_can_enable_sagv function contains a mix of workarounds for different platforms some of them are not valid for gens >= 11 already, so lets split it into separate functions. v2: - Rework watermark calculation algorithm to attempt to calculate Level 0 watermark with added sagv block time latency and check if it fits in DBuf in order to determine if SAGV can be enabled already at this stage, just as BSpec 49325 states. if that fails rollback to usual Level 0 latency and disable SAGV. - Remove unneeded tabs(James Ausmus) v3: Rebased the patch v4: - Added back interlaced check for Gen12 and added separate function for TGL SAGV check (thanks to James Ausmus for spotting) - Removed unneeded gen check - Extracted Gen12 SAGV decision making code to a separate function from skl_compute_wm v5: - Added SAGV global state to dev_priv, because we need to track all pipes, not only those in atomic state. Each pipe has now correspondent bit mask reflecting, whether it can tolerate SAGV or not(thanks to Ville Syrjala for suggestions). - Now using active flag instead of enable in crc usage check. v6: - Fixed rebase conflicts v7: - kms_cursor_legacy seems to get broken because of multiple memcpy calls when copying level 0 water marks for enabled SAGV, to fix this now simply using that field right away, without copying, for that introduced a new wm_level accessor which decides which wm_level to return based on SAGV state. v8: - Protect crtc_sagv_mask same way as we do for other global state changes: i.e check if changes are needed, then grab all crtc locks to serialize the changes(Ville Syrjälä) - Add crtc_sagv_mask caching in order to avoid needless recalculations (Matthew Roper) - Put back Gen12 SAGV switch in order to get it enabled in separate patch(Matthew Roper) - Rename *_set_sagv_mask to *_compute_sagv_mask(Matthew Roper) - Check if there are no active pipes in intel_can_enable_sagv instead of platform specific functions(Matthew Roper), same for intel_has_sagv check. v9 - Switched to u8 for crtc_sagv_mask(Ville Syrjälä) - crtc_sagv_mask now is pipe_sagv_mask(Ville Syrjälä) - Extracted sagv checking logic from skl/icl/tgl_compute_sagv_mask - Extracted skl_plane_wm_level function and passing latency to separate patches(Ville Syrjälä) - Removed part of unneeded copy-paste from tgl_check_pipe_fits_sagv_wm (Ville Syrjälä) - Now using simple assignment for sagv_wm0 as it contains only pod types and no pointers(Ville Syrjälä) - Fixed intel_can_enable_sagv not to do double duty, now it only check SAGV bits by ANDing those between local and global state. The SAGV masks are now computed after watermarks are available, in order to be able to figure out if ddb ranges are fitting nicely. (Ville Syrjälä) - Now having uv_sagv_wm0 and sagv_wm0, otherwise we have wrong logic when using skl_plane_wm_level accessor, as we had previously for Gen11+ color plane and regular wm levels, so probably both has to be recalculated with additional SAGV block time for Level 0. v10: - Starting to use new global state for storing pipe_sagv_mask v11: - Fixed rebase conflict with recent drm-tip - Check if we really need to recalculate SAGV mask, otherwise bail out without making any changes. - Use cached SAGV result, instead of recalculating it everytime, if bw_state hasn't changed. v12: - Removed WARN from intel_can_enable_sagv, in some of the commits if we don't recalculated watermarks, bw_state is not recalculated, thus leading to SAGV state not recalculated by the commit state, which is still calling intel_can_enable_sagv function. Fix that by just analyzing the current global bw_state object - because we simply have no other objects related to that. v13: - Rebased, fixed warnings regarding long lines - Changed function call sites from intel_atomic_bw* to intel_wb_* as was suggested.(Jani Nikula) - Taken ddb_state_changed and bw_state_changed into use. v14: - total_affected_planes is no longer needed to check for ddb changes, just as active_pipe_changes. v15: - Fixed stupid mistake with uninitialized crtc in skl_compute_sagv_mask. v16: - Convert pipe_sagv_mask to pipe_sagv_reject and now using inverted flag to indicate SAGV readiness for the pipe(Ville Syrjälä) - Added return value to intel_compute_sagv_mask which call intel_atomic_serialize_global_state in order to properly propagate EDEADLCK to drm. - Based on the discussion with Ville, removed active_pipe_changes check and also there seems to be no need for checking ddb_state_changes as well. Instead we just iterate through crtcs in state - having crtc in a
[Intel-gfx] [PATCH v19 3/8] drm/i915: Add intel_bw_get_*_state helpers
Add correspondent helpers to be able to get old/new bandwidth
global state object.
v2: - Fixed typo in function call
v3: - Changed new functions naming to use convention proposed
by Jani Nikula, i.e intel_bw_* in intel_bw.c file.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.c | 33 ++---
drivers/gpu/drm/i915/display/intel_bw.h | 9 +++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 58b264bc318d..bdad7476dc7b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -374,8 +374,35 @@ static unsigned int intel_bw_data_rate(struct
drm_i915_private *dev_priv,
return data_rate;
}
-static struct intel_bw_state *
-intel_atomic_get_bw_state(struct intel_atomic_state *state)
+struct intel_bw_state *
+intel_bw_get_old_state(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_global_state *bw_state;
+
+ bw_state = intel_atomic_get_old_global_obj_state(state,
_priv->bw_obj);
+ if (IS_ERR(bw_state))
+ return ERR_CAST(bw_state);
+
+ return to_intel_bw_state(bw_state);
+}
+
+struct intel_bw_state *
+intel_bw_get_new_state(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_global_state *bw_state;
+
+ bw_state = intel_atomic_get_new_global_obj_state(state,
_priv->bw_obj);
+
+ if (IS_ERR(bw_state))
+ return ERR_CAST(bw_state);
+
+ return to_intel_bw_state(bw_state);
+}
+
+struct intel_bw_state *
+intel_bw_get_state(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_global_state *bw_state;
@@ -420,7 +447,7 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
old_active_planes == new_active_planes)
continue;
- bw_state = intel_atomic_get_bw_state(state);
+ bw_state = intel_bw_get_state(state);
if (IS_ERR(bw_state))
return PTR_ERR(bw_state);
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index a8aa7624c5aa..b5f61463922f 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -24,6 +24,15 @@ struct intel_bw_state {
#define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
+struct intel_bw_state *
+intel_bw_get_old_state(struct intel_atomic_state *state);
+
+struct intel_bw_state *
+intel_bw_get_new_state(struct intel_atomic_state *state);
+
+struct intel_bw_state *
+intel_bw_get_state(struct intel_atomic_state *state);
+
void intel_bw_init_hw(struct drm_i915_private *dev_priv);
int intel_bw_init(struct drm_i915_private *dev_priv);
int intel_bw_atomic_check(struct intel_atomic_state *state);
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v19 1/8] drm/i915: Start passing latency as parameter
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
Reviewed-by: Ville Syrjälä
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8375054ba27d..c7928c870b0a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4016,6 +4016,7 @@ static int skl_compute_wm_params(const struct
intel_crtc_state *crtc_state,
int color_plane);
static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
int level,
+u32 latency,
const struct skl_wm_params *wp,
const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */);
@@ -4038,7 +4039,9 @@ skl_cursor_allocation(const struct intel_crtc_state
*crtc_state,
drm_WARN_ON(_priv->drm, ret);
for (level = 0; level <= max_level; level++) {
- skl_compute_plane_wm(crtc_state, level, , , );
+ u32 latency = dev_priv->wm.skl_latency[level];
+
+ skl_compute_plane_wm(crtc_state, level, latency, , , );
if (wm.min_ddb_alloc == U16_MAX)
break;
@@ -4972,12 +4975,12 @@ static bool skl_wm_has_lines(struct drm_i915_private
*dev_priv, int level)
static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
int level,
+u32 latency,
const struct skl_wm_params *wp,
const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
- u32 latency = dev_priv->wm.skl_latency[level];
uint_fixed_16_16_t method1, method2;
uint_fixed_16_16_t selected_result;
u32 res_blocks, res_lines, min_ddb_alloc = 0;
@@ -5106,9 +5109,10 @@ skl_compute_wm_levels(const struct intel_crtc_state
*crtc_state,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = [level];
+ u32 latency = dev_priv->wm.skl_latency[level];
- skl_compute_plane_wm(crtc_state, level, wm_params,
-result_prev, result);
+ skl_compute_plane_wm(crtc_state, level, latency,
+wm_params, result_prev, result);
result_prev = result;
}
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/gt: Mark up racy check of last list element
Chris Wilson writes:
> [ 25.025543] BUG: KCSAN: data-race in __i915_request_create [i915] /
> process_csb [i915]
> [ 25.025561]
> [ 25.025573] write (marked) to 0x8881e85c1620 of 8 bytes by task 696 on
> cpu 1:
> [ 25.025789] __i915_request_create+0x54b/0x5d0 [i915]
> [ 25.026001] i915_request_create+0xcc/0x150 [i915]
> [ 25.026218] i915_gem_do_execbuffer+0x2f70/0x4c20 [i915]
> [ 25.026428] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 25.026445] drm_ioctl_kernel+0xe4/0x120
> [ 25.026459] drm_ioctl+0x297/0x4c7
> [ 25.026472] ksys_ioctl+0x89/0xb0
> [ 25.026484] __x64_sys_ioctl+0x42/0x60
> [ 25.026497] do_syscall_64+0x6e/0x2c0
> [ 25.026510] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 25.026522]
> [ 25.026532] read to 0x8881e85c1620 of 8 bytes by interrupt on cpu 2:
> [ 25.026742] process_csb+0x8d6/0x1070 [i915]
> [ 25.026949] execlists_submission_tasklet+0x30/0x170 [i915]
> [ 25.026969] tasklet_action_common.isra.0+0x42/0xa0
> [ 25.026984] __do_softirq+0xd7/0x2cd
> [ 25.026997] irq_exit+0xbe/0xe0
> [ 25.027009] do_IRQ+0x51/0x100
> [ 25.027021] ret_from_intr+0x0/0x1c
> [ 25.027033] poll_idle+0x3e/0x13b
> [ 25.027047] cpuidle_enter_state+0x189/0x5d0
> [ 25.027060] cpuidle_enter+0x50/0x90
> [ 25.027074] do_idle+0x1a1/0x1f0
> [ 25.027086] cpu_startup_entry+0x14/0x16
> [ 25.027100] start_secondary+0x120/0x180
> [ 25.027116] secondary_startup_64+0xa4/0xb0
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> drivers/gpu/drm/i915/i915_utils.h | 6 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index a1d268880cfe..6266ef2ae6a0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1316,7 +1316,7 @@ __execlists_schedule_out(struct i915_request *rq,
>* If we have just completed this context, the engine may now be
>* idle and we want to re-enter powersaving.
>*/
> - if (list_is_last(>link, >timeline->requests) &&
> + if (list_is_last_rcu(>link, >timeline->requests) &&
> i915_request_completed(rq))
> intel_engine_add_retire(engine, ce->timeline);
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index 26f3a4a50b40..03a73d2bd50d 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -260,6 +260,12 @@ static inline void __list_del_many(struct list_head
> *head,
> WRITE_ONCE(head->next, first);
> }
>
> +static inline int list_is_last_rcu(const struct list_head *list,
> +const struct list_head *head)
> +{
> + return READ_ONCE(list->next) == head;
> +}
> +
> /*
> * Wait until the work is finally complete, even if it tries to postpone
> * by requeueing itself. Note, that if the worker never cancels itself,
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/17] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2. (rev2)
== Series Details ==
Series: series starting with [01/17] drm/i915: Add an implementation for
i915_gem_ww_ctx locking, v2. (rev2)
URL : https://patchwork.freedesktop.org/series/74387/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a07375e972da drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:506: WARNING:LONG_LINE: line over 100 characters
#506: FILE: drivers/gpu/drm/i915/i915_gem.c:1339:
+ while ((obj = list_first_entry_or_null(>obj_list, struct
drm_i915_gem_object, obj_link))) {
total: 0 errors, 1 warnings, 0 checks, 481 lines checked
fb5f8b0f4bd8 drm/i915: Remove locking from i915_gem_object_prepare_read/write
e73c2a91b83f drm/i915: Parse command buffer earlier in eb_relocate(slow)
4e33a47c9b1d drm/i915: Use per object locking in execbuf, v5.
22c3999407bc drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
Convert to using ww-waiting, and make sure we always pin intel_context_state,
total: 0 errors, 1 warnings, 0 checks, 202 lines checked
a0b296192afc drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line over 100 characters
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1064:
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
total: 0 errors, 1 warnings, 0 checks, 146 lines checked
164cef249306 drm/i915: Nuke arguments to eb_pin_engine
8f88e8dab92d drm/i915: Pin engine before pinning all objects, v3.
77b62e00cde5 drm/i915: Rework intel_context pinning to do everything outside of
pin_mutex
-:120: CHECK:LINE_SPACING: Please don't use multiple blank lines
#120: FILE: drivers/gpu/drm/i915/gt/intel_context.c:176:
+
+
-:330: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#330: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:3026:
+ *vaddr = i915_gem_object_pin_map(ce->state->obj,
+
i915_coherent_map_type(ce->engine->i915) |
total: 0 errors, 0 warnings, 2 checks, 435 lines checked
b825cd024f91 drm/i915: Make sure execbuffer always passes ww state to
i915_vma_pin.
-:80: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#80: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:573:
+ err = i915_vma_pin_ww(vma, >ww,
entry->pad_to_size, entry->alignment,
-:188: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#188: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2169:
+* hsw should have this fixed, but bdw mucks it up again. */
total: 0 errors, 1 warnings, 1 checks, 812 lines checked
fb5317b3dbd4 drm/i915: Convert i915_gem_object/client_blt.c to use ww locking
as well, v2.
e1bf61bde5c0 drm/i915: Kill last user of intel_context_create_request outside
of selftests
0ad82c88a73a drm/i915: Convert i915_perf to ww locking as well
feaac385addd drm/i915: Dirty hack to fix selftests locking inversion
c8beabdebf22 drm/i915/selftests: Fix locking inversion in lrc selftest.
69abe3bc5db6 drm/i915: Use ww pinning for intel_context_create_request()
c72d21a3cf9c drm/i915: Move i915_vma_lock in the selftests to avoid lock
inversion
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 125 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
Quoting Mika Kuoppala (2020-03-09 15:21:31)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-03-09 14:03:01)
> >> Chris Wilson writes:
> >>
> >> > During i915_request_retire() we decouple the i915_request.hwsp_seqno
> >> > from the intel_timeline so that it may be freed before the request is
> >> > released. However, we need to warn the compiler that the pointer may
> >> > update under its nose.
> >> >
> >> > [ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fence
> >> > [i915] / i915_request_retire [i915]
> >> > [ 171.438920]
> >> > [ 171.438932] write to 0x8881e7e28ce0 of 8 bytes by task 148 on cpu
> >> > 2:
> >> > [ 171.439174] i915_request_retire+0x1ea/0x660 [i915]
> >> > [ 171.439408] retire_requests+0x7a/0xd0 [i915]
> >> > [ 171.439640] engine_retire+0xa1/0xe0 [i915]
> >> > [ 171.439657] process_one_work+0x3b1/0x690
> >> > [ 171.439671] worker_thread+0x80/0x670
> >> > [ 171.439685] kthread+0x19a/0x1e0
> >> > [ 171.439701] ret_from_fork+0x1f/0x30
> >> > [ 171.439721]
> >> > [ 171.439739] read to 0x8881e7e28ce0 of 8 bytes by task 696 on cpu
> >> > 1:
> >> > [ 171.439990] i915_request_await_dma_fence+0x162/0x520 [i915]
> >> > [ 171.440230] i915_request_await_object+0x2fe/0x470 [i915]
> >> > [ 171.440467] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
> >> > [ 171.440704] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> >> > [ 171.440722] drm_ioctl_kernel+0xe4/0x120
> >> > [ 171.440736] drm_ioctl+0x297/0x4c7
> >> > [ 171.440750] ksys_ioctl+0x89/0xb0
> >> > [ 171.440766] __x64_sys_ioctl+0x42/0x60
> >> > [ 171.440788] do_syscall_64+0x6e/0x2c0
> >> > [ 171.440802] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >> >
> >> > Signed-off-by: Chris Wilson
> >> > Cc: Mika Kuoppala
> >> > ---
> >> > drivers/gpu/drm/i915/i915_request.h | 7 +--
> >> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_request.h
> >> > b/drivers/gpu/drm/i915/i915_request.h
> >> > index d4bae16b4785..6020d5b2a3df 100644
> >> > --- a/drivers/gpu/drm/i915/i915_request.h
> >> > +++ b/drivers/gpu/drm/i915/i915_request.h
> >> > @@ -396,7 +396,9 @@ static inline bool i915_seqno_passed(u32 seq1, u32
> >> > seq2)
> >> >
> >> > static inline u32 __hwsp_seqno(const struct i915_request *rq)
> >> > {
> >> > - return READ_ONCE(*rq->hwsp_seqno);
> >> > + const u32 *hwsp = READ_ONCE(rq->hwsp_seqno);
> >> > +
> >> > + return READ_ONCE(*hwsp);
> >>
> >> This is good enough for decouple. But good enough for hardware
> >> might be different thing.
> >>
> >> I am paranoid enough to wanting an rmb(), before the final
> >> read once.
> >
> > What? [That pointer is nothing to do with HW; it's a pointer to a
> > pointer to HW.]
>
> But you do read the value through the pointer to hardware.
>
> CPU:
> rmb(); READ_ONCE(*hwsp);
>
> GPU:
> WRITE_ONCE(*hwsp, seqno), wmb(), interrupt -> cpu.
>
> Thus on waking up, you would be guaranteed to see the
> value gpu intended upon.
The bspec gives us the guarantee that we see the correct value as the
GPU takes care of the cacheline invalidation on writing. We haven't had
reason not to believe that yet, all our issues so far have been the
arrival of the interrupt vs update of the seqno. (Well the whole design
of the request is that we don't really care how long it takes, just that
once a request is complete it stays completed.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Mark up the racy access to switch_priority_hint
== Series Details == Series: drm/i915/execlists: Mark up the racy access to switch_priority_hint URL : https://patchwork.freedesktop.org/series/74457/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16883 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16883/index.html Known issues Here are the changes found in Patchwork_16883 that come from known issues: ### IGT changes ### Issues hit * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][1] -> [DMESG-WARN][2] ([i915#44]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16883/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@i915_selftest@live@gem_contexts: - fi-skl-lmem:[INCOMPLETE][3] ([i915#424]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16883/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44 Participating hosts (46 -> 40) -- Additional (5): fi-glk-dsi fi-snb-2520m fi-elk-e7500 fi-bsw-kefka fi-tgl-y Missing(11): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus fi-kbl-r Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8097 -> Patchwork_16883 CI-20190529: 20190529 CI_DRM_8097: 2e46e269a2843c5d0b6c72bfb7fa9d9913c15415 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5499: 2e23cf6f63fc6ba1d9543f8327698d6f21813cec @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16883: c44455523ac832672d86d46d40d2a71a550c6536 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c44455523ac8 drm/i915/execlists: Mark up the racy access to switch_priority_hint == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16883/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
== Series Details == Series: series starting with [1/5] drm/i915: Mark up unlocked update of i915_request.hwsp_seqno URL : https://patchwork.freedesktop.org/series/74445/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16877_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16877_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_isolation@vcs1-clean: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb4/igt@gem_ctx_isolat...@vcs1-clean.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-iclb5/igt@gem_ctx_isolat...@vcs1-clean.html * igt@gem_ctx_persistence@close-replace-race: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-skl10/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-skl1/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-iclb7/igt@gem_exec_sched...@implicit-read-write-bsd2.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_8097/shard-iclb6/igt@gem_exec_sched...@pi-common-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb7/igt@gem_exec_sched...@reorder-wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-glk7/igt@gem_exec_whis...@basic-fds-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-glk2/igt@gem_exec_whis...@basic-fds-all.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#644]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-tglb6/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-tglb2/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_8097/shard-iclb8/igt@i915_pm_...@waitboost.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-iclb7/igt@i915_pm_...@waitboost.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#54]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16877/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#1188]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-skl1/igt@kms_...@bpc-switch-suspend.html [26]:
Re: [Intel-gfx] [PATCH] drm/i915: Mark racy read of intel_engine_cs.saturated
Quoting Mika Kuoppala (2020-03-09 15:05:45) > Chris Wilson writes: > > > [ 3783.276728] BUG: KCSAN: data-race in __i915_request_submit [i915] / > > i915_request_await_dma_fence [i915] > > [ 3783.276766] > > [ 3783.276787] write to 0x8881f1bc60a0 of 1 bytes by interrupt on cpu 2: > > [ 3783.277187] __i915_request_submit+0x47e/0x4a0 [i915] > > [ 3783.277580] __execlists_submission_tasklet+0x997/0x2780 [i915] > > [ 3783.277973] execlists_submission_tasklet+0xd3/0x170 [i915] > > [ 3783.278006] tasklet_action_common.isra.0+0x42/0xa0 > > [ 3783.278035] __do_softirq+0xd7/0x2cd > > [ 3783.278063] irq_exit+0xbe/0xe0 > > [ 3783.278089] do_IRQ+0x51/0x100 > > [ 3783.278114] ret_from_intr+0x0/0x1c > > [ 3783.278140] finish_task_switch+0x72/0x260 > > [ 3783.278170] __schedule+0x1e5/0x510 > > [ 3783.278198] schedule+0x45/0xb0 > > [ 3783.278226] smpboot_thread_fn+0x23e/0x300 > > [ 3783.278256] kthread+0x19a/0x1e0 > > [ 3783.278283] ret_from_fork+0x1f/0x30 > > [ 3783.278305] > > [ 3783.278327] read to 0x8881f1bc60a0 of 1 bytes by task 19440 on cpu 3: > > [ 3783.278724] i915_request_await_dma_fence+0x2a6/0x530 [i915] > > [ 3783.279130] i915_request_await_object+0x2fe/0x470 [i915] > > [ 3783.279524] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915] > > [ 3783.279908] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] > > [ 3783.279940] drm_ioctl_kernel+0xe4/0x120 > > [ 3783.279968] drm_ioctl+0x297/0x4c7 > > [ 3783.279996] ksys_ioctl+0x89/0xb0 > > [ 3783.280021] __x64_sys_ioctl+0x42/0x60 > > [ 3783.280047] do_syscall_64+0x6e/0x2c0 > > [ 3783.280074] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_request.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index 5de3989b6c4f..04b52bf347bf 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -907,7 +907,7 @@ already_busywaiting(struct i915_request *rq) > >* > >* See the are-we-too-late? check in __i915_request_submit(). > >*/ > > - return rq->sched.semaphores | rq->engine->saturated; > > + return rq->sched.semaphores | READ_ONCE(rq->engine->saturated); > > This seem to be a one way ticket to saturation (until parking it is). > Usually there should be the WRITE_ONCE counterpair! > > So now the question is that does it really matter if the race happens. It's a safety net, to turn off semaphore interengine synchronisation when fully occupied (polling the semaphore caused noticeable extra bus traffic). There's a small disparity in that we do want the switch to be global, as any process still trying to utilise semaphores is disadvantaged by the scheduler, which results in unfair scheduling. However, such transition will always be asynchronous with the work already queued, with new work being preferred over older queues. :( I do want to reinstate semaphores as there are measurable performance improvements (both in throughput as well as obvious latency improvement) and this safety net spoils the fun. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Defend against concurrent updates to execlists->active
Chris Wilson writes:
> [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
> [ 206.875654]
> [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
> bytes by task 703 on cpu 3:
> [ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
> [ 206.876130] __bump_priority+0x63/0x80 [i915]
> [ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915]
> [ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915]
> [ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915]
> [ 206.877057] i915_request_await_object+0x2fe/0x470 [i915]
> [ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
> [ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 206.877535] drm_ioctl_kernel+0xe4/0x120
> [ 206.877549] drm_ioctl+0x297/0x4c7
> [ 206.877563] ksys_ioctl+0x89/0xb0
> [ 206.877577] __x64_sys_ioctl+0x42/0x60
> [ 206.877591] do_syscall_64+0x6e/0x2c0
> [ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> References: https://gitlab.freedesktop.org/drm/intel/issues/1318
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 29c8c03c5caa..f267f51c457c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -107,7 +107,17 @@ execlists_num_ports(const struct intel_engine_execlists
> * const execlists)
> static inline struct i915_request *
> execlists_active(const struct intel_engine_execlists *execlists)
> {
> - return *READ_ONCE(execlists->active);
> + struct i915_request * const *cur = READ_ONCE(execlists->active);
> + struct i915_request * const *old;
> + struct i915_request *active;
> +
> + do {
> + old = cur;
> + active = READ_ONCE(*cur);
> + cur = READ_ONCE(execlists->active);
> + } while (cur != old);
> +
> + return active;
The updated side is scary. We are updating the execlists->active
in two phases and handling the array copying in between.
as WRITE_ONCE only guarantees ordering inside one context, due to
it is for compiler only, it makes me very suspicious about
how the memcpy of pending->inflight might unravel between two cpus.
smb_store_mb(execlists->active, execlists->pending);
memcpy(inflight, pending)
smb_wmb();
smb_store_mb(execlists->active, execlists->inflight);
smb_store_mb(execlists->pending[0], NULL);
This in paired with:
active = READ_ONCE(*cur);
smb_rmb();
cur = READ_ONCE(execlists->active);
With this, it should not matter at which point the execlists->active
is sampled as the pending would be guaranteed to be
immutable if it sampled early and inflight immutable if it
sampled late?
-Mika
> }
>
> static inline void
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++-
drivers/gpu/drm/i915/selftests/i915_request.c | 18 -
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 99f8466a108a..d93b7d9ad174 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -199,25 +199,25 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
i915_gem_object_lock(ctx->obj, NULL);
err = i915_gem_object_set_to_gtt_domain(ctx->obj, true);
- i915_gem_object_unlock(ctx->obj);
if (err)
- return err;
+ goto out_unlock;
vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_unlock;
+ }
rq = intel_engine_create_kernel_request(ctx->engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto out_unpin;
}
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
- i915_request_add(rq);
- i915_vma_unpin(vma);
- return PTR_ERR(cs);
+ err = PTR_ERR(cs);
+ goto out_rq;
}
if (INTEL_GEN(ctx->engine->i915) >= 8) {
@@ -238,14 +238,16 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
}
intel_ring_advance(rq, cs);
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- i915_vma_unpin(vma);
+out_rq:
i915_request_add(rq);
+out_unpin:
+ i915_vma_unpin(vma);
+out_unlock:
+ i915_gem_object_unlock(ctx->obj);
return err;
}
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..9a89097194ad 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -848,6 +848,8 @@ static int live_all_engines(void *arg)
goto out_free;
}
+ i915_vma_lock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
request[idx] = intel_engine_create_kernel_request(engine);
@@ -865,11 +867,9 @@ static int live_all_engines(void *arg)
GEM_BUG_ON(err);
request[idx]->batch = batch;
- i915_vma_lock(batch);
err = i915_request_await_object(request[idx], batch->obj, 0);
if (err == 0)
err = i915_vma_move_to_active(batch, request[idx], 0);
- i915_vma_unlock(batch);
GEM_BUG_ON(err);
i915_request_get(request[idx]);
@@ -877,6 +877,8 @@ static int live_all_engines(void *arg)
idx++;
}
+ i915_vma_unlock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
if (i915_request_completed(request[idx])) {
@@ -967,12 +969,13 @@ static int live_sequential_engines(void *arg)
goto out_free;
}
+ i915_vma_lock(batch);
request[idx] = intel_engine_create_kernel_request(engine);
if (IS_ERR(request[idx])) {
err = PTR_ERR(request[idx]);
pr_err("%s: Request allocation failed for %s with
err=%d\n",
__func__, engine->name, err);
- goto out_request;
+ goto out_unlock;
}
if (prev) {
@@ -982,7 +985,7 @@ static int live_sequential_engines(void *arg)
i915_request_add(request[idx]);
pr_err("%s: Request await failed for %s with
err=%d\n",
__func__, engine->name, err);
- goto out_request;
+ goto out_unlock;
}
}
@@ -993,12 +996,10 @@ static int live_sequential_engines(void *arg)
GEM_BUG_ON(err);
request[idx]->batch = batch;
- i915_vma_lock(batch);
err = i915_request_await_object(request[idx],
batch->obj, false);
if (err == 0)
err = i915_vma_move_to_active(batch, request[idx], 0);
- i915_vma_unlock(batch);
GEM_BUG_ON(err);
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-03-09 14:03:01)
>> Chris Wilson writes:
>>
>> > During i915_request_retire() we decouple the i915_request.hwsp_seqno
>> > from the intel_timeline so that it may be freed before the request is
>> > released. However, we need to warn the compiler that the pointer may
>> > update under its nose.
>> >
>> > [ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fence
>> > [i915] / i915_request_retire [i915]
>> > [ 171.438920]
>> > [ 171.438932] write to 0x8881e7e28ce0 of 8 bytes by task 148 on cpu 2:
>> > [ 171.439174] i915_request_retire+0x1ea/0x660 [i915]
>> > [ 171.439408] retire_requests+0x7a/0xd0 [i915]
>> > [ 171.439640] engine_retire+0xa1/0xe0 [i915]
>> > [ 171.439657] process_one_work+0x3b1/0x690
>> > [ 171.439671] worker_thread+0x80/0x670
>> > [ 171.439685] kthread+0x19a/0x1e0
>> > [ 171.439701] ret_from_fork+0x1f/0x30
>> > [ 171.439721]
>> > [ 171.439739] read to 0x8881e7e28ce0 of 8 bytes by task 696 on cpu 1:
>> > [ 171.439990] i915_request_await_dma_fence+0x162/0x520 [i915]
>> > [ 171.440230] i915_request_await_object+0x2fe/0x470 [i915]
>> > [ 171.440467] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
>> > [ 171.440704] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
>> > [ 171.440722] drm_ioctl_kernel+0xe4/0x120
>> > [ 171.440736] drm_ioctl+0x297/0x4c7
>> > [ 171.440750] ksys_ioctl+0x89/0xb0
>> > [ 171.440766] __x64_sys_ioctl+0x42/0x60
>> > [ 171.440788] do_syscall_64+0x6e/0x2c0
>> > [ 171.440802] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Mika Kuoppala
>> > ---
>> > drivers/gpu/drm/i915/i915_request.h | 7 +--
>> > 1 file changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_request.h
>> > b/drivers/gpu/drm/i915/i915_request.h
>> > index d4bae16b4785..6020d5b2a3df 100644
>> > --- a/drivers/gpu/drm/i915/i915_request.h
>> > +++ b/drivers/gpu/drm/i915/i915_request.h
>> > @@ -396,7 +396,9 @@ static inline bool i915_seqno_passed(u32 seq1, u32
>> > seq2)
>> >
>> > static inline u32 __hwsp_seqno(const struct i915_request *rq)
>> > {
>> > - return READ_ONCE(*rq->hwsp_seqno);
>> > + const u32 *hwsp = READ_ONCE(rq->hwsp_seqno);
>> > +
>> > + return READ_ONCE(*hwsp);
>>
>> This is good enough for decouple. But good enough for hardware
>> might be different thing.
>>
>> I am paranoid enough to wanting an rmb(), before the final
>> read once.
>
> What? [That pointer is nothing to do with HW; it's a pointer to a
> pointer to HW.]
But you do read the value through the pointer to hardware.
CPU:
rmb(); READ_ONCE(*hwsp);
GPU:
WRITE_ONCE(*hwsp, seqno), wmb(), interrupt -> cpu.
Thus on waking up, you would be guaranteed to see the
value gpu intended upon.
But as you say below, you want a cached value. And if
there is no reason to suspect the seqno vs int ordering,
I am fine with that.
-Mika
>
>> and clflush after.
>
> No. We want to keep the cached read around. If you are paranoid, you
> would put the clflush very carefully in the interrupt signalling.
>
>> If the hardware can't guarantee coherency in csb, why
>> would it in the different region in hwsp.
>
> It's the order of the writes that's the problem in icl. There's no such
> sequence here.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] drm/i915/display: conversion to drm_device based logging macros
Please ignore this, I seem to have some smtp trouble which fails some of tha patches. This will be incomplete. Wambui, I'll resend this later. BR, Jani. On Mon, 09 Mar 2020, Jani Nikula wrote: > Rebase of Wambui's series [1] to drm-tip, with a couple of manual > conversions included. > > BR, > Jani. > > [1] https://patchwork.freedesktop.org/series/72760/ > > > Wambui Karuga (10): > drm/i915/dsb: convert to drm_device based logging macros. > drm/i915/fbc: convert to drm_device based logging macros. > drm/i915/fbdev: convert to drm_device based logging. > drm/i915/fifo_underrun: convert to drm_device based logging. > drm/i915/gmbus: convert to drm_device based logging, > drm/i915/hdcp: convert to struct drm_device based logging. > drm/i915/hotplug: convert to drm_device based logging. > drm/i915/lpe_audio: convert to drm_device based logging macros. > drm/i915/lvds: convert to drm_device based logging macros. > drm/i915/overlay: convert to drm_device based logging. > > drivers/gpu/drm/i915/display/intel_dsb.c | 28 +++--- > drivers/gpu/drm/i915/display/intel_fbc.c | 30 +++--- > drivers/gpu/drm/i915/display/intel_fbdev.c| 96 +++ > .../drm/i915/display/intel_fifo_underrun.c| 29 +++--- > drivers/gpu/drm/i915/display/intel_gmbus.c| 33 --- > drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +- > drivers/gpu/drm/i915/display/intel_hotplug.c | 40 > .../gpu/drm/i915/display/intel_lpe_audio.c| 23 +++-- > drivers/gpu/drm/i915/display/intel_lvds.c | 43 + > drivers/gpu/drm/i915/display/intel_overlay.c | 11 ++- > 10 files changed, 195 insertions(+), 141 deletions(-) -- 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 00/10] drm/i915/display: conversion to drm_device based logging macros
Rebase of Wambui's series [1] to drm-tip, with a couple of manual conversions included. BR, Jani. [1] https://patchwork.freedesktop.org/series/72760/ Wambui Karuga (10): drm/i915/dsb: convert to drm_device based logging macros. drm/i915/fbc: convert to drm_device based logging macros. drm/i915/fbdev: convert to drm_device based logging. drm/i915/fifo_underrun: convert to drm_device based logging. drm/i915/gmbus: convert to drm_device based logging, drm/i915/hdcp: convert to struct drm_device based logging. drm/i915/hotplug: convert to drm_device based logging. drm/i915/lpe_audio: convert to drm_device based logging macros. drm/i915/lvds: convert to drm_device based logging macros. drm/i915/overlay: convert to drm_device based logging. drivers/gpu/drm/i915/display/intel_dsb.c | 28 +++--- drivers/gpu/drm/i915/display/intel_fbc.c | 30 +++--- drivers/gpu/drm/i915/display/intel_fbdev.c| 96 +++ .../drm/i915/display/intel_fifo_underrun.c| 29 +++--- drivers/gpu/drm/i915/display/intel_gmbus.c| 33 --- drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +- drivers/gpu/drm/i915/display/intel_hotplug.c | 40 .../gpu/drm/i915/display/intel_lpe_audio.c| 23 +++-- drivers/gpu/drm/i915/display/intel_lvds.c | 43 + drivers/gpu/drm/i915/display/intel_overlay.c | 11 ++- 10 files changed, 195 insertions(+), 141 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915/dsb: convert to drm_device based logging macros.
From: Wambui Karuga
This converts uses of the printk based drm logging macros to the struct
drm_device logging macros in i915/display/intel_dsb.c. This was done
using the following coccinelle script:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Signed-off-by: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dsb.c | 28 ++--
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 76ae01277fd6..d7a6bf2277df 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -52,7 +52,7 @@ static inline bool intel_dsb_enable_engine(struct intel_dsb
*dsb)
dsb_ctrl = intel_de_read(dev_priv, DSB_CTRL(pipe, dsb->id));
if (DSB_STATUS & dsb_ctrl) {
- DRM_DEBUG_KMS("DSB engine is busy.\n");
+ drm_dbg_kms(_priv->drm, "DSB engine is busy.\n");
return false;
}
@@ -72,7 +72,7 @@ static inline bool intel_dsb_disable_engine(struct intel_dsb
*dsb)
dsb_ctrl = intel_de_read(dev_priv, DSB_CTRL(pipe, dsb->id));
if (DSB_STATUS & dsb_ctrl) {
- DRM_DEBUG_KMS("DSB engine is busy.\n");
+ drm_dbg_kms(_priv->drm, "DSB engine is busy.\n");
return false;
}
@@ -115,20 +115,20 @@ intel_dsb_get(struct intel_crtc *crtc)
obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
if (IS_ERR(obj)) {
- DRM_ERROR("Gem object creation failed\n");
+ drm_err(>drm, "Gem object creation failed\n");
goto out;
}
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
if (IS_ERR(vma)) {
- DRM_ERROR("Vma creation failed\n");
+ drm_err(>drm, "Vma creation failed\n");
i915_gem_object_put(obj);
goto out;
}
buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
if (IS_ERR(buf)) {
- DRM_ERROR("Command buffer creation failed\n");
+ drm_err(>drm, "Command buffer creation failed\n");
goto out;
}
@@ -203,7 +203,7 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
i915_reg_t reg,
}
if (drm_WARN_ON(_priv->drm, dsb->free_pos >= DSB_BUF_SIZE)) {
- DRM_DEBUG_KMS("DSB buffer overflow\n");
+ drm_dbg_kms(_priv->drm, "DSB buffer overflow\n");
return;
}
@@ -277,7 +277,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
}
if (drm_WARN_ON(_priv->drm, dsb->free_pos >= DSB_BUF_SIZE)) {
- DRM_DEBUG_KMS("DSB buffer overflow\n");
+ drm_dbg_kms(_priv->drm, "DSB buffer overflow\n");
return;
}
@@ -310,7 +310,8 @@ void intel_dsb_commit(struct intel_dsb *dsb)
goto reset;
if (is_dsb_busy(dsb)) {
- DRM_ERROR("HEAD_PTR write failed - dsb engine is busy.\n");
+ drm_err(_priv->drm,
+ "HEAD_PTR write failed - dsb engine is busy.\n");
goto reset;
}
intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
@@ -322,15 +323,18 @@ void intel_dsb_commit(struct intel_dsb *dsb)
(tail - dsb->free_pos * 4));
if (is_dsb_busy(dsb)) {
- DRM_ERROR("TAIL_PTR write failed - dsb engine is busy.\n");
+ drm_err(_priv->drm,
+ "TAIL_PTR write failed - dsb engine is busy.\n");
goto reset;
}
- DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
- i915_ggtt_offset(dsb->vma), tail);
+ drm_dbg_kms(_priv->drm,
+ "DSB execution started - head 0x%x, tail 0x%x\n",
+ i915_ggtt_offset(dsb->vma), tail);
intel_de_write(dev_priv, DSB_TAIL(pipe, dsb->id),
i915_ggtt_offset(dsb->vma) + tail);
if (wait_for(!is_dsb_busy(dsb), 1)) {
- DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ drm_err(_priv->drm,
+ "Timed out waiting for
Re: [Intel-gfx] [PATCH] drm/i915: Mark racy read of intel_engine_cs.saturated
Chris Wilson writes: > [ 3783.276728] BUG: KCSAN: data-race in __i915_request_submit [i915] / > i915_request_await_dma_fence [i915] > [ 3783.276766] > [ 3783.276787] write to 0x8881f1bc60a0 of 1 bytes by interrupt on cpu 2: > [ 3783.277187] __i915_request_submit+0x47e/0x4a0 [i915] > [ 3783.277580] __execlists_submission_tasklet+0x997/0x2780 [i915] > [ 3783.277973] execlists_submission_tasklet+0xd3/0x170 [i915] > [ 3783.278006] tasklet_action_common.isra.0+0x42/0xa0 > [ 3783.278035] __do_softirq+0xd7/0x2cd > [ 3783.278063] irq_exit+0xbe/0xe0 > [ 3783.278089] do_IRQ+0x51/0x100 > [ 3783.278114] ret_from_intr+0x0/0x1c > [ 3783.278140] finish_task_switch+0x72/0x260 > [ 3783.278170] __schedule+0x1e5/0x510 > [ 3783.278198] schedule+0x45/0xb0 > [ 3783.278226] smpboot_thread_fn+0x23e/0x300 > [ 3783.278256] kthread+0x19a/0x1e0 > [ 3783.278283] ret_from_fork+0x1f/0x30 > [ 3783.278305] > [ 3783.278327] read to 0x8881f1bc60a0 of 1 bytes by task 19440 on cpu 3: > [ 3783.278724] i915_request_await_dma_fence+0x2a6/0x530 [i915] > [ 3783.279130] i915_request_await_object+0x2fe/0x470 [i915] > [ 3783.279524] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915] > [ 3783.279908] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] > [ 3783.279940] drm_ioctl_kernel+0xe4/0x120 > [ 3783.279968] drm_ioctl+0x297/0x4c7 > [ 3783.279996] ksys_ioctl+0x89/0xb0 > [ 3783.280021] __x64_sys_ioctl+0x42/0x60 > [ 3783.280047] do_syscall_64+0x6e/0x2c0 > [ 3783.280074] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_request.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 5de3989b6c4f..04b52bf347bf 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -907,7 +907,7 @@ already_busywaiting(struct i915_request *rq) >* >* See the are-we-too-late? check in __i915_request_submit(). >*/ > - return rq->sched.semaphores | rq->engine->saturated; > + return rq->sched.semaphores | READ_ONCE(rq->engine->saturated); This seem to be a one way ticket to saturation (until parking it is). Usually there should be the WRITE_ONCE counterpair! So now the question is that does it really matter if the race happens. As there is no other party at play inside driver and looks of it we just emit one semaphore extra if we get it wrong, Reviewed-by: Mika Kuoppala > } > > static int > -- > 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
== Series Details == Series: drm/i915: Mark up unlocked update of i915_request.hwsp_seqno URL : https://patchwork.freedesktop.org/series/74442/ State : success == Summary == CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16876_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16876_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd2.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_8097/shard-iclb6/igt@gem_exec_sched...@pi-common-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb7/igt@gem_exec_sched...@preempt-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-iclb1/igt@gem_exec_sched...@preempt-bsd.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [PASS][11] -> [INCOMPLETE][12] ([i915#58] / [k.org#198133]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-glk4/igt@gem_exec_whis...@basic-contexts-forked.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-glk5/igt@gem_exec_whis...@basic-contexts-forked.html * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-glk7/igt@gem_exec_whis...@basic-fds-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-glk2/igt@gem_exec_whis...@basic-fds-all.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-kbl7/igt@gem_soft...@noreloc-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-kbl4/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_dc@dc5-dpms: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#447]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-iclb2/igt@i915_pm...@dc5-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-iclb3/igt@i915_pm...@dc5-dpms.html * igt@kms_cursor_crc@pipe-b-cursor-128x42-onscreen: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-128x42-onscreen.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-128x42-onscreen.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#72]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-xtiled: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#52] / [i915#54]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/shard-skl2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-xtiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16876/shard-skl8/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-xtiled.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][25] -> [DMESG-WARN][26]
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark racy read of intel_engine_cs.saturated
== Series Details ==
Series: drm/i915: Mark racy read of intel_engine_cs.saturated
URL : https://patchwork.freedesktop.org/series/74455/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16882
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16882:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-1}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-ehl-1/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-ehl-1/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_16882 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([i915#92]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-skl-6770hq/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-skl-6770hq/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8700k: [PASS][5] -> [INCOMPLETE][6] ([i915#424])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2: [PASS][7] -> [FAIL][8] ([fdo#109635] / [i915#217])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-skl-6770hq: [PASS][9] -> [SKIP][10] ([fdo#109271]) +4 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-skl-6770hq: [PASS][11] -> [DMESG-WARN][12] ([i915#106])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Possible fixes
* igt@i915_selftest@live@gem_contexts:
- fi-skl-lmem:[INCOMPLETE][13] ([i915#424]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8097/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16882/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
Participating hosts (46 -> 43)
--
Additional (5): fi-glk-dsi fi-snb-2520m fi-elk-e7500 fi-bsw-kefka fi-tgl-y
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8097 -> Patchwork_16882
CI-20190529: 20190529
CI_DRM_8097: 2e46e269a2843c5d0b6c72bfb7fa9d9913c15415 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5499: 2e23cf6f63fc6ba1d9543f8327698d6f21813cec @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16882: 4b47cb86aa9e39ac563cf958a514f0949e63a901 @
[Intel-gfx] [PATCH] drm/i915/execlists: Mark up the racy access to switch_priority_hint
[ 7534.150687] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] /
process_csb [i915]
[ 7534.150706]
[ 7534.150717] write to 0x8881f1bc24b4 of 4 bytes by task 24404 on cpu 3:
[ 7534.150925] __execlists_submission_tasklet+0x1158/0x2780 [i915]
[ 7534.151133] execlists_submit_request+0x2e8/0x2f0 [i915]
[ 7534.151348] submit_notify+0x8f/0xc0 [i915]
[ 7534.151549] __i915_sw_fence_complete+0x5d/0x3e0 [i915]
[ 7534.151753] i915_sw_fence_complete+0x58/0x80 [i915]
[ 7534.151963] i915_sw_fence_commit+0x16/0x20 [i915]
[ 7534.152179] __i915_request_queue+0x60/0x70 [i915]
[ 7534.152388] i915_gem_do_execbuffer+0x3997/0x4c20 [i915]
[ 7534.152598] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 7534.152615] drm_ioctl_kernel+0xe4/0x120
[ 7534.152629] drm_ioctl+0x297/0x4c7
[ 7534.152642] ksys_ioctl+0x89/0xb0
[ 7534.152654] __x64_sys_ioctl+0x42/0x60
[ 7534.152667] do_syscall_64+0x6e/0x2c0
[ 7534.152681] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 7534.152693]
[ 7534.152703] read to 0x8881f1bc24b4 of 4 bytes by interrupt on cpu 2:
[ 7534.152914] process_csb+0xe7c/0x10a0 [i915]
[ 7534.153120] execlists_submission_tasklet+0x30/0x170 [i915]
[ 7534.153138] tasklet_action_common.isra.0+0x42/0xa0
[ 7534.153153] __do_softirq+0xd7/0x2cd
[ 7534.153166] run_ksoftirqd+0x15/0x20
[ 7534.153180] smpboot_thread_fn+0x1ab/0x300
[ 7534.153194] kthread+0x19a/0x1e0
[ 7534.153207] ret_from_fork+0x1f/0x30
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3eb7adc4e057..9890d248749e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1792,12 +1792,13 @@ timeslice(const struct intel_engine_cs *engine)
static unsigned long
active_timeslice(const struct intel_engine_cs *engine)
{
- const struct i915_request *rq = *engine->execlists.active;
+ const struct intel_engine_execlists *execlists = >execlists;
+ const struct i915_request *rq = *execlists->active;
if (!rq || i915_request_completed(rq))
return 0;
- if (engine->execlists.switch_priority_hint < effective_prio(rq))
+ if (READ_ONCE(execlists->switch_priority_hint) < effective_prio(rq))
return 0;
return timeslice(engine);
@@ -1814,8 +1815,11 @@ static void set_timeslice(struct intel_engine_cs *engine)
static void start_timeslice(struct intel_engine_cs *engine)
{
struct intel_engine_execlists *execlists = >execlists;
+ int prio = queue_prio(execlists);
- execlists->switch_priority_hint = execlists->queue_priority_hint;
+ WRITE_ONCE(execlists->switch_priority_hint, prio);
+ if (prio == INT_MIN)
+ return;
if (timer_pending(>timer))
return;
@@ -5342,10 +5346,10 @@ void intel_execlists_show_requests(struct
intel_engine_cs *engine,
if (execlists->switch_priority_hint != INT_MIN)
drm_printf(m, "\t\tSwitch priority hint: %d\n",
- execlists->switch_priority_hint);
+ READ_ONCE(execlists->switch_priority_hint));
if (execlists->queue_priority_hint != INT_MIN)
drm_printf(m, "\t\tQueue priority hint: %d\n",
- execlists->queue_priority_hint);
+ READ_ONCE(execlists->queue_priority_hint));
last = NULL;
count = 0;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
