Re: [Intel-gfx] [PATCH 2/4] drm/i915/uc: Reserve upper range of GGTT
Quoting Fernando Pacheco (2019-04-15 23:32:32)
>
> On 4/9/19 2:41 PM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-09 22:31:00)
> >> GuC and HuC depend on struct_mutex for device
> >> reinitialization. Moving away from this dependency
> >> requires perma-pinning the firmware images in GGTT.
> >> The upper portion of the GuC address space has
> >> a sizeable hole (several MB) that is inaccessible
> >> by GuC. Reserve this range within GGTT as it can
> >> comfortably hold GuC/HuC firmware images.
> >>
> >> Signed-off-by: Fernando Pacheco
> >> ---
> >> drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++---
> >> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
> >> drivers/gpu/drm/i915/intel_guc.h| 11 +++
> >> 3 files changed, 34 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> index 736c845eb77f..30f294a07e6d 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> @@ -2747,6 +2747,18 @@ int i915_gem_init_ggtt(struct drm_i915_private
> >> *dev_priv)
> >> if (ret)
> >> return ret;
> >>
> >> + /* Reserve a mappable slot for our lockless uC firmware load */
> >> + if (USES_GUC(dev_priv)) {
> >> + ret = drm_mm_insert_node_in_range(&ggtt->vm.mm,
> >> &ggtt->uc_fw,
> >> + GUC_GGTT_FW_SIZE, 0,
> >> + I915_COLOR_UNEVICTABLE,
> >> + GUC_GGTT_FW_START,
> >> + GUC_GGTT_FW_END,
> >> + DRM_MM_INSERT_LOW);
> > Use drm_mm_reserve_node() as you want an explicit address.
> >
> > We should be able to push this to guc init, with appropriate bailing if
> > something already took the high range.
>
> I tried pushing this to guc init, but this bailed immediately as there are
> pinnings between the calls to ggtt init and guc init. Did I misinterpret what
> you had in mind?
I was hoping we didn't... No worries, this reservation takes priority
and if that requires a hook here to call into guc so be it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 1/7] drm: Add gamma mode property
On Fri, Apr 12, 2019 at 03:50:57PM +0530, Uma Shankar wrote:
> From: Ville Syrjälä
>
> Add a gamma mode property to enable various kind of
> gamma modes supported by platforms like: Interpolated, Split,
> Multi Segmented etc. Userspace can get this property and
> should be able to get the platform capabilties wrt various
> gamma modes possible and the possible ranges.
>
> It can select one of the modes exposed as blob_id as an
> enum and set the respective mode.
>
> It can then create the LUT and send it to driver using
> already available GAMMA_LUT property as blob.
>
> v2: Addressed Sam Ravnborg's review comments. Implemented
> gamma mode with just one property and renamed the current
> one to GAMMA_MODE property as recommended by Ville.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Uma Shankar
Please also extend the CTM property docs, see
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#color-management-properties
And especially how GAMMA_MODE interacts with everything else we have
already. I think the current comments don't really explain well how this
is supposed to be used.
Also, since this is quite a complicated data structure, can't we do at
least some basic validation in the core code?
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 5 +++
> drivers/gpu/drm/drm_color_mgmt.c | 77
> +++
> include/drm/drm_color_mgmt.h | 8
> include/drm/drm_crtc.h| 7
> include/drm/drm_mode_config.h | 6 +++
> include/uapi/drm/drm_mode.h | 38 +++
> 6 files changed, 141 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index ea797d4..d85e0c9 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -459,6 +459,9 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == config->gamma_mode_property) {
> + state->gamma_mode = val;
> + state->color_mgmt_changed |= replaced;
> } else if (property == config->prop_out_fence_ptr) {
> s32 __user *fence_ptr = u64_to_user_ptr(val);
>
> @@ -495,6 +498,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> else if (property == config->prop_vrr_enabled)
> *val = state->vrr_enabled;
> + else if (property == config->gamma_mode_property)
> + *val = state->gamma_mode;
> else if (property == config->degamma_lut_property)
> *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
> else if (property == config->ctm_property)
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index d5d34d0..4d6792d 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -176,6 +176,83 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> }
> EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
>
> +void drm_crtc_attach_gamma_mode_property(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = &dev->mode_config;
> +
> + if (!config->gamma_mode_property)
> + return;
> +
> + drm_object_attach_property(&crtc->base,
> +config->gamma_mode_property, 0);
> +}
> +EXPORT_SYMBOL(drm_crtc_attach_gamma_mode_property);
> +
> +int drm_color_create_gamma_mode_property(struct drm_device *dev,
> + int num_values)
> +{
> + struct drm_mode_config *config = &dev->mode_config;
> + struct drm_property *prop;
> +
> + prop = drm_property_create(dev,
> +DRM_MODE_PROP_ENUM,
> +"GAMMA_MODE", num_values);
> + if (!prop)
> + return -ENOMEM;
> +
> + config->gamma_mode_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_color_create_gamma_mode_property);
> +
> +int drm_color_add_gamma_mode_range(struct drm_device *dev,
> +const char *name,
> +const struct drm_color_lut_range *ranges,
> +size_t length)
> +{
> + struct drm_mode_config *config = &dev->mode_config;
> + struct drm_property_blob *blob;
> + struct drm_property *prop;
> + int num_ranges = length / sizeof(ranges[0]);
> + int i, ret, num_types_0;
> +
> + if (WARN_ON(length == 0 || length % sizeof(ranges[0]) != 0))
> + return -EINVAL;
> +
> + num_types_0 = hweight8(ranges[0].flags & (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_DEGAMMA));
> + if (num_types_0 == 0)
> + return -EI
Re: [Intel-gfx] [PULL] gvt-next
I'm getting an error while pulling this, could you check it:
From https://github.com/intel/gvt-linux
* tag gvt-next-2019-04-09 -> FETCH_HEAD
dim: 66bd9f69d615 ("drm/i915/gvt: addressed guest GPU hang with HWS index
mode"): Fixes: SHA1 in not pointing at an ancestor:
dim: 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than
addresses")
dim: ERROR: issues in commits detected, aborting
Best Regards,
Joonas
Quoting Zhenyu Wang (2019-04-09 07:05:00)
>
> Hi,
>
> This includes various code refinement and cleanups, with proper
> async/sync display flip handling, and also some changes required
> for recent drm-intel-next as guest kernel, details below.
>
> Thanks
> --
> The following changes since commit a01b2c6f47d86c7d1a9fa822b3b91ec233b61784:
>
> drm/i915: Update DRIVER_DATE to 20190328 (2019-03-28 14:41:55 +0200)
>
> are available in the Git repository at:
>
> https://github.com/intel/gvt-linux.git tags/gvt-next-2019-04-09
>
> for you to fetch changes up to 201e3e8580bb4924d0cc29fc3841ea5782401b46:
>
> drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio list
> (2019-04-03 16:37:20 +0800)
>
>
> gvt-next-2019-04-09
>
> - Refine range of MCHBAR snapshot (Yakui)
> - Refine out-of-sync page struct (Yakui)
> - Remove unused vGPU sreg (Yan)
> - Refind MMIO reg names (Xiaolin)
> - Proper handling of sync/async flip (Colin)
> - Proper handling of PIPE_CONTROL/MI_FLUSH_DW index mode (Xiaolin)
> - EXCC reg mask fix (Colin)
>
>
> Colin Xu (5):
> drm/i915/gvt: Use consist max display pipe numbers as i915 definition
> drm/i915/gvt: Add macro define for mmio 0x50080 and gvt flip event
> drm/i915/gvt: Enable synchronous flip on handling MI_DISPLAY_FLIP
> drm/i915/gvt: Enable async flip on plane surface mmio writes
> drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio list
>
> Xiaolin Zhang (2):
> drm/i915/gvt: replaced register address with name
> drm/i915/gvt: addressed guest GPU hang with HWS index mode
>
> Yan Zhao (1):
> drm/i915/gvt: remove the unused sreg
>
> Zhao Yakui (2):
> drm/i915/gvt: Refine the snapshort range of I915 MCHBAR to optimize
> gvt-g boot time
> drm/i915/gvt: Refine the combined intel_vgpu_oos_page struct to save
> memory
>
> Zhenyu Wang (1):
> Merge tag 'drm-intel-next-2019-03-28' into gvt-next
>
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 30 +-
> drivers/gpu/drm/i915/gvt/display.c | 1 -
> drivers/gpu/drm/i915/gvt/gtt.c | 7 ++
> drivers/gpu/drm/i915/gvt/gtt.h | 2 +-
> drivers/gpu/drm/i915/gvt/gvt.h | 9 +-
> drivers/gpu/drm/i915/gvt/handlers.c | 159
> +++-
> drivers/gpu/drm/i915/gvt/mmio.c | 8 +-
> drivers/gpu/drm/i915/gvt/mmio_context.c | 4 +-
> drivers/gpu/drm/i915/gvt/reg.h | 34 +++
> 9 files changed, 172 insertions(+), 82 deletions(-)
>
>
> --
> Open Source Technology Center, Intel ltd.
>
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/12] drm/fb-helper: Avoid race with DRM userspace
On Sun, Apr 07, 2019 at 06:52:33PM +0200, Noralf Trønnes wrote:
> drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
> This is done by looking at the fb on the primary plane. By the time
> fb-helper gets around to committing, it's possible that the facts have
> changed.
>
> Avoid this race by holding the drm_device->master_mutex lock while
> committing. When DRM userspace does its first open, it will now wait
> until fb-helper is done. The helper will stay away if there's a master.
>
> Locking rule: Always take the fb-helper lock first.
>
> v2:
> - Remove drm_fb_helper_is_bound() (Daniel Vetter)
> - No need to check fb_helper->dev->master in
> drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_auth.c | 20
> drivers/gpu/drm/drm_fb_helper.c | 90 -
> drivers/gpu/drm/drm_internal.h | 2 +
> 3 files changed, 67 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index 1669c42c40ed..db199807b7dc 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -368,3 +368,23 @@ void drm_master_put(struct drm_master **master)
> *master = NULL;
> }
> EXPORT_SYMBOL(drm_master_put);
> +
> +/* Used by drm_client and drm_fb_helper */
> +bool drm_master_internal_acquire(struct drm_device *dev)
> +{
> + mutex_lock(&dev->master_mutex);
> + if (dev->master) {
> + mutex_unlock(&dev->master_mutex);
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_master_internal_acquire);
> +
> +/* Used by drm_client and drm_fb_helper */
> +void drm_master_internal_release(struct drm_device *dev)
> +{
> + mutex_unlock(&dev->master_mutex);
> +}
> +EXPORT_SYMBOL(drm_master_internal_release);
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 84791dd4a90d..a6be09ae899b 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -44,6 +44,7 @@
>
> #include "drm_crtc_internal.h"
> #include "drm_crtc_helper_internal.h"
> +#include "drm_internal.h"
>
> static bool drm_fbdev_emulation = true;
> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
> @@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper
> *fb_helper)
> return ret;
> }
>
> -static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> +static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
Bikeshed: usually the function variant that's run with locks already taken
is called _locked or has a __ prefix. _force feels a bit misplaced.
> {
> struct drm_device *dev = fb_helper->dev;
>
> @@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
> *fb_helper)
> return restore_fbdev_mode_legacy(fb_helper);
> }
>
> +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> +{
> + struct drm_device *dev = fb_helper->dev;
> + int ret;
> +
> + if (!drm_master_internal_acquire(dev))
> + return -EBUSY;
> +
> + ret = restore_fbdev_mode_force(fb_helper);
> +
> + drm_master_internal_release(dev);
> +
> + return ret;
> +}
> +
> /**
> * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> * @fb_helper: driver-allocated fbdev helper, can be NULL
> @@ -556,34 +572,6 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper)
> }
> EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
>
> -static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
> -{
> - struct drm_device *dev = fb_helper->dev;
> - struct drm_crtc *crtc;
> - int bound = 0, crtcs_bound = 0;
> -
> - /*
> - * Sometimes user space wants everything disabled, so don't steal the
> - * display if there's a master.
> - */
> - if (READ_ONCE(dev->master))
> - return false;
> -
> - drm_for_each_crtc(crtc, dev) {
> - drm_modeset_lock(&crtc->mutex, NULL);
> - if (crtc->primary->fb)
> - crtcs_bound++;
> - if (crtc->primary->fb == fb_helper->fb)
> - bound++;
> - drm_modeset_unlock(&crtc->mutex);
> - }
> -
> - if (bound < crtcs_bound)
> - return false;
> -
> - return true;
> -}
> -
> #ifdef CONFIG_MAGIC_SYSRQ
> /*
> * restore fbcon display for all kms driver's using this helper, used for
> sysrq
> @@ -604,7 +592,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
> continue;
>
> mutex_lock(&helper->lock);
> - ret = restore_fbdev_mode(helper);
> + ret = restore_fbdev_mode_force(helper);
I'd leave this as-is, because:
a) I'm too lazy to review the locking of our open/close calls to convince
myself that la
[Intel-gfx] [PATCH v2 4/4] drm/i915/selftests: Verify whitelist of context registers
The RING_NONPRIV allows us to add registers to a whitelist that allows
userspace to modify them. Ideally such registers should be safe and
saved within the context such that they do not impact system behaviour
for other users. This selftest verifies that those registers we do add
are (a) then writable by userspace and (b) only affect a single client.
Opens:
- Is GEN9_SLICE_COMMON_ECO_CHICKEN1 really write-only?
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
.../drm/i915/selftests/intel_workarounds.c| 320 ++
1 file changed, 320 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index a363748a7a4f..56799f3538f9 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -700,6 +700,325 @@ static int live_reset_whitelist(void *arg)
return err;
}
+static int read_whitelisted_registers(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct i915_vma *results)
+{
+ intel_wakeref_t wakeref;
+ struct i915_request *rq;
+ u32 srm, *cs;
+ int err, i;
+
+ rq = ERR_PTR(-ENODEV);
+ with_intel_runtime_pm(engine->i915, wakeref)
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ err = i915_vma_move_to_active(results, rq, EXEC_OBJECT_WRITE);
+ if (err)
+ goto err_req;
+
+ srm = MI_STORE_REGISTER_MEM;
+ if (INTEL_GEN(ctx->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * engine->whitelist.count);
+ if (IS_ERR(cs)) {
+ err = PTR_ERR(cs);
+ goto err_req;
+ }
+
+ for (i = 0; i < engine->whitelist.count; i++) {
+ u64 offset = results->node.start + sizeof(u32) * i;
+
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ *cs++ = lower_32_bits(offset);
+ *cs++ = upper_32_bits(offset);
+ }
+ intel_ring_advance(rq, cs);
+
+err_req:
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0)
+ err = -EIO;
+
+ return err;
+}
+
+static int scrub_whitelisted_registers(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ intel_wakeref_t wakeref;
+ struct i915_request *rq;
+ struct i915_vma *batch;
+ int i, err;
+ u32 *cs;
+
+ batch = create_batch(ctx);
+ if (IS_ERR(batch))
+ return PTR_ERR(batch);
+
+ cs = i915_gem_object_pin_map(batch->obj, I915_MAP_WC);
+ if (IS_ERR(cs)) {
+ err = PTR_ERR(cs);
+ goto err_batch;
+ }
+
+ *cs++ = MI_LOAD_REGISTER_IMM(engine->whitelist.count);
+ for (i = 0; i < engine->whitelist.count; i++) {
+ *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ *cs++ = 0x;
+ }
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_flush_map(batch->obj);
+ i915_gem_chipset_flush(ctx->i915);
+
+ rq = ERR_PTR(-ENODEV);
+ with_intel_runtime_pm(engine->i915, wakeref)
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq))
+ goto err_unpin;
+
+ if (engine->emit_init_breadcrumb) { /* Be nice if we hang */
+ err = engine->emit_init_breadcrumb(rq);
+ if (err)
+ goto err_request;
+ }
+
+ err = engine->emit_bb_start(rq, batch->node.start, 0, 0);
+
+err_request:
+ i915_request_add(rq);
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0)
+ err = -EIO;
+
+err_unpin:
+ i915_gem_object_unpin_map(batch->obj);
+err_batch:
+ i915_vma_unpin_and_release(&batch, 0);
+ return err;
+}
+
+static bool pardon_reg(struct drm_i915_private *i915, i915_reg_t reg)
+{
+ /* Alas, we must pardon some whitelists */
+ static const struct {
+ i915_reg_t reg;
+ unsigned long gen_mask;
+ } pardon[] = {
+ { GEN9_CTX_PREEMPT_REG, INTEL_GEN_MASK(9, 9) },
+ { GEN8_L3SQCREG4, INTEL_GEN_MASK(9, 9) },
+ };
+ u32 offset = i915_mmio_reg_offset(reg);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pardon); i++) {
+ if (INTEL_INFO(i915)->gen_mask & pardon[i].gen_mask &&
+ i915_mmio_reg_offset(pardon[i].reg) == offset)
+ return true;
+ }
+
+ return false;
+}
+
+static int eq_whitelisted_registers(struct i915_vma *A,
+ struct i915_vma *B,
+ struct intel_engine_cs *engine)
+{
+ u32 *a, *b;
+ int i, err;
+
+
[Intel-gfx] [PATCH v2 2/4] drm/i915: Verify the engine workarounds stick on application
Read the engine workarounds back using the GPU after loading the initial
context state to verify that we are setting them correctly, and bail if
it fails.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 6 +
drivers/gpu/drm/i915/intel_workarounds.c | 120 ++
drivers/gpu/drm/i915/intel_workarounds.h | 2 +
.../drm/i915/selftests/intel_workarounds.c| 53 +---
4 files changed, 134 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a818a60ad31..95ae69753e91 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4717,6 +4717,12 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
i915_request_add(rq);
if (err)
goto err_active;
+
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) &&
+ intel_engine_verify_workarounds(engine, "load")) {
+ err = -EIO;
+ goto err_active;
+ }
}
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 1c54b5030807..db99f2e676bb 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1259,6 +1259,126 @@ void intel_engine_apply_workarounds(struct
intel_engine_cs *engine)
wa_list_apply(engine->uncore, &engine->wa_list);
}
+static struct i915_vma *
+create_scratch(struct i915_address_space *vm, int count)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ unsigned int size;
+ int err;
+
+ size = round_up(count * 4, PAGE_SIZE);
+ obj = i915_gem_object_create_internal(vm->i915, size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_obj;
+ }
+
+ err = i915_vma_pin(vma, 0, 0,
+ i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+ if (err)
+ goto err_obj;
+
+ return vma;
+
+err_obj:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+wa_list_srm(struct i915_request *rq,
+ const struct i915_wa_list *wal,
+ struct i915_vma *vma)
+{
+ const struct i915_wa *wa;
+ u32 srm, *cs;
+ int i;
+
+ srm = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (INTEL_GEN(rq->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * wal->count);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(wa->reg);
+ *cs++ = i915_ggtt_offset(vma) + sizeof(u32) * i;
+ *cs++ = 0;
+ }
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int engine_wa_list_verify(struct intel_engine_cs *engine,
+const struct i915_wa_list * const wal,
+const char *from)
+{
+ const struct i915_wa *wa;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ unsigned int i;
+ u32 *results;
+ int err;
+
+ if (!wal->count)
+ return 0;
+
+ vma = create_scratch(&engine->i915->ggtt.vm, wal->count);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ rq = i915_request_alloc(engine, engine->kernel_context->gem_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_vma;
+ }
+
+ err = wa_list_srm(rq, wal, vma);
+ if (err)
+ goto err_vma;
+
+ i915_request_add(rq);
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0) {
+ err = -ETIME;
+ goto err_vma;
+ }
+
+ results = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);
+ if (IS_ERR(results)) {
+ err = PTR_ERR(results);
+ goto err_vma;
+ }
+
+ err = 0;
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
+ if (!wa_verify(wa, results[i], wal->name, from))
+ err = -ENXIO;
+
+ i915_gem_object_unpin_map(vma->obj);
+
+err_vma:
+ i915_vma_unpin(vma);
+ i915_vma_put(vma);
+ return err;
+}
+
+int intel_engine_verify_workarounds(struct intel_engine_cs *engine,
+ const char *from)
+{
+ return engine_wa_list_verify(engine, &engine->wa_list, from);
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/intel_workarounds.c"
#endif
[Intel-gfx] [PATCH v2 1/4] drm/i915: Verify workarounds immediately after application
Immediately after writing the workaround, verify that it stuck in the
register.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 32 +---
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index ccaf63679435..1c54b5030807 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -913,6 +913,20 @@ wal_get_fw_for_rmw(struct intel_uncore *uncore, const
struct i915_wa_list *wal)
return fw;
}
+static bool
+wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
+{
+ if ((cur ^ wa->val) & wa->mask) {
+ DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
+ name, from, i915_mmio_reg_offset(wa->reg), cur,
+ cur & wa->mask, wa->val, wa->mask);
+
+ return false;
+ }
+
+ return true;
+}
+
static void
wa_list_apply(struct intel_uncore *uncore, const struct i915_wa_list *wal)
{
@@ -931,6 +945,10 @@ wa_list_apply(struct intel_uncore *uncore, const struct
i915_wa_list *wal)
for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
intel_uncore_rmw_fw(uncore, wa->reg, wa->mask, wa->val);
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ wa_verify(wa,
+ intel_uncore_read_fw(uncore, wa->reg),
+ wal->name, "applictation");
}
intel_uncore_forcewake_put__locked(uncore, fw);
@@ -942,20 +960,6 @@ void intel_gt_apply_workarounds(struct drm_i915_private
*i915)
wa_list_apply(&i915->uncore, &i915->gt_wa_list);
}
-static bool
-wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
-{
- if ((cur ^ wa->val) & wa->mask) {
- DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
- name, from, i915_mmio_reg_offset(wa->reg), cur,
- cur & wa->mask, wa->val, wa->mask);
-
- return false;
- }
-
- return true;
-}
-
static bool wa_list_verify(struct intel_uncore *uncore,
const struct i915_wa_list *wal,
const char *from)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915: Make workaround verification *optional*
Sometimes the HW doesn't even play fair, and completely forgets about
register writes. Skip verifying known troublemakers.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 40 ++-
.../gpu/drm/i915/intel_workarounds_types.h| 7 ++--
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index db99f2e676bb..ba58be05f58c 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -122,6 +122,7 @@ static void _wa_add(struct i915_wa_list *wal, const struct
i915_wa *wa)
wal->wa_count++;
wa_->val |= wa->val;
wa_->mask |= wa->mask;
+ wa_->read |= wa->read;
return;
}
}
@@ -146,9 +147,10 @@ wa_write_masked_or(struct i915_wa_list *wal, i915_reg_t
reg, u32 mask,
u32 val)
{
struct i915_wa wa = {
- .reg = reg,
+ .reg = reg,
.mask = mask,
- .val = val
+ .val = val,
+ .read = mask,
};
_wa_add(wal, &wa);
@@ -172,6 +174,19 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32
val)
wa_write_masked_or(wal, reg, val, val);
}
+static void
+ignore_wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 mask, u32 val)
+{
+ struct i915_wa wa = {
+ .reg = reg,
+ .mask = mask,
+ .val = val,
+ /* Bonkers HW, skip verifying */
+ };
+
+ _wa_add(wal, &wa);
+}
+
#define WA_SET_BIT_MASKED(addr, mask) \
wa_write_masked_or(wal, (addr), (mask), _MASKED_BIT_ENABLE(mask))
@@ -916,10 +931,11 @@ wal_get_fw_for_rmw(struct intel_uncore *uncore, const
struct i915_wa_list *wal)
static bool
wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
{
- if ((cur ^ wa->val) & wa->mask) {
+ if ((cur ^ wa->val) & wa->read) {
DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
- name, from, i915_mmio_reg_offset(wa->reg), cur,
- cur & wa->mask, wa->val, wa->mask);
+ name, from, i915_mmio_reg_offset(wa->reg),
+ cur, cur & wa->read,
+ wa->val, wa->mask);
return false;
}
@@ -1122,9 +1138,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
_3D_CHICKEN3_AA_LINE_QUALITY_FIX_ENABLE);
/* WaPipelineFlushCoherentLines:icl */
- wa_write_or(wal,
- GEN8_L3SQCREG4,
- GEN8_LQSC_FLUSH_COHERENT_LINES);
+ ignore_wa_write_or(wal,
+ GEN8_L3SQCREG4,
+ GEN8_LQSC_FLUSH_COHERENT_LINES,
+ GEN8_LQSC_FLUSH_COHERENT_LINES);
/*
* Wa_1405543622:icl
@@ -1151,9 +1168,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
* Wa_1405733216:icl
* Formerly known as WaDisableCleanEvicts
*/
- wa_write_or(wal,
- GEN8_L3SQCREG4,
- GEN11_LQSC_CLEAN_EVICT_DISABLE);
+ ignore_wa_write_or(wal,
+ GEN8_L3SQCREG4,
+ GEN11_LQSC_CLEAN_EVICT_DISABLE,
+ GEN11_LQSC_CLEAN_EVICT_DISABLE);
/* WaForwardProgressSoftReset:icl */
wa_write_or(wal,
diff --git a/drivers/gpu/drm/i915/intel_workarounds_types.h
b/drivers/gpu/drm/i915/intel_workarounds_types.h
index 30918da180ff..42ac1fb99572 100644
--- a/drivers/gpu/drm/i915/intel_workarounds_types.h
+++ b/drivers/gpu/drm/i915/intel_workarounds_types.h
@@ -12,9 +12,10 @@
#include "i915_reg.h"
struct i915_wa {
- i915_reg_treg;
- u32 mask;
- u32 val;
+ i915_reg_t reg;
+ u32 mask;
+ u32 val;
+ u32 read;
};
struct i915_wa_list {
--
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: Enable workaround for pixel shader dispatch hang
Quoting Mika Kuoppala (2019-04-15 15:45:29)
> Set chicken bits to workaround a possible pixel shader
> dispatch hang.
>
> v2: no need to filter out preprod skl (Ville, Chris)
> v3: formatting
>
> Bspec: 14091, ID#0651
> Cc: Chris Wilson
> Cc: Ville Syrjälä
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_workarounds.c | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c1c0f7ab03e9..499cc843443d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8902,11 +8902,15 @@ enum {
> #define GEN7_ROW_CHICKEN2_GT2 _MMIO(0xf4f4)
> #define DOP_CLOCK_GATING_DISABLE (1 << 0)
> #define PUSH_CONSTANT_DEREF_DISABLE (1 << 8)
> +#define GEN8_DISABLE_RR_ARBITRATION (1 << 1)
> #define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
>
> #define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
> #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
>
> +#define GEN8_ROW_CHICKEN4 _MMIO(0xe48c)
> +#define GEN8_DISABLE_TDL_FIX (1 << 3)
> +
> #define HALF_SLICE_CHICKEN2_MMIO(0xe180)
> #define GEN8_ST_PO_DISABLE (1 << 13)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index ccaf63679435..b4709de49552 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -294,6 +294,10 @@ static void gen9_ctx_workarounds_init(struct
> intel_engine_cs *engine)
> FLOW_CONTROL_ENABLE |
> PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
>
> + /* Bspec wa: 0651, disable rr arb and enable tdl fix */
> + WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN8_DISABLE_RR_ARBITRATION);
> + WA_CLR_BIT_MASKED(GEN8_ROW_CHICKEN4, GEN8_DISABLE_TDL_FIX);
In your first patch, you had this only applying to Skylake. Is that
still the case? i.e. do we need if (IS_SKYLAKE()) { ... }
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ehl: inherit icl cdclk init/uninit
The cdclk init/uninit code was changed by commit 93a643f29bcb
("drm/i915/cdclk: have only one init/uninit function") between the
versions of commit 39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake
conditional code"). What got merged fails to do cdclk init/uninit on
ehl.
Fixes: 39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake conditional code")
Cc: José Roberto de Souza
Cc: Lucas De Marchi
Cc: Bob Paauwe
Cc: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_cdclk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 7f060ea..ae40a86 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2034,7 +2034,7 @@ static void cnl_uninit_cdclk(struct drm_i915_private
*dev_priv)
*/
void intel_cdclk_init(struct drm_i915_private *i915)
{
- if (IS_ICELAKE(i915))
+ if (INTEL_GEN(i915) >= 11)
icl_init_cdclk(i915);
else if (IS_CANNONLAKE(i915))
cnl_init_cdclk(i915);
@@ -2053,7 +2053,7 @@ void intel_cdclk_init(struct drm_i915_private *i915)
*/
void intel_cdclk_uninit(struct drm_i915_private *i915)
{
- if (IS_ICELAKE(i915))
+ if (INTEL_GEN(i915) >= 11)
icl_uninit_cdclk(i915);
else if (IS_CANNONLAKE(i915))
cnl_uninit_cdclk(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/12] drm/fb-helper: Remove drm_fb_helper_crtc
On Sun, Apr 07, 2019 at 06:52:37PM +0200, Noralf Trønnes wrote:
> It now only contains the modeset so use that directly instead and attach
> a modeset array to drm_client_dev. drm_fb_helper will use this array.
> Code will later be moved to drm_client, so add code there in a new file
> drm_client_modeset.c with MIT license to match drm_fb_helper.c.
>
> The modeset connector array size is hardcoded for the cloned case to avoid
> having to pass in a value from the driver. A value of 8 is chosen to err
> on the safe side. This means that the max connector argument for
> drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore,
> a todo entry for this is added.
>
> In pan_display_atomic() restore_fbdev_mode_force() is used instead of
> restore_fbdev_mode_atomic() because that one will later become internal
> to drm_client_modeset.
>
> Locking order:
> 1. drm_fb_helper->lock
> 2. drm_master_internal_acquire
> 3. drm_client_dev->modeset_mutex
>
> v2:
> - Add modesets array to drm_client (Daniel Vetter)
> - Use a new file for the modeset code (Daniel Vetter)
> - File has to be MIT licensed (Emmanuel Vadot)
> - Add copyrights from drm_fb_helper.c
>
> Signed-off-by: Noralf Trønnes
> ---
> Documentation/gpu/todo.rst | 7 +
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_client.c | 10 +-
> drivers/gpu/drm/drm_client_modeset.c | 102 +
> drivers/gpu/drm/drm_fb_helper.c | 301 +++
> include/drm/drm_client.h | 28 +++
> include/drm/drm_fb_helper.h | 8 -
> 7 files changed, 272 insertions(+), 186 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_client_modeset.c
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 1528ad2d598b..8fa08b5feab7 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -300,6 +300,13 @@ it to use drm_mode_hsync() instead.
>
> Contact: Sean Paul
>
> +drm_fb_helper cleanup tasks
> +---
> +
> +- The max connector argument for drm_fb_helper_init() and
> + drm_fb_helper_fbdev_setup() isn't used anymore and can be removed.
> +
> +
> Core refactorings
> =
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 6c7e8d162b4e..08c77c10ccbb 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -19,7 +19,7 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> - drm_atomic_uapi.o
> + drm_client_modeset.o drm_atomic_uapi.o
>
> drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> drm-$(CONFIG_DRM_VM) += drm_vm.o
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 9b2bd28dde0a..3ad5b57c1419 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -91,14 +91,20 @@ int drm_client_init(struct drm_device *dev, struct
> drm_client_dev *client,
> client->name = name;
> client->funcs = funcs;
>
> - ret = drm_client_open(client);
> + ret = drm_client_modeset_create(client);
> if (ret)
> goto err_put_module;
>
> + ret = drm_client_open(client);
> + if (ret)
> + goto err_free;
> +
> drm_dev_get(dev);
>
> return 0;
>
> +err_free:
> + drm_client_modeset_free(client);
> err_put_module:
> if (funcs)
> module_put(funcs->owner);
> @@ -147,6 +153,8 @@ void drm_client_release(struct drm_client_dev *client)
>
> DRM_DEV_DEBUG_KMS(dev->dev, "%s\n", client->name);
>
> + drm_client_modeset_release(client);
> + drm_client_modeset_free(client);
> drm_client_close(client);
> drm_dev_put(dev);
> if (client->funcs)
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> new file mode 100644
> index ..bb34222c9db8
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright 2018 Noralf Trønnes
> + * Copyright (c) 2006-2009 Red Hat Inc.
> + * Copyright (c) 2006-2008 Intel Corporation
> + * Jesse Barnes
> + * Copyright (c) 2007 Dave Airlie
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/* Used by drm_client and drm_fb_helper */
> +int drm_client_modeset_create(struct drm_client_dev *client)
> +{
> + struct drm_device *dev = client->dev;
> + unsigned int num_crtc = dev->mode_config.num_crtc;
> + unsigned int max_connector_count = 1;
> + struct drm_mode_set *modeset;
> + struct drm_crtc *crtc;
> + unsigned int i = 0;
> +
> + /* Add terminating zero entry to enable index less iteration */
> + client->modesets = kcalloc(num_cr
Re: [Intel-gfx] [PATCH v2 08/12] drm/fb-helper: Move out commit code
On Sun, Apr 07, 2019 at 06:52:39PM +0200, Noralf Trønnes wrote:
> Move the modeset commit code to drm_client_modeset.
> No changes except exporting API.
>
> v2: Move to drm_client_modeset.c instead of drm_client.c
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_client_modeset.c | 287 +++
Please add a new chapter in Documentation/gpu to pull in all the nice new
kerneldoc you've typed.
> drivers/gpu/drm/drm_fb_helper.c | 282 --
> include/drm/drm_client.h | 4 +
> 3 files changed, 291 insertions(+), 282 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index bb34222c9db8..94b52f97c06b 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -11,9 +11,14 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> +#include
> +
> +#include "drm_crtc_internal.h"
> +#include "drm_internal.h"
>
> /* Used by drm_client and drm_fb_helper */
> int drm_client_modeset_create(struct drm_client_dev *client)
> @@ -100,3 +105,285 @@ struct drm_mode_set *drm_client_find_modeset(struct
> drm_client_dev *client, stru
> }
> /* TODO: Remove export when modeset code has been moved over */
> EXPORT_SYMBOL(drm_client_find_modeset);
> +
> +/**
> + * drm_client_panel_rotation() - Check panel orientation
> + * @modeset: DRM modeset
> + * @rotation: Returned rotation value
> + *
> + * This function checks if the primary plane in @modeset can hw rotate to
> match
> + * the panel orientation on its connector.
> + *
> + * Note: Currently only 0 and 180 degrees are supported.
> + *
> + * Return:
> + * True if the plane can do the rotation, false otherwise.
> + */
> +bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int
> *rotation)
> +{
> + struct drm_connector *connector = modeset->connectors[0];
> + struct drm_plane *plane = modeset->crtc->primary;
> + u64 valid_mask = 0;
> + unsigned int i;
> +
> + if (!modeset->num_connectors)
> + return false;
> +
> + switch (connector->display_info.panel_orientation) {
> + case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
> + *rotation = DRM_MODE_ROTATE_180;
> + break;
> + case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
> + *rotation = DRM_MODE_ROTATE_90;
> + break;
> + case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
> + *rotation = DRM_MODE_ROTATE_270;
> + break;
> + default:
> + *rotation = DRM_MODE_ROTATE_0;
> + }
> +
> + /*
> + * TODO: support 90 / 270 degree hardware rotation,
> + * depending on the hardware this may require the framebuffer
> + * to be in a specific tiling format.
> + */
> + if (*rotation != DRM_MODE_ROTATE_180 || !plane->rotation_property)
> + return false;
> +
> + for (i = 0; i < plane->rotation_property->num_values; i++)
> + valid_mask |= (1ULL << plane->rotation_property->values[i]);
> +
> + if (!(*rotation & valid_mask))
> + return false;
> +
> + return true;
> +}
> +
> +static int drm_client_modeset_commit_atomic(struct drm_client_dev *client,
> bool active)
> +{
> + struct drm_device *dev = client->dev;
> + struct drm_plane_state *plane_state;
> + struct drm_plane *plane;
> + struct drm_atomic_state *state;
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_mode_set *mode_set;
> + int ret;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> +
> + state = drm_atomic_state_alloc(dev);
> + if (!state) {
> + ret = -ENOMEM;
> + goto out_ctx;
> + }
> +
> + state->acquire_ctx = &ctx;
> +retry:
> + drm_for_each_plane(plane, dev) {
> + plane_state = drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state)) {
> + ret = PTR_ERR(plane_state);
> + goto out_state;
> + }
> +
> + plane_state->rotation = DRM_MODE_ROTATE_0;
> +
> + /* disable non-primary: */
> + if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> + continue;
> +
> + ret = __drm_atomic_helper_disable_plane(plane, plane_state);
> + if (ret != 0)
> + goto out_state;
> + }
> +
> + drm_client_for_each_modeset(mode_set, client) {
> + struct drm_plane *primary = mode_set->crtc->primary;
> + unsigned int rotation;
> +
> + if (drm_client_panel_rotation(mode_set, &rotation)) {
> + /* Cannot fail as we've already gotten the plane state
> above */
> + plane_state = drm_atomic_get_new_plane_state(state,
> primary);
> + plane_state->rotation = rotation;
> + }
> +
> + ret = __drm_atomic_helper_set_config(mode_set, st
Re: [Intel-gfx] [PATCH v2 00/12] drm/fb-helper: Move modesetting code to drm_client
On Sun, Apr 07, 2019 at 06:52:31PM +0200, Noralf Trønnes wrote:
> This moves the modesetting code from drm_fb_helper to drm_client so it
> can be shared by all internal clients.
>
> The main change this time is to attach the modeset array to
> drm_client_dev and honour the drm_fb_helper MIT license. I've dropped
> the display abstraction.
>
> Noralf.
>
> Cc: Emmanuel Vadot
>
> Noralf Trønnes (12):
> drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
> drm/fb-helper: Avoid race with DRM userspace
> drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper
> drm/fb-helper: No need to cache rotation and sw_rotations
> drm/fb-helper: Remove drm_fb_helper_crtc->{x,y,desired_mode}
> drm/fb-helper: Remove drm_fb_helper_crtc
> drm/fb-helper: Prepare to move out commit code
> drm/fb-helper: Move out commit code
> drm/fb-helper: Remove drm_fb_helper_connector
> drm/fb-helper: Prepare to move out modeset config code
> drm/fb-helper: Move out modeset config code
> drm/client: Hack: Add bootsplash example
I like.
Reviewed some of the prep patches, plus some more suggestions for
drm_client_modeset api polishing ideas.
Maxime is working on some other fbdev helper features and your two patch
series will conflict badly I think. Probably best if you coordinate and
cross-review for final details and best coordination for merging into
drm-misc-next.
I think for the bootsplash good option would be to add it as a todo item,
with a link to patch of your latest proof of concept.
Cheers, Daniel
>
> Documentation/gpu/todo.rst | 10 +
> drivers/gpu/drm/Kconfig |5 +
> drivers/gpu/drm/Makefile |3 +-
> drivers/gpu/drm/drm_atomic.c | 168
> drivers/gpu/drm/drm_atomic_helper.c | 164
> drivers/gpu/drm/drm_auth.c | 20 +
> drivers/gpu/drm/drm_bootsplash.c | 359
> drivers/gpu/drm/drm_client.c | 17 +-
> drivers/gpu/drm/drm_client_modeset.c | 1086 +++
> drivers/gpu/drm/drm_crtc_internal.h |5 +
> drivers/gpu/drm/drm_drv.c|4 +
> drivers/gpu/drm/drm_fb_helper.c | 1195 +++---
> drivers/gpu/drm/drm_internal.h |2 +
> drivers/gpu/drm/i915/intel_fbdev.c | 218 -
> include/drm/drm_atomic_helper.h |4 -
> include/drm/drm_client.h | 48 ++
> include/drm/drm_fb_helper.h | 125 +--
> 17 files changed, 1859 insertions(+), 1574 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_bootsplash.c
> create mode 100644 drivers/gpu/drm/drm_client_modeset.c
>
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/12] drm/fb-helper: Move modesetting code to drm_client
On Tue, Apr 16, 2019 at 10:41:06AM +0200, Daniel Vetter wrote:
> On Sun, Apr 07, 2019 at 06:52:31PM +0200, Noralf Trønnes wrote:
> > This moves the modesetting code from drm_fb_helper to drm_client so it
> > can be shared by all internal clients.
> >
> > The main change this time is to attach the modeset array to
> > drm_client_dev and honour the drm_fb_helper MIT license. I've dropped
> > the display abstraction.
> >
> > Noralf.
> >
> > Cc: Emmanuel Vadot
> >
> > Noralf Trønnes (12):
> > drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
> > drm/fb-helper: Avoid race with DRM userspace
> > drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper
> > drm/fb-helper: No need to cache rotation and sw_rotations
> > drm/fb-helper: Remove drm_fb_helper_crtc->{x,y,desired_mode}
> > drm/fb-helper: Remove drm_fb_helper_crtc
> > drm/fb-helper: Prepare to move out commit code
> > drm/fb-helper: Move out commit code
> > drm/fb-helper: Remove drm_fb_helper_connector
> > drm/fb-helper: Prepare to move out modeset config code
> > drm/fb-helper: Move out modeset config code
> > drm/client: Hack: Add bootsplash example
>
> I like.
>
> Reviewed some of the prep patches, plus some more suggestions for
> drm_client_modeset api polishing ideas.
>
> Maxime is working on some other fbdev helper features and your two patch
> series will conflict badly I think. Probably best if you coordinate and
> cross-review for final details and best coordination for merging into
> drm-misc-next.
https://marc.info/?l=linux-arm-kernel&m=155498898611173&w=2
is what I meant.
-Daniel
>
> I think for the bootsplash good option would be to add it as a todo item,
> with a link to patch of your latest proof of concept.
>
> Cheers, Daniel
>
> >
> > Documentation/gpu/todo.rst | 10 +
> > drivers/gpu/drm/Kconfig |5 +
> > drivers/gpu/drm/Makefile |3 +-
> > drivers/gpu/drm/drm_atomic.c | 168
> > drivers/gpu/drm/drm_atomic_helper.c | 164
> > drivers/gpu/drm/drm_auth.c | 20 +
> > drivers/gpu/drm/drm_bootsplash.c | 359
> > drivers/gpu/drm/drm_client.c | 17 +-
> > drivers/gpu/drm/drm_client_modeset.c | 1086 +++
> > drivers/gpu/drm/drm_crtc_internal.h |5 +
> > drivers/gpu/drm/drm_drv.c|4 +
> > drivers/gpu/drm/drm_fb_helper.c | 1195 +++---
> > drivers/gpu/drm/drm_internal.h |2 +
> > drivers/gpu/drm/i915/intel_fbdev.c | 218 -
> > include/drm/drm_atomic_helper.h |4 -
> > include/drm/drm_client.h | 48 ++
> > include/drm/drm_fb_helper.h | 125 +--
> > 17 files changed, 1859 insertions(+), 1574 deletions(-)
> > create mode 100644 drivers/gpu/drm/drm_bootsplash.c
> > create mode 100644 drivers/gpu/drm/drm_client_modeset.c
> >
> > --
> > 2.20.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Fill in obj.offset for spinner resubmission
When resubmitting the spinner, fill in the expected offset so that we
are not tempted to relocate it across contexts (as the spinner must
point back to itself for the MI_BB_START to work). In this case, these
should work correctly as they are reusing the same active vma, but for
pedagogy we should dtrt.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_exec_schedule.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 29653ae24..6f3f52d20 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -223,12 +223,9 @@ static void independent(int fd, unsigned int engine)
if (spin == NULL) {
spin = __igt_spin_batch_new(fd, .engine = other);
} else {
- struct drm_i915_gem_exec_object2 obj = {
- .handle = spin->handle,
- };
struct drm_i915_gem_execbuffer2 eb = {
.buffer_count = 1,
- .buffers_ptr = to_user_pointer(&obj),
+ .buffers_ptr = to_user_pointer(&spin->obj[1]),
.flags = other,
};
gem_execbuf(fd, &eb);
@@ -621,12 +618,9 @@ static igt_spin_t *__noise(int fd, uint32_t ctx, int prio,
igt_spin_t *spin)
.ctx = ctx,
.engine = other);
} else {
- struct drm_i915_gem_exec_object2 obj = {
- .handle = spin->handle,
- };
struct drm_i915_gem_execbuffer2 eb = {
.buffer_count = 1,
- .buffers_ptr = to_user_pointer(&obj),
+ .buffers_ptr = to_user_pointer(&spin->obj[1]),
.rsvd1 = ctx,
.flags = other,
};
--
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: Drop bool return from breadcrumbs signaler
Since removal of the "missed interrupt detection" bobody used the result
of whether or not we signaled anybody during that invocation, so now
remove the return value.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 09ed90c0ba00..3cbffd400b1b 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -27,8 +27,6 @@
#include "i915_drv.h"
-#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL && !(tsk)->on_rq)
-
static void irq_enable(struct intel_engine_cs *engine)
{
if (!engine->irq_enable)
@@ -82,7 +80,7 @@ static inline bool __request_completed(const struct
i915_request *rq)
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
}
-bool intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
+void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
struct intel_context *ce, *cn;
@@ -146,19 +144,13 @@ bool intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
dma_fence_signal(&rq->fence);
i915_request_put(rq);
}
-
- return !list_empty(&signal);
}
-bool intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine)
+void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine)
{
- bool result;
-
local_irq_disable();
- result = intel_engine_breadcrumbs_irq(engine);
+ intel_engine_breadcrumbs_irq(engine);
local_irq_enable();
-
- return result;
}
static void signal_irq_work(struct irq_work *work)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 4b33e88eabb1..72c7c337ace9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -388,7 +388,7 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine);
void intel_engine_pin_breadcrumbs_irq(struct intel_engine_cs *engine);
void intel_engine_unpin_breadcrumbs_irq(struct intel_engine_cs *engine);
-bool intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine);
+void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
static inline void
@@ -397,7 +397,7 @@ intel_engine_queue_breadcrumbs(struct intel_engine_cs
*engine)
irq_work_queue(&engine->breadcrumbs.irq_work);
}
-bool intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine);
+void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine);
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 6/7] drm: Add Client Cap for advance gamma mode
mån 2019-04-15 klockan 15:43 +0300 skrev Ville Syrjälä: > On Mon, Apr 15, 2019 at 10:57:52AM +, Lankhorst, Maarten wrote: > > fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar: > > > Introduced a client cap for advance cap mode > > > capability. Userspace should set this to get > > > to be able to use the new gamma_mode property. > > > > > > If this is not set, driver will work in legacy > > > mode. > > > > > > Suggested-by: Ville Syrjälä > > > Signed-off-by: Uma Shankar > > > > Nack, this doesn't seem like a sensible idea. We already guard it > > behind the gamma mode property. Userspace shouldn't set the gamma > > mode > > to a value it doesn't understand. > > Old userspace wouldn't know what a gamma_mode prop is. While a client > cap isn't an entirely satisfactory solution I can't think of a better > way at the moment. > > Well, maybe the old "hey kernel, please reset all my props to some > sane default" idea could be another way to deal with this sort of > stuff. Yes, but this approach wouldn't work, lot of other properties that can cause problems when not reset, like plane alpha and blend mode. I don't see why gamma is special in that case. If userspace did set it to some special value, then presumably it knows how to reset it too. It would be different if the split gamma mode was the default. Then I would understand this, but right now this would even break s/r. ~Maarten smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next
On 2019.04.16 10:29:03 +0300, Joonas Lahtinen wrote:
> I'm getting an error while pulling this, could you check it:
>
> From https://github.com/intel/gvt-linux
>* tag gvt-next-2019-04-09 -> FETCH_HEAD
> dim: 66bd9f69d615 ("drm/i915/gvt: addressed guest GPU hang with HWS index
> mode"): Fixes: SHA1 in not pointing at an ancestor:
> dim: 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than
> addresses")
> dim: ERROR: issues in commits detected, aborting
>
Sorry for this, I applied gvt change earlier than back-merge one, which caused
this.
Now generated new one, pls help to pull.
Thanks.
--
The following changes since commit 28d618e9ab86f26a31af0b235ced55beb3e343c8:
drm/i915: Update DRIVER_DATE to 20190404 (2019-04-04 17:43:58 +0300)
are available in the Git repository at:
https://github.com/intel/gvt-linux.git tags/gvt-next-2019-04-16
for you to fetch changes up to 2bfc4975083ace0e5777116514c3a75e59b3dbcd:
drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio list
(2019-04-16 16:52:51 +0800)
gvt-next-2019-04-16
- Refine range of MCHBAR snapshot (Yakui)
- Refine out-of-sync page struct (Yakui)
- Remove unused vGPU sreg (Yan)
- Refind MMIO reg names (Xiaolin)
- Proper handling of sync/async flip (Colin)
- Proper handling of PIPE_CONTROL/MI_FLUSH_DW index mode (Xiaolin)
- EXCC reg mask fix (Colin)
Colin Xu (5):
drm/i915/gvt: Use consist max display pipe numbers as i915 definition
drm/i915/gvt: Add macro define for mmio 0x50080 and gvt flip event
drm/i915/gvt: Enable synchronous flip on handling MI_DISPLAY_FLIP
drm/i915/gvt: Enable async flip on plane surface mmio writes
drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio list
Xiaolin Zhang (2):
drm/i915/gvt: replaced register address with name
drm/i915/gvt: addressed guest GPU hang with HWS index mode
Yan Zhao (1):
drm/i915/gvt: remove the unused sreg
Zhao Yakui (2):
drm/i915/gvt: Refine the snapshort range of I915 MCHBAR to optimize gvt-g
boot time
drm/i915/gvt: Refine the combined intel_vgpu_oos_page struct to save
memory
Zhenyu Wang (1):
Merge tag 'drm-intel-next-2019-04-04' into gvt-next
drivers/gpu/drm/i915/gvt/cmd_parser.c | 30 +-
drivers/gpu/drm/i915/gvt/display.c | 1 -
drivers/gpu/drm/i915/gvt/gtt.c | 7 ++
drivers/gpu/drm/i915/gvt/gtt.h | 2 +-
drivers/gpu/drm/i915/gvt/gvt.h | 9 +-
drivers/gpu/drm/i915/gvt/handlers.c | 159 +++-
drivers/gpu/drm/i915/gvt/mmio.c | 8 +-
drivers/gpu/drm/i915/gvt/mmio_context.c | 4 +-
drivers/gpu/drm/i915/gvt/reg.h | 34 +++
9 files changed, 172 insertions(+), 82 deletions(-)
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 05/13] drivers: create binary sysfs for class
On Mon, Apr 15, 2019 at 09:14:12PM +0200, Daniel Vetter wrote: > On Mon, Apr 15, 2019 at 8:01 PM Greg Kroah-Hartman > wrote: > > On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote: > > > On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote: > > > > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote: > > > > > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote: > > > > > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote: > > > > > > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote: > > > > > > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote: > > > > > > > > > Functions to create and remove the binary sysfs for class are > > > > > > > > > added. > > > > > > > > > > > > > > > > > > These are getting introduced as DRM wants to create the > > > > > > > > > common binary > > > > > > > > > sysfs across the drm subsystem to handle hdcp srm. > > > > > > > > > > > > > > > > Why do you need individual files? That's almost always a sign > > > > > > > > that you > > > > > > > > are going to race with userspace in a bad way. Why not just > > > > > > > > use an > > > > > > > > attribute group which provides automatic support for this? > > > > > > > Greg, > > > > > > > > > > > > > > Reason behind this move is to have a common srm entry path across > > > > > > > all drm > > > > > > > drivers. And the data fed into this is binary blob. So I am > > > > > > > creating a > > > > > > > binary sysfs "hdcp_srm" at /sys/class/drm/ > > > > > > > > > > > > Ah, you want to have a file in your class directory, not your class > > > > > > device directory. > > > > > > > > > > > > No, please do not do that. There's a reason I got rid of those same > > > > > > types of apis in the past. > > > > > > > > > > > > And "binary blobs" are horrid anyway, they are only to be used as a > > > > > > pass-through to the device itself, from the kernel, no touching the > > > > > > data > > > > > > at all. If you really need/want this, then put it in the device's > > > > > > directory as that is where the data is going to, not the kernel > > > > > > "class" > > > > > > code as it sure as heck better not be doing anything with it. > > > > > Greg, > > > > > > > > > > But here the parsing of the received binary blob is done outside the > > > > > drm > > > > > device/cards. This will be generic code for all drm cardx(drivers). > > > > > And > > > > > this will provide the service helper functions to the drm drivers for > > > > > HDCP SRM checking. > > > > > > > > Again, the kernel is NOT to be parsing any binary data that comes > > > > through a sysfs file. If you need such a crazy thing, do it through > > > > your normal drm ioctl. > > > > > > > > > So we prefer to have the binary sysfs at /sys/class/drm/ than inside > > > > > the > > > > > cardx folders, so that it will be generic. Could you please suggest a > > > > > way to achieve that? > > > > > > > > What is a "cardx" driver? > > > Meant card0 card1 etc.. Drm drivers. > > > > Why can you not do it in a device-specific > > > > location? Are suddenly _ALL_ DRM drivers going to need this > > > > information? What is the use case? Who is going to be providing this > > > > blob and where is it going? What in the kernel uses it? What on the > > > > hardware uses it? What is it actually? > > > > > > This is for HDCP usecase. List of compromised receivers' ID called system > > > renewability Message (SRM) will be available at userspace which needs to > > > be passed to be kernel. And this data can be parsed at kernel used > > > across all DRM drivers to implement the HDCP authentication. Hence we > > > want generic code to parse the SRM data and provide a helper function to > > > all DRM drivers to validate their HDCP sink's ID. > > > > > > To achieve this we want to keep the sysfs and parsing logic outside the > > > drm drivers at the class level. > > > > > > At present I915 will be using these implementation. in future other DRM > > > drivers can use the same. > > > > Again, binary sysfs files are not for any data that the kernel has to > > parse at all. So do not use sysfs for this. > > So what's the recommend thing then? > - requrest_firmware blob could work, aside that the blob might change > (the point of this to allow updates). For some hw you can even stuff > the SRM into some eprom iirc, so not entirely misfit. Plus kernel > parses it, so not sure request_firmware is really the right thing. I think it is, as this really looks like "firmware" to me as you are wanting to do something with the buffer and pass it on. > - configfs? I never used that one, but the transactional config stuff > this provides feels like silly amounts of overkill Maybe, but why do you want to stuf binary data in your kernel in the first place? It is configuration, right, why not have it in a format that you can easily handle it in? Or is that the binary format you have? > - procfs :-) Hah, no. > - ioctl it definitely isn
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915: Make PSR registers relative to transcoders
On Mon, 15 Apr 2019, José Roberto de Souza wrote:
> PSR registers are a mess, some have the full address while others just
> have the additional offset from psr_mmio_base.
>
> psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET + 0x800 and
> using it makes more difficult for people with an PSR register address
> from BSpec to search the register name in i915 as also the BSpec name
> don't match with the name in i915.
>
> The other option would be use the whole hard-coded address but this is
> not future proof, so here going in the middle ground by making every
> PSR register relative to transcoder(that is EDP transcoder), the only
> exception is PSR_IMR/IIR that is not relative to nothing.
> For the _TRANS2() macros to work it needs the address of the register
> from the TRANSCODER_A, so adding it to every register together with
> the register address from the EDP transcoder so it will make easy for
> people searching with BSpec address also adding those with the BSpec
> name.
>
> For Haswell all the PSR register are relative to 0x64000, so
> mmio_base_adjust was added and used to take care of that.
>
> Also removing BDW_EDP_PSR_BASE from GVT because it is not used as
> the only PSR register that GVT have is this one(SRD/PSR_CTL).
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 1 -
> drivers/gpu/drm/i915/i915_drv.h | 5 +--
> drivers/gpu/drm/i915/i915_reg.h | 52 -
> drivers/gpu/drm/i915/intel_psr.c| 11 --
> 4 files changed, 48 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 86761b1def1e..d09b798e93cb 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -2739,7 +2739,6 @@ static int init_broadwell_mmio_info(struct intel_gvt
> *gvt)
> MMIO_D(CHICKEN_PIPESL_1(PIPE_C), D_BDW_PLUS);
>
> MMIO_D(WM_MISC, D_BDW);
> - MMIO_D(_MMIO(BDW_EDP_PSR_BASE), D_BDW);
>
> MMIO_D(_MMIO(0x6671c), D_BDW_PLUS);
> MMIO_D(_MMIO(0x66c00), D_BDW_PLUS);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 35d0782c077e..a9666290f0b8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -494,6 +494,8 @@ struct i915_drrs {
> };
>
> struct i915_psr {
> + /* different than zero only on HSW see _TRANS2_PSR() for more info */
> + u32 mmio_base_adjust;
> struct mutex lock;
>
> #define I915_PSR_DEBUG_MODE_MASK 0x0f
> @@ -508,6 +510,7 @@ struct i915_psr {
> bool enabled;
> struct intel_dp *dp;
> enum pipe pipe;
> + enum transcoder transcoder;
> bool active;
> struct work_struct work;
> unsigned busy_frontbuffer_bits;
> @@ -1534,8 +1537,6 @@ struct drm_i915_private {
> /* MMIO base address for MIPI regs */
> u32 mipi_mmio_base;
>
> - u32 psr_mmio_base;
> -
> u32 pps_mmio_base;
>
> wait_queue_head_t gmbus_wait_queue;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 36420af2cd6f..094bd19abb35 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4213,9 +4213,15 @@ enum {
> #define PIPE_MULT(trans) _MMIO_TRANS2(trans, _PIPE_MULT_A)
>
> /* HSW+ eDP PSR registers */
> -#define HSW_EDP_PSR_BASE 0x64800
> -#define BDW_EDP_PSR_BASE 0x6f800
> -#define EDP_PSR_CTL _MMIO(dev_priv->psr_mmio_base +
> 0)
> +#define HSW_EDP_PSR_BASE 0x64000
> +
> +/* PSR registers on HSW is not relative to eDP transcoder */
> +#define _TRANS2_PSR(reg) (_TRANS2(dev_priv->psr.transcoder, (reg)) -
> dev_priv->psr.mmio_base_adjust)
> +#define _MMIO_TRANS2_PSR(reg)_MMIO(_TRANS2_PSR(reg))
I really think this kind of macros should be at the top next to all the
indexing macros. I understand the desire to put them where they're used,
but having them at the top gives you a better idea what's available and
what to pick for the next use and what could be abstracted.
BR,
Jani.
> +
> +#define _SRD_CTL_A 0x60800
> +#define _SRD_CTL_EDP 0x6F800
> +#define EDP_PSR_CTL _MMIO_TRANS2_PSR(_SRD_CTL_A)
> #define EDP_PSR_ENABLE (1 << 31)
> #define BDW_PSR_SINGLE_FRAME (1 << 30)
> #define EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK(1 << 29) /* SW can't
> modify */
> @@ -4248,16 +4254,22 @@ enum {
> #define EDP_PSR_POST_EXIT (1 << 1)
> #define EDP_PSR_PRE_ENTRY (1 << 0)
>
> -#define EDP_PSR_AUX_CTL
> _MMIO(dev_priv->psr_mmio_base + 0x10)
> +#define _SRD_AUX_CTL_A 0x60810
> +#define _SRD_AUX_CTL_EDP 0x6F810
> +#
Re: [Intel-gfx] [PATCH] drm/i915: Drop bool return from breadcrumbs signaler
On 16/04/2019 09:52, Chris Wilson wrote:
Since removal of the "missed interrupt detection" bobody used the result
of whether or not we signaled anybody during that invocation, so now
remove the return value.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 09ed90c0ba00..3cbffd400b1b 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -27,8 +27,6 @@
#include "i915_drv.h"
-#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL && !(tsk)->on_rq)
-
static void irq_enable(struct intel_engine_cs *engine)
{
if (!engine->irq_enable)
@@ -82,7 +80,7 @@ static inline bool __request_completed(const struct
i915_request *rq)
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
}
-bool intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
+void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
struct intel_context *ce, *cn;
@@ -146,19 +144,13 @@ bool intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
dma_fence_signal(&rq->fence);
i915_request_put(rq);
}
-
- return !list_empty(&signal);
}
-bool intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine)
+void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine)
{
- bool result;
-
local_irq_disable();
- result = intel_engine_breadcrumbs_irq(engine);
+ intel_engine_breadcrumbs_irq(engine);
local_irq_enable();
-
- return result;
}
static void signal_irq_work(struct irq_work *work)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 4b33e88eabb1..72c7c337ace9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -388,7 +388,7 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine);
void intel_engine_pin_breadcrumbs_irq(struct intel_engine_cs *engine);
void intel_engine_unpin_breadcrumbs_irq(struct intel_engine_cs *engine);
-bool intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine);
+void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
static inline void
@@ -397,7 +397,7 @@ intel_engine_queue_breadcrumbs(struct intel_engine_cs
*engine)
irq_work_queue(&engine->breadcrumbs.irq_work);
}
-bool intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine);
+void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine);
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] [v3] drm/i915: Introduce vfunc intel_get_color_config to create hw lut
On Mon, 15 Apr 2019, Swati Sharma wrote:
> v3: Rebase
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/intel_color.c | 7 +++
> drivers/gpu/drm/i915/intel_color.h | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 63eca30..69ed05c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -342,6 +342,7 @@ struct drm_i915_display_funcs {
>* involved with the same commit.
>*/
> void (*load_luts)(const struct intel_crtc_state *crtc_state);
> + void (*get_color_config)(struct intel_crtc_state *crtc_state);
> };
>
> #define CSR_VERSION(major, minor)((major) << 16 | (minor))
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index ca341a9..321cf52 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -857,6 +857,13 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
> return dev_priv->display.color_check(crtc_state);
> }
>
> +void intel_get_color_config(struct intel_crtc_state *crtc_state)
Please call it intel_color_get_config.
Going forward, I'm going to push towards prefixing functions based on
the source filename. intel_foo.c -> intel_foo_bar().
You're not using this function anywhere... you only add that in patch
10/11. I'd rather see you add the user early on, and add the support
platform by platform incrementally.
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> +
> + dev_priv->display.get_color_config(crtc_state);
I.e. wrap this in if (dev_priv->display.get_color_config) and you'll be
able to call the function right away, regardless of the platform.
BR,
Jani.
> +}
> +
> static bool need_plane_update(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state)
> {
> diff --git a/drivers/gpu/drm/i915/intel_color.h
> b/drivers/gpu/drm/i915/intel_color.h
> index b8a3ce6..7ca304f 100644
> --- a/drivers/gpu/drm/i915/intel_color.h
> +++ b/drivers/gpu/drm/i915/intel_color.h
> @@ -13,5 +13,6 @@
> int intel_color_check(struct intel_crtc_state *crtc_state);
> void intel_color_commit(const struct intel_crtc_state *crtc_state);
> void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
> +void intel_get_color_config(struct intel_crtc_state *crtc_state);
>
> #endif /* __INTEL_COLOR_H__ */
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Verify whitelist of context registers
The RING_NONPRIV allows us to add registers to a whitelist that allows
userspace to modify them. Ideally such registers should be safe and
saved within the context such that they do not impact system behaviour
for other users. This selftest verifies that those registers we do add
are (a) then writable by userspace and (b) only affect a single client.
Opens:
- Is GEN9_SLICE_COMMON_ECO_CHICKEN1 really write-only?
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Compile fix for writeonly_reg()
---
.../drm/i915/selftests/intel_workarounds.c| 320 ++
1 file changed, 320 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index a363748a7a4f..f40e0937ec96 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -700,6 +700,325 @@ static int live_reset_whitelist(void *arg)
return err;
}
+static int read_whitelisted_registers(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct i915_vma *results)
+{
+ intel_wakeref_t wakeref;
+ struct i915_request *rq;
+ u32 srm, *cs;
+ int err, i;
+
+ rq = ERR_PTR(-ENODEV);
+ with_intel_runtime_pm(engine->i915, wakeref)
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ err = i915_vma_move_to_active(results, rq, EXEC_OBJECT_WRITE);
+ if (err)
+ goto err_req;
+
+ srm = MI_STORE_REGISTER_MEM;
+ if (INTEL_GEN(ctx->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * engine->whitelist.count);
+ if (IS_ERR(cs)) {
+ err = PTR_ERR(cs);
+ goto err_req;
+ }
+
+ for (i = 0; i < engine->whitelist.count; i++) {
+ u64 offset = results->node.start + sizeof(u32) * i;
+
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ *cs++ = lower_32_bits(offset);
+ *cs++ = upper_32_bits(offset);
+ }
+ intel_ring_advance(rq, cs);
+
+err_req:
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0)
+ err = -EIO;
+
+ return err;
+}
+
+static int scrub_whitelisted_registers(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ intel_wakeref_t wakeref;
+ struct i915_request *rq;
+ struct i915_vma *batch;
+ int i, err;
+ u32 *cs;
+
+ batch = create_batch(ctx);
+ if (IS_ERR(batch))
+ return PTR_ERR(batch);
+
+ cs = i915_gem_object_pin_map(batch->obj, I915_MAP_WC);
+ if (IS_ERR(cs)) {
+ err = PTR_ERR(cs);
+ goto err_batch;
+ }
+
+ *cs++ = MI_LOAD_REGISTER_IMM(engine->whitelist.count);
+ for (i = 0; i < engine->whitelist.count; i++) {
+ *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ *cs++ = 0x;
+ }
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_flush_map(batch->obj);
+ i915_gem_chipset_flush(ctx->i915);
+
+ rq = ERR_PTR(-ENODEV);
+ with_intel_runtime_pm(engine->i915, wakeref)
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq))
+ goto err_unpin;
+
+ if (engine->emit_init_breadcrumb) { /* Be nice if we hang */
+ err = engine->emit_init_breadcrumb(rq);
+ if (err)
+ goto err_request;
+ }
+
+ err = engine->emit_bb_start(rq, batch->node.start, 0, 0);
+
+err_request:
+ i915_request_add(rq);
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0)
+ err = -EIO;
+
+err_unpin:
+ i915_gem_object_unpin_map(batch->obj);
+err_batch:
+ i915_vma_unpin_and_release(&batch, 0);
+ return err;
+}
+
+static bool pardon_reg(struct drm_i915_private *i915, i915_reg_t reg)
+{
+ /* Alas, we must pardon some whitelists */
+ static const struct {
+ i915_reg_t reg;
+ unsigned long gen_mask;
+ } pardon[] = {
+ { GEN9_CTX_PREEMPT_REG, INTEL_GEN_MASK(9, 9) },
+ { GEN8_L3SQCREG4, INTEL_GEN_MASK(9, 9) },
+ };
+ u32 offset = i915_mmio_reg_offset(reg);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pardon); i++) {
+ if (INTEL_INFO(i915)->gen_mask & pardon[i].gen_mask &&
+ i915_mmio_reg_offset(pardon[i].reg) == offset)
+ return true;
+ }
+
+ return false;
+}
+
+static int eq_whitelisted_registers(struct i915_vma *A,
+ struct i915_vma *B,
+ struct intel_engine_cs *engine)
+{
+ u32
Re: [Intel-gfx] [PATCH 10/11] [v2] drm/i915: Enable intel_get_color_config()
On Mon, 15 Apr 2019, Swati Sharma wrote:
> Signed-off-by: Swati Sharma
Please add a commit message, and make this patch #2 in the series after
the changes I suggested in patch #1.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f29a348..0fc9dab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8275,6 +8275,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->cgm_mode = I915_READ(CGM_PIPE_MODE(crtc->pipe));
>
> i9xx_get_pipe_color_config(pipe_config);
> + intel_get_color_config(pipe_config);
>
> if (INTEL_GEN(dev_priv) < 4)
> pipe_config->double_wide = tmp & PIPECONF_DOUBLE_WIDE;
> @@ -9348,6 +9349,7 @@ static bool ironlake_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->csc_mode = I915_READ(PIPE_CSC_MODE(crtc->pipe));
>
> i9xx_get_pipe_color_config(pipe_config);
> + intel_get_color_config(pipe_config);
>
> if (I915_READ(PCH_TRANSCONF(crtc->pipe)) & TRANS_ENABLE) {
> struct intel_shared_dpll *pll;
> @@ -10011,6 +10013,7 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->csc_enable = true;
> } else {
> i9xx_get_pipe_color_config(pipe_config);
> + intel_get_color_config(pipe_config);
> }
>
> power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Verify workarounds immediately after application
On 16/04/2019 09:10, Chris Wilson wrote:
Immediately after writing the workaround, verify that it stuck in the
register.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 32 +---
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index ccaf63679435..1c54b5030807 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -913,6 +913,20 @@ wal_get_fw_for_rmw(struct intel_uncore *uncore, const
struct i915_wa_list *wal)
return fw;
}
+static bool
+wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
+{
+ if ((cur ^ wa->val) & wa->mask) {
+ DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
+ name, from, i915_mmio_reg_offset(wa->reg), cur,
+ cur & wa->mask, wa->val, wa->mask);
+
+ return false;
+ }
+
+ return true;
+}
+
static void
wa_list_apply(struct intel_uncore *uncore, const struct i915_wa_list *wal)
{
@@ -931,6 +945,10 @@ wa_list_apply(struct intel_uncore *uncore, const struct
i915_wa_list *wal)
for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
intel_uncore_rmw_fw(uncore, wa->reg, wa->mask, wa->val);
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ wa_verify(wa,
+ intel_uncore_read_fw(uncore, wa->reg),
+ wal->name, "applictation");
application
}
intel_uncore_forcewake_put__locked(uncore, fw);
@@ -942,20 +960,6 @@ void intel_gt_apply_workarounds(struct drm_i915_private
*i915)
wa_list_apply(&i915->uncore, &i915->gt_wa_list);
}
-static bool
-wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
-{
- if ((cur ^ wa->val) & wa->mask) {
- DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
- name, from, i915_mmio_reg_offset(wa->reg), cur,
- cur & wa->mask, wa->val, wa->mask);
-
- return false;
- }
-
- return true;
-}
-
static bool wa_list_verify(struct intel_uncore *uncore,
const struct i915_wa_list *wal,
const char *from)
With the typo fixed:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/gem_exec_schedule: Fill in obj.offset for spinner resubmission
== Series Details == Series: i915/gem_exec_schedule: Fill in obj.offset for spinner resubmission URL : https://patchwork.freedesktop.org/series/59564/ State : success == Summary == CI Bug Log - changes from IGT_4949 -> IGTPW_2862 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59564/revisions/1/mbox/ Known issues Here are the changes found in IGTPW_2862 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-whl-u: NOTRUN -> SKIP [fdo#109271] +41 * igt@debugfs_test@read_all_entries: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-whl-u: NOTRUN -> FAIL [fdo#103375] +1 * igt@kms_psr@cursor_plane_move: - fi-whl-u: NOTRUN -> FAIL [fdo#107383] +3 Possible fixes * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: FAIL [fdo#103167] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107383]: https://bugs.freedesktop.org/show_bug.cgi?id=107383 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (49 -> 38) -- Additional (1): fi-whl-u Missing(12): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-icl-y fi-bdw-samus fi-byt-clapper fi-skl-6700k2 Build changes - * IGT: IGT_4949 -> IGTPW_2862 CI_DRM_5936: 0ad14bd30d830a1a355040b29bfafbe6623d84f0 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_2862: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2862/ IGT_4949: 2bd82477a9ee6aa308e0f1045df4901f766683ea @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2862/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 05/13] drivers: create binary sysfs for class
On Tue, Apr 16, 2019 at 11:04 AM Greg Kroah-Hartman wrote: > On Mon, Apr 15, 2019 at 09:14:12PM +0200, Daniel Vetter wrote: > > On Mon, Apr 15, 2019 at 8:01 PM Greg Kroah-Hartman > > wrote: > > > On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote: > > > > On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote: > > > > > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote: > > > > > > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote: > > > > > > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote: > > > > > > > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote: > > > > > > > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote: > > > > > > > > > > Functions to create and remove the binary sysfs for class > > > > > > > > > > are added. > > > > > > > > > > > > > > > > > > > > These are getting introduced as DRM wants to create the > > > > > > > > > > common binary > > > > > > > > > > sysfs across the drm subsystem to handle hdcp srm. > > > > > > > > > > > > > > > > > > Why do you need individual files? That's almost always a > > > > > > > > > sign that you > > > > > > > > > are going to race with userspace in a bad way. Why not just > > > > > > > > > use an > > > > > > > > > attribute group which provides automatic support for this? > > > > > > > > Greg, > > > > > > > > > > > > > > > > Reason behind this move is to have a common srm entry path > > > > > > > > across all drm > > > > > > > > drivers. And the data fed into this is binary blob. So I am > > > > > > > > creating a > > > > > > > > binary sysfs "hdcp_srm" at /sys/class/drm/ > > > > > > > > > > > > > > Ah, you want to have a file in your class directory, not your > > > > > > > class > > > > > > > device directory. > > > > > > > > > > > > > > No, please do not do that. There's a reason I got rid of those > > > > > > > same > > > > > > > types of apis in the past. > > > > > > > > > > > > > > And "binary blobs" are horrid anyway, they are only to be used as > > > > > > > a > > > > > > > pass-through to the device itself, from the kernel, no touching > > > > > > > the data > > > > > > > at all. If you really need/want this, then put it in the device's > > > > > > > directory as that is where the data is going to, not the kernel > > > > > > > "class" > > > > > > > code as it sure as heck better not be doing anything with it. > > > > > > Greg, > > > > > > > > > > > > But here the parsing of the received binary blob is done outside > > > > > > the drm > > > > > > device/cards. This will be generic code for all drm cardx(drivers). > > > > > > And > > > > > > this will provide the service helper functions to the drm drivers > > > > > > for HDCP SRM checking. > > > > > > > > > > Again, the kernel is NOT to be parsing any binary data that comes > > > > > through a sysfs file. If you need such a crazy thing, do it through > > > > > your normal drm ioctl. > > > > > > > > > > > So we prefer to have the binary sysfs at /sys/class/drm/ than > > > > > > inside the > > > > > > cardx folders, so that it will be generic. Could you please suggest > > > > > > a way to achieve that? > > > > > > > > > > What is a "cardx" driver? > > > > Meant card0 card1 etc.. Drm drivers. > > > > > Why can you not do it in a device-specific > > > > > location? Are suddenly _ALL_ DRM drivers going to need this > > > > > information? What is the use case? Who is going to be providing this > > > > > blob and where is it going? What in the kernel uses it? What on the > > > > > hardware uses it? What is it actually? > > > > > > > > This is for HDCP usecase. List of compromised receivers' ID called > > > > system > > > > renewability Message (SRM) will be available at userspace which needs to > > > > be passed to be kernel. And this data can be parsed at kernel used > > > > across all DRM drivers to implement the HDCP authentication. Hence we > > > > want generic code to parse the SRM data and provide a helper function to > > > > all DRM drivers to validate their HDCP sink's ID. > > > > > > > > To achieve this we want to keep the sysfs and parsing logic outside the > > > > drm drivers at the class level. > > > > > > > > At present I915 will be using these implementation. in future other DRM > > > > drivers can use the same. > > > > > > Again, binary sysfs files are not for any data that the kernel has to > > > parse at all. So do not use sysfs for this. > > > > So what's the recommend thing then? > > - requrest_firmware blob could work, aside that the blob might change > > (the point of this to allow updates). For some hw you can even stuff > > the SRM into some eprom iirc, so not entirely misfit. Plus kernel > > parses it, so not sure request_firmware is really the right thing. > > I think it is, as this really looks like "firmware" to me as you are > wanting to do something with the buffer and pass it on. > > > - configfs? I never used that one, but the transactional config stuff > > this provides fe
Re: [Intel-gfx] [PATCH v2 02/12] drm/fb-helper: Avoid race with DRM userspace
On Sun, Apr 07, 2019 at 06:52:33PM +0200, Noralf Trønnes wrote: > drm_fb_helper_is_bound() is used to check if DRM userspace is in control. > This is done by looking at the fb on the primary plane. By the time > fb-helper gets around to committing, it's possible that the facts have > changed. > > Avoid this race by holding the drm_device->master_mutex lock while > committing. When DRM userspace does its first open, it will now wait > until fb-helper is done. The helper will stay away if there's a master. > > Locking rule: Always take the fb-helper lock first. > > v2: > - Remove drm_fb_helper_is_bound() (Daniel Vetter) > - No need to check fb_helper->dev->master in > drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check. > > Suggested-by: Daniel Vetter > Signed-off-by: Noralf Trønnes With the changes asked by Daniel, Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] [v3] drm/i915: Add intel_compare_color_lut() to compare hw and sw gamma lut values
On Mon, 15 Apr 2019, Swati Sharma wrote:
> v3: Rebase
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/intel_color.c | 49
>
> drivers/gpu/drm/i915/intel_color.h | 6 +
> drivers/gpu/drm/i915/intel_display.c | 10
> 3 files changed, 65 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index e2703f9..867c1de 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -1500,6 +1500,55 @@ static void ilk_get_color_config(struct
> intel_crtc_state *crtc_state)
> ilk_get_gamma_config(crtc_state);
> }
>
> +static inline bool gamma_err_check(struct drm_color_lut *sw_lut, struct
> drm_color_lut *hw_lut, u32 err)
> +{
> + return ((abs((long)hw_lut->red - sw_lut->red)) >= err) ||
> + ((abs((long)hw_lut->blue - sw_lut->blue)) >= err) ||
> + ((abs((long)hw_lut->green - sw_lut->green)) >= err);
> +}
> +
> +bool intel_compare_color_lut(struct drm_property_blob *blob1,
> + struct drm_property_blob *blob2,
> + u32 gamma_mode)
Please prefix the function name with intel_color_ like I mentioned
earlier in the series.
I don't think it's obvious what a boolean function called "compare"
should return. I see intel_compare_link_m_n() and
intel_compare_infoframe() I think they're equally bad.
intel_color_lut_match() or intel_color_lut_equal() would be obvious.
The C strcmp() is the notorious example where 0 means equal.
> +{
> + struct drm_color_lut *sw_lut = blob1->data;
> + struct drm_color_lut *hw_lut = blob2->data;
> + int sw_lut_size, hw_lut_size, i;
> + u32 bit_precision, err;
> +
> + if (!blob1 || !blob2)
> + return false;
> +
> + switch(gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
> + bit_precision = 8;
> + break;
> + case GAMMA_MODE_MODE_10BIT:
> + bit_precision = 10;
> + break;
> + case GAMMA_MODE_MODE_12BIT:
> + bit_precision = 12;
> + break;
> + default:
It's customary to just add the default label above the correct label
above.
BR,
Jani.
> + bit_precision = 8;
> + }
> +
> + err = 0x >> bit_precision;
> +
> + sw_lut_size = drm_color_lut_size(blob1);
> + hw_lut_size = drm_color_lut_size(blob2);
> +
> + if (sw_lut_size != hw_lut_size)
> + return false;
> +
> + for (i = 0; i < sw_lut_size; i++) {
> + if (!gamma_err_check(&hw_lut[i], &sw_lut[i], err))
> + return false;
> + }
> +
> + return true;
> +}
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> diff --git a/drivers/gpu/drm/i915/intel_color.h
> b/drivers/gpu/drm/i915/intel_color.h
> index 7ca304f..575003f 100644
> --- a/drivers/gpu/drm/i915/intel_color.h
> +++ b/drivers/gpu/drm/i915/intel_color.h
> @@ -6,13 +6,19 @@
> #ifndef __INTEL_COLOR_H__
> #define __INTEL_COLOR_H__
>
> +#include
> +
> struct intel_crtc_state;
> struct intel_crtc;
> +struct drm_property_blob;
>
> void intel_color_init(struct intel_crtc *crtc);
> int intel_color_check(struct intel_crtc_state *crtc_state);
> void intel_color_commit(const struct intel_crtc_state *crtc_state);
> void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
> void intel_get_color_config(struct intel_crtc_state *crtc_state);
> +bool intel_compare_color_lut(struct drm_property_blob *blob1,
> + struct drm_property_blob *blob2,
> + u32 gamma_mode);
>
> #endif /* __INTEL_COLOR_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0fc9dab..b074f00 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12236,6 +12236,14 @@ static bool fastboot_enabled(struct drm_i915_private
> *dev_priv)
> } \
> } while (0)
>
> +#define PIPE_CONF_CHECK_COLOR_LUT(name, gamma_mode) do { \
> + if (!intel_compare_color_lut(current_config->name, pipe_config->name,
> gamma_mode)) { \
> + pipe_config_err(adjust, __stringify(name), \
> + "hw_state doesn't match sw_state\n"); \
> + ret = false; \
> + } \
> +} while (0)
> +
> #define PIPE_CONF_QUIRK(quirk) \
> ((current_config->quirks | pipe_config->quirks) & (quirk))
>
> @@ -12379,6 +12387,8 @@ static bool fastboot_enabled(struct drm_i915_private
> *dev_priv)
> PIPE_CONF_CHECK_INFOFRAME(spd);
> PIPE_CONF_CHECK_INFOFRAME(hdmi);
>
> + PIPE_CONF_CHECK_COLOR_LUT(base.gamma_lut, pipe_config->gamma_mode);
> +
> #undef PIPE_CONF_CHECK_X
> #undef PIPE_CONF_CHECK_I
> #undef PIPE_CONF_CHECK_BOOL
--
Jani Nikula, Intel Open Source Graphics Center
_
Re: [Intel-gfx] [PATCH v2 04/12] drm/fb-helper: No need to cache rotation and sw_rotations
On Sun, Apr 07, 2019 at 06:52:35PM +0200, Noralf Trønnes wrote: > Getting rotation info is cheap so we can do it on demand. > > This is done in preparation for the removal of struct drm_fb_helper_crtc. > > Cc: Hans de Goede > Signed-off-by: Noralf Trønnes > Acked-by: Daniel Vetter Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 05/12] drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
On Sun, Apr 07, 2019 at 06:52:36PM +0200, Noralf Trønnes wrote: > The values are already present in the modeset. > > This is done in preparation for the removal of struct drm_fb_helper_crtc. > > Signed-off-by: Noralf Trønnes > Reviewed-by: Daniel Vetter Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/12] drm/fb-helper: Move out modeset config code
On Sun, Apr 07, 2019 at 06:52:42PM +0200, Noralf Trønnes wrote: > No functional changes, just moving code as-is and fixing includes. > > Signed-off-by: Noralf Trønnes Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Verify the engine workarounds stick on application
On 16/04/2019 09:10, Chris Wilson wrote:
Read the engine workarounds back using the GPU after loading the initial
context state to verify that we are setting them correctly, and bail if
it fails.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 6 +
drivers/gpu/drm/i915/intel_workarounds.c | 120 ++
drivers/gpu/drm/i915/intel_workarounds.h | 2 +
.../drm/i915/selftests/intel_workarounds.c| 53 +---
4 files changed, 134 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a818a60ad31..95ae69753e91 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4717,6 +4717,12 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
i915_request_add(rq);
if (err)
goto err_active;
+
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) &&
+ intel_engine_verify_workarounds(engine, "load")) {
+ err = -EIO;
+ goto err_active;
The two submission use different contexts timelines so strictly speaking
should be somehow explicitly serialized.
+ }
}
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 1c54b5030807..db99f2e676bb 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1259,6 +1259,126 @@ void intel_engine_apply_workarounds(struct
intel_engine_cs *engine)
wa_list_apply(engine->uncore, &engine->wa_list);
}
+static struct i915_vma *
+create_scratch(struct i915_address_space *vm, int count)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ unsigned int size;
+ int err;
+
+ size = round_up(count * 4, PAGE_SIZE);
sizeof(u32) if you want.
+ obj = i915_gem_object_create_internal(vm->i915, size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_obj;
+ }
+
+ err = i915_vma_pin(vma, 0, 0,
+ i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+ if (err)
+ goto err_obj;
+
+ return vma;
+
+err_obj:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+wa_list_srm(struct i915_request *rq,
+ const struct i915_wa_list *wal,
+ struct i915_vma *vma)
+{
+ const struct i915_wa *wa;
+ u32 srm, *cs;
+ int i;
A little bit of inconsistency between type of i here and in
engine_wa_list_verify. Up to you.
+
+ srm = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (INTEL_GEN(rq->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * wal->count);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(wa->reg);
+ *cs++ = i915_ggtt_offset(vma) + sizeof(u32) * i;
+ *cs++ = 0;
+ }
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int engine_wa_list_verify(struct intel_engine_cs *engine,
+const struct i915_wa_list * const wal,
+const char *from)
+{
+ const struct i915_wa *wa;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ unsigned int i;
+ u32 *results;
+ int err;
+
+ if (!wal->count)
+ return 0;
+
+ vma = create_scratch(&engine->i915->ggtt.vm, wal->count);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ rq = i915_request_alloc(engine, engine->kernel_context->gem_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_vma;
+ }
+
+ err = wa_list_srm(rq, wal, vma);
+ if (err)
+ goto err_vma;
+
+ i915_request_add(rq);
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0) {
Wouldn't:
err = i915_request_wait(...
if (err < 0 || !i915_request_completed())
be more correct?
+ err = -ETIME;
+ goto err_vma;
+ }
+
+ results = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);
+ if (IS_ERR(results)) {
+ err = PTR_ERR(results);
+ goto err_vma;
+ }
+
+ err = 0;
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
+ if (!wa_verify(wa, results[i], wal->name, from))
+ err = -ENXIO;
+
+ i915_gem_object_unpin
Re: [Intel-gfx] [PATCH v2 10/12] drm/fb-helper: Prepare to move out modeset config code
On Sun, Apr 07, 2019 at 06:52:41PM +0200, Noralf Trønnes wrote: > This prepares the modeset code so it can be moved out as-is in the next > patch. > > Signed-off-by: Noralf Trønnes Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Make workaround verification *optional*
On 16/04/2019 09:10, Chris Wilson wrote:
Sometimes the HW doesn't even play fair, and completely forgets about
register writes. Skip verifying known troublemakers.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 40 ++-
.../gpu/drm/i915/intel_workarounds_types.h| 7 ++--
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index db99f2e676bb..ba58be05f58c 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -122,6 +122,7 @@ static void _wa_add(struct i915_wa_list *wal, const struct
i915_wa *wa)
wal->wa_count++;
wa_->val |= wa->val;
wa_->mask |= wa->mask;
+ wa_->read |= wa->read;
return;
}
}
@@ -146,9 +147,10 @@ wa_write_masked_or(struct i915_wa_list *wal, i915_reg_t
reg, u32 mask,
u32 val)
{
struct i915_wa wa = {
- .reg = reg,
+ .reg = reg,
.mask = mask,
- .val = val
+ .val = val,
+ .read = mask,
};
_wa_add(wal, &wa);
@@ -172,6 +174,19 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32
val)
wa_write_masked_or(wal, reg, val, val);
}
+static void
+ignore_wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 mask, u32 val)
+{
+ struct i915_wa wa = {
+ .reg = reg,
+ .mask = mask,
+ .val = val,
+ /* Bonkers HW, skip verifying */
+ };
+
+ _wa_add(wal, &wa);
+}
+
#define WA_SET_BIT_MASKED(addr, mask) \
wa_write_masked_or(wal, (addr), (mask), _MASKED_BIT_ENABLE(mask))
@@ -916,10 +931,11 @@ wal_get_fw_for_rmw(struct intel_uncore *uncore, const struct i915_wa_list *wal)
static bool
wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
{
- if ((cur ^ wa->val) & wa->mask) {
+ if ((cur ^ wa->val) & wa->read) {
DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
- name, from, i915_mmio_reg_offset(wa->reg), cur,
- cur & wa->mask, wa->val, wa->mask);
+ name, from, i915_mmio_reg_offset(wa->reg),
+ cur, cur & wa->read,
+ wa->val, wa->mask);
return false;
}
@@ -1122,9 +1138,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
_3D_CHICKEN3_AA_LINE_QUALITY_FIX_ENABLE);
/* WaPipelineFlushCoherentLines:icl */
- wa_write_or(wal,
- GEN8_L3SQCREG4,
- GEN8_LQSC_FLUSH_COHERENT_LINES);
+ ignore_wa_write_or(wal,
+ GEN8_L3SQCREG4,
+ GEN8_LQSC_FLUSH_COHERENT_LINES,
+ GEN8_LQSC_FLUSH_COHERENT_LINES);
/*
* Wa_1405543622:icl
@@ -1151,9 +1168,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
* Wa_1405733216:icl
* Formerly known as WaDisableCleanEvicts
*/
- wa_write_or(wal,
- GEN8_L3SQCREG4,
- GEN11_LQSC_CLEAN_EVICT_DISABLE);
+ ignore_wa_write_or(wal,
+ GEN8_L3SQCREG4,
+ GEN11_LQSC_CLEAN_EVICT_DISABLE,
+ GEN11_LQSC_CLEAN_EVICT_DISABLE);
/* WaForwardProgressSoftReset:icl */
wa_write_or(wal,
diff --git a/drivers/gpu/drm/i915/intel_workarounds_types.h
b/drivers/gpu/drm/i915/intel_workarounds_types.h
index 30918da180ff..42ac1fb99572 100644
--- a/drivers/gpu/drm/i915/intel_workarounds_types.h
+++ b/drivers/gpu/drm/i915/intel_workarounds_types.h
@@ -12,9 +12,10 @@
#include "i915_reg.h"
struct i915_wa {
- i915_reg_treg;
- u32 mask;
- u32 val;
+ i915_reg_t reg;
+ u32 mask;
+ u32 val;
+ u32 read;
};
struct i915_wa_list {
The sporadic nature of failures worries me here. What is better:
a) Stop verifying from the driver and potentially lose a workaround
and/or never figure out what is actually going on.
b) Have CI buglog track this as a known issue "forever"? Can't our
automated tooling handle this?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Verify the engine workarounds stick on application
Quoting Tvrtko Ursulin (2019-04-16 10:43:43)
>
> On 16/04/2019 09:10, Chris Wilson wrote:
> > Read the engine workarounds back using the GPU after loading the initial
> > context state to verify that we are setting them correctly, and bail if
> > it fails.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 6 +
> > drivers/gpu/drm/i915/intel_workarounds.c | 120 ++
> > drivers/gpu/drm/i915/intel_workarounds.h | 2 +
> > .../drm/i915/selftests/intel_workarounds.c| 53 +---
> > 4 files changed, 134 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 0a818a60ad31..95ae69753e91 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4717,6 +4717,12 @@ static int __intel_engines_record_defaults(struct
> > drm_i915_private *i915)
> > i915_request_add(rq);
> > if (err)
> > goto err_active;
> > +
> > + if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) &&
> > + intel_engine_verify_workarounds(engine, "load")) {
> > + err = -EIO;
> > + goto err_active;
>
> The two submission use different contexts timelines so strictly speaking
> should be somehow explicitly serialized.
Yes, we are reading from the kernel context. Neither of these contexts
will overwrite the existing register state on first load, and there is
nothing to prevent fifo here. But it doesn't matter which order the read
is done, as the w/a are set by mmio, not engine->init_context().
Although I've been contemplating using init_context in case LRI work
better.
It could be in a separate loop beforehand, the only catch is that we
expect to leave this function with the GT idle, so it's best done before
we park.
> > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > b/drivers/gpu/drm/i915/intel_workarounds.c
> > index 1c54b5030807..db99f2e676bb 100644
> > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > @@ -1259,6 +1259,126 @@ void intel_engine_apply_workarounds(struct
> > intel_engine_cs *engine)
> > wa_list_apply(engine->uncore, &engine->wa_list);
> > }
> >
> > +static struct i915_vma *
> > +create_scratch(struct i915_address_space *vm, int count)
> > +{
> > + struct drm_i915_gem_object *obj;
> > + struct i915_vma *vma;
> > + unsigned int size;
> > + int err;
> > +
> > + size = round_up(count * 4, PAGE_SIZE);
>
> sizeof(u32) if you want.
>
> > + obj = i915_gem_object_create_internal(vm->i915, size);
> > + if (IS_ERR(obj))
> > + return ERR_CAST(obj);
> > +
> > + i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
> > +
> > + vma = i915_vma_instance(obj, vm, NULL);
> > + if (IS_ERR(vma)) {
> > + err = PTR_ERR(vma);
> > + goto err_obj;
> > + }
> > +
> > + err = i915_vma_pin(vma, 0, 0,
> > +i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
> > + if (err)
> > + goto err_obj;
> > +
> > + return vma;
> > +
> > +err_obj:
> > + i915_gem_object_put(obj);
> > + return ERR_PTR(err);
> > +}
> > +
> > +static int
> > +wa_list_srm(struct i915_request *rq,
> > + const struct i915_wa_list *wal,
> > + struct i915_vma *vma)
> > +{
> > + const struct i915_wa *wa;
> > + u32 srm, *cs;
> > + int i;
>
> A little bit of inconsistency between type of i here and in
> engine_wa_list_verify. Up to you.
>
> > +
> > + srm = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
> > + if (INTEL_GEN(rq->i915) >= 8)
> > + srm++;
> > +
> > + cs = intel_ring_begin(rq, 4 * wal->count);
> > + if (IS_ERR(cs))
> > + return PTR_ERR(cs);
> > +
> > + for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
> > + *cs++ = srm;
> > + *cs++ = i915_mmio_reg_offset(wa->reg);
> > + *cs++ = i915_ggtt_offset(vma) + sizeof(u32) * i;
> > + *cs++ = 0;
> > + }
> > + intel_ring_advance(rq, cs);
> > +
> > + return 0;
> > +}
> > +
> > +static int engine_wa_list_verify(struct intel_engine_cs *engine,
> > + const struct i915_wa_list * const wal,
> > + const char *from)
> > +{
> > + const struct i915_wa *wa;
> > + struct i915_request *rq;
> > + struct i915_vma *vma;
> > + unsigned int i;
> > + u32 *results;
> > + int err;
> > +
> > + if (!wal->count)
> > + return 0;
> > +
> > + vma = create_scratch(&engine->i915->ggtt.vm, wal->count);
> > + if (IS_ERR(vma))
> > + return PTR_ERR(vma);
> > +
> > + rq = i915_request_alloc(engine, engine->kernel_context->gem_context);
> > + if (IS_ERR(rq)) {
> > + err
Re: [Intel-gfx] [PATCH v2 01/12] drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
On Sun, Apr 07, 2019 at 06:52:32PM +0200, Noralf Trønnes wrote: > Prepare for moving drm_fb_helper modesetting code to drm_client. > drm_client will be linked to drm.ko, so move > __drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config() > out of drm_kms_helper.ko. > > While at it, fix two checkpatch complaints: > - WARNING: Block comments use a trailing */ on a separate line > - CHECK: Alignment should match open parenthesis > > Signed-off-by: Noralf Trønnes > Reviewed-by: Daniel Vetter Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ 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/ehl: inherit icl cdclk init/uninit
== Series Details == Series: drm/i915/ehl: inherit icl cdclk init/uninit URL : https://patchwork.freedesktop.org/series/59562/ State : success == Summary == CI Bug Log - changes from CI_DRM_5936 -> Patchwork_12812 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59562/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12812 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-icl-y: NOTRUN -> SKIP [fdo#109315] +17 - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +18 * igt@gem_exec_basic@basic-bsd2: - fi-icl-y: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_basic@gtt-bsd2: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +52 * igt@gem_exec_parse@basic-rejected: - fi-icl-y: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_exec_store@basic-bsd2: - fi-hsw-4770:NOTRUN -> SKIP [fdo#109271] +41 * igt@gem_exec_suspend@basic-s4-devices: - fi-icl-y: NOTRUN -> DMESG-WARN [fdo#109638] * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ] * igt@kms_addfb_basic@addfb25-y-tiled-small: - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] +51 * igt@kms_busy@basic-flip-c: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@dp-crc-fast: - fi-icl-y: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_chamelium@hdmi-edid-read: - fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_force_connector_basic@force-load-detect: - fi-icl-y: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814] - fi-byt-clapper: NOTRUN -> FAIL [fdo#103167] * igt@kms_psr@primary_mmap_gtt: - fi-icl-y: NOTRUN -> SKIP [fdo#110189] +3 * igt@kms_psr@primary_page_flip: - fi-skl-lmem:NOTRUN -> SKIP [fdo#109271] +37 * igt@prime_vgem@basic-fence-flip: - fi-icl-y: NOTRUN -> SKIP [fdo#109294] Possible fixes * igt@i915_module_load@reload: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS * igt@i915_selftest@live_execlists: - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109638]: https://bugs.freedesktop.org/show_bug.cgi?id=109638 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (43 -> 41) -- Additional (6): fi-hsw-peppy fi-hsw-4770 fi-icl-y fi-skl-lmem fi-byt-n2820 fi-byt-clapper Missing(8): fi-kbl-soraka fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 fi-bdw-samus Build changes - * Linux: CI_DRM_5936 -> Patchwork_12812 CI_DRM_5936: 0ad14bd30d830a1a355040b29bfafbe6623d84f0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4948: cf27a37b867bf31dccbe5f1b3bd84a2e606544f0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12812: c372e7edac1754c7b8d3e834b0ad89ffe7a155f3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c372e7edac17 drm/i915/ehl: inherit icl cdclk init/uninit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12812/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/12] drm/fb-helper: Remove drm_fb_helper_connector
Hi, On Sun, Apr 07, 2019 at 06:52:40PM +0200, Noralf Trønnes wrote: > All drivers add all their connectors so there's no need to keep around an > array of available connectors. > > Rename functions which signature is changed since they will be moved to > drm_client in a later patch. > > Signed-off-by: Noralf Trønnes The patch itself looks fine in itself, but I was planning on using connector_info to store the connector properties set on the kernel command line as part of video= Where should we put them now? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/2] drm/i915: start moving state checker to intel_verify.c
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/intel_display.c | 474 +--
drivers/gpu/drm/i915/intel_drv.h | 12 +
drivers/gpu/drm/i915/intel_verify.c | 464 ++
drivers/gpu/drm/i915/intel_verify.h | 22 ++
5 files changed, 510 insertions(+), 463 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_verify.c
create mode 100644 drivers/gpu/drm/i915/intel_verify.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index fbcb0904..a000fad 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ i915-y += dvo_ch7017.o \
intel_panel.o \
intel_sdvo.o \
intel_tv.o \
+ intel_verify.o \
vlv_dsi.o \
vlv_dsi_pll.o \
intel_vdsc.o
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3bd40a..31a931 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -69,6 +69,7 @@
#include "intel_sdvo.h"
#include "intel_sprite.h"
#include "intel_tv.h"
+#include "intel_verify.h"
/* Primary plane formats for gen <= 3 */
static const u32 i8xx_primary_formats[] = {
@@ -1243,7 +1244,7 @@ void assert_pipe(struct drm_i915_private *dev_priv,
pipe_name(pipe), onoff(state), onoff(cur_state));
}
-static void assert_plane(struct intel_plane *plane, bool state)
+void assert_plane(struct intel_plane *plane, bool state)
{
enum pipe pipe;
bool cur_state;
@@ -6607,45 +6608,6 @@ void intel_encoder_destroy(struct drm_encoder *encoder)
kfree(intel_encoder);
}
-/* Cross check the actual hw state with our own modeset state tracking (and
it's
- * internal consistency). */
-static void intel_connector_verify_state(struct drm_crtc_state *crtc_state,
-struct drm_connector_state *conn_state)
-{
- struct intel_connector *connector =
to_intel_connector(conn_state->connector);
-
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.base.id,
- connector->base.name);
-
- if (connector->get_hw_state(connector)) {
- struct intel_encoder *encoder = connector->encoder;
-
- I915_STATE_WARN(!crtc_state,
-"connector enabled without attached crtc\n");
-
- if (!crtc_state)
- return;
-
- I915_STATE_WARN(!crtc_state->active,
- "connector is active, but attached crtc isn't\n");
-
- if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
- return;
-
- I915_STATE_WARN(conn_state->best_encoder != &encoder->base,
- "atomic encoder doesn't match attached encoder\n");
-
- I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
- "attached encoder crtc differs from connector crtc\n");
- } else {
- I915_STATE_WARN(crtc_state && crtc_state->active,
- "attached crtc is active, but connector isn't\n");
- I915_STATE_WARN(!crtc_state && conn_state->best_encoder,
- "best encoder set without crtc!\n");
- }
-}
-
static int pipe_required_fdi_lanes(struct intel_crtc_state *crtc_state)
{
if (crtc_state->base.enable && crtc_state->has_pch_encoder)
@@ -6879,7 +6841,7 @@ static u32 ilk_pipe_pixel_rate(const struct
intel_crtc_state *pipe_config)
return pixel_rate;
}
-static void intel_crtc_compute_pixel_rate(struct intel_crtc_state *crtc_state)
+void intel_crtc_compute_pixel_rate(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
@@ -11584,9 +11546,9 @@ static const char *output_formats(enum
intel_output_format format)
return output_format_str[format];
}
-static void intel_dump_pipe_config(struct intel_crtc *crtc,
- struct intel_crtc_state *pipe_config,
- const char *context)
+void intel_dump_pipe_config(struct intel_crtc *crtc,
+ struct intel_crtc_state *pipe_config,
+ const char *context)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -12076,7 +12038,7 @@ static bool fastboot_enabled(struct drm_i915_private
*dev_priv)
return false;
}
-static bool
+bool
intel_pipe_config_compare(struct drm_i915_private *dev_priv,
struct intel_crtc_state *current_config,
struct intel_crtc_state *pipe_config,
@@ -12389,8 +12351,8 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
return ret;
}
-static void intel_pipe_config_sanity_check(struct drm_i
[Intel-gfx] [RFC 2/2] drm/i915: move pipe config compare to intel_verify.c
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 471 +--
drivers/gpu/drm/i915/intel_drv.h | 9 +-
drivers/gpu/drm/i915/intel_verify.c | 465 ++
drivers/gpu/drm/i915/intel_verify.h | 8 +
4 files changed, 478 insertions(+), 475 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 31a931..14899f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -202,9 +202,9 @@ static void intel_update_czclk(struct drm_i915_private
*dev_priv)
DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
}
-static inline u32 /* units of 100MHz */
-intel_fdi_link_freq(struct drm_i915_private *dev_priv,
- const struct intel_crtc_state *pipe_config)
+/* units of 100MHz */
+u32 intel_fdi_link_freq(struct drm_i915_private *dev_priv,
+ const struct intel_crtc_state *pipe_config)
{
if (HAS_DDI(dev_priv))
return pipe_config->port_clock; /* SPLL */
@@ -11904,471 +11904,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return 0;
}
-static bool intel_fuzzy_clock_check(int clock1, int clock2)
-{
- int diff;
-
- if (clock1 == clock2)
- return true;
-
- if (!clock1 || !clock2)
- return false;
-
- diff = abs(clock1 - clock2);
-
- if (diff + clock1 + clock2) * 100)) / (clock1 + clock2)) < 105)
- return true;
-
- return false;
-}
-
-static bool
-intel_compare_m_n(unsigned int m, unsigned int n,
- unsigned int m2, unsigned int n2,
- bool exact)
-{
- if (m == m2 && n == n2)
- return true;
-
- if (exact || !m || !n || !m2 || !n2)
- return false;
-
- BUILD_BUG_ON(DATA_LINK_M_N_MASK > INT_MAX);
-
- if (n > n2) {
- while (n > n2) {
- m2 <<= 1;
- n2 <<= 1;
- }
- } else if (n < n2) {
- while (n < n2) {
- m <<= 1;
- n <<= 1;
- }
- }
-
- if (n != n2)
- return false;
-
- return intel_fuzzy_clock_check(m, m2);
-}
-
-static bool
-intel_compare_link_m_n(const struct intel_link_m_n *m_n,
- struct intel_link_m_n *m2_n2,
- bool adjust)
-{
- if (m_n->tu == m2_n2->tu &&
- intel_compare_m_n(m_n->gmch_m, m_n->gmch_n,
- m2_n2->gmch_m, m2_n2->gmch_n, !adjust) &&
- intel_compare_m_n(m_n->link_m, m_n->link_n,
- m2_n2->link_m, m2_n2->link_n, !adjust)) {
- if (adjust)
- *m2_n2 = *m_n;
-
- return true;
- }
-
- return false;
-}
-
-static bool
-intel_compare_infoframe(const union hdmi_infoframe *a,
- const union hdmi_infoframe *b)
-{
- return memcmp(a, b, sizeof(*a)) == 0;
-}
-
-static void
-pipe_config_infoframe_err(struct drm_i915_private *dev_priv,
- bool adjust, const char *name,
- const union hdmi_infoframe *a,
- const union hdmi_infoframe *b)
-{
- if (adjust) {
- if ((drm_debug & DRM_UT_KMS) == 0)
- return;
-
- drm_dbg(DRM_UT_KMS, "mismatch in %s infoframe", name);
- drm_dbg(DRM_UT_KMS, "expected:");
- hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, a);
- drm_dbg(DRM_UT_KMS, "found");
- hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, b);
- } else {
- drm_err("mismatch in %s infoframe", name);
- drm_err("expected:");
- hdmi_infoframe_log(KERN_ERR, dev_priv->drm.dev, a);
- drm_err("found");
- hdmi_infoframe_log(KERN_ERR, dev_priv->drm.dev, b);
- }
-}
-
-static void __printf(3, 4)
-pipe_config_err(bool adjust, const char *name, const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
-
- va_start(args, format);
- vaf.fmt = format;
- vaf.va = &args;
-
- if (adjust)
- drm_dbg(DRM_UT_KMS, "mismatch in %s %pV", name, &vaf);
- else
- drm_err("mismatch in %s %pV", name, &vaf);
-
- va_end(args);
-}
-
-static bool fastboot_enabled(struct drm_i915_private *dev_priv)
-{
- if (i915_modparams.fastboot != -1)
- return i915_modparams.fastboot;
-
- /* Enable fastboot by default on Skylake and newer */
- if (INTEL_GEN(dev_priv) >= 9)
- return true;
-
- /* Enable fastboot by default on VLV and CHV */
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- return true;
-
- /* Disabled by default on all others */
- return f
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Verify the engine workarounds stick on application
On 16/04/2019 10:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-16 10:43:43)
On 16/04/2019 09:10, Chris Wilson wrote:
Read the engine workarounds back using the GPU after loading the initial
context state to verify that we are setting them correctly, and bail if
it fails.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 6 +
drivers/gpu/drm/i915/intel_workarounds.c | 120 ++
drivers/gpu/drm/i915/intel_workarounds.h | 2 +
.../drm/i915/selftests/intel_workarounds.c| 53 +---
4 files changed, 134 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a818a60ad31..95ae69753e91 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4717,6 +4717,12 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
i915_request_add(rq);
if (err)
goto err_active;
+
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) &&
+ intel_engine_verify_workarounds(engine, "load")) {
+ err = -EIO;
+ goto err_active;
The two submission use different contexts timelines so strictly speaking
should be somehow explicitly serialized.
Yes, we are reading from the kernel context. Neither of these contexts
will overwrite the existing register state on first load, and there is
nothing to prevent fifo here. But it doesn't matter which order the read
is done, as the w/a are set by mmio, not engine->init_context().
Although I've been contemplating using init_context in case LRI work
better.
Using init_context for what, engine wa/?
It could be in a separate loop beforehand, the only catch is that we
expect to leave this function with the GT idle, so it's best done before
we park.
Yep since the placement in the ->init_context loop confused me I think a
separate loop would indeed be better.
__i915_gem_restart_engines looks like the place, to follow
engine->init_hw which applies the engine workarounds.
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 1c54b5030807..db99f2e676bb 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1259,6 +1259,126 @@ void intel_engine_apply_workarounds(struct
intel_engine_cs *engine)
wa_list_apply(engine->uncore, &engine->wa_list);
}
+static struct i915_vma *
+create_scratch(struct i915_address_space *vm, int count)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ unsigned int size;
+ int err;
+
+ size = round_up(count * 4, PAGE_SIZE);
sizeof(u32) if you want.
+ obj = i915_gem_object_create_internal(vm->i915, size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_obj;
+ }
+
+ err = i915_vma_pin(vma, 0, 0,
+i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+ if (err)
+ goto err_obj;
+
+ return vma;
+
+err_obj:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+wa_list_srm(struct i915_request *rq,
+ const struct i915_wa_list *wal,
+ struct i915_vma *vma)
+{
+ const struct i915_wa *wa;
+ u32 srm, *cs;
+ int i;
A little bit of inconsistency between type of i here and in
engine_wa_list_verify. Up to you.
+
+ srm = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (INTEL_GEN(rq->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * wal->count);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(wa->reg);
+ *cs++ = i915_ggtt_offset(vma) + sizeof(u32) * i;
+ *cs++ = 0;
+ }
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int engine_wa_list_verify(struct intel_engine_cs *engine,
+ const struct i915_wa_list * const wal,
+ const char *from)
+{
+ const struct i915_wa *wa;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ unsigned int i;
+ u32 *results;
+ int err;
+
+ if (!wal->count)
+ return 0;
+
+ vma = create_scratch(&engine->i915->ggtt.vm, wal->count);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ rq = i915_request_alloc(engine, engine->kernel_context->gem_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_vma;
+ }
+
+ err = wa_list_srm(rq, wal, vma);
+ if (err)
+ goto err_vma;
+
+ i915_request_add(rq);
Re: [Intel-gfx] [PATCH 02/11] [v2] drm/i915: Extract i9xx_get_color_config()
On Mon, 15 Apr 2019, Swati Sharma wrote:
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h| 3 +++
> drivers/gpu/drm/i915/intel_color.c | 51
> ++
> 2 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9c206e8..8f2ae8a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7175,6 +7175,9 @@ enum {
> /* legacy palette */
> #define _LGC_PALETTE_A 0x4a000
> #define _LGC_PALETTE_B 0x4a800
> +#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
> +#define LGC_PALETTE_GREEN_MASK REG_GENMASK(15, 8)
> +#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0)
> #define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A,
> _LGC_PALETTE_B) + (i) * 4)
>
> /* ilk/snb precision palette */
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 321cf52..f394402 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -1228,6 +1228,56 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
> return 0;
> }
>
> +/* convert hw value with given bit_precision to lut property val */
> +static u32 intel_color_lut_pack(u32 val, u32 bit_precision)
> +{
> + u32 max = 0x >> (16 - bit_precision);
> +
> + val = clamp_val(val, 0, max);
> +
> + if (bit_precision < 16)
> + val <<= 16 - bit_precision;
> +
> + return val;
> +}
> +
> +static void i9xx_get_config_internal(struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + struct drm_property_blob *blob = NULL;
No need to initialize.
> + struct drm_color_lut *blob_data;
> + u32 i, val;
> +
> + blob = drm_property_create_blob(dev,
You can drop the dev local var as it's simply &dev_priv->drm.
> + sizeof(struct drm_color_lut) * 256,
> + NULL);
> + if (IS_ERR(blob))
> + return;
> +
> + blob_data = blob->data;
> +
> + for (i = 0; i < 256; i++) {
> + if (HAS_GMCH(dev_priv))
> + val = I915_READ(PALETTE(pipe, i));
> + else
> + val = I915_READ(LGC_PALETTE(pipe, i));
> +
> + blob_data[i].red =
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, val) >> 16, 8);
> + blob_data[i].green =
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val) >> 8, 8);
> + blob_data[i].blue =
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, val), 8);
REG_FIELD_GET() return the fields already shifted down according to the
mask. So the right shifts here are not needed.
> + }
> +
> + crtc_state->base.gamma_lut = blob;
> +}
> +
> +static void i9xx_get_color_config(struct intel_crtc_state *crtc_state)
> +{
> + i9xx_get_config_internal(crtc_state);
> +}
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> @@ -1248,6 +1298,7 @@ void intel_color_init(struct intel_crtc *crtc)
> dev_priv->display.color_check = i9xx_color_check;
> dev_priv->display.color_commit = i9xx_color_commit;
> dev_priv->display.load_luts = i9xx_load_luts;
> + dev_priv->display.get_color_config =
> i9xx_get_color_config;
> }
> } else {
> if (INTEL_GEN(dev_priv) >= 11)
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] [v2] drm/i915: Extract i9xx_get_color_config()
On Tue, 16 Apr 2019, Jani Nikula wrote:
> On Mon, 15 Apr 2019, Swati Sharma wrote:
>> Signed-off-by: Swati Sharma
>> ---
>> drivers/gpu/drm/i915/i915_reg.h| 3 +++
>> drivers/gpu/drm/i915/intel_color.c | 51
>> ++
>> 2 files changed, 54 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 9c206e8..8f2ae8a 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7175,6 +7175,9 @@ enum {
>> /* legacy palette */
>> #define _LGC_PALETTE_A 0x4a000
>> #define _LGC_PALETTE_B 0x4a800
>> +#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
>> +#define LGC_PALETTE_GREEN_MASK REG_GENMASK(15, 8)
>> +#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0)
>> #define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A,
>> _LGC_PALETTE_B) + (i) * 4)
>>
>> /* ilk/snb precision palette */
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 321cf52..f394402 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -1228,6 +1228,56 @@ static int icl_color_check(struct intel_crtc_state
>> *crtc_state)
>> return 0;
>> }
>>
>> +/* convert hw value with given bit_precision to lut property val */
>> +static u32 intel_color_lut_pack(u32 val, u32 bit_precision)
>> +{
>> +u32 max = 0x >> (16 - bit_precision);
>> +
>> +val = clamp_val(val, 0, max);
>> +
>> +if (bit_precision < 16)
>> +val <<= 16 - bit_precision;
>> +
>> +return val;
>> +}
>> +
>> +static void i9xx_get_config_internal(struct intel_crtc_state *crtc_state)
>> +{
>> +struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> +struct drm_device *dev = crtc->base.dev;
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +enum pipe pipe = crtc->pipe;
>> +struct drm_property_blob *blob = NULL;
>
> No need to initialize.
>
>> +struct drm_color_lut *blob_data;
>> +u32 i, val;
>> +
>> +blob = drm_property_create_blob(dev,
>
> You can drop the dev local var as it's simply &dev_priv->drm.
>
>> +sizeof(struct drm_color_lut) * 256,
>> +NULL);
>> +if (IS_ERR(blob))
>> +return;
>> +
>> +blob_data = blob->data;
>> +
>> +for (i = 0; i < 256; i++) {
>> +if (HAS_GMCH(dev_priv))
>> +val = I915_READ(PALETTE(pipe, i));
>> +else
>> +val = I915_READ(LGC_PALETTE(pipe, i));
>> +
>> +blob_data[i].red =
>> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, val) >> 16, 8);
>> +blob_data[i].green =
>> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val) >> 8, 8);
>> +blob_data[i].blue =
>> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, val), 8);
>
> REG_FIELD_GET() return the fields already shifted down according to the
> mask. So the right shifts here are not needed.
So the same comments apply to the rest of the platform specific get
config patches in the series, I'm not going to repeat them individually.
BR,
Jani.
>
>> +}
>> +
>> +crtc_state->base.gamma_lut = blob;
>> +}
>> +
>> +static void i9xx_get_color_config(struct intel_crtc_state *crtc_state)
>> +{
>> +i9xx_get_config_internal(crtc_state);
>> +}
>> +
>> void intel_color_init(struct intel_crtc *crtc)
>> {
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> @@ -1248,6 +1298,7 @@ void intel_color_init(struct intel_crtc *crtc)
>> dev_priv->display.color_check = i9xx_color_check;
>> dev_priv->display.color_commit = i9xx_color_commit;
>> dev_priv->display.load_luts = i9xx_load_luts;
>> +dev_priv->display.get_color_config =
>> i9xx_get_color_config;
>> }
>> } else {
>> if (INTEL_GEN(dev_priv) >= 11)
--
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.BAT: success for drm/i915: Drop bool return from breadcrumbs signaler
== Series Details == Series: drm/i915: Drop bool return from breadcrumbs signaler URL : https://patchwork.freedesktop.org/series/59565/ State : success == Summary == CI Bug Log - changes from CI_DRM_5936 -> Patchwork_12813 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59565/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12813 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-icl-y: NOTRUN -> SKIP [fdo#109315] +17 - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +18 * igt@gem_exec_basic@basic-bsd2: - fi-icl-y: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_basic@gtt-bsd2: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +52 * igt@gem_exec_parse@basic-rejected: - fi-icl-y: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_exec_store@basic-bsd2: - fi-hsw-4770:NOTRUN -> SKIP [fdo#109271] +41 * igt@gem_workarounds@basic-read: - fi-snb-2600:NOTRUN -> SKIP [fdo#109271] +52 * igt@i915_selftest@live_evict: - fi-bsw-kefka: PASS -> DMESG-WARN [fdo#107709] * igt@kms_addfb_basic@addfb25-y-tiled-small: - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] +51 * igt@kms_busy@basic-flip-c: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-snb-2600:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@dp-crc-fast: - fi-icl-y: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_chamelium@hdmi-edid-read: - fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_force_connector_basic@force-load-detect: - fi-icl-y: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] +1 * igt@kms_psr@primary_mmap_gtt: - fi-icl-y: NOTRUN -> SKIP [fdo#110189] +3 * igt@kms_psr@primary_page_flip: - fi-skl-lmem:NOTRUN -> SKIP [fdo#109271] +37 * igt@prime_vgem@basic-fence-flip: - fi-icl-y: NOTRUN -> SKIP [fdo#109294] * igt@runner@aborted: - fi-bsw-kefka: NOTRUN -> FAIL [fdo#107709] / [fdo#110446] Possible fixes * igt@i915_module_load@reload: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110446]: https://bugs.freedesktop.org/show_bug.cgi?id=110446 Participating hosts (43 -> 41) -- Additional (7): fi-hsw-peppy fi-hsw-4770 fi-icl-y fi-skl-lmem fi-byt-n2820 fi-byt-clapper fi-snb-2600 Missing(9): fi-kbl-soraka fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-j1900 fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-bdw-samus Build changes - * Linux: CI_DRM_5936 -> Patchwork_12813 CI_DRM_5936: 0ad14bd30d830a1a355040b29bfafbe6623d84f0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4948: cf27a37b867bf31dccbe5f1b3bd84a2e606544f0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12813: 4fe89fe97610463d193241aa45cc7b8b87a576dd @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4fe89fe97610 drm/i915: Drop bool return from breadcrumbs signaler == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12813/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Verify the engine workarounds stick on application
Quoting Tvrtko Ursulin (2019-04-16 11:36:12)
>
> On 16/04/2019 10:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-04-16 10:43:43)
> >>
> >> On 16/04/2019 09:10, Chris Wilson wrote:
> >>> Read the engine workarounds back using the GPU after loading the initial
> >>> context state to verify that we are setting them correctly, and bail if
> >>> it fails.
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/i915_gem.c | 6 +
> >>>drivers/gpu/drm/i915/intel_workarounds.c | 120 ++
> >>>drivers/gpu/drm/i915/intel_workarounds.h | 2 +
> >>>.../drm/i915/selftests/intel_workarounds.c| 53 +---
> >>>4 files changed, 134 insertions(+), 47 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >>> b/drivers/gpu/drm/i915/i915_gem.c
> >>> index 0a818a60ad31..95ae69753e91 100644
> >>> --- a/drivers/gpu/drm/i915/i915_gem.c
> >>> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >>> @@ -4717,6 +4717,12 @@ static int __intel_engines_record_defaults(struct
> >>> drm_i915_private *i915)
> >>>i915_request_add(rq);
> >>>if (err)
> >>>goto err_active;
> >>> +
> >>> + if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) &&
> >>> + intel_engine_verify_workarounds(engine, "load")) {
> >>> + err = -EIO;
> >>> + goto err_active;
> >>
> >> The two submission use different contexts timelines so strictly speaking
> >> should be somehow explicitly serialized.
> >
> > Yes, we are reading from the kernel context. Neither of these contexts
> > will overwrite the existing register state on first load, and there is
> > nothing to prevent fifo here. But it doesn't matter which order the read
> > is done, as the w/a are set by mmio, not engine->init_context().
> > Although I've been contemplating using init_context in case LRI work
> > better.
>
> Using init_context for what, engine wa/?
Yeah, just thinking of other ways to try and hammer icl-2/3 (or
whichever fail today) into submission.
> > It could be in a separate loop beforehand, the only catch is that we
> > expect to leave this function with the GT idle, so it's best done before
> > we park.
>
> Yep since the placement in the ->init_context loop confused me I think a
> separate loop would indeed be better.
>
> __i915_gem_restart_engines looks like the place, to follow
> engine->init_hw which applies the engine workarounds.
Hmm. That may restart with a full engine and a probe take an
unnecessarily, if not dangerously, long time.
load_power_context() perhaps. Bleugh, even on resume, we may have
restarted persistent batches in the near future.
So far I've talked myself into that we only know the system is idle at
init, and when we park the engines. We could squeeze a sanity check into
the parking.
> >>> + i915_request_add(rq);
> >>> + if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0) {
> >>
> >> Wouldn't:
> >>
> >> err = i915_request_wait(...
> >> if (err < 0 || !i915_request_completed())
> >>
> >> be more correct?
> >
> > It can't return for any other reason as it's an uninterruptible wait, so
> > it times out, or the request is completed.
> >
> > If you want to consider that hangcheck could have kicked in the 0.2ms
> > and cancelled the request, then we could need to check
> > request->fence.error.
>
> I was going by the comment for i915_request_wait which says "Returns the
> remaining time (in jiffies) if the request completed, which may be zero
> or -ETIME if the request is unfinished after the timeout expires.". So
> two timeout conditions. Anyways, I know it is highly hypothetical if that.
Hence why we check for < 0, though it could just be -ETIME.
Hmm, the sentence slightly runs on, it's the remaining time that may be
zero if the request completed just in the nick of time. -ETIME is always
the response if the request is not completed at timeout.
-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 series starting with [v2,1/4] drm/i915: Verify workarounds immediately after application (rev2)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Verify workarounds immediately after application (rev2) URL : https://patchwork.freedesktop.org/series/59560/ State : success == Summary == CI Bug Log - changes from CI_DRM_5936 -> Patchwork_12814 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59560/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12814 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-icl-y: NOTRUN -> SKIP [fdo#109315] +17 - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +18 * igt@gem_exec_basic@basic-bsd2: - fi-icl-y: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_basic@gtt-bsd2: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +52 * igt@gem_exec_parse@basic-rejected: - fi-icl-y: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_exec_store@basic-bsd2: - fi-hsw-4770:NOTRUN -> SKIP [fdo#109271] +41 * igt@gem_workarounds@basic-read: - fi-snb-2600:NOTRUN -> SKIP [fdo#109271] +52 * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: PASS -> FAIL [fdo#108511] * igt@kms_addfb_basic@addfb25-y-tiled-small: - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] +51 * igt@kms_busy@basic-flip-c: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-snb-2600:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@dp-crc-fast: - fi-icl-y: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_chamelium@hdmi-edid-read: - fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_force_connector_basic@force-load-detect: - fi-icl-y: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814] * igt@kms_psr@primary_mmap_gtt: - fi-icl-y: NOTRUN -> SKIP [fdo#110189] +3 * igt@kms_psr@primary_page_flip: - fi-skl-lmem:NOTRUN -> SKIP [fdo#109271] +37 * igt@prime_vgem@basic-fence-flip: - fi-icl-y: NOTRUN -> SKIP [fdo#109294] Possible fixes * igt@i915_module_load@reload: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 Participating hosts (43 -> 43) -- Additional (7): fi-hsw-peppy fi-hsw-4770 fi-icl-y fi-skl-lmem fi-byt-n2820 fi-byt-clapper fi-snb-2600 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5936 -> Patchwork_12814 CI_DRM_5936: 0ad14bd30d830a1a355040b29bfafbe6623d84f0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4948: cf27a37b867bf31dccbe5f1b3bd84a2e606544f0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12814: 51bc3ba1bd403dc3fb98067f31b691d192098fa1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 51bc3ba1bd40 drm/i915/selftests: Verify whitelist of context registers aee6d3ccd582 drm/i915: Make workaround verification *optional* 5ae134c4b5f5 drm/i915: Verify the engine workarounds stick on application 7b9f802e0167 drm/i915: Verify workarounds immediately after application == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12814/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Make workaround verification *optional*
Quoting Tvrtko Ursulin (2019-04-16 10:48:05)
>
> On 16/04/2019 09:10, Chris Wilson wrote:
> > Sometimes the HW doesn't even play fair, and completely forgets about
> > register writes. Skip verifying known troublemakers.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/intel_workarounds.c | 40 ++-
> > .../gpu/drm/i915/intel_workarounds_types.h| 7 ++--
> > 2 files changed, 33 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > b/drivers/gpu/drm/i915/intel_workarounds.c
> > index db99f2e676bb..ba58be05f58c 100644
> > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > @@ -122,6 +122,7 @@ static void _wa_add(struct i915_wa_list *wal, const
> > struct i915_wa *wa)
> > wal->wa_count++;
> > wa_->val |= wa->val;
> > wa_->mask |= wa->mask;
> > + wa_->read |= wa->read;
> > return;
> > }
> > }
> > @@ -146,9 +147,10 @@ wa_write_masked_or(struct i915_wa_list *wal,
> > i915_reg_t reg, u32 mask,
> > u32 val)
> > {
> > struct i915_wa wa = {
> > - .reg = reg,
> > + .reg = reg,
> > .mask = mask,
> > - .val = val
> > + .val = val,
> > + .read = mask,
> > };
> >
> > _wa_add(wal, &wa);
> > @@ -172,6 +174,19 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg,
> > u32 val)
> > wa_write_masked_or(wal, reg, val, val);
> > }
> >
> > +static void
> > +ignore_wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 mask, u32
> > val)
> > +{
> > + struct i915_wa wa = {
> > + .reg = reg,
> > + .mask = mask,
> > + .val = val,
> > + /* Bonkers HW, skip verifying */
> > + };
> > +
> > + _wa_add(wal, &wa);
> > +}
> > +
> > #define WA_SET_BIT_MASKED(addr, mask) \
> > wa_write_masked_or(wal, (addr), (mask), _MASKED_BIT_ENABLE(mask))
> >
> > @@ -916,10 +931,11 @@ wal_get_fw_for_rmw(struct intel_uncore *uncore, const
> > struct i915_wa_list *wal)
> > static bool
> > wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
> > *from)
> > {
> > - if ((cur ^ wa->val) & wa->mask) {
> > + if ((cur ^ wa->val) & wa->read) {
> > DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
> > mask=%x)\n",
> > - name, from, i915_mmio_reg_offset(wa->reg), cur,
> > - cur & wa->mask, wa->val, wa->mask);
> > + name, from, i915_mmio_reg_offset(wa->reg),
> > + cur, cur & wa->read,
> > + wa->val, wa->mask);
> >
> > return false;
> > }
> > @@ -1122,9 +1138,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> > struct i915_wa_list *wal)
> >_3D_CHICKEN3_AA_LINE_QUALITY_FIX_ENABLE);
> >
> > /* WaPipelineFlushCoherentLines:icl */
> > - wa_write_or(wal,
> > - GEN8_L3SQCREG4,
> > - GEN8_LQSC_FLUSH_COHERENT_LINES);
> > + ignore_wa_write_or(wal,
> > +GEN8_L3SQCREG4,
> > +GEN8_LQSC_FLUSH_COHERENT_LINES,
> > +GEN8_LQSC_FLUSH_COHERENT_LINES);
> >
> > /*
> >* Wa_1405543622:icl
> > @@ -1151,9 +1168,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> > struct i915_wa_list *wal)
> >* Wa_1405733216:icl
> >* Formerly known as WaDisableCleanEvicts
> >*/
> > - wa_write_or(wal,
> > - GEN8_L3SQCREG4,
> > - GEN11_LQSC_CLEAN_EVICT_DISABLE);
> > + ignore_wa_write_or(wal,
> > +GEN8_L3SQCREG4,
> > +GEN11_LQSC_CLEAN_EVICT_DISABLE,
> > +GEN11_LQSC_CLEAN_EVICT_DISABLE);
> >
> > /* WaForwardProgressSoftReset:icl */
> > wa_write_or(wal,
> > diff --git a/drivers/gpu/drm/i915/intel_workarounds_types.h
> > b/drivers/gpu/drm/i915/intel_workarounds_types.h
> > index 30918da180ff..42ac1fb99572 100644
> > --- a/drivers/gpu/drm/i915/intel_workarounds_types.h
> > +++ b/drivers/gpu/drm/i915/intel_workarounds_types.h
> > @@ -12,9 +12,10 @@
> > #include "i915_reg.h"
> >
> > struct i915_wa {
> > - i915_reg_treg;
> > - u32 mask;
> > - u32 val;
> > + i915_reg_t reg;
> > + u32 mask;
> > + u32 val;
> > + u32 read;
> > };
> >
> > struct i915_w
[Intel-gfx] ✓ Fi.CI.IGT: success for i915/gem_exec_schedule: Fill in obj.offset for spinner resubmission
== Series Details == Series: i915/gem_exec_schedule: Fill in obj.offset for spinner resubmission URL : https://patchwork.freedesktop.org/series/59564/ State : success == Summary == CI Bug Log - changes from IGT_4949_full -> IGTPW_2862_full Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59564/revisions/1/mbox/ Known issues Here are the changes found in IGTPW_2862_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mocs_settings@mocs-reset-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +2 * igt@gem_tiled_swapping@non-threaded: - shard-hsw: PASS -> INCOMPLETE [fdo#103540] +1 * igt@gen3_render_mixed_blits: - shard-hsw: NOTRUN -> SKIP [fdo#109271] +24 * igt@i915_pm_lpsp@edp-native: - shard-iclb: NOTRUN -> SKIP [fdo#109301] * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: PASS -> SKIP [fdo#109271] * igt@i915_pm_rpm@dpms-lpsp: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +12 * igt@i915_pm_rpm@modeset-non-lpsp-stress: - shard-iclb: NOTRUN -> SKIP [fdo#109308] * igt@kms_busy@extended-pageflip-hang-newfb-render-d: - shard-hsw: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_chamelium@hdmi-cmp-planes-random: - shard-iclb: NOTRUN -> SKIP [fdo#109284] * igt@kms_content_protection@legacy: - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_cursor_crc@cursor-512x512-suspend: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +2 * igt@kms_cursor_legacy@pipe-a-forked-move: - shard-apl: PASS -> DMESG-WARN [fdo#110376] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-iclb: PASS -> FAIL [fdo#103167] / [fdo#110378] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-cpu: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +6 * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +5 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-iclb: PASS -> FAIL [fdo#109247] +15 * igt@kms_frontbuffer_tracking@psr-slowdraw: - shard-apl: NOTRUN -> SKIP [fdo#109271] +90 * igt@kms_pipe_crc_basic@read-crc-pipe-f: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +4 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-f: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-apl: NOTRUN -> FAIL [fdo#108145] * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109441] * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: PASS -> SKIP [fdo#109441] +4 * igt@kms_setmode@basic: - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_universal_plane@disable-primary-vs-flip-pipe-e: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@v3d_get_bo_offset@get-bad-handle: - shard-iclb: NOTRUN -> SKIP [fdo#109315] Possible fixes * igt@gem_exec_reloc@basic-write-read: - shard-iclb: INCOMPLETE [fdo#107713] -> PASS * igt@gem_workarounds@suspend-resume: - shard-apl: DMESG-WARN [fdo#108566] -> PASS +8 * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP [fdo#109271] -> PASS * igt@kms_fbcon_fbt@psr-suspend: - shard-iclb: FAIL [fdo#103833] -> PASS * igt@kms_flip@nonexisting-fb-interruptible: - shard-kbl: SKIP [fdo#109271] -> PASS * igt@kms_frontbuffer_tracking@fbc-tilingchange: - shard-iclb: FAIL [fdo#103167] -> PASS +6 * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte: - shard-iclb: FAIL [fdo#103167] / [fdo#110378] -> PASS * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: FAIL [fdo#109247] -> PASS +14 * igt@kms_plane_scaling@pipe-b-scaler-with-rotation: - shard-glk: SKIP [fdo#109271] / [fdo#109278] -> PASS * igt@kms_psr@primary_render: - shard-iclb: FAIL [fdo#107383] / [fdo#110215] -> PASS * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: SKIP [fdo#109441] -> PASS * igt@testdisplay: - shard-kbl: INCOMPLETE [fdo#103665] -
Re: [Intel-gfx] [PATCH 11/11] [v3] drm/i915: Add intel_compare_color_lut() to compare hw and sw gamma lut values
Hi Swati,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Swati-Sharma/drm-i915-adding-state-checker-for-gamma-lut-values/20190416-021708
base: git://anongit.freedesktop.org/drm-intel for-linux-next
New smatch warnings:
drivers/gpu/drm/i915/intel_color.c:1519 intel_compare_color_lut() warn:
variable dereferenced before check 'blob1' (see line 1514)
drivers/gpu/drm/i915/intel_color.c:1519 intel_compare_color_lut() warn:
variable dereferenced before check 'blob2' (see line 1515)
#
https://github.com/0day-ci/linux/commit/14a61c5a3c40291ad8779909b5fdc261aad53df3
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 14a61c5a3c40291ad8779909b5fdc261aad53df3
vim +/blob1 +1519 drivers/gpu/drm/i915/intel_color.c
14a61c5a Swati Sharma 2019-04-15 1510 bool intel_compare_color_lut(struct
drm_property_blob *blob1,
14a61c5a Swati Sharma 2019-04-15 1511 struct
drm_property_blob *blob2,
14a61c5a Swati Sharma 2019-04-15 1512 u32
gamma_mode)
14a61c5a Swati Sharma 2019-04-15 1513 {
14a61c5a Swati Sharma 2019-04-15 @1514 struct drm_color_lut *sw_lut =
blob1->data;
^^^
14a61c5a Swati Sharma 2019-04-15 @1515 struct drm_color_lut *hw_lut =
blob2->data;
^^^
14a61c5a Swati Sharma 2019-04-15 1516 int sw_lut_size, hw_lut_size, i;
14a61c5a Swati Sharma 2019-04-15 1517 u32 bit_precision, err;
14a61c5a Swati Sharma 2019-04-15 1518
14a61c5a Swati Sharma 2019-04-15 @1519 if (!blob1 || !blob2)
^^^
14a61c5a Swati Sharma 2019-04-15 1520 return false;
14a61c5a Swati Sharma 2019-04-15 1521
14a61c5a Swati Sharma 2019-04-15 1522 switch(gamma_mode) {
14a61c5a Swati Sharma 2019-04-15 1523 case GAMMA_MODE_MODE_8BIT:
14a61c5a Swati Sharma 2019-04-15 1524 bit_precision = 8;
14a61c5a Swati Sharma 2019-04-15 1525 break;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/22] drm/i915/guc: Reset GuC ADS during sanitize
Only comment issues. Besides these:
Reviewed-by: Tomasz Lis
On 2019-04-11 10:44, Michal Wajdeczko wrote:
GuC stores some data in there, which might be stale after a reset.
Reinitialize whole ADS in case any part of it was corrupted during
previous GuC run.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: MichaĹ Winiarski
Cc: Tomasz Lis
---
drivers/gpu/drm/i915/intel_guc.h | 2 +
drivers/gpu/drm/i915/intel_guc_ads.c | 85 ++--
drivers/gpu/drm/i915/intel_guc_ads.h | 1 +
3 files changed, 57 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 2c59ff8d9f39..4f3cf8eddfe6 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -26,6 +26,7 @@
#define _INTEL_GUC_H_
#include "intel_uncore.h"
+#include "intel_guc_ads.h"
#include "intel_guc_fw.h"
#include "intel_guc_fwif.h"
#include "intel_guc_ct.h"
@@ -177,6 +178,7 @@ u32 intel_guc_reserved_gtt_size(struct intel_guc *guc);
static inline int intel_guc_sanitize(struct intel_guc *guc)
{
intel_uc_fw_sanitize(&guc->fw);
+ intel_guc_ads_reset(guc);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c b/drivers/gpu/drm/i915/intel_guc_ads.c
index abab5cb6909a..97926effb944 100644
--- a/drivers/gpu/drm/i915/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/intel_guc_ads.c
@@ -72,43 +72,28 @@ static void guc_ct_pool_entries_init(struct
guc_ct_pool_entry *pool, u32 num)
*/
#define LR_HW_CONTEXT_SIZE(80 * sizeof(u32))
-/**
- * intel_guc_ads_create() - creates GuC ADS
- * @guc: intel_guc struct
- *
- */
-int intel_guc_ads_create(struct intel_guc *guc)
+/* The ads obj includes the struct itself and buffers passed to GuC */
+struct __guc_ads_blob {
+ struct guc_ads ads;
+ struct guc_policies policies;
+ struct guc_mmio_reg_state reg_state;
+ struct guc_gt_system_info system_info;
+ struct guc_clients_info clients_info;
+ struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
+ u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE];
+} __packed;
+
+static int __guc_ads_reinit(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
- struct i915_vma *vma;
- /* The ads obj includes the struct itself and buffers passed to GuC */
- struct {
- struct guc_ads ads;
- struct guc_policies policies;
- struct guc_mmio_reg_state reg_state;
- struct guc_gt_system_info system_info;
- struct guc_clients_info clients_info;
- struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
- u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE];
- } __packed *blob;
+ struct __guc_ads_blob *blob;
const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
u32 base;
u8 engine_class;
- int ret;
-
- GEM_BUG_ON(guc->ads_vma);
-
- vma = intel_guc_allocate_vma(guc, PAGE_ALIGN(sizeof(*blob)));
- if (IS_ERR(vma))
- return PTR_ERR(vma);
-
- guc->ads_vma = vma;
blob = i915_gem_object_pin_map(guc->ads_vma->obj, I915_MAP_WB);
- if (IS_ERR(blob)) {
- ret = PTR_ERR(blob);
- goto err_vma;
- }
+ if (IS_ERR(blob))
+ return PTR_ERR(blob);
/* GuC scheduling policies */
guc_policies_init(&blob->policies);
@@ -142,7 +127,7 @@ int intel_guc_ads_create(struct intel_guc *guc)
blob->system_info.vebox_enable_mask = VEBOX_MASK(dev_priv);
blob->system_info.vdbox_sfc_support_mask =
RUNTIME_INFO(dev_priv)->vdbox_sfc_access;
- base = intel_guc_ggtt_offset(guc, vma);
+ base = intel_guc_ggtt_offset(guc, guc->ads_vma);
/* Clients info */
guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
@@ -161,6 +146,32 @@ int intel_guc_ads_create(struct intel_guc *guc)
i915_gem_object_unpin_map(guc->ads_vma->obj);
return 0;
+}
+
+/**
+ * intel_guc_ads_create() - creates GuC ADS
+ * @guc: intel_guc struct
Are we really ok with documentation which just reads names with spaces
instead of underscores?
I believe the description should go deeper, or at least use different
words to describe the thing.
ie. here:
intel_guc_ads_create() - allocates and initializes GuC Additional Data Struct
@guc: instance of intel_guc which will own the ADS
+ *
+ */
+int intel_guc_ads_create(struct intel_guc *guc)
+{
+ const u32 size = PAGE_ALIGN(sizeof(struct __guc_ads_blob));
+ struct i915_vma *vma;
+ int ret;
+
+ GEM_BUG_ON(guc->ads_vma);
+
+ vma = intel_guc_allocate_vma(guc, size);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ guc->ads_vma = vma;
+
+ ret = __guc_ads_reinit(guc);
+ if (ret)
+ goto err_vma;
+
+ return 0;
err_vma:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/2] drm/i915: start moving state checker to intel_verify.c
== Series Details == Series: series starting with [RFC,1/2] drm/i915: start moving state checker to intel_verify.c URL : https://patchwork.freedesktop.org/series/59569/ State : warning == Summary == $ dim checkpatch origin/drm-tip a4e2e34c9de6 drm/i915: start moving state checker to intel_verify.c -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:599: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #599: new file mode 100644 -:757: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #757: FILE: drivers/gpu/drm/i915/intel_verify.c:154: + * internal consistency). */ -:771: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #771: FILE: drivers/gpu/drm/i915/intel_verify.c:168: + I915_STATE_WARN(!crtc_state, +"connector enabled without attached crtc\n"); -:777: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #777: FILE: drivers/gpu/drm/i915/intel_verify.c:174: + I915_STATE_WARN(!crtc_state->active, + "connector is active, but attached crtc isn't\n"); -:783: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #783: FILE: drivers/gpu/drm/i915/intel_verify.c:180: + I915_STATE_WARN(conn_state->best_encoder != &encoder->base, + "atomic encoder doesn't match attached encoder\n"); -:786: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #786: FILE: drivers/gpu/drm/i915/intel_verify.c:183: + I915_STATE_WARN(conn_state->crtc != encoder->base.crtc, + "attached encoder crtc differs from connector crtc\n"); -:789: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #789: FILE: drivers/gpu/drm/i915/intel_verify.c:186: + I915_STATE_WARN(crtc_state && crtc_state->active, + "attached crtc is active, but connector isn't\n"); -:791: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #791: FILE: drivers/gpu/drm/i915/intel_verify.c:188: + I915_STATE_WARN(!crtc_state && conn_state->best_encoder, + "best encoder set without crtc!\n"); -:817: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #817: FILE: drivers/gpu/drm/i915/intel_verify.c:214: + I915_STATE_WARN(new_conn_state->best_encoder != encoder, +"connector's atomic encoder doesn't match legacy encoder\n"); -:844: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #844: FILE: drivers/gpu/drm/i915/intel_verify.c:241: + found = enabled = true; -:855: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #855: FILE: drivers/gpu/drm/i915/intel_verify.c:252: + I915_STATE_WARN(!!encoder->base.crtc != enabled, +"encoder's enabled state mismatch " -:864: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #864: FILE: drivers/gpu/drm/i915/intel_verify.c:261: + I915_STATE_WARN(active, +"encoder detached but still enabled on pipe %c.\n", -:899: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #899: FILE: drivers/gpu/drm/i915/intel_verify.c:296: + I915_STATE_WARN(new_crtc_state->active != active, +"crtc active state doesn't match with hw state " -:903: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #903: FILE: drivers/gpu/drm/i915/intel_verify.c:300: + I915_STATE_WARN(intel_crtc->active != new_crtc_state->active, +"transitional active state does not match atomic hw state " -:911: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #911: FILE: drivers/gpu/drm/i915/intel_verify.c:308: + I915_STATE_WARN(active != new_crtc_state->active, + "[ENCODER:%i] active %i with crtc active %i\n", -:971: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #971: FILE: drivers/gpu/drm/i915/intel_verify.c:368: + I915_STATE_WARN(!pll->on && pll->active_mask, +"pll in active use but not on in sw tracking\n"); -:973: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #973: FILE: drivers/gpu/drm/i915/intel_verify.c:370: + I915_STATE_WARN(pll->on && !pll->active_mask, +"pll is on but not used by any active crtc\n"); -:975: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #975: FILE: drivers/gpu/drm/i915/intel_verify.c:372: + I915_STATE_WARN(pll->on != active, +"pll on state mismatch (expected %i, found %i)\n", total: 0 errors, 3 warnings, 16 checks, 1051 lines checked 73e020a244ec drm/i915: move pipe config compare to intel_verify.c -:7: WARNING:COMMIT_MESSAGE: Missing commi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [RFC,1/2] drm/i915: start moving state checker to intel_verify.c
== Series Details == Series: series starting with [RFC,1/2] drm/i915: start moving state checker to intel_verify.c URL : https://patchwork.freedesktop.org/series/59569/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: start moving state checker to intel_verify.c +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: move pipe config compare to intel_verify.c Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/50] drm/i915: Mark up ips for RCU protection
Chris Wilson writes:
> drivers/gpu/drm/i915/intel_pm.c:8352:9: error: incompatible types in
> comparison expression (different address spaces)
> drivers/gpu/drm/i915/intel_pm.c:8359:9: error: incompatible types in
> comparison expression (different address spaces)
>
Yes, they are gone,
Reviewed-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8e826a6ab62e..934bbcf62025 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8263,14 +8263,14 @@ unsigned long i915_gfx_val(struct drm_i915_private
> *dev_priv)
> return val;
> }
>
> -static struct drm_i915_private *i915_mch_dev;
> +static struct drm_i915_private __rcu *i915_mch_dev;
>
> static struct drm_i915_private *mchdev_get(void)
> {
> struct drm_i915_private *i915;
>
> rcu_read_lock();
> - i915 = i915_mch_dev;
> + i915 = rcu_dereference(i915_mch_dev);
> if (!kref_get_unless_zero(&i915->drm.ref))
> i915 = NULL;
> rcu_read_unlock();
> --
> 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
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: inherit icl cdclk init/uninit
== Series Details == Series: drm/i915/ehl: inherit icl cdclk init/uninit URL : https://patchwork.freedesktop.org/series/59562/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5936_full -> Patchwork_12812_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12812_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12812_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_12812_full: ### IGT changes ### Possible regressions * igt@gem_exec_blt@normal-max: - shard-iclb: PASS -> INCOMPLETE Known issues Here are the changes found in Patchwork_12812_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@gem_mmap_gtt@basic: - shard-apl: NOTRUN -> INCOMPLETE [fdo#103927] * igt@gem_workarounds@suspend-resume-context: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +4 * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@i915_pm_rpm@modeset-pc8-residency-stress: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@kms_atomic_transition@3x-modeset-transitions: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +11 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-f: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_content_protection@atomic: - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_content_protection@legacy: - shard-kbl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc: - shard-skl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] +5 * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +21 * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> SKIP [fdo#109271] +127 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-onoff: - shard-iclb: PASS -> FAIL [fdo#109247] +7 * igt@kms_lease@atomic_implicit_crtc: - shard-skl: NOTRUN -> FAIL [fdo#110279] * igt@kms_plane@pixel-format-pipe-c-planes: - shard-glk: PASS -> SKIP [fdo#109271] * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-apl: NOTRUN -> FAIL [fdo#108145] +2 - shard-skl: NOTRUN -> FAIL [fdo#108145] +3 * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_psr@sprite_mmap_gtt: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2 * igt@kms_setmode@basic: - shard-kbl: PASS -> FAIL [fdo#99912] * igt@prime_nv_api@i915_nv_reimport_twice_check_flink_name: - shard-apl: NOTRUN -> SKIP [fdo#109271] +59 Possible fixes * igt@gem_ctx_isolation@vcs1-s3: - shard-kbl: DMESG-WARN [fdo#108566] -> PASS +1 * igt@i915_pm_rpm@dpms-non-lpsp: - shard-apl: DMESG-WARN [fdo#110376] -> PASS * igt@i915_selftest@live_workarounds: - shard-iclb: DMESG-FAIL [fdo#108954] -> PASS * igt@i915_suspend@debugfs-reader: - shard-apl: DMESG-WARN [fdo#108566] -> PASS +2 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS - shard-glk: FAIL [fdo#102887] -> PASS * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: FAIL [fdo#102887] / [fdo#105363] -> PASS - shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite: - shard-iclb: FAIL [fdo#109247] -> PASS +16 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt: - shard-iclb: FAIL [fdo#103167] -> PASS +4 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/2] drm/i915: start moving state checker to intel_verify.c
== Series Details == Series: series starting with [RFC,1/2] drm/i915: start moving state checker to intel_verify.c URL : https://patchwork.freedesktop.org/series/59569/ State : success == Summary == CI Bug Log - changes from CI_DRM_5937 -> Patchwork_12815 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59569/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12815 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965] * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +71 * igt@kms_busy@basic-flip-c: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: PASS -> FAIL [fdo#103167] Possible fixes * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: FAIL [fdo#108511] -> PASS * igt@i915_selftest@live_execlists: - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: FAIL [fdo#103191] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 Participating hosts (48 -> 42) -- Additional (1): fi-pnv-d510 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-ctg-p8600 fi-icl-y fi-bdw-samus Build changes - * Linux: CI_DRM_5937 -> Patchwork_12815 CI_DRM_5937: f65ca0674f94ab6a66bcec4d3a27b5e2c06f1813 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4951: cc9a60c029432b5843724e4f2c57f9f815f7adbb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12815: 73e020a244ecd62e3619f91b0d55aad5b28249fa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 73e020a244ec drm/i915: move pipe config compare to intel_verify.c a4e2e34c9de6 drm/i915: start moving state checker to intel_verify.c == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12815/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Verify workarounds immediately after application
Immediately after writing the workaround, verify that it stuck in the
register.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 32 +---
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index ccaf63679435..ea9292ee755a 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -913,6 +913,20 @@ wal_get_fw_for_rmw(struct intel_uncore *uncore, const
struct i915_wa_list *wal)
return fw;
}
+static bool
+wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
+{
+ if ((cur ^ wa->val) & wa->mask) {
+ DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
+ name, from, i915_mmio_reg_offset(wa->reg), cur,
+ cur & wa->mask, wa->val, wa->mask);
+
+ return false;
+ }
+
+ return true;
+}
+
static void
wa_list_apply(struct intel_uncore *uncore, const struct i915_wa_list *wal)
{
@@ -931,6 +945,10 @@ wa_list_apply(struct intel_uncore *uncore, const struct
i915_wa_list *wal)
for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
intel_uncore_rmw_fw(uncore, wa->reg, wa->mask, wa->val);
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ wa_verify(wa,
+ intel_uncore_read_fw(uncore, wa->reg),
+ wal->name, "application");
}
intel_uncore_forcewake_put__locked(uncore, fw);
@@ -942,20 +960,6 @@ void intel_gt_apply_workarounds(struct drm_i915_private
*i915)
wa_list_apply(&i915->uncore, &i915->gt_wa_list);
}
-static bool
-wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
-{
- if ((cur ^ wa->val) & wa->mask) {
- DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
- name, from, i915_mmio_reg_offset(wa->reg), cur,
- cur & wa->mask, wa->val, wa->mask);
-
- return false;
- }
-
- return true;
-}
-
static bool wa_list_verify(struct intel_uncore *uncore,
const struct i915_wa_list *wal,
const char *from)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Verify the engine workarounds stick on application
Read the engine workarounds back using the GPU after loading the initial
context state to verify that we are setting them correctly, and bail if
it fails.
v2: Break out the verification into its own loop
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 21 +++
drivers/gpu/drm/i915/intel_workarounds.c | 120 ++
drivers/gpu/drm/i915/intel_workarounds.h | 2 +
.../drm/i915/selftests/intel_workarounds.c| 53 +---
4 files changed, 149 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a818a60ad31..a5412323fee1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4842,6 +4842,23 @@ static void i915_gem_fini_scratch(struct
drm_i915_private *i915)
i915_vma_unpin_and_release(&i915->gt.scratch, 0);
}
+static int intel_engines_verify_workarounds(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int err = 0;
+
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return 0;
+
+ for_each_engine(engine, i915, id) {
+ if (intel_engine_verify_workarounds(engine, "load"))
+ err = -EIO;
+ }
+
+ return err;
+}
+
int i915_gem_init(struct drm_i915_private *dev_priv)
{
int ret;
@@ -4927,6 +4944,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
*/
intel_init_clock_gating(dev_priv);
+ ret = intel_engines_verify_workarounds(dev_priv);
+ if (ret)
+ goto err_init_hw;
+
ret = __intel_engines_record_defaults(dev_priv);
if (ret)
goto err_init_hw;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index ea9292ee755a..89e2c603e34b 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1259,6 +1259,126 @@ void intel_engine_apply_workarounds(struct
intel_engine_cs *engine)
wa_list_apply(engine->uncore, &engine->wa_list);
}
+static struct i915_vma *
+create_scratch(struct i915_address_space *vm, int count)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ unsigned int size;
+ int err;
+
+ size = round_up(count * sizeof(u32), PAGE_SIZE);
+ obj = i915_gem_object_create_internal(vm->i915, size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_obj;
+ }
+
+ err = i915_vma_pin(vma, 0, 0,
+ i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+ if (err)
+ goto err_obj;
+
+ return vma;
+
+err_obj:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+wa_list_srm(struct i915_request *rq,
+ const struct i915_wa_list *wal,
+ struct i915_vma *vma)
+{
+ const struct i915_wa *wa;
+ unsigned int i;
+ u32 srm, *cs;
+
+ srm = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (INTEL_GEN(rq->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * wal->count);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(wa->reg);
+ *cs++ = i915_ggtt_offset(vma) + sizeof(u32) * i;
+ *cs++ = 0;
+ }
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int engine_wa_list_verify(struct intel_engine_cs *engine,
+const struct i915_wa_list * const wal,
+const char *from)
+{
+ const struct i915_wa *wa;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ unsigned int i;
+ u32 *results;
+ int err;
+
+ if (!wal->count)
+ return 0;
+
+ vma = create_scratch(&engine->i915->ggtt.vm, wal->count);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ rq = i915_request_alloc(engine, engine->kernel_context->gem_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_vma;
+ }
+
+ err = wa_list_srm(rq, wal, vma);
+ if (err)
+ goto err_vma;
+
+ i915_request_add(rq);
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0) {
+ err = -ETIME;
+ goto err_vma;
+ }
+
+ results = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);
+ if (IS_ERR(results)) {
+ err = PTR_ERR(results);
+ goto err_vma;
+ }
+
+ err = 0;
+ for (i = 0, wa = wal->li
Re: [Intel-gfx] [PATCH v3] drm/i915: add immutable zpos plane properties
On Sat, Apr 13, 2019 at 11:13:27AM +, Simon Ser wrote:
> From: Ville Syrjälä
>
> This adds basic immutable support for the zpos property. The zpos increases
> from bottom to top: primary, sprites, cursor.
I was thinking a bit about how we might go about testing this.
We probably want a basic test that just checks that if any
plane has a zpos prop then all planes should have it.
A functional test would stack the planes up in some way and
compare against a software rendered reference. IIRC there was
a zpos test case floating around but that depended on alpha
blending which we don't necessarily have.
>
> Signed-off-by: Ville Syrjälä
> [cont...@emersion.fr: adapted for latest drm-tip]
> Signed-off-by: Simon Ser
> ---
>
> Maarten, could your review this patch?
>
> Changes from v2 to v3: add the zpos property in skl_universal_plane_create
> too.
>
> drivers/gpu/drm/i915/intel_display.c | 10 --
> drivers/gpu/drm/i915/intel_sprite.c | 7 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8576a7f799..f0a85a75bd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14323,7 +14323,7 @@ intel_primary_plane_create(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> - int ret;
> + int ret, zpos;
>
> if (INTEL_GEN(dev_priv) >= 9)
> return skl_universal_plane_create(dev_priv, pipe,
> @@ -14412,6 +14412,9 @@ intel_primary_plane_create(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> DRM_MODE_ROTATE_0,
> supported_rotations);
>
> + zpos = 0;
> + drm_plane_create_zpos_immutable_property(&plane->base, zpos);
> +
> drm_plane_helper_add(&plane->base, &intel_plane_helper_funcs);
>
> return plane;
> @@ -14428,7 +14431,7 @@ intel_cursor_plane_create(struct drm_i915_private
> *dev_priv,
> {
> unsigned int possible_crtcs;
> struct intel_plane *cursor;
> - int ret;
> + int ret, zpos;
>
> cursor = intel_plane_alloc();
> if (IS_ERR(cursor))
> @@ -14477,6 +14480,9 @@ intel_cursor_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_MODE_ROTATE_0 |
> DRM_MODE_ROTATE_180);
>
> + zpos = RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1;
> + drm_plane_create_zpos_immutable_property(&cursor->base, zpos);
> +
> drm_plane_helper_add(&cursor->base, &intel_plane_helper_funcs);
>
> return cursor;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 65de7387bf..40b7bcd720 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -2333,6 +2333,8 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
>BIT(DRM_MODE_BLEND_PREMULTI) |
>BIT(DRM_MODE_BLEND_COVERAGE));
>
> + drm_plane_create_zpos_immutable_property(&plane->base, plane_id);
> +
> drm_plane_helper_add(&plane->base, &intel_plane_helper_funcs);
>
> return plane;
> @@ -2354,7 +2356,7 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> - int ret;
> + int ret, zpos;
>
> if (INTEL_GEN(dev_priv) >= 9)
> return skl_universal_plane_create(dev_priv, pipe,
> @@ -2444,6 +2446,9 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_COLOR_YCBCR_BT709,
> DRM_COLOR_YCBCR_LIMITED_RANGE);
>
> + zpos = sprite + 1;
> + drm_plane_create_zpos_immutable_property(&plane->base, zpos);
> +
> drm_plane_helper_add(&plane->base, &intel_plane_helper_funcs);
>
> return plane;
> --
> 2.21.0
>
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable workaround for pixel shader dispatch hang
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-04-15 15:45:29)
>> Set chicken bits to workaround a possible pixel shader
>> dispatch hang.
>>
>> v2: no need to filter out preprod skl (Ville, Chris)
>> v3: formatting
>>
>> Bspec: 14091, ID#0651
>> Cc: Chris Wilson
>> Cc: Ville Syrjälä
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 4
>> drivers/gpu/drm/i915/intel_workarounds.c | 4
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index c1c0f7ab03e9..499cc843443d 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -8902,11 +8902,15 @@ enum {
>> #define GEN7_ROW_CHICKEN2_GT2 _MMIO(0xf4f4)
>> #define DOP_CLOCK_GATING_DISABLE (1 << 0)
>> #define PUSH_CONSTANT_DEREF_DISABLE (1 << 8)
>> +#define GEN8_DISABLE_RR_ARBITRATION (1 << 1)
>> #define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
>>
>> #define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
>> #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
>>
>> +#define GEN8_ROW_CHICKEN4 _MMIO(0xe48c)
>> +#define GEN8_DISABLE_TDL_FIX (1 << 3)
>> +
>> #define HALF_SLICE_CHICKEN2_MMIO(0xe180)
>> #define GEN8_ST_PO_DISABLE (1 << 13)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
>> b/drivers/gpu/drm/i915/intel_workarounds.c
>> index ccaf63679435..b4709de49552 100644
>> --- a/drivers/gpu/drm/i915/intel_workarounds.c
>> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
>> @@ -294,6 +294,10 @@ static void gen9_ctx_workarounds_init(struct
>> intel_engine_cs *engine)
>> FLOW_CONTROL_ENABLE |
>> PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
>>
>> + /* Bspec wa: 0651, disable rr arb and enable tdl fix */
>> + WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN8_DISABLE_RR_ARBITRATION);
>> + WA_CLR_BIT_MASKED(GEN8_ROW_CHICKEN4, GEN8_DISABLE_TDL_FIX);
>
> In your first patch, you had this only applying to Skylake. Is that
> still the case? i.e. do we need if (IS_SKYLAKE()) { ... }
I had !SKL_REVID() so I only wanted to exclude everything up to G0.
Bspec on row chicken 2 says that we want this from skl G0 onwards and
bxt b0 onwards up to ICL. So with preprods out, I think it holds.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Fill in obj.offset for spinner resubmission
Chris Wilson writes:
> When resubmitting the spinner, fill in the expected offset so that we
> are not tempted to relocate it across contexts (as the spinner must
> point back to itself for the MI_BB_START to work). In this case, these
> should work correctly as they are reusing the same active vma, but for
> pedagogy we should dtrt.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_exec_schedule.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> index 29653ae24..6f3f52d20 100644
> --- a/tests/i915/gem_exec_schedule.c
> +++ b/tests/i915/gem_exec_schedule.c
> @@ -223,12 +223,9 @@ static void independent(int fd, unsigned int engine)
> if (spin == NULL) {
> spin = __igt_spin_batch_new(fd, .engine = other);
> } else {
> - struct drm_i915_gem_exec_object2 obj = {
> - .handle = spin->handle,
> - };
> struct drm_i915_gem_execbuffer2 eb = {
> .buffer_count = 1,
> - .buffers_ptr = to_user_pointer(&obj),
> + .buffers_ptr = to_user_pointer(&spin->obj[1]),
> .flags = other,
> };
> gem_execbuf(fd, &eb);
> @@ -621,12 +618,9 @@ static igt_spin_t *__noise(int fd, uint32_t ctx, int
> prio, igt_spin_t *spin)
> .ctx = ctx,
> .engine = other);
> } else {
> - struct drm_i915_gem_exec_object2 obj = {
> - .handle = spin->handle,
> - };
> struct drm_i915_gem_execbuffer2 eb = {
> .buffer_count = 1,
> - .buffers_ptr = to_user_pointer(&obj),
> + .buffers_ptr = to_user_pointer(&spin->obj[1]),
> .rsvd1 = ctx,
> .flags = other,
> };
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: add immutable zpos plane properties
Op 16-04-2019 om 15:20 schreef Ville Syrjälä: > On Sat, Apr 13, 2019 at 11:13:27AM +, Simon Ser wrote: >> From: Ville Syrjälä >> >> This adds basic immutable support for the zpos property. The zpos increases >> from bottom to top: primary, sprites, cursor. > I was thinking a bit about how we might go about testing this. > > We probably want a basic test that just checks that if any > plane has a zpos prop then all planes should have it. This would be a good test for BAT. > A functional test would stack the planes up in some way and > compare against a software rendered reference. IIRC there was > a zpos test case floating around but that depended on alpha > blending which we don't necessarily have. But with semi-overlapping planes you would accomplish the same, without alpha dependency. Something like this? [BG] [Sprite 1][Cursor] [Primary] [Sprite 2] Perhaps primary fullscreen to prevent issues with hw that doesn't support partial planes? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable workaround for pixel shader dispatch hang
Quoting Mika Kuoppala (2019-04-16 14:26:19)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-04-15 15:45:29)
> >> Set chicken bits to workaround a possible pixel shader
> >> dispatch hang.
> >>
> >> v2: no need to filter out preprod skl (Ville, Chris)
> >> v3: formatting
> >>
> >> Bspec: 14091, ID#0651
> >> Cc: Chris Wilson
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Mika Kuoppala
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 4
> >> drivers/gpu/drm/i915/intel_workarounds.c | 4
> >> 2 files changed, 8 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index c1c0f7ab03e9..499cc843443d 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -8902,11 +8902,15 @@ enum {
> >> #define GEN7_ROW_CHICKEN2_GT2 _MMIO(0xf4f4)
> >> #define DOP_CLOCK_GATING_DISABLE (1 << 0)
> >> #define PUSH_CONSTANT_DEREF_DISABLE (1 << 8)
> >> +#define GEN8_DISABLE_RR_ARBITRATION (1 << 1)
> >> #define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
> >>
> >> #define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
> >> #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
> >>
> >> +#define GEN8_ROW_CHICKEN4 _MMIO(0xe48c)
> >> +#define GEN8_DISABLE_TDL_FIX (1 << 3)
> >> +
> >> #define HALF_SLICE_CHICKEN2_MMIO(0xe180)
> >> #define GEN8_ST_PO_DISABLE (1 << 13)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> >> b/drivers/gpu/drm/i915/intel_workarounds.c
> >> index ccaf63679435..b4709de49552 100644
> >> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> >> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> >> @@ -294,6 +294,10 @@ static void gen9_ctx_workarounds_init(struct
> >> intel_engine_cs *engine)
> >> FLOW_CONTROL_ENABLE |
> >> PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
> >>
> >> + /* Bspec wa: 0651, disable rr arb and enable tdl fix */
> >> + WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN8_DISABLE_RR_ARBITRATION);
> >> + WA_CLR_BIT_MASKED(GEN8_ROW_CHICKEN4, GEN8_DISABLE_TDL_FIX);
> >
> > In your first patch, you had this only applying to Skylake. Is that
> > still the case? i.e. do we need if (IS_SKYLAKE()) { ... }
>
> I had !SKL_REVID() so I only wanted to exclude everything up to G0.
>
> Bspec on row chicken 2 says that we want this from skl G0 onwards and
> bxt b0 onwards up to ICL. So with preprods out, I think it holds.
Ok, I'm easily convinced.
Acked-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: add immutable zpos plane properties
On Tue, Apr 16, 2019 at 03:28:15PM +0200, Maarten Lankhorst wrote: > Op 16-04-2019 om 15:20 schreef Ville Syrjälä: > > On Sat, Apr 13, 2019 at 11:13:27AM +, Simon Ser wrote: > >> From: Ville Syrjälä > >> > >> This adds basic immutable support for the zpos property. The zpos increases > >> from bottom to top: primary, sprites, cursor. > > I was thinking a bit about how we might go about testing this. > > > > We probably want a basic test that just checks that if any > > plane has a zpos prop then all planes should have it. > This would be a good test for BAT. > > A functional test would stack the planes up in some way and > > compare against a software rendered reference. IIRC there was > > a zpos test case floating around but that depended on alpha > > blending which we don't necessarily have. > > But with semi-overlapping planes you would accomplish the same, without alpha > dependency. > > Something like this? > > [BG] [Sprite 1][Cursor] > [Primary] [Sprite 2] Should probably be good enough. Though I was pondering is there a way to position an arbitraty number of planes such that the resulting picture has a visible region for every possible combination of planes? > > Perhaps primary fullscreen to prevent issues with hw that doesn't support > partial planes? I guess. And maybe a second test that disables the primary so that we can also get the bg color into the picture? -- 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 v5 1/2] drm: Add detection of changing of edid on between suspend and resume
On Thu, 2019-04-11 at 17:00 +0100, Lisovskiy, Stanislav wrote:
> On Thu, 2019-04-11 at 17:36 +0300, Gwan-gyeong Mun wrote:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can
> > detect
> > changing of status of connector, but it can not detect changing of
> > edid.
> >
> > Following scenario requires detection of changing of edid.
> >
> > 1) plug display device to a connector
> > 2) system suspend
> > 3) unplug 1)'s display device and plug the other display device to
> > a
> > connector
> > 4) system resume
> >
> > It adds edid check routine when a connector status still remains as
> > "connector_status_connected".
> >
> > v2: Add NULL check before comparing of EDIDs.
> > v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan,
> > Mika)
> > v4: Rebased
> > v5: Use a cached edid property blob data of connector instead of
> > adding
> > a new detected_edid variable. (Maarten)
> > Add an using of reference count for getting a cached edid
> > property
> > blob data. (Maarten)
> >
> > Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate
> > Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend
> > Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate
> > Testcase: igt/kms_chamelium/dp-edid-change-during-suspend
> >
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 34
> > +-
> > 1 file changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 6fd08e04b323..27ad7f3dabb7 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -742,7 +742,16 @@ EXPORT_SYMBOL(drm_kms_helper_poll_fini);
> > * panels.
> > *
> > * This helper function is useful for drivers which can't or don't
> > track hotplug
> > - * interrupts for each connector.
> > + * interrupts for each connector. And it also supports a detection
> > of changing
> > + * of edid on between suspend and resume when a connector status
> > still remains
> > + * as "connector_status_connected".
> > + *
> > + * Following scenario requires detection of changing of edid.
> > + * 1) plug display device to a connector
> > + * 2) system suspend
> > + * 3) unplug 1)'s display device and plug the other display
> > device
> > to a
> > + * connector
> > + * 4) system resume
> > *
> > * Drivers which support hotplug interrupts for each connector
> > individually and
> > * which have a more fine-grained detect logic should bypass this
> > code and
> > @@ -760,6 +769,7 @@ bool drm_helper_hpd_irq_event(struct drm_device
> > *dev)
> > struct drm_connector *connector;
> > struct drm_connector_list_iter conn_iter;
> > enum drm_connector_status old_status;
> > + struct drm_property_blob *old_edid_blob_ptr;
> > bool changed = false;
> >
> > if (!dev->mode_config.poll_enabled)
> > @@ -774,6 +784,11 @@ bool drm_helper_hpd_irq_event(struct
> > drm_device
> > *dev)
> >
> > old_status = connector->status;
> >
> > + if (connector->edid_blob_ptr)
> > + old_edid_blob_ptr =
> > drm_property_blob_get(connector->edid_blob_ptr);
> > + else
> > + old_edid_blob_ptr = NULL;
> > +
> > connector->status = drm_helper_probe_detect(connector,
> > NULL, false);
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s
> > to %s\n",
> > connector->base.id,
> > @@ -782,6 +797,23 @@ bool drm_helper_hpd_irq_event(struct
> > drm_device
> > *dev)
> > drm_get_connector_status_name(connector-
> > > status));
> > if (old_status != connector->status)
> > changed = true;
> > +
> > + /* Check changing of edid when a connector status still
> > remains
> > +* as "connector_status_connected".
> > +*/
> > + if (old_edid_blob_ptr && connector->edid_blob_ptr &&
>
> I guess you don't need to check both old_edid_blob_ptr && connector-
> > edid_blob_ptr here. Because if old_edid_blob_ptr is not NULL - it
> means that connector->edid_blob_ptr was not NULL for sure. See the
> condition you have added above.
> I mean this one:
>
> > + if (connector->edid_blob_ptr)
> > + old_edid_blob_ptr =
> > drm_property_blob_get(connector->edid_blob_ptr);
> > + else
> > + old_edid_blob_ptr = NULL;
>
> So I would check only old_edid_blob_ptr for not being NULL here.
>
>
Hi Stan,
Thank you for checking it.
First, drivers could set edid_blob_ptr to NULL with
drm_connector_update_edid_property().
And drm_helper_probe_detect() could lead updating of an internal edid
of driver and if driver can not get EDID from I2C, it could call
drm_connector_update_edid_property() with NULL.
therefore I think that we should check old and new edid_blob_ptr are
NUL
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Verify workarounds immediately after application
== Series Details == Series: series starting with [1/2] drm/i915: Verify workarounds immediately after application URL : https://patchwork.freedesktop.org/series/59579/ State : success == Summary == CI Bug Log - changes from CI_DRM_5938 -> Patchwork_12816 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59579/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12816 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> SKIP [fdo#109271] +38 * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-icl-y: NOTRUN -> SKIP [fdo#109315] +17 * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17 * igt@gem_exec_basic@basic-bsd2: - fi-icl-y: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_basic@gtt-bsd1: - fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_parse@basic-rejected: - fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1 - fi-icl-y: NOTRUN -> SKIP [fdo#109289] +1 * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ] * igt@kms_chamelium@dp-crc-fast: - fi-icl-y: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_chamelium@hdmi-edid-read: - fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_force_connector_basic@force-load-detect: - fi-icl-y: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_force_connector_basic@prune-stale-modes: - fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_psr@cursor_plane_move: - fi-skl-6260u: NOTRUN -> SKIP [fdo#109271] +37 * igt@kms_psr@primary_mmap_gtt: - fi-icl-y: NOTRUN -> SKIP [fdo#110189] +3 * igt@prime_vgem@basic-fence-flip: - fi-icl-y: NOTRUN -> SKIP [fdo#109294] Possible fixes * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS * igt@i915_selftest@live_execlists: - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: FAIL [fdo#103167] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (47 -> 44) -- Additional (3): fi-icl-y fi-bdw-5557u fi-skl-6260u Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5938 -> Patchwork_12816 CI_DRM_5938: 61a332623362ea87cdde81115229b1b955335654 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4951: cc9a60c029432b5843724e4f2c57f9f815f7adbb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12816: 1fcada518ec8f301a3f8c77bb3d1f22a5368f578 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1fcada518ec8 drm/i915: Verify the engine workarounds stick on application 0fe56c9cea0e drm/i915: Verify workarounds immediately after application == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12816/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Verify the engine workarounds stick on application
On 16/04/2019 14:14, Chris Wilson wrote:
Read the engine workarounds back using the GPU after loading the initial
context state to verify that we are setting them correctly, and bail if
it fails.
v2: Break out the verification into its own loop
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 21 +++
drivers/gpu/drm/i915/intel_workarounds.c | 120 ++
drivers/gpu/drm/i915/intel_workarounds.h | 2 +
.../drm/i915/selftests/intel_workarounds.c| 53 +---
4 files changed, 149 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a818a60ad31..a5412323fee1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4842,6 +4842,23 @@ static void i915_gem_fini_scratch(struct
drm_i915_private *i915)
i915_vma_unpin_and_release(&i915->gt.scratch, 0);
}
+static int intel_engines_verify_workarounds(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int err = 0;
+
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return 0;
+
+ for_each_engine(engine, i915, id) {
+ if (intel_engine_verify_workarounds(engine, "load"))
+ err = -EIO;
+ }
+
+ return err;
+}
+
int i915_gem_init(struct drm_i915_private *dev_priv)
{
int ret;
@@ -4927,6 +4944,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
*/
intel_init_clock_gating(dev_priv);
+ ret = intel_engines_verify_workarounds(dev_priv);
+ if (ret)
+ goto err_init_hw;
+
ret = __intel_engines_record_defaults(dev_priv);
if (ret)
goto err_init_hw;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index ea9292ee755a..89e2c603e34b 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1259,6 +1259,126 @@ void intel_engine_apply_workarounds(struct
intel_engine_cs *engine)
wa_list_apply(engine->uncore, &engine->wa_list);
}
+static struct i915_vma *
+create_scratch(struct i915_address_space *vm, int count)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ unsigned int size;
+ int err;
+
+ size = round_up(count * sizeof(u32), PAGE_SIZE);
+ obj = i915_gem_object_create_internal(vm->i915, size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_obj;
+ }
+
+ err = i915_vma_pin(vma, 0, 0,
+ i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+ if (err)
+ goto err_obj;
+
+ return vma;
+
+err_obj:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+wa_list_srm(struct i915_request *rq,
+ const struct i915_wa_list *wal,
+ struct i915_vma *vma)
+{
+ const struct i915_wa *wa;
+ unsigned int i;
+ u32 srm, *cs;
+
+ srm = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (INTEL_GEN(rq->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * wal->count);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(wa->reg);
+ *cs++ = i915_ggtt_offset(vma) + sizeof(u32) * i;
+ *cs++ = 0;
+ }
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int engine_wa_list_verify(struct intel_engine_cs *engine,
+const struct i915_wa_list * const wal,
+const char *from)
+{
+ const struct i915_wa *wa;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ unsigned int i;
+ u32 *results;
+ int err;
+
+ if (!wal->count)
+ return 0;
+
+ vma = create_scratch(&engine->i915->ggtt.vm, wal->count);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ rq = i915_request_alloc(engine, engine->kernel_context->gem_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_vma;
+ }
+
+ err = wa_list_srm(rq, wal, vma);
+ if (err)
+ goto err_vma;
+
+ i915_request_add(rq);
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0) {
+ err = -ETIME;
+ goto err_vma;
+ }
+
+ results = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);
+ if (IS_ERR(results)) {
+ err = PTR_ERR(results);
+ goto err_vma;
+
Re: [Intel-gfx] [PATCH v7] drm/i915/icl: Fix clockgating issue when using scalers
On Mon, Apr 15, 2019 at 03:55:19PM -0700, Radhakrishna Sripada wrote:
> Fixes the clock-gating issue when pipe scaling is enabled.
> (Lineage #2006604312)
>
> V2: Fix typo in headline(Chris)
> Handle the non double buffered nature of the register(Ville)
> V3: Fix checkpatch warning. BAT failure for V2 on gen3 looks unrelated.
> V4: Split the icl and skl wa's(Ville)
> V5: Split the checks for icl and skl(Ville)
> V6: Correct the flipped checks in intel_pre_plane_update(Ville)
> V7: Use enum for pipe and extend the WA for plane scalers(Ville)
>
> Cc: Chris Wilson
> Cc: Ville Syrjala
> Cc: Rodrigo Vivi
> Cc: Clint Taylor
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_display.c | 42
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3bd40a4a6739..6f68d039ab47 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -476,6 +476,7 @@ static const struct intel_limit intel_limits_bxt = {
> .p2 = { .p2_slow = 1, .p2_fast = 20 },
> };
>
> +/* WA Display #0827: Gen9:all */
> static void
> skl_wa_827(struct drm_i915_private *dev_priv, int pipe, bool enable)
> {
> @@ -489,6 +490,19 @@ skl_wa_827(struct drm_i915_private *dev_priv, int pipe,
> bool enable)
> ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> }
>
> +/* Wa_2006604312:icl */
> +static void
> +icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, enum pipe pipe,
> +bool enable)
> +{
> + if (enable)
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> +I915_READ(CLKGATE_DIS_PSL(pipe)) | DPFR_GATING_DIS);
> + else
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> +I915_READ(CLKGATE_DIS_PSL(pipe)) & ~DPFR_GATING_DIS);
> +}
> +
> static bool
> needs_modeset(const struct drm_crtc_state *state)
> {
> @@ -5505,6 +5519,18 @@ static bool needs_nv12_wa(struct drm_i915_private
> *dev_priv,
> return false;
> }
>
> +static bool needs_scalerclk_wa(struct drm_i915_private *dev_priv,
> +const struct intel_crtc_state *crtc_state)
> +{
> + /* Wa_2006604312:icl */
> + if (IS_ICELAKE(dev_priv) &&
> + (crtc_state->pch_pfit.enabled ||
I don't think we need the pfit check anymore. scaler_users should
account for that?
> + crtc_state->scaler_state.scaler_users > 0))
> + return true;
> +
> + return false;
> +}
> +
> static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> @@ -5538,11 +5564,13 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
> intel_post_enable_primary(&crtc->base, pipe_config);
> }
>
> - /* Display WA 827 */
> if (needs_nv12_wa(dev_priv, old_crtc_state) &&
> - !needs_nv12_wa(dev_priv, pipe_config)) {
> + !needs_nv12_wa(dev_priv, pipe_config))
> skl_wa_827(dev_priv, crtc->pipe, false);
> - }
> +
> + if (needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> + !needs_scalerclk_wa(dev_priv, pipe_config))
> + icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
> }
>
> static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
> @@ -5579,9 +5607,13 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>
> /* Display WA 827 */
> if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
> - needs_nv12_wa(dev_priv, pipe_config)) {
> + needs_nv12_wa(dev_priv, pipe_config))
> skl_wa_827(dev_priv, crtc->pipe, true);
> - }
> +
> + /* Wa_2006604312:icl */
> + if (!needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> + needs_scalerclk_wa(dev_priv, pipe_config))
> + icl_wa_scalerclkgating(dev_priv, crtc->pipe, true);
>
> /*
>* Vblank time updates from the shadow to live plane control register
> --
> 2.20.0.rc2.7.g965798d1f299
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
Hi, Based on quick tests with the patch: * Results in GfxBench and Unigine (Valley/Heaven) tests were within daily variation on the tested SKL machines * SKL GT4e (128MB eLLC) / Wayland / Weston: +15-20% SynMark TexMem512 (512MB of textures) +4-6% SynMark TerrainFly*, CSCloth, ShMapVsm -5-10% SynMark TexMem128 (128MB of textures) * SKL GT3e (64MB eLLC) / Xorg / Unity: +4-8% GpuTest Triangle fullscreen (FullHD) -5-10% GpuTest Triangle windowed (1/2 screen) * SKL GT2 (no eLLC) / Xorg / Unity: * Some of the higher FPS SynMark pixel and vertex shader tests are few percent higher, more than daily variance => Do you see any reason why this machine would be impacted although it doesn't eLLC? (I built it against drm-tip and compared results against previous and next day unpatched drm-tip results that I had otherwise.) - Eero On 15.4.2019 17.16, Ville Syrjala wrote: From: Ville Syrjälä Since SKL the eLLC has been sitting on the far side of the system agent, meaning the display engine can utilize it. Let's enable that. I chose WB for the caching mode, because my numbers are indicating that WT might actually be WB and WC might actually be UC. I'm not 100% sure that is indeed the case but at least my simple rendercopy based benchmark didn't see any difference in performance. Also if I configure things to do LLCeLLC+WT I still get cache dirt on my screen, suggesting that is in fact operating in WB mode anyway. This is also the reason I had to fix the MOCS target cache to really say PTE rather than LLC+eLLC. Caveat: I've not benchmarked any real workloads. IIRC Eero did benchmark an earlier version, but that didn't have the PTE vs. LLC+eLLC MOCS fix so it wasn't actually doing the right thing most likely. Cc: Eero Tamminen Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 3 +-- drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +-- drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +- drivers/gpu/drm/i915/intel_mocs.c | 2 +- 4 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 35d0782c077e..2a4f33fa2bba 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2517,8 +2517,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) #define HAS_SNOOP(dev_priv) (INTEL_INFO(dev_priv)->has_snoop) #define HAS_EDRAM(dev_priv) ((dev_priv)->edram_size_mb) -#define HAS_WT(dev_priv) ((IS_HASWELL(dev_priv) || \ -IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv)) +#define HAS_WT(dev_priv) HAS_EDRAM(dev_priv) #define HWS_NEEDS_PHYSICAL(dev_priv) (INTEL_INFO(dev_priv)->hws_needs_physical) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 8f460cc4cc1f..038fbf52a997 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -3071,7 +3071,7 @@ static void cnl_setup_private_ppat(struct intel_ppat *ppat) __alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC); __alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC); - __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); + __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE); __alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC); __alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0)); __alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1)); @@ -3109,7 +3109,10 @@ static void bdw_setup_private_ppat(struct intel_ppat *ppat) __alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC); /* for normal objects, no eLLC */ __alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC); /* for something pointing to ptes? */ - __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for scanout with eLLC */ + if (INTEL_GEN(ppat->i915) >= 9) + __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE); /* for scanout with eLLC */ + else + __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for scanout with eLLC */ __alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC); /* Uncached objects, mostly for scanout */ __alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0)); __alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1)); diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index f597f35b109b..47adc7268867 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -139,7 +139,7 @@ typedef u64 gen8_ppgtt_pml4e_t; #define PPAT_UNCACHED (_PAGE_PWT | _PAGE_PCD) #define PPAT_CACHED_PDE 0 /* WB LLC */ #define PPAT_CA
[Intel-gfx] [PATCH] drm/i915: Seal races between async GPU cancellation, retirement and signaling
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an interrupt for that request while it
is no longer in flight.
CPU0CPU1
intel_engine_breadcrumbs_irq
(queue request completion)
i915_request_cancel_signaling
... ...
i915_request_enable_signaling
dma_fence_signal
Hence in the time it took us to drop the lock to signal the request, a
preemption event may have occurred and re-queued the request. In the
process, that request would have seen I915_FENCE_FLAG_SIGNAL clear and
so reused the rq->signal_link that was in use on CPU0, leading to bad
pointer chasing in intel_engine_breadcrumbs_irq.
A related issue was that if someone started listening for a signal on a
completed but no longer in-flight request, we missed the opportunity to
immediately signal that request.
Furthermore, as intel_contexts may be immediately released during
request retirement, in order to be entirely sure that
intel_engine_breadcrumbs_irq may no longer dereference the intel_context
(ce->signals and ce->signal_link), we must wait for irq spinlock.
In order to prevent the race, we use a bit in the fence.flags to signal
the transfer onto the signal list inside intel_engine_breadcrumbs_irq.
For simplicity, we use the DMA_FENCE_FLAG_SIGNALED_BIT as it then
quickly signals to any outside observer that the fence is indeed signaled.
Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context
interrupt tracking")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 1 +
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 52 ++--
3 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 3aa8733f832a..9bf06042619a 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -29,6 +29,7 @@
EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
static DEFINE_SPINLOCK(dma_fence_stub_lock);
static struct dma_fence dma_fence_stub;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index b836721d3b13..e0efc334463b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -432,6 +432,7 @@ void __i915_request_submit(struct i915_request *request)
set_bit(I915_FENCE_FLAG_ACTIVE, &request->fence.flags);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags) &&
+ !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &request->fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_queue_breadcrumbs(engine);
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3cbffd400b1b..e19f84b006cc 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include "i915_drv.h"
@@ -83,6 +84,7 @@ static inline bool __request_completed(const struct
i915_request *rq)
void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ const ktime_t timestamp = ktime_get();
struct intel_context *ce, *cn;
struct list_head *pos, *next;
LIST_HEAD(signal);
@@ -104,6 +106,11 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_SIGNAL,
&rq->fence.flags));
+ clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
+
+ if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+&rq->fence.flags))
+ continue;
/*
* Queue for execution after dropping the signaling
@@ -111,14 +118,6 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
* more signalers to the same context or engine.
*/
i915_request_get(rq);
-
- /*
-* We may race with direct invocation of
-* dma_fence_signal(), e.g. i915_request_retire(),
-* so we need to acquire our reference to the request
-* before we cancel the breadcrumb.
-*/
- clear_bit(I915_FENCE_FLAG_SIGNAL
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Drop bool return from breadcrumbs signaler
== Series Details == Series: drm/i915: Drop bool return from breadcrumbs signaler URL : https://patchwork.freedesktop.org/series/59565/ State : success == Summary == CI Bug Log - changes from CI_DRM_5936_full -> Patchwork_12813_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12813_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_off: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@gem_tiled_swapping@non-threaded: - shard-iclb: PASS -> DMESG-WARN [fdo#108686] * igt@kms_atomic_transition@3x-modeset-transitions: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +14 * igt@kms_busy@basic-modeset-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-f: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_content_protection@legacy: - shard-kbl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc: - shard-skl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +21 * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> SKIP [fdo#109271] +147 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-wc: - shard-iclb: PASS -> FAIL [fdo#109247] +8 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] +5 * igt@kms_lease@atomic_implicit_crtc: - shard-skl: NOTRUN -> FAIL [fdo#110279] * igt@kms_lease@cursor_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110278] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-apl: NOTRUN -> DMESG-WARN [fdo#108566] * igt@kms_plane@pixel-format-pipe-c-planes: - shard-glk: PASS -> SKIP [fdo#109271] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +2 * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-apl: NOTRUN -> FAIL [fdo#108145] +1 - shard-skl: NOTRUN -> FAIL [fdo#108145] +3 * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: PASS -> SKIP [fdo#109441] +2 * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> FAIL [fdo#109016] * igt@kms_setmode@basic: - shard-apl: NOTRUN -> FAIL [fdo#99912] - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_sysfs_edid_timing: - shard-apl: NOTRUN -> FAIL [fdo#100047] * igt@prime_busy@hang-blt: - shard-apl: PASS -> FAIL [fdo#108807] * igt@prime_nv_api@i915_nv_reimport_twice_check_flink_name: - shard-apl: NOTRUN -> SKIP [fdo#109271] +72 Possible fixes * igt@gem_ctx_isolation@vcs1-s3: - shard-kbl: DMESG-WARN [fdo#108566] -> PASS +1 * igt@i915_pm_rpm@dpms-non-lpsp: - shard-apl: DMESG-WARN [fdo#110376] -> PASS * igt@i915_suspend@debugfs-reader: - shard-apl: DMESG-WARN [fdo#108566] -> PASS +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS - shard-glk: FAIL [fdo#102887] -> PASS * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: FAIL [fdo#102887] / [fdo#105363] -> PASS - shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite: - shard-iclb: FAIL [fdo#109247] -> PASS +16 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt: - shard-iclb: FAIL [fdo#103167] -> PASS +4 * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: FAIL [fdo#108145] -> PASS * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-glk: SKIP [fdo#109271] / [fdo#109278] -> PASS * igt@kms_psr@psr2_
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Verify the engine workarounds stick on application
Quoting Tvrtko Ursulin (2019-04-16 15:10:25) > > On 16/04/2019 14:14, Chris Wilson wrote: > > Read the engine workarounds back using the GPU after loading the initial > > context state to verify that we are setting them correctly, and bail if > > it fails. > > > > v2: Break out the verification into its own loop > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > Reviewed-by: Tvrtko Ursulin Now we just have to decide what to do about the +47 icl failures :) (Or however many it is this time.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_spin_batch: Add test to resend spinner
Add subtests to resend the same spinner to same context
and to other context.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
tests/i915/gem_spin_batch.c | 47 ++---
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/tests/i915/gem_spin_batch.c b/tests/i915/gem_spin_batch.c
index 52410010..e18b85c9 100644
--- a/tests/i915/gem_spin_batch.c
+++ b/tests/i915/gem_spin_batch.c
@@ -66,6 +66,36 @@ static void spin(int fd, unsigned int engine, unsigned int
timeout_sec)
assert_within_epsilon(timeout_100ms * loops, elapsed, MAX_ERROR);
}
+#define RESUBMIT_OTHER_CTX (1 << 0)
+
+static void spin_resubmit(int fd, unsigned int engine, unsigned int flags)
+{
+ const uint32_t ctx0 = gem_context_create(fd);
+ const uint32_t ctx1 = (flags & RESUBMIT_OTHER_CTX) ?
+ gem_context_create(fd) : ctx0;
+ igt_spin_t *spin = __igt_spin_batch_new(fd, .ctx = ctx0, .engine =
engine);
+
+ struct drm_i915_gem_execbuffer2 eb = {
+ .buffer_count = 1,
+ .buffers_ptr = to_user_pointer(&spin->obj[1]),
+ .rsvd1 = ctx1,
+ .flags = engine,
+ };
+
+ gem_execbuf(fd, &eb);
+
+ igt_spin_batch_end(spin);
+
+ gem_sync(fd, spin->obj[1].handle);
+
+ igt_spin_batch_free(fd, spin);
+
+ if (ctx1 != ctx0)
+ gem_context_destroy(fd, ctx1);
+
+ gem_context_destroy(fd, ctx0);
+}
+
static void spin_exit_handler(int sig)
{
igt_terminate_spin_batches();
@@ -96,22 +126,21 @@ igt_main
fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
igt_fork_hang_detector(fd);
- intel_detect_and_clear_missed_interrupts(fd);
}
for (e = intel_execution_engines; e->name; e++) {
- igt_subtest_f("basic-%s", e->name) {
- intel_detect_and_clear_missed_interrupts(fd);
+ igt_subtest_f("basic-%s", e->name)
spin(fd, e->exec_id, 3);
-
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
- }
+
+ igt_subtest_f("resubmit-%s", e->name)
+ spin_resubmit(fd, e->exec_id, 0);
+
+ igt_subtest_f("resubmit-other-%s", e->name)
+ spin_resubmit(fd, e->exec_id, RESUBMIT_OTHER_CTX);
}
- igt_subtest("spin-each") {
- intel_detect_and_clear_missed_interrupts(fd);
+ igt_subtest("spin-each")
spin_on_all_engines(fd, 3);
- igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
- }
igt_fixture {
igt_stop_hang_detector();
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_spin_batch: Add test to resend spinner
Quoting Mika Kuoppala (2019-04-16 15:23:15) > Add subtests to resend the same spinner to same context > and to other context. > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson For completeness in creating concise examples of use elsewhere, feed the gem_execbuf to the other engines. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
On Tue, Apr 16, 2019 at 05:28:57PM +0300, Eero Tamminen wrote: > Hi, > > Based on quick tests with the patch: > > * Results in GfxBench and Unigine (Valley/Heaven) tests were within > daily variation on the tested SKL machines > > * SKL GT4e (128MB eLLC) / Wayland / Weston: >+15-20% SynMark TexMem512 (512MB of textures) > +4-6% SynMark TerrainFly*, CSCloth, ShMapVsm >-5-10% SynMark TexMem128 (128MB of textures) These seem mostly good. The 128MB case regression seems understandable since we don't quite fit into the eLLC anymore. > > * SKL GT3e (64MB eLLC) / Xorg / Unity: >+4-8% GpuTest Triangle fullscreen (FullHD) > -5-10% GpuTest Triangle windowed (1/2 screen) Not quite sure why the windowed case would suffer here :/ > > * SKL GT2 (no eLLC) / Xorg / Unity: >* Some of the higher FPS SynMark pixel and vertex shader tests > are few percent higher, more than daily variance >=> Do you see any reason why this machine would be impacted > although it doesn't eLLC? Can't think of a reason for that. All display buffers should still be UC on such a machine. > > (I built it against drm-tip and compared results against previous and > next day unpatched drm-tip results that I had otherwise.) > > > - Eero > > On 15.4.2019 17.16, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Since SKL the eLLC has been sitting on the far side of the system > > agent, meaning the display engine can utilize it. Let's enable that. > > > > I chose WB for the caching mode, because my numbers are indicating > > that WT might actually be WB and WC might actually be UC. I'm not > > 100% sure that is indeed the case but at least my simple rendercopy > > based benchmark didn't see any difference in performance. > > > > Also if I configure things to do LLCeLLC+WT I still get cache dirt > > on my screen, suggesting that is in fact operating in WB mode > > anyway. This is also the reason I had to fix the MOCS target cache > > to really say PTE rather than LLC+eLLC. > > > > Caveat: I've not benchmarked any real workloads. IIRC Eero did > > benchmark an earlier version, but that didn't have the PTE vs. > > LLC+eLLC MOCS fix so it wasn't actually doing the right thing > > most likely. > > > > Cc: Eero Tamminen > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/i915_drv.h | 3 +-- > > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +-- > > drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +- > > drivers/gpu/drm/i915/intel_mocs.c | 2 +- > > 4 files changed, 8 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index 35d0782c077e..2a4f33fa2bba 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -2517,8 +2517,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > > #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) > > #define HAS_SNOOP(dev_priv) (INTEL_INFO(dev_priv)->has_snoop) > > #define HAS_EDRAM(dev_priv) ((dev_priv)->edram_size_mb) > > -#define HAS_WT(dev_priv) ((IS_HASWELL(dev_priv) || \ > > -IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv)) > > +#define HAS_WT(dev_priv) HAS_EDRAM(dev_priv) > > > > #define HWS_NEEDS_PHYSICAL(dev_priv) > > (INTEL_INFO(dev_priv)->hws_needs_physical) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > > b/drivers/gpu/drm/i915/i915_gem_gtt.c > > index 8f460cc4cc1f..038fbf52a997 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > > @@ -3071,7 +3071,7 @@ static void cnl_setup_private_ppat(struct intel_ppat > > *ppat) > > > > __alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC); > > __alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC); > > - __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); > > + __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE); > > __alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC); > > __alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | > > GEN8_PPAT_AGE(0)); > > __alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | > > GEN8_PPAT_AGE(1)); > > @@ -3109,7 +3109,10 @@ static void bdw_setup_private_ppat(struct intel_ppat > > *ppat) > > > > __alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC); /* for > > normal objects, no eLLC */ > > __alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC); /* for > > something pointing to ptes? */ > > - __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for > > scanout with eLLC */ > > + if (INTEL_GEN(ppat->i915) >= 9) > > + __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | > > GEN8_PPAT_ELLC_OVERRIDE); /* for scanout with eLLC */ > > + else > > + __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); > > /* for scanout with eLLC */ > > __alloc_ppat_entry(ppat, 3, GEN8_PPAT_U
Re: [Intel-gfx] [PATCH 4/4] Revert "drm/i915/guc: Disable global reset"
On 4/9/19 2:54 PM, Chris Wilson wrote: > Quoting Fernando Pacheco (2019-04-09 22:31:02) >> This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8. > And don't forget the test code that skips guc. > -Chris Selftests? I couldn't find anything that skips guc. I found some skips for guc submission. Fernando ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Verify whitelist of context registers
On 16/04/2019 10:12, Chris Wilson wrote:
The RING_NONPRIV allows us to add registers to a whitelist that allows
userspace to modify them. Ideally such registers should be safe and
saved within the context such that they do not impact system behaviour
for other users. This selftest verifies that those registers we do add
are (a) then writable by userspace and (b) only affect a single client.
Opens:
- Is GEN9_SLICE_COMMON_ECO_CHICKEN1 really write-only?
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Compile fix for writeonly_reg()
---
.../drm/i915/selftests/intel_workarounds.c| 320 ++
1 file changed, 320 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index a363748a7a4f..f40e0937ec96 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -700,6 +700,325 @@ static int live_reset_whitelist(void *arg)
return err;
}
+static int read_whitelisted_registers(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct i915_vma *results)
+{
+ intel_wakeref_t wakeref;
+ struct i915_request *rq;
+ u32 srm, *cs;
+ int err, i;
+
+ rq = ERR_PTR(-ENODEV);
+ with_intel_runtime_pm(engine->i915, wakeref)
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ err = i915_vma_move_to_active(results, rq, EXEC_OBJECT_WRITE);
+ if (err)
+ goto err_req;
Why do you track the vma? There's a wait below and in scrub you even
flush manually.
+
+ srm = MI_STORE_REGISTER_MEM;
+ if (INTEL_GEN(ctx->i915) >= 8)
+ srm++;
+
+ cs = intel_ring_begin(rq, 4 * engine->whitelist.count);
+ if (IS_ERR(cs)) {
+ err = PTR_ERR(cs);
+ goto err_req;
+ }
+
+ for (i = 0; i < engine->whitelist.count; i++) {
+ u64 offset = results->node.start + sizeof(u32) * i;
+
+ *cs++ = srm;
+ *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ *cs++ = lower_32_bits(offset);
+ *cs++ = upper_32_bits(offset);
+ }
+ intel_ring_advance(rq, cs);
+
+err_req:
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0)
+ err = -EIO;
+
+ return err;
+}
+
+static int scrub_whitelisted_registers(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ intel_wakeref_t wakeref;
+ struct i915_request *rq;
+ struct i915_vma *batch;
+ int i, err;
+ u32 *cs;
+
+ batch = create_batch(ctx);
+ if (IS_ERR(batch))
+ return PTR_ERR(batch);
+
+ cs = i915_gem_object_pin_map(batch->obj, I915_MAP_WC);
+ if (IS_ERR(cs)) {
+ err = PTR_ERR(cs);
+ goto err_batch;
+ }
+
+ *cs++ = MI_LOAD_REGISTER_IMM(engine->whitelist.count);
+ for (i = 0; i < engine->whitelist.count; i++) {
+ *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ *cs++ = 0x;
+ }
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_flush_map(batch->obj);
+ i915_gem_chipset_flush(ctx->i915);
+
+ rq = ERR_PTR(-ENODEV);
+ with_intel_runtime_pm(engine->i915, wakeref)
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq))
+ goto err_unpin;
+
+ if (engine->emit_init_breadcrumb) { /* Be nice if we hang */
+ err = engine->emit_init_breadcrumb(rq);
+ if (err)
+ goto err_request;
+ }
+
+ err = engine->emit_bb_start(rq, batch->node.start, 0, 0);
Why is batch needed here when everything else is happy to run from the ring?
+
+err_request:
+ i915_request_add(rq);
+ if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0)
+ err = -EIO;
+
+err_unpin:
+ i915_gem_object_unpin_map(batch->obj);
+err_batch:
+ i915_vma_unpin_and_release(&batch, 0);
+ return err;
+}
+
+static bool pardon_reg(struct drm_i915_private *i915, i915_reg_t reg)
+{
+ /* Alas, we must pardon some whitelists */
+ static const struct {
+ i915_reg_t reg;
+ unsigned long gen_mask;
+ } pardon[] = {
+ { GEN9_CTX_PREEMPT_REG, INTEL_GEN_MASK(9, 9) },
+ { GEN8_L3SQCREG4, INTEL_GEN_MASK(9, 9) },
+ };
+ u32 offset = i915_mmio_reg_offset(reg);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pardon); i++) {
+ if (INTEL_INFO(i915)->gen_mask & pardon[i].gen_mask &&
+ i915_mmio_reg_offset(pardon[i].reg) == offset)
+ return true;
+ }
+
+
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Verify whitelist of context registers
Hi Chris,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-selftests-Verify-whitelist-of-context-registers/20190416-105231
base: git://anongit.freedesktop.org/drm-intel for-linux-next
New smatch warnings:
drivers/gpu/drm/i915/selftests/intel_workarounds.c:846
scrub_whitelisted_registers() error: uninitialized symbol 'err'.
#
https://github.com/0day-ci/linux/commit/a9ce77a003ecaa54f530f1e9ff81cbae11380380
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout a9ce77a003ecaa54f530f1e9ff81cbae11380380
vim +/PTR_ERR +759 drivers/gpu/drm/i915/selftests/intel_workarounds.c
a9ce77a0 Chris Wilson 2019-04-15 794 static int
scrub_whitelisted_registers(struct i915_gem_context *ctx,
a9ce77a0 Chris Wilson 2019-04-15 795 struct
intel_engine_cs *engine)
a9ce77a0 Chris Wilson 2019-04-15 796 {
a9ce77a0 Chris Wilson 2019-04-15 797 intel_wakeref_t wakeref;
a9ce77a0 Chris Wilson 2019-04-15 798 struct i915_request *rq;
a9ce77a0 Chris Wilson 2019-04-15 799 struct i915_vma *batch;
a9ce77a0 Chris Wilson 2019-04-15 800 int i, err;
a9ce77a0 Chris Wilson 2019-04-15 801 u32 *cs;
a9ce77a0 Chris Wilson 2019-04-15 802
a9ce77a0 Chris Wilson 2019-04-15 803 batch = create_batch(ctx);
a9ce77a0 Chris Wilson 2019-04-15 804 if (IS_ERR(batch))
a9ce77a0 Chris Wilson 2019-04-15 805 return PTR_ERR(batch);
a9ce77a0 Chris Wilson 2019-04-15 806
a9ce77a0 Chris Wilson 2019-04-15 807 cs =
i915_gem_object_pin_map(batch->obj, I915_MAP_WC);
a9ce77a0 Chris Wilson 2019-04-15 808 if (IS_ERR(cs)) {
a9ce77a0 Chris Wilson 2019-04-15 809 err = PTR_ERR(cs);
a9ce77a0 Chris Wilson 2019-04-15 810 goto err_batch;
a9ce77a0 Chris Wilson 2019-04-15 811 }
a9ce77a0 Chris Wilson 2019-04-15 812
a9ce77a0 Chris Wilson 2019-04-15 813 *cs++ =
MI_LOAD_REGISTER_IMM(engine->whitelist.count);
a9ce77a0 Chris Wilson 2019-04-15 814 for (i = 0; i <
engine->whitelist.count; i++) {
a9ce77a0 Chris Wilson 2019-04-15 815 *cs++ =
i915_mmio_reg_offset(engine->whitelist.list[i].reg);
a9ce77a0 Chris Wilson 2019-04-15 816 *cs++ = STACK_MAGIC;
a9ce77a0 Chris Wilson 2019-04-15 817 }
a9ce77a0 Chris Wilson 2019-04-15 818 *cs++ = MI_BATCH_BUFFER_END;
a9ce77a0 Chris Wilson 2019-04-15 819
a9ce77a0 Chris Wilson 2019-04-15 820 i915_gem_object_flush_map(batch->obj);
a9ce77a0 Chris Wilson 2019-04-15 821 i915_gem_chipset_flush(ctx->i915);
a9ce77a0 Chris Wilson 2019-04-15 822
a9ce77a0 Chris Wilson 2019-04-15 823 rq = ERR_PTR(-ENODEV);
a9ce77a0 Chris Wilson 2019-04-15 824 with_intel_runtime_pm(engine->i915,
wakeref)
a9ce77a0 Chris Wilson 2019-04-15 825 rq = i915_request_alloc(engine,
ctx);
a9ce77a0 Chris Wilson 2019-04-15 826 if (IS_ERR(rq))
a9ce77a0 Chris Wilson 2019-04-15 827 goto err_unpin;
^^
"err" not set.
a9ce77a0 Chris Wilson 2019-04-15 828
a9ce77a0 Chris Wilson 2019-04-15 829 if (engine->emit_init_breadcrumb) { /*
Be nice if we hang */
a9ce77a0 Chris Wilson 2019-04-15 830 err =
engine->emit_init_breadcrumb(rq);
a9ce77a0 Chris Wilson 2019-04-15 831 if (err)
a9ce77a0 Chris Wilson 2019-04-15 832 goto err_request;
a9ce77a0 Chris Wilson 2019-04-15 833 }
a9ce77a0 Chris Wilson 2019-04-15 834
a9ce77a0 Chris Wilson 2019-04-15 835 err = engine->emit_bb_start(rq,
batch->node.start, 0, 0);
a9ce77a0 Chris Wilson 2019-04-15 836
a9ce77a0 Chris Wilson 2019-04-15 837 err_request:
a9ce77a0 Chris Wilson 2019-04-15 838 i915_request_add(rq);
a9ce77a0 Chris Wilson 2019-04-15 839 if (i915_request_wait(rq,
I915_WAIT_LOCKED, HZ / 5) < 0)
a9ce77a0 Chris Wilson 2019-04-15 840 err = -EIO;
a9ce77a0 Chris Wilson 2019-04-15 841
a9ce77a0 Chris Wilson 2019-04-15 842 err_unpin:
a9ce77a0 Chris Wilson 2019-04-15 843 i915_gem_object_unpin_map(batch->obj);
a9ce77a0 Chris Wilson 2019-04-15 844 err_batch:
a9ce77a0 Chris Wilson 2019-04-15 845 i915_vma_unpin_and_release(&batch, 0);
a9ce77a0 Chris Wilson 2019-04-15 @846 return err;
a9ce77a0 Chris Wilson 2019-04-15 847 }
a9ce77a0 Chris Wilson 2019-04-15 848
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Verify the engine workarounds stick on application
On 16/04/2019 15:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-04-16 15:10:25) On 16/04/2019 14:14, Chris Wilson wrote: Read the engine workarounds back using the GPU after loading the initial context state to verify that we are setting them correctly, and bail if it fails. v2: Break out the verification into its own loop Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Now we just have to decide what to do about the +47 icl failures :) (Or however many it is this time.) I am hardly keeping pace with your patches, let alone looking at the CI results. :I I see BAT success - where to see the failures and what is failing? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
On 4/9/19 3:22 PM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-09 22:31:01)
>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
>> b/drivers/gpu/drm/i915/intel_huc.c
>> index 94c04f16a2ad..89e0b942ae86 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>> @@ -40,6 +40,59 @@ int intel_huc_init_misc(struct intel_huc *huc)
>> return 0;
>> }
>>
>> +/*
>> + * The HuC firmware image now sits above GUC_GGTT_TOP and this
>> + * portion does not map through GTT. This means GuC cannot
>> + * perform the HuC auth with the rsa signature sitting in that
>> + * range. We resort to additionally perma-pinning the rsa signature
>> + * below GUC_GGTT_TOP and utilizing this mapping to perform
>> + * the authentication.
>> + */
>> +static int intel_huc_rsa_data_create(struct intel_huc *huc)
>> +{
>> + struct drm_i915_private *i915 = huc_to_i915(huc);
>> + struct intel_guc *guc = &i915->guc;
>> + struct i915_vma *vma;
>> + void *vaddr;
>> +
>> + vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
>> + if (IS_ERR(vma))
>> + return PTR_ERR(vma);
>> +
> Are we not allocating an object for the dma xfer here that is then bound
> to the reserved ggtt node? Why pin it again into the ggtt?
> -Chris
It is not bound to the reserved node. The reserved range is inaccessible by
GuC, so I
had to pull the signature back in for the auth stage.
Fernando
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/12] drm/fb-helper: Remove drm_fb_helper_connector
Den 16.04.2019 11.42, skrev Maxime Ripard: > Hi, > > On Sun, Apr 07, 2019 at 06:52:40PM +0200, Noralf Trønnes wrote: >> All drivers add all their connectors so there's no need to keep around an >> array of available connectors. >> >> Rename functions which signature is changed since they will be moved to >> drm_client in a later patch. >> >> Signed-off-by: Noralf Trønnes > > The patch itself looks fine in itself, but I was planning on using > connector_info to store the connector properties set on the kernel > command line as part of video= > > Where should we put them now? > I don't follow you here. Where do you see the conflict? Noralf. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Verify the engine workarounds stick on application
Quoting Tvrtko Ursulin (2019-04-16 15:53:40) > > On 16/04/2019 15:17, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-04-16 15:10:25) > >> > >> On 16/04/2019 14:14, Chris Wilson wrote: > >>> Read the engine workarounds back using the GPU after loading the initial > >>> context state to verify that we are setting them correctly, and bail if > >>> it fails. > >>> > >>> v2: Break out the verification into its own loop > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Tvrtko Ursulin > >> Reviewed-by: Tvrtko Ursulin > > > > Now we just have to decide what to do about the +47 icl failures :) > > (Or however many it is this time.) > > I am hardly keeping pace with your patches, let alone looking at the CI > results. :I > > I see BAT success - where to see the failures and what is failing? Wait for the shards. BAT just happens to have machines that work! In the shards we have about a 30% chance (at the last count) of any test that reloads the module to trigger a warning. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_spin_batch: Add test to resend spinner
Add subtests to resend the same spinner to same context
and to other context.
v2: other engines (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
tests/i915/gem_spin_batch.c | 67 -
1 file changed, 58 insertions(+), 9 deletions(-)
diff --git a/tests/i915/gem_spin_batch.c b/tests/i915/gem_spin_batch.c
index 52410010..9afdbe09 100644
--- a/tests/i915/gem_spin_batch.c
+++ b/tests/i915/gem_spin_batch.c
@@ -66,6 +66,48 @@ static void spin(int fd, unsigned int engine, unsigned int
timeout_sec)
assert_within_epsilon(timeout_100ms * loops, elapsed, MAX_ERROR);
}
+#define RESUBMIT_NEW_CTX (1 << 0)
+#define RESUBMIT_ALL_ENGINES (1 << 1)
+
+static void spin_resubmit(int fd, unsigned int engine, unsigned int flags)
+{
+ const uint32_t ctx0 = gem_context_create(fd);
+ const uint32_t ctx1 = (flags & RESUBMIT_NEW_CTX) ?
+ gem_context_create(fd) : ctx0;
+ igt_spin_t *spin = __igt_spin_batch_new(fd, .ctx = ctx0, .engine =
engine);
+ unsigned int other;
+
+ struct drm_i915_gem_execbuffer2 eb = {
+ .buffer_count = 1,
+ .buffers_ptr = to_user_pointer(&spin->obj[1]),
+ .rsvd1 = ctx1,
+ };
+
+ if (flags & RESUBMIT_ALL_ENGINES) {
+ for_each_physical_engine(fd, other) {
+ if (other == engine)
+ continue;
+
+ eb.flags = other;
+ gem_execbuf(fd, &eb);
+ }
+ } else {
+ eb.flags = engine;
+ gem_execbuf(fd, &eb);
+ }
+
+ igt_spin_batch_end(spin);
+
+ gem_sync(fd, spin->obj[1].handle);
+
+ igt_spin_batch_free(fd, spin);
+
+ if (ctx1 != ctx0)
+ gem_context_destroy(fd, ctx1);
+
+ gem_context_destroy(fd, ctx0);
+}
+
static void spin_exit_handler(int sig)
{
igt_terminate_spin_batches();
@@ -96,22 +138,29 @@ igt_main
fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
igt_fork_hang_detector(fd);
- intel_detect_and_clear_missed_interrupts(fd);
}
for (e = intel_execution_engines; e->name; e++) {
- igt_subtest_f("basic-%s", e->name) {
- intel_detect_and_clear_missed_interrupts(fd);
+ igt_subtest_f("basic-%s", e->name)
spin(fd, e->exec_id, 3);
-
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
- }
+
+ igt_subtest_f("resubmit-%s", e->name)
+ spin_resubmit(fd, e->exec_id, 0);
+
+ igt_subtest_f("resubmit-new-%s", e->name)
+ spin_resubmit(fd, e->exec_id, RESUBMIT_NEW_CTX);
+
+ igt_subtest_f("resubmit-all-%s", e->name)
+ spin_resubmit(fd, e->exec_id, RESUBMIT_ALL_ENGINES);
+
+ igt_subtest_f("resubmit-new-all-%s", e->name)
+ spin_resubmit(fd, e->exec_id,
+ RESUBMIT_NEW_CTX |
+ RESUBMIT_ALL_ENGINES);
}
- igt_subtest("spin-each") {
- intel_detect_and_clear_missed_interrupts(fd);
+ igt_subtest("spin-each")
spin_on_all_engines(fd, 3);
- igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
- }
igt_fixture {
igt_stop_hang_detector();
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
Quoting Fernando Pacheco (2019-04-16 15:51:15)
>
> On 4/9/19 3:22 PM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-09 22:31:01)
> >> diff --git a/drivers/gpu/drm/i915/intel_huc.c
> >> b/drivers/gpu/drm/i915/intel_huc.c
> >> index 94c04f16a2ad..89e0b942ae86 100644
> >> --- a/drivers/gpu/drm/i915/intel_huc.c
> >> +++ b/drivers/gpu/drm/i915/intel_huc.c
> >> @@ -40,6 +40,59 @@ int intel_huc_init_misc(struct intel_huc *huc)
> >> return 0;
> >> }
> >>
> >> +/*
> >> + * The HuC firmware image now sits above GUC_GGTT_TOP and this
> >> + * portion does not map through GTT. This means GuC cannot
> >> + * perform the HuC auth with the rsa signature sitting in that
> >> + * range. We resort to additionally perma-pinning the rsa signature
> >> + * below GUC_GGTT_TOP and utilizing this mapping to perform
> >> + * the authentication.
> >> + */
> >> +static int intel_huc_rsa_data_create(struct intel_huc *huc)
> >> +{
> >> + struct drm_i915_private *i915 = huc_to_i915(huc);
> >> + struct intel_guc *guc = &i915->guc;
> >> + struct i915_vma *vma;
> >> + void *vaddr;
> >> +
> >> + vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
> >> + if (IS_ERR(vma))
> >> + return PTR_ERR(vma);
> >> +
> > Are we not allocating an object for the dma xfer here that is then bound
> > to the reserved ggtt node? Why pin it again into the ggtt?
> > -Chris
>
> It is not bound to the reserved node. The reserved range is inaccessible by
> GuC, so I
> had to pull the signature back in for the auth stage.
Oh I see a stray comment above the function, and not about why you
allocate a second pinned vma. Comments are for describing why you do
things in the code; function doc are for telling users how to use the
iface.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] Revert "drm/i915/guc: Disable global reset"
Quoting Fernando Pacheco (2019-04-16 15:45:03) > > > On 4/9/19 2:54 PM, Chris Wilson wrote: > > Quoting Fernando Pacheco (2019-04-09 22:31:02) > >> This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8. > > And don't forget the test code that skips guc. > > -Chris > > Selftests? I couldn't find anything that skips guc. > I found some skips for guc submission. That should be moved to just skip the per-engine reset. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 6/7] drm: Add Client Cap for advance gamma mode
On Mon, Apr 15, 2019 at 09:20:55PM +0200, Daniel Vetter wrote: > On Mon, Apr 15, 2019 at 4:14 PM Lankhorst, Maarten > wrote: > > > > mån 2019-04-15 klockan 19:26 +0530 skrev Sharma, Shashank: > > > > -Original Message- > > > > From: Lankhorst, Maarten > > > > Sent: Monday, April 15, 2019 4:28 PM > > > > To: Shankar, Uma ; intel-gfx@lists.freedeskt > > > > op.org; dri- > > > > de...@lists.freedesktop.org > > > > Cc: Syrjala, Ville ; emil.l.velikov@gmail. > > > > com; > > > > s...@ravnborg.org; Roper, Matthew D ; > > > > seanp...@chromium.org; brian.star...@arm.com; dcasta...@chromium.or > > > > g; > > > > Sharma, Shashank > > > > Subject: Re: [v3 6/7] drm: Add Client Cap for advance gamma mode > > > > > > > > fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar: > > > > > Introduced a client cap for advance cap mode > > > > > capability. Userspace should set this to get > > > > > to be able to use the new gamma_mode property. > > > > > > > > > > If this is not set, driver will work in legacy > > > > > mode. > > > > > > > > > > Suggested-by: Ville Syrjälä > > > > > Signed-off-by: Uma Shankar > > > > > > > > Nack, this doesn't seem like a sensible idea. We already guard it > > > > behind the gamma mode property. Userspace shouldn't set the gamma > > > > mode > > > > to a value it doesn't understand. > > > > > > > > ~Maarten > > > > > > Hey Maarten, > > > In that case, what do you suggest should be the right way to do this > > > ? > > > > > > @Ville, any comments here ? > > > > > I would say drop this patch, and just enable segmented gamma > > unconditionally, it's not the first property that can cause trouble > > when not understood. > > Yeah, thus far we went with "new properties should have the old > behaviour as default, no cap/flag needed". That's a given. But it doesn't help with the mixed userspace when one of them doesn't know how to reset it back to default. > If you mix old&new > userspace and stuff starts looking funny, that's not a regression imo. > Also, it's a very uncommon use-case. I was mainly thinking of eg. wayland vs. X type of cases where the user might want to switch. If the wayland compositor uses the new fancy gamma thing but the xserver doesn't then this won't work anymore. But I guess easier solution is to just add the relevant knowledge to the ddx. Which should probably be a hard requirement for landing this. > > Wrt reset to default: fbdev emulation should do that for anything > that's too fancy, which is generally enough for the "developer of > compositors" use case. That part might be missing in the gamma/ctm > support in general I think. Probably. IIRC even running X at 8bpp and then swithcing back to fbcon leaves you with a gargbled palette. -- Ville Syrjälä Intel ___ 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 [v2,1/4] drm/i915: Verify workarounds immediately after application (rev2)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Verify workarounds immediately after application (rev2) URL : https://patchwork.freedesktop.org/series/59560/ State : success == Summary == CI Bug Log - changes from CI_DRM_5936_full -> Patchwork_12814_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12814_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_blt@normal-max: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +5 * igt@kms_atomic_transition@3x-modeset-transitions: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8 * igt@kms_busy@basic-modeset-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-f: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_content_protection@legacy: - shard-kbl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: PASS -> INCOMPLETE [fdo#109507] - shard-kbl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-wc: - shard-skl: PASS -> FAIL [fdo#108040] * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +21 * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> SKIP [fdo#109271] +94 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: PASS -> FAIL [fdo#103167] +5 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-onoff: - shard-iclb: PASS -> FAIL [fdo#109247] +7 * igt@kms_lease@atomic_implicit_crtc: - shard-skl: NOTRUN -> FAIL [fdo#110279] * igt@kms_lease@cursor_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110278] * igt@kms_plane@pixel-format-pipe-c-planes: - shard-glk: PASS -> SKIP [fdo#109271] * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-apl: NOTRUN -> FAIL [fdo#108145] +1 - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: PASS -> SKIP [fdo#109441] +2 * igt@kms_psr@sprite_mmap_gtt: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2 * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@kms_setmode@basic: - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_sysfs_edid_timing: - shard-apl: NOTRUN -> FAIL [fdo#100047] * igt@kms_universal_plane@universal-plane-gen9-features-pipe-b: - shard-apl: PASS -> DMESG-WARN [fdo#110376] +1 * igt@prime_nv_api@i915_nv_reimport_twice_check_flink_name: - shard-apl: NOTRUN -> SKIP [fdo#109271] +72 Possible fixes * igt@gem_ctx_isolation@vcs1-s3: - shard-kbl: DMESG-WARN [fdo#108566] -> PASS +1 * igt@i915_pm_rpm@dpms-non-lpsp: - shard-apl: DMESG-WARN [fdo#110376] -> PASS * igt@i915_selftest@live_workarounds: - shard-iclb: DMESG-FAIL [fdo#108954] -> PASS * igt@i915_suspend@debugfs-reader: - shard-apl: DMESG-WARN [fdo#108566] -> PASS +3 * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS - shard-glk: FAIL [fdo#102887] -> PASS * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: FAIL [fdo#102887] / [fdo#105363] -> PASS - shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS * igt@kms_flip@flip-vs-suspend: - shard-skl: INCOMPLETE [fdo#107773] / [fdo#109507] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite: - shard-iclb: FAIL [fdo#109247] -> PASS +16 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt: - shard-iclb: FAIL [fdo#103167] -> PASS +4 * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: FAIL [fdo#108145] -> PASS +1 * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: SKIP [fdo#109441] -> PASS +4 * igt@kms_psr@sprite_mmap_cpu: - shard-iclb: FAIL [fdo#107383] / [fdo#110215] -> PASS +4 [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047 [fdo#102887]: https://bugs.freedesktop
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_spin_batch: Add test to resend spinner
Quoting Mika Kuoppala (2019-04-16 16:01:58)
> Add subtests to resend the same spinner to same context
> and to other context.
>
> v2: other engines (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
> + igt_subtest_f("resubmit-%s", e->name)
> + spin_resubmit(fd, e->exec_id, 0);
> +
> + igt_subtest_f("resubmit-new-%s", e->name)
> + spin_resubmit(fd, e->exec_id, RESUBMIT_NEW_CTX);
> +
> + igt_subtest_f("resubmit-all-%s", e->name)
> + spin_resubmit(fd, e->exec_id, RESUBMIT_ALL_ENGINES);
> +
> + igt_subtest_f("resubmit-new-all-%s", e->name)
> + spin_resubmit(fd, e->exec_id,
> + RESUBMIT_NEW_CTX |
> + RESUBMIT_ALL_ENGINES);
You are getting close to wanting a loop here :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] Revert "drm/i915/guc: Disable global reset"
On 4/16/19 8:05 AM, Chris Wilson wrote: > Quoting Fernando Pacheco (2019-04-16 15:45:03) >> >> On 4/9/19 2:54 PM, Chris Wilson wrote: >>> Quoting Fernando Pacheco (2019-04-09 22:31:02) This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8. >>> And don't forget the test code that skips guc. >>> -Chris >> Selftests? I couldn't find anything that skips guc. >> I found some skips for guc submission. > That should be moved to just skip the per-engine reset. > -Chris Thanks for the clarification. Fernando ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ehl: inherit icl cdclk init/uninit
On Tue, 16 Apr 2019 11:28:52 +0300
Jani Nikula wrote:
> The cdclk init/uninit code was changed by commit 93a643f29bcb
> ("drm/i915/cdclk: have only one init/uninit function") between the
> versions of commit 39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake
> conditional code"). What got merged fails to do cdclk init/uninit on
> ehl.
Good catch!
Reviewed-by: Bob Paauwe
>
> Fixes: 39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake conditional code")
> Cc: José Roberto de Souza
> Cc: Lucas De Marchi
> Cc: Bob Paauwe
> Cc: Rodrigo Vivi
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 7f060ea..ae40a86 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -2034,7 +2034,7 @@ static void cnl_uninit_cdclk(struct drm_i915_private
> *dev_priv)
> */
> void intel_cdclk_init(struct drm_i915_private *i915)
> {
> - if (IS_ICELAKE(i915))
> + if (INTEL_GEN(i915) >= 11)
> icl_init_cdclk(i915);
> else if (IS_CANNONLAKE(i915))
> cnl_init_cdclk(i915);
> @@ -2053,7 +2053,7 @@ void intel_cdclk_init(struct drm_i915_private *i915)
> */
> void intel_cdclk_uninit(struct drm_i915_private *i915)
> {
> - if (IS_ICELAKE(i915))
> + if (INTEL_GEN(i915) >= 11)
> icl_uninit_cdclk(i915);
> else if (IS_CANNONLAKE(i915))
> cnl_uninit_cdclk(i915);
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
On 4/16/19 8:04 AM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-16 15:51:15)
>> On 4/9/19 3:22 PM, Chris Wilson wrote:
>>> Quoting Fernando Pacheco (2019-04-09 22:31:01)
diff --git a/drivers/gpu/drm/i915/intel_huc.c
b/drivers/gpu/drm/i915/intel_huc.c
index 94c04f16a2ad..89e0b942ae86 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -40,6 +40,59 @@ int intel_huc_init_misc(struct intel_huc *huc)
return 0;
}
+/*
+ * The HuC firmware image now sits above GUC_GGTT_TOP and this
+ * portion does not map through GTT. This means GuC cannot
+ * perform the HuC auth with the rsa signature sitting in that
+ * range. We resort to additionally perma-pinning the rsa signature
+ * below GUC_GGTT_TOP and utilizing this mapping to perform
+ * the authentication.
+ */
+static int intel_huc_rsa_data_create(struct intel_huc *huc)
+{
+ struct drm_i915_private *i915 = huc_to_i915(huc);
+ struct intel_guc *guc = &i915->guc;
+ struct i915_vma *vma;
+ void *vaddr;
+
+ vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
>>> Are we not allocating an object for the dma xfer here that is then bound
>>> to the reserved ggtt node? Why pin it again into the ggtt?
>>> -Chris
>> It is not bound to the reserved node. The reserved range is inaccessible by
>> GuC, so I
>> had to pull the signature back in for the auth stage.
> Oh I see a stray comment above the function, and not about why you
> allocate a second pinned vma. Comments are for describing why you do
Sorry, I thought I was providing an explanation. I'll revise!
> things in the code; function doc are for telling users how to use the
> iface.
Very true. Thanks for pointing this out.
Fernando
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Configurable GT idle frequency
On Mon, 15 Apr 2019 17:33:30 -0700
Vanshidhar Konda wrote:
> On Mon, Apr 15, 2019 at 04:05:26PM -0700, Bob Paauwe wrote:
> >There are real-time use cases where having deterministic CPU processes
> >can be more important than GPU power/performance. Parking the GPU at a
> >specific freqency by setting idle, min and max prohibits the normal
> >dynamic GPU frequency switching which can introduce significant PCI-E
> >latency. This adds the ability to configure the GPU "idle" frequecy
> >using the same method that already exists for minimum and maximum
> >frequencies.
> >
> >In addition, parking the idle frequency may reduce spool up latencies
> >on GPU workloads.
> >
> >Signed-off-by: Bob Paauwe
> >---
> > drivers/gpu/drm/i915/i915_sysfs.c | 60 +++
> > 1 file changed, 60 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> >b/drivers/gpu/drm/i915/i915_sysfs.c
> >index 41313005af42..62612c23d514 100644
> >--- a/drivers/gpu/drm/i915/i915_sysfs.c
> >+++ b/drivers/gpu/drm/i915/i915_sysfs.c
> >@@ -454,11 +454,69 @@ static ssize_t gt_min_freq_mhz_store(struct device
> >*kdev,
> > return ret ?: count;
> > }
> >
> >+static ssize_t gt_idle_freq_mhz_show(struct device *kdev, struct
> >device_attribute *attr, char *buf)
> >+{
> >+struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> >+
> >+return snprintf(buf, PAGE_SIZE, "%d\n",
> >+intel_gpu_freq(dev_priv,
> >+ dev_priv->gt_pm.rps.idle_freq));
> >+}
> >+
> >+static ssize_t gt_idle_freq_mhz_store(struct device *kdev,
> >+ struct device_attribute *attr,
> >+ const char *buf, size_t count)
> >+{
> >+struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> >+struct intel_rps *rps = &dev_priv->gt_pm.rps;
> >+intel_wakeref_t wakeref;
> >+u32 val;
>
> val can probably just be u8. max_freq, min_freq, etc. are only u8 in
> struct intel_rps *rps.
Using u32 is consistent with all the other _store functions in the file
and changing it would also mean changing the kstrtou32 call below. I'd
rather this function stay consistent with the min/max/boost frequency
functions. Changing to u8 would be a separate change and should be
applied to all the similar functions.
>
> >+ssize_t ret;
> >+
> >+ret = kstrtou32(buf, 0, &val);
> >+if (ret)
> >+return ret;
> >+
> >+wakeref = intel_runtime_pm_get(dev_priv);
> >+
> >+mutex_lock(&dev_priv->pcu_lock);
> >+
> >+val = intel_freq_opcode(dev_priv, val);
> >+
> >+if (val < rps->min_freq ||
> >+val > rps->max_freq ||
> >+val > rps->max_freq_softlimit) {
> >+mutex_unlock(&dev_priv->pcu_lock);
> >+intel_runtime_pm_put(dev_priv, wakeref);
> >+return -EINVAL;
> >+}
> >+
> >+rps->idle_freq = val;
> >+
> >+val = clamp_t(int, rps->cur_freq,
> >+ rps->idle_freq,
> >+ rps->max_freq_softlimit);
>
> This should probably be clamped to u8 instead of int.
Similar to above, this is consistent with the other similar functions.
>
> Vanshi
>
> >+
> >+/*
> >+ * If the current freq is at the old idle freq we should
> >+ * ajust it to the new idle. Calling *_set_rps will also
> >+ * update the interrupt limits and PMINTRMSK if ncessary.
> >+ */
> >+ret = intel_set_rps(dev_priv, val);
> >+
> >+mutex_unlock(&dev_priv->pcu_lock);
> >+
> >+intel_runtime_pm_put(dev_priv, wakeref);
> >+
> >+return ret ?: count;
> >+}
> >+
> > static DEVICE_ATTR_RO(gt_act_freq_mhz);
> > static DEVICE_ATTR_RO(gt_cur_freq_mhz);
> > static DEVICE_ATTR_RW(gt_boost_freq_mhz);
> > static DEVICE_ATTR_RW(gt_max_freq_mhz);
> > static DEVICE_ATTR_RW(gt_min_freq_mhz);
> >+static DEVICE_ATTR_RW(gt_idle_freq_mhz);
> >
> > static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
> >
> >@@ -492,6 +550,7 @@ static const struct attribute * const gen6_attrs[] = {
> > &dev_attr_gt_boost_freq_mhz.attr,
> > &dev_attr_gt_max_freq_mhz.attr,
> > &dev_attr_gt_min_freq_mhz.attr,
> >+&dev_attr_gt_idle_freq_mhz.attr,
> > &dev_attr_gt_RP0_freq_mhz.attr,
> > &dev_attr_gt_RP1_freq_mhz.attr,
> > &dev_attr_gt_RPn_freq_mhz.attr,
> >@@ -504,6 +563,7 @@ static const struct attribute * const vlv_attrs[] = {
> > &dev_attr_gt_boost_freq_mhz.attr,
> > &dev_attr_gt_max_freq_mhz.attr,
> > &dev_attr_gt_min_freq_mhz.attr,
> >+&dev_attr_gt_idle_freq_mhz.attr,
> > &dev_attr_gt_RP0_freq_mhz.attr,
> > &dev_attr_gt_RP1_freq_mhz.attr,
> > &dev_attr_gt_RPn_freq_mhz.attr,
> >--
> >2.19.2
> >
> >___
> >Intel-gfx mailing list
> >Intel-gfx@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Re: [Intel-gfx] [PATCH] drm/i915: Configurable GT idle frequency
On Tue, Apr 16, 2019 at 08:30:22AM -0700, Bob Paauwe wrote:
On Mon, 15 Apr 2019 17:33:30 -0700
Vanshidhar Konda wrote:
On Mon, Apr 15, 2019 at 04:05:26PM -0700, Bob Paauwe wrote:
>There are real-time use cases where having deterministic CPU processes
>can be more important than GPU power/performance. Parking the GPU at a
>specific freqency by setting idle, min and max prohibits the normal
>dynamic GPU frequency switching which can introduce significant PCI-E
>latency. This adds the ability to configure the GPU "idle" frequecy
>using the same method that already exists for minimum and maximum
>frequencies.
>
>In addition, parking the idle frequency may reduce spool up latencies
>on GPU workloads.
>
>Signed-off-by: Bob Paauwe
>---
> drivers/gpu/drm/i915/i915_sysfs.c | 60 +++
> 1 file changed, 60 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
>index 41313005af42..62612c23d514 100644
>--- a/drivers/gpu/drm/i915/i915_sysfs.c
>+++ b/drivers/gpu/drm/i915/i915_sysfs.c
>@@ -454,11 +454,69 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
>return ret ?: count;
> }
>
>+static ssize_t gt_idle_freq_mhz_show(struct device *kdev, struct
device_attribute *attr, char *buf)
>+{
>+ struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
>+
>+ return snprintf(buf, PAGE_SIZE, "%d\n",
>+ intel_gpu_freq(dev_priv,
>+ dev_priv->gt_pm.rps.idle_freq));
>+}
>+
>+static ssize_t gt_idle_freq_mhz_store(struct device *kdev,
>+ struct device_attribute *attr,
>+ const char *buf, size_t count)
>+{
>+ struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
>+ struct intel_rps *rps = &dev_priv->gt_pm.rps;
>+ intel_wakeref_t wakeref;
>+ u32 val;
val can probably just be u8. max_freq, min_freq, etc. are only u8 in
struct intel_rps *rps.
Using u32 is consistent with all the other _store functions in the file
and changing it would also mean changing the kstrtou32 call below. I'd
rather this function stay consistent with the min/max/boost frequency
functions. Changing to u8 would be a separate change and should be
applied to all the similar functions.
Thanks for pointing that out.
I recently joined the team, so not sure if you would like someone else
to review as well.
Reviewed-by: Vanshidhar Konda
>+ ssize_t ret;
>+
>+ ret = kstrtou32(buf, 0, &val);
>+ if (ret)
>+ return ret;
>+
>+ wakeref = intel_runtime_pm_get(dev_priv);
>+
>+ mutex_lock(&dev_priv->pcu_lock);
>+
>+ val = intel_freq_opcode(dev_priv, val);
>+
>+ if (val < rps->min_freq ||
>+ val > rps->max_freq ||
>+ val > rps->max_freq_softlimit) {
>+ mutex_unlock(&dev_priv->pcu_lock);
>+ intel_runtime_pm_put(dev_priv, wakeref);
>+ return -EINVAL;
>+ }
>+
>+ rps->idle_freq = val;
>+
>+ val = clamp_t(int, rps->cur_freq,
>+ rps->idle_freq,
>+ rps->max_freq_softlimit);
This should probably be clamped to u8 instead of int.
Similar to above, this is consistent with the other similar functions.
Vanshi
>+
>+ /*
>+* If the current freq is at the old idle freq we should
>+* ajust it to the new idle. Calling *_set_rps will also
>+* update the interrupt limits and PMINTRMSK if ncessary.
>+*/
>+ ret = intel_set_rps(dev_priv, val);
>+
>+ mutex_unlock(&dev_priv->pcu_lock);
>+
>+ intel_runtime_pm_put(dev_priv, wakeref);
>+
>+ return ret ?: count;
>+}
>+
> static DEVICE_ATTR_RO(gt_act_freq_mhz);
> static DEVICE_ATTR_RO(gt_cur_freq_mhz);
> static DEVICE_ATTR_RW(gt_boost_freq_mhz);
> static DEVICE_ATTR_RW(gt_max_freq_mhz);
> static DEVICE_ATTR_RW(gt_min_freq_mhz);
>+static DEVICE_ATTR_RW(gt_idle_freq_mhz);
>
> static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
>
>@@ -492,6 +550,7 @@ static const struct attribute * const gen6_attrs[] = {
>&dev_attr_gt_boost_freq_mhz.attr,
>&dev_attr_gt_max_freq_mhz.attr,
>&dev_attr_gt_min_freq_mhz.attr,
>+ &dev_attr_gt_idle_freq_mhz.attr,
>&dev_attr_gt_RP0_freq_mhz.attr,
>&dev_attr_gt_RP1_freq_mhz.attr,
>&dev_attr_gt_RPn_freq_mhz.attr,
>@@ -504,6 +563,7 @@ static const struct attribute * const vlv_attrs[] = {
>&dev_attr_gt_boost_freq_mhz.attr,
>&dev_attr_gt_max_freq_mhz.attr,
>&dev_attr_gt_min_freq_mhz.attr,
>+ &dev_attr_gt_idle_freq_mhz.attr,
>&dev_attr_gt_RP0_freq_mhz.attr,
>&dev_attr_gt_RP1_freq_mhz.attr,
>&dev_attr_gt_RPn_freq_mhz.attr,
>--
>2.19.2
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesk
Re: [Intel-gfx] [PATCH v7] drm/i915/icl: Fix clockgating issue when using scalers
On Tue, 2019-04-16 at 17:14 +0300, Ville Syrjälä wrote:
> On Mon, Apr 15, 2019 at 03:55:19PM -0700, Radhakrishna Sripada wrote:
> > Fixes the clock-gating issue when pipe scaling is enabled.
> > (Lineage #2006604312)
> >
> > V2: Fix typo in headline(Chris)
> > Handle the non double buffered nature of the register(Ville)
> > V3: Fix checkpatch warning. BAT failure for V2 on gen3 looks
> > unrelated.
> > V4: Split the icl and skl wa's(Ville)
> > V5: Split the checks for icl and skl(Ville)
> > V6: Correct the flipped checks in intel_pre_plane_update(Ville)
> > V7: Use enum for pipe and extend the WA for plane scalers(Ville)
> >
> > Cc: Chris Wilson
> > Cc: Ville Syrjala
> > Cc: Rodrigo Vivi
> > Cc: Clint Taylor
> > Signed-off-by: Radhakrishna Sripada > >
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 42
> >
> > 1 file changed, 37 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 3bd40a4a6739..6f68d039ab47 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -476,6 +476,7 @@ static const struct intel_limit
> > intel_limits_bxt = {
> > .p2 = { .p2_slow = 1, .p2_fast = 20 },
> > };
> >
> > +/* WA Display #0827: Gen9:all */
> > static void
> > skl_wa_827(struct drm_i915_private *dev_priv, int pipe, bool
> > enable)
> > {
> > @@ -489,6 +490,19 @@ skl_wa_827(struct drm_i915_private *dev_priv,
> > int pipe, bool enable)
> >~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> > }
> >
> > +/* Wa_2006604312:icl */
> > +static void
> > +icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, enum
> > pipe pipe,
> > + bool enable)
> > +{
> > + if (enable)
> > + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > + I915_READ(CLKGATE_DIS_PSL(pipe)) |
> > DPFR_GATING_DIS);
> > + else
> > + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > + I915_READ(CLKGATE_DIS_PSL(pipe)) &
> > ~DPFR_GATING_DIS);
> > +}
> > +
> > static bool
> > needs_modeset(const struct drm_crtc_state *state)
> > {
> > @@ -5505,6 +5519,18 @@ static bool needs_nv12_wa(struct
> > drm_i915_private *dev_priv,
> > return false;
> > }
> >
> > +static bool needs_scalerclk_wa(struct drm_i915_private *dev_priv,
> > + const struct intel_crtc_state
> > *crtc_state)
> > +{
> > + /* Wa_2006604312:icl */
> > + if (IS_ICELAKE(dev_priv) &&
> > + (crtc_state->pch_pfit.enabled ||
>
> I don't think we need the pfit check anymore. scaler_users should
> account for that?
I was of the same opinion but sided to err rather than to be sorry. I
can spin out a newer version with the suggested change.
- Radhakrishna(RK) Sripada
>
> > +crtc_state->scaler_state.scaler_users > 0))
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > static void intel_post_plane_update(struct intel_crtc_state
> > *old_crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> > >base.crtc);
> > @@ -5538,11 +5564,13 @@ static void intel_post_plane_update(struct
> > intel_crtc_state *old_crtc_state)
> > intel_post_enable_primary(&crtc->base,
> > pipe_config);
> > }
> >
> > - /* Display WA 827 */
> > if (needs_nv12_wa(dev_priv, old_crtc_state) &&
> > - !needs_nv12_wa(dev_priv, pipe_config)) {
> > + !needs_nv12_wa(dev_priv, pipe_config))
> > skl_wa_827(dev_priv, crtc->pipe, false);
> > - }
> > +
> > + if (needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> > + !needs_scalerclk_wa(dev_priv, pipe_config))
> > + icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
> > }
> >
> > static void intel_pre_plane_update(struct intel_crtc_state
> > *old_crtc_state,
> > @@ -5579,9 +5607,13 @@ static void intel_pre_plane_update(struct
> > intel_crtc_state *old_crtc_state,
> >
> > /* Display WA 827 */
> > if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
> > - needs_nv12_wa(dev_priv, pipe_config)) {
> > + needs_nv12_wa(dev_priv, pipe_config))
> > skl_wa_827(dev_priv, crtc->pipe, true);
> > - }
> > +
> > + /* Wa_2006604312:icl */
> > + if (!needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> > + needs_scalerclk_wa(dev_priv, pipe_config))
> > + icl_wa_scalerclkgating(dev_priv, crtc->pipe, true);
> >
> > /*
> > * Vblank time updates from the shadow to live plane control
> > register
> > --
> > 2.20.0.rc2.7.g965798d1f299
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Configurable GT idle frequency
Quoting Bob Paauwe (2019-04-16 00:05:26) > There are real-time use cases where having deterministic CPU processes > can be more important than GPU power/performance. Parking the GPU at a > specific freqency by setting idle, min and max prohibits the normal > dynamic GPU frequency switching which can introduce significant PCI-E > latency. This adds the ability to configure the GPU "idle" frequecy > using the same method that already exists for minimum and maximum > frequencies. What exactly is the problem? We never use idle frequency while active, always restarting at max(cur, rpe). So for the simple minded among us, where is the igt demonstrating the issue? -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 i915/gem_spin_batch: Add test to resend spinner (rev2)
== Series Details == Series: i915/gem_spin_batch: Add test to resend spinner (rev2) URL : https://patchwork.freedesktop.org/series/59586/ State : success == Summary == CI Bug Log - changes from IGT_4952 -> IGTPW_2870 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59586/revisions/2/mbox/ Known issues Here are the changes found in IGTPW_2870 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-icl-y: NOTRUN -> SKIP [fdo#109315] +17 * igt@gem_exec_basic@basic-bsd2: - fi-icl-y: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_parse@basic-rejected: - fi-icl-y: NOTRUN -> SKIP [fdo#109289] +1 * igt@i915_selftest@live_hangcheck: - fi-icl-y: NOTRUN -> INCOMPLETE [fdo#108569] * igt@kms_chamelium@dp-crc-fast: - fi-icl-y: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-glk-dsi: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_force_connector_basic@force-load-detect: - fi-icl-y: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#103191] * igt@kms_psr@primary_mmap_gtt: - fi-icl-y: NOTRUN -> SKIP [fdo#110189] +3 * igt@prime_vgem@basic-fence-flip: - fi-icl-y: NOTRUN -> SKIP [fdo#109294] [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (48 -> 43) -- Additional (1): fi-icl-y Missing(6): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * IGT: IGT_4952 -> IGTPW_2870 CI_DRM_5939: 757f5370dc4baed0475b6e28efd67ecc267e8745 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_2870: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2870/ IGT_4952: d196925ed16221768689efa1ea06c4869e9fc2a9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Testlist changes == +igt@gem_spin_batch@resubmit-all-blt +igt@gem_spin_batch@resubmit-all-bsd +igt@gem_spin_batch@resubmit-all-bsd1 +igt@gem_spin_batch@resubmit-all-bsd2 +igt@gem_spin_batch@resubmit-all-default +igt@gem_spin_batch@resubmit-all-render +igt@gem_spin_batch@resubmit-all-vebox +igt@gem_spin_batch@resubmit-blt +igt@gem_spin_batch@resubmit-bsd +igt@gem_spin_batch@resubmit-bsd1 +igt@gem_spin_batch@resubmit-bsd2 +igt@gem_spin_batch@resubmit-default +igt@gem_spin_batch@resubmit-new-all-blt +igt@gem_spin_batch@resubmit-new-all-bsd +igt@gem_spin_batch@resubmit-new-all-bsd1 +igt@gem_spin_batch@resubmit-new-all-bsd2 +igt@gem_spin_batch@resubmit-new-all-default +igt@gem_spin_batch@resubmit-new-all-render +igt@gem_spin_batch@resubmit-new-all-vebox +igt@gem_spin_batch@resubmit-new-blt +igt@gem_spin_batch@resubmit-new-bsd +igt@gem_spin_batch@resubmit-new-bsd1 +igt@gem_spin_batch@resubmit-new-bsd2 +igt@gem_spin_batch@resubmit-new-default +igt@gem_spin_batch@resubmit-new-render +igt@gem_spin_batch@resubmit-new-vebox +igt@gem_spin_batch@resubmit-render +igt@gem_spin_batch@resubmit-vebox == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2870/ ___ 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 [RFC,1/2] drm/i915: start moving state checker to intel_verify.c
== Series Details == Series: series starting with [RFC,1/2] drm/i915: start moving state checker to intel_verify.c URL : https://patchwork.freedesktop.org/series/59569/ State : success == Summary == CI Bug Log - changes from CI_DRM_5937_full -> Patchwork_12815_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12815_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-reset: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +5 * igt@gem_ctx_sseu@invalid-args: - shard-skl: NOTRUN -> SKIP [fdo#109271] +75 * igt@gem_exec_parse@basic-rejected: - shard-iclb: NOTRUN -> SKIP [fdo#109289] +3 * igt@gem_softpin@noreloc-s3: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@gem_tiled_swapping@non-threaded: - shard-snb: NOTRUN -> FAIL [fdo#108686] * igt@gem_userptr_blits@coherency-sync: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@i915_pm_rpm@sysfs-read: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +3 * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking: - shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7 * igt@kms_busy@basic-flip-d: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9 * igt@kms_chamelium@hdmi-crc-planes-random: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +2 * igt@kms_color@pipe-a-gamma: - shard-skl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-glk: NOTRUN -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] +2 * igt@kms_cursor_crc@cursor-512x170-onscreen: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_crc@cursor-64x21-random: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_flip@2x-flip-vs-panning: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +6 * igt@kms_force_connector_basic@force-connector-state: - shard-iclb: NOTRUN -> SKIP [fdo#109285] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite: - shard-snb: NOTRUN -> SKIP [fdo#109271] +74 * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +12 * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +7 * igt@kms_frontbuffer_tracking@fbcpsr-1p-indfb-fliptrack: - shard-glk: NOTRUN -> SKIP [fdo#109271] +44 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-gtt: - shard-iclb: PASS -> FAIL [fdo#109247] +18 * igt@kms_frontbuffer_tracking@psr-shrfb-scaledprimary: - shard-skl: PASS -> FAIL [fdo#103167] +2 * igt@kms_lease@page_flip_implicit_plane: - shard-snb: NOTRUN -> FAIL [fdo#110281] * igt@kms_lease@setcrtc_implicit_plane: - shard-skl: NOTRUN -> FAIL [fdo#110281] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9 * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: PASS -> SKIP [fdo#109271] * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#108145] / [fdo#110403] * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-glk: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format: - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_psr@primary_render: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] * igt@kms_psr@psr2_primary_blt: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +1 * igt@kms_psr@psr2_sprite_blt: - shard-iclb: PASS -> SKIP [fdo#109441] * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@prime_nv_test@nv_i915_sharing: - shard-iclb: NOTRUN -> SKIP [fdo#109291] +2 Possible fixes * igt@gem_exec_suspend@basic-s3: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@i915_suspend@debugfs-reader: - shard-apl: DMESG-WARN [fdo#108566] -> PASS +9 * igt@kms_color@pipe-b-ctm-0-5: - shard-skl:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Seal races between async GPU cancellation, retirement and signaling
== Series Details == Series: drm/i915: Seal races between async GPU cancellation, retirement and signaling URL : https://patchwork.freedesktop.org/series/59584/ State : success == Summary == CI Bug Log - changes from CI_DRM_5939 -> Patchwork_12817 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59584/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12817 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic-files: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +101 * igt@i915_module_load@reload-with-fault-injection: - fi-icl-y: PASS -> INCOMPLETE [fdo#107713] * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: PASS -> INCOMPLETE [fdo#108602] / [fdo#108744] * igt@kms_busy@basic-flip-c: - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +47 * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@read-crc-pipe-c: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-glk-dsi: PASS -> FAIL [fdo#103191] * igt@runner@aborted: - fi-skl-iommu: NOTRUN -> FAIL [fdo#104108] / [fdo#108602] - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] Possible fixes * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - fi-byt-clapper: FAIL [fdo#103191] -> PASS - fi-glk-dsi: FAIL [fdo#103191] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 Participating hosts (48 -> 42) -- Additional (2): fi-byt-j1900 fi-gdg-551 Missing(8): fi-kbl-soraka fi-kbl-7567u fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-kbl-7500u fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5939 -> Patchwork_12817 CI_DRM_5939: 757f5370dc4baed0475b6e28efd67ecc267e8745 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4951: cc9a60c029432b5843724e4f2c57f9f815f7adbb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12817: ac8241055cd5bf532313557418591c5b82ad3227 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ac8241055cd5 drm/i915: Seal races between async GPU cancellation, retirement and signaling == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12817/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: add immutable zpos plane properties
Op 16-04-2019 om 15:42 schreef Ville Syrjälä: > On Tue, Apr 16, 2019 at 03:28:15PM +0200, Maarten Lankhorst wrote: >> Op 16-04-2019 om 15:20 schreef Ville Syrjälä: >>> On Sat, Apr 13, 2019 at 11:13:27AM +, Simon Ser wrote: From: Ville Syrjälä This adds basic immutable support for the zpos property. The zpos increases from bottom to top: primary, sprites, cursor. >>> I was thinking a bit about how we might go about testing this. >>> >>> We probably want a basic test that just checks that if any >>> plane has a zpos prop then all planes should have it. >> This would be a good test for BAT. >>> A functional test would stack the planes up in some way and >>> compare against a software rendered reference. IIRC there was >>> a zpos test case floating around but that depended on alpha >>> blending which we don't necessarily have. >> But with semi-overlapping planes you would accomplish the same, without >> alpha dependency. >> >> Something like this? >> >> [BG] [Sprite 1][Cursor] >> [Primary] [Sprite 2] > Should probably be good enough. Though I was pondering is there a > way to position an arbitraty number of planes such that the > resulting picture has a visible region for every possible > combination of planes? n planes, width = width / (n + 1) position = n * 3/4 * plane_width ? or something If each plane has its own color, then it would work.. >> Perhaps primary fullscreen to prevent issues with hw that doesn't support >> partial planes? > I guess. And maybe a second test that disables the primary > so that we can also get the bg color into the picture? I don't think we finalized the bg color api yet, else it would be good to have.. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/12] drm/fb-helper: Avoid race with DRM userspace
Den 16.04.2019 09.59, skrev Daniel Vetter:
> On Sun, Apr 07, 2019 at 06:52:33PM +0200, Noralf Trønnes wrote:
>> drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
>> This is done by looking at the fb on the primary plane. By the time
>> fb-helper gets around to committing, it's possible that the facts have
>> changed.
>>
>> Avoid this race by holding the drm_device->master_mutex lock while
>> committing. When DRM userspace does its first open, it will now wait
>> until fb-helper is done. The helper will stay away if there's a master.
>>
>> Locking rule: Always take the fb-helper lock first.
>>
>> v2:
>> - Remove drm_fb_helper_is_bound() (Daniel Vetter)
>> - No need to check fb_helper->dev->master in
>> drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
>>
>> Suggested-by: Daniel Vetter
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/drm_auth.c | 20
>> drivers/gpu/drm/drm_fb_helper.c | 90 -
>> drivers/gpu/drm/drm_internal.h | 2 +
>> 3 files changed, 67 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
>> index 1669c42c40ed..db199807b7dc 100644
>> --- a/drivers/gpu/drm/drm_auth.c
>> +++ b/drivers/gpu/drm/drm_auth.c
>> @@ -368,3 +368,23 @@ void drm_master_put(struct drm_master **master)
>> *master = NULL;
>> }
>> EXPORT_SYMBOL(drm_master_put);
>> +
>> +/* Used by drm_client and drm_fb_helper */
>> +bool drm_master_internal_acquire(struct drm_device *dev)
>> +{
>> +mutex_lock(&dev->master_mutex);
>> +if (dev->master) {
>> +mutex_unlock(&dev->master_mutex);
>> +return false;
>> +}
>> +
>> +return true;
>> +}
>> +EXPORT_SYMBOL(drm_master_internal_acquire);
>> +
>> +/* Used by drm_client and drm_fb_helper */
>> +void drm_master_internal_release(struct drm_device *dev)
>> +{
>> +mutex_unlock(&dev->master_mutex);
>> +}
>> +EXPORT_SYMBOL(drm_master_internal_release);
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 84791dd4a90d..a6be09ae899b 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -44,6 +44,7 @@
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_crtc_helper_internal.h"
>> +#include "drm_internal.h"
>>
>> static bool drm_fbdev_emulation = true;
>> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
>> @@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct
>> drm_fb_helper *fb_helper)
>> return ret;
>> }
>>
>> -static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
>> +static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
>
> Bikeshed: usually the function variant that's run with locks already taken
> is called _locked or has a __ prefix. _force feels a bit misplaced.
This isn't a _locked function in the usual sense, it is: apply modeset
even if there is a DRM master. So we are _forcing a modeset on a
possibly unexpecting DRM userspace. To me a _locked function would imply
that the caller _must_ take a lock in order to use it.
But no big deal, I can rename it _locked if that reads better. After a
few years of reading kernel code I've come to appreciate the consistency
in how things are done and named. Every time things are different it
slows down my internal logic/pattern parser.
>> {
>> struct drm_device *dev = fb_helper->dev;
>>
>> @@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
>> *fb_helper)
>> return restore_fbdev_mode_legacy(fb_helper);
>> }
>>
>> +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
>> +{
>> +struct drm_device *dev = fb_helper->dev;
>> +int ret;
>> +
>> +if (!drm_master_internal_acquire(dev))
>> +return -EBUSY;
>> +
>> +ret = restore_fbdev_mode_force(fb_helper);
>> +
>> +drm_master_internal_release(dev);
>> +
>> +return ret;
>> +}
>> +
>> /**
>> * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
>> * @fb_helper: driver-allocated fbdev helper, can be NULL
>> @@ -556,34 +572,6 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
>> drm_fb_helper *fb_helper)
>> }
>> EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
>>
>> -static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
>> -{
>> -struct drm_device *dev = fb_helper->dev;
>> -struct drm_crtc *crtc;
>> -int bound = 0, crtcs_bound = 0;
>> -
>> -/*
>> - * Sometimes user space wants everything disabled, so don't steal the
>> - * display if there's a master.
>> - */
>> -if (READ_ONCE(dev->master))
>> -return false;
>> -
>> -drm_for_each_crtc(crtc, dev) {
>> -drm_modeset_lock(&crtc->mutex, NULL);
>> -if (crtc->primary->fb)
>> -crtcs_bound++;
>> -if (crtc->primary->fb == fb_helper->fb)
>> -bound
