[Intel-gfx] [PATCH] drm/i915: Add 180 degree primary plane rotation support
From: Sonika Jindal
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to drm_plane,so
drm layer will take care of resetting.
v10: adding updation of fbc when rotation is set to 0.
Testcase: igt/kms_rotation_crc
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: dri-de...@lists.freedesktop.org
Cc: vijay.a.purushotha...@intel.com
Signed-off-by: Uma Shankar
Signed-off-by: Sagar Kamble
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 102 --
drivers/gpu/drm/i915/intel_pm.c |7 +++
3 files changed, 105 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c804..c600d3b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4087,6 +4087,7 @@ enum punit_power_well {
#define DISPPLANE_NO_LINE_DOUBLE 0
#define DISPPLANE_STEREO_POLARITY_FIRST 0
#define DISPPLANE_STEREO_POLARITY_SECOND (1<<18)
+#define DISPPLANE_ROTATE_180 (1<<15)
#define DISPPLANE_TRICKLE_FEED_DISABLE (1<<14) /* Ironlake */
#define DISPPLANE_TILED (1<<10)
#define _DSPAADDR 0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..7f16d6f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2414,7 +2414,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg;
+ int pixel_size;
+ pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
@@ -2422,6 +2424,8 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
dspcntr = I915_READ(reg);
/* Mask out pixel format bits in case we change it */
dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
+ dspcntr &= ~DISPPLANE_ROTATE_180;
+
switch (fb->pixel_format) {
case DRM_FORMAT_C8:
dspcntr |= DISPPLANE_8BPP;
@@ -2463,8 +2467,6 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
if (INTEL_INFO(dev)->gen >= 4) {
@@ -2477,6 +2479,18 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
intel_crtc->dspaddr_offset = linear_offset;
}
+ if (to_intel_plane(crtc->primary)->rotation == BIT(DRM_ROTATE_180)) {
+ dspcntr |= DISPPLANE_ROTATE_180;
+
+ x += (intel_crtc->config.pipe_src_w - 1);
+ y += (intel_crtc->config.pipe_src_h - 1);
+ linear_offset += (intel_crtc->config.pipe_src_h - 1) *
+ fb->pitches[0] +
+ (intel_crtc->config.pipe_src_w - 1) * pixel_size;
+ }
+
+ I915_WRITE(reg, dspcntr);
+
DRM_DEBUG_KMS("Writing base %08lX %08lX %d %d %d\n",
i915_gem_obj_ggtt_offset(obj), linear_offset, x, y,
fb->pitches[0]);
@@ -2487,7 +2501,8 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
I915_WRITE(DSPLINOFF(plane), linear_offset);
} else
- I
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode
On Friday 13 June 2014 05:24 PM, Imre Deak wrote: Blanking/unblanking the console in a loop on an Asus T100 sometimes leaves the console blank. After some digging I found that applying commit 61bc95c1fbbb6a08b55bbe161fdf1ea5493fc595 Author: Egbert Eich Date: Mon Mar 4 09:24:38 2013 -0500 DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. fixed VLV too. In my case the problem seemed to happen already during the previous crtc disabling and went away if I disabled self-refresh mode before disabling the primary plane. The root cause for this is that updates from the shadow to live plane control register are blocked at vblank time if the memory self-refresh mode (aka max-fifo mode on VLV) is active at that moment. The controller checks at frame start time if the CPU is in C0 and the self-refresh mode enable bit is set and if so activates self-reresh mode, otherwise deactivates it. So to make sure that the plane truly gets disabled before pipe-off we have to: 1. disable memory self-refresh mode 2. disable plane 3. wait for vblank 4. disable pipe 5. wait for pipe-off v2: - add explanation for the root cause from HW team (Cesar Mancini et al) - remove note about the CPU C7S state, in my latest tests disabling it alone didn't make a difference - add vblank between disabling plane and pipe (Ville) - apply the same workaround for all gmch platforms (Ville) Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_display.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b9251c8..5eb8afe 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4799,6 +4799,16 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) if (IS_GEN2(dev)) intel_set_cpu_fifo_underrun_reporting(dev, pipe, false); + /* +* Vblank time updates from the shadow to live plane control register +* are blocked if the memory self-refresh mode is active at that +* moment. So to make sure the plane gets truly disabled, disable +* first the self-refresh mode. The self-refresh enable bit in turn +* will be checked/applied by the HW only at the next frame start +* event which is after the vblank start event, so we need to have a +* wait-for-vblank between disabling the plane and the pipe. +*/ + intel_set_memory_cxsr(dev_priv, false); intel_crtc_disable_planes(crtc); for_each_encoder_on_crtc(dev, crtc, encoder) @@ -4807,9 +4817,10 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) /* * On gen2 planes are double buffered but the pipe isn't, so we must * wait for planes to fully turn off before disabling the pipe. +* We also need to wait on all gmch platforms because of the +* self-refresh mode constraint explained above. */ - if (IS_GEN2(dev)) - intel_wait_for_vblank(dev, pipe); + intel_wait_for_vblank(dev, pipe); intel_disable_pipe(dev_priv, pipe); Reviewed-by: Deepak S ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: gmch: set SR WMs to valid values before enabling them
On Friday 13 June 2014 05:24 PM, Imre Deak wrote:
Atm it's possible that we enable the memory self-refresh mode before the
watermark levels used by this mode are programmed with valid values. So
move the enabling after we programmed the WM levels.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e55622e..c9ee1aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1332,6 +1332,7 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
int plane_sr, cursor_sr;
int ignore_plane_sr, ignore_cursor_sr;
unsigned int enabled = 0;
+ bool cxsr_enabled;
vlv_update_drain_latency(dev);
@@ -1358,8 +1359,9 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
&valleyview_wm_info,
&valleyview_cursor_wm_info,
&ignore_plane_sr, &cursor_sr)) {
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
intel_set_memory_cxsr(dev_priv, false);
plane_sr = cursor_sr = 0;
}
@@ -1380,6 +1382,9 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
I915_WRITE(DSPFW3,
(I915_READ(DSPFW3) & ~DSPFW_CURSOR_SR_MASK) |
(cursor_sr << DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void g4x_update_wm(struct drm_crtc *crtc)
@@ -1390,6 +1395,7 @@ static void g4x_update_wm(struct drm_crtc *crtc)
int planea_wm, planeb_wm, cursora_wm, cursorb_wm;
int plane_sr, cursor_sr;
unsigned int enabled = 0;
+ bool cxsr_enabled;
if (g4x_compute_wm0(dev, PIPE_A,
&g4x_wm_info, latency_ns,
@@ -1409,8 +1415,9 @@ static void g4x_update_wm(struct drm_crtc *crtc)
&g4x_wm_info,
&g4x_cursor_wm_info,
&plane_sr, &cursor_sr)) {
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
intel_set_memory_cxsr(dev_priv, false);
plane_sr = cursor_sr = 0;
}
@@ -1432,6 +1439,9 @@ static void g4x_update_wm(struct drm_crtc *crtc)
I915_WRITE(DSPFW3,
(I915_READ(DSPFW3) & ~(DSPFW_HPLL_SR_EN |
DSPFW_CURSOR_SR_MASK)) |
(cursor_sr << DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void i965_update_wm(struct drm_crtc *unused_crtc)
@@ -1441,6 +1451,7 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
struct drm_crtc *crtc;
int srwm = 1;
int cursor_sr = 16;
+ bool cxsr_enabled;
/* Calc sr entries for one plane configs */
crtc = single_enabled_crtc(dev);
@@ -1482,8 +1493,9 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
DRM_DEBUG_KMS("self-refresh watermark: display plane %d "
"cursor %d\n", srwm, cursor_sr);
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
/* Turn off self refresh if both pipes are enabled */
intel_set_memory_cxsr(dev_priv, false);
}
@@ -1497,6 +1509,9 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
I915_WRITE(DSPFW2, (8 << 8) | (8 << 0));
/* update cursor SR watermark */
I915_WRITE(DSPFW3, (cursor_sr << DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void i9xx_update_wm(struct drm_crtc *unused_crtc)
Reviewed-by: Deepak S
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: gmch: factor out intel_set_memory_cxsr
On Friday 13 June 2014 05:24 PM, Imre Deak wrote:
This functionality will be also needed by an upcoming patch, so factor
it out. As a bonus this also makes things a bit more uniform across
platforms. Note that this also changes the register read-modify-write
to a simple write during disabling. This is what we do during enabling
anyway and according to the spec all the relevant bits are reserved-MBZ
or reserved with a 0 default value.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 75 -
2 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f36d9eb..211a173 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2590,6 +2590,8 @@ extern void gen6_set_rps(struct drm_device *dev, u8 val);
extern void valleyview_set_rps(struct drm_device *dev, u8 val);
extern int valleyview_rps_max_freq(struct drm_i915_private *dev_priv);
extern int valleyview_rps_min_freq(struct drm_i915_private *dev_priv);
+extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
+ bool enable);
extern void intel_detect_pch(struct drm_device *dev);
extern int intel_trans_dp_port_sel(struct drm_crtc *crtc);
extern int intel_enable_rc6(const struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b088fe..e55622e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -789,12 +789,33 @@ static const struct cxsr_latency
*intel_get_cxsr_latency(int is_desktop,
return NULL;
}
-static void pineview_disable_cxsr(struct drm_device *dev)
+void intel_set_memory_cxsr(struct drm_i915_private *dev_priv, bool enable)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_device *dev = dev_priv->dev;
+ u32 val;
- /* deactivate cxsr */
- I915_WRITE(DSPFW3, I915_READ(DSPFW3) & ~PINEVIEW_SELF_REFRESH_EN);
+ if (IS_VALLEYVIEW(dev)) {
+ I915_WRITE(FW_BLC_SELF_VLV, enable ? FW_CSPWRDWNEN : 0);
+ } else if (IS_G4X(dev) || IS_CRESTLINE(dev)) {
+ I915_WRITE(FW_BLC_SELF, enable ? FW_BLC_SELF_EN : 0);
+ } else if (IS_PINEVIEW(dev)) {
+ val = I915_READ(DSPFW3) & ~PINEVIEW_SELF_REFRESH_EN;
+ val |= enable ? PINEVIEW_SELF_REFRESH_EN : 0;
+ I915_WRITE(DSPFW3, val);
+ } else if (IS_I945G(dev) || IS_I945GM(dev)) {
+ val = enable ? _MASKED_BIT_ENABLE(FW_BLC_SELF_EN) :
+ _MASKED_BIT_DISABLE(FW_BLC_SELF_EN);
+ I915_WRITE(FW_BLC_SELF, val);
+ } else if (IS_I915GM(dev)) {
+ val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
+ _MASKED_BIT_DISABLE(INSTPM_SELF_EN);
+ I915_WRITE(INSTPM, val);
+ } else {
+ return;
+ }
+
+ DRM_DEBUG_KMS("memory self-refresh is %s\n",
+ enable ? "enabled" : "disabled");
}
/*
@@ -1033,7 +1054,7 @@ static void pineview_update_wm(struct drm_crtc
*unused_crtc)
dev_priv->fsb_freq,
dev_priv->mem_freq);
if (!latency) {
DRM_DEBUG_KMS("Unknown FSB/MEM found, disable CxSR\n");
- pineview_disable_cxsr(dev);
+ intel_set_memory_cxsr(dev_priv, false);
return;
}
@@ -1085,12 +1106,7 @@ static void pineview_update_wm(struct drm_crtc *unused_crtc)
DRM_DEBUG_KMS("DSPFW3 register is %x\n", reg);
/* activate cxsr */
- I915_WRITE(DSPFW3,
- I915_READ(DSPFW3) | PINEVIEW_SELF_REFRESH_EN);
- DRM_DEBUG_KMS("Self-refresh is enabled\n");
- } else {
- pineview_disable_cxsr(dev);
- DRM_DEBUG_KMS("Self-refresh is disabled\n");
+ intel_set_memory_cxsr(dev_priv, true);
I think we need to pass "false" here to disable cxsr right?
Apart for this everything else looks good.
Reviewed-by: Deepak S
}
}
@@ -1342,10 +1358,9 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
&valleyview_wm_info,
&valleyview_cursor_wm_info,
&ignore_plane_sr, &cursor_sr)) {
- I915_WRITE(FW_BLC_SELF_VLV, FW_CSPWRDWNEN);
+ intel_set_memory_cxsr(dev_priv, true);
} else {
- I915_WRITE(FW_BLC_SELF_VLV,
- I915_READ(FW_BLC_SELF_VLV) & ~FW_CSPWRDWNEN);
+ intel_set_memory_cxsr(dev_priv, false);
plane_sr = cursor_sr = 0;
}
@@ -1394,10 +1409,9 @@ static void g4x_update_wm(struct drm_crtc *crtc)
&g4x_wm_info,
&g4x_c
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode
On 6/13/2014 5:24 PM, Imre Deak wrote: Blanking/unblanking the console in a loop on an Asus T100 sometimes leaves the console blank. After some digging I found that applying commit 61bc95c1fbbb6a08b55bbe161fdf1ea5493fc595 Author: Egbert Eich Date: Mon Mar 4 09:24:38 2013 -0500 DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. fixed VLV too. In my case the problem seemed to happen already during the previous crtc disabling and went away if I disabled self-refresh mode before disabling the primary plane. The root cause for this is that updates from the shadow to live plane control register are blocked at vblank time if the memory self-refresh mode (aka max-fifo mode on VLV) is active at that moment. The controller checks at frame start time if the CPU is in C0 and the self-refresh mode enable bit is set and if so activates self-reresh mode, otherwise deactivates it. So to make sure that the plane truly gets disabled before pipe-off we have to: 1. disable memory self-refresh mode 2. disable plane 3. wait for vblank 4. disable pipe 5. wait for pipe-off v2: - add explanation for the root cause from HW team (Cesar Mancini et al) - remove note about the CPU C7S state, in my latest tests disabling it alone didn't make a difference - add vblank between disabling plane and pipe (Ville) - apply the same workaround for all gmch platforms (Ville) Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_display.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b9251c8..5eb8afe 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4799,6 +4799,16 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) if (IS_GEN2(dev)) intel_set_cpu_fifo_underrun_reporting(dev, pipe, false); + /* +* Vblank time updates from the shadow to live plane control register +* are blocked if the memory self-refresh mode is active at that +* moment. So to make sure the plane gets truly disabled, disable +* first the self-refresh mode. The self-refresh enable bit in turn +* will be checked/applied by the HW only at the next frame start +* event which is after the vblank start event, so we need to have a +* wait-for-vblank between disabling the plane and the pipe. +*/ + intel_set_memory_cxsr(dev_priv, false); intel_crtc_disable_planes(crtc); for_each_encoder_on_crtc(dev, crtc, encoder) @@ -4807,9 +4817,10 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) /* * On gen2 planes are double buffered but the pipe isn't, so we must * wait for planes to fully turn off before disabling the pipe. +* We also need to wait on all gmch platforms because of the +* self-refresh mode constraint explained above. */ - if (IS_GEN2(dev)) - intel_wait_for_vblank(dev, pipe); + intel_wait_for_vblank(dev, pipe); intel_disable_pipe(dev_priv, pipe); Reviewed-by: Vijay Purushothaman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: gmch: set SR WMs to valid values before enabling them
On 6/13/2014 5:24 PM, Imre Deak wrote:
Atm it's possible that we enable the memory self-refresh mode before the
watermark levels used by this mode are programmed with valid values. So
move the enabling after we programmed the WM levels.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e55622e..c9ee1aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1332,6 +1332,7 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
int plane_sr, cursor_sr;
int ignore_plane_sr, ignore_cursor_sr;
unsigned int enabled = 0;
+ bool cxsr_enabled;
vlv_update_drain_latency(dev);
@@ -1358,8 +1359,9 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
&valleyview_wm_info,
&valleyview_cursor_wm_info,
&ignore_plane_sr, &cursor_sr)) {
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
intel_set_memory_cxsr(dev_priv, false);
plane_sr = cursor_sr = 0;
}
@@ -1380,6 +1382,9 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
I915_WRITE(DSPFW3,
(I915_READ(DSPFW3) & ~DSPFW_CURSOR_SR_MASK) |
(cursor_sr << DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void g4x_update_wm(struct drm_crtc *crtc)
@@ -1390,6 +1395,7 @@ static void g4x_update_wm(struct drm_crtc *crtc)
int planea_wm, planeb_wm, cursora_wm, cursorb_wm;
int plane_sr, cursor_sr;
unsigned int enabled = 0;
+ bool cxsr_enabled;
if (g4x_compute_wm0(dev, PIPE_A,
&g4x_wm_info, latency_ns,
@@ -1409,8 +1415,9 @@ static void g4x_update_wm(struct drm_crtc *crtc)
&g4x_wm_info,
&g4x_cursor_wm_info,
&plane_sr, &cursor_sr)) {
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
intel_set_memory_cxsr(dev_priv, false);
plane_sr = cursor_sr = 0;
}
@@ -1432,6 +1439,9 @@ static void g4x_update_wm(struct drm_crtc *crtc)
I915_WRITE(DSPFW3,
(I915_READ(DSPFW3) & ~(DSPFW_HPLL_SR_EN |
DSPFW_CURSOR_SR_MASK)) |
(cursor_sr << DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void i965_update_wm(struct drm_crtc *unused_crtc)
@@ -1441,6 +1451,7 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
struct drm_crtc *crtc;
int srwm = 1;
int cursor_sr = 16;
+ bool cxsr_enabled;
/* Calc sr entries for one plane configs */
crtc = single_enabled_crtc(dev);
@@ -1482,8 +1493,9 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
DRM_DEBUG_KMS("self-refresh watermark: display plane %d "
"cursor %d\n", srwm, cursor_sr);
- intel_set_memory_cxsr(dev_priv, true);
+ cxsr_enabled = true;
} else {
+ cxsr_enabled = false;
/* Turn off self refresh if both pipes are enabled */
intel_set_memory_cxsr(dev_priv, false);
}
@@ -1497,6 +1509,9 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
I915_WRITE(DSPFW2, (8 << 8) | (8 << 0));
/* update cursor SR watermark */
I915_WRITE(DSPFW3, (cursor_sr << DSPFW_CURSOR_SR_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
}
static void i9xx_update_wm(struct drm_crtc *unused_crtc)
Reviewed-by: Vijay Purushothaman
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type
On 2014/6/25 15:55, Paolo Bonzini wrote: Il 25/06/2014 09:34, Chen, Tiejun ha scritto: On 2014/6/25 14:48, Paolo Bonzini wrote: Second problem. Your IGD passthrough code currently works with QEMU's PIIX4-based machine. But what happens if you try to extend it, so that Yes, current xen machine, xenpv, is based on pii4, and also I don't known if we will plan to migrate to q35 or others. So its hard to further say more now. it works with QEMU's ICH9-based machine? That's a more modern machine that has a PCIe chipset and hence has its ISA bridge at 00:1f.0. Now But even in this case, could we set the real vendor/device ids for that ISA bridge at 00:1f.0? If not, what's broken? The config space layout changes for different vendor/device ids, so the guest firmware only works if you have the right vendor/device id. Paolo, After I discuss internal, we think even we just set the real vendor/device ids to this ISA bridge at 00:1f.0, guest firmware should still work well with these pair of real vendor/device ids. So if you think something would conflict or be broken, could you tell us what's exactly that? Then we will double check. Thanks Tiejun It is only slightly better, but the right solution is to fix the driver. There is absolutely zero reason why a graphics driver should know about the vendor/device ids of the PCH. This means we have to fix this both on Linux and Windows but I'm not sure if this is feasible to us. You have to do it if you want this feature in QEMU in a future-proof way. You _can_ provide the ugly PIIX4-specific hack as a compatibility fallback (and this patch is okay to make the compatibility fallback less hacky). However, I don't think QEMU should accept the patch for IGD passthrough unless Intel is willing to make drivers virtualization-friendly. Once you assign the IGD, it is not that integrated anymore and the drivers must take that into account. It is worthwhile pointing out that neither AMD nor nVidia need any of this. The right way could be to make QEMU add a vendor-specific capability to the video device. The driver can probe for that capability before Do you mean we can pick two unused offsets in the configuration space of the video device as a vendor-specific capability to hold the vendor/device ids of the PCH? Yes, either that or add a new capability (which lets you choose the offsets more freely). If the IGD driver needs config space fields of the MCH, those fields could also be mirrored in the new capability. QEMU would forward them automatically. It could even be a new BAR, which gives even more freedom to allocate the fields. looking at the PCI bus. QEMU can add the capability to the list, it is easy because all accesses to the video device's configuration space trap to QEMU. Then you do not need to add fake devices to the machine. In fact, it would be nice if Intel added such a capability on the next generation of integrated graphics, too. On real hardware, ACPI or some Maybe, but even this would be implemented, shouldn't we need to be compatible with those old generations? Yes. - old generation / old driver: use 00:1f.0 hack, only guaranteed to work on PIIX4-based virtual guest - old generation / new driver: use 00:1f.0 hack on real hardware, use capability on 00:02.0 on virtual guest, can work on PCIe virtual guest - new generation / old driver: doesn't exist - new generation / new driver: always use capability on 00:02.0, can work on PCIe virtual guest. Paolo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for branch device.
Background: Valleyview platform VTC1010 with a branch device DP2HDMI attached by a sink device Giantec HDMI display. Firstly changing to virtual console termial, after a while(10-20 minutes), connector issues a faked dpms signal which cause kernel to power off the monitor. And kernel will delete all allocated connecotr and encoder attached to this connector. This will cause monitor could not be restored at all even if you press any key or mouse. The root cause is that intel_dp_detect_dpcd funtion detects DP_SINK_COUNT from dpcd to check how many sink devices are attached. If greater than 0, it will be fine to keep connector alive. Otherwise the connector will be changed to be disconnected. And then all things related with this connector will be deleted. With testing, when SINK_COUNT is 0, drm_probe_ddc works and connector is still alive. So this patch will ignore the condition of SINK_COUNT=0, and continue to check if connector is really alive without touch others process. Signed-off-by: Quanxian Wang --- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 23b62b0..9984d22 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3414,8 +3414,8 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp) ®, 1) < 0) return connector_status_unknown; - return DP_GET_SINK_COUNT(reg) ? connector_status_connected - : connector_status_disconnected; + if (DP_GET_SINK_COUNT(reg)) + return connector_status_connected; } /* If no HPD, poke DDC gently */ -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote: Resend without html krud which causes list to bounce the message. > Hi > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot with > 3.16-git. Reverting it lets the boot proceed. > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the primary > console. The i915 is initialized > but does not have a physical display attached. > > With the patch applied the boot stops at the messages: > > [drm] Memory usable by graphics device = 2048M > [drm] Replacing VGA console driver > > and I need to interrupt or power off the box to get it back. > > (I did not notice messages about the R7 but they could have easily been > missed - this box does not have a serial console) > > Without the patch I get: > > Jun 28 14:53:54 localhost kernel: [2.075351] e1000e: Intel(R) PRO/1000 > Network Driver - 2.3.2-k > Jun 28 14:53:54 localhost kernel: [2.075796] [drm] Initialized drm 1.1.0 > 20060810 > Jun 28 14:53:54 localhost kernel: [2.075958] microcode: CPU0 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077289] microcode: CPU1 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077299] microcode: CPU2 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077307] microcode: CPU3 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077315] microcode: CPU4 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077325] microcode: CPU5 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077335] microcode: CPU6 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077342] microcode: CPU7 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077378] microcode: Microcode Update > Driver: v2.00 , Peter Oruba > Jun 28 14:53:54 localhost kernel: [2.079726] input: PC Speaker as > /devices/platform/pcspkr/input/input4 > Jun 28 14:53:54 localhost kernel: [2.083930] e1000e: Copyright(c) 1999 - > 2014 Intel Corporation. > Jun 28 14:53:54 localhost kernel: [2.084787] ACPI Warning: SystemIO range > 0xf040-0xf05f conflicts with OpRegion > 0xf040-0xf04f (\_SB_.PCI0.SBUS.SMBI) > (20140424/utaddress-258) > Jun 28 14:53:54 localhost kernel: [2.084788] ACPI: If an ACPI driver is > available for this device, you should use it instead of the native driver > Jun 28 14:53:54 localhost kernel: [2.084894] e1000e :00:19.0: > Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode > Jun 28 14:53:54 localhost kernel: [2.084905] e1000e :00:19.0: irq 44 > for MSI/MSI-X > Jun 28 14:53:54 localhost kernel: [2.096721] iTCO_vendor_support: > vendor-support=0 > Jun 28 14:53:54 localhost kernel: [2.096780] AVX2 version of gcm_enc/dec > engaged. > Jun 28 14:53:54 localhost kernel: [2.098512] iTCO_wdt: Intel TCO WatchDog > Timer Driver v1.11 > Jun 28 14:53:54 localhost kernel: [2.099042] iTCO_wdt: Found a Lynx Point > TCO device (Version=2, TCOBASE=0x1860) > Jun 28 14:53:54 localhost kernel: [2.099561] iTCO_wdt: initialized. > heartbeat=30 sec (nowayout=0) > Jun 28 14:53:54 localhost kernel: [2.100401] [drm] radeon kernel > modesetting enabled. > Jun 28 14:53:54 localhost kernel: [2.100918] checking generic (e000 > 30) vs hw (e000 1000) > Jun 28 14:53:54 localhost kernel: [2.100919] fb: switching to radeondrmfb > from simple > Jun 28 14:53:54 localhost kernel: [2.101372] Console: switching to colour > dummy device 80x25 > Jun 28 14:53:54 localhost kernel: [2.101527] [drm] initializing kernel > modesetting (BONAIRE 0x1002:0x6658 0x174B:0xE253). > Jun 28 14:53:54 localhost kernel: [2.101534] [drm] register mmio base: > 0xF080 > Jun 28 14:53:54 localhost kernel: [2.101535] [drm] register mmio size: > 262144 > Jun 28 14:53:54 localhost kernel: [2.101540] [drm] doorbell mmio base: > 0xF000 > Jun 28 14:53:54 localhost kernel: [2.101541] [drm] doorbell mmio size: > 8388608 > Jun 28 14:53:54 localhost kernel: [2.101579] ATOM BIOS: Bonaire > Jun 28 14:53:54 localhost kernel: [2.101627] radeon :01:00.0: VRAM: > 2048M 0x - 0x7FFF (2048M used) > Jun 28 14:53:54 localhost kernel: [2.101629] radeon :01:00.0: GTT: > 1024M 0x8000 - 0xBFFF > Jun 28 14:53:54 localhost kernel: [2.101630] [drm] Detected VRAM > RAM=2048M, BAR=256M > Jun 28 14:53:54 localhost kernel: [2.101631] [drm] RAM width 128bits DDR > Jun 28 14:53:54 localhost kernel: [2.101659] [TTM] Zone kernel: > Available graphics memory: 8145364 kiB > Jun 28 14:53:54 localhost kernel: [2.101660] [TTM] Zone dma32: > Available graphics memory: 2097152 kiB > Jun 28 14:53:54 localhost kernel: [2.101662]
