Thanks Jesse. We will re-run and compare the power numbers.
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Saturday, November 23, 2013 2:43 AM
To: S, Deepak
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add VLV
I got kernel WARNINGs frequently on Haswell laptops complaining about
invalid max DP link bw. With drm.debug=0x0e, it turned out that the
obtained DPCD is utterly bogus when it happens:
[drm:intel_dp_get_dpcd], DPCD: 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d
This seems happening
Hi
2013/11/20 Mika Kuoppala mika.kuopp...@linux.intel.com:
Daniel Vetter dan...@ffwll.ch writes:
Hi Daniel,
On Mon, Nov 18, 2013 at 04:34:44PM +0200, Mika Kuoppala wrote:
Large parts of hw initialization is behind per gen
clock gating functions. Including workarounds.
Call
On Thu, Nov 21, 2013 at 05:25:35PM +0100, Borislav Petkov wrote:
On Thu, Nov 21, 2013 at 05:10:30PM +0100, Richard Weinberger wrote:
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ed45a984230..1191aa47adc9 100644
---
On Thu, Nov 21, 2013 at 11:18:02PM +, Chris Wilson wrote:
On Thu, Nov 21, 2013 at 09:29:52PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
FBC host modification tracking only works through GTT mmaps, so any
direct CPU access needs to
2013/11/14 Imre Deak imre.d...@intel.com:
In intel_display_capture_error_state we use HAS_POWER_WELL to check if
we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER
which is specific to these platforms. Future platforms with power wells
don't have this register, so
2013/11/14 Imre Deak imre.d...@intel.com:
HW generations so far had only one always-on power well and optionally
one dynamic power well. Upcoming HW gens may have multiple dynamic power
wells, so add some infrastructure to support them.
The idea is to keep the existing power domain API used
2013/11/14 Imre Deak imre.d...@intel.com:
Instead of using a separate function to check whether a power domain is
is always on, add an always-on power well covering all these power
domains and do the usual get/put on these unconditionally. Since we
don't assign a .set handler for these the
On Fri, Nov 22, 2013 at 02:04:02PM -0200, Paulo Zanoni wrote:
2013/11/14 Imre Deak imre.d...@intel.com:
Instead of using a separate function to check whether a power domain is
is always on, add an always-on power well covering all these power
domains and do the usual get/put on these
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the kernel as drm_fourcc.h, and that
one is part of the userspace ABI
2013/11/14 Imre Deak imre.d...@intel.com:
So far we distinguished platforms without a dynamic power well with
the HAS_POWER_WELL macro and for such platforms we didn't call any power
domain functions. Instead of doing this check we can add an always-on
power well for these platforms and call
2013/11/14 Imre Deak imre.d...@intel.com:
Add a debugfs entry showing the use-count for all power domains of each
power well.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 69
+
drivers/gpu/drm/i915/i915_drv.h
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
tools/intel_dump_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/intel_dump_decode.c b/tools/intel_dump_decode.c
index a3cd2e5..959ec87 100644
--- a/tools/intel_dump_decode.c
+++
This is the one that already works in libdrm, so don't disappoint people
coming with expectations.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
tools/intel_dump_decode.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/intel_dump_decode.c
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the
On Fri, 22 Nov 2013 10:37:53 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
We have conflicting benchmark data that suggest either age 0 or age 3 is
better. However, the earlier benchmark on which we based the switch to
age 0
(commit 0d8ff15e9a15f2b393e53337a107b7a1e5919b6d
Author: Ben
Kayden noticed a few of those were wrong. It's clearly time to fix them!
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/rendercopy_gen8.c | 48 +++-
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index 723f4ef..8bcf2bb 100644
---
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/rendercopy_gen8.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index 660ff03..723f4ef 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -470,8
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/rendercopy_gen8.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index 8bcf2bb..0eeb179 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -783,7
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/rendercopy_gen8.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index 0eeb179..8d7d88b 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -789,7
On Fri, Nov 22, 2013 at 09:53:23AM -0800, Jesse Barnes wrote:
On Fri, 22 Nov 2013 10:37:53 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
We have conflicting benchmark data that suggest either age 0 or age 3 is
better. However, the earlier benchmark on which we based the switch to
Chris Wilson ch...@chris-wilson.co.uk writes:
We have conflicting benchmark data that suggest either age 0 or age 3 is
better. However, the earlier benchmark on which we based the switch to
age 0
(commit 0d8ff15e9a15f2b393e53337a107b7a1e5919b6d
Author: Ben Widawsky
On Fri, 2013-11-22 at 13:41 -0200, Paulo Zanoni wrote:
2013/11/14 Imre Deak imre.d...@intel.com:
In intel_display_capture_error_state we use HAS_POWER_WELL to check if
we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER
which is specific to these platforms. Future
On Fri, 2013-11-22 at 14:09 -0200, Paulo Zanoni wrote:
2013/11/14 Imre Deak imre.d...@intel.com:
Signed-off-by: Imre Deak imre.d...@intel.com
Since I assume all power wells will require some kind of
register-checking and hardware-touching at the init paths, shouldn't
we add
2013/11/22 Imre Deak imre.d...@intel.com:
On Fri, 2013-11-22 at 13:53 -0200, Paulo Zanoni wrote:
2013/11/14 Imre Deak imre.d...@intel.com:
HW generations so far had only one always-on power well and optionally
one dynamic power well. Upcoming HW gens may have multiple dynamic power
wells,
On Fri, 2013-11-22 at 15:32 -0200, Paulo Zanoni wrote:
2013/11/14 Imre Deak imre.d...@intel.com:
Add a debugfs entry showing the use-count for all power domains of each
power well.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 69
2013/11/15 Daniel Vetter daniel.vet...@ffwll.ch:
Oops, makes testing early boot failures in i915.ko a bit more pain, so
let's fix it.
v2: We already have a bit of static storage to track this (Chris).
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter
I believe, and an evening of i-g-t, that our original workaround for the
missed interrupts on Sandybridge, that of holding forcewake whilst we
wait for an interrupts, is no longer required. This leaves us dependent
on the second workaround of forcing an UC read of the ACTHD before
reading back the
On Fri, 22 Nov 2013 20:35:24 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
I believe, and an evening of i-g-t, that our original workaround for the
missed interrupts on Sandybridge, that of holding forcewake whilst we
wait for an interrupts, is no longer required. This leaves us dependent
Also, you might re-run your power numbers with Chris's patch to drop
the force wake ref around the irq get/put. That's the only one we
normally take at runtime, so getting rid of it should give you even
greater power savings in conjunction with the RC6 timeout update patch I
already pushed.
On Wed, 20 Nov 2013 15:10:39 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
+ case DISPPLANE_8BPP:
+ return DRM_FORMAT_C8;
+ case DISPPLANE_BGRX555:
+ return DRM_FORMAT_ARGB1555;
^
X
Oops fixed, thanks. These formats
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the
On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian Høgsberg wrote:
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for
On Fri, Nov 22, 2013 at 01:55:35PM -0800, Jesse Barnes wrote:
On Wed, 20 Nov 2013 15:10:39 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
+ case DISPPLANE_8BPP:
+ return DRM_FORMAT_C8;
+ case DISPPLANE_BGRX555:
+ return DRM_FORMAT_ARGB1555;
On Sat, 23 Nov 2013 01:08:17 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Nov 22, 2013 at 01:55:35PM -0800, Jesse Barnes wrote:
On Wed, 20 Nov 2013 15:10:39 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
+ case DISPPLANE_8BPP:
+
On Fri, Nov 22, 2013 at 03:21:08PM -0800, Jesse Barnes wrote:
On Sat, 23 Nov 2013 01:08:17 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Nov 22, 2013 at 01:55:35PM -0800, Jesse Barnes wrote:
On Wed, 20 Nov 2013 15:10:39 +0200
Ville Syrjälä
On Sat, 23 Nov 2013 01:26:34 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Nov 22, 2013 at 03:21:08PM -0800, Jesse Barnes wrote:
On Sat, 23 Nov 2013 01:08:17 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Nov 22, 2013 at 01:55:35PM -0800, Jesse
Kristian Høgsberg hoegsb...@gmail.com writes:
I already explained to Keith why we use different sets of format codes
in the DRI interface, but it's always fun to slam other peoples code.
As we discussed, my complaint isn't so much about __DRI_IMAGE_FOURCC,
but the fact that the __DRIimage
Ville Syrjälä ville.syrj...@linux.intel.com writes:
What is this format anyway? -ENODOCS
Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
If its just an srgb version of ARGB, then I wouldn't really want it
in drm_fourcc.h. I expect colorspacy stuff will be handled by various
On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote:
Ville Syrjälä ville.syrj...@linux.intel.com writes:
What is this format anyway? -ENODOCS
Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
If its just an srgb version of ARGB, then I wouldn't really want it
Summary
We covered the platform: Baytrail-M, Haswell mobile, HSW desktop, HSW ULT,
IvyBridge, SandyBridge, IronLake.
In this circle, 3 new bugs are filed, 35 bugs are still opened, no WONTFIX
bugs, 1 NOTABUG bugs ,no NOTOURBUG bugs, no Duplicated bugs, 1 REOPENED bugs, 6
bugs are fixed, 9 bugs
42 matches
Mail list logo
