Re: [Intel-gfx] [PATCH] drm/i915: Better overclock support
On Wed, Apr 3, 2013 at 4:45 AM, Ben Widawsky b...@bwidawsk.net wrote:
Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also fixes an issue where if one sets the max frequency to be
below the overclock max, they wouldn't be able to set back the proper
overclock max.
In addition I've added a couple of other bits:
Show the overclock freq. as max in sysfs
Print the overclock max in debugfs.
Print a warning if the user sets the min frequency to be in the
overclock range.
In this patch I've decided to store the hw_max when we read it from the
pcode at init. The reason I do this is the pcode reads can fail, and are
slow.
Reported-by: freezer?
Signed-off-by: Ben Widawsky b...@bwidawsk.net
I think we should go one step further and set the default max to rp0 and
not the overclocked max. That way users can set the BIOS to the highest it
allows without risking that their machines will hang right away.
Then we could switch the debug printk to max (we don't really care about
the min being too high) and mark all such bugs as wontfix ;-)
-Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_sysfs.c | 12
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7df8351..f081bb3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1006,6 +1006,9 @@ static int i915_cur_delayinfo(struct seq_file *m,
void *unused)
max_freq = rp_state_cap 0xff;
seq_printf(m, Max non-overclocked (RP0) frequency:
%dMHz\n,
max_freq * GT_FREQUENCY_MULTIPLIER);
+
+ seq_printf(m, Max overclocked frequency: %dMHz\n,
+ dev_priv-rps.hw_max * GT_FREQUENCY_MULTIPLIER);
} else {
seq_printf(m, no P-state info available\n);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 1657d873..9b53b39c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -648,6 +648,7 @@ struct intel_gen6_power_mgmt {
u8 cur_delay;
u8 min_delay;
u8 max_delay;
+ u8 hw_max;
struct delayed_work delayed_resume_work;
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index a3a3e22..5faf1a7 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -226,7 +226,7 @@ static ssize_t gt_max_freq_mhz_show(struct device
*kdev, struct device_attribute
int ret;
mutex_lock(dev_priv-rps.hw_lock);
- ret = dev_priv-rps.max_delay * GT_FREQUENCY_MULTIPLIER;
+ ret = dev_priv-rps.hw_max * GT_FREQUENCY_MULTIPLIER;
mutex_unlock(dev_priv-rps.hw_lock);
return snprintf(buf, PAGE_SIZE, %d\n, ret);
@@ -251,7 +251,7 @@ static ssize_t gt_max_freq_mhz_store(struct device
*kdev,
mutex_lock(dev_priv-rps.hw_lock);
rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
- hw_max = (rp_state_cap 0xff);
+ hw_max = dev_priv-rps.hw_max;
hw_min = ((rp_state_cap 0xff) 16);
if (val hw_min || val hw_max || val dev_priv-rps.min_delay)
{
@@ -290,7 +290,7 @@ static ssize_t gt_min_freq_mhz_store(struct device
*kdev,
struct drm_minor *minor = container_of(kdev, struct drm_minor,
kdev);
struct drm_device *dev = minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 val, rp_state_cap, hw_max, hw_min;
+ u32 val, rp_state_cap, hw_max, hw_min, non_oc_max;
ssize_t ret;
ret = kstrtou32(buf, 0, val);
@@ -302,7 +302,8 @@ static ssize_t gt_min_freq_mhz_store(struct device
*kdev,
mutex_lock(dev_priv-rps.hw_lock);
rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
- hw_max = (rp_state_cap 0xff);
+ hw_max = dev_priv-rps.hw_max;
+ non_oc_max = (rp_state_cap 0xff);
hw_min = ((rp_state_cap 0xff) 16);
if (val hw_min || val hw_max || val dev_priv-rps.max_delay)
{
@@ -310,6 +311,9 @@ static ssize_t gt_min_freq_mhz_store(struct device
*kdev,
return -EINVAL;
}
+ if (val non_oc_max)
+ DRM_DEBUG(User selected overclocked frequency for min\n);
+
if (dev_priv-rps.cur_delay val)
gen6_set_rps(dev_priv-dev, val);
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index ce3db2c..2edb743 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++
Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
On Wed, Apr 03, 2013 at 01:43:49PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 (Revert
drm/i915: write backlight harder) from Linus' tree and commit
31ad8ec6a614 (drm/i915: group backlight related stuff into a struct)
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Looks good, I carry the same merge resolution locally.
-Daniel
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_panel.c
index bee8cb6,0e7e873..000
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@@ -318,9 -321,16 +321,13 @@@ void intel_panel_enable_backlight(struc
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (dev_priv-backlight_level == 0)
- dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ if (dev_priv-backlight.level == 0) {
+ dev_priv-backlight.level = intel_panel_get_max_backlight(dev);
+ if (dev_priv-backlight.device)
+ dev_priv-backlight.device-props.brightness =
+ dev_priv-backlight.level;
+ }
-dev_priv-backlight.enabled = true;
-intel_panel_actually_set_backlight(dev, dev_priv-backlight.level);
-
if (INTEL_INFO(dev)-gen = 4) {
uint32_t reg, tmp;
@@@ -356,12 -366,12 +363,12 @@@
}
set_level:
-/* Check the current backlight level and try to set again if it's zero.
- * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
- * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
+/* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
+ * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
+ * registers are set.
*/
- dev_priv-backlight_enabled = true;
- intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
-if (!intel_panel_get_backlight(dev))
-intel_panel_actually_set_backlight(dev,
dev_priv-backlight.level);
++dev_priv-backlight.enabled = true;
++intel_panel_actually_set_backlight(dev, dev_priv-backlight.level);
}
static void intel_panel_init_backlight(struct drm_device *dev)
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix sdvo connector get_hw_state function
On Tue, Apr 02, 2013 at 09:30:34PM +0200, Daniel Vetter wrote: The active output is only the currently selected one, which does not imply that it's actually enabled. Since we don't use the sdvo encoder side dpms support, we need to check whether the chip-side sdvo port is enabled instead. v2: Fix up Bugzilla links. v3: Simplify logic a bit (Chris). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60138 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031 Cc: Egbert Eich e...@pdx.freedesktop.org Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Queued for next with a cc: stable tag. Since it's just mostly harmless warnings imo not something for -fixes right away. -Daniel --- drivers/gpu/drm/i915/intel_sdvo.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 33b46d9..35187d9 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1219,8 +1219,12 @@ static bool intel_sdvo_connector_get_hw_state(struct intel_connector *connector) struct intel_sdvo_connector *intel_sdvo_connector = to_intel_sdvo_connector(connector-base); struct intel_sdvo *intel_sdvo = intel_attached_sdvo(connector-base); + struct drm_i915_private *dev_priv = intel_sdvo-base.base.dev-dev_private; u16 active_outputs; + if (!(I915_READ(intel_sdvo-sdvo_reg) SDVO_ENABLE)) + return false; + intel_sdvo_get_active_outputs(intel_sdvo, active_outputs); if (active_outputs intel_sdvo_connector-output_flag) -- 1.7.10.4 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Tue, Mar 26, 2013 at 09:25:45AM -0700, Jesse Barnes wrote:
With the other bits in place, we can do this safely.
v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Something seems to be race with this, occasionally when resuming my vt is
on the X session (at least nothing happens when I try to switch to it),
the cursor is enabled, but I see the kernel console window.
Doing a vt switch to a non-X console and back to X fixes things. I haven't
looked exactly where we could race ...
-Daniel
---
drivers/gpu/drm/i915/i915_drv.c | 14 +++---
drivers/gpu/drm/i915/intel_fb.c |3 +++
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c4b13c..bf57e1c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -458,6 +458,7 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
static int i915_drm_freeze(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc;
/* ignore lid events during suspend */
mutex_lock(dev_priv-modeset_restore_lock);
@@ -481,10 +482,14 @@ static int i915_drm_freeze(struct drm_device *dev)
cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work);
- intel_modeset_disable(dev);
-
drm_irq_uninstall(dev);
dev_priv-enable_hotplug_processing = false;
+ /*
+ * Disable CRTCs directly since we want to preserve sw state
+ * for _thaw.
+ */
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
+ dev_priv-display.crtc_disable(crtc);
}
i915_save_state(dev);
@@ -562,7 +567,10 @@ static int __i915_drm_thaw(struct drm_device *dev)
drm_irq_install(dev);
intel_modeset_init_hw(dev);
- intel_modeset_setup_hw_state(dev, false);
+
+ drm_modeset_lock_all(dev);
+ intel_modeset_setup_hw_state(dev, true);
+ drm_modeset_unlock_all(dev);
/*
* ... but also need to make sure that hotplug processing
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index f203418..8d81c929 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -150,6 +150,9 @@ static int intelfb_create(struct drm_fb_helper *helper,
}
info-screen_size = size;
+ /* This driver doesn't need a VT switch to restore the mode on resume */
+ info-skip_vt_switch = true;
+
drm_fb_helper_fill_fix(info, fb-pitches[0], fb-depth);
drm_fb_helper_fill_var(info, ifbdev-helper, sizes-fb_width,
sizes-fb_height);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: create pipe_config-dpll for clock state
On Tue, Apr 02, 2013 at 02:14:23PM -0700, Jesse Barnes wrote: This one's hard to review since you mixed in a drm_crtc-intel_crtc function arg change. I'd rather have that split out, but it looks ok. Yeah, I've fumbled this one a bit, but decided to punt on the split-up. Generally I'm always a bit unsure when exactly we should do rote refactoring like this: We have a similar conversion going on from drm_encoder-intel_encoder, also with the switch away from the drm crtc helper vtables to our own. Usually I don't switch code I don't yet touch (Paulo complained about that, too) since such massive sed jobs simply make patch rebasing complete hell. Both for me, but also for anyone else with an in-flight patch series touching the same area. But once in a while I get fed up and convert a few more things while touching them, leading the slightly ugly patches ... Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org Thanks for the review, entire series is merged for -next. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Introduce i9xx_set_pipeconf()
On Tue, 02 Apr 2013, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Extract the PIPECONF setup into i9xx_set_pipeconf(). This makes the
=Gen4/VLV code follow the same pattern as the Gen5+ codepaths.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 123
+++
1 file changed, 68 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 298bc0c..dfaea15 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4514,6 +4514,71 @@ static void intel_set_pipe_timings(struct intel_crtc
*intel_crtc,
((mode-hdisplay - 1) 16) | (mode-vdisplay - 1));
}
+static void i9xx_set_pipeconf(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted_mode,
+ bool is_dp)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
+ u32 pipeconf;
+
+ /* setup pipeconf */
+ pipeconf = I915_READ(PIPECONF(pipe));
+
+ if (pipe == 0 INTEL_INFO(dev)-gen 4) {
+ /* Enable pixel doubling when the dot clock is 90% of the
(display)
+ * core speed.
+ *
+ * XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
+ * pipe == 0 check?
+ */
+ if (mode-clock
+ dev_priv-display.get_display_clock_speed(dev) * 9 / 10)
+ pipeconf |= PIPECONF_DOUBLE_WIDE;
+ else
+ pipeconf = ~PIPECONF_DOUBLE_WIDE;
+ }
+
+ /* default to 8bpc */
+ pipeconf = ~(PIPECONF_BPC_MASK | PIPECONF_DITHER_EN);
+ if (is_dp intel_crtc-config.dither) {
+ pipeconf |= PIPECONF_6BPC |
+ PIPECONF_DITHER_EN |
+ PIPECONF_DITHER_TYPE_SP;
+ }
+
+ if (IS_VALLEYVIEW(dev)
+ intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)
+ intel_crtc-config.dither) {
+ pipeconf |= PIPECONF_6BPC |
+ PIPECONF_ENABLE |
+ I965_PIPECONF_ACTIVE;
+ }
+
+ if (HAS_PIPE_CXSR(dev)) {
+ if (intel_crtc-lowfreq_avail) {
+ DRM_DEBUG_KMS(enabling CxSR downclocking\n);
+ pipeconf |= PIPECONF_CXSR_DOWNCLOCK;
+ } else {
+ DRM_DEBUG_KMS(disabling CxSR downclocking\n);
+ pipeconf = ~PIPECONF_CXSR_DOWNCLOCK;
+ }
+ }
+
+ pipeconf = ~PIPECONF_INTERLACE_MASK;
+ if (!IS_GEN2(dev)
+ adjusted_mode-flags DRM_MODE_FLAG_INTERLACE)
+ pipeconf |= PIPECONF_INTERLACE_W_FIELD_INDICATION;
+ else
+ pipeconf |= PIPECONF_PROGRESSIVE;
+
+ I915_WRITE(PIPECONF(pipe), pipeconf);
+ POSTING_READ(PIPECONF(pipe));
+}
+
static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
int x, int y,
struct drm_framebuffer *fb)
@@ -4528,7 +4593,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
int plane = intel_crtc-plane;
int refclk, num_connectors = 0;
intel_clock_t clock, reduced_clock;
- u32 dspcntr, pipeconf;
+ u32 dspcntr;
bool ok, has_reduced_clock = false, is_sdvo = false;
bool is_lvds = false, is_tv = false, is_dp = false;
struct intel_encoder *encoder;
@@ -4605,9 +4670,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
has_reduced_clock ? reduced_clock : NULL,
num_connectors);
- /* setup pipeconf */
- pipeconf = I915_READ(PIPECONF(pipe));
-
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -4618,58 +4680,9 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
dspcntr |= DISPPLANE_SEL_PIPE_B;
}
- if (pipe == 0 INTEL_INFO(dev)-gen 4) {
- /* Enable pixel doubling when the dot clock is 90% of the
(display)
- * core speed.
- *
- * XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
- * pipe == 0 check?
- */
- if (mode-clock
- dev_priv-display.get_display_clock_speed(dev) * 9 / 10)
- pipeconf |= PIPECONF_DOUBLE_WIDE;
- else
- pipeconf = ~PIPECONF_DOUBLE_WIDE;
- }
-
- /* default to 8bpc */
- pipeconf = ~(PIPECONF_BPC_MASK |
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Set PIPECONF color range bit on Valleyview
On Tue, 02 Apr 2013, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
VLV has the color range selection bit in the PIPECONF register.
Configure it appropriately.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dfaea15..e49d86a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4575,6 +4575,13 @@ static void i9xx_set_pipeconf(struct drm_crtc *crtc,
else
pipeconf |= PIPECONF_PROGRESSIVE;
+ if (IS_VALLEYVIEW(dev)) {
+ if (intel_crtc-config.limited_color_range)
+ pipeconf |= PIPECONF_COLOR_RANGE_SELECT;
+ else
+ pipeconf = ~PIPECONF_COLOR_RANGE_SELECT;
+ }
+
I915_WRITE(PIPECONF(pipe), pipeconf);
POSTING_READ(PIPECONF(pipe));
}
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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: Don't use the HDMI port color range bit on Valleyview
On Tue, 02 Apr 2013, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com VLV docs still list the the color range selection bit for the HDMI ports, but for DP ports it has been repurposed. I have no idea whether the HDMI color range selection bit still works on VLV, but since we now have to use the PIPECONF color range bit for DP, we might as well do the same for HDMI. I don't have any additional information on this. The patch does what it says above, so for that: Reviewed-by: Jani Nikula jani.nik...@intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index b206a0d..ee4a8da 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -602,7 +602,7 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder, u32 hdmi_val; hdmi_val = SDVO_ENCODING_HDMI; - if (!HAS_PCH_SPLIT(dev)) + if (!HAS_PCH_SPLIT(dev) !IS_VALLEYVIEW(dev)) hdmi_val |= intel_hdmi-color_range; if (adjusted_mode-flags DRM_MODE_FLAG_PVSYNC) hdmi_val |= SDVO_VSYNC_ACTIVE_HIGH; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Wed, Apr 03, 2013 at 11:15:40AM +0200, Daniel Vetter wrote: On Tue, Mar 26, 2013 at 09:25:45AM -0700, Jesse Barnes wrote: With the other bits in place, we can do this safely. v2: disable backlight on suspend to prevent premature enablement on resume v3: disable CRTCs on suspend to allow RTD3 (Kristen) Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Something seems to be race with this, occasionally when resuming my vt is on the X session (at least nothing happens when I try to switch to it), the cursor is enabled, but I see the kernel console window. Doing a vt switch to a non-X console and back to X fixes things. I haven't looked exactly where we could race ... This might be a DRM_MASTER race, if X fails to gain DRM_MASTER its takeover is postponed indefinitely. Any clues in Xorg.0.log? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] [v3] drm/i915: reference count for i915_hw_contexts
On Tue, Apr 02, 2013 at 06:27:00PM -0700, Ben Widawsky wrote: On Tue, Apr 02, 2013 at 03:45:42PM -0700, Ben Widawsky wrote: From: Mika Kuoppala mika.kuopp...@linux.intel.com In preparation to do analysis of which context was guilty of gpu hung, store kreffed context pointer into request struct. This allows us to inspect contexts when gpu is reset even if those contexts would already be released by userspace. v2: track i915_hw_context pointers instead of using ctx_ids (from Chris Wilson) v3 (Ben): Get rid of do_release() and handle refcounting more compactly. (recommended by Chris) Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net Now I remember why my version of reference counting was so much more complicated. In my case, I want to keep the last context around instead of the last context object. To do this we can't do a kref_put until we've switched to the next context (similar to how we manage the context object). I want to do this since the context stores the PPGTT which will currently be in use. I need to switch PDEs at context switch time. This seems feasible using requests and a callback from retire. The alternative is something hairy like intel_overlay, hence my desire for keeping all ring operations as a i915_gem_request. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Wed, 3 Apr 2013 11:54:23 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Apr 03, 2013 at 11:15:40AM +0200, Daniel Vetter wrote: On Tue, Mar 26, 2013 at 09:25:45AM -0700, Jesse Barnes wrote: With the other bits in place, we can do this safely. v2: disable backlight on suspend to prevent premature enablement on resume v3: disable CRTCs on suspend to allow RTD3 (Kristen) Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Something seems to be race with this, occasionally when resuming my vt is on the X session (at least nothing happens when I try to switch to it), the cursor is enabled, but I see the kernel console window. Doing a vt switch to a non-X console and back to X fixes things. I haven't looked exactly where we could race ... This might be a DRM_MASTER race, if X fails to gain DRM_MASTER its takeover is postponed indefinitely. Any clues in Xorg.0.log? Yeah, David said he saw this even w/o the VT switch patches. I've seen this bug too, maybe the lack of a VT switch makes the race a little more likely? -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
On Wed, Apr 03, 2013 at 02:34:11PM +0200, Christian Lamparter wrote:
The Mobile Sandy Bridge CPUs in the Fujitsu Esprimo Q900
mini desktop PCs are probably misleading the LVDS detection
code in intel_lvds_supported. Nothing is connected to the
LVDS ports in these systems.
Signed-off-by: Christian Lamparter chunk...@googlemail.com
So despite that snb has a bit who's _only_ purpose is to allow the bios to
tell the driver whether there's an lvds output or not, someone screwed it
finally up :( We just can't win against the firmware ...
Queued for -next with cc: stable, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 3d1d974..65893b0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -850,6 +850,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_PRODUCT_NAME, X7SPA-H),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = Fujitsu Esprimo Q900,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, FUJITSU),
+ DMI_MATCH(DMI_PRODUCT_NAME, ESPRIMO Q900),
+ },
+ },
{ } /* terminating entry */
};
--
1.7.10.4
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: drop the coditional mutex
mutex_is_locked_by() checks the owner of the lock against current. This
is done by accessing a private member of struct mutex which works on
mainline but does not on RT.
I did not figure out, why this lock-owner-check and the lock stealing
flag is required. If the lock can not be acquire the lock (because it
would deadlock) then it can return -1.
The lock stealing makes actually no sense to me. If
shrinker_no_lock_stealing is true then the same functions
(i915_gem_purge(), i915_gem_shrink_all()) are called from
i915_gem_object_create_mmap_offset() as from i915_gem_inactive_shrink().
I haven't found a path in which i915_gem_inactive_shrink() is invoked
from i915_gem_object_create_mmap_offset() that means there is no way
shrinker_no_lock_stealing is true _and_ the lock is owned by the current
process.
Since I don't see why the i915 needs this hack while all other user do
not I recommend to remove this hack and return -1 in case of a dead
lock. Here is the patch.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 32 +++-
2 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01769e2..47f28ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -724,7 +724,6 @@ struct i915_gem_mm {
struct i915_hw_ppgtt *aliasing_ppgtt;
struct shrinker inactive_shrinker;
- bool shrinker_no_lock_stealing;
/**
* List of objects currently involved in rendering.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e207e6..7949517 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1500,8 +1500,6 @@ static int i915_gem_object_create_mmap_offset(struct
drm_i915_gem_object *obj)
if (obj-base.map_list.map)
return 0;
- dev_priv-mm.shrinker_no_lock_stealing = true;
-
ret = drm_gem_create_mmap_offset(obj-base);
if (ret != -ENOSPC)
goto out;
@@ -1521,8 +1519,6 @@ static int i915_gem_object_create_mmap_offset(struct
drm_i915_gem_object *obj)
i915_gem_shrink_all(dev_priv);
ret = drm_gem_create_mmap_offset(obj-base);
out:
- dev_priv-mm.shrinker_no_lock_stealing = false;
-
return ret;
}
@@ -4368,19 +4364,6 @@ void i915_gem_release(struct drm_device *dev, struct
drm_file *file)
spin_unlock(file_priv-mm.lock);
}
-static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
-{
- if (!mutex_is_locked(mutex))
- return false;
-
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
- return mutex-owner == task;
-#else
- /* Since UP may be pre-empted, we cannot assume that we own the lock */
- return false;
-#endif
-}
-
static int
i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc)
{
@@ -4391,18 +4374,10 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
struct shrink_control *sc)
struct drm_device *dev = dev_priv-dev;
struct drm_i915_gem_object *obj;
int nr_to_scan = sc-nr_to_scan;
- bool unlock = true;
int cnt;
- if (!mutex_trylock(dev-struct_mutex)) {
- if (!mutex_is_locked_by(dev-struct_mutex, current))
- return 0;
-
- if (dev_priv-mm.shrinker_no_lock_stealing)
- return 0;
-
- unlock = false;
- }
+ if (!mutex_trylock(dev-struct_mutex))
+ return -1;
if (nr_to_scan) {
nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan);
@@ -4421,7 +4396,6 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
struct shrink_control *sc)
if (obj-pin_count == 0 obj-pages_pin_count == 0)
cnt += obj-base.size PAGE_SHIFT;
- if (unlock)
- mutex_unlock(dev-struct_mutex);
+ mutex_unlock(dev-struct_mutex);
return cnt;
}
--
1.7.6.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
The Mobile Sandy Bridge CPUs in the Fujitsu Esprimo Q900
mini desktop PCs are probably misleading the LVDS detection
code in intel_lvds_supported. Nothing is connected to the
LVDS ports in these systems.
Signed-off-by: Christian Lamparter chunk...@googlemail.com
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 3d1d974..65893b0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -850,6 +850,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_PRODUCT_NAME, X7SPA-H),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = Fujitsu Esprimo Q900,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, FUJITSU),
+ DMI_MATCH(DMI_PRODUCT_NAME, ESPRIMO Q900),
+ },
+ },
{ } /* terminating entry */
};
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
Hi all, Two things: - Please _always_ include a public mailing list when reporting bugs, your dear maintainer sometimes slacks off. - We need to see the error_state before we can assess what kind of hang you have (it's like gettting a SIGSEGV for a normal program, no two gpu hangs are the same ...). Cheers, Daniel On Wed, Apr 3, 2013 at 5:42 PM, Dihan Wickremasuriya dwickremasur...@rethinkrobotics.com wrote: Hi Chris/Daniel, This is Dihan from Rethink Robotics and we were hoping you could help with the GPU hang problem in the i915 driver mentioned in bug #26345: https://bugs.freedesktop.org/show_bug.cgi?id=26345 We are running into the same problem with the 3.8.5 kernel (which has the fix mentioned in comment #153 of the bug report) when running a Qt 5 application in Gentoo. At times the entire X session would freeze. The x11-perf tests described in the bug report run without any issues though. Would you happen to know whether this is because of an issue in the driver that is not currently being addressed by the fix? I have attached the Xorg log, the dmesg output and i915_error_state from a hung session. Please let me know if you need any more info. Thanks in advance! Best regards, Dihan -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] GPU Hang in Intel Driver
On Wed, Apr 3, 2013 at 5:58 PM, Dihan Wickremasuriya dwickremasur...@rethinkrobotics.com wrote: Thanks for the quick response and adding the mailing list. I did in fact attach the error_state in my original mail. Please let me know if it's not the one you were looking for (re-attached). Oops, missed that one. You have a gen7 ivb machine, so the bug you've reference is _definitely_ not yours - that one's for gen2. Now looking at your error state I've noticed that your mesa is using a massively outdated version of 3DSTATE_HIER_DEPTH_BUFFER, which has been fixed with 8.0, the broken version shipped with 7.11. Please upgrade to the latest released versions of mesa, libdrm, xf86-video-intel, your bug is very likely fixed already (since 8.0 is pretty old for gen7). Yours, Daniel Also added a subject to the thread. Best regards, Dihan On Wed, Apr 3, 2013 at 11:46 AM, Daniel Vetter daniel.vet...@ffwll.chwrote: Hi all, Two things: - Please _always_ include a public mailing list when reporting bugs, your dear maintainer sometimes slacks off. - We need to see the error_state before we can assess what kind of hang you have (it's like gettting a SIGSEGV for a normal program, no two gpu hangs are the same ...). Cheers, Daniel On Wed, Apr 3, 2013 at 5:42 PM, Dihan Wickremasuriya dwickremasur...@rethinkrobotics.com wrote: Hi Chris/Daniel, This is Dihan from Rethink Robotics and we were hoping you could help with the GPU hang problem in the i915 driver mentioned in bug #26345: https://bugs.freedesktop.org/show_bug.cgi?id=26345 We are running into the same problem with the 3.8.5 kernel (which has the fix mentioned in comment #153 of the bug report) when running a Qt 5 application in Gentoo. At times the entire X session would freeze. The x11-perf tests described in the bug report run without any issues though. Would you happen to know whether this is because of an issue in the driver that is not currently being addressed by the fix? I have attached the Xorg log, the dmesg output and i915_error_state from a hung session. Please let me know if you need any more info. Thanks in advance! Best regards, Dihan -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel-decode: Fix gen6 HIER_DEPTH_BUFFER decoding
It accidentally used the cmd id for the gen7 command and had an
outdated lenght field. Spotted while trying to make sense of an ivb
error_state from mesa 7.11 ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
intel/intel_decode.c |2 +-
intel/tests/gen6-3d.batch-ref.txt |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 842921b..ff19f92 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3162,7 +3162,7 @@ decode_3d_965(struct drm_intel_decode *ctx)
{ 0x7805, 0x00ff, 3, 3, 3DSTATE_URB },
{ 0x7804, 0x00ff, 3, 3, 3DSTATE_CLEAR_PARAMS },
{ 0x7806, 0x00ff, 3, 3, 3DSTATE_STENCIL_BUFFER },
- { 0x7807, 0x00ff, 4, 4, 3DSTATE_HIER_DEPTH_BUFFER, 6 },
+ { 0x790f, 0x00ff, 3, 3, 3DSTATE_HIER_DEPTH_BUFFER, 6 },
{ 0x7807, 0x00ff, 3, 3, 3DSTATE_HIER_DEPTH_BUFFER, 7,
gen7_3DSTATE_HIER_DEPTH_BUFFER },
{ 0x7808, 0x00ff, 5, 257, 3DSTATE_VERTEX_BUFFERS },
{ 0x7809, 0x00ff, 3, 256, 3DSTATE_VERTEX_ELEMENTS },
diff --git a/intel/tests/gen6-3d.batch-ref.txt
b/intel/tests/gen6-3d.batch-ref.txt
index 9499ed1..9035663 100644
--- a/intel/tests/gen6-3d.batch-ref.txt
+++ b/intel/tests/gen6-3d.batch-ref.txt
@@ -146,9 +146,9 @@
0x12300244: 0x:volume depth
0x12300248: 0x:
0x1230024c: 0x:
-0x12300250: 0x790f0001: 3D UNKNOWN: 3d_965 opcode = 0x790f
-0x12300254: 0x05ff: MI_NOOP
-0x12300258: 0x: MI_NOOP
+0x12300250: 0x790f0001: 3DSTATE_HIER_DEPTH_BUFFER
+0x12300254: 0x05ff:dword 1
+0x12300258: 0x:dword 2
0x1230025c: 0x790e0001: 3D UNKNOWN: 3d_965 opcode = 0x790e
0x12300260: 0x027f: MI_NOOP
0x12300264: 0x: MI_NOOP
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] [v3] drm/i915: reference count for i915_hw_contexts
On Wed, Apr 03, 2013 at 12:56:11PM +0100, Chris Wilson wrote: On Tue, Apr 02, 2013 at 06:27:00PM -0700, Ben Widawsky wrote: On Tue, Apr 02, 2013 at 03:45:42PM -0700, Ben Widawsky wrote: From: Mika Kuoppala mika.kuopp...@linux.intel.com In preparation to do analysis of which context was guilty of gpu hung, store kreffed context pointer into request struct. This allows us to inspect contexts when gpu is reset even if those contexts would already be released by userspace. v2: track i915_hw_context pointers instead of using ctx_ids (from Chris Wilson) v3 (Ben): Get rid of do_release() and handle refcounting more compactly. (recommended by Chris) Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net Now I remember why my version of reference counting was so much more complicated. In my case, I want to keep the last context around instead of the last context object. To do this we can't do a kref_put until we've switched to the next context (similar to how we manage the context object). I want to do this since the context stores the PPGTT which will currently be in use. I need to switch PDEs at context switch time. This seems feasible using requests and a callback from retire. The alternative is something hairy like intel_overlay, hence my desire for keeping all ring operations as a i915_gem_request. As long as the request object keeps a ref while the request is still oustanding and the ring itself keeps a ref to whatever is the currently last scheduled context, everything should work out fine. So I don't think we need to jump through any complicated hoops here. One quick bikeshed on the patch itself though: I'd like to see some static inlines for kref_get/put on contexts ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Introduce i9xx_set_pipeconf()
On Wed, Apr 03, 2013 at 01:08:16PM +0300, Jani Nikula wrote:
On Tue, 02 Apr 2013, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Extract the PIPECONF setup into i9xx_set_pipeconf(). This makes the
=Gen4/VLV code follow the same pattern as the Gen5+ codepaths.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Queued for -next with a pretty massive bikeshed (extended conflict
resolutions ftw), thanks for the patch.
-Daniel
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 123
+++
1 file changed, 68 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 298bc0c..dfaea15 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4514,6 +4514,71 @@ static void intel_set_pipe_timings(struct intel_crtc
*intel_crtc,
((mode-hdisplay - 1) 16) | (mode-vdisplay - 1));
}
+static void i9xx_set_pipeconf(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted_mode,
+ bool is_dp)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
+ u32 pipeconf;
+
+ /* setup pipeconf */
+ pipeconf = I915_READ(PIPECONF(pipe));
+
+ if (pipe == 0 INTEL_INFO(dev)-gen 4) {
+ /* Enable pixel doubling when the dot clock is 90% of the
(display)
+* core speed.
+*
+* XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
+* pipe == 0 check?
+*/
+ if (mode-clock
+ dev_priv-display.get_display_clock_speed(dev) * 9 / 10)
+ pipeconf |= PIPECONF_DOUBLE_WIDE;
+ else
+ pipeconf = ~PIPECONF_DOUBLE_WIDE;
+ }
+
+ /* default to 8bpc */
+ pipeconf = ~(PIPECONF_BPC_MASK | PIPECONF_DITHER_EN);
+ if (is_dp intel_crtc-config.dither) {
+ pipeconf |= PIPECONF_6BPC |
+ PIPECONF_DITHER_EN |
+ PIPECONF_DITHER_TYPE_SP;
+ }
+
+ if (IS_VALLEYVIEW(dev)
+ intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)
+ intel_crtc-config.dither) {
+ pipeconf |= PIPECONF_6BPC |
+ PIPECONF_ENABLE |
+ I965_PIPECONF_ACTIVE;
+ }
+
+ if (HAS_PIPE_CXSR(dev)) {
+ if (intel_crtc-lowfreq_avail) {
+ DRM_DEBUG_KMS(enabling CxSR downclocking\n);
+ pipeconf |= PIPECONF_CXSR_DOWNCLOCK;
+ } else {
+ DRM_DEBUG_KMS(disabling CxSR downclocking\n);
+ pipeconf = ~PIPECONF_CXSR_DOWNCLOCK;
+ }
+ }
+
+ pipeconf = ~PIPECONF_INTERLACE_MASK;
+ if (!IS_GEN2(dev)
+ adjusted_mode-flags DRM_MODE_FLAG_INTERLACE)
+ pipeconf |= PIPECONF_INTERLACE_W_FIELD_INDICATION;
+ else
+ pipeconf |= PIPECONF_PROGRESSIVE;
+
+ I915_WRITE(PIPECONF(pipe), pipeconf);
+ POSTING_READ(PIPECONF(pipe));
+}
+
static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
int x, int y,
struct drm_framebuffer *fb)
@@ -4528,7 +4593,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
int plane = intel_crtc-plane;
int refclk, num_connectors = 0;
intel_clock_t clock, reduced_clock;
- u32 dspcntr, pipeconf;
+ u32 dspcntr;
bool ok, has_reduced_clock = false, is_sdvo = false;
bool is_lvds = false, is_tv = false, is_dp = false;
struct intel_encoder *encoder;
@@ -4605,9 +4670,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
has_reduced_clock ? reduced_clock : NULL,
num_connectors);
- /* setup pipeconf */
- pipeconf = I915_READ(PIPECONF(pipe));
-
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -4618,58 +4680,9 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
dspcntr |= DISPPLANE_SEL_PIPE_B;
}
- if (pipe == 0 INTEL_INFO(dev)-gen 4) {
- /* Enable pixel doubling when the dot clock is 90% of the
(display)
-* core speed.
-*
-* XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
-* pipe == 0 check?
-*/
- if (mode-clock
- dev_priv-display.get_display_clock_speed(dev) * 9 / 10)
- pipeconf |= PIPECONF_DOUBLE_WIDE;
- else
-
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Don't use the HDMI port color range bit on Valleyview
On Wed, Apr 03, 2013 at 12:33:31PM +0300, Jani Nikula wrote: On Tue, 02 Apr 2013, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com VLV docs still list the the color range selection bit for the HDMI ports, but for DP ports it has been repurposed. I have no idea whether the HDMI color range selection bit still works on VLV, but since we now have to use the PIPECONF color range bit for DP, we might as well do the same for HDMI. I don't have any additional information on this. The patch does what it says above, so for that: Reviewed-by: Jani Nikula jani.nik...@intel.com Patches 2/3 also queued for -next, thanks for the patch. -Daniel Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index b206a0d..ee4a8da 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -602,7 +602,7 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder, u32 hdmi_val; hdmi_val = SDVO_ENCODING_HDMI; - if (!HAS_PCH_SPLIT(dev)) + if (!HAS_PCH_SPLIT(dev) !IS_VALLEYVIEW(dev)) hdmi_val |= intel_hdmi-color_range; if (adjusted_mode-flags DRM_MODE_FLAG_PVSYNC) hdmi_val |= SDVO_VSYNC_ACTIVE_HIGH; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't override PPGTT cacheability on HSW
Apparently these ECOCHK bits changed on HSW and the behavior is not what
we want. I've not been able to find VLV definition specifically so I'll
assume it's the same as IVB.
(Only compile tested)
Reported-by: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4cbae7b..01cf805 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -322,11 +322,11 @@ void i915_gem_init_ppgtt(struct drm_device *dev)
I915_WRITE(GAM_ECOCHK, ecochk | ECOCHK_SNB_BIT |
ECOCHK_PPGTT_CACHE64B);
I915_WRITE(GFX_MODE, _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
- } else if (INTEL_INFO(dev)-gen = 7) {
+ } else if (INTEL_INFO(dev)-gen = 7 !IS_HASWELL(dev)) {
I915_WRITE(GAM_ECOCHK, ECOCHK_PPGTT_CACHE64B);
- /* GFX_MODE is per-ring on gen7+ */
}
+ /* GFX_MODE is per-ring on gen7+ */
for_each_ring(ring, dev_priv, i) {
if (INTEL_INFO(dev)-gen = 7)
I915_WRITE(RING_MODE_GEN7(ring),
--
1.8.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't override PPGTT cacheability on HSW
On 04/03/2013 11:06 AM, Ben Widawsky wrote: Apparently these ECOCHK bits changed on HSW and the behavior is not what we want. I've not been able to find VLV definition specifically so I'll assume it's the same as IVB. (Only compile tested) Reported-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Ben Widawsky b...@bwidawsk.net The behavior isn't particularly bad, but the PTEs already take care of this for us, so it doesn't do anything. That said, having random override bits set for no purpose is bad...we should just let the PTEs do their job. Reviewed-and-tested-by: Kenneth Graunke kenn...@whitecape.org Thanks Ben! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't override PPGTT cacheability on HSW
On Wed, Apr 3, 2013 at 9:17 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 04/03/2013 11:06 AM, Ben Widawsky wrote: Apparently these ECOCHK bits changed on HSW and the behavior is not what we want. I've not been able to find VLV definition specifically so I'll assume it's the same as IVB. (Only compile tested) Reported-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Ben Widawsky b...@bwidawsk.net The behavior isn't particularly bad, but the PTEs already take care of this for us, so it doesn't do anything. That said, having random override bits set for no purpose is bad...we should just let the PTEs do their job. Reviewed-and-tested-by: Kenneth Graunke kenn...@whitecape.org This bit is used to set the cachability of the ppgtt PTEs themselves, _not_ the data pointed at by the ptes. We very much want that, it's after all the only reason we have enabled aliasing ppgtt support on snb/ivb. Iirc the speedup was around 10-20% on some benchmarks, disabling this bit here complety killed these improvements. Also, if you disable llc caching, the cpu pte writes aren't coherent any more with what the gt reads, so I'm pretty sure that this will blow up somewhere on one of our more nasty igt tests. So I've checked hsw bspec and the problem is that hw guys again changed the bits around a bit, and I think on HSW we actually want (0x8 3) instead of what's currently there. Could also be that on hsw the hw now supports pte cachability control in the pdes, but at least on snb/ivb that part didn't really work. And bspec is a bit an unclear mess in that area ... Since we should be ok with the override I don't think it's worth time to investigate this more. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't override PPGTT cacheability on HSW
On Wed, Apr 3, 2013 at 9:33 PM, Daniel Vetter dan...@ffwll.ch wrote: So I've checked hsw bspec and the problem is that hw guys again changed the bits around a bit, and I think on HSW we actually want (0x8 3) instead of what's currently there. Meh, I've screwed up reading the tables, 0x3 3 is what we imo want, so nothing needs to be changed. Sorry for the confusion. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't override PPGTT cacheability on HSW
On Wed, Apr 03, 2013 at 10:08:26PM +0200, Daniel Vetter wrote: On Wed, Apr 3, 2013 at 9:33 PM, Daniel Vetter dan...@ffwll.ch wrote: So I've checked hsw bspec and the problem is that hw guys again changed the bits around a bit, and I think on HSW we actually want (0x8 3) instead of what's currently there. Meh, I've screwed up reading the tables, 0x3 3 is what we imo want, so nothing needs to be changed. Sorry for the confusion. -Daniel I think the existing code is magic that we don't/shouldn't need. But I also see no reason to change it. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] GPU Hang in Intel Driver
On Wed, Apr 03, 2013 at 04:54:31PM -0400, Dihan Wickremasuriya wrote: mesa 8.0.4-r1, libdrm 2.4.43 and xf86-video-intel 2.21.5 on top of kernel 3.8.5 seems to work well. No hangs or crashes so far. Thank you very much for your help with this! Would you also happen to know where I can get a patch of the i915 kernel fix that has been backported to version 3.2? The kernel fix from the bug report you've cited does not apply to your platform. For your platform I'm not sure about the support status on vanilla 3.2 kernels, but distro's tend to backport the entire drm directory anyway. -Daniel Best regards, Dihan On Wed, Apr 3, 2013 at 1:02 PM, Dihan Wickremasuriya dwickremasur...@rethinkrobotics.com wrote: Will try mesa 8.0 or newer and report back. I had already bumped up libdrm and xf86-video-intel to the latest available (2.4.43 and 2.21.5 respectively). Thanks, Dihan On Wed, Apr 3, 2013 at 12:21 PM, Daniel Vetter daniel.vet...@ffwll.chwrote: On Wed, Apr 3, 2013 at 5:58 PM, Dihan Wickremasuriya dwickremasur...@rethinkrobotics.com wrote: Thanks for the quick response and adding the mailing list. I did in fact attach the error_state in my original mail. Please let me know if it's not the one you were looking for (re-attached). Oops, missed that one. You have a gen7 ivb machine, so the bug you've reference is _definitely_ not yours - that one's for gen2. Now looking at your error state I've noticed that your mesa is using a massively outdated version of 3DSTATE_HIER_DEPTH_BUFFER, which has been fixed with 8.0, the broken version shipped with 7.11. Please upgrade to the latest released versions of mesa, libdrm, xf86-video-intel, your bug is very likely fixed already (since 8.0 is pretty old for gen7). Yours, Daniel Also added a subject to the thread. Best regards, Dihan On Wed, Apr 3, 2013 at 11:46 AM, Daniel Vetter daniel.vet...@ffwll.chwrote: Hi all, Two things: - Please _always_ include a public mailing list when reporting bugs, your dear maintainer sometimes slacks off. - We need to see the error_state before we can assess what kind of hang you have (it's like gettting a SIGSEGV for a normal program, no two gpu hangs are the same ...). Cheers, Daniel On Wed, Apr 3, 2013 at 5:42 PM, Dihan Wickremasuriya dwickremasur...@rethinkrobotics.com wrote: Hi Chris/Daniel, This is Dihan from Rethink Robotics and we were hoping you could help with the GPU hang problem in the i915 driver mentioned in bug #26345: https://bugs.freedesktop.org/show_bug.cgi?id=26345 We are running into the same problem with the 3.8.5 kernel (which has the fix mentioned in comment #153 of the bug report) when running a Qt 5 application in Gentoo. At times the entire X session would freeze. The x11-perf tests described in the bug report run without any issues though. Would you happen to know whether this is because of an issue in the driver that is not currently being addressed by the fix? I have attached the Xorg log, the dmesg output and i915_error_state from a hung session. Please let me know if you need any more info. Thanks in advance! Best regards, Dihan -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: re-add eDP bpp clamping notice
This has been lost in my recent bpp handling rework in
commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Mar 27 00:44:58 2013 +0100
drm/i915: precompute pipe bpp before touching the hw
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_dp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c5cfec3..58ba0a0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -741,8 +741,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
/* Walk through all bpp values. Luckily they're all nicely spaced with 2
* bpc in between. */
bpp = min_t(int, 8*3, pipe_config-pipe_bpp);
- if (is_edp(intel_dp) dev_priv-edp.bpp)
+ if (is_edp(intel_dp) dev_priv-edp.bpp) {
+ DRM_DEBUG_KMS(clamping display bpc (was %d) to eDP (%d)\n,
+ bpp, dev_priv-edp.bpp);
bpp = min_t(int, bpp, dev_priv-edp.bpp);
+ }
for (; bpp = 6*3; bpp -= 2*3) {
mode_rate = intel_dp_link_required(target_clock, bpp);
--
1.7.10.4
___
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: Introduce i9xx_set_pipeconf()
On Wed, Apr 03, 2013 at 07:06:01PM +0200, Daniel Vetter wrote: On Wed, Apr 03, 2013 at 01:08:16PM +0300, Jani Nikula wrote: On Tue, 02 Apr 2013, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Extract the PIPECONF setup into i9xx_set_pipeconf(). This makes the =Gen4/VLV code follow the same pattern as the Gen5+ codepaths. Reviewed-by: Jani Nikula jani.nik...@intel.com Queued for -next with a pretty massive bikeshed (extended conflict resolutions ftw), thanks for the patch. I've changed my mind after trying to rebase my current pipe_config stuff on top of latest dinq - I've noticed that I've written this exact patch, but in slightly different colors: https://patchwork.kernel.org/patch/2173951/ The slightly different colors resulted in rebase hell in my pipe_config branch, so I've ditched your patch here and exchanged it with mine - rebasing your two patches on top was much easier ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 3.8.2, intel 2.21.5: drm:i915_hangcheck_hung with VAAPI
Hello everyone, I am running VDR (digital videorecoder) with plugin softhddevice (to output video via VAAPI to X11) on a second X server (:1.0) and sometimes the video freezes. Then I see the following messages in dmesg: [202828.719109] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [202828.719112] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state When I try to fetch the requested info the cat aborts with: playstation ~ # cat /debug/dri/0/i915_error_state cat: /debug/dri/0/i915_error_state: Cannot allocate memory and the following error is logged in dmesg: [202874.384439] [ cut here ] [202874.384450] WARNING: at mm/page_alloc.c:2376 __alloc_pages_nodemask+0x338/0x970() [202874.384452] Hardware name: [202874.384453] Modules linked in: vhost_net ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE ipt_REJECT xt_CHECKSUM w83627ehf hwmon_vid xt_conntrack iptable_filter iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables bonding ftdi_sio stv6110x(O) lnbp21(O) stv090x(O) coretemp ddbridge(O) lpc_ich cxd2099(O) mfd_core dvb_core(O) zfs(PO) zcommon(PO) znvpair(PO) zavl(PO) zunicode(PO) spl(O) [202874.384484] Pid: 22676, comm: cat Tainted: P O 3.8.2-gentoo #4 [202874.384486] Call Trace: [202874.384493] [810b7bba] warn_slowpath_common+0x7a/0xb0 [202874.384496] [810b7c05] warn_slowpath_null+0x15/0x20 [202874.384500] [81161ea8] __alloc_pages_nodemask+0x338/0x970 [202874.384504] [81446bb2] ? put_dec+0x72/0x90 [202874.384507] [81447a44] ? number.isra.2+0x304/0x330 [202874.384512] [81198635] alloc_pages_current+0xb5/0x170 [202874.384516] [8115e389] __get_free_pages+0x9/0x40 [202874.384520] [811a09ea] kmalloc_order_trace+0x3a/0xc0 [202874.384549] [811a19b3] __kmalloc+0x1a3/0x220 [202874.384561] [811a1125] ? kfree+0x135/0x150 [202874.384569] [811d18f5] seq_read+0x1b5/0x400 [202874.384573] [811b0c9b] vfs_read+0xab/0x170 [202874.384577] [811b0dad] sys_read+0x4d/0x90 [202874.384586] [8185e1c9] ? do_page_fault+0x9/0x10 [202874.384589] [818621d2] system_call_fastpath+0x16/0x1b [202874.384592] ---[ end trace 00716d8279da5aa9 ]--- Since the system has been rebooted not so far ago the system still has 10G free memory. Is there anything more which I can gather? I am running the following versions right now: playstation ~ # equery l xf86-video-intel mesa libva * Searching for xf86-video-intel ... [IP-] [ ] x11-drivers/xf86-video-intel-2.21.5:0 * Searching for mesa ... [IP-] [ ] media-libs/mesa-9.0.1:0 * Searching for libva ... [IP-] [ ] x11-libs/libva-1.0.15:0 Kernel version is: playstation ~ # uname -a Linux playstation 3.8.2-gentoo #4 SMP Wed Mar 20 22:41:17 CET 2013 x86_64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux Are there any further infos which I can provide? Thanks and best regards, Jogi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: fix DP get_hw_state return value
On Tue, Apr 02, 2013 at 08:11:05PM +0200, Daniel Vetter wrote: On Tue, Apr 02, 2013 at 10:03:56AM -0700, Jesse Barnes wrote: If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org These two fixes are merged for -next, thanks. Actually this one here is broken, so I've had to revert it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: fix DP get_hw_state return value
On Thu, Apr 04, 2013 at 01:15:28AM +0200, Daniel Vetter wrote: On Tue, Apr 02, 2013 at 08:11:05PM +0200, Daniel Vetter wrote: On Tue, Apr 02, 2013 at 10:03:56AM -0700, Jesse Barnes wrote: If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org These two fixes are merged for -next, thanks. Actually this one here is broken, so I've had to revert it. I'm also a bit unsure about the DDI one, since if we ever have a port enabled with a bogus pipe link, we probably still want to shut down the port. At least that part is pretty important to not end up with a black screen in a lot of cases, atm Egbert Eich is debugging such a case for sdvo ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: re-add eDP bpp clamping notice
On Wed, Apr 03, 2013 at 11:03:02PM +0200, Daniel Vetter wrote:
This has been lost in my recent bpp handling rework in
commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Mar 27 00:44:58 2013 +0100
drm/i915: precompute pipe bpp before touching the hw
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
I think we can disregard this patch since my next pipe-config series will
touch this some more and add a real debug output again. I'll (re) submit
that pile tomorrow.
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c5cfec3..58ba0a0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -741,8 +741,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
/* Walk through all bpp values. Luckily they're all nicely spaced with 2
* bpc in between. */
bpp = min_t(int, 8*3, pipe_config-pipe_bpp);
- if (is_edp(intel_dp) dev_priv-edp.bpp)
+ if (is_edp(intel_dp) dev_priv-edp.bpp) {
+ DRM_DEBUG_KMS(clamping display bpc (was %d) to eDP (%d)\n,
+ bpp, dev_priv-edp.bpp);
bpp = min_t(int, bpp, dev_priv-edp.bpp);
+ }
for (; bpp = 6*3; bpp -= 2*3) {
mode_rate = intel_dp_link_required(target_clock, bpp);
--
1.7.10.4
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't override PPGTT cacheability on HSW
On Wed, Apr 03, 2013 at 01:41:05PM -0700, Ben Widawsky wrote: On Wed, Apr 03, 2013 at 10:08:26PM +0200, Daniel Vetter wrote: On Wed, Apr 3, 2013 at 9:33 PM, Daniel Vetter dan...@ffwll.ch wrote: So I've checked hsw bspec and the problem is that hw guys again changed the bits around a bit, and I think on HSW we actually want (0x8 3) instead of what's currently there. Meh, I've screwed up reading the tables, 0x3 3 is what we imo want, so nothing needs to be changed. Sorry for the confusion. -Daniel I think the existing code is magic that we don't/shouldn't need. But I also see no reason to change it. Digging a bit more, it seems we want this for GEN6 (setting 33), but not GEN7. I'm done digging now. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: fix DP get_hw_state return value
On Thu, 4 Apr 2013 01:15:28 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Apr 02, 2013 at 08:11:05PM +0200, Daniel Vetter wrote: On Tue, Apr 02, 2013 at 10:03:56AM -0700, Jesse Barnes wrote: If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org These two fixes are merged for -next, thanks. Actually this one here is broken, so I've had to revert it. What failed? How is it possible we'd have a DP port without a pipe? Every pattern in the register field should correspond to a pipe right? -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
