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 specific
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 a
On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote:
> Ville Syrjälä 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
Ville Syrjälä 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
> crtc/plane properties in
Kristian Høgsberg 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 interfaces use *both*
On Sat, 23 Nov 2013 01:26:34 +0200
Ville Syrjälä 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ä wrote:
> >
> > > On Fri, Nov 22, 2013 at 01:55:35PM -0800, Jesse Barnes wrote:
> > > > On Wed, 20 Nov 2013 15:10:39 +0
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ä 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ä wrote:
> > > > > + case DISPPLANE_8BPP:
>
On Sat, 23 Nov 2013 01:08:17 +0200
Ville Syrjälä 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ä wrote:
> > > > + case DISPPLANE_8BPP:
> > > > + return DRM_FORMAT_C8;
> > > > + case DISPPLAN
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ä wrote:
> > > + case DISPPLANE_8BPP:
> > > + return DRM_FORMAT_C8;
> > > + case DISPPLANE_BGRX555:
> > > + return DRM_FORMAT_ARGB1555;
> >
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 wrote:
> > > Daniel Vetter writes:
> > >
> > >> Hm, where do we have the canonical source for all these fourcc co
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
> On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> > Daniel Vetter 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
On Wed, 20 Nov 2013 15:10:39 +0200
Ville Syrjälä wrote:
> > + case DISPPLANE_8BPP:
> > + return DRM_FORMAT_C8;
> > + case DISPPLANE_BGRX555:
> > + return DRM_FORMAT_ARGB1555;
> ^
> X
Oops fixed, thanks. These formats are a lot of typing.
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.
Thank
On Fri, 22 Nov 2013 20:35:24 +
Chris Wilson 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
> on the second worka
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
2013/11/15 Daniel Vetter :
> 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
> Signed-off-by: Daniel Vetter
I can reproduce the failure by booting with i915.modeset=
On Fri, 2013-11-22 at 15:32 -0200, Paulo Zanoni wrote:
> 2013/11/14 Imre Deak :
> > Add a debugfs entry showing the use-count for all power domains of each
> > power well.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 69
> > ++
2013/11/22 Imre Deak :
> On Fri, 2013-11-22 at 13:53 -0200, Paulo Zanoni wrote:
>> 2013/11/14 Imre Deak :
>> > 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
On Fri, 2013-11-22 at 14:09 -0200, Paulo Zanoni wrote:
> 2013/11/14 Imre Deak :
> > Signed-off-by: Imre Deak
>
> Since I assume all power wells will require some kind of
> register-checking and hardware-touching at the init paths, shouldn't
> we add power_well->init_hw() and call it once for each
On Fri, 2013-11-22 at 13:41 -0200, Paulo Zanoni wrote:
> 2013/11/14 Imre Deak :
> > 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
Chris Wilson 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
> Date: Thu Jul 4 11:02:03 2013 -0700
>
>
On Fri, 2013-11-22 at 13:53 -0200, Paulo Zanoni wrote:
> 2013/11/14 Imre Deak :
> > 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
On Fri, Nov 22, 2013 at 09:53:23AM -0800, Jesse Barnes wrote:
> On Fri, 22 Nov 2013 10:37:53 +
> Chris Wilson 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
> >
> > (co
Signed-off-by: Damien Lespiau
---
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 +789,9 @@ gen8_emit_depth(st
Signed-off-by: Damien Lespiau
---
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 +470,9 @@ gen6_create_sc
Signed-off-by: Damien Lespiau
---
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 +783,9 @@ gen8_emit_depth(st
Signed-off-by: Damien Lespiau
---
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
--- a/lib/rendercopy_gen8.c
+++ b/lib/renderco
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
On Fri, 22 Nov 2013 10:37:53 +
Chris Wilson 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 Widawsky
> Date:
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote:
> On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> > Daniel Vetter 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
This is the one that already works in libdrm, so don't disappoint people
coming with expectations.
Signed-off-by: Damien Lespiau
---
tools/intel_dump_decode.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/intel_dump_decode.c b/tools/intel_dump_decode.c
index 95
Signed-off-by: Damien Lespiau
---
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
+++ b/tools/intel_dump_decode.c
@@ -168,7 +168,7 @@ m
2013/11/14 Imre Deak :
> Add a debugfs entry showing the use-count for all power domains of each
> power well.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 69
> +
> drivers/gpu/drm/i915/i915_drv.h | 4 +++
> drivers/gpu/drm/
2013/11/14 Imre Deak :
> 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 the power domain
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> Daniel Vetter 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 since we use it to pass ar
On Fri, Nov 22, 2013 at 02:04:02PM -0200, Paulo Zanoni wrote:
> 2013/11/14 Imre Deak :
> > 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. Si
2013/11/14 Imre Deak :
> Signed-off-by: Imre Deak
Since I assume all power wells will require some kind of
register-checking and hardware-touching at the init paths, shouldn't
we add power_well->init_hw() and call it once for each power well? The
problem with this series is that we're doing code
2013/11/14 Imre Deak :
> 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 get/put won't have
2013/11/14 Imre Deak :
> 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 by the rest of
>
2013/11/14 Imre Deak :
> 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 HAS_POWER_WELL won't work
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ä
> >
> > FBC host modification tracking only works through GTT mmaps, so any
> > direct CPU access needs to manually nuke the compr
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
> > > --- a/driver
Hi
2013/11/20 Mika Kuoppala :
> Daniel Vetter 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 intel_modeset_init_hw after reset so that
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
Date: Thu Jul 4 11:02:03 2013 -0700
drm/i915/hsw: Set correct Haswell
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 intermittent
45 matches
Mail list logo
