Re: [Intel-gfx] [PATCH] tests: ddx_intel_after_fbdev loads intel ddx after fbdev was loaded.
On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
I'm confused what exactly this tests, since it seems to never fail ...
automated tests should have some checks for expected results.
Also I'm not sure whether we want such ddx/X tests in igt ...
-Daniel
---
tests/Makefile.am | 1 +
tests/ddx_intel_after_fbdev | 73
+
2 files changed, 74 insertions(+)
create mode 100755 tests/ddx_intel_after_fbdev
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 9e46cac..cce75ee 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -127,6 +127,7 @@ TESTS_scripts = \
sysfs_l3_parity \
test_rte_check \
tools_test \
+ ddx_intel_after_fbdev \
ZZ_hangman \
$(NULL)
diff --git a/tests/ddx_intel_after_fbdev b/tests/ddx_intel_after_fbdev
new file mode 100755
index 000..bcd2c29
--- /dev/null
+++ b/tests/ddx_intel_after_fbdev
@@ -0,0 +1,73 @@
+#!/bin/bash
+#
+# Testcase: Load Intel DDX after fbdev was loaded
+#
+
+whoami | grep -q root || {
+ echo ERROR: not running as root
+ exit 1
+}
+
+# no other X session should be running
+find /tmp/ -name .X*lock 2/dev/null | grep -q X {
+ echo ERROR: X session already running
+ exit 1
+}
+
+TMPDIR=$(mktemp -d /tmp/igt.) || {
+ echo ERROR: Failed to create temp dir
+ exit 1
+}
+
+cat $TMPDIR/xorg.conf.fbdev EOF
+Section Device
+ Driver fbdev
+ Identifier Device[fbdev]
+EndSection
+EOF
+
+cat $TMPDIR/xorg.conf.intel EOF
+Section Device
+ Driver intel
+ Identifier Device[intel]
+EndSection
+EOF
+
+# log before fbdev
+dmesg -c $TMPDIR/dmesg.1.before.fbdev
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.1.before.fbdev
+
+# run fbdev
+xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.fbdev
+sleep 5
+if [ -f `which intel_reg_dumper` ]; then
+`which intel_reg_dumper` $TMPDIR/intel_reg_dumped.1.fbdev
+fi
+killall X
+
+# log after fbdev before intel
+dmesg -c $TMPDIR/dmesg.2.after.fbdev.before.intel
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.2.after.fbdev.before.intel
+
+sleep 5
+
+# run intel
+xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.intel
+sleep 5
+if [ -f `which intel_reg_dumper` ]; then
+`which intel_reg_dumper` $TMPDIR/intel_reg_dumped.2.intel
+fi
+killall X
+
+# log after intel
+dmesg -c $TMPDIR/dmesg.3.after.intel
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.3.after.intel
+
+cp $0 $TMPDIR/
+
+tar czf $TMPDIR.tar.gz $TMPDIR/*
+if [ -f $TMPDIR.tar.gz ]; then
+ echo $TMPDIR.tar.gz contains this script, all configs and logs
generated on this tests
+fi
+
+exit 0
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests: ddx_intel_after_fbdev loads intel ddx after fbdev was loaded.
On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Aug 21, 2013 at 11:00:53AM +0200, Daniel Vetter wrote: On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote: Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com I'm confused what exactly this tests, since it seems to never fail ... automated tests should have some checks for expected results. Also I'm not sure whether we want such ddx/X tests in igt ... Whether or not it makes a good test, it is nice to have a repository of the little hacks we use for debugging. From little acorns mighty oaks grow. Agreed, but then it imo shouldn't be added to the default list of targets of tests to run. We already have a bunch of these scripts added to EXTRA_DIST, I guess adding a new variable SCRIPTS would be good. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests: ddx_intel_after_fbdev loads intel ddx after fbdev was loaded.
On Wed, Aug 21, 2013 at 6:27 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Aug 21, 2013 at 11:00:53AM +0200, Daniel Vetter wrote: On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote: Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com I'm confused what exactly this tests, since it seems to never fail ... fb.o #68030 automated tests should have some checks for expected results. Also I'm not sure whether we want such ddx/X tests in igt ... actually it was your idea and I liked it ;) Whether or not it makes a good test, it is nice to have a repository of the little hacks we use for debugging. From little acorns mighty oaks grow. Agreed, but then it imo shouldn't be added to the default list of targets of tests to run. Agreed. tbh I didn't realized I was doing that by adding it to TESTS_scripts We already have a bunch of these scripts added to EXTRA_DIST, I guess adding a new variable SCRIPTS would be good. Do you think we need an extra directory for scripts like this? or just create this new SCRIPTS variable at Makefile.am? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
Re: [Intel-gfx] [PATCH] tests: ddx_intel_after_fbdev loads intel ddx after fbdev was loaded.
On Wed, Aug 21, 2013 at 1:55 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: On Wed, Aug 21, 2013 at 6:27 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Aug 21, 2013 at 11:00:53AM +0200, Daniel Vetter wrote: On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote: Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com I'm confused what exactly this tests, since it seems to never fail ... fb.o #68030 automated tests should have some checks for expected results. Also I'm not sure whether we want such ddx/X tests in igt ... actually it was your idea and I liked it ;) Ah, what I meant was a reduced testcase to replay just the special modesetting sequence to reproduce the bug. Similar to what Imre recently has done with the kms_setmode.c testcase. If we add the entire script we essentially depend upon fbdev and our own ddx to not change behaviour ... Whether or not it makes a good test, it is nice to have a repository of the little hacks we use for debugging. From little acorns mighty oaks grow. Agreed, but then it imo shouldn't be added to the default list of targets of tests to run. Agreed. tbh I didn't realized I was doing that by adding it to TESTS_scripts We already have a bunch of these scripts added to EXTRA_DIST, I guess adding a new variable SCRIPTS would be good. Do you think we need an extra directory for scripts like this? or just create this new SCRIPTS variable at Makefile.am? Since it's essentially a special testcase script I think tests/ is good enough. Something like the below diff: Cheers, Daniel diff --git a/tests/Makefile.am b/tests/Makefile.am index ddb709f..805d90f 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -170,8 +170,14 @@ HANG = \ gem_non_secure_batch \ $(NULL) +scripts = \ + check_drm_clients \ + debugfs_wedged\ + drm_lib.sh \ + $(NULL) + EXTRA_PROGRAMS = $(TESTS_progs) $(TESTS_progs_M) $(HANG) -EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) drm_lib.sh check_drm_clients debugfs_wedged +EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) $(scripts) CLEANFILES = $(EXTRA_PROGRAMS) AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) \ -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests: ddx_intel_after_fbdev loads intel ddx after fbdev was loaded.
On Wed, Aug 21, 2013 at 9:03 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 1:55 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: On Wed, Aug 21, 2013 at 6:27 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Aug 21, 2013 at 11:00:53AM +0200, Daniel Vetter wrote: On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote: Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com I'm confused what exactly this tests, since it seems to never fail ... fb.o #68030 automated tests should have some checks for expected results. Also I'm not sure whether we want such ddx/X tests in igt ... actually it was your idea and I liked it ;) Ah, what I meant was a reduced testcase to replay just the special modesetting sequence to reproduce the bug. Similar to what Imre recently has done with the kms_setmode.c testcase. If we add the entire script we essentially depend upon fbdev and our own ddx to not change behaviour ... got your idea now... I had misunderstood... mainly because what is in my mind is the remaining blank screen in my suse case... chris patch apparently fixed the modesetting sequence and the remaining blank screen is still mysterious. Whether or not it makes a good test, it is nice to have a repository of the little hacks we use for debugging. From little acorns mighty oaks grow. Agreed, but then it imo shouldn't be added to the default list of targets of tests to run. Agreed. tbh I didn't realized I was doing that by adding it to TESTS_scripts We already have a bunch of these scripts added to EXTRA_DIST, I guess adding a new variable SCRIPTS would be good. Do you think we need an extra directory for scripts like this? or just create this new SCRIPTS variable at Makefile.am? Since it's essentially a special testcase script I think tests/ is good enough. Something like the below diff: Cheers, Daniel diff --git a/tests/Makefile.am b/tests/Makefile.am index ddb709f..805d90f 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -170,8 +170,14 @@ HANG = \ gem_non_secure_batch \ $(NULL) +scripts = \ + check_drm_clients \ + debugfs_wedged\ + drm_lib.sh \ + $(NULL) + EXTRA_PROGRAMS = $(TESTS_progs) $(TESTS_progs_M) $(HANG) -EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) drm_lib.sh check_drm_clients debugfs_wedged +EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) $(scripts) CLEANFILES = $(EXTRA_PROGRAMS) AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) \ -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
Re: [Intel-gfx] [PATCH] RFC drm/i915: Expose a PMU interface for perf queries
On Tue, Aug 20, 2013 at 10:17 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: The first goal is to be able to measure GPU (and invidual ring) busyness without having to poll registers from userspace. (Which not only incurs holding the forcewake lock indefinitely, perturbing the system, but also runs the risk of hanging the machine.) As an alternative we can use the perf event counter interface to sample the ring registers periodically and send those results to userspace. To be able to do so, we need to export the two symbols from kernel/events/core.c to register and unregister a PMU device. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Make sense imo to move the perf gathering into the kernel, a few random (and rather uninformed) points I've thought of: - What about the instdone busy bits intel_gpu_top currently presents? - Shouldn't we have one polling hrtimer that checks all enabled pmu event bits? - Plans for integrating the various status/debug bits in the display block (like fetches, fbc compression stuff, ...)? I know that this will tickle the all-encompassing paranoia about releasing performance counter details, but we can still hope. Iirc there's also some very minimal perf counter stuff on the GT arbiter. Overall I think this is great and should fill the gap until we're allowed to release some more of the integrated global perf counters (and even then those should neatly fit in ...). For testing I think just running your overlay tool with all possible events should be good enough (in some headless mode ofc) - functional testing of perf counter is imo too much fuss. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prevent loading of uninitialized context garbage
On Thu, Aug 08, 2013 at 08:00:26PM +0100, Chris Wilson wrote:
The extended state bits are stored in the LCA register and affect all
updates to the LCA register - i.e. the state on the old context is saved
when SAVE_EX_STATE_EN is currently set in the old context address before
the update, and the new context is restored when RESTORE_EX_STATE_EN is
set in the new context address. This is irrespective of the
RESTORE_INHIBIT flag in the MI_SET_CONTEXT.
Hence, upon initial loading the contents of the extended state is read
from uninitialised data. To workaround this, on first load we do a dummy
load without the mandatory RESTORE_EX_STATE_EN bit so that the real load
causes us to initialise the extended state of the context before it is
then loaded by the LCA update.
v2: Split out the introduction of the variable length MI_SET_CONTEXT
command sequence.
References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8a7b61e..a57d49a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -367,6 +367,8 @@ mi_set_context(struct intel_ring_buffer *ring,
case 5: len += 2;
break;
}
+ if (!new_context-is_initialized)
+ len += 2;
ret = intel_ring_begin(ring, len);
if (ret)
@@ -382,6 +384,22 @@ mi_set_context(struct intel_ring_buffer *ring,
break;
}
+ if (!new_context-is_initialized) {
+ /* The GPU tries to restore the extended state irrespective
+ * of RestoreInhibit (since it is part of the LCA switch
+ * itself rather than the MI_SET_CONTEXT command).
+ * Since the initial contents may be garbage we do a dummy
+ * load first then set the mandatory flag for any future
+ * ring context switches.
+ */
+ intel_ring_emit(ring, MI_SET_CONTEXT);
+ intel_ring_emit(ring,
+ i915_gem_obj_ggtt_offset(new_context-obj) |
+ MI_MM_SPACE_GTT |
+ MI_SAVE_EXT_STATE_EN |
+ hw_flags);
+ }
Hmm. Couldn't we just do this w/ one MI_SET_CONTEXT? Just drop the
MI_RESTORE_EXT_STATE_EN flag if the context is not initialized. The
MI_SAVE_EXT_STATE_EN will be saved in the CCID, so when we switch to
another context the extended state will be saved. And for the next
switch to this context we will set the MI_RESTORE_EXT_STATE_EN bit
in MI_SET_CONTEXT so it should get restored.
But I must admit BSpec is a bit confusing on the topic. It says the
restore bit affects the switch to the context specified in the
logical context address. I take that to mean that the effect of the
restore bit is immediate. But BSpec also says that the bit is stored in
CCID to control the subsequent switch to the same context. So does that
actually mean that 'effective.restore_ext = CCID.restore_ext |
MI_SET_CONTEXT.restore_ext'?
Oh, but BSpec also says that both bits must be set when RS2 power state
is enabled. I think that's the same as RC6, or is it? So I guess the
hardware might consult these bits when entering/leaving RC6. So I suppose
we really need to make sure both bits are always set in case we hit RC6.
So based on that reasoning the patch would seem correct.
I guess I'll give it an r-b regardless :)
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
+
intel_ring_emit(ring, MI_NOOP);
intel_ring_emit(ring, MI_SET_CONTEXT);
intel_ring_emit(ring, i915_gem_obj_ggtt_offset(new_context-obj) |
--
1.8.4.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 21 [ screen corruption in graphical mode ]
On Wed, Aug 21, 2013 at 12:35:08PM +0200, Sedat Dilek wrote: On Wed, Aug 21, 2013 at 11:21 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, There will be no linux-next trees on Aug 23 or 26. Changes since 20130820: New tree: aio-direct Removed tree: xilinx (at maintainer's request) The xfs tree still had its build failure for which I reverted a commit. The trivial tree gained conflicts against the crypto, net-next and wireless trees. The aio tree gained conflicts against the aio-direct tree. The akpm-current tree gained conflicts against the modules and aio-direct trees. Hi, I still have this issue with next-20130821 and Linux v3.11-rc6 plus drm-intel-nightly on top Any new development on this? Patches? Tbh I'm at a loss what we could try abovebeyond what Chris has already tried out. Currently, I have two workarounds: [1] Revert this commit: commit 5456fe3882812aba251886e36fe55bfefb8e8829 drm/i915: Allocate LLC ringbuffers from stolen Since with a rather decent chance the next testing cycle I'll do this friday will be the last chunk of features for 3.12 I'll probably drop the above patch from my queue and we can try again in 3.13. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: User POSTING_READ and I915_READ_NOTRACE in lcpll code
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.
Similarly for busy loops to wait for a bit to flip we use the _NOTRACE
variant to avoid filling up the tracebuffers with gunk. Spotted while
reading some follow-up patches from Paulo.
While at it add the missing posting read in the lcpll enable function
that Paulo spotted.
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a40427..39b53e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5999,7 +5999,7 @@ void hsw_disable_lcpll(struct drm_i915_private *dev_priv,
I915_WRITE(LCPLL_CTL, val);
POSTING_READ(LCPLL_CTL);
- if (wait_for((I915_READ(LCPLL_CTL) LCPLL_PLL_LOCK) == 0, 1))
+ if (wait_for((I915_READ_NOTRACE(LCPLL_CTL) LCPLL_PLL_LOCK) == 0, 1))
DRM_ERROR(LCPLL still locked\n);
val = I915_READ(D_COMP);
@@ -6008,7 +6008,7 @@ void hsw_disable_lcpll(struct drm_i915_private *dev_priv,
POSTING_READ(D_COMP);
ndelay(100);
- if (wait_for((I915_READ(D_COMP) D_COMP_RCOMP_IN_PROGRESS) == 0, 1))
+ if (wait_for((I915_READ_NOTRACE(D_COMP) D_COMP_RCOMP_IN_PROGRESS) ==
0, 1))
DRM_ERROR(D_COMP RCOMP still in progress\n);
if (allow_power_down) {
@@ -6036,19 +6036,20 @@ void hsw_restore_lcpll(struct drm_i915_private
*dev_priv)
if (val LCPLL_POWER_DOWN_ALLOW) {
val = ~LCPLL_POWER_DOWN_ALLOW;
I915_WRITE(LCPLL_CTL, val);
+ POSTING_READ(LCPLL_CTL);
}
val = I915_READ(D_COMP);
val |= D_COMP_COMP_FORCE;
val = ~D_COMP_COMP_DISABLE;
I915_WRITE(D_COMP, val);
- I915_READ(D_COMP);
+ POSTING_READ(D_COMP);
val = I915_READ(LCPLL_CTL);
val = ~LCPLL_PLL_DISABLE;
I915_WRITE(LCPLL_CTL, val);
- if (wait_for(I915_READ(LCPLL_CTL) LCPLL_PLL_LOCK, 5))
+ if (wait_for(I915_READ_NOTRACE(LCPLL_CTL) LCPLL_PLL_LOCK, 5))
DRM_ERROR(LCPLL not locked yet\n);
if (val LCPLL_CD_SOURCE_FCLK) {
@@ -6056,7 +6057,7 @@ void hsw_restore_lcpll(struct drm_i915_private *dev_priv)
val = ~LCPLL_CD_SOURCE_FCLK;
I915_WRITE(LCPLL_CTL, val);
- if (wait_for_atomic_us((I915_READ(LCPLL_CTL)
+ if (wait_for_atomic_us((I915_READ_NOTRACE(LCPLL_CTL)
LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
DRM_ERROR(Switching back to LCPLL failed\n);
}
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFM drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected.
RFM - request for measurement!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
Cc: Meng, Mengmeng mengmeng.m...@intel.com
Cc: Zhuang, Lena lena.zhu...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 091bb553..8ef3559 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1106,6 +1106,15 @@ static int __wait_seqno(struct intel_ring_buffer *ring,
u32 seqno,
if (WARN_ON(!ring-irq_get(ring)))
return -ENODEV;
+ if (dev_priv-info-gen = 6) {
+ mutex_lock(dev_priv-rps.hw_lock);
+ if (dev_priv-info-is_valleyview)
+ valleyview_set_rps(dev_priv-dev,
dev_priv-rps.max_delay);
+ else
+ gen6_set_rps(dev_priv-dev, dev_priv-rps.max_delay);
+ mutex_unlock(dev_priv-rps.hw_lock);
+ }
+
/* Record current time in case interrupted by signal, or wedged * */
getrawmonotonic(before);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.21.15
Release 2.21.15 (2013-08-21) Some build fixes for the BSDs and alternate compiler, and conflicting configure options and a critcial fix for some PRIME setups. * Don't fail to configure if DRI1 is not available and the user asks for both DRI and KMS-only [Regression from 2.21.14] * Lots of miscellaneous fixes for older gcc, other compilers and BSD. * Initial framework support for hosted X. * Improve transition from fbcon to X with multiple outputs and extended desktops. * Ensure the framebuffer exists before checking it against the CRTC constraints. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/121234 [Regression from 2.21.10] * Add RGB overlay support for Ironlake and later. * Don't release the overlay buffer too early, i.e. before the client disables the Xv image. * Tweak the ring switching logic to reduce use of semaphores on Sandybridge and later - a delicate balancing act between trying to use the faster engine for the task and preventing concurrent use of multiple rings. Complete list of changes since 2.21.14 -- Chris Wilson (50): sna: Define fast function attribute for old gcc or other compilers sna/trapezoids: Some minor DBG to investigate threaded rendering sna: Tweak threading thresholds sna: Rename the attribute macro __packed__ to avoid clang barfing sna: Update experimental create2 struct definition sna: Only use the experimental create2 if we support DISPLAY cacheing as well configure: Include the experimental features in the configuration summary sna/dri: Do not create a scanout-capable buffer if not flipping sna: Avoid leaking stolen framebuffer bo sna: Always reuse scanout bo where possible sna: Use create2 to allocate a DISPLAY bo even if we have not enough stolen configure: Only use XORG_TESTSET_CFLAG if defined sna: Check for EINVAL after mmapping sna: Rewrite the can-mmap-cpu test to handle stolen unclaimed bo intel: Disable incompatible features whilst hosted sna: Squelch a valid mode without a dotclock sna: Allow LLC to reuse any active write buffer sna: Tune pixmap_inplace() not to use a pinned busy GPU bo for replacement sna/glyphs: Micro-optimise glyph drawing sna/glyphs: Micro-optimise glyphs-to-dst sna: Remove the redundant clearing of kgem at startup sna: Avoid confusing conflicting CRTC probes vs a DRM race sna/gen7: Refine ring selection sna: Fix destination offset along memcpy composite fallback fastback sna: Reorder composite fallback migration to handle src==dst || mask==dst configure: Fix reversed check for XORG_TESTSET_CFLAG sna: Fix use of obsolete this_atlas in a DBG message configure: Correct the spelling of XORG_TESTSET_CFLAGS intel: Check for HW_SKIP_CONSOLE before use sna/glyphs: Do not attempt to release the negative cache lookup sna: Fix the assertions for the composite fb path sna: unwrap old modesetting API whilst hosted sna: Check that we successfully install the required hosting midlayer sna: Tile the old image onto the new framebuffer when enlarging sna: Rename sna_pixmap_get_bo() sna: Make sure the frontbuffer exists before doing pitch checks sna: Clip the tiled copy during framebuffer resize uxa: Restore the lost copyright block after splitting i965_reg.h from i915_reg.h sna/video: Don't assert on a client error, return BadAlloc sna/video: Expose an attribute to keep the overlay always on top sna/video: YUV420 is not supported by sprites, replace it with a RGB passthrough sna/video: Mark the sprite color key as changed when disabling sna/video: Keep a ref to the passthrough overlay bo sna: Make sure that external scanouts are immediately discarded sna/video: Turn off passthrough if given a zero name sna/video: Return the planar offset calculations to the planar branch sna/video: Initialise the UV offsets to 0 for packed formats sna: Do not force use of the CPU bo if replacing a busy GPU bo sna/gen6+: Tweak semaphore avoidance for composite operations 2.21.15 release Dave Airlie (1): configure.ac: fix dri enabled with kms only picked Julien Cristau (3): Check for struct sysinfo as well as sys/sysinfo.h configure: use CPPFLAGS for xaa.h check, not CFLAGS Link the driver against pixman Raul Fernandes (1): Micro-optimise box intersections Sedat Dilek (1): Correct misspelled caching git tag: 2.21.15 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.15.tar.bz2 MD5: 8b646d257ace8197d6ab4e5ddeb8efb2 xf86-video-intel-2.21.15.tar.bz2 SHA1: 6952e6e1deff1c4580ddee472dbc2223c3248d0f xf86-video-intel-2.21.15.tar.bz2 SHA256:
[Intel-gfx] [PATCH] drm/i915: drop WaMbcDriverBootEnable workaround
Turns out the BIOS will do this for us as needed, and if we try to do it again we risk hangs or other bad behavior. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_pm.c | 17 - 1 file changed, 17 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 21f4c95..c823861 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4864,10 +4864,6 @@ static void gen6_init_clock_gating(struct drm_device *dev) ILK_DPARBUNIT_CLOCK_GATE_ENABLE | ILK_DPFDUNIT_CLOCK_GATE_ENABLE); - /* WaMbcDriverBootEnable:snb */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | - GEN6_MBCTL_ENABLE_BOOT_FETCH); - g4x_disable_trickle_feed(dev); /* The default value should be 0x200 according to docs, but the two @@ -4963,10 +4959,6 @@ static void haswell_init_clock_gating(struct drm_device *dev) I915_WRITE(CACHE_MODE_1, _MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_DISABLE)); - /* WaMbcDriverBootEnable:hsw */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | - GEN6_MBCTL_ENABLE_BOOT_FETCH); - /* WaSwitchSolVfFArbitrationPriority:hsw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); @@ -5050,10 +5042,6 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) g4x_disable_trickle_feed(dev); - /* WaMbcDriverBootEnable:ivb */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | - GEN6_MBCTL_ENABLE_BOOT_FETCH); - /* WaVSRefCountFullforceMissDisable:ivb */ gen7_setup_fixed_func_scheduler(dev_priv); @@ -5113,11 +5101,6 @@ static void valleyview_init_clock_gating(struct drm_device *dev) I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) | GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB); - /* WaMbcDriverBootEnable:vlv */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | - GEN6_MBCTL_ENABLE_BOOT_FETCH); - - /* According to the BSpec vol1g, bit 12 (RCPBUNIT) clock * gating disable must be set. Failure to set it results in * flickering pixels due to Z write ordering failures after -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] How will Gfx driver support runtime PM on Haswell?
Hi Ben, How will Gfx driver support runtime PM on Haswell? Will the Gfx driver trigger Adapter Power State notification to BIOS when GPU switch state between D0 and D3? We need to support RTD3 for HD-A legacy audio on Haswell Ultrabook. And this depends on Gfx driver to implement two BIOS notifications. Here is the background of this dependency: The target of HD-Audio RTD3 is that BIOS can power off the on-board 3rd party audio codec to save power in S0. This would help to save ~60mW. Please note that audio driver cannot power off the codec, because the codec power is controlled by some GPIO which is board specific. The BIOS will power off the audio codec when three requirements are met: (1) System is running on battery (2) HD-Audio controller is in D3. Means no active audio application is using the audio devices. (3) All displays are off. This means system is in User-Absent Mode, and a long latency for devices to resume back to D0 is allowed, such as ~300ms to power on the audio codec. For the 3rd requirement, BIOS needs Gfx driver to tell whether the system is in user-absent mode. It needs Gfx driver to triger two SCI SW notifications: Display Power State Notification and Adapter Power State Notification. 'Display Power State Notification' was implemented by Jani. But we were told that 'Adapter Power State' notification needs Gfx driver to support runtime PM at first. So would you please share some information about runtime PM support in Gfx driver? Thanks Mengdong ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prevent loading of uninitialized context garbage
On Wed, Aug 21, 2013 at 04:43:33PM +0300, Ville Syrjälä wrote:
On Thu, Aug 08, 2013 at 08:00:26PM +0100, Chris Wilson wrote:
The extended state bits are stored in the LCA register and affect all
updates to the LCA register - i.e. the state on the old context is saved
when SAVE_EX_STATE_EN is currently set in the old context address before
the update, and the new context is restored when RESTORE_EX_STATE_EN is
set in the new context address. This is irrespective of the
RESTORE_INHIBIT flag in the MI_SET_CONTEXT.
Hence, upon initial loading the contents of the extended state is read
from uninitialised data. To workaround this, on first load we do a dummy
load without the mandatory RESTORE_EX_STATE_EN bit so that the real load
causes us to initialise the extended state of the context before it is
then loaded by the LCA update.
v2: Split out the introduction of the variable length MI_SET_CONTEXT
command sequence.
References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8a7b61e..a57d49a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -367,6 +367,8 @@ mi_set_context(struct intel_ring_buffer *ring,
case 5: len += 2;
break;
}
+ if (!new_context-is_initialized)
+ len += 2;
ret = intel_ring_begin(ring, len);
if (ret)
@@ -382,6 +384,22 @@ mi_set_context(struct intel_ring_buffer *ring,
break;
}
+ if (!new_context-is_initialized) {
+ /* The GPU tries to restore the extended state irrespective
+* of RestoreInhibit (since it is part of the LCA switch
+* itself rather than the MI_SET_CONTEXT command).
+* Since the initial contents may be garbage we do a dummy
+* load first then set the mandatory flag for any future
+* ring context switches.
+*/
+ intel_ring_emit(ring, MI_SET_CONTEXT);
+ intel_ring_emit(ring,
+ i915_gem_obj_ggtt_offset(new_context-obj) |
+ MI_MM_SPACE_GTT |
+ MI_SAVE_EXT_STATE_EN |
+ hw_flags);
+ }
Hmm. Couldn't we just do this w/ one MI_SET_CONTEXT? Just drop the
MI_RESTORE_EXT_STATE_EN flag if the context is not initialized. The
MI_SAVE_EXT_STATE_EN will be saved in the CCID, so when we switch to
another context the extended state will be saved. And for the next
switch to this context we will set the MI_RESTORE_EXT_STATE_EN bit
in MI_SET_CONTEXT so it should get restored.
But I must admit BSpec is a bit confusing on the topic. It says the
restore bit affects the switch to the context specified in the
logical context address. I take that to mean that the effect of the
restore bit is immediate. But BSpec also says that the bit is stored in
CCID to control the subsequent switch to the same context. So does that
actually mean that 'effective.restore_ext = CCID.restore_ext |
MI_SET_CONTEXT.restore_ext'?
Oh, but BSpec also says that both bits must be set when RS2 power state
is enabled. I think that's the same as RC6, or is it? So I guess the
hardware might consult these bits when entering/leaving RC6. So I suppose
we really need to make sure both bits are always set in case we hit RC6.
So based on that reasoning the patch would seem correct.
I guess I'll give it an r-b regardless :)
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
I just noticed that on HSW these bits control the resource streamer
state save/restore. The spec says we should always set the RS
restore bit if we set the RS save bit. So maybe we need some
!IS_HASWELL checks in there...
+
intel_ring_emit(ring, MI_NOOP);
intel_ring_emit(ring, MI_SET_CONTEXT);
intel_ring_emit(ring, i915_gem_obj_ggtt_offset(new_context-obj) |
--
1.8.4.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: fix SDEIMR assertion when disabling LCPLL
ok, if we don't care about this hotplug bits state I liked the simplification. Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote: From: Paulo Zanoni paulo.r.zan...@intel.com This was causing WARNs in one machine, so instead of trying to guess exactly which hotplug bits should exist, just do the test on the non-HPD bits. We don't care about the state of the hotplug bits, we just care about the others, that need to be 1. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8c63d8e..b9a4d8b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5930,11 +5930,7 @@ static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv) struct intel_ddi_plls *plls = dev_priv-ddi_plls; struct intel_crtc *crtc; unsigned long irqflags; - uint32_t val, pch_hpd_mask; - - pch_hpd_mask = SDE_PORTB_HOTPLUG_CPT | SDE_PORTC_HOTPLUG_CPT; - if (!(dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)) - pch_hpd_mask |= SDE_PORTD_HOTPLUG_CPT | SDE_CRT_HOTPLUG_CPT; + uint32_t val; list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) WARN(crtc-base.enabled, CRTC for pipe %c enabled\n, @@ -5960,7 +5956,7 @@ static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv) WARN((val ~DE_PCH_EVENT_IVB) != val, Unexpected DEIMR bits enabled: 0x%x\n, val); val = I915_READ(SDEIMR); - WARN((val ~pch_hpd_mask) != val, + WARN((val | SDE_HOTPLUG_MASK_CPT) != 0x, Unexpected SDEIMR bits enabled: 0x%x\n, val); spin_unlock_irqrestore(dev_priv-irq_lock, irqflags); } -- 1.8.1.2 ___ 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
Re: [Intel-gfx] [PATCH 4/6] drm/i915: add i915_pc8_status debugfs file
I haven't reviewed the patches that add pc8 itself, but I can assume
it is correct since it was already rv-b Chris.
So:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Make it print the value of the variables on the PC8 struct.
v2: Update to recent renames and add the new fields.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4785d8c..4d836f1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1769,6 +1769,30 @@ static int i915_edp_psr_status(struct seq_file *m,
void *data)
return 0;
}
+static int i915_pc8_status(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!IS_HASWELL(dev)) {
+ seq_puts(m, not supported\n);
+ return 0;
+ }
+
+ mutex_lock(dev_priv-pc8.lock);
+ seq_printf(m, Requirements met: %s\n,
+ yesno(dev_priv-pc8.requirements_met));
+ seq_printf(m, GPU idle: %s\n, yesno(dev_priv-pc8.gpu_idle));
+ seq_printf(m, Disable count: %d\n, dev_priv-pc8.disable_count);
+ seq_printf(m, IRQs disabled: %s\n,
+ yesno(dev_priv-pc8.irqs_disabled));
+ seq_printf(m, Enabled: %s\n, yesno(dev_priv-pc8.enabled));
+ mutex_unlock(dev_priv-pc8.lock);
+
+ return 0;
+}
+
static int
i915_wedged_get(void *data, u64 *val)
{
@@ -2208,6 +2232,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_dpio, i915_dpio_info, 0},
{i915_llc, i915_llc, 0},
{i915_edp_psr_status, i915_edp_psr_status, 0},
+ {i915_pc8_status, i915_pc8_status, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
--
1.8.1.2
___
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
Re: [Intel-gfx] [PATCH 6/6] drm/i915: enable Package C8+ by default
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote: From: Paulo Zanoni paulo.r.zan...@intel.com This should be working, so enable it by default. Also easy to revert. v2: Rebase, s/allow/enable/. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- 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 ad28a72..735dd56 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -141,9 +141,9 @@ module_param_named(fastboot, i915_fastboot, bool, 0600); MODULE_PARM_DESC(fastboot, Try to skip unnecessary mode sets at boot time (default: false)); -int i915_enable_pc8 __read_mostly = 0; +int i915_enable_pc8 __read_mostly = 1; module_param_named(enable_pc8, i915_enable_pc8, int, 0600); -MODULE_PARM_DESC(enable_pc8, Enable support for low power package C states (PC8+) (default: false)); +MODULE_PARM_DESC(enable_pc8, Enable support for low power package C states (PC8+) (default: true)); int i915_pc8_timeout __read_mostly = 5000; module_param_named(pc8_timeout, i915_pc8_timeout, int, 0600); -- 1.8.1.2 ___ 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
Re: [Intel-gfx] [PATCH 5/6] drm/i915: add i915.pc8_timeout function
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote: From: Paulo Zanoni paulo.r.zan...@intel.com We currently only enter PC8+ after all its required conditions are met, there's no rendering, and we stay like that for at least 5 seconds. I chose 5 seconds because this value is conservative and won't make us enter/leave PC8+ thousands of times after the screen is off: some desktop environments have applications that wake up and do rendering every 1-3 seconds, even when the screen is off and the machine is completely idle. But when I was testing my PC8+ patches I set the default value to 100ms so I could use the bad-behaving desktop environments to stress-test my patches. I also thought it would be a good idea to ask our power management team to test different values, but I'm pretty sure they would ask me for an easy way to change the timeout. So to help these 2 cases I decided to create an option that would make it easier to change the default value. I also expect people making specific products that use our driver could try to find the perfect timeout for them. Anyway, fixing the bad-behaving applications will always lead to better power savings than just changing the timeout value: you need to stop waking the Kernel, not quickly put it back to sleep again after you wake it for nothing. Bad sleep leads to bad mood! Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 4 drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_display.c | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index f197362..ad28a72 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -145,6 +145,10 @@ int i915_enable_pc8 __read_mostly = 0; module_param_named(enable_pc8, i915_enable_pc8, int, 0600); MODULE_PARM_DESC(enable_pc8, Enable support for low power package C states (PC8+) (default: false)); +int i915_pc8_timeout __read_mostly = 5000; +module_param_named(pc8_timeout, i915_pc8_timeout, int, 0600); +MODULE_PARM_DESC(pc8_timeout, Number of msecs of idleness required to enter PC8+ (default: 5000)); + bool i915_prefault_disable __read_mostly; module_param_named(prefault_disable, i915_prefault_disable, bool, 0600); MODULE_PARM_DESC(prefault_disable, diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 34c5af5..3138083 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1710,6 +1710,7 @@ extern int i915_disable_power_well __read_mostly; extern int i915_enable_ips __read_mostly; extern bool i915_fastboot __read_mostly; extern int i915_enable_pc8 __read_mostly; +extern int i915_pc8_timeout __read_mostly; extern bool i915_prefault_disable __read_mostly; extern int i915_suspend(struct drm_device *dev, pm_message_t state); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7d5b01a..ba3bdd5 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6099,7 +6099,7 @@ static void __hsw_enable_package_c8(struct drm_i915_private *dev_priv) return; schedule_delayed_work(dev_priv-pc8.enable_work, - msecs_to_jiffies(5 * 1000)); + msecs_to_jiffies(i915_pc8_timeout)); } static void __hsw_disable_package_c8(struct drm_i915_private *dev_priv) -- 1.8.1.2 ___ 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] [PATCH] drm/i915: Cleaning up the relocate entry function
From: Rafael Barbalho rafael.barba...@intel.com
As the relocate entry function was getting a bit too big I've moved
the code that used to use either the cpu or the gtt to for the
relocation into two separate functions.
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 88 ++
1 file changed, 54 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9b3b5f8..fa82396 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -208,6 +208,56 @@ static inline int use_cpu_reloc(struct drm_i915_gem_object
*obj)
}
static int
+relocate_entry_cpu(struct drm_i915_gem_object *obj,
+ struct drm_i915_gem_relocation_entry *reloc)
+{
+ uint32_t page_offset = offset_in_page(reloc-offset);
+ char *vaddr;
+ int ret = -EINVAL;
+
+ ret = i915_gem_object_set_to_cpu_domain(obj, 1);
+ if (ret)
+ return ret;
+
+ vaddr = kmap_atomic(i915_gem_object_get_page(obj,
+ reloc-offset PAGE_SHIFT));
+ *(uint32_t *)(vaddr + page_offset) = reloc-delta;
+ kunmap_atomic(vaddr);
+
+ return 0;
+}
+
+static int
+relocate_entry_gtt(struct drm_i915_gem_object *obj,
+ struct drm_i915_gem_relocation_entry *reloc)
+{
+ struct drm_device *dev = obj-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t __iomem *reloc_entry;
+ void __iomem *reloc_page;
+ int ret = -EINVAL;
+
+ ret = i915_gem_object_set_to_gtt_domain(obj, true);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_object_put_fence(obj);
+ if (ret)
+ return ret;
+
+ /* Map the page containing the relocation we're going to perform. */
+ reloc-offset += i915_gem_obj_ggtt_offset(obj);
+ reloc_page = io_mapping_map_atomic_wc(dev_priv-gtt.mappable,
+ reloc-offset PAGE_MASK);
+ reloc_entry = (uint32_t __iomem *)
+ (reloc_page + offset_in_page(reloc-offset));
+ iowrite32(reloc-delta, reloc_entry);
+ io_mapping_unmap_atomic(reloc_page);
+
+ return 0;
+}
+
+static int
i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
struct eb_vmas *eb,
struct drm_i915_gem_relocation_entry *reloc,
@@ -293,40 +343,10 @@ i915_gem_execbuffer_relocate_entry(struct
drm_i915_gem_object *obj,
return -EFAULT;
reloc-delta += target_offset;
- if (use_cpu_reloc(obj)) {
- uint32_t page_offset = offset_in_page(reloc-offset);
- char *vaddr;
-
- ret = i915_gem_object_set_to_cpu_domain(obj, 1);
- if (ret)
- return ret;
-
- vaddr = kmap_atomic(i915_gem_object_get_page(obj,
-reloc-offset
PAGE_SHIFT));
- *(uint32_t *)(vaddr + page_offset) = reloc-delta;
- kunmap_atomic(vaddr);
- } else {
- struct drm_i915_private *dev_priv = dev-dev_private;
- uint32_t __iomem *reloc_entry;
- void __iomem *reloc_page;
-
- ret = i915_gem_object_set_to_gtt_domain(obj, true);
- if (ret)
- return ret;
-
- ret = i915_gem_object_put_fence(obj);
- if (ret)
- return ret;
-
- /* Map the page containing the relocation we're going to
perform. */
- reloc-offset += i915_gem_obj_ggtt_offset(obj);
- reloc_page = io_mapping_map_atomic_wc(dev_priv-gtt.mappable,
- reloc-offset
PAGE_MASK);
- reloc_entry = (uint32_t __iomem *)
- (reloc_page + offset_in_page(reloc-offset));
- iowrite32(reloc-delta, reloc_entry);
- io_mapping_unmap_atomic(reloc_page);
- }
+ if (use_cpu_reloc(obj))
+ ret = relocate_entry_cpu(obj, reloc);
+ else
+ ret = relocate_entry_gtt(obj, reloc);
/* and update the user's relocation entry */
reloc-presumed_offset = target_offset;
--
1.8.3.4
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing
[Intel-gfx] [PATCH] RFM drm/i915: Downclock when idle idle-decay
This is the missing component for the last past that provides the
wait-boost. After boosting the RPS frequency of the GPU, it would not
decay, leaving the GPU at high clocks whenever it woke from idle. If we
apply the Valleyview logic of resetting our request to the optimal
frequency when we detect the GPU is idle, we recovered the automatic
regulating behaviour.
This patch removes the dedicated timer for Valleyview downclocking, and
moves the logic into intel_mark_idle(), taking care that we trigger the
downclock shortly after the earliest point we notice the GPU is idle.
RFM - request for measurement!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
Cc: Meng, Mengmeng mengmeng.m...@intel.com
Cc: Zhuang, Lena lena.zhu...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 +---
drivers/gpu/drm/i915/i915_gem.c | 20 +++-
drivers/gpu/drm/i915/i915_irq.c | 11 -
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 46 +---
6 files changed, 41 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0506b93..43577f3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -832,9 +832,6 @@ struct intel_gen6_power_mgmt {
struct work_struct work;
u32 pm_iir;
- /* On vlv we need to manually drop to Vmin with a delayed work. */
- struct delayed_work vlv_work;
-
/* The below variables an all the rps hw state are protected by
* dev-struct mutext. */
u8 cur_delay;
@@ -842,6 +839,7 @@ struct intel_gen6_power_mgmt {
u8 max_delay;
u8 rpe_delay;
u8 rp1_delay;
+ u8 rp0_delay;
u8 hw_max;
struct delayed_work delayed_resume_work;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ef3559..e4c6d67 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2476,10 +2476,18 @@ i915_gem_retire_requests(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring;
+ bool idle = true;
int i;
- for_each_ring(ring, dev_priv, i)
+ for_each_ring(ring, dev_priv, i) {
i915_gem_retire_requests_ring(ring);
+ idle = list_empty(ring-request_list);
+ }
+
+ if (idle)
+ queue_delayed_work(dev_priv-wq,
+ dev_priv-mm.retire_work,
+ msecs_to_jiffies(100));
}
static void
@@ -2502,13 +2510,13 @@ i915_gem_retire_work_handler(struct work_struct *work)
return;
}
- i915_gem_retire_requests(dev);
-
- /* Send a periodic flush down the ring so we don't hold onto GEM
-* objects indefinitely.
-*/
idle = true;
for_each_ring(ring, dev_priv, i) {
+ i915_gem_retire_requests_ring(ring);
+
+ /* Send a periodic flush down the ring so we don't hold
+* onto GEM objects indefinitely.
+*/
if (ring-gpu_caches_dirty)
i915_add_request(ring, NULL);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d4f8f65..4aa421e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -836,17 +836,6 @@ static void gen6_pm_rps_work(struct work_struct *work)
else
gen6_set_rps(dev_priv-dev, new_delay);
- if (IS_VALLEYVIEW(dev_priv-dev)) {
- /*
-* On VLV, when we enter RC6 we may not be at the minimum
-* voltage level, so arm a timer to check. It should only
-* fire when there's activity or once after we've entered
-* RC6, and then won't be re-armed until the next RPS interrupt.
-*/
- mod_delayed_work(dev_priv-wq, dev_priv-rps.vlv_work,
-msecs_to_jiffies(100));
- }
-
mutex_unlock(dev_priv-rps.hw_lock);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c6c19e1..d21d6c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7326,6 +7326,8 @@ void intel_mark_idle(struct drm_device *dev)
intel_decrease_pllclock(crtc);
}
+
+ gen6_rps_idle(dev-dev_private);
}
void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8222f24..482c30b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -785,4 +785,6 @@ extern void
Re: [Intel-gfx] [PATCH 09/12] drm/edid: Move HDMI_IDENTIFIER to hdmi.h
On Mon, Aug 19, 2013 at 09:31:42PM +0200, Thierry Reding wrote: On Mon, Aug 19, 2013 at 02:49:50PM +0100, Damien Lespiau wrote: On Thu, Aug 15, 2013 at 05:12:00PM +0200, Thierry Reding wrote: On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote: [...] +#define HDMI_IDENTIFIER 0x000c03 HDMI_IDENTIFIER sounds really generic. Perhaps HDMI_INFOFRAME_OUI_HDMI? This identifier is not infoframe specific, it's the IEEE OUI: http://standards.ieee.org/develop/regauth/oui/oui.txt would HDMI_IEEE_OUI suit you? Yes, that sounds much better. Or perhaps IEEE_OUI_HDMI? From a quick grep through the kernel code using the OUI as a prefix seems to be slightly more common. If we ever end up adding a header to collect OUIs it'd be useful to namespace them somehow. Hopefully we can agree that HDMI_IEEE_OUI is fine :) Would you mind having a look at the two patches introduced to address your comments HDMI 4k support v4 http://lists.freedesktop.org/archives/dri-devel/2013-August/043988.html Patches 11 and 14. Thanks, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFM drm/i915: Downclock when idle idle-decay
This is the missing component for the last past that provides the
wait-boost. After boosting the RPS frequency of the GPU, it would not
decay, leaving the GPU at high clocks whenever it woke from idle. If we
apply the Valleyview logic of resetting our request to the optimal
frequency when we detect the GPU is idle, we recovered the automatic
regulating behaviour.
This patch removes the dedicated timer for Valleyview downclocking, and
moves the logic into intel_mark_idle(), taking care that we trigger the
downclock shortly after the earliest point we notice the GPU is idle.
v2: Move the idle work handler back to its own delayed timer. The goal
is not to downclock too early, so we use mod_timer to keep the upclock
alive whilst requests are still being queued and retired.
This results in less aggressive downclocking, but equally doesn't
compromise peak performance.
RFM - request for measurement!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
Cc: Meng, Mengmeng mengmeng.m...@intel.com
Cc: Zhuang, Lena lena.zhu...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 15 ++---
drivers/gpu/drm/i915/i915_gem.c | 65 ++--
drivers/gpu/drm/i915/i915_irq.c | 11 --
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 46 -
6 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0506b93..e1d41ae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -832,9 +832,6 @@ struct intel_gen6_power_mgmt {
struct work_struct work;
u32 pm_iir;
- /* On vlv we need to manually drop to Vmin with a delayed work. */
- struct delayed_work vlv_work;
-
/* The below variables an all the rps hw state are protected by
* dev-struct mutext. */
u8 cur_delay;
@@ -842,6 +839,7 @@ struct intel_gen6_power_mgmt {
u8 max_delay;
u8 rpe_delay;
u8 rp1_delay;
+ u8 rp0_delay;
u8 hw_max;
struct delayed_work delayed_resume_work;
@@ -951,6 +949,15 @@ struct i915_gem_mm {
struct delayed_work retire_work;
/**
+* When we detect an idle GPU, we want to turn on
+* powersaving features. So once we see that there
+* are no more requests outstanding and no more
+* arrive within a small period of time, we fire
+* off the idle_work.
+*/
+ struct delayed_work idle_work;
+
+ /**
* Are we in a non-interruptible section of code like
* modesetting?
*/
@@ -1852,7 +1859,7 @@ i915_gem_object_unpin_fence(struct drm_i915_gem_object
*obj)
}
}
-void i915_gem_retire_requests(struct drm_device *dev);
+bool i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_requests_ring(struct intel_ring_buffer *ring);
int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ef3559..5ceb204 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2201,6 +2201,7 @@ int __i915_add_request(struct intel_ring_buffer *ring,
i915_queue_hangcheck(ring-dev);
if (was_empty) {
+ cancel_delayed_work_sync(dev_priv-mm.idle_work);
queue_delayed_work(dev_priv-wq,
dev_priv-mm.retire_work,
round_jiffies_up_relative(HZ));
@@ -2471,57 +2472,54 @@ i915_gem_retire_requests_ring(struct intel_ring_buffer
*ring)
WARN_ON(i915_verify_lists(ring-dev));
}
-void
+bool
i915_gem_retire_requests(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring;
+ bool idle = true;
int i;
- for_each_ring(ring, dev_priv, i)
+ for_each_ring(ring, dev_priv, i) {
i915_gem_retire_requests_ring(ring);
+ idle = list_empty(ring-request_list);
+ }
+
+ if (idle)
+ mod_delayed_work(dev_priv-wq,
+ dev_priv-mm.idle_work,
+ msecs_to_jiffies(100));
+
+ return idle;
}
static void
i915_gem_retire_work_handler(struct work_struct *work)
{
- drm_i915_private_t *dev_priv;
- struct drm_device *dev;
- struct intel_ring_buffer *ring;
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv), mm.retire_work.work);
+ struct drm_device *dev = dev_priv-dev;
bool idle;
- int i;
-
- dev_priv =
Re: [Intel-gfx] linux-next: Tree for Aug 21 [ screen corruption in graphical mode ]
On Wed, Aug 21, 2013 at 3:44 PM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 12:35:08PM +0200, Sedat Dilek wrote: On Wed, Aug 21, 2013 at 11:21 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, There will be no linux-next trees on Aug 23 or 26. Changes since 20130820: New tree: aio-direct Removed tree: xilinx (at maintainer's request) The xfs tree still had its build failure for which I reverted a commit. The trivial tree gained conflicts against the crypto, net-next and wireless trees. The aio tree gained conflicts against the aio-direct tree. The akpm-current tree gained conflicts against the modules and aio-direct trees. Hi, I still have this issue with next-20130821 and Linux v3.11-rc6 plus drm-intel-nightly on top Any new development on this? Patches? Tbh I'm at a loss what we could try abovebeyond what Chris has already tried out. Currently, I have two workarounds: [1] Revert this commit: commit 5456fe3882812aba251886e36fe55bfefb8e8829 drm/i915: Allocate LLC ringbuffers from stolen Since with a rather decent chance the next testing cycle I'll do this friday will be the last chunk of features for 3.12 I'll probably drop the above patch from my queue and we can try again in 3.13. Inspired by [1] I have switched from UXA to SNA... ...and applied [PATCH] drm/i915: Cleaning up the relocate entry function on top of next-20130821... ...and can NOT see the screen corruptions anymore. Can you explain that? - Sedat - [1] http://cynic.cc/blog//posts/sna_acceleration_vs_uxa/ [2] http://lists.freedesktop.org/archives/intel-gfx/2013-August/032182.html [3] https://patchwork.kernel.org/patch/2847846/ xorg.conf Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests: ddx_intel_after_fbdev loads intel ddx after fbdev was loaded.
v2: Don't add to kernel tests.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
tests/Makefile.am | 9 +-
tests/ddx_intel_after_fbdev | 73 +
2 files changed, 81 insertions(+), 1 deletion(-)
create mode 100755 tests/ddx_intel_after_fbdev
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 9e46cac..935495e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -169,8 +169,15 @@ HANG = \
gem_non_secure_batch \
$(NULL)
+scripts = \
+ check_drm_clients \
+ ddx_intel_after_fbdev \
+ debugfs_wedged \
+ drm_lib.sh \
+ $(NULL)
+
EXTRA_PROGRAMS = $(TESTS_progs) $(TESTS_progs_M) $(HANG)
-EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) drm_lib.sh check_drm_clients
debugfs_wedged
+EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) $(scripts)
CLEANFILES = $(EXTRA_PROGRAMS)
AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) \
diff --git a/tests/ddx_intel_after_fbdev b/tests/ddx_intel_after_fbdev
new file mode 100755
index 000..bcd2c29
--- /dev/null
+++ b/tests/ddx_intel_after_fbdev
@@ -0,0 +1,73 @@
+#!/bin/bash
+#
+# Testcase: Load Intel DDX after fbdev was loaded
+#
+
+whoami | grep -q root || {
+ echo ERROR: not running as root
+ exit 1
+}
+
+# no other X session should be running
+find /tmp/ -name .X*lock 2/dev/null | grep -q X {
+ echo ERROR: X session already running
+ exit 1
+}
+
+TMPDIR=$(mktemp -d /tmp/igt.) || {
+ echo ERROR: Failed to create temp dir
+ exit 1
+}
+
+cat $TMPDIR/xorg.conf.fbdev EOF
+Section Device
+ Driver fbdev
+ Identifier Device[fbdev]
+EndSection
+EOF
+
+cat $TMPDIR/xorg.conf.intel EOF
+Section Device
+ Driver intel
+ Identifier Device[intel]
+EndSection
+EOF
+
+# log before fbdev
+dmesg -c $TMPDIR/dmesg.1.before.fbdev
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.1.before.fbdev
+
+# run fbdev
+xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.fbdev
+sleep 5
+if [ -f `which intel_reg_dumper` ]; then
+`which intel_reg_dumper` $TMPDIR/intel_reg_dumped.1.fbdev
+fi
+killall X
+
+# log after fbdev before intel
+dmesg -c $TMPDIR/dmesg.2.after.fbdev.before.intel
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.2.after.fbdev.before.intel
+
+sleep 5
+
+# run intel
+xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.intel
+sleep 5
+if [ -f `which intel_reg_dumper` ]; then
+`which intel_reg_dumper` $TMPDIR/intel_reg_dumped.2.intel
+fi
+killall X
+
+# log after intel
+dmesg -c $TMPDIR/dmesg.3.after.intel
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.3.after.intel
+
+cp $0 $TMPDIR/
+
+tar czf $TMPDIR.tar.gz $TMPDIR/*
+if [ -f $TMPDIR.tar.gz ]; then
+ echo $TMPDIR.tar.gz contains this script, all configs and logs
generated on this tests
+fi
+
+exit 0
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cleaning up the relocate entry function
From: Rafael Barbalho rafael.barbalho at intel.com As the relocate entry function was getting a bit too big I've moved the code that used to use either the cpu or the gtt to for the relocation into two separate functions. Signed-off-by: Rafael Barbalho rafael.barbalho at intel.com Feel free to add my... Tested-by: Sedat Dilek sedat.di...@gmail.com (against next-20130821) - Sedat - [1] http://lists.freedesktop.org/archives/intel-gfx/2013-August/032182.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests: ddx_intel_after_fbdev loads intel ddx after fbdev was loaded.
On Wed, Aug 21, 2013 at 03:13:13PM -0300, Rodrigo Vivi wrote:
v2: Don't add to kernel tests.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
lgtm, applied.
-Daniel
---
tests/Makefile.am | 9 +-
tests/ddx_intel_after_fbdev | 73
+
2 files changed, 81 insertions(+), 1 deletion(-)
create mode 100755 tests/ddx_intel_after_fbdev
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 9e46cac..935495e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -169,8 +169,15 @@ HANG = \
gem_non_secure_batch \
$(NULL)
+scripts = \
+ check_drm_clients \
+ ddx_intel_after_fbdev \
+ debugfs_wedged \
+ drm_lib.sh \
+ $(NULL)
+
EXTRA_PROGRAMS = $(TESTS_progs) $(TESTS_progs_M) $(HANG)
-EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) drm_lib.sh
check_drm_clients debugfs_wedged
+EXTRA_DIST = $(TESTS_scripts) $(TESTS_scripts_M) $(scripts)
CLEANFILES = $(EXTRA_PROGRAMS)
AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) \
diff --git a/tests/ddx_intel_after_fbdev b/tests/ddx_intel_after_fbdev
new file mode 100755
index 000..bcd2c29
--- /dev/null
+++ b/tests/ddx_intel_after_fbdev
@@ -0,0 +1,73 @@
+#!/bin/bash
+#
+# Testcase: Load Intel DDX after fbdev was loaded
+#
+
+whoami | grep -q root || {
+ echo ERROR: not running as root
+ exit 1
+}
+
+# no other X session should be running
+find /tmp/ -name .X*lock 2/dev/null | grep -q X {
+ echo ERROR: X session already running
+ exit 1
+}
+
+TMPDIR=$(mktemp -d /tmp/igt.) || {
+ echo ERROR: Failed to create temp dir
+ exit 1
+}
+
+cat $TMPDIR/xorg.conf.fbdev EOF
+Section Device
+ Driver fbdev
+ Identifier Device[fbdev]
+EndSection
+EOF
+
+cat $TMPDIR/xorg.conf.intel EOF
+Section Device
+ Driver intel
+ Identifier Device[intel]
+EndSection
+EOF
+
+# log before fbdev
+dmesg -c $TMPDIR/dmesg.1.before.fbdev
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.1.before.fbdev
+
+# run fbdev
+xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.fbdev
+sleep 5
+if [ -f `which intel_reg_dumper` ]; then
+`which intel_reg_dumper` $TMPDIR/intel_reg_dumped.1.fbdev
+fi
+killall X
+
+# log after fbdev before intel
+dmesg -c $TMPDIR/dmesg.2.after.fbdev.before.intel
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.2.after.fbdev.before.intel
+
+sleep 5
+
+# run intel
+xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.intel
+sleep 5
+if [ -f `which intel_reg_dumper` ]; then
+`which intel_reg_dumper` $TMPDIR/intel_reg_dumped.2.intel
+fi
+killall X
+
+# log after intel
+dmesg -c $TMPDIR/dmesg.3.after.intel
+cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.3.after.intel
+
+cp $0 $TMPDIR/
+
+tar czf $TMPDIR.tar.gz $TMPDIR/*
+if [ -f $TMPDIR.tar.gz ]; then
+ echo $TMPDIR.tar.gz contains this script, all configs and logs
generated on this tests
+fi
+
+exit 0
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 21 [ screen corruption in graphical mode ]
On Wed, Aug 21, 2013 at 08:11:27PM +0200, Sedat Dilek wrote: On Wed, Aug 21, 2013 at 3:44 PM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 12:35:08PM +0200, Sedat Dilek wrote: On Wed, Aug 21, 2013 at 11:21 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, There will be no linux-next trees on Aug 23 or 26. Changes since 20130820: New tree: aio-direct Removed tree: xilinx (at maintainer's request) The xfs tree still had its build failure for which I reverted a commit. The trivial tree gained conflicts against the crypto, net-next and wireless trees. The aio tree gained conflicts against the aio-direct tree. The akpm-current tree gained conflicts against the modules and aio-direct trees. Hi, I still have this issue with next-20130821 and Linux v3.11-rc6 plus drm-intel-nightly on top Any new development on this? Patches? Tbh I'm at a loss what we could try abovebeyond what Chris has already tried out. Currently, I have two workarounds: [1] Revert this commit: commit 5456fe3882812aba251886e36fe55bfefb8e8829 drm/i915: Allocate LLC ringbuffers from stolen Since with a rather decent chance the next testing cycle I'll do this friday will be the last chunk of features for 3.12 I'll probably drop the above patch from my queue and we can try again in 3.13. Inspired by [1] I have switched from UXA to SNA... ...and applied [PATCH] drm/i915: Cleaning up the relocate entry function on top of next-20130821... ...and can NOT see the screen corruptions anymore. Can you explain that? If the relocate cleanup patch [1] is indeed required, then I can't explain this at all. Can you please double-check that this is really it, and that it's not the uxa-sna switch? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop WaMbcDriverBootEnable workaround
On Wed, Aug 21, 2013 at 08:08:55AM -0700, Jesse Barnes wrote: Turns out the BIOS will do this for us as needed, and if we try to do it again we risk hangs or other bad behavior. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Regressing commit citation missing and also cc: stable I guess? -Daniel --- drivers/gpu/drm/i915/intel_pm.c | 17 - 1 file changed, 17 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 21f4c95..c823861 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4864,10 +4864,6 @@ static void gen6_init_clock_gating(struct drm_device *dev) ILK_DPARBUNIT_CLOCK_GATE_ENABLE | ILK_DPFDUNIT_CLOCK_GATE_ENABLE); - /* WaMbcDriverBootEnable:snb */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | -GEN6_MBCTL_ENABLE_BOOT_FETCH); - g4x_disable_trickle_feed(dev); /* The default value should be 0x200 according to docs, but the two @@ -4963,10 +4959,6 @@ static void haswell_init_clock_gating(struct drm_device *dev) I915_WRITE(CACHE_MODE_1, _MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_DISABLE)); - /* WaMbcDriverBootEnable:hsw */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | -GEN6_MBCTL_ENABLE_BOOT_FETCH); - /* WaSwitchSolVfFArbitrationPriority:hsw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); @@ -5050,10 +5042,6 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) g4x_disable_trickle_feed(dev); - /* WaMbcDriverBootEnable:ivb */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | -GEN6_MBCTL_ENABLE_BOOT_FETCH); - /* WaVSRefCountFullforceMissDisable:ivb */ gen7_setup_fixed_func_scheduler(dev_priv); @@ -5113,11 +5101,6 @@ static void valleyview_init_clock_gating(struct drm_device *dev) I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) | GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB); - /* WaMbcDriverBootEnable:vlv */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | -GEN6_MBCTL_ENABLE_BOOT_FETCH); - - /* According to the BSpec vol1g, bit 12 (RCPBUNIT) clock * gating disable must be set. Failure to set it results in * flickering pixels due to Z write ordering failures after -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prevent loading of uninitialized context garbage
On Wed, Aug 21, 2013 at 06:31:07PM +0300, Ville Syrjälä wrote:
On Wed, Aug 21, 2013 at 04:43:33PM +0300, Ville Syrjälä wrote:
On Thu, Aug 08, 2013 at 08:00:26PM +0100, Chris Wilson wrote:
The extended state bits are stored in the LCA register and affect all
updates to the LCA register - i.e. the state on the old context is saved
when SAVE_EX_STATE_EN is currently set in the old context address before
the update, and the new context is restored when RESTORE_EX_STATE_EN is
set in the new context address. This is irrespective of the
RESTORE_INHIBIT flag in the MI_SET_CONTEXT.
Hence, upon initial loading the contents of the extended state is read
from uninitialised data. To workaround this, on first load we do a dummy
load without the mandatory RESTORE_EX_STATE_EN bit so that the real load
causes us to initialise the extended state of the context before it is
then loaded by the LCA update.
v2: Split out the introduction of the variable length MI_SET_CONTEXT
command sequence.
References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8a7b61e..a57d49a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -367,6 +367,8 @@ mi_set_context(struct intel_ring_buffer *ring,
case 5: len += 2;
break;
}
+ if (!new_context-is_initialized)
+ len += 2;
ret = intel_ring_begin(ring, len);
if (ret)
@@ -382,6 +384,22 @@ mi_set_context(struct intel_ring_buffer *ring,
break;
}
+ if (!new_context-is_initialized) {
+ /* The GPU tries to restore the extended state irrespective
+ * of RestoreInhibit (since it is part of the LCA switch
+ * itself rather than the MI_SET_CONTEXT command).
+ * Since the initial contents may be garbage we do a dummy
+ * load first then set the mandatory flag for any future
+ * ring context switches.
+ */
+ intel_ring_emit(ring, MI_SET_CONTEXT);
+ intel_ring_emit(ring,
+ i915_gem_obj_ggtt_offset(new_context-obj) |
+ MI_MM_SPACE_GTT |
+ MI_SAVE_EXT_STATE_EN |
+ hw_flags);
+ }
Hmm. Couldn't we just do this w/ one MI_SET_CONTEXT? Just drop the
MI_RESTORE_EXT_STATE_EN flag if the context is not initialized. The
MI_SAVE_EXT_STATE_EN will be saved in the CCID, so when we switch to
another context the extended state will be saved. And for the next
switch to this context we will set the MI_RESTORE_EXT_STATE_EN bit
in MI_SET_CONTEXT so it should get restored.
But I must admit BSpec is a bit confusing on the topic. It says the
restore bit affects the switch to the context specified in the
logical context address. I take that to mean that the effect of the
restore bit is immediate. But BSpec also says that the bit is stored in
CCID to control the subsequent switch to the same context. So does that
actually mean that 'effective.restore_ext = CCID.restore_ext |
MI_SET_CONTEXT.restore_ext'?
Oh, but BSpec also says that both bits must be set when RS2 power state
is enabled. I think that's the same as RC6, or is it? So I guess the
hardware might consult these bits when entering/leaving RC6. So I suppose
we really need to make sure both bits are always set in case we hit RC6.
So based on that reasoning the patch would seem correct.
I guess I'll give it an r-b regardless :)
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
I just noticed that on HSW these bits control the resource streamer
state save/restore. The spec says we should always set the RS
restore bit if we set the RS save bit. So maybe we need some
!IS_HASWELL checks in there...
Looks like we're lucky since we don't have RS support yet ;-) Can you
please poke Abdiel about this so we make sure to test/check for this?
Cc'ing him.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: User POSTING_READ and I915_READ_NOTRACE in lcpll code
On Wed, Aug 21, 2013 at 10:59:47AM -0300, Paulo Zanoni wrote: 2013/8/21 Daniel Vetter daniel.vet...@ffwll.ch: If we don't use the return value of a mmio read our coding style is to use the POSTING_READ macro. This avoids cluttering the mmio traces. Similarly for busy loops to wait for a bit to flip we use the _NOTRACE variant to avoid filling up the tracebuffers with gunk. Spotted while reading some follow-up patches from Paulo. While at it add the missing posting read in the lcpll enable function that Paulo spotted. Cc: Paulo Zanoni przan...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com I'm pretty sure I added many other wait_for calls without the _NOTRACE in the past... Hm, you're right and I even missed one wait_for loop without _NOTRACE in the lcpll code. On further though we only use _NOTRACE consistently in the mmio vfuncs for forcewake and the gt fifo stuff. Which makes sense since those are just the details of how to write a register in the gt. But the actual delay loops in the modeset code are probably rather interesting, so I now think we should keep them ;-) I'll resend with just the posting read stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use POSTING_READ in lcpll code
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.
While at it add the missing posting read in the lcpll enable function
that Paulo spotted.
v2: Drop the _NOTRACE changes, tracing such wait_for loops in the modeset
code might actually be rather useful!
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a40427..937fc5a6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6036,13 +6036,14 @@ void hsw_restore_lcpll(struct drm_i915_private
*dev_priv)
if (val LCPLL_POWER_DOWN_ALLOW) {
val = ~LCPLL_POWER_DOWN_ALLOW;
I915_WRITE(LCPLL_CTL, val);
+ POSTING_READ(LCPLL_CTL);
}
val = I915_READ(D_COMP);
val |= D_COMP_COMP_FORCE;
val = ~D_COMP_COMP_DISABLE;
I915_WRITE(D_COMP, val);
- I915_READ(D_COMP);
+ POSTING_READ(D_COMP);
val = I915_READ(LCPLL_CTL);
val = ~LCPLL_PLL_DISABLE;
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop WaMbcDriverBootEnable workaround
On Wed, 21 Aug 2013 23:23:04 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 08:08:55AM -0700, Jesse Barnes wrote: Turns out the BIOS will do this for us as needed, and if we try to do it again we risk hangs or other bad behavior. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Regressing commit citation missing and also cc: stable I guess? If you want, I think we've only had this reported on Chrome, which probably doesn't need it in stable... -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use POSTING_READ in lcpll code
2013/8/21 Daniel Vetter daniel.vet...@ffwll.ch:
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.
While at it add the missing posting read in the lcpll enable function
that Paulo spotted.
v2: Drop the _NOTRACE changes, tracing such wait_for loops in the modeset
code might actually be rather useful!
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a40427..937fc5a6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6036,13 +6036,14 @@ void hsw_restore_lcpll(struct drm_i915_private
*dev_priv)
if (val LCPLL_POWER_DOWN_ALLOW) {
val = ~LCPLL_POWER_DOWN_ALLOW;
I915_WRITE(LCPLL_CTL, val);
+ POSTING_READ(LCPLL_CTL);
}
val = I915_READ(D_COMP);
val |= D_COMP_COMP_FORCE;
val = ~D_COMP_COMP_DISABLE;
I915_WRITE(D_COMP, val);
- I915_READ(D_COMP);
+ POSTING_READ(D_COMP);
val = I915_READ(LCPLL_CTL);
val = ~LCPLL_PLL_DISABLE;
--
1.8.4.rc3
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop WaMbcDriverBootEnable workaround
On Wed, Aug 21, 2013 at 02:39:34PM -0700, Jesse Barnes wrote: On Wed, 21 Aug 2013 23:23:04 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 21, 2013 at 08:08:55AM -0700, Jesse Barnes wrote: Turns out the BIOS will do this for us as needed, and if we try to do it again we risk hangs or other bad behavior. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Regressing commit citation missing and also cc: stable I guess? If you want, I think we've only had this reported on Chrome, which probably doesn't need it in stable... Added plus the t-d from Stephane plus the regressing citation. I'm just not a grumpy enough maintainer it seems ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Add debugfs interface for planes
This interface can enhanced over time to get more per plane information.
I've just flip counts for now. What I'd like to do with flip counts is
integrate them with existing flip tests. It serves a similar, but more
course purpose to some of the CRC work being done.
Unfortunately, I've been unable to get something going on the test side
thus far because I am inexperienced with the APIs, and don't see a way
to map a crtc to a hardware plane (which is what we have flip counts
for).
Chris, maybe you can do something useful with this?
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 236d97e..1cf0461 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1791,6 +1791,26 @@ static int i915_energy_uJ(struct seq_file *m, void *data)
return 0;
}
+static int i915_plane_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uintptr_t plane = (uintptr_t) node-info_ent-data;
+
+ if (INTEL_INFO(dev)-gen 5 !INTEL_INFO(dev)-is_g4x)
+ return -ENODEV;
+
+ if (plane = INTEL_INFO(dev)-num_pipes)
+ return -ENODEV;
+
+ DRM_ERROR(Plane was %p\n, data);
+
+ seq_printf(m, flip count: %u\n, I915_READ(DSPFLIPCNT(plane)));
+
+ return 0;
+}
+
static int
i915_wedged_get(void *data, u64 *val)
{
@@ -2231,6 +2251,9 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_llc, i915_llc, 0},
{i915_edp_psr_status, i915_edp_psr_status, 0},
{i915_energy_uJ, i915_energy_uJ, 0},
+ {i915_plane_a, i915_plane_info, 0, (void *)0},
+ {i915_plane_b, i915_plane_info, 0, (void *)1},
+ {i915_plane_c, i915_plane_info, 0, (void *)2},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
--
1.8.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Update plane flip count registers
Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_reg.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 53d0e70..d1079db 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3277,7 +3277,6 @@ #define PIPE_PIXEL_SHIFT0 /* GM45+ just has to be different */ #define _PIPEA_FRMCOUNT_GM45 0x70040 -#define _PIPEA_FLIPCOUNT_GM45 0x70044 #define PIPE_FRMCOUNT_GM45(pipe) _PIPE(pipe, _PIPEA_FRMCOUNT_GM45, _PIPEB_FRMCOUNT_GM45) /* Cursor A B regs */ @@ -3361,6 +3360,7 @@ #define DISPPLANE_STEREO_POLARITY_SECOND (118) #define DISPPLANE_TRICKLE_FEED_DISABLE (114) /* Ironlake */ #define DISPPLANE_TILED (110) +#define _DSPAFLIPCNT (dev_priv-info-display_mmio_offset + 0x70044) #define _DSPAADDR (dev_priv-info-display_mmio_offset + 0x70184) #define _DSPASTRIDE(dev_priv-info-display_mmio_offset + 0x70188) #define _DSPAPOS (dev_priv-info-display_mmio_offset + 0x7018C) /* reserved */ @@ -3380,6 +3380,7 @@ #define DSPLINOFF(plane) DSPADDR(plane) #define DSPOFFSET(plane) _PIPE(plane, _DSPAOFFSET, _DSPBOFFSET) #define DSPSURFLIVE(plane) _PIPE(plane, _DSPASURFLIVE, _DSPBSURFLIVE) +#define DSPFLIPCNT(plane) _PIPE(plane, _DSPAFLIPCNT, _DSPBFLIPCNT) /* Display/Sprite base address macros */ #define DISP_BASEADDR_MASK (0xf000) @@ -3410,10 +3411,11 @@ #define _PIPEBFRAMEHIGH(dev_priv-info-display_mmio_offset + 0x71040) #define _PIPEBFRAMEPIXEL (dev_priv-info-display_mmio_offset + 0x71044) #define _PIPEB_FRMCOUNT_GM45 0x71040 -#define _PIPEB_FLIPCOUNT_GM45 0x71044 +#define _PIPEB_FLIPCOUNT (dev_priv-info-display_mmio_offset + 0x71044 /* Display B control */ +#define _DSPBFLIPCNT (dev_priv-info-display_mmio_offset + 0x71044) #define _DSPBCNTR (dev_priv-info-display_mmio_offset + 0x71180) #define DISPPLANE_ALPHA_TRANS_ENABLE (115) #define DISPPLANE_ALPHA_TRANS_DISABLE0 -- 1.8.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] [v2] drm/i915: Add debugfs interface for planes
This interface can enhanced over time to get more per plane information.
I've just flip counts for now. What I'd like to do with flip counts is
integrate them with existing flip tests. It serves a similar, but more
coarse purpose to some of the CRC work being done. It can be used to
determine if something is being flipped when we expect it to be flipped.
The immediate issue I want to look into is I've seen some funny behavior
where we're getting two flips per flip queued.
Unfortunately, I've been unable to get something going on the test side
thus far because I am inexperienced with the APIs, and don't see a way
to map a crtc to a hardware plane (which is what we have flip counts
for).
Chris, maybe you can do something useful with this?
v2: Use the right patch, with the right commit msg.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 236d97e..27aee95 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1791,6 +1791,24 @@ static int i915_energy_uJ(struct seq_file *m, void *data)
return 0;
}
+static int i915_plane_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uintptr_t plane = (uintptr_t) node-info_ent-data;
+
+ if (INTEL_INFO(dev)-gen 5 !INTEL_INFO(dev)-is_g4x)
+ return -ENODEV;
+
+ if (plane = INTEL_INFO(dev)-num_pipes)
+ return -ENODEV;
+
+ seq_printf(m, flip count: %u\n, I915_READ(DSPFLIPCNT(plane)));
+
+ return 0;
+}
+
static int
i915_wedged_get(void *data, u64 *val)
{
@@ -2231,6 +2249,9 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_llc, i915_llc, 0},
{i915_edp_psr_status, i915_edp_psr_status, 0},
{i915_energy_uJ, i915_energy_uJ, 0},
+ {i915_plane_a, i915_plane_info, 0, (void *)0},
+ {i915_plane_b, i915_plane_info, 0, (void *)1},
+ {i915_plane_c, i915_plane_info, 0, (void *)2},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
--
1.8.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add debugfs interface for planes
On Wed, Aug 21, 2013 at 07:16:53PM -0700, Ben Widawsky wrote: Sent the unfinished commit by accident On Wed, Aug 21, 2013 at 08:15:53PM -0700, Ben Widawsky wrote: This interface can enhanced over time to get more per plane information. I've just flip counts for now. What I'd like to do with flip counts is integrate them with existing flip tests. It serves a similar, but more course purpose to some of the CRC work being done. ^^ coarse. It can be used to determine if something is being flipped when we expect it to be flipped. The immediate issue I want to look into is I've seen some funny behavior where we're getting two flips per flip queued. Cursed email - I only have your reply. On the machines you are interested in, the CRTCs are assigned to fixed planes. -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 2/2] drm/i915: Add debugfs interface for planes
On Thu, Aug 22, 2013 at 03:21:09AM +0100, Chris Wilson wrote: On Wed, Aug 21, 2013 at 07:16:53PM -0700, Ben Widawsky wrote: Sent the unfinished commit by accident On Wed, Aug 21, 2013 at 08:15:53PM -0700, Ben Widawsky wrote: This interface can enhanced over time to get more per plane information. I've just flip counts for now. What I'd like to do with flip counts is integrate them with existing flip tests. It serves a similar, but more course purpose to some of the CRC work being done. ^^ coarse. It can be used to determine if something is being flipped when we expect it to be flipped. The immediate issue I want to look into is I've seen some funny behavior where we're getting two flips per flip queued. Cursed email - I only have your reply. On the machines you are interested in, the CRTCs are assigned to fixed planes. -Chris It's not just you, mailman is acting weird for me also. In any case, can you give me another hint on how to go from crtc_id to plane? -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add debugfs interface for planes
On Wed, Aug 21, 2013 at 07:27:11PM -0700, Ben Widawsky wrote: On Thu, Aug 22, 2013 at 03:21:09AM +0100, Chris Wilson wrote: On Wed, Aug 21, 2013 at 07:16:53PM -0700, Ben Widawsky wrote: Sent the unfinished commit by accident On Wed, Aug 21, 2013 at 08:15:53PM -0700, Ben Widawsky wrote: This interface can enhanced over time to get more per plane information. I've just flip counts for now. What I'd like to do with flip counts is integrate them with existing flip tests. It serves a similar, but more course purpose to some of the CRC work being done. ^^ coarse. It can be used to determine if something is being flipped when we expect it to be flipped. The immediate issue I want to look into is I've seen some funny behavior where we're getting two flips per flip queued. Cursed email - I only have your reply. On the machines you are interested in, the CRTCs are assigned to fixed planes. -Chris It's not just you, mailman is acting weird for me also. In any case, can you give me another hint on how to go from crtc_id to plane? crtc-id to plane is easy, use the get_pipe_ioctl and the plane is identical to the pipe (for these machines). If you want plane to crtc, then you need to build a little mapping table. -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 3/3] RFM drm/i915: Tweak RPS thresholds to more aggressively downclock
After applying wait-boost we often find ourselves stuck at higher clocks
than required. The current threshold value requires the GPU to be
continuously and completely idle for 313ms before it is dropped by one
bin. Conversely, we require the GPU to be busy for an average of 90% over
a 84ms before we upclock. So the current thresholds almost never
downclock the GPU, and respond very slowly to sudden demands for more
power.
A more sensible approach, as discussed in the bspec, is to a continuous
threshold for upclocking, and an average value for downclocking.
RFM - request for measurement!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
Cc: Meng, Mengmeng mengmeng.m...@intel.com
Cc: Zhuang, Lena lena.zhu...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 15 +--
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3f5bddd..04b23cb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4620,7 +4620,7 @@
#define GEN6_RP_UP_IDLE_MIN (0x13)
#define GEN6_RP_UP_BUSY_AVG (0x23)
#define GEN6_RP_UP_BUSY_CONT (0x43)
-#define GEN7_RP_DOWN_IDLE_AVG(0x20)
+#define GEN6_RP_DOWN_IDLE_AVG(0x20)
#define GEN6_RP_DOWN_IDLE_CONT (0x10)
#define GEN6_RP_UP_THRESHOLD 0xA02C
#define GEN6_RP_DOWN_THRESHOLD 0xA030
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index aa98b0b..1dcda84 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3581,10 +3581,13 @@ static void gen6_enable_rps(struct drm_device *dev)
dev_priv-rps.max_delay 24 |
dev_priv-rps.min_delay 16);
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
- I915_WRITE(GEN6_RP_UP_EI, 66000);
- I915_WRITE(GEN6_RP_DOWN_EI, 35);
+ /* Upclock if continuously busy for 5ms, ~1/3 of a frame */
+ I915_WRITE(GEN6_RP_UP_EI, 16000); /* not used for continuous mode */
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 5000);
+
+ /* Downclock if less than 66% busy over 33ms, last ~2 frames */
+ I915_WRITE(GEN6_RP_DOWN_EI, 33000);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 22000);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
@@ -3592,8 +3595,8 @@ static void gen6_enable_rps(struct drm_device *dev)
GEN6_RP_MEDIA_HW_NORMAL_MODE |
GEN6_RP_MEDIA_IS_GFX |
GEN6_RP_ENABLE |
- GEN6_RP_UP_BUSY_AVG |
- (IS_HASWELL(dev) ? GEN7_RP_DOWN_IDLE_AVG :
GEN6_RP_DOWN_IDLE_CONT));
+ GEN6_RP_UP_BUSY_CONT |
+ GEN6_RP_DOWN_IDLE_AVG);
ret = sandybridge_pcode_write(dev_priv,
GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0);
if (!ret) {
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] RFM drm/i915: Downclock when idle idle-decay
This is the missing component for the last past that provides the
wait-boost. After boosting the RPS frequency of the GPU, it would not
decay, leaving the GPU at high clocks whenever it woke from idle. If we
apply the Valleyview logic of resetting our request to the optimal
frequency when we detect the GPU is idle, we recovered the automatic
regulating behaviour.
This patch removes the dedicated timer for Valleyview downclocking, and
moves the logic into intel_mark_idle(), taking care that we trigger the
downclock shortly after the earliest point we notice the GPU is idle.
v2: Move the idle work handler back to its own delayed timer. The goal
is not to downclock too early, so we use mod_timer to keep the upclock
alive whilst requests are still being queued and retired.
RFM - request for measurement!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
Cc: Meng, Mengmeng mengmeng.m...@intel.com
Cc: Zhuang, Lena lena.zhu...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 15 ++---
drivers/gpu/drm/i915/i915_gem.c | 65 ++--
drivers/gpu/drm/i915/i915_irq.c | 11 --
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 46 -
6 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0506b93..e1d41ae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -832,9 +832,6 @@ struct intel_gen6_power_mgmt {
struct work_struct work;
u32 pm_iir;
- /* On vlv we need to manually drop to Vmin with a delayed work. */
- struct delayed_work vlv_work;
-
/* The below variables an all the rps hw state are protected by
* dev-struct mutext. */
u8 cur_delay;
@@ -842,6 +839,7 @@ struct intel_gen6_power_mgmt {
u8 max_delay;
u8 rpe_delay;
u8 rp1_delay;
+ u8 rp0_delay;
u8 hw_max;
struct delayed_work delayed_resume_work;
@@ -951,6 +949,15 @@ struct i915_gem_mm {
struct delayed_work retire_work;
/**
+* When we detect an idle GPU, we want to turn on
+* powersaving features. So once we see that there
+* are no more requests outstanding and no more
+* arrive within a small period of time, we fire
+* off the idle_work.
+*/
+ struct delayed_work idle_work;
+
+ /**
* Are we in a non-interruptible section of code like
* modesetting?
*/
@@ -1852,7 +1859,7 @@ i915_gem_object_unpin_fence(struct drm_i915_gem_object
*obj)
}
}
-void i915_gem_retire_requests(struct drm_device *dev);
+bool i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_requests_ring(struct intel_ring_buffer *ring);
int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ef3559..5ceb204 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2201,6 +2201,7 @@ int __i915_add_request(struct intel_ring_buffer *ring,
i915_queue_hangcheck(ring-dev);
if (was_empty) {
+ cancel_delayed_work_sync(dev_priv-mm.idle_work);
queue_delayed_work(dev_priv-wq,
dev_priv-mm.retire_work,
round_jiffies_up_relative(HZ));
@@ -2471,57 +2472,54 @@ i915_gem_retire_requests_ring(struct intel_ring_buffer
*ring)
WARN_ON(i915_verify_lists(ring-dev));
}
-void
+bool
i915_gem_retire_requests(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring;
+ bool idle = true;
int i;
- for_each_ring(ring, dev_priv, i)
+ for_each_ring(ring, dev_priv, i) {
i915_gem_retire_requests_ring(ring);
+ idle = list_empty(ring-request_list);
+ }
+
+ if (idle)
+ mod_delayed_work(dev_priv-wq,
+ dev_priv-mm.idle_work,
+ msecs_to_jiffies(100));
+
+ return idle;
}
static void
i915_gem_retire_work_handler(struct work_struct *work)
{
- drm_i915_private_t *dev_priv;
- struct drm_device *dev;
- struct intel_ring_buffer *ring;
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv), mm.retire_work.work);
+ struct drm_device *dev = dev_priv-dev;
bool idle;
- int i;
-
- dev_priv = container_of(work, drm_i915_private_t,
- mm.retire_work.work);
- dev =
[Intel-gfx] [PATCH 1/3] RFM drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected.
RFM - request for measurement!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
Cc: Meng, Mengmeng mengmeng.m...@intel.com
Cc: Zhuang, Lena lena.zhu...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 091bb553..8ef3559 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1106,6 +1106,15 @@ static int __wait_seqno(struct intel_ring_buffer *ring,
u32 seqno,
if (WARN_ON(!ring-irq_get(ring)))
return -ENODEV;
+ if (dev_priv-info-gen = 6) {
+ mutex_lock(dev_priv-rps.hw_lock);
+ if (dev_priv-info-is_valleyview)
+ valleyview_set_rps(dev_priv-dev,
dev_priv-rps.max_delay);
+ else
+ gen6_set_rps(dev_priv-dev, dev_priv-rps.max_delay);
+ mutex_unlock(dev_priv-rps.hw_lock);
+ }
+
/* Record current time in case interrupted by signal, or wedged * */
getrawmonotonic(before);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
