[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove unecessary check for unsupported modifiers for NV12
== Series Details == Series: drm/i915: Remove unecessary check for unsupported modifiers for NV12 URL : https://patchwork.freedesktop.org/series/45548/ State : warning == Summary == $ dim checkpatch origin/drm-tip ba24b4784bad drm/i915: Remove unecessary check for unsupported modifiers for NV12 -:4: WARNING:TYPO_SPELLING: 'unecessary' may be misspelled - perhaps 'unnecessary'? #4: Subject: [PATCH] drm/i915: Remove unecessary check for unsupported modifiers total: 0 errors, 1 warnings, 0 checks, 11 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Remove support for legacy debugfs crc interface
This interface is deprecated, and has been replaced by the upstream
drm crc interface.
Signed-off-by: Maarten Lankhorst
Cc: Tomi Sarvela
Cc: Petri Latvala
Cc: Jani Nikula
Cc: Ville Syrjälä
Acked-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 11 +-
drivers/gpu/drm/i915/i915_irq.c | 79 ++---
drivers/gpu/drm/i915/intel_drv.h | 2 -
drivers/gpu/drm/i915/intel_pipe_crc.c | 445 --
5 files changed, 24 insertions(+), 520 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c400f42a54ec..b753d50b013b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4799,7 +4799,6 @@ static const struct i915_debugfs_files {
#endif
{"i915_fifo_underrun_reset", &i915_fifo_underrun_reset_ops},
{"i915_next_seqno", &i915_next_seqno_fops},
- {"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
{"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
{"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
{"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
@@ -4819,7 +4818,7 @@ int i915_debugfs_register(struct drm_i915_private
*dev_priv)
{
struct drm_minor *minor = dev_priv->drm.primary;
struct dentry *ent;
- int ret, i;
+ int i;
ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
minor->debugfs_root, to_i915(minor->dev),
@@ -4827,10 +4826,6 @@ int i915_debugfs_register(struct drm_i915_private
*dev_priv)
if (!ent)
return -ENOMEM;
- ret = intel_pipe_crc_create(minor);
- if (ret)
- return ret;
-
for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
ent = debugfs_create_file(i915_debugfs_files[i].name,
S_IRUGO | S_IWUSR,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b684f431c60..298b6497cdc5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1276,20 +1276,11 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_MAX,
};
-struct intel_pipe_crc_entry {
- uint32_t frame;
- uint32_t crc[5];
-};
-
#define INTEL_PIPE_CRC_ENTRIES_NR 128
struct intel_pipe_crc {
spinlock_t lock;
- bool opened;/* exclusive access to the result file */
- struct intel_pipe_crc_entry *entries;
- enum intel_pipe_crc_source source;
- int head, tail;
- wait_queue_head_t wq;
int skipped;
+ enum intel_pipe_crc_source source;
};
struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 46aaef5c1851..08928830fa03 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1703,69 +1703,34 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
uint32_t crc4)
{
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
- struct intel_pipe_crc_entry *entry;
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
- struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
- int head, tail;
spin_lock(&pipe_crc->lock);
- if (pipe_crc->source && !crtc->base.crc.opened) {
- if (!pipe_crc->entries) {
- spin_unlock(&pipe_crc->lock);
- DRM_DEBUG_KMS("spurious interrupt\n");
- return;
- }
-
- head = pipe_crc->head;
- tail = pipe_crc->tail;
-
- if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
- spin_unlock(&pipe_crc->lock);
- DRM_ERROR("CRC buffer overflowing\n");
- return;
- }
-
- entry = &pipe_crc->entries[head];
-
- entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
- entry->crc[0] = crc0;
- entry->crc[1] = crc1;
- entry->crc[2] = crc2;
- entry->crc[3] = crc3;
- entry->crc[4] = crc4;
-
- head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
- pipe_crc->head = head;
-
- spin_unlock(&pipe_crc->lock);
-
- wake_up_interruptible(&pipe_crc->wq);
- } else {
- /*
-* For some not yet identified reason, the first CRC is
-* bonkers. So let's just wait for the next vblank and read
-* out the buggy result.
-*
-* On GEN8+ sometimes the second CRC is bonkers as well, so
-* don't trust that one either.
-*/
- if (pipe_crc->skipp
[Intel-gfx] [PATCH 2/2] drm/i915: Replace use of pipe_crc->lock with an atomic
pipe_crc->lock only protects pipe_crc->skipped. Replace the lock with
atomic operations instead, it should work just as well, without the
spinlock. In the case we don't skip CRC in the irq, the fastpath is
only a single atomic_read().
Signed-off-by: Maarten Lankhorst
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_irq.c | 15 ---
drivers/gpu/drm/i915/intel_pipe_crc.c | 20 +++-
4 files changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0db3c83cce29..5ad69b488d2a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -923,7 +923,6 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
- intel_display_crc_init(dev_priv);
intel_detect_preproduction_hw(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 298b6497cdc5..a8961adde497 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1278,8 +1278,7 @@ enum intel_pipe_crc_source {
#define INTEL_PIPE_CRC_ENTRIES_NR 128
struct intel_pipe_crc {
- spinlock_t lock;
- int skipped;
+ atomic_t skipped;
enum intel_pipe_crc_source source;
};
@@ -3335,12 +3334,10 @@ u32 i915_gem_fence_alignment(struct drm_i915_private
*dev_priv, u32 size,
#ifdef CONFIG_DEBUG_FS
int i915_debugfs_register(struct drm_i915_private *dev_priv);
int i915_debugfs_connector_add(struct drm_connector *connector);
-void intel_display_crc_init(struct drm_i915_private *dev_priv);
#else
static inline int i915_debugfs_register(struct drm_i915_private *dev_priv)
{return 0;}
static inline int i915_debugfs_connector_add(struct drm_connector *connector)
{ return 0; }
-static inline void intel_display_crc_init(struct drm_i915_private *dev_priv) {}
#endif
const char *i915_cache_level_str(struct drm_i915_private *i915, int type);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 08928830fa03..5688cf1e1225 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1705,8 +1705,8 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
uint32_t crcs[5];
+ int to_skip;
- spin_lock(&pipe_crc->lock);
/*
* For some not yet identified reason, the first CRC is
* bonkers. So let's just wait for the next vblank and read
@@ -1715,13 +1715,14 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
* On GEN8+ sometimes the second CRC is bonkers as well, so
* don't trust that one either.
*/
- if (pipe_crc->skipped <= 0 ||
- (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
- pipe_crc->skipped++;
- spin_unlock(&pipe_crc->lock);
+
+ if (INTEL_GEN(dev_priv) >= 8)
+ to_skip = 2;
+ else
+ to_skip = 1;
+
+ if (atomic_add_unless(&pipe_crc->skipped, 1, to_skip))
return;
- }
- spin_unlock(&pipe_crc->lock);
crcs[0] = crc0;
crcs[1] = crc1;
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 849e1b69ba73..25ec1c2a64b7 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -457,17 +457,6 @@ display_crc_ctl_parse_source(const char *buf, enum
intel_pipe_crc_source *s)
return 0;
}
-void intel_display_crc_init(struct drm_i915_private *dev_priv)
-{
- enum pipe pipe;
-
- for_each_pipe(dev_priv, pipe) {
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
-
- spin_lock_init(&pipe_crc->lock);
- }
-}
-
int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
size_t *values_cnt)
{
@@ -507,7 +496,7 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, const
char *source_name,
hsw_pipe_A_crc_wa(dev_priv, false);
}
- pipe_crc->skipped = 0;
+ atomic_set(&pipe_crc->skipped, 0);
*values_cnt = 5;
out:
@@ -529,8 +518,7 @@ void intel_crtc_enable_pipe_crc(struct intel_crtc
*intel_crtc)
if (get_new_crc_ctl_reg(dev_priv, crtc->index, &pipe_crc->source, &val,
false) < 0)
return;
- /* Don't need pipe_crc->lock here, IRQs are not generated. */
- pipe_crc->skipped = 0;
+ atomic_set(&pipe_crc->skipped, 0);
I915_WRITE(PIPE_CRC_CTL(crtc->index), val);
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unecessary check for unsupported modifiers for NV12
== Series Details == Series: drm/i915: Remove unecessary check for unsupported modifiers for NV12 URL : https://patchwork.freedesktop.org/series/45548/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4395 -> Patchwork_9458 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45548/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9458 that come from known issues: === IGT changes === Issues hit igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: PASS -> FAIL (fdo#103841) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927) fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (43 -> 39) == Additional (1): fi-bxt-dsi Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4395 -> Patchwork_9458 CI_DRM_4395: 90dc6e8ebc4152ea9f146c023b06f15371cbb244 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9458: ba24b4784badf884cc39c6a5e151f73666b9170c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ba24b4784bad drm/i915: Remove unecessary check for unsupported modifiers for NV12 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9458/issues.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/2] drm/i915: Remove support for legacy debugfs crc interface
== Series Details == Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs crc interface URL : https://patchwork.freedesktop.org/series/45553/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6428445ab929 drm/i915: Remove support for legacy debugfs crc interface -:168: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #168: FILE: drivers/gpu/drm/i915/i915_irq.c:1769: + drm_crtc_add_crc_entry(&crtc->base, true, + drm_crtc_accurate_vblank_count(&crtc->base), total: 0 errors, 0 warnings, 1 checks, 626 lines checked 107c66964ccb drm/i915: Replace use of pipe_crc->lock with an atomic ___ 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/2] drm/i915: Remove support for legacy debugfs crc interface
== Series Details == Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs crc interface URL : https://patchwork.freedesktop.org/series/45553/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Remove support for legacy debugfs crc interface -drivers/gpu/drm/i915/selftests/../i915_drv.h:3672:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3663:16: warning: expression using sizeof(void) -./include/linux/slab.h:631:13: error: undefined identifier '__builtin_mul_overflow' -./include/linux/slab.h:631:13: warning: call with no type! Commit: drm/i915: Replace use of pipe_crc->lock with an atomic -drivers/gpu/drm/i915/selftests/../i915_drv.h:3663:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression using sizeof(void) ___ 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: Remove support for legacy debugfs crc interface
== Series Details == Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs crc interface URL : https://patchwork.freedesktop.org/series/45553/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9459 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45553/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9459 that come from known issues: === IGT changes === Issues hit igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-hsw-4200u == Build changes == * Linux: CI_DRM_4396 -> Patchwork_9459 CI_DRM_4396: dd5f49f9686f412baa426502d417ac74a37fc77e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9459: 107c66964ccb63a1faf7cde7381cd533ddd8b237 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 107c66964ccb drm/i915: Replace use of pipe_crc->lock with an atomic 6428445ab929 drm/i915: Remove support for legacy debugfs crc interface == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9459/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Reduce spinlock hold time during notify_ring() interrupt
Chris Wilson writes:
> By taking advantage of the RCU protection of the task struct, we can find
> the appropriate signaler under the spinlock and then release the spinlock
> before waking the task and signaling the fence.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 32 +---
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 46aaef5c1851..56a080bc4498 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1145,21 +1145,23 @@ static void ironlake_rps_change_irq_handler(struct
> drm_i915_private *dev_priv)
>
> static void notify_ring(struct intel_engine_cs *engine)
> {
> + const u32 seqno = intel_engine_get_seqno(engine);
> struct i915_request *rq = NULL;
> + struct task_struct *tsk = NULL;
> struct intel_wait *wait;
>
> - if (!engine->breadcrumbs.irq_armed)
> + if (unlikely(!engine->breadcrumbs.irq_armed))
> return;
>
> atomic_inc(&engine->irq_count);
> - set_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
> +
> + rcu_read_lock();
>
> spin_lock(&engine->breadcrumbs.irq_lock);
> wait = engine->breadcrumbs.irq_wait;
> if (wait) {
> - bool wakeup = engine->irq_seqno_barrier;
> -
> - /* We use a callback from the dma-fence to submit
> + /*
> + * We use a callback from the dma-fence to submit
>* requests after waiting on our own requests. To
>* ensure minimum delay in queuing the next request to
>* hardware, signal the fence now rather than wait for
> @@ -1170,19 +1172,22 @@ static void notify_ring(struct intel_engine_cs
> *engine)
>* and to handle coalescing of multiple seqno updates
>* and many waiters.
>*/
> - if (i915_seqno_passed(intel_engine_get_seqno(engine),
> - wait->seqno)) {
> + if (i915_seqno_passed(seqno, wait->seqno)) {
> struct i915_request *waiter = wait->request;
>
> - wakeup = true;
> if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> &waiter->fence.flags) &&
> intel_wait_check_request(wait, waiter))
> rq = i915_request_get(waiter);
> - }
>
> - if (wakeup)
> - wake_up_process(wait->tsk);
> + tsk = wait->tsk;
> + } else {
> + if (engine->irq_seqno_barrier) {
> + set_bit(ENGINE_IRQ_BREADCRUMB,
> + &engine->irq_posted);
> + tsk = wait->tsk;
> + }
> + }
> } else {
> if (engine->breadcrumbs.irq_armed)
> __intel_engine_disarm_breadcrumbs(engine);
> @@ -1195,6 +1200,11 @@ static void notify_ring(struct intel_engine_cs *engine)
> i915_request_put(rq);
> }
>
> + if (tsk && tsk->state & TASK_NORMAL)
> + wake_up_process(tsk);
> +
> + rcu_read_unlock();
> +
> trace_intel_engine_notify(engine, wait);
> }
>
> --
> 2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Only trigger missed-seqno checking next to boundary
Chris Wilson writes:
> If we have more interrupts pending (because we know there are more
> breadcrumb signals before the completion), then we do not need to
> trigger an irq_seqno_barrier or even wakeup the task on this interrupt
> as there will be another. To allow some margin of error (we are trying
> to work around incoherent seqno after all), we wakeup the breadcrumb
> before the target as well as on the target.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Thanks for splitting this out.
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 56a080bc4498..55aba89adfb1 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1182,7 +1182,8 @@ static void notify_ring(struct intel_engine_cs *engine)
>
> tsk = wait->tsk;
> } else {
> - if (engine->irq_seqno_barrier) {
> + if (engine->irq_seqno_barrier &&
> + i915_seqno_passed(seqno, wait->seqno - 1)) {
> set_bit(ENGINE_IRQ_BREADCRUMB,
> &engine->irq_posted);
> tsk = wait->tsk;
> --
> 2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Show vma allocator stack when in doubt
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 45 +++--
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e82aa804cdba..222787106169 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -21,7 +21,7 @@
* IN THE SOFTWARE.
*
*/
-
+
#include "i915_vma.h"
#include "i915_drv.h"
@@ -30,6 +30,45 @@
#include
+#if defined(CONFIG_DRM_I915_DEBUG_GEM) && defined(CONFIG_DRM_DEBUG_MM)
+
+#include
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+ unsigned long entries[16];
+ struct stack_trace trace = {
+ .entries = entries,
+ .max_entries = ARRAY_SIZE(entries),
+ };
+ char *buf;
+
+ if (!vma->node.stack) {
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: unknown
owner\n",
+vma->node.start, vma->node.size, reason);
+ return;
+ }
+
+ buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ depot_fetch_stack(vma->node.stack, &trace);
+ snprint_stack_trace(buf, PAGE_SIZE, &trace, 0);
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: inserted at %s\n",
+vma->node.start, vma->node.size, reason, buf);
+
+ kfree(buf);
+}
+
+#else
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+}
+
+#endif
+
static void
i915_vma_retire(struct i915_gem_active *active, struct i915_request *rq)
{
@@ -875,8 +914,10 @@ int i915_vma_unbind(struct i915_vma *vma)
}
GEM_BUG_ON(i915_vma_is_active(vma));
- if (i915_vma_is_pinned(vma))
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
return -EBUSY;
+ }
if (!drm_mm_node_allocated(&vma->node))
return 0;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove unecessary check for unsupported modifiers for NV12
Op 28-06-18 om 08:18 schreef Dhinakaran Pandiyan:
> There is already a check to allow only RGB formats with CCS
> modifiers.
>
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index eaa0663963a5..c5ec13e0f484 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14521,11 +14521,6 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> }
> break;
> case DRM_FORMAT_NV12:
> - if (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS ||
> - mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS) {
> - DRM_DEBUG_KMS("RC not to be enabled with NV12\n");
> - goto err;
> - }
> if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv) ||
> IS_BROXTON(dev_priv)) {
> DRM_DEBUG_KMS("unsupported pixel format: %s\n",
Fair enough, probably rebase noise. :)
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove support for legacy debugfs crc interface
On Thu, 28 Jun 2018, Maarten Lankhorst
wrote:
> This interface is deprecated, and has been replaced by the upstream
> drm crc interface.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Tomi Sarvela
> Cc: Petri Latvala
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Acked-by: Ville Syrjälä
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 7 +-
> drivers/gpu/drm/i915/i915_drv.h | 11 +-
> drivers/gpu/drm/i915/i915_irq.c | 79 ++---
> drivers/gpu/drm/i915/intel_drv.h | 2 -
> drivers/gpu/drm/i915/intel_pipe_crc.c | 445 --
> 5 files changed, 24 insertions(+), 520 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c400f42a54ec..b753d50b013b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4799,7 +4799,6 @@ static const struct i915_debugfs_files {
> #endif
> {"i915_fifo_underrun_reset", &i915_fifo_underrun_reset_ops},
> {"i915_next_seqno", &i915_next_seqno_fops},
> - {"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
> {"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
> {"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
> {"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
> @@ -4819,7 +4818,7 @@ int i915_debugfs_register(struct drm_i915_private
> *dev_priv)
> {
> struct drm_minor *minor = dev_priv->drm.primary;
> struct dentry *ent;
> - int ret, i;
> + int i;
>
> ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
> minor->debugfs_root, to_i915(minor->dev),
> @@ -4827,10 +4826,6 @@ int i915_debugfs_register(struct drm_i915_private
> *dev_priv)
> if (!ent)
> return -ENOMEM;
>
> - ret = intel_pipe_crc_create(minor);
> - if (ret)
> - return ret;
> -
> for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
> ent = debugfs_create_file(i915_debugfs_files[i].name,
> S_IRUGO | S_IWUSR,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b684f431c60..298b6497cdc5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1276,20 +1276,11 @@ enum intel_pipe_crc_source {
> INTEL_PIPE_CRC_SOURCE_MAX,
> };
>
> -struct intel_pipe_crc_entry {
> - uint32_t frame;
> - uint32_t crc[5];
> -};
> -
> #define INTEL_PIPE_CRC_ENTRIES_NR128
> struct intel_pipe_crc {
> spinlock_t lock;
> - bool opened;/* exclusive access to the result file */
> - struct intel_pipe_crc_entry *entries;
> - enum intel_pipe_crc_source source;
> - int head, tail;
> - wait_queue_head_t wq;
> int skipped;
> + enum intel_pipe_crc_source source;
> };
>
> struct i915_frontbuffer_tracking {
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 46aaef5c1851..08928830fa03 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1703,69 +1703,34 @@ static void display_pipe_crc_irq_handler(struct
> drm_i915_private *dev_priv,
>uint32_t crc4)
> {
> struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
> - struct intel_pipe_crc_entry *entry;
> struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> - struct drm_driver *driver = dev_priv->drm.driver;
> uint32_t crcs[5];
> - int head, tail;
>
> spin_lock(&pipe_crc->lock);
> - if (pipe_crc->source && !crtc->base.crc.opened) {
> - if (!pipe_crc->entries) {
> - spin_unlock(&pipe_crc->lock);
> - DRM_DEBUG_KMS("spurious interrupt\n");
> - return;
> - }
> -
> - head = pipe_crc->head;
> - tail = pipe_crc->tail;
> -
> - if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
> - spin_unlock(&pipe_crc->lock);
> - DRM_ERROR("CRC buffer overflowing\n");
> - return;
> - }
> -
> - entry = &pipe_crc->entries[head];
> -
> - entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
> - entry->crc[0] = crc0;
> - entry->crc[1] = crc1;
> - entry->crc[2] = crc2;
> - entry->crc[3] = crc3;
> - entry->crc[4] = crc4;
> -
> - head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
> - pipe_crc->head = head;
> -
> - spin_unlock(&pipe_crc->lock);
> -
> - wake_up_interruptible(&pipe_crc->wq);
> - } else {
> - /*
> - * For some not yet identified reason, the first CRC is
> - * bonkers. So let's just wait for the next vblank and read
> - * out the buggy result.
> -
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Show vma allocator stack when in doubt
== Series Details ==
Series: drm/i915: Show vma allocator stack when in doubt
URL : https://patchwork.freedesktop.org/series/45562/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9460 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9460 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9460, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/45562/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9460:
=== IGT changes ===
Possible regressions
igt@gem_exec_gttfill@basic:
{fi-kbl-x1275}: PASS -> DMESG-WARN
fi-kbl-7500u: PASS -> DMESG-WARN
fi-kbl-guc: PASS -> DMESG-WARN
fi-skl-6600u: PASS -> DMESG-WARN
fi-kbl-7560u: PASS -> DMESG-WARN
fi-cfl-s3: PASS -> DMESG-WARN
fi-skl-6770hq: PASS -> DMESG-WARN
fi-skl-6700k2: PASS -> DMESG-WARN
fi-skl-6260u: PASS -> DMESG-WARN
fi-kbl-r: PASS -> DMESG-WARN
fi-bdw-5557u: PASS -> DMESG-WARN
fi-glk-j4005: PASS -> DMESG-WARN
fi-kbl-7567u: PASS -> DMESG-WARN
fi-skl-guc: PASS -> DMESG-WARN
fi-cfl-8700k: PASS -> DMESG-WARN
fi-whl-u: PASS -> DMESG-WARN
fi-cfl-guc: PASS -> DMESG-WARN
fi-bxt-j4205: PASS -> DMESG-WARN
fi-skl-6700hq: PASS -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9460 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_exec_gttfill@basic:
fi-byt-n2820: PASS -> FAIL (fdo#106744)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744
== Participating hosts (43 -> 38) ==
Missing(5): fi-byt-j1900 fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4396 -> Patchwork_9460
CI_DRM_4396: dd5f49f9686f412baa426502d417ac74a37fc77e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9460: ddf619ecd8f95acdf401d58a5670956322500a20 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ddf619ecd8f9 drm/i915: Show vma allocator stack when in doubt
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9460/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Show vma allocator stack when in doubt
Quoting Patchwork (2018-06-28 09:55:21)
> == Series Details ==
>
> Series: drm/i915: Show vma allocator stack when in doubt
> URL : https://patchwork.freedesktop.org/series/45562/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9460 =
>
> == Summary - FAILURE ==
>
> Serious unknown changes coming with Patchwork_9460 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_9460, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/45562/revisions/1/mbox/
>
> == Possible new issues ==
>
> Here are the unknown changes that may have been introduced in
> Patchwork_9460:
>
> === IGT changes ===
>
> Possible regressions
>
> igt@gem_exec_gttfill@basic:
> {fi-kbl-x1275}: PASS -> DMESG-WARN
> fi-kbl-7500u: PASS -> DMESG-WARN
> fi-kbl-guc: PASS -> DMESG-WARN
> fi-skl-6600u: PASS -> DMESG-WARN
> fi-kbl-7560u: PASS -> DMESG-WARN
> fi-cfl-s3: PASS -> DMESG-WARN
> fi-skl-6770hq: PASS -> DMESG-WARN
> fi-skl-6700k2: PASS -> DMESG-WARN
> fi-skl-6260u: PASS -> DMESG-WARN
> fi-kbl-r: PASS -> DMESG-WARN
> fi-bdw-5557u: PASS -> DMESG-WARN
> fi-glk-j4005: PASS -> DMESG-WARN
> fi-kbl-7567u: PASS -> DMESG-WARN
> fi-skl-guc: PASS -> DMESG-WARN
> fi-cfl-8700k: PASS -> DMESG-WARN
> fi-whl-u: PASS -> DMESG-WARN
> fi-cfl-guc: PASS -> DMESG-WARN
> fi-bxt-j4205: PASS -> DMESG-WARN
> fi-skl-6700hq: PASS -> DMESG-WARN
Allocation not allowed, hmm. Let's see just how much the stack can take!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Show vma allocator stack when in doubt
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
v2: We cannot allocate inside the printer (as it may be on an fs-reclaim
path), so hope for the best and build the string on the stack
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 39 +++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e82aa804cdba..1a9aed773a5b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -21,7 +21,7 @@
* IN THE SOFTWARE.
*
*/
-
+
#include "i915_vma.h"
#include "i915_drv.h"
@@ -30,6 +30,39 @@
#include
+#if defined(CONFIG_DRM_I915_DEBUG_GEM) && defined(CONFIG_DRM_DEBUG_MM)
+
+#include
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+ unsigned long entries[16];
+ struct stack_trace trace = {
+ .entries = entries,
+ .max_entries = ARRAY_SIZE(entries),
+ };
+ char buf[512];
+
+ if (!vma->node.stack) {
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: unknown
owner\n",
+vma->node.start, vma->node.size, reason);
+ return;
+ }
+
+ depot_fetch_stack(vma->node.stack, &trace);
+ snprint_stack_trace(buf, sizeof(buf), &trace, 0);
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: inserted at %s\n",
+vma->node.start, vma->node.size, reason, buf);
+}
+
+#else
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+}
+
+#endif
+
static void
i915_vma_retire(struct i915_gem_active *active, struct i915_request *rq)
{
@@ -875,8 +908,10 @@ int i915_vma_unbind(struct i915_vma *vma)
}
GEM_BUG_ON(i915_vma_is_active(vma));
- if (i915_vma_is_pinned(vma))
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
return -EBUSY;
+ }
if (!drm_mm_node_allocated(&vma->node))
return 0;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove unecessary check for unsupported modifiers for NV12
== Series Details == Series: drm/i915: Remove unecessary check for unsupported modifiers for NV12 URL : https://patchwork.freedesktop.org/series/45548/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4395_full -> Patchwork_9458_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9458_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9458_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_9458_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9458_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: PASS -> FAIL (fdo#105347) igt@drv_suspend@fence-restore-untiled: shard-kbl: NOTRUN -> DMESG-WARN (fdo#103313) igt@drv_suspend@shrink: shard-snb: PASS -> INCOMPLETE (fdo#105411) igt@gem_ctx_switch@basic-all-light: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@gem_exec_schedule@pi-ringfull-render: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@gem_mmap_gtt@coherency: shard-glk: NOTRUN -> FAIL (fdo#100587) igt@gem_softpin@noreloc-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: NOTRUN -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) +1 Possible fixes igt@drv_selftest@live_hangcheck: shard-apl: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS igt@gem_ctx_isolation@rcs0-s3: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@modeset-vs-vblank-race: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 == Participating hosts (6 -> 6) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4395 -> Patchwork_9458 CI_DRM_4395: 90dc6e8ebc4152ea9f146c023b06f15371cbb244 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9458: ba24b4784badf884cc39c6a5e151f73666b9170c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9458/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/crt: make intel_crt_reset() static again
On Thu, 28 Jun 2018, Daniel Vetter wrote:
> On Wed, Jun 27, 2018 at 02:49:40PM +0300, Jani Nikula wrote:
>> On Thu, 21 Jun 2018, Ville Syrjälä wrote:
>> > On Thu, Jun 21, 2018 at 04:03:30PM +0300, Jani Nikula wrote:
>> >> Commit 9504a8924759 ("drm/i915/vlv: Reset the ADPA in
>> >> vlv_display_power_well_init()") started calling intel_crt_reset()
>> >> directly, while we could just as well use the hooks and keep the
>> >> function static.
>> >>
>> >> Cc: Lyude
>> >> Cc: Ville Syrjälä
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> drivers/gpu/drm/i915/intel_crt.c| 2 +-
>> >> drivers/gpu/drm/i915/intel_drv.h| 1 -
>> >> drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
>> >> 3 files changed, 2 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_crt.c
>> >> b/drivers/gpu/drm/i915/intel_crt.c
>> >> index 0c6bf82bb059..c2cb3b7a255b 100644
>> >> --- a/drivers/gpu/drm/i915/intel_crt.c
>> >> +++ b/drivers/gpu/drm/i915/intel_crt.c
>> >> @@ -881,7 +881,7 @@ static int intel_crt_get_modes(struct drm_connector
>> >> *connector)
>> >> return ret;
>> >> }
>> >>
>> >> -void intel_crt_reset(struct drm_encoder *encoder)
>> >> +static void intel_crt_reset(struct drm_encoder *encoder)
>> >> {
>> >> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>> >> struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
>> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> >> b/drivers/gpu/drm/i915/intel_drv.h
>> >> index 0c3ac0eafde0..b2002fee1b58 100644
>> >> --- a/drivers/gpu/drm/i915/intel_drv.h
>> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> >> @@ -1373,7 +1373,6 @@ void gen9_disable_guc_interrupts(struct
>> >> drm_i915_private *dev_priv);
>> >> bool intel_crt_port_enabled(struct drm_i915_private *dev_priv,
>> >> i915_reg_t adpa_reg, enum pipe *pipe);
>> >> void intel_crt_init(struct drm_i915_private *dev_priv);
>> >> -void intel_crt_reset(struct drm_encoder *encoder);
>> >>
>> >> /* intel_ddi.c */
>> >> void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
>> >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> >> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> >> index de3a81034f77..0b3da5818383 100644
>> >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> >> @@ -972,7 +972,7 @@ static void vlv_display_power_well_init(struct
>> >> drm_i915_private *dev_priv)
>> >> /* Re-enable the ADPA, if we have one */
>> >> for_each_intel_encoder(&dev_priv->drm, encoder) {
>> >> if (encoder->type == INTEL_OUTPUT_ANALOG)
>> >> - intel_crt_reset(&encoder->base);
>> >> + encoder->base.funcs->reset(&encoder->base);
>> >
>> > I have a feeling I requested the direct call to make it less annoying to
>> > figure out what it's actually calling. But if people prefer the function
>> > pointer version I can live with that too.
>>
>> True that, but I thought the direct call was a layering violation.
>>
>> To push, or not to push, that is the question.
>
> Lemma pile my bikeshed on top: Given that we specifically filter for the
> CRT encoder I think a direct call is better here, since a bit more clear
> what's going on. hw occasionally encouragse layering violations ...
Okay, I'll drop the patch for now.
BR,
Jani.
> -Daniel
>
>>
>> BR,
>> Jani.
>>
>> >
>> > Reviewed-by: Ville Syrjälä
>> >
>> >> }
>> >>
>> >> i915_redisable_vga_power_on(dev_priv);
>> >> --
>> >> 2.11.0
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show vma allocator stack when in doubt (rev2)
== Series Details == Series: drm/i915: Show vma allocator stack when in doubt (rev2) URL : https://patchwork.freedesktop.org/series/45562/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9461 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45562/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9461 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-hsw-4200u == Build changes == * Linux: CI_DRM_4396 -> Patchwork_9461 CI_DRM_4396: dd5f49f9686f412baa426502d417ac74a37fc77e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9461: a729778bbfad9a0da7953fce9da5be9c67fd1741 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a729778bbfad drm/i915: Show vma allocator stack when in doubt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9461/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Show vma allocator stack when in doubt
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
v2: We cannot allocate inside the printer (as it may be on an fs-reclaim
path), so hope for the best and build the string on the stack
v3: stack depth of 16 routinely overflows a 512 character string, limit
it to 12 to avoid unsightly truncation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 39 +++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e82aa804cdba..2b7440568e4d 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -21,7 +21,7 @@
* IN THE SOFTWARE.
*
*/
-
+
#include "i915_vma.h"
#include "i915_drv.h"
@@ -30,6 +30,39 @@
#include
+#if defined(CONFIG_DRM_I915_DEBUG_GEM) && defined(CONFIG_DRM_DEBUG_MM)
+
+#include
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+ unsigned long entries[12];
+ struct stack_trace trace = {
+ .entries = entries,
+ .max_entries = ARRAY_SIZE(entries),
+ };
+ char buf[512];
+
+ if (!vma->node.stack) {
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: unknown
owner\n",
+vma->node.start, vma->node.size, reason);
+ return;
+ }
+
+ depot_fetch_stack(vma->node.stack, &trace);
+ snprint_stack_trace(buf, sizeof(buf), &trace, 0);
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: inserted at %s\n",
+vma->node.start, vma->node.size, reason, buf);
+}
+
+#else
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+}
+
+#endif
+
static void
i915_vma_retire(struct i915_gem_active *active, struct i915_request *rq)
{
@@ -875,8 +908,10 @@ int i915_vma_unbind(struct i915_vma *vma)
}
GEM_BUG_ON(i915_vma_is_active(vma));
- if (i915_vma_is_pinned(vma))
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
return -EBUSY;
+ }
if (!drm_mm_node_allocated(&vma->node))
return 0;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] dma-buf: add dma_buf_(un)map_attachment_locked variants v2
On 06/22/2018 10:11 PM, Christian König wrote:
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 57 +++
include/linux/dma-buf.h | 5 +
2 files changed, 62 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 852a3928ee71..dc94e76e2e2a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -606,6 +606,40 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
}
EXPORT_SYMBOL_GPL(dma_buf_detach);
+/**
+ * dma_buf_map_attachment_locked - Maps the buffer into _device_ address space
+ * with the reservation lock held. Is a wrapper for map_dma_buf() of the
+ *
+ * Returns the scatterlist table of the attachment;
+ * dma_buf_ops.
+ * @attach:[in]attachment whose scatterlist is to be returned
+ * @direction: [in]direction of DMA transfer
+ *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error. May return -EINTR if it is interrupted by a signal.
+ *
+ * A mapping must be unmapped by using dma_buf_unmap_attachment_locked(). Note
+ * that the underlying backing storage is pinned for as long as a mapping
+ * exists, therefore users/importers should not hold onto a mapping for undue
+ * amounts of time.
+ */
+struct sg_table *
+dma_buf_map_attachment_locked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction)
+{
+ struct sg_table *sg_table;
+
Perhaps better to add some error check, like dma_buf_map_attachment()
WARN_ON(!attach || !attach->dmabuf)
Apart from that, it's
Reviewed-by: Junwei Zhang
Jerry
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
+
+ return sg_table;
+}
+EXPORT_SYMBOL_GPL(dma_buf_map_attachment_locked);
+
/**
* dma_buf_map_attachment - Returns the scatterlist table of the attachment;
* mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
@@ -639,6 +673,29 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
+/**
+ * dma_buf_unmap_attachment_locked - unmaps the buffer with reservation lock
+ * held, should deallocate the associated scatterlist. Is a wrapper for
+ * unmap_dma_buf() of dma_buf_ops.
+ * @attach:[in]attachment to unmap buffer from
+ * @sg_table: [in]scatterlist info of the buffer to unmap
+ * @direction: [in]direction of DMA transfer
+ *
+ * This unmaps a DMA mapping for @attached obtained by
+ * dma_buf_map_attachment_locked().
+ */
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *attach,
+struct sg_table *sg_table,
+enum dma_data_direction direction)
+{
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
+ direction);
+}
+EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
+
/**
* dma_buf_unmap_attachment - unmaps and decreases usecount of the
buffer;might
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 991787a03199..a25e754ae2f7 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -384,8 +384,13 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
void dma_buf_put(struct dma_buf *dmabuf);
+struct sg_table *dma_buf_map_attachment_locked(struct dma_buf_attachment *,
+ enum dma_data_direction);
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *,
+struct sg_table *,
+enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
enum dma_data_direction);
int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
drm-misc-fixes-2018-06-28: drm-misc-fixes for v4.18-rc3: - A single fix in meson for an unhandled error path in meson_drv_bind_master(). The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-06-28 for you to fetch changes up to 01a9e9493fb3f65c07077d59cf8ba8b6d2e0463e: drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()' (2018-06-26 10:22:29 +0200) drm-misc-fixes for v4.18-rc3: - A single fix in meson for an unhandled error path in meson_drv_bind_master(). Christophe JAILLET (1): drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()' drivers/gpu/drm/meson/meson_drv.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] dma-buf: add dma_buf_(un)map_attachment_locked variants v2
On 06/22/2018 10:11 PM, Christian König wrote:
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 57 +++
include/linux/dma-buf.h | 5 +
2 files changed, 62 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 852a3928ee71..dc94e76e2e2a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -606,6 +606,40 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
}
EXPORT_SYMBOL_GPL(dma_buf_detach);
+/**
+ * dma_buf_map_attachment_locked - Maps the buffer into _device_ address space
+ * with the reservation lock held. Is a wrapper for map_dma_buf() of the
+ *
+ * Returns the scatterlist table of the attachment;
+ * dma_buf_ops.
+ * @attach:[in]attachment whose scatterlist is to be returned
+ * @direction: [in]direction of DMA transfer
+ *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error. May return -EINTR if it is interrupted by a signal.
+ *
+ * A mapping must be unmapped by using dma_buf_unmap_attachment_locked(). Note
+ * that the underlying backing storage is pinned for as long as a mapping
+ * exists, therefore users/importers should not hold onto a mapping for undue
+ * amounts of time.
+ */
+struct sg_table *
+dma_buf_map_attachment_locked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction)
+{
+ struct sg_table *sg_table;
+
Perhaps better to add some error check, like dma_buf_map_attachment()
WARN_ON(!attach || !attach->dmabuf)
Apart from that, it's
Reviewed-by: Junwei Zhang
Jerry
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
+
+ return sg_table;
+}
+EXPORT_SYMBOL_GPL(dma_buf_map_attachment_locked);
+
/**
* dma_buf_map_attachment - Returns the scatterlist table of the attachment;
* mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
@@ -639,6 +673,29 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
+/**
+ * dma_buf_unmap_attachment_locked - unmaps the buffer with reservation lock
+ * held, should deallocate the associated scatterlist. Is a wrapper for
+ * unmap_dma_buf() of dma_buf_ops.
+ * @attach:[in]attachment to unmap buffer from
+ * @sg_table: [in]scatterlist info of the buffer to unmap
+ * @direction: [in]direction of DMA transfer
+ *
+ * This unmaps a DMA mapping for @attached obtained by
+ * dma_buf_map_attachment_locked().
+ */
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *attach,
+struct sg_table *sg_table,
+enum dma_data_direction direction)
+{
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
+ direction);
+}
+EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
+
/**
* dma_buf_unmap_attachment - unmaps and decreases usecount of the
buffer;might
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 991787a03199..a25e754ae2f7 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -384,8 +384,13 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
void dma_buf_put(struct dma_buf *dmabuf);
+struct sg_table *dma_buf_map_attachment_locked(struct dma_buf_attachment *,
+ enum dma_data_direction);
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *,
+struct sg_table *,
+enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
enum dma_data_direction);
int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2
On 06/22/2018 10:11 PM, Christian König wrote:
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by: Christian König
looks good for me.
Reviewed-by: Junwei Zhang
Jerry
---
drivers/dma-buf/dma-buf.c | 9 ++---
include/linux/dma-buf.h | 4
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index dc94e76e2e2a..49f23b791eb8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -665,7 +665,9 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
- sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ sg_table = dma_buf_map_attachment_locked(attach, direction);
+ reservation_object_unlock(attach->dmabuf->resv);
if (!sg_table)
sg_table = ERR_PTR(-ENOMEM);
@@ -715,8 +717,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
- attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
- direction);
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ dma_buf_unmap_attachment_locked(attach, sg_table, direction);
+ reservation_object_unlock(attach->dmabuf->resv);
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a25e754ae2f7..024658d1f22e 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -118,6 +118,8 @@ struct dma_buf_ops {
* any other kind of sharing that the exporter might wish to make
* available to buffer-users.
*
+* This is called with the dmabuf->resv object locked.
+*
* Returns:
*
* A &sg_table scatter list of or the backing storage of the DMA buffer,
@@ -138,6 +140,8 @@ struct dma_buf_ops {
* It should also unpin the backing storage if this is the last mapping
* of the DMA buffer, it the exporter supports backing storage
* migration.
+*
+* This is called with the dmabuf->resv object locked.
*/
void (*unmap_dma_buf)(struct dma_buf_attachment *,
struct sg_table *,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/amdgpu: add independent DMA-buf export v3
On 06/22/2018 10:11 PM, Christian König wrote:
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 94 +--
3 files changed, 39 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d8e0cc08f9db..5e71af8dd3a7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -373,7 +373,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a549483032b0..cdf0be85d361 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -919,7 +919,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
- .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
I may miss some patches or important info.
Even applied the series of patch, I still could find below code in
drm_gem_map_dma_buf().
In this case, it will cause NULL pointer access. Please help me out of here.
{{{
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
}}}
Jerry
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index b2286bc41aec..038a8c8488b7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -40,22 +40,6 @@
static const struct dma_buf_ops amdgpu_dmabuf_ops;
-/**
- * amdgpu_gem_prime_get_sg_table - &drm_driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the buffer object's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
/**
* amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
* @obj: GEM buffer object
@@ -189,35 +173,29 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
}
/**
- * amdgpu_gem_map_attach - &dma_buf_ops.attach implementation
- * @dma_buf: shared DMA buffer
- * @target_dev: target device
+ * amdgpu_gem_map_dma_buf - &dma_buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
+ * @dir: DMA direction
*
* Makes sure that the shared DMA buffer can be accessed by the target device.
* For now, simply pins it to the GTT domain, where it should be accessible by
* all DMA devices.
*
* Returns:
- * 0 on success or negative error code.
+ * sg_table filled with the DMA addresses to use or ERR_PRT with negative error
+ * code.
*/
-static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
-struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
{
+ struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct sg_table *sgt;
long r;
- r = drm_gem_map_attach(dma_buf, attach);
- if (r)
- return r;
-
- r = amdgpu_bo_reserve(bo, false);
- if (unlikely(r != 0))
- goto error_detach;
-
-
if (attach->dev->driver != adev->dev->driver) {
/*
* Wait for all shared fences to complete before we switch to
future
@@ -228,54 +206,62 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
MAX_SCHEDULE_TIMEOUT);
if (unlikely(r
Re: [Intel-gfx] [PATCH 5/9] drm/i915/execlists: Unify CSB access pointers
On 27/06/2018 22:07, Chris Wilson wrote:
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce the CSB access to a set of read/write/buffer pointers and
treat the various paths identically and not worry about forcewake.
(Forcewake is nightmare for worstcase latency, and we want to process
this all with irqsoff -- no latency allowed!)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel_lrc.c| 116 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 23 +++--
3 files changed, 65 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d3264bd6e9dc..7209c22798e6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,7 +25,6 @@
#include
#include "i915_drv.h"
-#include "i915_vgpu.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
@@ -456,21 +455,10 @@ static void intel_engine_init_batch_pool(struct intel_engine_cs *engine)
i915_gem_batch_pool_init(&engine->batch_pool, engine);
}
-static bool csb_force_mmio(struct drm_i915_private *i915)
-{
- /* Older GVT emulation depends upon intercepting CSB mmio */
- if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
- return true;
-
- return false;
-}
-
static void intel_engine_init_execlist(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- execlists->csb_use_mmio = csb_force_mmio(engine->i915);
-
execlists->port_mask = 1;
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 91656eb2f2db..368a8c74d11d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
#include
#include "i915_drv.h"
#include "i915_gem_render_state.h"
+#include "i915_vgpu.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_workarounds.h"
@@ -953,44 +954,23 @@ static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
- struct drm_i915_private *i915 = engine->i915;
-
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
- bool fw = false;
+ const u32 * const buf = execlists->csb_status;
+ u8 head, tail;
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_use_mmio)) {
- intel_uncore_forcewake_get(i915, execlists->fw_domains);
- fw = true;
-
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+ /* Note that csb_write, csb_status may be either in HWSP or mmio */
+ head = execlists->csb_head;
+ tail = READ_ONCE(*execlists->csb_write);
Under GVT when this is emulated mmio I think you need to mask and shift
it with GEN8_CSB_WRITE_PTR.
+ GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
+ if (unlikely(head == tail))
+ return;
- head = readl(i915->regs + i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ rmb(); /* Hopefully paired with a wmb() in HW */
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- engine->name,
- head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-
- while (head != tail) {
+ do {
Why convert while to do-while? Early unlikely return above handles the
void process_csb calls? Would the same effe
Re: [Intel-gfx] [PATCH V2] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
On Wed, Jun 27, 2018 at 03:26:54PM -0700, Clint Taylor wrote:
>
>
> On 06/25/2018 03:33 AM, Imre Deak wrote:
> > On Wed, Jun 13, 2018 at 02:48:49PM -0700, clinton.a.tay...@intel.com wrote:
> > > From: Clint Taylor
> > >
> > > On GLK NUC platforms the HDMI retiming buffer needs additional disabled
> > > time to correctly sync to a faster incoming signal.
> > >
> > > When measured on a scope the highspeed lines of the HDMI clock turn off
> > > for ~400uS during a normal resolution change. The HDMI retimer on the
> > > GLK NUC appears to require at least a full frame of quiet time before a
> > > new faster clock can be correctly sync'd. The worst case scenario appears
> > > to be 23.98Hz modes which requires a wait of 41.25ms. Add a quirk to the
> > > driver for GLK NUC that waits 42ms.
> > >
> > > V2: Add more devices to the quirk list
> > >
> > > Cc: Imre Deak
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
> > > Signed-off-by: Clint Taylor
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_ddi.c | 8
> > > drivers/gpu/drm/i915/intel_display.c | 19 +++
> > > 3 files changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index be8c2f0..da196b4 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -656,6 +656,7 @@ enum intel_sbi_destination {
> > > #define QUIRK_BACKLIGHT_PRESENT (1<<3)
> > > #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > +#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > struct intel_fbdev;
> > > struct intel_fbc_work;
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index ca73387..bc3d012 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1791,6 +1791,9 @@ void intel_ddi_enable_transcoder_func(const struct
> > > intel_crtc_state *crtc_state)
> > > I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
> > > }
> > > +/* Quirk time computed based on 24fps frame time of 41.25ms */
> > > +#define DDI_DISABLED_QUIRK_TIME 42
> > > +
> > > void intel_ddi_disable_transcoder_func(struct drm_i915_private
> > > *dev_priv,
> > > enum transcoder cpu_transcoder)
> > > {
> > > @@ -1800,6 +1803,11 @@ void intel_ddi_disable_transcoder_func(struct
> > > drm_i915_private *dev_priv,
> > > val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK |
> > > TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
> > > val |= TRANS_DDI_PORT_NONE;
> > > I915_WRITE(reg, val);
> > > +
> > > + if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME) {
> > > + msleep(DDI_DISABLED_QUIRK_TIME);
> > > + DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
> > No need for the define or the debug message here imo. msleep() can be
> > inaccurate (even sleeping less than expected), so I'd use a bigger
> > margin, sleeping say 100ms.
>
> Easy to do and I can submit v3.
>
> >
> > If the problem is with the HDMI retimer chip, we should limit the quirk
> > to HDMI outputs.
> Output type is not available in intel_disable_ddi() and I would prefer not
> to change the interface only for the quirk. I could move the quirk execution
> up a level to haswell_crtc_disable() and detect the old_crtc_state->type
> before executing the quirk. However, the quirk is only being detected for
> certain boards that only have HDMI outputs. Unless more boards are added to
> the quirk_list[] we really don't need logic to detect HDMI outputs.
Ok, but I'm sure we'll forget about this detail once we have to update
the list with a GLK having a DP output too. OTOH, changing
intel_ddi_disable_transcoder_func() to accept
struct intel_crtc_state *crtc_state would make it symmetric with
intel_ddi_enable_transcoder_func(), so imo a good change on its own.
--Imre
>
> -Clint
>
> > > + }
> > > }
> > > int intel_ddi_toggle_hdcp_signalling(struct intel_encoder
> > > *intel_encoder,
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 8251e18..40e0306 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -14749,6 +14749,17 @@ static void quirk_increase_t12_delay(struct
> > > drm_device *dev)
> > > DRM_INFO("Applying T12 delay quirk\n");
> > > }
> > > +/* GeminiLake NUC HDMI outputs require additional off time
> > > + * this allows the onboard retimer to correctly sync to signal
> > > + */
> > > +static void quirk_increase_ddi_disabled_time(struct drm_device *dev)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > +
> > > + dev_priv->quirks |= QUIRK_INCREASE_DDI_DISABLED_TIME;
> > > + DRM_INFO("Applying Increase DDI Disabled quirk\n
Re: [Intel-gfx] [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset
On 27/06/2018 22:07, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 368a8c74d11d..8b111a268697 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
+static void reset_csb_pointers(struct intel_engine_execlists *execlists)
+{
+ /*
+* After a reset, the HW starts writing into CSB entry [0]. We
+* therefore have to set our HEAD pointer back one entry so that
+* the *first* entry we check is entry 0. To complicate this further,
+* as we don't wait for the first interrupt after reset, we have to
+* fake the HW write to point back to the last entry so that our
+* inline comparison of our cached head position against the last HW
+* write works even before the first interrupt.
+*/
+ execlists->csb_head = GEN8_CSB_ENTRIES - 1;
+ WRITE_ONCE(*execlists->csb_write, (GEN8_CSB_ENTRIES - 1) | 0xff << 16);
Use _MASKED_FIELD and GEN8_CSB_WRITE_PTR_MASK?
+}
+
static void execlists_cancel_requests(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -1953,7 +1968,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
__unwind_incomplete_requests(engine);
/* Following the reset, we need to reload the CSB read/write pointers */
- engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
+ reset_csb_pointers(&engine->execlists);
spin_unlock_irqrestore(&engine->timeline.lock, flags);
@@ -2452,7 +2467,6 @@ static int logical_ring_init(struct intel_engine_cs *engine)
upper_32_bits(ce->lrc_desc);
}
- execlists->csb_head = GEN8_CSB_ENTRIES - 1;
execlists->csb_read =
i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
if (csb_force_mmio(i915)) {
@@ -2467,6 +2481,7 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
execlists->csb_write =
&engine->status_page.page_addr[intel_hws_csb_write_index(i915)];
}
+ reset_csb_pointers(execlists);
return 0;
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/i915/execlists: Stop storing the CSB read pointer in the mmio register
On 27/06/2018 22:07, Chris Wilson wrote: As we now never read back our current head position from the CSB pointers register, and the HW itself doesn't use it to prevent overwriting unread CSB entries, we do not need to keep updating the register. As it turns out this register is not listed as being shadowed, and so requires forcewake -- but we haven't been taking forcewake around it so the writes has probably been regularly dropped. Fortuitously, we only read the value after a reset where it did not matter, and zero was the right answer (well, close enough). Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_lrc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 8b111a268697..a6268103663f 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1100,8 +1100,6 @@ static void process_csb(struct intel_engine_cs *engine) } } while (head != tail); - writel(_MASKED_FIELD(GEN8_CSB_READ_PTR_MASK, head << 8), - execlists->csb_read); execlists->csb_head = head; } Proof is in the pudding. :) Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915/execlists: Unify CSB access pointers
Quoting Tvrtko Ursulin (2018-06-28 11:02:17)
>
> On 27/06/2018 22:07, Chris Wilson wrote:
> > Following the removal of the last workarounds, the only CSB mmio access
> > is for the old vGPU interface. The mmio registers presented by vGPU do
> > not require forcewake and can be treated as ordinary volatile memory,
> > i.e. they behave just like the HWSP access just at a different location.
> > We can reduce the CSB access to a set of read/write/buffer pointers and
> > treat the various paths identically and not worry about forcewake.
> > (Forcewake is nightmare for worstcase latency, and we want to process
> > this all with irqsoff -- no latency allowed!)
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
> > drivers/gpu/drm/i915/intel_lrc.c| 116 ++--
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 23 +++--
> > 3 files changed, 65 insertions(+), 86 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index d3264bd6e9dc..7209c22798e6 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -25,7 +25,6 @@
> > #include
> >
> > #include "i915_drv.h"
> > -#include "i915_vgpu.h"
> > #include "intel_ringbuffer.h"
> > #include "intel_lrc.h"
> >
> > @@ -456,21 +455,10 @@ static void intel_engine_init_batch_pool(struct
> > intel_engine_cs *engine)
> > i915_gem_batch_pool_init(&engine->batch_pool, engine);
> > }
> >
> > -static bool csb_force_mmio(struct drm_i915_private *i915)
> > -{
> > - /* Older GVT emulation depends upon intercepting CSB mmio */
> > - if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
> > - return true;
> > -
> > - return false;
> > -}
> > -
> > static void intel_engine_init_execlist(struct intel_engine_cs *engine)
> > {
> > struct intel_engine_execlists * const execlists = &engine->execlists;
> >
> > - execlists->csb_use_mmio = csb_force_mmio(engine->i915);
> > -
> > execlists->port_mask = 1;
> > BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
> > GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 91656eb2f2db..368a8c74d11d 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -137,6 +137,7 @@
> > #include
> > #include "i915_drv.h"
> > #include "i915_gem_render_state.h"
> > +#include "i915_vgpu.h"
> > #include "intel_lrc_reg.h"
> > #include "intel_mocs.h"
> > #include "intel_workarounds.h"
> > @@ -953,44 +954,23 @@ static void process_csb(struct intel_engine_cs
> > *engine)
> > {
> > struct intel_engine_execlists * const execlists = &engine->execlists;
> > struct execlist_port *port = execlists->port;
> > - struct drm_i915_private *i915 = engine->i915;
> > -
> > - /* The HWSP contains a (cacheable) mirror of the CSB */
> > - const u32 *buf =
> > - &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> > - unsigned int head, tail;
> > - bool fw = false;
> > + const u32 * const buf = execlists->csb_status;
> > + u8 head, tail;
> >
> > /* Clear before reading to catch new interrupts */
> > clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> > smp_mb__after_atomic();
> >
> > - if (unlikely(execlists->csb_use_mmio)) {
> > - intel_uncore_forcewake_get(i915, execlists->fw_domains);
> > - fw = true;
> > -
> > - buf = (u32 * __force)
> > - (i915->regs +
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> > + /* Note that csb_write, csb_status may be either in HWSP or mmio */
> > + head = execlists->csb_head;
> > + tail = READ_ONCE(*execlists->csb_write);
>
> Under GVT when this is emulated mmio I think you need to mask and shift
> it with GEN8_CSB_WRITE_PTR.
Shift is 0, mask is applied by u8.
> > + GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
> > + if (unlikely(head == tail))
> > + return;
> >
> > - head = readl(i915->regs +
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
> > - tail = GEN8_CSB_WRITE_PTR(head);
> > - head = GEN8_CSB_READ_PTR(head);
> > - execlists->csb_head = head;
> > - } else {
> > - const int write_idx =
> > - intel_hws_csb_write_index(i915) -
> > - I915_HWS_CSB_BUF0_INDEX;
> > + rmb(); /* Hopefully paired with a wmb() in HW */
> >
> > - head = execlists->csb_head;
> > - tail = READ_ONCE(buf[write_idx]);
> > - rmb(); /* Hopefully paired with a wmb() in HW */
> > - }
> > - GEM_TRACE("%s cs-irq head=%d [%d%s],
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Show vma allocator stack when in doubt (rev3)
== Series Details == Series: drm/i915: Show vma allocator stack when in doubt (rev3) URL : https://patchwork.freedesktop.org/series/45562/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9462 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9462 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9462, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/45562/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9462: === IGT changes === Possible regressions igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-skl-6600u: PASS -> DMESG-WARN +4 == Known issues == Here are the changes found in Patchwork_9462 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload: fi-skl-6600u: PASS -> DMESG-WARN (fdo#106697) igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128) fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106697 https://bugs.freedesktop.org/show_bug.cgi?id=106697 == Participating hosts (43 -> 38) == Missing(5): fi-ctg-p8600 fi-kbl-7560u fi-byt-squawks fi-ilk-m540 fi-hsw-4200u == Build changes == * Linux: CI_DRM_4396 -> Patchwork_9462 CI_DRM_4396: dd5f49f9686f412baa426502d417ac74a37fc77e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9462: 0baf797439ce8499f92211da1b442b6ca94dd283 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0baf797439ce drm/i915: Show vma allocator stack when in doubt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9462/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset
Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
>
> On 27/06/2018 22:07, Chris Wilson wrote:
> > On HW reset, the HW clears the write pointer (to 0). But since it also
> > writes its first CSB entry to slot 0, we need to reset the write pointer
> > back to the element before (so the first entry we read is 0).
> >
> > This is required for the next patch, where we trust the CSB completely!
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 19 +--
> > 1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 368a8c74d11d..8b111a268697 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
> > clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> > }
> >
> > +static void reset_csb_pointers(struct intel_engine_execlists *execlists)
> > +{
> > + /*
> > + * After a reset, the HW starts writing into CSB entry [0]. We
> > + * therefore have to set our HEAD pointer back one entry so that
> > + * the *first* entry we check is entry 0. To complicate this further,
> > + * as we don't wait for the first interrupt after reset, we have to
> > + * fake the HW write to point back to the last entry so that our
> > + * inline comparison of our cached head position against the last HW
> > + * write works even before the first interrupt.
> > + */
> > + execlists->csb_head = GEN8_CSB_ENTRIES - 1;
> > + WRITE_ONCE(*execlists->csb_write, (GEN8_CSB_ENTRIES - 1) | 0xff <<
> > 16);
>
> Use _MASKED_FIELD and GEN8_CSB_WRITE_PTR_MASK?
Hah, there goes my attempt to kill off unused magic.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/execlists: Reset CSB write pointer after reset
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
v2: Use _MASKED_FIELD
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 368a8c74d11d..2e712a99425f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -884,6 +884,22 @@ static void reset_irq(struct intel_engine_cs *engine)
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
+static void reset_csb_pointers(struct intel_engine_execlists *execlists)
+{
+ /*
+* After a reset, the HW starts writing into CSB entry [0]. We
+* therefore have to set our HEAD pointer back one entry so that
+* the *first* entry we check is entry 0. To complicate this further,
+* as we don't wait for the first interrupt after reset, we have to
+* fake the HW write to point back to the last entry so that our
+* inline comparison of our cached head position against the last HW
+* write works even before the first interrupt.
+*/
+ execlists->csb_head = GEN8_CSB_ENTRIES - 1;
+ WRITE_ONCE(*execlists->csb_write,
+ _MASKED_FIELD(0xff, GEN8_CSB_ENTRIES - 1));
+}
+
static void execlists_cancel_requests(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -1953,7 +1969,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
__unwind_incomplete_requests(engine);
/* Following the reset, we need to reload the CSB read/write pointers */
- engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
+ reset_csb_pointers(&engine->execlists);
spin_unlock_irqrestore(&engine->timeline.lock, flags);
@@ -2452,7 +2468,6 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
upper_32_bits(ce->lrc_desc);
}
- execlists->csb_head = GEN8_CSB_ENTRIES - 1;
execlists->csb_read =
i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
if (csb_force_mmio(i915)) {
@@ -2467,6 +2482,7 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
execlists->csb_write =
&engine->status_page.page_addr[intel_hws_csb_write_index(i915)];
}
+ reset_csb_pointers(execlists);
return 0;
--
2.18.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 series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev2)
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts (rev2)
URL : https://patchwork.freedesktop.org/series/45531/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6d78246fb880 drm/i915: Drop posting reads to flush master interrupts
a029fbce709f drm/i915/execlists: Pull submit after dequeue under timeline lock
eede2b30ffb9 drm/i915/execlists: Pull CSB reset under the timeline.lock
92843704c6d6 drm/i915/execlists: Process one CSB update at a time
-:68: WARNING:MEMORY_BARRIER: memory barrier without comment
#68: FILE: drivers/gpu/drm/i915/intel_lrc.c:966:
+ smp_mb__after_atomic();
-:114: WARNING:LONG_LINE: line over 100 characters
#114: FILE: drivers/gpu/drm/i915/intel_lrc.c:990:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:115: WARNING:LONG_LINE: line over 100 characters
#115: FILE: drivers/gpu/drm/i915/intel_lrc.c:991:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-:183: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#183: FILE: drivers/gpu/drm/i915/intel_lrc.c:1022:
+ status, buf[2*head + 1],
^
-:211: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#211: FILE: drivers/gpu/drm/i915/intel_lrc.c:1040:
+ buf[2*head + 1] == execlists->preempt_complete_status) {
^
total: 0 errors, 3 warnings, 2 checks, 316 lines checked
c4c5eb343fb5 drm/i915/execlists: Unify CSB access pointers
a7894f5a9301 drm/i915/execlists: Reset CSB write pointer after reset
cd3ce098db8d drm/i915/execlists: Stop storing the CSB read pointer in the mmio
register
657a10b942d4 drm/i915/execlists: Trust the CSB
81f84fa1a393 drm/i915/execlists: Direct submission of new requests (avoid
tasklet/ksoftirqd)
-:104: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#104:
References: 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom
half")
-:104: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit 27af5eea54d1 ("drm/i915:
Move execlists irq handler to a bottom half")'
#104:
References: 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom
half")
total: 1 errors, 1 warnings, 0 checks, 178 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Remove support for legacy debugfs crc interface
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove support for legacy debugfs
crc interface
URL : https://patchwork.freedesktop.org/series/45553/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4396_full -> Patchwork_9459_full =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9459_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9459_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_9459_full:
=== IGT changes ===
Possible regressions
igt@kms_universal_plane@cursor-fb-leak-pipe-b:
shard-apl: PASS -> FAIL
Warnings
igt@gem_exec_schedule@deep-bsd2:
shard-kbl: SKIP -> PASS
igt@gem_exec_schedule@deep-vebox:
shard-kbl: PASS -> SKIP +1
== Known issues ==
Here are the changes found in Patchwork_9459_full that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
shard-apl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947)
igt@drv_selftest@mock_scatterlist:
shard-kbl: NOTRUN -> DMESG-WARN (fdo#103667)
igt@gem_exec_schedule@pi-ringfull-bsd1:
shard-kbl: NOTRUN -> FAIL (fdo#103158)
igt@gem_exec_schedule@pi-ringfull-vebox:
shard-glk: NOTRUN -> FAIL (fdo#103158)
igt@kms_flip@2x-plain-flip-fb-recreate:
{shard-glk9}: NOTRUN -> FAIL (fdo#100368)
igt@kms_flip_tiling@flip-x-tiled:
shard-glk: PASS -> FAIL (fdo#103822, fdo#104724)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render:
shard-snb: PASS -> FAIL (fdo#103167, fdo#104724)
igt@kms_setmode@basic:
shard-kbl: PASS -> FAIL (fdo#99912)
igt@testdisplay:
shard-glk: NOTRUN -> INCOMPLETE (fdo#103359, k.org#198133)
Possible fixes
igt@drv_selftest@live_gtt:
shard-glk: FAIL (fdo#105347) -> PASS
igt@kms_flip@plain-flip-fb-recreate:
shard-glk: FAIL (fdo#100368) -> PASS
igt@kms_flip_tiling@flip-y-tiled:
shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133
== Participating hosts (6 -> 6) ==
No changes in participating hosts
== Build changes ==
* Linux: CI_DRM_4396 -> Patchwork_9459
CI_DRM_4396: dd5f49f9686f412baa426502d417ac74a37fc77e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9459: 107c66964ccb63a1faf7cde7381cd533ddd8b237 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9459/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/kms_universal_plane: Flush pending cleanups
drm_atomic_helper allows for up to one outstanding cleanup task to be in flight before a new modeset (see stall_commit in stall_checks()), In lieu of hooking up a debugfs to force flushing of the outstanding work, submit enough blocking modesets to ensure that the pending work is completed before continuing. Signed-off-by: Chris Wilson Cc: Maarten Lankhorst --- tests/kms_universal_plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c index 58f329e68..f875fd194 100644 --- a/tests/kms_universal_plane.c +++ b/tests/kms_universal_plane.c @@ -638,6 +638,7 @@ cursor_leak_test_pipe(data_t *data, enum pipe pipe, igt_output_t *output) igt_plane_set_fb(primary, NULL); igt_plane_set_fb(cursor, NULL); igt_display_commit2(display, COMMIT_LEGACY); + igt_display_commit2(display, COMMIT_LEGACY); cursor_leak_test_fini(data, output, &background_fb, cursor_fb); /* We should be back to the same framebuffer count as when we started */ -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915/execlists: Unify CSB access pointers
On 28/06/2018 11:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 11:02:17)
On 27/06/2018 22:07, Chris Wilson wrote:
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce the CSB access to a set of read/write/buffer pointers and
treat the various paths identically and not worry about forcewake.
(Forcewake is nightmare for worstcase latency, and we want to process
this all with irqsoff -- no latency allowed!)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel_lrc.c| 116 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 23 +++--
3 files changed, 65 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d3264bd6e9dc..7209c22798e6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,7 +25,6 @@
#include
#include "i915_drv.h"
-#include "i915_vgpu.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
@@ -456,21 +455,10 @@ static void intel_engine_init_batch_pool(struct intel_engine_cs *engine)
i915_gem_batch_pool_init(&engine->batch_pool, engine);
}
-static bool csb_force_mmio(struct drm_i915_private *i915)
-{
- /* Older GVT emulation depends upon intercepting CSB mmio */
- if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
- return true;
-
- return false;
-}
-
static void intel_engine_init_execlist(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- execlists->csb_use_mmio = csb_force_mmio(engine->i915);
-
execlists->port_mask = 1;
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 91656eb2f2db..368a8c74d11d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
#include
#include "i915_drv.h"
#include "i915_gem_render_state.h"
+#include "i915_vgpu.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_workarounds.h"
@@ -953,44 +954,23 @@ static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
- struct drm_i915_private *i915 = engine->i915;
-
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
- bool fw = false;
+ const u32 * const buf = execlists->csb_status;
+ u8 head, tail;
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_use_mmio)) {
- intel_uncore_forcewake_get(i915, execlists->fw_domains);
- fw = true;
-
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+ /* Note that csb_write, csb_status may be either in HWSP or mmio */
+ head = execlists->csb_head;
+ tail = READ_ONCE(*execlists->csb_write);
Under GVT when this is emulated mmio I think you need to mask and shift
it with GEN8_CSB_WRITE_PTR.
Shift is 0, mask is applied by u8.
Evil. :) Put a comment please.
+ GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
+ if (unlikely(head == tail))
+ return;
- head = readl(i915->regs + i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ rmb(); /* Hopefully paired with a wmb() in HW */
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- engine->name,
- head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-
- while (head != tail)
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev2)
== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev2) URL : https://patchwork.freedesktop.org/series/45531/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4396 -> Patchwork_9463 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45531/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9463 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-dsi: PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: PASS -> FAIL (fdo#103375) +2 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-hsw-4200u == Build changes == * Linux: CI_DRM_4396 -> Patchwork_9463 CI_DRM_4396: dd5f49f9686f412baa426502d417ac74a37fc77e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9463: 81f84fa1a3932d0f1b36cb10d41fc8a9e6836241 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 81f84fa1a393 drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) 657a10b942d4 drm/i915/execlists: Trust the CSB cd3ce098db8d drm/i915/execlists: Stop storing the CSB read pointer in the mmio register a7894f5a9301 drm/i915/execlists: Reset CSB write pointer after reset c4c5eb343fb5 drm/i915/execlists: Unify CSB access pointers 92843704c6d6 drm/i915/execlists: Process one CSB update at a time eede2b30ffb9 drm/i915/execlists: Pull CSB reset under the timeline.lock a029fbce709f drm/i915/execlists: Pull submit after dequeue under timeline lock 6d78246fb880 drm/i915: Drop posting reads to flush master interrupts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9463/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset
On 28/06/2018 11:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
On 27/06/2018 22:07, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 368a8c74d11d..8b111a268697 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
+static void reset_csb_pointers(struct intel_engine_execlists *execlists)
+{
+ /*
+ * After a reset, the HW starts writing into CSB entry [0]. We
+ * therefore have to set our HEAD pointer back one entry so that
+ * the *first* entry we check is entry 0. To complicate this further,
+ * as we don't wait for the first interrupt after reset, we have to
+ * fake the HW write to point back to the last entry so that our
+ * inline comparison of our cached head position against the last HW
+ * write works even before the first interrupt.
+ */
+ execlists->csb_head = GEN8_CSB_ENTRIES - 1;
+ WRITE_ONCE(*execlists->csb_write, (GEN8_CSB_ENTRIES - 1) | 0xff << 16);
Use _MASKED_FIELD and GEN8_CSB_WRITE_PTR_MASK?
Hah, there goes my attempt to kill off unused magic.
At least _MASKED_FIELD makes it clearer.
But the u8 trick is still evil since here you even explicitly do a fake
masked write on hwsp. Ugly and evil. How about storing
execlists->csb_write_default at init time and applying it here?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915/execlists: Unify CSB access pointers
Quoting Tvrtko Ursulin (2018-06-28 11:58:26)
> On 28/06/2018 11:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-28 11:02:17)
> >>
> >> On 27/06/2018 22:07, Chris Wilson wrote:
> >>> + GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
> >>> + if (unlikely(head == tail))
> >>> + return;
> >>>
> >>> - head = readl(i915->regs +
> >>> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
> >>> - tail = GEN8_CSB_WRITE_PTR(head);
> >>> - head = GEN8_CSB_READ_PTR(head);
> >>> - execlists->csb_head = head;
> >>> - } else {
> >>> - const int write_idx =
> >>> - intel_hws_csb_write_index(i915) -
> >>> - I915_HWS_CSB_BUF0_INDEX;
> >>> + rmb(); /* Hopefully paired with a wmb() in HW */
> >>>
> >>> - head = execlists->csb_head;
> >>> - tail = READ_ONCE(buf[write_idx]);
> >>> - rmb(); /* Hopefully paired with a wmb() in HW */
> >>> - }
> >>> - GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
> >>> - engine->name,
> >>> - head, GEN8_CSB_READ_PTR(readl(i915->regs +
> >>> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
> >>> - tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
> >>> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
> >>> -
> >>> - while (head != tail) {
> >>> + do {
> >>
> >> Why convert while to do-while? Early unlikely return above handles the
> >> void process_csb calls? Would the same effect happen if you put unlikely
> >> in the while (head != tail) condition and would be simpler?
> >
> > The earlier return to circumvent the lfence.
>
> Oh that one.. so why it is safe to compare head and tail before the rmb
> since we need the rmb afterwards?
There's a direct data dependency in the control flow of using the
volatile read from HWSP, but later on there is no data dependencies
between the write pointer we've "already" used and the rest of the CSB[]
we want to pull from HWSP. So while it seems unlikely, without that
lfence those later reads could be performed before the test (but the
test itself can't be performed before the read!). And sadly we can't get
away with our older read_barrier(), which for a long time I thought was
sufficient to order the read of the write pointer before the reads of
CSB[].
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_universal_plane: Flush pending cleanups
Op 28-06-18 om 12:51 schreef Chris Wilson: > drm_atomic_helper allows for up to one outstanding cleanup task to be in > flight before a new modeset (see stall_commit in stall_checks()), In > lieu of hooking up a debugfs to force flushing of the outstanding work, > submit enough blocking modesets to ensure that the pending work is > completed before continuing. > > Signed-off-by: Chris Wilson > Cc: Maarten Lankhorst > --- > tests/kms_universal_plane.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c > index 58f329e68..f875fd194 100644 > --- a/tests/kms_universal_plane.c > +++ b/tests/kms_universal_plane.c > @@ -638,6 +638,7 @@ cursor_leak_test_pipe(data_t *data, enum pipe pipe, > igt_output_t *output) > igt_plane_set_fb(primary, NULL); > igt_plane_set_fb(cursor, NULL); > igt_display_commit2(display, COMMIT_LEGACY); > + igt_display_commit2(display, COMMIT_LEGACY); > cursor_leak_test_fini(data, output, &background_fb, cursor_fb); > > /* We should be back to the same framebuffer count as when we started */ This won't work, we won't commit anything without anything changed, probably best to put the set_fb in the loop too. Testcase: kms_universal_plane@cursor-fb-leak-* ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Remove support for legacy debugfs crc interface
Op 28-06-18 om 12:41 schreef Patchwork: > == Series Details == > > Series: series starting with [1/2] drm/i915: Remove support for legacy > debugfs crc interface > URL : https://patchwork.freedesktop.org/series/45553/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4396_full -> Patchwork_9459_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_9459_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_9459_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_9459_full: > > === IGT changes === > > Possible regressions > > igt@kms_universal_plane@cursor-fb-leak-pipe-b: > shard-apl: PASS -> FAIL Likely the following culprit: commit 8d52e447807b350b98ffb4e64bc2fcc1f181c5be Author: Chris Wilson Date: Sat Jun 23 11:39:51 2018 +0100 drm/i915: Defer modeset cleanup to a secondary task ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/execlists: Unify CSB access pointers
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce the CSB access to a set of read/write/buffer pointers and
treat the various paths identically and not worry about forcewake.
(Forcewake is nightmare for worstcase latency, and we want to process
this all with irqsoff -- no latency allowed!)
v2: Comments, comments, comments. Well, 2 bonus comments.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel_lrc.c| 133
drivers/gpu/drm/i915/intel_ringbuffer.h | 23 ++--
3 files changed, 82 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d3264bd6e9dc..7209c22798e6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,7 +25,6 @@
#include
#include "i915_drv.h"
-#include "i915_vgpu.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
@@ -456,21 +455,10 @@ static void intel_engine_init_batch_pool(struct
intel_engine_cs *engine)
i915_gem_batch_pool_init(&engine->batch_pool, engine);
}
-static bool csb_force_mmio(struct drm_i915_private *i915)
-{
- /* Older GVT emulation depends upon intercepting CSB mmio */
- if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
- return true;
-
- return false;
-}
-
static void intel_engine_init_execlist(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- execlists->csb_use_mmio = csb_force_mmio(engine->i915);
-
execlists->port_mask = 1;
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 91656eb2f2db..8531a5b6f6ff 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
#include
#include "i915_drv.h"
#include "i915_gem_render_state.h"
+#include "i915_vgpu.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_workarounds.h"
@@ -953,44 +954,40 @@ static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
- struct drm_i915_private *i915 = engine->i915;
-
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
- bool fw = false;
+ const u32 * const buf = execlists->csb_status;
+ u8 head, tail;
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_use_mmio)) {
- intel_uncore_forcewake_get(i915, execlists->fw_domains);
- fw = true;
-
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-
- head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ /*
+* Note that csb_write, csb_status may be either in HWSP or mmio.
+* When reading from the csb_write mmio register, we have to be
+* careful to only use the GEN8_CSB_WRITE_PTR portion, which is
+* the low 4bits. As it happens we know the next 4bits are always
+* zero and so we can simply masked off the low u8 of the register
+* and treat it identically to reading from the HWSP (without having
+* to use explicit shifting and masking, and probably bifurcating
+* the code to handle the legacy mmio read).
+*/
+ head = execlists->csb_head;
+ tail = READ_ONCE(*execlists->csb_write);
+ GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
+ if (unlikely(head == tail))
+ return;
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- engine->name,
- head, GEN8_CSB_
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_universal_plane: Flush pending cleanups
Quoting Maarten Lankhorst (2018-06-28 12:06:35) > Op 28-06-18 om 12:51 schreef Chris Wilson: > > drm_atomic_helper allows for up to one outstanding cleanup task to be in > > flight before a new modeset (see stall_commit in stall_checks()), In > > lieu of hooking up a debugfs to force flushing of the outstanding work, > > submit enough blocking modesets to ensure that the pending work is > > completed before continuing. > > > > Signed-off-by: Chris Wilson > > Cc: Maarten Lankhorst > > --- > > tests/kms_universal_plane.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c > > index 58f329e68..f875fd194 100644 > > --- a/tests/kms_universal_plane.c > > +++ b/tests/kms_universal_plane.c > > @@ -638,6 +638,7 @@ cursor_leak_test_pipe(data_t *data, enum pipe pipe, > > igt_output_t *output) > > igt_plane_set_fb(primary, NULL); > > igt_plane_set_fb(cursor, NULL); > > igt_display_commit2(display, COMMIT_LEGACY); > > + igt_display_commit2(display, COMMIT_LEGACY); > > cursor_leak_test_fini(data, output, &background_fb, cursor_fb); > > > > /* We should be back to the same framebuffer count as when we started > > */ > > This won't work, we won't commit anything without anything changed, probably > best to put the set_fb in the loop too. Fill in the details above. :-p Is that igt or the kernel? I have this belief that when I ask it to do something, it should ;) igt_display_commit3(display, COMMIT_LEGACY, DOIT); -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3)
== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3) URL : https://patchwork.freedesktop.org/series/45531/ State : failure == Summary == Applying: drm/i915: Drop posting reads to flush master interrupts Applying: drm/i915/execlists: Pull submit after dequeue under timeline lock Applying: drm/i915/execlists: Pull CSB reset under the timeline.lock Applying: drm/i915/execlists: Process one CSB update at a time Applying: drm/i915/execlists: Unify CSB access pointers Applying: drm/i915/execlists: Reset CSB write pointer after reset Applying: drm/i915/execlists: Stop storing the CSB read pointer in the mmio register Applying: drm/i915/execlists: Trust the CSB error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_irq.c). error: could not build fake ancestor Patch failed at 0008 drm/i915/execlists: Trust the CSB Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Unify CSB access pointers
On 28/06/2018 12:13, Chris Wilson wrote:
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce the CSB access to a set of read/write/buffer pointers and
treat the various paths identically and not worry about forcewake.
(Forcewake is nightmare for worstcase latency, and we want to process
this all with irqsoff -- no latency allowed!)
v2: Comments, comments, comments. Well, 2 bonus comments.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel_lrc.c| 133
drivers/gpu/drm/i915/intel_ringbuffer.h | 23 ++--
3 files changed, 82 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d3264bd6e9dc..7209c22798e6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,7 +25,6 @@
#include
#include "i915_drv.h"
-#include "i915_vgpu.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
@@ -456,21 +455,10 @@ static void intel_engine_init_batch_pool(struct intel_engine_cs *engine)
i915_gem_batch_pool_init(&engine->batch_pool, engine);
}
-static bool csb_force_mmio(struct drm_i915_private *i915)
-{
- /* Older GVT emulation depends upon intercepting CSB mmio */
- if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
- return true;
-
- return false;
-}
-
static void intel_engine_init_execlist(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- execlists->csb_use_mmio = csb_force_mmio(engine->i915);
-
execlists->port_mask = 1;
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 91656eb2f2db..8531a5b6f6ff 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
#include
#include "i915_drv.h"
#include "i915_gem_render_state.h"
+#include "i915_vgpu.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_workarounds.h"
@@ -953,44 +954,40 @@ static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
- struct drm_i915_private *i915 = engine->i915;
-
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
- bool fw = false;
+ const u32 * const buf = execlists->csb_status;
+ u8 head, tail;
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_use_mmio)) {
- intel_uncore_forcewake_get(i915, execlists->fw_domains);
- fw = true;
-
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-
- head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ /*
+* Note that csb_write, csb_status may be either in HWSP or mmio.
+* When reading from the csb_write mmio register, we have to be
+* careful to only use the GEN8_CSB_WRITE_PTR portion, which is
+* the low 4bits. As it happens we know the next 4bits are always
+* zero and so we can simply masked off the low u8 of the register
+* and treat it identically to reading from the HWSP (without having
+* to use explicit shifting and masking, and probably bifurcating
+* the code to handle the legacy mmio read).
+*/
+ head = execlists->csb_head;
+ tail = READ_ONCE(*execlists->csb_write);
+ GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
+ if (unlikely(head == tail))
+ return;
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- en
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_universal_plane: Flush pending cleanups
Op 28-06-18 om 13:16 schreef Chris Wilson: > Quoting Maarten Lankhorst (2018-06-28 12:06:35) >> Op 28-06-18 om 12:51 schreef Chris Wilson: >>> drm_atomic_helper allows for up to one outstanding cleanup task to be in >>> flight before a new modeset (see stall_commit in stall_checks()), In >>> lieu of hooking up a debugfs to force flushing of the outstanding work, >>> submit enough blocking modesets to ensure that the pending work is >>> completed before continuing. >>> >>> Signed-off-by: Chris Wilson >>> Cc: Maarten Lankhorst >>> --- >>> tests/kms_universal_plane.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c >>> index 58f329e68..f875fd194 100644 >>> --- a/tests/kms_universal_plane.c >>> +++ b/tests/kms_universal_plane.c >>> @@ -638,6 +638,7 @@ cursor_leak_test_pipe(data_t *data, enum pipe pipe, >>> igt_output_t *output) >>> igt_plane_set_fb(primary, NULL); >>> igt_plane_set_fb(cursor, NULL); >>> igt_display_commit2(display, COMMIT_LEGACY); >>> + igt_display_commit2(display, COMMIT_LEGACY); >>> cursor_leak_test_fini(data, output, &background_fb, cursor_fb); >>> >>> /* We should be back to the same framebuffer count as when we started >>> */ >> This won't work, we won't commit anything without anything changed, probably >> best to put the set_fb in the loop too. > Fill in the details above. :-p > > Is that igt or the kernel? I have this belief that when I ask it to do > something, it should ;) > > igt_display_commit3(display, COMMIT_LEGACY, DOIT); > -Chris But you didn't tell it to do anything, nothing changed from last commit, so nothing gets committed. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] drm/i915/execlists: Trust the CSB
On 27/06/2018 22:07, Chris Wilson wrote:
Now that we use the CSB stored in the CPU friendly HWSP, we do not need
to track interrupts for when the mmio CSB registers are valid and can
just check where we read up to last from the cached HWSP. This means we
can forgo the atomic bit tracking from interrupt, and in the next patch
it means we can check the CSB at any time.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 11 ++-
drivers/gpu/drm/i915/intel_engine_cs.c | 8 ++
drivers/gpu/drm/i915/intel_lrc.c| 38 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
4 files changed, 14 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3702992f9f75..44fb11ca3cab 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1469,15 +1469,10 @@ static void snb_gt_irq_handler(struct drm_i915_private
*dev_priv,
static void
gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
{
- struct intel_engine_execlists * const execlists = &engine->execlists;
bool tasklet = false;
- if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active)) {
- set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- tasklet = true;
- }
- }
+ if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
+ tasklet = true;
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
@@ -1485,7 +1480,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
}
if (tasklet)
- tasklet_hi_schedule(&execlists->tasklet);
+ tasklet_hi_schedule(&engine->execlists.tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7209c22798e6..ace93958689e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1353,12 +1353,10 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
read = GEN8_CSB_READ_PTR(ptr);
write = GEN8_CSB_WRITE_PTR(ptr);
- drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from
hws], interrupt posted? %s, tasklet queued? %s (%s)\n",
+ drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from
hws], tasklet queued? %s (%s)\n",
read, execlists->csb_head,
write,
intel_read_status_page(engine,
intel_hws_csb_write_index(engine->i915)),
- yesno(test_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted)),
yesno(test_bit(TASKLET_STATE_SCHED,
&engine->execlists.tasklet.state)),
enableddisabled(!atomic_read(&engine->execlists.tasklet.count)));
@@ -1570,11 +1568,9 @@ void intel_engine_dump(struct intel_engine_cs *engine,
spin_unlock(&b->rb_lock);
local_irq_restore(flags);
- drm_printf(m, "IRQ? 0x%lx (breadcrumbs? %s) (execlists? %s)\n",
+ drm_printf(m, "IRQ? 0x%lx (breadcrumbs? %s)\n",
engine->irq_posted,
yesno(test_bit(ENGINE_IRQ_BREADCRUMB,
- &engine->irq_posted)),
- yesno(test_bit(ENGINE_IRQ_EXECLIST,
&engine->irq_posted)));
drm_printf(m, "HWSP:\n");
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a6268103663f..87dd8ee117c8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -874,14 +874,6 @@ static void reset_irq(struct intel_engine_cs *engine)
smp_store_mb(engine->execlists.active, 0);
clear_gtiir(engine);
-
- /*
-* The port is checked prior to scheduling a tasklet, but
-* just in case we have suspended the tasklet to do the
-* wedging make sure that when it wakes, it decides there
-* is no work to do by clearing the irq_posted bit.
-*/
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
static void reset_csb_pointers(struct intel_engine_execlists *execlists)
@@ -972,10 +964,6 @@ static void process_csb(struct intel_engine_cs *engine)
const u32 * const buf = execlists->csb_status;
u8 head, tail;
- /* Clear before reading to catch new interrupts */
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- smp_mb__after_atomic();
-
/* Note that csb_write, csb_status may be either in HWSP or mmio */
head = execlists->csb_head;
tail = READ_ONCE(*execlists->csb_wri
Re: [Intel-gfx] [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset
Quoting Tvrtko Ursulin (2018-06-28 12:02:30)
>
> On 28/06/2018 11:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
> >>
> >> On 27/06/2018 22:07, Chris Wilson wrote:
> >>> On HW reset, the HW clears the write pointer (to 0). But since it also
> >>> writes its first CSB entry to slot 0, we need to reset the write pointer
> >>> back to the element before (so the first entry we read is 0).
> >>>
> >>> This is required for the next patch, where we trust the CSB completely!
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/intel_lrc.c | 19 +--
> >>>1 file changed, 17 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/intel_lrc.c
> >>> index 368a8c74d11d..8b111a268697 100644
> >>> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>> @@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
> >>>clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> >>>}
> >>>
> >>> +static void reset_csb_pointers(struct intel_engine_execlists *execlists)
> >>> +{
> >>> + /*
> >>> + * After a reset, the HW starts writing into CSB entry [0]. We
> >>> + * therefore have to set our HEAD pointer back one entry so that
> >>> + * the *first* entry we check is entry 0. To complicate this
> >>> further,
> >>> + * as we don't wait for the first interrupt after reset, we have to
> >>> + * fake the HW write to point back to the last entry so that our
> >>> + * inline comparison of our cached head position against the last HW
> >>> + * write works even before the first interrupt.
> >>> + */
> >>> + execlists->csb_head = GEN8_CSB_ENTRIES - 1;
> >>> + WRITE_ONCE(*execlists->csb_write, (GEN8_CSB_ENTRIES - 1) | 0xff <<
> >>> 16);
> >>
> >> Use _MASKED_FIELD and GEN8_CSB_WRITE_PTR_MASK?
> >
> > Hah, there goes my attempt to kill off unused magic.
>
> At least _MASKED_FIELD makes it clearer.
>
> But the u8 trick is still evil since here you even explicitly do a fake
> masked write on hwsp. Ugly and evil. How about storing
> execlists->csb_write_default at init time and applying it here?
Honestly, I thought it made sense next to the READ_ONCE(*csb_write).
Could I just convince you with another comment pleading guilty to the
atrocities?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_universal_plane: Flush pending cleanups
Quoting Maarten Lankhorst (2018-06-28 12:25:18) > Op 28-06-18 om 13:16 schreef Chris Wilson: > > Quoting Maarten Lankhorst (2018-06-28 12:06:35) > >> Op 28-06-18 om 12:51 schreef Chris Wilson: > >>> drm_atomic_helper allows for up to one outstanding cleanup task to be in > >>> flight before a new modeset (see stall_commit in stall_checks()), In > >>> lieu of hooking up a debugfs to force flushing of the outstanding work, > >>> submit enough blocking modesets to ensure that the pending work is > >>> completed before continuing. > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Maarten Lankhorst > >>> --- > >>> tests/kms_universal_plane.c | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c > >>> index 58f329e68..f875fd194 100644 > >>> --- a/tests/kms_universal_plane.c > >>> +++ b/tests/kms_universal_plane.c > >>> @@ -638,6 +638,7 @@ cursor_leak_test_pipe(data_t *data, enum pipe pipe, > >>> igt_output_t *output) > >>> igt_plane_set_fb(primary, NULL); > >>> igt_plane_set_fb(cursor, NULL); > >>> igt_display_commit2(display, COMMIT_LEGACY); > >>> + igt_display_commit2(display, COMMIT_LEGACY); > >>> cursor_leak_test_fini(data, output, &background_fb, cursor_fb); > >>> > >>> /* We should be back to the same framebuffer count as when we > >>> started */ > >> This won't work, we won't commit anything without anything changed, > >> probably best to put the set_fb in the loop too. > > Fill in the details above. :-p > > > > Is that igt or the kernel? I have this belief that when I ask it to do > > something, it should ;) > > > > igt_display_commit3(display, COMMIT_LEGACY, DOIT); > > -Chris > > But you didn't tell it to do anything, nothing changed from last commit, so > nothing gets committed. But I want it to reapply the commit I built up. That's how I think of it, since I'm used to a stateless API. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset
On 28/06/2018 12:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 12:02:30)
On 28/06/2018 11:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
On 27/06/2018 22:07, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 368a8c74d11d..8b111a268697 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
+static void reset_csb_pointers(struct intel_engine_execlists *execlists)
+{
+ /*
+ * After a reset, the HW starts writing into CSB entry [0]. We
+ * therefore have to set our HEAD pointer back one entry so that
+ * the *first* entry we check is entry 0. To complicate this further,
+ * as we don't wait for the first interrupt after reset, we have to
+ * fake the HW write to point back to the last entry so that our
+ * inline comparison of our cached head position against the last HW
+ * write works even before the first interrupt.
+ */
+ execlists->csb_head = GEN8_CSB_ENTRIES - 1;
+ WRITE_ONCE(*execlists->csb_write, (GEN8_CSB_ENTRIES - 1) | 0xff << 16);
Use _MASKED_FIELD and GEN8_CSB_WRITE_PTR_MASK?
Hah, there goes my attempt to kill off unused magic.
At least _MASKED_FIELD makes it clearer.
But the u8 trick is still evil since here you even explicitly do a fake
masked write on hwsp. Ugly and evil. How about storing
execlists->csb_write_default at init time and applying it here?
Honestly, I thought it made sense next to the READ_ONCE(*csb_write).
Could I just convince you with another comment pleading guilty to the
atrocities?
I'd prefer we did not write random stuff into hwsp. Like if one day
someone is debugging something, they could see either 0xff00?? or 0x??
in there depending on the timings. Then would have to waste time
figuring out what's happening.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_universal_plane: Flush pending cleanups
Op 28-06-18 om 13:34 schreef Chris Wilson: > Quoting Maarten Lankhorst (2018-06-28 12:25:18) >> Op 28-06-18 om 13:16 schreef Chris Wilson: >>> Quoting Maarten Lankhorst (2018-06-28 12:06:35) Op 28-06-18 om 12:51 schreef Chris Wilson: > drm_atomic_helper allows for up to one outstanding cleanup task to be in > flight before a new modeset (see stall_commit in stall_checks()), In > lieu of hooking up a debugfs to force flushing of the outstanding work, > submit enough blocking modesets to ensure that the pending work is > completed before continuing. > > Signed-off-by: Chris Wilson > Cc: Maarten Lankhorst > --- > tests/kms_universal_plane.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c > index 58f329e68..f875fd194 100644 > --- a/tests/kms_universal_plane.c > +++ b/tests/kms_universal_plane.c > @@ -638,6 +638,7 @@ cursor_leak_test_pipe(data_t *data, enum pipe pipe, > igt_output_t *output) > igt_plane_set_fb(primary, NULL); > igt_plane_set_fb(cursor, NULL); > igt_display_commit2(display, COMMIT_LEGACY); > + igt_display_commit2(display, COMMIT_LEGACY); > cursor_leak_test_fini(data, output, &background_fb, cursor_fb); > > /* We should be back to the same framebuffer count as when we > started */ This won't work, we won't commit anything without anything changed, probably best to put the set_fb in the loop too. >>> Fill in the details above. :-p >>> >>> Is that igt or the kernel? I have this belief that when I ask it to do >>> something, it should ;) >>> >>> igt_display_commit3(display, COMMIT_LEGACY, DOIT); >>> -Chris >> But you didn't tell it to do anything, nothing changed from last commit, so >> nothing gets committed. > But I want it to reapply the commit I built up. That's how I think of > it, since I'm used to a stateless API. > -Chris But there's nothing to apply, the commit is already applied. That's how the api has always worked, at least. :) ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 08/40] drm/i915: Initialize HDCP2.2 and its MEI interface
[ The bot has a bug where it doesn't copy the error messages so I just
guess what the issue is. - dan ]
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180627-174219
base: git://anongit.freedesktop.org/drm-intel for-linux-next
#
https://github.com/0day-ci/linux/commit/86525c76cf90e793d6d915879e144924d1520d60
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 86525c76cf90e793d6d915879e144924d1520d60
vim +941 drivers/gpu/drm/i915/intel_hdcp.c
86525c76 Ramalingam C 2018-06-27 913
86525c76 Ramalingam C 2018-06-27 914 static int
i915_hdcp_component_master_bind(struct device *dev)
86525c76 Ramalingam C 2018-06-27 915 {
86525c76 Ramalingam C 2018-06-27 916 struct drm_i915_private *dev_priv =
kdev_to_i915(dev);
86525c76 Ramalingam C 2018-06-27 917 struct i915_hdcp_component *comp =
dev_priv->hdcp_comp;
86525c76 Ramalingam C 2018-06-27 918 int ret;
86525c76 Ramalingam C 2018-06-27 919
86525c76 Ramalingam C 2018-06-27 920 mutex_lock(&comp->mutex);
86525c76 Ramalingam C 2018-06-27 921 ret = component_bind_all(dev, comp);
86525c76 Ramalingam C 2018-06-27 922 if (ret < 0)
86525c76 Ramalingam C 2018-06-27 923 return ret;
^^
We should unlock before returning. goto unlock. We probably don't want
to unbind if the bind failed?
86525c76 Ramalingam C 2018-06-27 924
86525c76 Ramalingam C 2018-06-27 925 /*
86525c76 Ramalingam C 2018-06-27 926* Atm, we don't support dynamic
unbinding initiated by the child
86525c76 Ramalingam C 2018-06-27 927* component, so pin its containing
module until we unbind.
86525c76 Ramalingam C 2018-06-27 928*/
86525c76 Ramalingam C 2018-06-27 929 if (!try_module_get(comp->ops->owner)) {
86525c76 Ramalingam C 2018-06-27 930 ret = -ENODEV;
86525c76 Ramalingam C 2018-06-27 931 goto out_unbind;
86525c76 Ramalingam C 2018-06-27 932 }
86525c76 Ramalingam C 2018-06-27 933
86525c76 Ramalingam C 2018-06-27 934 mutex_unlock(&comp->mutex);
86525c76 Ramalingam C 2018-06-27 935 return 0;
86525c76 Ramalingam C 2018-06-27 936
86525c76 Ramalingam C 2018-06-27 937 out_unbind:
86525c76 Ramalingam C 2018-06-27 938 component_unbind_all(dev, comp);
86525c76 Ramalingam C 2018-06-27 939 mutex_unlock(&comp->mutex);
86525c76 Ramalingam C 2018-06-27 940
86525c76 Ramalingam C 2018-06-27 @941 return ret;
86525c76 Ramalingam C 2018-06-27 942 }
86525c76 Ramalingam C 2018-06-27 943
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
On 27/06/2018 16:28, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-06-27 16:21:24) On 27/06/2018 14:29, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-06-27 14:15:22) On 27/06/2018 11:58, Chris Wilson wrote: That tasklets get kicked randomly, I think was the culprit. What do you mean? I hope we have busy-idle quite controlled and we know when we should and should expect a tasklet. If we synced them when transitioning to idle they cannot happen. Otherwise we better be active! GEM_BUG_ON(!engine->i915->gt.awake) instead? Does that trigger?! tasklet_schedule() is called off the main path, without locking, so unsynchronized to parking. Just because. I need to understand this - which main path? Submission - we will be mark_busy. After last request - we will idle the engines and sync the tasklet. There's a bonus kick in intel_engine_is_idle() (behind an unprotected read of active, so still possible to race), and I've added an unconditional kick to pmu_enable because we play games with tasklet_disable there that may cause us to miss a direct submission. intel_engine_is_idle form the idle work handler is before awake is cleared, so not that? And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't taking the timeline lock around active state reconstruction solve that simpler? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/execlists: Reset CSB write pointer after reset
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
v2: Use _MASKED_FIELD
v3: Store the reset value, so that we differentiate between mmio/hwsp
transparently and without pretense.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c| 23 +--
drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8531a5b6f6ff..49bf5048043c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
+static void reset_csb_pointers(struct intel_engine_execlists *execlists)
+{
+ /*
+* After a reset, the HW starts writing into CSB entry [0]. We
+* therefore have to set our HEAD pointer back one entry so that
+* the *first* entry we check is entry 0. To complicate this further,
+* as we don't wait for the first interrupt after reset, we have to
+* fake the HW write to point back to the last entry so that our
+* inline comparison of our cached head position against the last HW
+* write works even before the first interrupt.
+*/
+ execlists->csb_head = execlists->csb_write_reset & 0xff;
+ WRITE_ONCE(*execlists->csb_write, execlists->csb_write_reset);
+}
+
static void execlists_cancel_requests(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -1970,7 +1985,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
__unwind_incomplete_requests(engine);
/* Following the reset, we need to reload the CSB read/write pointers */
- engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
+ reset_csb_pointers(&engine->execlists);
spin_unlock_irqrestore(&engine->timeline.lock, flags);
@@ -2469,7 +2484,6 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
upper_32_bits(ce->lrc_desc);
}
- execlists->csb_head = GEN8_CSB_ENTRIES - 1;
execlists->csb_read =
i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
if (csb_force_mmio(i915)) {
@@ -2477,13 +2491,18 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
execlists->csb_write = (u32 __force *)execlists->csb_read;
+ execlists->csb_write_reset =
+ _MASKED_FIELD(GEN8_CSB_WRITE_PTR_MASK,
+ GEN8_CSB_ENTRIES - 1);
} else {
execlists->csb_status =
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
execlists->csb_write =
&engine->status_page.page_addr[intel_hws_csb_write_index(i915)];
+ execlists->csb_write_reset = GEN8_CSB_ENTRIES - 1;
}
+ reset_csb_pointers(execlists);
return 0;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 970dbb3c9812..6ec7c019b5d9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -304,6 +304,15 @@ struct intel_engine_execlists {
*/
unsigned int csb_head;
+ /**
+* @csb_write_reset: reset value for CSB write pointer
+*
+* As the CSB write pointer maybe either in HWSP or as a field
+* inside an mmio register, we want to reprogram it slightly
+* differently to avoid later confusion.
+*/
+ u32 csb_write_reset;
+
/**
* @csb_read: control register for Context Switch buffer
*
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] drm/i915/execlists: Trust the CSB
Quoting Tvrtko Ursulin (2018-06-28 12:29:41)
>
> On 27/06/2018 22:07, Chris Wilson wrote:
> > @@ -1881,6 +1861,7 @@ execlists_reset_prepare(struct intel_engine_cs
> > *engine)
> > {
> > struct intel_engine_execlists * const execlists = &engine->execlists;
> > struct i915_request *request, *active;
> > + unsigned long flags;
> >
> > GEM_TRACE("%s\n", engine->name);
> >
> > @@ -1902,8 +1883,9 @@ execlists_reset_prepare(struct intel_engine_cs
> > *engine)
> >* and avoid blaming an innocent request if the stall was due to the
> >* preemption itself.
> >*/
> > - if (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted))
> > - process_csb(engine);
> > + spin_lock_irqsave(&engine->timeline.lock, flags);
> > +
> > + process_csb(engine);
>
> I think taking the lock over process_csb belongs in the following patch.
Splitter!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: encourage BIT() macro usage in register definitions
On Wed, 27 Jun 2018, Chris Wilson wrote: > Quoting Michal Wajdeczko (2018-06-27 16:51:42) >> On Wed, 27 Jun 2018 16:41:13 +0200, Jani Nikula >> wrote: >> >> > There's already some BIT() usage here and there, embrace it. >> > >> > Cc: Paulo Zanoni >> > Signed-off-by: Jani Nikula >> > --- >> > drivers/gpu/drm/i915/i915_reg.h | 9 + >> > 1 file changed, 5 insertions(+), 4 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h >> > b/drivers/gpu/drm/i915/i915_reg.h >> > index 476118f46cf3..64b9c270045d 100644 >> > --- a/drivers/gpu/drm/i915/i915_reg.h >> > +++ b/drivers/gpu/drm/i915/i915_reg.h >> > @@ -65,9 +65,10 @@ >> > * but do note that the macros may be needed to read as well as write >> > the >> > * register contents. >> > * >> > - * Define bits using ``(1 << N)`` instead of ``BIT(N)``. We may change >> > this in >> > - * the future, but this is the prevailing style. Do **not** add >> > ``_BIT`` suffix >> > - * to the name. >> > + * Define bits using ``BIT(N)`` instead of ``(1 << N)``. Do **not** add >> > ``_BIT`` >> > + * suffix to the name. Exception to ``BIT()`` usage: Value 1 for a bit >> > field >> > + * should be defined using ``(1 << N)`` to be in line with other values >> > such as >> > + * ``(2 << N)`` for the same field. >> > * >> > * Group the register and its contents together without blank lines, >> > separate >> > * from other registers and their contents with one blank line. >> > @@ -105,7 +106,7 @@ >> > * #define _FOO_A 0xf000 >> > * #define _FOO_B 0xf001 >> > * #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B) >> > - * #define FOO_ENABLE(1 << 31) >> > + * #define FOO_ENABLEBIT(31) >> >> hmm, this breaks nice consistency between one- and multi-bit fields .. >> >> > * #define FOO_MODE_MASK (0xf << 16) >> >> .. but if you want to use macro for single bit, then maybe you should >> also consider other existing macro for the mask definition: >> >> #define FOO_MODE_MASK GENMASK(19, 16) >> >> > * #define FOO_MODE_SHIFT16 >> > * #define FOO_MODE_BAR (0 << 16) >> >> .. but we still don't have any macro for defining multi-bit values >> so I'm not sure if this change will make code really easier to read > > #include > > I'm not sure if I'm ready to embrace that yet, but it does seem to be > the direction we should be heading in. Primarily to check the invalid > range checking & usage. I guess there are two things here. Using bitfield.h macros to define our own stuff is one thing, like so: #define FOO_ENABLEBIT(31) #define FOO_MODE_MASK GENMASK(19, 16) #define FOO_MODE_SHIFT16 #define FOO_MODE_BAR FIELD_PREP(FOO_MODE_MASK, 0) #define FOO_MODE_BAZ FIELD_PREP(FOO_MODE_MASK, 1) #define FOO_MODE_QUX_SNB FIELD_PREP(FOO_MODE_MASK, 2) The range checking is indeed an advantage. Using FIELD_PREP() or FIELD_GET() in code is another, because we currently don't define the *unshifted* field values. Everything is defined with the shift. Defining everything unshifted and then moving the FIELD_PREP() and FIELD_GET() in code would be quite the change. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Quoting Tvrtko Ursulin (2018-06-28 12:56:56) > > On 27/06/2018 16:28, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-06-27 16:21:24) > >> > >> On 27/06/2018 14:29, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2018-06-27 14:15:22) > > On 27/06/2018 11:58, Chris Wilson wrote: > > That tasklets get kicked randomly, I think was the culprit. > > What do you mean? I hope we have busy-idle quite controlled and we know > when we should and should expect a tasklet. If we synced them when > transitioning to idle they cannot happen. Otherwise we better be active! > GEM_BUG_ON(!engine->i915->gt.awake) instead? Does that trigger?! > >>> > >>> tasklet_schedule() is called off the main path, without locking, so > >>> unsynchronized to parking. Just because. > >> > >> I need to understand this - which main path? Submission - we will be > >> mark_busy. After last request - we will idle the engines and sync the > >> tasklet. > > > > There's a bonus kick in intel_engine_is_idle() (behind an unprotected > > read of active, so still possible to race), and I've added an > > unconditional kick to pmu_enable because we play games with > > tasklet_disable there that may cause us to miss a direct submission. > > intel_engine_is_idle form the idle work handler is before awake is > cleared, so not that? intel_engine_is_idle() may be called at any time though, and will race. > And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't > taking the timeline lock around active state reconstruction solve that > simpler? Can you? We probably can. (That one was a very recent discovery and quick fix.) Since that was a very recent discovery, my fallible memory says the GEM_BUG_ON() popped up from intel_engine_is_idle. Not that everything has changed since then, ofc. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev4)
== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev4) URL : https://patchwork.freedesktop.org/series/45531/ State : failure == Summary == Applying: drm/i915: Drop posting reads to flush master interrupts Applying: drm/i915/execlists: Pull submit after dequeue under timeline lock Applying: drm/i915/execlists: Pull CSB reset under the timeline.lock Applying: drm/i915/execlists: Process one CSB update at a time Applying: drm/i915/execlists: Unify CSB access pointers Applying: drm/i915/execlists: Reset CSB write pointer after reset Applying: drm/i915/execlists: Stop storing the CSB read pointer in the mmio register Applying: drm/i915/execlists: Trust the CSB error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_irq.c). error: could not build fake ancestor Patch failed at 0008 drm/i915/execlists: Trust the CSB Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Quoting Chris Wilson (2018-06-28 13:07:51) > Quoting Tvrtko Ursulin (2018-06-28 12:56:56) > > And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't > > taking the timeline lock around active state reconstruction solve that > > simpler? > > Can you? We probably can. (That one was a very recent discovery and > quick fix.) The biggest issue being whether or not the same locking applies equally to all submission backends. That's not yet true, but then again we don't use stats everywhere. So whether or not that's an issue, I don't know, but it's enough to make me want to punt changing the locking inside intel_enable_engine_stats to a separate patch. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/execlists: Reset CSB write pointer after reset
On 28/06/2018 12:59, Chris Wilson wrote:
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
v2: Use _MASKED_FIELD
v3: Store the reset value, so that we differentiate between mmio/hwsp
transparently and without pretense.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c| 23 +--
drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8531a5b6f6ff..49bf5048043c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
+static void reset_csb_pointers(struct intel_engine_execlists *execlists)
+{
+ /*
+* After a reset, the HW starts writing into CSB entry [0]. We
+* therefore have to set our HEAD pointer back one entry so that
+* the *first* entry we check is entry 0. To complicate this further,
+* as we don't wait for the first interrupt after reset, we have to
+* fake the HW write to point back to the last entry so that our
+* inline comparison of our cached head position against the last HW
+* write works even before the first interrupt.
+*/
+ execlists->csb_head = execlists->csb_write_reset & 0xff;
Idea for avoiding the & 0xff and applying the trick throughout - make
csb_head u8. :)
+ WRITE_ONCE(*execlists->csb_write, execlists->csb_write_reset);
+}
+
static void execlists_cancel_requests(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -1970,7 +1985,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
__unwind_incomplete_requests(engine);
/* Following the reset, we need to reload the CSB read/write pointers */
- engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
+ reset_csb_pointers(&engine->execlists);
spin_unlock_irqrestore(&engine->timeline.lock, flags);
@@ -2469,7 +2484,6 @@ static int logical_ring_init(struct intel_engine_cs *engine)
upper_32_bits(ce->lrc_desc);
}
- execlists->csb_head = GEN8_CSB_ENTRIES - 1;
execlists->csb_read =
i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
if (csb_force_mmio(i915)) {
@@ -2477,13 +2491,18 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
execlists->csb_write = (u32 __force *)execlists->csb_read;
+ execlists->csb_write_reset =
+ _MASKED_FIELD(GEN8_CSB_WRITE_PTR_MASK,
+ GEN8_CSB_ENTRIES - 1);
} else {
execlists->csb_status =
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
execlists->csb_write =
&engine->status_page.page_addr[intel_hws_csb_write_index(i915)];
+ execlists->csb_write_reset = GEN8_CSB_ENTRIES - 1;
}
+ reset_csb_pointers(execlists);
return 0;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 970dbb3c9812..6ec7c019b5d9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -304,6 +304,15 @@ struct intel_engine_execlists {
*/
unsigned int csb_head;
+ /**
+* @csb_write_reset: reset value for CSB write pointer
+*
+* As the CSB write pointer maybe either in HWSP or as a field
+* inside an mmio register, we want to reprogram it slightly
+* differently to avoid later confusion.
+*/
+ u32 csb_write_reset;
+
/**
* @csb_read: control register for Context Switch buffer
*
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/execlists: Reset CSB write pointer after reset
Quoting Tvrtko Ursulin (2018-06-28 13:15:07)
>
> On 28/06/2018 12:59, Chris Wilson wrote:
> > On HW reset, the HW clears the write pointer (to 0). But since it also
> > writes its first CSB entry to slot 0, we need to reset the write pointer
> > back to the element before (so the first entry we read is 0).
> >
> > This is required for the next patch, where we trust the CSB completely!
> >
> > v2: Use _MASKED_FIELD
> > v3: Store the reset value, so that we differentiate between mmio/hwsp
> > transparently and without pretense.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c| 23 +--
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +
> > 2 files changed, 30 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 8531a5b6f6ff..49bf5048043c 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
> > clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> > }
> >
> > +static void reset_csb_pointers(struct intel_engine_execlists *execlists)
> > +{
> > + /*
> > + * After a reset, the HW starts writing into CSB entry [0]. We
> > + * therefore have to set our HEAD pointer back one entry so that
> > + * the *first* entry we check is entry 0. To complicate this further,
> > + * as we don't wait for the first interrupt after reset, we have to
> > + * fake the HW write to point back to the last entry so that our
> > + * inline comparison of our cached head position against the last HW
> > + * write works even before the first interrupt.
> > + */
> > + execlists->csb_head = execlists->csb_write_reset & 0xff;
>
> Idea for avoiding the & 0xff and applying the trick throughout - make
> csb_head u8. :)
Just leaves intel_engine_execlists full of holes. It did close my mind.
They may just spontaneously rearrange themselves...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
On 28/06/2018 13:11, Chris Wilson wrote: Quoting Chris Wilson (2018-06-28 13:07:51) Quoting Tvrtko Ursulin (2018-06-28 12:56:56) And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't taking the timeline lock around active state reconstruction solve that simpler? Can you? We probably can. (That one was a very recent discovery and quick fix.) The biggest issue being whether or not the same locking applies equally to all submission backends. That's not yet true, but then again we don't use stats everywhere. So whether or not that's an issue, I don't know, but it's enough to make me want to punt changing the locking inside intel_enable_engine_stats to a separate patch. Big benefit is removing the extra tasklet schedule from engine stats which is in fact even racy. We need the state reconstruction to be atomic so I think it really needs to be under the engine lock. tasklet_disable/enable can then also be dropped I think. To which patch in this series that belongs is the question. Last one I think, when all is in place that port updates are protected by the timeline lock. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915/execlists: Process one CSB update at a time
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
v2: Tvrtko pointed out it was safer to unconditionally kick the tasklet
after each irq, when assuming that the tasklet is called for each irq.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 7 +-
drivers/gpu/drm/i915/intel_lrc.c | 278 +++
2 files changed, 141 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e83fcedcbf1d..97418efec719 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1482,9 +1482,10 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
bool tasklet = false;
if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active))
- tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted);
+ if (READ_ONCE(engine->execlists.active)) {
+ set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+ tasklet = true;
+ }
}
if (iir & GT_RENDER_USER_INTERRUPT) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4b31e8f42aeb..91656eb2f2db 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -954,166 +954,162 @@ static void process_csb(struct intel_engine_cs *engine)
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
struct drm_i915_private *i915 = engine->i915;
+
+ /* The HWSP contains a (cacheable) mirror of the CSB */
+ const u32 *buf =
+ &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
+ unsigned int head, tail;
bool fw = false;
- do {
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
-
- /* Clear before reading to catch new interrupts */
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- smp_mb__after_atomic();
-
- if (unlikely(execlists->csb_use_mmio)) {
- if (!fw) {
- intel_uncore_forcewake_get(i915,
execlists->fw_domains);
- fw = true;
- }
+ /* Clear before reading to catch new interrupts */
+ clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+ smp_mb__after_atomic();
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+ if (unlikely(execlists->csb_use_mmio)) {
+ intel_uncore_forcewake_get(i915, execlists->fw_domains);
+ fw = true;
- head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ buf = (u32 * __force)
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- engine->name,
- head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
+ head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+ tail = GEN8_CSB_WRITE_PTR(head);
+ head = GEN8_CSB_READ_PTR(head);
+ execlists->csb_head = head;
+ } else {
+ const int write_idx =
+ intel_hws_csb_write_index(i915) -
+ I915_HWS_CSB_BUF0_INDEX;
- while (head != tail) {
- struct i915_request *rq;
-
[Intel-gfx] [PATCH 1/9] drm/i915: Drop posting reads to flush master interrupts
We do not need to do a posting read of our uncached mmio write to
re-enable the master interrupt lines after handling an interrupt, so
don't. This saves us a slow UC read before we can process the interrupt,
most noticeable in execlists where any stalls imposes extra latency on
GPU command execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7a7c4a2bd778..e83fcedcbf1d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2168,7 +2168,6 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
I915_WRITE(VLV_IER, ier);
I915_WRITE(VLV_MASTER_IER, MASTER_INTERRUPT_ENABLE);
- POSTING_READ(VLV_MASTER_IER);
if (gt_iir)
snb_gt_irq_handler(dev_priv, gt_iir);
@@ -2253,7 +2252,6 @@ static irqreturn_t cherryview_irq_handler(int irq, void
*arg)
I915_WRITE(VLV_IER, ier);
I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
- POSTING_READ(GEN8_MASTER_IRQ);
gen8_gt_irq_handler(dev_priv, master_ctl, gt_iir);
@@ -2622,7 +2620,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
/* disable master interrupt before clearing iir */
de_ier = I915_READ(DEIER);
I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
- POSTING_READ(DEIER);
/* Disable south interrupts. We'll only write to SDEIIR once, so further
* interrupts will will be stored on its back queue, and then we'll be
@@ -2632,7 +2629,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
if (!HAS_PCH_NOP(dev_priv)) {
sde_ier = I915_READ(SDEIER);
I915_WRITE(SDEIER, 0);
- POSTING_READ(SDEIER);
}
/* Find, clear, then process each source of interrupt */
@@ -2667,11 +2663,8 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
}
I915_WRITE(DEIER, de_ier);
- POSTING_READ(DEIER);
- if (!HAS_PCH_NOP(dev_priv)) {
+ if (!HAS_PCH_NOP(dev_priv))
I915_WRITE(SDEIER, sde_ier);
- POSTING_READ(SDEIER);
- }
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
enable_rpm_wakeref_asserts(dev_priv);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915/execlists: Pull submit after dequeue under timeline lock
In the next patch, we will begin processing the CSB from inside the
submission path (underneath an irqsoff section, and even from inside
interrupt handlers). This means that updating the execlists->port[] will
no longer be serialised by the tasklet but needs to be locked by the
engine->timeline.lock instead. Pull dequeue and submit under the same
lock for protection. (An alternate future plan is to keep the in/out
arrays separate for concurrent processing and reduced lock coverage.)
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2b21a6596360..009db92b67d7 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -567,7 +567,7 @@ static void complete_preempt_context(struct
intel_engine_execlists *execlists)
execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
}
-static bool __execlists_dequeue(struct intel_engine_cs *engine)
+static void __execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
@@ -622,11 +622,11 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
* the HW to indicate that it has had a chance to respond.
*/
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_HWACK))
- return false;
+ return;
if (need_preempt(engine, last, execlists->queue_priority)) {
inject_preempt_context(engine);
- return false;
+ return;
}
/*
@@ -651,7 +651,7 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
* priorities of the ports haven't been switch.
*/
if (port_count(&port[1]))
- return false;
+ return;
/*
* WaIdleLiteRestore:bdw,skl
@@ -751,8 +751,10 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
port != execlists->port ? rq_prio(last) : INT_MIN;
execlists->first = rb;
- if (submit)
+ if (submit) {
port_assign(port, last);
+ execlists_submit_ports(engine);
+ }
/* We must always keep the beast fed if we have work piled up */
GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
@@ -761,24 +763,19 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
if (last)
execlists_user_begin(execlists, execlists->port);
- return submit;
+ /* If the engine is now idle, so should be the flag; and vice versa. */
+ GEM_BUG_ON(execlists_is_active(&engine->execlists,
+ EXECLISTS_ACTIVE_USER) ==
+ !port_isset(engine->execlists.port));
}
static void execlists_dequeue(struct intel_engine_cs *engine)
{
- struct intel_engine_execlists * const execlists = &engine->execlists;
unsigned long flags;
- bool submit;
spin_lock_irqsave(&engine->timeline.lock, flags);
- submit = __execlists_dequeue(engine);
+ __execlists_dequeue(engine);
spin_unlock_irqrestore(&engine->timeline.lock, flags);
-
- if (submit)
- execlists_submit_ports(engine);
-
- GEM_BUG_ON(port_isset(execlists->port) &&
- !execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
}
void
@@ -1161,11 +1158,6 @@ static void execlists_submission_tasklet(unsigned long
data)
if (!execlists_is_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT))
execlists_dequeue(engine);
-
- /* If the engine is now idle, so should be the flag; and vice versa. */
- GEM_BUG_ON(execlists_is_active(&engine->execlists,
- EXECLISTS_ACTIVE_USER) ==
- !port_isset(engine->execlists.port));
}
static void queue_request(struct intel_engine_cs *engine,
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915/execlists: Trust the CSB
Now that we use the CSB stored in the CPU friendly HWSP, we do not need
to track interrupts for when the mmio CSB registers are valid and can
just check where we read up to last from the cached HWSP. This means we
can forgo the atomic bit tracking from interrupt, and in the next patch
it means we can check the CSB at any time.
v2: Change the splitting inside reset_prepare, we only want to lose
testing the interrupt in this patch, the next patch requires the change
in locking
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 11 +++---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 ++-
drivers/gpu/drm/i915/intel_lrc.c| 29 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
4 files changed, 9 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 97418efec719..cb91b213aa67 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1478,15 +1478,10 @@ static void snb_gt_irq_handler(struct drm_i915_private
*dev_priv,
static void
gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
{
- struct intel_engine_execlists * const execlists = &engine->execlists;
bool tasklet = false;
- if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active)) {
- set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- tasklet = true;
- }
- }
+ if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
+ tasklet = true;
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
@@ -1494,7 +1489,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
}
if (tasklet)
- tasklet_hi_schedule(&execlists->tasklet);
+ tasklet_hi_schedule(&engine->execlists.tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7209c22798e6..ace93958689e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1353,12 +1353,10 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
read = GEN8_CSB_READ_PTR(ptr);
write = GEN8_CSB_WRITE_PTR(ptr);
- drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d
from hws], interrupt posted? %s, tasklet queued? %s (%s)\n",
+ drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d
from hws], tasklet queued? %s (%s)\n",
read, execlists->csb_head,
write,
intel_read_status_page(engine,
intel_hws_csb_write_index(engine->i915)),
- yesno(test_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted)),
yesno(test_bit(TASKLET_STATE_SCHED,
&engine->execlists.tasklet.state)),
enableddisabled(!atomic_read(&engine->execlists.tasklet.count)));
@@ -1570,11 +1568,9 @@ void intel_engine_dump(struct intel_engine_cs *engine,
spin_unlock(&b->rb_lock);
local_irq_restore(flags);
- drm_printf(m, "IRQ? 0x%lx (breadcrumbs? %s) (execlists? %s)\n",
+ drm_printf(m, "IRQ? 0x%lx (breadcrumbs? %s)\n",
engine->irq_posted,
yesno(test_bit(ENGINE_IRQ_BREADCRUMB,
- &engine->irq_posted)),
- yesno(test_bit(ENGINE_IRQ_EXECLIST,
&engine->irq_posted)));
drm_printf(m, "HWSP:\n");
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14be53035610..7f8b29684d9d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -874,14 +874,6 @@ static void reset_irq(struct intel_engine_cs *engine)
smp_store_mb(engine->execlists.active, 0);
clear_gtiir(engine);
-
- /*
-* The port is checked prior to scheduling a tasklet, but
-* just in case we have suspended the tasklet to do the
-* wedging make sure that when it wakes, it decides there
-* is no work to do by clearing the irq_posted bit.
-*/
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
static void reset_csb_pointers(struct intel_engine_execlists *execlists)
@@ -972,10 +964,6 @@ static void process_csb(struct intel_engine_cs *engine)
const u32 * const buf = execlists->csb_status;
u8 head, tail;
- /* Clear before reading to catch new interrupts */
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- smp_mb__after_atomic();
-
/*
[Intel-gfx] [PATCH 3/9] drm/i915/execlists: Pull CSB reset under the timeline.lock
In the following patch, we will process the CSB events under the
timeline.lock and not serialised by the tasklet. This also means that we
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
v2: Move sync_irq to avoid deadlocks between taking timeline.lock from
our interrupt handler.
v3: Kill off the synchronize_hardirq as it raises more questions than
answered; now we use the timeline.lock entirely for CSB serialisation
between the irq and elsewhere, we don't need to be so heavy handed with
flushing
v4: Treat request cancellation (wedging after failed reset) similarly
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 009db92b67d7..4b31e8f42aeb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -871,7 +871,6 @@ static void reset_irq(struct intel_engine_cs *engine)
{
/* Mark all CS interrupts as complete */
smp_store_mb(engine->execlists.active, 0);
- synchronize_hardirq(engine->i915->drm.irq);
clear_gtiir(engine);
@@ -908,14 +907,12 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
* submission's irq state, we also wish to remind ourselves that
* it is irq state.)
*/
- local_irq_save(flags);
+ spin_lock_irqsave(&engine->timeline.lock, flags);
/* Cancel the requests on the HW and clear the ELSP tracker. */
execlists_cancel_port_requests(execlists);
reset_irq(engine);
- spin_lock(&engine->timeline.lock);
-
/* Mark all executing requests as skipped. */
list_for_each_entry(rq, &engine->timeline.requests, link) {
GEM_BUG_ON(!rq->global_seqno);
@@ -949,9 +946,7 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
execlists->first = NULL;
GEM_BUG_ON(port_isset(execlists->port));
- spin_unlock(&engine->timeline.lock);
-
- local_irq_restore(flags);
+ spin_unlock_irqrestore(&engine->timeline.lock, flags);
}
static void process_csb(struct intel_engine_cs *engine)
@@ -1969,8 +1964,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
engine->name, request ? request->global_seqno : 0,
intel_engine_get_seqno(engine));
- /* See execlists_cancel_requests() for the irq/spinlock split. */
- local_irq_save(flags);
+ spin_lock_irqsave(&engine->timeline.lock, flags);
/*
* Catch up with any missed context-switch interrupts.
@@ -1985,14 +1979,12 @@ static void execlists_reset(struct intel_engine_cs
*engine,
reset_irq(engine);
/* Push back any incomplete requests for replay after the reset. */
- spin_lock(&engine->timeline.lock);
__unwind_incomplete_requests(engine);
- spin_unlock(&engine->timeline.lock);
/* Following the reset, we need to reload the CSB read/write pointers */
engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
- local_irq_restore(flags);
+ spin_unlock_irqrestore(&engine->timeline.lock, flags);
/*
* If the request was innocent, we leave the request in the ELSP
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915/execlists: Unify CSB access pointers
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce the CSB access to a set of read/write/buffer pointers and
treat the various paths identically and not worry about forcewake.
(Forcewake is nightmare for worstcase latency, and we want to process
this all with irqsoff -- no latency allowed!)
v2: Comments, comments, comments. Well, 2 bonus comments.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel_lrc.c| 133
drivers/gpu/drm/i915/intel_ringbuffer.h | 23 ++--
3 files changed, 82 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d3264bd6e9dc..7209c22798e6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,7 +25,6 @@
#include
#include "i915_drv.h"
-#include "i915_vgpu.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
@@ -456,21 +455,10 @@ static void intel_engine_init_batch_pool(struct
intel_engine_cs *engine)
i915_gem_batch_pool_init(&engine->batch_pool, engine);
}
-static bool csb_force_mmio(struct drm_i915_private *i915)
-{
- /* Older GVT emulation depends upon intercepting CSB mmio */
- if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
- return true;
-
- return false;
-}
-
static void intel_engine_init_execlist(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- execlists->csb_use_mmio = csb_force_mmio(engine->i915);
-
execlists->port_mask = 1;
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 91656eb2f2db..8531a5b6f6ff 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
#include
#include "i915_drv.h"
#include "i915_gem_render_state.h"
+#include "i915_vgpu.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_workarounds.h"
@@ -953,44 +954,40 @@ static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
- struct drm_i915_private *i915 = engine->i915;
-
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
- bool fw = false;
+ const u32 * const buf = execlists->csb_status;
+ u8 head, tail;
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_use_mmio)) {
- intel_uncore_forcewake_get(i915, execlists->fw_domains);
- fw = true;
-
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-
- head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ /*
+* Note that csb_write, csb_status may be either in HWSP or mmio.
+* When reading from the csb_write mmio register, we have to be
+* careful to only use the GEN8_CSB_WRITE_PTR portion, which is
+* the low 4bits. As it happens we know the next 4bits are always
+* zero and so we can simply masked off the low u8 of the register
+* and treat it identically to reading from the HWSP (without having
+* to use explicit shifting and masking, and probably bifurcating
+* the code to handle the legacy mmio read).
+*/
+ head = execlists->csb_head;
+ tail = READ_ONCE(*execlists->csb_write);
+ GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
+ if (unlikely(head == tail))
+ return;
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- engine->name,
-
[Intel-gfx] [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
v2: Use _MASKED_FIELD
v3: Store the reset value, so that we differentiate between mmio/hwsp
transparently and without pretense.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c| 23 +--
drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8531a5b6f6ff..f597a12f705b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
+static void reset_csb_pointers(struct intel_engine_execlists *execlists)
+{
+ /*
+* After a reset, the HW starts writing into CSB entry [0]. We
+* therefore have to set our HEAD pointer back one entry so that
+* the *first* entry we check is entry 0. To complicate this further,
+* as we don't wait for the first interrupt after reset, we have to
+* fake the HW write to point back to the last entry so that our
+* inline comparison of our cached head position against the last HW
+* write works even before the first interrupt.
+*/
+ execlists->csb_head = execlists->csb_write_reset;
+ WRITE_ONCE(*execlists->csb_write, execlists->csb_write_reset);
+}
+
static void execlists_cancel_requests(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -1970,7 +1985,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
__unwind_incomplete_requests(engine);
/* Following the reset, we need to reload the CSB read/write pointers */
- engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
+ reset_csb_pointers(&engine->execlists);
spin_unlock_irqrestore(&engine->timeline.lock, flags);
@@ -2469,7 +2484,6 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
upper_32_bits(ce->lrc_desc);
}
- execlists->csb_head = GEN8_CSB_ENTRIES - 1;
execlists->csb_read =
i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
if (csb_force_mmio(i915)) {
@@ -2477,13 +2491,18 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
execlists->csb_write = (u32 __force *)execlists->csb_read;
+ execlists->csb_write_reset =
+ _MASKED_FIELD(GEN8_CSB_WRITE_PTR_MASK,
+ GEN8_CSB_ENTRIES - 1);
} else {
execlists->csb_status =
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
execlists->csb_write =
&engine->status_page.page_addr[intel_hws_csb_write_index(i915)];
+ execlists->csb_write_reset = GEN8_CSB_ENTRIES - 1;
}
+ reset_csb_pointers(execlists);
return 0;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 80fde36561fb..62e3db6f6f8d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -325,6 +325,15 @@ struct intel_engine_execlists {
*/
u32 preempt_complete_status;
+ /**
+* @csb_write_reset: reset value for CSB write pointer
+*
+* As the CSB write pointer maybe either in HWSP or as a field
+* inside an mmio register, we want to reprogram it slightly
+* differently to avoid later confusion.
+*/
+ u32 csb_write_reset;
+
/**
* @csb_head: context status buffer head
*/
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on average! Deferring our work to a tasklet allowed us to do the
processing with irqs enabled, reducing the impact to an average of about
50us.
We have since eradicated the use of forcewaked mmio from inside the CSB
processing and ELSP submission, bringing the impact down to around 5us
(on Kabylake); an order of magnitude better than our measurements 2
years ago on Broadwell and only about 2x worse on average than the
gem_syslatency on an unladen system.
In this iteration of the tasklet-vs-direct submission debate, we seek a
compromise where by we submit new requests immediately to the HW but
defer processing the CS interrupt onto a tasklet. We gain the advantage
of low-latency and ksoftirqd avoidance when waking up the HW, while
avoiding the system-wide starvation of our CS irq-storms.
Comparing the impact on the maximum latency observed (that is the time
stolen from an RT process) over a 120s interval, repeated several times
(using gem_syslatency, similar to RT's cyclictest) while the system is
fully laden with i915 nops, we see that direct submission an actually
improve the worse case.
Maximum latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 2)
x Always using tasklets (a couple of >1000us outliers removed)
+ Only using tasklets from CS irq, direct submission of requests
++
| + |
| + |
| + |
| + + |
| + + + |
| + + + + x x x |
| +++ + + + x x x x x x |
| +++ + ++ + + *x x x x x x |
| +++ + ++ + * *x x * x x x |
|+ +++ + ++ * * +*xxx * x x xx |
|* +++ + * *x+**xx+ * x x x |
| **x*++**+*x*xx+ * +x xx x x|
|x* **+***++*+***xx* xx*x xxx +x+|
| |__MA___| |
| |__M__A| |
++
N Min MaxMedian AvgStddev
x 11891 186 124 125.28814 16.279137
+ 12092 187 109 112.00833 13.458617
Difference at 95.0% confidence
-13.2798 +/- 3.79219
-10.5994% +/- 3.02677%
(Student's t, pooled s = 14.9237)
However the mean latency is adversely affected:
Mean latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 1)
x Always using tasklets
+ Only using tasklets from CS irq, direct submission of requests
++
| xx+ ++ |
| xx+ ++ |
| xx + +++ ++ |
| xxx + ++ |
| xxx + ++ |
| xxx + +++|
| xxx + ++ |
| ++ ++ |
| ++ ++ |
| xx+++ |
| xxxx +++ |
|x x x ++ ++ +|
| |__A__| |
| |A___||
++
N Min MaxMedian AvgStddev
x 120 3.506 3.727 3.631 3.63214170.02773109
+ 120 3.834 4.149 4.039 4.0375167 0.041221676
Difference at 95.0% confidence
0.405375 +/- 0.00888913
11.1608% +/-
[Intel-gfx] [PATCH 7/9] drm/i915/execlists: Stop storing the CSB read pointer in the mmio register
As we now never read back our current head position from the CSB
pointers register, and the HW itself doesn't use it to prevent
overwriting unread CSB entries, we do not need to keep updating the
register. As it turns out this register is not listed as being shadowed,
and so requires forcewake -- but we haven't been taking forcewake around
it so the writes has probably been regularly dropped. Fortuitously, we
only read the value after a reset where it did not matter, and zero was
the right answer (well, close enough).
Mika pointed out that this was how we used to do it (accidentally!)
before he fixed it in commit cc53699b25b5 ("drm/i915: Use masked write
for Context Status Buffer Pointer").
References: cc53699b25b5 ("drm/i915: Use masked write for Context Status Buffer
Pointer")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Mika Kuoppala
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f597a12f705b..14be53035610 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1117,8 +1117,6 @@ static void process_csb(struct intel_engine_cs *engine)
}
} while (head != tail);
- writel(_MASKED_FIELD(GEN8_CSB_READ_PTR_MASK, head << 8),
- execlists->csb_read);
execlists->csb_head = head;
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Quoting Tvrtko Ursulin (2018-06-28 13:29:32) > > On 28/06/2018 13:11, Chris Wilson wrote: > > Quoting Chris Wilson (2018-06-28 13:07:51) > >> Quoting Tvrtko Ursulin (2018-06-28 12:56:56) > >>> And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't > >>> taking the timeline lock around active state reconstruction solve that > >>> simpler? > >> > >> Can you? We probably can. (That one was a very recent discovery and > >> quick fix.) > > > > The biggest issue being whether or not the same locking applies equally > > to all submission backends. That's not yet true, but then again we don't > > use stats everywhere. So whether or not that's an issue, I don't know, > > but it's enough to make me want to punt changing the locking inside > > intel_enable_engine_stats to a separate patch. > > Big benefit is removing the extra tasklet schedule from engine stats > which is in fact even racy. It's racy, but the tasklet being run more often than required is just wasted effort. Unless you think we can get ourselves into a loop here? > We need the state reconstruction to be > atomic so I think it really needs to be under the engine lock. > > tasklet_disable/enable can then also be dropped I think. > > To which patch in this series that belongs is the question. Last one I > think, when all is in place that port updates are protected by the > timeline lock. I definitely support it being a new patch. I don't think the race is a problem that requires preventative work. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts
== Series Details ==
Series: series starting with [1/9] drm/i915: Drop posting reads to flush master
interrupts
URL : https://patchwork.freedesktop.org/series/45574/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c25ca2aa7052 drm/i915: Drop posting reads to flush master interrupts
72c874d9629c drm/i915/execlists: Pull submit after dequeue under timeline lock
23551321d1f8 drm/i915/execlists: Pull CSB reset under the timeline.lock
339457d39e59 drm/i915/execlists: Process one CSB update at a time
-:68: WARNING:MEMORY_BARRIER: memory barrier without comment
#68: FILE: drivers/gpu/drm/i915/intel_lrc.c:966:
+ smp_mb__after_atomic();
-:114: WARNING:LONG_LINE: line over 100 characters
#114: FILE: drivers/gpu/drm/i915/intel_lrc.c:990:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:115: WARNING:LONG_LINE: line over 100 characters
#115: FILE: drivers/gpu/drm/i915/intel_lrc.c:991:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-:183: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#183: FILE: drivers/gpu/drm/i915/intel_lrc.c:1022:
+ status, buf[2*head + 1],
^
-:211: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#211: FILE: drivers/gpu/drm/i915/intel_lrc.c:1040:
+ buf[2*head + 1] == execlists->preempt_complete_status) {
^
total: 0 errors, 3 warnings, 2 checks, 316 lines checked
4f9269b804df drm/i915/execlists: Unify CSB access pointers
851d680bba4a drm/i915/execlists: Reset CSB write pointer after reset
258f82686b87 drm/i915/execlists: Stop storing the CSB read pointer in the mmio
register
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
References: cc53699b25b5 ("drm/i915: Use masked write for Context Status Buffer
Pointer")
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit cc53699b25b5 ("drm/i915: Use
masked write for Context Status Buffer Pointer")'
#20:
References: cc53699b25b5 ("drm/i915: Use masked write for Context Status Buffer
Pointer")
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
1b995c4ffd64 drm/i915/execlists: Trust the CSB
30fd3a0d176d drm/i915/execlists: Direct submission of new requests (avoid
tasklet/ksoftirqd)
-:104: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#104:
References: 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom
half")
-:104: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit 27af5eea54d1 ("drm/i915:
Move execlists irq handler to a bottom half")'
#104:
References: 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom
half")
total: 1 errors, 1 warnings, 0 checks, 219 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/2] drm/i915/gmbus: Enable burst read
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the need for burst_read [Jani]
Calculation enhancement.
v4:
GMBUS0 reg val is passed from caller [ville]
Removed a extra var [ville]
Extra brackets are removed [ville]
Implemented the handling of 512Bytes Burst Read.
v5:
Burst read max length is fixed at 767Bytes [Ville]
v6:
Collecting the received reviewed-by.
Signed-off-by: Ramalingam C
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 61 +---
3 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b684f431c60..7636afd78368 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2574,6 +2574,9 @@ intel_info(const struct drm_i915_private *dev_priv)
IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
+#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+ IS_GEMINILAKE(dev_priv) || \
+ IS_KABYLAKE(dev_priv))
/* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
* rows, which changed the alignment requirements and fence programming.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7353ad447936..7bfc11a676b1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3064,6 +3064,7 @@ enum i915_power_well_id {
#define GMBUS_RATE_400KHZ(2 << 8) /* reserved on Pineview */
#define GMBUS_RATE_1MHZ (3 << 8) /* reserved on Pineview */
#define GMBUS_HOLD_EXT (1 << 7) /* 300ns hold time, rsvd on Pineview */
+#define GMBUS_BYTE_CNT_OVERRIDE (1 << 6)
#define GMBUS_PIN_DISABLED 0
#define GMBUS_PIN_SSC1
#define GMBUS_PIN_VGADDC 2
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 82bb9c33ab1c..bef32b7c248e 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -371,12 +371,29 @@ unsigned int gmbus_max_xfer_size(struct drm_i915_private
*dev_priv)
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
- u32 gmbus1_index)
+ u32 gmbus0_reg, u32 gmbus1_index)
{
+ unsigned int size = len;
+ bool burst_read = len > gmbus_max_xfer_size(dev_priv);
+ bool extra_byte_added = false;
+
+ if (burst_read) {
+ /*
+* As per HW Spec, for 512Bytes need to read extra Byte and
+* Ignore the extra byte read.
+*/
+ if (len == 512) {
+ extra_byte_added = true;
+ len++;
+ }
+ size = len % 256 + 256;
+ I915_WRITE_FW(GMBUS0, gmbus0_reg | GMBUS_BYTE_CNT_OVERRIDE);
+ }
+
I915_WRITE_FW(GMBUS1,
gmbus1_index |
GMBUS_CYCLE_WAIT |
- (len << GMBUS_BYTE_COUNT_SHIFT) |
+ (size << GMBUS_BYTE_COUNT_SHIFT) |
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
while (len) {
@@ -389,17 +406,34 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
val = I915_READ_FW(GMBUS3);
do {
+ if (extra_byte_added && len == 1)
+ break;
+
*buf++ = val & 0xff;
val >>= 8;
} while (--len && ++loop < 4);
+
+ if (burst_read && len == size - 4)
+ /* Reset the override bit */
+ I915_WRITE_FW(GMBUS0, gmbus0_reg);
}
return 0;
}
+/*
+ * HW spec says that 512Bytes in Burst read need special treatment.
+ * But it doesn't talk about other multiple of 256Bytes. And couldn't locate
+ * an I2C slave, which supports such a lengthy burst read too for experiments.
+ *
+ * So until things get clarified on HW support, to avoid the burst read length
+ * in fold of 256Bytes except 512, max burst read length is fixed at 767Bytes.
+ */
+#define INTEL_GMBUS_BURST_READ_MAX_LEN 767U
+
static int
gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
- u32 gmbus1_index)
+ u32 gmbus0_reg, u32 gmbus1_index)
{
u8 *buf = msg->buf;
unsigned int rx_size = msg->len;
@@
[Intel-gfx] [PATCH v5 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
enabling the 511Bytes per RD/WR cycle on legacy platforms for no
absolute ROIs, this change allows the max bytes per op upto 511Bytes
from Gen9 onwards.
v2:
No Change.
v3:
Inline function for max_xfer_size and renaming of the macro.[Jani]
v4:
Extra brackets removed [ville]
Commit msg is modified.
v5:
Collecting the Reviewed-By received.
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Ramalingam C
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c30cfcd90754..7353ad447936 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3093,6 +3093,7 @@ enum i915_power_well_id {
#define GMBUS_CYCLE_STOP (4 << 25)
#define GMBUS_BYTE_COUNT_SHIFT 16
#define GMBUS_BYTE_COUNT_MAX 256U
+#define GEN9_GMBUS_BYTE_COUNT_MAX 511U
#define GMBUS_SLAVE_INDEX_SHIFT 8
#define GMBUS_SLAVE_ADDR_SHIFT 1
#define GMBUS_SLAVE_READ (1 << 0)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 97606c1be70d..82bb9c33ab1c 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
return ret;
}
+static inline
+unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv)
+{
+ return INTEL_GEN(dev_priv) >= 9 ? GEN9_GMBUS_BYTE_COUNT_MAX :
+ GMBUS_BYTE_COUNT_MAX;
+}
+
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
@@ -400,7 +407,7 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(rx_size, GMBUS_BYTE_COUNT_MAX);
+ len = min(rx_size, gmbus_max_xfer_size(dev_priv));
ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
buf, len, gmbus1_index);
@@ -462,7 +469,7 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
+ len = min(tx_size, gmbus_max_xfer_size(dev_priv));
ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
gmbus1_index);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
On 28/06/2018 13:35, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-06-28 13:29:32) On 28/06/2018 13:11, Chris Wilson wrote: Quoting Chris Wilson (2018-06-28 13:07:51) Quoting Tvrtko Ursulin (2018-06-28 12:56:56) And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't taking the timeline lock around active state reconstruction solve that simpler? Can you? We probably can. (That one was a very recent discovery and quick fix.) The biggest issue being whether or not the same locking applies equally to all submission backends. That's not yet true, but then again we don't use stats everywhere. So whether or not that's an issue, I don't know, but it's enough to make me want to punt changing the locking inside intel_enable_engine_stats to a separate patch. Big benefit is removing the extra tasklet schedule from engine stats which is in fact even racy. It's racy, but the tasklet being run more often than required is just wasted effort. Unless you think we can get ourselves into a loop here? We need the state reconstruction to be atomic so I think it really needs to be under the engine lock. tasklet_disable/enable can then also be dropped I think. To which patch in this series that belongs is the question. Last one I think, when all is in place that port updates are protected by the timeline lock. I definitely support it being a new patch. I don't think the race is a problem that requires preventative work. I think it has to be part of this series as the last, or before it, since otherwise the perf_pmu test could/would/should start failing. Because it is this series which breaks the assumption in intel_enable_engine_stats that ports can be sampled safely while the tasklet is disabled. I don't think the extra tasklet schedule fixes it - it cannot help correcting the state once the above races with direct submission. So that extra/new tasklet schedule also goes away. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] drm/i915/execlists: Trust the CSB
On 28/06/2018 13:33, Chris Wilson wrote:
Now that we use the CSB stored in the CPU friendly HWSP, we do not need
to track interrupts for when the mmio CSB registers are valid and can
just check where we read up to last from the cached HWSP. This means we
can forgo the atomic bit tracking from interrupt, and in the next patch
it means we can check the CSB at any time.
v2: Change the splitting inside reset_prepare, we only want to lose
testing the interrupt in this patch, the next patch requires the change
in locking
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 11 +++---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 ++-
drivers/gpu/drm/i915/intel_lrc.c| 29 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
4 files changed, 9 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 97418efec719..cb91b213aa67 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1478,15 +1478,10 @@ static void snb_gt_irq_handler(struct drm_i915_private
*dev_priv,
static void
gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
{
- struct intel_engine_execlists * const execlists = &engine->execlists;
bool tasklet = false;
- if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active)) {
- set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- tasklet = true;
- }
- }
+ if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
+ tasklet = true;
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
@@ -1494,7 +1489,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
}
if (tasklet)
- tasklet_hi_schedule(&execlists->tasklet);
+ tasklet_hi_schedule(&engine->execlists.tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7209c22798e6..ace93958689e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1353,12 +1353,10 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
read = GEN8_CSB_READ_PTR(ptr);
write = GEN8_CSB_WRITE_PTR(ptr);
- drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from
hws], interrupt posted? %s, tasklet queued? %s (%s)\n",
+ drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from
hws], tasklet queued? %s (%s)\n",
read, execlists->csb_head,
write,
intel_read_status_page(engine,
intel_hws_csb_write_index(engine->i915)),
- yesno(test_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted)),
yesno(test_bit(TASKLET_STATE_SCHED,
&engine->execlists.tasklet.state)),
enableddisabled(!atomic_read(&engine->execlists.tasklet.count)));
@@ -1570,11 +1568,9 @@ void intel_engine_dump(struct intel_engine_cs *engine,
spin_unlock(&b->rb_lock);
local_irq_restore(flags);
- drm_printf(m, "IRQ? 0x%lx (breadcrumbs? %s) (execlists? %s)\n",
+ drm_printf(m, "IRQ? 0x%lx (breadcrumbs? %s)\n",
engine->irq_posted,
yesno(test_bit(ENGINE_IRQ_BREADCRUMB,
- &engine->irq_posted)),
- yesno(test_bit(ENGINE_IRQ_EXECLIST,
&engine->irq_posted)));
drm_printf(m, "HWSP:\n");
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14be53035610..7f8b29684d9d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -874,14 +874,6 @@ static void reset_irq(struct intel_engine_cs *engine)
smp_store_mb(engine->execlists.active, 0);
clear_gtiir(engine);
-
- /*
-* The port is checked prior to scheduling a tasklet, but
-* just in case we have suspended the tasklet to do the
-* wedging make sure that when it wakes, it decides there
-* is no work to do by clearing the irq_posted bit.
-*/
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
static void reset_csb_pointers(struct intel_engine_execlists *execlists)
@@ -972,10 +964,6 @@ static void process_csb(struct intel_engine_cs *engine)
const u32 * const buf = execlists->csb_status;
u8 head, tail;
- /* Clear before reading to catch new interrupts */
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- smp_mb_
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts
== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts URL : https://patchwork.freedesktop.org/series/45574/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9466 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45574/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9466 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4397 -> Patchwork_9466 CI_DRM_4397: 7306233935b0e426454e8adcf09a8022faa03cbc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9466: 30fd3a0d176db02ee1262d490acc80892eaa93e6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 30fd3a0d176d drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) 1b995c4ffd64 drm/i915/execlists: Trust the CSB 258f82686b87 drm/i915/execlists: Stop storing the CSB read pointer in the mmio register 851d680bba4a drm/i915/execlists: Reset CSB write pointer after reset 4f9269b804df drm/i915/execlists: Unify CSB access pointers 339457d39e59 drm/i915/execlists: Process one CSB update at a time 23551321d1f8 drm/i915/execlists: Pull CSB reset under the timeline.lock 72c874d9629c drm/i915/execlists: Pull submit after dequeue under timeline lock c25ca2aa7052 drm/i915: Drop posting reads to flush master interrupts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9466/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Drop posting reads to flush master interrupts
On Thu, Jun 28, 2018 at 01:33:43PM +0100, Chris Wilson wrote:
> We do not need to do a posting read of our uncached mmio write to
> re-enable the master interrupt lines after handling an interrupt, so
> don't. This saves us a slow UC read before we can process the interrupt,
> most noticeable in execlists where any stalls imposes extra latency on
> GPU command execution.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_irq.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 7a7c4a2bd778..e83fcedcbf1d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2168,7 +2168,6 @@ static irqreturn_t valleyview_irq_handler(int irq, void
> *arg)
>
> I915_WRITE(VLV_IER, ier);
> I915_WRITE(VLV_MASTER_IER, MASTER_INTERRUPT_ENABLE);
> - POSTING_READ(VLV_MASTER_IER);
>
> if (gt_iir)
> snb_gt_irq_handler(dev_priv, gt_iir);
> @@ -2253,7 +2252,6 @@ static irqreturn_t cherryview_irq_handler(int irq, void
> *arg)
>
> I915_WRITE(VLV_IER, ier);
> I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
> - POSTING_READ(GEN8_MASTER_IRQ);
>
> gen8_gt_irq_handler(dev_priv, master_ctl, gt_iir);
>
> @@ -2622,7 +2620,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> *arg)
> /* disable master interrupt before clearing iir */
> de_ier = I915_READ(DEIER);
> I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> - POSTING_READ(DEIER);
>
> /* Disable south interrupts. We'll only write to SDEIIR once, so further
>* interrupts will will be stored on its back queue, and then we'll be
> @@ -2632,7 +2629,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> *arg)
> if (!HAS_PCH_NOP(dev_priv)) {
> sde_ier = I915_READ(SDEIER);
> I915_WRITE(SDEIER, 0);
> - POSTING_READ(SDEIER);
> }
>
> /* Find, clear, then process each source of interrupt */
> @@ -2667,11 +2663,8 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> *arg)
> }
>
> I915_WRITE(DEIER, de_ier);
> - POSTING_READ(DEIER);
> - if (!HAS_PCH_NOP(dev_priv)) {
> + if (!HAS_PCH_NOP(dev_priv))
> I915_WRITE(SDEIER, sde_ier);
> - POSTING_READ(SDEIER);
> - }
Not 100% sure about the SDEIER thing. I believe it goes over the link
to the PCH so I suppose it might be posted. No idea how it would get
ordered wrt. subsequent accesses to CPU side registers. Hmm. Oh we
actually restore master first, then SDEIER. But I suppose the order
doesn't actually matter. As long as SDEIER is 0 at some point we should
get a new edge in the end if SDEIIR still has something asserted.
Yeah, seems fine by me:
Reviewed-by: Ville Syrjälä
>
> /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> enable_rpm_wakeref_asserts(dev_priv);
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
== Series Details == Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op URL : https://patchwork.freedesktop.org/series/45576/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3065ccd37dd8 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op 968b33b77723 drm/i915/gmbus: Enable burst read -:42: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #42: FILE: drivers/gpu/drm/i915/i915_drv.h:2577: +#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \ + IS_GEMINILAKE(dev_priv) || \ + IS_KABYLAKE(dev_priv)) total: 0 errors, 0 warnings, 1 checks, 130 lines checked ___ 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 [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
== Series Details == Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op URL : https://patchwork.freedesktop.org/series/45576/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/gmbus: Increase the Bytes per Rd/Wr Op -O:drivers/gpu/drm/i915/intel_i2c.c:403:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:465:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) Commit: drm/i915/gmbus: Enable burst read -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:445:31: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:447:31: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:447:31: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3672:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3675:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Drop posting reads to flush master interrupts
Quoting Ville Syrjälä (2018-06-28 14:06:40)
> On Thu, Jun 28, 2018 at 01:33:43PM +0100, Chris Wilson wrote:
> > We do not need to do a posting read of our uncached mmio write to
> > re-enable the master interrupt lines after handling an interrupt, so
> > don't. This saves us a slow UC read before we can process the interrupt,
> > most noticeable in execlists where any stalls imposes extra latency on
> > GPU command execution.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 7a7c4a2bd778..e83fcedcbf1d 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2168,7 +2168,6 @@ static irqreturn_t valleyview_irq_handler(int irq,
> > void *arg)
> >
> > I915_WRITE(VLV_IER, ier);
> > I915_WRITE(VLV_MASTER_IER, MASTER_INTERRUPT_ENABLE);
> > - POSTING_READ(VLV_MASTER_IER);
> >
> > if (gt_iir)
> > snb_gt_irq_handler(dev_priv, gt_iir);
> > @@ -2253,7 +2252,6 @@ static irqreturn_t cherryview_irq_handler(int irq,
> > void *arg)
> >
> > I915_WRITE(VLV_IER, ier);
> > I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
> > - POSTING_READ(GEN8_MASTER_IRQ);
> >
> > gen8_gt_irq_handler(dev_priv, master_ctl, gt_iir);
> >
> > @@ -2622,7 +2620,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> > *arg)
> > /* disable master interrupt before clearing iir */
> > de_ier = I915_READ(DEIER);
> > I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> > - POSTING_READ(DEIER);
> >
> > /* Disable south interrupts. We'll only write to SDEIIR once, so
> > further
> >* interrupts will will be stored on its back queue, and then we'll be
> > @@ -2632,7 +2629,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> > *arg)
> > if (!HAS_PCH_NOP(dev_priv)) {
> > sde_ier = I915_READ(SDEIER);
> > I915_WRITE(SDEIER, 0);
> > - POSTING_READ(SDEIER);
> > }
> >
> > /* Find, clear, then process each source of interrupt */
> > @@ -2667,11 +2663,8 @@ static irqreturn_t ironlake_irq_handler(int irq,
> > void *arg)
> > }
> >
> > I915_WRITE(DEIER, de_ier);
> > - POSTING_READ(DEIER);
> > - if (!HAS_PCH_NOP(dev_priv)) {
> > + if (!HAS_PCH_NOP(dev_priv))
> > I915_WRITE(SDEIER, sde_ier);
> > - POSTING_READ(SDEIER);
> > - }
>
> Not 100% sure about the SDEIER thing. I believe it goes over the link
> to the PCH so I suppose it might be posted. No idea how it would get
> ordered wrt. subsequent accesses to CPU side registers. Hmm. Oh we
> actually restore master first, then SDEIER. But I suppose the order
> doesn't actually matter. As long as SDEIER is 0 at some point we should
> get a new edge in the end if SDEIIR still has something asserted.
I have vague memories of you saying "oh master is done before sdeier",
that's odd (or that might have been me)!
> Yeah, seems fine by me:
> Reviewed-by: Ville Syrjälä
Ta,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on average! Deferring our work to a tasklet allowed us to do the
processing with irqs enabled, reducing the impact to an average of about
50us.
We have since eradicated the use of forcewaked mmio from inside the CSB
processing and ELSP submission, bringing the impact down to around 5us
(on Kabylake); an order of magnitude better than our measurements 2
years ago on Broadwell and only about 2x worse on average than the
gem_syslatency on an unladen system.
In this iteration of the tasklet-vs-direct submission debate, we seek a
compromise where by we submit new requests immediately to the HW but
defer processing the CS interrupt onto a tasklet. We gain the advantage
of low-latency and ksoftirqd avoidance when waking up the HW, while
avoiding the system-wide starvation of our CS irq-storms.
Comparing the impact on the maximum latency observed (that is the time
stolen from an RT process) over a 120s interval, repeated several times
(using gem_syslatency, similar to RT's cyclictest) while the system is
fully laden with i915 nops, we see that direct submission an actually
improve the worse case.
Maximum latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 2)
x Always using tasklets (a couple of >1000us outliers removed)
+ Only using tasklets from CS irq, direct submission of requests
++
| + |
| + |
| + |
| + + |
| + + + |
| + + + + x x x |
| +++ + + + x x x x x x |
| +++ + ++ + + *x x x x x x |
| +++ + ++ + * *x x * x x x |
|+ +++ + ++ * * +*xxx * x x xx |
|* +++ + * *x+**xx+ * x x x |
| **x*++**+*x*xx+ * +x xx x x|
|x* **+***++*+***xx* xx*x xxx +x+|
| |__MA___| |
| |__M__A| |
++
N Min MaxMedian AvgStddev
x 11891 186 124 125.28814 16.279137
+ 12092 187 109 112.00833 13.458617
Difference at 95.0% confidence
-13.2798 +/- 3.79219
-10.5994% +/- 3.02677%
(Student's t, pooled s = 14.9237)
However the mean latency is adversely affected:
Mean latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 1)
x Always using tasklets
+ Only using tasklets from CS irq, direct submission of requests
++
| xx+ ++ |
| xx+ ++ |
| xx + +++ ++ |
| xxx + ++ |
| xxx + ++ |
| xxx + +++|
| xxx + ++ |
| ++ ++ |
| ++ ++ |
| xx+++ |
| xxxx +++ |
|x x x ++ ++ +|
| |__A__| |
| |A___||
++
N Min MaxMedian AvgStddev
x 120 3.506 3.727 3.631 3.63214170.02773109
+ 120 3.834 4.149 4.039 4.0375167 0.041221676
Difference at 95.0% confidence
0.405375 +/- 0.00888913
11.1608% +/-
[Intel-gfx] [i-g-t] tests/kms_plane_multiple: DDB corner testcase
This is to exercise DDB algorithm corner case where
DDB allocation was not happening properly for varying size plane.
Current DDB algorithm uses datarate based DDB division among
planes, but planes with same width require same DDB allocation
irrespective of their height.
To address this a Multiplane flip is added, with all planes other
than the topmost plane having full size, and the top most plane
size and position is varied.
Signed-off-by: Mahesh Kumar
Signed-off-by: Karthik B S
---
tests/kms_plane_multiple.c | 130 -
1 file changed, 116 insertions(+), 14 deletions(-)
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
index e61bc84..e9ebaeb 100644
--- a/tests/kms_plane_multiple.c
+++ b/tests/kms_plane_multiple.c
@@ -35,6 +35,8 @@ IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple
planes ");
#define SIZE_PLANE 256
#define SIZE_CURSOR 128
#define LOOP_FOREVER -1
+#define TEST_DDB_ALGO1
+#define SIZE_PANE 10
typedef struct {
float red;
@@ -48,6 +50,7 @@ typedef struct {
igt_crc_t ref_crc;
igt_pipe_crc_t *pipe_crc;
igt_plane_t **plane;
+ unsigned int flag;
struct igt_fb *fb;
} data_t;
@@ -62,6 +65,14 @@ struct {
.seed = 1,
};
+enum position {
+ POS_TOP,
+ POS_LEFT,
+ POS_BOTTOM,
+ POS_RIGHT,
+ POS_MAX,
+};
+
/*
* Common code across all tests, acting on data_t
*/
@@ -242,6 +253,80 @@ prepare_planes(data_t *data, enum pipe pipe_id, color_t
*color,
}
static void
+prepare_planes2(data_t *data, enum pipe pipe_id, color_t *color,
+ uint64_t tiling, int max_planes, igt_output_t *output,
+ enum position position)
+{
+ drmModeModeInfo *mode;
+ int x;
+ int y;
+ int i;
+ int hsize, vsize;
+
+ mode = igt_output_get_mode(output);
+
+ for (i = 0; i < max_planes; i++) {
+ igt_plane_t *plane = igt_output_get_plane(output, i);
+ uint32_t format = DRM_FORMAT_XRGB;
+
+ if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ format = DRM_FORMAT_ARGB;
+ tiling = LOCAL_DRM_FORMAT_MOD_NONE;
+ x = 0;
+ y = 0;
+ hsize = SIZE_CURSOR;
+ vsize = SIZE_CURSOR;
+ } else if ((plane->index == max_planes - 2) &&
+ (plane->type != DRM_PLANE_TYPE_PRIMARY)) {
+ /* Top most plane and not the primary plane */
+ switch (position) {
+ case POS_TOP:
+ x = 0;
+ y = 0;
+ hsize = mode->hdisplay;
+ vsize = SIZE_PANE;
+ break;
+ case POS_RIGHT:
+ x = mode->hdisplay - SIZE_PANE;
+ y = 0;
+ hsize = SIZE_PANE;
+ vsize = mode->vdisplay;
+ break;
+ case POS_BOTTOM:
+ x = 0;
+ y = mode->vdisplay - SIZE_PANE;
+ hsize = mode->hdisplay;
+ vsize = SIZE_PANE;
+ break;
+ case POS_LEFT:
+ x = 0;
+ y = 0;
+ hsize = SIZE_PANE;
+ vsize = mode->vdisplay;
+ break;
+ default:
+ igt_info("Invalid Position\n");
+ }
+
+ } else {
+ x = 0;
+ y = 0;
+ hsize = mode->hdisplay;
+ vsize = mode->vdisplay;
+ }
+
+ data->plane[i] = plane;
+ igt_create_color_fb(data->drm_fd,
+ hsize, vsize,
+ format, tiling,
+ color->red, color->green, color->blue,
+ &data->fb[i]);
+ igt_plane_set_position(data->plane[i], x, y);
+ igt_plane_set_fb(data->plane[i], &data->fb[i]);
+ }
+}
+
+static void
test_plane_position_with_output(data_t *data, enum pipe pipe,
igt_output_t *output, int n_planes,
uint64_t tiling)
@@ -267,21 +352,29 @@ test_plane_position_with_output(data_t *data, enum pipe
pipe,
info, opt.seed);
test_init(data, pipe, n_planes);
-
test_grab_crc(data, output, pipe, &blue, tiling);
- i = 0;
- while (i < iter
[Intel-gfx] [PATCH v2 2/9] drm/i915: Nuke intel_mst_best_encoder()
From: Ville Syrjälä
With the fb-helper no longer relying on the non-atomic .best_encoder()
we can eliminate the hook from the MST encoder.
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
Reviewed-by: Daniel Vetter
Reviewed-by: Alex Deucher
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp_mst.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 5890500a3a8b..0f012fbe34eb 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -403,20 +403,10 @@ static struct drm_encoder
*intel_mst_atomic_best_encoder(struct drm_connector *c
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
-static struct drm_encoder *intel_mst_best_encoder(struct drm_connector
*connector)
-{
- struct intel_connector *intel_connector = to_intel_connector(connector);
- struct intel_dp *intel_dp = intel_connector->mst_port;
- if (!intel_dp)
- return NULL;
- return &intel_dp->mst_encoders[0]->base.base;
-}
-
static const struct drm_connector_helper_funcs
intel_dp_mst_connector_helper_funcs = {
.get_modes = intel_dp_mst_get_modes,
.mode_valid = intel_dp_mst_mode_valid,
.atomic_best_encoder = intel_mst_atomic_best_encoder,
- .best_encoder = intel_mst_best_encoder,
.atomic_check = intel_dp_mst_atomic_check,
};
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/9] drm/fb-helper: Eliminate the .best_encoder() usage
From: Ville Syrjälä
Instead of using the .best_encoder() hook to figure out whether a given
connector+crtc combo will work, let's instead do what userspace does and
just iterate over all the encoders for the connector, and then check
each crtc against each encoder's possible_crtcs bitmask.
v2: Avoid oopsing on NULL encoders (Daniel)
s/connector_crtc_ok/connector_has_possible_crtc/
Cc: Dhinakaran Pandiyan
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
Reviewed-by: Alex Deucher #v1
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_helper.c | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cab14f253384..b37f06317d51 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2323,6 +2323,27 @@ static bool drm_target_preferred(struct drm_fb_helper
*fb_helper,
return true;
}
+static bool connector_has_possible_crtc(struct drm_connector *connector,
+ struct drm_crtc *crtc)
+{
+ int i;
+
+ for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+ struct drm_encoder *encoder;
+
+ if (connector->encoder_ids[i] == 0)
+ break;
+
+ encoder = drm_encoder_find(connector->dev, NULL,
+ connector->encoder_ids[i]);
+
+ if (encoder->possible_crtcs & drm_crtc_mask(crtc))
+ return true;
+ }
+
+ return false;
+}
+
static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_crtc **best_crtcs,
struct drm_display_mode **modes,
@@ -2331,7 +2352,6 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
int c, o;
struct drm_connector *connector;
const struct drm_connector_helper_funcs *connector_funcs;
- struct drm_encoder *encoder;
int my_score, best_score, score;
struct drm_fb_helper_crtc **crtcs, *crtc;
struct drm_fb_helper_connector *fb_helper_conn;
@@ -2362,20 +2382,6 @@ static int drm_pick_crtcs(struct drm_fb_helper
*fb_helper,
connector_funcs = connector->helper_private;
- /*
-* If the DRM device implements atomic hooks and ->best_encoder() is
-* NULL we fallback to the default drm_atomic_helper_best_encoder()
-* helper.
-*/
- if (drm_drv_uses_atomic_modeset(fb_helper->dev) &&
- !connector_funcs->best_encoder)
- encoder = drm_atomic_helper_best_encoder(connector);
- else
- encoder = connector_funcs->best_encoder(connector);
-
- if (!encoder)
- goto out;
-
/*
* select a crtc for this connector and then attempt to configure
* remaining connectors
@@ -2383,7 +2389,8 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
for (c = 0; c < fb_helper->crtc_count; c++) {
crtc = &fb_helper->crtc_info[c];
- if ((encoder->possible_crtcs & (1 << c)) == 0)
+ if (!connector_has_possible_crtc(connector,
+crtc->mode_set.crtc))
continue;
for (o = 0; o < n; o++)
@@ -2410,7 +2417,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
sizeof(struct drm_fb_helper_crtc *));
}
}
-out:
+
kfree(crtcs);
return best_score;
}
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/9] drm/amdgpu: Use drm_connector_for_each_possible_encoder()
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Harry Wentland
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher #v1
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 81 +++---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 15 ++---
2 files changed, 25 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 8e66851eb427..881f7cb7ae6e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -212,30 +212,21 @@ static void
amdgpu_connector_update_scratch_regs(struct drm_connector *connector,
enum drm_connector_status status)
{
- struct drm_encoder *best_encoder = NULL;
- struct drm_encoder *encoder = NULL;
+ struct drm_encoder *best_encoder;
+ struct drm_encoder *encoder;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
int i;
best_encoder = connector_funcs->best_encoder(connector);
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] == 0)
- break;
-
- encoder = drm_encoder_find(connector->dev, NULL,
- connector->encoder_ids[i]);
- if (!encoder)
- continue;
-
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
if ((encoder == best_encoder) && (status ==
connector_status_connected))
connected = true;
else
connected = false;
amdgpu_atombios_encoder_set_bios_scratch_regs(connector,
encoder, connected);
-
}
}
@@ -246,17 +237,11 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
struct drm_encoder *encoder;
int i;
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] == 0)
- break;
- encoder = drm_encoder_find(connector->dev, NULL,
- connector->encoder_ids[i]);
- if (!encoder)
- continue;
-
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
if (encoder->encoder_type == encoder_type)
return encoder;
}
+
return NULL;
}
@@ -360,11 +345,13 @@ static int amdgpu_connector_ddc_get_modes(struct
drm_connector *connector)
static struct drm_encoder *
amdgpu_connector_best_single_encoder(struct drm_connector *connector)
{
- int enc_id = connector->encoder_ids[0];
+ struct drm_encoder *encoder;
+ int i;
+
+ /* pick the first one */
+ drm_connector_for_each_possible_encoder(connector, encoder, i)
+ return encoder;
- /* pick the encoder ids */
- if (enc_id)
- return drm_encoder_find(connector->dev, NULL, enc_id);
return NULL;
}
@@ -985,9 +972,8 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
struct drm_device *dev = connector->dev;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
- struct drm_encoder *encoder = NULL;
const struct drm_encoder_helper_funcs *encoder_funcs;
- int i, r;
+ int r;
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false, broken_edid = false;
@@ -1077,14 +1063,10 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
/* find analog encoder */
if (amdgpu_connector->dac_load_detect) {
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] == 0)
- break;
-
- encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
- if (!encoder)
- continue;
+ struct drm_encoder *encoder;
+ int i;
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DAC &&
encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
continue;
@@ -1132,18 +1114,11 @@ amdgpu_connector_dvi_detect(struct drm_co
[Intel-gfx] [PATCH v2 0/9] drm: Third attempt at fixing the fb-helper .best_encoder() mess
From: Ville Syrjälä Changes from the previous version mainly involve Danoie's suggestion of hiding the drm_encoder_find() in the iterator macro. I also polished the msm and tilcdc cases a bit more with another small helper. Cc: Alex Deucher Cc: amd-...@lists.freedesktop.org Cc: Ben Skeggs Cc: "Christian König" Cc: Daniel Vetter Cc: "David (ChunMing) Zhou" Cc: Dhinakaran Pandiyan Cc: freedr...@lists.freedesktop.org Cc: Harry Wentland Cc: Jyri Sarha Cc: linux-arm-...@vger.kernel.org Cc: nouv...@lists.freedesktop.org Cc: Rob Clark Cc: Tomi Valkeinen Ville Syrjälä (9): drm/fb-helper: Eliminate the .best_encoder() usage drm/i915: Nuke intel_mst_best_encoder() drm: Add drm_connector_for_each_possible_encoder() drm/amdgpu: Use drm_connector_for_each_possible_encoder() drm/nouveau: Use drm_connector_for_each_possible_encoder() drm/radeon: Use drm_connector_for_each_possible_encoder() drm: Add drm_connector_has_possible_encoder() drm/msm: Use drm_connector_has_possible_encoder() drm/tilcdc: Use drm_connector_has_possible_encoder() drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 81 ++- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 15 ++--- drivers/gpu/drm/drm_connector.c| 44 + drivers/gpu/drm/drm_fb_helper.c| 34 +- drivers/gpu/drm/drm_probe_helper.c | 10 +-- drivers/gpu/drm/i915/intel_dp_mst.c| 10 --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 8 +-- drivers/gpu/drm/nouveau/nouveau_connector.c| 21 +- drivers/gpu/drm/radeon/radeon_connectors.c | 90 -- drivers/gpu/drm/tilcdc/tilcdc_external.c | 9 ++- include/drm/drm_connector.h| 16 + 11 files changed, 128 insertions(+), 210 deletions(-) -- 2.16.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher #v1
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7b557c354307..28d7b42cd666 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -363,19 +363,11 @@ module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
struct nouveau_encoder *
find_encoder(struct drm_connector *connector, int type)
{
- struct drm_device *dev = connector->dev;
struct nouveau_encoder *nv_encoder;
struct drm_encoder *enc;
- int i, id;
-
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- id = connector->encoder_ids[i];
- if (!id)
- break;
+ int i;
- enc = drm_encoder_find(dev, NULL, id);
- if (!enc)
- continue;
+ drm_connector_for_each_possible_encoder(connector, enc, i) {
nv_encoder = nouveau_encoder(enc);
if (type == DCB_OUTPUT_ANY ||
@@ -436,14 +428,7 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
}
}
- for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- int id = connector->encoder_ids[i];
- if (id == 0)
- break;
-
- encoder = drm_encoder_find(dev, NULL, id);
- if (!encoder)
- continue;
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
nv_encoder = nouveau_encoder(encoder);
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/9] drm/radeon: Use drm_connector_for_each_possible_encoder()
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Harry Wentland
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher #v1
---
drivers/gpu/drm/radeon/radeon_connectors.c | 90 +-
1 file changed, 26 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 2aea2bdff99b..0655698f2956 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -244,23 +244,15 @@ radeon_connector_update_scratch_regs(struct drm_connector
*connector, enum drm_c
{
struct drm_device *dev = connector->dev;
struct radeon_device *rdev = dev->dev_private;
- struct drm_encoder *best_encoder = NULL;
- struct drm_encoder *encoder = NULL;
+ struct drm_encoder *best_encoder;
+ struct drm_encoder *encoder;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
int i;
best_encoder = connector_funcs->best_encoder(connector);
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] == 0)
- break;
-
- encoder = drm_encoder_find(connector->dev, NULL,
- connector->encoder_ids[i]);
- if (!encoder)
- continue;
-
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
if ((encoder == best_encoder) && (status ==
connector_status_connected))
connected = true;
else
@@ -270,7 +262,6 @@ radeon_connector_update_scratch_regs(struct drm_connector
*connector, enum drm_c
radeon_atombios_connected_scratch_regs(connector,
encoder, connected);
else
radeon_combios_connected_scratch_regs(connector,
encoder, connected);
-
}
}
@@ -279,17 +270,11 @@ static struct drm_encoder *radeon_find_encoder(struct
drm_connector *connector,
struct drm_encoder *encoder;
int i;
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] == 0)
- break;
-
- encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
- if (!encoder)
- continue;
-
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
if (encoder->encoder_type == encoder_type)
return encoder;
}
+
return NULL;
}
@@ -393,10 +378,13 @@ static int radeon_ddc_get_modes(struct drm_connector
*connector)
static struct drm_encoder *radeon_best_single_encoder(struct drm_connector
*connector)
{
- int enc_id = connector->encoder_ids[0];
- /* pick the encoder ids */
- if (enc_id)
- return drm_encoder_find(connector->dev, NULL, enc_id);
+ struct drm_encoder *encoder;
+ int i;
+
+ /* pick the first one */
+ drm_connector_for_each_possible_encoder(connector, encoder, i)
+ return encoder;
+
return NULL;
}
@@ -436,19 +424,19 @@ radeon_connector_analog_encoder_conflict_solve(struct
drm_connector *connector,
struct drm_device *dev = connector->dev;
struct drm_connector *conflict;
struct radeon_connector *radeon_conflict;
- int i;
list_for_each_entry(conflict, &dev->mode_config.connector_list, head) {
+ struct drm_encoder *enc;
+ int i;
+
if (conflict == connector)
continue;
radeon_conflict = to_radeon_connector(conflict);
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (conflict->encoder_ids[i] == 0)
- break;
+ drm_connector_for_each_possible_encoder(conflict, enc, i) {
/* if the IDs match */
- if (conflict->encoder_ids[i] == encoder->base.id) {
+ if (enc == encoder) {
if (conflict->status !=
connector_status_connected)
continue;
@@ -1256,7 +1244,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
struct drm_encoder *encoder = NULL;
const struct drm_encoder_helper_funcs *encoder_funcs;
- int i, r;
+
[Intel-gfx] [PATCH v2 7/9] drm: Add drm_connector_has_possible_encoder()
From: Ville Syrjälä
Add a small helper for checking whether a connector and
encoder are associated with each other.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 23 +++
include/drm/drm_connector.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 186febcf4e55..84ff2fcdcb55 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -331,6 +331,29 @@ int drm_mode_connector_attach_encoder(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_mode_connector_attach_encoder);
+/**
+ * drm_connector_has_possible_encoder - check if the connector and encoder are
assosicated with each other
+ * @connector: the connector
+ * @encoder: the encoder
+ *
+ * Returns:
+ * True if @encoder is one of the possible encoders for @connector.
+ */
+bool drm_connector_has_possible_encoder(struct drm_connector *connector,
+ struct drm_encoder *encoder)
+{
+ struct drm_encoder *enc;
+ int i;
+
+ drm_connector_for_each_possible_encoder(connector, enc, i) {
+ if (enc == encoder)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(drm_connector_has_possible_encoder);
+
static void drm_mode_remove(struct drm_connector *connector,
struct drm_display_mode *mode)
{
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8de3a3aa516a..9c59485fec36 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1181,6 +1181,9 @@ struct drm_connector *
drm_connector_list_iter_next(struct drm_connector_list_iter *iter);
void drm_connector_list_iter_end(struct drm_connector_list_iter *iter);
+bool drm_connector_has_possible_encoder(struct drm_connector *connector,
+ struct drm_encoder *encoder);
+
/**
* drm_for_each_connector_iter - connector_list iterator macro
* @connector: &struct drm_connector pointer used as cursor
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/9] drm: Add drm_connector_for_each_possible_encoder()
From: Ville Syrjälä
Add a convenience macro for iterating connector->encoder_ids[].
Isolates the users from the implementation details.
Note that we don't seem to pass the file_priv down to drm_encoder_find()
because encoders apparently don't get leased. No idea why
drm_encoder_finc() even takes the file_priv actually.
Also use ARRAY_SIZE() when populating the array to avoid spreading
knowledge about the array size all over.
v2: Hide the drm_encoder_find() in the macro, and
rename the macro appropriately (Daniel)
Cc: Daniel Vetter
Reviewed-by: Alex Deucher #v1
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c| 21 +
drivers/gpu/drm/drm_fb_helper.c| 11 ++-
drivers/gpu/drm/drm_probe_helper.c | 10 +++---
include/drm/drm_connector.h| 13 +
4 files changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2f9ebddd178e..186febcf4e55 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -321,7 +321,7 @@ int drm_mode_connector_attach_encoder(struct drm_connector
*connector,
if (WARN_ON(connector->encoder))
return -EINVAL;
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+ for (i = 0; i < ARRAY_SIZE(connector->encoder_ids); i++) {
if (connector->encoder_ids[i] == 0) {
connector->encoder_ids[i] = encoder->base.id;
return 0;
@@ -1708,22 +1708,19 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
if (!connector)
return -ENOENT;
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
- if (connector->encoder_ids[i] != 0)
- encoders_count++;
+ drm_connector_for_each_possible_encoder(connector, encoder, i)
+ encoders_count++;
if ((out_resp->count_encoders >= encoders_count) && encoders_count) {
copied = 0;
encoder_ptr = (uint32_t __user *)(unsigned
long)(out_resp->encoders_ptr);
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] != 0) {
- if (put_user(connector->encoder_ids[i],
-encoder_ptr + copied)) {
- ret = -EFAULT;
- goto out;
- }
- copied++;
+
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ if (put_user(encoder->base.id, encoder_ptr + copied)) {
+ ret = -EFAULT;
+ goto out;
}
+ copied++;
}
}
out_resp->count_encoders = encoders_count;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b37f06317d51..d697c1c4a067 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2326,17 +2326,10 @@ static bool drm_target_preferred(struct drm_fb_helper
*fb_helper,
static bool connector_has_possible_crtc(struct drm_connector *connector,
struct drm_crtc *crtc)
{
+ struct drm_encoder *encoder;
int i;
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- struct drm_encoder *encoder;
-
- if (connector->encoder_ids[i] == 0)
- break;
-
- encoder = drm_encoder_find(connector->dev, NULL,
- connector->encoder_ids[i]);
-
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
if (encoder->possible_crtcs & drm_crtc_mask(crtc))
return true;
}
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 527743394150..1a901fe9e23e 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -88,9 +88,9 @@ drm_mode_validate_pipeline(struct drm_display_mode *mode,
struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
- uint32_t *ids = connector->encoder_ids;
enum drm_mode_status ret = MODE_OK;
- unsigned int i;
+ struct drm_encoder *encoder;
+ int i;
/* Step 1: Validate against connector */
ret = drm_connector_mode_valid(connector, mode);
@@ -98,13 +98,9 @@ drm_mode_validate_pipeline(struct drm_display_mode *mode,
return ret;
/* Step 2: Validate against encoders and crtcs */
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- struct drm_encoder *encoder = drm_encoder_find(dev, NULL,
ids[i]);
+ drm_connector_for_each_possible_encoder(c
[Intel-gfx] [PATCH v2 8/9] drm/msm: Use drm_connector_has_possible_encoder()
From: Ville Syrjälä
Use drm_connector_has_possible_encoder() for checking
whether the encoder has an associated connector.
v2: Replace the drm_for_each_connector_encoder_ids() loop
with a simple drm_connector_has_possible_encoder() call
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 4cb1cb68878b..4beba3f7d067 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -751,12 +751,8 @@ struct drm_connector *msm_dsi_manager_ext_bridge_init(u8
id)
connector_list = &dev->mode_config.connector_list;
list_for_each_entry(connector, connector_list, head) {
- int i;
-
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] == encoder->base.id)
- return connector;
- }
+ if (drm_connector_has_possible_encoder(connector, encoder))
+ return connector;
}
return ERR_PTR(-ENODEV);
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 9/9] drm/tilcdc: Use drm_connector_has_possible_encoder()
From: Ville Syrjälä
Use drm_connector_has_possible_encoder() for checking
whether the encoder has an associated connector.
v2: Replace the drm_for_each_connector_encoder_ids() loop
with a simple drm_connector_has_possible_encoder() call
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index d651bdd6597e..b4eaf9bc87f8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -103,12 +103,11 @@ struct drm_connector
*tilcdc_encoder_find_connector(struct drm_device *ddev,
struct drm_encoder *encoder)
{
struct drm_connector *connector;
- int i;
- list_for_each_entry(connector, &ddev->mode_config.connector_list, head)
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
- if (connector->encoder_ids[i] == encoder->base.id)
- return connector;
+ list_for_each_entry(connector, &ddev->mode_config.connector_list, head)
{
+ if (drm_connector_has_possible_encoder(connector, encoder))
+ return connector;
+ }
dev_err(ddev->dev, "No connector found for %s encoder (id %d)\n",
encoder->name, encoder->base.id);
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
On 28/06/2018 14:11, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on average! Deferring our work to a tasklet allowed us to do the
processing with irqs enabled, reducing the impact to an average of about
50us.
We have since eradicated the use of forcewaked mmio from inside the CSB
processing and ELSP submission, bringing the impact down to around 5us
(on Kabylake); an order of magnitude better than our measurements 2
years ago on Broadwell and only about 2x worse on average than the
gem_syslatency on an unladen system.
In this iteration of the tasklet-vs-direct submission debate, we seek a
compromise where by we submit new requests immediately to the HW but
defer processing the CS interrupt onto a tasklet. We gain the advantage
of low-latency and ksoftirqd avoidance when waking up the HW, while
avoiding the system-wide starvation of our CS irq-storms.
Comparing the impact on the maximum latency observed (that is the time
stolen from an RT process) over a 120s interval, repeated several times
(using gem_syslatency, similar to RT's cyclictest) while the system is
fully laden with i915 nops, we see that direct submission an actually
improve the worse case.
Maximum latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 2)
x Always using tasklets (a couple of >1000us outliers removed)
+ Only using tasklets from CS irq, direct submission of requests
++
| + |
| + |
| + |
| + + |
| + + + |
| + + + + x x x |
| +++ + + + x x x x x x |
| +++ + ++ + + *x x x x x x |
| +++ + ++ + * *x x * x x x |
|+ +++ + ++ * * +*xxx * x x xx |
|* +++ + * *x+**xx+ * x x x |
| **x*++**+*x*xx+ * +x xx x x|
|x* **+***++*+***xx* xx*x xxx +x+|
| |__MA___| |
| |__M__A| |
++
N Min MaxMedian AvgStddev
x 11891 186 124 125.28814 16.279137
+ 12092 187 109 112.00833 13.458617
Difference at 95.0% confidence
-13.2798 +/- 3.79219
-10.5994% +/- 3.02677%
(Student's t, pooled s = 14.9237)
However the mean latency is adversely affected:
Mean latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 1)
x Always using tasklets
+ Only using tasklets from CS irq, direct submission of requests
++
| xx+ ++ |
| xx+ ++ |
| xx + +++ ++ |
| xxx + ++ |
| xxx + ++ |
| xxx + +++|
| xxx + ++ |
| ++ ++ |
| ++ ++ |
| xx+++ |
| xxxx +++ |
|x x x ++ ++ +|
| |__A__| |
| |A___||
++
N Min MaxMedian AvgStddev
x 120 3.506 3.727 3.631 3.63214170.02773109
+ 120 3.834 4.149 4.039 4.0375167 0.041221676
Difference at 95.0% confidence
[Intel-gfx] [PATCH v4] drm/i915: Show vma allocator stack when in doubt
At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.
v2: We cannot allocate inside the printer (as it may be on an fs-reclaim
path), so hope for the best and build the string on the stack
v3: stack depth of 16 routinely overflows a 512 character string, limit
it to 12 to avoid unsightly truncation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 39 +++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e82aa804cdba..d0e606e9b27a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -21,7 +21,7 @@
* IN THE SOFTWARE.
*
*/
-
+
#include "i915_vma.h"
#include "i915_drv.h"
@@ -30,6 +30,39 @@
#include
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) && IS_ENABLED(CONFIG_DRM_DEBUG_MM)
+
+#include
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+ unsigned long entries[12];
+ struct stack_trace trace = {
+ .entries = entries,
+ .max_entries = ARRAY_SIZE(entries),
+ };
+ char buf[512];
+
+ if (!vma->node.stack) {
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: unknown
owner\n",
+vma->node.start, vma->node.size, reason);
+ return;
+ }
+
+ depot_fetch_stack(vma->node.stack, &trace);
+ snprint_stack_trace(buf, sizeof(buf), &trace, 0);
+ DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: inserted at %s\n",
+vma->node.start, vma->node.size, reason, buf);
+}
+
+#else
+
+static void vma_print_allocator(struct i915_vma *vma, const char *reason)
+{
+}
+
+#endif
+
static void
i915_vma_retire(struct i915_gem_active *active, struct i915_request *rq)
{
@@ -875,8 +908,10 @@ int i915_vma_unbind(struct i915_vma *vma)
}
GEM_BUG_ON(i915_vma_is_active(vma));
- if (i915_vma_is_pinned(vma))
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
return -EBUSY;
+ }
if (!drm_mm_node_allocated(&vma->node))
return 0;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t] tests/kms_plane_multiple: DDB corner testcase
Op 28-06-18 om 15:03 schreef Karthik B S:
> This is to exercise DDB algorithm corner case where
> DDB allocation was not happening properly for varying size plane.
>
> Current DDB algorithm uses datarate based DDB division among
> planes, but planes with same width require same DDB allocation
> irrespective of their height.
>
> To address this a Multiplane flip is added, with all planes other
> than the topmost plane having full size, and the top most plane
> size and position is varied.
>
> Signed-off-by: Mahesh Kumar
> Signed-off-by: Karthik B S
> ---
> tests/kms_plane_multiple.c | 130
> -
> 1 file changed, 116 insertions(+), 14 deletions(-)
>
> diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
> index e61bc84..e9ebaeb 100644
> --- a/tests/kms_plane_multiple.c
> +++ b/tests/kms_plane_multiple.c
> @@ -35,6 +35,8 @@ IGT_TEST_DESCRIPTION("Test atomic mode setting with
> multiple planes ");
> #define SIZE_PLANE 256
> #define SIZE_CURSOR 128
> #define LOOP_FOREVER -1
> +#define TEST_DDB_ALGO 1
> +#define SIZE_PANE 10
>
> typedef struct {
> float red;
> @@ -48,6 +50,7 @@ typedef struct {
> igt_crc_t ref_crc;
> igt_pipe_crc_t *pipe_crc;
> igt_plane_t **plane;
> + unsigned int flag;
> struct igt_fb *fb;
> } data_t;
>
> @@ -62,6 +65,14 @@ struct {
> .seed = 1,
> };
>
> +enum position {
> + POS_TOP,
> + POS_LEFT,
> + POS_BOTTOM,
> + POS_RIGHT,
> + POS_MAX,
> +};
> +
> /*
> * Common code across all tests, acting on data_t
> */
> @@ -242,6 +253,80 @@ prepare_planes(data_t *data, enum pipe pipe_id, color_t
> *color,
> }
>
> static void
> +prepare_planes2(data_t *data, enum pipe pipe_id, color_t *color,
> +uint64_t tiling, int max_planes, igt_output_t *output,
> +enum position position)
> +{
> + drmModeModeInfo *mode;
> + int x;
> + int y;
> + int i;
> + int hsize, vsize;
> +
> + mode = igt_output_get_mode(output);
> +
> + for (i = 0; i < max_planes; i++) {
> + igt_plane_t *plane = igt_output_get_plane(output, i);
> + uint32_t format = DRM_FORMAT_XRGB;
> +
> + if (plane->type == DRM_PLANE_TYPE_CURSOR) {
> + format = DRM_FORMAT_ARGB;
> + tiling = LOCAL_DRM_FORMAT_MOD_NONE;
> + x = 0;
> + y = 0;
> + hsize = SIZE_CURSOR;
> + vsize = SIZE_CURSOR;
> + } else if ((plane->index == max_planes - 2) &&
> +(plane->type != DRM_PLANE_TYPE_PRIMARY)) {
> + /* Top most plane and not the primary plane */
> + switch (position) {
> + case POS_TOP:
> + x = 0;
> + y = 0;
> + hsize = mode->hdisplay;
> + vsize = SIZE_PANE;
> + break;
> + case POS_RIGHT:
> + x = mode->hdisplay - SIZE_PANE;
> + y = 0;
> + hsize = SIZE_PANE;
> + vsize = mode->vdisplay;
> + break;
> + case POS_BOTTOM:
> + x = 0;
> + y = mode->vdisplay - SIZE_PANE;
> + hsize = mode->hdisplay;
> + vsize = SIZE_PANE;
> + break;
> + case POS_LEFT:
> + x = 0;
> + y = 0;
> + hsize = SIZE_PANE;
> + vsize = mode->vdisplay;
> + break;
> + default:
> + igt_info("Invalid Position\n");
> + }
> +
> + } else {
> + x = 0;
> + y = 0;
> + hsize = mode->hdisplay;
> + vsize = mode->vdisplay;
> + }
> +
> + data->plane[i] = plane;
> + igt_create_color_fb(data->drm_fd,
> + hsize, vsize,
> + format, tiling,
> + color->red, color->green, color->blue,
> + &data->fb[i]);
> + igt_plane_set_position(data->plane[i], x, y);
> + igt_plane_set_fb(data->plane[i], &data->fb[i]);
> + }
> +}
> +
> +static void
> test_plane_position_with_output(data_t *data, enum pipe pipe,
> igt_output_t *output, int n_planes,
> uint64_t tiling)
> @@ -267,21 +352,29 @@ test_plane_position_with_output(data_t *data, enum pipe
> pipe,
>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
== Series Details == Series: series starting with [v5,1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op URL : https://patchwork.freedesktop.org/series/45576/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4397 -> Patchwork_9467 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45576/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9467 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c-frame-sequence: fi-whl-u: PASS -> FAIL (fdo#103481) fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4397 -> Patchwork_9467 CI_DRM_4397: 7306233935b0e426454e8adcf09a8022faa03cbc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4530: 0e98bf69f146eb72fe3a7c3b19a049b5786f0ca3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9467: 968b33b77723ba1e10028b97c56c13477cfa732b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 968b33b77723 drm/i915/gmbus: Enable burst read 3065ccd37dd8 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9467/issues.html ___ 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/9] drm/i915: Drop posting reads to flush master interrupts (rev2)
== Series Details == Series: series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev2) URL : https://patchwork.freedesktop.org/series/45574/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_engine_cs.o drivers/gpu/drm/i915/intel_engine_cs.c: In function ‘intel_enable_engine_stats’: drivers/gpu/drm/i915/intel_engine_cs.c:1623:2: error: too many arguments to function ‘write_seqlock’ write_seqlock(&engine->stats.lock, flags); ^ In file included from ./include/linux/dcache.h:10:0, from ./include/linux/fs.h:8, from ./include/linux/seq_file.h:11, from ./include/drm/drm_print.h:31, from drivers/gpu/drm/i915/intel_engine_cs.c:25: ./include/linux/seqlock.h:446:20: note: declared here static inline void write_seqlock(seqlock_t *sl) ^ drivers/gpu/drm/i915/intel_engine_cs.c:1648:2: error: implicit declaration of function ‘spin_lock_irqrestore’; did you mean ‘spin_unlock_irqrestore’? [-Werror=implicit-function-declaration] spin_lock_irqrestore(&engine->timeline.lock, flags); ^~~~ spin_unlock_irqrestore cc1: all warnings being treated as errors scripts/Makefile.build:317: recipe for target 'drivers/gpu/drm/i915/intel_engine_cs.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_engine_cs.o] Error 1 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1034: 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
Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Quoting Tvrtko Ursulin (2018-06-28 14:21:06)
>
> On 28/06/2018 14:11, Chris Wilson wrote:
> > +/*
> > + * Check the unread Context Status Buffers and manage the submission of new
> > + * contexts to the ELSP accordingly.
> > + */
> > +static void execlists_submission_tasklet(unsigned long data)
> > +{
> > + struct intel_engine_cs * const engine = (struct intel_engine_cs
> > *)data;
> > + unsigned long flags;
> > +
> > + GEM_TRACE("%s awake?=%d, active=%x\n",
> > + engine->name,
> > + engine->i915->gt.awake,
> > + engine->execlists.active);
> > +
> > + spin_lock_irqsave(&engine->timeline.lock, flags);
> > +
> > + if (engine->i915->gt.awake) /* we may be delayed until after we idle!
> > */
>
> No races between the check and tasklet call? In other words the code
> path which you were describing that can race is taking the timeline lock?
intel_engine_is_idle() is unserialised.
> > + __execlists_submission_tasklet(engine);
> > +
> > + spin_unlock_irqrestore(&engine->timeline.lock, flags);
> > +}
> > +
> > static void queue_request(struct intel_engine_cs *engine,
> > struct i915_sched_node *node,
> > int prio)
> > @@ -1144,16 +1155,30 @@ static void queue_request(struct intel_engine_cs
> > *engine,
> > &lookup_priolist(engine, prio)->requests);
> > }
> >
> > -static void __submit_queue(struct intel_engine_cs *engine, int prio)
> > +static void __update_queue(struct intel_engine_cs *engine, int prio)
> > {
> > engine->execlists.queue_priority = prio;
> > - tasklet_hi_schedule(&engine->execlists.tasklet);
> > +}
> > +
> > +static void __submit_queue_imm(struct intel_engine_cs *engine)
> > +{
> > + struct intel_engine_execlists * const execlists = &engine->execlists;
> > +
> > + if (reset_in_progress(execlists))
> > + return; /* defer until we restart the engine following reset
> > */
>
> We have a tasklet kick somewhere in that path?
In execlists_reset_finish()
> > + if (execlists->tasklet.func == execlists_submission_tasklet)
> > + __execlists_submission_tasklet(engine);
> > + else
> > + tasklet_hi_schedule(&execlists->tasklet);
> > }
> >
> > static void submit_queue(struct intel_engine_cs *engine, int prio)
> > {
> > - if (prio > engine->execlists.queue_priority)
> > - __submit_queue(engine, prio);
> > + if (prio > engine->execlists.queue_priority) {
> > + __update_queue(engine, prio);
> > + __submit_queue_imm(engine);
> > + }
> > }
> >
> > static void execlists_submit_request(struct i915_request *request)
> > @@ -1165,11 +1190,12 @@ static void execlists_submit_request(struct
> > i915_request *request)
> > spin_lock_irqsave(&engine->timeline.lock, flags);
> >
> > queue_request(engine, &request->sched, rq_prio(request));
> > - submit_queue(engine, rq_prio(request));
> >
> > GEM_BUG_ON(!engine->execlists.first);
> > GEM_BUG_ON(list_empty(&request->sched.link));
> >
> > + submit_queue(engine, rq_prio(request));
> > +
> > spin_unlock_irqrestore(&engine->timeline.lock, flags);
> > }
> >
> > @@ -1296,8 +1322,11 @@ static void execlists_schedule(struct i915_request
> > *request,
> > }
> >
> > if (prio > engine->execlists.queue_priority &&
> > - i915_sw_fence_done(&sched_to_request(node)->submit))
> > - __submit_queue(engine, prio);
> > + i915_sw_fence_done(&sched_to_request(node)->submit)) {
> > + /* defer submission until after all of our updates */
> > + __update_queue(engine, prio);
> > + tasklet_hi_schedule(&engine->execlists.tasklet);
>
> _imm suffix on __submit_queue_imm sounds unused if there is no plain
> __submit_queue, which could have been used here. But meh.
I thought of trying to emphasis the immediate nature of this path. It's
not a huge deal, but I didn't particularly like calling it
direct_submit_queue() (or just direct_submit(), too many submits!)
__ prefix to indicate that it's an inner function to submit_queue,
_imm suffix to indicate what's special.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
