Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Security mitigation for Intel Gen7/7.5 HWs
Quoting Patchwork (2020-02-20 03:31:24) > Participating hosts (42 -> 36) > -- > > Additional (6): fi-bdw-5557u fi-glk-dsi fi-ilk-650 fi-snb-2520m > fi-cfl-8109u fi-bsw-kefka > Missing(12): fi-hsw-4770r fi-hsw-4200u fi-byt-j1900 fi-byt-squawks > fi-bsw-cyan fi-cfl-8700k fi-cfl-guc fi-kbl-7500u fi-hsw-4770 fi-byt-n2820 > fi-byt-clapper fi-bdw-samus Please see the fixes (and cleanup) patch so that the bb is actually built and not killing gen7 hosts. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/gt: Prevent allocation on a banned context
If a context is banned even before we submit our first request to it,
report the failure before we attempt to allocate any resources for the
context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 8bb444cda14f..01474d3a558b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -51,6 +51,11 @@ int intel_context_alloc_state(struct intel_context *ce)
return -EINTR;
if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {
+ if (intel_context_is_banned(ce)) {
+ err = -EIO;
+ goto unlock;
+ }
+
err = ce->ops->alloc(ce);
if (unlikely(err))
goto unlock;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915/gt: Declare when we enabled timeslicing
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine.h | 3 ++-
drivers/gpu/drm/i915/gt/intel_engine_user.c | 5 +
include/uapi/drm/i915_drm.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 29c8c03c5caa..a32dc82a90d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -326,7 +326,8 @@ intel_engine_has_timeslices(const struct intel_engine_cs
*engine)
if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
return false;
- return intel_engine_has_semaphores(engine);
+ return (intel_engine_has_semaphores(engine) &&
+ intel_engine_has_preemption(engine));
}
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 848decee9066..b84fdd722781 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -121,6 +121,11 @@ static void set_scheduler_caps(struct drm_i915_private
*i915)
else
disabled |= BIT(map[i].sched);
}
+
+ if (intel_engine_has_timeslices(engine))
+ enabled |= I915_SCHEDULER_CAP_TIMESLICING;
+ else
+ disabled |= I915_SCHEDULER_CAP_TIMESLICING;
}
i915->caps.scheduler = enabled & ~disabled;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 829c0a48577f..f4d521f51258 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -523,6 +523,7 @@ typedef struct drm_i915_irq_wait {
#define I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
#define I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
#define I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
+#define I915_SCHEDULER_CAP_TIMESLICING (1ul << 5)
#define I915_PARAM_HUC_STATUS 42
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.
v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 +++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 40 +---
drivers/gpu/drm/i915/i915_reg.h | 1 +
5 files changed, 61 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e46e55354e95..1a2e9610f1a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1288,6 +1288,12 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
if (engine->id == RENDER_CLASS && IS_GEN_RANGE(dev_priv, 4, 7))
drm_printf(m, "\tCCID: 0x%08x\n", ENGINE_READ(engine, CCID));
+ if (HAS_EXECLISTS(dev_priv)) {
+ drm_printf(m, "\tEL_STAT_HI: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_HI));
+ drm_printf(m, "\tEL_STAT_LO: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_LO));
+ }
drm_printf(m, "\tRING_START: 0x%08x\n",
ENGINE_READ(engine, RING_START));
drm_printf(m, "\tRING_HEAD: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index b23366a81048..24cff658e6e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -156,6 +156,15 @@ struct intel_engine_execlists {
*/
struct i915_priolist default_priolist;
+ /**
+* @yield: CCID at the time of the last semaphore-wait interrupt.
+*
+* Instead of leaving a semaphore busy-spinning on an engine, we would
+* like to switch to another ready context, i.e. yielding the semaphore
+* timeslice.
+*/
+ u32 yield;
+
/**
* @error_interrupt: CS Master EIR
*
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f0e7fd95165a..875bd0392ffc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -39,6 +39,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
}
}
+ if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
+ WRITE_ONCE(engine->execlists.yield,
+ ENGINE_READ_FW(engine, RING_EXECLIST_STATUS_HI));
+ if (del_timer(>execlists.timer))
+ tasklet = true;
+ }
+
if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
tasklet = true;
@@ -228,7 +235,8 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
const u32 dmask = irqs << 16 | irqs;
const u32 smask = irqs << 16;
@@ -366,7 +374,8 @@ void gen8_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
const u32 gt_interrupts[] = {
irqs << GEN8_RCS_IRQ_SHIFT | irqs << GEN8_BCS_IRQ_SHIFT,
irqs << GEN8_VCS0_IRQ_SHIFT | irqs << GEN8_VCS1_IRQ_SHIFT,
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
[Intel-gfx] [PATCH 1/6] drm/i915/gt: Protect signaler walk with RCU
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the list_del_rcu.
v2: Mark the deps as safe-for-rcu
Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new
waiters")
Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
requests")
Signed-off-by: Chris Wilson
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 7 ---
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ba31cbe8c68e..47561dc29304 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1668,9 +1668,9 @@ last_active(const struct intel_engine_execlists
*execlists)
wait_link)
#define for_each_signaler(p__, rq__) \
- list_for_each_entry_lockless(p__, \
-&(rq__)->sched.signalers_list, \
-signal_link)
+ list_for_each_entry_rcu(p__, \
+ &(rq__)->sched.signalers_list, \
+ signal_link)
static void defer_request(struct i915_request *rq, struct list_head * const pl)
{
@@ -2533,11 +2533,13 @@ static bool execlists_hold(struct intel_engine_cs
*engine,
static bool hold_request(const struct i915_request *rq)
{
struct i915_dependency *p;
+ bool result = false;
/*
* If one of our ancestors is on hold, we must also be on hold,
* otherwise we will bypass it and execute before it.
*/
+ rcu_read_lock();
for_each_signaler(p, rq) {
const struct i915_request *s =
container_of(p->signaler, typeof(*s), sched);
@@ -2545,11 +2547,13 @@ static bool hold_request(const struct i915_request *rq)
if (s->engine != rq->engine)
continue;
- if (i915_request_on_hold(s))
- return true;
+ result = i915_request_on_hold(s);
+ if (result)
+ break;
}
+ rcu_read_unlock();
- return false;
+ return result;
}
static void __execlists_unhold(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index e19a37a83397..59f70b674665 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -486,7 +486,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
list_for_each_entry_safe(dep, tmp, >signalers_list, signal_link) {
GEM_BUG_ON(!list_empty(>dfs_link));
- list_del(>wait_link);
+ list_del_rcu(>wait_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
GEM_BUG_ON(dep->signaler != node);
GEM_BUG_ON(!list_empty(>dfs_link));
- list_del(>signal_link);
+ list_del_rcu(>signal_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -526,7 +526,8 @@ static struct i915_global_scheduler global = { {
int __init i915_global_scheduler_init(void)
{
global.slab_dependencies = KMEM_CACHE(i915_dependency,
- SLAB_HWCACHE_ALIGN);
+ SLAB_HWCACHE_ALIGN |
+ SLAB_TYPESAFE_BY_RCU);
if (!global.slab_dependencies)
return -ENOMEM;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915/gem: Check that the context wasn't closed during setup
As setup takes a long time, the user may close the context during the
construction of the execbuf. In order to make sure we correctly track
all outstanding work with non-persistent contexts, we need to serialise
the submission with the context closure and mop up any leaks.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 87fa5f42c39a..b2311fe93ad8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2729,6 +2729,12 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_batch_unpin;
}
+ /* Check that the context wasn't destroyed before setup */
+ if (!rcu_access_pointer(eb.context->gem_context)) {
+ err = -ENOENT;
+ goto err_request;
+ }
+
if (in_fence) {
err = i915_request_await_dma_fence(eb.request, in_fence);
if (err < 0)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915/gem: Consolidate ctx->engines[] release
Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241
Signed-off-by: Chris Wilson
---
Reorder set-closed/engine_idle_release to avoid premature killing
Take a reference to prevent racing context free with engine cleanup
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 190 ++--
1 file changed, 100 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 3e82739bdbc0..99206ec45876 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -243,7 +243,6 @@ static void __free_engines(struct i915_gem_engines *e,
unsigned int count)
if (!e->engines[count])
continue;
- RCU_INIT_POINTER(e->engines[count]->gem_context, NULL);
intel_context_put(e->engines[count]);
}
kfree(e);
@@ -270,8 +269,6 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
if (!e)
return ERR_PTR(-ENOMEM);
- e->ctx = ctx;
-
for_each_engine(engine, gt, id) {
struct intel_context *ce;
@@ -305,7 +302,6 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
list_del(>link);
spin_unlock(>i915->gem.contexts.lock);
- free_engines(rcu_access_pointer(ctx->engines));
mutex_destroy(>engines_mutex);
if (ctx->timeline)
@@ -492,30 +488,110 @@ static void kill_engines(struct i915_gem_engines
*engines)
static void kill_stale_engines(struct i915_gem_context *ctx)
{
struct i915_gem_engines *pos, *next;
- unsigned long flags;
- spin_lock_irqsave(>stale.lock, flags);
+ spin_lock_irq(>stale.lock);
+ GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
list_for_each_entry_safe(pos, next, >stale.engines, link) {
- if (!i915_sw_fence_await(>fence))
+ if (!i915_sw_fence_await(>fence)) {
+ list_del_init(>link);
continue;
+ }
- spin_unlock_irqrestore(>stale.lock, flags);
+ spin_unlock_irq(>stale.lock);
kill_engines(pos);
- spin_lock_irqsave(>stale.lock, flags);
+ spin_lock_irq(>stale.lock);
+ GEM_BUG_ON(i915_sw_fence_signaled(>fence));
list_safe_reset_next(pos, next, link);
list_del_init(>link); /* decouple from FENCE_COMPLETE */
i915_sw_fence_complete(>fence);
}
- spin_unlock_irqrestore(>stale.lock, flags);
+ spin_unlock_irq(>stale.lock);
}
static void kill_context(struct i915_gem_context *ctx)
{
kill_stale_engines(ctx);
- kill_engines(__context_engines_static(ctx));
+}
+
+static int engines_notify(struct i915_sw_fence *fence,
+ enum i915_sw_fence_notify state)
+{
+ struct i915_gem_engines *engines =
+ container_of(fence, typeof(*engines), fence);
+
+ switch (state) {
+ case FENCE_COMPLETE:
+ if (!list_empty(>link)) {
+ struct i915_gem_context *ctx = engines->ctx;
+ unsigned long flags;
+
+ spin_lock_irqsave(>stale.lock, flags);
+ list_del(>link);
+ spin_unlock_irqrestore(>stale.lock, flags);
+ }
+ break;
+
+ case FENCE_FREE:
+ i915_gem_context_put(engines->ctx);
+ init_rcu_head(>rcu);
+ call_rcu(>rcu, free_engines_rcu);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static void engines_idle_release(struct i915_gem_context *ctx,
+struct i915_gem_engines *engines)
+{
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ i915_sw_fence_init(>fence, engines_notify);
+ INIT_LIST_HEAD(>link);
+
+ engines->ctx = i915_gem_context_get(ctx);
+
+ for_each_gem_engine(ce, engines, it) {
+ int err = 0;
+
+ RCU_INIT_POINTER(ce->gem_context, NULL);
+
+ if (!ce->timeline) { /* XXX serialisation with execbuf? */
+ intel_context_set_banned(ce);
+ continue;
+ }
+
+ mutex_lock(>timeline->mutex);
+ if (!list_empty(>timeline->requests)) {
+ struct i915_request *rq;
+
+ rq = list_last_entry(>timeline->requests,
+typeof(*rq),
+link);
+
+ err = i915_sw_fence_await_dma_fence(>fence,
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Distribute switch variables for initialization
== Series Details ==
Series: drm/i915: Distribute switch variables for initialization
URL : https://patchwork.freedesktop.org/series/73690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7970 -> Patchwork_16641
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/index.html
Known issues
Here are the changes found in Patchwork_16641 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [PASS][1] -> [INCOMPLETE][2] ([i915#45])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
- fi-byt-n2820: [PASS][3] -> [INCOMPLETE][4] ([i915#45])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-guc: [PASS][5] -> [INCOMPLETE][6] ([fdo#108744])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([i915#585])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_chamelium@dp-edid-read:
- fi-cml-u2: [PASS][9] -> [FAIL][10] ([i915#217] / [i915#976])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [TIMEOUT][11] ([fdo#112271] / [i915#1084]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_execlists:
- {fi-tgl-dsi}: [INCOMPLETE][13] ([i915#529] / [i915#647]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gtt:
- fi-kbl-7500u: [TIMEOUT][15] ([fdo#112271]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
Warnings
* igt@runner@aborted:
- fi-byt-n2820: [FAIL][17] ([i915#999]) -> [FAIL][18] ([i915#816])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-byt-n2820/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16641/fi-byt-n2820/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#529]: https://gitlab.freedesktop.org/drm/intel/issues/529
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#647]: https://gitlab.freedesktop.org/drm/intel/issues/647
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976
[i915#999]: https://gitlab.freedesktop.org/drm/intel/issues/999
Participating hosts (48 -> 45)
--
Additional (4): fi-gdg-551 fi-bsw-nick fi-skl-6600u fi-snb-2600
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-kbl-7560u fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7970 -> Patchwork_16641
CI-20190529: 20190529
CI_DRM_7970: 6b8b833350142345f4b1a6af9486db7d316a7ff1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5452:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915/gt: Show the cumulative context runtime in engine debug (rev3)
== Series Details ==
Series: series starting with [1/6] drm/i915/gt: Show the cumulative context
runtime in engine debug (rev3)
URL : https://patchwork.freedesktop.org/series/73567/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7961_full -> Patchwork_16598_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16598_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16598_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_16598_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock_requests:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-tglb2/igt@i915_selftest@mock_requests.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-tglb3/igt@i915_selftest@mock_requests.html
* igt@perf@gen8-unprivileged-single-ctx-counters:
- shard-skl: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-skl5/igt@p...@gen8-unprivileged-single-ctx-counters.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-skl4/igt@p...@gen8-unprivileged-single-ctx-counters.html
- shard-iclb: [PASS][5] -> [INCOMPLETE][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-iclb5/igt@p...@gen8-unprivileged-single-ctx-counters.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-iclb3/igt@p...@gen8-unprivileged-single-ctx-counters.html
* igt@runner@aborted:
- shard-kbl: NOTRUN -> ([FAIL][7], [FAIL][8]) ([fdo#103665] /
[i915#873])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-kbl4/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-kbl3/igt@run...@aborted.html
- shard-apl: NOTRUN -> ([FAIL][9], [FAIL][10]) ([i915#873])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-apl6/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-apl7/igt@run...@aborted.html
Warnings
* igt@perf@gen12-mi-rpc:
- shard-tglb: [TIMEOUT][11] ([fdo#112271] / [i915#1085]) ->
[DMESG-FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-tglb6/igt@p...@gen12-mi-rpc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-tglb5/igt@p...@gen12-mi-rpc.html
* igt@runner@aborted:
- shard-tglb: [FAIL][13] ([i915#584]) -> ([FAIL][14], [FAIL][15])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-tglb2/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-tglb3/igt@run...@aborted.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-tglb1/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_ctx_persistence@close-replace-race}:
- shard-kbl: [FAIL][16] ([i915#1241]) -> [FAIL][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-kbl3/igt@gem_ctx_persiste...@close-replace-race.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-kbl6/igt@gem_ctx_persiste...@close-replace-race.html
- shard-glk: [FAIL][18] ([i915#1241]) -> [FAIL][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-glk7/igt@gem_ctx_persiste...@close-replace-race.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-glk2/igt@gem_ctx_persiste...@close-replace-race.html
Known issues
Here are the changes found in Patchwork_16598_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic-nohangcheck:
- shard-snb: [PASS][20] -> [FAIL][21] ([i915#1148])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-snb6/igt@gem_ctx_e...@basic-nohangcheck.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-snb5/igt@gem_ctx_e...@basic-nohangcheck.html
- shard-hsw: [PASS][22] -> [FAIL][23] ([i915#1148])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7961/shard-hsw7/igt@gem_ctx_e...@basic-nohangcheck.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16598/shard-hsw6/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][24] -> [SKIP][25] ([fdo#110841])
[24]:
[Intel-gfx] [PATCH] drm/i915: Distribute switch variables for initialization
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.
To avoid these problems, move such variables into the "case" where
they're used or lift them up into the main function body.
drivers/gpu/drm/i915/display/intel_display.c: In function
‘check_digital_port_conflicts’:
drivers/gpu/drm/i915/display/intel_display.c:12963:17: warning: statement will
never be executed [-Wswitch-unreachable]
12963 |unsigned int port_mask;
| ^
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_get_fifo_size’:
drivers/gpu/drm/i915/intel_pm.c:474:7: warning: statement will never be
executed [-Wswitch-unreachable]
474 | u32 dsparb, dsparb2, dsparb3;
| ^~
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_atomic_update_fifo’:
drivers/gpu/drm/i915/intel_pm.c:1997:7: warning: statement will never be
executed [-Wswitch-unreachable]
1997 | u32 dsparb, dsparb2, dsparb3;
| ^~
[1] https://bugs.llvm.org/show_bug.cgi?id=44916
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/display/intel_display.c |6 --
drivers/gpu/drm/i915/intel_pm.c |4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 064dd99bbc49..c829cd26f99e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12960,14 +12960,15 @@ static bool check_digital_port_conflicts(struct
intel_atomic_state *state)
WARN_ON(!connector_state->crtc);
switch (encoder->type) {
- unsigned int port_mask;
case INTEL_OUTPUT_DDI:
if (WARN_ON(!HAS_DDI(to_i915(dev
break;
/* else, fall through */
case INTEL_OUTPUT_DP:
case INTEL_OUTPUT_HDMI:
- case INTEL_OUTPUT_EDP:
+ case INTEL_OUTPUT_EDP: {
+ unsigned int port_mask;
+
port_mask = 1 << encoder->port;
/* the same port mustn't appear more than once */
@@ -12976,6 +12977,7 @@ static bool check_digital_port_conflicts(struct
intel_atomic_state *state)
used_ports |= port_mask;
break;
+ }
case INTEL_OUTPUT_DP_MST:
used_mst_ports |=
1 << encoder->port;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bd2d30ecc030..17d8833787c4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -469,9 +469,9 @@ static void vlv_get_fifo_size(struct intel_crtc_state
*crtc_state)
struct vlv_fifo_state *fifo_state = _state->wm.vlv.fifo_state;
enum pipe pipe = crtc->pipe;
int sprite0_start, sprite1_start;
+ u32 dsparb, dsparb2, dsparb3;
switch (pipe) {
- u32 dsparb, dsparb2, dsparb3;
case PIPE_A:
dsparb = I915_READ(DSPARB);
dsparb2 = I915_READ(DSPARB2);
@@ -1969,6 +1969,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
const struct vlv_fifo_state *fifo_state =
_state->wm.vlv.fifo_state;
int sprite0_start, sprite1_start, fifo_size;
+ u32 dsparb, dsparb2, dsparb3;
if (!crtc_state->fifo_changed)
return;
@@ -1994,7 +1995,6 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
spin_lock(>lock);
switch (crtc->pipe) {
- u32 dsparb, dsparb2, dsparb3;
case PIPE_A:
dsparb = intel_uncore_read_fw(uncore, DSPARB);
dsparb2 = intel_uncore_read_fw(uncore, DSPARB2);
___
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 [1/4] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details ==
Series: series starting with [1/4] drm/i915: Add mechanism to submit a context
WA on ring submission
URL : https://patchwork.freedesktop.org/series/73688/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7970 -> Patchwork_16640
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/index.html
Known issues
Here are the changes found in Patchwork_16640 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [PASS][1] -> [INCOMPLETE][2] ([i915#45])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([i915#585])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
Possible fixes
* igt@i915_selftest@live_execlists:
- {fi-tgl-dsi}: [INCOMPLETE][5] ([i915#529] / [i915#647]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gtt:
- fi-kbl-7500u: [TIMEOUT][7] ([fdo#112271]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
Warnings
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][9] ([fdo#109315] / [i915#585]) -> [SKIP][10]
([fdo#109315])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
* igt@runner@aborted:
- fi-byt-n2820: [FAIL][11] ([i915#999]) -> [FAIL][12] ([i915#816])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-byt-n2820/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/fi-byt-n2820/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#529]: https://gitlab.freedesktop.org/drm/intel/issues/529
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#647]: https://gitlab.freedesktop.org/drm/intel/issues/647
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#999]: https://gitlab.freedesktop.org/drm/intel/issues/999
Participating hosts (48 -> 39)
--
Additional (3): fi-gdg-551 fi-skl-6600u fi-snb-2600
Missing(12): fi-ilk-m540 fi-bsw-n3050 fi-byt-j1900 fi-hsw-4200u
fi-hsw-peppy fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-bsw-kefka fi-kbl-7560u
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7970 -> Patchwork_16640
CI-20190529: 20190529
CI_DRM_7970: 6b8b833350142345f4b1a6af9486db7d316a7ff1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5452: c05dc6cd816feb1cc518ce777ab3fd6c81893113 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16640: 2e93e87685a1aa49a5611a2fe26941d9d456a302 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2e93e87685a1 tidy
986254d23dbb fix
c85cf8225fe4 drm/i915/gen7: Clear all EU/L3 residual contexts
6fa7e7f3fc3a drm/i915: Add mechanism to submit a context WA on ring submission
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16640/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details == Series: series starting with [1/4] drm/i915: Add mechanism to submit a context WA on ring submission URL : https://patchwork.freedesktop.org/series/73688/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915: Add mechanism to submit a context WA on ring submission Okay! Commit: drm/i915/gen7: Clear all EU/L3 residual contexts +drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h:14:11: warning: symbol 'hsw_eu_kernel' was not declared. Should it be static? +drivers/gpu/drm/i915/gt/gen7_clearbuffer.h:14:11: warning: symbol 'ivb_eu_kernel' was not declared. Should it be static? Commit: fix Okay! Commit: tidy -O:drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h:14:11: warning: symbol 'hsw_eu_kernel' was not declared. Should it be static? -O:drivers/gpu/drm/i915/gt/gen7_clearbuffer.h:14:11: warning: symbol 'ivb_eu_kernel' was not declared. Should it be static? + ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details == Series: series starting with [1/4] drm/i915: Add mechanism to submit a context WA on ring submission URL : https://patchwork.freedesktop.org/series/73688/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6fa7e7f3fc3a drm/i915: Add mechanism to submit a context WA on ring submission c85cf8225fe4 drm/i915/gen7: Clear all EU/L3 residual contexts -:38: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #38: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 598 lines checked 986254d23dbb fix -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:51: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 38 lines checked 2e93e87685a1 tidy -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:47: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #47: rename from drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h -:100: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 2 warnings, 0 checks, 65 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2-resend] drm/i915/psr: Force PSR probe only after full initialization
On 2020-02-18 at 23:53:28 +0530, José Roberto de Souza wrote:
> Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR") was forcing the state compute too earlier
> causing errors because not everything was initialized, so here
> moving to i915_driver_register() when everything is ready and driver
> is registering into the rest of the system.
>
> Also fixing the place where it disarm the force probe as during the
> atomic check phase errors could happen like the ones due locking and
> it would cause PSR to never be enabled if that happens.
> Leaving the disarm to the atomic commit phase, intel_psr_enable() or
> intel_psr_update() will be called even if the current state do not
> allow PSR to be enabled.
Is it possible to having a psr state in intel crtc state to do this,
this can be used in future when will have dual psr display?
intel_psr_fastset_force() also forcing the fastset when psr mode
change from debugfs, may be intel_psr_force_mode_changed_set(true)
can get rid of that.
>
> v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
>
> Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute phase once to
> enable PSR")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
> Reported-by: Ross Zwisler
> Tested-by: Ross Zwisler
> Cc: Gwan-gyeong Mun
> Cc: Jani Nikula
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 18 --
> drivers/gpu/drm/i915/display/intel_psr.h | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 4 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b4942b6445ae..35bafd281deb 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -936,6 +936,8 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> + intel_psr_force_mode_changed_set(intel_dp, false);
> +
> if (!crtc_state->has_psr)
> return;
>
> @@ -1096,6 +1098,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
> struct i915_psr *psr = _priv->psr;
> bool enable, psr2_enable;
>
> + intel_psr_force_mode_changed_set(intel_dp, false);
> +
> if (!CAN_PSR(dev_priv) || READ_ONCE(psr->dp) != intel_dp)
> return;
>
> @@ -1629,7 +1633,7 @@ void intel_psr_atomic_check(struct drm_connector
> *connector,
> struct drm_crtc_state *crtc_state;
>
> if (!CAN_PSR(dev_priv) || !new_state->crtc ||
> - dev_priv->psr.initially_probed)
> + !dev_priv->psr.force_mode_changed)
> return;
>
> intel_connector = to_intel_connector(connector);
> @@ -1640,5 +1644,15 @@ void intel_psr_atomic_check(struct drm_connector
> *connector,
> crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> new_state->crtc);
> crtc_state->mode_changed = true;
> - dev_priv->psr.initially_probed = true;
> +}
> +
> +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp, bool set)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + if (!CAN_PSR(dev_priv) || !intel_dp || !intel_dp_is_edp(intel_dp) ||
> + intel_dp != dev_priv->psr.dp)
> + return;
> +
> + dev_priv->psr.force_mode_changed = set;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
> b/drivers/gpu/drm/i915/display/intel_psr.h
> index c58a1d438808..27a70468e2b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.h
> +++ b/drivers/gpu/drm/i915/display/intel_psr.h
> @@ -40,5 +40,6 @@ bool intel_psr_enabled(struct intel_dp *intel_dp);
> void intel_psr_atomic_check(struct drm_connector *connector,
> struct drm_connector_state *old_state,
> struct drm_connector_state *new_state);
> +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp, bool set);
>
> #endif /* __INTEL_PSR_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f7a1c33697b7..83791c197611 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -58,6 +58,7 @@
> #include "display/intel_hotplug.h"
> #include "display/intel_overlay.h"
> #include "display/intel_pipe_crc.h"
> +#include "display/intel_psr.h"
> #include "display/intel_sprite.h"
> #include "display/intel_vga.h"
>
> @@ -1256,6 +1257,8 @@ static void i915_driver_register(struct
> drm_i915_private *dev_priv)
>
> intel_audio_init(dev_priv);
>
> + intel_psr_force_mode_changed_set(dev_priv->psr.dp, true);
> +
> /*
>* Some ports require correctly set-up hpd registers for detection to
>* work properly (leading to ghost connected connector
[Intel-gfx] ✓ Fi.CI.BAT: success for Security mitigation for Intel Gen7/7.5 HWs
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73686/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7969 -> Patchwork_16639
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16639/index.html
Known issues
Here are the changes found in Patchwork_16639 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-icl-guc: [PASS][1] -> [DMESG-FAIL][2] ([fdo#108569])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7969/fi-icl-guc/igt@i915_selftest@live_execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16639/fi-icl-guc/igt@i915_selftest@live_execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
Participating hosts (42 -> 36)
--
Additional (6): fi-bdw-5557u fi-glk-dsi fi-ilk-650 fi-snb-2520m fi-cfl-8109u
fi-bsw-kefka
Missing(12): fi-hsw-4770r fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-cfl-8700k fi-cfl-guc fi-kbl-7500u fi-hsw-4770 fi-byt-n2820
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7969 -> Patchwork_16639
CI-20190529: 20190529
CI_DRM_7969: 9c7e7742ccb46cc82acf226367115763d50e9d42 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5452: c05dc6cd816feb1cc518ce777ab3fd6c81893113 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16639: d66eb25865a22d48b69a18d8f1367c13358160d5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d66eb25865a2 drm/i915/gen7: Clear all EU/L3 residual contexts
ffdac73cd979 drm/i915: Add mechanism to submit a context WA on ring submission
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16639/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Security mitigation for Intel Gen7/7.5 HWs
== Series Details == Series: Security mitigation for Intel Gen7/7.5 HWs URL : https://patchwork.freedesktop.org/series/73686/ State : warning == Summary == $ dim checkpatch origin/drm-tip ffdac73cd979 drm/i915: Add mechanism to submit a context WA on ring submission d66eb25865a2 drm/i915/gen7: Clear all EU/L3 residual contexts -:41: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #41: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 598 lines checked ___ 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: Donot reuse icl get and put dplls (rev2)
== Series Details ==
Series: drm/i915/ehl: Donot reuse icl get and put dplls (rev2)
URL : https://patchwork.freedesktop.org/series/73681/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7968 -> Patchwork_16638
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16638/index.html
Known issues
Here are the changes found in Patchwork_16638 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [PASS][1] -> [INCOMPLETE][2] ([i915#45])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7968/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16638/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([CI#80] / [fdo#106070]
/ [i915#424])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7968/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16638/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@i915_selftest@live_gem_contexts:
- fi-hsw-peppy: [DMESG-FAIL][5] ([i915#722]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7968/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16638/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- fi-bxt-dsi: [TIMEOUT][7] ([fdo#112271]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7968/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16638/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [INCOMPLETE][9] ([fdo#108569]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7968/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16638/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722
Participating hosts (51 -> 46)
--
Additional (1): fi-kbl-7560u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7968 -> Patchwork_16638
CI-20190529: 20190529
CI_DRM_7968: fbfd614e946dc8ba097ea684179eee70fb6e53ed @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5452: c05dc6cd816feb1cc518ce777ab3fd6c81893113 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16638: 093d71af9e3fa0560bfd27666d8f401daf67731d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
093d71af9e3f drm/i915/ehl: Donot reuse icl get and put dplls
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16638/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/ehl: Donot reuse icl get and put dplls (rev2)
== Series Details == Series: drm/i915/ehl: Donot reuse icl get and put dplls (rev2) URL : https://patchwork.freedesktop.org/series/73681/ State : warning == Summary == $ dim checkpatch origin/drm-tip 093d71af9e3f drm/i915/ehl: Donot reuse icl get and put dplls -:82: CHECK:LINE_SPACING: Please don't use multiple blank lines #82: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:3161: + + total: 0 errors, 0 warnings, 1 checks, 99 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/core-for-CI 18/21] init/Kconfig:77: symbol BROKEN is selected by DRM_I915_DEBUG
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: 2a97892fdbae277a104d6ba0b90f8a47cbe53681 commit: 0db409f2a5a4ec41dba541c21d6fa294c8a4dfd4 [18/21] Revert "drm/i915: Don't select BROKEN" config: powerpc-ksi8560_defconfig compiler: powerpc-linux-gcc (GCC) 7.5.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 0db409f2a5a4ec41dba541c21d6fa294c8a4dfd4 GCC_VERSION=7.5.0 make.cross ARCH=powerpc 85xx/ksi8560_defconfig GCC_VERSION=7.5.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> arch/powerpc/platforms/embedded6xx/Kconfig:2:error: recursive dependency >> detected! >> arch/powerpc/platforms/embedded6xx/Kconfig:2: symbol EMBEDDED6xx depends on >> BROKEN_ON_SMP >> init/Kconfig:80: symbol BROKEN_ON_SMP depends on BROKEN >> init/Kconfig:77: symbol BROKEN is selected by DRM_I915_DEBUG >> drivers/gpu/drm/i915/Kconfig.debug:19: symbol DRM_I915_DEBUG depends on >> DRM_I915 >> drivers/gpu/drm/i915/Kconfig:2: symbol DRM_I915 depends on DRM >> drivers/gpu/drm/Kconfig:8: symbol DRM depends on AGP >> drivers/char/agp/Kconfig:2: symbol AGP depends on PCI >> drivers/pci/Kconfig:16: symbol PCI depends on HAVE_PCI >> drivers/pci/Kconfig:7: symbol HAVE_PCI is selected by FORCE_PCI >> drivers/pci/Kconfig:11: symbol FORCE_PCI is selected by MVME5100 >> arch/powerpc/platforms/embedded6xx/Kconfig:51: symbol MVME5100 depends on >> EMBEDDED6xx For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" vim +77 init/Kconfig ^1da177e4c3f41 Linus Torvalds 2005-04-16 76 ^1da177e4c3f41 Linus Torvalds 2005-04-16 @77 config BROKEN ^1da177e4c3f41 Linus Torvalds 2005-04-16 78bool ^1da177e4c3f41 Linus Torvalds 2005-04-16 79 ^1da177e4c3f41 Linus Torvalds 2005-04-16 @80 config BROKEN_ON_SMP ^1da177e4c3f41 Linus Torvalds 2005-04-16 81bool ^1da177e4c3f41 Linus Torvalds 2005-04-16 82depends on BROKEN || !SMP ^1da177e4c3f41 Linus Torvalds 2005-04-16 83default y ^1da177e4c3f41 Linus Torvalds 2005-04-16 84 :: The code at line 77 was first introduced by commit :: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2 :: TO: Linus Torvalds :: CC: Linus Torvalds --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] tidy
---
drivers/gpu/drm/i915/gt/gen7_renderclear.c | 13 +++--
.../gt/{gen7_5_clearbuffer.h => hsw_clear_kernel.c} | 10 +-
.../gt/{gen7_clearbuffer.h => ivb_clear_kernel.c} | 10 +-
3 files changed, 9 insertions(+), 24 deletions(-)
rename drivers/gpu/drm/i915/gt/{gen7_5_clearbuffer.h => hsw_clear_kernel.c}
(93%)
rename drivers/gpu/drm/i915/gt/{gen7_clearbuffer.h => ivb_clear_kernel.c} (93%)
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index beeb2e82c6fe..adac4487d793 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -4,8 +4,6 @@
*/
#include "gen7_renderclear.h"
-#include "gen7_5_clearbuffer.h"
-#include "gen7_clearbuffer.h"
#include "i915_drv.h"
#include "intel_gpu_commands.h"
@@ -21,8 +19,11 @@ struct cb_kernel {
#define CB_KERNEL(name) { .data = (name), .size = sizeof(name) }
-static const struct cb_kernel cb_kernel_gen7 = CB_KERNEL(ivb_eu_kernel);
-static const struct cb_kernel cb_kernel_gen7_5 = CB_KERNEL(hsw_eu_kernel);
+#include "ivb_clear_kernel.c"
+static const struct cb_kernel cb_kernel_ivb = CB_KERNEL(ivb_clear_kernel);
+
+#include "hsw_clear_kernel.c"
+static const struct cb_kernel cb_kernel_hsw = CB_KERNEL(hsw_clear_kernel);
struct batch_chunk {
struct i915_vma *vma;
@@ -355,8 +356,8 @@ static void emit_batch(struct i915_vma * const vma,
interface_descriptor =
gen7_fill_interface_descriptor(, bv,
IS_HASWELL(i915) ?
- _kernel_gen7_5 :
- _kernel_gen7,
+ _kernel_hsw :
+ _kernel_ivb,
desc_count);
gen7_emit_pipeline_flush();
batch_add(, PIPELINE_SELECT | PIPELINE_SELECT_MEDIA);
diff --git a/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
b/drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
similarity index 93%
rename from drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
rename to drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
index 126e8133b951..3061de70a88a 100644
--- a/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
+++ b/drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
@@ -5,13 +5,7 @@
* Generate by: Intel-gpu-tools on Thu 13 Feb 2020 01:06:41 AM UTC
*/
-#ifndef __GEN7_5_CLEARBUFFER_H__
-#define __GEN7_5_CLEARBUFFER_H__
-
-#include
-
-/* Media CB Kernel for gen7.5 devices */
-const u32 hsw_eu_kernel[] = {
+static const u32 hsw_clear_kernel[] = {
0x0001, 0x26020128, 0x0024, 0x,
0x0040, 0x20280c21, 0x0028, 0x0001,
0x0110, 0x2c20, 0x002c, 0x,
@@ -65,5 +59,3 @@ const u32 hsw_eu_kernel[] = {
0x00010220, 0x34001c00, 0x1400, 0xffc0,
0x07600032, 0x2fa0, 0x008d0fe0, 0x8210,
};
-
-#endif /* __GEN7_5_CLEARBUFFER_H__ */
diff --git a/drivers/gpu/drm/i915/gt/gen7_clearbuffer.h
b/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
similarity index 93%
rename from drivers/gpu/drm/i915/gt/gen7_clearbuffer.h
rename to drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
index 524189d90ded..b1cd3479527e 100644
--- a/drivers/gpu/drm/i915/gt/gen7_clearbuffer.h
+++ b/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
@@ -5,13 +5,7 @@
* Generate by: Intel-gpu-tools on Thu 13 Feb 2020 01:05:56 AM UTC
*/
-#ifndef __GEN7_CLEARBUFFER_H__
-#define __GEN7_CLEARBUFFER_H__
-
-#include
-
-/* Media CB Kernel for gen7 devices */
-const u32 ivb_eu_kernel[] = {
+static const u32 ivb_clear_kernel[] = {
0x0001, 0x26020128, 0x0024, 0x,
0x0040, 0x20280c21, 0x0028, 0x0001,
0x0110, 0x2c20, 0x002c, 0x,
@@ -65,5 +59,3 @@ const u32 ivb_eu_kernel[] = {
0x00010220, 0x34001c00, 0x1400, 0xfff8,
0x07600032, 0x2fa0, 0x008d0fe0, 0x8210,
};
-
-#endif /* __GEN7_CLEARBUFFER_H__ */
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Add mechanism to submit a context WA on ring submission
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
v2: Update vm_alias params to point to correct address space "vm" due to
changes made in the patch "f21613797bae98773"
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 134 +-
1 file changed, 130 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index f70b903a98bc..593710558b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1360,7 +1360,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1435,7 +1437,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1550,13 +1552,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context->vm));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = >wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce->vm));
if (ret)
return ret;
@@ -1564,7 +1609,7 @@ static int switch_context(struct i915_request *rq)
if (ce->state) {
u32 flags;
- GEM_BUG_ON(rq->engine->id != RCS0);
+ GEM_BUG_ON(engine->id != RCS0);
/* For resource streamer on HSW+ and power context elsewhere */
BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
@@ -1576,7 +1621,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1585,6 +1630,20 @@ static int
[Intel-gfx] [PATCH 3/4] fix
---
drivers/gpu/drm/i915/gt/gen7_renderclear.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index 2c3aabc72b4e..beeb2e82c6fe 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -90,7 +90,7 @@ static u32 batch_addr(const struct batch_chunk *bc)
static void batch_add(struct batch_chunk *bc, const u32 d)
{
- GEM_DEBUG_WARN_ON((bc->end - bc->start) >= bc->max_items);
+ GEM_BUG_ON(bc->end - bc->start >= bc->max_items);
*bc->end++ = d;
}
@@ -154,11 +154,10 @@ static u32
gen7_fill_binding_table(struct batch_chunk *state,
const struct batch_vals *bv)
{
+ u32 surface_start = gen7_fill_surface_state(state, bv->batch_size, bv);
u32 *cs = batch_alloc_items(state, 32, 8);
u32 offset = batch_offset(state, cs);
- u32 surface_start;
- surface_start = gen7_fill_surface_state(state, bv->batch_size, bv);
*cs++ = surface_start - state->offset;
*cs++ = 0;
*cs++ = 0;
@@ -188,13 +187,16 @@ gen7_fill_interface_descriptor(struct batch_chunk *state,
const struct cb_kernel *kernel,
unsigned int count)
{
+ u32 kernel_offset =
+ gen7_fill_kernel_data(state, kernel->data, kernel->size);
+ u32 binding_table = gen7_fill_binding_table(state, bv);
u32 *cs = batch_alloc_items(state, 32, 8 * count);
u32 offset = batch_offset(state, cs);
- *cs++ = gen7_fill_kernel_data(state, kernel->data, kernel->size);
+ *cs++ = kernel_offset;
*cs++ = (1 << 7) | (1 << 13);
*cs++ = 0;
- *cs++ = (gen7_fill_binding_table(state, bv) - state->offset) | 1;
+ *cs++ = (binding_table - state->offset) | 1;
*cs++ = 0;
*cs++ = 0;
*cs++ = 0;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/gen7: Clear all EU/L3 residual contexts
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.
This security mitigation changes does not triggers any performance
regression. Performance is on par with current drm-tips.
v2: Add igt generated header file for CB kernel assembled with mesa tool
and addressed use of Kernel macro for ptr_align comment.
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h | 69 +++
drivers/gpu/drm/i915/gt/gen7_clearbuffer.h| 69 +++
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 399 ++
drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
7 files changed, 569 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
create mode 100644 drivers/gpu/drm/i915/gt/gen7_clearbuffer.h
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b314d44ded5e..ebe3a160f588 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+ gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
b/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
new file mode 100644
index ..126e8133b951
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ *
+ * Generate by: Intel-gpu-tools on Thu 13 Feb 2020 01:06:41 AM UTC
+ */
+
+#ifndef __GEN7_5_CLEARBUFFER_H__
+#define __GEN7_5_CLEARBUFFER_H__
+
+#include
+
+/* Media CB Kernel for gen7.5 devices */
+const u32 hsw_eu_kernel[] = {
+ 0x0001, 0x26020128, 0x0024, 0x,
+ 0x0040, 0x20280c21, 0x0028, 0x0001,
+ 0x0110, 0x2c20, 0x002c, 0x,
+ 0x00010220, 0x34001c00, 0x1400, 0x0160,
+ 0x0061, 0x20600061, 0x, 0x,
+ 0x0008, 0x20601c85, 0x0e00, 0x000c,
+ 0x0005, 0x20601ca5, 0x0060, 0x0001,
+ 0x0008, 0x20641c85, 0x0e00, 0x000d,
+ 0x0005, 0x20641ca5, 0x0064, 0x0003,
+ 0x0041, 0x207424a5, 0x0064, 0x0034,
+ 0x0040, 0x206014a5, 0x0060, 0x0074,
+ 0x0008, 0x20681c85, 0x0e00, 0x0008,
+ 0x0005, 0x20681ca5, 0x0068, 0x000f,
+ 0x0041, 0x20701ca5, 0x0060, 0x0010,
+ 0x0040, 0x206814a5, 0x0068, 0x0070,
+ 0x0061, 0x20a00061, 0x, 0x,
+ 0x0005, 0x206c1c85, 0x0e00, 0x0007,
+ 0x0041, 0x206c1ca5, 0x006c, 0x0004,
+ 0x0061, 0x20800021, 0x008d, 0x,
+ 0x0001, 0x20800021, 0x006c, 0x,
+ 0x0001, 0x20840021, 0x0068, 0x,
+ 0x0001, 0x20880061, 0x, 0x0003,
+ 0x0005, 0x208c0d21, 0x0086, 0x,
+ 0x05600032, 0x20a00fa1, 0x008d0080, 0x02190001,
+ 0x0040, 0x20a01ca5, 0x00a0, 0x0001,
+ 0x05600032, 0x20a00fa1, 0x008d0080, 0x040a8001,
+ 0x0240, 0x20281c21, 0x0028, 0x,
+ 0x00010220, 0x34001c00, 0x1400, 0xffe0,
+ 0x0001, 0x26020128, 0x0024, 0x,
+ 0x0001, 0x220010e4, 0x, 0x,
+ 0x0001, 0x220831ec, 0x, 0x007f007f,
+ 0x0061, 0x20400021, 0x008d, 0x,
+ 0x0061, 0x2fe00021, 0x008d, 0x,
+ 0x0021, 0x20400121, 0x00450020, 0x,
+ 0x0001, 0x20480061, 0x, 0x000f000f,
+ 0x0005, 0x204c0d21, 0x0046, 0xffef,
+ 0x0081, 0x20600061, 0x, 0x,
+ 0x0081, 0x20800061, 0x, 0x,
+ 0x0081, 0x20a00061, 0x, 0x,
+ 0x0081, 0x20c00061, 0x, 0x,
+ 0x0081, 0x20e00061, 0x, 0x,
+ 0x0081, 0x2161, 0x, 0x,
+ 0x0081, 0x21200061, 0x, 0x,
+ 0x0081, 0x21400061, 0x, 0x,
+ 0x05600032, 0x2fa0, 0x008d0040, 0x120a8000,
+ 0x0040, 0x20402d21,
[Intel-gfx] [PATCH v3 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
v2: Update vm_alias params to point to correct address space "vm" due to
changes made in the patch "f21613797bae98773"
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 134 +-
1 file changed, 130 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index f70b903a98bc..593710558b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1360,7 +1360,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1435,7 +1437,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1550,13 +1552,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context->vm));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = >wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce->vm));
if (ret)
return ret;
@@ -1564,7 +1609,7 @@ static int switch_context(struct i915_request *rq)
if (ce->state) {
u32 flags;
- GEM_BUG_ON(rq->engine->id != RCS0);
+ GEM_BUG_ON(engine->id != RCS0);
/* For resource streamer on HSW+ and power context elsewhere */
BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
@@ -1576,7 +1621,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1585,6 +1630,20 @@ static int
[Intel-gfx] [PATCH v3 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.
This security mitigation changes does not triggers any performance
regression. Performance is on par with current drm-tips.
v2: Add igt generated header file for CB kernel assembled with Mesa tool
and addressed use of Kernel macro for ptr_align comment.
v3: Resolve Sparse warnings with newly generated, and imported CB
kernel.
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h | 69 +++
drivers/gpu/drm/i915/gt/gen7_clearbuffer.h| 69 +++
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 399 ++
drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
7 files changed, 569 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
create mode 100644 drivers/gpu/drm/i915/gt/gen7_clearbuffer.h
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b314d44ded5e..ebe3a160f588 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+ gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
b/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
new file mode 100644
index ..a0d5e3b20caa
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ *
+ * Generated by: IGT Gpu Tools on Thu 20 Feb 2020 12:30:21 AM UTC
+ */
+
+#ifndef __GEN7_5_CLEARBUFFER_H__
+#define __GEN7_5_CLEARBUFFER_H__
+
+#include
+
+/* Media CB Kernel for gen7.5 devices */
+static const u32 hsw_eu_kernel[] = {
+ 0x0001, 0x26020128, 0x0024, 0x,
+ 0x0040, 0x20280c21, 0x0028, 0x0001,
+ 0x0110, 0x2c20, 0x002c, 0x,
+ 0x00010220, 0x34001c00, 0x1400, 0x0160,
+ 0x0061, 0x20600061, 0x, 0x,
+ 0x0008, 0x20601c85, 0x0e00, 0x000c,
+ 0x0005, 0x20601ca5, 0x0060, 0x0001,
+ 0x0008, 0x20641c85, 0x0e00, 0x000d,
+ 0x0005, 0x20641ca5, 0x0064, 0x0003,
+ 0x0041, 0x207424a5, 0x0064, 0x0034,
+ 0x0040, 0x206014a5, 0x0060, 0x0074,
+ 0x0008, 0x20681c85, 0x0e00, 0x0008,
+ 0x0005, 0x20681ca5, 0x0068, 0x000f,
+ 0x0041, 0x20701ca5, 0x0060, 0x0010,
+ 0x0040, 0x206814a5, 0x0068, 0x0070,
+ 0x0061, 0x20a00061, 0x, 0x,
+ 0x0005, 0x206c1c85, 0x0e00, 0x0007,
+ 0x0041, 0x206c1ca5, 0x006c, 0x0004,
+ 0x0061, 0x20800021, 0x008d, 0x,
+ 0x0001, 0x20800021, 0x006c, 0x,
+ 0x0001, 0x20840021, 0x0068, 0x,
+ 0x0001, 0x20880061, 0x, 0x0003,
+ 0x0005, 0x208c0d21, 0x0086, 0x,
+ 0x05600032, 0x20a00fa1, 0x008d0080, 0x02190001,
+ 0x0040, 0x20a01ca5, 0x00a0, 0x0001,
+ 0x05600032, 0x20a00fa1, 0x008d0080, 0x040a8001,
+ 0x0240, 0x20281c21, 0x0028, 0x,
+ 0x00010220, 0x34001c00, 0x1400, 0xffe0,
+ 0x0001, 0x26020128, 0x0024, 0x,
+ 0x0001, 0x220010e4, 0x, 0x,
+ 0x0001, 0x220831ec, 0x, 0x007f007f,
+ 0x0061, 0x20400021, 0x008d, 0x,
+ 0x0061, 0x2fe00021, 0x008d, 0x,
+ 0x0021, 0x20400121, 0x00450020, 0x,
+ 0x0001, 0x20480061, 0x, 0x000f000f,
+ 0x0005, 0x204c0d21, 0x0046, 0xffef,
+ 0x0081, 0x20600061, 0x, 0x,
+ 0x0081, 0x20800061, 0x, 0x,
+ 0x0081, 0x20a00061, 0x, 0x,
+ 0x0081, 0x20c00061, 0x, 0x,
+ 0x0081, 0x20e00061, 0x, 0x,
+ 0x0081, 0x2161, 0x, 0x,
+ 0x0081, 0x21200061, 0x, 0x,
+ 0x0081, 0x21400061, 0x, 0x,
+
[Intel-gfx] [PATCH v3 0/2] Security mitigation for Intel Gen7/7.5 HWs
Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access Products affected: -- Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics. Mitigation Summary -- This patch provides mitigation for Gen7 and Gen7.5 hardware only. Patch for Gen9 devices have been provided and merged to Linux mainline, and backported to stable kernels. Note that Gen8 is not impacted due to a previously implemented workaround. The mitigation involves submitting a custom EU kernel prior to every context restore, in order to forcibly clear down residual EU and URB resources. The custom EU kernel are generated/assembled automatically, using Mesa (an open source tool) and IGT GPU tool - assembly sources are provided with IGT source code. This security mitigation change does not trigger any known performance regression. Performance is on par with current mainline/drm-tip. Note on Address Space Isolation (Full PPGTT) Isolation of EU kernel assets should be considered complementary to the existing support for address space isolation (aka Full PPGTT), since without address space isolation there is minimal value in preventing leakage between EU contexts. Full PPGTT has long been supported on Gen Gfx devices since Gen8, and protection against EU residual leakage is a welcome addition for these newer platforms. By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only as a hardware development feature for anticipated Gen8 productization. Support was never intended for, or provided to the Linux kernels for these platforms. Recent work (still ongoing) to the mainline kernel is retroactively providing this support, but due to the level of complexity it is not practical to attempt to backport this to earlier stable kernels. Since without Full PPGTT, EU residuals protection has questionable benefit, *there are no plans to provide stable kernel backports for this patch series.* Mika Kuoppala (1): drm/i915: Add mechanism to submit a context WA on ring submission Prathap Kumar Valsan (1): drm/i915/gen7: Clear all EU/L3 residual contexts drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h | 69 +++ drivers/gpu/drm/i915/gt/gen7_clearbuffer.h| 69 +++ drivers/gpu/drm/i915/gt/gen7_renderclear.c| 399 ++ drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 135 +- 7 files changed, 698 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h create mode 100644 drivers/gpu/drm/i915/gt/gen7_clearbuffer.h create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h -- 2.20.1 ___ 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/hotplug: Use phy to get the hpd_pin instead of the port (rev4)
== Series Details == Series: drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev4) URL : https://patchwork.freedesktop.org/series/72747/ State : success == Summary == CI Bug Log - changes from CI_DRM_7967 -> Patchwork_16637 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16637/index.html Known issues Here are the changes found in Patchwork_16637 that come from known issues: ### IGT changes ### Issues hit * igt@gem_close_race@basic-threads: - fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16637/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html * igt@i915_selftest@live_gem_contexts: - fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([CI#80] / [fdo#106070] / [i915#424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16637/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html * igt@i915_selftest@live_gtt: - fi-icl-dsi: [PASS][5] -> [TIMEOUT][6] ([fdo#112271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-icl-dsi/igt@i915_selftest@live_gtt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16637/fi-icl-dsi/igt@i915_selftest@live_gtt.html Possible fixes * igt@i915_selftest@live_blt: - fi-ivb-3770:[DMESG-FAIL][7] ([i915#725]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-ivb-3770/igt@i915_selftest@live_blt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16637/fi-ivb-3770/igt@i915_selftest@live_blt.html * igt@kms_chamelium@dp-edid-read: - fi-cml-u2: [FAIL][9] ([i915#976]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16637/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80 [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725 [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (49 -> 40) -- Additional (2): fi-bwr-2160 fi-bsw-nick Missing(11): fi-ilk-m540 fi-tgl-dsi fi-hsw-4200u fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-8109u fi-byt-n2820 fi-bdw-samus fi-kbl-r Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7967 -> Patchwork_16637 CI-20190529: 20190529 CI_DRM_7967: 0d3c3511d707cc46d78ffcf7fe39ac882c0030af @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5452: c05dc6cd816feb1cc518ce777ab3fd6c81893113 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16637: e755f16ff5e05125fd8f3e16d68e81b002034273 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e755f16ff5e0 drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v3) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16637/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/ehl: Donot reuse icl get and put dplls
Elkhartlake does not have as many PLL combinations as Icelake.
Use a simpler get pll function and reuse intel_put_pll for ehl.
v2: Fix the build error
Suggested-by: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +++-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 57 +++
2 files changed, 54 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee7d54ccd3e6..9bb6ccb5b3ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10763,10 +10763,15 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
return;
}
- pipe_config->icl_port_dplls[port_dpll_id].pll =
- intel_get_shared_dpll_by_id(dev_priv, id);
+ if (!IS_ELKHARTLAKE(dev_priv)) {
+ pipe_config->icl_port_dplls[port_dpll_id].pll =
+ intel_get_shared_dpll_by_id(dev_priv, id);
- icl_set_active_port_dpll(pipe_config, port_dpll_id);
+ icl_set_active_port_dpll(pipe_config, port_dpll_id);
+ } else {
+ pipe_config->shared_dpll =
+ intel_get_shared_dpll_by_id(dev_priv, id);
+ }
}
static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index e5bfe5245276..6092abc2b875 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3016,8 +3016,7 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct icl_port_dpll *port_dpll =
_state->icl_port_dplls[ICL_PORT_DPLL_DEFAULT];
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum port port = encoder->port;
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
unsigned long dpll_mask;
if (!icl_calc_dpll_state(crtc_state, encoder, _dpll->hw_state)) {
@@ -3027,13 +3026,7 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
return false;
}
- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
- dpll_mask =
- BIT(DPLL_ID_EHL_DPLL4) |
- BIT(DPLL_ID_ICL_DPLL1) |
- BIT(DPLL_ID_ICL_DPLL0);
- else
- dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
port_dpll->pll = intel_find_shared_dpll(state, crtc,
_dpll->hw_state,
@@ -3154,6 +3147,48 @@ static void icl_put_dplls(struct intel_atomic_state
*state,
}
}
+static bool ehl_get_dpll(struct intel_atomic_state *state,
+struct intel_crtc *crtc,
+struct intel_encoder *encoder)
+{
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ struct intel_shared_dpll *pll;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum port port = encoder->port;
+ unsigned long dpll_mask;
+
+
+ if (!icl_calc_dpll_state(crtc_state, encoder,
_state->dpll_hw_state)) {
+ DRM_DEBUG_KMS("Could not calculate combo PHY PLL state.\n");
+
+ return false;
+ }
+
+ if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
+ dpll_mask =
+ BIT(DPLL_ID_EHL_DPLL4) |
+ BIT(DPLL_ID_ICL_DPLL1) |
+ BIT(DPLL_ID_ICL_DPLL0);
+ else
+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+
+ pll = intel_find_shared_dpll(state, crtc,
+_state->dpll_hw_state,
+dpll_mask);
+ if (!pll) {
+ DRM_DEBUG_KMS("No PLL selected\n");
+ return false;
+ }
+
+ intel_reference_shared_dpll(state, crtc,
+ pll, _state->dpll_hw_state);
+
+ crtc_state->shared_dpll = pll;
+
+ return true;
+}
+
static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
struct intel_dpll_hw_state *hw_state)
@@ -3751,8 +3786,8 @@ static const struct dpll_info ehl_plls[] = {
static const struct intel_dpll_mgr ehl_pll_mgr = {
.dpll_info = ehl_plls,
- .get_dplls = icl_get_dplls,
- .put_dplls = icl_put_dplls,
+ .get_dplls = ehl_get_dpll,
+ .put_dplls = intel_put_dpll,
.dump_hw_state = icl_dump_hw_state,
};
--
2.20.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Add Wa_22010178259:tgl (rev2)
== Series Details ==
Series: drm/i915/tgl: Add Wa_22010178259:tgl (rev2)
URL : https://patchwork.freedesktop.org/series/73255/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7967 -> Patchwork_16634
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16634/index.html
Known issues
Here are the changes found in Patchwork_16634 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [FAIL][1] ([i915#694]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16634/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [DMESG-FAIL][3] ([i915#1052]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16634/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][5] ([i915#585]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16634/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_chamelium@dp-edid-read:
- fi-cml-u2: [FAIL][7] ([i915#976]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16634/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
Warnings
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][9] ([fdo#109315]) -> [SKIP][10] ([fdo#109315]
/ [i915#585])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16634/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976
Participating hosts (49 -> 38)
--
Additional (1): fi-bsw-nick
Missing(12): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-kbl-7500u fi-ctg-p8600 fi-gdg-551 fi-ivb-3770 fi-bsw-kefka
fi-skl-lmem fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7967 -> Patchwork_16634
CI-20190529: 20190529
CI_DRM_7967: 0d3c3511d707cc46d78ffcf7fe39ac882c0030af @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5452: c05dc6cd816feb1cc518ce777ab3fd6c81893113 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16634: 432a7f4dd272a8a0dee928428627301f2a7bb7f7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
432a7f4dd272 drm/i915/tgl: Add Wa_22010178259:tgl
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16634/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/ehl: Donot reuse icl get and put dplls
== Series Details == Series: drm/i915/ehl: Donot reuse icl get and put dplls URL : https://patchwork.freedesktop.org/series/73681/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/display/intel_dpll_mgr.o In file included from ./include/drm/drm_mm.h:49:0, from ./include/drm/drm_vma_manager.h:26, from ./include/drm/drm_gem.h:40, from ./drivers/gpu/drm/i915/i915_drv.h:53, from drivers/gpu/drm/i915/display/intel_display_types.h:46, from drivers/gpu/drm/i915/display/intel_dpll_mgr.c:24: drivers/gpu/drm/i915/display/intel_dpll_mgr.c: In function ‘icl_get_combo_phy_dpll’: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:3022:16: error: ‘dev_priv’ undeclared (first use in this function); did you mean ‘dev_crit’? drm_dbg_kms(_priv->drm, ^ ./include/drm/drm_print.h:432:15: note: in definition of macro ‘drm_dbg_kms’ drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__) ^~~ drivers/gpu/drm/i915/display/intel_dpll_mgr.c:3022:16: note: each undeclared identifier is reported only once for each function it appears in drm_dbg_kms(_priv->drm, ^ ./include/drm/drm_print.h:432:15: note: in definition of macro ‘drm_dbg_kms’ drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__) ^~~ scripts/Makefile.build:267: recipe for target 'drivers/gpu/drm/i915/display/intel_dpll_mgr.o' failed make[4]: *** [drivers/gpu/drm/i915/display/intel_dpll_mgr.o] Error 1 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1681: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/tgl: add Wa_1409085225, Wa_14010229206
== Series Details == Series: drm/i915/tgl: add Wa_1409085225, Wa_14010229206 URL : https://patchwork.freedesktop.org/series/73679/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gt/intel_workarounds.o drivers/gpu/drm/i915/gt/intel_workarounds.c: In function ‘tgl_ctx_workarounds_init’: drivers/gpu/drm/i915/gt/intel_workarounds.c:583:27: error: unused variable ‘i915’ [-Werror=unused-variable] struct drm_i915_private *i915 = engine->i915; ^~~~ cc1: all warnings being treated as errors scripts/Makefile.build:267: recipe for target 'drivers/gpu/drm/i915/gt/intel_workarounds.o' failed make[4]: *** [drivers/gpu/drm/i915/gt/intel_workarounds.o] Error 1 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1681: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ 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/gt: Protect signaler walk with RCU (rev2)
== Series Details ==
Series: drm/i915/gt: Protect signaler walk with RCU (rev2)
URL : https://patchwork.freedesktop.org/series/73601/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7967 -> Patchwork_16633
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/index.html
Known issues
Here are the changes found in Patchwork_16633 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [PASS][1] -> [INCOMPLETE][2] ([i915#424])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [FAIL][3] ([i915#694]) -> [PASS][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
* igt@i915_selftest@live_blt:
- fi-ivb-3770:[DMESG-FAIL][5] ([i915#725]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-ivb-3770/igt@i915_selftest@live_blt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/fi-ivb-3770/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [DMESG-FAIL][7] ([i915#1052]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@dp-edid-read:
- fi-cml-u2: [FAIL][9] ([i915#976]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
Warnings
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [INCOMPLETE][11] ([i915#45]) -> [TIMEOUT][12]
([fdo#112271] / [i915#1084] / [i915#816])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7967/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976
Participating hosts (49 -> 45)
--
Additional (2): fi-bwr-2160 fi-bsw-nick
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7967 -> Patchwork_16633
CI-20190529: 20190529
CI_DRM_7967: 0d3c3511d707cc46d78ffcf7fe39ac882c0030af @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5452: c05dc6cd816feb1cc518ce777ab3fd6c81893113 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16633: 13adcd1e3f54b2ecff48acd425222a159633cad3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
13adcd1e3f54 drm/i915/gt: Protect signaler walk with RCU
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16633/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ehl: Donot reuse icl get and put dplls
Elkhartlake does not have as many PLL combinations as Icelake.
Use a simpler get pll function and reuse intel_put_pll for ehl.
Suggested-by: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +++-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 56 +++
2 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee7d54ccd3e6..9bb6ccb5b3ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10763,10 +10763,15 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
return;
}
- pipe_config->icl_port_dplls[port_dpll_id].pll =
- intel_get_shared_dpll_by_id(dev_priv, id);
+ if (!IS_ELKHARTLAKE(dev_priv)) {
+ pipe_config->icl_port_dplls[port_dpll_id].pll =
+ intel_get_shared_dpll_by_id(dev_priv, id);
- icl_set_active_port_dpll(pipe_config, port_dpll_id);
+ icl_set_active_port_dpll(pipe_config, port_dpll_id);
+ } else {
+ pipe_config->shared_dpll =
+ intel_get_shared_dpll_by_id(dev_priv, id);
+ }
}
static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index e5bfe5245276..6d79547433f5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3016,8 +3016,6 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct icl_port_dpll *port_dpll =
_state->icl_port_dplls[ICL_PORT_DPLL_DEFAULT];
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum port port = encoder->port;
unsigned long dpll_mask;
if (!icl_calc_dpll_state(crtc_state, encoder, _dpll->hw_state)) {
@@ -3027,13 +3025,7 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
return false;
}
- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
- dpll_mask =
- BIT(DPLL_ID_EHL_DPLL4) |
- BIT(DPLL_ID_ICL_DPLL1) |
- BIT(DPLL_ID_ICL_DPLL0);
- else
- dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
port_dpll->pll = intel_find_shared_dpll(state, crtc,
_dpll->hw_state,
@@ -3154,6 +3146,48 @@ static void icl_put_dplls(struct intel_atomic_state
*state,
}
}
+static bool ehl_get_dpll(struct intel_atomic_state *state,
+struct intel_crtc *crtc,
+struct intel_encoder *encoder)
+{
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ struct intel_shared_dpll *pll;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum port port = encoder->port;
+ unsigned long dpll_mask;
+
+
+ if (!icl_calc_dpll_state(crtc_state, encoder,
_state->dpll_hw_state)) {
+ DRM_DEBUG_KMS("Could not calculate combo PHY PLL state.\n");
+
+ return false;
+ }
+
+ if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
+ dpll_mask =
+ BIT(DPLL_ID_EHL_DPLL4) |
+ BIT(DPLL_ID_ICL_DPLL1) |
+ BIT(DPLL_ID_ICL_DPLL0);
+ else
+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+
+ pll = intel_find_shared_dpll(state, crtc,
+_state->dpll_hw_state,
+dpll_mask);
+ if (!pll) {
+ DRM_DEBUG_KMS("No PLL selected\n");
+ return false;
+ }
+
+ intel_reference_shared_dpll(state, crtc,
+ pll, _state->dpll_hw_state);
+
+ crtc_state->shared_dpll = pll;
+
+ return true;
+}
+
static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
struct intel_dpll_hw_state *hw_state)
@@ -3751,8 +3785,8 @@ static const struct dpll_info ehl_plls[] = {
static const struct intel_dpll_mgr ehl_pll_mgr = {
.dpll_info = ehl_plls,
- .get_dplls = icl_get_dplls,
- .put_dplls = icl_put_dplls,
+ .get_dplls = ehl_get_dpll,
+ .put_dplls = intel_put_dpll,
.dump_hw_state = icl_dump_hw_state,
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/i915/tgl: add Wa_1409085225, Wa_14010229206
On Wed, Feb 19, 2020 at 02:05:29PM -0500, Matt Atwood wrote:
> Disable Push Constant buffer addition, which can cause FIFO
> underruns.
>
> Fix a minor white space issue while we're here.
>
> v2: typos, add additional Wa reference
>
> Bspec: 52890
> Cc: Rafael Antognolli
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 887e0dc701f7..0681e64be741 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -580,6 +580,7 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
>struct i915_wa_list *wal)
According to bspec page 46255, this register isn't part of the TGL
context image, so ctx_workarounds_init isn't the right place to handle
this. The next question is whether this is a general GT workaround or a
specific engine workaround...in this case, 0xE48C falls in one of the
render engine forcewake ranges (0xE000-0xE8FF -- see bspec page 52078)
so rcs_engine_wa_init() is where we'd actually want to take care of
this. That will ensure that the workaround gets re-applied when we
reset the render engine without doing a full GPU reset.
> {
> + struct drm_i915_private *i915 = engine->i915;
> u32 val;
>
> /* Wa_1409142259:tgl */
> @@ -590,6 +591,7 @@ static void tgl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> val = intel_uncore_read(engine->uncore, FF_MODE2);
> val &= ~FF_MODE2_TDS_TIMER_MASK;
> val |= FF_MODE2_TDS_TIMER_128;
> +
> /*
>* FIXME: FF_MODE2 register is not readable till TGL B0. We can
>* enable verification of WA from the later steppings, which enables
> @@ -598,6 +600,13 @@ static void tgl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val,
> IS_TGL_REVID(engine->i915, TGL_REVID_A0, TGL_REVID_A0) ? 0 :
> FF_MODE2_TDS_TIMER_MASK);
> +
> + /*
> + * Wa_1409085225:tgl
> + * Wa_14010229206:tgl
> + * Push Constant Buffer can cause FIFO underruns on tgl
The description in the bspec says that it can cause an overflow rather
than an underrun.
Actually, I'm not sure whether it's worth even mentioning this here
since the things that's overflowing isn't something that our kernel
driver has any direct interaction with. I.e., this FIFO is completely
different than the display FIFO that underruns when we have watermark
issues.
> + */
> + WA_SET_BIT_MASKED(GEN9_ROW_CHICKEN4, GEN12_DISABLE_TDL_PUSH);
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b09c1d6dc0aa..70cbe576fdfa 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9153,6 +9153,9 @@ enum {
> #define PUSH_CONSTANT_DEREF_DISABLE(1 << 8)
> #define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
>
> +#define GEN9_ROW_CHICKEN4_MMIO(0xe48c)
> +#define GEN12_DISABLE_TDL_PUSH (1 << 9)
Even though many of the registers in this area of the file use the old
form, the preferred style for new registers is to use REG_BIT(9). See
the comments at the top of the file for details.
Matt
> +
> #define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
> #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
>
> --
> 2.21.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: add Wa_1409085225, Wa_14010229206
Disable Push Constant buffer addition, which can cause FIFO
underruns.
Fix a minor white space issue while we're here.
v2: typos, add additional Wa reference
Bspec: 52890
Cc: Rafael Antognolli
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 887e0dc701f7..0681e64be741 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -580,6 +580,7 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs
*engine,
static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
{
+ struct drm_i915_private *i915 = engine->i915;
u32 val;
/* Wa_1409142259:tgl */
@@ -590,6 +591,7 @@ static void tgl_ctx_workarounds_init(struct intel_engine_cs
*engine,
val = intel_uncore_read(engine->uncore, FF_MODE2);
val &= ~FF_MODE2_TDS_TIMER_MASK;
val |= FF_MODE2_TDS_TIMER_128;
+
/*
* FIXME: FF_MODE2 register is not readable till TGL B0. We can
* enable verification of WA from the later steppings, which enables
@@ -598,6 +600,13 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val,
IS_TGL_REVID(engine->i915, TGL_REVID_A0, TGL_REVID_A0) ? 0 :
FF_MODE2_TDS_TIMER_MASK);
+
+ /*
+* Wa_1409085225:tgl
+* Wa_14010229206:tgl
+* Push Constant Buffer can cause FIFO underruns on tgl
+*/
+ WA_SET_BIT_MASKED(GEN9_ROW_CHICKEN4, GEN12_DISABLE_TDL_PUSH);
}
static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b09c1d6dc0aa..70cbe576fdfa 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9153,6 +9153,9 @@ enum {
#define PUSH_CONSTANT_DEREF_DISABLE (1 << 8)
#define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
+#define GEN9_ROW_CHICKEN4 _MMIO(0xe48c)
+#define GEN12_DISABLE_TDL_PUSH(1 << 9)
+
#define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
#define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
--
2.21.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/tgl: Add Wa_22010178259:tgl
On Wed, 2020-02-19 at 13:56 -0800, Matt Roper wrote:
> We need to explicitly set the TLB Request Timer initial value in the
> BW_BUDDY registers to 0x8 rather than relying on the hardware
> default.
>
> v2: Apply missing REG_FIELD_PREP to ensure 0x8 is placed in the
> correct
> bits during the rmw. (Jose)
>
> Bspec: 52890
> Bspec: 50044
Reviewed-by: José Roberto de Souza
> Cc: Stanislav Lisovskiy
> Cc: José Roberto de Souza
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 8
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 0d94fe01be7f..8ba68ec6dc24 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -5003,6 +5003,14 @@ static void tgl_bw_buddy_init(struct
> drm_i915_private *dev_priv)
> table[i].page_mask);
> intel_de_write(dev_priv, BW_BUDDY2_PAGE_MASK,
> table[i].page_mask);
> +
> + /* Wa_22010178259:tgl */
> + intel_de_rmw(dev_priv, BW_BUDDY1_CTL,
> + BW_BUDDY_TLB_REQ_TIMER_MASK,
> + REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK
> , 0x8));
> + intel_de_rmw(dev_priv, BW_BUDDY2_CTL,
> + BW_BUDDY_TLB_REQ_TIMER_MASK,
> + REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK
> , 0x8));
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index a6847f26678c..d829b9ae8402 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7766,6 +7766,7 @@ enum {
> #define BW_BUDDY1_CTL_MMIO(0x45140)
> #define BW_BUDDY2_CTL_MMIO(0x45150)
> #define BW_BUDDY_DISABLE REG_BIT(31)
> +#define BW_BUDDY_TLB_REQ_TIMER_MASKREG_GENMASK(21, 16)
>
> #define BW_BUDDY1_PAGE_MASK _MMIO(0x45144)
> #define BW_BUDDY2_PAGE_MASK _MMIO(0x45154)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/tgl: Add Wa_22010178259:tgl
We need to explicitly set the TLB Request Timer initial value in the
BW_BUDDY registers to 0x8 rather than relying on the hardware default.
v2: Apply missing REG_FIELD_PREP to ensure 0x8 is placed in the correct
bits during the rmw. (Jose)
Bspec: 52890
Bspec: 50044
Cc: Stanislav Lisovskiy
Cc: José Roberto de Souza
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display_power.c | 8
drivers/gpu/drm/i915/i915_reg.h| 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0d94fe01be7f..8ba68ec6dc24 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5003,6 +5003,14 @@ static void tgl_bw_buddy_init(struct drm_i915_private
*dev_priv)
table[i].page_mask);
intel_de_write(dev_priv, BW_BUDDY2_PAGE_MASK,
table[i].page_mask);
+
+ /* Wa_22010178259:tgl */
+ intel_de_rmw(dev_priv, BW_BUDDY1_CTL,
+BW_BUDDY_TLB_REQ_TIMER_MASK,
+REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
+ intel_de_rmw(dev_priv, BW_BUDDY2_CTL,
+BW_BUDDY_TLB_REQ_TIMER_MASK,
+REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a6847f26678c..d829b9ae8402 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7766,6 +7766,7 @@ enum {
#define BW_BUDDY1_CTL _MMIO(0x45140)
#define BW_BUDDY2_CTL _MMIO(0x45150)
#define BW_BUDDY_DISABLE REG_BIT(31)
+#define BW_BUDDY_TLB_REQ_TIMER_MASK REG_GENMASK(21, 16)
#define BW_BUDDY1_PAGE_MASK_MMIO(0x45144)
#define BW_BUDDY2_PAGE_MASK_MMIO(0x45154)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: Protect signaler walk with RCU
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the list_del_rcu.
v2: Mark the deps as safe-for-rcu
Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new
waiters")
Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
requests")
Signed-off-by: Chris Wilson
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 7 ---
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ba31cbe8c68e..47561dc29304 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1668,9 +1668,9 @@ last_active(const struct intel_engine_execlists
*execlists)
wait_link)
#define for_each_signaler(p__, rq__) \
- list_for_each_entry_lockless(p__, \
-&(rq__)->sched.signalers_list, \
-signal_link)
+ list_for_each_entry_rcu(p__, \
+ &(rq__)->sched.signalers_list, \
+ signal_link)
static void defer_request(struct i915_request *rq, struct list_head * const pl)
{
@@ -2533,11 +2533,13 @@ static bool execlists_hold(struct intel_engine_cs
*engine,
static bool hold_request(const struct i915_request *rq)
{
struct i915_dependency *p;
+ bool result = false;
/*
* If one of our ancestors is on hold, we must also be on hold,
* otherwise we will bypass it and execute before it.
*/
+ rcu_read_lock();
for_each_signaler(p, rq) {
const struct i915_request *s =
container_of(p->signaler, typeof(*s), sched);
@@ -2545,11 +2547,13 @@ static bool hold_request(const struct i915_request *rq)
if (s->engine != rq->engine)
continue;
- if (i915_request_on_hold(s))
- return true;
+ result = i915_request_on_hold(s);
+ if (result)
+ break;
}
+ rcu_read_unlock();
- return false;
+ return result;
}
static void __execlists_unhold(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index e19a37a83397..59f70b674665 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -486,7 +486,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
list_for_each_entry_safe(dep, tmp, >signalers_list, signal_link) {
GEM_BUG_ON(!list_empty(>dfs_link));
- list_del(>wait_link);
+ list_del_rcu(>wait_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
GEM_BUG_ON(dep->signaler != node);
GEM_BUG_ON(!list_empty(>dfs_link));
- list_del(>signal_link);
+ list_del_rcu(>signal_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -526,7 +526,8 @@ static struct i915_global_scheduler global = { {
int __init i915_global_scheduler_init(void)
{
global.slab_dependencies = KMEM_CACHE(i915_dependency,
- SLAB_HWCACHE_ALIGN);
+ SLAB_HWCACHE_ALIGN |
+ SLAB_TYPESAFE_BY_RCU);
if (!global.slab_dependencies)
return -ENOMEM;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Adding YUV444 packed format support for skl+ (rev3)
== Series Details ==
Series: Adding YUV444 packed format support for skl+ (rev3)
URL : https://patchwork.freedesktop.org/series/73020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16632
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/index.html
Known issues
Here are the changes found in Patchwork_16632 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [PASS][1] -> [INCOMPLETE][2] ([i915#45])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
Possible fixes
* igt@amdgpu/amd_prime@i915-to-amd:
- fi-kbl-8809g: [DMESG-WARN][3] ([i915#1209]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-kbl-8809g/igt@amdgpu/amd_pr...@i915-to-amd.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/fi-kbl-8809g/igt@amdgpu/amd_pr...@i915-to-amd.html
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [INCOMPLETE][5] ([i915#694] / [i915#816]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
- fi-byt-j1900: [INCOMPLETE][7] ([i915#45]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_gtt:
- fi-glk-dsi: [TIMEOUT][9] ([fdo#112271] / [i915#690]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-glk-dsi/igt@i915_selftest@live_gtt.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/fi-glk-dsi/igt@i915_selftest@live_gtt.html
Warnings
* igt@kms_chamelium@dp-hpd-fast:
- fi-icl-u3: [SKIP][11] ([fdo#109284] / [fdo#111827] / [i915#585])
-> [SKIP][12] ([fdo#109284] / [fdo#111827])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@kms_chamel...@dp-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/fi-icl-u3/igt@kms_chamel...@dp-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1209]: https://gitlab.freedesktop.org/drm/intel/issues/1209
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#690]: https://gitlab.freedesktop.org/drm/intel/issues/690
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
Participating hosts (49 -> 45)
--
Additional (3): fi-skl-lmem fi-skl-6600u fi-snb-2600
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* IGT: IGT_5451 -> IGTPW_4011
* Linux: CI_DRM_7966 -> Patchwork_16632
CI-20190529: 20190529
CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4011: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4011/index.html
IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16632: 6e576dd5ff3664855ce63be067856c64fd993146 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6e576dd5ff36 drm/i915: Adding YUV444 packed format support for skl+ (V14)
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16632/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Protect signaler walk with RCU
Quoting Matthew Auld (2020-02-19 19:02:36) > > @@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node) > > GEM_BUG_ON(dep->signaler != node); > > GEM_BUG_ON(!list_empty(>dfs_link)); > > > > - list_del(>signal_link); > > + list_del_rcu(>signal_link); > > if (dep->flags & I915_DEPENDENCY_ALLOC) > > i915_dependency_free(dep); > > Is this not a potential uaf? Do we not have to wait for the grace > period before doing the free, or what? If we insert SLAB_TYPESAFE_BY_RCU that should satisfy all. (Give or that the amount of pain in thinking about rcu-freelists.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add Wa_22010178259:tgl
On Mon, 2020-02-10 at 12:28 -0800, Matt Roper wrote:
> We need to explicitly set the TLB Request Timer initial value in the
> BW_BUDDY registers to 0x8 rather than relying on the hardware
> default.
>
> Bspec: 52890
> Bspec: 50044
> Cc: Stanislav Lisovskiy
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 6 ++
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 6e55e88ca0d0..2ad2694a28e6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -5001,6 +5001,12 @@ static void tgl_bw_buddy_init(struct
> drm_i915_private *dev_priv)
> table[i].page_mask);
> intel_de_write(dev_priv, BW_BUDDY2_PAGE_MASK,
> table[i].page_mask);
> +
> + /* Wa_22010178259:tgl */
> + intel_de_rmw(dev_priv, BW_BUDDY1_CTL,
> + BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8);
> + intel_de_rmw(dev_priv, BW_BUDDY2_CTL,
> + BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8);
This will clear BW_BUDDY_TLB_REQ_TIMER_MASK and set 0x8, while it
should be 0x8 << 16(adding a macro for that)
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index a6847f26678c..d829b9ae8402 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7766,6 +7766,7 @@ enum {
> #define BW_BUDDY1_CTL_MMIO(0x45140)
> #define BW_BUDDY2_CTL_MMIO(0x45150)
> #define BW_BUDDY_DISABLE REG_BIT(31)
> +#define BW_BUDDY_TLB_REQ_TIMER_MASKREG_GENMASK(21, 16)
>
> #define BW_BUDDY1_PAGE_MASK _MMIO(0x45144)
> #define BW_BUDDY2_PAGE_MASK _MMIO(0x45154)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Adding YUV444 packed format support for skl+ (rev3)
== Series Details == Series: Adding YUV444 packed format support for skl+ (rev3) URL : https://patchwork.freedesktop.org/series/73020/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6e576dd5ff36 drm/i915: Adding YUV444 packed format support for skl+ (V14) -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification. total: 0 errors, 1 warnings, 0 checks, 73 lines checked ___ 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: Put drm_display_mode on diet
== Series Details ==
Series: drm: Put drm_display_mode on diet
URL : https://patchwork.freedesktop.org/series/73674/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16631
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16631/index.html
Known issues
Here are the changes found in Patchwork_16631 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] ([i915#1242])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16631/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [PASS][3] -> [DMESG-FAIL][4] ([i915#1052])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16631/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][5] ([i915#877]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16631/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
Warnings
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][7] ([fdo#109315] / [i915#585]) -> [SKIP][8]
([fdo#109315])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16631/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 40)
--
Additional (3): fi-skl-lmem fi-skl-6600u fi-snb-2600
Missing(12): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u
fi-hsw-peppy fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7966 -> Patchwork_16631
CI-20190529: 20190529
CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16631: 133ee95728f4361cc469df6ee57430d5096cc8c7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
133ee95728f4 drm: pahole struct drm_display_mode
185304bca386 drm: Shrink mode->private_flags
2b38c59a9a1c drm: Flatten drm_mode_vrefresh()
461918918abd drm: Shrink drm_display_mode timings
95bbdbf0fc19 drm: Make mode->flags u32
123730c56db7 drm: Shrink mode->type to u8
ebc0d4878fa3 drm: Shrink {width,height}_mm to u16
5ffd09532dbc drm/msm/dpu: Stop copying around mode->private_flags
fc4bd0c92150 drm: Nuke mode->vrefresh
28e0079cb232 drm/i915: Introduce some local intel_dp variables
60d00db46691 drm/exynos: Use mode->clock instead of reverse calculating it from
the vrefresh
1547c317f1a8 drm: Nuke mode->hsync
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16631/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
On Wed, Feb 19, 2020 at 10:35:32PM +0200, Ville Syrjala wrote: > - Eliminate the second list head somehow? I think we could just convert that to a boolean, or even just borrow eg. the one totally free mode->type bit for our internal use to tag the exposed modes. That would in fact get us down to 120 bytes on 64bit machines (and 112 bytes on 32bit). The downside would be one extra loop over the modes in the getconnector ioctl to clear the stale tags. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: Adding YUV444 packed format support for skl+ (V14)
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
labels.
v5: Started to use XYUV instead of AYUV, as we don't use alpha.
v6: Removed unneeded initializer for new XYUV format.
v7: Added scaling support for DRM_FORMAT_XYUV
v8: Edited commit message to be more clear about skl+, renamed
PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
doesn't support per-pixel alpha. Fixed minor code issues.
v9: Moved DRM format check to proper place in intel_framebuffer_init.
v10: Added missing XYUV format to sprite planes for skl+.
v11: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV.
v12: Fixed rebase conflicts
V13: Rebased.
Added format to ICL format lists.
V14: Added format to TGL format lists.
Rebased.
v12:
Reviewed-by: Ville Syrjälä
Reviewed-by: Matt Roper
Signed-off-by: Stanislav Lisovskiy
Signed-off-by: Bob Paauwe
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +
drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 2 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 61ba1f2256a0..919270b7e240 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3331,6 +3331,8 @@ int skl_format_to_fourcc(int format, bool rgb_order, bool
alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_XYUV:
+ return DRM_FORMAT_XYUV;
case PLANE_CTL_FORMAT_P010:
return DRM_FORMAT_P010;
case PLANE_CTL_FORMAT_P012:
@@ -4570,6 +4572,8 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
case DRM_FORMAT_XRGB16161616F:
case DRM_FORMAT_ARGB16161616F:
return PLANE_CTL_FORMAT_XRGB_16161616F;
+ case DRM_FORMAT_XYUV:
+ return PLANE_CTL_FORMAT_XYUV;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -6186,6 +6190,7 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 7abeefe8dce5..8a95a1e7448a 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2483,6 +2483,7 @@ static const u32 skl_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+ DRM_FORMAT_XYUV,
};
static const u32 skl_planar_formats[] = {
@@ -2501,6 +2502,7 @@ static const u32 skl_planar_formats[] = {
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
DRM_FORMAT_NV12,
+ DRM_FORMAT_XYUV,
};
static const u32 glk_planar_formats[] = {
@@ -2572,6 +2574,7 @@ static const u32 icl_sdr_uv_plane_formats[] = {
DRM_FORMAT_XVYU2101010,
DRM_FORMAT_XVYU12_16161616,
DRM_FORMAT_XVYU16161616,
+ DRM_FORMAT_XYUV,
};
static const u32 icl_hdr_plane_formats[] = {
@@ -2603,6 +2606,7 @@ static const u32 icl_hdr_plane_formats[] = {
DRM_FORMAT_XVYU2101010,
DRM_FORMAT_XVYU12_16161616,
DRM_FORMAT_XVYU16161616,
+ DRM_FORMAT_XYUV,
};
static const u64 skl_plane_format_modifiers_noccs[] = {
@@ -2770,6 +2774,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
@@ -2834,6 +2839,7 @@ static bool gen12_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b09c1d6dc0aa..17e6453d31d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6768,7 +6768,7 @@ enum {
#define PLANE_CTL_FORMAT_P012(5 << 24)
#define PLANE_CTL_FORMAT_XRGB_16161616F (6 << 24)
#define PLANE_CTL_FORMAT_P016(7 << 24)
-#define PLANE_CTL_FORMAT_AYUV(8 << 24)
[Intel-gfx] [PATCH 0/1] Adding YUV444 packed format support for skl+
Test-with: 20200127192859.20029-1-bob.j.paa...@intel.com Stanislav Lisovskiy (1): drm/i915: Adding YUV444 packed format support for skl+ (V14) drivers/gpu/drm/i915/display/intel_display.c | 5 + drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++ drivers/gpu/drm/i915/i915_reg.h | 2 +- 3 files changed, 12 insertions(+), 1 deletion(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Put drm_display_mode on diet
== Series Details ==
Series: drm: Put drm_display_mode on diet
URL : https://patchwork.freedesktop.org/series/73674/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1547c317f1a8 drm: Nuke mode->hsync
60d00db46691 drm/exynos: Use mode->clock instead of reverse calculating it from
the vrefresh
28e0079cb232 drm/i915: Introduce some local intel_dp variables
fc4bd0c92150 drm: Nuke mode->vrefresh
-:1393: WARNING:LONG_LINE: line over 100 characters
#1393: FILE: drivers/gpu/drm/i915/display/intel_dp.c:7225:
+
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode));
-:1402: WARNING:LONG_LINE: line over 100 characters
#1402: FILE: drivers/gpu/drm/i915/display/intel_dp.c:7271:
+
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode));
total: 0 errors, 2 warnings, 0 checks, 2529 lines checked
5ffd09532dbc drm/msm/dpu: Stop copying around mode->private_flags
-:84: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#84: FILE: drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:330:
+ TP_PROTO(uint32_t drm_id, unsigned int flags),
total: 0 errors, 0 warnings, 1 checks, 71 lines checked
ebc0d4878fa3 drm: Shrink {width,height}_mm to u16
123730c56db7 drm: Shrink mode->type to u8
95bbdbf0fc19 drm: Make mode->flags u32
461918918abd drm: Shrink drm_display_mode timings
2b38c59a9a1c drm: Flatten drm_mode_vrefresh()
185304bca386 drm: Shrink mode->private_flags
133ee95728f4 drm: pahole struct drm_display_mode
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: make a gt sysfs group and move power management files (rev5)
== Series Details == Series: drm/i915/gt: make a gt sysfs group and move power management files (rev5) URL : https://patchwork.freedesktop.org/series/73190/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16630 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16630 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16630, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16630: ### IGT changes ### Possible regressions * igt@i915_pm_rps@basic-api: - fi-kbl-guc: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-kbl-guc/igt@i915_pm_...@basic-api.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-kbl-guc/igt@i915_pm_...@basic-api.html - fi-cfl-8109u: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cfl-8109u/igt@i915_pm_...@basic-api.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-cfl-8109u/igt@i915_pm_...@basic-api.html - fi-hsw-4770r: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-hsw-4770r/igt@i915_pm_...@basic-api.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-hsw-4770r/igt@i915_pm_...@basic-api.html - fi-bsw-nick:[PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-bsw-nick/igt@i915_pm_...@basic-api.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-bsw-nick/igt@i915_pm_...@basic-api.html - fi-kbl-7500u: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-kbl-7500u/igt@i915_pm_...@basic-api.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-kbl-7500u/igt@i915_pm_...@basic-api.html - fi-hsw-peppy: NOTRUN -> [DMESG-WARN][11] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-hsw-peppy/igt@i915_pm_...@basic-api.html - fi-kbl-8809g: [PASS][12] -> [DMESG-WARN][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-kbl-8809g/igt@i915_pm_...@basic-api.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-kbl-8809g/igt@i915_pm_...@basic-api.html - fi-kbl-r: [PASS][14] -> [DMESG-WARN][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-kbl-r/igt@i915_pm_...@basic-api.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-kbl-r/igt@i915_pm_...@basic-api.html - fi-bsw-kefka: [PASS][16] -> [DMESG-WARN][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-bsw-kefka/igt@i915_pm_...@basic-api.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-bsw-kefka/igt@i915_pm_...@basic-api.html - fi-glk-dsi: [PASS][18] -> [DMESG-WARN][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-glk-dsi/igt@i915_pm_...@basic-api.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-glk-dsi/igt@i915_pm_...@basic-api.html - fi-icl-u3: [PASS][20] -> [DMESG-WARN][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@i915_pm_...@basic-api.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-icl-u3/igt@i915_pm_...@basic-api.html - fi-kbl-x1275: [PASS][22] -> [DMESG-WARN][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-kbl-x1275/igt@i915_pm_...@basic-api.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-kbl-x1275/igt@i915_pm_...@basic-api.html - fi-cml-s: [PASS][24] -> [DMESG-WARN][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_pm_...@basic-api.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-cml-s/igt@i915_pm_...@basic-api.html - fi-snb-2600:NOTRUN -> [DMESG-WARN][26] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-snb-2600/igt@i915_pm_...@basic-api.html - fi-cfl-guc: [PASS][27] -> [DMESG-WARN][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cfl-guc/igt@i915_pm_...@basic-api.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16630/fi-cfl-guc/igt@i915_pm_...@basic-api.html - fi-bsw-n3050: [PASS][29] -> [DMESG-WARN][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-bsw-n3050/igt@i915_pm_...@basic-api.html [30]:
[Intel-gfx] [PATCH 11/12] drm: Shrink mode->private_flags
From: Ville Syrjälä
gma500 needs 4 bits (to store a pixel multiplier) in the
mode->private_flags, i915 currently has three bits defined.
No one else uses this. Reduce the size to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index b585074945b5..dadb0f3e5b0b 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -378,7 +378,7 @@ struct drm_display_mode {
* by atomic drivers since they can store any additional data by
* subclassing state structures.
*/
- int private_flags;
+ u8 private_flags;
/**
* @picture_aspect_ratio:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/12] drm: pahole struct drm_display_mode
From: Ville Syrjälä
Reorganize drm_display_mode to eliminate all the holes.
We'll put all the actual timings to the start of the
struct and all the extra junk to the end.
Gets the size down to 136 bytes on 64bit and 120 bytes on
32bit. With a bit more work we should be able to get this
below the two cacheline mark even on 64bit.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 139
1 file changed, 70 insertions(+), 69 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index dadb0f3e5b0b..fded81306a47 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -222,56 +222,6 @@ enum drm_mode_status {
* For printing you can use %DRM_MODE_FMT and DRM_MODE_ARG().
*/
struct drm_display_mode {
- /**
-* @head:
-*
-* struct list_head for mode lists.
-*/
- struct list_head head;
-
- /**
-* @name:
-*
-* Human-readable name of the mode, filled out with drm_mode_set_name().
-*/
- char name[DRM_DISPLAY_MODE_LEN];
-
- /**
-* @status:
-*
-* Status of the mode, used to filter out modes not supported by the
-* hardware. See enum _mode_status.
-*/
- enum drm_mode_status status;
-
- /**
-* @type:
-*
-* A bitmask of flags, mostly about the source of a mode. Possible flags
-* are:
-*
-* - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
-*resolution of an LCD panel. There should only be one preferred
-*mode per connector at any given time.
-* - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
-*them really. Drivers must set this bit for all modes they create
-*and expose to userspace.
-* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
-*
-* Plus a big list of flags which shouldn't be used at all, but are
-* still around since these flags are also used in the userspace ABI.
-* We no longer accept modes with these types though:
-*
-* - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, unused.
-*Use DRM_MODE_TYPE_DRIVER instead.
-* - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
-*DRM_MODE_TYPE_PREFERRED instead.
-* - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
-*which are stuck around for hysterical raisins only. No one has an
-*idea what they were meant for. Don't use.
-*/
- u8 type;
-
/**
* @clock:
*
@@ -324,22 +274,6 @@ struct drm_display_mode {
*/
u32 flags;
- /**
-* @width_mm:
-*
-* Addressable size of the output in mm, projectors should set this to
-* 0.
-*/
- u16 width_mm;
-
- /**
-* @height_mm:
-*
-* Addressable size of the output in mm, projectors should set this to
-* 0.
-*/
- u16 height_mm;
-
/**
* @crtc_clock:
*
@@ -370,6 +304,50 @@ struct drm_display_mode {
u16 crtc_vsync_end;
u16 crtc_vtotal;
+ /**
+* @width_mm:
+*
+* Addressable size of the output in mm, projectors should set this to
+* 0.
+*/
+ u16 width_mm;
+
+ /**
+* @height_mm:
+*
+* Addressable size of the output in mm, projectors should set this to
+* 0.
+*/
+ u16 height_mm;
+
+ /**
+* @type:
+*
+* A bitmask of flags, mostly about the source of a mode. Possible flags
+* are:
+*
+* - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
+*resolution of an LCD panel. There should only be one preferred
+*mode per connector at any given time.
+* - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
+*them really. Drivers must set this bit for all modes they create
+*and expose to userspace.
+* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
+*
+* Plus a big list of flags which shouldn't be used at all, but are
+* still around since these flags are also used in the userspace ABI.
+* We no longer accept modes with these types though:
+*
+* - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, unused.
+*Use DRM_MODE_TYPE_DRIVER instead.
+* - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
+*DRM_MODE_TYPE_PREFERRED instead.
+* - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
+*which are stuck around for hysterical raisins only. No one has an
+*idea what they were meant for. Don't use.
+*/
+ u8 type;
+
/**
* @private_flags:
[Intel-gfx] [PATCH 08/12] drm: Make mode->flags u32
From: Ville Syrjälä
The mode flags are direclty exposed in the uapi as u32. Use the
same size type to store them internally.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 5c20285cc317..b28c0234fcd7 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -322,7 +322,7 @@ struct drm_display_mode {
* - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF: frame split into left and
*right parts.
*/
- unsigned int flags;
+ u32 flags;
/**
* @width_mm:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/12] drm: Shrink drm_display_mode timings
From: Ville Syrjälä
Store the timings (apart from the clock) as u16. The uapi mode
struct already uses u16 for everything so using something bigger
internally doesn't really help us.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 7 --
include/drm/drm_modes.h | 46 ++---
2 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 0e7c9ba241c4..cc9fc52f9f7c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1917,13 +1917,6 @@ EXPORT_SYMBOL(drm_mode_create_from_cmdline_mode);
void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
const struct drm_display_mode *in)
{
- WARN(in->hdisplay > USHRT_MAX || in->hsync_start > USHRT_MAX ||
-in->hsync_end > USHRT_MAX || in->htotal > USHRT_MAX ||
-in->hskew > USHRT_MAX || in->vdisplay > USHRT_MAX ||
-in->vsync_start > USHRT_MAX || in->vsync_end > USHRT_MAX ||
-in->vtotal > USHRT_MAX || in->vscan > USHRT_MAX,
-"timing values too large for mode info\n");
-
out->clock = in->clock;
out->hdisplay = in->hdisplay;
out->hsync_start = in->hsync_start;
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index b28c0234fcd7..b585074945b5 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -278,16 +278,16 @@ struct drm_display_mode {
* Pixel clock in kHz.
*/
int clock; /* in kHz */
- int hdisplay;
- int hsync_start;
- int hsync_end;
- int htotal;
- int hskew;
- int vdisplay;
- int vsync_start;
- int vsync_end;
- int vtotal;
- int vscan;
+ u16 hdisplay;
+ u16 hsync_start;
+ u16 hsync_end;
+ u16 htotal;
+ u16 hskew;
+ u16 vdisplay;
+ u16 vsync_start;
+ u16 vsync_end;
+ u16 vtotal;
+ u16 vscan;
/**
* @flags:
*
@@ -356,19 +356,19 @@ struct drm_display_mode {
* difference is exactly a factor of 10.
*/
int crtc_clock;
- int crtc_hdisplay;
- int crtc_hblank_start;
- int crtc_hblank_end;
- int crtc_hsync_start;
- int crtc_hsync_end;
- int crtc_htotal;
- int crtc_hskew;
- int crtc_vdisplay;
- int crtc_vblank_start;
- int crtc_vblank_end;
- int crtc_vsync_start;
- int crtc_vsync_end;
- int crtc_vtotal;
+ u16 crtc_hdisplay;
+ u16 crtc_hblank_start;
+ u16 crtc_hblank_end;
+ u16 crtc_hsync_start;
+ u16 crtc_hsync_end;
+ u16 crtc_htotal;
+ u16 crtc_hskew;
+ u16 crtc_vdisplay;
+ u16 crtc_vblank_start;
+ u16 crtc_vblank_end;
+ u16 crtc_vsync_start;
+ u16 crtc_vsync_end;
+ u16 crtc_vtotal;
/**
* @private_flags:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/12] drm: Flatten drm_mode_vrefresh()
From: Ville Syrjälä
Remove the pointless whole-function indentation. Also don't
need to worry about negative values anymore since we switched
everything to u16.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index cc9fc52f9f7c..d20a273b4b9a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -773,24 +773,22 @@ EXPORT_SYMBOL(drm_mode_hsync);
*/
int drm_mode_vrefresh(const struct drm_display_mode *mode)
{
- int refresh = 0;
+ unsigned int num, den;
- if (mode->htotal > 0 && mode->vtotal > 0) {
- unsigned int num, den;
+ if (mode->htotal == 0 || mode->vtotal == 0)
+ return 0;
- num = mode->clock * 1000;
- den = mode->htotal * mode->vtotal;
+ num = mode->clock * 1000;
+ den = mode->htotal * mode->vtotal;
- if (mode->flags & DRM_MODE_FLAG_INTERLACE)
- num *= 2;
- if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
- den *= 2;
- if (mode->vscan > 1)
- den *= mode->vscan;
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ num *= 2;
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ den *= 2;
+ if (mode->vscan > 1)
+ den *= mode->vscan;
- refresh = DIV_ROUND_CLOSEST(num, den);
- }
- return refresh;
+ return DIV_ROUND_CLOSEST(num, den);
}
EXPORT_SYMBOL(drm_mode_vrefresh);
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/12] drm: Shrink mode->type to u8
From: Ville Syrjälä
We only have 7 bits defined for mode->type. Shrink the storage to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2bb2b1a8592a..5c20285cc317 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -270,7 +270,7 @@ struct drm_display_mode {
*which are stuck around for hysterical raisins only. No one has an
*idea what they were meant for. Don't use.
*/
- unsigned int type;
+ u8 type;
/**
* @clock:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/12] drm: Shrink {width,height}_mm to u16
From: Ville Syrjälä
Instead of supporting ~2000km wide displayes let's limit ourselves
to ~65m. That seems plenty big enough to me.
Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
10*0xfff which fits into the 16 bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 52e8ca613e4b..2bb2b1a8592a 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -330,7 +330,7 @@ struct drm_display_mode {
* Addressable size of the output in mm, projectors should set this to
* 0.
*/
- int width_mm;
+ u16 width_mm;
/**
* @height_mm:
@@ -338,7 +338,7 @@ struct drm_display_mode {
* Addressable size of the output in mm, projectors should set this to
* 0.
*/
- int height_mm;
+ u16 height_mm;
/**
* @crtc_clock:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] drm: Nuke mode->hsync
From: Ville Syrjälä
Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 14 ++
drivers/gpu/drm/i915/display/intel_display.c | 1 -
include/drm/drm_modes.h | 10 --
3 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d4d64518e11b..fe7e872a6239 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -752,24 +752,14 @@ EXPORT_SYMBOL(drm_mode_set_name);
* @mode: mode
*
* Returns:
- * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
- * value first if it is not yet set.
+ * @modes's hsync rate in kHz, rounded to the nearest integer
*/
int drm_mode_hsync(const struct drm_display_mode *mode)
{
- unsigned int calc_val;
-
- if (mode->hsync)
- return mode->hsync;
-
if (mode->htotal <= 0)
return 0;
- calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
- calc_val += 500;/* round to 1000Hz */
- calc_val /= 1000; /* truncate to kHz */
-
- return calc_val;
+ return DIV_ROUND_CLOSEST(mode->clock, mode->htotal);
}
EXPORT_SYMBOL(drm_mode_hsync);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee7d54ccd3e6..fab914819489 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8867,7 +8867,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode
*mode,
mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
- mode->hsync = drm_mode_hsync(mode);
mode->vrefresh = drm_mode_vrefresh(mode);
drm_mode_set_name(mode);
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 99134d4f35eb..7dab7f172431 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -390,16 +390,6 @@ struct drm_display_mode {
*/
int vrefresh;
- /**
-* @hsync:
-*
-* Horizontal refresh rate, for debug output in human readable form. Not
-* used in a functional way.
-*
-* This value is in kHz.
-*/
- int hsync;
-
/**
* @picture_aspect_ratio:
*
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä
The driver never sets mode->private_flags so copying
it back and forth is entirely pointless. Stop doing it.
Also drop private_flags from the tracepoint.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +++
2 files changed, 5 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 58d3400668f5..4511e2ba3680 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -500,23 +500,6 @@ void dpu_encoder_helper_split_config(
}
}
-static void _dpu_encoder_adjust_mode(struct drm_connector *connector,
- struct drm_display_mode *adj_mode)
-{
- struct drm_display_mode *cur_mode;
-
- if (!connector || !adj_mode)
- return;
-
- list_for_each_entry(cur_mode, >modes, head) {
- if (cur_mode->vdisplay == adj_mode->vdisplay &&
- cur_mode->hdisplay == adj_mode->hdisplay &&
- drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode))
{
- adj_mode->private_flags |= cur_mode->private_flags;
- }
- }
-}
-
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
@@ -580,15 +563,6 @@ static int dpu_encoder_virt_atomic_check(
adj_mode = _state->adjusted_mode;
trace_dpu_enc_atomic_check(DRMID(drm_enc));
- /*
-* display drivers may populate private fields of the drm display mode
-* structure while registering possible modes of a connector with DRM.
-* These private fields are not populated back while DRM invokes
-* the mode_set callbacks. This module retrieves and populates the
-* private fields of the given mode.
-*/
- _dpu_encoder_adjust_mode(conn_state->connector, adj_mode);
-
/* perform atomic check on the first physical encoder (master) */
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
@@ -623,8 +597,7 @@ static int dpu_encoder_virt_atomic_check(
}
}
- trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags,
- adj_mode->private_flags);
+ trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags);
return ret;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index eecfe9b3199e..6714b088970f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -327,20 +327,18 @@ DEFINE_EVENT(dpu_enc_keyval_template,
dpu_enc_trigger_start,
);
TRACE_EVENT(dpu_enc_atomic_check_flags,
- TP_PROTO(uint32_t drm_id, unsigned int flags, int private_flags),
- TP_ARGS(drm_id, flags, private_flags),
+ TP_PROTO(uint32_t drm_id, unsigned int flags),
+ TP_ARGS(drm_id, flags),
TP_STRUCT__entry(
__field(uint32_t, drm_id )
__field(unsigned int, flags )
- __field(int,private_flags )
),
TP_fast_assign(
__entry->drm_id = drm_id;
__entry->flags = flags;
- __entry->private_flags = private_flags;
),
- TP_printk("id=%u, flags=%u, private_flags=%d",
- __entry->drm_id, __entry->flags, __entry->private_flags)
+ TP_printk("id=%u, flags=%u",
+ __entry->drm_id, __entry->flags)
);
DECLARE_EVENT_CLASS(dpu_enc_id_enable_template,
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/12] drm/i915: Introduce some local intel_dp variables
From: Ville Syrjälä
The drrs code dereferences mode->vrefresh via some really long chain
of structures/pointers. Couldn't get coccinelle to see through all
that so let's add some local variables to help it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 82baf5aba84b..f9e1361460d8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7196,6 +7196,7 @@ static void intel_edp_drrs_downclock_work(struct
work_struct *work)
void intel_edp_drrs_invalidate(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits)
{
+ struct intel_dp *intel_dp;
struct drm_crtc *crtc;
enum pipe pipe;
@@ -7205,12 +7206,14 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
cancel_delayed_work(_priv->drrs.work);
mutex_lock(_priv->drrs.mutex);
- if (!dev_priv->drrs.dp) {
+
+ intel_dp = dev_priv->drrs.dp;
+ if (!intel_dp) {
mutex_unlock(_priv->drrs.mutex);
return;
}
- crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+ crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
@@ -7219,7 +7222,7 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
/* invalidate means busy screen hence upclock */
if (frontbuffer_bits && dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
intel_dp_set_drrs_state(dev_priv, to_intel_crtc(crtc)->config,
-
dev_priv->drrs.dp->attached_connector->panel.fixed_mode->vrefresh);
+
intel_dp->attached_connector->panel.fixed_mode->vrefresh);
mutex_unlock(_priv->drrs.mutex);
}
@@ -7239,6 +7242,7 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
void intel_edp_drrs_flush(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits)
{
+ struct intel_dp *intel_dp;
struct drm_crtc *crtc;
enum pipe pipe;
@@ -7248,12 +7252,14 @@ void intel_edp_drrs_flush(struct drm_i915_private
*dev_priv,
cancel_delayed_work(_priv->drrs.work);
mutex_lock(_priv->drrs.mutex);
- if (!dev_priv->drrs.dp) {
+
+ intel_dp = dev_priv->drrs.dp;
+ if (!intel_dp) {
mutex_unlock(_priv->drrs.mutex);
return;
}
- crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+ crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
@@ -7262,7 +7268,7 @@ void intel_edp_drrs_flush(struct drm_i915_private
*dev_priv,
/* flush means busy screen hence upclock */
if (frontbuffer_bits && dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
intel_dp_set_drrs_state(dev_priv, to_intel_crtc(crtc)->config,
-
dev_priv->drrs.dp->attached_connector->panel.fixed_mode->vrefresh);
+
intel_dp->attached_connector->panel.fixed_mode->vrefresh);
/*
* flush also means no more activity hence schedule downclock, if all
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh
From: Ville Syrjälä
htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ff59c641fa80..e7b58097ccdc 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -139,7 +139,7 @@ static void decon_ctx_remove(struct decon_context *ctx)
static u32 decon_calc_clkdiv(struct decon_context *ctx,
const struct drm_display_mode *mode)
{
- unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
+ unsigned long ideal_clk = mode->clock;
u32 clkdiv;
/* Find the clock divider value that gets us closest to ideal_clk */
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä
struct drm_display_mode is extremely fat. Put it on diet.
Some stats for the whole series:
64bit sizeof(struct drm_display_mode):
200 -> 136 bytes (-32%)
64bit bloat-o-meter -c drm.ko:
add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
Function old new delta
...
Total: Before=189430, After=188779, chg -0.34%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Data old new delta
Total: Before=11667, After=11667, chg +0.00%
add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
RO Data old new delta
edid_4k_modes 1000 680-320
edid_est_modes 34002312 -1088
edid_cea_modes_193 54003672 -1728
drm_dmt_modes 17600 11968 -5632
edid_cea_modes_1 25400 17272 -8128
Total: Before=71239, After=54343, chg -23.72%
64bit bloat-o-meter drm.ko:
add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
...
Total: Before=272336, After=254789, chg -6.44%
32bit sizeof(struct drm_display_mode):
184 -> 120 bytes (-34%)
32bit bloat-o-meter -c drm.ko
add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
Function old new delta
...
Total: Before=172359, After=171734, chg -0.36%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Data old new delta
Total: Before=4227, After=4227, chg +0.00%
add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
RO Data old new delta
edid_4k_modes920 600-320
edid_est_modes 31282040 -1088
edid_cea_modes_193 49683240 -1728
drm_dmt_modes 16192 10560 -5632
edid_cea_modes_1 23368 15240 -8128
Total: Before=59230, After=42334, chg -28.53%
32bit bloat-o-meter drm.ko:
add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
...
Total: Before=235816, After=218295, chg -7.43%
Some ideas for further reduction:
- Convert mode->name to a pointer (saves 24/28 bytes in the
struct but would often require a heap alloc for the name (though
typical mode name is <10 bytes so still overall win perhaps)
- Get rid of mode->name entirely? I guess setcrtc & co. is the only
place where we have to preserve the user provided name, elsewhere
could pehaps just generate on demand? Not sure how tricky this
would get.
- Eliminate the second list head somehow?
Pie in the sky idea:
- Eliminate the normal vs. crtc_ dual timings where not needed. Ie.
Just use two structs if necessary instead of packing both to the
same struct. Can't imagine this being an easy conversion.
Entire series available here:
git://github.com/vsyrjala/linux.git drm_mode_diet_4
Ville Syrjälä (12):
drm: Nuke mode->hsync
drm/exynos: Use mode->clock instead of reverse calculating it from the
vrefresh
drm/i915: Introduce some local intel_dp variables
drm: Nuke mode->vrefresh
drm/msm/dpu: Stop copying around mode->private_flags
drm: Shrink {width,height}_mm to u16
drm: Shrink mode->type to u8
drm: Make mode->flags u32
drm: Shrink drm_display_mode timings
drm: Flatten drm_mode_vrefresh()
drm: Shrink mode->private_flags
drm: pahole struct drm_display_mode
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_edid.c| 328 +-
drivers/gpu/drm/drm_modes.c | 54 +--
drivers/gpu/drm/drm_probe_helper.c| 3 -
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
drivers/gpu/drm/i2c/ch7006_mode.c | 1 -
drivers/gpu/drm/i915/display/intel_display.c | 2 -
.../drm/i915/display/intel_display_debugfs.c | 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 24 +-
drivers/gpu/drm/i915/display/intel_tv.c | 3 -
drivers/gpu/drm/mcde/mcde_dsi.c | 6 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +-
drivers/gpu/drm/panel/panel-arm-versatile.c | 4 -
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 3 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 6 +-
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 3 +-
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +-
Re: [Intel-gfx] [PATCH] drm/i915: Extend Wa_1606931601 for all steppings.
On Tue, Feb 18, 2020 at 07:59:02PM -0800, Anusha Srivatsa wrote:
> Previously known by the WA number - Wa_1607090982, extend
> the WA (Disable Early Read and Src Swap (bit 14) by
> setting the chicken register.) to all steppings.
This description is a bit hard to follow; maybe something like this
would be more clear?
"""
drm/i915: Extend Wa_1606931601 for all steppings
According to the bspec, Wa_1606931601 applies to all TGL
steppings so we need to move it out of the the A0-only block
of rcs_engine_wa_init().
Note that this workaround has also been referred to by an
alternate name Wa_1607090982 in some previous patches.
"""
>
> The WA is implemented in -
> 3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982")
This sentence can be dropped in favor of the formal "Fixes:" line below.
>
> Bspec: 46045,52890
>
Please add a
Fixes: 3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982")
line here to make sure that maintainer tools will properly
apply/backport this fix to all the appropriate trees.
> Cc: Mika Kuoppala
> Signed-off-by: Anusha Srivatsa
Aside from the above this looks good, so
Reviewed-by: Matt Roper
with an updated commit message.
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 887e0dc701f7..7cc8a7fc53c7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1329,6 +1329,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = engine->i915;
>
> + if (IS_TIGERLAKE(i915)) {
> + /* Wa_1606931601:tgl */
> + wa_masked_en(wal,
> + GEN7_ROW_CHICKEN2,
> + GEN12_DISABLE_EARLY_READ);
> + }
> +
> if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
> /* Wa_1606700617:tgl */
> wa_masked_en(wal,
> @@ -1360,11 +1367,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> wa_write_or(wal,
> GEN7_FF_THREAD_MODE,
> GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
> -
> - /* Wa_1606931601:tgl */
> - wa_masked_en(wal,
> - GEN7_ROW_CHICKEN2,
> - GEN12_DISABLE_EARLY_READ);
> }
>
> if (IS_GEN(i915, 11)) {
> --
> 2.25.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: make a gt sysfs group and move power management files (rev5)
== Series Details == Series: drm/i915/gt: make a gt sysfs group and move power management files (rev5) URL : https://patchwork.freedesktop.org/series/73190/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/gt: make a gt sysfs group and move power management files +drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:19:17: warning: symbol 'intel_gt_sysfs_get_drvdata' was not declared. Should it be static? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] dma-buf: add dynamic DMA-buf handling v15
== Series Details ==
Series: series starting with [1/7] dma-buf: add dynamic DMA-buf handling v15
URL : https://patchwork.freedesktop.org/series/73665/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16629
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16629 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16629, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16629/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16629:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_gt_heartbeat:
- fi-bwr-2160:[PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-bwr-2160/igt@i915_selftest@live_gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16629/fi-bwr-2160/igt@i915_selftest@live_gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_16629 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][3] ([i915#877]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16629/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- fi-glk-dsi: [TIMEOUT][5] ([fdo#112271] / [i915#690]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-glk-dsi/igt@i915_selftest@live_gtt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16629/fi-glk-dsi/igt@i915_selftest@live_gtt.html
Warnings
* igt@gem_exec_parallel@fds:
- fi-byt-n2820: [FAIL][7] ([i915#694]) -> [TIMEOUT][8] ([fdo#112271]
/ [i915#1084])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-byt-n2820/igt@gem_exec_paral...@fds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16629/fi-byt-n2820/igt@gem_exec_paral...@fds.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#690]: https://gitlab.freedesktop.org/drm/intel/issues/690
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 39)
--
Additional (1): fi-skl-6600u
Missing(11): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-ivb-3770 fi-bsw-kefka fi-byt-clapper
fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7966 -> Patchwork_16629
CI-20190529: 20190529
CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16629: ab64183605a5e61b02a5f12b58f30a899210ca26 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ab64183605a5 dma-buf: make move_notify mandatory if importer_ops are provided
6a48a4358556 dma-buf: drop dynamic_mapping flag
2d6a296d68e9 drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
4b91a843ed4c drm/amdgpu: add amdgpu_dma_buf_pin/unpin v2
745ab3baba32 drm/amdgpu: use allowed_domains for exported DMA-bufs
c574d9957711 drm/ttm: remove the backing store if no placement is given
49072c39a5b6 dma-buf: add dynamic DMA-buf handling v15
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16629/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: make a gt sysfs group and move power management files (rev5)
== Series Details == Series: drm/i915/gt: make a gt sysfs group and move power management files (rev5) URL : https://patchwork.freedesktop.org/series/73190/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1ad40388b0d2 drm/i915/gt: make a gt sysfs group and move power management files -:88: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #88: new file mode 100644 -:164: WARNING:TYPO_SPELLING: 'wether' may be misspelled - perhaps 'whether'? #164: FILE: drivers/gpu/drm/i915/gt/sysfs_gt.c:72: +* the name gt tells us wether sysfs_root -:567: WARNING:DEVICE_ATTR_FUNCTIONS: Consider renaming function(s) 'gt_rp_mhz_show' to 'gt_RP0_freq_mhz_show' #567: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:362: +static DEVICE_ATTR(gt_RP0_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:568: WARNING:DEVICE_ATTR_FUNCTIONS: Consider renaming function(s) 'gt_rp_mhz_show' to 'gt_RP1_freq_mhz_show' #568: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:363: +static DEVICE_ATTR(gt_RP1_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:569: CHECK:CAMELCASE: Avoid CamelCase: #569: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:364: +static DEVICE_ATTR(gt_RPn_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:569: WARNING:DEVICE_ATTR_FUNCTIONS: Consider renaming function(s) 'gt_rp_mhz_show' to 'gt_RPn_freq_mhz_show' #569: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:364: +static DEVICE_ATTR(gt_RPn_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:584: CHECK:CAMELCASE: Avoid CamelCase: #584: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:379: + else if (attr == _attr_gt_RPn_freq_mhz) -:587: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #587: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:382: + BUG(); total: 0 errors, 6 warnings, 2 checks, 1009 lines checked ___ 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 [1/2] drm/i915/pmu: Avoid using globals for CPU hotplug state
== Series Details ==
Series: series starting with [1/2] drm/i915/pmu: Avoid using globals for CPU
hotplug state
URL : https://patchwork.freedesktop.org/series/73663/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16628
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16628/index.html
Known issues
Here are the changes found in Patchwork_16628 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [PASS][1] -> [TIMEOUT][2] ([fdo#112271] / [i915#1084]
/ [i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16628/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [INCOMPLETE][3] ([i915#694] / [i915#816]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16628/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][5] ([i915#877]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16628/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- fi-glk-dsi: [TIMEOUT][7] ([fdo#112271] / [i915#690]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-glk-dsi/igt@i915_selftest@live_gtt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16628/fi-glk-dsi/igt@i915_selftest@live_gtt.html
Warnings
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][9] ([fdo#109315] / [i915#585]) -> [SKIP][10]
([fdo#109315])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16628/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#690]: https://gitlab.freedesktop.org/drm/intel/issues/690
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 41)
--
Additional (2): fi-skl-lmem fi-snb-2600
Missing(10): fi-ilk-m540 fi-bdw-samus fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-blb-e6850 fi-byt-clapper fi-skl-6700k2
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7966 -> Patchwork_16628
CI-20190529: 20190529
CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16628: 547528017979d02096d4957b1f838b0f3ccea60e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
547528017979 drm/i915/pmu: Avoid using globals for PMU events
c91c32fb10db drm/i915/pmu: Avoid using globals for CPU hotplug state
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16628/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] dma-buf: add dynamic DMA-buf handling v15
== Series Details == Series: series starting with [1/7] dma-buf: add dynamic DMA-buf handling v15 URL : https://patchwork.freedesktop.org/series/73665/ State : warning == Summary == $ dim checkpatch origin/drm-tip 49072c39a5b6 dma-buf: add dynamic DMA-buf handling v15 -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: called when the importer doesn't implement dynamic handling, move notification -:452: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 2 warnings, 0 checks, 374 lines checked c574d9957711 drm/ttm: remove the backing store if no placement is given -:36: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 18 lines checked 745ab3baba32 drm/amdgpu: use allowed_domains for exported DMA-bufs -:36: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 17 lines checked 4b91a843ed4c drm/amdgpu: add amdgpu_dma_buf_pin/unpin v2 -:125: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 97 lines checked 2d6a296d68e9 drm/amdgpu: implement amdgpu_gem_prime_move_notify v2 -:123: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 97 lines checked 6a48a4358556 dma-buf: drop dynamic_mapping flag -:97: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 65 lines checked ab64183605a5 dma-buf: make move_notify mandatory if importer_ops are provided -:72: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 48 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 7:19 PM Greg Kroah-Hartman wrote: > > On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote: > > Hi Greg, > > > > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > > > quality. The biggest wrong pattern is that developers use devm_, > > > > > > > which > > > > > > > ties the release action to the underlying struct device, whereas > > > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > > > files and mmap'ed buffers). Give people what they want, but with > > > > > > > more > > > > > > > correctness. > > > > > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit > > > > > > > drm_device and > > > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > > > the types don't match code sharing looked like a hopeless > > > > > > > endeavour. > > > > > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > > > actions (but kfree exists, we'll need that soon). Plus all > > > > > > > specific to > > > > > > > drm_device ofc, including the logging. Which I didn't bother to > > > > > > > make > > > > > > > compile-time optional, since none of the other drm logging is > > > > > > > compile > > > > > > > time optional either. > > > > > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > > > allocation registered before drm_dev_init registers any of its own > > > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > > > drm_device is emebedded into the overall structure, and by the > > > > > > > time it > > > > > > > returns it'll all be too late. And forcing drivers to be able > > > > > > > clean up > > > > > > > everything except the one kzalloc is silly. > > > > > > > > > > > > > > Work around this by having a very special final_kfree pointer. > > > > > > > This > > > > > > > also avoids troubles with the list head possibly disappearing from > > > > > > > underneath us when we release all resources attached to the > > > > > > > drm_device. > > > > > > > > > > > > This is all a very good idea ! Many subsystems are plagged by > > > > > > drivers > > > > > > using devm_k*alloc to allocate data accessible by userspace. Since > > > > > > the > > > > > > introduction of devm_*, we've likely reduced the number of memory > > > > > > leaks, > > > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > > > some drivers that used .release() callbacks correctly being naively > > > > > > converted to incorrect devm_* usage :-( > > > > > > > > > > > > This leads me to a question: if other subsystems have the same > > > > > > problem, > > > > > > could we turn this implementation into something more generic ? It > > > > > > doesn't have to be done right away and shouldn't block merging this > > > > > > series, but I think it would be very useful. > > > > > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > > > (driver_memory?) > > > > > > > > > > And yes, I think it's much better than devm_* for the obvious reasons > > > > > of > > > > > this being needed here. > > > > > > > > There's two reasons I went with copypasta instead of trying to share > > > > code: > > > > - Type checking, I definitely don't want people to mix up devm_ with > > > > drmm_. But even if we do a drv_m that subsystems could embed we do > > > > have quite a few different types of component drivers (and with > > > > drm_panel and drm_bridge even standardized), and I don't want people > > > > to be able to pass the wrong kind of struct to e.g. a managed > > > > drmm_connector_init - it really needs to be the drm_device, not a > > > > panel or bridge or something else. > > > > > > Fair enough, that makes sense. > > > > > > > - We could still share the code as a kind of implementation/backend > > > > library. But it's not much, and with embedding I could use the drm > > > > device logging stuff which is kinda nice. But if there's more demand > > > > for this I can definitely see the point in sharing this, as Laurent > > > > pointed out with the tiny optimization with not allocating a NULL void > > > > * that I've done (and screwed up) it's not entirely trivial code. > > > > > > I think moving over time to having this be a backend library is good. > > >
Re: [Intel-gfx] [PATCH 01/52] mm/sl[uo]b: export __kmalloc_track(_node)_caller
On Wed, 19 Feb 2020 11:20:31 +0100 Daniel Vetter wrote: > tracker in drm for stuff that's tied to the lifetime of a drm_device, > not the underlying struct device. Kinda like devres, but for drm. > > ... > > Ack for merging through drm trees very much appreciated. Acked-by: Andrew Morton ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/pmu: Avoid using globals for CPU hotplug state
== Series Details == Series: series starting with [1/2] drm/i915/pmu: Avoid using globals for CPU hotplug state URL : https://patchwork.freedesktop.org/series/73663/ State : warning == Summary == $ dim checkpatch origin/drm-tip c91c32fb10db drm/i915/pmu: Avoid using globals for CPU hotplug state 547528017979 drm/i915/pmu: Avoid using globals for PMU events -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: double free the global state, hitting null ptr deref in free_event_attributes. total: 0 errors, 1 warnings, 0 checks, 108 lines checked ___ 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: make dbuf configurations const
== Series Details ==
Series: drm/i915: make dbuf configurations const
URL : https://patchwork.freedesktop.org/series/73659/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16627
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16627/index.html
Known issues
Here are the changes found in Patchwork_16627 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-bsw-n3050: [PASS][1] -> [INCOMPLETE][2] ([fdo#105876])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16627/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [INCOMPLETE][3] ([i915#45]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16627/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][5] ([i915#877]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16627/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][7] ([i915#585]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16627/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 38)
--
Additional (3): fi-kbl-7560u fi-skl-6600u fi-snb-2600
Missing(14): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy
fi-skl-guc fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-ivb-3770
fi-bsw-kefka fi-byt-clapper fi-bdw-samus fi-kbl-r
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7966 -> Patchwork_16627
CI-20190529: 20190529
CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16627: 1521946da24f338192379c9b079321d232437e76 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1521946da24f drm/i915: make dbuf configurations const
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16627/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/gt: make a gt sysfs group and move power management files
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
The new interfaces are:
gt/gt_act_freq_mhz
gt/gt_boost_freq_mhz
gt/gt_cur_freq_mhz
gt/gt_info
gt/gt_max_freq_mhz
gt/gt_min_freq_mhz
gt/gt_RP0_freq_mhz
gt/gt_RP1_freq_mhz
gt/gt_RPn_freq_mhz
gt/rc6_enable
gt/rc6_residency_ms
The once in the root directory will be marked as deprecated, if
accessed a warning message is printed.
Signed-off-by: Andi Shyti
---
v4 -> v5:
- removed spurious ghost 'vvv' file that was never meant to be
there... sorry for spamming.
v3 -> v4:
- fixed Tvrtko's comments:
- some renaming
- some clumsy unbalanced kobject_put/get
- the warning print is more descriptive and printed with
limited rate
- TODO: drm_print doesn't have a drm_warn_unlimited, to
be added
v2 -> v3:
- fix some cleanups that I forgot in the previous patch
- fix reference pointers to the gt structure
- and many other small changes here and there.
v1 -> v2:
- keep the existing files as they are
- use "intel_gt_*" as prefix instead of "sysfs_*"
drivers/gpu/drm/i915/Makefile| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
drivers/gpu/drm/i915/gt/sysfs_gt.c | 79 +
drivers/gpu/drm/i915/gt/sysfs_gt.h | 22 ++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c| 432 +++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.h| 17 +
drivers/gpu/drm/i915/i915_sysfs.c| 375 +---
drivers/gpu/drm/i915/i915_sysfs.h| 3 +
9 files changed, 561 insertions(+), 375 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b314d44ded5e..ff9e17c97dc2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,7 +107,9 @@ gt-y += \
gt/intel_rps.o \
gt/intel_sseu.o \
gt/intel_timeline.o \
- gt/intel_workarounds.o
+ gt/intel_workarounds.o \
+ gt/sysfs_gt.o \
+ gt/sysfs_gt_pm.o
# autogenerated null render state
gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f1f1b306e0af..e794d05d69a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -15,6 +15,7 @@
#include "intel_rps.h"
#include "intel_uncore.h"
#include "intel_pm.h"
+#include "sysfs_gt.h"
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
{
@@ -321,6 +322,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>rps);
debugfs_gt_register(gt);
+ intel_gt_sysfs_register(gt);
}
static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
@@ -641,6 +643,7 @@ void intel_gt_driver_remove(struct intel_gt *gt)
void intel_gt_driver_unregister(struct intel_gt *gt)
{
+ intel_gt_sysfs_unregister(gt);
intel_rps_driver_unregister(>rps);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 96890dd12b5f..7f0b4f8d9e28 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -32,6 +32,7 @@ struct intel_gt {
struct drm_i915_private *i915;
struct intel_uncore *uncore;
struct i915_ggtt *ggtt;
+ struct kobject sysfs_root;
struct intel_uc uc;
diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c
b/drivers/gpu/drm/i915/gt/sysfs_gt.c
new file mode 100644
index ..9335a92d5248
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/sysfs_gt.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include "../i915_drv.h"
+#include "intel_gt.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+#include "sysfs_gt.h"
+#include "sysfs_gt_pm.h"
+
+static inline struct kobject *gt_get_parent_obj(struct intel_gt *gt)
+{
+ return >i915->drm.primary->kdev->kobj;
+}
+
+static ssize_t gt_info_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ return snprintf(buff, PAGE_SIZE, "0\n");
+}
+
+static DEVICE_ATTR_RO(gt_info);
+
+static struct kobj_type sysfs_gt_ktype = {
+ .sysfs_ops = _sysfs_ops,
+};
+
+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+ struct kobject *parent = kobject_get(gt_get_parent_obj(gt));
+ int ret;
+
+ ret = kobject_init_and_add(>sysfs_root,
+ _gt_ktype,
+
Re: [Intel-gfx] [PATCH v4] drm/i915/gt: make a gt sysfs group and move power management files
> drivers/gpu/drm/i915/Makefile|4 +- > drivers/gpu/drm/i915/gt/intel_gt.c |3 + > drivers/gpu/drm/i915/gt/intel_gt_types.h |1 + > drivers/gpu/drm/i915/gt/sysfs_gt.c | 79 ++ > drivers/gpu/drm/i915/gt/sysfs_gt.h | 22 + > drivers/gpu/drm/i915/gt/sysfs_gt_pm.c| 432 + > drivers/gpu/drm/i915/gt/sysfs_gt_pm.h| 17 + > drivers/gpu/drm/i915/i915_sysfs.c| 375 +-- > drivers/gpu/drm/i915/i915_sysfs.h|3 + > vvv | 1127 ++ ^^^ ops fortunately nothing compromising in it :) Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/pmu: Avoid using globals for per-device state
== Series Details == Series: drm/i915/pmu: Avoid using globals for per-device state URL : https://patchwork.freedesktop.org/series/73658/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16626 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16626 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16626, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16626/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16626: ### IGT changes ### Possible regressions * igt@i915_selftest@live_hugepages: - fi-bwr-2160:[PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-bwr-2160/igt@i915_selftest@live_hugepages.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16626/fi-bwr-2160/igt@i915_selftest@live_hugepages.html Known issues Here are the changes found in Patchwork_16626 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_close_race@basic-threads: - fi-hsw-peppy: [INCOMPLETE][3] ([i915#694] / [i915#816]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16626/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html * igt@i915_selftest@live_gem_contexts: - fi-cml-s: [DMESG-FAIL][5] ([i915#877]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_selftest@live_gem_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16626/fi-cml-s/igt@i915_selftest@live_gem_contexts.html * igt@i915_selftest@live_gtt: - fi-glk-dsi: [TIMEOUT][7] ([fdo#112271] / [i915#690]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-glk-dsi/igt@i915_selftest@live_gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16626/fi-glk-dsi/igt@i915_selftest@live_gtt.html Warnings * igt@amdgpu/amd_prime@amd-to-i915: - fi-icl-u3: [SKIP][9] ([fdo#109315] / [i915#585]) -> [SKIP][10] ([fdo#109315]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16626/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585 [i915#690]: https://gitlab.freedesktop.org/drm/intel/issues/690 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (49 -> 38) -- Additional (1): fi-snb-2600 Missing(12): fi-ilk-m540 fi-tgl-dsi fi-bsw-n3050 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-8109u fi-bsw-kefka fi-byt-n2820 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7966 -> Patchwork_16626 CI-20190529: 20190529 CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16626: bf883c0099c6f41681b2a979afc71d0d746eceba @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == bf883c0099c6 drm/i915/pmu: Avoid using globals for per-device state == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16626/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/gt: make a gt sysfs group and move power management files
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
The new interfaces are:
gt/gt_act_freq_mhz
gt/gt_boost_freq_mhz
gt/gt_cur_freq_mhz
gt/gt_info
gt/gt_max_freq_mhz
gt/gt_min_freq_mhz
gt/gt_RP0_freq_mhz
gt/gt_RP1_freq_mhz
gt/gt_RPn_freq_mhz
gt/rc6_enable
gt/rc6_residency_ms
The once in the root directory will be marked as deprecated, if
accessed a warning message is printed.
Signed-off-by: Andi Shyti
---
v3 -> v4:
- fixed Tvrtko's comments:
- some renaming
- some clumsy unbalanced kobject_put/get
- the warning print is more descriptive and printed with
limited rate
- TODO: drm_print doesn't have a drm_warn_unlimited, to
be added
v2 -> v3:
- fix some cleanups that I forgot in the previous patch
- fix reference pointers to the gt structure
- and many other small changes here and there.
v1 -> v2:
- keep the existing files as they are
- use "intel_gt_*" as prefix instead of "sysfs_*"
drivers/gpu/drm/i915/Makefile|4 +-
drivers/gpu/drm/i915/gt/intel_gt.c |3 +
drivers/gpu/drm/i915/gt/intel_gt_types.h |1 +
drivers/gpu/drm/i915/gt/sysfs_gt.c | 79 ++
drivers/gpu/drm/i915/gt/sysfs_gt.h | 22 +
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c| 432 +
drivers/gpu/drm/i915/gt/sysfs_gt_pm.h| 17 +
drivers/gpu/drm/i915/i915_sysfs.c| 375 +--
drivers/gpu/drm/i915/i915_sysfs.h|3 +
vvv | 1127 ++
10 files changed, 1688 insertions(+), 375 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h
create mode 100644 vvv
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b314d44ded5e..ff9e17c97dc2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,7 +107,9 @@ gt-y += \
gt/intel_rps.o \
gt/intel_sseu.o \
gt/intel_timeline.o \
- gt/intel_workarounds.o
+ gt/intel_workarounds.o \
+ gt/sysfs_gt.o \
+ gt/sysfs_gt_pm.o
# autogenerated null render state
gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f1f1b306e0af..e794d05d69a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -15,6 +15,7 @@
#include "intel_rps.h"
#include "intel_uncore.h"
#include "intel_pm.h"
+#include "sysfs_gt.h"
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
{
@@ -321,6 +322,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>rps);
debugfs_gt_register(gt);
+ intel_gt_sysfs_register(gt);
}
static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
@@ -641,6 +643,7 @@ void intel_gt_driver_remove(struct intel_gt *gt)
void intel_gt_driver_unregister(struct intel_gt *gt)
{
+ intel_gt_sysfs_unregister(gt);
intel_rps_driver_unregister(>rps);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 96890dd12b5f..7f0b4f8d9e28 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -32,6 +32,7 @@ struct intel_gt {
struct drm_i915_private *i915;
struct intel_uncore *uncore;
struct i915_ggtt *ggtt;
+ struct kobject sysfs_root;
struct intel_uc uc;
diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c
b/drivers/gpu/drm/i915/gt/sysfs_gt.c
new file mode 100644
index ..9335a92d5248
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/sysfs_gt.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include "../i915_drv.h"
+#include "intel_gt.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+#include "sysfs_gt.h"
+#include "sysfs_gt_pm.h"
+
+static inline struct kobject *gt_get_parent_obj(struct intel_gt *gt)
+{
+ return >i915->drm.primary->kdev->kobj;
+}
+
+static ssize_t gt_info_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ return snprintf(buff, PAGE_SIZE, "0\n");
+}
+
+static DEVICE_ATTR_RO(gt_info);
+
+static struct kobj_type sysfs_gt_ktype = {
+ .sysfs_ops = _sysfs_ops,
+};
+
+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+ struct kobject *parent = kobject_get(gt_get_parent_obj(gt));
+ int ret;
+
+ ret = kobject_init_and_add(>sysfs_root,
+ _gt_ktype,
+ parent, "gt");
+ if
Re: [Intel-gfx] [PATCH] drm/i915/gt: Protect signaler walk with RCU
On Tue, 18 Feb 2020 at 20:23, Chris Wilson wrote:
>
> While we know that the waiters cannot disappear as we walk our list
> (only that they might be added), the same cannot be said for our
> signalers as they may be completed by the HW and retired as we process
> this request. Ergo we need to use rcu to protect the list iteration and
> remember to mark up the list_del_rcu.
>
> Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new
> waiters")
> Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
> requests")
> Signed-off-by: Chris Wilson
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
> drivers/gpu/drm/i915/i915_scheduler.c | 4 ++--
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index ba31cbe8c68e..47561dc29304 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1668,9 +1668,9 @@ last_active(const struct intel_engine_execlists
> *execlists)
> wait_link)
>
> #define for_each_signaler(p__, rq__) \
> - list_for_each_entry_lockless(p__, \
> -&(rq__)->sched.signalers_list, \
> -signal_link)
> + list_for_each_entry_rcu(p__, \
> + &(rq__)->sched.signalers_list, \
> + signal_link)
>
> static void defer_request(struct i915_request *rq, struct list_head * const
> pl)
> {
> @@ -2533,11 +2533,13 @@ static bool execlists_hold(struct intel_engine_cs
> *engine,
> static bool hold_request(const struct i915_request *rq)
> {
> struct i915_dependency *p;
> + bool result = false;
>
> /*
> * If one of our ancestors is on hold, we must also be on hold,
> * otherwise we will bypass it and execute before it.
> */
> + rcu_read_lock();
> for_each_signaler(p, rq) {
> const struct i915_request *s =
> container_of(p->signaler, typeof(*s), sched);
> @@ -2545,11 +2547,13 @@ static bool hold_request(const struct i915_request
> *rq)
> if (s->engine != rq->engine)
> continue;
>
> - if (i915_request_on_hold(s))
> - return true;
> + result = i915_request_on_hold(s);
> + if (result)
> + break;
> }
> + rcu_read_unlock();
>
> - return false;
> + return result;
> }
>
> static void __execlists_unhold(struct i915_request *rq)
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index e19a37a83397..4e48757e9de6 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -486,7 +486,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
> list_for_each_entry_safe(dep, tmp, >signalers_list,
> signal_link) {
> GEM_BUG_ON(!list_empty(>dfs_link));
>
> - list_del(>wait_link);
> + list_del_rcu(>wait_link);
> if (dep->flags & I915_DEPENDENCY_ALLOC)
> i915_dependency_free(dep);
> }
> @@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
> GEM_BUG_ON(dep->signaler != node);
> GEM_BUG_ON(!list_empty(>dfs_link));
>
> - list_del(>signal_link);
> + list_del_rcu(>signal_link);
> if (dep->flags & I915_DEPENDENCY_ALLOC)
> i915_dependency_free(dep);
Is this not a potential uaf? Do we not have to wait for the grace
period before doing the free, or what?
> }
> --
> 2.25.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Deactive FBC in fastsets when disabled by parameter
On Wed, Feb 19, 2020 at 06:37:27PM +, Souza, Jose wrote: > On Wed, 2020-02-19 at 15:37 +0200, Ville Syrjälä wrote: > > On Tue, Feb 18, 2020 at 05:42:28PM -0800, José Roberto de Souza > > wrote: > > > Most of the kms_frontbuffer_tracking tests disables the feature > > > being > > > tested, draw, get the CRC then enable the feature, draw again, get > > > the > > > CRC and check if it matches. > > > Some times it is able to do that with a fastset, so > > > intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() > > > was > > > not checking if FBC is now enabled in this CRTC leaving FBC active > > > and > > > causing the warning bellow in __intel_fbc_disable() > > > > > > [IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb- > > > multidraw > > > Setting dangerous option enable_fbc - tainting kernel > > > i915 :00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR > > > debug to f > > > i915 :00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug > > > mask f > > > i915 :00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR > > > debug to 1 > > > i915 :00:02.0: [drm:intel_atomic_check [i915]] > > > [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID > > > bpp 24, requested bpp 36, max platform bpp 36 > > > [drm:intel_dp_compute_config [i915]] DP link computation with max > > > lane count 2 max rate 27 max bpp 24 pixel clock 138120KHz > > > [drm:intel_dp_compute_config [i915]] Force DSC en = 0 > > > [drm:intel_dp_compute_config [i915]] DP lane count 2 clock 27 > > > bpp 24 > > > [drm:intel_dp_compute_config [i915]] DP link rate required 414360 > > > available 54 > > > i915 :00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, > > > pipe bpp: 24, dithering: 0 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > [CRTC:91:pipe A] enable: yes [fastset] > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, > > > output_types: EDP (0x100), output format: RGB > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > cpu_transcoder: EDP, pipe bpp: 24, dithering: 0 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: > > > lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: > > > 524288, tu: 64 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, > > > infoframes: 0, infoframes enabled: 0x0 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] requested > > > mode: > > > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 > > > 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted > > > mode: > > > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 > > > 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa > > > [drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 > > > 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: > > > 27, pipe src size: 1920x1080, pixel rate 138120 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: > > > 119, ips linetime: 0 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: > > > 2, scaler_users: 0x0, scaler_id: -1 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: > > > pos: 0x, size: 0x, disabled, force thru: no > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, > > > double wide: 0 > > > [drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, > > > cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, > > > mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, > > > mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, > > > mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: > > > 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] MST master > > > transcoder: > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little- > > > endian (0x34325258), visible: yes > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]]rotatio > > > n: 0x1, scaler: -1 > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]]src: > > > 1920.00x1080.00+0.00+0.00 dst: 1920x1080+0+0 > > > i915 :00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling > > > PSR1 > > > i915 :00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't > > > support DRRS > > > [ cut here ] > > > i915 :00:02.0: drm_WARN_ON(fbc->active) > > > WARNING: CPU: 4 PID: 1175 at > > > drivers/gpu/drm/i915/display/intel_fbc.c:973 > > > __intel_fbc_disable+0xa5/0x130 [i915] > > > Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek > > > snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal
Re: [Intel-gfx] [PATCH 11/52] drm/v3d: Use drmm_add_final_kfree
On Wed, Feb 19, 2020 at 2:21 AM Daniel Vetter wrote: > > With this we can drop the final kfree from the release function. > > I also noticed that the unwind code is wrong, after drm_dev_init the > drm_device owns the v3d allocation, so the kfree(v3d) is a double-free. > Reorder the setup to fix this issue. > > After a bit more prep in drivers and drm core v3d should be able to > switch over to devm_drm_dev_init, which should clean this up further. > > Signed-off-by: Daniel Vetter > Cc: Eric Anholt Acked-by: Eric Anholt ___ 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/userptr: Activate MMU notifier only after pages are set
== Series Details ==
Series: drm/i915/userptr: Activate MMU notifier only after pages are set
URL : https://patchwork.freedesktop.org/series/73652/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16625
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16625/index.html
Known issues
Here are the changes found in Patchwork_16625 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [PASS][1] -> [INCOMPLETE][2] ([i915#45])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16625/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [INCOMPLETE][3] ([i915#694] / [i915#816]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16625/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][5] ([i915#877]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16625/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
Warnings
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][7] ([fdo#109315] / [i915#585]) -> [SKIP][8]
([fdo#109315])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16625/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 38)
--
Additional (3): fi-skl-lmem fi-skl-6600u fi-snb-2600
Missing(14): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bdw-gvtdvm
fi-glk-dsi fi-byt-squawks fi-bwr-2160 fi-ilk-650 fi-bsw-cyan fi-ctg-p8600
fi-gdg-551 fi-byt-clapper fi-bsw-nick fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7966 -> Patchwork_16625
CI-20190529: 20190529
CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16625: 2944b0b1ec9bd79379661df1fcab798caa03bcaf @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2944b0b1ec9b drm/i915/userptr: Activate MMU notifier only after pages are set
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16625/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Deactive FBC in fastsets when disabled by parameter
On Wed, 2020-02-19 at 15:37 +0200, Ville Syrjälä wrote: > On Tue, Feb 18, 2020 at 05:42:28PM -0800, José Roberto de Souza > wrote: > > Most of the kms_frontbuffer_tracking tests disables the feature > > being > > tested, draw, get the CRC then enable the feature, draw again, get > > the > > CRC and check if it matches. > > Some times it is able to do that with a fastset, so > > intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() > > was > > not checking if FBC is now enabled in this CRTC leaving FBC active > > and > > causing the warning bellow in __intel_fbc_disable() > > > > [IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb- > > multidraw > > Setting dangerous option enable_fbc - tainting kernel > > i915 :00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR > > debug to f > > i915 :00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug > > mask f > > i915 :00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR > > debug to 1 > > i915 :00:02.0: [drm:intel_atomic_check [i915]] > > [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID > > bpp 24, requested bpp 36, max platform bpp 36 > > [drm:intel_dp_compute_config [i915]] DP link computation with max > > lane count 2 max rate 27 max bpp 24 pixel clock 138120KHz > > [drm:intel_dp_compute_config [i915]] Force DSC en = 0 > > [drm:intel_dp_compute_config [i915]] DP lane count 2 clock 27 > > bpp 24 > > [drm:intel_dp_compute_config [i915]] DP link rate required 414360 > > available 54 > > i915 :00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, > > pipe bpp: 24, dithering: 0 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > [CRTC:91:pipe A] enable: yes [fastset] > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, > > output_types: EDP (0x100), output format: RGB > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > cpu_transcoder: EDP, pipe bpp: 24, dithering: 0 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: > > lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: > > 524288, tu: 64 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, > > infoframes: 0, infoframes enabled: 0x0 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] requested > > mode: > > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 > > 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted > > mode: > > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 > > 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa > > [drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 > > 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: > > 27, pipe src size: 1920x1080, pixel rate 138120 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: > > 119, ips linetime: 0 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: > > 2, scaler_users: 0x0, scaler_id: -1 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: > > pos: 0x, size: 0x, disabled, force thru: no > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, > > double wide: 0 > > [drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, > > cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, > > mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, > > mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, > > mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: > > 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] MST master > > transcoder: > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little- > > endian (0x34325258), visible: yes > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] rotatio > > n: 0x1, scaler: -1 > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] src: > > 1920.00x1080.00+0.00+0.00 dst: 1920x1080+0+0 > > i915 :00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling > > PSR1 > > i915 :00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't > > support DRRS > > [ cut here ] > > i915 :00:02.0: drm_WARN_ON(fbc->active) > > WARNING: CPU: 4 PID: 1175 at > > drivers/gpu/drm/i915/display/intel_fbc.c:973 > > __intel_fbc_disable+0xa5/0x130 [i915] > > Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek > > snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp > > crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg > > snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether > > e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt > > intel_lpss_pci prime_numbers > >
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote: > Hi Greg, > > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > > quality. The biggest wrong pattern is that developers use devm_, > > > > > > which > > > > > > ties the release action to the underlying struct device, whereas > > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > > files and mmap'ed buffers). Give people what they want, but with > > > > > > more > > > > > > correctness. > > > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device > > > > > > and > > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > > actions (but kfree exists, we'll need that soon). Plus all specific > > > > > > to > > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > > compile-time optional, since none of the other drm logging is > > > > > > compile > > > > > > time optional either. > > > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > > allocation registered before drm_dev_init registers any of its own > > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > > drm_device is emebedded into the overall structure, and by the time > > > > > > it > > > > > > returns it'll all be too late. And forcing drivers to be able clean > > > > > > up > > > > > > everything except the one kzalloc is silly. > > > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > > also avoids troubles with the list head possibly disappearing from > > > > > > underneath us when we release all resources attached to the > > > > > > drm_device. > > > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > > introduction of devm_*, we've likely reduced the number of memory > > > > > leaks, > > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > > some drivers that used .release() callbacks correctly being naively > > > > > converted to incorrect devm_* usage :-( > > > > > > > > > > This leads me to a question: if other subsystems have the same > > > > > problem, > > > > > could we turn this implementation into something more generic ? It > > > > > doesn't have to be done right away and shouldn't block merging this > > > > > series, but I think it would be very useful. > > > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > > (driver_memory?) > > > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > > this being needed here. > > > > > > There's two reasons I went with copypasta instead of trying to share code: > > > - Type checking, I definitely don't want people to mix up devm_ with > > > drmm_. But even if we do a drv_m that subsystems could embed we do > > > have quite a few different types of component drivers (and with > > > drm_panel and drm_bridge even standardized), and I don't want people > > > to be able to pass the wrong kind of struct to e.g. a managed > > > drmm_connector_init - it really needs to be the drm_device, not a > > > panel or bridge or something else. > > > > Fair enough, that makes sense. > > > > > - We could still share the code as a kind of implementation/backend > > > library. But it's not much, and with embedding I could use the drm > > > device logging stuff which is kinda nice. But if there's more demand > > > for this I can definitely see the point in sharing this, as Laurent > > > pointed out with the tiny optimization with not allocating a NULL void > > > * that I've done (and screwed up) it's not entirely trivial code. > > > > I think moving over time to having this be a backend library is good. > > But no rush/issues here with this going in now, it solves a real need > > and we can refactor it later on to try to make it more "bus/class" > > generic as needed. > > >From a type checking point of view, it would then be nice to have a > structure that models a device node, other than just struct device that > is
Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_
On Wed, Feb 19, 2020 at 6:30 PM Noralf Trønnes wrote:
>
>
>
> Den 19.02.2020 17.23, skrev Daniel Vetter:
> > On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> > wrote:
> >>
> >> Hi Daniel,
> >>
> >> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> >>> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
> On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> > drm_mode_config_cleanup is idempotent, so no harm in calling this
> > twice. This allows us to gradually switch drivers over by removing
> > explicit drm_mode_config_cleanup calls.
> >
> > With this step it's not also possible that (at least for simple
> > drivers) automatic resource cleanup can be done correctly without a
> > drm_driver->release hook. Therefore allow this now in
> > devm_drm_dev_init().
> >
> > Also with drmm_ explicit drm_driver->release hooks are kinda not the
> > best option, so deprecate that hook to discourage future users.
> >
> > v2: Fixup the example in the kerneldoc too.
> >
> > Cc: "Noralf Trønnes"
> > Cc: Sam Ravnborg
> > Cc: Thomas Zimmermann
> > Signed-off-by: Daniel Vetter
> > ---
>
>
>
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers/gpu/drm/drm_mode_config.c
> > index 08e6eff6a179..957db1edba0c 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -373,6 +374,11 @@ static int
> > drm_mode_create_standard_properties(struct drm_device *dev)
> > return 0;
> > }
> >
> > +static void drm_mode_config_init_release(struct drm_device *dev, void
> > *ptr)
> > +{
> > + drm_mode_config_cleanup(dev);
> > +}
> > +
> > /**
> > * drm_mode_config_init - initialize DRM mode_configuration structure
> > * @dev: DRM device
> > @@ -384,8 +390,10 @@ static int
> > drm_mode_create_standard_properties(struct drm_device *dev)
> > * problem, since this should happen single threaded at init time. It
> > is the
> > * driver's problem to ensure this guarantee.
> > *
> > + * Cleanup is automatically handled through registering
> > drm_mode_config_cleanup
> > + * with drmm_add_action().
> > */
> > -void drm_mode_config_init(struct drm_device *dev)
> > +int drm_mode_config_init(struct drm_device *dev)
> > {
> > mutex_init(>mode_config.mutex);
> > drm_modeset_lock_init(>mode_config.connection_mutex);
> > @@ -443,6 +451,8 @@ void drm_mode_config_init(struct drm_device *dev)
> > drm_modeset_acquire_fini(_ctx);
> > dma_resv_fini();
> > }
> > +
> > + return drmm_add_action(dev, drm_mode_config_init_release, NULL);
>
> If this fails, shouldn't drm_mode_config_cleanup() be called here ?
> >>>
> >>> Maybe for ocd reasons, but not for actually cleaning up anything. It's
> >>> just a bunch of empty lists that drm_mode_config_cleanup will walk and
> >>> do nothing about. Not sure I should add that ...
> >>
> >> How about the ida init, and the mutex_init() that isn't a no-op when
> >> lock debugging is enabled ?
> >
> > Hm right, I'll fix this.
> >
>
> You could make a drmm_ version of devm_add_action_or_reset() for this.
...
How did I not see that in devres.c. In my defense, I've never written
a driver using devm because of all the lifetime bugs that would cause
in drm, but yes this is exactly what we want here.
Thanks a lot for the pointer, I'll go do some typing!
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: split i915_driver_modeset_probe() to pre/post irq install
== Series Details == Series: drm/i915: split i915_driver_modeset_probe() to pre/post irq install URL : https://patchwork.freedesktop.org/series/73649/ State : success == Summary == CI Bug Log - changes from CI_DRM_7966 -> Patchwork_16624 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16624/index.html Known issues Here are the changes found in Patchwork_16624 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_gtt: - fi-kbl-7500u: [PASS][1] -> [TIMEOUT][2] ([fdo#112271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-kbl-7500u/igt@i915_selftest@live_gtt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16624/fi-kbl-7500u/igt@i915_selftest@live_gtt.html Possible fixes * igt@i915_selftest@live_gem_contexts: - fi-cml-s: [DMESG-FAIL][3] ([i915#877]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-cml-s/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16624/fi-cml-s/igt@i915_selftest@live_gem_contexts.html * igt@i915_selftest@live_gtt: - fi-glk-dsi: [TIMEOUT][5] ([fdo#112271] / [i915#690]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-glk-dsi/igt@i915_selftest@live_gtt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16624/fi-glk-dsi/igt@i915_selftest@live_gtt.html * igt@i915_selftest@live_sanitycheck: - fi-icl-u3: [DMESG-WARN][7] ([i915#585]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7966/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16624/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585 [i915#690]: https://gitlab.freedesktop.org/drm/intel/issues/690 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (49 -> 35) -- Additional (1): fi-snb-2600 Missing(15): fi-ilk-m540 fi-bdw-5557u fi-tgl-dsi fi-bsw-n3050 fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-ivb-3770 fi-blb-e6850 fi-byt-clapper fi-bsw-nick fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7966 -> Patchwork_16624 CI-20190529: 20190529 CI_DRM_7966: 014bfb094e0b4e80d7510dc5d6f45e5e73bbb419 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5451: 1c42f971d37a066da3e588783611ab08d5afbded @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16624: c6fcb662e9c3133e0be1997b152336e08f5c349b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c6fcb662e9c3 drm/i915: split i915_driver_modeset_probe() to pre/post irq install == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16624/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make dbuf configurations const
On Wed, Feb 19, 2020 at 05:45:42PM +0200, Jani Nikula wrote:
> Ensure const data goes to rodata.
>
> Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
> Cc: Matt Roper
> Cc: Stanislav Lisovskiy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Matt Roper
> ---
> 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 ffac0b862ca5..9b74c37e4fa4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4178,7 +4178,7 @@ struct dbuf_slice_conf_entry {
> * as is from BSpec itself - that way it is at least easier
> * to compare, change and check.
> */
> -static struct dbuf_slice_conf_entry icl_allowed_dbufs[] =
> +static const struct dbuf_slice_conf_entry icl_allowed_dbufs[] =
> /* Autogenerated with igt/tools/intel_dbuf_map tool: */
> {
> {
> @@ -4240,7 +4240,7 @@ static struct dbuf_slice_conf_entry icl_allowed_dbufs[]
> =
> * as is from BSpec itself - that way it is at least easier
> * to compare, change and check.
> */
> -static struct dbuf_slice_conf_entry tgl_allowed_dbufs[] =
> +static const struct dbuf_slice_conf_entry tgl_allowed_dbufs[] =
> /* Autogenerated with igt/tools/intel_dbuf_map tool: */
> {
> {
> --
> 2.20.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Greg, On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > quality. The biggest wrong pattern is that developers use devm_, which > > > > > ties the release action to the underlying struct device, whereas > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > files and mmap'ed buffers). Give people what they want, but with more > > > > > correctness. > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > compile-time optional, since none of the other drm logging is compile > > > > > time optional either. > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > allocation registered before drm_dev_init registers any of its own > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > drm_device is emebedded into the overall structure, and by the time it > > > > > returns it'll all be too late. And forcing drivers to be able clean up > > > > > everything except the one kzalloc is silly. > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > also avoids troubles with the list head possibly disappearing from > > > > > underneath us when we release all resources attached to the > > > > > drm_device. > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > introduction of devm_*, we've likely reduced the number of memory leaks, > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > some drivers that used .release() callbacks correctly being naively > > > > converted to incorrect devm_* usage :-( > > > > > > > > This leads me to a question: if other subsystems have the same problem, > > > > could we turn this implementation into something more generic ? It > > > > doesn't have to be done right away and shouldn't block merging this > > > > series, but I think it would be very useful. > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > (driver_memory?) > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > this being needed here. > > > > There's two reasons I went with copypasta instead of trying to share code: > > - Type checking, I definitely don't want people to mix up devm_ with > > drmm_. But even if we do a drv_m that subsystems could embed we do > > have quite a few different types of component drivers (and with > > drm_panel and drm_bridge even standardized), and I don't want people > > to be able to pass the wrong kind of struct to e.g. a managed > > drmm_connector_init - it really needs to be the drm_device, not a > > panel or bridge or something else. > > Fair enough, that makes sense. > > > - We could still share the code as a kind of implementation/backend > > library. But it's not much, and with embedding I could use the drm > > device logging stuff which is kinda nice. But if there's more demand > > for this I can definitely see the point in sharing this, as Laurent > > pointed out with the tiny optimization with not allocating a NULL void > > * that I've done (and screwed up) it's not entirely trivial code. > > I think moving over time to having this be a backend library is good. > But no rush/issues here with this going in now, it solves a real need > and we can refactor it later on to try to make it more "bus/class" > generic as needed. >From a type checking point of view, it would then be nice to have a structure that models a device node, other than just struct device that is shared by all types of devices. As someone who was involve in the creation of the device model we have today, and thus know the history, what's your opinion on that ? -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_
Den 19.02.2020 17.23, skrev Daniel Vetter:
> On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> wrote:
>>
>> Hi Daniel,
>>
>> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
>>> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> drm_mode_config_cleanup is idempotent, so no harm in calling this
> twice. This allows us to gradually switch drivers over by removing
> explicit drm_mode_config_cleanup calls.
>
> With this step it's not also possible that (at least for simple
> drivers) automatic resource cleanup can be done correctly without a
> drm_driver->release hook. Therefore allow this now in
> devm_drm_dev_init().
>
> Also with drmm_ explicit drm_driver->release hooks are kinda not the
> best option, so deprecate that hook to discourage future users.
>
> v2: Fixup the example in the kerneldoc too.
>
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Signed-off-by: Daniel Vetter
> ---
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index 08e6eff6a179..957db1edba0c 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -373,6 +374,11 @@ static int
> drm_mode_create_standard_properties(struct drm_device *dev)
> return 0;
> }
>
> +static void drm_mode_config_init_release(struct drm_device *dev, void
> *ptr)
> +{
> + drm_mode_config_cleanup(dev);
> +}
> +
> /**
> * drm_mode_config_init - initialize DRM mode_configuration structure
> * @dev: DRM device
> @@ -384,8 +390,10 @@ static int
> drm_mode_create_standard_properties(struct drm_device *dev)
> * problem, since this should happen single threaded at init time. It is
> the
> * driver's problem to ensure this guarantee.
> *
> + * Cleanup is automatically handled through registering
> drm_mode_config_cleanup
> + * with drmm_add_action().
> */
> -void drm_mode_config_init(struct drm_device *dev)
> +int drm_mode_config_init(struct drm_device *dev)
> {
> mutex_init(>mode_config.mutex);
> drm_modeset_lock_init(>mode_config.connection_mutex);
> @@ -443,6 +451,8 @@ void drm_mode_config_init(struct drm_device *dev)
> drm_modeset_acquire_fini(_ctx);
> dma_resv_fini();
> }
> +
> + return drmm_add_action(dev, drm_mode_config_init_release, NULL);
If this fails, shouldn't drm_mode_config_cleanup() be called here ?
>>>
>>> Maybe for ocd reasons, but not for actually cleaning up anything. It's
>>> just a bunch of empty lists that drm_mode_config_cleanup will walk and
>>> do nothing about. Not sure I should add that ...
>>
>> How about the ida init, and the mutex_init() that isn't a no-op when
>> lock debugging is enabled ?
>
> Hm right, I'll fix this.
>
You could make a drmm_ version of devm_add_action_or_reset() for this.
Noralf.
> Fun thing is that I've found a pile of missing mutex_destroy and
> ida_cleanup() while reviewing all the code I've read. Not sure I've
> fixed them all up ...
> -Daniel
>
>>
> }
> EXPORT_SYMBOL(drm_mode_config_init);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc
On 2/19/20 12:20 PM, Daniel Vetter wrote: > I also did a full review of all callers, and only the xen driver > forgot to call drm_dev_put in the failure path. Fix that up too. > > v2: I noticed that xen has a drm_driver.release hook, and uses > drm_dev_alloc(). We need to remove the kfree from > xen_drm_drv_release(). > > bochs also has a release hook, but leaked the drm_device ever since > > commit 0a6659bdc5e8221da99eebb176fd9591435e38de > Author: Gerd Hoffmann > Date: Tue Dec 17 18:04:46 2013 +0100 > > drm/bochs: new driver > > This patch here fixes that leak. > > Same for virtio, started leaking with > > commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a > Author: Gerd Hoffmann > Date: Tue Feb 11 14:58:04 2020 +0100 > > drm/virtio: add drm_driver.release callback. > > Cc: Gerd Hoffmann > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > > Signed-off-by: Daniel Vetter Thank you, Reviewed-by: Oleksandr Andrushchenko > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > --- > drivers/gpu/drm/drm_drv.c | 3 +++ > drivers/gpu/drm/xen/xen_drm_front.c | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index 3e5627d6eba6..9e62e28bbc62 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -819,6 +820,8 @@ struct drm_device *drm_dev_alloc(struct drm_driver > *driver, > return ERR_PTR(ret); > } > > + drmm_add_final_kfree(dev, dev); > + > return dev; > } > EXPORT_SYMBOL(drm_dev_alloc); > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 4be49c1aef51..d22b5da38935 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -461,7 +461,6 @@ static void xen_drm_drv_release(struct drm_device *dev) > drm_mode_config_cleanup(dev); > > drm_dev_fini(dev); > - kfree(dev); > > if (front_info->cfg.be_alloc) > xenbus_switch_state(front_info->xb_dev, > @@ -561,6 +560,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info > *front_info) > fail_modeset: > drm_kms_helper_poll_fini(drm_dev); > drm_mode_config_cleanup(drm_dev); > + drm_dev_put(drm_dev); > fail: > kfree(drm_info); > return ret; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 6:02 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote: > > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > > >> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > >>> On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > >> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > >>> We have lots of these. And the cleanup code tends to be of dubious > > >>> quality. The biggest wrong pattern is that developers use devm_, > > >>> which > > >>> ties the release action to the underlying struct device, whereas > > >>> all the userspace visible stuff attached to a drm_device can long > > >>> outlive that one (e.g. after a hotunplug while userspace has open > > >>> files and mmap'ed buffers). Give people what they want, but with > > >>> more > > >>> correctness. > > >>> > > >>> Mostly copied from devres.c, with types adjusted to fit drm_device > > >>> and > > >>> a few simplifications - I didn't (yet) copy over everything. Since > > >>> the types don't match code sharing looked like a hopeless endeavour. > > >>> > > >>> For now it's only super simplified, no groups, you can't remove > > >>> actions (but kfree exists, we'll need that soon). Plus all specific > > >>> to > > >>> drm_device ofc, including the logging. Which I didn't bother to make > > >>> compile-time optional, since none of the other drm logging is > > >>> compile > > >>> time optional either. > > >>> > > >>> One tricky bit here is the chicken between allocating your > > >>> drm_device structure and initiliazing it with drm_dev_init. For > > >>> perfect onion unwinding we'd need to have the action to kfree the > > >>> allocation registered before drm_dev_init registers any of its own > > >>> release handlers. But drm_dev_init doesn't know where exactly the > > >>> drm_device is emebedded into the overall structure, and by the time > > >>> it > > >>> returns it'll all be too late. And forcing drivers to be able clean > > >>> up > > >>> everything except the one kzalloc is silly. > > >>> > > >>> Work around this by having a very special final_kfree pointer. This > > >>> also avoids troubles with the list head possibly disappearing from > > >>> underneath us when we release all resources attached to the > > >>> drm_device. > > >> > > >> This is all a very good idea ! Many subsystems are plagged by drivers > > >> using devm_k*alloc to allocate data accessible by userspace. Since > > >> the > > >> introduction of devm_*, we've likely reduced the number of memory > > >> leaks, > > >> but I'm pretty sure we've increased the risk of crashes as I've seen > > >> some drivers that used .release() callbacks correctly being naively > > >> converted to incorrect devm_* usage :-( > > >> > > >> This leads me to a question: if other subsystems have the same > > >> problem, > > >> could we turn this implementation into something more generic ? It > > >> doesn't have to be done right away and shouldn't block merging this > > >> series, but I think it would be very useful. > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > (driver_memory?) > > > > > > And yes, I think it's much better than devm_* for the obvious reasons > > > of > > > this being needed here. > > > > There's two reasons I went with copypasta instead of trying to share > > code: > > - Type checking, I definitely don't want people to mix up devm_ with > > drmm_. But even if we do a drv_m that subsystems could embed we do > > have quite a few different types of component drivers (and with > > drm_panel and drm_bridge even standardized), and I don't want people > > to be able to pass the wrong kind of struct to e.g. a managed > > drmm_connector_init - it really needs to be the drm_device, not a > > panel or bridge or something else. > > > > - We could still share the code as a kind of implementation/backend > > library. But it's not much, and with embedding I could use the drm > > device logging stuff which is kinda nice. But if there's more demand > > for this I can definitely see the point in sharing this, as Laurent > > pointed out with the tiny optimization with not allocating a NULL void > > * that I've done (and screwed up) it's not entirely trivial code. > > >>> > > >>> My 2c as they say, although closer to a brain dump :-) > > >>> > > >>> On one hand the drm_device has an embedded struct device. On the other > >
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Daniel, On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > >> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > >>> On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > >> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > >>> We have lots of these. And the cleanup code tends to be of dubious > >>> quality. The biggest wrong pattern is that developers use devm_, which > >>> ties the release action to the underlying struct device, whereas > >>> all the userspace visible stuff attached to a drm_device can long > >>> outlive that one (e.g. after a hotunplug while userspace has open > >>> files and mmap'ed buffers). Give people what they want, but with more > >>> correctness. > >>> > >>> Mostly copied from devres.c, with types adjusted to fit drm_device and > >>> a few simplifications - I didn't (yet) copy over everything. Since > >>> the types don't match code sharing looked like a hopeless endeavour. > >>> > >>> For now it's only super simplified, no groups, you can't remove > >>> actions (but kfree exists, we'll need that soon). Plus all specific to > >>> drm_device ofc, including the logging. Which I didn't bother to make > >>> compile-time optional, since none of the other drm logging is compile > >>> time optional either. > >>> > >>> One tricky bit here is the chicken between allocating your > >>> drm_device structure and initiliazing it with drm_dev_init. For > >>> perfect onion unwinding we'd need to have the action to kfree the > >>> allocation registered before drm_dev_init registers any of its own > >>> release handlers. But drm_dev_init doesn't know where exactly the > >>> drm_device is emebedded into the overall structure, and by the time it > >>> returns it'll all be too late. And forcing drivers to be able clean up > >>> everything except the one kzalloc is silly. > >>> > >>> Work around this by having a very special final_kfree pointer. This > >>> also avoids troubles with the list head possibly disappearing from > >>> underneath us when we release all resources attached to the > >>> drm_device. > >> > >> This is all a very good idea ! Many subsystems are plagged by drivers > >> using devm_k*alloc to allocate data accessible by userspace. Since the > >> introduction of devm_*, we've likely reduced the number of memory > >> leaks, > >> but I'm pretty sure we've increased the risk of crashes as I've seen > >> some drivers that used .release() callbacks correctly being naively > >> converted to incorrect devm_* usage :-( > >> > >> This leads me to a question: if other subsystems have the same problem, > >> could we turn this implementation into something more generic ? It > >> doesn't have to be done right away and shouldn't block merging this > >> series, but I think it would be very useful. > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > (driver_memory?) > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > this being needed here. > > There's two reasons I went with copypasta instead of trying to share > code: > - Type checking, I definitely don't want people to mix up devm_ with > drmm_. But even if we do a drv_m that subsystems could embed we do > have quite a few different types of component drivers (and with > drm_panel and drm_bridge even standardized), and I don't want people > to be able to pass the wrong kind of struct to e.g. a managed > drmm_connector_init - it really needs to be the drm_device, not a > panel or bridge or something else. > > - We could still share the code as a kind of implementation/backend > library. But it's not much, and with embedding I could use the drm > device logging stuff which is kinda nice. But if there's more demand > for this I can definitely see the point in sharing this, as Laurent > pointed out with the tiny optimization with not allocating a NULL void > * that I've done (and screwed up) it's not entirely trivial code. > >>> > >>> My 2c as they say, although closer to a brain dump :-) > >>> > >>> On one hand the drm_device has an embedded struct device. On the other > >>> drm_device preserves state which outlives the embedded struct device. > >>> > >>> Would it make sense to keep drm_device better related to the > >>> underlying device? Effectively moving the $misc state to drm_driver. > >>> This idea does raise another question - struct drm_driver unlike many > >>> other struct $foo_driver, does not embedded
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman > wrote: > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > Hi Daniel, > > > > > > Thank you for the patch. > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > quality. The biggest wrong pattern is that developers use devm_, which > > > > ties the release action to the underlying struct device, whereas > > > > all the userspace visible stuff attached to a drm_device can long > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > files and mmap'ed buffers). Give people what they want, but with more > > > > correctness. > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > compile-time optional, since none of the other drm logging is compile > > > > time optional either. > > > > > > > > One tricky bit here is the chicken between allocating your > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > allocation registered before drm_dev_init registers any of its own > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > drm_device is emebedded into the overall structure, and by the time it > > > > returns it'll all be too late. And forcing drivers to be able clean up > > > > everything except the one kzalloc is silly. > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > also avoids troubles with the list head possibly disappearing from > > > > underneath us when we release all resources attached to the > > > > drm_device. > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > introduction of devm_*, we've likely reduced the number of memory leaks, > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > some drivers that used .release() callbacks correctly being naively > > > converted to incorrect devm_* usage :-( > > > > > > This leads me to a question: if other subsystems have the same problem, > > > could we turn this implementation into something more generic ? It > > > doesn't have to be done right away and shouldn't block merging this > > > series, but I think it would be very useful. > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > (driver_memory?) > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > this being needed here. > > There's two reasons I went with copypasta instead of trying to share code: > - Type checking, I definitely don't want people to mix up devm_ with > drmm_. But even if we do a drv_m that subsystems could embed we do > have quite a few different types of component drivers (and with > drm_panel and drm_bridge even standardized), and I don't want people > to be able to pass the wrong kind of struct to e.g. a managed > drmm_connector_init - it really needs to be the drm_device, not a > panel or bridge or something else. Fair enough, that makes sense. > - We could still share the code as a kind of implementation/backend > library. But it's not much, and with embedding I could use the drm > device logging stuff which is kinda nice. But if there's more demand > for this I can definitely see the point in sharing this, as Laurent > pointed out with the tiny optimization with not allocating a NULL void > * that I've done (and screwed up) it's not entirely trivial code. I think moving over time to having this be a backend library is good. But no rush/issues here with this going in now, it solves a real need and we can refactor it later on to try to make it more "bus/class" generic as needed. thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 86000c75b133..1a040ccf61bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -451,7 +451,71 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct
dma_buf *dma_buf)
return ERR_PTR(ret);
}
+/**
+ * amdgpu_dma_buf_move_notify - _notify implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct ttm_operation_ctx ctx = { false, false };
+ struct ttm_placement placement = {};
+ struct amdgpu_vm_bo_base *bo_base;
+ int r;
+
+ if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+ return;
+
+ r = ttm_bo_validate(>tbo, , );
+ if (r) {
+ DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+ return;
+ }
+
+ for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
+ struct amdgpu_vm *vm = bo_base->vm;
+ struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+ if (ticket) {
+ /* When we get an error here it means that somebody
+* else is holding the VM lock and updating page tables
+* So we can just continue here.
+*/
+ r = dma_resv_lock(resv, ticket);
+ if (r)
+ continue;
+
+ } else {
+ /* TODO: This is more problematic and we actually need
+* to allow page tables updates without holding the
+* lock.
+*/
+ if (!dma_resv_trylock(resv))
+ continue;
+ }
+
+ r = amdgpu_vm_clear_freed(adev, vm, NULL);
+ if (!r)
+ r = amdgpu_vm_handle_moved(adev, vm);
+
+ if (r && r != -EBUSY)
+ DRM_ERROR("Failed to invalidate VM page tables (%d))\n",
+ r);
+
+ dma_resv_unlock(resv);
+ }
+}
+
static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+ .move_notify = amdgpu_dma_buf_move_notify
};
/**
@@ -487,7 +551,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
return obj;
attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
- _dma_buf_attach_ops, NULL);
+ _dma_buf_attach_ops, obj);
if (IS_ERR(attach)) {
drm_gem_object_put(obj);
return ERR_CAST(attach);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 9de8374bbbab..5fa8f59c4ccf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -926,6 +926,9 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
return 0;
}
+ if (bo->tbo.base.import_attach)
+ dma_buf_pin(bo->tbo.base.import_attach);
+
bo->flags |= AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
/* force to pin into visible video ram */
if (!(bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS))
@@ -1009,6 +1012,9 @@ int amdgpu_bo_unpin(struct amdgpu_bo *bo)
amdgpu_bo_subtract_pin_size(bo);
+ if (bo->tbo.base.import_attach)
+ dma_buf_unpin(bo->tbo.base.import_attach);
+
for (i = 0; i < bo->placement.num_placement; i++) {
bo->placements[i].lpfn = 0;
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] dma-buf: add dynamic DMA-buf handling v15
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify
v13: add might_lock in appropriate places
v14: rebase on separated locking change
v15: add EXPERIMENTAL flag, some more code comments
Signed-off-by: Christian König
---
drivers/dma-buf/Kconfig | 10 ++
drivers/dma-buf/dma-buf.c | 110 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +-
include/linux/dma-buf.h | 82 +--
4 files changed, 188 insertions(+), 20 deletions(-)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index e7d820ce0724..ef73b678419c 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -39,6 +39,16 @@ config UDMABUF
A driver to let userspace turn memfd regions into dma-bufs.
Qemu can use this to create host dmabufs for guest framebuffers.
+config DMABUF_MOVE_NOTIFY
+ bool "Move notify between drivers (EXPERIMENTAL)"
+ default n
+ help
+ Don''t pin buffers if the dynamic DMA-buf interface is available on
both the
+ exporter as well as the importer. This fixes a security problem where
+ userspace is able to pin unrestricted amounts of memory through
DMA-buf.
+ But marked experimental because we don''t jet have a consistent
execution
+ context and memory management between drivers.
+
config DMABUF_SELFTESTS
tristate "Selftests for the dma-buf interfaces"
default n
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d4097856c86b..5f10d1929476 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -527,6 +527,10 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
exp_info->ops->dynamic_mapping))
return ERR_PTR(-EINVAL);
+ if (WARN_ON(!exp_info->ops->dynamic_mapping &&
+ (exp_info->ops->pin || exp_info->ops->unpin)))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -651,7 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* calls attach() of dma_buf_ops to allow device-specific attach functionality
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
- * @dynamic_mapping: [in]calling convention for map/unmap
+ * @importer_ops [in]importer operations for the attachment
+ * @importer_priv [in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -667,11 +672,13 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
*/
struct dma_buf_attachment *
dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
- bool dynamic_mapping)
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
+ /* TODO: make move_notify mandatory if importer_ops are provided. */
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
@@ -681,7 +688,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
attach->dev = dev;
attach->dmabuf = dmabuf;
- attach->dynamic_mapping = dynamic_mapping;
+ attach->importer_ops = importer_ops;
+ attach->importer_priv = importer_priv;
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, attach);
@@ -700,15 +708,19 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
- if
[Intel-gfx] [PATCH 6/7] dma-buf: drop dynamic_mapping flag
Instead use the pin() callback to detect dynamic DMA-buf handling.
Since amdgpu is now migrated it doesn't make much sense to keep
the extra flag.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 5 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 1 -
include/linux/dma-buf.h | 21 +
3 files changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5f10d1929476..6d0a82d1b23d 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -524,11 +524,10 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
}
if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
- exp_info->ops->dynamic_mapping))
+ (exp_info->ops->pin || exp_info->ops->unpin)))
return ERR_PTR(-EINVAL);
- if (WARN_ON(!exp_info->ops->dynamic_mapping &&
- (exp_info->ops->pin || exp_info->ops->unpin)))
+ if (WARN_ON(!exp_info->ops->pin != !exp_info->ops->unpin))
return ERR_PTR(-EINVAL);
if (!try_module_get(exp_info->owner))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 1a040ccf61bf..ffeb20f11c07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -364,7 +364,6 @@ static int amdgpu_dma_buf_begin_cpu_access(struct dma_buf
*dma_buf,
}
const struct dma_buf_ops amdgpu_dmabuf_ops = {
- .dynamic_mapping = true,
.attach = amdgpu_dma_buf_attach,
.detach = amdgpu_dma_buf_detach,
.pin = amdgpu_dma_buf_pin,
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index b38cea240b67..1ade486fc2bb 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -42,18 +42,6 @@ struct dma_buf_ops {
*/
bool cache_sgt_mapping;
- /**
-* @dynamic_mapping:
-*
-* If true the framework makes sure that the map/unmap_dma_buf
-* callbacks are always called with the dma_resv object locked.
-*
-* If false the framework makes sure that the map/unmap_dma_buf
-* callbacks are always called without the dma_resv object locked.
-* Mutual exclusive with @cache_sgt_mapping.
-*/
- bool dynamic_mapping;
-
/**
* @attach:
*
@@ -99,7 +87,8 @@ struct dma_buf_ops {
* This is called by dma_buf_pin and lets the exporter know that the
* DMA-buf can't be moved any more.
*
-* This is called with the dmabuf->resv object locked.
+* This is called with the dmabuf->resv object locked and is mutual
+* exclusive with @cache_sgt_mapping.
*
* This callback is optional and should only be used in limited use
* cases like scanout and not for temporary pin operations.
@@ -116,7 +105,8 @@ struct dma_buf_ops {
* This is called by dma_buf_unpin and lets the exporter know that the
* DMA-buf can be moved again.
*
-* This is called with the dmabuf->resv object locked.
+* This is called with the dmabuf->resv object locked and is mutual
+* exclusive with @cache_sgt_mapping.
*
* This callback is optional.
*/
@@ -455,8 +445,7 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
*/
static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
{
- /* TODO: switch to using pin/unpin functions as indicator. */
- return dmabuf->ops->dynamic_mapping;
+ return !!dmabuf->ops->pin;
}
/**
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/ttm: remove the backing store if no placement is given
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 151edfd8de77..6d1e91be9c78 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1196,6 +1196,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
dma_resv_assert_held(bo->base.resv);
+
+ /*
+* Remove the backing store if no placement is given.
+*/
+ if (!placement->num_placement && !placement->num_busy_placement) {
+ ret = ttm_bo_pipeline_gutting(bo);
+ if (ret)
+ return ret;
+
+ return ttm_tt_create(bo, false);
+ }
+
/*
* Check whether we need to move buffer.
*/
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/amdgpu: add amdgpu_dma_buf_pin/unpin v2
This implements the exporter side of unpinned DMA-buf handling.
v2: fix minor coding style issues
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 53 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++
2 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 7cafc65fd76a..86000c75b133 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -222,6 +222,37 @@ static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
bo->prime_shared_count--;
}
+/**
+ * amdgpu_dma_buf_pin - _buf_ops.pin implementation
+ *
+ * @attach: attachment to pin down
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ /* pin buffer into GTT */
+ return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_dma_buf_unpin - _buf_ops.unpin implementation
+ *
+ * @attach: attachment to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ amdgpu_bo_unpin(bo);
+}
+
/**
* amdgpu_dma_buf_map - _buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
@@ -244,9 +275,19 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
struct sg_table *sgt;
long r;
- r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
- if (r)
- return ERR_PTR(r);
+ if (!bo->pin_count) {
+ /* move buffer into GTT */
+ struct ttm_operation_ctx ctx = { false, false };
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ r = ttm_bo_validate(>tbo, >placement, );
+ if (r)
+ return ERR_PTR(r);
+
+ } else if (!(amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type) &
+AMDGPU_GEM_DOMAIN_GTT)) {
+ return ERR_PTR(-EBUSY);
+ }
sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
if (IS_ERR(sgt))
@@ -277,13 +318,9 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment
*attach,
struct sg_table *sgt,
enum dma_data_direction dir)
{
- struct drm_gem_object *obj = attach->dmabuf->priv;
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-
dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
sg_free_table(sgt);
kfree(sgt);
- amdgpu_bo_unpin(bo);
}
/**
@@ -330,6 +367,8 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
.dynamic_mapping = true,
.attach = amdgpu_dma_buf_attach,
.detach = amdgpu_dma_buf_detach,
+ .pin = amdgpu_dma_buf_pin,
+ .unpin = amdgpu_dma_buf_unpin,
.map_dma_buf = amdgpu_dma_buf_map,
.unmap_dma_buf = amdgpu_dma_buf_unmap,
.release = drm_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e3f16b49e970..9de8374bbbab 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
*/
#include
#include
+#include
#include
#include
@@ -1274,6 +1275,10 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
amdgpu_bo_kunmap(abo);
+ if (abo->tbo.base.dma_buf && !abo->tbo.base.import_attach &&
+ bo->mem.mem_type != TTM_PL_SYSTEM)
+ dma_buf_move_notify(abo->tbo.base.dma_buf);
+
/* remember the eviction */
if (evict)
atomic64_inc(>num_evictions);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/amdgpu: use allowed_domains for exported DMA-bufs
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index a52a084158b1..41bd2dad842c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -415,7 +416,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
/* Don't move this buffer if we have depleted our allowance
* to move it. Don't move anything if the threshold is zero.
*/
- if (p->bytes_moved < p->bytes_moved_threshold) {
+ if (p->bytes_moved < p->bytes_moved_threshold &&
+ (!bo->tbo.base.dma_buf ||
+ list_empty(>tbo.base.dma_buf->attachments))) {
if (!amdgpu_gmc_vram_full_visible(>gmc) &&
(bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
/* And don't move a CPU_ACCESS_REQUIRED BO to limited
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] dma-buf: make move_notify mandatory if importer_ops are provided
This makes the move_notify callback mandatory when the importer_ops are
provided. Since amdgpu is now migrated it doesn't make much sense
anymore to allow this.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6d0a82d1b23d..f4ace9af2191 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -677,10 +677,12 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
struct dma_buf_attachment *attach;
int ret;
- /* TODO: make move_notify mandatory if importer_ops are provided. */
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
+ if (WARN_ON(importer_ops && !importer_ops->move_notify))
+ return ERR_PTR(-EINVAL);
+
attach = kzalloc(sizeof(*attach), GFP_KERNEL);
if (!attach)
return ERR_PTR(-ENOMEM);
@@ -877,8 +879,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (dma_buf_is_dynamic(attach->dmabuf)) {
dma_resv_assert_held(attach->dmabuf->resv);
- if (!attach->importer_ops->move_notify ||
- !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
+ if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
r = dma_buf_pin(attach);
if (r)
return ERR_PTR(r);
@@ -890,8 +891,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
sg_table = ERR_PTR(-ENOMEM);
if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) &&
- (!attach->importer_ops->move_notify ||
-!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)))
+!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
dma_buf_unpin(attach);
if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
@@ -934,8 +934,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
if (dma_buf_is_dynamic(attach->dmabuf) &&
- (!attach->importer_ops->move_notify ||
-!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)))
+ !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
dma_buf_unpin(attach);
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
@@ -955,7 +954,7 @@ void dma_buf_move_notify(struct dma_buf *dmabuf)
dma_resv_assert_held(dmabuf->resv);
list_for_each_entry(attach, >attachments, node)
- if (attach->importer_ops && attach->importer_ops->move_notify)
+ if (attach->importer_ops)
attach->importer_ops->move_notify(attach);
}
EXPORT_SYMBOL_GPL(dma_buf_move_notify);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > >> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > >>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > We have lots of these. And the cleanup code tends to be of dubious > > > quality. The biggest wrong pattern is that developers use devm_, which > > > ties the release action to the underlying struct device, whereas > > > all the userspace visible stuff attached to a drm_device can long > > > outlive that one (e.g. after a hotunplug while userspace has open > > > files and mmap'ed buffers). Give people what they want, but with more > > > correctness. > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > a few simplifications - I didn't (yet) copy over everything. Since > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > For now it's only super simplified, no groups, you can't remove > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > drm_device ofc, including the logging. Which I didn't bother to make > > > compile-time optional, since none of the other drm logging is compile > > > time optional either. > > > > > > One tricky bit here is the chicken between allocating your > > > drm_device structure and initiliazing it with drm_dev_init. For > > > perfect onion unwinding we'd need to have the action to kfree the > > > allocation registered before drm_dev_init registers any of its own > > > release handlers. But drm_dev_init doesn't know where exactly the > > > drm_device is emebedded into the overall structure, and by the time it > > > returns it'll all be too late. And forcing drivers to be able clean up > > > everything except the one kzalloc is silly. > > > > > > Work around this by having a very special final_kfree pointer. This > > > also avoids troubles with the list head possibly disappearing from > > > underneath us when we release all resources attached to the > > > drm_device. > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > using devm_k*alloc to allocate data accessible by userspace. Since the > > introduction of devm_*, we've likely reduced the number of memory > > leaks, > > but I'm pretty sure we've increased the risk of crashes as I've seen > > some drivers that used .release() callbacks correctly being naively > > converted to incorrect devm_* usage :-( > > > > This leads me to a question: if other subsystems have the same problem, > > could we turn this implementation into something more generic ? It > > doesn't have to be done right away and shouldn't block merging this > > series, but I think it would be very useful. > > >>> > > >>> It shouldn't be that hard to tie this into a drv_m() type of a thing > > >>> (driver_memory?) > > >>> > > >>> And yes, I think it's much better than devm_* for the obvious reasons of > > >>> this being needed here. > > >> > > >> There's two reasons I went with copypasta instead of trying to share > > >> code: > > >> - Type checking, I definitely don't want people to mix up devm_ with > > >> drmm_. But even if we do a drv_m that subsystems could embed we do > > >> have quite a few different types of component drivers (and with > > >> drm_panel and drm_bridge even standardized), and I don't want people > > >> to be able to pass the wrong kind of struct to e.g. a managed > > >> drmm_connector_init - it really needs to be the drm_device, not a > > >> panel or bridge or something else. > > >> > > >> - We could still share the code as a kind of implementation/backend > > >> library. But it's not much, and with embedding I could use the drm > > >> device logging stuff which is kinda nice. But if there's more demand > > >> for this I can definitely see the point in sharing this, as Laurent > > >> pointed out with the tiny optimization with not allocating a NULL void > > >> * that I've done (and screwed up) it's not entirely trivial code. > > > > > > My 2c as they say, although closer to a brain dump :-) > > > > > > On one hand the drm_device has an embedded struct device. On the other > > > drm_device preserves state which outlives the embedded struct device. > > > > > > Would it make sense to keep drm_device better related to the > > > underlying device? Effectively moving the $misc state to drm_driver. > > > This idea does raise another question - struct drm_driver unlike many > > > other struct $foo_driver, does not embedded device_driver :-( > > > So if one is to cover the above two,
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Daniel, On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > >> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > >>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers use devm_, which > > ties the release action to the underlying struct device, whereas > > all the userspace visible stuff attached to a drm_device can long > > outlive that one (e.g. after a hotunplug while userspace has open > > files and mmap'ed buffers). Give people what they want, but with more > > correctness. > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > a few simplifications - I didn't (yet) copy over everything. Since > > the types don't match code sharing looked like a hopeless endeavour. > > > > For now it's only super simplified, no groups, you can't remove > > actions (but kfree exists, we'll need that soon). Plus all specific to > > drm_device ofc, including the logging. Which I didn't bother to make > > compile-time optional, since none of the other drm logging is compile > > time optional either. > > > > One tricky bit here is the chicken between allocating your > > drm_device structure and initiliazing it with drm_dev_init. For > > perfect onion unwinding we'd need to have the action to kfree the > > allocation registered before drm_dev_init registers any of its own > > release handlers. But drm_dev_init doesn't know where exactly the > > drm_device is emebedded into the overall structure, and by the time it > > returns it'll all be too late. And forcing drivers to be able clean up > > everything except the one kzalloc is silly. > > > > Work around this by having a very special final_kfree pointer. This > > also avoids troubles with the list head possibly disappearing from > > underneath us when we release all resources attached to the > > drm_device. > > This is all a very good idea ! Many subsystems are plagged by drivers > using devm_k*alloc to allocate data accessible by userspace. Since the > introduction of devm_*, we've likely reduced the number of memory leaks, > but I'm pretty sure we've increased the risk of crashes as I've seen > some drivers that used .release() callbacks correctly being naively > converted to incorrect devm_* usage :-( > > This leads me to a question: if other subsystems have the same problem, > could we turn this implementation into something more generic ? It > doesn't have to be done right away and shouldn't block merging this > series, but I think it would be very useful. > >>> > >>> It shouldn't be that hard to tie this into a drv_m() type of a thing > >>> (driver_memory?) > >>> > >>> And yes, I think it's much better than devm_* for the obvious reasons of > >>> this being needed here. > >> > >> There's two reasons I went with copypasta instead of trying to share code: > >> - Type checking, I definitely don't want people to mix up devm_ with > >> drmm_. But even if we do a drv_m that subsystems could embed we do > >> have quite a few different types of component drivers (and with > >> drm_panel and drm_bridge even standardized), and I don't want people > >> to be able to pass the wrong kind of struct to e.g. a managed > >> drmm_connector_init - it really needs to be the drm_device, not a > >> panel or bridge or something else. > >> > >> - We could still share the code as a kind of implementation/backend > >> library. But it's not much, and with embedding I could use the drm > >> device logging stuff which is kinda nice. But if there's more demand > >> for this I can definitely see the point in sharing this, as Laurent > >> pointed out with the tiny optimization with not allocating a NULL void > >> * that I've done (and screwed up) it's not entirely trivial code. > > > > My 2c as they say, although closer to a brain dump :-) > > > > On one hand the drm_device has an embedded struct device. On the other > > drm_device preserves state which outlives the embedded struct device. > > > > Would it make sense to keep drm_device better related to the > > underlying device? Effectively moving the $misc state to drm_driver. > > This idea does raise another question - struct drm_driver unlike many > > other struct $foo_driver, does not embedded device_driver :-( > > So if one is to cover the above two, then the embedding concerns will > > be elevated. > > drm_driver isn't a bus device driver in the linux driver model sense, > but an uapi thing that sits on top of some underlying device. So maybe > better to rename drm_driver to
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx
== Series Details == Series: drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx URL : https://patchwork.freedesktop.org/series/73647/ State : success == Summary == CI Bug Log - changes from CI_DRM_7965 -> Patchwork_16623 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16623/index.html Known issues Here are the changes found in Patchwork_16623 that come from known issues: ### IGT changes ### Issues hit * igt@gem_close_race@basic-threads: - fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7965/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16623/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html Possible fixes * igt@gem_close_race@basic-threads: - fi-byt-n2820: [INCOMPLETE][3] ([i915#45]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7965/fi-byt-n2820/igt@gem_close_r...@basic-threads.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16623/fi-byt-n2820/igt@gem_close_r...@basic-threads.html Warnings * igt@gem_close_race@basic-threads: - fi-byt-j1900: [INCOMPLETE][5] ([i915#45]) -> [TIMEOUT][6] ([fdo#112271] / [i915#1084] / [i915#816]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7965/fi-byt-j1900/igt@gem_close_r...@basic-threads.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16623/fi-byt-j1900/igt@gem_close_r...@basic-threads.html [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084 [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816 Participating hosts (51 -> 44) -- Additional (1): fi-pnv-d510 Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7965 -> Patchwork_16623 CI-20190529: 20190529 CI_DRM_7965: e2896d5957301e0411d7048e724d4dc5c96450ea @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5450: dfba090e720ed4e043158887f1ba6a76059491e8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16623: cbbae23f65cbcaffbc4f45fb131b067a047a3ed4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cbbae23f65cb drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16623/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, 19 Feb 2020 at 16:22, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > > > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > > Hi Daniel, > > > > > > > > > > Thank you for the patch. > > > > > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > > quality. The biggest wrong pattern is that developers use devm_, > > > > > > which > > > > > > ties the release action to the underlying struct device, whereas > > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > > files and mmap'ed buffers). Give people what they want, but with > > > > > > more > > > > > > correctness. > > > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device > > > > > > and > > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > > actions (but kfree exists, we'll need that soon). Plus all specific > > > > > > to > > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > > compile-time optional, since none of the other drm logging is > > > > > > compile > > > > > > time optional either. > > > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > > allocation registered before drm_dev_init registers any of its own > > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > > drm_device is emebedded into the overall structure, and by the time > > > > > > it > > > > > > returns it'll all be too late. And forcing drivers to be able clean > > > > > > up > > > > > > everything except the one kzalloc is silly. > > > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > > also avoids troubles with the list head possibly disappearing from > > > > > > underneath us when we release all resources attached to the > > > > > > drm_device. > > > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > > introduction of devm_*, we've likely reduced the number of memory > > > > > leaks, > > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > > some drivers that used .release() callbacks correctly being naively > > > > > converted to incorrect devm_* usage :-( > > > > > > > > > > This leads me to a question: if other subsystems have the same > > > > > problem, > > > > > could we turn this implementation into something more generic ? It > > > > > doesn't have to be done right away and shouldn't block merging this > > > > > series, but I think it would be very useful. > > > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > > (driver_memory?) > > > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > > this being needed here. > > > > > > There's two reasons I went with copypasta instead of trying to share code: > > > - Type checking, I definitely don't want people to mix up devm_ with > > > drmm_. But even if we do a drv_m that subsystems could embed we do > > > have quite a few different types of component drivers (and with > > > drm_panel and drm_bridge even standardized), and I don't want people > > > to be able to pass the wrong kind of struct to e.g. a managed > > > drmm_connector_init - it really needs to be the drm_device, not a > > > panel or bridge or something else. > > > > > > - We could still share the code as a kind of implementation/backend > > > library. But it's not much, and with embedding I could use the drm > > > device logging stuff which is kinda nice. But if there's more demand > > > for this I can definitely see the point in sharing this, as Laurent > > > pointed out with the tiny optimization with not allocating a NULL void > > > * that I've done (and screwed up) it's not entirely trivial code. > > > > > > > My 2c as they say, although closer to a brain dump :-) > > > > On one hand the drm_device has an embedded struct device. On the other > > drm_device preserves state which outlives the embedded struct device. > > > > Would it make sense to keep drm_device better related to the > > underlying device? Effectively moving the $misc state to drm_driver. > > This idea does raise
