Re: [Intel-gfx] [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver
The X environment will eventually call mode_set when the user
environment decides to use the monitor. Any audio bits can, and should,
await the user's choice of a video mode before choosing the audio format
to use. We should not be adding eld information until the monitor is in
use.
Yeah. I just tested the full gnome desktop and find it behave like the
KMS console:
1) -mode_set will be called
2) crtc is 0 in intel_hdmi_hotplug(), hence skipping the ELD code there
So the v3 patch will behave equally well on KMS console, gnome desktop
and bare X. Shall we just use it, or go back and use the original
-hot_remove patch?
Here is the patch with updated comments and changelog to reflect the
new findings.
---
Subject: drm/i915: hot plug/unplug notification to HDMI audio driver
Date: Fri Nov 11 13:49:04 CST 2011
On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly. So that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.
A new callback -hotplug() is added to struct drm_connector_funcs which
will be called immediately after -detect() knowing that the monitor is
either plugged or unplugged.
It's noticed that X may not call -mode_set() at monitor hot plug, so it's
necessary to call drm_edid_to_eld() earlier at -detect() time rather than
in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
in -hotplug.
The call sequence on hot plug is
(the difference part lies in -mode_set vs -hotplug)
- KMS console
-detect
drm_edid_to_eld
-mode_set
intel_write_eld
set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- X
-detect
drm_edid_to_eld
-hotplug
intel_write_eld
set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
On hot remove, the call sequence is
-hotplug
clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
cc: Wang Zhenyu zhenyu.z.w...@intel.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/drm_crtc_helper.c |6 +++
drivers/gpu/drm/i915/intel_dp.c| 44 +--
drivers/gpu/drm/i915/intel_hdmi.c | 31 +++
drivers/gpu/drm/i915/intel_modes.c |2 -
include/drm/drm_crtc.h |1
5 files changed, 72 insertions(+), 12 deletions(-)
--- linux.orig/drivers/gpu/drm/i915/intel_dp.c 2011-11-21 11:26:09.0
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c 2011-11-21 14:12:21.0
+0800
@@ -28,6 +28,7 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/export.h
+#include drm/drm_edid.h
#include drmP.h
#include drm.h
#include drm_crtc.h
@@ -1970,20 +1971,44 @@ intel_dp_detect(struct drm_connector *co
if (status != connector_status_connected)
return status;
- if (intel_dp-force_audio) {
- intel_dp-has_audio = intel_dp-force_audio 0;
- } else {
- edid = intel_dp_get_edid(connector, intel_dp-adapter);
- if (edid) {
- intel_dp-has_audio = drm_detect_monitor_audio(edid);
- connector-display_info.raw_edid = NULL;
- kfree(edid);
- }
+ edid = intel_dp_get_edid(connector, intel_dp-adapter);
+ if (edid) {
+ intel_dp-has_audio = drm_detect_monitor_audio(edid);
+ drm_edid_to_eld(connector, edid);
+ connector-display_info.raw_edid = NULL;
+ kfree(edid);
}
+ if (intel_dp-force_audio)
+ intel_dp-has_audio = intel_dp-force_audio 0;
+
return connector_status_connected;
}
+static void intel_dp_hotplug(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;
+
+ DRM_DEBUG_DRIVER(DisplayPort hotplug status %d crtc %p eld %#x\n,
+connector-status,
+crtc,
+(unsigned int)connector-eld[0]);
+
+ if (connector-status == connector_status_disconnected) {
+ intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
+ } else if (connector-status == connector_status_connected crtc) {
+ intel_write_eld(intel_dp-base.base, crtc-mode);
+ intel_dp-DP |= DP_AUDIO_OUTPUT_ENABLE;
+ } else {
+ return;
+ }
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2168,7 @@ static const struct drm_connector_funcs
.detect = intel_dp_detect,
.fill_modes =
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Mon, Nov 21, 2011 at 09:41:26PM -0800, Andrew Lutomirski wrote: On Thu, Nov 17, 2011 at 1:22 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Oops, sorry for wasting your time, wrong branch. Can you try the for-poland one? And also please try what happens when enabling the iommu. for-poland with semaphores, rc6, and iommu on seems to work. I'm sending this email from that kernel right now :) Awesome! Well, not quite because it still blows up for me (but no longer hard-hangs, just gpu death). Can you please attach full dmesg and lspci -nn, I want to check a few things? Thanks a lot, Daniel -- 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] backlight issue with an Acer Iconia Dual Screen
Hi all I am trying to install a fedora 16 on an Acer Iconia, a laptop with a double touch screen. Thanks to a recent patch in the Intel graphics driver, the second touch screen is now well recognized. However the backlight is set to the minimal value and there is no way to control it (only the backlight of the first screen can be changed). The log suggests that two control interfaces for backlight are found: [30.752] (II) intel(0): Output LVDS1 has no monitor section [30.758] (II) intel(0): found backlight control interface /sys/class/backlight/acpi_video0 [30.758] (II) intel(0): Output VGA1 has no monitor section [30.851] (II) intel(0): Output LVDS2 has no monitor section [30.856] (II) intel(0): found backlight control interface /sys/class/backlight/acpi_video0 In the /sys/class/backlight directory there is an acpi_video0 directory that seems rightly initialized and there is also an intel_backlight directory but with a max_brightness set to 1. Do you think that the problem comes from the driver? Thanks a lot Mathieu -- Mathieu Magnaudet - Chercheur Laboratoire d'Informatique Interactive ENAC - 7 av Edouard Belin 31055 TOULOUSE CEDEX 4 (phone) +33 562 174 217 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix invalid backpanel values for GEN3 or older chips
On Tue, 22 Nov 2011 17:40:25 +0100, Daniel Mack zon...@gmail.com wrote: Just curious - is this patch queued somewhere for mainline yet? I'm waiting for airlied to pull drm-fixes-intel before I push more stuff there. -- keith.pack...@intel.com pgpn9lOMl3zqH.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 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver
On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang fengguang...@intel.com wrote: So the v3 patch will behave equally well on KMS console, gnome desktop and bare X. Shall we just use it, or go back and use the original -hot_remove patch? I'm not sure why we need any change to the core DRM code. The HDMI and DP drivers will be told when to turn the monitors on and off, and that's the appropriate time to control whether audio is routed to them. Hotplug is considered simply a notification to user space that something has changed -- user space is in charge of configuring which outputs are in use. -- keith.pack...@intel.com pgpkvr77v8lev.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] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote: + /* + * Only enable RC6 if all dma remapping is disabled, or if + * there's no iommu present in the machine. + */ + if (INTEL_INFO(dev)-gen == 6) + return no_iommu || dmar_disabled; So the user has to choose between 5W of power saving or having dmar? And we default to giving them dmar? I think that's going to come as a surprise to people. -- 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] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Tue, Nov 22, 2011 at 18:15, Matthew Garrett m...@redhat.com wrote: On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote: + /* + * Only enable RC6 if all dma remapping is disabled, or if + * there's no iommu present in the machine. + */ + if (INTEL_INFO(dev)-gen == 6) + return no_iommu || dmar_disabled; So the user has to choose between 5W of power saving or having dmar? And we default to giving them dmar? From the latest investigations, it is either this, or random gpu hangs and crashes when both are enabled :(. When the root cause will be discovered, we should allow both of course. But so far, all the attempts on this weren't successful. -- 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] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Tue, Nov 22, 2011 at 06:46:21PM -0200, Eugeni Dodonov wrote: On Tue, Nov 22, 2011 at 18:15, Matthew Garrett m...@redhat.com wrote: On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote: + /* + * Only enable RC6 if all dma remapping is disabled, or if + * there's no iommu present in the machine. + */ + if (INTEL_INFO(dev)-gen == 6) + return no_iommu || dmar_disabled; So the user has to choose between 5W of power saving or having dmar? And we default to giving them dmar? From the latest investigations, it is either this, or random gpu hangs and crashes when both are enabled :(. So blacklist dmar on sandybridge. The power saving is going to be more important for most users. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Update GEN6_RP_CONTROL definitions
This matches the modern specs more accurately. This will be used by the following patch to fix the way we display RC status. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_reg.h |6 +- drivers/gpu/drm/i915/intel_display.c |2 +- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a34e866..44f8b75 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3469,7 +3469,11 @@ #define GEN6_CAGF_MASK (0x7f GEN6_CAGF_SHIFT) #define GEN6_RP_CONTROL0xA024 #define GEN6_RP_MEDIA_TURBO (111) -#define GEN6_RP_USE_NORMAL_FREQ (19) +#define GEN6_RP_MEDIA_MODE_MASK (39) +#define GEN6_RP_MEDIA_HW_TURBO_MODE (39) +#define GEN6_RP_MEDIA_HW_NORMAL_MODE (29) +#define GEN6_RP_MEDIA_HW_MODE(19) +#define GEN6_RP_MEDIA_SW_MODE(09) #define GEN6_RP_MEDIA_IS_GFX (18) #define GEN6_RP_ENABLE (17) #define GEN6_RP_UP_IDLE_MIN (0x13) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 591eb0ed..389cf79a 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7949,7 +7949,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv) I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10); I915_WRITE(GEN6_RP_CONTROL, GEN6_RP_MEDIA_TURBO | - GEN6_RP_USE_NORMAL_FREQ | + GEN6_RP_MEDIA_HW_MODE | GEN6_RP_MEDIA_IS_GFX | GEN6_RP_ENABLE | GEN6_RP_UP_BUSY_AVG | -- 1.7.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: drpc debugfs update for gen6
Many of the old fields from Ironlake have gone away. Strip all those
fields, and try to update to fields people care about. RC information
isn't exactly ideal anymore. All we can guarantee when we read the
register is that we're not using forcewake, ie. the software isn't
forcing the hardware to stay awake. The downside is that in doing this
we may wait a while and that causes an unnaturally idle state on the
GPU.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42578
Cc: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 82 ++-
drivers/gpu/drm/i915/i915_reg.h | 13 +-
2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f2e0207..74c3b55 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -999,7 +999,7 @@ static int i915_inttoext_table(struct seq_file *m, void
*unused)
return 0;
}
-static int i915_drpc_info(struct seq_file *m, void *unused)
+static int ironlake_drpc_info(struct seq_file *m)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
struct drm_device *dev = node-minor-dev;
@@ -1066,6 +1066,86 @@ static int i915_drpc_info(struct seq_file *m, void
*unused)
return 0;
}
+static int gen6_drpc_info(struct seq_file *m)
+{
+
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 rpmodectl1, gt_core_status, rcctl1;
+ int count=0, ret;
+
+ ret = mutex_lock_interruptible(dev-struct_mutex);
+ if (ret)
+ return ret;
+
+ /* NB: we cannot use forcewake, else we read the wrong values */
+ while (count++ 50 (I915_READ_NOTRACE(FORCEWAKE_ACK) 1))
+ udelay(10);
+
+ if (count == 50)
+ DRM_INFO(Couldn't get accurate RC information\n);
+
+ gt_core_status = readl(dev_priv-regs + GEN6_GT_CORE_STATUS);
+ trace_i915_reg_rw(false, GEN6_GT_CORE_STATUS, gt_core_status, 4);
+
+ rpmodectl1 = I915_READ(GEN6_RP_CONTROL);
+ rcctl1 = I915_READ(GEN6_RC_CONTROL);
+ mutex_unlock(dev-struct_mutex);
+
+ seq_printf(m, Video Turbo Mode: %s\n,
+ yesno(rpmodectl1 GEN6_RP_MEDIA_TURBO));
+ seq_printf(m, HW control enabled: %s\n,
+ yesno(rpmodectl1 GEN6_RP_ENABLE));
+ seq_printf(m, SW control enabled: %s\n,
+ yesno((rpmodectl1 GEN6_RP_MEDIA_MODE_MASK) ==
+ GEN6_RP_MEDIA_SW_MODE));
+ seq_printf(m, RC6 Enabled: %s\n,
+ yesno(rcctl1 GEN6_RC_CTL_RC1e_ENABLE));
+ seq_printf(m, RC6 Enabled: %s\n,
+ yesno(rcctl1 GEN6_RC_CTL_RC6_ENABLE));
+ seq_printf(m, Deep RC6 Enabled: %s\n,
+ yesno(rcctl1 GEN6_RC_CTL_RC6p_ENABLE));
+ seq_printf(m, Deepest RC6 Enabled: %s\n,
+ yesno(rcctl1 GEN6_RC_CTL_RC6pp_ENABLE));
+ seq_printf(m, Current RC state: );
+ switch (gt_core_status GEN6_RCn_MASK) {
+ case GEN6_RC0:
+ if (gt_core_status GEN6_CORE_CPD_STATE_MASK)
+ seq_printf(m, Core Power Down\n);
+ else
+ seq_printf(m, on\n);
+ break;
+ case GEN6_RC3:
+ seq_printf(m, RC3\n);
+ break;
+ case GEN6_RC6:
+ seq_printf(m, RC6\n);
+ break;
+ case GEN6_RC7:
+ seq_printf(m, RC7\n);
+ break;
+ default:
+ seq_printf(m, Unknown\n);
+ break;
+ }
+
+ seq_printf(m, Core Power Down: %s\n,
+ yesno(gt_core_status GEN6_CORE_CPD_STATE_MASK));
+ return 0;
+}
+
+static int i915_drpc_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+
+ if (IS_GEN6(dev) || IS_GEN7(dev))
+ return gen6_drpc_info(m);
+ else
+ return ironlake_drpc_info(m);
+}
+
static int i915_fbc_status(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 44f8b75..a1ffe6c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3449,8 +3449,11 @@
# define GEN6_RCCUNIT_CLOCK_GATE_DISABLE (1 11)
#define GEN6_RPNSWREQ 0xA008
+#define GEN6_GT_THREAD_P_REQ 0x13807C
#define GEN6_TURBO_DISABLE (131)
-#define GEN6_FREQUENCY(x)((x)25)
+#define GEN6_FREQUENCY_SHIFT 25
Re: [Intel-gfx] [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com wrote: So the user has to choose between 5W of power saving or having dmar? And we default to giving them dmar? I think that's going to come as a surprise to people. You'd have to go into the BIOS to turn this on for most machines at least? But, yeah, it seems like we should be turning DMAR off unless explicitly requested; I can't understand how you'd ever need this running native on the hardware. Not exactly an area I care about deeply; I've always worked hard to make sure all virtualization garbage is disabled on every machine I use. -- keith.pack...@intel.com pgp1bj6grFC77.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
