Re: [Intel-gfx] [PATCH] i915: Fix bug where screen brightness is not restored
At Tue, 15 Nov 2011 13:54:44 -0800,
Kamal Mostafa wrote:
On Tue, 2011-11-15 at 21:28 +0100, Takashi Iwai wrote:
My rough guess is the inconsistency of property taken during the
backlight disabled. How about the patch below (untested!) in addition
to the fix in 3.2?
Takashi
Yes Takashi, your patch below (plus the already committed fix[0]) does
indeed fix the problem[1] for me. Thanks!
Tested-by: Kamal Mostafa ka...@canonical.com
OK, I'll resend the patch with proper sign-off, etc.
thanks,
Takashi
-Kamal
[0] f52c619a590fa75276c07dfcaf380dee53e4ea4c
drm/i915/panel: Always record the backlight level again (but cleverly)
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 499d4c0..21f60b7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -326,7 +326,8 @@ static int intel_panel_update_status(struct
backlight_device *bd)
static int intel_panel_get_brightness(struct backlight_device *bd)
{
struct drm_device *dev = bl_get_data(bd);
- return intel_panel_get_backlight(dev);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ return dev_priv-backlight_level;
}
static const struct backlight_ops intel_panel_bl_ops = {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix inconsistent backlight level during disabled
When the brightness property is inquired while the backlight is disabled,
the driver returns a wrong value (zero) because it probes the value after
the backlight was turned off. This caused a black screen even after the
backlight is enabled again. It should return the internal backlight_level
instead, so that it won't be influenced by the backlight-enable state.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=41926
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652
Tested-by: Kamal Mostafa ka...@canonical.com
Cc: Alex Davis alex14...@yahoo.com
Cc: sta...@kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/i915/intel_panel.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 499d4c0..21f60b7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -326,7 +326,8 @@ static int intel_panel_update_status(struct
backlight_device *bd)
static int intel_panel_get_brightness(struct backlight_device *bd)
{
struct drm_device *dev = bl_get_data(bd);
- return intel_panel_get_backlight(dev);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ return dev_priv-backlight_level;
}
static const struct backlight_ops intel_panel_bl_ops = {
--
1.7.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2 v2] hda - delayed ELD repoll
Dear Fengguang,
Am Mittwoch, den 16.11.2011, 00:57 +0800 schrieb Wu Fengguang:
The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
actually readable. During the time the ELD buffer is mysteriously all 0.
Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
Signed-off-by: Wu Fengguang fengguang...@intel.com
other then my comment at the end, please note that it is very confusing
for European (and other folks) what your first name is.
If it is Fengguang then you should use
Fengguang Wu or Wu, Fengguang
where I prefer the first one.
---
sound/pci/hda/hda_local.h |2 +
sound/pci/hda/patch_hdmi.c | 49 ++-
2 files changed, 44 insertions(+), 7 deletions(-)
--- linux.orig/sound/pci/hda/hda_local.h 2011-11-15 21:29:53.0
+0800
+++ linux/sound/pci/hda/hda_local.h 2011-11-15 21:29:54.0 +0800
@@ -655,6 +655,8 @@ struct hdmi_eld {
#ifdef CONFIG_PROC_FS
struct snd_info_entry *proc_entry;
#endif
+ struct hda_codec *codec;
+ struct delayed_work work;
};
int snd_hdmi_get_eld_size(struct hda_codec *codec, hda_nid_t nid);
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-15 21:29:53.0
+0800
+++ linux/sound/pci/hda/patch_hdmi.c 2011-11-16 00:50:50.0 +0800
@@ -746,7 +746,7 @@ static void hdmi_setup_audio_infoframe(s
*/
static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
-struct hdmi_eld *eld);
+struct hdmi_eld *eld, bool retry);
static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
{
@@ -766,7 +766,7 @@ static void hdmi_intrinsic_event(struct
return;
eld = spec-pins[pin_idx].sink_eld;
- hdmi_present_sense(codec, pin_nid, eld);
+ hdmi_present_sense(codec, pin_nid, eld, true);
/*
* HDMI sink's ELD info cannot always be retrieved for now, e.g.
@@ -969,7 +969,7 @@ static int hdmi_read_pin_conn(struct hda
}
static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
-struct hdmi_eld *eld)
+struct hdmi_eld *eld, bool retry)
{
/*
* Always execute a GetPinSense verb here, even when called from
@@ -992,13 +992,31 @@ static void hdmi_present_sense(struct hd
HDMI status: Codec=%d Pin=%d Presence_Detect=%d
ELD_Valid=%d\n,
codec-addr, pin_nid, eld-monitor_present, eld_valid);
- if (eld_valid)
+ if (eld_valid) {
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
+ else if (retry) {
+ queue_delayed_work(codec-bus-workq,
+eld-work,
+msecs_to_jiffies(300));
+ }
Would adding a comment referring to the discussion thread be beneficial
for code readers asking why a delay is needed?
+ }
snd_hda_input_jack_report(codec, pin_nid);
}
[…]
Thanks,
Paul
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 v3] drm/i915: Honor SSC quirk table over the default, unless set by user
Hi Keith, That patch is still not in 3.2-rc2, drm-intel-fixes or drm-intel-next. I've been using it successfully on i915 (both SSC-blacklisted and not) and non-i915 machines; feel free to set the Tested-by and Reviewed-by tags. Thanks, -- Michel On 11/09/2011 07:07 PM, Keith Packard wrote: On Wed, 09 Nov 2011 17:30:29 +0100, Michel Alexandre Salim sali...@fedoraproject.org wrote: Additional note: while I've not touched the line since it does not affect me, it seems that i915_panel_use_ssc *cannot* be less than 0 since that variable is declared as unsigned. Oops. That's the bug here -- we're supposed to make it so that the command line can override the quirks, but there's no way to use a quirk given the mis-declared parameter. This is untested... From e64ecadef40e3c2035cd4e9b967ffd83489bdea0 Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Wed, 9 Nov 2011 09:57:50 -0800 Subject: [PATCH] drm/i915: Module parameters using '-1' as default must be signed type Testing i915_panel_use_ssc for the default value was broken, so the driver would never autodetect the correct value. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_drv.c |4 ++-- drivers/gpu/drm/i915/i915_drv.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 548e04b..13488be 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -67,7 +67,7 @@ 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)); -unsigned int i915_enable_fbc __read_mostly = -1; +int i915_enable_fbc __read_mostly = -1; module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600); MODULE_PARM_DESC(i915_enable_fbc, Enable frame buffer compression for power savings @@ -79,7 +79,7 @@ MODULE_PARM_DESC(lvds_downclock, Use panel (LVDS/eDP) downclocking for power savings (default: false)); -unsigned int i915_panel_use_ssc __read_mostly = -1; +int i915_panel_use_ssc __read_mostly = -1; module_param_named(lvds_use_ssc, i915_panel_use_ssc, int, 0600); MODULE_PARM_DESC(lvds_use_ssc, Use Spread Spectrum Clock with panels [LVDS/eDP] diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index d2da91f..4a9c1b9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1000,10 +1000,10 @@ extern int i915_panel_ignore_lid __read_mostly; extern unsigned int i915_powersave __read_mostly; extern unsigned int i915_semaphores __read_mostly; extern unsigned int i915_lvds_downclock __read_mostly; -extern unsigned int i915_panel_use_ssc __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 unsigned int i915_enable_fbc __read_mostly; +extern int i915_enable_fbc __read_mostly; extern bool i915_enable_hangcheck __read_mostly; extern int i915_suspend(struct drm_device *dev, pm_message_t state); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Michel Alexandre Salim µblog: http://identi.ca/hircus http://twitter.com/hircus GPG key ID: 78884778 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] HDMI ELD fixes for 3.2
Keith, Here are 3 fixes on HDMI/ELD audio. The third one adds a -hot_remove hook to drm_connector_funcs. Please review. [PATCH 1/3] drm/i915: fix ELD writing for SandyBridge [PATCH 2/3] drm/i915: dont trigger hotplug events on unchanged ELD [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: dont trigger hotplug events on unchanged ELD
The ELD may or may not change when switching the video mode.
If unchanged, don't trigger hot plug events to HDMI audio driver.
This avoids disturbing the user with repeated printks.
Reported-by: Nick Bowler nbow...@elliptictech.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 51 ++---
1 file changed, 46 insertions(+), 5 deletions(-)
--- linux.orig/drivers/gpu/drm/i915/intel_display.c 2011-11-10
17:23:04.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_display.c 2011-11-10 17:59:25.0
+0800
@@ -5811,6 +5811,35 @@ static int intel_crtc_mode_set(struct dr
return ret;
}
+static bool intel_eld_uptodate(struct drm_connector *connector,
+ int reg_eldv, uint32_t bits_eldv,
+ int reg_elda, uint32_t bits_elda,
+ int reg_edid)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ uint32_t i;
+
+ i = I915_READ(reg_eldv);
+ i = bits_eldv;
+
+ if (!eld[0])
+ return !i;
+
+ if (!i)
+ return false;
+
+ i = I915_READ(reg_elda);
+ i = ~bits_elda;
+ I915_WRITE(reg_elda, i);
+
+ for (i = 0; i eld[2]; i++)
+ if (I915_READ(reg_edid) != *((uint32_t *)eld + i))
+ return false;
+
+ return true;
+}
+
static void g4x_write_eld(struct drm_connector *connector,
struct drm_crtc *crtc)
{
@@ -5827,6 +5856,12 @@ static void g4x_write_eld(struct drm_con
else
eldv = G4X_ELDV_DEVCTG;
+ if (intel_eld_uptodate(connector,
+ G4X_AUD_CNTL_ST, eldv,
+ G4X_AUD_CNTL_ST, G4X_ELD_ADDR,
+ G4X_HDMIW_HDMIEDID))
+ return;
+
i = I915_READ(G4X_AUD_CNTL_ST);
i = ~(eldv | G4X_ELD_ADDR);
len = (i 9) 0x1f; /* ELD buffer size */
@@ -5886,6 +5921,17 @@ static void ironlake_write_eld(struct dr
eldv = GEN5_ELD_VALIDB ((i - 1) * 4);
}
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+ DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
+ eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
+ }
+
+ if (intel_eld_uptodate(connector,
+ aud_cntrl_st2, eldv,
+ aud_cntl_st, GEN5_ELD_ADDRESS,
+ hdmiw_hdmiedid))
+ return;
+
i = I915_READ(aud_cntrl_st2);
i = ~eldv;
I915_WRITE(aud_cntrl_st2, i);
@@ -5893,11 +5939,6 @@ static void ironlake_write_eld(struct dr
if (!eld[0])
return;
- if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
- DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
- eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
- }
-
i = I915_READ(aud_cntl_st);
i = ~GEN5_ELD_ADDRESS;
I915_WRITE(aud_cntl_st, i);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: fix ELD writing for SandyBridge
SandyBridge should be using the same register addresses as IvyBridge.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |6 +++---
drivers/gpu/drm/i915/intel_display.c | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
--- linux.orig/drivers/gpu/drm/i915/i915_reg.h 2011-11-09 13:17:19.0
+0800
+++ linux/drivers/gpu/drm/i915/i915_reg.h 2011-11-09 13:18:39.0
+0800
@@ -3543,8 +3543,8 @@
#define GEN5_ELD_VALIDB(1 0)
#define GEN5_CP_READYB (1 1)
-#define GEN7_HDMIW_HDMIEDID_A 0xE5050
-#define GEN7_AUD_CNTRL_ST_A0xE50B4
-#define GEN7_AUD_CNTRL_ST2 0xE50C0
+#define GEN6_HDMIW_HDMIEDID_A 0xE5050
+#define GEN6_AUD_CNTL_ST_A 0xE50B4
+#define GEN6_AUD_CNTRL_ST2 0xE50C0
#endif /* _I915_REG_H_ */
--- linux.orig/drivers/gpu/drm/i915/intel_display.c 2011-11-09
13:19:28.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_display.c 2011-11-09 13:20:02.0
+0800
@@ -5857,14 +5857,14 @@ static void ironlake_write_eld(struct dr
int aud_cntl_st;
int aud_cntrl_st2;
- if (IS_IVYBRIDGE(connector-dev)) {
- hdmiw_hdmiedid = GEN7_HDMIW_HDMIEDID_A;
- aud_cntl_st = GEN7_AUD_CNTRL_ST_A;
- aud_cntrl_st2 = GEN7_AUD_CNTRL_ST2;
- } else {
+ if (IS_GEN5(connector-dev)) {
hdmiw_hdmiedid = GEN5_HDMIW_HDMIEDID_A;
aud_cntl_st = GEN5_AUD_CNTL_ST_A;
aud_cntrl_st2 = GEN5_AUD_CNTL_ST2;
+ } else {
+ hdmiw_hdmiedid = GEN6_HDMIW_HDMIEDID_A;
+ aud_cntl_st = GEN6_AUD_CNTL_ST_A;
+ aud_cntrl_st2 = GEN6_AUD_CNTRL_ST2;
}
i = to_intel_crtc(crtc)-pipe;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver
On monitor hot removal:
1) clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE
2) clear ELD Valid bit
So that the audio driver will receive hot plug events and take action to
refresh its device state and ELD contents.
cc: Wang Zhenyu zhenyu.z.w...@intel.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/drm_crtc_helper.c |4
drivers/gpu/drm/i915/intel_dp.c | 17 +
drivers/gpu/drm/i915/intel_drv.h |4
drivers/gpu/drm/i915/intel_hdmi.c | 17 +
include/drm/drm_crtc.h|1 +
5 files changed, 43 insertions(+)
--- linux.orig/drivers/gpu/drm/i915/intel_dp.c 2011-11-16 20:54:28.0
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c 2011-11-16 21:19:42.0
+0800
@@ -1984,6 +1984,22 @@ intel_dp_detect(struct drm_connector *co
return connector_status_connected;
}
+static void intel_dp_hot_remove(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_device *dev = intel_dp-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = intel_dp-base.base.crtc;
+
+ intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+
+ connector-eld[0] = 0;
+ if (dev_priv-display.write_eld)
+ dev_priv-display.write_eld(connector, crtc);
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2159,7 @@ static const struct drm_connector_funcs
.detect = intel_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_dp_set_property,
+ .hot_remove = intel_dp_hot_remove,
.destroy = intel_dp_destroy,
};
--- linux.orig/drivers/gpu/drm/i915/intel_drv.h 2011-11-16 20:54:27.0
+0800
+++ linux/drivers/gpu/drm/i915/intel_drv.h 2011-11-16 21:19:42.0
+0800
@@ -382,6 +382,10 @@ extern void intel_fb_restore_mode(struct
extern void intel_init_clock_gating(struct drm_device *dev);
extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
+extern void intel_hotplug_status(struct drm_device *dev,
+ struct drm_connector *connector,
+ struct drm_crtc *crtc,
+ enum drm_connector_status status);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
#endif /* __INTEL_DRV_H__ */
--- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-11-16
20:55:13.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2011-11-16 21:19:42.0
+0800
@@ -350,6 +350,22 @@ intel_hdmi_detect(struct drm_connector *
return status;
}
+static void intel_hdmi_hot_remove(struct drm_connector *connector)
+{
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ u32 temp;
+
+ temp = I915_READ(intel_hdmi-sdvox_reg);
+ I915_WRITE(intel_hdmi-sdvox_reg, temp ~SDVO_AUDIO_ENABLE);
+ POSTING_READ(intel_hdmi-sdvox_reg);
+
+ connector-eld[0] = 0;
+ if (dev_priv-display.write_eld)
+ dev_priv-display.write_eld(connector,
+ intel_hdmi-base.base.crtc);
+}
+
static int intel_hdmi_get_modes(struct drm_connector *connector)
{
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
@@ -459,6 +475,7 @@ static const struct drm_connector_funcs
.detect = intel_hdmi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_hdmi_set_property,
+ .hot_remove = intel_hdmi_hot_remove,
.destroy = intel_hdmi_destroy,
};
--- linux.orig/drivers/gpu/drm/drm_crtc_helper.c2011-11-16
20:55:13.0 +0800
+++ linux/drivers/gpu/drm/drm_crtc_helper.c 2011-11-16 21:19:42.0
+0800
@@ -905,6 +905,10 @@ static void output_poll_execute(struct w
old_status, connector-status);
if (old_status != connector-status)
changed = true;
+ if (old_status == connector_status_connected
+ connector-status == connector_status_disconnected)
+ connector-funcs-hot_remove(connector);
+
}
mutex_unlock(dev-mode_config.mutex);
--- linux.orig/include/drm/drm_crtc.h 2011-11-16 20:54:28.0 +0800
+++ linux/include/drm/drm_crtc.h2011-11-16 21:19:42.0 +0800
@@ -419,6 +419,7 @@ struct drm_connector_funcs {
int (*fill_modes)(struct drm_connector *connector, uint32_t max_width,
uint32_t max_height);
int (*set_property)(struct drm_connector *connector, struct
drm_property
Re: [Intel-gfx] [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver
Sorry forgot to remove this left over chunk... Note that I've not yet got the hardware to test the DisplayPort part of this patch, but should be able to do so this week. --- linux.orig/drivers/gpu/drm/i915/intel_drv.h 2011-11-16 20:54:27.0 +0800 +++ linux/drivers/gpu/drm/i915/intel_drv.h2011-11-16 21:19:42.0 +0800 @@ -382,6 +382,10 @@ extern void intel_fb_restore_mode(struct extern void intel_init_clock_gating(struct drm_device *dev); extern void intel_write_eld(struct drm_encoder *encoder, struct drm_display_mode *mode); +extern void intel_hotplug_status(struct drm_device *dev, + struct drm_connector *connector, + struct drm_crtc *crtc, + enum drm_connector_status status); extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe); #endif /* __INTEL_DRV_H__ */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3 v2] drm/i915: hot removal notification to HDMI audio driver
On monitor hot removal:
1) clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE
2) clear ELD Valid bit
So that the audio driver will receive hot plug events and take action to
refresh its device state and ELD contents.
cc: Wang Zhenyu zhenyu.z.w...@intel.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/drm_crtc_helper.c |4
drivers/gpu/drm/i915/intel_dp.c | 17 +
drivers/gpu/drm/i915/intel_hdmi.c | 17 +
include/drm/drm_crtc.h|1 +
4 files changed, 39 insertions(+)
--- linux.orig/drivers/gpu/drm/i915/intel_dp.c 2011-11-16 21:36:58.0
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c 2011-11-16 21:37:00.0
+0800
@@ -1984,6 +1984,22 @@ intel_dp_detect(struct drm_connector *co
return connector_status_connected;
}
+static void intel_dp_hot_remove(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_device *dev = intel_dp-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = intel_dp-base.base.crtc;
+
+ intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+
+ connector-eld[0] = 0;
+ if (dev_priv-display.write_eld)
+ dev_priv-display.write_eld(connector, crtc);
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2159,7 @@ static const struct drm_connector_funcs
.detect = intel_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_dp_set_property,
+ .hot_remove = intel_dp_hot_remove,
.destroy = intel_dp_destroy,
};
--- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-11-16
21:36:58.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2011-11-16 21:37:00.0
+0800
@@ -350,6 +350,22 @@ intel_hdmi_detect(struct drm_connector *
return status;
}
+static void intel_hdmi_hot_remove(struct drm_connector *connector)
+{
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ u32 temp;
+
+ temp = I915_READ(intel_hdmi-sdvox_reg);
+ I915_WRITE(intel_hdmi-sdvox_reg, temp ~SDVO_AUDIO_ENABLE);
+ POSTING_READ(intel_hdmi-sdvox_reg);
+
+ connector-eld[0] = 0;
+ if (dev_priv-display.write_eld)
+ dev_priv-display.write_eld(connector,
+ intel_hdmi-base.base.crtc);
+}
+
static int intel_hdmi_get_modes(struct drm_connector *connector)
{
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
@@ -459,6 +475,7 @@ static const struct drm_connector_funcs
.detect = intel_hdmi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_hdmi_set_property,
+ .hot_remove = intel_hdmi_hot_remove,
.destroy = intel_hdmi_destroy,
};
--- linux.orig/drivers/gpu/drm/drm_crtc_helper.c2011-11-16
21:36:58.0 +0800
+++ linux/drivers/gpu/drm/drm_crtc_helper.c 2011-11-16 21:37:00.0
+0800
@@ -905,6 +905,10 @@ static void output_poll_execute(struct w
old_status, connector-status);
if (old_status != connector-status)
changed = true;
+ if (old_status == connector_status_connected
+ connector-status == connector_status_disconnected)
+ connector-funcs-hot_remove(connector);
+
}
mutex_unlock(dev-mode_config.mutex);
--- linux.orig/include/drm/drm_crtc.h 2011-11-16 21:36:58.0 +0800
+++ linux/include/drm/drm_crtc.h2011-11-16 21:37:00.0 +0800
@@ -419,6 +419,7 @@ struct drm_connector_funcs {
int (*fill_modes)(struct drm_connector *connector, uint32_t max_width,
uint32_t max_height);
int (*set_property)(struct drm_connector *connector, struct
drm_property *property,
uint64_t val);
+ void (*hot_remove)(struct drm_connector *connector);
void (*destroy)(struct drm_connector *connector);
void (*force)(struct drm_connector *connector);
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] Reduce idle vblank wakeups
The drm core currently waits 5 seconds from userspace dropping a request for vblanks to vblanks actually being disabled. This appears to be a workaround for broken hardware, but results in a mostly idle desktop generating a huge number of wakeups that are entirely unnecessary but which consume measurable amounts of power. This patchset makes the vblank timeout per-device rather than global, making it easy for drivers to override the behaviour without compromising other graphics hardware in the system. It then removes the delay on Intel hardware. I've tested this successfully on Sandybridge without any evidence of spurious or missing irqs, but I don't know how well it works on older hardware. Feedback not only welcome, but positively desired. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/3] drm: Handle the vblank_offdelay=0 case properly
Right now if vblank_offdelay is 0, vblanks won't be disabled after the last user. Fix that case up. Signed-off-by: Matthew Garrett m...@redhat.com --- drivers/gpu/drm/drm_irq.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 8bcb6a4..94f9579 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -935,8 +935,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc) BUG_ON(atomic_read(dev-vblank_refcount[crtc]) == 0); /* Last user schedules interrupt disable */ - if (atomic_dec_and_test(dev-vblank_refcount[crtc]) - (dev-vblank_offdelay 0)) + if (atomic_dec_and_test(dev-vblank_refcount[crtc])) mod_timer(dev-vblank_disable_timer, jiffies + ((dev-vblank_offdelay * DRM_HZ)/1000)); } -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/3] i915: Drop vblank_offdelay
Sandybridge, at least, seems to manage without any vblank offdelay. Dropping this reduces the number of wakeups on an otherwise idle system dramatically. Signed-off-by: Matthew Garrett m...@redhat.com --- drivers/gpu/drm/i915/i915_dma.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index a9533c5..46e7172 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1917,6 +1917,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) goto free_priv; } + /* vblank is reliable */ + dev-vblank_offdelay = 0; + /* overlay on gen2 is broken and can't address above 1G */ if (IS_GEN2(dev)) dma_set_coherent_mask(dev-pdev-dev, DMA_BIT_MASK(30)); -- 1.7.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
On Wed, 2011-11-16 at 09:20 -0500, Matthew Garrett wrote: The drm core currently waits 5 seconds from userspace dropping a request for vblanks to vblanks actually being disabled. This appears to be a workaround for broken hardware, but results in a mostly idle desktop generating a huge number of wakeups that are entirely unnecessary but which consume measurable amounts of power. This patchset makes the vblank timeout per-device rather than global, making it easy for drivers to override the behaviour without compromising other graphics hardware in the system. It then removes the delay on Intel hardware. I've tested this successfully on Sandybridge without any evidence of spurious or missing irqs, but I don't know how well it works on older hardware. Feedback not only welcome, but positively desired. Looks good to me. I'll test this on some other intel kit I've got handy. For the series: Reviewed-by: Adam Jackson a...@redhat.com - ajax 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
[Intel-gfx] How to disable the internal graphics device of Q45 for lower power consumption
Hi all, I wonder if there is a way to disable or power off the built-in graphics device that is integrated in chipset if it is not used for most of the time, for instance, on servers. What I have tried is, experiment on Q45 chipset, set bit 3 and 4 of register 'deven' at offset 54-57h in the PCI configuration space belonging to device 0 function 0. The datasheet of Q45 tells setting these bits can disable the internal graphics(deveice 2 function 0 and 1). I tried and it turned out that if the VGA cable is connected, setting the bits leads up to shut-off of signal and the power meter shows less dissipation. That is great. But if I unplug the VGA cable, I can also see the same drop in degree as much as which if I disable the device. That means if cable is unconnected, disable the device cannot further reduce the power consumption. So I am guessing the graphics device is not fully powered off by this method. The questions goes, is there any way which can fully power off the device or at least put it into much much lower power state. If that is possible I can do it on our online servers to save energy. The sever is Atom based platform with GMA 3150 graphics integrated. Thanks, Joseph** ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Mon, Nov 14, 2011 at 21:39, Eugeni Dodonov eugeni.dodo...@intel.com wrote: Semaphores seem to fix most of the hangs on SNB and IVB, and do not cause any known regressions as of now. Let's re-enable them by default to provide a wider testing and coverage. Acked-by: Keith Packard kei...@keithp.com CC: Jesse Barnes jbar...@virtuousgeek.org CC: Daniel Vetter daniel.vet...@ffwll.ch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42696 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40564 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38862 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com Semaphores are still broken on my snb in combination with DMAR. ppgtt seems to slightly change the failure mode and probably helps in tracking this down, but without ppgtt it's a hard hang a few seconds after login. So we need to check whether DMAR is enabled (on the entire system, i.e. the variable exported for the ilk workaround is not good enough) on snb and then disable it by default. So in this current form: Nacked-by: Daniel Vetter daniel.vet...@ffwll.ch (still causes easily reproducible hard-hangs) I don't have anything against enabling this by default on ivb. -- 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 2/2] drm/i915: re-enable rc6 by default
On Mon, Nov 14, 2011 at 21:39, Eugeni Dodonov eugeni.dodo...@intel.com wrote: Most of the rc6-related hangs and major issues were addressed for the past months. Let's re-enable it by default to provide a more wider testing, and catch the remaining problems. According to tests, enablement of rc6 results in up to +50% improvements in power usage and battery life, so it certainly would be a nice feature to have enabled by default. Also, most of the issues related to rc6 seem to came from VTd, so if you are experiencing any problems with it, try disabling VTd in bios or using intel_iommu=off kernel parameter to investigate whether it solves the issue. Acked-by: Keith Packard kei...@keithp.com CC: Daniel Vetter daniel.vet...@ffwll.ch CC: Jesse Barnes jbar...@virtuousgeek.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com Iirc the same applies to rc6 as to semaphores. We have bug reports that it causes hard-hangs in combination with DMAR. I haven't yet gotten around to poking the relevant reporters whether ppgtt changes anything, because internet access here at the Intel Poland site sucks. So again I think we need to disable this on snb when DMAR is on. -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] [alsa-devel] [PATCH 2/2] hda - delayed ELD repoll
At Wed, 16 Nov 2011 07:51:28 -0800, Stephen Warren wrote: 250mS almost sounds like it's setting ELDV in the audio HW, then going and reading the EDID, then writing the EDID to the audio HW; perhaps the graphics driver is accidentally setting PRESENT+ELDV when it's meant to be setting just PRESENT, and later setting ELDV? From the debug dmesg, I'm pretty sure that the ELDV events are triggered exactly by the eld_valid = 0 and eld_valid = 1 register writes. Since the ELD data is already prepared, there is no EDID read in between. Below is the dmesg representing a video mode set. ELD writes from the graphics driver [ 424.254958] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 424.257670] [drm:ironlake_write_eld], ELD on pipe B [ 424.259833] [drm:ironlake_write_eld], Audio directed to unknown port [ 424.262156] [drm:ironlake_write_eld], ELD size 13 ELD events received by audio driver (eld reads 0) [ 424.263258] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 That line makes sense. [ 424.265877] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 I don't /think/ it's related to this issue, but I wonder why ELDV==1 in that message; it seems that the unsolicited response contains the correct data, but AC_VERB_GET_PIN_SENSE contains ELDV==1 all the time. That's odd. Note that this bit isn't from GET_PIN_SENSE verb but the bit in the unsol event argument. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: add SNB and IVB video sprite support v2
On Mon, Nov 14, 2011 at 21:22, Jesse Barnes jbar...@virtuousgeek.org wrote: The video sprites support various video surface formats natively and can handle scaling as well. So add support for them using the new DRM core sprite support functions. v2: use drm specific fourcc header and defines v3: address Daniel's comments: - don't take struct mutex around register access (only needed for regs in the GT power well) - don't hold struct mutex across vblank waits - fix up update_plane API (pass obj instead of GTT offset) - add interlaced defines for sprite regs - drop unnecessary 'reg' variables - comment double buffered reg flushing Also fix w/h confusion when writing the scaling reg. For this version, I tested DPMS since it came up in the last review; DPMS off/on works ok when a video player is working under X, but for power saving we'll probably want to do something smarter. I'll leave that for a separate patch on top. Likewise with the refcounting/fb layer handling, which are really separate cleanups. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org I haven't rechecked with Bspec (I'm not that insane ;-) but with my comments addressed, this looks good, and fixing dpms handling and framebuffer ugliness is something for another patch series. Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 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 3/3] drm/i915: track sprite coverage and disable primary plane if possible
On Mon, Nov 14, 2011 at 21:22, Jesse Barnes jbar...@virtuousgeek.org wrote: To save power when the sprite is full screen, we can disable the primary plane on the same pipe. Track the sprite status and enable/disable the primary opportunistically. Signed-off-by: Jesse Barnes Imo the indirection is overkill because afaics there's no difference. And in my experience this will only get in the way when later hw _really_ needs some abstraction (*cough* intel_ringbuffer.c *cough*. Can we just kill it? -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 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 2/3] drm/i915: add destination color key support
On Mon, Nov 14, 2011 at 21:22, Jesse Barnes jbar...@virtuousgeek.org wrote: Add new ioctls for getting and setting the current destination color key. This allows for simple overlay display control by matching a color key value in the primary plane before blending the overlay on top. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Just a few comments because reviewing patches here is a royal pain: - Is taking dev-struct_mutex really required around the register access? - You unconditionally enable the color key. Do we anticipate any other uses (like no color key or dst color key) or is this just the make-Xv-work ioctl? - Same for the mask Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 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] [alsa-devel] [PATCH 2/2] hda - delayed ELD repoll
At Wed, 16 Nov 2011 08:12:04 -0800, Stephen Warren wrote: Takashi Iwai wrote at Wednesday, November 16, 2011 8:58 AM: At Wed, 16 Nov 2011 07:51:28 -0800, Stephen Warren wrote: ... [ 424.263258] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 That line makes sense. [ 424.265877] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 I don't /think/ it's related to this issue, but I wonder why ELDV==1 in that message; it seems that the unsolicited response contains the correct data, but AC_VERB_GET_PIN_SENSE contains ELDV==1 all the time. That's odd. Note that this bit isn't from GET_PIN_SENSE verb but the bit in the unsol event argument. The first message above prints data from the unsolicited event. The second message above is derived from the GET_PIN_SENSE verb. Ah, right. Too similar lines... thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: track sprite coverage and disable primary plane if possible
On Wed, 16 Nov 2011 17:05:50 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Mon, Nov 14, 2011 at 21:22, Jesse Barnes jbar...@virtuousgeek.org wrote: To save power when the sprite is full screen, we can disable the primary plane on the same pipe. Track the sprite status and enable/disable the primary opportunistically. Signed-off-by: Jesse Barnes Imo the indirection is overkill because afaics there's no difference. And in my experience this will only get in the way when later hw _really_ needs some abstraction (*cough* intel_ringbuffer.c *cough*. Can we just kill it? Yeah I can make ivb and snb share at least (and probably ilk), but I *do* have code coming that needs the separation. (At least I'm pretty sure; I'll remove the abstraction if it turns out I don't need it.) Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add destination color key support
On Wed, 16 Nov 2011 17:10:53 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Mon, Nov 14, 2011 at 21:22, Jesse Barnes jbar...@virtuousgeek.org wrote: Add new ioctls for getting and setting the current destination color key. This allows for simple overlay display control by matching a color key value in the primary plane before blending the overlay on top. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Just a few comments because reviewing patches here is a royal pain: - Is taking dev-struct_mutex really required around the register access? Oh did I leave them in place for these paths? I'll drop them too. - You unconditionally enable the color key. Do we anticipate any other uses (like no color key or dst color key) or is this just the make-Xv-work ioctl? I was thinking of that... W/o a src or dest key, the overlay will always be on top. That's probably reasonable for simple cases, so having a key present flag makes sense. Which means setting a 0 dest key would mean disable dest key and go back to the default behavior. So the interface would stay the same even if we added other key types in the future. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix invalid backpanel values for GEN3 or older chips
While refactoring of backlight control code in commit [a95735569:
drm/i915: Refactor panel backlight controls], the handling of the bit
0 of duty-cycle was gone except for pineview. This resulted in invalid
register values for old chips like 915GM. When the bit 0 is set, the
backlight is turned off suddenly.
This patch changes the bit-0 check by replacing with the condition of
gen 4 (pineview is included in this condition, too).
Reported-and-tested-by: Daniel Mack zon...@gmail.com
Cc: sta...@kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/i915/intel_panel.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 499d4c0..737d00f 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -178,12 +178,10 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
max = 16;
} else {
- if (IS_PINEVIEW(dev)) {
+ if (INTEL_INFO(dev)-gen 4) {
max = 17;
} else {
max = 16;
- if (INTEL_INFO(dev)-gen 4)
- max = ~1;
}
if (is_backlight_combination_mode(dev))
@@ -203,7 +201,7 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CPU_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
} else {
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
- if (IS_PINEVIEW(dev))
+ if (INTEL_INFO(dev)-gen 4)
val = 1;
if (is_backlight_combination_mode(dev)) {
@@ -246,7 +244,7 @@ static void intel_panel_actually_set_backlight(struct
drm_device *dev, u32 level
}
tmp = I915_READ(BLC_PWM_CTL);
- if (IS_PINEVIEW(dev)) {
+ if (INTEL_INFO(dev)-gen 4) {
tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level = 1;
} else
--
1.7.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: So we need to check whether DMAR is enabled (on the entire system, i.e. the variable exported for the ilk workaround is not good enough) Can you figure out what *would* be sufficient? Getting semaphores turned on for the 99% who aren't enabling VT-d would be a fairly nice performance improvement. -- keith.pack...@intel.com pgp2bBgO64y9R.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel Dänzer wrote: I thought the main reason for the delay wasn't broken hardware but to avoid constantly ping-ponging the vblank IRQ between on and off with apps which regularly neeed the vblank counter value, as that could make the counter unreliable. Maybe I'm misremembering though. If turning it on and off results in the counter value being wrong then surely that's a hardware problem? I've tested that turning it on and off between every IRQ still gives valid counter values on sandybridge. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
2011/11/16 Matthew Garrett mj...@srcf.ucam.org: On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel Dänzer wrote: I thought the main reason for the delay wasn't broken hardware but to avoid constantly ping-ponging the vblank IRQ between on and off with apps which regularly neeed the vblank counter value, as that could make the counter unreliable. Maybe I'm misremembering though. If turning it on and off results in the counter value being wrong then surely that's a hardware problem? I've tested that turning it on and off between every IRQ still gives valid counter values on sandybridge. This, and the thread that contains it, might be interesting: http://permalink.gmane.org/gmane.comp.video.dri.devel/53201 In summary: there was some resistance to doing this in January, but I couldn't find any legitimate reason. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
On Wed, Nov 16, 2011 at 07:27:51PM +0100, Mario Kleiner wrote: It's not broken hardware, but fast ping-ponging it on and off can make the vblank counter and vblank timestamps unreliable for apps that need high timing precision, especially for the ones that use the OML_sync_control extensions for precise swap scheduling. My target application is vision science neuroscience, where (sub-)milliseconds often matter for visual stimulation. I'll admit that I'm struggling to understand the issue here. If the vblank counter is incremented at the time of vblank (which isn't the case for radeon, it seems, but as far as I can tell is the case for Intel) then how does ping-ponging the IRQ matter? vblank_disable_and_save() appears to handle this case. I think making the vblank off delay driver specific via these patches is a good idea. Lowering the timeout to something like a few refresh cycles, maybe somewhere between 50 msecs and 100 msecs would be also fine by me. I still would like to keep some drm config option to disable or override the vblank off delay by users. Does the timeout serve any purpose other than letting software effectively prevent vblanks from being disabled? The intel and radeon kms drivers implement everything that's needed to make it mostly work. Except for a small race between the cpu and gpu in the vblank_disable_and_save() function http://lxr.free- electrons.com/source/drivers/gpu/drm/drm_irq.c#L101 and drm_update_vblank_count(). It can cause an off-by-one error when reinitializing the drm vblank counter from the gpu's hardware counter if the enable/disable function is called at the wrong moment while the gpu's scanout is inside the vblank interval, see comments in the code. I have some sketchy idea for a patch that could detect when the race happens and retry hw counter queries to fix this. Without that patch, there's some chance between 0% and 4% of being off-by-one. For Radeon, I'd have thought you could handle this by scheduling an irq for the beginning of scanout (avivo has a register for that) and delaying the vblank disable until you hit it? On current nouveau kms, disabling vblank irqs guarantees you wrong vblank counts and wrong vblank timestamps after turning them on again, because the kms driver doesn't implement the hook for hardware vblank counter query correctly. The drm vblank counter misses all counts during the vblank irq off period. Other timing related hooks are missing as well. I have a couple of patches queued up and some more to come for the ddx and kms driver to mostly fix this. NVidia gpu's only have hardware vblank counters for NV-50 and later, fixing this for earlier gpu's would require some emulation of a hw vblank counter inside the kms driver. I've no problem with all of this work being case by case. Apps that rely on the vblank counter being totally reliable over long periods of time currently would be in a bad situation with a lowered vblank off delay, but that's probably generally not a good assumption. Toolkits like mine, which are more paranoid, currently can work fine as long as the off delay is at least a few video refresh cycles. I do the following for scheduling a reliably timed swap: 1. Query current vblank counter current_msc and vblank timestamp current_ust. 2. Calculate a target vblank count target_msc, based on current_msc, current_ust and some target time from usercode. 3. Schedule bufferswap for target_msc. As long as the vblank off delay is long enough so that vblanks don't get turned off between 1. and 3, everything is fine, otherwise bad things will happen. Keeping a way to override the default off delay would be good to allow poor scientists to work around potentially broken drivers or gpu's in the future. @Matthew: I'm appealing here to your ex- Drosophila biologist heritage ;-) If vblanks are disabled and then re-enabled between 1 and 3, what's the negative outcome? -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Wed, Nov 16, 2011 at 15:24, Andrew Lutomirski l...@mit.edu wrote: AFAICT my snb laptop has always been stable with semaphores and VT-d enabled. Is this problem possibly restricted to just desktop machines? I'm happy to test, since my box that can reproduce the hang instantly is still around. I cannot reproduce those issues on any mobile SNB, but I am out of desktop ones. So perhaps it is a clue. Jesse, Keith, Daniel, what if we add something like: ... .has_semaphores=1, .has_rc6=1 ... to i915_drv.c intel_sandybridge_m_info, and take them into account when using default values for those settings? -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Wed, 16 Nov 2011 17:05:37 -0200 Eugeni Dodonov eug...@dodonov.net wrote: On Wed, Nov 16, 2011 at 15:24, Andrew Lutomirski l...@mit.edu wrote: AFAICT my snb laptop has always been stable with semaphores and VT-d enabled. Is this problem possibly restricted to just desktop machines? I'm happy to test, since my box that can reproduce the hang instantly is still around. I cannot reproduce those issues on any mobile SNB, but I am out of desktop ones. So perhaps it is a clue. Jesse, Keith, Daniel, what if we add something like: ... .has_semaphores=1, .has_rc6=1 ... to i915_drv.c intel_sandybridge_m_info, and take them into account when using default values for those settings? Something like that is fine with me, or just doing it in modeset_init for certain chipsets. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Wed, Nov 16, 2011 at 18:16, Keith Packard kei...@keithp.com wrote: On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: So we need to check whether DMAR is enabled (on the entire system, i.e. the variable exported for the ilk workaround is not good enough) Can you figure out what *would* be sufficient? Getting semaphores turned on for the 99% who aren't enabling VT-d would be a fairly nice performance improvement. Last time I've played around with all the combinations, only intel_iommu=off was good enough to prevent the hang. intel_iommu=igd_off still hangs (which is what the current value exported by the dmar code dopends on, iirc). If I remember things correctly, intel_iommu=off also reliably works around issues for all reporters (both semaphores and rc6). And for reproducing it, at least here the key ingredient seems to be a kde4 desktop. Spare the jokes ;-) -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 2/2] drm/i915: re-enable rc6 by default
On Wed, Nov 16, 2011 at 16:59, Andrew Lutomirski a...@luto.us wrote: On Nov 16, 2011 7:54 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: On Mon, Nov 14, 2011 at 21:39, Eugeni Dodonov eugeni.dodo...@intel.com wrote: Most of the rc6-related hangs and major issues were addressed for the past months. Let's re-enable it by default to provide a more wider testing, and catch the remaining problems. According to tests, enablement of rc6 results in up to +50% improvements in power usage and battery life, so it certainly would be a nice feature to have enabled by default. Also, most of the issues related to rc6 seem to came from VTd, so if you are experiencing any problems with it, try disabling VTd in bios or using intel_iommu=off kernel parameter to investigate whether it solves the issue. Acked-by: Keith Packard kei...@keithp.com CC: Daniel Vetter daniel.vet...@ffwll.ch CC: Jesse Barnes jbar...@virtuousgeek.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com Iirc the same applies to rc6 as to semaphores. We have bug reports that it causes hard-hangs in combination with DMAR. I haven't yet gotten around to poking the relevant reporters whether ppgtt changes anything, because internet access here at the Intel Poland site sucks. So again I think we need to disable this on snb when DMAR is on. I can reproduce the semaphore hang easily. Where are the ppgtt patches/settings to play with? FWIW, rc6 is a *huge* win on my SNB laptop, and the laptop has always been rock-solid with any set of options. Maybe this is only an issue on desktop parts, and the 5W difference is a bigger deal on laptops anyway. Grab the ppgtt branch from my fdo repo: http://cgit.freedesktop.org/~danvet/drm/ Note that this branch will only work on snb/ivb and that resume is broken. Also, after the first gpu reset ppgtt will get disabled and hence your machine might die rather quickly. So perhaps boot with i915.reset=0 to prevent that. Testing feedback highly welcome. Yours, 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 1/2] drm/i915: re-enable semaphores by default
Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when decoding videos (vaapi) and running OpenGL apps/games at the same time. Disabling iommu makes my system relatively stable even with rc6 enabled. I haven't played with the semaphores however. -- Nic -Ursprüngliche Nachricht- Von: Andrew Lutomirski l...@mit.edu Gesendet: Nov 16, 2011 6:24:54 PM An: Keith Packard kei...@keithp.com Betreff: Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default On Wed, Nov 16, 2011 at 9:16 AM, Keith Packard kei...@keithp.com wrote: On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: So we need to check whether DMAR is enabled (on the entire system, i.e. the variable exported for the ilk workaround is not good enough) Can you figure out what *would* be sufficient? Getting semaphores turned on for the 99% who aren't enabling VT-d would be a fairly nice performance improvement. AFAICT my snb laptop has always been stable with semaphores and VT-d enabled. Is this problem possibly restricted to just desktop machines? I'm happy to test, since my box that can reproduce the hang instantly is still around. Also, rc6-by-default would be very nice. It decreases the total power consumption on my laptop from over 13W to around 8W. That's huge. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Wed, Nov 16, 2011 at 21:56, Nicolas Kalkhof nkalk...@web.de wrote: Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when decoding videos (vaapi) and running OpenGL apps/games at the same time. Disabling iommu makes my system relatively stable even with rc6 enabled. I haven't played with the semaphores however. Can you please try my ppgtt branch from my fdo repo at http://cgit.freedesktop.org/~danvet/drm/ ? Note thought that it'll only work on snb/ivb and that suspend/resume is broken. Also, it won't properly re-enable ppgtt when resetting the gpu after a hang. But testing feedback highly appreciated. 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 1/2] drm/i915: re-enable semaphores by default
On Wed, 16 Nov 2011 21:18:13 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: Last time I've played around with all the combinations, only intel_iommu=off was good enough to prevent the hang. intel_iommu=igd_off still hangs (which is what the current value exported by the dmar code dopends on, iirc). If I remember things correctly, intel_iommu=off also reliably works around issues for all reporters (both semaphores and rc6). So, the dmar_disabled flag would suffice? Should be trivial to export that and check in our driver. -- keith.pack...@intel.com pgpzri5pUuZyX.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Wed, 16 Nov 2011 21:56:37 +0100 (CET), Nicolas Kalkhof nkalk...@web.de wrote: Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when decoding videos (vaapi) and running OpenGL apps/games at the same time. Disabling iommu makes my system relatively stable even with rc6 enabled. I haven't played with the semaphores however. So, if we disabled rc6 when iommu is enabled (dmar_disable = 0), we should be in good shape then. -- keith.pack...@intel.com pgpeKemZMe720.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 2/2] hda - delayed ELD repoll
On Wed, Nov 16, 2011 at 11:51:28PM +0800, Stephen Warren wrote: Wu Fengguang wrote at Tuesday, November 15, 2011 7:48 PM: On Wed, Nov 16, 2011 at 02:25:00AM +0800, Stephen Warren wrote: Wu Fengguang wrote at Tuesday, November 15, 2011 7:33 AM: The Intel HDMI chips (ironlake at least) are found to have ~250ms delay between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes actually readable. During the time the ELD buffer is mysteriously all 0. Fix it by scheduling a delayed work to re-read ELD buffer after 300ms. Any idea why; is the graphics driver writing the ELD data to the audio HW after triggering the unsolicited even rather than before, or something like that? Nope. The graphics driver is doing eld_valid = 0 write to eld buffer eld_valid = 1 OK, that sounds fine. 250mS almost sounds like it's setting ELDV in the audio HW, then going and reading the EDID, then writing the EDID to the audio HW; perhaps the graphics driver is accidentally setting PRESENT+ELDV when it's meant to be setting just PRESENT, and later setting ELDV? From the debug dmesg, I'm pretty sure that the ELDV events are triggered exactly by the eld_valid = 0 and eld_valid = 1 register writes. Since the ELD data is already prepared, there is no EDID read in between. Below is the dmesg representing a video mode set. ELD writes from the graphics driver [ 424.254958] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 424.257670] [drm:ironlake_write_eld], ELD on pipe B [ 424.259833] [drm:ironlake_write_eld], Audio directed to unknown port [ 424.262156] [drm:ironlake_write_eld], ELD size 13 ELD events received by audio driver (eld reads 0) [ 424.263258] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 That line makes sense. [ 424.265877] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 I don't /think/ it's related to this issue, but I wonder why ELDV==1 in that message; it seems that the unsolicited response contains the correct data, but AC_VERB_GET_PIN_SENSE contains ELDV==1 all the time. That's odd. It depends on timing. When audio driver receives the unsolicited event, graphics driver has finished with eld_valid = 1, hence AC_VERB_GET_PIN_SENSE returns ELDV=1. It's not happening /all the time/ though. For example here is another dmesg showing a different timing on the same test box. [ 467.561516] [drm:intel_dp_mode_set], Enabling DP audio on pipe B [ 467.567503] [drm:intel_write_eld], ELD on [CONNECTOR:26:DP-3], [ENCODER:27:TMDS-27] [ 467.574207] [drm:ironlake_write_eld], ELD on pipe B [ 467.579346] [drm:ironlake_write_eld], Audio directed to unknown port [ 467.584724] [drm:ironlake_write_eld], ELD: DisplayPort detected [ 467.586540] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.599608] [drm:ironlake_write_eld], [ 467.599922] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.605834] ELD size 9 [ 467.610434] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 7, cursor: 6 [ 467.612365] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 [ 467.620654] [drm:sandybridge_update_wm], [ 467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 [ 424.272415] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 [ 424.274566] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 424.277027] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 424.283157] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 graphics driver go on with its job [ 424.314331] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.367183] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.368960] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 424.370700] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 424.424056] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.476906] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.479169] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 424.481084] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 424.483452] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 424.485444] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 424.486765] [drm:ironlake_fdi_link_train], FDI train done [ 424.490820] [drm:intel_update_fbc], [ 424.491841] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 424.494449] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 424.505904] [drm:intel_prepare_page_flip], preparing flip with no unpin work? audio driver repoll the ELD after 300ms (eld data readable now) [ 424.574763] HDMI status: Codec=3
[Intel-gfx] [Mesa-dev] Mesa/Gallium overall design
In a posting to intel-gfx on Mon Apr 12 10:12:12 PDT 2010, Jesse Barnes gave several reasons why the Intel Mesa drivers team was not supporting the Gallium drivers at that time. Here is an excerpt from that email: Moving to Gallium would be a huge effort for us. We've invested a lot into the current drivers, stabilizing them, adding features, and generally supporting them. If we moved to Gallium, much of that effort would be thrown away as with any large rewrite, leaving users in a situation where the driver that worked was unsupported and the one that was supported didn't work very well (at least for quite some time). Currently, the benefits of Gallium are outweighed by this consideration, at least in my opinion. However, Dave has been poking us a bit about using LLVM for a sw vertex shader implementation on 945, which Gallium would make much easier aiui, so who knows things may change in the future. I still worry about delivering a high quality and supported driver to our users though. It is now a year and seven months later. Is this still the policy of the Intel graphics organization? It appears from looking at the Classic and Gallium driver code base, that OpenVG is only supported in the Gallium version. Is this correct? Can someone please enumerate any other feature differences between the Classic and Gallium drivers? Thank you very much in advance. Allen Leinwand Allen Leinwand Teleca , allen.leinw...@teleca.com http://www.teleca.com/ Follow what's going on at Teleca's blog on http://www.whatsyourideaoftomorrow.blogspot.com/. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 2/2] hda - delayed ELD repoll
Below is the dmesg representing a video mode set. ELD writes from the graphics driver [ 424.254958] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 424.257670] [drm:ironlake_write_eld], ELD on pipe B [ 424.259833] [drm:ironlake_write_eld], Audio directed to unknown port [ 424.262156] [drm:ironlake_write_eld], ELD size 13 ELD events received by audio driver (eld reads 0) [ 424.263258] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 That line makes sense. [ 424.265877] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 I don't /think/ it's related to this issue, but I wonder why ELDV==1 in that message; it seems that the unsolicited response contains the correct data, but AC_VERB_GET_PIN_SENSE contains ELDV==1 all the time. That's odd. It depends on timing. When audio driver receives the unsolicited event, graphics driver has finished with eld_valid = 1, hence AC_VERB_GET_PIN_SENSE returns ELDV=1. It's not happening /all the time/ though. For example here is another dmesg showing a different timing on the same test box. Sorry this is actually from another test box. But I did see similar ones from the same test box. [ 467.561516] [drm:intel_dp_mode_set], Enabling DP audio on pipe B [ 467.567503] [drm:intel_write_eld], ELD on [CONNECTOR:26:DP-3], [ENCODER:27:TMDS-27] [ 467.574207] [drm:ironlake_write_eld], ELD on pipe B [ 467.579346] [drm:ironlake_write_eld], Audio directed to unknown port [ 467.584724] [drm:ironlake_write_eld], ELD: DisplayPort detected [ 467.586540] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.599608] [drm:ironlake_write_eld], [ 467.599922] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.605834] ELD size 9 [ 467.610434] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 7, cursor: 6 [ 467.612365] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 [ 467.620654] [drm:sandybridge_update_wm], [ 467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.17.0
A few months have passed, and we have accumulated a surprising number of bug fixes. Oops! We would strongly encourage everyone to upgrade. -Chris Bugs fixed in this release (compared to 2.16.0) --- * Video clobbering composite batch state http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635953 * Incorrect reuse of surface bindings within a batch for multiple formats https://bugs.freedesktop.org/show_bug.cgi?id=40926 * Nothing was rendered for text with procedural sources https://bugs.freedesktop.org/show_bug.cgi?id=31819 * Handle fallbacks involving alpha maps * Workaround blitter hang on SandyBridge and IvyBridge https://bugzilla.kernel.org/show_bug.cgi?id=27892 https://bugs.freedesktop.org/show_bug.cgi * Workaround pipe control issues on SandyBridge * Use correct maximum PS thread count on IvyBridge * Protect against failed pixmap allocation for XV https://bugs.freedesktop.org/show_bug.cgi?id=40439 git tag: 2.17.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.17.0.tar.bz2 MD5: 6d7b1f199dba5820f250888b136186ff xf86-video-intel-2.17.0.tar.bz2 SHA1: 04ad9fa1f4c4e0a90f48752a709bf14700c864af xf86-video-intel-2.17.0.tar.bz2 SHA256: 8b8450f2a2cc52ef31a83414e2f290e748a956690e11b41759d5650aaedc4387 xf86-video-intel-2.17.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.17.0.tar.gz MD5: 7443f0054f9c81aad7facecbef3daef0 xf86-video-intel-2.17.0.tar.gz SHA1: aeea2c4e8e9c25b84802c2f0dc26942ccc3590c1 xf86-video-intel-2.17.0.tar.gz SHA256: 7da1d957b4abe6da38958f3c282d857138e7318028286dc1a1f57df5e0ff0da8 xf86-video-intel-2.17.0.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: support for per-device semaphores settings
This allows to enable semaphores by default on devices which support them.
By default, let's enable them on IVB only for now. When DMAR issues on SNB
will be solved, we can enable them on SNB as well.
For IVB, it should fix many hangs and issues.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42696
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40564
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38862
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c|6 --
drivers/gpu/drm/i915/i915_drv.h|3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc531bb..355f1ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -58,10 +58,10 @@ module_param_named(powersave, i915_powersave, int, 0600);
MODULE_PARM_DESC(powersave,
Enable powersavings, fbc, downclocking, etc. (default: true));
-unsigned int i915_semaphores __read_mostly = 0;
+unsigned int i915_semaphores __read_mostly = -1;
module_param_named(semaphores, i915_semaphores, int, 0600);
MODULE_PARM_DESC(semaphores,
- Use semaphores for inter-ring sync (default: false));
+ Use semaphores for inter-ring sync (default: -1 (use per-chip
defaults)));
unsigned int i915_enable_rc6 __read_mostly = 0;
module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600);
@@ -229,6 +229,7 @@ static const struct intel_device_info
intel_ivybridge_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .enable_semaphores = 1,
};
static const struct intel_device_info intel_ivybridge_m_info = {
@@ -237,6 +238,7 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
.has_fbc = 0, /* FBC is not enabled on Ivybridge mobile yet */
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .enable_semaphores = 1,
};
static const struct pci_device_id pciidlist[] = { /* aka */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 06a37f4..0e819d2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -247,6 +247,7 @@ struct intel_device_info {
u8 supports_tv:1;
u8 has_bsd_ring:1;
u8 has_blt_ring:1;
+ u8 enable_semaphores:1;
};
enum no_fbc_reason {
@@ -990,6 +991,8 @@ struct drm_i915_file_private {
#define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
+#define ENABLE_SEMAPHORES(dev)(INTEL_INFO(dev)-enable_semaphores)
+
#include i915_trace.h
extern struct drm_ioctl_desc i915_ioctls[];
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3693e83..094ff4c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -753,12 +753,16 @@ i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object
*obj,
struct intel_ring_buffer *from = obj-ring;
u32 seqno;
int ret, idx;
+ int enable_semaphores = 0;
if (from == NULL || to == from)
return 0;
+ if (i915_semaphores 0 ENABLE_SEMAPHORES(obj-base.dev))
+ enable_semaphores = 1;
+
/* XXX gpu semaphores are implicated in various hard hangs on SNB */
- if (INTEL_INFO(obj-base.dev)-gen 6 || !i915_semaphores)
+ if (INTEL_INFO(obj-base.dev)-gen 6 || !enable_semaphores)
return i915_gem_object_wait_rendering(obj);
idx = intel_ring_sync_index(from, to);
--
1.7.7.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: allow semaphores on SNB if DMAR is disabled
Semaphores cause issues when DMAR is enabled. So if we are set to per-chip
default, and we are on SNB, we can enable semaphores as long as SMAR is
disabled.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c|2 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 +++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 355f1ab..565725c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -214,6 +214,7 @@ static const struct intel_device_info
intel_sandybridge_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .enable_semaphores = 1,
};
static const struct intel_device_info intel_sandybridge_m_info = {
@@ -222,6 +223,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
.has_fbc = 1,
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .enable_semaphores = 1,
};
static const struct intel_device_info intel_ivybridge_d_info = {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 094ff4c..0510735 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -32,6 +32,7 @@
#include i915_drv.h
#include i915_trace.h
#include intel_drv.h
+#include linux/intel-iommu.h
struct change_domains {
uint32_t invalidate_domains;
@@ -758,7 +759,8 @@ i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object
*obj,
if (from == NULL || to == from)
return 0;
- if (i915_semaphores 0 ENABLE_SEMAPHORES(obj-base.dev))
+ /* Only enable semaphores if DMAR is disabled */
+ if (i915_semaphores 0 ENABLE_SEMAPHORES(obj-base.dev)
dmar_disabled)
enable_semaphores = 1;
/* XXX gpu semaphores are implicated in various hard hangs on SNB */
--
1.7.7.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: re-enable rc6 by default when GMAR is disabled
Most of the rc6-related hangs and major issues were addressed for the past
months.
Let's re-enable it by default to provide a more wider testing, and catch
the remaining problems.
According to tests, enablement of rc6 results in up to +50% improvements
in power usage and battery life, so it certainly would be a nice feature
to have enabled by default.
Also, most of the rc6-related issues seem to came from GMAR, so we only
enable it as long as GMAR is disabled.
CC: Keith Packard kei...@keithp.com
CC: Daniel Vetter daniel.vet...@ffwll.ch
CC: Jesse Barnes jbar...@virtuousgeek.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/intel_display.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 565725c..337a568 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -63,7 +63,7 @@ module_param_named(semaphores, i915_semaphores, int, 0600);
MODULE_PARM_DESC(semaphores,
Use semaphores for inter-ring sync (default: -1 (use per-chip
defaults)));
-unsigned int i915_enable_rc6 __read_mostly = 0;
+unsigned 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));
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 981b1f1..5dd0878 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -31,6 +31,7 @@
#include linux/kernel.h
#include linux/slab.h
#include linux/vgaarb.h
+#include linux/intel-iommu.h
#include drm/drm_edid.h
#include drmP.h
#include intel_drv.h
@@ -8746,7 +8747,7 @@ void intel_modeset_init(struct drm_device *dev)
void intel_modeset_gem_init(struct drm_device *dev)
{
- if (IS_IRONLAKE_M(dev))
+ if (IS_IRONLAKE_M(dev) dmar_disabled)
ironlake_enable_rc6(dev);
intel_setup_overlay(dev);
--
1.7.7.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Hook up Ivybridge eDP
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:
-
Re: [Intel-gfx] [PATCH 3/3] drm/i915: re-enable rc6 by default when GMAR is disabled
On Wed, Nov 16, 2011 at 10:17:55PM -0200, Eugeni Dodonov wrote:
Most of the rc6-related hangs and major issues were addressed for the past
months.
Let's re-enable it by default to provide a more wider testing, and catch
the remaining problems.
According to tests, enablement of rc6 results in up to +50% improvements
in power usage and battery life, so it certainly would be a nice feature
to have enabled by default.
Also, most of the rc6-related issues seem to came from GMAR, so we only
enable it as long as GMAR is disabled.
CC: Keith Packard kei...@keithp.com
CC: Daniel Vetter daniel.vet...@ffwll.ch
CC: Jesse Barnes jbar...@virtuousgeek.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/intel_display.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 565725c..337a568 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -63,7 +63,7 @@ module_param_named(semaphores, i915_semaphores, int, 0600);
MODULE_PARM_DESC(semaphores,
Use semaphores for inter-ring sync (default: -1 (use per-chip
defaults)));
-unsigned int i915_enable_rc6 __read_mostly = 0;
+unsigned 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));
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 981b1f1..5dd0878 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -31,6 +31,7 @@
#include linux/kernel.h
#include linux/slab.h
#include linux/vgaarb.h
+#include linux/intel-iommu.h
#include drm/drm_edid.h
#include drmP.h
#include intel_drv.h
@@ -8746,7 +8747,7 @@ void intel_modeset_init(struct drm_device *dev)
void intel_modeset_gem_init(struct drm_device *dev)
{
- if (IS_IRONLAKE_M(dev))
+ if (IS_IRONLAKE_M(dev) dmar_disabled)
ironlake_enable_rc6(dev);
intel_setup_overlay(dev);
--
This is not sufficient. You need to know that DMAR is compiled in, and
is actually being used.
The variable you want is: !intel_iommu_gfx_mapped
I think I saw Keith say he was sending this patch out on IRC.
Ben
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: allow semaphores on SNB if DMAR is disabled
On Wed, Nov 16, 2011 at 10:17:54PM -0200, Eugeni Dodonov wrote: Semaphores cause issues when DMAR is enabled. So if we are set to per-chip default, and we are on SNB, we can enable semaphores as long as SMAR is disabled. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com See my response to patch 3... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] Introduce Glamor to UXA framework.
On Wed, 16 Nov 2011 15:04:35 +0800, Zhigang Gong zhigang.g...@linux.intel.com wrote: This patchset initially enable glamor with UXA. And two functions ,fill_spans and poly_fill_rects, go to the glamor path. I tested it with render check, and it works fine. I split your patches slightly differently and pushed them. I could only verify that it didn't impact UXA without the glamor_egl module available. Do you have a patch for testing? -Chrid -- 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 0/2] Introduce Glamor to UXA framework.
-Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Thursday, November 17, 2011 9:14 AM To: Zhigang Gong; intel-gfx@lists.freedesktop.org Cc: zhigang.g...@linux.intel.com Subject: Re: [PATCH 0/2] Introduce Glamor to UXA framework. On Wed, 16 Nov 2011 15:04:35 +0800, Zhigang Gong zhigang.g...@linux.intel.com wrote: This patchset initially enable glamor with UXA. And two functions ,fill_spans and poly_fill_rects, go to the glamor path. I tested it with render check, and it works fine. I split your patches slightly differently and pushed them. I just checked out the master branch, and have a simple test, everything seems ok. Thanks. I could only verify that it didn't impact UXA without the glamor_egl module available. Do you have a patch for testing? Now glamor was extracted from the xorg and be a separate library. Please checkout glamor at : git://people.freedesktop.org/~gongzg/glamor. This library implements two modules glamor and glamor_egl which are required for intel video driver to enable glamor. -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] [RFC] Reduce idle vblank wakeups
On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote: On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote: For Radeon, I'd have thought you could handle this by scheduling an irq for the beginning of scanout (avivo has a register for that) and delaying the vblank disable until you hit it? For Radeon there is such an irq, but iirc we had some discussions on this, also with Alex Deucher, a while ago and some irq's weren't considered very reliable, or already used for other stuff. The idea i had goes like this: Use the crtc scanout position queries together with the vblank counter queries inside some calibration loop, maybe executed after each modeset, to find out the scanline range in which the hardware vblank counter increments -- basically a forbidden range of scanline positions where the race would happen. Then at each vblank off/on, query scanout position before and after the hw vblank counter query. If according to the scanout positions the vblank counter query happened within the forbidden time window, retry the query. With a well working calibration that should add no delay in most cases and a delay to the on/off code of a few dozen microseconds (=duration of a few scanlines) worst case. Assuming we're sleeping rather than busy-looping, that's certainly ok. My previous experiments with radeon indicated that the scanout irq was certainly not entirely reliable - on the other hand, I was trying to use it for completing memory reclocking within the vblank interval. It was typically still within a few scanlines, so a sanity check there wouldn't pose too much of a problem. I think there's a simpler fix: just keep the hardware and software counts in sync -- if everything is working correctly (even with all these crazy races), the difference should be constant. Patch coming momentarily. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: re-enable rc6 by default when GMAR is disabled
On Wed, 16 Nov 2011 22:11:06 -0800 keith.pack...@intel.com wrote: On Wed, 16 Nov 2011 16:56:16 -0800, Ben Widawsky b...@bwidawsk.net wrote: The variable you want is: !intel_iommu_gfx_mapped From what Daniel Vetter said: Last time I've played around with all the combinations, only intel_iommu=off was good enough to prevent the hang. intel_iommu=igd_off still hangs (which is what the current value exported by the dmar code dopends on, iirc). If I remember things correctly, intel_iommu=off also reliably works around issues for all reporters (both semaphores and rc6). we need to use dmar_disabled instead of intel_iommu_gfx_mapped. Other places in the code use: if (no_iommu || dmar_disabled) As long as he meant igfx_off, then okay... igd_off didn't immediately register to me earlier. Sorry for the confusion. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
