Re: [Intel-gfx] v3.9-rc1 instability on Chromebook Pixel with gmbus irq
On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung ble...@chromium.org wrote: I'm working on touch devices Chromium OS, and I've noticed a regression between 3.8 and 3.9-rc1, which was posted yesterday. The hardware in question is a Chromebook Pixel. For this device, we have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s touchscreen. The touchpad is on bus 1, i915 gmbus vga at 1-004b. The touchscreen is on bus 2, i915 gmbus panel at 2-004a. I was testing v3.9-rc1 on the Pixel and the touchscreen driver is being returned -110 (-ETIMEDOUT) on an i2c_transfer after several seconds of both touch devices working correctly. At the time of the failure, there are no error messages from GMBUS that I can see, but the bus never recovers. I can keep interacting with the touchscreen or touchpad, and the interrupts trigger reads, but all subsequent reads return -110. I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus irq support was merged. After bisecting, I found that this commit seems to be causing the timeout problem. Reverting it makes the problem go away, and the bus is stable. Can you please retest with latest drm-intel-fixes merged into -rc1? Paulo's patch fixes a race in handling PCH interrupts (where the gmbus hw is) which matches rather well with your description here. Thanks, Daniel commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Sat Dec 1 13:53:46 2012 +0100 drm/i915: use gmbus irq to wait for gmbus idle GMBUS_ACTIVE has inverted sense and so doesn't fit into the wait_hw_status helper, hence create a new gmbus_wait_idle functions. Also, we only care about the idle irq event and nothing else, which allows us to use the wait_event_timeout helper directly without jumping through hoops to catch NAKs. Since gen2/3 don't have gmbus interrupts, handle them separately with the old wait_for macro. This shaves another few ms off reading EDID from a hdmi screen on my testbox here. EDID reading with interrupt driven gmbus is now as fast as with busy-looping gmbus at 28 ms here (with negligible cpu overhead). Reviewed-by: Imre Deak imre.d...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Is there anything I can do to help debug this some more? -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- 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 incorrect definition of ADPA HSYNC and VSYNC bits
On Tue, Mar 05, 2013 at 02:19:31PM -0800, Eric Anholt wrote: Patrik Jakobsson patrik.r.jakobs...@gmail.com writes: Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend becoming standby and vice versa. Fixed by swapping their bit position. Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com Confirmed in the 945 and 845 specs. Reviewed-by: Eric Anholt e...@anholt.net Picked up for -fixes, thanks for the patch. -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: On G45 enable cursor plane briefly after enabling the display plane.
Am Montag, den 04.03.2013, 17:17 +0100 schrieb Daniel Vetter:
On Mon, Mar 04, 2013 at 09:24:38AM -0500, Egbert Eich wrote:
On G45 some low res modes (800x600 and 1024x768) produce a blank
screen when the display plane is enabled with with cursor plane
off.
Experiments showed that this issue occurred when the following
conditions were met:
a. a previous mode had the cursor plane enabled (Xserver).
b. this mode or the previous one was using self refresh. (Thus
the problem was only seen with low res modes).
The screens lit up as soon as the cursor plane got enabled.
Therefore the blank screen occurred only in console mode, not
when running an Xserver.
It also seemed to be necessary to disable self refresh while briefly
enabling the cursor plane.
Signed-off-by: Egbert Eich e...@suse.com
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=61457
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
This w/a is impressive ;-) Applied to -fixes, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 28 +++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6eb3882..689cc3a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
[…]
@@ -6337,7 +6363,7 @@ static int intel_crtc_cursor_set(struct drm_crtc
*crtc,
i915_gem_detach_phys_object(dev,
intel_crtc-cursor_bo);
} else
i915_gem_object_unpin(intel_crtc-cursor_bo);
- drm_gem_object_unreference(intel_crtc-cursor_bo-base);
+
drm_gem_object_unreference(intel_crtc-cursor_bo-base);
As there are no {} around the else branch, this indentation is
incorrect, right?
}
mutex_unlock(dev-struct_mutex);
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm: Add struct drm_region and assorted utility functions
On Wed, Mar 06, 2013 at 10:56:05AM +, Chris Wilson wrote: On Thu, Feb 21, 2013 at 11:35:00PM +0200, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com struct drm_region represents a two dimensional region. The utility functions are there to help driver writers. v2: Moved the region stuff into its own file, made the smaller funcs static inline, used 64bit maths in the scaled clipping function to avoid overflows (instead it will saturate to INT_MIN or INT_MAX). Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com My criticisms here are mainly that the function names are different than what I am used to for a region API. Namely drm_region_clip, drm_region_subsample would more conventionally be drm_region_intersect, drm_region_downscale. And that a region to me is an ordered list of rectangles, whereas here you just have a single rectangle. I'm fine with renaming stuff. Ideally the names should be so obvious that people never have to look at the documentation. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits
On Wed, Mar 6, 2013 at 12:17 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Patrik, Hi Paul Am Dienstag, den 05.03.2013, 19:09 +0100 schrieb Patrik Jakobsson: Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend becoming standby and vice versa. nice find. Could you elaborate on the symptoms please as I have never experienced any issues with suspend and resume on my ASUS Eee PC 701 4G? Ville did all the finding, I just wrote the patch to make sure it wasn't forgotten. This isn't related to suspend/resume of the system, but putting external monitors in suspend or standby state. When in standby, the monitor consumes more power than in suspend but wakes up faster. Fixed by swapping their bit position. Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com Where did Ville report this? Maybe my questions are already answered there. He found it while looking at another patch I've sent: http://lists.freedesktop.org/archives/intel-gfx/2013-March/025418.html -Patrik ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: don't clear pfit at startup any more
Since
commit 24a1f16de97c4cf0029d9acd04be06db32208726
Author: Mika Kuoppala mika.kuopp...@linux.intel.com
Date: Fri Feb 8 16:35:37 2013 +0200
drm/i915: disable shared panel fitter for pipe
We clear the single panel fitter when disabling the pipe it's attached to, so no
need to additionally clear it when there's no lvds port detected. Since that
alone isn't good enough e.g. when an external monitor is connected and the bios
uses the panel fitter on that output.
Cc: Mika Kuoppala mika.kuopp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 502cb28..8567506 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8318,10 +8318,6 @@ static void intel_setup_outputs(struct drm_device *dev)
bool has_lvds;
has_lvds = intel_lvds_init(dev);
- if (!has_lvds !HAS_PCH_SPLIT(dev)) {
- /* disable the panel fitter on everything but LVDS */
- I915_WRITE(PFIT_CONTROL, 0);
- }
if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES)))
intel_crt_init(dev);
--
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 10/22] drm/i915: don't init LVDS on VLV
On Wed, Feb 06, 2013 at 03:19:03PM +0200, Jani Nikula wrote: On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote: Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Jani Nikula jani.nik...@intel.com Queued for -next, thanks for the patch. And Paulo promised to fix up the confusion around LVDS presence checks. -Daniel --- drivers/gpu/drm/i915/intel_lvds.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 8c61876..feef18c 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -1024,6 +1024,9 @@ static bool intel_lvds_supported(struct drm_device *dev) if (HAS_PCH_SPLIT(dev)) return true; + if (IS_VALLEYVIEW(dev)) + return false; + /* Otherwise LVDS was only attached to mobile products, * except for the inglorious 830gm */ return IS_MOBILE(dev) !IS_I830(dev); -- 1.7.9.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
Re: [Intel-gfx] commit drm/i915: disable shared panel fitter for pipe breaks resolution switching
Hello Hans, Daniel Vetter daniel.vet...@ffwll.ch writes: Hi Hans, Can you please test with 3.9-rc1? That contains an additional patch which might prevent the regression. Specifically commit 9d6d9f19e8146fa24903cb561e204a22232740e3 Author: Mika Kuoppala mika.kuopp...@linux.intel.com Date: Fri Feb 8 16:35:38 2013 +0200 drm/i915: clean up panel fitter handling in lvds Thanks, Daniel Further, could you also test: https://github.com/mkuoppal/linux/tree/pfit_test Thanks, --Mika On Sun, Mar 3, 2013 at 9:10 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: On Sat, Mar 2, 2013 at 8:40 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote: Mika, I am a huge van of ald dos games. Since commit 24a1f16de97c4cf0029d9acd04be06db32208726, drm/i915: disable shared panel fitter for pipe my laptop does not change resolution when I use xdosemu full screen. The screen is just moved to the upper left corner and is not scaled up to fill the screen. Adding relevent mailing lists, please always cc lists when reporting bugs. -Daniel -- Hans I have a del latitude d430. lspci reports: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0201 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at eff0 (32-bit, non-prefetchable) [size=512K] I/O ports at eff8 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at efec (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Dell Device 0201 Flags: bus master, fast devsel, latency 0 Memory at eff8 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 lcpi: -- 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: GFDT support for SNB/IVB
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently all scanout buffers must be uncached because the
display controller doesn't snoop the LLC. SNB introduced another
method to guarantee coherency for the display controller. It's
called the GFDT or graphics data type.
Pages that have the GFDT bit enabled in their PTEs get flushed
all the way to memory when a MI_FLUSH_DW or PIPE_CONTROL is
issued with the synchronize GFDT bit set.
So rather than making all scanout buffers uncached, set the GFDT
bit in their PTEs, and modify the ring flush functions to enable
the synchronize GFDT bit.
On HSW the GFDT bit was removed from the PTE, and it's only present in
surface state, so we can't really set it from the kernel. Also the docs
state that the hardware isn't actually guaranteed to respect the GFDT
bit. So it looks like GFDT isn't all that useful on HSW.
So far I've tried this very quickly on an IVB machine, and
it seems to be working as advertised. No idea if it does any
good though.
On an i5-2520m (laptop) running gnome-shell at 1366x768:
padman140.78 - 145.98 fps
openarena 183.72 - 186.87 fps
gtkperf ComboBoxEntry 20.27 - 22.14s
gtkperf pixbuf 1.12 - 1.47s
x11perf -aa10text 13.40 - 13.20 Mglyphs
which are well within the throttling noise.
v2 [ickle]: adapt to comply with existing userspace guarantees
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.c|4 +
drivers/gpu/drm/i915/i915_drv.h| 16 +++-
drivers/gpu/drm/i915/i915_gem.c| 111
drivers/gpu/drm/i915/i915_gem_context.c|5 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 38 ++
drivers/gpu/drm/i915/i915_reg.h|2 +
drivers/gpu/drm/i915/i915_trace.h | 10 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c| 79 +---
drivers/gpu/drm/i915/intel_ringbuffer.h|5 +-
10 files changed, 225 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 66d06ac..ff935f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -235,6 +235,7 @@ static const struct intel_device_info
intel_sandybridge_d_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_gfdt = 1,
.has_force_wake = 1,
};
@@ -245,6 +246,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_gfdt = 1,
.has_force_wake = 1,
};
@@ -254,6 +256,7 @@ static const struct intel_device_info
intel_ivybridge_d_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_gfdt = 1,
.has_force_wake = 1,
};
@@ -264,6 +267,7 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_gfdt = 1,
.has_force_wake = 1,
};
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 535bf29..9841dd7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -367,6 +367,7 @@ struct intel_device_info {
u8 has_bsd_ring:1;
u8 has_blt_ring:1;
u8 has_llc:1;
+ u8 has_gfdt:1;
};
enum i915_cache_level {
@@ -409,7 +410,8 @@ struct i915_gtt {
void (*gtt_insert_entries)(struct drm_device *dev,
struct sg_table *st,
unsigned int pg_start,
- enum i915_cache_level cache_level);
+ enum i915_cache_level cache_level,
+ bool gfdt);
};
#define gtt_total_entries(gtt) ((gtt).total PAGE_SHIFT)
@@ -430,7 +432,8 @@ struct i915_hw_ppgtt {
void (*insert_entries)(struct i915_hw_ppgtt *ppgtt,
struct sg_table *st,
unsigned int pg_start,
- enum i915_cache_level cache_level);
+ enum i915_cache_level cache_level,
+ bool gfdt);
void (*cleanup)(struct i915_hw_ppgtt *ppgtt);
};
@@ -1170,6 +1173,8 @@ struct drm_i915_gem_object {
unsigned int fenced_gpu_access:1;
unsigned int cache_level:2;
+ unsigned int gfdt:1;
+ unsigned int gfdt_dirty:1;
unsigned int has_aliasing_ppgtt_mapping:1;
unsigned int has_global_gtt_mapping:1;
@@ -1328,6 +1333,9 @@ struct drm_i915_file_private {
#define HAS_LLC(dev)(INTEL_INFO(dev)-has_llc)
#define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)-need_gfx_hws)
+/* Only SNB and IVB have GFDT in PTEs
Re: [Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
On Tue, Mar 05, 2013 at 02:24:48PM +0100, Patrik Jakobsson wrote: According to PRM we need to disable hsync and vsync even though ADPA is disabled. The previous code did infact do the opposite so we fix it. Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com Bugreporter confirmed that it works, so merged to -fixes with cc: stable. Thanks for the patch. -Daniel --- drivers/gpu/drm/i915/intel_crt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 969d08c..32a3693 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -88,7 +88,7 @@ static void intel_disable_crt(struct intel_encoder *encoder) u32 temp; temp = I915_READ(crt-adpa_reg); - temp = ~(ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE); + temp |= ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE; temp = ~ADPA_DAC_ENABLE; I915_WRITE(crt-adpa_reg, temp); } -- 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 07/26] drm/i915: implement WaDisablePSDDualDispatchEnable on VLV
On Fri, Mar 01, 2013 at 02:08:23PM -0800, Jesse Barnes wrote: Can prevent a hang when we get to tessellation. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_pm.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 61fee7f..59ea12a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3899,8 +3899,10 @@ static void valleyview_init_clock_gating(struct drm_device *dev) CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); + /* WaDisablePSDDualDispatchEnable */ I915_WRITE(GEN7_HALF_SLICE_CHICKEN1, -_MASKED_BIT_ENABLE(GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE)); +_MASKED_BIT_ENABLE(GEN7_MAX_PS_THREAD_DEP | + GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE)); The comment added matches what we already did. But the thread dep stuff seems to be something else. It seems to match the default value anyway, so shouldn't be needed AFAICS. /* Apply the WaDisableRHWOOptimizationForRenderHang workaround. */ I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1, -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/26] drm/i915: implement WaDisablePSDDualDispatchEnable on VLV
On Wed, 6 Mar 2013 20:20:21 +0200 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Fri, Mar 01, 2013 at 02:08:23PM -0800, Jesse Barnes wrote: Can prevent a hang when we get to tessellation. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_pm.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 61fee7f..59ea12a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3899,8 +3899,10 @@ static void valleyview_init_clock_gating(struct drm_device *dev) CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); + /* WaDisablePSDDualDispatchEnable */ I915_WRITE(GEN7_HALF_SLICE_CHICKEN1, - _MASKED_BIT_ENABLE(GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE)); + _MASKED_BIT_ENABLE(GEN7_MAX_PS_THREAD_DEP | + GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE)); The comment added matches what we already did. But the thread dep stuff seems to be something else. It seems to match the default value anyway, so shouldn't be needed AFAICS. Hm not sure if we can trust the defaults with all the various BIOSes out there. I'll have to check the workaround and see if the other bit is needed (seems like it might be). -- 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 15/26] drm/i915: add media well to VLV force wake routines
On Fri, Mar 01, 2013 at 02:08:31PM -0800, Jesse Barnes wrote:
We could split this out into a separate routine at some point as an
optimization.
BTW did anyone try to gang wakeup thing instead?
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1c6e066..558c6d1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4271,6 +4271,8 @@
#define FORCEWAKE 0xA18C
#define FORCEWAKE_VLV 0x1300b0
#define FORCEWAKE_ACK_VLV 0x1300b4
+#define FORCEWAKE_MEDIA_VLV 0x1300b8
+#define FORCEWAKE_ACK_MEDIA_VLV 0x1300bc
#define FORCEWAKE_ACK_HSW 0x130044
#define FORCEWAKE_ACK 0x130090
#define VLV_GTLC_WAKE_CTRL 0x130090
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3e976f4..e3947cb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4423,10 +4423,15 @@ static void vlv_force_wake_get(struct
drm_i915_private *dev_priv)
DRM_ERROR(Timed out waiting for forcewake old ack to
clear.\n);
I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_VLV) 1),
FORCEWAKE_ACK_TIMEOUT_MS))
- DRM_ERROR(Timed out waiting for forcewake to ack request.\n);
+ DRM_ERROR(Timed out waiting for GT to ack forcewake
request.\n);
+
+ if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_MEDIA_VLV) 1),
+ FORCEWAKE_ACK_TIMEOUT_MS))
+ DRM_ERROR(Timed out waiting for media to ack forcewake
request.\n);
Based on some of my recent patches the ' 1's should be
' FORCEWAKE_KERNEL'.
__gen6_gt_wait_for_thread_c0(dev_priv);
}
@@ -4434,8 +4439,8 @@ static void vlv_force_wake_get(struct drm_i915_private
*dev_priv)
static void vlv_force_wake_put(struct drm_i915_private *dev_priv)
{
I915_WRITE_NOTRACE(FORCEWAKE_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
- /* something from same cacheline, but !FORCEWAKE_VLV */
- POSTING_READ(FORCEWAKE_ACK_VLV);
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
+ /* The below doubles as a POSTING_READ */
Are we sure? ;)
gen6_gt_check_fifodbg(dev_priv);
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/26] drm/i915: add media well to VLV force wake routines
On Wed, 6 Mar 2013 20:28:07 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Mar 01, 2013 at 02:08:31PM -0800, Jesse Barnes wrote:
We could split this out into a separate routine at some point as an
optimization.
BTW did anyone try to gang wakeup thing instead?
Not afaik.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 1c6e066..558c6d1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4271,6 +4271,8 @@
#define FORCEWAKE 0xA18C
#define FORCEWAKE_VLV 0x1300b0
#define FORCEWAKE_ACK_VLV 0x1300b4
+#define FORCEWAKE_MEDIA_VLV 0x1300b8
+#define FORCEWAKE_ACK_MEDIA_VLV 0x1300bc
#define FORCEWAKE_ACK_HSW 0x130044
#define FORCEWAKE_ACK 0x130090
#define VLV_GTLC_WAKE_CTRL0x130090
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 3e976f4..e3947cb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4423,10 +4423,15 @@ static void vlv_force_wake_get(struct
drm_i915_private *dev_priv)
DRM_ERROR(Timed out waiting for forcewake old ack to
clear.\n);
I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_VLV) 1),
FORCEWAKE_ACK_TIMEOUT_MS))
- DRM_ERROR(Timed out waiting for forcewake to ack request.\n);
+ DRM_ERROR(Timed out waiting for GT to ack forcewake
request.\n);
+
+ if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_MEDIA_VLV) 1),
+ FORCEWAKE_ACK_TIMEOUT_MS))
+ DRM_ERROR(Timed out waiting for media to ack forcewake
request.\n);
Based on some of my recent patches the ' 1's should be
' FORCEWAKE_KERNEL'.
And that was based on my misunderstanding of MT forcewake. I thought
it was so the BIOS or AMT could do forcewake, but it's actually meant
for multiple kernel thread accesses. Since we don't do that, simply
using the lowest bit all the time is fine.
__gen6_gt_wait_for_thread_c0(dev_priv);
}
@@ -4434,8 +4439,8 @@ static void vlv_force_wake_get(struct
drm_i915_private *dev_priv)
static void vlv_force_wake_put(struct drm_i915_private *dev_priv)
{
I915_WRITE_NOTRACE(FORCEWAKE_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
- /* something from same cacheline, but !FORCEWAKE_VLV */
- POSTING_READ(FORCEWAKE_ACK_VLV);
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
+ /* The below doubles as a POSTING_READ */
Are we sure? ;)
gen6_gt_check_fifodbg(dev_priv);
Well it does a read first thing so I think so.
--
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 13/26] drm/i915: use gen6 stolen check on VLV
On Fri, Mar 01, 2013 at 02:08:29PM -0800, Jesse Barnes wrote: It uses the same bit definitions. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Matches what I see in the docs. Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/i915_gem_gtt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 926a1e2..2d7d3a9 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -752,7 +752,7 @@ static int gen6_gmch_probe(struct drm_device *dev, pci_read_config_word(dev-pdev, SNB_GMCH_CTRL, snb_gmch_ctl); gtt_size = gen6_get_total_gtt_size(snb_gmch_ctl); - if (IS_GEN7(dev)) + if (IS_GEN7(dev) !IS_VALLEYVIEW(dev)) *stolen = gen7_get_stolen_size(snb_gmch_ctl); else *stolen = gen6_get_stolen_size(snb_gmch_ctl); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/28] drm/i915: VLV has force wake
On Fri, Mar 01, 2013 at 01:14:13PM -0800, Jesse Barnes wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Commit message is a bit sparse given that the only thing this does is
enable the forcewake duct-tape for more coherent seqno waiting. I've
pimped the commit message a bit.
Applied, thanks.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dba68c3..af19dca 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -275,6 +275,7 @@ static const struct intel_device_info
intel_valleyview_m_info = {
.has_blt_ring = 1,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_force_wake = 1,
};
static const struct intel_device_info intel_valleyview_d_info = {
@@ -285,6 +286,7 @@ static const struct intel_device_info
intel_valleyview_d_info = {
.has_blt_ring = 1,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_force_wake = 1,
};
static const struct intel_device_info intel_haswell_d_info = {
--
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 12/28] drm/i915: add more clock gating for VLV, allow force wake at init
On Fri, Mar 01, 2013 at 01:14:15PM -0800, Jesse Barnes wrote:
From: Ben Widawsky b...@bwidawsk.net
Disable all Gunit clock gating and make set the allow force wake bit.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Can we make the in-code comments here a bit louder to explain that this is
pre-production w/a stuff which should be killed eventually?
-Daniel
---
drivers/gpu/drm/i915/i915_gem.c |4
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 10 +-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8413ffc..dd67698 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4010,7 +4010,11 @@ int i915_gem_init(struct drm_device *dev)
int ret;
mutex_lock(dev-struct_mutex);
+
+ /* VLVA0 (potential hack), BIOS isn't actually waking us */
+ I915_WRITE(VLV_GTLC_WAKE_CTRL, 1);
i915_gem_init_global_gtt(dev);
+
ret = i915_gem_init_hw(dev);
mutex_unlock(dev-struct_mutex);
if (ret) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4c45e91..ecf5f30 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4276,6 +4276,7 @@
#define FORCEWAKE_ACK_VLV 0x1300b4
#define FORCEWAKE_ACK_HSW 0x130044
#define FORCEWAKE_ACK 0x130090
+#define VLV_GTLC_WAKE_CTRL 0x130090
#define FORCEWAKE_MT0xa188 /*
multi-threaded */
#define FORCEWAKE_KERNEL 0x1
#define FORCEWAKE_USER 0x2
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d6d028a..7de8cec 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3991,7 +3991,15 @@ static void valleyview_init_clock_gating(struct
drm_device *dev)
* Disable clock gating on th GCFG unit to prevent a delay
* in the reporting of vblank events.
*/
- I915_WRITE(VLV_GUNIT_CLOCK_GATE, GCFG_DIS);
+ /* VLVA0 HACK */
+ I915_WRITE(VLV_GUNIT_CLOCK_GATE, 0x);
+ I915_WRITE(0x9400, 0x);
+ I915_WRITE(0x9404, 0x);
+ I915_WRITE(0x9408, 0x);
+ I915_WRITE(0x940c, 0x);
+ I915_WRITE(0x9410, 0x);
+ I915_WRITE(0x9414, 0x);
+ I915_WRITE(0x9418, 0x);
}
static void g4x_init_clock_gating(struct drm_device *dev)
--
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 15/26] drm/i915: add media well to VLV force wake routines
On Wed, Mar 06, 2013 at 10:33:34AM -0800, Jesse Barnes wrote:
On Wed, 6 Mar 2013 20:28:07 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Mar 01, 2013 at 02:08:31PM -0800, Jesse Barnes wrote:
We could split this out into a separate routine at some point as an
optimization.
BTW did anyone try to gang wakeup thing instead?
Not afaik.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 1c6e066..558c6d1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4271,6 +4271,8 @@
#define FORCEWAKE 0xA18C
#define FORCEWAKE_VLV 0x1300b0
#define FORCEWAKE_ACK_VLV 0x1300b4
+#define FORCEWAKE_MEDIA_VLV 0x1300b8
+#define FORCEWAKE_ACK_MEDIA_VLV 0x1300bc
#define FORCEWAKE_ACK_HSW 0x130044
#define FORCEWAKE_ACK 0x130090
#define VLV_GTLC_WAKE_CTRL 0x130090
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 3e976f4..e3947cb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4423,10 +4423,15 @@ static void vlv_force_wake_get(struct
drm_i915_private *dev_priv)
DRM_ERROR(Timed out waiting for forcewake old ack to
clear.\n);
I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_VLV) 1),
FORCEWAKE_ACK_TIMEOUT_MS))
- DRM_ERROR(Timed out waiting for forcewake to ack request.\n);
+ DRM_ERROR(Timed out waiting for GT to ack forcewake
request.\n);
+
+ if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_MEDIA_VLV) 1),
+ FORCEWAKE_ACK_TIMEOUT_MS))
+ DRM_ERROR(Timed out waiting for media to ack forcewake
request.\n);
Based on some of my recent patches the ' 1's should be
' FORCEWAKE_KERNEL'.
And that was based on my misunderstanding of MT forcewake. I thought
it was so the BIOS or AMT could do forcewake, but it's actually meant
for multiple kernel thread accesses. Since we don't do that, simply
using the lowest bit all the time is fine.
I just want to be consistent which names we give the bits to avoid
confusing people (mainly myself), that's all.
__gen6_gt_wait_for_thread_c0(dev_priv);
}
@@ -4434,8 +4439,8 @@ static void vlv_force_wake_get(struct
drm_i915_private *dev_priv)
static void vlv_force_wake_put(struct drm_i915_private *dev_priv)
{
I915_WRITE_NOTRACE(FORCEWAKE_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
- /* something from same cacheline, but !FORCEWAKE_VLV */
- POSTING_READ(FORCEWAKE_ACK_VLV);
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
+ /* The below doubles as a POSTING_READ */
Are we sure? ;)
gen6_gt_check_fifodbg(dev_priv);
Well it does a read first thing so I think so.
But does it read the right magic register? Referring to the magic ECOBUS
mess we had earlier. But if this code actually works, then I guess we
can be happy.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/28] drm/i915: disable watermarks on VLV, pondicherry takes care of this
On Fri, Mar 01, 2013 at 01:14:17PM -0800, Jesse Barnes wrote:
For current usage, not needed.
Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7de8cec..b8f5a17 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4211,7 +4211,9 @@ void intel_init_pm(struct drm_device *dev)
} else
dev_priv-display.update_wm = NULL;
} else if (IS_VALLEYVIEW(dev)) {
- dev_priv-display.update_wm = valleyview_update_wm;
+// dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_wm = NULL;
+// dev_priv-display.update_sprite_wm =
valleyview_update_sprite_wm;
Either kill this all (it's kzalloced so no need for NULL assignments) or
add a giant comment explaining what's going on. Adding commented-out code
without comment is strange ...
-Daniel
dev_priv-display.init_clock_gating =
valleyview_init_clock_gating;
} else if (IS_PINEVIEW(dev)) {
--
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 20/28] drm/i915: don't enumerate VGA on VLV
On Fri, Mar 01, 2013 at 01:14:23PM -0800, Jesse Barnes wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fd4a0d4..60397e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8503,7 +8503,8 @@ static void intel_setup_outputs(struct drm_device *dev)
I915_WRITE(PFIT_CONTROL, 0);
}
- if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES)))
+ if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES))
+ !IS_VALLEYVIEW(dev))
If HAS_DDI is true on baytrail, that's a bug in the HAS_DDI macro. And I'd
like that to be a feature-flag in the intel_infor struct anyway, iirc
Damien is volunteered.
-Daniel
intel_crt_init(dev);
if (HAS_DDI(dev)) {
--
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 23/28] drm/i915: use VLV DIP routines on VLV
On Fri, Mar 01, 2013 at 01:14:26PM -0800, Jesse Barnes wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
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 fcb36c6..9982b7f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1038,7 +1038,7 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
BUG();
}
- if (!HAS_PCH_SPLIT(dev)) {
+ if (!HAS_PCH_SPLIT(dev) !IS_VALLEYVIEW(dev)) {
We have an IS_VLV block right below ... move it up? Or just rework the if
ladder here to not use negation, that's imo easier to parse, too.
-Daniel
intel_hdmi-write_infoframe = g4x_write_infoframe;
intel_hdmi-set_infoframes = g4x_set_infoframes;
} else if (IS_VALLEYVIEW(dev)) {
--
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 24/28] drm/i915: export intel_dpio_write for use in intel_dp.c
On Fri, Mar 01, 2013 at 01:14:27PM -0800, Jesse Barnes wrote:
We need it for some DP training related bits.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Maintainer-bikeshed: Imo having such unstatic-only patches doesn't really
add value, I prefer it squashed with the new use-site (with a small
comment in the commit message maybe). True bikeshed, so will merge anyway.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c |3 +--
drivers/gpu/drm/i915/intel_drv.h |2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2559435..022349b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -434,8 +434,7 @@ u32 intel_dpio_read(struct drm_i915_private *dev_priv,
int reg)
return I915_READ(DPIO_DATA);
}
-static void intel_dpio_write(struct drm_i915_private *dev_priv, int reg,
- u32 val)
+void intel_dpio_write(struct drm_i915_private *dev_priv, int reg, u32 val)
{
WARN_ON(!mutex_is_locked(dev_priv-dpio_lock));
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 494037d..03fdfbd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -661,6 +661,8 @@ extern int intel_sprite_get_colorkey(struct drm_device
*dev, void *data,
struct drm_file *file_priv);
extern u32 intel_dpio_read(struct drm_i915_private *dev_priv, int reg);
+extern void intel_dpio_write(struct drm_i915_private *dev_priv, int reg,
+ u32 val);
/* Power-related functions, located in intel_pm.c */
extern void intel_init_pm(struct drm_device *dev);
--
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 20/28] drm/i915: don't enumerate VGA on VLV
On Fri, Mar 01, 2013 at 01:14:23PM -0800, Jesse Barnes wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fd4a0d4..60397e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8503,7 +8503,8 @@ static void intel_setup_outputs(struct drm_device *dev)
I915_WRITE(PFIT_CONTROL, 0);
}
- if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES)))
+ if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES))
+ !IS_VALLEYVIEW(dev))
intel_crt_init(dev);
I was under the impression that VLV still has this. Was I mistaken?
if (HAS_DDI(dev)) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/28] drm/i915/dp: don't use ILK paths on VLV
On Fri, Mar 01, 2013 at 01:14:30PM -0800, Jesse Barnes wrote:
Fix up a couple of places where we messed with PCH bits on VLV.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
We might want ot untangle the cpu vs. pch dp port question from the dp vs.
edp question eventually. Anyway, I've merged this patch here to dinq.
-Daniel
---
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 03340fd..05e1000 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -976,7 +976,7 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode,
intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
}
- if (is_cpu_edp(intel_dp))
+ if (is_cpu_edp(intel_dp) !IS_VALLEYVIEW(dev))
ironlake_set_pll_edp(crtc, adjusted_mode-clock);
}
@@ -1373,7 +1373,7 @@ static bool intel_dp_get_hw_state(struct intel_encoder
*encoder,
if (!(tmp DP_PORT_EN))
return false;
- if (is_cpu_edp(intel_dp) IS_GEN7(dev)) {
+ if (is_cpu_edp(intel_dp) IS_GEN7(dev) !IS_VALLEYVIEW(dev)) {
*pipe = PORT_TO_PIPE_CPT(tmp);
} else if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
*pipe = PORT_TO_PIPE(tmp);
--
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 28/28] drm/i915/dp: add pre-PCH eDP checking to DP detect for VLV
On Fri, Mar 01, 2013 at 01:14:31PM -0800, Jesse Barnes wrote:
Allows us to detect eDP panels that may not have the hotplug pin wired up.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Historically the lid status is horribly broken which is why it's disabled
by default. What changed to now enable it unconditionally? Is this a
requirement on vlv?
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 05e1000..c127cb7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2413,6 +2413,16 @@ g4x_dp_detect(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
uint32_t bit;
+ /* Can't disconnect eDP, but you can close the lid... */
+ if (is_edp(intel_dp)) {
+ enum drm_connector_status status;
+
+ status = intel_panel_detect(dev);
+ if (status == connector_status_unknown)
+ status = connector_status_connected;
+ return status;
+ }
+
switch (intel_dig_port-port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS;
--
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 13/26] drm/i915: use gen6 stolen check on VLV
On Wed, Mar 06, 2013 at 08:45:47PM +0200, Ville Syrjälä wrote: On Fri, Mar 01, 2013 at 02:08:29PM -0800, Jesse Barnes wrote: It uses the same bit definitions. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Matches what I see in the docs. Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Queued for -next, thanks for the patch. -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 15/26] drm/i915: add media well to VLV force wake routines
On Wed, Mar 06, 2013 at 10:33:34AM -0800, Jesse Barnes wrote:
On Wed, 6 Mar 2013 20:28:07 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Mar 01, 2013 at 02:08:31PM -0800, Jesse Barnes wrote:
We could split this out into a separate routine at some point as an
optimization.
BTW did anyone try to gang wakeup thing instead?
Not afaik.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 1c6e066..558c6d1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4271,6 +4271,8 @@
#define FORCEWAKE 0xA18C
#define FORCEWAKE_VLV 0x1300b0
#define FORCEWAKE_ACK_VLV 0x1300b4
+#define FORCEWAKE_MEDIA_VLV 0x1300b8
+#define FORCEWAKE_ACK_MEDIA_VLV 0x1300bc
#define FORCEWAKE_ACK_HSW 0x130044
#define FORCEWAKE_ACK 0x130090
#define VLV_GTLC_WAKE_CTRL 0x130090
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 3e976f4..e3947cb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4423,10 +4423,15 @@ static void vlv_force_wake_get(struct
drm_i915_private *dev_priv)
DRM_ERROR(Timed out waiting for forcewake old ack to
clear.\n);
I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_VLV) 1),
FORCEWAKE_ACK_TIMEOUT_MS))
- DRM_ERROR(Timed out waiting for forcewake to ack request.\n);
+ DRM_ERROR(Timed out waiting for GT to ack forcewake
request.\n);
+
+ if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_MEDIA_VLV) 1),
+ FORCEWAKE_ACK_TIMEOUT_MS))
+ DRM_ERROR(Timed out waiting for media to ack forcewake
request.\n);
Based on some of my recent patches the ' 1's should be
' FORCEWAKE_KERNEL'.
And that was based on my misunderstanding of MT forcewake. I thought
it was so the BIOS or AMT could do forcewake, but it's actually meant
for multiple kernel thread accesses. Since we don't do that, simply
using the lowest bit all the time is fine.
You're a bit outdated, we now use that facility. It's the only way to pull
off the forcewake dance required to get scanline waits working on gen7. So
I guess the same applies for vlv ...
-Daniel
__gen6_gt_wait_for_thread_c0(dev_priv);
}
@@ -4434,8 +4439,8 @@ static void vlv_force_wake_get(struct
drm_i915_private *dev_priv)
static void vlv_force_wake_put(struct drm_i915_private *dev_priv)
{
I915_WRITE_NOTRACE(FORCEWAKE_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
- /* something from same cacheline, but !FORCEWAKE_VLV */
- POSTING_READ(FORCEWAKE_ACK_VLV);
+ I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV,
_MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
+ /* The below doubles as a POSTING_READ */
Are we sure? ;)
gen6_gt_check_fifodbg(dev_priv);
Well it does a read first thing so I think so.
--
Jesse Barnes, Intel Open Source Technology Center
___
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 20/28] drm/i915: don't enumerate VGA on VLV
On Wed, 6 Mar 2013 21:00:11 +0200 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Fri, Mar 01, 2013 at 01:14:23PM -0800, Jesse Barnes wrote: Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index fd4a0d4..60397e8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8503,7 +8503,8 @@ static void intel_setup_outputs(struct drm_device *dev) I915_WRITE(PFIT_CONTROL, 0); } - if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES))) + if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES)) + !IS_VALLEYVIEW(dev)) intel_crt_init(dev); I was under the impression that VLV still has this. Was I mistaken? Not exposed anymore I think. And yeah this can be dropped since the DDI check should dtrt. -- 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 14/28] drm/i915: disable watermarks on VLV, pondicherry takes care of this
On Wed, Mar 06, 2013 at 07:56:33PM +0100, Daniel Vetter wrote:
On Fri, Mar 01, 2013 at 01:14:17PM -0800, Jesse Barnes wrote:
For current usage, not needed.
Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 7de8cec..b8f5a17 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4211,7 +4211,9 @@ void intel_init_pm(struct drm_device *dev)
} else
dev_priv-display.update_wm = NULL;
} else if (IS_VALLEYVIEW(dev)) {
- dev_priv-display.update_wm = valleyview_update_wm;
+// dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_wm = NULL;
+// dev_priv-display.update_sprite_wm =
valleyview_update_sprite_wm;
Either kill this all (it's kzalloced so no need for NULL assignments) or
add a giant comment explaining what's going on. Adding commented-out code
without comment is strange ...
The whole premise that pondicherry magically handles things is a bit
weird too. I suppose all it really means is that the default WMs were
high enough to avoid underruns for the guys who tested this.
Actually wasn't there a comment on an earlier version of this patch
that there was a div by zero or something, and that's the real reason
for this patch?
-Daniel
dev_priv-display.init_clock_gating =
valleyview_init_clock_gating;
} else if (IS_PINEVIEW(dev)) {
--
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
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/28] drm/i915: use VLV DIP routines on VLV
On Wed, 6 Mar 2013 20:00:37 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Mar 01, 2013 at 01:14:26PM -0800, Jesse Barnes wrote:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
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 fcb36c6..9982b7f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1038,7 +1038,7 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
BUG();
}
- if (!HAS_PCH_SPLIT(dev)) {
+ if (!HAS_PCH_SPLIT(dev) !IS_VALLEYVIEW(dev)) {
We have an IS_VLV block right below ... move it up? Or just rework the if
ladder here to not use negation, that's imo easier to parse, too.
-Daniel
intel_hdmi-write_infoframe = g4x_write_infoframe;
intel_hdmi-set_infoframes = g4x_set_infoframes;
} else if (IS_VALLEYVIEW(dev)) {
--
Yeah that would be better.
--
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 24/28] drm/i915: export intel_dpio_write for use in intel_dp.c
On Wed, 6 Mar 2013 20:02:43 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Fri, Mar 01, 2013 at 01:14:27PM -0800, Jesse Barnes wrote: We need it for some DP training related bits. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Maintainer-bikeshed: Imo having such unstatic-only patches doesn't really add value, I prefer it squashed with the new use-site (with a small comment in the commit message maybe). True bikeshed, so will merge anyway. Yeah feel free to squash into the DP vswing/preemphasis patch, that's what needs it. Having it split out helped me with merge rebase along the way but it's definitely not necessary... -- 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 14/28] drm/i915: disable watermarks on VLV, pondicherry takes care of this
On Wed, Mar 06, 2013 at 09:09:06PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2013 at 07:56:33PM +0100, Daniel Vetter wrote:
On Fri, Mar 01, 2013 at 01:14:17PM -0800, Jesse Barnes wrote:
For current usage, not needed.
Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 7de8cec..b8f5a17 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4211,7 +4211,9 @@ void intel_init_pm(struct drm_device *dev)
} else
dev_priv-display.update_wm = NULL;
} else if (IS_VALLEYVIEW(dev)) {
- dev_priv-display.update_wm = valleyview_update_wm;
+// dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_wm = NULL;
+// dev_priv-display.update_sprite_wm =
valleyview_update_sprite_wm;
Either kill this all (it's kzalloced so no need for NULL assignments) or
add a giant comment explaining what's going on. Adding commented-out code
without comment is strange ...
The whole premise that pondicherry magically handles things is a bit
weird too. I suppose all it really means is that the default WMs were
high enough to avoid underruns for the guys who tested this.
Actually wasn't there a comment on an earlier version of this patch
that there was a div by zero or something, and that's the real reason
for this patch?
Fyi the patch which fixed div-by-zero on other platforms is:
commit 3490ea5de6ac4af309c3df8a26a5cca61306334c
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Jan 7 10:11:40 2013 +
drm/i915: Treat crtc-mode.clock == 0 as disabled
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
Re: [Intel-gfx] [PATCH 20/28] drm/i915: don't enumerate VGA on VLV
On Wed, Mar 06, 2013 at 11:09:08AM -0800, Jesse Barnes wrote: On Wed, 6 Mar 2013 21:00:11 +0200 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Fri, Mar 01, 2013 at 01:14:23PM -0800, Jesse Barnes wrote: Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index fd4a0d4..60397e8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8503,7 +8503,8 @@ static void intel_setup_outputs(struct drm_device *dev) I915_WRITE(PFIT_CONTROL, 0); } - if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES))) + if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES)) + !IS_VALLEYVIEW(dev)) intel_crt_init(dev); I was under the impression that VLV still has this. Was I mistaken? Not exposed anymore I think. And yeah this can be dropped since the DDI check should dtrt. It's testing for !HAS_DDI() which should equal true for VLV. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/28] drm/i915: disable watermarks on VLV, pondicherry takes care of this
On Wed, Mar 06, 2013 at 08:14:54PM +0100, Daniel Vetter wrote:
On Wed, Mar 06, 2013 at 09:09:06PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2013 at 07:56:33PM +0100, Daniel Vetter wrote:
On Fri, Mar 01, 2013 at 01:14:17PM -0800, Jesse Barnes wrote:
For current usage, not needed.
Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 7de8cec..b8f5a17 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4211,7 +4211,9 @@ void intel_init_pm(struct drm_device *dev)
} else
dev_priv-display.update_wm = NULL;
} else if (IS_VALLEYVIEW(dev)) {
- dev_priv-display.update_wm = valleyview_update_wm;
+// dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_wm = NULL;
+// dev_priv-display.update_sprite_wm =
valleyview_update_sprite_wm;
Either kill this all (it's kzalloced so no need for NULL assignments) or
add a giant comment explaining what's going on. Adding commented-out code
without comment is strange ...
The whole premise that pondicherry magically handles things is a bit
weird too. I suppose all it really means is that the default WMs were
high enough to avoid underruns for the guys who tested this.
Actually wasn't there a comment on an earlier version of this patch
that there was a div by zero or something, and that's the real reason
for this patch?
Fyi the patch which fixed div-by-zero on other platforms is:
commit 3490ea5de6ac4af309c3df8a26a5cca61306334c
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Jan 7 10:11:40 2013 +
drm/i915: Treat crtc-mode.clock == 0 as disabled
Now I actually remember that Jani did try reverting this patch in his
tree, and didn't get any div by zeros. So we were a bit confused about
the patch at the time. If he had that fix in his tree, then that would
explain it. Maybe this patch can be dropped then?
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.9-rc1 instability on Chromebook Pixel with gmbus irq
Hi Daniel, I've just tried drm-intel-fixes merged into v3.9-rc1, and so far it's looking good. No suspicious timeouts. Thanks for the quick response! Benson On Wed, Mar 6, 2013 at 12:14 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung ble...@chromium.org wrote: I'm working on touch devices Chromium OS, and I've noticed a regression between 3.8 and 3.9-rc1, which was posted yesterday. The hardware in question is a Chromebook Pixel. For this device, we have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s touchscreen. The touchpad is on bus 1, i915 gmbus vga at 1-004b. The touchscreen is on bus 2, i915 gmbus panel at 2-004a. I was testing v3.9-rc1 on the Pixel and the touchscreen driver is being returned -110 (-ETIMEDOUT) on an i2c_transfer after several seconds of both touch devices working correctly. At the time of the failure, there are no error messages from GMBUS that I can see, but the bus never recovers. I can keep interacting with the touchscreen or touchpad, and the interrupts trigger reads, but all subsequent reads return -110. I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus irq support was merged. After bisecting, I found that this commit seems to be causing the timeout problem. Reverting it makes the problem go away, and the bus is stable. Can you please retest with latest drm-intel-fixes merged into -rc1? Paulo's patch fixes a race in handling PCH interrupts (where the gmbus hw is) which matches rather well with your description here. Thanks, Daniel commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Sat Dec 1 13:53:46 2012 +0100 drm/i915: use gmbus irq to wait for gmbus idle GMBUS_ACTIVE has inverted sense and so doesn't fit into the wait_hw_status helper, hence create a new gmbus_wait_idle functions. Also, we only care about the idle irq event and nothing else, which allows us to use the wait_event_timeout helper directly without jumping through hoops to catch NAKs. Since gen2/3 don't have gmbus interrupts, handle them separately with the old wait_for macro. This shaves another few ms off reading EDID from a hdmi screen on my testbox here. EDID reading with interrupt driven gmbus is now as fast as with busy-looping gmbus at 28 ms here (with negligible cpu overhead). Reviewed-by: Imre Deak imre.d...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Is there anything I can do to help debug this some more? -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/28] drm/i915: disable watermarks on VLV, pondicherry takes care of this
On Wed, Mar 06, 2013 at 09:19:27PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2013 at 08:14:54PM +0100, Daniel Vetter wrote:
On Wed, Mar 06, 2013 at 09:09:06PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2013 at 07:56:33PM +0100, Daniel Vetter wrote:
On Fri, Mar 01, 2013 at 01:14:17PM -0800, Jesse Barnes wrote:
For current usage, not needed.
Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 7de8cec..b8f5a17 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4211,7 +4211,9 @@ void intel_init_pm(struct drm_device *dev)
} else
dev_priv-display.update_wm = NULL;
} else if (IS_VALLEYVIEW(dev)) {
- dev_priv-display.update_wm = valleyview_update_wm;
+// dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_wm = NULL;
+// dev_priv-display.update_sprite_wm =
valleyview_update_sprite_wm;
Either kill this all (it's kzalloced so no need for NULL assignments) or
add a giant comment explaining what's going on. Adding commented-out
code
without comment is strange ...
The whole premise that pondicherry magically handles things is a bit
weird too. I suppose all it really means is that the default WMs were
high enough to avoid underruns for the guys who tested this.
Actually wasn't there a comment on an earlier version of this patch
that there was a div by zero or something, and that's the real reason
for this patch?
Fyi the patch which fixed div-by-zero on other platforms is:
commit 3490ea5de6ac4af309c3df8a26a5cca61306334c
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Jan 7 10:11:40 2013 +
drm/i915: Treat crtc-mode.clock == 0 as disabled
Now I actually remember that Jani did try reverting this patch in his
tree, and didn't get any div by zeros. So we were a bit confused about
the patch at the time. If he had that fix in his tree, then that would
explain it. Maybe this patch can be dropped then?
This is a fallout from the reworked modeset code. Since we now read out
the bios hw state, if the new state leaves pipe B running, but enables
pipe A (happens only when the bios enables pipe B) we try to recompute
watermarks for pipe B, but that mode is 0. Hence boom.
This patch can be killed once the hw state readout is properly extended to
cover the required information (i.e. we need to move all the wm code to
only look at pipe_config and ensure that all the values in there are
correct).
Once booted, you can't hit this any 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 15/26] drm/i915: add media well to VLV force wake routines
On Wed, 6 Mar 2013 20:10:42 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Mar 06, 2013 at 10:33:34AM -0800, Jesse Barnes wrote: On Wed, 6 Mar 2013 20:28:07 +0200 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Fri, Mar 01, 2013 at 02:08:31PM -0800, Jesse Barnes wrote: We could split this out into a separate routine at some point as an optimization. BTW did anyone try to gang wakeup thing instead? Not afaik. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_reg.h |2 ++ drivers/gpu/drm/i915/intel_pm.c | 11 --- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 1c6e066..558c6d1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4271,6 +4271,8 @@ #define FORCEWAKE 0xA18C #define FORCEWAKE_VLV 0x1300b0 #define FORCEWAKE_ACK_VLV 0x1300b4 +#define FORCEWAKE_MEDIA_VLV 0x1300b8 +#define FORCEWAKE_ACK_MEDIA_VLV 0x1300bc #define FORCEWAKE_ACK_HSW 0x130044 #define FORCEWAKE_ACK 0x130090 #define VLV_GTLC_WAKE_CTRL0x130090 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 3e976f4..e3947cb 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4423,10 +4423,15 @@ static void vlv_force_wake_get(struct drm_i915_private *dev_priv) DRM_ERROR(Timed out waiting for forcewake old ack to clear.\n); I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL)); + I915_WRITE_NOTRACE(FORCEWAKE_MEDIA_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL)); if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_VLV) 1), FORCEWAKE_ACK_TIMEOUT_MS)) - DRM_ERROR(Timed out waiting for forcewake to ack request.\n); + DRM_ERROR(Timed out waiting for GT to ack forcewake request.\n); + + if (wait_for_atomic((I915_READ_NOTRACE(FORCEWAKE_ACK_MEDIA_VLV) 1), + FORCEWAKE_ACK_TIMEOUT_MS)) + DRM_ERROR(Timed out waiting for media to ack forcewake request.\n); Based on some of my recent patches the ' 1's should be ' FORCEWAKE_KERNEL'. And that was based on my misunderstanding of MT forcewake. I thought it was so the BIOS or AMT could do forcewake, but it's actually meant for multiple kernel thread accesses. Since we don't do that, simply using the lowest bit all the time is fine. You're a bit outdated, we now use that facility. It's the only way to pull off the forcewake dance required to get scanline waits working on gen7. So I guess the same applies for vlv ... Ah ok, I'll fix this up then. -- 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 28/28] drm/i915/dp: add pre-PCH eDP checking to DP detect for VLV
On Wed, 6 Mar 2013 20:05:59 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Mar 01, 2013 at 01:14:31PM -0800, Jesse Barnes wrote:
Allows us to detect eDP panels that may not have the hotplug pin wired up.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Historically the lid status is horribly broken which is why it's disabled
by default. What changed to now enable it unconditionally? Is this a
requirement on vlv?
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 05e1000..c127cb7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2413,6 +2413,16 @@ g4x_dp_detect(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
uint32_t bit;
+ /* Can't disconnect eDP, but you can close the lid... */
+ if (is_edp(intel_dp)) {
+ enum drm_connector_status status;
+
+ status = intel_panel_detect(dev);
+ if (status == connector_status_unknown)
+ status = connector_status_connected;
+ return status;
+ }
+
Well this doesn't touch the panel_detect() stuff at all, where we have
the hacks to avoid using _LID...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [pull] drm-intel-fixes
Hi Dave, A bunch of fixes, nothing truely horrible: - Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs and subsequent fallout (Paulo) - Fixup off-by-one in our hsw id table (Kenneth) - Fixup ilk rc6 support (disabled by default), regression introduced in 3.8 - g4x plane w/a from Egbert Eich - gen2/3/4 dpms suspend/standy fixes for VGA outputs from Patrik Jakobsson - Workaround dying ivb machines with less aggressive rc6 values (Stéphane Marchesin) Most of the patches are cc: stable, one with a note about an additional patch which needs to be backported as prerequisite. Cheers, Daniel The following changes since commit 202adf4b9f5957b26a1cb97267d78e0edb319c5e: drm/i915: Revert hdmi HDP pin checks (2013-02-22 13:04:33 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to f40ebd6bcbbd0d30591f42dc16be52b5086a366b: drm/i915: Turn off hsync and vsync on ADPA when disabling crt (2013-03-06 18:03:07 +0100) Daniel Vetter (1): drm/i915: enable irqs earlier when resuming Egbert Eich (1): DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. Kenneth Graunke (1): drm/i915: Fix Haswell/CRW PCI IDs. Patrik Jakobsson (2): drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits drm/i915: Turn off hsync and vsync on ADPA when disabling crt Paulo Zanoni (2): drm/i915: wait_event_timeout's timeout is in jiffies drm/i915: also disable south interrupts when handling them Stéphane Marchesin (1): drm/i915: Increase the RC6p threshold. Syam Sidhardhan (1): drm/i915: Fix missing variable initilization Ville Syrjälä (1): drm/i915: Don't clobber crtc-fb when queue_flip fails drivers/gpu/drm/i915/i915_drv.c | 25 --- drivers/gpu/drm/i915/i915_irq.c | 26 ++-- drivers/gpu/drm/i915/i915_reg.h |4 ++-- drivers/gpu/drm/i915/intel_crt.c |2 +- drivers/gpu/drm/i915/intel_ddi.c |2 +- drivers/gpu/drm/i915/intel_display.c | 37 +++--- drivers/gpu/drm/i915/intel_dp.c |3 ++- drivers/gpu/drm/i915/intel_pm.c |2 +- 8 files changed, 79 insertions(+), 22 deletions(-) -- 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 28/28] drm/i915/dp: add pre-PCH eDP checking to DP detect for VLV
On Wed, Mar 6, 2013 at 9:55 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 6 Mar 2013 20:05:59 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Mar 01, 2013 at 01:14:31PM -0800, Jesse Barnes wrote:
Allows us to detect eDP panels that may not have the hotplug pin wired up.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Historically the lid status is horribly broken which is why it's disabled
by default. What changed to now enable it unconditionally? Is this a
requirement on vlv?
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 05e1000..c127cb7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2413,6 +2413,16 @@ g4x_dp_detect(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
uint32_t bit;
+ /* Can't disconnect eDP, but you can close the lid... */
+ if (is_edp(intel_dp)) {
+ enum drm_connector_status status;
+
+ status = intel_panel_detect(dev);
+ if (status == connector_status_unknown)
+ status = connector_status_connected;
+ return status;
+ }
+
Well this doesn't touch the panel_detect() stuff at all, where we have
the hacks to avoid using _LID...
Oh right, patch looks good to me now ;-) Merget to dinq, thanks.
-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] commit drm/i915: disable shared panel fitter for pipe breaks resolution switching
On Wed, Mar 6, 2013 at 7:39 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote: On 03/06/2013 03:00 PM, Daniel Vetter wrote: Hi Hans, Can you please test with 3.9-rc1? That contains an additional patch which might prevent the regression. Specifically commit 9d6d9f19e8146fa24903cb561e204a22232740e3 Author: Mika Kuoppala mika.kuopp...@linux.intel.com Date: Fri Feb 8 16:35:38 2013 +0200 drm/i915: clean up panel fitter handling in lvds Today's kernel still contains the bug. Hm, I've just retested latest drm-intel-nightly which should have the same set of relevant patches, and I couldn't reproduce your issue. Low-res modes on the lvds panel seem to correctly scale up here on my 945gm. Can you pls retest with latest -nightly from http://cgit.freedesktop.org/~danvet/drm-intel ? Also please attach the output of xrandr --verbose when running with a reduced mode. Thanks, 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] [PATCH 00/15] More unclaimed register fixes
From: Paulo Zanoni paulo.r.zan...@intel.com Hi This series fixes a few more unclaimed register problems. Some of them are only visible if you're only using eDP (i.e., the power well is down) and most of them are only visible if you get a GPU hang. The good thing is that I only get GPU hangs when I run ZZ_hangman :) Now when I boot a machine with only eDP the only unclaimed register message I see is right after the audio driver loads. And then if I run ZZ_hangmen I won't see unclaimed register messages. Big series but small patches, most of them trivial. Thanks, Paulo Paulo Zanoni (15): drm/i915: only disable DDI sound if intel_crtc-eld_vld drm/i915: disable sound first on intel_disable_ddi drm/i915: add intel_power_well_is_down drm/i915: don't touch the PF regs if the power well is down drm/i915: capture the correct cursor registers on IVB drm/i915: there's no DSPSIZE register on gen4+ drm/i915: there's no DSPADDR register on Haswell drm/i915: remove DSPPOS register drm/i915: there's no PIPESTAT on Gen5+ drm/i915: check the power well when capturing error state drm/i915: add HAS_POWER_WELL drm/i915: reorganize intel_lvds_supported drm/i915: don't save/restore PCH_LVDS on LPT drm/i915: check the power well on i915_pipe_enabled drm/i915: add missing space in error message drivers/gpu/drm/i915/i915_drv.h |3 +- drivers/gpu/drm/i915/i915_irq.c | 10 +++-- drivers/gpu/drm/i915/i915_reg.h |3 -- drivers/gpu/drm/i915/i915_suspend.c |7 +-- drivers/gpu/drm/i915/i915_ums.c |4 -- drivers/gpu/drm/i915/intel_ddi.c | 11 +++-- drivers/gpu/drm/i915/intel_display.c | 80 +++--- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_lvds.c| 10 ++--- drivers/gpu/drm/i915/intel_pm.c | 20 - 10 files changed, 98 insertions(+), 51 deletions(-) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915: only disable DDI sound if intel_crtc-eld_vld
From: Paulo Zanoni paulo.r.zan...@intel.com
We already have the same check on intel_enable_ddi. This patch
prevents unclaimed register messages when the power well is
disabled.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 56bb7cb..cd2f519 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1347,9 +1347,12 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
ironlake_edp_backlight_off(intel_dp);
}
- tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
- tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
- I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
+ if (intel_crtc-eld_vld) {
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A)
+(pipe * 4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
+ }
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915: disable sound first on intel_disable_ddi
From: Paulo Zanoni paulo.r.zan...@intel.com
Our mode set sequence documentation says audio must be disabled before
the backlight.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd2f519..c4c0e7e 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1341,18 +1341,18 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t tmp;
- if (type == INTEL_OUTPUT_EDP) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- ironlake_edp_backlight_off(intel_dp);
- }
-
if (intel_crtc-eld_vld) {
tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A)
(pipe * 4));
I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
}
+
+ if (type == INTEL_OUTPUT_EDP) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ ironlake_edp_backlight_off(intel_dp);
+ }
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: add intel_power_well_is_down
From: Paulo Zanoni paulo.r.zan...@intel.com
It returns true if we're not supposed to touch the registers on the
power down well.
For now there's just one caller, but I'm going to add more.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 16
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 502cb28..bd27336 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1227,8 +1227,8 @@ void assert_pipe(struct drm_i915_private *dev_priv,
if (pipe == PIPE_A dev_priv-quirks QUIRK_PIPEA_FORCE)
state = true;
- if (IS_HASWELL(dev_priv-dev) cpu_transcoder != TRANSCODER_EDP
- !(I915_READ(HSW_PWR_WELL_DRIVER) HSW_PWR_WELL_ENABLE)) {
+ if (intel_power_well_is_down(dev_priv-dev)
+ cpu_transcoder != TRANSCODER_EDP) {
cur_state = false;
} else {
reg = PIPECONF(cpu_transcoder);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 010e998..28c4789 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -671,6 +671,7 @@ extern void intel_update_fbc(struct drm_device *dev);
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
extern void intel_gpu_ips_teardown(void);
+extern bool intel_power_well_is_down(struct drm_device *dev);
extern void intel_init_power_well(struct drm_device *dev);
extern void intel_set_power_well(struct drm_device *dev, bool enable);
extern void intel_enable_gt_powersave(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5479363..90562bc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4070,6 +4070,22 @@ void intel_init_clock_gating(struct drm_device *dev)
dev_priv-display.init_clock_gating(dev);
}
+/**
+ * Returns true if we're not supposed to touch the registers on the power down
+ * well. Notice that we don't check whether the power well is actually off, we
+ * just check if our driver told the hardware that it doesn't need the power
+ * well enabled.
+ */
+bool intel_power_well_is_down(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (IS_HASWELL(dev))
+ return !(I915_READ(HSW_PWR_WELL_DRIVER) HSW_PWR_WELL_ENABLE);
+ else
+ return false;
+}
+
void intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: there's no DSPSIZE register on gen4+
From: Paulo Zanoni paulo.r.zan...@intel.com
So don't read it when capturing the error state. This solves some
unclaimed register messages on Haswell when we hang the GPU.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 789a95a..56cca6e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9348,7 +9348,8 @@ intel_display_capture_error_state(struct drm_device *dev)
error-plane[i].control = I915_READ(DSPCNTR(i));
error-plane[i].stride = I915_READ(DSPSTRIDE(i));
- error-plane[i].size = I915_READ(DSPSIZE(i));
+ if (INTEL_INFO(dev)-gen = 3)
+ error-plane[i].size = I915_READ(DSPSIZE(i));
error-plane[i].pos = I915_READ(DSPPOS(i));
error-plane[i].addr = I915_READ(DSPADDR(i));
if (INTEL_INFO(dev)-gen = 4) {
@@ -9392,7 +9393,8 @@ intel_display_print_error_state(struct seq_file *m,
seq_printf(m, Plane [%d]:\n, i);
seq_printf(m, CNTR: %08x\n, error-plane[i].control);
seq_printf(m, STRIDE: %08x\n, error-plane[i].stride);
- seq_printf(m, SIZE: %08x\n, error-plane[i].size);
+ if (INTEL_INFO(dev)-gen = 3)
+ seq_printf(m, SIZE: %08x\n, error-plane[i].size);
seq_printf(m, POS: %08x\n, error-plane[i].pos);
seq_printf(m, ADDR: %08x\n, error-plane[i].addr);
if (INTEL_INFO(dev)-gen = 4) {
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/15] drm/i915: there's no DSPADDR register on Haswell
From: Paulo Zanoni paulo.r.zan...@intel.com
So don't read it when we hang the GPU. This solves unclaimed
register messages.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 56cca6e..0451056 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9351,7 +9351,8 @@ intel_display_capture_error_state(struct drm_device *dev)
if (INTEL_INFO(dev)-gen = 3)
error-plane[i].size = I915_READ(DSPSIZE(i));
error-plane[i].pos = I915_READ(DSPPOS(i));
- error-plane[i].addr = I915_READ(DSPADDR(i));
+ if (!IS_HASWELL(dev))
+ error-plane[i].addr = I915_READ(DSPADDR(i));
if (INTEL_INFO(dev)-gen = 4) {
error-plane[i].surface = I915_READ(DSPSURF(i));
error-plane[i].tile_offset = I915_READ(DSPTILEOFF(i));
@@ -9396,7 +9397,8 @@ intel_display_print_error_state(struct seq_file *m,
if (INTEL_INFO(dev)-gen = 3)
seq_printf(m, SIZE: %08x\n, error-plane[i].size);
seq_printf(m, POS: %08x\n, error-plane[i].pos);
- seq_printf(m, ADDR: %08x\n, error-plane[i].addr);
+ if (!IS_HASWELL(dev))
+ seq_printf(m, ADDR: %08x\n, error-plane[i].addr);
if (INTEL_INFO(dev)-gen = 4) {
seq_printf(m, SURF: %08x\n,
error-plane[i].surface);
seq_printf(m, TILEOFF: %08x\n,
error-plane[i].tile_offset);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/i915: remove DSPPOS register
From: Paulo Zanoni paulo.r.zan...@intel.com
I couldn't find any evidence that this register exists on Gen2+. On
Gen 2/3/4 documents this register is listed as reserved and read-only.
On the newer Gens this register is not even documented.
Also all we do with this register is:
- Write 0 to it on i9xx_crtc_mode_set
- Save/restore its value on the UMS code
- Read it on intel_display_capture_error_state
This commit fixes unclaimed register messages when there's a GPU
hang on Haswell.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 --
drivers/gpu/drm/i915/i915_reg.h |3 ---
drivers/gpu/drm/i915/i915_ums.c |4
drivers/gpu/drm/i915/intel_display.c |4
4 files changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca6b215..9bf15e5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -513,7 +513,6 @@ struct i915_suspend_saved_registers {
u32 savePIPEASTAT;
u32 saveDSPASTRIDE;
u32 saveDSPASIZE;
- u32 saveDSPAPOS;
u32 saveDSPAADDR;
u32 saveDSPASURF;
u32 saveDSPATILEOFF;
@@ -544,7 +543,6 @@ struct i915_suspend_saved_registers {
u32 savePIPEBSTAT;
u32 saveDSPBSTRIDE;
u32 saveDSPBSIZE;
- u32 saveDSPBPOS;
u32 saveDSPBADDR;
u32 saveDSPBSURF;
u32 saveDSPBTILEOFF;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4cf3ece..26e4b86 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3051,7 +3051,6 @@
#define DISPPLANE_TILED (110)
#define _DSPAADDR (dev_priv-info-display_mmio_offset + 0x70184)
#define _DSPASTRIDE(dev_priv-info-display_mmio_offset + 0x70188)
-#define _DSPAPOS (dev_priv-info-display_mmio_offset + 0x7018C)
/* reserved */
#define _DSPASIZE (dev_priv-info-display_mmio_offset + 0x70190)
#define _DSPASURF (dev_priv-info-display_mmio_offset + 0x7019C)
/* 965+ only */
#define _DSPATILEOFF (dev_priv-info-display_mmio_offset + 0x701A4)
/* 965+ only */
@@ -3061,7 +3060,6 @@
#define DSPCNTR(plane) _PIPE(plane, _DSPACNTR, _DSPBCNTR)
#define DSPADDR(plane) _PIPE(plane, _DSPAADDR, _DSPBADDR)
#define DSPSTRIDE(plane) _PIPE(plane, _DSPASTRIDE, _DSPBSTRIDE)
-#define DSPPOS(plane) _PIPE(plane, _DSPAPOS, _DSPBPOS)
#define DSPSIZE(plane) _PIPE(plane, _DSPASIZE, _DSPBSIZE)
#define DSPSURF(plane) _PIPE(plane, _DSPASURF, _DSPBSURF)
#define DSPTILEOFF(plane) _PIPE(plane, _DSPATILEOFF, _DSPBTILEOFF)
@@ -3109,7 +3107,6 @@
#define DISPPLANE_SPRITE_ABOVE_OVERLAY (1)
#define _DSPBADDR (dev_priv-info-display_mmio_offset + 0x71184)
#define _DSPBSTRIDE(dev_priv-info-display_mmio_offset + 0x71188)
-#define _DSPBPOS (dev_priv-info-display_mmio_offset + 0x7118C)
#define _DSPBSIZE (dev_priv-info-display_mmio_offset + 0x71190)
#define _DSPBSURF (dev_priv-info-display_mmio_offset + 0x7119C)
#define _DSPBTILEOFF (dev_priv-info-display_mmio_offset + 0x711A4)
diff --git a/drivers/gpu/drm/i915/i915_ums.c b/drivers/gpu/drm/i915/i915_ums.c
index 985a097..0e21925 100644
--- a/drivers/gpu/drm/i915/i915_ums.c
+++ b/drivers/gpu/drm/i915/i915_ums.c
@@ -160,7 +160,6 @@ void i915_save_display_reg(struct drm_device *dev)
dev_priv-regfile.saveDSPACNTR = I915_READ(_DSPACNTR);
dev_priv-regfile.saveDSPASTRIDE = I915_READ(_DSPASTRIDE);
dev_priv-regfile.saveDSPASIZE = I915_READ(_DSPASIZE);
- dev_priv-regfile.saveDSPAPOS = I915_READ(_DSPAPOS);
dev_priv-regfile.saveDSPAADDR = I915_READ(_DSPAADDR);
if (INTEL_INFO(dev)-gen = 4) {
dev_priv-regfile.saveDSPASURF = I915_READ(_DSPASURF);
@@ -217,7 +216,6 @@ void i915_save_display_reg(struct drm_device *dev)
dev_priv-regfile.saveDSPBCNTR = I915_READ(_DSPBCNTR);
dev_priv-regfile.saveDSPBSTRIDE = I915_READ(_DSPBSTRIDE);
dev_priv-regfile.saveDSPBSIZE = I915_READ(_DSPBSIZE);
- dev_priv-regfile.saveDSPBPOS = I915_READ(_DSPBPOS);
dev_priv-regfile.saveDSPBADDR = I915_READ(_DSPBADDR);
if (INTEL_INFO(dev)-gen = 4) {
dev_priv-regfile.saveDSPBSURF = I915_READ(_DSPBSURF);
@@ -390,7 +388,6 @@ void i915_restore_display_reg(struct drm_device *dev)
/* Restore plane info */
I915_WRITE(_DSPASIZE, dev_priv-regfile.saveDSPASIZE);
- I915_WRITE(_DSPAPOS, dev_priv-regfile.saveDSPAPOS);
I915_WRITE(_PIPEASRC, dev_priv-regfile.savePIPEASRC);
I915_WRITE(_DSPAADDR, dev_priv-regfile.saveDSPAADDR);
I915_WRITE(_DSPASTRIDE, dev_priv-regfile.saveDSPASTRIDE);
@@ -459,7 +456,6 @@ void i915_restore_display_reg(struct drm_device *dev)
/* Restore plane info */
I915_WRITE(_DSPBSIZE, dev_priv-regfile.saveDSPBSIZE);
-
[Intel-gfx] [PATCH 09/15] drm/i915: there's no PIPESTAT on Gen5+
From: Paulo Zanoni paulo.r.zan...@intel.com
So don't read it when capturing the error state. This solves
unclaimed register messages on Haswell when we have a GPU hang.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2139714..29b1bb1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1366,8 +1366,9 @@ static void i915_capture_error_state(struct drm_device
*dev)
else if (INTEL_INFO(dev)-gen == 6)
error-forcewake = I915_READ(FORCEWAKE);
- for_each_pipe(pipe)
- error-pipestat[pipe] = I915_READ(PIPESTAT(pipe));
+ if (INTEL_INFO(dev)-gen = 4)
+ for_each_pipe(pipe)
+ error-pipestat[pipe] = I915_READ(PIPESTAT(pipe));
if (INTEL_INFO(dev)-gen = 6) {
error-error = I915_READ(ERROR_GEN6);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] drm/i915: add HAS_POWER_WELL
From: Paulo Zanoni paulo.r.zan...@intel.com
We're starting to add many IS_HASWELL checks for the power well code,
so add a HAS_POWER_WELL macro to properly document that we're checking
for hardware that has the power down well.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c |4 ++--
drivers/gpu/drm/i915/intel_pm.c |6 +++---
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9bf15e5..60e24d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1337,6 +1337,7 @@ struct drm_i915_file_private {
#define HAS_PIPE_CONTROL(dev) (INTEL_INFO(dev)-gen = 5)
#define HAS_DDI(dev) (IS_HASWELL(dev))
+#define HAS_POWER_WELL(dev)(IS_HASWELL(dev))
#define INTEL_PCH_DEVICE_ID_MASK 0xff00
#define INTEL_PCH_IBX_DEVICE_ID_TYPE 0x3b00
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 835bec2..39f5f72 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9338,7 +9338,7 @@ intel_display_capture_error_state(struct drm_device *dev)
power_well_is_down = intel_power_well_is_down(dev);
- if (IS_HASWELL(dev))
+ if (HAS_POWER_WELL(dev))
error-power_well_driver = I915_READ(HSW_PWR_WELL_DRIVER);
for_each_pipe(i) {
@@ -9394,7 +9394,7 @@ intel_display_print_error_state(struct seq_file *m,
int i;
seq_printf(m, Num Pipes: %d\n, dev_priv-num_pipe);
- if (IS_HASWELL(dev))
+ if (HAS_POWER_WELL(dev))
seq_printf(m, PWR_WELL_CTL2: %08x\n,
error-power_well_driver);
for_each_pipe(i) {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 90562bc..9e22ad3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4080,7 +4080,7 @@ bool intel_power_well_is_down(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (IS_HASWELL(dev))
+ if (HAS_POWER_WELL(dev))
return !(I915_READ(HSW_PWR_WELL_DRIVER) HSW_PWR_WELL_ENABLE);
else
return false;
@@ -4092,7 +4092,7 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!IS_HASWELL(dev))
+ if (!HAS_POWER_WELL(dev))
return;
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
@@ -4127,7 +4127,7 @@ void intel_init_power_well(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (!IS_HASWELL(dev))
+ if (!HAS_POWER_WELL(dev))
return;
/* For now, we need the power well to be always enabled. */
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/i915: reorganize intel_lvds_supported
From: Paulo Zanoni paulo.r.zan...@intel.com
Now it returns false for all platforms unless they're explicitly
listed on the function. There should be no real difference, except for
the fact that it now returns false on Haswell.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_lvds.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 6b24fc5..53bd5fd 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -1020,15 +1020,15 @@ static bool intel_lvds_supported(struct drm_device *dev)
{
/* With the introduction of the PCH we gained a dedicated
* LVDS presence pin, use it. */
- if (HAS_PCH_SPLIT(dev))
+ if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
return true;
- if (IS_VALLEYVIEW(dev))
- return false;
-
/* Otherwise LVDS was only attached to mobile products,
* except for the inglorious 830gm */
- return IS_MOBILE(dev) !IS_I830(dev);
+ if (INTEL_INFO(dev)-gen = 4 IS_MOBILE(dev) !IS_I830(dev))
+ return true;
+
+ return false;
}
/**
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] drm/i915: don't save/restore PCH_LVDS on LPT
From: Paulo Zanoni paulo.r.zan...@intel.com
Because the register does not exist on LPT. The interesting fact is
that reading/writing PCH_LVDS on LPT does *not* give us unclaimed
register messages, but the register value is always 0.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index c1e02b0..41f0fde 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -209,7 +209,8 @@ static void i915_save_display(struct drm_device *dev)
dev_priv-regfile.saveBLC_PWM_CTL2 =
I915_READ(BLC_PWM_PCH_CTL2);
dev_priv-regfile.saveBLC_CPU_PWM_CTL =
I915_READ(BLC_PWM_CPU_CTL);
dev_priv-regfile.saveBLC_CPU_PWM_CTL2 =
I915_READ(BLC_PWM_CPU_CTL2);
- dev_priv-regfile.saveLVDS = I915_READ(PCH_LVDS);
+ if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
+ dev_priv-regfile.saveLVDS = I915_READ(PCH_LVDS);
} else {
dev_priv-regfile.savePP_CONTROL = I915_READ(PP_CONTROL);
dev_priv-regfile.savePFIT_PGM_RATIOS =
I915_READ(PFIT_PGM_RATIOS);
@@ -271,9 +272,9 @@ static void i915_restore_display(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_MODESET))
mask = ~LVDS_PORT_EN;
- if (HAS_PCH_SPLIT(dev)) {
+ if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
I915_WRITE(PCH_LVDS, dev_priv-regfile.saveLVDS mask);
- } else if (IS_MOBILE(dev) !IS_I830(dev))
+ else if (INTEL_INFO(dev)-gen = 4 IS_MOBILE(dev) !IS_I830(dev))
I915_WRITE(LVDS, dev_priv-regfile.saveLVDS mask);
if (!IS_I830(dev) !IS_845G(dev) !HAS_PCH_SPLIT(dev))
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/15] drm/i915: check the power well on i915_pipe_enabled
From: Paulo Zanoni paulo.r.zan...@intel.com This fixes unclaimed register messages when the power well is disabled and there's a GPU hang. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_irq.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 29b1bb1..aefc674 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -129,6 +129,9 @@ i915_pipe_enabled(struct drm_device *dev, int pipe) enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe); + if (intel_power_well_is_down(dev) cpu_transcoder != TRANSCODER_EDP) + return false; + return I915_READ(PIPECONF(cpu_transcoder)) PIPECONF_ENABLE; } -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] drm/i915: add missing space in error message
From: Paulo Zanoni paulo.r.zan...@intel.com To avoid this: [ 256.798060] [drm] capturing error event; look for more information in/sys/kernel/debug/dri/0/i915_error_state Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_irq.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index aefc674..0abd8ec 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1340,7 +1340,7 @@ static void i915_capture_error_state(struct drm_device *dev) return; } - DRM_INFO(capturing error event; look for more information in + DRM_INFO(capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n, dev-primary-index); -- 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 09/15] drm/i915: there's no PIPESTAT on Gen5+
On Wed, Mar 06, 2013 at 08:03:16PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
So don't read it when capturing the error state. This solves
unclaimed register messages on Haswell when we have a GPU hang.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Iirc pipestat exists on vlv, so I think this needs a !HAS_PCH_SPLIT test.
Ville should know for sure.
-Daniel
---
drivers/gpu/drm/i915/i915_irq.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2139714..29b1bb1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1366,8 +1366,9 @@ static void i915_capture_error_state(struct drm_device
*dev)
else if (INTEL_INFO(dev)-gen == 6)
error-forcewake = I915_READ(FORCEWAKE);
- for_each_pipe(pipe)
- error-pipestat[pipe] = I915_READ(PIPESTAT(pipe));
+ if (INTEL_INFO(dev)-gen = 4)
+ for_each_pipe(pipe)
+ error-pipestat[pipe] = I915_READ(PIPESTAT(pipe));
if (INTEL_INFO(dev)-gen = 6) {
error-error = I915_READ(ERROR_GEN6);
--
1.7.10.4
___
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 03/15] drm/i915: add intel_power_well_is_down
On Wed, Mar 06, 2013 at 08:03:10PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
It returns true if we're not supposed to touch the registers on the
power down well.
For now there's just one caller, but I'm going to add more.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 16
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 502cb28..bd27336 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1227,8 +1227,8 @@ void assert_pipe(struct drm_i915_private *dev_priv,
if (pipe == PIPE_A dev_priv-quirks QUIRK_PIPEA_FORCE)
state = true;
- if (IS_HASWELL(dev_priv-dev) cpu_transcoder != TRANSCODER_EDP
- !(I915_READ(HSW_PWR_WELL_DRIVER) HSW_PWR_WELL_ENABLE)) {
+ if (intel_power_well_is_down(dev_priv-dev)
The name here feels a bit too generic given that we already have on hsw
different display c states with different requirements and different
pieces of hw not working.
Can't thinkg of anything better than intel_display_power_well_is_down
though ...
-Daniel
+ cpu_transcoder != TRANSCODER_EDP) {
cur_state = false;
} else {
reg = PIPECONF(cpu_transcoder);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 010e998..28c4789 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -671,6 +671,7 @@ extern void intel_update_fbc(struct drm_device *dev);
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
extern void intel_gpu_ips_teardown(void);
+extern bool intel_power_well_is_down(struct drm_device *dev);
extern void intel_init_power_well(struct drm_device *dev);
extern void intel_set_power_well(struct drm_device *dev, bool enable);
extern void intel_enable_gt_powersave(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5479363..90562bc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4070,6 +4070,22 @@ void intel_init_clock_gating(struct drm_device *dev)
dev_priv-display.init_clock_gating(dev);
}
+/**
+ * Returns true if we're not supposed to touch the registers on the power
down
+ * well. Notice that we don't check whether the power well is actually off,
we
+ * just check if our driver told the hardware that it doesn't need the power
+ * well enabled.
+ */
+bool intel_power_well_is_down(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (IS_HASWELL(dev))
+ return !(I915_READ(HSW_PWR_WELL_DRIVER) HSW_PWR_WELL_ENABLE);
+ else
+ return false;
+}
+
void intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.7.10.4
___
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 04/15] drm/i915: don't touch the PF regs if the power well is down
On Wed, Mar 06, 2013 at 08:03:11PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This solves some unclaimed register messages when booting the
machine with eDP attached.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bd27336..9a9f6d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3584,8 +3584,10 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);
/* Disable PF */
- I915_WRITE(PF_CTL(pipe), 0);
- I915_WRITE(PF_WIN_SZ(pipe), 0);
+ if (!intel_power_well_is_down(dev)) {
+ I915_WRITE(PF_CTL(pipe), 0);
+ I915_WRITE(PF_WIN_SZ(pipe), 0);
+ }
I'd vote for a /* XXX: Once we have proper pfit state tracking implemented
with hw state read/check support we should switch to only disable the pfit
when we know it's used */
The idea is that the power well code here irks me a bit, after all if
something is on and we want to disable it, it can't be also off due to the
power well being down ;-)
-Daniel
intel_ddi_disable_pipe_clock(intel_crtc);
--
1.7.10.4
___
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 03/15] drm/i915: add intel_power_well_is_down
On Thu, Mar 07, 2013 at 12:26:23AM +0100, Daniel Vetter wrote:
On Wed, Mar 06, 2013 at 08:03:10PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
It returns true if we're not supposed to touch the registers on the
power down well.
For now there's just one caller, but I'm going to add more.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 16
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 502cb28..bd27336 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1227,8 +1227,8 @@ void assert_pipe(struct drm_i915_private *dev_priv,
if (pipe == PIPE_A dev_priv-quirks QUIRK_PIPEA_FORCE)
state = true;
- if (IS_HASWELL(dev_priv-dev) cpu_transcoder != TRANSCODER_EDP
- !(I915_READ(HSW_PWR_WELL_DRIVER) HSW_PWR_WELL_ENABLE)) {
+ if (intel_power_well_is_down(dev_priv-dev)
The name here feels a bit too generic given that we already have on hsw
different display c states with different requirements and different
pieces of hw not working.
Can't thinkg of anything better than intel_display_power_well_is_down
though ...
Also maybe make the function assure that the power well is on i.e.
power_well_enabled to avoid double-negation logic in a bunch of places.
-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
