[PATCH 1/2] iommu: Export intel_iommu_enabled to signal when iommu is in use

[Keith Packard]

From: Eugeni Dodonov <eugeni.dodo...@intel.com>

In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. The new 'intel_iommu_enabled' variable signals when the
iommu code is in operation.

Cc: Ted Phelps 
Cc: Peter 
Cc: Lukas Hejtmanek 
Cc: Andrew Lutomirski 
CC: Daniel Vetter 
Cc: Eugeni Dodonov 
Signed-off-by: Keith Packard 
---
 drivers/iommu/intel-iommu.c   |5 +
 include/linux/dma_remapping.h |2 ++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c0c7820..8dc19b8 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -405,6 +405,9 @@ int dmar_disabled = 0;
 int dmar_disabled = 1;
 #endif /*CONFIG_INTEL_IOMMU_DEFAULT_ON*/

+int intel_iommu_enabled = 0;
+EXPORT_SYMBOL_GPL(intel_iommu_enabled);
+
 static int dmar_map_gfx = 1;
 static int dmar_forcedac;
 static int intel_iommu_strict;
@@ -3647,6 +3650,8 @@ int __init intel_iommu_init(void)

bus_register_notifier(_bus_type, _nb);

+   intel_iommu_enabled = 1;
+
return 0;
 }

diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
index ef90cbd..57c9a8a 100644
--- a/include/linux/dma_remapping.h
+++ b/include/linux/dma_remapping.h
@@ -31,6 +31,7 @@ extern void free_dmar_iommu(struct intel_iommu *iommu);
 extern int iommu_calculate_agaw(struct intel_iommu *iommu);
 extern int iommu_calculate_max_sagaw(struct intel_iommu *iommu);
 extern int dmar_disabled;
+extern int intel_iommu_enabled;
 #else
 static inline int iommu_calculate_agaw(struct intel_iommu *iommu)
 {
@@ -44,6 +45,7 @@ static inline void free_dmar_iommu(struct intel_iommu *iommu)
 {
 }
 #define dmar_disabled  (1)
+#define intel_iommu_enabled (0)
 #endif


-- 
1.7.7.3

drm/i915: Enabling RC6 where possible

[Keith Packard]

Ok, here's a "final" patch set to enable RC6 where possible on SNB and IVB
machines.

The first patch creates a new variable, intel_iommu_enabled, that is
exported by the intel iommu code and set when that code has
successfully initialized itself. The old plan of using no_iommu ||
dmar_disabled would work -- those variables are set only by kernel
parameters and don't reflect what the system is actually doing about
virtualization.


The second patch uses that value on SNB to tell whether RC6 can be
enabled by default. On IVB, RC6 is always enabled.


Of course, in all cases, you can override the RC6 setting with the
i915 module parameter.

For those of you who have experienced the delights of RC6 crashing
your machines, please test as this will be heading to 3.2 unless you
find something wrong with it.

-keith

[PATCH] drm/i915: Clean up multi-threaded forcewake patch

[Keith Packard]

We learned that the ECOBUS register was inside the GT power well, and
so *did* need force wake to be read, so it gets removed from the list
of 'doesn't need force wake' registers.

That means the code reading ECOBUS after forcing the mt_force_wake
function to be called needs to use I915_READ_NOTRACE; it doesn't need
to do more force wake fun as it's already done it manually.

This also adds a comment explaining why the MT forcewake testing code
only needs to call mt_forcewake_get/put and not disable RC6 manually
-- the ECOBUS read will return 0 if the device is in RC6 and isn't
using MT forcewake, causing the test to work correctly.

Signed-off-by: Keith Packard 
Cc: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.c  |7 ---
 drivers/gpu/drm/i915/i915_drv.h  |3 +--
 drivers/gpu/drm/i915/intel_display.c |8 +++-
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 28836fe..e63a0f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -922,13 +922,6 @@ MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");

-/* We give fast paths for the really cool registers */
-#define NEEDS_FORCE_WAKE(dev_priv, reg) \
-   (((dev_priv)->info->gen >= 6) && \
-((reg) < 0x4) &&\
-((reg) != FORCEWAKE) && \
-((reg) != ECOBUS))
-
 #define __i915_read(x, y) \
 u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
u##x val = 0; \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1421118..bbd0604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1364,8 +1364,7 @@ void __gen6_gt_wait_for_fifo(struct drm_i915_private 
*dev_priv);
 #define NEEDS_FORCE_WAKE(dev_priv, reg) \
(((dev_priv)->info->gen >= 6) && \
 ((reg) < 0x4) &&\
-((reg) != FORCEWAKE) && \
-((reg) != ECOBUS))
+((reg) != FORCEWAKE))

 #define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a03ebf6..5abfc36 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8539,9 +8539,15 @@ static void intel_init_display(struct drm_device *dev)
if (IS_IVYBRIDGE(dev)) {
u32 ecobus;

+   /* A small trick here - if the bios hasn't configured 
MT forcewake,
+* and if the device is in RC6, then force_wake_mt_get 
will not wake
+* the device and the ECOBUS read will return zero. 
Which will be
+* (correctly) interpreted by the test below as MT 
forcewake being
+* disabled.
+*/
mutex_lock(>struct_mutex);
__gen6_gt_force_wake_mt_get(dev_priv);
-   ecobus = I915_READ(ECOBUS);
+   ecobus = I915_READ_NOTRACE(ECOBUS);
__gen6_gt_force_wake_mt_put(dev_priv);
mutex_unlock(>struct_mutex);

-- 
1.7.7.3

[PATCH] drm/i915: Clean up multi-threaded forcewake patch

[Keith Packard]

We learned that the ECOBUS register was inside the GT power well, and
so *did* need force wake to be read, so it gets removed from the list
of 'doesn't need force wake' registers.

That means the code reading ECOBUS after forcing the mt_force_wake
function to be called needs to use I915_READ_NOTRACE; it doesn't need
to do more force wake fun as it's already done it manually.

This also adds a comment explaining why the MT forcewake testing code
only needs to call mt_forcewake_get/put and not disable RC6 manually
-- the ECOBUS read will return 0 if the device is in RC6 and isn't
using MT forcewake, causing the test to work correctly.

Signed-off-by: Keith Packard kei...@keithp.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/i915_drv.c  |7 ---
 drivers/gpu/drm/i915/i915_drv.h  |3 +--
 drivers/gpu/drm/i915/intel_display.c |8 +++-
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 28836fe..e63a0f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -922,13 +922,6 @@ MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE(GPL and additional rights);
 
-/* We give fast paths for the really cool registers */
-#define NEEDS_FORCE_WAKE(dev_priv, reg) \
-   (((dev_priv)-info-gen = 6)  \
-((reg)  0x4) \
-((reg) != FORCEWAKE)  \
-((reg) != ECOBUS))
-
 #define __i915_read(x, y) \
 u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
u##x val = 0; \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1421118..bbd0604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1364,8 +1364,7 @@ void __gen6_gt_wait_for_fifo(struct drm_i915_private 
*dev_priv);
 #define NEEDS_FORCE_WAKE(dev_priv, reg) \
(((dev_priv)-info-gen = 6)  \
 ((reg)  0x4) \
-((reg) != FORCEWAKE)  \
-((reg) != ECOBUS))
+((reg) != FORCEWAKE))
 
 #define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a03ebf6..5abfc36 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8539,9 +8539,15 @@ static void intel_init_display(struct drm_device *dev)
if (IS_IVYBRIDGE(dev)) {
u32 ecobus;
 
+   /* A small trick here - if the bios hasn't configured 
MT forcewake,
+* and if the device is in RC6, then force_wake_mt_get 
will not wake
+* the device and the ECOBUS read will return zero. 
Which will be
+* (correctly) interpreted by the test below as MT 
forcewake being
+* disabled.
+*/
mutex_lock(dev-struct_mutex);
__gen6_gt_force_wake_mt_get(dev_priv);
-   ecobus = I915_READ(ECOBUS);
+   ecobus = I915_READ_NOTRACE(ECOBUS);
__gen6_gt_force_wake_mt_put(dev_priv);
mutex_unlock(dev-struct_mutex);
 
-- 
1.7.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] iommu: Export intel_iommu_enabled to signal when iommu is in use

[Keith Packard]

From: Eugeni Dodonov eugeni.dodo...@intel.com

In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. The new 'intel_iommu_enabled' variable signals when the
iommu code is in operation.

Cc: Ted Phelps phe...@gnusto.com
Cc: Peter pab1...@gmail.com
Cc: Lukas Hejtmanek xhejt...@fi.muni.cz
Cc: Andrew Lutomirski l...@mit.edu
CC: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/iommu/intel-iommu.c   |5 +
 include/linux/dma_remapping.h |2 ++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c0c7820..8dc19b8 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -405,6 +405,9 @@ int dmar_disabled = 0;
 int dmar_disabled = 1;
 #endif /*CONFIG_INTEL_IOMMU_DEFAULT_ON*/
 
+int intel_iommu_enabled = 0;
+EXPORT_SYMBOL_GPL(intel_iommu_enabled);
+
 static int dmar_map_gfx = 1;
 static int dmar_forcedac;
 static int intel_iommu_strict;
@@ -3647,6 +3650,8 @@ int __init intel_iommu_init(void)
 
bus_register_notifier(pci_bus_type, device_nb);
 
+   intel_iommu_enabled = 1;
+
return 0;
 }
 
diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
index ef90cbd..57c9a8a 100644
--- a/include/linux/dma_remapping.h
+++ b/include/linux/dma_remapping.h
@@ -31,6 +31,7 @@ extern void free_dmar_iommu(struct intel_iommu *iommu);
 extern int iommu_calculate_agaw(struct intel_iommu *iommu);
 extern int iommu_calculate_max_sagaw(struct intel_iommu *iommu);
 extern int dmar_disabled;
+extern int intel_iommu_enabled;
 #else
 static inline int iommu_calculate_agaw(struct intel_iommu *iommu)
 {
@@ -44,6 +45,7 @@ static inline void free_dmar_iommu(struct intel_iommu *iommu)
 {
 }
 #define dmar_disabled  (1)
+#define intel_iommu_enabled (0)
 #endif
 
 
-- 
1.7.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm/i915: Enabling RC6 where possible

[Keith Packard]

Ok, here's a final patch set to enable RC6 where possible on SNB and IVB
machines.

The first patch creates a new variable, intel_iommu_enabled, that is
exported by the intel iommu code and set when that code has
successfully initialized itself. The old plan of using no_iommu ||
dmar_disabled would work -- those variables are set only by kernel
parameters and don't reflect what the system is actually doing about
virtualization.


The second patch uses that value on SNB to tell whether RC6 can be
enabled by default. On IVB, RC6 is always enabled.


Of course, in all cases, you can override the RC6 setting with the
i915 module parameter.

For those of you who have experienced the delights of RC6 crashing
your machines, please test as this will be heading to 3.2 unless you
find something wrong with it.

-keith
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/kms: Use the standard VESA timeout for DDC channels

[Keith Packard]

On Fri, 21 Oct 2011 09:10:12 +0200, Jean Delvare  wrote:

> - /* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always
> -  * make this, 2 jiffies is a lot more reliable */
> - i2c->algo.bit.timeout = 2;
> + i2c->algo.bit.timeout = usecs_to_jiffies(2200); /* from VESA */

[Intel-gfx] [PATCH] iommu: export no_iommu and dmar_disabled symbols

[Keith Packard]

On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse  
wrote:

> This is horrid. In the general case, drivers have no business knowing
> this. We need to properly identify what is wrong with this hardware, and
> put in a quirk for it ? perhaps refusing to enable the IOMMU at all on
> the broken chipsets.

That'd be fine with me, right now we're disabling RC6 and semaphores --
semaphores aren't all that important, although they do improve
performance a bit. RC6 is important, saving a huge amount of power.

I'd also be OK with requiring special options to enable DMAR and having
that also disable RC6/semaphores, if you'd rather expose that. In either
case, we need something that works and avoids hanging machines.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang  
wrote:

> What I need is a hot plug hook that knows whether the monitor is
> plugged or removed, which is only possible if the hook is called
> after ->detect().

That would be mode_set to tell you that the monitor is in use, and the
disable function to tell you when the monitor is no longer in use.

You do not want to do anything to the hardware in the hot_plug paths;
those are strictly informative; telling user space which connectors are
present.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang fengguang...@intel.com wrote:

 What I need is a hot plug hook that knows whether the monitor is
 plugged or removed, which is only possible if the hook is called
 after -detect().

That would be mode_set to tell you that the monitor is in use, and the
disable function to tell you when the monitor is no longer in use.

You do not want to do anything to the hardware in the hot_plug paths;
those are strictly informative; telling user space which connectors are
present.

-- 
keith.pack...@intel.com


pgpOxnjFD8SfE.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] iommu: export no_iommu and dmar_disabled symbols

[Keith Packard]

On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse dw...@infradead.org wrote:

 This is horrid. In the general case, drivers have no business knowing
 this. We need to properly identify what is wrong with this hardware, and
 put in a quirk for it — perhaps refusing to enable the IOMMU at all on
 the broken chipsets.

That'd be fine with me, right now we're disabling RC6 and semaphores --
semaphores aren't all that important, although they do improve
performance a bit. RC6 is important, saving a huge amount of power.

I'd also be OK with requiring special options to enable DMAR and having
that also disable RC6/semaphores, if you'd rather expose that. In either
case, we need something that works and avoids hanging machines.

-- 
keith.pack...@intel.com


pgpxTRscEyNin.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/kms: Use the standard VESA timeout for DDC channels

[Keith Packard]

On Fri, 21 Oct 2011 09:10:12 +0200, Jean Delvare jdelv...@suse.de wrote:

 - /* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always
 -  * make this, 2 jiffies is a lot more reliable */
 - i2c-algo.bit.timeout = 2;
 + i2c-algo.bit.timeout = usecs_to_jiffies(2200); /* from VESA */

From my reading of the usecs_to_jiffies code, it always returns a time
at least as long as requested, so this will ensure that you're waiting
at least 2.2ms, unlike 2 jiffies which is some random amount of time
depending on the HZ setting in the kernel.

Reviewed-by: Keith Packard kei...@keithp.com

-- 
keith.pack...@intel.com


pgpY1RP4t0c3h.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Wed, 23 Nov 2011 09:28:52 +0200 (EET), Meelis Roos  wrote:

> Yes, VT-x and VT-d are both enabled from BIOS setup.

Any reason for that? We've found all kinds of problems with DMAR enabled
on these machines that is only resolved by completely turning it
off. You might try with intel_iommu=off and make sure that's stable.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

i915: hangcheck timer elapsed

[Keith Packard]

On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds  wrote:

> X is hung, but I can at least switch VT's and send this from a text 
> terminal..

Yeah, the GPU is locked up; doesn't look like we did anything wrong in
the kernel here; it's happily waiting for the GPU which isn't moving.

Presumably a bug in either the 2D driver or Mesa. I'm betting the 2D
driver, and yes, I'm trying to fix this (by deleting code, which is
always the best way).

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett  wrote:

> So the user has to choose between 5W of power saving or having dmar? And 
> we default to giving them dmar? I think that's going to come as a 
> surprise to people.

You'd have to go into the BIOS to turn this on for most machines at
least?

But, yeah, it seems like we should be turning DMAR off unless explicitly
requested; I can't understand how you'd ever need this running native on
the hardware. Not exactly an area I care about deeply; I've always
worked hard to make sure all virtualization garbage is disabled on every
machine I use.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang  
wrote:

> So the v3 patch will behave equally well on KMS console, gnome desktop
> and bare X. Shall we just use it, or go back and use the original
> ->hot_remove patch?

I'm not sure why we need any change to the core DRM code. The HDMI and
DP drivers will be told when to turn the monitors on and off, and that's
the appropriate time to control whether audio is routed to them. Hotplug
is considered simply a notification to user space that something has
changed -- user space is in charge of configuring which outputs are in
use.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Tue, 22 Nov 2011 13:08:06 +0200 (EET), Meelis Roos  wrote:

> > 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
> > hangs in random places while using X.

Do you have VT-d enabled in the BIOS?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

Re: Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Tue, 22 Nov 2011 13:08:06 +0200 (EET), Meelis Roos mr...@linux.ee wrote:

  3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
  hangs in random places while using X.

Do you have VT-d enabled in the BIOS?

-- 
keith.pack...@intel.com


pgpDDQsjBrQss.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang fengguang...@intel.com wrote:

 So the v3 patch will behave equally well on KMS console, gnome desktop
 and bare X. Shall we just use it, or go back and use the original
 -hot_remove patch?

I'm not sure why we need any change to the core DRM code. The HDMI and
DP drivers will be told when to turn the monitors on and off, and that's
the appropriate time to control whether audio is routed to them. Hotplug
is considered simply a notification to user space that something has
changed -- user space is in charge of configuring which outputs are in
use.

-- 
keith.pack...@intel.com


pgpYH4pomV8WR.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com wrote:

 So the user has to choose between 5W of power saving or having dmar? And 
 we default to giving them dmar? I think that's going to come as a 
 surprise to people.

You'd have to go into the BIOS to turn this on for most machines at
least?

But, yeah, it seems like we should be turning DMAR off unless explicitly
requested; I can't understand how you'd ever need this running native on
the hardware. Not exactly an area I care about deeply; I've always
worked hard to make sure all virtualization garbage is disabled on every
machine I use.

-- 
keith.pack...@intel.com


pgpRsQVpYbb00.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: hangcheck timer elapsed

[Keith Packard]

On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds 
torva...@linux-foundation.org wrote:

 X is hung, but I can at least switch VT's and send this from a text 
 terminal..

Yeah, the GPU is locked up; doesn't look like we did anything wrong in
the kernel here; it's happily waiting for the GPU which isn't moving.

Presumably a bug in either the 2D driver or Mesa. I'm betting the 2D
driver, and yes, I'm trying to fix this (by deleting code, which is
always the best way).

-- 
keith.pack...@intel.com


pgpafhKSqqRa9.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Wed, 23 Nov 2011 09:28:52 +0200 (EET), Meelis Roos mr...@linux.ee wrote:

 Yes, VT-x and VT-d are both enabled from BIOS setup.

Any reason for that? We've found all kinds of problems with DMAR enabled
on these machines that is only resolved by completely turning it
off. You might try with intel_iommu=off and make sure that's stable.

-- 
keith.pack...@intel.com


pgpI2xpV2z070.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

max PWM is zero

[Keith Packard]

On Mon, 21 Nov 2011 22:48:21 + (Local time zone must be set--see zic manual 
page), Marcos Paulo de Souza  wrote:

> My max_brightness is 1, and my brightness is 0.

Right, we've prevented the internal backlight driver from exposing a max
value of 0 as that's just confusing.

> But, my acpi_video0 have a 
> max_brightness value = 9...

Right, sounds like your device is just using some other backlight
controller, which is perfectly reasonable.

> So, what can I do to silence this warning...? Change the driver of 
> backlight?

If your backlight keys work correctly, then things are fine and perhaps
we should just remove the warning from the driver, or disable the
internal driver when we discover this situation.

This is the first time I've heard of this warning appearing...

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

[Keith Packard]

On Mon, 21 Nov 2011 17:23:06 +0100, Daniel Vetter  wrote:

> Indeed, nice catch (albeit totally unlikely to be hit, because the error
> only happens when the gpu ceases to progress in the ring, so imo not
> stable material). Keith, please pick this up for fixes, thanks.

It's already there and queued for airlied :-)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 19:05:38 +0800, Wu Fengguang  
wrote:

> Ah I got it. I'm running debian+fluxbox w/o those fancy features...

Then you can manually run the 'xrandr' command to configure the new
monitor as desired, at which point the kernel mode_set function will be
called.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang  
wrote:
> On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
> or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
> receive hot plug events and take action to refresh its device state and
> ELD contents.
> 
> A new callback ->hotplug() is added to struct drm_connector_funcs which
> will be called immediately after ->detect() knowing that the monitor is
> either plugged or unplugged.
> 
> It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
> necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
> in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
> in ->hotplug.

The X environment will eventually call mode_set when the user
environment decides to use the monitor. Any audio bits can, and should,
await the user's choice of a video mode before choosing the audio format
to use. We should not be adding eld information until the monitor is in
use.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang fengguang...@intel.com wrote:
 On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
 or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
 receive hot plug events and take action to refresh its device state and
 ELD contents.
 
 A new callback -hotplug() is added to struct drm_connector_funcs which
 will be called immediately after -detect() knowing that the monitor is
 either plugged or unplugged.
 
 It's noticed that X may not call -mode_set() at monitor hot plug, so it's
 necessary to call drm_edid_to_eld() earlier at -detect() time rather than
 in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
 in -hotplug.

The X environment will eventually call mode_set when the user
environment decides to use the monitor. Any audio bits can, and should,
await the user's choice of a video mode before choosing the audio format
to use. We should not be adding eld information until the monitor is in
use.

-- 
keith.pack...@intel.com


pgp4h11z4X0OU.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 19:05:38 +0800, Wu Fengguang fengguang...@intel.com wrote:

 Ah I got it. I'm running debian+fluxbox w/o those fancy features...

Then you can manually run the 'xrandr' command to configure the new
monitor as desired, at which point the kernel mode_set function will be
called.

-- 
keith.pack...@intel.com


pgpehj0HQTyQN.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

[Keith Packard]

On Mon, 21 Nov 2011 17:23:06 +0100, Daniel Vetter dan...@ffwll.ch wrote:

 Indeed, nice catch (albeit totally unlikely to be hit, because the error
 only happens when the gpu ceases to progress in the ring, so imo not
 stable material). Keith, please pick this up for fixes, thanks.

It's already there and queued for airlied :-)

-- 
keith.pack...@intel.com


pgpwHjTLTmsoZ.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

max PWM is zero

[Keith Packard]

On Sat, 19 Nov 2011 11:26:07 + (Local time zone must be set--see zic manual 
page), Marcos Paulo de Souza  wrote:
> So, anybody gets the same message?
> 
> I'm trying the 3.2-rc2 and it gives the same message.
> 
> Again, if you need someone to make tests, or test some patches, I'm 
> able to do this.

Is your machine even using the intel backlight device? You can test this
by:

# cd /sys/class/backlight/intel_backlight

Then look at 'max_brightness' and try echoing a range of numbers from 0
to max_brightness into the brightness file and see if it changes the
backlight.

It's more than possible that your machine is simply using some other
hardware to drive the backlight and that the integrated backlight
controller is simply disabled.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov  
wrote:

> Just one question I caught on 2nd read. Shouldn't we have #else within
> this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
> not defined, we'll always disable rc6.

Oops! Thanks for catching this. Here's a new version of that function
(the rest of the patch is the same). This one has explicit conditions
for Ironlake and Sandybridge (when CONFIG_INTEL_IOMMU is set), allowing
the Ivybridge and Sandybridge-without-IOMMU cases to take the default
path. This will also cause all future chips to enable rc6 by default.

+static bool intel_enable_rc6(struct drm_device *dev)
+{
+   /*
+* Respect the kernel parameter if it is set
+*/
+   if (i915_enable_rc6 >= 0)
+   return i915_enable_rc6;
+
+   /*
+* Disable RC6 on Ironlake
+*/
+   if (INTEL_INFO(dev)->gen == 5)
+   return 0;
+
+#ifdef CONFIG_INTEL_IOMMU
+   /*
+* Enable rc6 on Sandybridge if DMA remapping is disabled
+*/
+   if (INTEL_INFO(dev)->gen == 6)
+   return no_iommu || dmar_disabled;
+#endif
+   return 1;
+}
+

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov eug...@dodonov.net wrote:

 Just one question I caught on 2nd read. Shouldn't we have #else within
 this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
 not defined, we'll always disable rc6.

Oops! Thanks for catching this. Here's a new version of that function
(the rest of the patch is the same). This one has explicit conditions
for Ironlake and Sandybridge (when CONFIG_INTEL_IOMMU is set), allowing
the Ivybridge and Sandybridge-without-IOMMU cases to take the default
path. This will also cause all future chips to enable rc6 by default.
 
+static bool intel_enable_rc6(struct drm_device *dev)
+{
+   /*
+* Respect the kernel parameter if it is set
+*/
+   if (i915_enable_rc6 = 0)
+   return i915_enable_rc6;
+
+   /*
+* Disable RC6 on Ironlake
+*/
+   if (INTEL_INFO(dev)-gen == 5)
+   return 0;
+
+#ifdef CONFIG_INTEL_IOMMU
+   /*
+* Enable rc6 on Sandybridge if DMA remapping is disabled
+*/
+   if (INTEL_INFO(dev)-gen == 6)
+   return no_iommu || dmar_disabled;
+#endif
+   return 1;
+}
+

-- 
keith.pack...@intel.com


pgpsVTFwiWzSB.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Keith Packard]

Hey Dave:

Here's a pile of fixes to the intel driver. This pull includes the three
patches you already merged in, but it merges cleanly so I didn't rebase
around them.

The following changes since commit 37be944a0270402f9cda291a930b0286f6dc92f5:

  Merge branch 'drm-core-next' of git://people.freedesktop.org/~airlied/linux 
(2011-10-28 05:54:23 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~keithp/linux drm-intel-fixes

Adam Jackson (1):
  drm/i915: intel_choose_pipe_bpp_dither messages should be DRM_DEBUG_KMS

Ben Widawsky (1):
  drm/i915: forcewake warning fixes in debugfs

Dan Carpenter (1):
  drm/i915: fix if statement (bogus semi-colon)

Daniel Vetter (4):
  drm/i915: disable temporal dithering on the internal panel
  drm/i915: only match on PCI_BASE_CLASS_DISPLAY
  drm/i915: Ivybridge still has fences!
  drm/i915: add constants to size fence arrays and fields

Eric Anholt (3):
  drm/i915: Fix object refcount leak on mmappable size limit error path.
  drm/i915: Turn on a required 3D clock gating bit on Sandybridge.
  drm/i915: Turn on another required clock gating bit on gen6.

Jesse Barnes (1):
  drm/i915: enable cacheable objects on Ivybridge

Keith Packard (12):
  agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
  drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
  drm/i915: Module parameters using '-1' as default must be signed type
  drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control
  drm/i915: Remove link_status field from intel_dp structure
  drm/i915: Treat PCH eDP like DP in most places
  drm/i915: Let panel power sequencing hardware do its job
  drm/i915: Make DP prepare/commit consistent with DP dpms
  drm/i915: Try harder during dp pattern 1 link training
  drm/i915: Remove trailing white space
  drm/i915: Initiate DP link training only on the lanes we'll be using
  drm/i915: Use DPCD value for max DP lanes.

Rakib Mullick (1):
  drm, i915: Fix memory leak in i915_gem_busy_ioctl().

Takashi Iwai (1):
  drm/i915: Fix inconsistent backlight level during disabled

 drivers/char/agp/intel-gtt.c |7 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |   57 +-
 drivers/gpu/drm/i915/i915_drv.c  |6 +-
 drivers/gpu/drm/i915/i915_drv.h  |   19 +-
 drivers/gpu/drm/i915/i915_gem.c  |   14 +-
 drivers/gpu/drm/i915/i915_irq.c  |1 +
 drivers/gpu/drm/i915/i915_reg.h  |   21 ++-
 drivers/gpu/drm/i915/i915_suspend.c  |2 +
 drivers/gpu/drm/i915/intel_display.c |   33 ++-
 drivers/gpu/drm/i915/intel_dp.c  |  411 +++--
 drivers/gpu/drm/i915/intel_panel.c   |3 +-
 11 files changed, 359 insertions(+), 215 deletions(-)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2018/4e3efcd7/attachment-0001.pgp>

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. Make the default value for the parameter turn
it on in these cases. Setting the value to either 0 or 1 will force
the specified behavior.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_drv.c  |4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |2 +-
 drivers/gpu/drm/i915/intel_display.c |   26 +++---
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 15bfa91..cf5c1bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -63,10 +63,10 @@ module_param_named(semaphores, i915_semaphores, int, 0600);
 MODULE_PARM_DESC(semaphores,
"Use semaphores for inter-ring sync (default: false)");

-unsigned int i915_enable_rc6 __read_mostly = 0;
+int i915_enable_rc6 __read_mostly = -1;
 module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600);
 MODULE_PARM_DESC(i915_enable_rc6,
-   "Enable power-saving render C-state 6 (default: true)");
+   "Enable power-saving render C-state 6 (default: -1 (false when 
VT-d enabled)");

 int i915_enable_fbc __read_mostly = -1;
 module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a9c1b9..172b022 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1002,7 +1002,7 @@ extern unsigned int i915_semaphores __read_mostly;
 extern unsigned int i915_lvds_downclock __read_mostly;
 extern int i915_panel_use_ssc __read_mostly;
 extern int i915_vbt_sdvo_panel_type __read_mostly;
-extern unsigned int i915_enable_rc6 __read_mostly;
+extern int i915_enable_rc6 __read_mostly;
 extern int i915_enable_fbc __read_mostly;
 extern bool i915_enable_hangcheck __read_mostly;

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e77a863..13fd4c0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -38,8 +38,11 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "drm_dp_helper.h"
-
 #include "drm_crtc_helper.h"
+#ifdef CONFIG_INTEL_IOMMU
+#include 
+#include 
+#endif

 #define HAS_eDP (intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))

@@ -7887,6 +7890,23 @@ void intel_init_emon(struct drm_device *dev)
dev_priv->corr = (lcfuse & LCFUSE_HIV_MASK);
 }

+static bool intel_enable_rc6(struct drm_device *dev)
+{
+   if (i915_enable_rc6 >= 0)
+   return i915_enable_rc6;
+   if (INTEL_INFO(dev)->gen >= 7)
+   return 1;
+#ifdef CONFIG_INTEL_IOMMU
+   /*
+* Only enable RC6 if all dma remapping is disabled, or if
+* there's no iommu present in the machine.
+*/
+   if (INTEL_INFO(dev)->gen == 6)
+   return no_iommu || dmar_disabled;
+#endif
+   return 0;
+}
+
 void gen6_enable_rps(struct drm_i915_private *dev_priv)
 {
u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
@@ -7923,7 +7943,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
I915_WRITE(GEN6_RC6p_THRESHOLD, 10);
I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */

-   if (i915_enable_rc6)
+   if (intel_enable_rc6(dev_priv->dev))
rc6_mask = GEN6_RC_CTL_RC6p_ENABLE |
GEN6_RC_CTL_RC6_ENABLE;

@@ -8372,7 +8392,7 @@ void ironlake_enable_rc6(struct drm_device *dev)
/* rc6 disabled by default due to repeated reports of hanging during
 * boot and resume.
 */
-   if (!i915_enable_rc6)
+   if (!intel_enable_rc6(dev))
return;

mutex_lock(>struct_mutex);
-- 
1.7.7.3

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Keith Packard]

On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang  
wrote:

> However when in X, ->mode_set won't be called at all.  Only
> ->get_modes and ->detect are called...

The desktop software will call mode_set when it configures the
monitor. Otherwise, it's not being used (and so shouldn't have audio
routed to it by default).

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

Re: [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Keith Packard]

On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com wrote:

 However when in X, -mode_set won't be called at all.  Only
 -get_modes and -detect are called...

The desktop software will call mode_set when it configures the
monitor. Otherwise, it's not being used (and so shouldn't have audio
routed to it by default).

-- 
keith.pack...@intel.com


pgpXrM48veW26.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. Make the default value for the parameter turn
it on in these cases. Setting the value to either 0 or 1 will force
the specified behavior.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 15bfa91..cf5c1bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -63,10 +63,10 @@ module_param_named(semaphores, i915_semaphores, int, 0600);
 MODULE_PARM_DESC(semaphores,
Use semaphores for inter-ring sync (default: false));
 
-unsigned int i915_enable_rc6 __read_mostly = 0;
+int i915_enable_rc6 __read_mostly = -1;
 module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600);
 MODULE_PARM_DESC(i915_enable_rc6,
-   Enable power-saving render C-state 6 (default: true));
+   Enable power-saving render C-state 6 (default: -1 (false when 
VT-d enabled));
 
 int i915_enable_fbc __read_mostly = -1;
 module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a9c1b9..172b022 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1002,7 +1002,7 @@ extern unsigned int i915_semaphores __read_mostly;
 extern unsigned int i915_lvds_downclock __read_mostly;
 extern int i915_panel_use_ssc __read_mostly;
 extern int i915_vbt_sdvo_panel_type __read_mostly;
-extern unsigned int i915_enable_rc6 __read_mostly;
+extern int i915_enable_rc6 __read_mostly;
 extern int i915_enable_fbc __read_mostly;
 extern bool i915_enable_hangcheck __read_mostly;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e77a863..13fd4c0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -38,8 +38,11 @@
 #include i915_drv.h
 #include i915_trace.h
 #include drm_dp_helper.h
-
 #include drm_crtc_helper.h
+#ifdef CONFIG_INTEL_IOMMU
+#include linux/dma_remapping.h
+#include linux/dmar.h
+#endif
 
 #define HAS_eDP (intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))
 
@@ -7887,6 +7890,23 @@ void intel_init_emon(struct drm_device *dev)
dev_priv-corr = (lcfuse  LCFUSE_HIV_MASK);
 }
 
+static bool intel_enable_rc6(struct drm_device *dev)
+{
+   if (i915_enable_rc6 = 0)
+   return i915_enable_rc6;
+   if (INTEL_INFO(dev)-gen = 7)
+   return 1;
+#ifdef CONFIG_INTEL_IOMMU
+   /*
+* Only enable RC6 if all dma remapping is disabled, or if
+* there's no iommu present in the machine.
+*/
+   if (INTEL_INFO(dev)-gen == 6)
+   return no_iommu || dmar_disabled;
+#endif
+   return 0;
+}
+
 void gen6_enable_rps(struct drm_i915_private *dev_priv)
 {
u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
@@ -7923,7 +7943,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
I915_WRITE(GEN6_RC6p_THRESHOLD, 10);
I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */
 
-   if (i915_enable_rc6)
+   if (intel_enable_rc6(dev_priv-dev))
rc6_mask = GEN6_RC_CTL_RC6p_ENABLE |
GEN6_RC_CTL_RC6_ENABLE;
 
@@ -8372,7 +8392,7 @@ void ironlake_enable_rc6(struct drm_device *dev)
/* rc6 disabled by default due to repeated reports of hanging during
 * boot and resume.
 */
-   if (!i915_enable_rc6)
+   if (!intel_enable_rc6(dev))
return;
 
mutex_lock(dev-struct_mutex);
-- 
1.7.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Keith Packard]

Hey Dave:

Here's a pile of fixes to the intel driver. This pull includes the three
patches you already merged in, but it merges cleanly so I didn't rebase
around them.

The following changes since commit 37be944a0270402f9cda291a930b0286f6dc92f5:

  Merge branch 'drm-core-next' of git://people.freedesktop.org/~airlied/linux 
(2011-10-28 05:54:23 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~keithp/linux drm-intel-fixes

Adam Jackson (1):
  drm/i915: intel_choose_pipe_bpp_dither messages should be DRM_DEBUG_KMS

Ben Widawsky (1):
  drm/i915: forcewake warning fixes in debugfs

Dan Carpenter (1):
  drm/i915: fix if statement (bogus semi-colon)

Daniel Vetter (4):
  drm/i915: disable temporal dithering on the internal panel
  drm/i915: only match on PCI_BASE_CLASS_DISPLAY
  drm/i915: Ivybridge still has fences!
  drm/i915: add constants to size fence arrays and fields

Eric Anholt (3):
  drm/i915: Fix object refcount leak on mmappable size limit error path.
  drm/i915: Turn on a required 3D clock gating bit on Sandybridge.
  drm/i915: Turn on another required clock gating bit on gen6.

Jesse Barnes (1):
  drm/i915: enable cacheable objects on Ivybridge

Keith Packard (12):
  agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
  drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
  drm/i915: Module parameters using '-1' as default must be signed type
  drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control
  drm/i915: Remove link_status field from intel_dp structure
  drm/i915: Treat PCH eDP like DP in most places
  drm/i915: Let panel power sequencing hardware do its job
  drm/i915: Make DP prepare/commit consistent with DP dpms
  drm/i915: Try harder during dp pattern 1 link training
  drm/i915: Remove trailing white space
  drm/i915: Initiate DP link training only on the lanes we'll be using
  drm/i915: Use DPCD value for max DP lanes.

Rakib Mullick (1):
  drm, i915: Fix memory leak in i915_gem_busy_ioctl().

Takashi Iwai (1):
  drm/i915: Fix inconsistent backlight level during disabled

 drivers/char/agp/intel-gtt.c |7 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |   57 +-
 drivers/gpu/drm/i915/i915_drv.c  |6 +-
 drivers/gpu/drm/i915/i915_drv.h  |   19 +-
 drivers/gpu/drm/i915/i915_gem.c  |   14 +-
 drivers/gpu/drm/i915/i915_irq.c  |1 +
 drivers/gpu/drm/i915/i915_reg.h  |   21 ++-
 drivers/gpu/drm/i915/i915_suspend.c  |2 +
 drivers/gpu/drm/i915/intel_display.c |   33 ++-
 drivers/gpu/drm/i915/intel_dp.c  |  411 +++--
 drivers/gpu/drm/i915/intel_panel.c   |3 +-
 11 files changed, 359 insertions(+), 215 deletions(-)

-- 
keith.pack...@intel.com


pgp1HwuSQH30r.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] drm/i915: Hook up Ivybridge eDP

[Keith Packard]

On Thu, 17 Nov 2011 17:45:40 -0500, Adam Jackson  wrote:

> Your silicon people worry me.

In any case, the changes are mostly to move bits around so that there
are two bits for pipe select

> I don't even.  Unless you're looking at some other version of the DP
> spec than me, I was pretty sure those weren't legal voltage values.  And
> 3.5dB preemph on 1000mV gives you 1500mV at the peak, which is
> definitely outside the spec.

I'm just writing down what's in the spec. I don't use these values, just
the useful ones above.

You don't happen to have any hardware to test this with, do you?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH] drm/i915: Hook up Ivybridge eDP

[Keith Packard]

The Ivybridge eDP control register looks like a cross between a
Cougarpoint PCH DP control register and a Sandybridge eDP control
register.

Where things trivially match, share the code. Where there are any
tricky bits, just split things out into two obviously separate code paths.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_reg.h |   18 +
 drivers/gpu/drm/i915/intel_dp.c |  151 ++-
 2 files changed, 135 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b080cc8..43f27ad 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3447,6 +3447,24 @@
 #define  EDP_LINK_TRAIN_800_1200MV_0DB_SNB_B   (0x38<<22)
 #define  EDP_LINK_TRAIN_VOL_EMP_MASK_SNB   (0x3f<<22)

+/* IVB */
+#define EDP_LINK_TRAIN_400MV_0DB_IVB   (0x24 <<22)
+#define EDP_LINK_TRAIN_400MV_3_5DB_IVB (0x2a <<22)
+#define EDP_LINK_TRAIN_400MV_6DB_IVB   (0x2f <<22)
+#define EDP_LINK_TRAIN_600MV_0DB_IVB   (0x30 <<22)
+#define EDP_LINK_TRAIN_600MV_3_5DB_IVB (0x36 <<22)
+#define EDP_LINK_TRAIN_800MV_0DB_IVB   (0x38 <<22)
+#define EDP_LINK_TRAIN_800MV_3_5DB_IVB (0x33 <<22)
+
+/* legacy values */
+#define EDP_LINK_TRAIN_500MV_0DB_IVB   (0x00 <<22)
+#define EDP_LINK_TRAIN_1000MV_0DB_IVB  (0x20 <<22)
+#define EDP_LINK_TRAIN_500MV_3_5DB_IVB (0x02 <<22)
+#define EDP_LINK_TRAIN_1000MV_3_5DB_IVB(0x22 <<22)
+#define EDP_LINK_TRAIN_1000MV_6DB_IVB  (0x23 <<22)
+
+#define  EDP_LINK_TRAIN_VOL_EMP_MASK_IVB   (0x3f<<22)
+
 #define  FORCEWAKE 0xA18C
 #define  FORCEWAKE_ACK 0x130090

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ec28aeb..f63c6b2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -361,8 +361,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 * clock divider.
 */
if (is_cpu_edp(intel_dp)) {
-   if (IS_GEN6(dev))
-   aux_clock_divider = 200; /* SNB eDP input clock at 
400Mhz */
+   if (IS_GEN6(dev) || IS_GEN7(dev))
+   aux_clock_divider = 200; /* SNB & IVB eDP input clock 
at 400Mhz */
else
aux_clock_divider = 225; /* eDP input clock at 450Mhz */
} else if (HAS_PCH_SPLIT(dev))
@@ -816,10 +816,11 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
}

/*
-* There are three kinds of DP registers:
+* There are four kinds of DP registers:
 *
 *  IBX PCH
-*  CPU
+*  SNB CPU
+*  IVB CPU
 *  CPT PCH
 *
 * IBX PCH and CPU are the same for almost everything,
@@ -872,7 +873,26 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,

/* Split out the IBX/CPU vs CPT settings */

-   if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
+   if (is_cpu_edp(intel_dp) && IS_GEN7(dev)) {
+   if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
+   intel_dp->DP |= DP_SYNC_HS_HIGH;
+   if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
+   intel_dp->DP |= DP_SYNC_VS_HIGH;
+   intel_dp->DP |= DP_LINK_TRAIN_OFF_CPT;
+
+   if (intel_dp->link_configuration[1] & 
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+   intel_dp->DP |= DP_ENHANCED_FRAMING;
+
+   intel_dp->DP |= intel_crtc->pipe << 29;
+
+   /* don't miss out required setting for eDP */
+   intel_dp->DP |= DP_PLL_ENABLE;
+   if (adjusted_mode->clock < 20)
+   intel_dp->DP |= DP_PLL_FREQ_160MHZ;
+   else
+   intel_dp->DP |= DP_PLL_FREQ_270MHZ;
+   
+   } else if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
intel_dp->DP |= intel_dp->color_range;

if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
@@ -1374,34 +1394,60 @@ static char *link_train_names[] = {
  * These are source-specific values; current Intel hardware supports
  * a maximum voltage of 800mV and a maximum pre-emphasis of 6dB
  */
-#define I830_DP_VOLTAGE_MAXDP_TRAIN_VOLTAGE_SWING_800
-#define I830_DP_VOLTAGE_MAX_CPTDP_TRAIN_VOLTAGE_SWING_1200

 static uint8_t
-intel_dp_pre_emphasis_max(uint8_t voltage_swing)
+intel_dp_voltage_max(struct intel_dp *intel_dp)
 {
-   switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
-   case DP_TRAIN_VOLTAGE_SWING_400:
-   return DP_TRAIN_PRE_EMPHASIS_6;
-   case 

[PATCH] drm/i915: Hook up Ivybridge eDP

[Keith Packard]

The Ivybridge eDP control register looks like a cross between a
Cougarpoint PCH DP control register and a Sandybridge eDP control
register.

Where things trivially match, share the code. Where there are any
tricky bits, just split things out into two obviously separate code paths.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/i915_reg.h |   18 +
 drivers/gpu/drm/i915/intel_dp.c |  151 ++-
 2 files changed, 135 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b080cc8..43f27ad 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3447,6 +3447,24 @@
 #define  EDP_LINK_TRAIN_800_1200MV_0DB_SNB_B   (0x3822)
 #define  EDP_LINK_TRAIN_VOL_EMP_MASK_SNB   (0x3f22)
 
+/* IVB */
+#define EDP_LINK_TRAIN_400MV_0DB_IVB   (0x24 22)
+#define EDP_LINK_TRAIN_400MV_3_5DB_IVB (0x2a 22)
+#define EDP_LINK_TRAIN_400MV_6DB_IVB   (0x2f 22)
+#define EDP_LINK_TRAIN_600MV_0DB_IVB   (0x30 22)
+#define EDP_LINK_TRAIN_600MV_3_5DB_IVB (0x36 22)
+#define EDP_LINK_TRAIN_800MV_0DB_IVB   (0x38 22)
+#define EDP_LINK_TRAIN_800MV_3_5DB_IVB (0x33 22)
+
+/* legacy values */
+#define EDP_LINK_TRAIN_500MV_0DB_IVB   (0x00 22)
+#define EDP_LINK_TRAIN_1000MV_0DB_IVB  (0x20 22)
+#define EDP_LINK_TRAIN_500MV_3_5DB_IVB (0x02 22)
+#define EDP_LINK_TRAIN_1000MV_3_5DB_IVB(0x22 22)
+#define EDP_LINK_TRAIN_1000MV_6DB_IVB  (0x23 22)
+
+#define  EDP_LINK_TRAIN_VOL_EMP_MASK_IVB   (0x3f22)
+
 #define  FORCEWAKE 0xA18C
 #define  FORCEWAKE_ACK 0x130090
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ec28aeb..f63c6b2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -361,8 +361,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 * clock divider.
 */
if (is_cpu_edp(intel_dp)) {
-   if (IS_GEN6(dev))
-   aux_clock_divider = 200; /* SNB eDP input clock at 
400Mhz */
+   if (IS_GEN6(dev) || IS_GEN7(dev))
+   aux_clock_divider = 200; /* SNB  IVB eDP input clock 
at 400Mhz */
else
aux_clock_divider = 225; /* eDP input clock at 450Mhz */
} else if (HAS_PCH_SPLIT(dev))
@@ -816,10 +816,11 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
}
 
/*
-* There are three kinds of DP registers:
+* There are four kinds of DP registers:
 *
 *  IBX PCH
-*  CPU
+*  SNB CPU
+*  IVB CPU
 *  CPT PCH
 *
 * IBX PCH and CPU are the same for almost everything,
@@ -872,7 +873,26 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
 
/* Split out the IBX/CPU vs CPT settings */
 
-   if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
+   if (is_cpu_edp(intel_dp)  IS_GEN7(dev)) {
+   if (adjusted_mode-flags  DRM_MODE_FLAG_PHSYNC)
+   intel_dp-DP |= DP_SYNC_HS_HIGH;
+   if (adjusted_mode-flags  DRM_MODE_FLAG_PVSYNC)
+   intel_dp-DP |= DP_SYNC_VS_HIGH;
+   intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
+
+   if (intel_dp-link_configuration[1]  
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+   intel_dp-DP |= DP_ENHANCED_FRAMING;
+
+   intel_dp-DP |= intel_crtc-pipe  29;
+
+   /* don't miss out required setting for eDP */
+   intel_dp-DP |= DP_PLL_ENABLE;
+   if (adjusted_mode-clock  20)
+   intel_dp-DP |= DP_PLL_FREQ_160MHZ;
+   else
+   intel_dp-DP |= DP_PLL_FREQ_270MHZ;
+   
+   } else if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
intel_dp-DP |= intel_dp-color_range;
 
if (adjusted_mode-flags  DRM_MODE_FLAG_PHSYNC)
@@ -1374,34 +1394,60 @@ static char *link_train_names[] = {
  * These are source-specific values; current Intel hardware supports
  * a maximum voltage of 800mV and a maximum pre-emphasis of 6dB
  */
-#define I830_DP_VOLTAGE_MAXDP_TRAIN_VOLTAGE_SWING_800
-#define I830_DP_VOLTAGE_MAX_CPTDP_TRAIN_VOLTAGE_SWING_1200
 
 static uint8_t
-intel_dp_pre_emphasis_max(uint8_t voltage_swing)
+intel_dp_voltage_max(struct intel_dp *intel_dp)
 {
-   switch (voltage_swing  DP_TRAIN_VOLTAGE_SWING_MASK) {
-   case DP_TRAIN_VOLTAGE_SWING_400:
-   return DP_TRAIN_PRE_EMPHASIS_6;
-   case DP_TRAIN_VOLTAGE_SWING_600:
-   return DP_TRAIN_PRE_EMPHASIS_6;
-   case DP_TRAIN_VOLTAGE_SWING_800:
-   return DP_TRAIN_PRE_EMPHASIS_3_5;
-   case DP_TRAIN_VOLTAGE_SWING_1200

[Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

[Keith Packard]

On Thu, 3 Nov 2011 15:41:25 -0700, Jesse Barnes  
wrote:

> Except for VDD??  That does come on... and shouldn't be any different
> than a full power sequence as far as link training etc go...

Oh, that's a good point. Doing things in this order essentially forces
yet another full panel power sequence delay at this point. Hrm. I'll
have to test again when I get a chance, but perhaps we can turn the sink
DPMS on before we turn the panel power off.

> Oh missed the vdd on, which is in this path too...  So I'm still
> confused by the panel off, vdd on sequence, but at least they're
> consistent.

Right, I'll try doing the sink_dpms before turning the panel off; that
should work just fine, and should make the sequence a bit faster.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space

[Keith Packard]

On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes  
wrote:

> Reviewed-by: Jesse Barnes 

I've updated the pch-edp-fixes branch with your suggestions and attached
your R-b: to the reviewed patches.

That leaves only the panel power sequencing changes, which could
probably use more testing to make sure no existing systems stop
working. I've got an ILK eDP system here that I haven't tested yet, so I
can do that. I have tested SNB CPU eDP on the MacBook and CPT PCH eDP on
the other system.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

On Thu, 3 Nov 2011 13:03:29 -0700, Jesse Barnes  
wrote:

> Sneaky putting this bug fix into this patch. :)

Ickle already saw that, and I've split it out into a separate patch. I
don't think this is necessary, but it seems like a sensible change.

> Don't you love the training state machine?  I think this looks ok, and
> the DP compliance test should catch any grievous errors, so aside from
> the bug fix hunk which should be split out:
> 
> Reviewed-by: Jesse Barnes 

And that chunk has already been split out :-)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

[Keith Packard]

On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes  
wrote:

> A few comments on this one (also, is it strictly required to fix your
> bug)?

I think so; the panel definitely was not happy when I turned the link
off while the panel power was on. Having the mode setting and DPMS paths
doing things in different orders definitely doesn't seem reasonable
though. I nearly managed to share code between the two paths, but there
are subtle differences in requirements and so I didn't bother.

> Ok so you're making sure the panel has power to down the link, I think
> that's fine.

No, I'm turning the panel off *before* turning off the link.  The panel
goes nuts if you down the link before turning its power off; lots of
technicolor.

Downing the link doesn't require any communication with the panel, so
there's no issue with losing connectivity at this point:

ironlake_edp_backlight_off(intel_dp);
ironlake_edp_panel_off(intel_dp);   <= panel off

/* Wake up the sink first */
ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_link_down(intel_dp);   <= link down
ironlake_edp_panel_vdd_off(intel_dp, false);

> But here it looks like you're shutting it off, then downing the link?
> Should this be reordered?

Nope, it's in the same order:

ironlake_edp_backlight_off(intel_dp);
ironlake_edp_panel_off(intel_dp);   <= panel off

ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);   <= link down
ironlake_edp_panel_vdd_off(intel_dp, false);

The only difference in these two code paths is that dp_prepare turns the
sink to DPMS_ON, while dp_dpms turns the sink to DPMS_OFF.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

On Thu, 3 Nov 2011 12:57:08 -0700, Jesse Barnes  
wrote:

> Modulo what we already discussed on irc about the PP_READY bit, and the

Right, the PP_READY bit requires that everything needed for PCH eDP be
running, even when you're using a CPU connected eDP panel, and so it's
not actually useful.

> CodingStyle nitpicks (newlines before {?  come on, this isn't X :),

Ok, I can fix that at least, even if I think it's ugly in kernel style.

I'll clean up the style and attach your R-b.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

On Thu, 3 Nov 2011 12:57:08 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Modulo what we already discussed on irc about the PP_READY bit, and the

Right, the PP_READY bit requires that everything needed for PCH eDP be
running, even when you're using a CPU connected eDP panel, and so it's
not actually useful.

 CodingStyle nitpicks (newlines before {?  come on, this isn't X :),

Ok, I can fix that at least, even if I think it's ugly in kernel style.

I'll clean up the style and attach your R-b.

-- 
keith.pack...@intel.com


pgpKCm3er06T8.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

[Keith Packard]

On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 A few comments on this one (also, is it strictly required to fix your
 bug)?

I think so; the panel definitely was not happy when I turned the link
off while the panel power was on. Having the mode setting and DPMS paths
doing things in different orders definitely doesn't seem reasonable
though. I nearly managed to share code between the two paths, but there
are subtle differences in requirements and so I didn't bother.

 Ok so you're making sure the panel has power to down the link, I think
 that's fine.

No, I'm turning the panel off *before* turning off the link.  The panel
goes nuts if you down the link before turning its power off; lots of
technicolor.

Downing the link doesn't require any communication with the panel, so
there's no issue with losing connectivity at this point:

ironlake_edp_backlight_off(intel_dp);
ironlake_edp_panel_off(intel_dp);   = panel off

/* Wake up the sink first */
ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_link_down(intel_dp);   = link down
ironlake_edp_panel_vdd_off(intel_dp, false);

 But here it looks like you're shutting it off, then downing the link?
 Should this be reordered?

Nope, it's in the same order:

ironlake_edp_backlight_off(intel_dp);
ironlake_edp_panel_off(intel_dp);   = panel off

ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);   = link down
ironlake_edp_panel_vdd_off(intel_dp, false);

The only difference in these two code paths is that dp_prepare turns the
sink to DPMS_ON, while dp_dpms turns the sink to DPMS_OFF.

-- 
keith.pack...@intel.com


pgpIvVW5jiEXv.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

On Thu, 3 Nov 2011 13:03:29 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Sneaky putting this bug fix into this patch. :)

Ickle already saw that, and I've split it out into a separate patch. I
don't think this is necessary, but it seems like a sensible change.

 Don't you love the training state machine?  I think this looks ok, and
 the DP compliance test should catch any grievous errors, so aside from
 the bug fix hunk which should be split out:
 
 Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

And that chunk has already been split out :-)

-- 
keith.pack...@intel.com


pgpByHdFAP5A1.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space

[Keith Packard]

On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

Thanks for your careful patch review here.

-- 
keith.pack...@intel.com


pgpPNrs802K0I.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space

[Keith Packard]

On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

I've updated the pch-edp-fixes branch with your suggestions and attached
your R-b: to the reviewed patches.

That leaves only the panel power sequencing changes, which could
probably use more testing to make sure no existing systems stop
working. I've got an ILK eDP system here that I haven't tested yet, so I
can do that. I have tested SNB CPU eDP on the MacBook and CPT PCH eDP on
the other system.

-- 
keith.pack...@intel.com


pgpm3ot8yI5Vq.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

[Keith Packard]

On Thu, 3 Nov 2011 15:41:25 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Except for VDD??  That does come on... and shouldn't be any different
 than a full power sequence as far as link training etc go...

Oh, that's a good point. Doing things in this order essentially forces
yet another full panel power sequence delay at this point. Hrm. I'll
have to test again when I get a chance, but perhaps we can turn the sink
DPMS on before we turn the panel power off.

 Oh missed the vdd on, which is in this path too...  So I'm still
 confused by the panel off, vdd on sequence, but at least they're
 consistent.

Right, I'll try doing the sink_dpms before turning the panel off; that
should work just fine, and should make the sequence a bit faster.

-- 
keith.pack...@intel.com


pgprcA7sBUzUk.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson  wrote:

> It is?  The DP 1.1a text for lane count is "For Rev.1.1, only the 
> following three values are supported. All other values are reserved."

Yeah, if you look at the MAX_LINK_RATE field, we assume that it has a
useful value. I'll bet they were thinking of letting the spec support
things like alternate clock rates or 3 lanes or something, and the 1.1
version just tied things down to allow only sensible values there.

How about we just always use the DPCD value?

commit e0fafa5dee031ef6174eadb005a5f01d13da931d
Author: Keith Packard 
Date:   Wed Nov 2 13:03:47 2011 -0700

drm/i915: Use DPCD value for max DP lanes.

The BIOS VBT value for an eDP panel has been shown to be incorrect on
one machine, and we haven't found any machines where the DPCD value
was wrong, so we'll use the DPCD value everywhere.

    Signed-off-by: Keith Packard 

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b56ce..5056d29 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -154,16 +154,12 @@ intel_edp_link_config(struct intel_encoder *intel_encoder,
 static int
 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 {
-   int max_lane_count = 4;
-
-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
-   max_lane_count = intel_dp->dpcd[DP_MAX_LANE_COUNT] & 0x1f;
-   switch (max_lane_count) {
-   case 1: case 2: case 4:
-   break;
-   default:
-   max_lane_count = 4;
-   }
+   int max_lane_count = intel_dp->dpcd[DP_MAX_LANE_COUNT] & 0x1f;
+   switch (max_lane_count) {
+   case 1: case 2: case 4:
+   break;
+   default:
+   max_lane_count = 4;
}
return max_lane_count;
 }
@@ -765,12 +761,11 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
continue;

intel_dp = enc_to_intel_dp(encoder);
-   if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT || 
is_pch_edp(intel_dp)) {
+   if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_dp->base.type == INTEL_OUTPUT_EDP)
+   {
lane_count = intel_dp->lane_count;
break;
-   } else if (is_cpu_edp(intel_dp)) {
-   lane_count = dev_priv->edp.lanes;
-   break;
}
}

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/77a12b47/attachment.pgp>

[Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson  wrote:

> The VBT is going to be crap.

The only question then is what to do with hardware that doesn't have the
DPCD value -- that's "new" in revision 0x11, after all.

How about this:

commit 34ebe02cc78f20ae6b7865c5087c3b5ac7810185
Author: Keith Packard 
Date:   Wed Nov 2 13:03:47 2011 -0700

drm/i915: Use DPCD value for max DP lanes where possible

Fall back to the VBT value for eDP monitors only when DPCD is missing
the value.

Signed-off-by: Keith Packard 

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b56ce..93b082a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -154,6 +154,8 @@ intel_edp_link_config(struct intel_encoder *intel_encoder,
 static int
 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 {
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
int max_lane_count = 4;

if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
@@ -164,6 +166,8 @@ intel_dp_max_lane_count(struct intel_dp *intel_dp)
default:
max_lane_count = 4;
}
+   } else if (is_edp(intel_dp)) {
+   max_lane_count = dev_priv->edp.lanes;
}
return max_lane_count;
 }
@@ -765,12 +769,11 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
continue;

intel_dp = enc_to_intel_dp(encoder);
-   if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT || 
is_pch_edp(intel_dp)) {
+   if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_dp->base.type == INTEL_OUTPUT_EDP)
+   {
lane_count = intel_dp->lane_count;
break;
-   } else if (is_cpu_edp(intel_dp)) {
-   lane_count = dev_priv->edp.lanes;
-   break;
}
}



-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/cb2a29b6/attachment.pgp>

[PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Tue,  1 Nov 2011 23:20:26 -0700, Keith Packard  wrote:

>   intel_dp = enc_to_intel_dp(encoder);
> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
> + if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT || 
> is_pch_edp(intel_dp)) {
>   lane_count = intel_dp->lane_count;
>   break;
> - } else if (is_edp(intel_dp)) {
> + } else if (is_cpu_edp(intel_dp)) {
>   lane_count = dev_priv->edp.lanes;
>   break;

Thinking about this one more time -- if we ever want to use
dev_priv->edp.lanes, we should use it in
intel_dp_max_lane_count. intel_dp_set_m_n should use
intel_dp->lane_count unconditionally as that's the value we've used
everywhere else for mode setting.

Perhaps we should use it for monitors that don't include the
MAX_LANE_COUNT field in the dpcd? Perhaps we should use it on all eDP
monitors?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/a20227c9/attachment.pgp>

[PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson  
wrote:

> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.
> -Chris

Here's that patch separated out:

commit e7fecae483754ca9a42312be18f58ceb454702fe
Author: Keith Packard 
Date:   Wed Nov 2 10:17:59 2011 -0700

drm/i915: Initiate DP link training only on the lanes we'll be using

Limit the link training setting command to the lanes needed for the
current mode. It seems vaguely possible that a monitor will try to
train the other lanes and fail in some way, so this seems like the
safer plan.

Signed-off-by: Keith Packard 

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0a4fa64..02b56ce 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1567,8 +1567,9 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,

ret = intel_dp_aux_native_write(intel_dp,
DP_TRAINING_LANE0_SET,
-   intel_dp->train_set, 4);
-   if (ret != 4)
+   intel_dp->train_set,
+   intel_dp->lane_count);
+   if (ret != intel_dp->lane_count)
return false;

return true;


-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/97aa2748/attachment.pgp>

[Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes  
wrote:

> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...

Here's the new version of that chunk:

@@ -906,32 +905,56 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
}
 }

-static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+#define IDLE_ON_MASK   (PP_ON | 0| PP_SEQUENCE_MASK | 0
 | PP_SEQUENCE_STATE_MASK)
+#define IDLE_ON_VALUE  (PP_ON | 0| PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_ON_IDLE)
+
+#define IDLE_OFF_MASK  (PP_ON | 0| PP_SEQUENCE_MASK | 0
 | PP_SEQUENCE_STATE_MASK)
+#define IDLE_OFF_VALUE (0 | 0| PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_OFF_IDLE)
+
+#define IDLE_CYCLE_MASK(PP_ON | 0| PP_SEQUENCE_MASK | 
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK)
+#define IDLE_CYCLE_VALUE   (0 | 0| PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_OFF_IDLE)
+
+static void ironlake_wait_panel_status(struct intel_dp *intel_dp,
+  u32 mask,
+  u32 value)
 {


-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson  wrote:

> Redundant.  You've already done the link_configuration |= above in the 
> common code.  You can drop the second if chunk altogether.

Here's the new version of that chunk of patch:

@@ -850,32 +864,45 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
intel_write_eld(encoder, adjusted_mode);
}
-
memset(intel_dp->link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
intel_dp->link_configuration[0] = intel_dp->link_bw;
intel_dp->link_configuration[1] = intel_dp->lane_count;
intel_dp->link_configuration[8] = DP_SET_ANSI_8B10B;
-
/*
 * Check for DPCD version > 1.1 and enhanced framing support
 */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
(intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_ENHANCED_FRAME_CAP)) {
intel_dp->link_configuration[1] |= 
DP_LANE_COUNT_ENHANCED_FRAME_EN;
-   intel_dp->DP |= DP_ENHANCED_FRAMING;
}

-   /* CPT DP's pipe select is decided in TRANS_DP_CTL */
-   if (intel_crtc->pipe == 1 && !HAS_PCH_CPT(dev))
-   intel_dp->DP |= DP_PIPEB_SELECT;
+   /* Split out the IBX/CPU vs CPT settings */

-   if (is_cpu_edp(intel_dp)) {
-   /* don't miss out required setting for eDP */
-   intel_dp->DP |= DP_PLL_ENABLE;
-   if (adjusted_mode->clock < 20)
-   intel_dp->DP |= DP_PLL_FREQ_160MHZ;
-   else
-   intel_dp->DP |= DP_PLL_FREQ_270MHZ;
+   if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
+   intel_dp->DP |= intel_dp->color_range;
+
+   if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
+   intel_dp->DP |= DP_SYNC_HS_HIGH;
+   if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
+   intel_dp->DP |= DP_SYNC_VS_HIGH;
+   intel_dp->DP |= DP_LINK_TRAIN_OFF;
+
+   if (intel_dp->link_configuration[1] & 
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+   intel_dp->DP |= DP_ENHANCED_FRAMING;
+
+   if (intel_crtc->pipe == 1)
+   intel_dp->DP |= DP_PIPEB_SELECT;
+
+   if (is_cpu_edp(intel_dp)) {
+   /* don't miss out required setting for eDP */
+   intel_dp->DP |= DP_PLL_ENABLE;
+   if (adjusted_mode->clock < 20)
+   intel_dp->DP |= DP_PLL_FREQ_160MHZ;
+   else
+   intel_dp->DP |= DP_PLL_FREQ_270MHZ;
+   }
+   } else {
+   intel_dp->DP |= DP_LINK_TRAIN_OFF_CPT;
}
 }

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson  wrote:

> Given the choice of trusting DPCD or the VBT, I'd definitely prefer
> DPCD.

Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may neglect to connect some
of the wires. In any case, if we want to look at these values, we should
be doing it before computing the M/N ratio so that we actually set the
hardware up correctly.

Any bets on how long until we find a machine that has right value in the
VBT and the wrong one in DPCD? Or a machine with wrong values in both places?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson  
wrote:

> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.

Yeah, this got left in during some debugging; it might be a good thing
to do, but it's completely separate. I've pulled it out into a separate
patch.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes  
wrote:

> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...

Yeah, I'd like to understand why PP_READY isn't getting set; we should
have all of the other pieces ready before we turn on the panel. But,
given that it's really just a sanity check, it probably doesn't make
sense to spin for 5 seconds waiting for a bit to turn on that won't.

I've just removed that bit from the IDLE_ON_MASK and IDLE_ON_VALUE.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 2 Nov 2011 09:20:19 -0700, Jesse Barnes  
wrote:

> But I was curious about this hunk:
> 
> @@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
> drm_display_mode *mode,
>   continue;
>  
>   intel_dp = enc_to_intel_dp(encoder);
> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
> + if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT || 
> is_pch_edp(intel_dp)) {
>   lane_count = intel_dp->lane_count;
>   break;
> - } else if (is_edp(intel_dp)) {
> + } else if (is_cpu_edp(intel_dp)) {
>   lane_count = dev_priv->edp.lanes;
>   break;
>   }
> 
> I guess this means we can't trust the BIOS settings for PCH eDP?

I'm pretty sure this isn't the right place to look at this value in any
case; we're setting the m/n ratios after already deciding how many lanes
to use. Getting this wrong means sending the wrong timing to the
monitor, not setting a different mode.

In any case, my AIO box sets the BIOS value to 1, when it needs 2 lanes
for the mode it uses.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson  wrote:

> Redundant.  You've already done the link_configuration |= above in the 
> common code.  You can drop the second if chunk altogether.

Thanks for catching this mistake; cut programming without the cut part...

> In related news, the corresponding section for this in TRANS_DP_CTL 
> setup appears to turn on enhanced framing unconditionally.  This is 
> probably not a big deal, I don't think I've ever seen a display not 
> support it, but.

Yeah, it's actually a huge pain because TRANS_DP_CTL is set up in
ironlake_pch_enable, which is part of the crtc enable path not the
encoder mode set path, and getting to the appropriate intel_dp structure
takes a walk through all of the encoders to find the matching one.

I think we could move the TRANS_DP_CTL code into intel_dp.c where it
belongs; this chunk was stuck inside ironlake_crtc_dpms by Zhenyu last
year when DP/eDP support for Sandybridge and Cougarpoint was added in
commit e3421a189447c0b8cd0aff5c299f53b5ab7c38f6.

Most of the TRANS_DP_CTL chunk inside ironlake_pch_enable should just
get moved to intel_dp_mode_set, but I don't know if the
TRANS_DP_OUTPUT_ENABLE bit needs to be set before
intel_enable_transcoder is called; if it does, then we'd need to
preserve that piece inside ironlake_pch_enable, otherwise that bit would
move to intel_dp_commit.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[Intel-gfx] [PATCH 1/7] drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control

[Keith Packard]

On Wed, 2 Nov 2011 09:02:55 -0700, Jesse Barnes  
wrote:

> Can't we just set UNLOCK_REGS at load time and have asserts sprinkled
> here and there?

I think we'd need it at resume time as well; it seemed easier to just
set it every time we touch the register.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

On Tue,  1 Nov 2011 23:20:27 -0700, Keith Packard  wrote:

> -static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
> +#define IDLE_ON_MASK (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
>  | PP_SEQUENCE_STATE_MASK)
> +#define IDLE_ON_VALUE(PP_ON | PP_READY | PP_SEQUENCE_NONE | 0
>  | PP_SEQUENCE_STATE_ON_IDLE)

A bit more testing -- looks like the MacBook Air doesn't mange to get
PP_READY set when it's time to turn the panel on. I should look at this
a bit more closely; there's no reason it shouldn't be set. But, nothing
bad seems to happen if we simply ignore the PP_READY bit

+#define IDLE_ON_MASK   (PP_ON | 0  | PP_SEQUENCE_MASK | 0  
   | PP_SEQUENCE_STATE_MASK)
+#define IDLE_ON_VALUE  (PP_ON | 0  | PP_SEQUENCE_NONE | 0  
   | PP_SEQUENCE_STATE_ON_IDLE)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/5aa8566a/attachment.pgp>

[PATCH 7/7] drm/i915: Remove trailing white space

[Keith Packard]

Found a couple of bare tabs in intel_dp.c

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_dp.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf20a35..7ebeb01 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1054,7 +1054,7 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp 
*intel_dp, bool sync)

DRM_DEBUG_KMS("Turn eDP VDD off %d\n", intel_dp->want_panel_vdd);
WARN(!intel_dp->want_panel_vdd, "eDP VDD not forced on");
-   
+
intel_dp->want_panel_vdd = false;

if (sync) {
@@ -2402,7 +2402,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)

cur.t8 = (pp_on & PANEL_LIGHT_ON_DELAY_MASK) >>
PANEL_LIGHT_ON_DELAY_SHIFT;
-   
+
cur.t9 = (pp_off & PANEL_LIGHT_OFF_DELAY_MASK) >>
PANEL_LIGHT_OFF_DELAY_SHIFT;

-- 
1.7.7

[PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

Instead of going through the sequence just once, run through the whole
set up to 5 times to see if something can work. This isn't part of the
DP spec, but the BIOS seems to do it, and given that link training
failure is so bad, it seems reasonable to follow suit.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_dp.c |   41 +-
 1 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6be6a04..bf20a35 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1576,8 +1576,9 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,

ret = intel_dp_aux_native_write(intel_dp,
DP_TRAINING_LANE0_SET,
-   intel_dp->train_set, 4);
-   if (ret != 4)
+   intel_dp->train_set,
+   intel_dp->lane_count);
+   if (ret != intel_dp->lane_count)
return false;

return true;
@@ -1593,7 +1594,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
int i;
uint8_t voltage;
bool clock_recovery = false;
-   int tries;
+   int voltage_tries, loop_tries;
u32 reg;
uint32_t DP = intel_dp->DP;

@@ -1620,7 +1621,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP &= ~DP_LINK_TRAIN_MASK;
memset(intel_dp->train_set, 0, 4);
voltage = 0xff;
-   tries = 0;
+   voltage_tries = 0;
+   loop_tries = 0;
clock_recovery = false;
for (;;) {
/* Use intel_dp->train_set[0] to set the voltage and pre 
emphasis values */
@@ -1663,17 +1665,28 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
for (i = 0; i < intel_dp->lane_count; i++)
if ((intel_dp->train_set[i] & 
DP_TRAIN_MAX_SWING_REACHED) == 0)
break;
-   if (i == intel_dp->lane_count)
-   break;
-
-   /* Check to see if we've tried the same voltage 5 times */
-   if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) == 
voltage) {
-   ++tries;
-   if (tries == 5)
+   if (i == intel_dp->lane_count) {
+   ++loop_tries;
+   if (loop_tries == 5) {
+   DRM_DEBUG_KMS("too many full retries, give 
up\n");
break;
-   } else
-   tries = 0;
-   voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
+   }
+   memset(intel_dp->train_set, 0, 4);
+   voltage_tries = 0;
+   continue;
+   } else {
+
+   /* Check to see if we've tried the same voltage 5 times 
*/
+   if ((intel_dp->train_set[0] & 
DP_TRAIN_VOLTAGE_SWING_MASK) == voltage) {
+   ++voltage_tries;
+   if (voltage_tries == 5) {
+   DRM_DEBUG_KMS("too many voltage 
retries, give up\n");
+   break;
+   }
+   } else
+   voltage_tries = 0;
+   voltage = intel_dp->train_set[0] & 
DP_TRAIN_VOLTAGE_SWING_MASK;
+   }

/* Compute new intel_dp->train_set as requested by target */
intel_get_adjust_train(intel_dp, link_status);
-- 
1.7.7

[PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

[Keith Packard]

Make sure the sequence of operations in all three functions makes
sense:

 1) The backlight must be off unless the screen is running
 2) The link must be running to turn the eDP panel on/off
 3) The CPU eDP PLL must be running until everything is off

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_dp.c |   22 +-
 1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d6c6608..6be6a04 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1234,17 +1234,18 @@ static void intel_dp_prepare(struct drm_encoder 
*encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);

+   ironlake_edp_backlight_off(intel_dp);
+   ironlake_edp_panel_off(intel_dp);
+
/* Wake up the sink first */
ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   intel_dp_link_down(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, false);

/* Make sure the panel is off before trying to
 * change the mode
 */
-   ironlake_edp_backlight_off(intel_dp);
-   intel_dp_link_down(intel_dp);
-   ironlake_edp_panel_off(intel_dp);
 }

 static void intel_dp_commit(struct drm_encoder *encoder)
@@ -1276,16 +1277,20 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
uint32_t dp_reg = I915_READ(intel_dp->output_reg);

if (mode != DRM_MODE_DPMS_ON) {
+   ironlake_edp_backlight_off(intel_dp);
+   ironlake_edp_panel_off(intel_dp);
+
ironlake_edp_panel_vdd_on(intel_dp);
-   if (is_edp(intel_dp))
-   ironlake_edp_backlight_off(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);
-   ironlake_edp_panel_off(intel_dp);
-   if (is_edp(intel_dp) && !is_pch_edp(intel_dp))
-   ironlake_edp_pll_off(encoder);
ironlake_edp_panel_vdd_off(intel_dp, false);
+
+   if (is_cpu_edp(intel_dp))
+   ironlake_edp_pll_off(encoder);
} else {
+   if (is_cpu_edp(intel_dp))
+   ironlake_edp_pll_on(encoder);
+
ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
if (!(dp_reg & DP_PORT_EN)) {
@@ -1293,7 +1298,6 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
ironlake_edp_panel_on(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, true);
intel_dp_complete_link_train(intel_dp);
-   ironlake_edp_backlight_on(intel_dp);
} else
ironlake_edp_panel_vdd_off(intel_dp, false);
ironlake_edp_backlight_on(intel_dp);
-- 
1.7.7

[PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_reg.h |   17 -
 drivers/gpu/drm/i915/intel_dp.c |  138 +--
 2 files changed, 87 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5a09416..275d149 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1553,12 +1553,21 @@
  */
 #define   PP_READY (1 << 30)
 #define   PP_SEQUENCE_NONE (0 << 28)
-#define   PP_SEQUENCE_ON   (1 << 28)
-#define   PP_SEQUENCE_OFF  (2 << 28)
-#define   PP_SEQUENCE_MASK 0x3000
+#define   PP_SEQUENCE_POWER_UP (1 << 28)
+#define   PP_SEQUENCE_POWER_DOWN (2 << 28)
+#define   PP_SEQUENCE_MASK (3 << 28)
+#define   PP_SEQUENCE_SHIFT28
 #define   PP_CYCLE_DELAY_ACTIVE(1 << 27)
-#define   PP_SEQUENCE_STATE_ON_IDLE (1 << 3)
 #define   PP_SEQUENCE_STATE_MASK 0x000f
+#define   PP_SEQUENCE_STATE_OFF_IDLE   (0x0 << 0)
+#define   PP_SEQUENCE_STATE_OFF_S0_1   (0x1 << 0)
+#define   PP_SEQUENCE_STATE_OFF_S0_2   (0x2 << 0)
+#define   PP_SEQUENCE_STATE_OFF_S0_3   (0x3 << 0)
+#define   PP_SEQUENCE_STATE_ON_IDLE(0x8 << 0)
+#define   PP_SEQUENCE_STATE_ON_S1_0(0x9 << 0)
+#define   PP_SEQUENCE_STATE_ON_S1_2(0xa << 0)
+#define   PP_SEQUENCE_STATE_ON_S1_3(0xb << 0)
+#define   PP_SEQUENCE_STATE_RESET  (0xf << 0)
 #define PP_CONTROL 0x61204
 #define   POWER_TARGET_ON  (1 << 0)
 #define PP_ON_DELAYS   0x61208
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 185fae6..d6c6608 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -66,7 +66,6 @@ struct intel_dp {
struct drm_display_mode *panel_fixed_mode;  /* for eDP */
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
-   unsigned long panel_off_jiffies;
 };

 /**
@@ -915,32 +914,56 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
}
 }

-static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+#define IDLE_ON_MASK   (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
 | PP_SEQUENCE_STATE_MASK)
+#define IDLE_ON_VALUE  (PP_ON | PP_READY | PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_ON_IDLE)
+
+#define IDLE_OFF_MASK  (PP_ON | 0| PP_SEQUENCE_MASK | 0
 | PP_SEQUENCE_STATE_MASK)
+#define IDLE_OFF_VALUE (0 | 0| PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_OFF_IDLE)
+
+#define IDLE_CYCLE_MASK(PP_ON | 0| PP_SEQUENCE_MASK | 
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK)
+#define IDLE_CYCLE_VALUE   (0 | 0| PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_OFF_IDLE)
+
+static void ironlake_wait_panel_status(struct intel_dp *intel_dp,
+  u32 mask,
+  u32 value)
 {
-   unsigned long   off_time;
-   unsigned long   delay;
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;

-   DRM_DEBUG_KMS("Wait for panel power off time\n");
+   DRM_DEBUG_KMS("mask %08x value %08x status %08x control %08x\n",
+ mask, value,
+ I915_READ(PCH_PP_STATUS),
+ I915_READ(PCH_PP_CONTROL));

-   if (ironlake_edp_have_panel_power(intel_dp) ||
-   ironlake_edp_have_panel_vdd(intel_dp))
+   if (_wait_for((I915_READ(PCH_PP_STATUS) & mask) == value,
+ 5000,
+ 10))
{
-   DRM_DEBUG_KMS("Panel still on, no delay needed\n");
-   return;
+   DRM_ERROR("Panel status timeout: status %08x control %08x\n",
+ I915_READ(PCH_PP_STATUS),
+ I915_READ(PCH_PP_CONTROL));
}
+}

-   off_time = intel_dp->panel_off_jiffies + 
msecs_to_jiffies(intel_dp->panel_power_down_delay);
-   if (time_after(jiffies, off_time)) {
-   DRM_DEBUG_KMS("Time already passed");
-   return;
-   }
-   delay = jiffies_to_msecs(off_time - jiffies);
-   if (delay > intel_dp->panel_power_down_delay)
-   delay = intel_dp->panel_power_down_delay;
-   DRM_DEBUG_KMS("Waiting an additional %ld ms\n", delay);
-   msleep(delay);
+static void ironlake_wait_panel_on(struct intel_dp *intel_d

[PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_display.c |3 +-
 drivers/gpu/drm/i915/intel_dp.c  |  112 --
 2 files changed, 81 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9fa342e..53eb29e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2933,7 +2933,8 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)

/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev) &&
-   intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+   (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPE_BPC_MASK) >> 5;
reg = TRANS_DP_CTL(pipe);
temp = I915_READ(reg);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c0c482..185fae6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
continue;

intel_dp = enc_to_intel_dp(encoder);
-   if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
+   if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT || 
is_pch_edp(intel_dp)) {
lane_count = intel_dp->lane_count;
break;
-   } else if (is_edp(intel_dp)) {
+   } else if (is_cpu_edp(intel_dp)) {
lane_count = dev_priv->edp.lanes;
break;
}
@@ -808,6 +808,7 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
  struct drm_display_mode *adjusted_mode)
 {
struct drm_device *dev = encoder->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct drm_crtc *crtc = intel_dp->base.base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -820,18 +821,31 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
ironlake_edp_pll_off(encoder);
}

-   intel_dp->DP = DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
-   intel_dp->DP |= intel_dp->color_range;
+   /*
+* There are three kinds of DP registers:
+*
+*  IBX PCH
+*  CPU
+*  CPT PCH
+*
+* IBX PCH and CPU are the same for almost everything,
+* except that the CPU DP PLL is configured in this
+* register
+*
+* CPT PCH is quite different, having many bits moved
+* to the TRANS_DP_CTL register instead. That
+* configuration happens (oddly) in ironlake_pch_enable
+*/

-   if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
-   intel_dp->DP |= DP_SYNC_HS_HIGH;
-   if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
-   intel_dp->DP |= DP_SYNC_VS_HIGH;
+   /* Preserve the BIOS-computed detected bit. This is
+* supposed to be read-only.
+*/
+   intel_dp->DP = I915_READ(intel_dp->output_reg) & DP_DETECTED;
+   intel_dp->DP |=  DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;

-   if (HAS_PCH_CPT(dev) && !is_cpu_edp(intel_dp))
-   intel_dp->DP |= DP_LINK_TRAIN_OFF_CPT;
-   else
-   intel_dp->DP |= DP_LINK_TRAIN_OFF;
+   /* Handle DP bits in common between all three register formats */
+
+   intel_dp->DP |= DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;

switch (intel_dp->lane_count) {
case 1:
@@ -850,32 +864,54 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
intel_write_eld(encoder, adjusted_mode);
}
-
memset(intel_dp->link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
intel_dp->link_configuration[0] = intel_dp->link_bw;
intel_dp->link_configuration[1] = intel_dp->lane_count;
intel_dp->link_configuration[8] = DP_SET_ANSI_8B10B;
-
/*
 * Check for DPCD version > 1.1 and enhanced framing support
 */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
(intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_ENHANCED_FRAME_CAP)) {
intel_dp->link_configuration[1] |= 
DP_LANE_COUNT_ENHANCED_FRAME_EN;
-   intel_dp->DP |= DP_ENHANCED_FRAMING;
}

-   /* CPT DP's pipe select is decided in TRANS_DP

[PATCH 2/7] drm/i915: Remove link_status field from intel_dp structure

[Keith Packard]

No persistent data was ever stored here, so link_status is instead
allocated on the stack as needed.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_dp.c |   65 +-
 1 files changed, 36 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index efe5f9e..2c0c482 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -58,7 +58,6 @@ struct intel_dp {
struct i2c_algo_dp_aux_data algo;
bool is_pch_edp;
uint8_t train_set[4];
-   uint8_t link_status[DP_LINK_STATUS_SIZE];
int panel_power_up_delay;
int panel_power_down_delay;
int panel_power_cycle_delay;
@@ -1285,11 +1284,11 @@ intel_dp_aux_native_read_retry(struct intel_dp 
*intel_dp, uint16_t address,
  * link status information
  */
 static bool
-intel_dp_get_link_status(struct intel_dp *intel_dp)
+intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
 {
return intel_dp_aux_native_read_retry(intel_dp,
  DP_LANE0_1_STATUS,
- intel_dp->link_status,
+ link_status,
  DP_LINK_STATUS_SIZE);
 }

@@ -1301,27 +1300,25 @@ intel_dp_link_status(uint8_t 
link_status[DP_LINK_STATUS_SIZE],
 }

 static uint8_t
-intel_get_adjust_request_voltage(uint8_t link_status[DP_LINK_STATUS_SIZE],
+intel_get_adjust_request_voltage(uint8_t adjust_request[2],
 int lane)
 {
-   int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
int s = ((lane & 1) ?
 DP_ADJUST_VOLTAGE_SWING_LANE1_SHIFT :
 DP_ADJUST_VOLTAGE_SWING_LANE0_SHIFT);
-   uint8_t l = intel_dp_link_status(link_status, i);
+   uint8_t l = adjust_request[lane>>1];

return ((l >> s) & 3) << DP_TRAIN_VOLTAGE_SWING_SHIFT;
 }

 static uint8_t
-intel_get_adjust_request_pre_emphasis(uint8_t link_status[DP_LINK_STATUS_SIZE],
+intel_get_adjust_request_pre_emphasis(uint8_t adjust_request[2],
  int lane)
 {
-   int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
int s = ((lane & 1) ?
 DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT :
 DP_ADJUST_PRE_EMPHASIS_LANE0_SHIFT);
-   uint8_t l = intel_dp_link_status(link_status, i);
+   uint8_t l = adjust_request[lane>>1];

return ((l >> s) & 3) << DP_TRAIN_PRE_EMPHASIS_SHIFT;
 }
@@ -1362,15 +1359,18 @@ intel_dp_pre_emphasis_max(uint8_t voltage_swing)
 }

 static void
-intel_get_adjust_train(struct intel_dp *intel_dp)
+intel_get_adjust_train(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
 {
+   struct drm_device *dev = intel_dp->base.base.dev;
uint8_t v = 0;
uint8_t p = 0;
int lane;
+   uint8_t *adjust_request = link_status + (DP_ADJUST_REQUEST_LANE0_1 - 
DP_LANE0_1_STATUS);
+   int voltage_max;

for (lane = 0; lane < intel_dp->lane_count; lane++) {
-   uint8_t this_v = 
intel_get_adjust_request_voltage(intel_dp->link_status, lane);
-   uint8_t this_p = 
intel_get_adjust_request_pre_emphasis(intel_dp->link_status, lane);
+   uint8_t this_v = 
intel_get_adjust_request_voltage(adjust_request, lane);
+   uint8_t this_p = 
intel_get_adjust_request_pre_emphasis(adjust_request, lane);

if (this_v > v)
v = this_v;
@@ -1389,7 +1389,7 @@ intel_get_adjust_train(struct intel_dp *intel_dp)
 }

 static uint32_t
-intel_dp_signal_levels(uint8_t train_set, int lane_count)
+intel_dp_signal_levels(uint8_t train_set)
 {
uint32_tsignal_levels = 0;

@@ -1458,9 +1458,8 @@ static uint8_t
 intel_get_lane_status(uint8_t link_status[DP_LINK_STATUS_SIZE],
  int lane)
 {
-   int i = DP_LANE0_1_STATUS + (lane >> 1);
int s = (lane & 1) * 4;
-   uint8_t l = intel_dp_link_status(link_status, i);
+   uint8_t l = link_status[lane>>1];

return (l >> s) & 0xf;
 }
@@ -1485,18 +1484,18 @@ intel_clock_recovery_ok(uint8_t 
link_status[DP_LINK_STATUS_SIZE], int lane_count
 DP_LANE_CHANNEL_EQ_DONE|\
 DP_LANE_SYMBOL_LOCKED)
 static bool
-intel_channel_eq_ok(struct intel_dp *intel_dp)
+intel_channel_eq_ok(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
 {
uint8_t lane_align;
uint8_t lane_status;
int lane;

-   lane_align = intel_dp_link_status(intel_dp->link_status,
+   lane_align = intel_dp_link_status(link_status,
  DP_LANE_ALIGN_STATUS_UPDA

[PATCH 1/7] drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control

[Keith Packard]

Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
ensure that writes will be respected, move this to a common function
to make the driver cleaner.

No functional changes.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_dp.c |   37 +++--
 1 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7259034..efe5f9e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -906,6 +906,19 @@ static void ironlake_wait_panel_off(struct intel_dp 
*intel_dp)
msleep(delay);
 }

+/* Read the current pp_control value, unlocking the register if it
+ * is locked
+ */
+
+static  u32 ironlake_get_pp_control(struct drm_i915_private *dev_priv)
+{
+   u32 control = I915_READ(PCH_PP_CONTROL);
+
+   control &= ~PANEL_UNLOCK_MASK;
+   control |= PANEL_UNLOCK_REGS;
+   return control;
+}
+
 static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp->base.base.dev;
@@ -926,9 +939,7 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
}

ironlake_wait_panel_off(intel_dp);
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp &= ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -951,9 +962,7 @@ static void ironlake_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
u32 pp;

if (!intel_dp->want_panel_vdd && ironlake_edp_have_panel_vdd(intel_dp)) 
{
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp &= ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp &= ~EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -1012,9 +1021,7 @@ static void ironlake_edp_panel_on(struct intel_dp 
*intel_dp)
return;

ironlake_wait_panel_off(intel_dp);
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp &= ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);

if (IS_GEN5(dev)) {
/* ILK workaround: disable reset around power sequence */
@@ -1049,9 +1056,7 @@ static void ironlake_edp_panel_off(struct drm_encoder 
*encoder)

if (!is_edp(intel_dp))
return;
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp &= ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);

if (IS_GEN5(dev)) {
/* ILK workaround: disable reset around power sequence */
@@ -1098,9 +1103,7 @@ static void ironlake_edp_backlight_on(struct intel_dp 
*intel_dp)
 * allowing it to appear.
 */
msleep(intel_dp->backlight_on_delay);
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp &= ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -1116,9 +1119,7 @@ static void ironlake_edp_backlight_off(struct intel_dp 
*intel_dp)
return;

DRM_DEBUG_KMS("\n");
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp &= ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp &= ~EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
-- 
1.7.7

[PATCH 0/7] drm/i915: Fix PCH eDP support for SNB

[Keith Packard]

Here's a patch sequence which makes my PCH-connected eDP panel
work. The main bug was a pile of places where the driver was
incorrectly treating a PCH connected eDP panel like a CPU connected
eDP panel, setting incorrect bits in the DP_CTL register and failing
to configure the TRANS_DP_CTL register entirely.

Beyond that, this eDP panel appears very sensitive to panel power
sequencing, and I found a bunch of minor errors there. I switched from
using blind timings to polling the panel power sequencing status
register to make sure we waited until that thought things were done,
and so that any panel power sequencing errors would show up in the
kernel log.

Finally, I noticed that the BIOS tried harder to get the link trained,
by simply starting over when it failed and trying the whole sequence
up to 5 times. This is not part of the DP spec, but given how bad
failing to train a panel is, it seems like it might be a good idea.

The three most interesting patches are the one which handles PCH eDP
more like PCH DP, the one which switches to using the panel power
sequencing hardware for all delays and finally the patch which tries
to do the panel power-up/down in the same order for both
dp_prepare/commit and dp_dpms.

All of these patches are on my pch-edp-fixes branch at

git://people.freedesktop.org/~keithp/linux

If you've got a PCH connected eDP display, I'd love to know if this
makes it work. If you've got a CPU connected eDP display or PCH
connected DP, please see if this causes any problems.

(I've got several machines failing to resume with this patch, but I've
checked and it's not the fault of anything in the i915 directory;
applying this sequence to v3.1 makes suspend/resume work fine).

[PATCH 0/7] drm/i915: Fix PCH eDP support for SNB

[Keith Packard]

Here's a patch sequence which makes my PCH-connected eDP panel
work. The main bug was a pile of places where the driver was
incorrectly treating a PCH connected eDP panel like a CPU connected
eDP panel, setting incorrect bits in the DP_CTL register and failing
to configure the TRANS_DP_CTL register entirely.

Beyond that, this eDP panel appears very sensitive to panel power
sequencing, and I found a bunch of minor errors there. I switched from
using blind timings to polling the panel power sequencing status
register to make sure we waited until that thought things were done,
and so that any panel power sequencing errors would show up in the
kernel log.

Finally, I noticed that the BIOS tried harder to get the link trained,
by simply starting over when it failed and trying the whole sequence
up to 5 times. This is not part of the DP spec, but given how bad
failing to train a panel is, it seems like it might be a good idea.

The three most interesting patches are the one which handles PCH eDP
more like PCH DP, the one which switches to using the panel power
sequencing hardware for all delays and finally the patch which tries
to do the panel power-up/down in the same order for both
dp_prepare/commit and dp_dpms.

All of these patches are on my pch-edp-fixes branch at

git://people.freedesktop.org/~keithp/linux

If you've got a PCH connected eDP display, I'd love to know if this
makes it work. If you've got a CPU connected eDP display or PCH
connected DP, please see if this causes any problems.

(I've got several machines failing to resume with this patch, but I've
checked and it's not the fault of anything in the i915 directory;
applying this sequence to v3.1 makes suspend/resume work fine).

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control

[Keith Packard]

Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
ensure that writes will be respected, move this to a common function
to make the driver cleaner.

No functional changes.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_dp.c |   37 +++--
 1 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7259034..efe5f9e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -906,6 +906,19 @@ static void ironlake_wait_panel_off(struct intel_dp 
*intel_dp)
msleep(delay);
 }
 
+/* Read the current pp_control value, unlocking the register if it
+ * is locked
+ */
+
+static  u32 ironlake_get_pp_control(struct drm_i915_private *dev_priv)
+{
+   u32 control = I915_READ(PCH_PP_CONTROL);
+
+   control = ~PANEL_UNLOCK_MASK;
+   control |= PANEL_UNLOCK_REGS;
+   return control;
+}
+
 static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp-base.base.dev;
@@ -926,9 +939,7 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
}
 
ironlake_wait_panel_off(intel_dp);
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp = ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -951,9 +962,7 @@ static void ironlake_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
u32 pp;
 
if (!intel_dp-want_panel_vdd  ironlake_edp_have_panel_vdd(intel_dp)) 
{
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp = ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp = ~EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -1012,9 +1021,7 @@ static void ironlake_edp_panel_on(struct intel_dp 
*intel_dp)
return;
 
ironlake_wait_panel_off(intel_dp);
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp = ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
 
if (IS_GEN5(dev)) {
/* ILK workaround: disable reset around power sequence */
@@ -1049,9 +1056,7 @@ static void ironlake_edp_panel_off(struct drm_encoder 
*encoder)
 
if (!is_edp(intel_dp))
return;
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp = ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
 
if (IS_GEN5(dev)) {
/* ILK workaround: disable reset around power sequence */
@@ -1098,9 +1103,7 @@ static void ironlake_edp_backlight_on(struct intel_dp 
*intel_dp)
 * allowing it to appear.
 */
msleep(intel_dp-backlight_on_delay);
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp = ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -1116,9 +1119,7 @@ static void ironlake_edp_backlight_off(struct intel_dp 
*intel_dp)
return;
 
DRM_DEBUG_KMS(\n);
-   pp = I915_READ(PCH_PP_CONTROL);
-   pp = ~PANEL_UNLOCK_MASK;
-   pp |= PANEL_UNLOCK_REGS;
+   pp = ironlake_get_pp_control(dev_priv);
pp = ~EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

[Keith Packard]

Make sure the sequence of operations in all three functions makes
sense:

 1) The backlight must be off unless the screen is running
 2) The link must be running to turn the eDP panel on/off
 3) The CPU eDP PLL must be running until everything is off

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_dp.c |   22 +-
 1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d6c6608..6be6a04 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1234,17 +1234,18 @@ static void intel_dp_prepare(struct drm_encoder 
*encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
+   ironlake_edp_backlight_off(intel_dp);
+   ironlake_edp_panel_off(intel_dp);
+
/* Wake up the sink first */
ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   intel_dp_link_down(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, false);
 
/* Make sure the panel is off before trying to
 * change the mode
 */
-   ironlake_edp_backlight_off(intel_dp);
-   intel_dp_link_down(intel_dp);
-   ironlake_edp_panel_off(intel_dp);
 }
 
 static void intel_dp_commit(struct drm_encoder *encoder)
@@ -1276,16 +1277,20 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
uint32_t dp_reg = I915_READ(intel_dp-output_reg);
 
if (mode != DRM_MODE_DPMS_ON) {
+   ironlake_edp_backlight_off(intel_dp);
+   ironlake_edp_panel_off(intel_dp);
+
ironlake_edp_panel_vdd_on(intel_dp);
-   if (is_edp(intel_dp))
-   ironlake_edp_backlight_off(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);
-   ironlake_edp_panel_off(intel_dp);
-   if (is_edp(intel_dp)  !is_pch_edp(intel_dp))
-   ironlake_edp_pll_off(encoder);
ironlake_edp_panel_vdd_off(intel_dp, false);
+
+   if (is_cpu_edp(intel_dp))
+   ironlake_edp_pll_off(encoder);
} else {
+   if (is_cpu_edp(intel_dp))
+   ironlake_edp_pll_on(encoder);
+
ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
if (!(dp_reg  DP_PORT_EN)) {
@@ -1293,7 +1298,6 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
ironlake_edp_panel_on(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, true);
intel_dp_complete_link_train(intel_dp);
-   ironlake_edp_backlight_on(intel_dp);
} else
ironlake_edp_panel_vdd_off(intel_dp, false);
ironlake_edp_backlight_on(intel_dp);
-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/i915_reg.h |   17 -
 drivers/gpu/drm/i915/intel_dp.c |  138 +--
 2 files changed, 87 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5a09416..275d149 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1553,12 +1553,21 @@
  */
 #define   PP_READY (1  30)
 #define   PP_SEQUENCE_NONE (0  28)
-#define   PP_SEQUENCE_ON   (1  28)
-#define   PP_SEQUENCE_OFF  (2  28)
-#define   PP_SEQUENCE_MASK 0x3000
+#define   PP_SEQUENCE_POWER_UP (1  28)
+#define   PP_SEQUENCE_POWER_DOWN (2  28)
+#define   PP_SEQUENCE_MASK (3  28)
+#define   PP_SEQUENCE_SHIFT28
 #define   PP_CYCLE_DELAY_ACTIVE(1  27)
-#define   PP_SEQUENCE_STATE_ON_IDLE (1  3)
 #define   PP_SEQUENCE_STATE_MASK 0x000f
+#define   PP_SEQUENCE_STATE_OFF_IDLE   (0x0  0)
+#define   PP_SEQUENCE_STATE_OFF_S0_1   (0x1  0)
+#define   PP_SEQUENCE_STATE_OFF_S0_2   (0x2  0)
+#define   PP_SEQUENCE_STATE_OFF_S0_3   (0x3  0)
+#define   PP_SEQUENCE_STATE_ON_IDLE(0x8  0)
+#define   PP_SEQUENCE_STATE_ON_S1_0(0x9  0)
+#define   PP_SEQUENCE_STATE_ON_S1_2(0xa  0)
+#define   PP_SEQUENCE_STATE_ON_S1_3(0xb  0)
+#define   PP_SEQUENCE_STATE_RESET  (0xf  0)
 #define PP_CONTROL 0x61204
 #define   POWER_TARGET_ON  (1  0)
 #define PP_ON_DELAYS   0x61208
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 185fae6..d6c6608 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -66,7 +66,6 @@ struct intel_dp {
struct drm_display_mode *panel_fixed_mode;  /* for eDP */
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
-   unsigned long panel_off_jiffies;
 };
 
 /**
@@ -915,32 +914,56 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
}
 }
 
-static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+#define IDLE_ON_MASK   (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
 | PP_SEQUENCE_STATE_MASK)
+#define IDLE_ON_VALUE  (PP_ON | PP_READY | PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_ON_IDLE)
+
+#define IDLE_OFF_MASK  (PP_ON | 0| PP_SEQUENCE_MASK | 0
 | PP_SEQUENCE_STATE_MASK)
+#define IDLE_OFF_VALUE (0 | 0| PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_OFF_IDLE)
+
+#define IDLE_CYCLE_MASK(PP_ON | 0| PP_SEQUENCE_MASK | 
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK)
+#define IDLE_CYCLE_VALUE   (0 | 0| PP_SEQUENCE_NONE | 0
 | PP_SEQUENCE_STATE_OFF_IDLE)
+
+static void ironlake_wait_panel_status(struct intel_dp *intel_dp,
+  u32 mask,
+  u32 value)
 {
-   unsigned long   off_time;
-   unsigned long   delay;
+   struct drm_device *dev = intel_dp-base.base.dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
 
-   DRM_DEBUG_KMS(Wait for panel power off time\n);
+   DRM_DEBUG_KMS(mask %08x value %08x status %08x control %08x\n,
+ mask, value,
+ I915_READ(PCH_PP_STATUS),
+ I915_READ(PCH_PP_CONTROL));
 
-   if (ironlake_edp_have_panel_power(intel_dp) ||
-   ironlake_edp_have_panel_vdd(intel_dp))
+   if (_wait_for((I915_READ(PCH_PP_STATUS)  mask) == value,
+ 5000,
+ 10))
{
-   DRM_DEBUG_KMS(Panel still on, no delay needed\n);
-   return;
+   DRM_ERROR(Panel status timeout: status %08x control %08x\n,
+ I915_READ(PCH_PP_STATUS),
+ I915_READ(PCH_PP_CONTROL));
}
+}
 
-   off_time = intel_dp-panel_off_jiffies + 
msecs_to_jiffies(intel_dp-panel_power_down_delay);
-   if (time_after(jiffies, off_time)) {
-   DRM_DEBUG_KMS(Time already passed);
-   return;
-   }
-   delay = jiffies_to_msecs(off_time - jiffies);
-   if (delay  intel_dp-panel_power_down_delay)
-   delay = intel_dp-panel_power_down_delay;
-   DRM_DEBUG_KMS(Waiting an additional %ld ms\n, delay);
-   msleep(delay);
+static void ironlake_wait_panel_on(struct intel_dp *intel_dp)
+{
+   DRM_DEBUG_KMS(Wait for panel power on\n);
+   ironlake_wait_panel_status(intel_dp, IDLE_ON_MASK, IDLE_ON_VALUE);
 }
 
+static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+{
+   DRM_DEBUG_KMS(Wait

[PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_display.c |3 +-
 drivers/gpu/drm/i915/intel_dp.c  |  112 --
 2 files changed, 81 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9fa342e..53eb29e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2933,7 +2933,8 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 
/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev) 
-   intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+   (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
u32 bpc = (I915_READ(PIPECONF(pipe))  PIPE_BPC_MASK)  5;
reg = TRANS_DP_CTL(pipe);
temp = I915_READ(reg);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c0c482..185fae6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
continue;
 
intel_dp = enc_to_intel_dp(encoder);
-   if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT) {
+   if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT || 
is_pch_edp(intel_dp)) {
lane_count = intel_dp-lane_count;
break;
-   } else if (is_edp(intel_dp)) {
+   } else if (is_cpu_edp(intel_dp)) {
lane_count = dev_priv-edp.lanes;
break;
}
@@ -808,6 +808,7 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
  struct drm_display_mode *adjusted_mode)
 {
struct drm_device *dev = encoder-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct drm_crtc *crtc = intel_dp-base.base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -820,18 +821,31 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
ironlake_edp_pll_off(encoder);
}
 
-   intel_dp-DP = DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
-   intel_dp-DP |= intel_dp-color_range;
+   /*
+* There are three kinds of DP registers:
+*
+*  IBX PCH
+*  CPU
+*  CPT PCH
+*
+* IBX PCH and CPU are the same for almost everything,
+* except that the CPU DP PLL is configured in this
+* register
+*
+* CPT PCH is quite different, having many bits moved
+* to the TRANS_DP_CTL register instead. That
+* configuration happens (oddly) in ironlake_pch_enable
+*/
 
-   if (adjusted_mode-flags  DRM_MODE_FLAG_PHSYNC)
-   intel_dp-DP |= DP_SYNC_HS_HIGH;
-   if (adjusted_mode-flags  DRM_MODE_FLAG_PVSYNC)
-   intel_dp-DP |= DP_SYNC_VS_HIGH;
+   /* Preserve the BIOS-computed detected bit. This is
+* supposed to be read-only.
+*/
+   intel_dp-DP = I915_READ(intel_dp-output_reg)  DP_DETECTED;
+   intel_dp-DP |=  DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
 
-   if (HAS_PCH_CPT(dev)  !is_cpu_edp(intel_dp))
-   intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
-   else
-   intel_dp-DP |= DP_LINK_TRAIN_OFF;
+   /* Handle DP bits in common between all three register formats */
+
+   intel_dp-DP |= DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
 
switch (intel_dp-lane_count) {
case 1:
@@ -850,32 +864,54 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_dp-DP |= DP_AUDIO_OUTPUT_ENABLE;
intel_write_eld(encoder, adjusted_mode);
}
-
memset(intel_dp-link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
intel_dp-link_configuration[0] = intel_dp-link_bw;
intel_dp-link_configuration[1] = intel_dp-lane_count;
intel_dp-link_configuration[8] = DP_SET_ANSI_8B10B;
-
/*
 * Check for DPCD version  1.1 and enhanced framing support
 */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
(intel_dp-dpcd[DP_MAX_LANE_COUNT]  DP_ENHANCED_FRAME_CAP)) {
intel_dp-link_configuration[1] |= 
DP_LANE_COUNT_ENHANCED_FRAME_EN;
-   intel_dp-DP |= DP_ENHANCED_FRAMING;
}
 
-   /* CPT DP's pipe select is decided in TRANS_DP_CTL */
-   if (intel_crtc-pipe == 1  !HAS_PCH_CPT(dev))
-   intel_dp-DP |= DP_PIPEB_SELECT;
+   /* Split out the IBX/CPU vs CPT settings

[PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

Instead of going through the sequence just once, run through the whole
set up to 5 times to see if something can work. This isn't part of the
DP spec, but the BIOS seems to do it, and given that link training
failure is so bad, it seems reasonable to follow suit.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_dp.c |   41 +-
 1 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6be6a04..bf20a35 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1576,8 +1576,9 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
 
ret = intel_dp_aux_native_write(intel_dp,
DP_TRAINING_LANE0_SET,
-   intel_dp-train_set, 4);
-   if (ret != 4)
+   intel_dp-train_set,
+   intel_dp-lane_count);
+   if (ret != intel_dp-lane_count)
return false;
 
return true;
@@ -1593,7 +1594,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
int i;
uint8_t voltage;
bool clock_recovery = false;
-   int tries;
+   int voltage_tries, loop_tries;
u32 reg;
uint32_t DP = intel_dp-DP;
 
@@ -1620,7 +1621,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP = ~DP_LINK_TRAIN_MASK;
memset(intel_dp-train_set, 0, 4);
voltage = 0xff;
-   tries = 0;
+   voltage_tries = 0;
+   loop_tries = 0;
clock_recovery = false;
for (;;) {
/* Use intel_dp-train_set[0] to set the voltage and pre 
emphasis values */
@@ -1663,17 +1665,28 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
for (i = 0; i  intel_dp-lane_count; i++)
if ((intel_dp-train_set[i]  
DP_TRAIN_MAX_SWING_REACHED) == 0)
break;
-   if (i == intel_dp-lane_count)
-   break;
-
-   /* Check to see if we've tried the same voltage 5 times */
-   if ((intel_dp-train_set[0]  DP_TRAIN_VOLTAGE_SWING_MASK) == 
voltage) {
-   ++tries;
-   if (tries == 5)
+   if (i == intel_dp-lane_count) {
+   ++loop_tries;
+   if (loop_tries == 5) {
+   DRM_DEBUG_KMS(too many full retries, give 
up\n);
break;
-   } else
-   tries = 0;
-   voltage = intel_dp-train_set[0]  DP_TRAIN_VOLTAGE_SWING_MASK;
+   }
+   memset(intel_dp-train_set, 0, 4);
+   voltage_tries = 0;
+   continue;
+   } else {
+
+   /* Check to see if we've tried the same voltage 5 times 
*/
+   if ((intel_dp-train_set[0]  
DP_TRAIN_VOLTAGE_SWING_MASK) == voltage) {
+   ++voltage_tries;
+   if (voltage_tries == 5) {
+   DRM_DEBUG_KMS(too many voltage 
retries, give up\n);
+   break;
+   }
+   } else
+   voltage_tries = 0;
+   voltage = intel_dp-train_set[0]  
DP_TRAIN_VOLTAGE_SWING_MASK;
+   }
 
/* Compute new intel_dp-train_set as requested by target */
intel_get_adjust_train(intel_dp, link_status);
-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

On Tue,  1 Nov 2011 23:20:27 -0700, Keith Packard kei...@keithp.com wrote:

 -static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
 +#define IDLE_ON_MASK (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
  | PP_SEQUENCE_STATE_MASK)
 +#define IDLE_ON_VALUE(PP_ON | PP_READY | PP_SEQUENCE_NONE | 0
  | PP_SEQUENCE_STATE_ON_IDLE)

A bit more testing -- looks like the MacBook Air doesn't mange to get
PP_READY set when it's time to turn the panel on. I should look at this
a bit more closely; there's no reason it shouldn't be set. But, nothing
bad seems to happen if we simply ignore the PP_READY bit

+#define IDLE_ON_MASK   (PP_ON | 0  | PP_SEQUENCE_MASK | 0  
   | PP_SEQUENCE_STATE_MASK)
+#define IDLE_ON_VALUE  (PP_ON | 0  | PP_SEQUENCE_NONE | 0  
   | PP_SEQUENCE_STATE_ON_IDLE)

-- 
keith.pack...@intel.com


pgpoYD2MnTVFw.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control

[Keith Packard]

On Wed, 2 Nov 2011 09:02:55 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Can't we just set UNLOCK_REGS at load time and have asserts sprinkled
 here and there?

I think we'd need it at resume time as well; it seemed easier to just
set it every time we touch the register.

-- 
keith.pack...@intel.com


pgpajPl54EXQj.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson a...@redhat.com wrote:

 Redundant.  You've already done the link_configuration |= above in the 
 common code.  You can drop the second if chunk altogether.

Thanks for catching this mistake; cutpaste programming without the cut part...

 In related news, the corresponding section for this in TRANS_DP_CTL 
 setup appears to turn on enhanced framing unconditionally.  This is 
 probably not a big deal, I don't think I've ever seen a display not 
 support it, but.

Yeah, it's actually a huge pain because TRANS_DP_CTL is set up in
ironlake_pch_enable, which is part of the crtc enable path not the
encoder mode set path, and getting to the appropriate intel_dp structure
takes a walk through all of the encoders to find the matching one.

I think we could move the TRANS_DP_CTL code into intel_dp.c where it
belongs; this chunk was stuck inside ironlake_crtc_dpms by Zhenyu last
year when DP/eDP support for Sandybridge and Cougarpoint was added in
commit e3421a189447c0b8cd0aff5c299f53b5ab7c38f6.

Most of the TRANS_DP_CTL chunk inside ironlake_pch_enable should just
get moved to intel_dp_mode_set, but I don't know if the
TRANS_DP_OUTPUT_ENABLE bit needs to be set before
intel_enable_transcoder is called; if it does, then we'd need to
preserve that piece inside ironlake_pch_enable, otherwise that bit would
move to intel_dp_commit.

-- 
keith.pack...@intel.com


pgpeaoMpxiQLN.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 2 Nov 2011 09:20:19 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 But I was curious about this hunk:
 
 @@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
 drm_display_mode *mode,
   continue;
  
   intel_dp = enc_to_intel_dp(encoder);
 - if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT) {
 + if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT || 
 is_pch_edp(intel_dp)) {
   lane_count = intel_dp-lane_count;
   break;
 - } else if (is_edp(intel_dp)) {
 + } else if (is_cpu_edp(intel_dp)) {
   lane_count = dev_priv-edp.lanes;
   break;
   }
 
 I guess this means we can't trust the BIOS settings for PCH eDP?

I'm pretty sure this isn't the right place to look at this value in any
case; we're setting the m/n ratios after already deciding how many lanes
to use. Getting this wrong means sending the wrong timing to the
monitor, not setting a different mode.

In any case, my AIO box sets the BIOS value to 1, when it needs 2 lanes
for the mode it uses.

-- 
keith.pack...@intel.com


pgpb7g2XzkOMy.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

[Keith Packard]

On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Note that PP_READY will incorrectly depend on some other register
 values, so in some configs the panel will happily power up even if
 PP_READY isn't set yet...

Yeah, I'd like to understand why PP_READY isn't getting set; we should
have all of the other pieces ready before we turn on the panel. But,
given that it's really just a sanity check, it probably doesn't make
sense to spin for 5 seconds waiting for a bit to turn on that won't.

I've just removed that bit from the IDLE_ON_MASK and IDLE_ON_VALUE.

-- 
keith.pack...@intel.com


pgpQXi5hT2J1M.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson ch...@chris-wilson.co.uk 
wrote:

 This would seem to be a separate chunk to initiate training on only the
 lanes we intend to use.

Yeah, this got left in during some debugging; it might be a good thing
to do, but it's completely separate. I've pulled it out into a separate
patch.

-- 
keith.pack...@intel.com


pgpQo3jYJ4ueU.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson a...@redhat.com wrote:

 Given the choice of trusting DPCD or the VBT, I'd definitely prefer
 DPCD.

Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may neglect to connect some
of the wires. In any case, if we want to look at these values, we should
be doing it before computing the M/N ratio so that we actually set the
hardware up correctly.

Any bets on how long until we find a machine that has right value in the
VBT and the wrong one in DPCD? Or a machine with wrong values in both places?

-- 
keith.pack...@intel.com


pgpDrGqfr3m9q.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson a...@redhat.com wrote:

 Redundant.  You've already done the link_configuration |= above in the 
 common code.  You can drop the second if chunk altogether.

Here's the new version of that chunk of patch:

@@ -850,32 +864,45 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_dp-DP |= DP_AUDIO_OUTPUT_ENABLE;
intel_write_eld(encoder, adjusted_mode);
}
-
memset(intel_dp-link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
intel_dp-link_configuration[0] = intel_dp-link_bw;
intel_dp-link_configuration[1] = intel_dp-lane_count;
intel_dp-link_configuration[8] = DP_SET_ANSI_8B10B;
-
/*
 * Check for DPCD version  1.1 and enhanced framing support
 */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
(intel_dp-dpcd[DP_MAX_LANE_COUNT]  DP_ENHANCED_FRAME_CAP)) {
intel_dp-link_configuration[1] |= 
DP_LANE_COUNT_ENHANCED_FRAME_EN;
-   intel_dp-DP |= DP_ENHANCED_FRAMING;
}
 
-   /* CPT DP's pipe select is decided in TRANS_DP_CTL */
-   if (intel_crtc-pipe == 1  !HAS_PCH_CPT(dev))
-   intel_dp-DP |= DP_PIPEB_SELECT;
+   /* Split out the IBX/CPU vs CPT settings */
 
-   if (is_cpu_edp(intel_dp)) {
-   /* don't miss out required setting for eDP */
-   intel_dp-DP |= DP_PLL_ENABLE;
-   if (adjusted_mode-clock  20)
-   intel_dp-DP |= DP_PLL_FREQ_160MHZ;
-   else
-   intel_dp-DP |= DP_PLL_FREQ_270MHZ;
+   if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
+   intel_dp-DP |= intel_dp-color_range;
+
+   if (adjusted_mode-flags  DRM_MODE_FLAG_PHSYNC)
+   intel_dp-DP |= DP_SYNC_HS_HIGH;
+   if (adjusted_mode-flags  DRM_MODE_FLAG_PVSYNC)
+   intel_dp-DP |= DP_SYNC_VS_HIGH;
+   intel_dp-DP |= DP_LINK_TRAIN_OFF;
+
+   if (intel_dp-link_configuration[1]  
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+   intel_dp-DP |= DP_ENHANCED_FRAMING;
+
+   if (intel_crtc-pipe == 1)
+   intel_dp-DP |= DP_PIPEB_SELECT;
+
+   if (is_cpu_edp(intel_dp)) {
+   /* don't miss out required setting for eDP */
+   intel_dp-DP |= DP_PLL_ENABLE;
+   if (adjusted_mode-clock  20)
+   intel_dp-DP |= DP_PLL_FREQ_160MHZ;
+   else
+   intel_dp-DP |= DP_PLL_FREQ_270MHZ;
+   }
+   } else {
+   intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
}
 }
 
-- 
keith.pack...@intel.com


pgpPsppIjprHF.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

[Keith Packard]

On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson ch...@chris-wilson.co.uk 
wrote:

 This would seem to be a separate chunk to initiate training on only the
 lanes we intend to use.
 -Chris

Here's that patch separated out:

commit e7fecae483754ca9a42312be18f58ceb454702fe
Author: Keith Packard kei...@keithp.com
Date:   Wed Nov 2 10:17:59 2011 -0700

drm/i915: Initiate DP link training only on the lanes we'll be using

Limit the link training setting command to the lanes needed for the
current mode. It seems vaguely possible that a monitor will try to
train the other lanes and fail in some way, so this seems like the
safer plan.

Signed-off-by: Keith Packard kei...@keithp.com

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0a4fa64..02b56ce 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1567,8 +1567,9 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
 
ret = intel_dp_aux_native_write(intel_dp,
DP_TRAINING_LANE0_SET,
-   intel_dp-train_set, 4);
-   if (ret != 4)
+   intel_dp-train_set,
+   intel_dp-lane_count);
+   if (ret != intel_dp-lane_count)
return false;
 
return true;


-- 
keith.pack...@intel.com


pgpoiA8fzE7ea.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Tue,  1 Nov 2011 23:20:26 -0700, Keith Packard kei...@keithp.com wrote:

   intel_dp = enc_to_intel_dp(encoder);
 - if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT) {
 + if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT || 
 is_pch_edp(intel_dp)) {
   lane_count = intel_dp-lane_count;
   break;
 - } else if (is_edp(intel_dp)) {
 + } else if (is_cpu_edp(intel_dp)) {
   lane_count = dev_priv-edp.lanes;
   break;

Thinking about this one more time -- if we ever want to use
dev_priv-edp.lanes, we should use it in
intel_dp_max_lane_count. intel_dp_set_m_n should use
intel_dp-lane_count unconditionally as that's the value we've used
everywhere else for mode setting.

Perhaps we should use it for monitors that don't include the
MAX_LANE_COUNT field in the dpcd? Perhaps we should use it on all eDP
monitors?

-- 
keith.pack...@intel.com


pgpQ6WExCPHDW.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson a...@redhat.com wrote:

 The VBT is going to be crap.

The only question then is what to do with hardware that doesn't have the
DPCD value -- that's new in revision 0x11, after all.

How about this:

commit 34ebe02cc78f20ae6b7865c5087c3b5ac7810185
Author: Keith Packard kei...@keithp.com
Date:   Wed Nov 2 13:03:47 2011 -0700

drm/i915: Use DPCD value for max DP lanes where possible

Fall back to the VBT value for eDP monitors only when DPCD is missing
the value.

Signed-off-by: Keith Packard kei...@keithp.com

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b56ce..93b082a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -154,6 +154,8 @@ intel_edp_link_config(struct intel_encoder *intel_encoder,
 static int
 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 {
+   struct drm_device *dev = intel_dp-base.base.dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
int max_lane_count = 4;
 
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11) {
@@ -164,6 +166,8 @@ intel_dp_max_lane_count(struct intel_dp *intel_dp)
default:
max_lane_count = 4;
}
+   } else if (is_edp(intel_dp)) {
+   max_lane_count = dev_priv-edp.lanes;
}
return max_lane_count;
 }
@@ -765,12 +769,11 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
continue;
 
intel_dp = enc_to_intel_dp(encoder);
-   if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT || 
is_pch_edp(intel_dp)) {
+   if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_dp-base.type == INTEL_OUTPUT_EDP)
+   {
lane_count = intel_dp-lane_count;
break;
-   } else if (is_cpu_edp(intel_dp)) {
-   lane_count = dev_priv-edp.lanes;
-   break;
}
}
 


-- 
keith.pack...@intel.com


pgpfuIUJESMUJ.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Treat PCH eDP like DP in most places

[Keith Packard]

On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson a...@redhat.com wrote:

 It is?  The DP 1.1a text for lane count is For Rev.1.1, only the 
 following three values are supported. All other values are reserved.

Yeah, if you look at the MAX_LINK_RATE field, we assume that it has a
useful value. I'll bet they were thinking of letting the spec support
things like alternate clock rates or 3 lanes or something, and the 1.1
version just tied things down to allow only sensible values there.

How about we just always use the DPCD value?

commit e0fafa5dee031ef6174eadb005a5f01d13da931d
Author: Keith Packard kei...@keithp.com
Date:   Wed Nov 2 13:03:47 2011 -0700

drm/i915: Use DPCD value for max DP lanes.

The BIOS VBT value for an eDP panel has been shown to be incorrect on
one machine, and we haven't found any machines where the DPCD value
was wrong, so we'll use the DPCD value everywhere.

Signed-off-by: Keith Packard kei...@keithp.com

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b56ce..5056d29 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -154,16 +154,12 @@ intel_edp_link_config(struct intel_encoder *intel_encoder,
 static int
 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 {
-   int max_lane_count = 4;
-
-   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11) {
-   max_lane_count = intel_dp-dpcd[DP_MAX_LANE_COUNT]  0x1f;
-   switch (max_lane_count) {
-   case 1: case 2: case 4:
-   break;
-   default:
-   max_lane_count = 4;
-   }
+   int max_lane_count = intel_dp-dpcd[DP_MAX_LANE_COUNT]  0x1f;
+   switch (max_lane_count) {
+   case 1: case 2: case 4:
+   break;
+   default:
+   max_lane_count = 4;
}
return max_lane_count;
 }
@@ -765,12 +761,11 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
continue;
 
intel_dp = enc_to_intel_dp(encoder);
-   if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT || 
is_pch_edp(intel_dp)) {
+   if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_dp-base.type == INTEL_OUTPUT_EDP)
+   {
lane_count = intel_dp-lane_count;
break;
-   } else if (is_cpu_edp(intel_dp)) {
-   lane_count = dev_priv-edp.lanes;
-   break;
}
}

-- 
keith.pack...@intel.com


pgp09gmQgXgO3.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set

[Keith Packard]

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?

Signed-off-by: Keith Packard 
Cc: Ben Widawsky 
---

Here's a shorter patch which just elides the body of the needs_idle_maps 
functions

 drivers/char/agp/intel-gtt.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 3a8d448..c92424c 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1186,10 +1186,11 @@ static void gen6_cleanup(void)
 /* Certain Gen5 chipsets require require idling the GPU before
  * unmapping anything from the GTT when VT-d is enabled.
  */
-extern int intel_iommu_gfx_mapped;
 static inline int needs_idle_maps(void)
 {
+#ifdef CONFIG_INTEL_IOMMU
const unsigned short gpu_devid = intel_private.pcidev->device;
+   extern int intel_iommu_gfx_mapped;

/* Query intel_iommu to see if we need the workaround. Presumably that
 * was loaded first.
@@ -1198,7 +1199,7 @@ static inline int needs_idle_maps(void)
 gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG) &&
 intel_iommu_gfx_mapped)
return 1;
-
+#endif
return 0;
 }

-- 
1.7.7

[PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set

[Keith Packard]

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?

Signed-off-by: Keith Packard 
Cc: Ben Widawsky 
---
 drivers/char/agp/intel-gtt.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 3a8d448..222190f 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1183,6 +1183,7 @@ static void gen6_cleanup(void)
 {
 }

+#ifdef CONFIG_INTEL_IOMMU
 /* Certain Gen5 chipsets require require idling the GPU before
  * unmapping anything from the GTT when VT-d is enabled.
  */
@@ -1201,6 +1202,7 @@ static inline int needs_idle_maps(void)

return 0;
 }
+#endif

 static int i9xx_setup(void)
 {
@@ -1236,8 +1238,10 @@ static int i9xx_setup(void)
intel_private.gtt_bus_addr = reg_addr + gtt_offset;
}

+#ifdef CONFIG_INTEL_IOMMU
if (needs_idle_maps())
intel_private.base.do_idle_maps = 1;
+#endif

intel_i9xx_setup_flush();

-- 
1.7.7

[PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set

[Keith Packard]

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?

Signed-off-by: Keith Packard kei...@keithp.com
Cc: Ben Widawsky b...@bwidawsk.net
---
 drivers/char/agp/intel-gtt.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 3a8d448..222190f 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1183,6 +1183,7 @@ static void gen6_cleanup(void)
 {
 }
 
+#ifdef CONFIG_INTEL_IOMMU
 /* Certain Gen5 chipsets require require idling the GPU before
  * unmapping anything from the GTT when VT-d is enabled.
  */
@@ -1201,6 +1202,7 @@ static inline int needs_idle_maps(void)
 
return 0;
 }
+#endif
 
 static int i9xx_setup(void)
 {
@@ -1236,8 +1238,10 @@ static int i9xx_setup(void)
intel_private.gtt_bus_addr = reg_addr + gtt_offset;
}
 
+#ifdef CONFIG_INTEL_IOMMU
if (needs_idle_maps())
intel_private.base.do_idle_maps = 1;
+#endif
 
intel_i9xx_setup_flush();
 
-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set

[Keith Packard]

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?

Signed-off-by: Keith Packard kei...@keithp.com
Cc: Ben Widawsky b...@bwidawsk.net
---

Here's a shorter patch which just elides the body of the needs_idle_maps 
functions

 drivers/char/agp/intel-gtt.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 3a8d448..c92424c 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1186,10 +1186,11 @@ static void gen6_cleanup(void)
 /* Certain Gen5 chipsets require require idling the GPU before
  * unmapping anything from the GTT when VT-d is enabled.
  */
-extern int intel_iommu_gfx_mapped;
 static inline int needs_idle_maps(void)
 {
+#ifdef CONFIG_INTEL_IOMMU
const unsigned short gpu_devid = intel_private.pcidev-device;
+   extern int intel_iommu_gfx_mapped;
 
/* Query intel_iommu to see if we need the workaround. Presumably that
 * was loaded first.
@@ -1198,7 +1199,7 @@ static inline int needs_idle_maps(void)
 gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG) 
 intel_iommu_gfx_mapped)
return 1;
-
+#endif
return 0;
 }
 
-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next

[Keith Packard]

Here's a pile of new code for the 3.2 series.

Overview:

 * 3 pipe support for IVB.
 * eDP fixes for SNB
 * Interrupt race condition fixes
 * Switch from MI_FLUSH to PIPECONTROL
 * VT-d work-around for ILK

The following changes since commit 0ac225e56997ef89f46eb51b02799a685b78f214:

  Merge branch 'drm-intel-fixes' into drm-intel-next (2011-09-28 14:44:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~keithp/linux drm-intel-next

Adam Jackson (8):
  drm/i915: Remove "i2c_speed" nonsense from child device table
  drm/i915: Fix multifunction SDVO detection
  drm/i915: Rename intel_sdvo_hdmi_sink_detect
  drm/i915: Remove redundant bit shifting from intel_gmbus_set_speed
  drm/i915/dp: Fix the math in intel_dp_link_required
  drm/i915/dp: Remove eDP special cases from bandwidth checks
  drm/i915/dp: Introduce is_cpu_edp()
  drm/i915/dp: Fix eDP on PCH DP on CPT/PPT

Andi Kleen (1):
  i915: Move i915_read/write out of line

Ben Widawsky (3):
  drm/i915: Remove early exit on i915_gpu_idle
  drm/i915: ILK + VT-d workaround
  drm: Add Panel Self Refresh DP addresses

Chris Wilson (1):
  drm/i915: Defend against userspace creating a gem object with size==0

Daniel Vetter (7):
  drm/i915: close PM interrupt masking races in the irq handler
  drm/i915: close PM interrupt masking races in the rps work func
  drm/i915: properly cancel rps_work on module unload v2
  drm/i915: fix swizzling on gen6+
  drm/i915: simplify swapin/out swizzle checking a bit
  io-mapping: ensure io_mapping_map_atomic _is_ atomic
  drm/i915: drop KM_USER0 argument to k(un)map_atomic

David Woodhouse (2):
  intel-iommu: Workaround IOTLB hang on Ironlake GPU
  intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.

Jesse Barnes (19):
  drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  drm/i915: always set FDI composite sync bit
  drm/i915: PLL macro cleanup and pipe assertion check
  drm/i915: support 3 pipes on IVB+
  drm/i915: split refclk code out of ironlake_crtc_mode_set
  drm/i915: use transcoder select bits on VGA and HDMI on CPT
  drm/i915: fix PCH PLL assertion check for 3 pipes
  drm/i915: add PLL sharing support to handle 3 pipes
  drm/i915: fix debug output for 3 pipe configs
  drm/i915: fix IVB cursor support
  drm/i915: fix transcoder PLL select masking
  drm/i915: export a CPT mode set verification function
  drm/i915: set watermarks for third pipe on IVB
  drm/i915: if transcoder disable fails, say which
  drm/i915: remove transcoder PLL mashing from mode_set per specs
  drm/i915: read full receiver capability field during DP hot plug
  drm/i915: add DP test request handling
  drm/i915: fix ILK+ infoframe support
  drm/i915: use correct SPD type value

Keith Packard (30):
  drm/i915: broken copyright encoding in intel_bios.c
  drm/i915: Use DRM_DEBUG_KMS for all messages in intel_bios.c
  drv/i915: Pull display_clock_mode out of VBT table
  drm/i915: Document a few more BDB_GENERAL_FEATURES bits from PCH BIOS
  drm/i915: Allow SSC parameter to override VBT value
  drm/i915: Fix PCH SSC reference clock settings
  drm/i915: Use CK505 as non-SSC source where available
  drm/i915: All PCH refclks are 120MHz
  drm/i915: Initialize PCH refclks at modeset init time
  drm/i915: Enable digital port hotplug on PCH systems
  drm/i915: Shut down PCH interrupts during irq_uninstall
  drm/i915: Only use VBT panel mode on eDP if no EDID is found
  drm/i915: Check eDP power when doing aux channel communications
  drm/i915: Unlock PCH_PP_CONTROL always
  drm/i915: Check for eDP inside edp panel on/off funcs
  drm/i915: Turn force VDD back off when panel running in intel_dp_dpms
  drm/i915: Ensure panel is on during DPMS off
  drm/i915: Delay DP i2c initialization until panel power timings are 
computed
  drm/i915: Wrap DP EDID fetch functions to enable eDP panel power
  drm/i915: Enable eDP panel power during I2C initialization sequence
  drm/i915: Ensure eDP powered up during DP_SET_POWER operation in 
dp_prepare
  drm/i915: Correct eDP panel power sequencing delay computations
  drm/i915: Move eDP panel fixed mode from dev_priv to intel_dp
  drm/i915: edp_panel_on does not need to return a bool
  drm/i915: Create helper functions to determine eDP power state
  drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously
  drm/i915: Restrict ILK-specific eDP power hack to ILK
  drm/i915: No need to wait for eDP power off delay if panel is on
  Merge branch 'edp-training-fixes' into drm-intel-next
  Merge branch 'fix-pch-refclk' into foo

Kenneth Graunke (2):
  drm/i915: Remove implied length of 2 from GFX_OP_PIPE_CONTROL #define.
  drm/i915: Rename PIPE_CONTROL bit defines to be 

[PULL] drm-intel-next

[Keith Packard]

Here's a pile of new code for the 3.2 series.

Overview:

 * 3 pipe support for IVB.
 * eDP fixes for SNB
 * Interrupt race condition fixes
 * Switch from MI_FLUSH to PIPECONTROL
 * VT-d work-around for ILK

The following changes since commit 0ac225e56997ef89f46eb51b02799a685b78f214:

  Merge branch 'drm-intel-fixes' into drm-intel-next (2011-09-28 14:44:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~keithp/linux drm-intel-next

Adam Jackson (8):
  drm/i915: Remove i2c_speed nonsense from child device table
  drm/i915: Fix multifunction SDVO detection
  drm/i915: Rename intel_sdvo_hdmi_sink_detect
  drm/i915: Remove redundant bit shifting from intel_gmbus_set_speed
  drm/i915/dp: Fix the math in intel_dp_link_required
  drm/i915/dp: Remove eDP special cases from bandwidth checks
  drm/i915/dp: Introduce is_cpu_edp()
  drm/i915/dp: Fix eDP on PCH DP on CPT/PPT

Andi Kleen (1):
  i915: Move i915_read/write out of line

Ben Widawsky (3):
  drm/i915: Remove early exit on i915_gpu_idle
  drm/i915: ILK + VT-d workaround
  drm: Add Panel Self Refresh DP addresses

Chris Wilson (1):
  drm/i915: Defend against userspace creating a gem object with size==0

Daniel Vetter (7):
  drm/i915: close PM interrupt masking races in the irq handler
  drm/i915: close PM interrupt masking races in the rps work func
  drm/i915: properly cancel rps_work on module unload v2
  drm/i915: fix swizzling on gen6+
  drm/i915: simplify swapin/out swizzle checking a bit
  io-mapping: ensure io_mapping_map_atomic _is_ atomic
  drm/i915: drop KM_USER0 argument to k(un)map_atomic

David Woodhouse (2):
  intel-iommu: Workaround IOTLB hang on Ironlake GPU
  intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.

Jesse Barnes (19):
  drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  drm/i915: always set FDI composite sync bit
  drm/i915: PLL macro cleanup and pipe assertion check
  drm/i915: support 3 pipes on IVB+
  drm/i915: split refclk code out of ironlake_crtc_mode_set
  drm/i915: use transcoder select bits on VGA and HDMI on CPT
  drm/i915: fix PCH PLL assertion check for 3 pipes
  drm/i915: add PLL sharing support to handle 3 pipes
  drm/i915: fix debug output for 3 pipe configs
  drm/i915: fix IVB cursor support
  drm/i915: fix transcoder PLL select masking
  drm/i915: export a CPT mode set verification function
  drm/i915: set watermarks for third pipe on IVB
  drm/i915: if transcoder disable fails, say which
  drm/i915: remove transcoder PLL mashing from mode_set per specs
  drm/i915: read full receiver capability field during DP hot plug
  drm/i915: add DP test request handling
  drm/i915: fix ILK+ infoframe support
  drm/i915: use correct SPD type value

Keith Packard (30):
  drm/i915: broken copyright encoding in intel_bios.c
  drm/i915: Use DRM_DEBUG_KMS for all messages in intel_bios.c
  drv/i915: Pull display_clock_mode out of VBT table
  drm/i915: Document a few more BDB_GENERAL_FEATURES bits from PCH BIOS
  drm/i915: Allow SSC parameter to override VBT value
  drm/i915: Fix PCH SSC reference clock settings
  drm/i915: Use CK505 as non-SSC source where available
  drm/i915: All PCH refclks are 120MHz
  drm/i915: Initialize PCH refclks at modeset init time
  drm/i915: Enable digital port hotplug on PCH systems
  drm/i915: Shut down PCH interrupts during irq_uninstall
  drm/i915: Only use VBT panel mode on eDP if no EDID is found
  drm/i915: Check eDP power when doing aux channel communications
  drm/i915: Unlock PCH_PP_CONTROL always
  drm/i915: Check for eDP inside edp panel on/off funcs
  drm/i915: Turn force VDD back off when panel running in intel_dp_dpms
  drm/i915: Ensure panel is on during DPMS off
  drm/i915: Delay DP i2c initialization until panel power timings are 
computed
  drm/i915: Wrap DP EDID fetch functions to enable eDP panel power
  drm/i915: Enable eDP panel power during I2C initialization sequence
  drm/i915: Ensure eDP powered up during DP_SET_POWER operation in 
dp_prepare
  drm/i915: Correct eDP panel power sequencing delay computations
  drm/i915: Move eDP panel fixed mode from dev_priv to intel_dp
  drm/i915: edp_panel_on does not need to return a bool
  drm/i915: Create helper functions to determine eDP power state
  drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously
  drm/i915: Restrict ILK-specific eDP power hack to ILK
  drm/i915: No need to wait for eDP power off delay if panel is on
  Merge branch 'edp-training-fixes' into drm-intel-next
  Merge branch 'fix-pch-refclk' into foo

Kenneth Graunke (2):
  drm/i915: Remove implied length of 2 from GFX_OP_PIPE_CONTROL #define.
  drm/i915: Rename PIPE_CONTROL bit defines to be less terse

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Keith Packard]

On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov  
wrote:

> From what I've checked, the other return error value in this context could
> be -EREMOTEIO, which could be caused by transmission error so it should be
> retried.

Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
bowels of the kernel i2c bits. Starting with the obvious (ENXIO) seems
safest to me.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Keith Packard]

On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov  wrote:

> + if (ret == -ENXIO) {
> + DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> + adapter->name);
> + break;
> + }

This seems good to me; are there additional error values which should
also be considered fatal and not subject to retry?

Reviewed-by: Keith Packard 

-keith
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111017/645b97c2/attachment.pgp>

Re: [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Keith Packard]

On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov eugeni.dodo...@intel.com 
wrote:

 + if (ret == -ENXIO) {
 + DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n,
 + adapter-name);
 + break;
 + }

This seems good to me; are there additional error values which should
also be considered fatal and not subject to retry?

Reviewed-by: Keith Packard kei...@keithp.com

-keith


pgpFsUdLzQUmW.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel