Re: [Intel-gfx] [PATCH] tools/intel_audio_dump: add details dump for Cherryview
On 2015.01.26 01:15:36 +, Yang, Libin wrote: > Any comments? > Looks fine to me. Reviewed-by: Zhenyu Wang I will help to push this later. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fallback to using CPU relocations for large batch buffers
On Wed, 14 Jan 2015, Chris Wilson wrote:
> If the batch buffer is too large to fit into the aperture and we need a
> GTT mapping for relocations, we currently fail. This only applies to a
> subset of machines for a subset of environments, quite undesirable. We
> can simply check after failing to insert the batch into the GTT as to
> whether we only need a mappable binding for relocation and, if so, we can
> revert to using a non-mappable binding and an alternate relocation
> method. However, using relocate_entry_cpu() is excruciatingly slow for
> large buffers on non-LLC as the entire buffer requires clflushing before
> and after the relocation handling. Alternatively, we can implement a
> third relocation method that only clflushes around the relocation entry.
> This is still slower than updating through the GTT, so we prefer using
> the GTT where possible, but is orders of magnitude faster as we
> typically do not have to then clflush the entire buffer.
>
> An alternative idea of using a temporary WC mapping of the backing store
> is promising (it should be faster than using the GTT itself), but
> requires fairly extensive arch/x86 support - along the lines of
> kmap_atomic_prof_pfn() (which is not universally implemented even for
> x86).
>
> Testcase: igt/gem_exec_big #pnv,byt
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88392
Tested-by: lu hua
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 84
> +-
> 1 file changed, 72 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index e3ef17783765..06bdf7670584 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -251,7 +251,6 @@ static inline int use_cpu_reloc(struct
> drm_i915_gem_object *obj)
> {
> return (HAS_LLC(obj->base.dev) ||
> obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
> - !obj->map_and_fenceable ||
> obj->cache_level != I915_CACHE_NONE);
> }
>
> @@ -337,6 +336,51 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
> return 0;
> }
>
> +static void
> +clflush_write32(void *addr, uint32_t value)
> +{
> + /* This is not a fast path, so KISS. */
> + drm_clflush_virt_range(addr, sizeof(uint32_t));
> + *(uint32_t *)addr = value;
> + drm_clflush_virt_range(addr, sizeof(uint32_t));
> +}
> +
> +static int
> +relocate_entry_clflush(struct drm_i915_gem_object *obj,
> +struct drm_i915_gem_relocation_entry *reloc,
> +uint64_t target_offset)
> +{
> + struct drm_device *dev = obj->base.dev;
> + uint32_t page_offset = offset_in_page(reloc->offset);
> + uint64_t delta = (int)reloc->delta + target_offset;
> + char *vaddr;
> + int ret;
> +
> + ret = i915_gem_object_set_to_gtt_domain(obj, true);
> + if (ret)
> + return ret;
> +
> + vaddr = kmap_atomic(i915_gem_object_get_page(obj,
> + reloc->offset >> PAGE_SHIFT));
> + clflush_write32(vaddr + page_offset, lower_32_bits(delta));
> +
> + if (INTEL_INFO(dev)->gen >= 8) {
> + page_offset = offset_in_page(page_offset + sizeof(uint32_t));
> +
> + if (page_offset == 0) {
> + kunmap_atomic(vaddr);
> + vaddr = kmap_atomic(i915_gem_object_get_page(obj,
> + (reloc->offset + sizeof(uint32_t)) >> PAGE_SHIFT));
> + }
> +
> + clflush_write32(vaddr + page_offset, upper_32_bits(delta));
> + }
> +
> + kunmap_atomic(vaddr);
> +
> + return 0;
> +}
> +
> static int
> i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
> struct eb_vmas *eb,
> @@ -426,9 +470,12 @@ i915_gem_execbuffer_relocate_entry(struct
> drm_i915_gem_object *obj,
>
> if (use_cpu_reloc(obj))
> ret = relocate_entry_cpu(obj, reloc, target_offset);
> - else
> + else if (obj->map_and_fenceable)
> ret = relocate_entry_gtt(obj, reloc, target_offset);
> -
> + else if (cpu_has_clflush)
> + ret = relocate_entry_clflush(obj, reloc, target_offset);
> + else
> + ret = -ENODEV;
> if (ret)
> return ret;
>
> @@ -525,6 +572,12 @@ i915_gem_execbuffer_relocate(struct eb_vmas *eb)
> return ret;
> }
>
> +static bool only_mappable_for_reloc(unsigned int flags)
> +{
> + return (flags & (EXEC_OBJECT_NEEDS_FENCE | __EXEC_OBJECT_NEEDS_MAP)) ==
> + __EXEC_OBJECT_NEEDS_MAP;
> +}
> +
> static int
> i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> struct intel_engine_cs *ring,
> @@ -536,14 +589,21 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> int ret;
>
> flags = 0;
> - if (entry->flags & __EXEC_OBJECT_NEEDS_MAP
Re: [Intel-gfx] [RFC v2] drm/i915: Android native sync support
On Mon, Jan 26, 2015 at 08:52:39AM +0100, Daniel Vetter wrote: > I think the problem will be platforms that want full explicit fence (like > android) but allow delayed creation of the fence fd from a gl sync object > (like the android egl extension allows). > > I'm not sure yet how to best expose that really since just creating a > fence from the implicit request attached to the batch might upset the > interface purists with the mix in implicit and explicit fencing ;-) Hence > why I think for now we should just do the eager fd creation at execbuf > until ppl scream (well maybe not merge this patch until ppl scream ...). Everything we do is buffer centric. Even in the future with random bits of memory, we will still use buffers behind the scenes. From an interface perspective, it is clearer to me if we say "give me a fence for this buffer". Exactly the same way as we say "is this buffer busy" or "wait on this buffer". The change is that we now hand back an fd to slot into an event loop. That, to me, is a much smaller evolutionary step of the existing API, and yet more versatile than just attaching one to the execbuf. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] agp/intel: Serialise after GTT updates
An interesting bug occurs on Pineview through which the root cause is
that the writes of the PTE values into the GTT is not serialised with
subsequent memory access through the GTT (when using WC updates of the
PTE values). This is despite there being a posting read after the GTT
update. However, by changing the address of the posting read, the memory
access is indeed serialised correctly.
Whilst we are manipulating the memory barriers, we can remove the
compiler :memory restraint on the intermediate PTE writes knowing that
we explicitly perform a posting read afterwards.
v2: Replace posting reads with explicit write memory barriers - in
particular this is advantages in case of single page objects. Update
comments to mention this issue is only with WC writes.
Testcase: igt/gem_exec_big #pnv
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191
Tested-by: huax...@intel.com (v1)
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/char/agp/intel-gtt.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 92aa43fa8d70..0b4188b9af7c 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -225,7 +225,7 @@ static int i810_insert_dcache_entries(struct agp_memory
*mem, off_t pg_start,
intel_private.driver->write_entry(addr,
i, type);
}
- readl(intel_private.gtt+i-1);
+ wmb();
return 0;
}
@@ -329,7 +329,7 @@ static void i810_write_entry(dma_addr_t addr, unsigned int
entry,
break;
}
- writel(addr | pte_flags, intel_private.gtt + entry);
+ writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
}
static const struct aper_size_info_fixed intel_fake_agp_sizes[] = {
@@ -735,7 +735,7 @@ static void i830_write_entry(dma_addr_t addr, unsigned int
entry,
if (flags == AGP_USER_CACHED_MEMORY)
pte_flags |= I830_PTE_SYSTEM_CACHED;
- writel(addr | pte_flags, intel_private.gtt + entry);
+ writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
}
bool intel_enable_gtt(void)
@@ -858,7 +858,7 @@ void intel_gtt_insert_sg_entries(struct sg_table *st,
j++;
}
}
- readl(intel_private.gtt+j-1);
+ wmb();
}
EXPORT_SYMBOL(intel_gtt_insert_sg_entries);
@@ -875,7 +875,7 @@ static void intel_gtt_insert_pages(unsigned int first_entry,
intel_private.driver->write_entry(addr,
j, flags);
}
- readl(intel_private.gtt+j-1);
+ wmb();
}
static int intel_fake_agp_insert_entries(struct agp_memory *mem,
@@ -938,7 +938,7 @@ void intel_gtt_clear_range(unsigned int first_entry,
unsigned int num_entries)
intel_private.driver->write_entry(intel_private.scratch_page_dma,
i, 0);
}
- readl(intel_private.gtt+i-1);
+ wmb();
}
EXPORT_SYMBOL(intel_gtt_clear_range);
@@ -1106,7 +1106,7 @@ static void i965_write_entry(dma_addr_t addr,
/* Shift high bits down */
addr |= (addr >> 28) & 0xf0;
- writel(addr | pte_flags, intel_private.gtt + entry);
+ writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
}
static int i9xx_setup(void)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2] drm/i915: Android native sync support
On 01/24/2015 09:47 AM, Daniel Vetter wrote: On Fri, Jan 23, 2015 at 5:49 PM, Tvrtko Ursulin wrote: Could you please translate this into something understandable by newcomers? :) I don't know which parts are confusing without questions so please ask them ... the questions below about scheduler interactions seem fairly advanced ;-) I suppose for starters, when I took over this work I read the last thread from December. There you were saying to Jesse to convert the separate ioctl into execbuf interface for in & out fences. That's what I did I thought. So is that not the fashion of the day any more or I misunderstood something? People will scream very soon for something along these lines anyway since it is kind of packaged with the scheduler I am told and both will be very much desired soon. Idea is to allow submitting of work and not block in userspace rather let the scheduler queue and shuffle depending on fences. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] uxa: fix XVMC = no build
Signed-off-by: Patrick Welche --- src/uxa/i965_video.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/uxa/i965_video.c b/src/uxa/i965_video.c index 68e6fd3..438ab90 100644 --- a/src/uxa/i965_video.c +++ b/src/uxa/i965_video.c @@ -37,7 +37,6 @@ #include "fourcc.h" #include "intel.h" -#include "intel_xvmc.h" #include "intel_uxa.h" #include "i830_reg.h" #include "i965_reg.h" -- 2.2.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] NetBSD build fixes
I found the first three patches useful when trying to build xf86-video-intel on NetBSD-current. The fourth is a coverty fix. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] configure.ac: pwd doesn't take an argument
bash built-in doesn't give an error, but real pwd does, and the argument is unnecessary. Signed-off-by: Patrick Welche --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 0ba56c1..3704722 100644 --- a/configure.ac +++ b/configure.ac @@ -847,7 +847,7 @@ AC_OUTPUT echo "" echo "" -test -e `pwd $0`/README && cat `pwd $0`/README +cat $srcdir/README accel_msg="" if test "x$SNA" != "xno"; then -- 2.2.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] backlight.c: test for features
Signed-off-by: Patrick Welche --- configure.ac| 2 ++ src/backlight.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 314e638..0ba56c1 100644 --- a/configure.ac +++ b/configure.ac @@ -398,6 +398,8 @@ AC_ARG_ENABLE(sna, [SNA="$enableval"], [SNA=auto]) +AC_CHECK_HEADERS([dev/wscons/wsconsio.h]) + if test "x$SNA" != "xno"; then AC_DEFINE(USE_SNA, 1, [Enable SNA support]) AC_CHECK_HEADERS([sys/sysinfo.h], AC_CHECK_MEMBERS([struct sysinfo.totalram], [], [], [[#include ]])) diff --git a/src/backlight.c b/src/backlight.c index 9f23986..5d63b2c 100644 --- a/src/backlight.c +++ b/src/backlight.c @@ -84,7 +84,7 @@ void backlight_init(struct backlight *b) b->has_power = 0; } -#ifdef __OpenBSD__ +#ifdef HAVE_DEV_WSCONS_WSCONSIO_H #include #include -- 2.2.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] i810: coverty fix - avoid random stack access
From: Christos Zoulas
CID 1107540: Make the code safe avoiding random stack access. In
the first loop where there is a singleton point to pptSrc, only
access that singleton, no matter what.
November 2013 patch from NetBSD xsrc:
http://mail-index.netbsd.org/source-changes/2013/11/14/msg049188.html
Signed-off-by: Patrick Welche
---
src/legacy/i810/i810_dri.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/legacy/i810/i810_dri.c b/src/legacy/i810/i810_dri.c
index cca35d6..edfbad2 100644
--- a/src/legacy/i810/i810_dri.c
+++ b/src/legacy/i810/i810_dri.c
@@ -1104,10 +1104,17 @@ I810DRIMoveBuffers(WindowPtr pParent, DDXPointRec
ptOldOrg,
while ((pboxNext >= pbox) && (pboxBase->y1 == pboxNext->y1))
pboxNext--;
pboxTmp = pboxNext + 1;
- pptTmp = pptSrc + (pboxTmp - pbox);
- while (pboxTmp <= pboxBase) {
- *pboxNew1++ = *pboxTmp++;
- *pptNew1++ = *pptTmp++;
+ if (pptSrc == &ptOldOrg) {
+ if (pboxTmp <= pboxBase) {
+ *pboxNew1++ = *pboxTmp;
+ *pptNew1++ = *pptSrc;
+ }
+ } else {
+ pptTmp = pptSrc + (pboxTmp - pbox);
+ while (pboxTmp <= pboxBase) {
+ *pboxNew1++ = *pboxTmp++;
+ *pptNew1++ = *pptTmp++;
+ }
}
pboxBase = pboxNext;
}
--
2.2.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] i810: coverty fix - avoid random stack access
On Mon, Jan 26, 2015 at 12:25:43PM +, Patrick Welche wrote: > From: Christos Zoulas > > CID 1107540: Make the code safe avoiding random stack access. In > the first loop where there is a singleton point to pptSrc, only > access that singleton, no matter what. By "singleton point" do you mean nbox==1? That's the only case I can see in which the loop is dangerous (i.e. it will read beyond the end of the array), but that loop is not accessed if nbox==1. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] NetBSD build fixes
I found the first three patches useful when getting xf86-video-intel to build on NetBSD-current. The fourth patch is a coverty fix. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] NetBSD build fixes
On Mon, Jan 26, 2015 at 12:25:39PM +, Patrick Welche wrote: > I found the first three patches useful when trying to build > xf86-video-intel on NetBSD-current. The fourth is a coverty > fix. Applied the first 3. I am dubious about the last - it looks like it is a false positive, but maybe I am just confused. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Display current hangcheck status in debugfs
From: Chris Wilson
For example,
/sys/kernel/debug/dri/0/i915_hangcheck_info:
Hangcheck active, fires in 15887800ms
render ring:
seqno = -4059 [current -583]
action = 2
score = 0
ACTHD = 1ee8 [current 21f980]
max ACTHD = 0
v2: Include expiration ETA. Can anyone spot a problem?
v3: Convert for workqueued hangcheck (Mika)
v4: Print seqnos as unsigned ints (Ville)
v5: Print seqnos as hex (Chris)
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com) (v2)
Signed-off-by: Chris Wilson (v2)
Signed-off-by: Rodrigo Vivi (v2)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ad4c48..f865cfd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1219,6 +1219,41 @@ out:
return ret;
}
+static int i915_hangcheck_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
+ struct intel_engine_cs *ring;
+ int i;
+
+ if (!i915.enable_hangcheck) {
+ seq_printf(m, "Hangcheck disabled\n");
+ return 0;
+ }
+
+ if (delayed_work_pending(&dev_priv->gpu_error.hangcheck_work)) {
+ seq_printf(m, "Hangcheck active, fires in %dms\n",
+
jiffies_to_msecs(dev_priv->gpu_error.hangcheck_work.timer.expires -
+ jiffies));
+ } else
+ seq_printf(m, "Hangcheck inactive\n");
+
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, "%s:\n", ring->name);
+ seq_printf(m, "\tseqno = %x [current %x]\n",
+ ring->hangcheck.seqno, ring->get_seqno(ring, false));
+ seq_printf(m, "\taction = %d\n", ring->hangcheck.action);
+ seq_printf(m, "\tscore = %d\n", ring->hangcheck.score);
+ seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
+ (long long)ring->hangcheck.acthd,
+ (long long)intel_ring_get_active_head(ring));
+ seq_printf(m, "\tmax ACTHD = 0x%08llx\n",
+ (long long)ring->hangcheck.max_acthd);
+ }
+
+ return 0;
+}
+
static int ironlake_drpc_info(struct seq_file *m)
{
struct drm_info_node *node = m->private;
@@ -4407,6 +4442,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
+ {"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
{"i915_emon_status", i915_emon_status, 0},
{"i915_ring_freq_table", i915_ring_freq_table, 0},
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Remove nested work in gpu error handling
Now when we declare gpu errors only through our own dedicated
hangcheck workqueue there is no need to have a separate workqueue
for handling the resetting and waking up the clients as the deadlock
concerns are no more.
The only exception is i915_debugfs::i915_set_wedged, which triggers
error handling through process context. However as this is only used through
test harness it is responsibility for test harness not to introduce hangs
through both debug interface and through hangcheck mechanism at the same time.
Remove gpu_error.work and let the hangcheck work do the tasks it used to.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_dma.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_irq.c | 34 +-
3 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6eaf795..1a46787 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -945,7 +945,6 @@ int i915_driver_unload(struct drm_device *dev)
/* Free error state after interrupts are fully disabled. */
cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
- cancel_work_sync(&dev_priv->gpu_error.work);
i915_destroy_error_state(dev);
if (dev->pdev->msi_enabled)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4eb023..cfb2641 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1352,8 +1352,6 @@ struct i915_gpu_error {
spinlock_t lock;
/* Protected by the above dev->gpu_error.lock. */
struct drm_i915_error_state *first_error;
- struct work_struct work;
-
unsigned long missed_irq_rings;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 234b1f7..44dbf78 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2421,19 +2421,15 @@ static void i915_error_wake_up(struct drm_i915_private
*dev_priv,
}
/**
- * i915_error_work_func - do process context error handling work
- * @work: work struct
+ * i915_reset_and_wakeup - do process context error handling work
*
* Fire an error uevent so userspace can see that a hang or error
* was detected.
*/
-static void i915_error_work_func(struct work_struct *work)
+static void i915_reset_and_wakeup(struct drm_device *dev)
{
- struct i915_gpu_error *error = container_of(work, struct i915_gpu_error,
- work);
- struct drm_i915_private *dev_priv =
- container_of(error, struct drm_i915_private, gpu_error);
- struct drm_device *dev = dev_priv->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct i915_gpu_error *error = &dev_priv->gpu_error;
char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
char *reset_done_event[] = { I915_ERROR_UEVENT "=0", NULL };
@@ -2600,10 +2596,10 @@ static void i915_report_and_clear_eir(struct drm_device
*dev)
}
/**
- * i915_handle_error - handle an error interrupt
+ * i915_handle_error - handle a gpu error
* @dev: drm device
*
- * Do some basic checking of regsiter state at error interrupt time and
+ * Do some basic checking of regsiter state at error time and
* dump it to the syslog. Also call i915_capture_error_state() to make
* sure we get a record and make it available in debugfs. Fire a uevent
* so userspace knows something bad happened (should trigger collection
@@ -2616,6 +2612,9 @@ void i915_handle_error(struct drm_device *dev, bool
wedged,
va_list args;
char error_msg[80];
+ if (WARN_ON(mutex_is_locked(&dev_priv->dev->struct_mutex)))
+ return;
+
va_start(args, fmt);
vscnprintf(error_msg, sizeof(error_msg), fmt, args);
va_end(args);
@@ -2628,9 +2627,9 @@ void i915_handle_error(struct drm_device *dev, bool
wedged,
&dev_priv->gpu_error.reset_counter);
/*
-* Wakeup waiting processes so that the reset work function
-* i915_error_work_func doesn't deadlock trying to grab various
-* locks. By bumping the reset counter first, the woken
+* Wakeup waiting processes so that the reset function
+* i915_reset_and_wakeup doesn't deadlock trying to grab
+* various locks. By bumping the reset counter first, the woken
* processes will see a reset in progress and back off,
* releasing their locks and then wait for the reset completion.
* We must do this for _all_ gpu waiters that might hold locks
@@ -2643,13 +2642,7 @@ void i915_handle_error(struct drm_device *dev, bool
wedged,
i915_error_wake_up(dev_priv, false);
}
-
[Intel-gfx] [PATCH 4/4] drm/i915: Be consistent on printing seqnos
We have had %x and %u intermixed. Bring everything in line and
use %x
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f865cfd..28316c7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -123,7 +123,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
struct i915_vma *vma;
int pin_count = 0;
- seq_printf(m, "%pK: %s%s%s %8zdKiB %02x %02x %u %u %u%s%s%s",
+ seq_printf(m, "%pK: %s%s%s %8zdKiB %02x %02x %x %x %x%s%s%s",
&obj->base,
get_pin_flag(obj),
get_tiling_flag(obj),
@@ -569,7 +569,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void
*data)
struct intel_engine_cs *ring =
i915_gem_request_get_ring(work->flip_queued_req);
- seq_printf(m, "Flip queued on %s at seqno %u,
next seqno %u [current breadcrumb %u], completed? %d\n",
+ seq_printf(m, "Flip queued on %s at seqno %x,
next seqno %x [current breadcrumb %x], completed? %d\n",
ring->name,
i915_gem_request_get_seqno(work->flip_queued_req),
dev_priv->next_seqno,
@@ -658,7 +658,7 @@ static int i915_gem_request_info(struct seq_file *m, void
*data)
list_for_each_entry(gem_request,
&ring->request_list,
list) {
- seq_printf(m, "%d @ %d\n",
+ seq_printf(m, "%x @ %d\n",
gem_request->seqno,
(int) (jiffies -
gem_request->emitted_jiffies));
}
@@ -676,7 +676,7 @@ static void i915_ring_seqno_info(struct seq_file *m,
struct intel_engine_cs *ring)
{
if (ring->get_seqno) {
- seq_printf(m, "Current sequence (%s): %u\n",
+ seq_printf(m, "Current sequence (%s): %x\n",
ring->name, ring->get_seqno(ring, false));
}
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Convert hangcheck from a timer into a delayed work item
From: Chris Wilson
When run as a timer, i915_hangcheck_elapsed() must adhere to all the
rules of running in a softirq context. This is advantageous to us as we
want to minimise the risk that a driver bug will prevent us from
detecting a hung GPU. However, that is irrelevant if the driver bug
prevents us from resetting and recovering. Still it is prudent not to
rely on mutexes inside the checker, but given the coarseness of
dev->struct_mutex doing so is extremely hard.
Give in and run from a work queue, i.e. outside of softirq.
v2: Use own workqueue to avoid deadlocks (Daniel)
Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris)
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Chris Wilson (v1)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_dma.c | 13 -
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 28 +++-
5 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 51e8fe5..6eaf795 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -790,6 +790,14 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
goto out_freewq;
}
+ dev_priv->gpu_error.hangcheck_wq =
+ alloc_ordered_workqueue("i915-hangcheck", 0);
+ if (dev_priv->gpu_error.hangcheck_wq == NULL) {
+ DRM_ERROR("Failed to create our hangcheck workqueue.\n");
+ ret = -ENOMEM;
+ goto out_freedpwq;
+ }
+
intel_irq_init(dev_priv);
intel_uncore_sanitize(dev);
@@ -864,6 +872,8 @@ out_gem_unload:
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
pm_qos_remove_request(&dev_priv->pm_qos);
+ destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
+out_freedpwq:
destroy_workqueue(dev_priv->dp_wq);
out_freewq:
destroy_workqueue(dev_priv->wq);
@@ -934,7 +944,7 @@ int i915_driver_unload(struct drm_device *dev)
}
/* Free error state after interrupts are fully disabled. */
- del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
+ cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
cancel_work_sync(&dev_priv->gpu_error.work);
i915_destroy_error_state(dev);
@@ -960,6 +970,7 @@ int i915_driver_unload(struct drm_device *dev)
destroy_workqueue(dev_priv->dp_wq);
destroy_workqueue(dev_priv->wq);
+ destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
pm_qos_remove_request(&dev_priv->pm_qos);
i915_global_gtt_cleanup(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 66c72bd..cb1468d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1396,7 +1396,7 @@ static int intel_runtime_suspend(struct device *device)
return ret;
}
- del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
+ cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
intel_uncore_forcewake_reset(dev, false);
dev_priv->pm.suspended = true;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0d67b17..a4eb023 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1345,7 +1345,8 @@ struct i915_gpu_error {
/* Hang gpu twice in this window and your context gets banned */
#define DRM_I915_CTX_BAN_PERIOD DIV_ROUND_UP(8*DRM_I915_HANGCHECK_PERIOD, 1000)
- struct timer_list hangcheck_timer;
+ struct workqueue_struct *hangcheck_wq;
+ struct delayed_work hangcheck_work;
/* For reset and error_state handling. */
spinlock_t lock;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fc81889..8a178cd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4615,7 +4615,7 @@ i915_gem_suspend(struct drm_device *dev)
i915_gem_stop_ringbuffers(dev);
mutex_unlock(&dev->struct_mutex);
- del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
+ cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(&dev_priv->mm.retire_work);
flush_delayed_work(&dev_priv->mm.idle_work);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2399eae..234b1f7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2982,10 +2982,12 @@ ring_stuck(struct intel_engine_cs *ring, u64 acthd)
* we kick the ring. If we see no progress on three subsequent calls
* we assume chip is wedged and try to fix it by resetting the chip.
*/
-static void i915_hangcheck_elapsed(unsigned long data)
+static void i915_hangcheck_elapsed(struct work_struct *w
[Intel-gfx] [PATCH i-g-t 3/3] tests: Introduce kms_nuclear (v2)
A very simple testcase to exercise nuclear pageflip. We'll definitely
want to expand upon this in the future, but this is a good starting
point to sanity check nuclear pageflip support.
v2:
- Add IGT_TEST_DESCRIPTION() (Thomas Wood)
- Don't use fixture-generated pipe number for main loop since this will
prevent proper test enumeration. Just assume three pipes for the
main loop and skip inside the tests if we have fewer. (Thomas Wood)
- Add to .gitignore (Thomas Wood)
Signed-off-by: Matt Roper
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/kms_nuclear.c| 320 +
3 files changed, 322 insertions(+)
create mode 100644 tests/kms_nuclear.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 88a6405..15fcf0e 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -128,6 +128,7 @@ kms_flip_event_leak
kms_flip_tiling
kms_force_connector
kms_mmio_vs_cs_flip
+kms_nuclear
kms_pipe_crc_basic
kms_plane
kms_psr_sink_crc
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 74deec3..9ab0ff4 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -70,6 +70,7 @@ TESTS_progs_M = \
kms_flip_event_leak \
kms_flip_tiling \
kms_mmio_vs_cs_flip \
+ kms_nuclear \
kms_pipe_crc_basic \
kms_plane \
kms_psr_sink_crc \
diff --git a/tests/kms_nuclear.c b/tests/kms_nuclear.c
new file mode 100644
index 000..e3f7182
--- /dev/null
+++ b/tests/kms_nuclear.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+
+IGT_TEST_DESCRIPTION("Simple test of nuclear pageflip functionality");
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+} data_t;
+
+typedef struct {
+ data_t *data;
+ igt_pipe_crc_t *pipe_crc;
+ igt_crc_t crc_1, crc_2, crc_3, crc_4, crc_5, crc_6, crc_7, crc_8,
+ crc_9, crc_10;
+ struct igt_fb red_fb, blue_fb, black_fb, yellow_fb;
+ drmModeModeInfo *mode;
+} functional_test_t;
+
+typedef struct {
+ data_t *data;
+ drmModeResPtr moderes;
+ struct igt_fb blue_fb, oversized_fb, undersized_fb;
+} sanity_test_t;
+
+typedef struct {
+ data_t *data;
+ struct igt_fb red_fb, blue_fb;
+} pageflip_test_t;
+
+static void
+functional_test_init(functional_test_t *test, igt_output_t *output, enum pipe
pipe)
+{
+ data_t *data = test->data;
+ drmModeModeInfo *mode;
+
+ test->pipe_crc = igt_pipe_crc_new(pipe, INTEL_PIPE_CRC_SOURCE_AUTO);
+
+ igt_output_set_pipe(output, pipe);
+
+ mode = igt_output_get_mode(output);
+ igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB,
+ false, /* tiled */
+ 0.0, 0.0, 0.0,
+ &test->black_fb);
+ igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB,
+ false, /* tiled */
+ 0.0, 0.0, 1.0,
+ &test->blue_fb);
+ igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB,
+ false, /* tiled */
+ 1.0, 1.0, 0.0,
+ &test->yellow_fb);
+ igt_create_color_fb(data->drm_fd, 100, 100,
+ DRM_FORMAT_XRGB,
+ false, /* tiled */
+ 1.0, 0.0, 0.0,
+ &test->red_fb);
+
+ test->mode = mode;
+}
+
+
[Intel-gfx] [PATCH i-g-t] tests/kms_universal_plane: Fix subtest enumeration
We shouldn't use the contents of data.display to determine which pipes
to run subtests on since this structure is initialized in an igt_fixture
and won't contain any useful data when enumerating subtests (i.e.,
--list-subtests won't return anything).
Instead, just assume we have three pipes in the main loop and ensure
that each subtest will skip if we don't really have that many.
Signed-off-by: Matt Roper
---
tests/kms_universal_plane.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c
index 58e4691..04ff840 100644
--- a/tests/kms_universal_plane.c
+++ b/tests/kms_universal_plane.c
@@ -359,6 +359,8 @@ sanity_test_pipe(data_t *data, enum pipe pipe, igt_output_t
*output)
drmModeModeInfo *mode;
int i, ret = 0;
+ igt_skip_on(pipe >= data->display.n_pipes);
+
igt_output_set_pipe(output, pipe);
mode = igt_output_get_mode(output);
@@ -471,6 +473,8 @@ pageflip_test_pipe(data_t *data, enum pipe pipe,
igt_output_t *output)
fd_set fds;
int ret = 0;
+ igt_skip_on(pipe >= data->display.n_pipes);
+
igt_output_set_pipe(output, pipe);
pageflip_test_init(&test, output, pipe);
@@ -552,8 +556,6 @@ static data_t data;
igt_main
{
- int num_pipes;
-
igt_skip_on_simulation();
igt_fixture {
@@ -567,8 +569,7 @@ igt_main
igt_require(data.display.has_universal_planes);
}
- num_pipes = igt_display_get_n_pipes(&data.display);
- for (int pipe = 0; pipe < num_pipes; pipe++)
+ for (int pipe = 0; pipe < 3; pipe++)
run_tests_for_pipe(&data, pipe);
igt_fixture {
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable/disable DRRS
On Sun, Jan 25, 2015 at 11:31 PM, Daniel Vetter wrote:
> On Thu, Jan 22, 2015 at 03:17:40PM +0530, Ramalingam C wrote:
>> From: Vandana Kannan
>>
>> Calling enable/disable DRRS when enable/disable DDI are called.
>> These functions are responsible for setup of drrs data (in enable) and
>> reset of drrs (in disable).
>> has_drrs is true when downclock_mode is found and SEAMLESS_DRRS is set in
>> the VBT. A check has been added for has_drrs in these functions, to make
>> sure the functions go through only if DRRS will work on the platform with
>> the attached panel.
>>
>> V2: [By Ram]: WARN_ON is used when intel_edp_drrs_enable() is called more
>> than
>> once [Rodrigo]
>>
>> Signed-off-by: Vandana Kannan
>> Signed-off-by: Rodrigo Vivi
>
> Please be a bit more careful with adding sob lines - afaik Rodrigo did not
> handle this patch. If you just want to get people's attention, please use
> Cc: instead.
>
> Fixed while applying.
> -Daniel
that was actually my fault... I had fixed a rebase conflicted and
added to a drrs-review branch at cgit.
I signed-off but didn't increment the v2 explaining the rebase.
Thanks for merging.
>
>> Signed-off-by: Ramalingam C
>> ---
>> drivers/gpu/drm/i915/intel_ddi.c |2 ++
>> drivers/gpu/drm/i915/intel_dp.c | 55
>> ++
>> drivers/gpu/drm/i915/intel_drv.h |2 ++
>> 3 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index f10ec26..ad8b73d 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -1610,6 +1610,7 @@ static void intel_enable_ddi(struct intel_encoder
>> *intel_encoder)
>>
>> intel_edp_backlight_on(intel_dp);
>> intel_psr_enable(intel_dp);
>> + intel_edp_drrs_enable(intel_dp);
>> }
>>
>> if (intel_crtc->config->has_audio) {
>> @@ -1635,6 +1636,7 @@ static void intel_disable_ddi(struct intel_encoder
>> *intel_encoder)
>> if (type == INTEL_OUTPUT_EDP) {
>> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>>
>> + intel_edp_drrs_disable(intel_dp);
>> intel_psr_disable(intel_dp);
>> intel_edp_backlight_off(intel_dp);
>> }
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index c066560..f843fe0 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -4820,6 +4820,61 @@ static void intel_dp_set_drrs_state(struct drm_device
>> *dev, int refresh_rate)
>> DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
>> }
>>
>> +void intel_edp_drrs_enable(struct intel_dp *intel_dp)
>> +{
>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> + struct drm_crtc *crtc = dig_port->base.base.crtc;
>> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> +
>> + if (!intel_crtc->config->has_drrs) {
>> + DRM_DEBUG_KMS("Panel doesn't support DRRS\n");
>> + return;
>> + }
>> +
>> + mutex_lock(&dev_priv->drrs.mutex);
>> + if (WARN_ON(dev_priv->drrs.dp)) {
>> + DRM_ERROR("DRRS already enabled\n");
>> + goto unlock;
>> + }
>> +
>> + dev_priv->drrs.busy_frontbuffer_bits = 0;
>> +
>> + dev_priv->drrs.dp = intel_dp;
>> +
>> +unlock:
>> + mutex_unlock(&dev_priv->drrs.mutex);
>> +}
>> +
>> +void intel_edp_drrs_disable(struct intel_dp *intel_dp)
>> +{
>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> + struct drm_crtc *crtc = dig_port->base.base.crtc;
>> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> +
>> + if (!intel_crtc->config->has_drrs)
>> + return;
>> +
>> + mutex_lock(&dev_priv->drrs.mutex);
>> + if (!dev_priv->drrs.dp) {
>> + mutex_unlock(&dev_priv->drrs.mutex);
>> + return;
>> + }
>> +
>> + if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
>> + intel_dp_set_drrs_state(dev_priv->dev,
>> + intel_dp->attached_connector->panel.
>> + fixed_mode->vrefresh);
>> +
>> + dev_priv->drrs.dp = NULL;
>> + mutex_unlock(&dev_priv->drrs.mutex);
>> +
>> + cancel_delayed_work_sync(&dev_priv->drrs.work);
>> +}
>> +
>> static void intel_edp_drrs_downclock_work(struct work_struct *work)
>> {
>> struct drm_i915_private *dev_priv =
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index e957d4d..5a14725 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1030,6 +1030,8 @@ int intel_update_plane(struct drm_plane *plane,
Re: [Intel-gfx] [PATCH] drm/i915: allow requesting the audio power well for all platforms
On Fri, Dec 5, 2014 at 5:55 AM, Imre Deak wrote:
> On Fri, 2014-12-05 at 15:28 +0200, Imre Deak wrote:
>> So far we only allowed HSW and BDW to request for the audio power
>> domain, but it is also needed at least on VLV/CHV. There is no need
>> for this restriction, since the power domain->power well mapping should
>> take care of the distinctions between platforms.
>>
>> Spotted-by: Jani Nikula
>> Signed-off-by: Imre Deak
>> ---
>> drivers/gpu/drm/i915/intel_runtime_pm.c | 20 ++--
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 8a2bd18..58204ab 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -50,7 +50,7 @@
>> * present for a given platform.
>> */
>>
>> -static struct i915_power_domains *hsw_pwr;
>> +static struct i915_power_domains *i915_pwr;
>>
>> #define for_each_power_well(i, power_well, domain_mask, power_domains)
>> \
>> for (i = 0; \
>> @@ -1098,10 +1098,8 @@ int intel_power_domains_init(struct drm_i915_private
>> *dev_priv)
>>*/
>> if (IS_HASWELL(dev_priv->dev)) {
>> set_power_wells(power_domains, hsw_power_wells);
>> - hsw_pwr = power_domains;
>> } else if (IS_BROADWELL(dev_priv->dev)) {
>> set_power_wells(power_domains, bdw_power_wells);
>> - hsw_pwr = power_domains;
>> } else if (IS_CHERRYVIEW(dev_priv->dev)) {
>> set_power_wells(power_domains, chv_power_wells);
>> } else if (IS_VALLEYVIEW(dev_priv->dev)) {
>> @@ -1110,6 +1108,8 @@ int intel_power_domains_init(struct drm_i915_private
>> *dev_priv)
>> set_power_wells(power_domains, i9xx_always_on_power_well);
>> }
>>
>> + i915_pwr = power_domains;
>> +
>> return 0;
>> }
>>
>> @@ -1146,7 +1146,7 @@ void intel_power_domains_fini(struct drm_i915_private
>> *dev_priv)
>>* we're going to unload/reload. */
>> intel_display_set_init_power(dev_priv, true);
>>
>> - hsw_pwr = NULL;
>> + i915_pwr = NULL;
>> }
>>
>> static void intel_power_domains_resume(struct drm_i915_private *dev_priv)
>> @@ -1360,10 +1360,10 @@ int i915_request_power_well(void)
>> {
>> struct drm_i915_private *dev_priv;
>>
>> - if (!hsw_pwr)
>> + if (!i915_pwr)
>> return -ENODEV;
>>
>> - dev_priv = container_of(hsw_pwr, struct drm_i915_private,
>> + dev_priv = container_of(i915_pwr, struct drm_i915_private,
>> power_domains);
>> intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
>> return 0;
>> @@ -1375,10 +1375,10 @@ int i915_release_power_well(void)
>> {
>> struct drm_i915_private *dev_priv;
>>
>> - if (!hsw_pwr)
>> + if (!i915_pwr)
>> return -ENODEV;
>>
>> - dev_priv = container_of(hsw_pwr, struct drm_i915_private,
>> + dev_priv = container_of(i915_pwr, struct drm_i915_private,
>> power_domains);
>> intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
>> return 0;
>> @@ -1395,10 +1395,10 @@ int i915_get_cdclk_freq(void)
>> {
>> struct drm_i915_private *dev_priv;
>>
>> - if (!hsw_pwr)
>> + if (!i915_pwr)
>> return -ENODEV;
>
> Err, we should also WARN and return here for !HAS_DDI. This is used for
> restoring the audio BCLK M/N values in the HSW/BDW extended mode
> registers, but there is no corresponding registers on other platforms.
I was getting this patch for collector but this comment confused me.
Should we expect a v2 or get this?
>
>>
>> - dev_priv = container_of(hsw_pwr, struct drm_i915_private,
>> + dev_priv = container_of(i915_pwr, struct drm_i915_private,
>> power_domains);
>>
>> return intel_ddi_get_cdclk_freq(dev_priv);
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] commit break fullscreen video
Hello, with latest git xf86-video-intel, video work but when i switch to fullscreen , i just got a crash of X. This with vdr-sxfe (xine-lib) and kodi (xbmc). Both use vaapi. Starting vdr-sxfe with xv seem to don't crash but i need vaapi. After some more test ,it's seem it's commit "sna/dri2: Only preserve back buffers with the same pitch" the faulty. If i unpatch the commit fullscreen video work again. See you. kernel 3.18.3-gentoo xorg-server-1.16.3-r1 mesa-10.4.2 git xf86-video-intel Intel Core i3 3220T (Ivy Bridge hd graphics 2500) lspci -vxxx -s 0:02.0 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) DeviceName: Onboard IGD Subsystem: Micro-Star International Co., Ltd. [MSI] Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 28 Memory at f780 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915 00: 86 80 52 01 07 04 90 00 09 00 00 03 00 00 00 00 10: 04 00 80 f7 00 00 00 00 0c 00 00 e0 00 00 00 00 20: 01 f0 00 00 00 00 00 00 00 00 00 00 62 14 11 21 30: 00 00 00 00 90 00 00 00 00 00 00 00 0b 01 00 00 40: 09 00 0c 01 92 80 80 e2 d0 00 50 14 00 00 00 00 50: 41 02 00 00 11 00 00 00 00 00 00 00 01 00 a0 cf 60: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 05 d0 01 00 0c f0 e0 fe 52 41 00 00 00 00 00 00 a0: 00 00 00 00 13 00 06 03 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 a4 22 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 09 00 18 90 5a cd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring
Similar to: commit 02c9f7e3cfe76a7f54ef03438c36aade86cc1c8b Author: Kenneth Graunke Date: Mon Jan 27 14:20:16 2014 -0800 drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround. On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set must be preceded by a PIPE_CONTROL with the "CS Stall" bit set. Documented on the BSpec 3D workarounds page. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_lrc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 9b95233..ae29f30d 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1286,6 +1286,7 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf, struct intel_engine_cs *ring = ringbuf->ring; u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES; u32 flags = 0; + int ret; flags |= PIPE_CONTROL_CS_STALL; @@ -1303,6 +1304,15 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf, flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE; flags |= PIPE_CONTROL_QW_WRITE; flags |= PIPE_CONTROL_GLOBAL_GTT_IVB; + + + /* WaCsStallBeforeStateCacheInvalidate:bdw,chv */ + ret = gen8_emit_pipe_control(ring, +PIPE_CONTROL_CS_STALL | +PIPE_CONTROL_STALL_AT_SCOREBOARD, +0); + if (ret) + return ret; } return gen8_emit_pipe_control(ringbuf, flags, scratch_addr); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] drm/i915: Extend GET_APERTURE ioctl to report available map space
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116 ++--
include/uapi/drm/i915_drm.h | 25
3 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0d11cbe..f1aea86 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -498,6 +498,32 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node->minor->dev, &arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, "Total size of the GTT: %llu bytes\n",
+ arg.aper_size);
+ seq_printf(m, "Available space in the GTT: %llu bytes\n",
+ arg.aper_available_size);
+ seq_printf(m, "Available space in the mappable aperture: %llu bytes\n",
+ arg.map_available_size);
+ seq_printf(m, "Single largest space in the mappable aperture: %llu
bytes\n",
+ arg.map_largest_size);
+ seq_printf(m, "Available space for fences: %llu bytes\n",
+ arg.fence_available_size);
+ seq_printf(m, "Single largest fence available: %llu bytes\n",
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -4398,6 +4424,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
+ {"i915_gem_aperture", i915_gem_aperture_info, 0},
{"i915_gem_gtt", i915_gem_gtt_info, 0},
{"i915_gem_pinned", i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{"i915_gem_active", i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 123ce34..0a074bc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -31,6 +31,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_drv.h"
+#include
#include
#include
#include
@@ -153,6 +154,55 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) && !obj->active;
+}
+
+static int obj_rank_by_ggtt(void *priv,
+ struct list_head *A,
+ struct list_head *B)
+{
+ struct drm_i915_gem_object *a = list_entry(A,typeof(*a), obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B,typeof(*b), obj_exec_link);
+
+ return i915_gem_obj_ggtt_offset(a) - i915_gem_obj_ggtt_offset(b);
+}
+
+static u32 __fence_size(struct drm_i915_private *dev_priv, u32 start, u32 end)
+{
+ u32 size = end - start;
+ u32 fence_size;
+
+ if (INTEL_INFO(dev_priv)->gen < 4) {
+ u32 fence_max;
+ u32 fence_next;
+
+ if (IS_GEN3(dev_priv)) {
+ fence_max = I830_FENCE_MAX_SIZE_VAL << 20;
+ fen
[Intel-gfx] [PATCH 08/11] Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"
From: Chris Wilson The core fix was applied in commit a63b03e2d2477586440741677ecac45bcf28d7b1 Author: Chris Wilson Date: Tue Jan 6 10:29:35 2015 + mutex: Always clear owner field upon mutex_unlock() (note the absence of stable@ tag) so we can now revert our band-aid commit 226e5ae9e5f910 for -next. Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 0a074bc..b50a2b4 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -5213,7 +5213,7 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task) if (!mutex_is_locked(mutex)) return false; -#if defined(CONFIG_SMP) && !defined(CONFIG_DEBUG_MUTEXES) +#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES) return mutex->owner == task; #else /* Since UP may be pre-empted, we cannot assume that we own the lock */ -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915: add irq_barrier operation for synchronising reads
From: Dave Gordon
On some generations of chips, it is necessary to read an MMIO register
before getting the sequence number from the status page in main memory,
in order to ensure coherency; and on all generations this should be
either helpful or harmless.
In general, we want this operation to be the cheapest possible, since
we require only the side-effect of DMA completion and don't interpret
the result of the read, and don't require any coordination with other
threads, power domains, or anything else.
However, finding a suitable register may be problematic; on GEN6 chips
the ACTHD register was used, but on VLV et al access to this register
requires FORCEWAKE and therefore many complications involving spinlocks
and polling.
So this commit introduces this synchronising operation as a distinct
vfunc in the engine structure, so that it can be GEN- or chip-specific
if needed.
And there are three implementations; a dummy one, for chips where no
synchronising read is needed, a gen6(+) version that issues a posting
read (to TAIL), and a VLV-specific one that issues a raw read instead,
avoiding touching FORCEWAKE and GTFIFO and other such complications.
We then change gen6_ring_get_seqno() to use this new irq_barrier rather
than a POSTING_READ of ACTHD. Note that both older (pre-GEN6) and newer
(GEN8+) devices running in LRC mode do not currently include any posting
read in their own get_seqno() implementations, so this change only
makes a difference on VLV (and not CHV+).
Signed-off-by: Dave Gordon
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 37 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 23020d6..97473ed 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1227,6 +1227,28 @@ pc_render_add_request(struct intel_engine_cs *ring)
return 0;
}
+static void
+dummy_irq_barrier(struct intel_engine_cs *ring)
+{
+}
+
+static void
+gen6_irq_barrier(struct intel_engine_cs *ring)
+{
+ struct drm_i915_private *dev_priv = to_i915(ring->dev);
+ POSTING_READ(RING_TAIL(ring->mmio_base));
+}
+
+#define __raw_i915_read32(dev_priv__, reg__) readl((dev_priv__)->regs +
(reg__))
+#define RAW_POSTING_READ(reg__)
(void)__raw_i915_read32(dev_priv, reg__)
+
+static void
+vlv_irq_barrier(struct intel_engine_cs *ring)
+{
+ struct drm_i915_private *dev_priv = to_i915(ring->dev);
+ RAW_POSTING_READ(RING_TAIL(ring->mmio_base));
+}
+
static u32
gen6_ring_get_seqno(struct intel_engine_cs *ring, bool lazy_coherency)
{
@@ -1234,8 +1256,7 @@ gen6_ring_get_seqno(struct intel_engine_cs *ring, bool
lazy_coherency)
* ivb (and maybe also on snb) by reading from a CS register (like
* ACTHD) before reading the status page. */
if (!lazy_coherency) {
- struct drm_i915_private *dev_priv = ring->dev->dev_private;
- POSTING_READ(RING_ACTHD(ring->mmio_base));
+ ring->irq_barrier(ring);
}
return intel_read_status_page(ring, I915_GEM_HWS_INDEX);
@@ -2393,6 +2414,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring->irq_get = gen8_ring_get_irq;
ring->irq_put = gen8_ring_put_irq;
ring->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
+ ring->irq_barrier = gen6_irq_barrier;
ring->get_seqno = gen6_ring_get_seqno;
ring->set_seqno = ring_set_seqno;
if (i915_semaphore_is_enabled(dev)) {
@@ -2409,6 +2431,10 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring->irq_get = gen6_ring_get_irq;
ring->irq_put = gen6_ring_put_irq;
ring->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
+ if (IS_VALLEYVIEW(dev) && !IS_GEN8(dev))
+ ring->irq_barrier = vlv_irq_barrier;
+ else
+ ring->irq_barrier = gen6_irq_barrier;
ring->get_seqno = gen6_ring_get_seqno;
ring->set_seqno = ring_set_seqno;
if (i915_semaphore_is_enabled(dev)) {
@@ -2435,6 +2461,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
} else if (IS_GEN5(dev)) {
ring->add_request = pc_render_add_request;
ring->flush = gen4_render_ring_flush;
+ ring->irq_barrier = dummy_irq_barrier;
ring->get_seqno = pc_render_get_seqno;
ring->set_seqno = pc_render_set_seqno;
ring->irq_get = gen5_ring_get_irq;
@@ -2447,6 +2474,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring->flush = gen2_rende
[Intel-gfx] [PATCH 06/11] drm/i915/vlv: check port in infoframe_enabled v2
From: Jesse Barnes Same as IBX and G4x, they all share the same genetic material. v2: we all need a bit more port in our lives Signed-off-by: Jesse Barnes Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_hdmi.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 3abc200..62606e6 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -323,10 +323,15 @@ static bool vlv_infoframe_enabled(struct drm_encoder *encoder) struct drm_device *dev = encoder->dev; struct drm_i915_private *dev_priv = dev->dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc); + struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); int reg = VLV_TVIDEO_DIP_CTL(intel_crtc->pipe); u32 val = I915_READ(reg); + u32 port = intel_dig_port->port; - return val & VIDEO_DIP_ENABLE; + if (port == (val & VIDEO_DIP_PORT_MASK)) + return val & VIDEO_DIP_ENABLE; + + return false; } static void hsw_write_infoframe(struct drm_encoder *encoder, -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] drm/i915: Display current hangcheck status in debugfs
From: Chris Wilson
For example,
/sys/kernel/debug/dri/0/i915_hangcheck_info:
Hangcheck active, fires in 15887800ms
render ring:
seqno = -4059 [current -583]
action = 2
score = 0
ACTHD = 1ee8 [current 21f980]
max ACTHD = 0
v2: Include expiration ETA. Can anyone spot a problem?
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f1aea86..bc06ad4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1245,6 +1245,40 @@ out:
return ret;
}
+static int i915_hangcheck_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
+ struct intel_engine_cs *ring;
+ int i;
+
+ if (!i915.enable_hangcheck) {
+ seq_printf(m, "Hangcheck disabled\n");
+ return 0;
+ }
+
+ if (timer_pending(&dev_priv->gpu_error.hangcheck_timer)) {
+ seq_printf(m, "Hangcheck active, fires in %dms\n",
+
jiffies_to_msecs(dev_priv->gpu_error.hangcheck_timer.expires - jiffies));
+ } else
+ seq_printf(m, "Hangcheck inactive\n");
+
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, "%s:\n", ring->name);
+ seq_printf(m, "\tseqno = %d [current %d]\n",
+ ring->hangcheck.seqno, ring->get_seqno(ring, false));
+ seq_printf(m, "\taction = %d\n", ring->hangcheck.action);
+ seq_printf(m, "\tscore = %d\n", ring->hangcheck.score);
+ seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
+ (long long)ring->hangcheck.acthd,
+ (long long)intel_ring_get_active_head(ring));
+ seq_printf(m, "\tmax ACTHD = 0x%08llx\n",
+ (long long)ring->hangcheck.max_acthd);
+ }
+
+ return 0;
+}
+
static int ironlake_drpc_info(struct seq_file *m)
{
struct drm_info_node *node = m->private;
@@ -4441,6 +4475,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
+ {"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
{"i915_emon_status", i915_emon_status, 0},
{"i915_ring_freq_table", i915_ring_freq_table, 0},
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915: use effective_size for ringbuffer calculations
From: Dave Gordon
When calculating the available space in a ringbuffer, we should
use the effective_size rather than the true size of the ring.
v2: rebase to latest drm-intel-nightly
Signed-off-by: Dave Gordon
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ae29f30d..59e8517 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -941,7 +941,7 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
/* Would completion of this request free enough space? */
if (__intel_ring_space(request->tail, ringbuf->tail,
- ringbuf->size) >= bytes) {
+ ringbuf->effective_size) >= bytes) {
break;
}
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 97473ed..0c46410 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -66,7 +66,8 @@ void intel_ring_update_space(struct intel_ringbuffer *ringbuf)
}
ringbuf->space = __intel_ring_space(ringbuf->head & HEAD_ADDR,
- ringbuf->tail, ringbuf->size);
+ ringbuf->tail,
+ ringbuf->effective_size);
}
int intel_ring_space(struct intel_ringbuffer *ringbuf)
@@ -1971,7 +1972,7 @@ static int intel_ring_wait_request(struct intel_engine_cs
*ring, int n)
list_for_each_entry(request, &ring->request_list, list) {
if (__intel_ring_space(request->tail, ringbuf->tail,
- ringbuf->size) >= n) {
+ ringbuf->effective_size) >= n) {
break;
}
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/11] drm-intel-collector - update
This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Put logical pipe_control emission into a helper. - Reviewer: Patch drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring - Reviewer: Patch drm/i915: Remove pinned check from madvise_ioctl - Reviewer: Patch drm/i915: Extend GET_APERTURE ioctl to report available map space - Reviewer: Patch drm/i915: Display current hangcheck status in debugfs - Reviewer: Patch drm/i915/vlv: check port in infoframe_enabled v2 - Reviewer: Patch drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg - Reviewer: Patch Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES" - Reviewer: Patch drm/i915: FIFO space query code refactor - Reviewer: Patch drm/i915: add irq_barrier operation for synchronising reads - Reviewer: Patch drm/i915: use effective_size for ringbuffer calculations - Reviewer: Another round for discussions finished from Dec-05 to Dec-19. Thanks in advance, Rodrigo. Chris Wilson (3): drm/i915: Remove pinned check from madvise_ioctl drm/i915: Display current hangcheck status in debugfs Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES" Dave Gordon (3): drm/i915: FIFO space query code refactor drm/i915: add irq_barrier operation for synchronising reads drm/i915: use effective_size for ringbuffer calculations Imre Deak (1): drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg Jesse Barnes (1): drm/i915/vlv: check port in infoframe_enabled v2 Rodrigo Vivi (3): drm/i915: Put logical pipe_control emission into a helper. drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring drm/i915: Extend GET_APERTURE ioctl to report available map space drivers/gpu/drm/i915/i915_debugfs.c | 62 drivers/gpu/drm/i915/i915_drv.c | 4 +- drivers/gpu/drm/i915/i915_gem.c | 124 +--- drivers/gpu/drm/i915/intel_hdmi.c | 7 +- drivers/gpu/drm/i915/intel_lrc.c| 43 +++ drivers/gpu/drm/i915/intel_ringbuffer.c | 42 +-- drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + drivers/gpu/drm/i915/intel_uncore.c | 19 +++-- include/uapi/drm/i915_drm.h | 25 +++ 9 files changed, 289 insertions(+), 38 deletions(-) -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg
From: Imre Deak Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0c36f3665446518c609be91f9336ef674 Author: Imre Deak Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Signed-off-by: Imre Deak Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 308774f..bf39a1d 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1028,7 +1028,7 @@ static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv) s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS_BASE + i * 4); s->media_max_req_count = I915_READ(GEN7_MEDIA_MAX_REQ_COUNT); - s->gfx_max_req_count= I915_READ(GEN7_MEDIA_MAX_REQ_COUNT); + s->gfx_max_req_count= I915_READ(GEN7_GFX_MAX_REQ_COUNT); s->render_hwsp = I915_READ(RENDER_HWS_PGA_GEN7); s->ecochk = I915_READ(GAM_ECOCHK); @@ -1109,7 +1109,7 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv) I915_WRITE(GEN7_LRA_LIMITS_BASE + i * 4, s->lra_limits[i]); I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->media_max_req_count); - I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->gfx_max_req_count); + I915_WRITE(GEN7_GFX_MAX_REQ_COUNT, s->gfx_max_req_count); I915_WRITE(RENDER_HWS_PGA_GEN7, s->render_hwsp); I915_WRITE(GAM_ECOCHK, s->ecochk); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] drm/i915: Remove pinned check from madvise_ioctl
From: Chris Wilson
We don't need to incur the overhead of checking whether the object is
pinned prior to changing its madvise. If the object is pinned, the
madvise will not take effect until it is unpinned and so we cannot free
the pages being pointed at by hardware. Marking a pinned object with
allocated pages as DONTNEED will not trigger any undue warnings. The check
is therefore superfluous, and by removing it we can remove a linear walk
over all the vma the object has.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6c40365..123ce34 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4365,11 +4365,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
*data,
goto unlock;
}
- if (i915_gem_obj_is_pinned(obj)) {
- ret = -EINVAL;
- goto out;
- }
-
if (obj->pages &&
obj->tiling_mode != I915_TILING_NONE &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
@@ -4388,7 +4383,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
args->retained = obj->madv != __I915_MADV_PURGED;
-out:
drm_gem_object_unreference(&obj->base);
unlock:
mutex_unlock(&dev->struct_mutex);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915: Put logical pipe_control emission into a helper.
To be used for a Workaroud. Similar to:
commit 884ceacee308f0e4616d0c933518af2639f7b1d8
Author: Kenneth Graunke
Date: Sat Jun 28 02:04:20 2014 +0300
drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_lrc.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e405b61..9b95233 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1259,6 +1259,26 @@ static int gen8_emit_flush(struct intel_ringbuffer
*ringbuf,
return 0;
}
+static int gen8_emit_pipe_control(struct intel_ringbuffer *ringbuf,
+ u32 flags, u32 scratch_addr)
+{
+ int ret;
+
+ ret = intel_logical_ring_begin(ringbuf, 6);
+ if (ret)
+ return ret;
+
+ intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
+ intel_logical_ring_emit(ringbuf, flags);
+ intel_logical_ring_emit(ringbuf, scratch_addr);
+ intel_logical_ring_emit(ringbuf, 0);
+ intel_logical_ring_emit(ringbuf, 0);
+ intel_logical_ring_emit(ringbuf, 0);
+ intel_logical_ring_advance(ringbuf);
+
+ return 0;
+}
+
static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
u32 invalidate_domains,
u32 flush_domains)
@@ -1266,7 +1286,6 @@ static int gen8_emit_flush_render(struct intel_ringbuffer
*ringbuf,
struct intel_engine_cs *ring = ringbuf->ring;
u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES;
u32 flags = 0;
- int ret;
flags |= PIPE_CONTROL_CS_STALL;
@@ -1286,19 +1305,7 @@ static int gen8_emit_flush_render(struct
intel_ringbuffer *ringbuf,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
}
- ret = intel_logical_ring_begin(ringbuf, 6);
- if (ret)
- return ret;
-
- intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
- intel_logical_ring_emit(ringbuf, flags);
- intel_logical_ring_emit(ringbuf, scratch_addr);
- intel_logical_ring_emit(ringbuf, 0);
- intel_logical_ring_emit(ringbuf, 0);
- intel_logical_ring_emit(ringbuf, 0);
- intel_logical_ring_advance(ringbuf);
-
- return 0;
+ return gen8_emit_pipe_control(ringbuf, flags, scratch_addr);
}
static u32 gen8_get_seqno(struct intel_engine_cs *ring, bool lazy_coherency)
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/i915: FIFO space query code refactor
From: Dave Gordon
When querying the GTFIFOCTL register to check the FIFO space, the read value
must be masked. The operation is repeated explicitly in several places. This
change refactors the read-and-mask code into a function call.
v2*: rebased on top of Mika's forcewake changes
Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: Dave Gordon
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_uncore.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e9561de..d29b4d4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -147,6 +147,13 @@ static void __gen7_gt_force_wake_mt_put(struct
drm_i915_private *dev_priv,
gen6_gt_check_fifodbg(dev_priv);
}
+static inline u32 fifo_free_entries(struct drm_i915_private *dev_priv)
+{
+ u32 count = __raw_i915_read32(dev_priv, GTFIFOCTL);
+
+ return count & GT_FIFO_FREE_ENTRIES_MASK;
+}
+
static int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
{
int ret = 0;
@@ -154,16 +161,15 @@ static int __gen6_gt_wait_for_fifo(struct
drm_i915_private *dev_priv)
/* On VLV, FIFO will be shared by both SW and HW.
* So, we need to read the FREE_ENTRIES everytime */
if (IS_VALLEYVIEW(dev_priv->dev))
- dev_priv->uncore.fifo_count =
- __raw_i915_read32(dev_priv, GTFIFOCTL) &
- GT_FIFO_FREE_ENTRIES_MASK;
+ dev_priv->uncore.fifo_count = fifo_free_entries(dev_priv);
if (dev_priv->uncore.fifo_count < GT_FIFO_NUM_RESERVED_ENTRIES) {
int loop = 500;
- u32 fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) &
GT_FIFO_FREE_ENTRIES_MASK;
+ u32 fifo = fifo_free_entries(dev_priv);
+
while (fifo <= GT_FIFO_NUM_RESERVED_ENTRIES && loop--) {
udelay(10);
- fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) &
GT_FIFO_FREE_ENTRIES_MASK;
+ fifo = fifo_free_entries(dev_priv);
}
if (WARN_ON(loop < 0 && fifo <= GT_FIFO_NUM_RESERVED_ENTRIES))
++ret;
@@ -505,8 +511,7 @@ void intel_uncore_forcewake_reset(struct drm_device *dev,
bool restore)
if (IS_GEN6(dev) || IS_GEN7(dev))
dev_priv->uncore.fifo_count =
- __raw_i915_read32(dev_priv, GTFIFOCTL) &
- GT_FIFO_FREE_ENTRIES_MASK;
+ fifo_free_entries(dev_priv);
}
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: allow requesting the audio power well for all platforms
On Mon, 2015-01-26 at 11:12 -0800, Rodrigo Vivi wrote:
> On Fri, Dec 5, 2014 at 5:55 AM, Imre Deak wrote:
> > On Fri, 2014-12-05 at 15:28 +0200, Imre Deak wrote:
> >> So far we only allowed HSW and BDW to request for the audio power
> >> domain, but it is also needed at least on VLV/CHV. There is no need
> >> for this restriction, since the power domain->power well mapping should
> >> take care of the distinctions between platforms.
> >>
> >> Spotted-by: Jani Nikula
> >> Signed-off-by: Imre Deak
> >> ---
> >> drivers/gpu/drm/i915/intel_runtime_pm.c | 20 ++--
> >> 1 file changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> index 8a2bd18..58204ab 100644
> >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> @@ -50,7 +50,7 @@
> >> * present for a given platform.
> >> */
> >>
> >> -static struct i915_power_domains *hsw_pwr;
> >> +static struct i915_power_domains *i915_pwr;
> >>
> >> #define for_each_power_well(i, power_well, domain_mask, power_domains)
> >>\
> >> for (i = 0; \
> >> @@ -1098,10 +1098,8 @@ int intel_power_domains_init(struct
> >> drm_i915_private *dev_priv)
> >>*/
> >> if (IS_HASWELL(dev_priv->dev)) {
> >> set_power_wells(power_domains, hsw_power_wells);
> >> - hsw_pwr = power_domains;
> >> } else if (IS_BROADWELL(dev_priv->dev)) {
> >> set_power_wells(power_domains, bdw_power_wells);
> >> - hsw_pwr = power_domains;
> >> } else if (IS_CHERRYVIEW(dev_priv->dev)) {
> >> set_power_wells(power_domains, chv_power_wells);
> >> } else if (IS_VALLEYVIEW(dev_priv->dev)) {
> >> @@ -1110,6 +1108,8 @@ int intel_power_domains_init(struct drm_i915_private
> >> *dev_priv)
> >> set_power_wells(power_domains, i9xx_always_on_power_well);
> >> }
> >>
> >> + i915_pwr = power_domains;
> >> +
> >> return 0;
> >> }
> >>
> >> @@ -1146,7 +1146,7 @@ void intel_power_domains_fini(struct
> >> drm_i915_private *dev_priv)
> >>* we're going to unload/reload. */
> >> intel_display_set_init_power(dev_priv, true);
> >>
> >> - hsw_pwr = NULL;
> >> + i915_pwr = NULL;
> >> }
> >>
> >> static void intel_power_domains_resume(struct drm_i915_private *dev_priv)
> >> @@ -1360,10 +1360,10 @@ int i915_request_power_well(void)
> >> {
> >> struct drm_i915_private *dev_priv;
> >>
> >> - if (!hsw_pwr)
> >> + if (!i915_pwr)
> >> return -ENODEV;
> >>
> >> - dev_priv = container_of(hsw_pwr, struct drm_i915_private,
> >> + dev_priv = container_of(i915_pwr, struct drm_i915_private,
> >> power_domains);
> >> intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
> >> return 0;
> >> @@ -1375,10 +1375,10 @@ int i915_release_power_well(void)
> >> {
> >> struct drm_i915_private *dev_priv;
> >>
> >> - if (!hsw_pwr)
> >> + if (!i915_pwr)
> >> return -ENODEV;
> >>
> >> - dev_priv = container_of(hsw_pwr, struct drm_i915_private,
> >> + dev_priv = container_of(i915_pwr, struct drm_i915_private,
> >> power_domains);
> >> intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
> >> return 0;
> >> @@ -1395,10 +1395,10 @@ int i915_get_cdclk_freq(void)
> >> {
> >> struct drm_i915_private *dev_priv;
> >>
> >> - if (!hsw_pwr)
> >> + if (!i915_pwr)
> >> return -ENODEV;
> >
> > Err, we should also WARN and return here for !HAS_DDI. This is used for
> > restoring the audio BCLK M/N values in the HSW/BDW extended mode
> > registers, but there is no corresponding registers on other platforms.
>
> I was getting this patch for collector but this comment confused me.
> Should we expect a v2 or get this?
Rodrigo, this patch can be ignored, since we have already the audio
component code merged. That one solves this problem too.
>
> >
> >>
> >> - dev_priv = container_of(hsw_pwr, struct drm_i915_private,
> >> + dev_priv = container_of(i915_pwr, struct drm_i915_private,
> >> power_domains);
> >>
> >> return intel_ddi_get_cdclk_freq(dev_priv);
> >
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Add gt_act_freq_mhz sysfs file
On Sun, Jan 25, 2015 at 09:34:33AM +, Chris Wilson wrote:
> On Fri, Jan 23, 2015 at 09:04:24PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently the 'gt_cur_freq_mhz' file shows the actual GPU frequency on
> > VLV/CHV, and the last requested frequency on other platforms. Change the
> > meaning of the file on VLV/CHV to follow the the other platforms, and
> > introduce a new file 'gt_act_freq_mhz' which shows the actual frequency
> > on all platforms.
> >
> > Signed-off-by: Ville Syrjälä
> Reviewed-by: Chris Wilson
>
> > drivers/gpu/drm/i915/i915_sysfs.c | 35 ++-
> > 1 file changed, 34 insertions(+), 1 deletion(-)
> >
> > +static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct drm_minor *minor = dev_to_drm_minor(kdev);
> > + struct drm_device *dev = minor->dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + int ret;
> > +
> > + flush_delayed_work(&dev_priv->rps.delayed_resume_work);
>
> Is this required for querying the current value?
>
> Though probably better to keep it similar to the others.
> -Chris
[TOR:] flush_delayed_work is needed to make sure rps.cur_freq
is valid for non VLV/CHV platforms.
Tom O'Rourke
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Add gt_act_freq_mhz sysfs file
On Mon, Jan 26, 2015 at 12:22:07PM -0800, O'Rourke, Tom wrote:
> On Sun, Jan 25, 2015 at 09:34:33AM +, Chris Wilson wrote:
> > On Fri, Jan 23, 2015 at 09:04:24PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Currently the 'gt_cur_freq_mhz' file shows the actual GPU frequency on
> > > VLV/CHV, and the last requested frequency on other platforms. Change the
> > > meaning of the file on VLV/CHV to follow the the other platforms, and
> > > introduce a new file 'gt_act_freq_mhz' which shows the actual frequency
> > > on all platforms.
> > >
> > > Signed-off-by: Ville Syrjälä
> > Reviewed-by: Chris Wilson
> >
> > > drivers/gpu/drm/i915/i915_sysfs.c | 35
> > > ++-
> > > 1 file changed, 34 insertions(+), 1 deletion(-)
> > >
> > > +static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> > > + struct device_attribute *attr, char *buf)
> > > +{
> > > + struct drm_minor *minor = dev_to_drm_minor(kdev);
> > > + struct drm_device *dev = minor->dev;
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > + int ret;
> > > +
> > > + flush_delayed_work(&dev_priv->rps.delayed_resume_work);
> >
> > Is this required for querying the current value?
> >
> > Though probably better to keep it similar to the others.
> > -Chris
>
> [TOR:] flush_delayed_work is needed to make sure rps.cur_freq
> is valid for non VLV/CHV platforms.
It is reporting the actual hw frequency. I still fail to see how
flushing the pending work is important for reporting that instantaneous
value.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop pipe_enable checks in vblank funcs
Hi Daniel,
Thank you for the patch.
On Monday 26 January 2015 07:41:59 Daniel Vetter wrote:
> With Ville's rework to use drm_crtc_vblank_on/off the core will take
> care of rejecting drm_vblank_get calls when the pipe is off.
After debugging a related issue in the omapdrm driver I think this is only
partially true. drm_vblank_off() will increase the vblank refcount, resulting
in drm_vblank_get() returning an error instead of calling the driver's
.enable_vblank operation. However, this only works if drm_vblank_off() has
been called, not when the pipe is off because it hasn't been turned on yet.
Consider this case. The driver has just been loaded, all pipes are off. An
application opens the DRM device node and closes it without enabling the pipe.
The lastclose operation will be called, and it will call
drm_fb_helper_restore_fbdev_mode_unlocked() to restore the CRTC. This triggers
the timeout warning in drm_wait_one_vblank with omapdrm when using the atomic
update transitional helpers. The callstack is as follows.
[] (drm_wait_one_vblank [drm])
[] (drm_plane_helper_commit [drm_kms_helper])
[] (drm_crtc_helper_set_mode [drm_kms_helper])
[] (drm_crtc_helper_set_config [drm_kms_helper])
[] (drm_mode_set_config_internal [drm])
[] (restore_fbdev_mode [drm_kms_helper])
[] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper])
[] (dev_lastclose [omapdrm])
[] (drm_lastclose [drm])
[] (drm_release [drm])
[] (__fput)
[] (task_work_run)
[] (do_work_pending)
The drm_crtc_vblank_get() call in drm_plane_helper_commit() will not return an
error as drm_vblank_off() has never been called so far.
The exact same issue obviously doesn't affect the i915 driver as it doesn't
use the transitional helpers, but a different issue could be present with the
same root cause.
Where do you think this should be fixed ?
> Also the core won't call the get_vblank_counter hooks in that case either.
> And since we've dropped ums support recently we can now remove these
> hacks, yay!
>
> Noticed while trying to answer questions Laurent had about how the new
> atomic helpers work.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq.c | 52 --
> 1 file changed, 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c index 2399eaed2ca3..4761f7fe6fb1 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -492,31 +492,6 @@ static void i915_enable_asle_pipestat(struct drm_device
> *dev) spin_unlock_irq(&dev_priv->irq_lock);
> }
>
> -/**
> - * i915_pipe_enabled - check if a pipe is enabled
> - * @dev: DRM device
> - * @pipe: pipe to check
> - *
> - * Reading certain registers when the pipe is disabled can hang the chip.
> - * Use this routine to make sure the PLL is running and the pipe is active
> - * before reading such registers if unsure.
> - */
> -static int
> -i915_pipe_enabled(struct drm_device *dev, int pipe)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> - /* Locking is horribly broken here, but whatever. */
> - struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> -
> - return intel_crtc->active;
> - } else {
> - return I915_READ(PIPECONF(pipe)) & PIPECONF_ENABLE;
> - }
> -}
> -
> /*
> * This timing diagram depicts the video signal in and
> * around the vertical blanking period.
> @@ -583,12 +558,6 @@ static u32 i915_get_vblank_counter(struct drm_device
> *dev, int pipe) unsigned long low_frame;
> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
>
> - if (!i915_pipe_enabled(dev, pipe)) {
> - DRM_DEBUG_DRIVER("trying to get vblank count for disabled "
> - "pipe %c\n", pipe_name(pipe));
> - return 0;
> - }
> -
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> struct intel_crtc *intel_crtc =
> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> @@ -648,12 +617,6 @@ static u32 gm45_get_vblank_counter(struct drm_device
> *dev, int pipe) struct drm_i915_private *dev_priv = dev->dev_private;
> int reg = PIPE_FRMCOUNT_GM45(pipe);
>
> - if (!i915_pipe_enabled(dev, pipe)) {
> - DRM_DEBUG_DRIVER("trying to get vblank count for disabled "
> - "pipe %c\n", pipe_name(pipe));
> - return 0;
> - }
> -
> return I915_READ(reg);
> }
>
> @@ -2660,9 +2623,6 @@ static int i915_enable_vblank(struct drm_device *dev,
> int pipe) struct drm_i915_private *dev_priv = dev->dev_private;
> unsigned long irqflags;
>
> - if (!i915_pipe_enabled(dev, pipe))
> - return -EINVAL;
> -
> spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
>
Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges
On 23 January 2015 at 18:05, Thierry Reding wrote: > From: Thierry Reding > > The current implementation is limited by the number of addresses that > fit into an unsigned long. This causes problems on 32-bit Tegra where > unsigned long is 32-bit but drm_mm is used to manage an IOVA space of > 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 > (or 4 GiB - 4 KiB for page granularity). > > This commit changes the start and size of the range to be an unsigned > 64-bit integer, thus allowing much larger ranges to be supported. This seems fine to me, Chris, Daniel or Thomas, any objections? Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges
On Fri, Jan 23, 2015 at 3:05 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> The current implementation is limited by the number of addresses that
> fit into an unsigned long. This causes problems on 32-bit Tegra where
> unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
> 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
> (or 4 GiB - 4 KiB for page granularity).
>
> This commit changes the start and size of the range to be an unsigned
> 64-bit integer, thus allowing much larger ranges to be supported.
>
> Signed-off-by: Thierry Reding
Looks reasonable to me:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_mm.c | 152
> ---
> include/drm/drm_mm.h | 52
> 2 files changed, 105 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 04a209e2b66d..7fc6f8bd4821 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -91,29 +91,29 @@
> */
>
> static struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm
> *mm,
> - unsigned long size,
> + u64 size,
> unsigned alignment,
> unsigned long color,
> enum drm_mm_search_flags
> flags);
> static struct drm_mm_node *drm_mm_search_free_in_range_generic(const struct
> drm_mm *mm,
> - unsigned long size,
> + u64 size,
> unsigned alignment,
> unsigned long color,
> - unsigned long start,
> - unsigned long end,
> + u64 start,
> + u64 end,
> enum drm_mm_search_flags
> flags);
>
> static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
> struct drm_mm_node *node,
> -unsigned long size, unsigned alignment,
> +u64 size, unsigned alignment,
> unsigned long color,
> enum drm_mm_allocator_flags flags)
> {
> struct drm_mm *mm = hole_node->mm;
> - unsigned long hole_start = drm_mm_hole_node_start(hole_node);
> - unsigned long hole_end = drm_mm_hole_node_end(hole_node);
> - unsigned long adj_start = hole_start;
> - unsigned long adj_end = hole_end;
> + u64 hole_start = drm_mm_hole_node_start(hole_node);
> + u64 hole_end = drm_mm_hole_node_end(hole_node);
> + u64 adj_start = hole_start;
> + u64 adj_end = hole_end;
>
> BUG_ON(node->allocated);
>
> @@ -124,12 +124,15 @@ static void drm_mm_insert_helper(struct drm_mm_node
> *hole_node,
> adj_start = adj_end - size;
>
> if (alignment) {
> - unsigned tmp = adj_start % alignment;
> - if (tmp) {
> + u64 tmp = adj_start;
> + unsigned rem;
> +
> + rem = do_div(tmp, alignment);
> + if (rem) {
> if (flags & DRM_MM_CREATE_TOP)
> - adj_start -= tmp;
> + adj_start -= rem;
> else
> - adj_start += alignment - tmp;
> + adj_start += alignment - rem;
> }
> }
>
> @@ -176,9 +179,9 @@ static void drm_mm_insert_helper(struct drm_mm_node
> *hole_node,
> int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
> {
> struct drm_mm_node *hole;
> - unsigned long end = node->start + node->size;
> - unsigned long hole_start;
> - unsigned long hole_end;
> + u64 end = node->start + node->size;
> + u64 hole_start;
> + u64 hole_end;
>
> BUG_ON(node == NULL);
>
> @@ -227,7 +230,7 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
> * 0 on success, -ENOSPC if there's no suitable hole.
> */
> int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
> - unsigned long size, unsigned alignment,
> + u64 size, unsigned alignment,
>unsigned long color,
>enum drm_mm_search_flags sflags,
>enum drm_mm_allocator_flags aflags)
> @@ -246,16 +249,16 @@ EXPORT_SYMBOL(drm_mm_insert_node_generic);
>
> static void drm_mm_insert_helper_range(struct drm_mm_node *hole_node,
>
Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges
On 01/26/2015 11:51 PM, Dave Airlie wrote: > On 23 January 2015 at 18:05, Thierry Reding wrote: >> From: Thierry Reding >> >> The current implementation is limited by the number of addresses that >> fit into an unsigned long. This causes problems on 32-bit Tegra where >> unsigned long is 32-bit but drm_mm is used to manage an IOVA space of >> 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 >> (or 4 GiB - 4 KiB for page granularity). >> >> This commit changes the start and size of the range to be an unsigned >> 64-bit integer, thus allowing much larger ranges to be supported. > This seems fine to me, Chris, Daniel or Thomas, any objections? > > Dave. This is perfectly fine with me, although I'm a bit curious why the allocation granularity of the IOVA space needs to be 1 byte? Thanks, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment
On Mon, 26 Jan 2015, Kumar Amit Mehta wrote: > The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent > with the code and the rest of the comment for this routine. This patch > fixes this typo in comment. > > Signed-off-by: Kumar Amit Mehta Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c > b/drivers/gpu/drm/i915/intel_fifo_underrun.c > index 77af512..04e248d 100644 > --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c > +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c > @@ -341,7 +341,7 @@ bool intel_set_pch_fifo_underrun_reporting(struct > drm_i915_private *dev_priv, > } > > /** > - * intel_pch_fifo_underrun_irq_handler - handle PCH fifo underrun interrupt > + * intel_cpu_fifo_underrun_irq_handler - handle CPU fifo underrun interrupt > * @dev_priv: i915 device instance > * @pipe: (CPU) pipe to set state for > * > -- > 2.1.0 > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
