Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell

[Wang, Xingchao]

Hi Takashi,

In order to let audio power-save work even with charger connected, two 
parameters need be modified in userspace pm-utils scripts.
I tested the changes under Ubuntu 13.10 on Harris Beach, no matter charger 
connected or not, runtime power-saving works and power-well will 
Be released as expected.

Here's my test under Ubuntu 13.04, the changes are:
1) 
/usr/lib/pm-utils/power.d/intel-audio-powersave
case $1 in
true) audio_powersave 1 ;;
+false) audio_powersave 10 ;;
-false) audio_powersave 0 ;;
help) help;;
*) exit $NA
esac

Audio will enter power-save mode after 10s inactive period.
2) /usr/lib/pm-utils/power.d/pci_devices

 0x040300) # audio
echo Setting Audio device $id to $1
+   echo auto  $dev/power/control
-echo $1  $dev/power/control

This keep audio subsystem always on.

This way the user may not let audio subsystem always active, may bring some 
delay from codec/controllers, or harm some chips.
Do you think we should add an exception for Haswell only or just make it as a 
common solution for audio subsystem?

Thanks
--xingchao
 -Original Message-
 From: Wang, Xingchao
 Sent: Wednesday, July 24, 2013 10:00 PM
 To: Takashi Iwai
 Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter;
 daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
 intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon
 Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
 implementation for Haswell
 
 
 
  -Original Message-
  From: Takashi Iwai [mailto:ti...@suse.de]
  Sent: Wednesday, July 24, 2013 9:43 PM
  To: Wang, Xingchao
  Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter;
  daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
  intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon
  Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
  implementation for Haswell
 
  At Wed, 24 Jul 2013 13:30:16 +,
  Wang, Xingchao wrote:
  
  
  
-Original Message-
From: Wysocki, Rafael J
Sent: Wednesday, July 24, 2013 9:15 PM
To: David Henningsson
Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter;
daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
   
On 7/24/2013 1:57 PM, David Henningsson wrote:
 On 07/24/2013 01:33 PM, Wang, Xingchao wrote:
 Yes, I agree. I'm debugging this issue on Ubuntu, not sure it
 happens on other distribution too.
 If it's related to Ubuntu, maybe need check Ubuntu power policy.
 Does anyone know the Ubuntu power-policy on laptop?
 i.e. when charger connected, will Ubuntu make decision to
 disable power-save feature for audio subsystem?

 I'm not a power management expert, but I got a pointer from my
 team mate to pm-utils:

 http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio
 -p
 ower
 save


 If I understand correctly, The scripts in power.d are executed
 when battery / AC-power is changed.

   
To me, this sounds like a user space issue.  It requested power on
and the kernel delivered.
  
   Do you know which user-space application will touch below two flags?
   - /sys/devices/pci\:00/\:00\:03.0/power/control
   - /sys/module/snd_hda_intel/parameters/power_save
 
  The latter is touched most likely by pm-utils, one of the hooks, as David
 pointed.
 
 Oh yes I found the hook:
 ./pm/power.d/intel-audio-powersave
 
 --xingchao
  The former is unknown, but better to check pm-utils hooks and udev rules.
 
 
  Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3

[Daniel Vetter]

On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
 Systems with Intel graphics controllers set aside memory exclusively for
 gfx driver use.  This memory is not marked in the E820 as reserved or as
 RAM, and so is subject to overlap from E820 manipulation later in the
 boot process.  On some systems, MMIO space is allocated on top, despite
 the efforts of the RAM buffer approach, which simply rounds memory
 boundaries up to 64M to try to catch space that may decode as RAM and so
 is not suitable for MMIO.
 
 v2: use read_pci_config for 32 bit reads instead of adding a new one
 (Chris)
 add gen6 stolen size function (Chris)
 use a function pointer (Chris)
 drop gen2 bits (Daniel)
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  arch/x86/kernel/early-quirks.c  |  158 
 +++
  drivers/gpu/drm/i915/i915_reg.h |   15 
  include/drm/i915_drm.h  |   32 
  3 files changed, 190 insertions(+), 15 deletions(-)
 
 diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
 index 94ab6b9..bff8a6f 100644
 --- a/arch/x86/kernel/early-quirks.c
 +++ b/arch/x86/kernel/early-quirks.c
 @@ -12,6 +12,7 @@
  #include linux/pci.h
  #include linux/acpi.h
  #include linux/pci_ids.h
 +#include drm/i915_drm.h
  #include asm/pci-direct.h
  #include asm/dma.h
  #include asm/io_apic.h
 @@ -208,6 +209,161 @@ static void __init intel_remapping_check(int num, int 
 slot, int func)
  
  }
  
 +/*
 + * Systems with Intel graphics controllers set aside memory exclusively
 + * for gfx driver use.  This memory is not marked in the E820 as reserved
 + * or as RAM, and so is subject to overlap from E820 manipulation later
 + * in the boot process.  On some systems, MMIO space is allocated on top,
 + * despite the efforts of the RAM buffer approach, which simply rounds
 + * memory boundaries up to 64M to try to catch space that may decode
 + * as RAM and so is not suitable for MMIO.
 + *
 + * And yes, so far on current devices the base addr is always under 4G.
 + */
 +static u32 __init intel_stolen_base(int num, int slot, int func)
 +{
 + u32 base;
 +
 + /*
 +  * Almost universally we can find the Graphics Base of Stolen Memory
 +  * at offset 0x5c in the igfx configuration space. On a few (desktop)
 +  * machines this is also mirrored in the bridge device at different
 +  * locations, or in the MCHBAR.
 +  */
 + base = read_pci_config(num, slot, func, 0x5c);
 + base = ~((120) - 1);
 +
 + return base;
 +}
 +
 +#define KB(x)((x) * 1024)
 +#define MB(x)(KB (KB (x)))
 +#define GB(x)(MB (KB (x)))
 +
 +static size_t __init gen3_stolen_size(int num, int slot, int func)
 +{
 + size_t stolen_size;
 + u16 gmch_ctrl;
 +
 + gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
 +
 + switch (gmch_ctrl  I855_GMCH_GMS_MASK) {
 + case I855_GMCH_GMS_STOLEN_1M:
 + stolen_size = MB(1);
 + break;
 + case I855_GMCH_GMS_STOLEN_4M:
 + stolen_size = MB(4);
 + break;
 + case I855_GMCH_GMS_STOLEN_8M:
 + stolen_size = MB(8);
 + break;
 + case I855_GMCH_GMS_STOLEN_16M:
 + stolen_size = MB(16);
 + break;
 + case I855_GMCH_GMS_STOLEN_32M:
 + stolen_size = MB(32);
 + break;
 + case I915_GMCH_GMS_STOLEN_48M:
 + stolen_size = MB(48);
 + break;
 + case I915_GMCH_GMS_STOLEN_64M:
 + stolen_size = MB(64);
 + break;
 + case G33_GMCH_GMS_STOLEN_128M:
 + stolen_size = MB(128);
 + break;
 + case G33_GMCH_GMS_STOLEN_256M:
 + stolen_size = MB(256);
 + break;
 + case INTEL_GMCH_GMS_STOLEN_96M:
 + stolen_size = MB(96);
 + break;
 + case INTEL_GMCH_GMS_STOLEN_160M:
 + stolen_size = MB(160);
 + break;
 + case INTEL_GMCH_GMS_STOLEN_224M:
 + stolen_size = MB(224);
 + break;
 + case INTEL_GMCH_GMS_STOLEN_352M:
 + stolen_size = MB(352);
 + break;
 + default:
 + stolen_size = 0;
 + break;
 + }
 +
 + return stolen_size;
 +}
 +
 +static size_t __init gen6_stolen_size(int num, int slot, int func)
 +{
 + u16 gmch_ctrl;
 +
 + gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
 + gmch_ctrl = SNB_GMCH_GMS_SHIFT;
 + gmch_ctrl = SNB_GMCH_GMS_MASK;
 +
 + return gmch_ctrl  25; /* 32 MB units */
 +}
 +
 +typedef size_t (*stolen_size_fn)(int num, int slot, int func);
 +
 +static struct pci_device_id intel_stolen_ids[] __initdata = {
 + INTEL_I915G_IDS(gen3_stolen_size),
 + INTEL_I915GM_IDS(gen3_stolen_size),
 + INTEL_I945G_IDS(gen3_stolen_size),
 + INTEL_I945GM_IDS(gen3_stolen_size),
 + INTEL_VLV_M_IDS(gen3_stolen_size),
 + INTEL_VLV_D_IDS(gen3_stolen_size),
 + 

Re: [Intel-gfx] i915 irq storm mitigation in 3.10

[Egbert Eich]

Hi Jan!

Jan Niggemann writes:
  Hi Egbert,

[...]

Thanks for generating the logs! Hope you had a nice birthday dinner :)

  
  I applied this patch (but not the one you sent on Monday), recompiled 
  and logged:
  uncompressed (8,2M) http://files.hz6.de/kern_20130724.log
  bz2 (288 KB) http://files.hz6.de/kern_20130724.log.bz2

These logs show clearly that we are seeing interrupts which
should be disabled.
Could it be that we we have either the status or enable bits
mixed up? Unfortunately the publically available docs for GEN4
don't show the HOTPLUG_EN and HOTPLUG_STAT registers.

Daniel, could you please help me out here?

Thanks a lot!

Cheers,
Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Jani Nikula]

On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
 On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
 On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
 
  I think a i915 module option should be doable, otoh people seem to have a
  viable workaround by setting a different acpi os version already.
 
 At least the original claim was that if you set a non-windows8 acpi os
 version, you hit other bugs..
 
 But yeah, if we just do a plain revert, that may be the only option
 for the people for whom the current (to-be-reverted) patches made
 things work.

 Well, I wonder what about the appended (untested) patch?

Rafael, before going there, I've been trying to wrap my (poor, rusty
after vacation) head around

commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date:   Thu Jul 18 02:08:06 2013 +0200

ACPI / video / i915: No ACPI backlight if firmware expects Windows 8

and I can't see how it could work.

First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
it's actually set anywhere. Buried deep in the calls from
acpi_video_bus_add(), acpi_video_verify_backlight_support() is used
before acpi_video_backlight_quirks() gets called. (Perhaps if i915 is
reloaded, this goes right as the flags are already set.)

Second, with i915 that has opregion support, __acpi_video_register()
should only ever get called once. Which means the acpi_walk_namespace()
with video_unregister_backlight() should never get called in register.

Please enlighten me.

BR,
Jani.

-- 
Jani Nikula, 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] x86: add early quirk for reserving Intel graphics stolen memory v3

[Chris Wilson]

On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote:
 On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
 Two bikesheds:
 - Can't we give the thing a better name like Intel Graphics Stolen?

Using a custom type and name seems simple enough and naturally leads it
to ending up in iomem_resource.

 - Can't we store the iomem region somewhere so that intel-gtt.ko and
   i915.ko can get at it and we could drop the duplicated stolen detection
   code?

The choice is then walking the resource list looking for our named
region or reading a couple of registers. Certainly walking the iomem makes
everything much clearer.
-Chris

diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index bbae024..5e12db4 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -38,6 +38,7 @@
 #define E820_NVS   4
 #define E820_UNUSABLE  5
 
+#define E820_STOLEN_IGFX 6
 
 /*
  * reserved RAM used by kernel itself
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index d32abea..d8f0e4f 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -149,6 +149,10 @@ static void __init e820_print_type(u32 type)
case E820_UNUSABLE:
printk(KERN_CONT unusable);
break;
+
+   case E820_STOLEN_IGFX:
+   printk(KERN_CONT Intel Graphics Stolen);
+   break;
default:
printk(KERN_CONT type %u, type);
break;
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bff8a6f..27b6d17 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -350,18 +350,10 @@ static void __init intel_graphics_stolen(int num, int 
slot, int func)
size = stolen_size(num, slot, func);
start = intel_stolen_base(num, slot, func);
if (size  start)
-   goto found;
-   else
-   break;
+   e820_add_region(start, size, E820_STOLEN_IGFX);
+   return;
}
}
-
-   /* No match or invalid data, don't bother reserving */
-   return;
-found:
-   /* Mark this space as reserved */
-   e820_add_region(start, size, E820_RESERVED);
-   return;
 }
 
 #define QFLAG_APPLY_ONCE   0x1

-- 
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] x86: add early quirk for reserving Intel graphics stolen memory v3

[Daniel Vetter]

On Thu, Jul 25, 2013 at 09:34:05AM +0100, Chris Wilson wrote:
 On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote:
  On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
  Two bikesheds:
  - Can't we give the thing a better name like Intel Graphics Stolen?
 
 Using a custom type and name seems simple enough and naturally leads it
 to ending up in iomem_resource.
 
  - Can't we store the iomem region somewhere so that intel-gtt.ko and
i915.ko can get at it and we could drop the duplicated stolen detection
code?
 
 The choice is then walking the resource list looking for our named
 region or reading a couple of registers. Certainly walking the iomem makes
 everything much clearer.

Oh, I like this ;-)
-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 6/6] drm/i915: Convert the register access tracepoint to be conditional

[Daniel Vetter]

On Fri, Jul 19, 2013 at 08:36:56PM +0100, Chris Wilson wrote:
 The TRACE_EVENT_CONDITION is supposed to generate more efficient code
 than if (cond) trace(), which is what we are currently using inside the
 register access functions.
 
 v2: Rebase onto uncore
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

Ok, merged the remaining patches in this series. The move functions
around one need a bit of wrestling to fit, but I think I've done it
correctly.
-Daniel

 ---
  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
  drivers/gpu/drm/i915/i915_trace.h   | 8 +---
  drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
  3 files changed, 8 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 0513743..cc3e74a 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -1004,7 +1004,7 @@ static int gen6_drpc_info(struct seq_file *m)
   }
  
   gt_core_status = readl(dev_priv-regs + GEN6_GT_CORE_STATUS);
 - trace_i915_reg_rw(false, GEN6_GT_CORE_STATUS, gt_core_status, 4);
 + trace_i915_reg_rw(false, GEN6_GT_CORE_STATUS, gt_core_status, 4, true);
  
   rpmodectl1 = I915_READ(GEN6_RP_CONTROL);
   rcctl1 = I915_READ(GEN6_RC_CONTROL);
 diff --git a/drivers/gpu/drm/i915/i915_trace.h 
 b/drivers/gpu/drm/i915/i915_trace.h
 index 7d283b5..2933e2f 100644
 --- a/drivers/gpu/drm/i915/i915_trace.h
 +++ b/drivers/gpu/drm/i915/i915_trace.h
 @@ -406,10 +406,12 @@ TRACE_EVENT(i915_flip_complete,
   TP_printk(plane=%d, obj=%p, __entry-plane, __entry-obj)
  );
  
 -TRACE_EVENT(i915_reg_rw,
 - TP_PROTO(bool write, u32 reg, u64 val, int len),
 +TRACE_EVENT_CONDITION(i915_reg_rw,
 + TP_PROTO(bool write, u32 reg, u64 val, int len, bool trace),
  
 - TP_ARGS(write, reg, val, len),
 + TP_ARGS(write, reg, val, len, trace),
 +
 + TP_CONDITION(trace),
  
   TP_STRUCT__entry(
   __field(u64, val)
 diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
 b/drivers/gpu/drm/i915/intel_uncore.c
 index 2c39467..b2703db 100644
 --- a/drivers/gpu/drm/i915/intel_uncore.c
 +++ b/drivers/gpu/drm/i915/intel_uncore.c
 @@ -361,7 +361,7 @@ u##x i915_read##x(struct drm_i915_private *dev_priv, u32 
 reg, bool trace) { \
   val = __raw_i915_read##x(dev_priv, reg); \
   } \
   spin_unlock_irqrestore(dev_priv-uncore.lock, irqflags); \
 - if (trace) trace_i915_reg_rw(false, reg, val, sizeof(val)); \
 + trace_i915_reg_rw(false, reg, val, sizeof(val), trace); \
   return val; \
  }
  
 @@ -375,7 +375,7 @@ __i915_read(64)
  void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x val, 
 bool trace) { \
   unsigned long irqflags; \
   u32 __fifo_ret = 0; \
 - if (trace) trace_i915_reg_rw(true, reg, val, sizeof(val)); \
 + trace_i915_reg_rw(true, reg, val, sizeof(val), trace); \
   spin_lock_irqsave(dev_priv-uncore.lock, irqflags); \
   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
   __fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
 -- 
 1.8.3.2
 
 ___
 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] drm/i915: fix the racy object accounting

[Daniel Vetter]

On Wed, Jul 24, 2013 at 11:01:08PM +0100, Chris Wilson wrote:
 On Wed, Jul 24, 2013 at 10:40:23PM +0200, Daniel Vetter wrote:
  Just use a spinlock to protect them.
  
  v2: Rebase onto the new object create refcount fix patch.
  
  v3: Don't kill dev_priv-mm.object_memory as requested by Chris and
  hence just use a spinlock instead of atomic_t.
  
  Cc: Chris Wilson ch...@chris-wilson.co.uk
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 Sadly, I have no better answer to my desire have my cake and eat it.
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

Queued for -next, thanks for the review.
-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 1/3] x86: Use a custom name for the Intel Graphics Stolen reservation

[Chris Wilson]

By giving the stolen a region a unique type and name, we then insert it
into the iomem_resource as a known resource. This clear identifies it to
the user when printing the e820 map (and later the iomem resources), and
exposes it to the driver for later use.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 arch/x86/include/uapi/asm/e820.h |  2 ++
 arch/x86/kernel/e820.c   |  4 
 arch/x86/kernel/early-quirks.c   | 12 ++--
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index bbae024..72384ce 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -38,6 +38,8 @@
 #define E820_NVS   4
 #define E820_UNUSABLE  5
 
+#define E820_STOLEN_IGFX 6
+#define E820_STOLEN_IGFX_STRING Intel Graphics Stolen
 
 /*
  * reserved RAM used by kernel itself
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index d32abea..ce4b448 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -149,6 +149,10 @@ static void __init e820_print_type(u32 type)
case E820_UNUSABLE:
printk(KERN_CONT unusable);
break;
+
+   case E820_STOLEN_IGFX:
+   printk(KERN_CONT E820_STOLEN_IGFX_STRING);
+   break;
default:
printk(KERN_CONT type %u, type);
break;
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bff8a6f..27b6d17 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -350,18 +350,10 @@ static void __init intel_graphics_stolen(int num, int 
slot, int func)
size = stolen_size(num, slot, func);
start = intel_stolen_base(num, slot, func);
if (size  start)
-   goto found;
-   else
-   break;
+   e820_add_region(start, size, E820_STOLEN_IGFX);
+   return;
}
}
-
-   /* No match or invalid data, don't bother reserving */
-   return;
-found:
-   /* Mark this space as reserved */
-   e820_add_region(start, size, E820_RESERVED);
-   return;
 }
 
 #define QFLAG_APPLY_ONCE   0x1
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] resource: Introduce lookup_resource_by_name()

[Chris Wilson]

This is useful for drivers to find a resource inserted by, for example,
an early PCI quirk.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 include/linux/ioport.h |  2 ++
 kernel/resource.c  | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 89b7c24..acad72f 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -158,6 +158,8 @@ extern int allocate_resource(struct resource *root, struct 
resource *new,
   resource_size_t),
 void *alignf_data);
 struct resource *lookup_resource(struct resource *root, resource_size_t start);
+struct resource *lookup_resource_by_name(struct resource *root,
+const char *name);
 int adjust_resource(struct resource *res, resource_size_t start,
resource_size_t size);
 resource_size_t resource_alignment(struct resource *res);
diff --git a/kernel/resource.c b/kernel/resource.c
index 3f285dc..9cc1bb8 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -624,6 +624,20 @@ struct resource *lookup_resource(struct resource *root, 
resource_size_t start)
return res;
 }
 
+struct resource *lookup_resource_by_name(struct resource *root, const char 
*name)
+{
+   struct resource *res;
+
+   read_lock(resource_lock);
+   for (res = root-child; res; res = res-sibling) {
+   if (strcmp(res-name, name) == 0)
+   break;
+   }
+   read_unlock(resource_lock);
+
+   return res;
+}
+
 /*
  * Insert a resource into the resource tree. If successful, return NULL,
  * otherwise return the conflicting resource (compare to __request_resource())
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915: Lookup stolen region reserved during early PCI quirk processing

[Chris Wilson]

As we now hook into the early PCI quirk table to earmark the Intel
Graphics Stolen region (inserting it into the iomem_resource) to prevent
it conflicting with any later resource allocations, we can simply walk
the iomem_resource tree and find it for our use. Thereby removing all of
our own code to define the stolen region.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/char/agp/intel-gtt.c   | 92 +++---
 drivers/gpu/drm/i915/i915_drv.h|  3 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 15 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c | 70 ++
 include/drm/intel-gtt.h|  2 +-
 5 files changed, 26 insertions(+), 156 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index b8e2014..fe31280 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -343,90 +343,15 @@ static const struct aper_size_info_fixed 
intel_fake_agp_sizes[] = {
 
 static unsigned int intel_gtt_stolen_size(void)
 {
-   u16 gmch_ctrl;
-   u8 rdct;
-   int local = 0;
-   static const int ddt[4] = { 0, 16, 32, 64 };
-   unsigned int stolen_size = 0;
-
-   if (INTEL_GTT_GEN == 1)
-   return 0; /* no stolen mem on i81x */
-
-   pci_read_config_word(intel_private.bridge_dev,
-I830_GMCH_CTRL, gmch_ctrl);
+   struct resource *r;
+   unsigned int stolen_size;
 
-   if (intel_private.bridge_dev-device == PCI_DEVICE_ID_INTEL_82830_HB ||
-   intel_private.bridge_dev-device == PCI_DEVICE_ID_INTEL_82845G_HB) {
-   switch (gmch_ctrl  I830_GMCH_GMS_MASK) {
-   case I830_GMCH_GMS_STOLEN_512:
-   stolen_size = KB(512);
-   break;
-   case I830_GMCH_GMS_STOLEN_1024:
-   stolen_size = MB(1);
-   break;
-   case I830_GMCH_GMS_STOLEN_8192:
-   stolen_size = MB(8);
-   break;
-   case I830_GMCH_GMS_LOCAL:
-   rdct = 
readb(intel_private.registers+I830_RDRAM_CHANNEL_TYPE);
-   stolen_size = (I830_RDRAM_ND(rdct) + 1) *
-   MB(ddt[I830_RDRAM_DDT(rdct)]);
-   local = 1;
-   break;
-   default:
-   stolen_size = 0;
-   break;
-   }
-   } else {
-   switch (gmch_ctrl  I855_GMCH_GMS_MASK) {
-   case I855_GMCH_GMS_STOLEN_1M:
-   stolen_size = MB(1);
-   break;
-   case I855_GMCH_GMS_STOLEN_4M:
-   stolen_size = MB(4);
-   break;
-   case I855_GMCH_GMS_STOLEN_8M:
-   stolen_size = MB(8);
-   break;
-   case I855_GMCH_GMS_STOLEN_16M:
-   stolen_size = MB(16);
-   break;
-   case I855_GMCH_GMS_STOLEN_32M:
-   stolen_size = MB(32);
-   break;
-   case I915_GMCH_GMS_STOLEN_48M:
-   stolen_size = MB(48);
-   break;
-   case I915_GMCH_GMS_STOLEN_64M:
-   stolen_size = MB(64);
-   break;
-   case G33_GMCH_GMS_STOLEN_128M:
-   stolen_size = MB(128);
-   break;
-   case G33_GMCH_GMS_STOLEN_256M:
-   stolen_size = MB(256);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_96M:
-   stolen_size = MB(96);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_160M:
-   stolen_size = MB(160);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_224M:
-   stolen_size = MB(224);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_352M:
-   stolen_size = MB(352);
-   break;
-   default:
-   stolen_size = 0;
-   break;
-   }
-   }
+   r = lookup_resource_by_name(iomem_resource, E820_STOLEN_IGFX_STRING);
 
-   if (stolen_size  0) {
-   dev_info(intel_private.bridge_dev-dev, detected %dK %s 
memory\n,
-  stolen_size / KB(1), local ? local : stolen);
+   if (r) {
+   stolen_size = r-end - r-start + 1;
+   dev_info(intel_private.bridge_dev-dev, detected %dK stolen 
memory\n,
+  stolen_size / KB(1));
} else {
dev_info(intel_private.bridge_dev-dev,
   no pre-allocated video memory detected\n);
@@ -1404,11 +1329,10 @@ int intel_gmch_probe(struct pci_dev 

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Jani Nikula]

On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
 jani.nik...@linux.intel.com wrote:
 On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
 Hi all,

 Changes since 20130724:

 Removed tree:
 arm-dt (at maintainer's request)

 The wireless-next tree lost its build failure and gained a conflict
 against Linus' tree.

 The tty tree lost its build failure.

 The staging tree gained a build failure for which I disabled a driver.

 


 [ CCing drm and drm-intel folks ]

 With today's next-20130725 I see the following:

 Use of dev_priv-gt_lock in I915_WRITE through
 intel_disable_gt_powersave before spin lock init, caused by

 commit 181d1b9e31c668259d3798c521672afb8edd355c
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Sun Jul 21 13:16:24 2013 +0200

 drm/i915: fix up gt init sequence fallout


 Ah, cool.

 I assumed/tested drm/i915: fix the racy object accounting, but this
 does not fix it.
 Will try with yours.


 Sorry, Jani.

 next-20130725 ships the patch you pointed, too.

Confused. I meant that the above mentioned commit drm/i915: fix up gt
init sequence fallout causes the problem. The patch I included in my
mail should fix it. Could you try that please?

BR,
Jani.




 - Sedat -

 [1] 
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130725qt=grepq=drm%2Fi915%3A+fix+up+gt+init+sequence+fallout
 [2] 
 http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=181d1b9e31c668259d3798c521672afb8edd355c


-- 
Jani Nikula, 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] i915 irq storm mitigation in 3.10

[Egbert Eich]

Daniel Vetter writes:
  
  I've checked the docs again for gm45 and we seem to have the right
  values. But on early gen4 (i.e. i965g/gm) the Bspec has been wrong
  about these, so I wouldn't be surprised at all if they're wrong for
  the digital ports on gm45, too.
  
  Iirc we've already had a case like that, but there was no real
  conclusion (and atm I can't find the bug). Can you pls try the below
  patch (on top of Egbert's debug stuff)?
  
If this doesn't help, lets disable all the digital ports together for
testing.

  
  
  Egbert I think your debug patch has fairly useful information for
  debugging the storm code in general, can you please submit a patch
  against drm-intel-nightly?
  

Will do :)

Cheers,
Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: do not disable backlight on vgaswitcheroo switch off

[Jani Nikula]

On muxed systems, the other vgaswitcheroo client may depend on i915 to
handle the backlight. We began switching off the backlight since

commit a261b246ebd552fd5d5a8ed84cc931bb821c427f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Thu Jul 26 19:21:47 2012 +0200

drm/i915: disable all crtcs at suspend time

breaking backlight on discreet graphics in (some) muxed systems.

Keep the backlight on when the state is changed through vgaswitcheroo.

Note: The alternative would be to add a quirk table to achieve the same
based on system identifiers, but AFAICS it would asymptotically approach
effectively the same as this patch as more IDs are added, but with the
maintenance burden of the quirk table.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55311
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59785
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_panel.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 67e2c1f..1062154 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -515,6 +515,17 @@ void intel_panel_disable_backlight(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long flags;
 
+   /*
+* Do not disable backlight on the vgaswitcheroo path. When switching
+* away from i915, the other client may depend on i915 to handle the
+* backlight. This will leave the backlight on unnecessarily when
+* another client is not activated.
+*/
+   if (dev-switch_power_state == DRM_SWITCH_POWER_CHANGING) {
+   DRM_DEBUG_DRIVER(Skipping backlight disable on vga switch\n);
+   return;
+   }
+
spin_lock_irqsave(dev_priv-backlight.lock, flags);
 
dev_priv-backlight.enabled = false;
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
 On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
  On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
  On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter daniel.vet...@ffwll.ch 
  wrote:
  
   I think a i915 module option should be doable, otoh people seem to have a
   viable workaround by setting a different acpi os version already.
  
  At least the original claim was that if you set a non-windows8 acpi os
  version, you hit other bugs..
  
  But yeah, if we just do a plain revert, that may be the only option
  for the people for whom the current (to-be-reverted) patches made
  things work.
 
  Well, I wonder what about the appended (untested) patch?
 
 Rafael, before going there, I've been trying to wrap my (poor, rusty
 after vacation) head around
 
 commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
 Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Date:   Thu Jul 18 02:08:06 2013 +0200
 
 ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
 
 and I can't see how it could work.

Well, if it didn't work, people wouldn't see either improvement or breakage
from it, but they do see that, so it evidently works. :-)

 First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
 it's actually set anywhere.

Are you sure about that?

acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
means that acpi_video_bus_add() can only be called *after* acpi_video_bus
has been registered with the ACPI subsystem (and the driver core).  That
is done by acpi_bus_register_driver() and, guess what?, this happens in
__acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run before
__acpi_video_register().

 Buried deep in the calls from
 acpi_video_bus_add(), acpi_video_verify_backlight_support() is used
 before acpi_video_backlight_quirks() gets called. (Perhaps if i915 is
 reloaded, this goes right as the flags are already set.)

Please see above.

 Second, with i915 that has opregion support, __acpi_video_register()
 should only ever get called once. Which means the acpi_walk_namespace()
 with video_unregister_backlight() should never get called in register.
 
 Please enlighten me.

Actually, that's correct, so we don't need the whole
video_unregister_backlight() thing, calling acpi_video_backlight_quirks() would
be sufficient.

Ah, one more reason to do a full revert.  I'm thinking, though, that I'll leave
acpi_video_backlight_quirks() as is so that it can be used by
acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
problems to happen.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Jani Nikula]

On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
 On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
 On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
  Well, I wonder what about the appended (untested) patch?
 
 Rafael, before going there, I've been trying to wrap my (poor, rusty
 after vacation) head around
 
 commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
 Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Date:   Thu Jul 18 02:08:06 2013 +0200
 
 ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
 
 and I can't see how it could work.

 Well, if it didn't work, people wouldn't see either improvement or breakage
 from it, but they do see that, so it evidently works. :-)

I didn't claim it didn't work, just that *I* didn't see how it could. ;)

 First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
 it's actually set anywhere.

 Are you sure about that?

 acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
 in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
 means that acpi_video_bus_add() can only be called *after* acpi_video_bus
 has been registered with the ACPI subsystem (and the driver core).  That
 is done by acpi_bus_register_driver() and, guess what?, this happens in
 __acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run before
 __acpi_video_register().

Right. I totally missed the call within the ternary operator. Thanks for
the explanation, and apologies for the noise.

 Second, with i915 that has opregion support, __acpi_video_register()
 should only ever get called once. Which means the acpi_walk_namespace()
 with video_unregister_backlight() should never get called in register.
 
 Please enlighten me.

 Actually, that's correct, so we don't need the whole
 video_unregister_backlight() thing, calling acpi_video_backlight_quirks() 
 would
 be sufficient.

 Ah, one more reason to do a full revert.  I'm thinking, though, that I'll 
 leave
 acpi_video_backlight_quirks() as is so that it can be used by
 acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
 problems to happen.

I observe that for the regular non-quirk acpi_video_register() call,
acpi_video_backlight_quirks() won't be called during register, but it
will get called later. This might have subtle effects later on, don't
you think?

As to the original problem, and your patch in this thread, what do you
think about having another value in acpi_backlight kernel parameter for
it? Having an i915 module parameter to tell acpi to use or not use
quirks seems odd, since the i915 is not really taking over
anything. It's just passing the info on to acpi.

BR,
Jani.

-- 
Jani Nikula, 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] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:
 On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
  On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
  On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
   Well, I wonder what about the appended (untested) patch?
  
  Rafael, before going there, I've been trying to wrap my (poor, rusty
  after vacation) head around
  
  commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
  Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
  Date:   Thu Jul 18 02:08:06 2013 +0200
  
  ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
  
  and I can't see how it could work.
 
  Well, if it didn't work, people wouldn't see either improvement or breakage
  from it, but they do see that, so it evidently works. :-)
 
 I didn't claim it didn't work, just that *I* didn't see how it could. ;)
 
  First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
  it's actually set anywhere.
 
  Are you sure about that?
 
  acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
  in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
  means that acpi_video_bus_add() can only be called *after* acpi_video_bus
  has been registered with the ACPI subsystem (and the driver core).  That
  is done by acpi_bus_register_driver() and, guess what?, this happens in
  __acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run 
  before
  __acpi_video_register().
 
 Right. I totally missed the call within the ternary operator. Thanks for
 the explanation, and apologies for the noise.
 
  Second, with i915 that has opregion support, __acpi_video_register()
  should only ever get called once. Which means the acpi_walk_namespace()
  with video_unregister_backlight() should never get called in register.
  
  Please enlighten me.
 
  Actually, that's correct, so we don't need the whole
  video_unregister_backlight() thing, calling acpi_video_backlight_quirks() 
  would
  be sufficient.
 
  Ah, one more reason to do a full revert.  I'm thinking, though, that I'll 
  leave
  acpi_video_backlight_quirks() as is so that it can be used by
  acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
  problems to happen.
 
 I observe that for the regular non-quirk acpi_video_register() call,
 acpi_video_backlight_quirks() won't be called during register, but it
 will get called later. This might have subtle effects later on, don't
 you think?

Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIGHT it should be OK.

 As to the original problem, and your patch in this thread, what do you
 think about having another value in acpi_backlight kernel parameter for
 it? Having an i915 module parameter to tell acpi to use or not use
 quirks seems odd, since the i915 is not really taking over
 anything. It's just passing the info on to acpi.

I agree, I'm going to send a full revert in a while and we'll think what to
do about all that later.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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] Linux 3.11-rc2 (acpi backlight, revert)

[Rafael J. Wysocki]

On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
 On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
  On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:
  
   Linus, do you want me to send a pull request reverting 8c5bd7a and 
   efaa14c?
  
  Yes, but let's wait a while. Not because I think we'll fix the problem
  (hey, miracles might happen), but because I think it would be useful
  to couple the reverts with information about the particular machines
  that broke (and the people who reported it). So that when we
  inevitably try again, we can perhaps get some testing effort with
  those machines/people.
  
  It doesn't seem to be a show-stopped for a large number of people, so
  there's no huge hurry. I'd suggest doing the revert just in time for
  rc3, but waiting until then to gather info about people who see
  breakage.
  
  Sound like a plan?
 
 Yes, it does.

OK, time to revert I guess.

James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
fixes the backlight for you.

Aaron, please double check if acpi_video_backlight_quirks() will still work as
needed.

Thanks,
Rafael


---
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: Revert ACPI / video / i915: No ACPI backlight if firmware expects 
Windows 8

We attempted to address a regression introduced by commit a57f7f9
(ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
ACPI video backlight support doesn't work on a number of systems,
because the relevant AML methods in the ACPI tables in their BIOSes
become useless after the BIOS has been told that the OS is compatible
with Windows 8.  That problem is tracked by the bug entry at:

https://bugzilla.kernel.org/show_bug.cgi?id=51231

Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
expects Windows 8) introduced for this purpose essentially prevented
the ACPI backlight support from being used if the BIOS had been told
that the OS was compatible with Windows 8 and the i915 driver was
loaded, in which case the backlight would always be handled by i915.
Unfortunately, however, that turned out to cause problems with
backlight to appear on multiple systems with symptoms indicating that
i915 was unable to control the backlight on those systems as
expected.

For this reason, revert commit 8c5bd7a, but leave the function
acpi_video_backlight_quirks() introduced by it, because another
commit on top of it uses that function.

References: https://lkml.org/lkml/2013/7/21/119
References: https://lkml.org/lkml/2013/7/22/261
References: https://lkml.org/lkml/2013/7/23/429
References: https://lkml.org/lkml/2013/7/23/459
References: https://lkml.org/lkml/2013/7/23/81
References: https://lkml.org/lkml/2013/7/24/27
Reported-by: James Hogan ja...@albanarts.com
Reported-by: Steven Newbury st...@snewbury.org.uk
Reported-by: Kamal Mostafa ka...@canonical.com
Reported-by: Martin Steigerwald mar...@lichtvoll.de
Reported-by: Jörg Otte jrg.o...@gmail.com
Reported-by: Kalle Valo kv...@adurom.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
 drivers/acpi/internal.h |2 -
 drivers/acpi/video.c|   67 
 drivers/acpi/video_detect.c |   15 
 drivers/gpu/drm/i915/i915_dma.c |2 -
 include/acpi/video.h|   11 --
 include/linux/acpi.h|1 
 6 files changed, 11 insertions(+), 87 deletions(-)

Index: linux-pm/drivers/acpi/video.c
===
--- linux-pm.orig/drivers/acpi/video.c
+++ linux-pm/drivers/acpi/video.c
@@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s
if (acpi_video_init_brightness(device))
return;
 
-   if (acpi_video_verify_backlight_support()) {
+   if (acpi_video_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
@@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi
unsigned long long level_current, level_next;
int result = -EINVAL;
 
-   /* no warning message if acpi_backlight=vendor or a quirk is used */
-   if (!acpi_video_verify_backlight_support())
+   /* no warning message if acpi_backlight=vendor is used */
+   if (!acpi_video_backlight_support())
return 0;
 
if (!device-brightness)
@@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct
return 0;
 }
 
-static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
- void *context, void **rv)
-{
-   struct acpi_device *acpi_dev;
-   struct acpi_video_bus *video;
-   struct acpi_video_device *dev, *next;
-
-   if (acpi_bus_get_device(handle, acpi_dev))
-   return AE_OK;
-
-   if (acpi_match_device_ids(acpi_dev, video_device_ids))
-   return AE_OK;
-
-   video 

[Intel-gfx] [PATCH] drm/i915: dvo_ch7xxx: fix vsync polarity setting

[Imre Deak]

This fixes a typo which set the wrong vsync and possibly also hsync
polarity for any modes with positive vsync polarity.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/dvo_ch7xxx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c 
b/drivers/gpu/drm/i915/dvo_ch7xxx.c
index 757e0fa..af42e94 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -307,7 +307,7 @@ static void ch7xxx_mode_set(struct intel_dvo_device *dvo,
idf |= CH7xxx_IDF_HSP;
 
if (mode-flags  DRM_MODE_FLAG_PVSYNC)
-   idf |= CH7xxx_IDF_HSP;
+   idf |= CH7xxx_IDF_VSP;
 
ch7xxx_writeb(dvo, CH7xxx_IDF, idf);
 }
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Daniel Vetter]

On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
 jani.nik...@linux.intel.com wrote:
  On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
  On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek sedat.di...@gmail.com 
  wrote:
  On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
  jani.nik...@linux.intel.com wrote:
  On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
  On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell 
  s...@canb.auug.org.au wrote:
  Hi all,
 
  Changes since 20130724:
 
  Removed tree:
  arm-dt (at maintainer's request)
 
  The wireless-next tree lost its build failure and gained a conflict
  against Linus' tree.
 
  The tty tree lost its build failure.
 
  The staging tree gained a build failure for which I disabled a driver.
 
  
 
 
  [ CCing drm and drm-intel folks ]
 
  With today's next-20130725 I see the following:
 
  Use of dev_priv-gt_lock in I915_WRITE through
  intel_disable_gt_powersave before spin lock init, caused by
 
  commit 181d1b9e31c668259d3798c521672afb8edd355c
  Author: Daniel Vetter daniel.vet...@ffwll.ch
  Date:   Sun Jul 21 13:16:24 2013 +0200
 
  drm/i915: fix up gt init sequence fallout
 
 
  Ah, cool.
 
  I assumed/tested drm/i915: fix the racy object accounting, but this
  does not fix it.
  Will try with yours.
 
 
  Sorry, Jani.
 
  next-20130725 ships the patch you pointed, too.
 
  Confused. I meant that the above mentioned commit drm/i915: fix up gt
  init sequence fallout causes the problem. The patch I included in my
  mail should fix it. Could you try that please?
 
 
 [ Note2myself: Do not read half of the message... ]
 
 The bad... Your patch needed some refresh against next-20130725 (guess
 it's against drm-intel-nightly).
 
 The good... YES, your patch fixes the issue for me!
 
 The ugly... /me.
 
 Feel free to add my:
 
Tested-by: Sedat Dilek sedat.di...@gmail.com
 
 Thanks for the quick fix!

Thanks a lot for the report, since this should be something I should have
caught. And for added insult the offending patch is already in Linus' tree
:( Patch merged to -fixes.
-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: dvo_ch7xxx: fix vsync polarity setting

[Chris Wilson]

On Thu, Jul 25, 2013 at 04:22:31PM +0300, Imre Deak wrote:
 This fixes a typo which set the wrong vsync and possibly also hsync
 polarity for any modes with positive vsync polarity.

Note that this typo exists in the very first import of KMS:
commit 79e539453b34e35f39299a899d263b0a1f1670bd
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Fri Nov 7 14:24:08 2008 -0800

DRM: i915: add mode setting support

 Signed-off-by: Imre Deak imre.d...@intel.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: dvo_ch7xxx: fix vsync polarity setting

[Daniel Vetter]

On Thu, Jul 25, 2013 at 02:45:05PM +0100, Chris Wilson wrote:
 On Thu, Jul 25, 2013 at 04:22:31PM +0300, Imre Deak wrote:
  This fixes a typo which set the wrong vsync and possibly also hsync
  polarity for any modes with positive vsync polarity.
 
 Note that this typo exists in the very first import of KMS:
 commit 79e539453b34e35f39299a899d263b0a1f1670bd
 Author: Jesse Barnes jbar...@virtuousgeek.org
 Date:   Fri Nov 7 14:24:08 2008 -0800
 
 DRM: i915: add mode setting support
 
  Signed-off-by: Imre Deak imre.d...@intel.com
 Cc: Jesse Barnes jbar...@virtuousgeek.org
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

Queued for -next, thanks for the patch.
-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] Linux 3.11-rc2 (acpi backlight, revert)

[Aaron Lu]

On Thu, Jul 25, 2013 at 9:00 PM, Rafael J. Wysocki r...@sisk.pl wrote:

 On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
  On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
   On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl
 wrote:
   
Linus, do you want me to send a pull request reverting 8c5bd7a and
 efaa14c?
  
   Yes, but let's wait a while. Not because I think we'll fix the problem
   (hey, miracles might happen), but because I think it would be useful
   to couple the reverts with information about the particular machines
   that broke (and the people who reported it). So that when we
   inevitably try again, we can perhaps get some testing effort with
   those machines/people.
  
   It doesn't seem to be a show-stopped for a large number of people, so
   there's no huge hurry. I'd suggest doing the revert just in time for
   rc3, but waiting until then to gather info about people who see
   breakage.
  
   Sound like a plan?
 
  Yes, it does.

 OK, time to revert I guess.

 James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
 patch
 fixes the backlight for you.

 Aaron, please double check if acpi_video_backlight_quirks() will still
 work as
 needed.


Yes, I think so.

Thanks,
Aaron



 Thanks,
 Rafael


 ---
 From: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Subject: Revert ACPI / video / i915: No ACPI backlight if firmware
 expects Windows 8

 We attempted to address a regression introduced by commit a57f7f9
 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
 ACPI video backlight support doesn't work on a number of systems,
 because the relevant AML methods in the ACPI tables in their BIOSes
 become useless after the BIOS has been told that the OS is compatible
 with Windows 8.  That problem is tracked by the bug entry at:

 https://bugzilla.kernel.org/show_bug.cgi?id=51231

 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
 expects Windows 8) introduced for this purpose essentially prevented
 the ACPI backlight support from being used if the BIOS had been told
 that the OS was compatible with Windows 8 and the i915 driver was
 loaded, in which case the backlight would always be handled by i915.
 Unfortunately, however, that turned out to cause problems with
 backlight to appear on multiple systems with symptoms indicating that
 i915 was unable to control the backlight on those systems as
 expected.

 For this reason, revert commit 8c5bd7a, but leave the function
 acpi_video_backlight_quirks() introduced by it, because another
 commit on top of it uses that function.

 References: https://lkml.org/lkml/2013/7/21/119
 References: https://lkml.org/lkml/2013/7/22/261
 References: https://lkml.org/lkml/2013/7/23/429
 References: https://lkml.org/lkml/2013/7/23/459
 References: https://lkml.org/lkml/2013/7/23/81
 References: https://lkml.org/lkml/2013/7/24/27
 Reported-by: James Hogan ja...@albanarts.com
 Reported-by: Steven Newbury st...@snewbury.org.uk
 Reported-by: Kamal Mostafa ka...@canonical.com
 Reported-by: Martin Steigerwald mar...@lichtvoll.de
 Reported-by: Jörg Otte jrg.o...@gmail.com
 Reported-by: Kalle Valo kv...@adurom.com
 Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 ---
  drivers/acpi/internal.h |2 -
  drivers/acpi/video.c|   67
 
  drivers/acpi/video_detect.c |   15 
  drivers/gpu/drm/i915/i915_dma.c |2 -
  include/acpi/video.h|   11 --
  include/linux/acpi.h|1
  6 files changed, 11 insertions(+), 87 deletions(-)

 Index: linux-pm/drivers/acpi/video.c
 ===
 --- linux-pm.orig/drivers/acpi/video.c
 +++ linux-pm/drivers/acpi/video.c
 @@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s
 if (acpi_video_init_brightness(device))
 return;

 -   if (acpi_video_verify_backlight_support()) {
 +   if (acpi_video_backlight_support()) {
 struct backlight_properties props;
 struct pci_dev *pdev;
 acpi_handle acpi_parent;
 @@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi
 unsigned long long level_current, level_next;
 int result = -EINVAL;

 -   /* no warning message if acpi_backlight=vendor or a quirk is used
 */
 -   if (!acpi_video_verify_backlight_support())
 +   /* no warning message if acpi_backlight=vendor is used */
 +   if (!acpi_video_backlight_support())
 return 0;

 if (!device-brightness)
 @@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct
 return 0;
  }

 -static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
 - void *context, void **rv)
 -{
 -   struct acpi_device *acpi_dev;
 -   struct acpi_video_bus *video;
 -   struct acpi_video_device 

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
 jani.nik...@linux.intel.com wrote:
  On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
  On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek sedat.di...@gmail.com 
  wrote:
  On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
  jani.nik...@linux.intel.com wrote:
  On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
  On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell 
  s...@canb.auug.org.au wrote:
  Hi all,
 
  Changes since 20130724:
 
  Removed tree:
  arm-dt (at maintainer's request)
 
  The wireless-next tree lost its build failure and gained a conflict
  against Linus' tree.
 
  The tty tree lost its build failure.
 
  The staging tree gained a build failure for which I disabled a driver.
 
  
 
 
  [ CCing drm and drm-intel folks ]
 
  With today's next-20130725 I see the following:
 
  Use of dev_priv-gt_lock in I915_WRITE through
  intel_disable_gt_powersave before spin lock init, caused by
 
  commit 181d1b9e31c668259d3798c521672afb8edd355c
  Author: Daniel Vetter daniel.vet...@ffwll.ch
  Date:   Sun Jul 21 13:16:24 2013 +0200
 
  drm/i915: fix up gt init sequence fallout
 
 
  Ah, cool.
 
  I assumed/tested drm/i915: fix the racy object accounting, but this
  does not fix it.
  Will try with yours.
 
 
  Sorry, Jani.
 
  next-20130725 ships the patch you pointed, too.
 
  Confused. I meant that the above mentioned commit drm/i915: fix up gt
  init sequence fallout causes the problem. The patch I included in my
  mail should fix it. Could you try that please?
 

 [ Note2myself: Do not read half of the message... ]

 The bad... Your patch needed some refresh against next-20130725 (guess
 it's against drm-intel-nightly).

 The good... YES, your patch fixes the issue for me!

 The ugly... /me.

 Feel free to add my:

Tested-by: Sedat Dilek sedat.di...@gmail.com

 Thanks for the quick fix!

 Thanks a lot for the report, since this should be something I should have
 caught. And for added insult the offending patch is already in Linus' tree
 :( Patch merged to -fixes.

Hmmm, don't you merge -fixes into -nightly?

- Sedat -

 -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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Daniel Vetter]

On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
  On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
  jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek sedat.di...@gmail.com 
   wrote:
   On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
   jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell 
   s...@canb.auug.org.au wrote:
   Hi all,
  
   Changes since 20130724:
  
   Removed tree:
   arm-dt (at maintainer's request)
  
   The wireless-next tree lost its build failure and gained a conflict
   against Linus' tree.
  
   The tty tree lost its build failure.
  
   The staging tree gained a build failure for which I disabled a 
   driver.
  
   
  
  
   [ CCing drm and drm-intel folks ]
  
   With today's next-20130725 I see the following:
  
   Use of dev_priv-gt_lock in I915_WRITE through
   intel_disable_gt_powersave before spin lock init, caused by
  
   commit 181d1b9e31c668259d3798c521672afb8edd355c
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Sun Jul 21 13:16:24 2013 +0200
  
   drm/i915: fix up gt init sequence fallout
  
  
   Ah, cool.
  
   I assumed/tested drm/i915: fix the racy object accounting, but this
   does not fix it.
   Will try with yours.
  
  
   Sorry, Jani.
  
   next-20130725 ships the patch you pointed, too.
  
   Confused. I meant that the above mentioned commit drm/i915: fix up gt
   init sequence fallout causes the problem. The patch I included in my
   mail should fix it. Could you try that please?
  
 
  [ Note2myself: Do not read half of the message... ]
 
  The bad... Your patch needed some refresh against next-20130725 (guess
  it's against drm-intel-nightly).
 
  The good... YES, your patch fixes the issue for me!
 
  The ugly... /me.
 
  Feel free to add my:
 
 Tested-by: Sedat Dilek sedat.di...@gmail.com
 
  Thanks for the quick fix!
 
  Thanks a lot for the report, since this should be something I should have
  caught. And for added insult the offending patch is already in Linus' tree
  :( Patch merged to -fixes.
 
 Hmmm, don't you merge -fixes into -nightly?

I do, but it seems to only blow up with spinlock debugging enabling I
think. Our QA should run full debug buils in the -nightly testing, but
apparently they didn't catch this. I'm looking into what went wrong here
and fix up the process.
-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] Linux 3.11-rc2 (acpi backlight, revert)

[Kamal Mostafa]

On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
 On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
  On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
   On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:
   
Linus, do you want me to send a pull request reverting 8c5bd7a and 
efaa14c?
   
   Yes, but let's wait a while. Not because I think we'll fix the problem
   (hey, miracles might happen), but because I think it would be useful
   to couple the reverts with information about the particular machines
   that broke (and the people who reported it). So that when we
   inevitably try again, we can perhaps get some testing effort with
   those machines/people.
   
   It doesn't seem to be a show-stopped for a large number of people, so
   there's no huge hurry. I'd suggest doing the revert just in time for
   rc3, but waiting until then to gather info about people who see
   breakage.
   
   Sound like a plan?
  
  Yes, it does.
 
 OK, time to revert I guess.
 
 James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
 fixes the backlight for you.

Yes, this revert patch does re-enable backlight control for the affected
Dell XPS13 models.

 -Kamal


 Aaron, please double check if acpi_video_backlight_quirks() will still work as
 needed.
 
 Thanks,
 Rafael
 
 
 ---
 From: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Subject: Revert ACPI / video / i915: No ACPI backlight if firmware expects 
 Windows 8
 
 We attempted to address a regression introduced by commit a57f7f9
 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
 ACPI video backlight support doesn't work on a number of systems,
 because the relevant AML methods in the ACPI tables in their BIOSes
 become useless after the BIOS has been told that the OS is compatible
 with Windows 8.  That problem is tracked by the bug entry at:
 
 https://bugzilla.kernel.org/show_bug.cgi?id=51231
 
 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
 expects Windows 8) introduced for this purpose essentially prevented
 the ACPI backlight support from being used if the BIOS had been told
 that the OS was compatible with Windows 8 and the i915 driver was
 loaded, in which case the backlight would always be handled by i915.
 Unfortunately, however, that turned out to cause problems with
 backlight to appear on multiple systems with symptoms indicating that
 i915 was unable to control the backlight on those systems as
 expected.
 
 For this reason, revert commit 8c5bd7a, but leave the function
 acpi_video_backlight_quirks() introduced by it, because another
 commit on top of it uses that function.
 
 References: https://lkml.org/lkml/2013/7/21/119
 References: https://lkml.org/lkml/2013/7/22/261
 References: https://lkml.org/lkml/2013/7/23/429
 References: https://lkml.org/lkml/2013/7/23/459
 References: https://lkml.org/lkml/2013/7/23/81
 References: https://lkml.org/lkml/2013/7/24/27
 Reported-by: James Hogan ja...@albanarts.com
 Reported-by: Steven Newbury st...@snewbury.org.uk
 Reported-by: Kamal Mostafa ka...@canonical.com
 Reported-by: Martin Steigerwald mar...@lichtvoll.de
 Reported-by: Jörg Otte jrg.o...@gmail.com
 Reported-by: Kalle Valo kv...@adurom.com
 Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 ---
  drivers/acpi/internal.h |2 -
  drivers/acpi/video.c|   67 
 
  drivers/acpi/video_detect.c |   15 
  drivers/gpu/drm/i915/i915_dma.c |2 -
  include/acpi/video.h|   11 --
  include/linux/acpi.h|1 
  6 files changed, 11 insertions(+), 87 deletions(-)
 
 Index: linux-pm/drivers/acpi/video.c
 ===
 --- linux-pm.orig/drivers/acpi/video.c
 +++ linux-pm/drivers/acpi/video.c
 @@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s
   if (acpi_video_init_brightness(device))
   return;
  
 - if (acpi_video_verify_backlight_support()) {
 + if (acpi_video_backlight_support()) {
   struct backlight_properties props;
   struct pci_dev *pdev;
   acpi_handle acpi_parent;
 @@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi
   unsigned long long level_current, level_next;
   int result = -EINVAL;
  
 - /* no warning message if acpi_backlight=vendor or a quirk is used */
 - if (!acpi_video_verify_backlight_support())
 + /* no warning message if acpi_backlight=vendor is used */
 + if (!acpi_video_backlight_support())
   return 0;
  
   if (!device-brightness)
 @@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct
   return 0;
  }
  
 -static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
 -   void *context, void **rv)
 -{
 - struct acpi_device *acpi_dev;
 - struct acpi_video_bus 

Re: [Intel-gfx] Linux 3.11-rc2 (acpi backlight, revert)

[Daniel Vetter]

On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
 On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
  On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
   On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:

 Linus, do you want me to send a pull request reverting 8c5bd7a and 
 efaa14c?

Yes, but let's wait a while. Not because I think we'll fix the problem
(hey, miracles might happen), but because I think it would be useful
to couple the reverts with information about the particular machines
that broke (and the people who reported it). So that when we
inevitably try again, we can perhaps get some testing effort with
those machines/people.

It doesn't seem to be a show-stopped for a large number of people, so
there's no huge hurry. I'd suggest doing the revert just in time for
rc3, but waiting until then to gather info about people who see
breakage.

Sound like a plan?
   
   Yes, it does.
  
  OK, time to revert I guess.
  
  James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
  patch
  fixes the backlight for you.
 
 Yes, this revert patch does re-enable backlight control for the affected
 Dell XPS13 models.

Are these the same models that neeed the special quirk to not write
PCH_PWM_ENABLE? Or do they need both?
-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] Linux 3.11-rc2 (acpi backlight, revert)

[Kamal Mostafa]

On Thu, 2013-07-25 at 16:46 +0200, Daniel Vetter wrote:
 On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
  On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
   On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
 On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl 
 wrote:
 
  Linus, do you want me to send a pull request reverting 8c5bd7a and 
  efaa14c?
 
 Yes, but let's wait a while. Not because I think we'll fix the problem
 (hey, miracles might happen), but because I think it would be useful
 to couple the reverts with information about the particular machines
 that broke (and the people who reported it). So that when we
 inevitably try again, we can perhaps get some testing effort with
 those machines/people.
 
 It doesn't seem to be a show-stopped for a large number of people, so
 there's no huge hurry. I'd suggest doing the revert just in time for
 rc3, but waiting until then to gather info about people who see
 breakage.
 
 Sound like a plan?

Yes, it does.
   
   OK, time to revert I guess.
   
   James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
   patch
   fixes the backlight for you.
  
  Yes, this revert patch does re-enable backlight control for the affected
  Dell XPS13 models.
 
 Are these the same models that neeed the special quirk to not write
 PCH_PWM_ENABLE? Or do they need both?

Hi Daniel-

Yes, these are the same models (Dell XPS13) that need the PCH_PWM_ENABLE
quirk, but that's not related to this ACPI problem...

All of the XPS13 models still need the PCH_PWM_ENABLE quirk which is now
present in mainline (e85843b drm/i915: quirk no PCH_PWM_ENABLE for Dell
XPS13 backlight).

Separately from that, some of the XPS13 models were _also_ adversely
affected (as were some other machines) by the ACPI changes that are
about to be reverted.

 -Kamal



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
  On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
  jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek sedat.di...@gmail.com 
   wrote:
   On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
   jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell 
   s...@canb.auug.org.au wrote:
   Hi all,
  
   Changes since 20130724:
  
   Removed tree:
   arm-dt (at maintainer's request)
  
   The wireless-next tree lost its build failure and gained a conflict
   against Linus' tree.
  
   The tty tree lost its build failure.
  
   The staging tree gained a build failure for which I disabled a 
   driver.
  
   
  
  
   [ CCing drm and drm-intel folks ]
  
   With today's next-20130725 I see the following:
  
   Use of dev_priv-gt_lock in I915_WRITE through
   intel_disable_gt_powersave before spin lock init, caused by
  
   commit 181d1b9e31c668259d3798c521672afb8edd355c
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Sun Jul 21 13:16:24 2013 +0200
  
   drm/i915: fix up gt init sequence fallout
  
  
   Ah, cool.
  
   I assumed/tested drm/i915: fix the racy object accounting, but this
   does not fix it.
   Will try with yours.
  
  
   Sorry, Jani.
  
   next-20130725 ships the patch you pointed, too.
  
   Confused. I meant that the above mentioned commit drm/i915: fix up gt
   init sequence fallout causes the problem. The patch I included in my
   mail should fix it. Could you try that please?
  
 
  [ Note2myself: Do not read half of the message... ]
 
  The bad... Your patch needed some refresh against next-20130725 (guess
  it's against drm-intel-nightly).
 
  The good... YES, your patch fixes the issue for me!
 
  The ugly... /me.
 
  Feel free to add my:
 
 Tested-by: Sedat Dilek sedat.di...@gmail.com
 
  Thanks for the quick fix!
 
  Thanks a lot for the report, since this should be something I should have
  caught. And for added insult the offending patch is already in Linus' tree
  :( Patch merged to -fixes.

 Hmmm, don't you merge -fixes into -nightly?

 I do, but it seems to only blow up with spinlock debugging enabling I
 think. Our QA should run full debug buils in the -nightly testing, but
 apparently they didn't catch this. I'm looking into what went wrong here
 and fix up the process.

First, I thought I made my merge wrong, but there is no

$ grep spin_lock_init linux-next/drivers/gpu/drm/i915/i915_dma.c | grep gt_lock

Same in [1]:
...
spin_lock_init(dev_priv-irq_lock);
spin_lock_init(dev_priv-gpu_error.lock);
spin_lock_init(dev_priv-backlight.lock);
spin_lock_init(dev_priv-uncore.lock);
spin_lock_init(dev_priv-mm.object_stat_lock);
...

- Sedat -

[1] 
http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915/i915_dma.c?h=drm-intel-nightly#n1477


 -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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Daniel Vetter]

On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
  On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
  jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek sedat.di...@gmail.com 
   wrote:
   On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
   jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell 
   s...@canb.auug.org.au wrote:
   Hi all,
  
   Changes since 20130724:
  
   Removed tree:
   arm-dt (at maintainer's request)
  
   The wireless-next tree lost its build failure and gained a 
   conflict
   against Linus' tree.
  
   The tty tree lost its build failure.
  
   The staging tree gained a build failure for which I disabled a 
   driver.
  
   
  
  
   [ CCing drm and drm-intel folks ]
  
   With today's next-20130725 I see the following:
  
   Use of dev_priv-gt_lock in I915_WRITE through
   intel_disable_gt_powersave before spin lock init, caused by
  
   commit 181d1b9e31c668259d3798c521672afb8edd355c
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Sun Jul 21 13:16:24 2013 +0200
  
   drm/i915: fix up gt init sequence fallout
  
  
   Ah, cool.
  
   I assumed/tested drm/i915: fix the racy object accounting, but this
   does not fix it.
   Will try with yours.
  
  
   Sorry, Jani.
  
   next-20130725 ships the patch you pointed, too.
  
   Confused. I meant that the above mentioned commit drm/i915: fix up gt
   init sequence fallout causes the problem. The patch I included in my
   mail should fix it. Could you try that please?
  
 
  [ Note2myself: Do not read half of the message... ]
 
  The bad... Your patch needed some refresh against next-20130725 (guess
  it's against drm-intel-nightly).
 
  The good... YES, your patch fixes the issue for me!
 
  The ugly... /me.
 
  Feel free to add my:
 
 Tested-by: Sedat Dilek sedat.di...@gmail.com
 
  Thanks for the quick fix!
 
  Thanks a lot for the report, since this should be something I should have
  caught. And for added insult the offending patch is already in Linus' tree
  :( Patch merged to -fixes.

 Hmmm, don't you merge -fixes into -nightly?

 I do, but it seems to only blow up with spinlock debugging enabling I
 think. Our QA should run full debug buils in the -nightly testing, but
 apparently they didn't catch this. I'm looking into what went wrong here
 and fix up the process.

 First, I thought I made my merge wrong, but there is no

 $ grep spin_lock_init linux-next/drivers/gpu/drm/i915/i915_dma.c | grep 
 gt_lock

 Same in [1]:
 ...
 spin_lock_init(dev_priv-irq_lock);
 spin_lock_init(dev_priv-gpu_error.lock);
 spin_lock_init(dev_priv-backlight.lock);
 spin_lock_init(dev_priv-uncore.lock);

It's hiding in plain sight here ;-) -next has it renamed to
uncore.lock, so I've applied the patch to -fixes only. I've also
changed the patch in -fixes to cause an explicit conflict here, makes
merging a bit easier.
-Daniel

 spin_lock_init(dev_priv-mm.object_stat_lock);
 ...

 - Sedat -

 [1] 
 http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915/i915_dma.c?h=drm-intel-nightly#n1477


 -Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch



--
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 Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 5:05 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
  On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
  jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek 
   sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
   jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell 
   s...@canb.auug.org.au wrote:
   Hi all,
  
   Changes since 20130724:
  
   Removed tree:
   arm-dt (at maintainer's request)
  
   The wireless-next tree lost its build failure and gained a 
   conflict
   against Linus' tree.
  
   The tty tree lost its build failure.
  
   The staging tree gained a build failure for which I disabled a 
   driver.
  
   
  
  
   [ CCing drm and drm-intel folks ]
  
   With today's next-20130725 I see the following:
  
   Use of dev_priv-gt_lock in I915_WRITE through
   intel_disable_gt_powersave before spin lock init, caused by
  
   commit 181d1b9e31c668259d3798c521672afb8edd355c
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Sun Jul 21 13:16:24 2013 +0200
  
   drm/i915: fix up gt init sequence fallout
  
  
   Ah, cool.
  
   I assumed/tested drm/i915: fix the racy object accounting, but 
   this
   does not fix it.
   Will try with yours.
  
  
   Sorry, Jani.
  
   next-20130725 ships the patch you pointed, too.
  
   Confused. I meant that the above mentioned commit drm/i915: fix up gt
   init sequence fallout causes the problem. The patch I included in my
   mail should fix it. Could you try that please?
  
 
  [ Note2myself: Do not read half of the message... ]
 
  The bad... Your patch needed some refresh against next-20130725 (guess
  it's against drm-intel-nightly).
 
  The good... YES, your patch fixes the issue for me!
 
  The ugly... /me.
 
  Feel free to add my:
 
 Tested-by: Sedat Dilek sedat.di...@gmail.com
 
  Thanks for the quick fix!
 
  Thanks a lot for the report, since this should be something I should have
  caught. And for added insult the offending patch is already in Linus' 
  tree
  :( Patch merged to -fixes.

 Hmmm, don't you merge -fixes into -nightly?

 I do, but it seems to only blow up with spinlock debugging enabling I
 think. Our QA should run full debug buils in the -nightly testing, but
 apparently they didn't catch this. I'm looking into what went wrong here
 and fix up the process.

 First, I thought I made my merge wrong, but there is no

 $ grep spin_lock_init linux-next/drivers/gpu/drm/i915/i915_dma.c | grep 
 gt_lock

 Same in [1]:
 ...
 spin_lock_init(dev_priv-irq_lock);
 spin_lock_init(dev_priv-gpu_error.lock);
 spin_lock_init(dev_priv-backlight.lock);
 spin_lock_init(dev_priv-uncore.lock);

 It's hiding in plain sight here ;-) -next has it renamed to
 uncore.lock, so I've applied the patch to -fixes only. I've also
 changed the patch in -fixes to cause an explicit conflict here, makes
 merging a bit easier.

Ah, I see... drm/i915: Colocate all GT access routines in the same file

@@ -1493,7 +1477,7 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags)
...
- spin_lock_init(dev_priv-gt_lock);
+ spin_lock_init(dev_priv-uncore.lock);
...

- Sedat -

http://cgit.freedesktop.org/~danvet/drm-intel/commit/drivers/gpu/drm/i915/i915_dma.c?h=drm-intel-nightlyid=907b28c56ea40629aa6595ddfa414ec2fc7da41c

 -Daniel

 spin_lock_init(dev_priv-mm.object_stat_lock);
 ...

 - Sedat -

 [1] 
 http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915/i915_dma.c?h=drm-intel-nightly#n1477


 -Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch



 --
 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 Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 5:34 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 5:05 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
  On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
  jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek 
   sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
   jani.nik...@linux.intel.com wrote:
   On Thu, 25 Jul 2013, Sedat Dilek sedat.di...@gmail.com wrote:
   On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell 
   s...@canb.auug.org.au wrote:
   Hi all,
  
   Changes since 20130724:
  
   Removed tree:
   arm-dt (at maintainer's request)
  
   The wireless-next tree lost its build failure and gained a 
   conflict
   against Linus' tree.
  
   The tty tree lost its build failure.
  
   The staging tree gained a build failure for which I disabled a 
   driver.
  
   
  
  
   [ CCing drm and drm-intel folks ]
  
   With today's next-20130725 I see the following:
  
   Use of dev_priv-gt_lock in I915_WRITE through
   intel_disable_gt_powersave before spin lock init, caused by
  
   commit 181d1b9e31c668259d3798c521672afb8edd355c
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Sun Jul 21 13:16:24 2013 +0200
  
   drm/i915: fix up gt init sequence fallout
  
  
   Ah, cool.
  
   I assumed/tested drm/i915: fix the racy object accounting, but 
   this
   does not fix it.
   Will try with yours.
  
  
   Sorry, Jani.
  
   next-20130725 ships the patch you pointed, too.
  
   Confused. I meant that the above mentioned commit drm/i915: fix up 
   gt
   init sequence fallout causes the problem. The patch I included in my
   mail should fix it. Could you try that please?
  
 
  [ Note2myself: Do not read half of the message... ]
 
  The bad... Your patch needed some refresh against next-20130725 (guess
  it's against drm-intel-nightly).
 
  The good... YES, your patch fixes the issue for me!
 
  The ugly... /me.
 
  Feel free to add my:
 
 Tested-by: Sedat Dilek sedat.di...@gmail.com
 
  Thanks for the quick fix!
 
  Thanks a lot for the report, since this should be something I should 
  have
  caught. And for added insult the offending patch is already in Linus' 
  tree
  :( Patch merged to -fixes.

 Hmmm, don't you merge -fixes into -nightly?

 I do, but it seems to only blow up with spinlock debugging enabling I
 think. Our QA should run full debug buils in the -nightly testing, but
 apparently they didn't catch this. I'm looking into what went wrong here
 and fix up the process.

 First, I thought I made my merge wrong, but there is no

 $ grep spin_lock_init linux-next/drivers/gpu/drm/i915/i915_dma.c | grep 
 gt_lock

 Same in [1]:
 ...
 spin_lock_init(dev_priv-irq_lock);
 spin_lock_init(dev_priv-gpu_error.lock);
 spin_lock_init(dev_priv-backlight.lock);
 spin_lock_init(dev_priv-uncore.lock);

 It's hiding in plain sight here ;-) -next has it renamed to
 uncore.lock, so I've applied the patch to -fixes only. I've also
 changed the patch in -fixes to cause an explicit conflict here, makes
 merging a bit easier.

 Ah, I see... drm/i915: Colocate all GT access routines in the same file

 @@ -1493,7 +1477,7 @@ int i915_driver_load(struct drm_device *dev,
 unsigned long flags)
 ...
 - spin_lock_init(dev_priv-gt_lock);
 + spin_lock_init(dev_priv-uncore.lock);
 ...


Might be OT, but I cannot use my X graphics stack containing
libdrm-2.4.46, mesa-9.1.5 and intel-ddx 2.21.12-git (tried also
v2.21.11).
Switching back to the one from Ubuntu/precise lets my X start.


[40.379] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[40.379] (II) AIGLX: enabled GLX_INTEL_swap_event
[40.380] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[40.380] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[40.380] (II) AIGLX: Loaded and initialized i965
[40.380] (II) GLX: Initialized DRI2 GL provider for screen 0
[40.380]
Fatal server error:
[40.380] failed to create screen resources
[40.380]
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[40.380] Please also check the log file at /var/log/Xorg.0.log
for additional information.
[40.380]
[40.380] (II) AIGLX: Suspending AIGLX clients for VT switch
[40.396]  ddxSigGiveUp: Closing log
[40.398] Server terminated with error (1). Closing log file.

- Sedat -

 - Sedat -

 http://cgit.freedesktop.org/~danvet/drm-intel/commit

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Thu, Jul 25, 2013 at 06:11:18PM +0200, Sedat Dilek wrote:
 Might be OT, but I cannot use my X graphics stack containing
 libdrm-2.4.46, mesa-9.1.5 and intel-ddx 2.21.12-git (tried also
 v2.21.11).
 Switching back to the one from Ubuntu/precise lets my X start.
 
 
 [40.379] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
 [40.379] (II) AIGLX: enabled GLX_INTEL_swap_event
 [40.380] (II) AIGLX: enabled GLX_SGI_swap_control and 
 GLX_MESA_swap_control
 [40.380] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
 [40.380] (II) AIGLX: Loaded and initialized i965
 [40.380] (II) GLX: Initialized DRI2 GL provider for screen 0
 [40.380]
 Fatal server error:
 [40.380] failed to create screen resources
 [40.380]
 Please consult the The X.Org Foundation support
  at http://wiki.x.org
  for help.
 [40.380] Please also check the log file at /var/log/Xorg.0.log
 for additional information.
 [40.380]
 [40.380] (II) AIGLX: Suspending AIGLX clients for VT switch
 [40.396]  ddxSigGiveUp: Closing log
 [40.398] Server terminated with error (1). Closing log file.

Please attach the full Xorg.0.log so that I can make a few guesses.
-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] Ugly patches for stolen reservation

[Jesse Barnes]

Patch 2/2 has the description, but suffice it to say I'm not really
pleased with this, though it does solve a problem we have.  On some
machines, we get MMIO space allocated on top of this hidden memory,
which can cause problems.  I'm not sure if there are similar problems
for other hunks of the address space; if so it's possible this could be
made more general (though the bits for looking up the address of this
region are definitely Intel graphics specific).

Chris has some patches on top to add a new E820 type so we can look up
the region later, which removes some redundant code in the i915 driver
at least.

Any comments?  I assume no one likes this, but maybe it's just another
early quirk we'll have to live with...

Thanks,
Jesse

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: split PCI IDs out into i915_drm.h v3

[Jesse Barnes]

For use by userspace (at some point in the future) and other kernel code.

v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/i915_drv.c |  164 +++---
 include/drm/i915_drm.h  |2 +
 include/drm/i915_pciids.h   |  208 +++
 3 files changed, 244 insertions(+), 130 deletions(-)
 create mode 100644 include/drm/i915_pciids.h

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b07362f..e87bccf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -140,25 +140,6 @@ MODULE_PARM_DESC(fastboot, Try to skip unnecessary mode 
sets at boot time 
 static struct drm_driver driver;
 extern int intel_agp_enabled;
 
-#define INTEL_VGA_DEVICE(id, info) {   \
-   .class = PCI_BASE_CLASS_DISPLAY  16,  \
-   .class_mask = 0xff, \
-   .vendor = 0x8086,   \
-   .device = id,   \
-   .subvendor = PCI_ANY_ID,\
-   .subdevice = PCI_ANY_ID,\
-   .driver_data = (unsigned long) info }
-
-#define INTEL_QUANTA_VGA_DEVICE(info) {\
-   .class = PCI_BASE_CLASS_DISPLAY  16,  \
-   .class_mask = 0xff, \
-   .vendor = 0x8086,   \
-   .device = 0x16a,\
-   .subvendor = 0x152d,\
-   .subdevice = 0x8990,\
-   .driver_data = (unsigned long) info }
-
-
 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
.has_overlay = 1, .overlay_needs_physical = 1,
@@ -333,118 +314,41 @@ static const struct intel_device_info 
intel_haswell_m_info = {
.has_vebox_ring = 1,
 };
 
+/*
+ * Make sure any device matches here are from most specific to most
+ * general.  For example, since the Quanta match is based on the subsystem
+ * and subvendor IDs, we need it to come before the more general IVB
+ * PCI ID matches, otherwise we'll use the wrong info struct above.
+ */
+#define INTEL_PCI_IDS \
+   INTEL_I830_IDS(intel_i830_info),   \
+   INTEL_I845G_IDS(intel_845g_info),  \
+   INTEL_I85X_IDS(intel_i85x_info),   \
+   INTEL_I865G_IDS(intel_i865g_info), \
+   INTEL_I915G_IDS(intel_i915g_info), \
+   INTEL_I915GM_IDS(intel_i915gm_info),   \
+   INTEL_I945G_IDS(intel_i945g_info), \
+   INTEL_I945GM_IDS(intel_i945gm_info),   \
+   INTEL_I965G_IDS(intel_i965g_info), \
+   INTEL_G33_IDS(intel_g33_info), \
+   INTEL_I965GM_IDS(intel_i965gm_info),   \
+   INTEL_GM45_IDS(intel_gm45_info),   \
+   INTEL_G45_IDS(intel_g45_info), \
+   INTEL_PINEVIEW_IDS(intel_pineview_info),   \
+   INTEL_IRONLAKE_D_IDS(intel_ironlake_d_info),   \
+   INTEL_IRONLAKE_M_IDS(intel_ironlake_m_info),   \
+   INTEL_SNB_D_IDS(intel_sandybridge_d_info), \
+   INTEL_SNB_M_IDS(intel_sandybridge_m_info), \
+   INTEL_IVB_Q_IDS(intel_ivybridge_q_info), /* must be first IVB */ \
+   INTEL_IVB_M_IDS(intel_ivybridge_m_info),   \
+   INTEL_IVB_D_IDS(intel_ivybridge_d_info),   \
+   INTEL_HSW_D_IDS(intel_haswell_d_info), \
+   INTEL_HSW_M_IDS(intel_haswell_m_info), \
+   INTEL_VLV_M_IDS(intel_valleyview_m_info),  \
+   INTEL_VLV_D_IDS(intel_valleyview_d_info)
+
 static const struct pci_device_id pciidlist[] = {  /* aka */
-   INTEL_VGA_DEVICE(0x3577, intel_i830_info), /* I830_M */
-   INTEL_VGA_DEVICE(0x2562, intel_845g_info), /* 845_G */
-   INTEL_VGA_DEVICE(0x3582, intel_i85x_info), /* I855_GM */
-   INTEL_VGA_DEVICE(0x358e, intel_i85x_info),
-   INTEL_VGA_DEVICE(0x2572, intel_i865g_info),/* I865_G */
-   INTEL_VGA_DEVICE(0x2582, intel_i915g_info),/* I915_G */
-   INTEL_VGA_DEVICE(0x258a, intel_i915g_info),/* E7221_G */
-   INTEL_VGA_DEVICE(0x2592, intel_i915gm_info),   /* I915_GM */
-   INTEL_VGA_DEVICE(0x2772, intel_i945g_info),/* I945_G */
-   INTEL_VGA_DEVICE(0x27a2, intel_i945gm_info),   /* I945_GM */
-   INTEL_VGA_DEVICE(0x27ae, intel_i945gm_info),   /* I945_GME */
-   INTEL_VGA_DEVICE(0x2972, intel_i965g_info),/* I946_GZ */
-   INTEL_VGA_DEVICE(0x2982, intel_i965g_info),/* G35_G */
-   INTEL_VGA_DEVICE(0x2992, intel_i965g_info),/* I965_Q */
-   INTEL_VGA_DEVICE(0x29a2, intel_i965g_info),/* I965_G */
-   INTEL_VGA_DEVICE(0x29b2, intel_g33_info),  /* Q35_G */
-   INTEL_VGA_DEVICE(0x29c2, intel_g33_info),  /* G33_G */
-

[Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3

[Jesse Barnes]

Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use.  This memory is not marked in the E820 as reserved or as
RAM, and so is subject to overlap from E820 manipulation later in the
boot process.  On some systems, MMIO space is allocated on top, despite
the efforts of the RAM buffer approach, which simply rounds memory
boundaries up to 64M to try to catch space that may decode as RAM and so
is not suitable for MMIO.

v2: use read_pci_config for 32 bit reads instead of adding a new one
(Chris)
add gen6 stolen size function (Chris)
use a function pointer (Chris)
drop gen2 bits (Daniel)

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 arch/x86/kernel/early-quirks.c  |  158 +++
 drivers/gpu/drm/i915/i915_reg.h |   15 
 include/drm/i915_drm.h  |   32 
 3 files changed, 190 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 94ab6b9..bff8a6f 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -12,6 +12,7 @@
 #include linux/pci.h
 #include linux/acpi.h
 #include linux/pci_ids.h
+#include drm/i915_drm.h
 #include asm/pci-direct.h
 #include asm/dma.h
 #include asm/io_apic.h
@@ -208,6 +209,161 @@ static void __init intel_remapping_check(int num, int 
slot, int func)
 
 }
 
+/*
+ * Systems with Intel graphics controllers set aside memory exclusively
+ * for gfx driver use.  This memory is not marked in the E820 as reserved
+ * or as RAM, and so is subject to overlap from E820 manipulation later
+ * in the boot process.  On some systems, MMIO space is allocated on top,
+ * despite the efforts of the RAM buffer approach, which simply rounds
+ * memory boundaries up to 64M to try to catch space that may decode
+ * as RAM and so is not suitable for MMIO.
+ *
+ * And yes, so far on current devices the base addr is always under 4G.
+ */
+static u32 __init intel_stolen_base(int num, int slot, int func)
+{
+   u32 base;
+
+   /*
+* Almost universally we can find the Graphics Base of Stolen Memory
+* at offset 0x5c in the igfx configuration space. On a few (desktop)
+* machines this is also mirrored in the bridge device at different
+* locations, or in the MCHBAR.
+*/
+   base = read_pci_config(num, slot, func, 0x5c);
+   base = ~((120) - 1);
+
+   return base;
+}
+
+#define KB(x)  ((x) * 1024)
+#define MB(x)  (KB (KB (x)))
+#define GB(x)  (MB (KB (x)))
+
+static size_t __init gen3_stolen_size(int num, int slot, int func)
+{
+   size_t stolen_size;
+   u16 gmch_ctrl;
+
+   gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
+
+   switch (gmch_ctrl  I855_GMCH_GMS_MASK) {
+   case I855_GMCH_GMS_STOLEN_1M:
+   stolen_size = MB(1);
+   break;
+   case I855_GMCH_GMS_STOLEN_4M:
+   stolen_size = MB(4);
+   break;
+   case I855_GMCH_GMS_STOLEN_8M:
+   stolen_size = MB(8);
+   break;
+   case I855_GMCH_GMS_STOLEN_16M:
+   stolen_size = MB(16);
+   break;
+   case I855_GMCH_GMS_STOLEN_32M:
+   stolen_size = MB(32);
+   break;
+   case I915_GMCH_GMS_STOLEN_48M:
+   stolen_size = MB(48);
+   break;
+   case I915_GMCH_GMS_STOLEN_64M:
+   stolen_size = MB(64);
+   break;
+   case G33_GMCH_GMS_STOLEN_128M:
+   stolen_size = MB(128);
+   break;
+   case G33_GMCH_GMS_STOLEN_256M:
+   stolen_size = MB(256);
+   break;
+   case INTEL_GMCH_GMS_STOLEN_96M:
+   stolen_size = MB(96);
+   break;
+   case INTEL_GMCH_GMS_STOLEN_160M:
+   stolen_size = MB(160);
+   break;
+   case INTEL_GMCH_GMS_STOLEN_224M:
+   stolen_size = MB(224);
+   break;
+   case INTEL_GMCH_GMS_STOLEN_352M:
+   stolen_size = MB(352);
+   break;
+   default:
+   stolen_size = 0;
+   break;
+   }
+
+   return stolen_size;
+}
+
+static size_t __init gen6_stolen_size(int num, int slot, int func)
+{
+   u16 gmch_ctrl;
+
+   gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
+   gmch_ctrl = SNB_GMCH_GMS_SHIFT;
+   gmch_ctrl = SNB_GMCH_GMS_MASK;
+
+   return gmch_ctrl  25; /* 32 MB units */
+}
+
+typedef size_t (*stolen_size_fn)(int num, int slot, int func);
+
+static struct pci_device_id intel_stolen_ids[] __initdata = {
+   INTEL_I915G_IDS(gen3_stolen_size),
+   INTEL_I915GM_IDS(gen3_stolen_size),
+   INTEL_I945G_IDS(gen3_stolen_size),
+   INTEL_I945GM_IDS(gen3_stolen_size),
+   INTEL_VLV_M_IDS(gen3_stolen_size),
+   INTEL_VLV_D_IDS(gen3_stolen_size),
+   INTEL_PINEVIEW_IDS(gen3_stolen_size),
+   INTEL_I965G_IDS(gen3_stolen_size),
+   

Re: [Intel-gfx] [PATCH 1/2] drm/i915: split PCI IDs out into i915_drm.h v3

[Chad Versace]

On 07/24/2013 05:04 PM, Jesse Barnes wrote:

For use by userspace (at some point in the future) and other kernel code.

v2: move PCI IDs to uabi (Chris)
 move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
  drivers/gpu/drm/i915/i915_drv.c |  164 +++---
  include/drm/i915_drm.h  |2 +
  include/drm/i915_pciids.h   |  208 +++
  3 files changed, 244 insertions(+), 130 deletions(-)
  create mode 100644 include/drm/i915_pciids.h




+#define INTEL_VGA_DEVICE(id, info) {   \
+   .class = PCI_BASE_CLASS_DISPLAY  16,\
+   .class_mask = 0xff, \
+   .vendor = 0x8086,   \
+   .device = id,   \
+   .subvendor = PCI_ANY_ID,\
+   .subdevice = PCI_ANY_ID,\
+   .driver_data = (unsigned long) info }


I retract my objections from yesterday. I expected the header to define
a static table (like static const struct xxx i915_pci_ids[] = ...), which
I didn't like due its inflexibility. But, this macro I do like. It's
flexible enough.

Acked-by: Chad Versace chad.vers...@linux.intel.com


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: enable IPS for bpp = 24

[Jesse Barnes]

Art confirms that this should work fine.  Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 12ea1a9..7cf475b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4091,7 +4091,7 @@ static void hsw_compute_ips_config(struct intel_crtc 
*crtc,
 {
pipe_config-ips_enabled = i915_enable_ips 
   hsw_crtc_supports_ips(crtc) 
-  pipe_config-pipe_bpp == 24;
+  pipe_config-pipe_bpp = 24;
 }
 
 static int intel_crtc_compute_config(struct intel_crtc *crtc,
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: enable IPS for bpp = 24

[Chris Wilson]

On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
 Art confirms that this should work fine.  Since most panels are 18bpp
 with dithering from 24bpp, the existing code wouldn't be enabled in most
 cases.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_display.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 12ea1a9..7cf475b 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -4091,7 +4091,7 @@ static void hsw_compute_ips_config(struct intel_crtc 
 *crtc,
  {
   pipe_config-ips_enabled = i915_enable_ips 
  hsw_crtc_supports_ips(crtc) 
 -pipe_config-pipe_bpp == 24;
 +pipe_config-pipe_bpp = 24;

Don't you want to check that the incoming fb is depth 24?
-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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  Basically boils down to either an object allocation failure or mmaping
  failure. I think dmesg with drm.debug=7 is the next step.
 
 Attached! Thanks for taking care.

Hmm, looks like i915_gem_map_gtt fails, but no reason given, so can you
please apply this for more debug:

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0563661..34e09bf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1630,24 +1630,29 @@ i915_gem_mmap_gtt(struct drm_file *file,
 
obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
if (obj-base == NULL) {
+   DRM_DRIVER_DEBUG(Unknown object handle %d\n, handle);
ret = -ENOENT;
goto unlock;
}
 
if (obj-base.size  dev_priv-gtt.mappable_end) {
+   DRM_DRIVER_DEBUG(Object (%d) larger than mappable aperture 
(%d)  %d\n,
+   (int)obj-base.size, 
(int)dev_priv-gtt.mappable_end);
ret = -E2BIG;
goto out;
}
 
if (obj-madv != I915_MADV_WILLNEED) {
-   DRM_ERROR(Attempting to mmap a purgeable buffer\n);
+   DRM_DRIVER_DEBUG(Attempting to mmap a purgeable buffer\n);
ret = -EINVAL;
goto out;
}
 
ret = i915_gem_object_create_mmap_offset(obj);
-   if (ret)
+   if (ret) {
+   DRM_DRIVER_DEBUG(Failed to allocate mmap offset (ret=%d)\n, 
ret);
goto out;
+   }
 
*offset = (u64)obj-base.map_list.hash.key  PAGE_SHIFT;

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: enable IPS for bpp = 24

[Jesse Barnes]

On Thu, 25 Jul 2013 18:17:59 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
  Art confirms that this should work fine.  Since most panels are 18bpp
  with dithering from 24bpp, the existing code wouldn't be enabled in most
  cases.
  
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   drivers/gpu/drm/i915/intel_display.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 12ea1a9..7cf475b 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -4091,7 +4091,7 @@ static void hsw_compute_ips_config(struct intel_crtc 
  *crtc,
   {
  pipe_config-ips_enabled = i915_enable_ips 
 hsw_crtc_supports_ips(crtc) 
  -  pipe_config-pipe_bpp == 24;
  +  pipe_config-pipe_bpp = 24;
 
 Don't you want to check that the incoming fb is depth 24?

I think this field will have the right bits in it for a 12bpc HDMI
config for example, so we should be able to use it for IPS support.

-- 
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: enable IPS for bpp = 24

[Daniel Vetter]

On Thu, Jul 25, 2013 at 7:27 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Thu, 25 Jul 2013 18:17:59 +0100
 Chris Wilson ch...@chris-wilson.co.uk wrote:

 On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
  Art confirms that this should work fine.  Since most panels are 18bpp
  with dithering from 24bpp, the existing code wouldn't be enabled in most
  cases.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   drivers/gpu/drm/i915/intel_display.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 12ea1a9..7cf475b 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -4091,7 +4091,7 @@ static void hsw_compute_ips_config(struct intel_crtc 
  *crtc,
   {
  pipe_config-ips_enabled = i915_enable_ips 
 hsw_crtc_supports_ips(crtc) 
  -  pipe_config-pipe_bpp == 24;
  +  pipe_config-pipe_bpp = 24;

 Don't you want to check that the incoming fb is depth 24?

 I think this field will have the right bits in it for a 12bpc HDMI
 config for example, so we should be able to use it for IPS support.

Atm the above should work, but I expect that longer-term we need to
track sprite/plane configuration bits (like the watermark stuff
maybe), too. Only HDMI rounds up from the fb bpp value, but it doesn't
round up 8bpc to 12bpc. This might change eventually when we get
around to implement the high-precision gamma tables, since with a
10bpc display it would make sense to have the higher precision even
with a 24bpp scanout buffer.
-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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 7:52 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  Basically boils down to either an object allocation failure or mmaping
  failure. I think dmesg with drm.debug=7 is the next step.

 Attached! Thanks for taking care.

 Hmm, looks like i915_gem_map_gtt fails, but no reason given, so can you
 please apply this for more debug:

 diff --git a/drivers/gpu/drm/i915/i915_gem.c 
 b/drivers/gpu/drm/i915/i915_gem.c
 index 0563661..34e09bf 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -1630,24 +1630,29 @@ i915_gem_mmap_gtt(struct drm_file *file,

 obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
 if (obj-base == NULL) {
 +   DRM_DRIVER_DEBUG(Unknown object handle %d\n, handle);
 ret = -ENOENT;
 goto unlock;
 }

 if (obj-base.size  dev_priv-gtt.mappable_end) {
 +   DRM_DRIVER_DEBUG(Object (%d) larger than mappable aperture 
 (%d)  %d\n,
 +   (int)obj-base.size, 
 (int)dev_priv-gtt.mappable_end);
 ret = -E2BIG;
 goto out;
 }

 if (obj-madv != I915_MADV_WILLNEED) {
 -   DRM_ERROR(Attempting to mmap a purgeable buffer\n);
 +   DRM_DRIVER_DEBUG(Attempting to mmap a purgeable buffer\n);
 ret = -EINVAL;
 goto out;
 }

 ret = i915_gem_object_create_mmap_offset(obj);
 -   if (ret)
 +   if (ret) {
 +   DRM_DRIVER_DEBUG(Failed to allocate mmap offset 
 (ret=%d)\n, ret);
 goto out;
 +   }

 *offset = (u64)obj-base.map_list.hash.key  PAGE_SHIFT;

 --

 This does not apply... After refreshing and some cleanups... does not build:

 $ LANG=C LC_ALL=C make M=drivers/gpu/drm/i915
   LD  drivers/gpu/drm/i915/built-in.o
   CC [M]  drivers/gpu/drm/i915/i915_drv.o
   CC [M]  drivers/gpu/drm/i915/i915_dma.o
   CC [M]  drivers/gpu/drm/i915/i915_irq.o
   CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
   CC [M]  drivers/gpu/drm/i915/i915_gpu_error.o
   CC [M]  drivers/gpu/drm/i915/i915_suspend.o
   CC [M]  drivers/gpu/drm/i915/i915_gem.o
 drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_mmap_gtt':
 drivers/gpu/drm/i915/i915_gem.c:1538:3: error: implicit declaration of
 function 'DRM_DRIVER_DEBUG' [-Werror=implicit-function-declaration]
 cc1: some warnings being treated as errors
 make[1]: *** [drivers/gpu/drm/i915/i915_gem.o] Error 1
 make: *** [_module_drivers/gpu/drm/i915] Error 2


F*ck. Wrong patch refreshed.

- S.

 - Sedat -

 Chris Wilson, Intel Open Source Technology Centre
 --
 To unsubscribe from this list: send the line unsubscribe linux-next in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


0001-i915-Debug-test-patch-to-see-why-i915_gem_map_gtt-fa.patch
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Thu, Jul 25, 2013 at 07:52:22PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
  On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
   Basically boils down to either an object allocation failure or mmaping
   failure. I think dmesg with drm.debug=7 is the next step.
 
  Attached! Thanks for taking care.
 
  Hmm, looks like i915_gem_map_gtt fails, but no reason given, so can you
  please apply this for more debug:
 
  diff --git a/drivers/gpu/drm/i915/i915_gem.c 
  b/drivers/gpu/drm/i915/i915_gem.c
  index 0563661..34e09bf 100644
  --- a/drivers/gpu/drm/i915/i915_gem.c
  +++ b/drivers/gpu/drm/i915/i915_gem.c
  @@ -1630,24 +1630,29 @@ i915_gem_mmap_gtt(struct drm_file *file,
 
  obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
  if (obj-base == NULL) {
  +   DRM_DRIVER_DEBUG(Unknown object handle %d\n, handle);
  ret = -ENOENT;
  goto unlock;
  }
 
  if (obj-base.size  dev_priv-gtt.mappable_end) {
  +   DRM_DRIVER_DEBUG(Object (%d) larger than mappable aperture 
  (%d)  %d\n,
  +   (int)obj-base.size, 
  (int)dev_priv-gtt.mappable_end);
  ret = -E2BIG;
  goto out;
  }
 
  if (obj-madv != I915_MADV_WILLNEED) {
  -   DRM_ERROR(Attempting to mmap a purgeable buffer\n);
  +   DRM_DRIVER_DEBUG(Attempting to mmap a purgeable buffer\n);
  ret = -EINVAL;
  goto out;
  }
 
  ret = i915_gem_object_create_mmap_offset(obj);
  -   if (ret)
  +   if (ret) {
  +   DRM_DRIVER_DEBUG(Failed to allocate mmap offset 
  (ret=%d)\n, ret);
  goto out;
  +   }
 
  *offset = (u64)obj-base.map_list.hash.key  PAGE_SHIFT;
 
  --
 
 This does not apply... After refreshing and some cleanups... does not build:
 
 $ LANG=C LC_ALL=C make M=drivers/gpu/drm/i915
   LD  drivers/gpu/drm/i915/built-in.o
   CC [M]  drivers/gpu/drm/i915/i915_drv.o
   CC [M]  drivers/gpu/drm/i915/i915_dma.o
   CC [M]  drivers/gpu/drm/i915/i915_irq.o
   CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
   CC [M]  drivers/gpu/drm/i915/i915_gpu_error.o
   CC [M]  drivers/gpu/drm/i915/i915_suspend.o
   CC [M]  drivers/gpu/drm/i915/i915_gem.o
 drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_mmap_gtt':
 drivers/gpu/drm/i915/i915_gem.c:1538:3: error: implicit declaration of
 function 'DRM_DRIVER_DEBUG' [-Werror=implicit-function-declaration]
 cc1: some warnings being treated as errors
 make[1]: *** [drivers/gpu/drm/i915/i915_gem.o] Error 1
 make: *** [_module_drivers/gpu/drm/i915] Error 2

Bah, try DRM_DEBUG_DRIVER instead.
-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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Thu, Jul 25, 2013 at 08:03:06PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 7:55 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  F*ck. Wrong patch refreshed.
 
 
 New dmesg attached.

Hmm, not seeing any difference, so let's add a couple more lines just to
be sure:

(apologies I didn't stash the previous debug patch)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0563661..4d21f37 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1624,30 +1624,39 @@ i915_gem_mmap_gtt(struct drm_file *file,
struct drm_i915_gem_object *obj;
int ret;
 
+   printk(KERN_ERR Hello!\n);
+
ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
+   if (ret) {
+   DRM_DEBUG_DRIVER(interrupted: ret=%d\n, ret);
return ret;
+   }
 
obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
if (obj-base == NULL) {
+   DRM_DEBUG_DRIVER(Unknown object handle %d\n, handle);
ret = -ENOENT;
goto unlock;
}
 
if (obj-base.size  dev_priv-gtt.mappable_end) {
+   DRM_DEBUG_DRIVER(Object (%d) larger than mappable aperture 
(%d)  %d\n,
+   (int)obj-base.size, 
(int)dev_priv-gtt.mappable_end);
ret = -E2BIG;
goto out;
}
 
if (obj-madv != I915_MADV_WILLNEED) {
-   DRM_ERROR(Attempting to mmap a purgeable buffer\n);
+   DRM_DEBUG_DRIVER(Attempting to mmap a purgeable buffer\n);
ret = -EINVAL;
goto out;
}
 
ret = i915_gem_object_create_mmap_offset(obj);
-   if (ret)
+   if (ret) {
+   DRM_DEBUG_DRIVER(Failed to allocate mmap offset (ret=%d)\n, 
ret);
goto out;
+   }
 
*offset = (u64)obj-base.map_list.hash.key  PAGE_SHIFT;
 
@@ -1655,6 +1664,7 @@ out:
drm_gem_object_unreference(obj-base);
 unlock:
mutex_unlock(dev-struct_mutex);
+   DRM_DEBUG_DRIVER(done, ret=%d\n, ret);
return ret;
 }


-- 
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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 8:45 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Thu, Jul 25, 2013 at 08:03:06PM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 7:55 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  F*ck. Wrong patch refreshed.
 

 New dmesg attached.

 Hmm, not seeing any difference, so let's add a couple more lines just to
 be sure:

 (apologies I didn't stash the previous debug patch)

 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 0563661..4d21f37 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -1624,30 +1624,39 @@ i915_gem_mmap_gtt(struct drm_file *file,
 struct drm_i915_gem_object *obj;
 int ret;

 +   printk(KERN_ERR Hello!\n);
 +
 ret = i915_mutex_lock_interruptible(dev);
 -   if (ret)
 +   if (ret) {
 +   DRM_DEBUG_DRIVER(interrupted: ret=%d\n, ret);
 return ret;
 +   }

 obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
 if (obj-base == NULL) {
 +   DRM_DEBUG_DRIVER(Unknown object handle %d\n, handle);
 ret = -ENOENT;
 goto unlock;
 }

 if (obj-base.size  dev_priv-gtt.mappable_end) {
 +   DRM_DEBUG_DRIVER(Object (%d) larger than mappable aperture 
 (%d)  %d\n,
 +   (int)obj-base.size, 
 (int)dev_priv-gtt.mappable_end);
 ret = -E2BIG;
 goto out;
 }

 if (obj-madv != I915_MADV_WILLNEED) {
 -   DRM_ERROR(Attempting to mmap a purgeable buffer\n);
 +   DRM_DEBUG_DRIVER(Attempting to mmap a purgeable buffer\n);
 ret = -EINVAL;
 goto out;
 }

 ret = i915_gem_object_create_mmap_offset(obj);
 -   if (ret)
 +   if (ret) {
 +   DRM_DEBUG_DRIVER(Failed to allocate mmap offset (ret=%d)\n, 
 ret);
 goto out;
 +   }

 *offset = (u64)obj-base.map_list.hash.key  PAGE_SHIFT;

 @@ -1655,6 +1664,7 @@ out:
 drm_gem_object_unreference(obj-base);
  unlock:
 mutex_unlock(dev-struct_mutex);
 +   DRM_DEBUG_DRIVER(done, ret=%d\n, ret);
 return ret;
  }


 --

Against what tree is this applicable? It is definitely not drm-intel-nightly.

- S.
 Chris Wilson, Intel Open Source Technology Centre
 --
 To unsubscribe from this list: send the line unsubscribe linux-next in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Thu, Jul 25, 2013 at 08:50:59PM +0200, Sedat Dilek wrote:
 Against what tree is this applicable? It is definitely not drm-intel-nightly.

Applied cleanly to nightly here, but just in case here's a rebased version:

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3a5d4ba..5818fe8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1527,30 +1527,39 @@ i915_gem_mmap_gtt(struct drm_file *file,
struct drm_i915_gem_object *obj;
int ret;
 
+   printk(KERN_ERR Hello!\n);
+
ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
+   if (ret) {
+   DRM_DEBUG_DRIVER(interrupted: ret=%d\n, ret);
return ret;
+   }
 
obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
if (obj-base == NULL) {
+   DRM_DEBUG_DRIVER(Unknown object handle %d\n, handle);
ret = -ENOENT;
goto unlock;
}
 
if (obj-base.size  dev_priv-gtt.mappable_end) {
+   DRM_DEBUG_DRIVER(Object (%d) larger than mappable aperture 
(%d)  %d\n,
+   (int)obj-base.size, 
(int)dev_priv-gtt.mappable_end);
ret = -E2BIG;
goto out;
}
 
if (obj-madv != I915_MADV_WILLNEED) {
-   DRM_ERROR(Attempting to mmap a purgeable buffer\n);
+   DRM_DEBUG_DRIVER(Attempting to mmap a purgeable buffer\n);
ret = -EINVAL;
goto out;
}
 
ret = i915_gem_object_create_mmap_offset(obj);
-   if (ret)
+   if (ret) {
+   DRM_DEBUG_DRIVER(Failed to allocate mmap offset (ret=%d)\n, 
ret);
goto out;
+   }
 
*offset = drm_vma_node_offset_addr(obj-base.vma_node);
 
@@ -1558,6 +1567,7 @@ out:
drm_gem_object_unreference(obj-base);
 unlock:
mutex_unlock(dev-struct_mutex);
+   DRM_DEBUG_DRIVER(done, ret=%d\n, ret);
return ret;
 }

-- 
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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Thu, Jul 25, 2013 at 09:12:41PM +0200, Sedat Dilek wrote:
 New -3 dmesg.

That puts the ball back in the ddx's court. Next debugging patch:

diff --git a/src/intel_driver.c b/src/intel_driver.c
index f4d76bb..1f4f299 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -170,6 +170,7 @@ static Bool i830CreateScreenResources(ScreenPtr screen)
return FALSE;
 
intel_copy_fb(scrn);
+   ErrorF(%s: Success\n, __func__);
return TRUE;
 }
 
diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index 2f14173..6be7ebe 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -1150,11 +1150,15 @@ Bool intel_uxa_create_screen_resources(ScreenPtr screen)
intel_screen_private *intel = intel_get_screen_private(scrn);
dri_bo *bo = intel-front_buffer;
 
-   if (!uxa_resources_init(screen))
+   if (!uxa_resources_init(screen)) {
+   ErrorF(bang: %d\n, __LINE__);
return FALSE;
+   }
 
-   if (drm_intel_gem_bo_map_gtt(bo))
+   if (drm_intel_gem_bo_map_gtt(bo)) {
+   ErrorF(bang: %d\n, __LINE__);
return FALSE;
+   }
 
pixmap = screen-GetScreenPixmap(screen);
intel_set_pixmap_bo(pixmap, bo);
@@ -1167,8 +1171,10 @@ Bool intel_uxa_create_screen_resources(ScreenPtr screen)
   NULL);
scrn-displayWidth = intel-front_pitch / intel-cpp;
 
-   if (!intel_glamor_create_screen_resources(screen))
+   if (!intel_glamor_create_screen_resources(screen)) {
+   ErrorF(bang: %d\n, __LINE__);
return FALSE;
+   }
 
return TRUE;
 }

-- 
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] Linux 3.11-rc2 (acpi backlight, revert)

[Rafael J. Wysocki]

On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote:
 On 25 July 2013 14:00, Rafael J. Wysocki r...@sisk.pl wrote:
  On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
  On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
   On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:
   
Linus, do you want me to send a pull request reverting 8c5bd7a and 
efaa14c?
  
   Yes, but let's wait a while. Not because I think we'll fix the problem
   (hey, miracles might happen), but because I think it would be useful
   to couple the reverts with information about the particular machines
   that broke (and the people who reported it). So that when we
   inevitably try again, we can perhaps get some testing effort with
   those machines/people.
  
   It doesn't seem to be a show-stopped for a large number of people, so
   there's no huge hurry. I'd suggest doing the revert just in time for
   rc3, but waiting until then to gather info about people who see
   breakage.
  
   Sound like a plan?
 
  Yes, it does.
 
  OK, time to revert I guess.
 
  James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
  patch
  fixes the backlight for you.
 
 Works for me

Great!

James, Kamal, Jörg, thanks for confirmations.  I'll tentatively put the revert
into linux-next in a while.

Other people who experienced problems with backlight in 3.11-rc2, please let me
know whether or not the revert works for you too if you can.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Brown-paper-bag pull request here. The snb rc6 fix from the last pull
broke forcewake BIOS dirt cleanup, which with fixed. But that fix broke
the spinlock init sequence, which results in an ugly BUG when spinlock
debugging is enabled :( So I get to throw another patch at cc: stable to
fix up the mess ...

I'm working on process improvements to make sure that this doesn't slip
through again. We /should/ be running debug kernels in our -nightly
testing, but apparently we don't.

Otherwise a hdmi dotclock limit fix for hsw, fixes a 3.11 regression.
Otherwise nothing seems to be seriously amiss.

I'll be on vacation next week, Ben agreed to keep track of bugs and
regression reports. So please yell at him if something breaks ;-)

Cheers, Daniel


The following changes since commit 058ca4a22ebf22ea1cbedd6cc0340ed1e2e94ee1:

  Merge tag 'drm-intel-fixes-2013-07-22' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-22 
16:14:26 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-07-25

for you to fetch changes up to 14c5cec5d0cd73e7e9d4fbea2bbfeea8f3ade871:

  drm/i915: initialize gt_lock early with other spin locks (2013-07-25 15:39:15 
+0200)


Daniel Vetter (1):
  drm/i915: fix hdmi portclock limits

Jani Nikula (1):
  drm/i915: initialize gt_lock early with other spin locks

 drivers/gpu/drm/i915/i915_dma.c   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c | 19 ---
 drivers/gpu/drm/i915/intel_pm.c   |  2 --
 3 files changed, 17 insertions(+), 5 deletions(-)
-- 
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 Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 9:32 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 9:22 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Thu, Jul 25, 2013 at 09:12:41PM +0200, Sedat Dilek wrote:
 New -3 dmesg.

 That puts the ball back in the ddx's court. Next debugging patch:

 diff --git a/src/intel_driver.c b/src/intel_driver.c
 index f4d76bb..1f4f299 100644
 --- a/src/intel_driver.c
 +++ b/src/intel_driver.c
 @@ -170,6 +170,7 @@ static Bool i830CreateScreenResources(ScreenPtr screen)
 return FALSE;

 intel_copy_fb(scrn);
 +   ErrorF(%s: Success\n, __func__);
 return TRUE;
  }

 diff --git a/src/intel_uxa.c b/src/intel_uxa.c
 index 2f14173..6be7ebe 100644
 --- a/src/intel_uxa.c
 +++ b/src/intel_uxa.c
 @@ -1150,11 +1150,15 @@ Bool intel_uxa_create_screen_resources(ScreenPtr 
 screen)
 intel_screen_private *intel = intel_get_screen_private(scrn);
 dri_bo *bo = intel-front_buffer;

 -   if (!uxa_resources_init(screen))
 +   if (!uxa_resources_init(screen)) {
 +   ErrorF(bang: %d\n, __LINE__);
 return FALSE;
 +   }

 -   if (drm_intel_gem_bo_map_gtt(bo))
 +   if (drm_intel_gem_bo_map_gtt(bo)) {
 +   ErrorF(bang: %d\n, __LINE__);
 return FALSE;
 +   }

 pixmap = screen-GetScreenPixmap(screen);
 intel_set_pixmap_bo(pixmap, bo);
 @@ -1167,8 +1171,10 @@ Bool intel_uxa_create_screen_resources(ScreenPtr 
 screen)
NULL);
 scrn-displayWidth = intel-front_pitch / intel-cpp;

 -   if (!intel_glamor_create_screen_resources(screen))
 +   if (!intel_glamor_create_screen_resources(screen)) {
 +   ErrorF(bang: %d\n, __LINE__);
 return FALSE;
 +   }

 return TRUE;
  }

 --

 dmesg -4 and X.log attached.


What means the bang line?

[54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
[54.565] bang: 1159
[54.565]
Fatal server error:
[54.565] failed to create screen resources

From [1];
...
Bool intel_uxa_create_screen_resources(ScreenPtr screen)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
PixmapPtr pixmap;
intel_screen_private *intel = intel_get_screen_private(scrn);
dri_bo *bo = intel-front_buffer;

if (!uxa_resources_init(screen))
return FALSE;

if (drm_intel_gem_bo_map_gtt(bo))
return FALSE;

pixmap = screen-GetScreenPixmap(screen); --- Line #1159 ?
intel_set_pixmap_bo(pixmap, bo);
intel_get_pixmap_private(pixmap)-pinned |= PIN_SCANOUT;
screen-ModifyPixmapHeader(pixmap,
   scrn-virtualX,
   scrn-virtualY,
   -1, -1,
   intel-front_pitch,
   NULL);
scrn-displayWidth = intel-front_pitch / intel-cpp;

if (!intel_glamor_create_screen_resources(screen))
return FALSE;

return TRUE;
}
...

- Sedat -

[1] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/intel_uxa.c?id=6f5fd772c7ca656b86394a0f036d4e0cf5b33d8e#n1159


 - S.

 Chris Wilson, Intel Open Source Technology Centre
 --
 To unsubscribe from this list: send the line unsubscribe linux-next in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Ugly patches for stolen reservation

[Jesse Barnes]

On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar mi...@kernel.org wrote:

 
 * Jesse Barnes jbar...@virtuousgeek.org wrote:
 
  Patch 2/2 has the description, but suffice it to say I'm 
  not really pleased with this, though it does solve a 
  problem we have.  On some machines, we get MMIO space 
  allocated on top of this hidden memory, which can cause 
  problems.  I'm not sure if there are similar problems for 
  other hunks of the address space; if so it's possible 
  this could be made more general (though the bits for 
  looking up the address of this region are definitely 
  Intel graphics specific).
 
 It looks pretty hardware specific. Discovering it the hard 
 way and marking it e820 reserved in an early quirk is what 
 the firmware should have done to begin with - and I doubt 
 the kernel could do anything significantly cleaner.
 
 How does Windows manage to not crash? By luckily never 
 allocating PCI resources on top of the RAM? Or does it have 
 a quirk?

Pretty sure Windows doesn't allocate MMIO space the same way we do, so
doesn't run into this on platforms where it's not E820_RESERVED.  On
top of that, BIOS vendors probably just move things around until
Windows boots and the device manager doesn't have any dreaded yellow
bang icons that would prevent them from getting their designed for
windows sticker.

  Chris has some patches on top to add a new E820 type so 
  we can look up the region later, which removes some 
  redundant code in the i915 driver at least.
  
  Any comments?  I assume no one likes this, but maybe it's 
  just another early quirk we'll have to live with...
 
 No strong feelings against it - my only suggestion would be 
 to make this more visible - right now it's added as e820 
 reserved which hides amongst other areas already marked 
 reserved - would a low-key printk() of the range added make 
 it more apparent that a kernel quirk activated here?

Sounds good, I think Chris's patches should satisfy there.  They make
it a new E820 type so it's clear in /proc/iomem too.

 
 Just so that people know that it came from the kernel, not 
 the firmware.
 
 But in any case:
 
 Acked-by: Ingo Molnar mi...@kernel.org

Thanks,
-- 
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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
 What means the bang line?
 
 [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
 [54.565] bang: 1159
 [54.565]
 Fatal server error:
 [54.565] failed to create screen resources

That means between the kernel reporting success for
DRM_IOCTL_I915_GEM_MMAP_GTT and libdrm returning from
drm_intel_gem_bo_map_gtt(), something went wrong. This implies that the
call to mmap() failed.

I don't see how changing versions of the ddx would unmask the bug, nor
why the mmap() should suddenly start failing. Anybody have any
suggestions other than

diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index 2f14173..3872258 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -1149,12 +1149,15 @@ Bool intel_uxa_create_screen_resources(ScreenPtr screen)
PixmapPtr pixmap;
intel_screen_private *intel = intel_get_screen_private(scrn);
dri_bo *bo = intel-front_buffer;
+   int ret;
 
if (!uxa_resources_init(screen))
return FALSE;
 
-   if (drm_intel_gem_bo_map_gtt(bo))
+   if ((ret = drm_intel_gem_bo_map_gtt(bo))) {
+   ErrorF(%s:%d bang, errno=%d\n, __func__, __LINE__, -ret);
return FALSE;
+   }
 
pixmap = screen-GetScreenPixmap(screen);
intel_set_pixmap_bo(pixmap, bo);

which is most likely to report EINVAL (22)?
-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] Ugly patches for stolen reservation

[Daniel Vetter]

On Thu, Jul 25, 2013 at 01:16:48PM -0700, Jesse Barnes wrote:
 On Thu, 25 Jul 2013 22:05:51 +0200
 Ingo Molnar mi...@kernel.org wrote:
   Chris has some patches on top to add a new E820 type so 
   we can look up the region later, which removes some 
   redundant code in the i915 driver at least.
   
   Any comments?  I assume no one likes this, but maybe it's 
   just another early quirk we'll have to live with...
  
  No strong feelings against it - my only suggestion would be 
  to make this more visible - right now it's added as e820 
  reserved which hides amongst other areas already marked 
  reserved - would a low-key printk() of the range added make 
  it more apparent that a kernel quirk activated here?
 
 Sounds good, I think Chris's patches should satisfy there.  They make
 it a new E820 type so it's clear in /proc/iomem too.

I think it'd be good to get it all in in one go, since with Chris' patches
i915 will also use the detection logic from the quirk code, so more
testing for it. And imo the i915 cleanups shouldn't conflict really with
ongoing work in drm/i915, so could all go in through x86 trees.
-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 4/5] drm/i915: Add async page flip support for IVB

[Keith Packard]

 Generally I think checking our current sw state instead of reading hw
 registers would be safer, e.g. in case we start to queue up more than
 one pageflip. For async pageflips in benchmark mode flip as fast as
 you can queue would be a sensible mode.

Ok, I've moved the tiling checks to the general code and removed the
stride checks as those are already present there. These were moved to
the general code because the pointer to the previous FB has already
been overwritten by the time the queue_flip functions are called.

This should be followed by replacements for the last to patches in the
series.

-keith

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Add async page flip support for IVB

[Keith Packard]

This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/i915_reg.h  |  6 ++
 drivers/gpu/drm/i915/intel_display.c | 37 
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc3d6a7..029cfb0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -209,6 +209,7 @@
 #define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
 #define MI_DISPLAY_FLIPMI_INSTR(0x14, 2)
 #define MI_DISPLAY_FLIP_I915   MI_INSTR(0x14, 1)
+#define   MI_DISPLAY_FLIP_ASYNC_INDICATOR  (1  22)
 #define   MI_DISPLAY_FLIP_PLANE(n) ((n)  20)
 /* IVB has funny definitions for which plane to flip. */
 #define   MI_DISPLAY_FLIP_IVB_PLANE_A  (0  19)
@@ -217,6 +218,11 @@
 #define   MI_DISPLAY_FLIP_IVB_SPRITE_B (3  19)
 #define   MI_DISPLAY_FLIP_IVB_PLANE_C  (4  19)
 #define   MI_DISPLAY_FLIP_IVB_SPRITE_C (5  19)
+/* These go in the bottom of the base address value */
+#define   MI_DISPLAY_FLIP_TYPE_SYNC(0  0)
+#define   MI_DISPLAY_FLIP_TYPE_ASYNC   (1  0)
+#define   MI_DISPLAY_FLIP_TYPE_STEREO  (2  0)
+#define   MI_DISPLAY_FLIP_TYPE_SYNCHRONOUS (0  0)
 #define MI_ARB_ON_OFF  MI_INSTR(0x08, 0)
 #define   MI_ARB_ENABLE(10)
 #define   MI_ARB_DISABLE   (00)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bdb8854..166aa2c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1833,8 +1833,10 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
alignment = 64 * 1024;
break;
case I915_TILING_X:
-   /* pin() will align the object as required by fence */
-   alignment = 0;
+   /* Async page flipping requires X tiling and 32kB alignment, so 
just
+* make all X tiled frame buffers aligned for that
+*/
+   alignment = 32 * 1024;
break;
case I915_TILING_Y:
/* Despite that we check this in framebuffer_init userspace can
@@ -7514,6 +7516,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_ring_buffer *ring = dev_priv-ring[BCS];
uint32_t plane_bit = 0;
+   uint32_t cmd;
+   uint32_t base;
int ret;
 
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
@@ -7536,13 +7540,21 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
goto err_unpin;
}
 
+   cmd = MI_DISPLAY_FLIP_I915 | plane_bit;
+   base = i915_gem_obj_ggtt_offset(obj) + intel_crtc-dspaddr_offset;
+
+   if (flags  DRM_MODE_PAGE_FLIP_ASYNC) {
+   cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
+   base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
+   }
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err_unpin;
 
-   intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
+   intel_ring_emit(ring, cmd);
intel_ring_emit(ring, (fb-pitches[0] | obj-tiling_mode));
-   intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) + 
intel_crtc-dspaddr_offset);
+   intel_ring_emit(ring, base);
intel_ring_emit(ring, (MI_NOOP));
 
intel_mark_page_flip_active(intel_crtc);
@@ -7591,6 +7603,19 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
 fb-pitches[0] != crtc-fb-pitches[0]))
return -EINVAL;
 
+   /* Check tiling restrictions specific to asynchronous flips
+*/
+   if (page_flip_flags  DRM_MODE_PAGE_FLIP_ASYNC) {
+
+   /* New FB must be X tiled */
+   if (obj-tiling_mode != I915_TILING_X)
+   return -EINVAL;
+
+   /* Current FB must be X tiled */
+   if (to_intel_framebuffer(old_fb)-obj-tiling_mode != 
I915_TILING_X)
+   return -EINVAL;
+   }
+
work = kzalloc(sizeof *work, GFP_KERNEL);
if (work == NULL)
return -ENOMEM;
@@ -9705,6 +9730,10 @@ void intel_modeset_init(struct drm_device *dev)
dev-mode_config.max_width = 8192;
dev-mode_config.max_height = 8192;
}
+
+   if (IS_GEN7(dev))
+   dev-mode_config.async_page_flip = true;
+
dev-mode_config.fb_base = dev_priv-gtt.mappable_base;
 
DRM_DEBUG_KMS(%d display pipe%s available.\n,
-- 
1.8.3.2

___
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 async page flip support for SNB

[Keith Packard]

Just copies the IVB code

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_display.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 166aa2c..4a118c3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7465,20 +7465,29 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_ring_buffer *ring = dev_priv-ring[RCS];
uint32_t pf, pipesrc;
+   uint32_t cmd;
+   uint32_t base;
int ret;
 
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
if (ret)
goto err;
 
+   cmd = MI_DISPLAY_FLIP | MI_DISPLAY_FLIP_PLANE(intel_crtc-plane);
+   base = i915_gem_obj_ggtt_offset(obj) + intel_crtc-dspaddr_offset;
+
+   if (flags  DRM_MODE_PAGE_FLIP_ASYNC) {
+   cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
+   base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
+   }
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err_unpin;
 
-   intel_ring_emit(ring, MI_DISPLAY_FLIP |
-   MI_DISPLAY_FLIP_PLANE(intel_crtc-plane));
+   intel_ring_emit(ring, cmd);
intel_ring_emit(ring, fb-pitches[0] | obj-tiling_mode);
-   intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) + 
intel_crtc-dspaddr_offset);
+   intel_ring_emit(ring, base);
 
/* Contrary to the suggestions in the documentation,
 * Enable Panel Fitter does not seem to be required when page
@@ -9731,7 +9740,7 @@ void intel_modeset_init(struct drm_device *dev)
dev-mode_config.max_height = 8192;
}
 
-   if (IS_GEN7(dev))
+   if (IS_GEN6(dev) || IS_GEN7(dev))
dev-mode_config.async_page_flip = true;
 
dev-mode_config.fb_base = dev_priv-gtt.mappable_base;
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] resource: Introduce lookup_resource_by_name()

[Chris Wilson]

This is useful for drivers to find a resource inserted by, for example,
an early PCI quirk.

v2: We need to recurse through the resource tree as the named region we
are looking for may be a grandchild of the root node.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
 include/linux/ioport.h |  2 ++
 kernel/resource.c  | 30 ++
 2 files changed, 32 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 89b7c24..acad72f 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -158,6 +158,8 @@ extern int allocate_resource(struct resource *root, struct 
resource *new,
   resource_size_t),
 void *alignf_data);
 struct resource *lookup_resource(struct resource *root, resource_size_t start);
+struct resource *lookup_resource_by_name(struct resource *root,
+const char *name);
 int adjust_resource(struct resource *res, resource_size_t start,
resource_size_t size);
 resource_size_t resource_alignment(struct resource *res);
diff --git a/kernel/resource.c b/kernel/resource.c
index 3f285dc..c6dd827 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -624,6 +624,36 @@ struct resource *lookup_resource(struct resource *root, 
resource_size_t start)
return res;
 }
 
+static struct resource *__lookup_resource_by_name(struct resource *res,
+ const char *name)
+{
+   while (res) {
+   struct resource *child;
+
+   if (strcmp(res-name, name) == 0)
+   return res;
+
+   child = __lookup_resource_by_name(res-child, name);
+   if (child)
+   return child;
+
+   res = res-sibling;
+   }
+
+   return NULL;
+}
+
+struct resource *lookup_resource_by_name(struct resource *root, const char 
*name)
+{
+   struct resource *res;
+
+   read_lock(resource_lock);
+   res = __lookup_resource_by_name(root-child, name);
+   read_unlock(resource_lock);
+
+   return res;
+}
+
 /*
  * Insert a resource into the resource tree. If successful, return NULL,
  * otherwise return the conflicting resource (compare to __request_resource())
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915: Lookup stolen region reserved during early PCI quirk processing

[Chris Wilson]

As we now hook into the early PCI quirk table to earmark the Intel
Graphics Stolen region (inserting it into the iomem_resource) to prevent
it conflicting with any later resource allocations, we can simply walk
the iomem_resource tree and find it for our use. Thereby removing all of
our own code to define the stolen region.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/char/agp/intel-gtt.c   | 93 +++---
 drivers/gpu/drm/i915/i915_drv.h|  3 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 15 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c | 70 +
 include/drm/intel-gtt.h|  2 +-
 5 files changed, 26 insertions(+), 157 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index b8e2014..586efed 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -343,90 +343,14 @@ static const struct aper_size_info_fixed 
intel_fake_agp_sizes[] = {
 
 static unsigned int intel_gtt_stolen_size(void)
 {
-   u16 gmch_ctrl;
-   u8 rdct;
-   int local = 0;
-   static const int ddt[4] = { 0, 16, 32, 64 };
-   unsigned int stolen_size = 0;
-
-   if (INTEL_GTT_GEN == 1)
-   return 0; /* no stolen mem on i81x */
-
-   pci_read_config_word(intel_private.bridge_dev,
-I830_GMCH_CTRL, gmch_ctrl);
-
-   if (intel_private.bridge_dev-device == PCI_DEVICE_ID_INTEL_82830_HB ||
-   intel_private.bridge_dev-device == PCI_DEVICE_ID_INTEL_82845G_HB) {
-   switch (gmch_ctrl  I830_GMCH_GMS_MASK) {
-   case I830_GMCH_GMS_STOLEN_512:
-   stolen_size = KB(512);
-   break;
-   case I830_GMCH_GMS_STOLEN_1024:
-   stolen_size = MB(1);
-   break;
-   case I830_GMCH_GMS_STOLEN_8192:
-   stolen_size = MB(8);
-   break;
-   case I830_GMCH_GMS_LOCAL:
-   rdct = 
readb(intel_private.registers+I830_RDRAM_CHANNEL_TYPE);
-   stolen_size = (I830_RDRAM_ND(rdct) + 1) *
-   MB(ddt[I830_RDRAM_DDT(rdct)]);
-   local = 1;
-   break;
-   default:
-   stolen_size = 0;
-   break;
-   }
-   } else {
-   switch (gmch_ctrl  I855_GMCH_GMS_MASK) {
-   case I855_GMCH_GMS_STOLEN_1M:
-   stolen_size = MB(1);
-   break;
-   case I855_GMCH_GMS_STOLEN_4M:
-   stolen_size = MB(4);
-   break;
-   case I855_GMCH_GMS_STOLEN_8M:
-   stolen_size = MB(8);
-   break;
-   case I855_GMCH_GMS_STOLEN_16M:
-   stolen_size = MB(16);
-   break;
-   case I855_GMCH_GMS_STOLEN_32M:
-   stolen_size = MB(32);
-   break;
-   case I915_GMCH_GMS_STOLEN_48M:
-   stolen_size = MB(48);
-   break;
-   case I915_GMCH_GMS_STOLEN_64M:
-   stolen_size = MB(64);
-   break;
-   case G33_GMCH_GMS_STOLEN_128M:
-   stolen_size = MB(128);
-   break;
-   case G33_GMCH_GMS_STOLEN_256M:
-   stolen_size = MB(256);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_96M:
-   stolen_size = MB(96);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_160M:
-   stolen_size = MB(160);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_224M:
-   stolen_size = MB(224);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_352M:
-   stolen_size = MB(352);
-   break;
-   default:
-   stolen_size = 0;
-   break;
-   }
-   }
+   struct resource *r;
+   unsigned int stolen_size;
 
-   if (stolen_size  0) {
-   dev_info(intel_private.bridge_dev-dev, detected %dK %s 
memory\n,
-  stolen_size / KB(1), local ? local : stolen);
+   r = lookup_resource_by_name(iomem_resource, E820_STOLEN_IGFX_STRING);
+   if (r) {
+   stolen_size = r-end - r-start + 1;
+   dev_info(intel_private.bridge_dev-dev, detected %dK stolen 
memory\n,
+  stolen_size / KB(1));
} else {
dev_info(intel_private.bridge_dev-dev,
   no pre-allocated video memory detected\n);
@@ -1404,11 +1328,10 @@ int intel_gmch_probe(struct pci_dev 

[Intel-gfx] [PATCH 1/3] x86: Use a custom name for the Intel Graphics Stolen reservation

[Chris Wilson]

By giving the stolen a region a unique type and name, we then insert it
into the iomem_resource as a known resource. This clear identifies it to
the user when printing the e820 map (and later the iomem resources), and
exposes it to the driver for later use.

v2: Also need to add the string to a second id-to-name switch

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
 arch/x86/include/uapi/asm/e820.h |  2 ++
 arch/x86/kernel/e820.c   |  5 +
 arch/x86/kernel/early-quirks.c   | 12 ++--
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index bbae024..72384ce 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -38,6 +38,8 @@
 #define E820_NVS   4
 #define E820_UNUSABLE  5
 
+#define E820_STOLEN_IGFX 6
+#define E820_STOLEN_IGFX_STRING Intel Graphics Stolen
 
 /*
  * reserved RAM used by kernel itself
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index d32abea..3918f4d3 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -149,6 +149,10 @@ static void __init e820_print_type(u32 type)
case E820_UNUSABLE:
printk(KERN_CONT unusable);
break;
+
+   case E820_STOLEN_IGFX:
+   printk(KERN_CONT E820_STOLEN_IGFX_STRING);
+   break;
default:
printk(KERN_CONT type %u, type);
break;
@@ -915,6 +919,7 @@ static inline const char *e820_type_to_string(int e820_type)
case E820_ACPI: return ACPI Tables;
case E820_NVS:  return ACPI Non-volatile Storage;
case E820_UNUSABLE: return Unusable memory;
+   case E820_STOLEN_IGFX: return E820_STOLEN_IGFX_STRING;
default:return reserved;
}
 }
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bff8a6f..27b6d17 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -350,18 +350,10 @@ static void __init intel_graphics_stolen(int num, int 
slot, int func)
size = stolen_size(num, slot, func);
start = intel_stolen_base(num, slot, func);
if (size  start)
-   goto found;
-   else
-   break;
+   e820_add_region(start, size, E820_STOLEN_IGFX);
+   return;
}
}
-
-   /* No match or invalid data, don't bother reserving */
-   return;
-found:
-   /* Mark this space as reserved */
-   e820_add_region(start, size, E820_RESERVED);
-   return;
 }
 
 #define QFLAG_APPLY_ONCE   0x1
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3

[Chris Wilson]

Hmm, interesting licence block in i915_pciids.h - our claim to
grant licence but TG disclaims liability.
-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 1/2] drm/i915: split PCI IDs out into i915_drm.h v3

[Chris Wilson]

On Thu, Jul 25, 2013 at 09:37:48AM -0700, Jesse Barnes wrote:
 For use by userspace (at some point in the future) and other kernel code.
 
 v2: move PCI IDs to uabi (Chris)
 move PCI IDs to drm/ (Dave)
 v3: fixup Quanta detection - needs to come first (Daniel)

One last comment!

 +#define INTEL_VGA_DEVICE(id, info) { \
 + .class = PCI_BASE_CLASS_DISPLAY  16,  \
 + .class_mask = 0xff, \
 + .vendor = 0x8086,   \
 + .device = id,   \
 + .subvendor = PCI_ANY_ID,\
 + .subdevice = PCI_ANY_ID,\
 + .driver_data = (unsigned long) info }

libpciaccess doesn't define either PCI_BASE_CLASS_DISPLAY or PCI_ANY_ID.
Since we use the hex values for the rest of the elements, it would seem
to be tidier to also use 0x3  16 instead of PCI_BASE_CLASS_DISPLAY  16.
I would leave PCI_ANY_ID as a symbolic value though.
-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] Ugly patches for stolen reservation

[Jesse Barnes]

Well, it's ok if the boot loader writes to this memory, the worst
that'll happen is you'll see garbage on the screen.  If the boot loader
tries to do MMIO mapping on top it'll get into trouble... but why would
it do that?

Jesse

On Thu, 25 Jul 2013 15:42:25 -0700
H. Peter Anvin h...@zytor.com wrote:

 So the bootloader is just as likely to step on things... what happens when/if 
 it does?
 
 Ingo Molnar mi...@kernel.org wrote:
 
 * Jesse Barnes jbar...@virtuousgeek.org wrote:
 
  Patch 2/2 has the description, but suffice it to say I'm 
  not really pleased with this, though it does solve a 
  problem we have.  On some machines, we get MMIO space 
  allocated on top of this hidden memory, which can cause 
  problems.  I'm not sure if there are similar problems for 
  other hunks of the address space; if so it's possible 
  this could be made more general (though the bits for 
  looking up the address of this region are definitely 
  Intel graphics specific).
 
 It looks pretty hardware specific. Discovering it the hard 
 way and marking it e820 reserved in an early quirk is what 
 the firmware should have done to begin with - and I doubt 
 the kernel could do anything significantly cleaner.
 
 How does Windows manage to not crash? By luckily never 
 allocating PCI resources on top of the RAM? Or does it have 
 a quirk?
 
  Chris has some patches on top to add a new E820 type so 
  we can look up the region later, which removes some 
  redundant code in the i915 driver at least.
  
  Any comments?  I assume no one likes this, but maybe it's 
  just another early quirk we'll have to live with...
 
 No strong feelings against it - my only suggestion would be 
 to make this more visible - right now it's added as e820 
 reserved which hides amongst other areas already marked 
 reserved - would a low-key printk() of the range added make 
 it more apparent that a kernel quirk activated here?
 
 Just so that people know that it came from the kernel, not 
 the firmware.
 
 But in any case:
 
 Acked-by: Ingo Molnar mi...@kernel.org
 
 Thanks,
 
  Ingo
 


-- 
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 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3

[Jesse Barnes]

On Thu, 25 Jul 2013 23:59:25 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 Hmm, interesting licence block in i915_pciids.h - our claim to
 grant licence but TG disclaims liability.

Oops my manual search  replace obviously failed.  Will fix up.

-- 
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] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Sedat Dilek]

On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
 What means the bang line?

 [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
 [54.565] bang: 1159
 [54.565]
 Fatal server error:
 [54.565] failed to create screen resources

 That means between the kernel reporting success for
 DRM_IOCTL_I915_GEM_MMAP_GTT and libdrm returning from
 drm_intel_gem_bo_map_gtt(), something went wrong. This implies that the
 call to mmap() failed.

 I don't see how changing versions of the ddx would unmask the bug, nor
 why the mmap() should suddenly start failing. Anybody have any
 suggestions other than

 diff --git a/src/intel_uxa.c b/src/intel_uxa.c
 index 2f14173..3872258 100644
 --- a/src/intel_uxa.c
 +++ b/src/intel_uxa.c
 @@ -1149,12 +1149,15 @@ Bool intel_uxa_create_screen_resources(ScreenPtr 
 screen)
 PixmapPtr pixmap;
 intel_screen_private *intel = intel_get_screen_private(scrn);
 dri_bo *bo = intel-front_buffer;
 +   int ret;

 if (!uxa_resources_init(screen))
 return FALSE;

 -   if (drm_intel_gem_bo_map_gtt(bo))
 +   if ((ret = drm_intel_gem_bo_map_gtt(bo))) {
 +   ErrorF(%s:%d bang, errno=%d\n, __func__, __LINE__, -ret);
 return FALSE;
 +   }

 pixmap = screen-GetScreenPixmap(screen);
 intel_set_pixmap_bo(pixmap, bo);

 which is most likely to report EINVAL (22)?

Yupp, this shows me...

[28.542] (II) GLX: Initialized DRI2 GL provider for screen 0
[28.543] intel_uxa_create_screen_resources:1158 bang, errno=22
[28.543]
Fatal server error:
[28.543] failed to create screen resources


- Sedat -

 -Chris

 --
 Chris Wilson, Intel Open Source Technology Centre
 --
 To unsubscribe from this list: send the line unsubscribe linux-next in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


Xorg.0.log
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

[Chris Wilson]

On Fri, Jul 26, 2013 at 01:21:07AM +0200, Sedat Dilek wrote:
 On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
  What means the bang line?
 
  [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
  [54.565] bang: 1159
  [54.565]
  Fatal server error:
  [54.565] failed to create screen resources
 
  That means between the kernel reporting success for
  DRM_IOCTL_I915_GEM_MMAP_GTT and libdrm returning from
  drm_intel_gem_bo_map_gtt(), something went wrong. This implies that the
  call to mmap() failed.
 
  I don't see how changing versions of the ddx would unmask the bug, nor
  why the mmap() should suddenly start failing. Anybody have any
  suggestions other than
 
  diff --git a/src/intel_uxa.c b/src/intel_uxa.c
  index 2f14173..3872258 100644
  --- a/src/intel_uxa.c
  +++ b/src/intel_uxa.c
  @@ -1149,12 +1149,15 @@ Bool intel_uxa_create_screen_resources(ScreenPtr 
  screen)
  PixmapPtr pixmap;
  intel_screen_private *intel = intel_get_screen_private(scrn);
  dri_bo *bo = intel-front_buffer;
  +   int ret;
 
  if (!uxa_resources_init(screen))
  return FALSE;
 
  -   if (drm_intel_gem_bo_map_gtt(bo))
  +   if ((ret = drm_intel_gem_bo_map_gtt(bo))) {
  +   ErrorF(%s:%d bang, errno=%d\n, __func__, __LINE__, -ret);
  return FALSE;
  +   }
 
  pixmap = screen-GetScreenPixmap(screen);
  intel_set_pixmap_bo(pixmap, bo);
 
  which is most likely to report EINVAL (22)?
 
 Yupp, this shows me...
 
 [28.542] (II) GLX: Initialized DRI2 GL provider for screen 0
 [28.543] intel_uxa_create_screen_resources:1158 bang, errno=22
 [28.543]
 Fatal server error:
 [28.543] failed to create screen resources

I'm out of ideas, could you bisect this? Either kernel, userspace or
both. Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Ugly patches for stolen reservation

[Linus Torvalds]

On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin h...@zytor.com wrote:
 So the bootloader is just as likely to step on things... what happens when/if 
 it does?

This isn't a new problem. We've had this firmware tables don't show
all devices issue before.

The only odd thing about this one is how the quirk in question uses
e820_add_region() instead of just adding things to the MMIO list.
And I think that's actually likely a mistake.

So Jesse, why don't you do what the other quirks do, and claim an
actual MMIO resource? If you make it a real resource, you'll get to
use fancy things like REAL NAMES, and actually document it. With
human-readable strings.

See quirk_io_region() in drivers/pci/quirks.c for example. The same
code except for IORESOURCE_MEM should do a lovely job..

And even *if* it's already marked reserved in the e820 table, it just
looks nice in /proc/iomem.

Hmm?

   Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Ugly patches for stolen reservation

[Jesse Barnes]

To clarify: it'll either be marked reserved or not listed at all in e820, which 
is why I did this early, before any other e820 stuff like the RAM buffer are 
allocated, and before we could use the iomem resource (or maybe we could even 
early per Linus? I'll check). 

Jesse


--
Jesse Barnes, Intel Open Source Technology Center


 Original message 
From: H. Peter Anvin h...@zytor.com 
Date: 07/25/2013  5:49 PM  (GMT-08:00) 
To: Jesse Barnes jbar...@virtuousgeek.org 
Cc: Ingo Molnar 
mi...@kernel.org,intel-gfx@lists.freedesktop.org,linux-ker...@vger.kernel.org,mi...@elte.hu,t...@linutronix.de,torva...@linux-foundation.org
 
Subject: Re: Ugly patches for stolen reservation 
 
On 07/25/2013 04:17 PM, Jesse Barnes wrote:
 Well, it's ok if the boot loader writes to this memory, the worst
 that'll happen is you'll see garbage on the screen.  If the boot loader
 tries to do MMIO mapping on top it'll get into trouble... but why would
 it do that?
 
 Jesse

Much worse: it could be hunting for a place to put the kernel, and put
it there.

-hpa



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 14c5cec5d0cd (drm/i915:
initialize gt_lock early with other spin locks) from the drm-intel-fixes
tree and commit 907b28c56ea4 (drm/i915: Colocate all GT access routines
in the same file) from the drm-intel tree.

I fixed it up (using the drm-intel tree version) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpvRFii86KkM.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit 14c5cec5d0cd (drm/i915:
initialize gt_lock early with other spin locks) from the drm-intel-fixes
tree and commit 907b28c56ea4 (drm/i915: Colocate all GT access routines
in the same file) from the drm-intel tree.

I fixed it up (using the drm-intel tree version) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpVz4Y7nqqc6.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 irq storm mitigation in 3.10

[Egbert Eich]

Jan Niggemann writes:
  Hi Daniel,
  
  Am 25.07.2013 11:58, schrieb Daniel Vetter:
   Can you pls try the below
   patch (on top of Egbert's debug stuff)?
  
   diff --git a/drivers/gpu/drm/i915/i915_reg.h
   b/drivers/gpu/drm/i915/i915_reg.h
   index 6caa748..2d4c884 100644
   --- a/drivers/gpu/drm/i915/i915_reg.h
   +++ b/drivers/gpu/drm/i915/i915_reg.h
   @@ -1925,9 +1925,9 @@
  
#define PORT_HOTPLUG_STAT  (dev_priv-info-display_mmio_offset
   + 0x61114)
/* HDMI/DP bits are gen4+ */
   -#define   PORTB_HOTPLUG_LIVE_STATUS   (1  29)
   +#define   PORTD_HOTPLUG_LIVE_STATUS   (1  29)
#define   PORTC_HOTPLUG_LIVE_STATUS   (1  28)
   -#define   PORTD_HOTPLUG_LIVE_STATUS   (1  27)
   +#define   PORTB_HOTPLUG_LIVE_STATUS   (1  27)
#define   PORTD_HOTPLUG_INT_STATUS (3  21)
#define   PORTC_HOTPLUG_INT_STATUS (3  19)
#define   PORTB_HOTPLUG_INT_STATUS (3  17)
  I did, here are the logs:
  364K http://files.hz6.de/kern_20130724_2.log

I get a 'forbidden' when I try to access this.

  I don't understand what exactly this patch does, but I noticed:
  - much less drm debug info, resulting in a much smaller log
  - no more noticeable lag on my system (even though a storm was 
  detected).

Ok, so this indicates that the storm detection works now :)

  I double checked the latter and the lag seems indeed to be gone...

Before we actually masked out individual events it was irrelevant
if the bits were mixed up. Now we need to be correct on these.

Jan, thanks for your help!

Cheers,
Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx