[Intel-gfx] [PATCH] drm/i915: convert dpms functions of dvo/sdvo/crt
Yeah, big patch but I couldn't come up with a neat idea of how to
split it up further, that wouldn't break dpms on cloned configs
somehow. But the changes in dvo/sdvo/crt are all pretty much
orthonogal, so it's not too bad a patch.
These are the only encoders that support cloning, which requires a few
special changes compared to the previous patches.
- Compute the desired state of the display pipe by walking all
connected encoders and checking whether any has active connectors.
To make this clearer, drop the old mode parameter to the crtc dpms
function and rename it to intel_crtc_update_dpms.
- There's the curious case of intel_crtc-dpms_mode. With the previous
patches to remove the overlay pipe A code and to rework the load
detect pipe code, the big users are gone. We still keep it to avoid
enabling the pipe twice, but we duplicate this logic with
crtc-active, too. Still, leave this for now and just push a fake
dpms mode into it that reflects the state of the display pipe.
Changes in the encoder dpms functions:
- We clamp the dpms state to the supported range right away. This is
escpecially important for the VGA outputs, where only older hw
supports the intermediate states. This (and the crt-adpa_reg patch)
allows us to unify the crt dpms code again between all variants
(gmch, vlv and pch).
- We only enable/disable the output for dvo/sdvo and leave the encoder
running. The encoder will be disabled/enabled when we switch the
state of the entire output pipeline (which will happen right away
for non-cloned setups). This way the duplication is reduced and
strange interaction when disabling output ports at the wrong time
avoided.
The dpms code for all three types of connectors contains a bit of
duplicated logic, but I think keeping these special cases separate is
simpler: CRT is the only one that hanldes intermediate dpms state
(which requires extra logic to enable/disable things in the right
order), and introducing some abstraction just to share the code
between dvo and sdvo smells like overkill. We can do that once someone
bothers to implement cloning for the more modern outputs. But I doubt
that this will ever happen.
v2: s/crtc/crt/_set_dpms, noticed by Paulo Zanoni.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_crt.c | 97 +++-
drivers/gpu/drm/i915/intel_display.c | 37 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_dvo.c | 39 +++
drivers/gpu/drm/i915/intel_sdvo.c| 60 ++
5 files changed, 122 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 543ea40..76646c7 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -84,13 +84,17 @@ static void intel_enable_crt(struct intel_encoder *encoder)
I915_WRITE(crt-adpa_reg, temp);
}
-static void pch_crt_dpms(struct drm_encoder *encoder, int mode)
+/* Note: The caller is required to filter out dpms modes not supported by the
+ * platform. */
+static void intel_crt_set_dpms(struct intel_encoder *encoder, int mode)
{
- struct drm_device *dev = encoder-dev;
+ struct drm_device *dev = encoder-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crt *crt = intel_encoder_to_crt(encoder);
u32 temp;
- temp = I915_READ(PCH_ADPA);
+ temp = I915_READ(crt-adpa_reg);
+ temp = ~(ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE);
temp = ~ADPA_DAC_ENABLE;
switch (mode) {
@@ -98,44 +102,59 @@ static void pch_crt_dpms(struct drm_encoder *encoder, int
mode)
temp |= ADPA_DAC_ENABLE;
break;
case DRM_MODE_DPMS_STANDBY:
+ temp |= ADPA_DAC_ENABLE | ADPA_HSYNC_CNTL_DISABLE;
+ break;
case DRM_MODE_DPMS_SUSPEND:
+ temp |= ADPA_DAC_ENABLE | ADPA_VSYNC_CNTL_DISABLE;
+ break;
case DRM_MODE_DPMS_OFF:
- /* Just leave port enable cleared */
+ temp |= ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE;
break;
}
- I915_WRITE(PCH_ADPA, temp);
+ I915_WRITE(crt-adpa_reg, temp);
}
-static void gmch_crt_dpms(struct drm_encoder *encoder, int mode)
+static void intel_crt_dpms(struct drm_connector *connector, int mode)
{
- struct drm_device *dev = encoder-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- u32 temp;
-
- temp = I915_READ(ADPA);
- temp = ~(ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE);
- temp = ~ADPA_DAC_ENABLE;
+ struct drm_device *dev = connector-dev;
+ struct intel_encoder *encoder = intel_attached_encoder(connector);
+ struct drm_crtc *crtc;
+ int old_dpms;
- if (IS_VALLEYVIEW(dev) mode != DRM_MODE_DPMS_ON)
+ /* PCH
Re: [Intel-gfx] [PULL] drm-intel-fixes
Per usual, I've forgotten all the cc's ... I really need to script this, I'm too dumb to remember. -Daniel On Wed, Aug 29, 2012 at 10:29:43AM +0200, Daniel Vetter wrote: Hi Dave, Just a few smaller things: - Fix up a pipe vs. plane confusion from a refactoring, fixes a regression from 3.1 (Anhua Xu). - Fix ivb sprite pixel formats (Vijay). - Fixup ppgtt pde placement for machines where the Bios artifically limits the availbale gtt space in the name of ... product differentiation (Chris). This fixes an oops. - Yet another no_lvds quirk entry. Otherwise nothing outstanding afaik, things are as boring as they should be ;-) Cheers, Daniel The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0: Linux 3.6-rc3 (2012-08-22 13:29:06 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to a51d4ed01e5bb39d2cf36a12f9976ab08872c192: i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard (2012-08-24 14:40:09 +0200) Calvin Walton (1): i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard Chris Wilson (1): drm/i915: Use the correct size of the GTT for placing the per-process entries Vijay Purushothaman (1): drm/i915: fix color order for BGR formats on IVB Xu, Anhua (1): drm/i915: fix wrong order of parameters in port checking functions drivers/gpu/drm/i915/i915_gem_gtt.c |2 +- drivers/gpu/drm/i915/intel_display.c | 12 ++-- drivers/gpu/drm/i915/intel_lvds.c|8 drivers/gpu/drm/i915/intel_sprite.c |4 ++-- 4 files changed, 17 insertions(+), 9 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: only enable sdvo hotplug irq if needed
Avoid constant wakeups caused by noisy irq lines when we don't even care
about the irq. This should be particularly useful for i945g/gm where the
hotplug has been disabled:
commit 768b107e4b3be0acf6f58e914afe4f337c00932b
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri May 4 11:29:56 2012 +0200
drm/i915: disable sdvo hotplug on i945g/gm
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
N.B. This really needs a Tested-by from the bug reporter.
---
drivers/gpu/drm/i915/intel_sdvo.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index f3762f8..14379b5 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2529,7 +2529,6 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_encoder *intel_encoder;
struct intel_sdvo *intel_sdvo;
- u32 hotplug_mask;
int i;
intel_sdvo = kzalloc(sizeof(struct intel_sdvo), GFP_KERNEL);
@@ -2561,19 +2560,6 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
}
}
- hotplug_mask = 0;
- if (IS_G4X(dev)) {
- hotplug_mask = intel_sdvo-is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_G4X :
SDVOC_HOTPLUG_INT_STATUS_G4X;
- } else if (IS_GEN4(dev)) {
- hotplug_mask = intel_sdvo-is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I965 :
SDVOC_HOTPLUG_INT_STATUS_I965;
- } else {
- hotplug_mask = intel_sdvo-is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I915 :
SDVOC_HOTPLUG_INT_STATUS_I915;
- }
- dev_priv-hotplug_supported_mask |= hotplug_mask;
-
drm_encoder_helper_add(intel_encoder-base, intel_sdvo_helper_funcs);
/* In default case sdvo lvds is false */
@@ -2595,6 +2581,24 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
goto err;
}
+ /* Only enable the hotplug irq if we need it, to work around noisy
+* hotplug lines.
+*/
+ if (intel_sdvo-hotplug_active[0] 0x3) {
+ u32 hotplug_mask;
+ if (IS_G4X(dev)) {
+ hotplug_mask = intel_sdvo-is_sdvob ?
+ SDVOB_HOTPLUG_INT_STATUS_G4X :
SDVOC_HOTPLUG_INT_STATUS_G4X;
+ } else if (IS_GEN4(dev)) {
+ hotplug_mask = intel_sdvo-is_sdvob ?
+ SDVOB_HOTPLUG_INT_STATUS_I965 :
SDVOC_HOTPLUG_INT_STATUS_I965;
+ } else {
+ hotplug_mask = intel_sdvo-is_sdvob ?
+ SDVOB_HOTPLUG_INT_STATUS_I915 :
SDVOC_HOTPLUG_INT_STATUS_I915;
+ }
+ dev_priv-hotplug_supported_mask |= hotplug_mask;
+ }
+
intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo, sdvo_reg);
/* Set the input timing to the screen. Assume always input 0. */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: only enable sdvo hotplug irq if needed
Avoid constant wakeups caused by noisy irq lines when we don't even care
about the irq. This should be particularly useful for i945g/gm where the
hotplug has been disabled:
commit 768b107e4b3be0acf6f58e914afe4f337c00932b
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri May 4 11:29:56 2012 +0200
drm/i915: disable sdvo hotplug on i945g/gm
v2: While at it, remove the bogus hotplug_active read, and do not mask
hotplug_active[0] before checking whether the irq is needed, per discussion
with Daniel on IRC.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
N.B. This really needs a Tested-by from the bug reporter.
---
drivers/gpu/drm/i915/intel_sdvo.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index d81bb0b..123afd3 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2573,7 +2573,6 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
hotplug_mask = intel_sdvo-is_sdvob ?
SDVOB_HOTPLUG_INT_STATUS_I915 :
SDVOC_HOTPLUG_INT_STATUS_I915;
}
- dev_priv-hotplug_supported_mask |= hotplug_mask;
drm_encoder_helper_add(intel_encoder-base, intel_sdvo_helper_funcs);
@@ -2581,14 +2580,6 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
if (!intel_sdvo_get_capabilities(intel_sdvo, intel_sdvo-caps))
goto err;
- /* Set up hotplug command - note paranoia about contents of reply.
-* We assume that the hardware is in a sane state, and only touch
-* the bits we think we understand.
-*/
- intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG,
-intel_sdvo-hotplug_active, 2);
- intel_sdvo-hotplug_active[0] = ~0x3;
-
if (intel_sdvo_output_setup(intel_sdvo,
intel_sdvo-caps.output_flags) != true) {
DRM_DEBUG_KMS(SDVO output failed to setup on %s\n,
@@ -2596,6 +2587,12 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
goto err;
}
+ /* Only enable the hotplug irq if we need it, to work around noisy
+* hotplug lines.
+*/
+ if (intel_sdvo-hotplug_active[0])
+ dev_priv-hotplug_supported_mask |= hotplug_mask;
+
intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo, sdvo_reg);
/* Set the input timing to the screen. Assume always input 0. */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: compute masks of crtcs affected in set_mode
This is definetely a bit more generic than currently required, but
if we keep track of all crtcs that need to be disabled/enable (because
they loose an encoder or something similar), crtcs that get completely
disabled and those that we need to do an actual mode change on nicely
prepares us for global modeset operations on multiple crtcs.
The only big thing missing here would be a global resource allocation
step (for e.g. pch plls), which would equally frob these bitmasks if
e.g. a crtc only needs a new pll.
These masks aren't yet put to use in this patch, this will follow in the
next one.
v2-v5: Fix up the computations for good (hopefully).
v6: Fixup a confusion reported by Damien Lespiau: I've conserved the
(imo braindead) behaviour of the crtc helper to disable _any_
disconnected outputs if we do a modeset, even when that newly disabled
connector isn't connected to the crtc being changed by the modeset.
The effect of that is that we could disable an arbitrary number of
unrelated crtcs, which I haven't taken into account when writing this
code. Fix this up.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 96
1 file changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c59569e..8f71957 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6706,6 +6706,98 @@ fail:
return ERR_PTR(-EINVAL);
}
+/* Computes which crtcs are affected and sets the relevant bits in the mask.
For
+ * simplicity we use the crtc's pipe number (because it's easier to obtain). */
+static void
+intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes,
+unsigned *prepare_pipes, unsigned *disable_pipes)
+{
+ struct intel_crtc *intel_crtc;
+ struct drm_device *dev = crtc-dev;
+ struct intel_encoder *encoder;
+ struct intel_connector *connector;
+ struct drm_crtc *tmp_crtc;
+
+ *disable_pipes = *modeset_pipes = *prepare_pipes = 0;
+
+ /* Check which crtcs have changed outputs connected to them, these need
+* to be part of the prepare_pipes mask. We don't (yet) support global
+* modeset across multiple crtcs, so modeset_pipes will only have one
+* bit set at most. */
+ list_for_each_entry(connector, dev-mode_config.connector_list,
+ base.head) {
+ if (connector-base.encoder == connector-new_encoder-base)
+ continue;
+
+ if (connector-base.encoder) {
+ tmp_crtc = connector-base.encoder-crtc;
+
+ *prepare_pipes |= 1 to_intel_crtc(tmp_crtc)-pipe;
+ }
+
+ if (connector-new_encoder)
+ *prepare_pipes |=
+ 1 connector-new_encoder-new_crtc-pipe;
+ }
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list,
+ base.head) {
+ if (encoder-base.crtc == encoder-new_crtc-base)
+ continue;
+
+ if (encoder-base.crtc) {
+ tmp_crtc = encoder-base.crtc;
+
+ *prepare_pipes |= 1 to_intel_crtc(tmp_crtc)-pipe;
+ }
+
+ if (encoder-new_crtc)
+ *prepare_pipes |= 1 encoder-new_crtc-pipe;
+ }
+
+ /* Check for any pipes that will be fully disabled ... */
+ list_for_each_entry(intel_crtc, dev-mode_config.crtc_list,
+ base.head) {
+ bool used = false;
+
+ /* Don't try to disable disabled crtcs. */
+ if (!intel_crtc-base.enabled)
+ continue;
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list,
+ base.head) {
+ if (encoder-new_crtc == intel_crtc)
+ used = true;
+ }
+
+ if (!used)
+ *disable_pipes |= 1 intel_crtc-pipe;
+ }
+
+
+ /* set_mode is also used to update properties on life display pipes. */
+ intel_crtc = to_intel_crtc(crtc);
+ if (crtc-enabled)
+ *prepare_pipes |= 1 intel_crtc-pipe;
+
+ /* We only support modeset on one single crtc, hence we need to do that
+* only for the passed in crtc iff we change anything else than just
+* disable crtcs.
+*
+* This is actually not true, to be fully compatible with the old crtc
+* helper we automatically disable _any_ output (i.e. doesn't need to be
+* connected to the crtc we're modesetting on) if it's disconnected.
+* Which is a rather nutty api (since changed the output configuration
+* without userspace's explicit request can lead to
Re: [Intel-gfx] [PATCH 00/58] modeset-rework, the basic conversion
On Thu, Aug 23, 2012 at 11:39 PM, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Aug 23, 2012 at 01:26:39PM +0100, Lespiau, Damien wrote: On Wed, Aug 22, 2012 at 10:21 PM, Daniel Vetter dan...@ffwll.ch wrote: Please test the for-damien branch in my personal fdo git repo. I'm rather positive that the patch there should fix this (but in the least it should unearth the real culprit). After a bit of back and forth and the updated 50/58 patch, does not regress any more here with the testing done on an IVB system. Tested-by: Damien Lespiau damien.lesp...@intel.com -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] intel_reg_dumper: Dump FDI_RX_DEBUG registers
On Fri, Aug 24, 2012 at 12:14 AM, Ben Widawsky b...@bwidawsk.net wrote: +#define FDI_RXA_DEBUG 0xf0020 +#define FDI_RXB_DEBUG 0xf1020 [snip] My only gripe with this patch is in the naming. Can you please use something find-able in the BSPEC, like: FDI_RX_DEBUG_B instead of FDI_RXB_DEBUG I used the same convention as all the others FDI_[R,T]x_[A,B,C]_* registers, if you look closely: FDX_TXA_CTL, FDX_TXA_MISC, ... I believe this is because those registers have been introduced with ironlake and the ILK spec names them like this while later specs adopt the _A, _B, _C suffixes. I went for consistency. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix sdvo hotplug support check and activation
The sdvo hotplug support check and activation has worked by coincidence for
TMDS0. The boolean value returned by intel_sdvo_supports_hotplug() was
masked with a bit shifted by device number, which also should have been one
of SDVO_OUTPUT_* bits instead. Boolean true masked with 1 shifted by 0 just
happened to match SDVO_OUTPUT_TMDS0...
Get hotplug support as a bit mask, check the correct bits for support, and
use the correct bits for activating hotplug support.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
In reply to the other patch as this depends on it.
---
drivers/gpu/drm/i915/intel_sdvo.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 80552de..6b4f43f 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -97,7 +97,7 @@ struct intel_sdvo {
/*
* Hotplug activation bits for this device
*/
- uint8_t hotplug_active[2];
+ uint16_t hotplug_active;
/**
* This is used to select the color range of RBG outputs in HDMI mode.
@@ -1251,25 +1251,29 @@ static bool intel_sdvo_get_capabilities(struct
intel_sdvo *intel_sdvo, struct in
return true;
}
-static int intel_sdvo_supports_hotplug(struct intel_sdvo *intel_sdvo)
+static uint16_t intel_sdvo_get_hotplug_support(struct intel_sdvo *intel_sdvo)
{
struct drm_device *dev = intel_sdvo-base.base.dev;
- u8 response[2];
+ uint16_t hotplug;
/* HW Erratum: SDVO Hotplug is broken on all i945G chips, there's noise
* on the line. */
if (IS_I945G(dev) || IS_I945GM(dev))
- return false;
+ return 0;
+
+ if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
+ hotplug, sizeof(hotplug)))
+ return 0;
- return intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
- response, 2) response[0];
+ return hotplug;
}
static void intel_sdvo_enable_hotplug(struct intel_encoder *encoder)
{
struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder-base);
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
intel_sdvo-hotplug_active, 2);
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
+ intel_sdvo-hotplug_active, 2);
}
static bool
@@ -2063,17 +2067,18 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int
device)
intel_connector = intel_sdvo_connector-base;
connector = intel_connector-base;
- if (intel_sdvo_supports_hotplug(intel_sdvo) (1 device)) {
+ if (intel_sdvo_get_hotplug_support(intel_sdvo)
+ intel_sdvo_connector-output_flag) {
connector-polled = DRM_CONNECTOR_POLL_HPD;
- intel_sdvo-hotplug_active[0] |= 1 device;
+ intel_sdvo-hotplug_active |= intel_sdvo_connector-output_flag;
/* Some SDVO devices have one-shot hotplug interrupts.
* Ensure that they get re-enabled when an interrupt happens.
*/
intel_encoder-hot_plug = intel_sdvo_enable_hotplug;
intel_sdvo_enable_hotplug(intel_encoder);
- }
- else
+ } else {
connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
+ }
encoder-encoder_type = DRM_MODE_ENCODER_TMDS;
connector-connector_type = DRM_MODE_CONNECTOR_DVID;
@@ -2589,7 +2594,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
/* Only enable the hotplug irq if we need it, to work around noisy
* hotplug lines.
*/
- if (intel_sdvo-hotplug_active[0])
+ if (intel_sdvo-hotplug_active)
dev_priv-hotplug_supported_mask |= hotplug_mask;
intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo, sdvo_reg);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set DERRMR around batches required vblank events
On Thu, 26 Jul 2012 21:30:19 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: In order for the Display Engine to send messages to the Render Engine, that event must be unmasked in the Display Engine Render Response Mask Register (DERRMR). By default all events are masked to prevent unwanted messages to conserve power, and it is strongly recommended that only single events be unmasked at any time. So in order to pipeline the register writes around individual batchbuffers, userspace must notify the kernel when it requires a vblank event, this patch implements an interface to do so with an single (pipe, event) request through the execbuffer flags. Note that another workaround is required for IVB, in that we must also prevent RC6 sleeps whilst waiting upon an event. To do that we also pipeline a forcewake into the second MT slot. Anyone have any criticisms for this patch? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] intel_reg_dumper: Dump FDI_RX_DEBUG registers
On Wed, 29 Aug 2012 13:50:42 +0100 Lespiau, Damien damien.lesp...@intel.com wrote: On Fri, Aug 24, 2012 at 12:14 AM, Ben Widawsky b...@bwidawsk.net wrote: +#define FDI_RXA_DEBUG 0xf0020 +#define FDI_RXB_DEBUG 0xf1020 [snip] My only gripe with this patch is in the naming. Can you please use something find-able in the BSPEC, like: FDI_RX_DEBUG_B instead of FDI_RXB_DEBUG I used the same convention as all the others FDI_[R,T]x_[A,B,C]_* registers, if you look closely: FDX_TXA_CTL, FDX_TXA_MISC, ... I believe this is because those registers have been introduced with ironlake and the ILK spec names them like this while later specs adopt the _A, _B, _C suffixes. I went for consistency. Generally, I agree with this approach, but in this case I'd rather shift everything over to the new naming instead. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix sdvo hotplug support check and activation
(apologies to Daniel and Jani, who've seen this twice - I accidentally sent it from the wrong address originally). On Wednesday 29 August 2012 16:43:58 Jani Nikula wrote: The sdvo hotplug support check and activation has worked by coincidence for TMDS0. The boolean value returned by intel_sdvo_supports_hotplug() was masked with a bit shifted by device number, which also should have been one of SDVO_OUTPUT_* bits instead. Boolean true masked with 1 shifted by 0 just happened to match SDVO_OUTPUT_TMDS0... Get hotplug support as a bit mask, check the correct bits for support, and use the correct bits for activating hotplug support. Signed-off-by: Jani Nikula jani.nik...@intel.com Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.com The code you're fixing was written with the aid of ajax's educated guesses - it's nice to see an Intel employee fix it to match the spec. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/76] drm/fb-helper: don't clobber output routing in setup_crtcs
On Thu, 26 Jul 2012 20:48:26 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder-crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the new drm/i915 code depends upon to be
absolutely correct.
The crtc helper itself doesn't really care about that, since it
disables unused encoders in a rather roundabout way.
Two places call drm_setup_crts:
- For the initial fb config. I've auditted all current drivers, and
they all allocate their encoders with kzalloc. So there's no need to
clear encoder-crtc once more.
- When processing hotplug events while showing the fb console. This
one is a bit more tricky, but both the crtc helper code and the new
drm/i915 modeset code disable encoders if their crtc is changed and
that encoder isn't part of the new config. Also, both disable any
disconnected outputs, too.
Which only leaves encoders that are on, connected, but for some odd
reason the fb helper code doesn't want to use. That would be a bug
in the fb configuration selector, since it tries to light up as many
outputs as possible.
v2: Kill the now unused encoders variable.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c index f546d1e..4ecc869 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1230,7 +1230,6 @@ static void drm_setup_crtcs(struct
drm_fb_helper *fb_helper) struct drm_device *dev = fb_helper-dev;
struct drm_fb_helper_crtc **crtcs;
struct drm_display_mode **modes;
- struct drm_encoder *encoder;
struct drm_mode_set *modeset;
bool *enabled;
int width, height;
@@ -1241,11 +1240,6 @@ static void drm_setup_crtcs(struct
drm_fb_helper *fb_helper) width = dev-mode_config.max_width;
height = dev-mode_config.max_height;
- /* clean out all the encoder/crtc combos */
- list_for_each_entry(encoder, dev-mode_config.encoder_list,
head) {
- encoder-crtc = NULL;
- }
-
crtcs = kcalloc(dev-mode_config.num_connector,
sizeof(struct drm_fb_helper_crtc *),
GFP_KERNEL); modes = kcalloc(dev-mode_config.num_connector,
I remember running into this when doing the fastboot stuff, but I
thought it had other side effects too (maybe hot plug). But that was
probably some other bug I worked through in while testing, since in
theory the above should be ok.
All of this stuff will need lots of tested-bys, but this one has my
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org fwiw.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/76] drm/i915: add missing gen2 pipe A quirk entries
On Thu, 26 Jul 2012 20:48:27 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
For some odd reason we've missed i830 and a i855 variant. Also
kill the two now redundant i830 entries.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c index 17020cd..21eff8b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7027,21 +7027,17 @@ static struct intel_quirk intel_quirks[] = {
/* HP Mini needs pipe A force quirk (LP: #322104) */
{ 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
- /* Thinkpad R31 needs pipe A force quirk */
- { 0x3577, 0x1014, 0x0505, quirk_pipea_force },
/* Toshiba Protege R-205, S-209 needs pipe A force quirk */
{ 0x2592, 0x1179, 0x0001, quirk_pipea_force },
- /* ThinkPad X30 needs pipe A force quirk (LP: #304614) */
- { 0x3577, 0x1014, 0x0513, quirk_pipea_force },
- /* ThinkPad X40 needs pipe A force quirk */
-
/* ThinkPad T60 needs pipe A force quirk (bug #16494) */
{ 0x2782, 0x17aa, 0x201a, quirk_pipea_force },
/* 855 before need to leave pipe A dpll A up */
{ 0x3582, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
{ 0x2562, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
+ { 0x3577, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
+ { 0x358e, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
/* Lenovo U160 cannot use SSC on LVDS */
{ 0x0046, 0x17aa, 0x3920, quirk_ssc_force_disable },
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/76] drm/i915: simplify dvo dpms interface
On Thu, 26 Jul 2012 20:48:31 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
All dvo drivers only support 2 dpms states, and our dvo driver
even switches of the dvo port for anything else than DPMS_ON. Hence
ditch this complexity and simply use bool enable.
While reading through this code I've noticed that the mode_set
function of ch7017 is a bit peculiar - it disable the lvds again, even
though the crtc helper code should have done that ... This might be to
work around an issue at driver load, we pretty much ignore the hw
state when taking over.
v2: Also do the conversion for the new ns2501 driver.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/dvo.h|9 -
drivers/gpu/drm/i915/dvo_ch7017.c |8
drivers/gpu/drm/i915/dvo_ch7xxx.c |4 ++--
drivers/gpu/drm/i915/dvo_ivch.c |8
drivers/gpu/drm/i915/dvo_ns2501.c | 14 ++
drivers/gpu/drm/i915/dvo_sil164.c |4 ++--
drivers/gpu/drm/i915/dvo_tfp410.c |4 ++--
drivers/gpu/drm/i915/intel_dvo.c |4 ++--
8 files changed, 26 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo.h b/drivers/gpu/drm/i915/dvo.h
index 0c8ac4d..0fa839e 100644
--- a/drivers/gpu/drm/i915/dvo.h
+++ b/drivers/gpu/drm/i915/dvo.h
@@ -58,13 +58,12 @@ struct intel_dvo_dev_ops {
void (*create_resources)(struct intel_dvo_device *dvo);
/*
- * Turn on/off output or set intermediate power levels if
available.
+ * Turn on/off output.
*
- * Unsupported intermediate modes drop to the lower power
setting.
- * If the mode is DPMSModeOff, the output must be disabled,
- * as the DPLL may be disabled afterwards.
+ * Because none of our dvo drivers support an intermediate
power levels,
+ * we don't expose this in the interfac.
*/
- void (*dpms)(struct intel_dvo_device *dvo, int mode);
+ void (*dpms)(struct intel_dvo_device *dvo, bool enable);
/*
* Callback for testing a video mode for a given output.
diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c
b/drivers/gpu/drm/i915/dvo_ch7017.c index 1ca799a..71e7650 100644
--- a/drivers/gpu/drm/i915/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/dvo_ch7017.c
@@ -163,7 +163,7 @@ struct ch7017_priv {
};
static void ch7017_dump_regs(struct intel_dvo_device *dvo);
-static void ch7017_dpms(struct intel_dvo_device *dvo, int mode);
+static void ch7017_dpms(struct intel_dvo_device *dvo, bool enable);
static bool ch7017_read(struct intel_dvo_device *dvo, u8 addr, u8
*val) {
@@ -309,7 +309,7 @@ static void ch7017_mode_set(struct
intel_dvo_device *dvo, lvds_power_down =
CH7017_LVDS_POWER_DOWN_DEFAULT_RESERVED | (mode-hdisplay 0x0700)
8;
- ch7017_dpms(dvo, DRM_MODE_DPMS_OFF);
+ ch7017_dpms(dvo, false);
ch7017_write(dvo, CH7017_HORIZONTAL_ACTIVE_PIXEL_INPUT,
horizontal_active_pixel_input);
ch7017_write(dvo, CH7017_HORIZONTAL_ACTIVE_PIXEL_OUTPUT,
@@ -331,7 +331,7 @@ static void ch7017_mode_set(struct
intel_dvo_device *dvo, }
/* set the CH7017 power state */
-static void ch7017_dpms(struct intel_dvo_device *dvo, int mode)
+static void ch7017_dpms(struct intel_dvo_device *dvo, bool enable)
{
uint8_t val;
@@ -345,7 +345,7 @@ static void ch7017_dpms(struct intel_dvo_device
*dvo, int mode) CH7017_DAC3_POWER_DOWN |
CH7017_TV_POWER_DOWN_EN);
- if (mode == DRM_MODE_DPMS_ON) {
+ if (enable) {
/* Turn on the LVDS */
ch7017_write(dvo, CH7017_LVDS_POWER_DOWN,
val ~CH7017_LVDS_POWER_DOWN_EN);
diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c
b/drivers/gpu/drm/i915/dvo_ch7xxx.c index 4a03660..c1dea5b 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -289,9 +289,9 @@ static void ch7xxx_mode_set(struct
intel_dvo_device *dvo, }
/* set the CH7xxx power state */
-static void ch7xxx_dpms(struct intel_dvo_device *dvo, int mode)
+static void ch7xxx_dpms(struct intel_dvo_device *dvo, bool enable)
{
- if (mode == DRM_MODE_DPMS_ON)
+ if (enable)
ch7xxx_writeb(dvo, CH7xxx_PM, CH7xxx_PM_DVIL |
CH7xxx_PM_DVIP); else
ch7xxx_writeb(dvo, CH7xxx_PM, CH7xxx_PM_FPD);
diff --git a/drivers/gpu/drm/i915/dvo_ivch.c
b/drivers/gpu/drm/i915/dvo_ivch.c index 04f2893..fa8ff6b 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -288,7 +288,7 @@ static enum drm_mode_status
ivch_mode_valid(struct intel_dvo_device *dvo, }
/** Sets the power state of the panel connected to the ivch */
-static void ivch_dpms(struct intel_dvo_device *dvo, int mode)
+static void ivch_dpms(struct intel_dvo_device *dvo, bool enable)
{
int i;
uint16_t vr01, vr30, backlight;
@@ -297,13 +297,13 @@ static void ivch_dpms(struct intel_dvo_device
*dvo, int mode) if
Re: [Intel-gfx] intel graphics rc6 power saving causes flickering
On Wed, Aug 29, 2012 at 7:15 PM, Giampiero Salvi giampisa...@gmail.com wrote: Hi Daniel, I hope you are the right person to contact about this upstream bug. I'll try to follow the form at https://wiki.ubuntu.com/Bugs/Upstream/kernel to report it. Please consider that it's the first time I report an upstream bug :) Bug report looks good, but mailing your maintainer won't scale. Please file at bugs.freedesktop.org against dri - drm/intel. You can pretty much ditch all the additional information, save for maybe an lspci -nn attachment. Also, retesting on latest 3.6-rc3 kernels would be rather interesting, we've fixed a few things that /might/ apply to your issue. Yours, Daniel Best, Giampiero [1.] One line summary of the problem: intel graphics rc6 power saving causes flickering [2.] Full description of the problem/report: Since RC6 power saving was enabled by default (Ubuntu 12.04), disconnecting the power cable causes flickering in the screen. The problem is solved by disabling RC6 power saving in the kernel parameters. This is done by adding i915.i915_enable_rc6=0 to the GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub and by running 'sudo update-grub'. The problem seems to be related to the power level that the video card sends to the screen, that seems to become comparable to the thermal noise and makes the screen loose sync. In fact, in a minority of times, I need to move the screen back and forward to trigger the problem, which made me think of a wiring problem in the beginning. However, the problem never occurs when I am connected to the power source even when I move the screen strongly. [3.] Keywords (i.e., modules, networking, kernel): kernel, modules, intel graphics, flickering [4.] Kernel version (from /proc/version): Linux version 3.6.0-030600rc3-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201208221735 SMP Wed Aug 22 21:45:31 UTC 2012 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) does not apply [6.] A small shell script or example program which triggers the problem (if possible) a script is not needed to trigger the problem [7.] Environment Description:Ubuntu 12.04.1 LTS Release:12.04 [7.1.] Software (add the output of the ver_linux script here) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ctt-netbook 3.6.0-030600rc3-generic #201208221735 SMP Wed Aug 22 21:45:31 UTC 2012 i686 i686 i386 GNU/Linux Gnu C 4.6 Gnu make 3.81 binutils 2.22 util-linux 2.20.1 mount support module-init-tools 3.16 e2fsprogs 1.42 pcmciautils018 Linux C Library2.15 Dynamic linker (ldd) 2.15 Procps 3.2.8 Net-tools 1.60 Kbd1.15.2 Sh-utils 8.13 wireless-tools 30 Modules Loaded rfcomm bnep bluetooth parport_pc ppdev binfmt_misc dm_crypt joydev arc4 snd_hda_codec_realtek snd_hda_intel snd_hda_codec ath9k mac80211 eeepc_wmi asus_wmi snd_hwdep snd_pcm coretemp snd_seq_midi ath9k_common ath9k_hw sparse_keymap snd_rawmidi snd_seq_midi_event snd_seq ath microcode snd_timer psmouse snd_seq_device snd serio_raw cfg80211 soundcore snd_page_alloc lpc_ich mac_hid lp parport i915 atl1c drm_kms_helper drm i2c_algo_bit video wmi [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU N450 @ 1.66GHz stepping: 10 microcode : 0x107 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm bogomips: .19 clflush size: 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU N450 @ 1.66GHz stepping: 10 microcode : 0x107 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 0 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug
Re: [Intel-gfx] [PATCH 07/76] drm/i915: kill a few unused things in dev_priv
On Thu, 26 Jul 2012 20:48:32 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
... and move a few others only used by i915_dma.c into the dri1
dungeon.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 22 +++---
drivers/gpu/drm/i915/i915_drv.h | 13 ++---
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index 71672ce..6ff86c1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -235,10 +235,10 @@ static int i915_initialize(struct drm_device *
dev, drm_i915_init_t * init) }
}
- dev_priv-cpp = init-cpp;
- dev_priv-back_offset = init-back_offset;
- dev_priv-front_offset = init-front_offset;
- dev_priv-current_page = 0;
+ dev_priv-dri1.cpp = init-cpp;
+ dev_priv-dri1.back_offset = init-back_offset;
+ dev_priv-dri1.front_offset = init-front_offset;
+ dev_priv-dri1.current_page = 0;
if (master_priv-sarea_priv)
master_priv-sarea_priv-pf_current_page = 0;
@@ -575,7 +575,7 @@ static int i915_dispatch_flip(struct drm_device *
dev)
DRM_DEBUG_DRIVER(%s: page=%d pfCurrentPage=%d\n,
__func__,
- dev_priv-current_page,
+ dev_priv-dri1.current_page,
master_priv-sarea_priv-pf_current_page);
i915_kernel_lost_context(dev);
@@ -589,12 +589,12 @@ static int i915_dispatch_flip(struct drm_device
* dev)
OUT_RING(CMD_OP_DISPLAYBUFFER_INFO | ASYNC_FLIP);
OUT_RING(0);
- if (dev_priv-current_page == 0) {
- OUT_RING(dev_priv-back_offset);
- dev_priv-current_page = 1;
+ if (dev_priv-dri1.current_page == 0) {
+ OUT_RING(dev_priv-dri1.back_offset);
+ dev_priv-dri1.current_page = 1;
} else {
- OUT_RING(dev_priv-front_offset);
- dev_priv-current_page = 0;
+ OUT_RING(dev_priv-dri1.front_offset);
+ dev_priv-dri1.current_page = 0;
}
OUT_RING(0);
@@ -613,7 +613,7 @@ static int i915_dispatch_flip(struct drm_device *
dev) ADVANCE_LP_RING();
}
- master_priv-sarea_priv-pf_current_page =
dev_priv-current_page;
+ master_priv-sarea_priv-pf_current_page =
dev_priv-dri1.current_page; return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 0b2eb17..1258a74 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -402,12 +402,6 @@ typedef struct drm_i915_private {
struct resource mch_res;
- unsigned int cpp;
- int back_offset;
- int front_offset;
- int current_page;
- int page_flipping;
-
atomic_t irq_received;
/* protects the irq masks */
@@ -425,7 +419,6 @@ typedef struct drm_i915_private {
u32 hotplug_supported_mask;
struct work_struct hotplug_work;
- unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
int num_pipe;
int num_pch_pll;
@@ -764,6 +757,12 @@ typedef struct drm_i915_private {
struct {
unsigned allow_batchbuffer : 1;
u32 __iomem *gfx_hws_cpu_addr;
+
+ unsigned int cpp;
+ int back_offset;
+ int front_offset;
+ int current_page;
+ int page_flipping;
} dri1;
/* Kernel Modesetting */
Does dri1 work anymore? If not, and no one has noticed, let's kill it!
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel graphics rc6 power saving causes flickering
On Wed, Aug 29, 2012 at 7:38 PM, Giampiero Salvi giampisa...@gmail.com wrote: Hi Daniel, thank you for the fast answer. On Wed, Aug 29, 2012 at 7:31 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Also, retesting on latest 3.6-rc3 kernels would be rather interesting, we've fixed a few things that /might/ apply to your issue. Where can I find the latest rc3? I thought I used the latest available, at least at http://kernel.ubuntu.com/~kernel-ppa/mainline/ Please _always_ group reply when answering, since otherwise ppl and mailing lists will not get this ... Dunno which ppa you need to use to get -rc3, but generally it's much more useful if you can compile your own kernels from sources if you report a bug upstream. Otherwise we can't let you test patches, which makes you as a bug reporter for upstream not too useful. Thanks, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/58] drm/i915: add crtc-enable/disable vfuncs insted of dpms
On Sun, 19 Aug 2012 21:12:18 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Because that's what we're essentially calling. This is the first step
in untangling the crtc_helper induced dpms handling mess we have - at
the crtc level we only have 2 states and the magic is just in
selecting which one (and atm there isn't even much magic, but on
recent platforms where not even the crt output has more than 2 states
we could do better).
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_display.c | 62
+++- 2 files changed, 20
insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index ed3ba70..fb46c6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -240,7 +240,6 @@ struct drm_i915_error_state {
};
struct drm_i915_display_funcs {
- void (*dpms)(struct drm_crtc *crtc, int mode);
bool (*fbc_enabled)(struct drm_device *dev);
void (*enable_fbc)(struct drm_crtc *crtc, unsigned long
interval); void (*disable_fbc)(struct drm_device *dev);
@@ -256,6 +255,8 @@ struct drm_i915_display_funcs {
struct drm_display_mode *adjusted_mode,
int x, int y,
struct drm_framebuffer *old_fb);
+ void (*crtc_enable)(struct drm_crtc *crtc);
+ void (*crtc_disable)(struct drm_crtc *crtc);
void (*off)(struct drm_crtc *crtc);
void (*write_eld)(struct drm_connector *connector,
struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c index 42c5758..adc9868 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3342,30 +3342,6 @@ static void ironlake_crtc_disable(struct
drm_crtc *crtc) mutex_unlock(dev-struct_mutex);
}
-static void ironlake_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int pipe = intel_crtc-pipe;
- int plane = intel_crtc-plane;
-
- /* XXX: When our outputs are all unaware of DPMS modes other
than off
- * and on, we should map those modes to DRM_MODE_DPMS_OFF in
the CRTC.
- */
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- case DRM_MODE_DPMS_STANDBY:
- case DRM_MODE_DPMS_SUSPEND:
- DRM_DEBUG_KMS(crtc %d/%d dpms on\n, pipe, plane);
- ironlake_crtc_enable(crtc);
- break;
-
- case DRM_MODE_DPMS_OFF:
- DRM_DEBUG_KMS(crtc %d/%d dpms off\n, pipe, plane);
- ironlake_crtc_disable(crtc);
- break;
- }
-}
-
static void ironlake_crtc_off(struct drm_crtc *crtc)
{
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -3445,23 +3421,6 @@ static void i9xx_crtc_disable(struct drm_crtc
*crtc) intel_update_watermarks(dev);
}
-static void i9xx_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
- /* XXX: When our outputs are all unaware of DPMS modes other
than off
- * and on, we should map those modes to DRM_MODE_DPMS_OFF in
the CRTC.
- */
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- case DRM_MODE_DPMS_STANDBY:
- case DRM_MODE_DPMS_SUSPEND:
- i9xx_crtc_enable(crtc);
- break;
- case DRM_MODE_DPMS_OFF:
- i9xx_crtc_disable(crtc);
- break;
- }
-}
-
static void i9xx_crtc_off(struct drm_crtc *crtc)
{
}
@@ -3483,7 +3442,20 @@ static void intel_crtc_dpms(struct drm_crtc
*crtc, int mode)
intel_crtc-dpms_mode = mode;
- dev_priv-display.dpms(crtc, mode);
+ /* XXX: When our outputs are all unaware of DPMS modes other
than off
+ * and on, we should map those modes to DRM_MODE_DPMS_OFF in
the CRTC.
+ */
+ switch (mode) {
+ case DRM_MODE_DPMS_ON:
+ case DRM_MODE_DPMS_STANDBY:
+ case DRM_MODE_DPMS_SUSPEND:
+ dev_priv-display.crtc_enable(crtc);
+ break;
+
+ case DRM_MODE_DPMS_OFF:
+ dev_priv-display.crtc_disable(crtc);
+ break;
+ }
if (!dev-primary-master)
return;
@@ -6971,13 +6943,15 @@ static void intel_init_display(struct
drm_device *dev)
/* We always want a DPMS function */
if (HAS_PCH_SPLIT(dev)) {
- dev_priv-display.dpms = ironlake_crtc_dpms;
dev_priv-display.crtc_mode_set =
ironlake_crtc_mode_set;
+ dev_priv-display.crtc_enable = ironlake_crtc_enable;
+ dev_priv-display.crtc_disable =
ironlake_crtc_disable; dev_priv-display.off = ironlake_crtc_off;
dev_priv-display.update_plane =
ironlake_update_plane; } else {
- dev_priv-display.dpms = i9xx_crtc_dpms;
dev_priv-display.crtc_mode_set =
Re: [Intel-gfx] [PATCH 08/76] drm/i915: extract ironlake_fdi_pll_disable
On Thu, 26 Jul 2012 20:48:33 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Simply to make the ilk+ crtc disable path clearer and more symmetric
with the enable function.
Also switch to intel_crtc for the enable function.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 57
-- 1 file changed, 33 insertions(+),
24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c index 7224055..1d5a811 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2708,11 +2708,10 @@ static void ivb_manual_fdi_link_train(struct
drm_crtc *crtc) DRM_DEBUG_KMS(FDI train done.\n);
}
-static void ironlake_fdi_pll_enable(struct drm_crtc *crtc)
+static void ironlake_fdi_pll_enable(struct intel_crtc *intel_crtc)
{
- struct drm_device *dev = crtc-dev;
+ struct drm_device *dev = intel_crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc-pipe;
u32 reg, temp;
@@ -2753,6 +2752,35 @@ static void ironlake_fdi_pll_enable(struct
drm_crtc *crtc) }
}
+static void ironlake_fdi_pll_disable(struct intel_crtc *intel_crtc)
+{
+ struct drm_device *dev = intel_crtc-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int pipe = intel_crtc-pipe;
+ u32 reg, temp;
+
+ /* Switch from PCDclk to Rawclk */
+ reg = FDI_RX_CTL(pipe);
+ temp = I915_READ(reg);
+ I915_WRITE(reg, temp ~FDI_PCDCLK);
+
+ /* Disable CPU FDI TX PLL */
+ reg = FDI_TX_CTL(pipe);
+ temp = I915_READ(reg);
+ I915_WRITE(reg, temp ~FDI_TX_PLL_ENABLE);
+
+ POSTING_READ(reg);
+ udelay(100);
+
+ reg = FDI_RX_CTL(pipe);
+ temp = I915_READ(reg);
+ I915_WRITE(reg, temp ~FDI_RX_PLL_ENABLE);
+
+ /* Wait for the clocks to turn off. */
+ POSTING_READ(reg);
+ udelay(100);
+}
+
static void cpt_phase_pointer_disable(struct drm_device *dev, int
pipe) {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3200,7 +3228,7 @@ static void ironlake_crtc_enable(struct
drm_crtc *crtc) is_pch_port = intel_crtc_driving_pch(crtc);
if (is_pch_port)
- ironlake_fdi_pll_enable(crtc);
+ ironlake_fdi_pll_enable(intel_crtc);
else
ironlake_fdi_disable(crtc);
@@ -3303,26 +3331,7 @@ static void ironlake_crtc_disable(struct
drm_crtc *crtc) /* disable PCH DPLL */
intel_disable_pch_pll(intel_crtc);
- /* Switch from PCDclk to Rawclk */
- reg = FDI_RX_CTL(pipe);
- temp = I915_READ(reg);
- I915_WRITE(reg, temp ~FDI_PCDCLK);
-
- /* Disable CPU FDI TX PLL */
- reg = FDI_TX_CTL(pipe);
- temp = I915_READ(reg);
- I915_WRITE(reg, temp ~FDI_TX_PLL_ENABLE);
-
- POSTING_READ(reg);
- udelay(100);
-
- reg = FDI_RX_CTL(pipe);
- temp = I915_READ(reg);
- I915_WRITE(reg, temp ~FDI_RX_PLL_ENABLE);
-
- /* Wait for the clocks to turn off. */
- POSTING_READ(reg);
- udelay(100);
+ ironlake_fdi_pll_disable(intel_crtc);
intel_crtc-active = false;
intel_update_watermarks(dev);
Looks good.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/58] drm/i915: add direct encoder disable/enable infrastructure
On Sun, 19 Aug 2012 21:12:20 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Just prep work, not yet put to some use.
Note that because we're still using the crtc helper to switch modes
(and their complicated way to do partial modesets), we need to call
the encoder's disable function unconditionally.
But once this is cleaned up we shouldn't call the encoder's disable
function unconditionally any more, because then we know that we'll
only call it if the encoder is actually enabled. Also note that we
then need to be careful about which crtc we're filtering the encoder
list on: We want to filter on the crtc of the _current_ mode, not the
one we're about to set up.
For the enabling side we need to do the same trick. And again, we
should be able to simplify this quite a bit when things have settled
into place.
Also note that this simply does not take cloning into account, so dpms
needs to be handled specially for the few outputs where we even bother
with it.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 38
++--
drivers/gpu/drm/i915/intel_drv.h | 2 ++ 2 files changed, 38
insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c index 04bec4b..82aaded 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3209,13 +3209,16 @@ static void ironlake_crtc_enable(struct
drm_crtc *crtc) struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_encoder *encoder;
int pipe = intel_crtc-pipe;
int plane = intel_crtc-plane;
u32 temp;
bool is_pch_port;
+ /* XXX: For compatability with the crtc helper code, call
the encoder's
+ * enable function unconditionally for now. */
if (intel_crtc-active)
- return;
+ goto encoders;
intel_crtc-active = true;
intel_update_watermarks(dev);
@@ -3262,6 +3265,12 @@ static void ironlake_crtc_enable(struct
drm_crtc *crtc) mutex_unlock(dev-struct_mutex);
intel_crtc_update_cursor(crtc, true);
+
+encoders:
+ for_each_encoder_on_crtc(dev, crtc, encoder) {
+ if (encoder-enable)
+ encoder-enable(encoder);
+ }
}
static void ironlake_crtc_disable(struct drm_crtc *crtc)
@@ -3269,10 +3278,18 @@ static void ironlake_crtc_disable(struct
drm_crtc *crtc) struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_encoder *encoder;
int pipe = intel_crtc-pipe;
int plane = intel_crtc-plane;
u32 reg, temp;
+ /* XXX: For compatability with the crtc helper code, call
the encoder's
+ * disable function unconditionally for now. */
+ for_each_encoder_on_crtc(dev, crtc, encoder) {
+ if (encoder-disable)
+ encoder-disable(encoder);
+ }
+
if (!intel_crtc-active)
return;
@@ -3371,11 +3388,14 @@ static void i9xx_crtc_enable(struct drm_crtc
*crtc) struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_encoder *encoder;
int pipe = intel_crtc-pipe;
int plane = intel_crtc-plane;
+ /* XXX: For compatability with the crtc helper code, call
the encoder's
+ * enable function unconditionally for now. */
if (intel_crtc-active)
- return;
+ goto encoders;
intel_crtc-active = true;
intel_update_watermarks(dev);
@@ -3390,6 +3410,12 @@ static void i9xx_crtc_enable(struct drm_crtc
*crtc) /* Give the overlay scaler a chance to enable if it's on this
pipe */ intel_crtc_dpms_overlay(intel_crtc, true);
intel_crtc_update_cursor(crtc, true);
+
+encoders:
+ for_each_encoder_on_crtc(dev, crtc, encoder) {
+ if (encoder-enable)
+ encoder-enable(encoder);
+ }
}
static void i9xx_crtc_disable(struct drm_crtc *crtc)
@@ -3397,9 +3423,17 @@ static void i9xx_crtc_disable(struct drm_crtc
*crtc) struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_encoder *encoder;
int pipe = intel_crtc-pipe;
int plane = intel_crtc-plane;
+ /* XXX: For compatability with the crtc helper code, call
the encoder's
+ * disable function unconditionally for now. */
+ for_each_encoder_on_crtc(dev, crtc, encoder) {
+ if (encoder-disable)
+ encoder-disable(encoder);
+ }
+
if (!intel_crtc-active)
Re: [Intel-gfx] [PATCH 02/58] drm/i915: rip out crtc prepare/commit indirection
On Sun, 19 Aug 2012 21:12:19 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Just impendance matching with the the crtc helper stuff.
... and somehow the design of this all ended up in this commit here,
too ;-)
The big plan is that this new set of crtc display_funcs take full
responsibility of modeset operations for the entire display output
pipeline (by calling down into object-specific callbacks and
functions). The platform-specific callbacks simply know best what the
proper order is.
This has the drawback that we can't do minimal change-overs any more
if a modeset just disables one encoder in a cloned configuration
(because we will only expose a disable/enable action that takes
down/sets up the entire crtc including all encoders). Imo that's the
only sane way to do it though:
- The use-case for this is pretty minimal, even when presenting (at
least sane people) should use a dual-screen output so that you can
see your notes on your panel. Clone mode is imo BS.
- With all the clone mode constrains, shared resources, and special
ordering requirements (which differ even on the same platform
sometimes for different outputs) there's no way we'd get this right
for all cases. Especially since this is a under-used feature.
- And to top it off: On haswell even dp link re-training requires us
to take down the entire display pipe - otherwise the chip dies.
So the only sane way is to do a full modeset on every crtc where the
output config changes in any way.
To support global modeset (i.e. set the configuration for all crtcs at
once) we'd then add one more function to allocate global and shared
objects in the best ways (e.g. fdi links, pch plls, ...). The crtc
functions would then simply use the pre-allocated stuff (and shouldn't
be able to fail, ever). We could even do all the object pinning in
there (and maybe try to defragment the global gtt if we fail)!
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 37
++-- 1 file changed, 2 insertions(+),
35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c index adc9868..04bec4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3500,34 +3500,6 @@ static void intel_crtc_disable(struct drm_crtc
*crtc) }
}
-/* Prepare for a mode set.
- *
- * Note we could be a lot smarter here. We need to figure out which
outputs
- * will be enabled, which disabled (in short, how the config will
changes)
- * and perform the minimum necessary steps to accomplish that, e.g.
updating
- * watermarks, FBC configuration, making sure PLLs are programmed
correctly,
- * panel fitting is in the proper state, etc.
- */
-static void i9xx_crtc_prepare(struct drm_crtc *crtc)
-{
- i9xx_crtc_disable(crtc);
-}
-
-static void i9xx_crtc_commit(struct drm_crtc *crtc)
-{
- i9xx_crtc_enable(crtc);
-}
-
-static void ironlake_crtc_prepare(struct drm_crtc *crtc)
-{
- ironlake_crtc_disable(crtc);
-}
-
-static void ironlake_crtc_commit(struct drm_crtc *crtc)
-{
- ironlake_crtc_enable(crtc);
-}
-
void intel_encoder_prepare(struct drm_encoder *encoder)
{
struct drm_encoder_helper_funcs *encoder_funcs =
encoder-helper_private; @@ -6626,13 +6598,8 @@ static void
intel_crtc_init(struct drm_device *dev, int pipe) intel_crtc-active
= true; /* force the pipe off on setup_init_config */ intel_crtc-bpp
= 24; /* default for pre-Ironlake */
- if (HAS_PCH_SPLIT(dev)) {
- intel_helper_funcs.prepare = ironlake_crtc_prepare;
- intel_helper_funcs.commit = ironlake_crtc_commit;
- } else {
- intel_helper_funcs.prepare = i9xx_crtc_prepare;
- intel_helper_funcs.commit = i9xx_crtc_commit;
- }
+ intel_helper_funcs.prepare = dev_priv-display.crtc_disable;
+ intel_helper_funcs.commit = dev_priv-display.crtc_enable;
drm_crtc_helper_add(intel_crtc-base, intel_helper_funcs);
}
Looks fine.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: no longer call drm_helper_resume_force_mode
Since this only calls crtc helper functions, of which a shocking amount are NULL. Now the curious thing is how the new modeset code worked with this function call still present: Thanks to the hw state readout and the suspend fixes to properly quiescent the register state, nothing is actually enabled at resume (if the bios doesn't set up anything). Which means resume_force_mode doesn't actually do anything and hence nothing blows up at resume time. The other reason things do work is that the fbcon layer has it's own resume notifier callback, which restores the mode. And thanks to the force vt switch at suspend/resume, that then forces X to restore it's own mode. Hence everything still worked (as long as the bios doesn't enable anything). And we can just kill the call to resume_force_mode. The upside of both this patch and the preceeding patch to quiescent the modeset state is that our resume path is much simpler: - We now longer restore bogus register values (which most often would enable the backlight a bit and a few ports), causing flickering. - We now longer call resume_force_mode to restore a mode that the fbcon layer would overwrite right away anyway. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_drv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index fe7512a..cd6697c 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -549,11 +549,6 @@ static int i915_drm_thaw(struct drm_device *dev) intel_modeset_setup_hw_state(dev); drm_mode_config_reset(dev); drm_irq_install(dev); - - /* Resume the modeset for every activated CRTC */ - mutex_lock(dev-mode_config.mutex); - drm_helper_resume_force_mode(dev); - mutex_unlock(dev-mode_config.mutex); } intel_opregion_init(dev); -- 1.7.11.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/edp: get the panel delay before powering up
In order to setup the i2c channel, we power up the panel
via ironlake_edp_panel_vdd_on, however it requires
intel_dp-panel_power_up_delay to be initialised,
which hasn't been setup yet.
So move things around so we set the panel power up
values first then init the i2c stuff.
This is one step to fixing the eDP panel in the MBP
from uninitialised state.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a6c426a..ace757a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2533,14 +2533,10 @@ intel_dp_init(struct drm_device *dev, int output_reg)
break;
}
- intel_dp_i2c_init(intel_dp, intel_connector, name);
-
/* Cache some DPCD data in the eDP case */
if (is_edp(intel_dp)) {
- bool ret;
struct edp_power_seqcur, vbt;
u32 pp_on, pp_off, pp_div;
- struct edid *edid;
pp_on = I915_READ(PCH_PP_ON_DELAYS);
pp_off = I915_READ(PCH_PP_OFF_DELAYS);
@@ -2591,6 +2587,13 @@ intel_dp_init(struct drm_device *dev, int output_reg)
DRM_DEBUG_KMS(backlight on delay %d, off delay %d\n,
intel_dp-backlight_on_delay,
intel_dp-backlight_off_delay);
+ }
+
+ intel_dp_i2c_init(intel_dp, intel_connector, name);
+
+ if (is_edp(intel_dp)) {
+ bool ret;
+ struct edid *edid;
ironlake_edp_panel_vdd_on(intel_dp);
ret = intel_dp_get_dpcd(intel_dp);
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
