[Intel-gfx] [PATCH] drm/i915: Apply post-sync write for pipe control invalidates
When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.
Reported-by: yex.t...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 35 ++-
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 13318a0..7608bc2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -213,20 +213,27 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
* number of bits based on the write domains has little performance
* impact.
*/
- flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
- flags |= PIPE_CONTROL_TLB_INVALIDATE;
- flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
- flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
- /*
-* Ensure that any following seqno writes only happen when the render
-* cache is indeed flushed (but only if the caller actually wants that).
-*/
- if (flush_domains)
+ if (flush_domains) {
+ flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ /*
+* Ensure that any following seqno writes only happen
+* when the render cache is indeed flushed.
+*/
flags |= PIPE_CONTROL_CS_STALL;
+ }
+ if (invalidate_domains) {
+ flags |= PIPE_CONTROL_TLB_INVALIDATE;
+ flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
+ /*
+* TLB invalidate requires a post-sync write.
+*/
+ flags |= PIPE_CONTROL_QW_WRITE;
+ }
ret = intel_ring_begin(ring, 4);
if (ret)
@@ -234,7 +241,7 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(4));
intel_ring_emit(ring, flags);
- intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, (u32)ring->status_page.gfx_addr+2048);
intel_ring_emit(ring, 0);
intel_ring_advance(ring);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: ingore eDP bpc settings
This has originally been introduced to not oversubscribe the dp links
in
commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18
Author: Zhenyu Wang
Date: Tue Jan 12 05:38:31 2010 +0800
drm/i915: fix pixel color depth setting on eDP
Since then we've fixed up the dp link bandwidth calculation code for
code and should now automatically fall back to 6bpc dithering. So this
is unnecessary.
Furthermore it seems to break the new MacbookPro with retina display,
hence let's just rip this out.
Reported-by: Benoit Gschwind
Cc: Benoit Gschwind
Cc: Francois Rigaut
Cc: Greg KH
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
Testing feedback highgly welcome, and thanks for Benoit for finding
out that the bpc computations are busted.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bddb290..ddd4db3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3755,17 +3755,6 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
continue;
}
- if (intel_encoder->type == INTEL_OUTPUT_EDP) {
- /* Use VBT settings if we have an eDP panel */
- unsigned int edp_bpc = dev_priv->edp.bpp / 3;
-
- if (edp_bpc < display_bpc) {
- DRM_DEBUG_KMS("clamping display bpc (was %d) to
eDP (%d)\n", display_bpc, edp_bpc);
- display_bpc = edp_bpc;
- }
- continue;
- }
-
/* Not one of the known troublemakers, check the EDID */
list_for_each_entry(connector, &dev->mode_config.connector_list,
head) {
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Apply post-sync write for pipe control invalidates
When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.
Exposure to this hang on IVB seems to be a result of removing the extra
stalls required for SNB pipecontrol workarounds:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
Reported-by: yex.t...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 35 ++-
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 13318a0..7608bc2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -213,20 +213,27 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
* number of bits based on the write domains has little performance
* impact.
*/
- flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
- flags |= PIPE_CONTROL_TLB_INVALIDATE;
- flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
- flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
- flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
- /*
-* Ensure that any following seqno writes only happen when the render
-* cache is indeed flushed (but only if the caller actually wants that).
-*/
- if (flush_domains)
+ if (flush_domains) {
+ flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ /*
+* Ensure that any following seqno writes only happen
+* when the render cache is indeed flushed.
+*/
flags |= PIPE_CONTROL_CS_STALL;
+ }
+ if (invalidate_domains) {
+ flags |= PIPE_CONTROL_TLB_INVALIDATE;
+ flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
+ /*
+* TLB invalidate requires a post-sync write.
+*/
+ flags |= PIPE_CONTROL_QW_WRITE;
+ }
ret = intel_ring_begin(ring, 4);
if (ret)
@@ -234,7 +241,7 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(4));
intel_ring_emit(ring, flags);
- intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, (u32)ring->status_page.gfx_addr+2048);
intel_ring_emit(ring, 0);
intel_ring_advance(ring);
--
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] drm/i915: Lazily apply the SNB+ seqno w/a
On Thu, Aug 09, 2012 at 12:29:16PM +0200, Daniel Vetter wrote: > On Thu, Aug 09, 2012 at 10:58:30AM +0100, Chris Wilson wrote: > > Avoid the forcewake overhead when simply retiring requests, as often the > > last seen seqno is good enough to satisfy the retirment process and will > > be promptly re-run in any case. Only ensure that we force the coherent > > seqno read when we are explicitly waiting upon a completion event to be > > sure that none go missing, and also for when we are reporting seqno > > values in case of error or debugging. > > > > This greatly reduces the load for userspace using the busy-ioctl to > > track active buffers, for instance halving the CPU used by X in pushing > > the pixels from a software render (flash). The effect will be even more > > magnified with userptr and so providing a zero-copy upload path in that > > instance, or in similar instances where X is simply compositing DRI > > buffers. > > > > v2: Reverse the polarity of the tachyon stream. Daniel suggested that > > 'force' was too generic for the parameter name and that 'lazy_coherency' > > better encapsulated the semantics of it being an optimization and its > > purpose. Also notice that gen6_get_seqno() is only used by gen6/7 > > chipsets and so the test for IS_GEN6 || IS_GEN7 is redundant in that > > function. > > > > Signed-off-by: Chris Wilson > > Yeah, I like the new color. > > Reviewed-by: Daniel Vetter > > I'll muse over this some more before picking it up, just in case I'll > notice a place this could blow up ... Ok, slurped into dinq, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Apply post-sync write for pipe control invalidates
On Fri, 10 Aug 2012, Chris Wilson wrote:
> When invalidating the TLBs it is documentated as requiring a post-sync
> write. Failure to do so seems to result in a GPU hang.
>
> Exposure to this hang on IVB seems to be a result of removing the extra
> stalls required for SNB pipecontrol workarounds:
Hi Chris, AFAICT TLB invalidate requires PIPE_CONTROL_CS_STALL set per
the spec. I can't find a mention of the post-sync write, though. Could
you double check, please?
BR,
Jani.
>
> commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
> Author: Chris Wilson
> Date: Fri Jul 20 18:02:28 2012 +0100
>
> drm/i915: Only apply the SNB pipe control w/a to gen6
>
> Reported-by: yex.t...@intel.com
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 35
> ++-
> 1 file changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 13318a0..7608bc2 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -213,20 +213,27 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
>* number of bits based on the write domains has little performance
>* impact.
>*/
> - flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> - flags |= PIPE_CONTROL_TLB_INVALIDATE;
> - flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
> - flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
> - flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> - flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
> - flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
> - flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
> - /*
> - * Ensure that any following seqno writes only happen when the render
> - * cache is indeed flushed (but only if the caller actually wants that).
> - */
> - if (flush_domains)
> + if (flush_domains) {
> + flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + /*
> + * Ensure that any following seqno writes only happen
> + * when the render cache is indeed flushed.
> + */
> flags |= PIPE_CONTROL_CS_STALL;
> + }
> + if (invalidate_domains) {
> + flags |= PIPE_CONTROL_TLB_INVALIDATE;
> + flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
> + flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
> + flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
> + flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
> + flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
> + /*
> + * TLB invalidate requires a post-sync write.
> + */
> + flags |= PIPE_CONTROL_QW_WRITE;
> + }
>
> ret = intel_ring_begin(ring, 4);
> if (ret)
> @@ -234,7 +241,7 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
>
> intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(4));
> intel_ring_emit(ring, flags);
> - intel_ring_emit(ring, 0);
> + intel_ring_emit(ring, (u32)ring->status_page.gfx_addr+2048);
> intel_ring_emit(ring, 0);
> intel_ring_advance(ring);
>
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Apply post-sync write for pipe control invalidates
On Fri, 10 Aug 2012 12:57:59 +0300, Jani Nikula wrote: > On Fri, 10 Aug 2012, Chris Wilson wrote: > > When invalidating the TLBs it is documentated as requiring a post-sync > > write. Failure to do so seems to result in a GPU hang. > > > > Exposure to this hang on IVB seems to be a result of removing the extra > > stalls required for SNB pipecontrol workarounds: > > Hi Chris, AFAICT TLB invalidate requires PIPE_CONTROL_CS_STALL set per > the spec. I can't find a mention of the post-sync write, though. Could > you double check, please? Considering replacing it with a CS_STALL just hard hung my box, I remain unconvinced. :-p -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Apply post-sync write for pipe control invalidates
On Fri, 10 Aug 2012 11:07:47 +0100, Chris Wilson wrote: > On Fri, 10 Aug 2012 12:57:59 +0300, Jani Nikula > wrote: > > On Fri, 10 Aug 2012, Chris Wilson wrote: > > > When invalidating the TLBs it is documentated as requiring a post-sync > > > write. Failure to do so seems to result in a GPU hang. > > > > > > Exposure to this hang on IVB seems to be a result of removing the extra > > > stalls required for SNB pipecontrol workarounds: > > > > Hi Chris, AFAICT TLB invalidate requires PIPE_CONTROL_CS_STALL set per > > the spec. I can't find a mention of the post-sync write, though. Could > > you double check, please? To be clear, the w/a is mentioned for DevGT-A (but presumably still required): For all PIPE_CONTROLs that *only* have RO cache invalidation, software must set the post-sync operation field to something other than 0 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: ingore eDP bpc settings
Hello,
I confirm this patch work apply to kernel 3.6-rc1
Best regards
On 10/08/2012 11:10, Daniel Vetter wrote:
> This has originally been introduced to not oversubscribe the dp links
> in
>
> commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18
> Author: Zhenyu Wang
> Date: Tue Jan 12 05:38:31 2010 +0800
>
> drm/i915: fix pixel color depth setting on eDP
>
> Since then we've fixed up the dp link bandwidth calculation code for
> code and should now automatically fall back to 6bpc dithering. So this
> is unnecessary.
>
> Furthermore it seems to break the new MacbookPro with retina display,
> hence let's just rip this out.
>
> Reported-by: Benoit Gschwind
> Cc: Benoit Gschwind
> Cc: Francois Rigaut
> Cc: Greg KH
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter
>
> --
>
> Testing feedback highgly welcome, and thanks for Benoit for finding
> out that the bpc computations are busted.
> -Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bddb290..ddd4db3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3755,17 +3755,6 @@ static bool intel_choose_pipe_bpp_dither(struct
> drm_crtc *crtc,
> continue;
> }
>
> - if (intel_encoder->type == INTEL_OUTPUT_EDP) {
> - /* Use VBT settings if we have an eDP panel */
> - unsigned int edp_bpc = dev_priv->edp.bpp / 3;
> -
> - if (edp_bpc < display_bpc) {
> - DRM_DEBUG_KMS("clamping display bpc (was %d) to
> eDP (%d)\n", display_bpc, edp_bpc);
> - display_bpc = edp_bpc;
> - }
> - continue;
> - }
> -
> /* Not one of the known troublemakers, check the EDID */
> list_for_each_entry(connector, &dev->mode_config.connector_list,
> head) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] glamor 0.5.0
After three moths development, Im pleased to release glamor version 0.5.0. The major improvements are as below: 1. Support tiling large pixmap to multiple small textures. 2. Enable gradient shader. 3. Optimize glyphs rendering performance 4. Implement first shader to generate trapezoids. Cairo-demos spinner on a large picture(12000x12000) get about 10x improvement, and gradient also get about 2x improvement. Aa10text and rgb10text also get about 2x improvement. Thanks for Junyan and Michels contribution. Glamor has a restriction with latest xserver. The main issue is that glamor rely on the module loading sequence which is not guaranteed by current xserver. We will fix this issue in next version. If you want to try a full functional xserver with glamor, its recommended to use the following xserver version: commit a615b90cab7569fae9d123e4da1d3373c871d84b Author: Keith Packard Date: Wed Mar 14 11:32:36 2012 -0700 Bump version number to 1.12.99.0 Now that 1.12 has branched, reset the version on master to a development number. Signed-off-by: Keith Packard kei...@keithp.com We have the following work items for next release: 1. Fix the coexisting problem with glx for latest xserver. Dont rely on the module loading sequence. 2. Continue performance tuning: a) Implement delay flushing mechanism to avoid tiny drawing operation for each DrawElements/DrawArrays call. b) Implement atlas for small pixmap. c) Optimize trapezoid shader to reduce the overhead for those non-edge pixels. d) Optimize trapezoid/gradient shader to merge the mask/source creation and compositing into one shader. e) Optimize glamor itself overhead. 3. Xv support. The following changes since commit d5cdad0497ae5f6cd936a74f68169c0910ea1e68: Release 0.4. (2012-04-28 17:02:35 +0800) are available in the git repository at: git://anongit.freedesktop.org/xorg/driver/glamor tag v0.5 tar ball is at: http://cgit.freedesktop.org/xorg/driver/glamor/snapshot/glamor-0.5.tar.gz Please refer the following wiki page for how to try glamor with Intel driver. http://www.freedesktop.org/wiki/Software/Glamor for you to fetch changes up to 9b8a791290af0add84269efdb315f9f58798f6d2: Bump to version 0.5. (2012-08-10 13:46:42 +0800) Junyan He (14): Extract the gradient related code out. Fix a bugy macro definition. Fix the problem of set the same stop several times. Fix the problem of vertical and horizontal case error in linear gradient. Fix the problem of x_source and y_source causing radial error Add macro of vertex setting for triangle stripe Modilfy the composite logic to two phases Add the trapezoid direct render logic Use the direct render path for A1 Fix a bug for trapezoid clip Change the trapezoid render to use VBO. Just use the shader to generate trapezoid if PolyMode == Imprecise Fix the problem of VBO leak. Fallback to pixman when trapezoid mask is big. Michel Dänzer (4): Fix translation of clip region for composite fallback. Stream vertex data to VBOs. Print space between name of missing EGL extension and 'required'. Prefer KHR_surfaceless_context EGL extension over KHR_surfaceless_opengl/gles2. RobinHe (2): Create the file glamor_triangles.c Use shader to generate the temp trapezoid mask Zhigang Gong (43): We should not call gradient finalization code if we disable it. Added strict warning flags to CFLAGS. Remove the texture cache code. glamor_set_destination_pixmap_priv_nc: set drawable's width x height. glamor_largepixmap: first commit for large pixmap. largepixmap: Implement infrastructure for large pixmap. largepixmap: Enable glamor_composite. glamor_putimage: Correct the wrong stride value. glamor_getimage: should call miGetimage if failed to get sub-image. largepixmap: Add transform/repeat/reflect/pad support. largepixmap: Support self composite for large pixmap. largepixmap: Fix the selfcopy issue. Enable large pixmap by default. trapezoid: Fallback to sw-rasterize for largepixmap. copyarea: Cleanup the error handling logic. glamor_glyphs: Before get upload to cache flush is needed. glamor_emit_composite_vert: Optimize to don't do two times vert coping. gles2_largepixmap: force clip for a non-large pixmap. glamor_fbo: fix a memory leak for large pixmap. glamor_create_pixmap: Allocate glyphs pixmap in memory. glamor_render: Don't fallback when rendering glyphs with OpOver. glamor_glyphs: Detect fake or real glyphs overlap. glamor_composite_glyph: Optimize glyphs with non-s
Re: [Intel-gfx] [PATCH] drm/i915: Apply post-sync write for pipe control invalidates
On Fri, 10 Aug 2012, Chris Wilson wrote: > On Fri, 10 Aug 2012 12:57:59 +0300, Jani Nikula > wrote: >> On Fri, 10 Aug 2012, Chris Wilson wrote: >> > When invalidating the TLBs it is documentated as requiring a post-sync >> > write. Failure to do so seems to result in a GPU hang. >> > >> > Exposure to this hang on IVB seems to be a result of removing the extra >> > stalls required for SNB pipecontrol workarounds: >> >> Hi Chris, AFAICT TLB invalidate requires PIPE_CONTROL_CS_STALL set per >> the spec. I can't find a mention of the post-sync write, though. Could >> you double check, please? > > Considering replacing it with a CS_STALL just hard hung my box, I remain > unconvinced. :-p I meant you could check the spec, not actually try it! ;) But I accept that's a good reason not to use it. BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Find bugs in i915 driver
On Tue, Jul 31, 2012 at 07:23:18AM -0700, Greg KH wrote: > On Tue, Jul 31, 2012 at 09:17:15AM +, Xu, Anhua wrote: > > Thanks Chris. I add this in the the commit description. The updated patch > > is below: > > > > commit 71c3ff04834a01c81a5843996b87397273eb538d > > Author: Xu Anhua > > Date: Tue Jul 31 17:16:50 2012 +0800 > > > > i915: make the parameters passed-in coherent with functions' > > definition when calling hdmi/adpa/lvds_pipe_enabled() > > > > This bug is indroduced by commit > > 1519b9956eb4b4180fa3f47c73341463cdcfaa37 > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > No signed-off-by? No tag for inclusion in the stable tree? > > This patch isn't going very far :( Xu Anhua, can you please update your patch with signed-off-by and cc: stable? Also, your commit headline is a bit long, it should fit on one line of at most 70 chars (or thereabouts). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: try harder to find WR PLL clock settings
From: Paulo Zanoni
If we don't find the exact refresh rate, go with the next one. This
makes some modes work for me. They won't have the best settings, but
will at least have something. Just returning from this function when
we don't find the perfect settings does not help us at all.
Version 2:
- Remove duplicate lines on the clock table.
- Add back debug message with refresh, p, n2 and r2.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 39 +--
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ff03a3a..9584226 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -267,7 +267,8 @@ struct wrpll_tmds_clock {
u16 r2; /* Reference divider */
};
-/* Table of matching values for WRPLL clocks programming for each frequency */
+/* Table of matching values for WRPLL clocks programming for each frequency.
+ * The code assumes this table is sorted. */
static const struct wrpll_tmds_clock wrpll_tmds_clock_table[] = {
{19750, 38, 25, 18},
{2, 48, 32, 18},
@@ -277,7 +278,6 @@ static const struct wrpll_tmds_clock
wrpll_tmds_clock_table[] = {
{23000, 36, 23, 15},
{23500, 40, 40, 23},
{23750, 26, 16, 14},
- {23750, 26, 16, 14},
{24000, 36, 24, 15},
{25000, 36, 25, 15},
{25175, 26, 40, 33},
@@ -437,7 +437,6 @@ static const struct wrpll_tmds_clock
wrpll_tmds_clock_table[] = {
{108000,8, 24, 15},
{108108,8, 173,108},
{109000,6, 23, 19},
- {109000,6, 23, 19},
{11,6, 22, 18},
{110013,6, 22, 18},
{110250,8, 49, 30},
@@ -614,7 +613,6 @@ static const struct wrpll_tmds_clock
wrpll_tmds_clock_table[] = {
{218250,4, 42, 26},
{218750,4, 34, 21},
{219000,4, 47, 29},
- {219000,4, 47, 29},
{22,4, 44, 27},
{220640,4, 49, 30},
{220750,4, 36, 22},
@@ -658,7 +656,7 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
int port = intel_hdmi->ddi_port;
int pipe = intel_crtc->pipe;
- int p, n2, r2, valid=0;
+ int p, n2, r2;
u32 temp, i;
/* On Haswell, we need to enable the clocks and prepare DDI function to
@@ -666,26 +664,23 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
*/
DRM_DEBUG_KMS("Preparing HDMI DDI mode for Haswell on port %c, pipe
%c\n", port_name(port), pipe_name(pipe));
- for (i=0; i < ARRAY_SIZE(wrpll_tmds_clock_table); i++) {
- if (crtc->mode.clock == wrpll_tmds_clock_table[i].clock) {
- p = wrpll_tmds_clock_table[i].p;
- n2 = wrpll_tmds_clock_table[i].n2;
- r2 = wrpll_tmds_clock_table[i].r2;
+ for (i = 0; i < ARRAY_SIZE(wrpll_tmds_clock_table); i++)
+ if (crtc->mode.clock <= wrpll_tmds_clock_table[i].clock)
+ break;
- DRM_DEBUG_KMS("WR PLL clock: found settings for %dKHz
refresh rate: p=%d, n2=%d, r2=%d\n",
- crtc->mode.clock,
- p, n2, r2);
+ if (i == ARRAY_SIZE(wrpll_tmds_clock_table))
+ i--;
- valid = 1;
- break;
- }
- }
+ p = wrpll_tmds_clock_table[i].p;
+ n2 = wrpll_tmds_clock_table[i].n2;
+ r2 = wrpll_tmds_clock_table[i].r2;
- if (!valid) {
- DRM_ERROR("Unable to find WR PLL clock settings for %dKHz
refresh rate\n",
- crtc->mode.clock);
- return;
- }
+ if (wrpll_tmds_clock_table[i].clock != crtc->mode.clock)
+ DRM_INFO("WR PLL: using settings for %dKHz on %dKHz mode\n",
+wrpll_tmds_clock_table[i].clock, crtc->mode.clock);
+
+ DRM_DEBUG_KMS("WR PLL: %dKHz refresh rate with p=%d, n2=%d r2=%d\n",
+ crtc->mode.clock, p, n2, r2);
/* Enable LCPLL if disabled */
temp = I915_READ(LCPLL_CTL);
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: use the correct encoder type when comparing
From: Paulo Zanoni
- intel_encoder->type is INTEL_OUTPUT_SOMETHING
- drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING
Here we're using intel_encoder, so compare the oranges against
oranges. While at it, rename the variable to "intel_encoder" so we
keep our naming standards used everywhere.
Luckily this was not a bug because both DRM_MODE_ENCODER_DAC and
INTEL_OUTPUT_ANALOG are defined as 1. This is the only case where the
drm definition matches the intel definition.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
This was not tested, just compiled :)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2e1f28f..ea19a72 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2837,13 +2837,13 @@ static void intel_crtc_wait_for_pending_flips(struct
drm_crtc *crtc)
static bool intel_crtc_driving_pch(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
- struct intel_encoder *encoder;
+ struct intel_encoder *intel_encoder;
/*
* If there's a non-PCH eDP on this crtc, it must be DP_A, and that
* must be driven by its own crtc; no sharing is possible.
*/
- for_each_encoder_on_crtc(dev, crtc, encoder) {
+ for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
/* On Haswell, LPT PCH handles the VGA connection via FDI, and
Haswell
* CPU handles all others */
@@ -2851,19 +2851,19 @@ static bool intel_crtc_driving_pch(struct drm_crtc
*crtc)
/* It is still unclear how this will work on PPT, so
throw up a warning */
WARN_ON(!HAS_PCH_LPT(dev));
- if (encoder->type == DRM_MODE_ENCODER_DAC) {
+ if (intel_encoder->type == INTEL_OUTPUT_ANALOG) {
DRM_DEBUG_KMS("Haswell detected DAC encoder,
assuming is PCH\n");
return true;
} else {
DRM_DEBUG_KMS("Haswell detected encoder %d,
assuming is CPU\n",
- encoder->type);
+ intel_encoder->type);
return false;
}
}
- switch (encoder->type) {
+ switch (intel_encoder->type) {
case INTEL_OUTPUT_EDP:
- if (!intel_encoder_is_pch_edp(&encoder->base))
+ if (!intel_encoder_is_pch_edp(&intel_encoder->base))
return false;
continue;
}
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915: Haswell HDMI audio initialization
Hi,
couple of comments inlined:
On Thu, Aug 9, 2012 at 11:52 AM, Wang Xingchao wrote:
> Added new haswell_write_eld() to initialize Haswell HDMI audio registers
> to generate an unsolicited response to the audio controller driver to
> indicate that the controller sequence should start.
>
> Signed-off-by: Wang Xingchao
> ---
> drivers/gpu/drm/i915/i915_reg.h |1 +
> drivers/gpu/drm/i915/intel_display.c | 94
> +-
> 2 files changed, 94 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 55aa10e..08f8b65 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4294,6 +4294,7 @@
> #define AUD_DIG_CNVT(pipe) _PIPE(pipe, \
> HSW_AUD_DIG_CNVT_1, \
> HSW_AUD_DIG_CNVT_2)
> +#define DIP_PORT_SEL_MASK0x3
>
> #define HSW_AUD_EDID_DATA_A 0x65050
> #define HSW_AUD_EDID_DATA_B 0x65150
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 70d30fc..be0950d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5067,6 +5067,98 @@ static void g4x_write_eld(struct drm_connector
> *connector,
> I915_WRITE(G4X_AUD_CNTL_ST, i);
> }
>
> +static void haswell_write_eld(struct drm_connector *connector,
> +struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = connector->dev->dev_private;
> + uint8_t *eld = connector->eld;
> + uint32_t eldv;
> + uint32_t i;
> + int len;
> + int pipe = to_intel_crtc(crtc)->pipe;
> + int tmp;
> +
> + int hdmiw_hdmiedid = HSW_AUD_EDID_DATA(pipe);
> + int aud_cntl_st = HSW_AUD_DIP_ELD_CTRL(pipe);
> + int aud_config = HSW_AUD_CFG(pipe);
> + int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
> +
> +
> + DRM_DEBUG_DRIVER("HDMI: Haswell Audio initialize\n");
> +
> + /* Audio output enable */
> + DRM_DEBUG_DRIVER("HDMI audio: enable codec\n");
> + tmp = I915_READ(aud_cntrl_st2);
uint32_t for tmp would be better, in case you happen to right shift
tmp with bit31 set.
> + tmp |= (AUDIO_OUTPUT_ENABLE_A | AUDIO_OUTPUT_ENABLE_B |
> AUDIO_OUTPUT_ENABLE_C);
> + I915_WRITE(aud_cntrl_st2, tmp);
I don't know much about HDMI, but according to the spec you'd need to
wait for one vblank here. At least a comment why we don't do it would
be nice.
> +
> + /* Set ELD valid state */
> + tmp = I915_READ(aud_cntrl_st2);
> + DRM_DEBUG_DRIVER("HDMI audio: pin eld vld status=0x%8x\n", tmp);
> + tmp |= (AUDIO_ELD_VALID_A | AUDIO_ELD_VALID_B | AUDIO_ELD_VALID_C);
> + I915_WRITE(aud_cntrl_st2, tmp);
> + tmp = I915_READ(aud_cntrl_st2);
> + DRM_DEBUG_DRIVER("HDMI audio: eld vld status=0x%8x\n", tmp);
> +
> + /* Enable HDMI mode */
> + tmp = I915_READ(aud_config);
> + DRM_DEBUG_DRIVER("HDMI audio: audio conf: 0x%8x\n", tmp);
> + /* clear N_programing_enable and N_value_index */
> + tmp &= ~(AUD_CONFIG_N_VALUE_INDEX | AUD_CONFIG_N_PROG_ENABLE);
> + I915_WRITE(aud_config, tmp);
> +
> + DRM_DEBUG_DRIVER("ELD on pipe %c\n", pipe_name(pipe));
> +
> + i = I915_READ(aud_cntl_st);
> + i = (i >> 29) & DIP_PORT_SEL_MASK; /* DIP_Port_Select,
> 0x1 = PortB */
> + if (!i) {
> + DRM_DEBUG_DRIVER("Audio directed to unknown port\n");
> + /* operate blindly on all ports */
> + eldv = AUDIO_ELD_VALID_A;
> + eldv |= AUDIO_ELD_VALID_B;
> + eldv |= AUDIO_ELD_VALID_C;
> + } else {
> + DRM_DEBUG_DRIVER("ELD on port %c\n", 'A' + i);
> + eldv = AUDIO_ELD_VALID_A << ((i - 1) * 4);
This is confusing. Reading the spec I undersand i=1 means port B, but
in that case we'll set eldv to AUDIO_ELD_VALID_A. Is it intentional?
Other than the above, for the patchset:
Reviewed-by: imre.d...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: try harder to find WR PLL clock settings
On Fri, 10 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we don't find the exact refresh rate, go with the next one. This
> makes some modes work for me. They won't have the best settings, but
> will at least have something. Just returning from this function when
> we don't find the perfect settings does not help us at all.
>
> Version 2:
> - Remove duplicate lines on the clock table.
> - Add back debug message with refresh, p, n2 and r2.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 39 +--
> 1 file changed, 17 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ff03a3a..9584226 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -267,7 +267,8 @@ struct wrpll_tmds_clock {
> u16 r2; /* Reference divider */
> };
>
> -/* Table of matching values for WRPLL clocks programming for each frequency
> */
> +/* Table of matching values for WRPLL clocks programming for each frequency.
> + * The code assumes this table is sorted. */
> static const struct wrpll_tmds_clock wrpll_tmds_clock_table[] = {
> {19750, 38, 25, 18},
> {2, 48, 32, 18},
> @@ -277,7 +278,6 @@ static const struct wrpll_tmds_clock
> wrpll_tmds_clock_table[] = {
> {23000, 36, 23, 15},
> {23500, 40, 40, 23},
> {23750, 26, 16, 14},
> - {23750, 26, 16, 14},
> {24000, 36, 24, 15},
> {25000, 36, 25, 15},
> {25175, 26, 40, 33},
> @@ -437,7 +437,6 @@ static const struct wrpll_tmds_clock
> wrpll_tmds_clock_table[] = {
> {108000,8, 24, 15},
> {108108,8, 173,108},
> {109000,6, 23, 19},
> - {109000,6, 23, 19},
> {11,6, 22, 18},
> {110013,6, 22, 18},
> {110250,8, 49, 30},
> @@ -614,7 +613,6 @@ static const struct wrpll_tmds_clock
> wrpll_tmds_clock_table[] = {
> {218250,4, 42, 26},
> {218750,4, 34, 21},
> {219000,4, 47, 29},
> - {219000,4, 47, 29},
> {22,4, 44, 27},
> {220640,4, 49, 30},
> {220750,4, 36, 22},
> @@ -658,7 +656,7 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
> struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> int port = intel_hdmi->ddi_port;
> int pipe = intel_crtc->pipe;
> - int p, n2, r2, valid=0;
> + int p, n2, r2;
> u32 temp, i;
>
> /* On Haswell, we need to enable the clocks and prepare DDI function to
> @@ -666,26 +664,23 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
>*/
> DRM_DEBUG_KMS("Preparing HDMI DDI mode for Haswell on port %c, pipe
> %c\n", port_name(port), pipe_name(pipe));
>
> - for (i=0; i < ARRAY_SIZE(wrpll_tmds_clock_table); i++) {
> - if (crtc->mode.clock == wrpll_tmds_clock_table[i].clock) {
> - p = wrpll_tmds_clock_table[i].p;
> - n2 = wrpll_tmds_clock_table[i].n2;
> - r2 = wrpll_tmds_clock_table[i].r2;
> + for (i = 0; i < ARRAY_SIZE(wrpll_tmds_clock_table); i++)
> + if (crtc->mode.clock <= wrpll_tmds_clock_table[i].clock)
> + break;
>
> - DRM_DEBUG_KMS("WR PLL clock: found settings for %dKHz
> refresh rate: p=%d, n2=%d, r2=%d\n",
> - crtc->mode.clock,
> - p, n2, r2);
> + if (i == ARRAY_SIZE(wrpll_tmds_clock_table))
> + i--;
>
> - valid = 1;
> - break;
> - }
> - }
> + p = wrpll_tmds_clock_table[i].p;
> + n2 = wrpll_tmds_clock_table[i].n2;
> + r2 = wrpll_tmds_clock_table[i].r2;
>
> - if (!valid) {
> - DRM_ERROR("Unable to find WR PLL clock settings for %dKHz
> refresh rate\n",
> - crtc->mode.clock);
> - return;
> - }
> + if (wrpll_tmds_clock_table[i].clock != crtc->mode.clock)
> + DRM_INFO("WR PLL: using settings for %dKHz on %dKHz mode\n",
> + wrpll_tmds_clock_table[i].clock, crtc->mode.clock);
> +
> + DRM_DEBUG_KMS("WR PLL: %dKHz refresh rate with p=%d, n2=%d r2=%d\n",
> + crtc->mode.clock, p, n2, r2);
>
> /* Enable LCPLL if disabled */
> temp = I915_READ(LCPLL_CTL);
> --
> 1.7.11.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-
Re: [Intel-gfx] [PATCH] drm/i915: use the correct encoder type when comparing
On Fri, 10 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> - intel_encoder->type is INTEL_OUTPUT_SOMETHING
> - drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING
>
> Here we're using intel_encoder, so compare the oranges against
> oranges. While at it, rename the variable to "intel_encoder" so we
> keep our naming standards used everywhere.
intel_display.c still has plenty of 'struct intel_encoder *encoder'...
Reviewed-by: Jani Nikula
> Luckily this was not a bug because both DRM_MODE_ENCODER_DAC and
> INTEL_OUTPUT_ANALOG are defined as 1. This is the only case where the
> drm definition matches the intel definition.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> This was not tested, just compiled :)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2e1f28f..ea19a72 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2837,13 +2837,13 @@ static void intel_crtc_wait_for_pending_flips(struct
> drm_crtc *crtc)
> static bool intel_crtc_driving_pch(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> - struct intel_encoder *encoder;
> + struct intel_encoder *intel_encoder;
>
> /*
>* If there's a non-PCH eDP on this crtc, it must be DP_A, and that
>* must be driven by its own crtc; no sharing is possible.
>*/
> - for_each_encoder_on_crtc(dev, crtc, encoder) {
> + for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
>
> /* On Haswell, LPT PCH handles the VGA connection via FDI, and
> Haswell
>* CPU handles all others */
> @@ -2851,19 +2851,19 @@ static bool intel_crtc_driving_pch(struct drm_crtc
> *crtc)
> /* It is still unclear how this will work on PPT, so
> throw up a warning */
> WARN_ON(!HAS_PCH_LPT(dev));
>
> - if (encoder->type == DRM_MODE_ENCODER_DAC) {
> + if (intel_encoder->type == INTEL_OUTPUT_ANALOG) {
> DRM_DEBUG_KMS("Haswell detected DAC encoder,
> assuming is PCH\n");
> return true;
> } else {
> DRM_DEBUG_KMS("Haswell detected encoder %d,
> assuming is CPU\n",
> - encoder->type);
> + intel_encoder->type);
> return false;
> }
> }
>
> - switch (encoder->type) {
> + switch (intel_encoder->type) {
> case INTEL_OUTPUT_EDP:
> - if (!intel_encoder_is_pch_edp(&encoder->base))
> + if (!intel_encoder_is_pch_edp(&intel_encoder->base))
> return false;
> continue;
> }
> --
> 1.7.11.2
>
> ___
> 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
[Intel-gfx] Fan constantly running with Intel Graphics card
Hi, I am having an issue with a new Dell E5520 laptop (Intel(R) Core(TM) i5-2520 CPU @ 2.5GHz) running Linux Mint 13 (Kernel: Linux 3.2.0-23-generic (i686)). I am using the graphics driver that ships with the kernel: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) My problem is that the fan is constantly on even though I am not doing any intensive processing. The laptop runs very nicely (quietly) when I boot into Windows 7. There was a recent post which suggests running the following commands: $ cat /sys/kernel/debug/dri/0/i915_cur_delayinfo | grep Lowest then echo that value into the max freq file, e.g.: $ echo 400 > /sys/kernel/debug/dri/0/i915_max_freq I tried this (and restarted the machine) but still no joy, it seems that in my case GPU frequency is not to blame. Any advice would be greatly appreciated. Regards Patrick ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915: Haswell HDMI audio initialization
HI Deak,
> -Original Message-
> From: Imre Deak [mailto:imre.d...@gmail.com]
> Sent: Friday, August 10, 2012 9:15 PM
> To: Wang, Xingchao
> Cc: dan...@ffwll.ch; przan...@gmail.com; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 3/4] drm/i915: Haswell HDMI audio
> initialization
>
> Hi,
>
> couple of comments inlined:
>
> On Thu, Aug 9, 2012 at 11:52 AM, Wang Xingchao
> wrote:
> > Added new haswell_write_eld() to initialize Haswell HDMI audio
> > registers to generate an unsolicited response to the audio controller
> > driver to indicate that the controller sequence should start.
> >
> > Signed-off-by: Wang Xingchao
> > ---
> > drivers/gpu/drm/i915/i915_reg.h |1 +
> > drivers/gpu/drm/i915/intel_display.c | 94
> +-
> > 2 files changed, 94 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 55aa10e..08f8b65 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4294,6 +4294,7 @@
> > #define AUD_DIG_CNVT(pipe) _PIPE(pipe, \
> > HSW_AUD_DIG_CNVT_1, \
> > HSW_AUD_DIG_CNVT_2)
> > +#define DIP_PORT_SEL_MASK0x3
> >
> > #define HSW_AUD_EDID_DATA_A 0x65050
> > #define HSW_AUD_EDID_DATA_B 0x65150
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 70d30fc..be0950d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5067,6 +5067,98 @@ static void g4x_write_eld(struct drm_connector
> *connector,
> > I915_WRITE(G4X_AUD_CNTL_ST, i); }
> >
> > +static void haswell_write_eld(struct drm_connector *connector,
> > +struct drm_crtc *crtc) {
> > + struct drm_i915_private *dev_priv = connector->dev->dev_private;
> > + uint8_t *eld = connector->eld;
> > + uint32_t eldv;
> > + uint32_t i;
> > + int len;
> > + int pipe = to_intel_crtc(crtc)->pipe;
> > + int tmp;
> > +
> > + int hdmiw_hdmiedid = HSW_AUD_EDID_DATA(pipe);
> > + int aud_cntl_st = HSW_AUD_DIP_ELD_CTRL(pipe);
> > + int aud_config = HSW_AUD_CFG(pipe);
> > + int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
> > +
> > +
> > + DRM_DEBUG_DRIVER("HDMI: Haswell Audio initialize\n");
> > +
> > + /* Audio output enable */
> > + DRM_DEBUG_DRIVER("HDMI audio: enable codec\n");
> > + tmp = I915_READ(aud_cntrl_st2);
>
> uint32_t for tmp would be better, in case you happen to right shift tmp with
> bit31 set.
Agree, will change it to u32 type in next version.
>
> > + tmp |= (AUDIO_OUTPUT_ENABLE_A | AUDIO_OUTPUT_ENABLE_B
> | AUDIO_OUTPUT_ENABLE_C);
> > + I915_WRITE(aud_cntrl_st2, tmp);
>
> I don't know much about HDMI, but according to the spec you'd need to wait
> for one vblank here. At least a comment why we don't do it would be nice.
Yeah, according to audio programming sequence, wait 1 vertical blank here.
I left it empty here because I did not found the proper api and did not meet
issue during test.
Is intel_wait_for_vblank() the proper one I should call ?
>
> > +
> > + /* Set ELD valid state */
> > + tmp = I915_READ(aud_cntrl_st2);
> > + DRM_DEBUG_DRIVER("HDMI audio: pin eld vld status=0x%8x\n",
> tmp);
> > + tmp |= (AUDIO_ELD_VALID_A | AUDIO_ELD_VALID_B |
> AUDIO_ELD_VALID_C);
> > + I915_WRITE(aud_cntrl_st2, tmp);
> > + tmp = I915_READ(aud_cntrl_st2);
> > + DRM_DEBUG_DRIVER("HDMI audio: eld vld status=0x%8x\n",
> tmp);
> > +
> > + /* Enable HDMI mode */
> > + tmp = I915_READ(aud_config);
> > + DRM_DEBUG_DRIVER("HDMI audio: audio conf: 0x%8x\n", tmp);
> > + /* clear N_programing_enable and N_value_index */
> > + tmp &= ~(AUD_CONFIG_N_VALUE_INDEX |
> AUD_CONFIG_N_PROG_ENABLE);
> > + I915_WRITE(aud_config, tmp);
> > +
> > + DRM_DEBUG_DRIVER("ELD on pipe %c\n", pipe_name(pipe));
> > +
> > + i = I915_READ(aud_cntl_st);
> > + i = (i >> 29) & DIP_PORT_SEL_MASK; /*
> DIP_Port_Select, 0x1 = PortB */
> > + if (!i) {
> > + DRM_DEBUG_DRIVER("Audio directed to unknown
> port\n");
> > + /* operate blindly on all ports */
> > + eldv = AUDIO_ELD_VALID_A;
> > + eldv |= AUDIO_ELD_VALID_B;
> > + eldv |= AUDIO_ELD_VALID_C;
> > + } else {
> > + DRM_DEBUG_DRIVER("ELD on port %c\n", 'A' + i);
> > + eldv = AUDIO_ELD_VALID_A << ((i - 1) * 4);
>
> This is confusing. Reading the spec I undersand i=1 means port B, but in that
> case we'll set eldv to AUDIO_ELD_VALID_A. Is it intentional?
Bit 0 is for ELD Valid A in Project DevHSW and for ELD Valid B for HSW-X0, and
HSW-X0 is old one which
doesnot need to support
[Intel-gfx] v3.6 haswell regression from v3.5?
Hello, I've been attempting to get a Shark Bay / Haswell platform up & running, and have been having some difficulties that I'm hoping you all can possibly help with. I first tried the 3.5 kernel, and had some success after applying the following patch: https://patchwork.kernel.org/patch/1229541/ This seemed to be necessary to get the 0x0c26 PCI id to be loaded by i915, and use KMS. After doing this, I had some success, but things still would become unstable, and flash test patterns on the screen about every third boot. I figured that I would move on to the tip, and see if that fixed anything. However, at the tip, I cannot get i915 to display graphics at all - even with applying the patch above. I understand that this is still under development - but this seems like a regression from 3.5 Is there a codebase that I should be using for this testing? Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use the correct encoder type when comparing
On Fri, Aug 10, 2012 at 04:27:23PM +0300, Jani Nikula wrote: > On Fri, 10 Aug 2012, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > - intel_encoder->type is INTEL_OUTPUT_SOMETHING > > - drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING > > > > Here we're using intel_encoder, so compare the oranges against > > oranges. While at it, rename the variable to "intel_encoder" so we > > keep our naming standards used everywhere. > > intel_display.c still has plenty of 'struct intel_encoder *encoder'... > > Reviewed-by: Jani Nikula Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: try harder to find WR PLL clock settings
On Fri, Aug 10, 2012 at 04:18:45PM +0300, Jani Nikula wrote: > On Fri, 10 Aug 2012, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > If we don't find the exact refresh rate, go with the next one. This > > makes some modes work for me. They won't have the best settings, but > > will at least have something. Just returning from this function when > > we don't find the perfect settings does not help us at all. > > > > Version 2: > > - Remove duplicate lines on the clock table. > > - Add back debug message with refresh, p, n2 and r2. > > Reviewed-by: Jani Nikula Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fwd: Re: Macbook Pro Retina display problems
Hello Daniel and Francois,
apologies for posting 'out of thread'.
> Can you please re-grab the
> dumps?
http://luna.vmars.tuwien.ac.at/~froemel/ird_noi915.txt
http://luna.vmars.tuwien.ac.at/~froemel/ird_i915.txt
http://luna.vmars.tuwien.ac.at/~froemel/ird_i915_pC.txt (short freeze,
screen looks for a second scaled to 2/3 (black border), same
corruption and then looks just like before)
Also, have you seen this post by 'gschwind':
http://ubuntuforums.org/showpost.php?p=12160766&postcount=70 ?
For convenience reasons the patch that is attached to the forum post:
--- linux-3.5.1.orig/drivers/gpu/drm/i915/intel_display.c 2012-08-09
17:23:56.0 +0200
+++ linux-3.5.1/drivers/gpu/drm/i915/intel_display.c2012-08-09
21:13:43.146996673 +0200
@@ -3583,7 +3583,8 @@
if (intel_encoder->type == INTEL_OUTPUT_EDP) {
/* Use VBT settings if we have an eDP panel */
- unsigned int edp_bpc = dev_priv->edp.bpp / 3;
+ //unsigned int edp_bpc = dev_priv->edp.bpp / 3;
+ unsigned int edp_bpc = 8;
if (edp_bpc < display_bpc) {
DRM_DEBUG_KMS("clamping display bpc (was %d) to
eDP (%d)\n",
display_bpc, edp_bpc);
Cheers, Bernhard
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
specifically, I get the following in my serial console - it is a warning...but seems to coincide with when standard vesa modes are switching over to the higer res KMS modes: [ 15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake wait timed out [ 15.897707] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 15.905161] [drm] Driver supports precise vblank timestamp query. [ 15.912293] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 15.943700] [ cut here ] [ 15.949041] WARNING: at /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1118 assert_fdi_tx+0x87/0x90 [i915]() [ 15.963591] Hardware name: Shark Bay Client platform [ 15.969288] FDI TX state assertion failure (expected off, current on) [ 15.976678] Modules linked in: crc32c_intel ahci(+) libahci ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt video xhci_hcd [ 15.992621] Pid: 148, comm: modprobe Not tainted 3.6.0-orc #9 [ 15.993459] usb 1-5: new low-speed USB device number 2 using xhci_hcd [ 16.006609] Call Trace: [ 16.009462] [] warn_slowpath_common+0x7f/0xc0 [ 16.016356] [] warn_slowpath_fmt+0x46/0x50 [ 16.019911] usb 1-5: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 16.032989] [] assert_fdi_tx+0x87/0x90 [i915] [ 16.040070] [] ironlake_crtc_disable+0x185/0x820 [i915] [ 16.047923] [] ironlake_crtc_dpms+0x8e/0xa0 [i915] [ 16.055302] [] intel_crtc_dpms+0x48/0x140 [i915] [ 16.061100] usbcore: registered new interface driver usbhid [ 16.061101] usbhid: USB HID core driver [ 16.073325] [] intel_crtc_disable+0x35/0xb0 [i915] [ 16.080700] [] drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] [ 16.090943] [] intel_modeset_init+0x6b7/0xf10 [i915] [ 16.098525] [] i915_driver_load+0xa8a/0xb90 [i915] [ 16.105913] [] ? drm_get_minor+0x26b/0x310 [drm] [ 16.113082] [] drm_get_pci_dev+0x191/0x2b0 [drm] [ 16.120276] [] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 16.128061] [] i915_pci_probe+0x4f/0x57 [i915] [ 16.135039] [] pci_device_probe+0xb0/0x140 [ 16.141631] [] driver_probe_device+0x7b/0x240 [ 16.148525] [] __driver_attach+0xab/0xb0 [ 16.154927] [] ? driver_probe_device+0x240/0x240 [ 16.162106] [] bus_for_each_dev+0x56/0x90 [ 16.168607] [] driver_attach+0x1e/0x20 [ 16.174811] [] bus_add_driver+0x190/0x290 [ 16.181303] [] driver_register+0x7a/0x160 [ 16.187805] [] __pci_register_driver+0x55/0xd0 [ 16.193436] usb 1-6: new low-speed USB device number 3 using xhci_hcd [ 16.202180] [] ? notifier_call_chain+0x4d/0x70 [ 16.209173] [] drm_pci_init+0x11a/0x130 [drm] [ 16.216061] [] ? 0xa0124fff [ 16.221970] [] i915_init+0x66/0x68 [i915] [ 16.223558] usb 1-6: ep 0x81 - rounding interval to 128 microframes, ep desc says 192 microframes [ 16.238617] [] do_one_initcall+0x3f/0x170 [ 16.245104] [] sys_init_module+0x8f/0x200 [ 16.251599] [] system_call_fastpath+0x16/0x1b [ 16.258494] ---[ end trace 949ccd38b0452265 ]--- On Fri, Aug 10, 2012 at 12:25 PM, Ben Guthro wrote: > Hello, I've been attempting to get a Shark Bay / Haswell platform up & > running, and have been having some difficulties that I'm hoping you > all can possibly help with. > > I first tried the 3.5 kernel, and had some success after applying the > following patch: > https://patchwork.kernel.org/patch/1229541/ > > This seemed to be necessary to get the 0x0c26 PCI id to be loaded by > i915, and use KMS. > > After doing this, I had some success, but things still would become > unstable, and flash test patterns on the screen about every third > boot. > > > I figured that I would move on to the tip, and see if that fixed anything. > > However, at the tip, I cannot get i915 to display graphics at all - > even with applying the patch above. > > > I understand that this is still under development - but this seems > like a regression from 3.5 > Is there a codebase that I should be using for this testing? > > > Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
On Fri, Aug 10, 2012 at 12:51:42PM -0400, Ben Guthro wrote: > specifically, I get the following in my serial console - it is a > warning...but seems to coincide with when standard vesa modes are > switching over to the higer res KMS modes: Can you try to boot with i915.i915_enable_rc6=0 please? -Daniel > > [ 15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake > wait timed out > [ 15.897707] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [ 15.905161] [drm] Driver supports precise vblank timestamp query. > [ 15.912293] vgaarb: device changed decodes: > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > [ 15.943700] [ cut here ] > [ 15.949041] WARNING: at > /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1118 > assert_fdi_tx+0x87/0x90 [i915]() > [ 15.963591] Hardware name: Shark Bay Client platform > [ 15.969288] FDI TX state assertion failure (expected off, current on) > [ 15.976678] Modules linked in: crc32c_intel ahci(+) libahci > ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp > i2c_algo_bit intel_gtt video xhci_hcd > [ 15.992621] Pid: 148, comm: modprobe Not tainted 3.6.0-orc #9 > [ 15.993459] usb 1-5: new low-speed USB device number 2 using xhci_hcd > [ 16.006609] Call Trace: > [ 16.009462] [] warn_slowpath_common+0x7f/0xc0 > [ 16.016356] [] warn_slowpath_fmt+0x46/0x50 > [ 16.019911] usb 1-5: ep 0x81 - rounding interval to 64 microframes, > ep desc says 80 microframes > [ 16.032989] [] assert_fdi_tx+0x87/0x90 [i915] > [ 16.040070] [] ironlake_crtc_disable+0x185/0x820 [i915] > [ 16.047923] [] ironlake_crtc_dpms+0x8e/0xa0 [i915] > [ 16.055302] [] intel_crtc_dpms+0x48/0x140 [i915] > [ 16.061100] usbcore: registered new interface driver usbhid > [ 16.061101] usbhid: USB HID core driver > [ 16.073325] [] intel_crtc_disable+0x35/0xb0 [i915] > [ 16.080700] [] > drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] > [ 16.090943] [] intel_modeset_init+0x6b7/0xf10 [i915] > [ 16.098525] [] i915_driver_load+0xa8a/0xb90 [i915] > [ 16.105913] [] ? drm_get_minor+0x26b/0x310 [drm] > [ 16.113082] [] drm_get_pci_dev+0x191/0x2b0 [drm] > [ 16.120276] [] ? _raw_spin_unlock_irqrestore+0x1e/0x30 > [ 16.128061] [] i915_pci_probe+0x4f/0x57 [i915] > [ 16.135039] [] pci_device_probe+0xb0/0x140 > [ 16.141631] [] driver_probe_device+0x7b/0x240 > [ 16.148525] [] __driver_attach+0xab/0xb0 > [ 16.154927] [] ? driver_probe_device+0x240/0x240 > [ 16.162106] [] bus_for_each_dev+0x56/0x90 > [ 16.168607] [] driver_attach+0x1e/0x20 > [ 16.174811] [] bus_add_driver+0x190/0x290 > [ 16.181303] [] driver_register+0x7a/0x160 > [ 16.187805] [] __pci_register_driver+0x55/0xd0 > [ 16.193436] usb 1-6: new low-speed USB device number 3 using xhci_hcd > [ 16.202180] [] ? notifier_call_chain+0x4d/0x70 > [ 16.209173] [] drm_pci_init+0x11a/0x130 [drm] > [ 16.216061] [] ? 0xa0124fff > [ 16.221970] [] i915_init+0x66/0x68 [i915] > [ 16.223558] usb 1-6: ep 0x81 - rounding interval to 128 > microframes, ep desc says 192 microframes > [ 16.238617] [] do_one_initcall+0x3f/0x170 > [ 16.245104] [] sys_init_module+0x8f/0x200 > [ 16.251599] [] system_call_fastpath+0x16/0x1b > [ 16.258494] ---[ end trace 949ccd38b0452265 ]--- > > > > > On Fri, Aug 10, 2012 at 12:25 PM, Ben Guthro wrote: > > Hello, I've been attempting to get a Shark Bay / Haswell platform up & > > running, and have been having some difficulties that I'm hoping you > > all can possibly help with. > > > > I first tried the 3.5 kernel, and had some success after applying the > > following patch: > > https://patchwork.kernel.org/patch/1229541/ > > > > This seemed to be necessary to get the 0x0c26 PCI id to be loaded by > > i915, and use KMS. > > > > After doing this, I had some success, but things still would become > > unstable, and flash test patterns on the screen about every third > > boot. > > > > > > I figured that I would move on to the tip, and see if that fixed anything. > > > > However, at the tip, I cannot get i915 to display graphics at all - > > even with applying the patch above. > > > > > > I understand that this is still under development - but this seems > > like a regression from 3.5 > > Is there a codebase that I should be using for this testing? > > > > > > Ben > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fwd: Re: Macbook Pro Retina display problems
On Fri, Aug 10, 2012 at 06:49:03PM +0200, Bernhard Froemel wrote:
> Hello Daniel and Francois,
>
> apologies for posting 'out of thread'.
>
> > Can you please re-grab the
> > dumps?
> http://luna.vmars.tuwien.ac.at/~froemel/ird_noi915.txt
> http://luna.vmars.tuwien.ac.at/~froemel/ird_i915.txt
> http://luna.vmars.tuwien.ac.at/~froemel/ird_i915_pC.txt (short freeze,
> screen looks for a second scaled to 2/3 (black border), same
> corruption and then looks just like before)
> Also, have you seen this post by 'gschwind':
> http://ubuntuforums.org/showpost.php?p=12160766&postcount=70 ?
Please test the patch at
http://www.gossamer-threads.com/lists/linux/kernel/1579401
and supply your tested-by if it works.
Thanks, Daniel
>
> For convenience reasons the patch that is attached to the forum post:
> --- linux-3.5.1.orig/drivers/gpu/drm/i915/intel_display.c 2012-08-09
> 17:23:56.0 +0200
> +++ linux-3.5.1/drivers/gpu/drm/i915/intel_display.c 2012-08-09
> 21:13:43.146996673 +0200
> @@ -3583,7 +3583,8 @@
>
> if (intel_encoder->type == INTEL_OUTPUT_EDP) {
> /* Use VBT settings if we have an eDP panel */
> - unsigned int edp_bpc = dev_priv->edp.bpp / 3;
> + //unsigned int edp_bpc = dev_priv->edp.bpp / 3;
> + unsigned int edp_bpc = 8;
>
> if (edp_bpc < display_bpc) {
> DRM_DEBUG_KMS("clamping display bpc (was %d) to
> eDP (%d)\n",
> display_bpc, edp_bpc);
>
> Cheers, Bernhard
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
well...it gave me a different stack...but still no graphics: This is with the drm-intel-fixes branch merged in - I thought that branch might help...but it didn't seem to. [ 16.615950] [ cut here ] [ 16.621229] WARNING: at /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1119 assert_fdi_tx+0x87/0x90 [i915]() [ 16.635796] Hardware name: Shark Bay Client platform [ 16.641472] FDI TX state assertion failure (expected off, current on) [ 16.648863] Modules linked in: crc32c_intel ahci(+) libahci ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt video xhci_hcd [ 16.664808] Pid: 141, comm: modprobe Not tainted 3.6.0-orc #11 [ 16.671503] Call Trace: [ 16.674364] [] warn_slowpath_common+0x7f/0xc0 [ 16.681250] [] warn_slowpath_fmt+0x46/0x50 [ 16.681305] usb 1-5: new low-speed USB device number 2 using xhci_hcd [ 16.695251] [] assert_fdi_tx+0x87/0x90 [i915] [ 16.702135] [] ironlake_crtc_disable+0x185/0x820 [i915] [ 16.710013] [] ironlake_crtc_dpms+0x8e/0xa0 [i915] [ 16.711864] usb 1-5: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 16.727384] [] intel_crtc_dpms+0x48/0x140 [i915] [ 16.734590] [] intel_crtc_disable+0x35/0xb0 [i915] [ 16.741932] [] drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] [ 16.751668] usbcore: registered new interface driver usbhid [ 16.751669] usbhid: USB HID core driver [ 16.763019] [] intel_modeset_init+0x6b7/0xf10 [i915] [ 16.770594] [] i915_driver_load+0xa8a/0xb90 [i915] [ 16.777977] [] ? drm_get_minor+0x26b/0x310 [drm] [ 16.785143] [] drm_get_pci_dev+0x191/0x2b0 [drm] [ 16.792337] [] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 16.800125] [] i915_pci_probe+0x4f/0x57 [i915] [ 16.807096] [] pci_device_probe+0xb0/0x140 [ 16.813689] [] driver_probe_device+0x7b/0x240 [ 16.820582] [] __driver_attach+0xab/0xb0 [ 16.826984] [] ? driver_probe_device+0x240/0x240 [ 16.834163] [] bus_for_each_dev+0x56/0x90 [ 16.840664] [] driver_attach+0x1e/0x20 [ 16.840694] usb 1-6: new low-speed USB device number 3 using xhci_hcd [ 16.854251] [] bus_add_driver+0x190/0x290 [ 16.860748] [] driver_register+0x7a/0x160 [ 16.867247] [] __pci_register_driver+0x55/0xd0 [ 16.868830] usb 1-6: ep 0x81 - rounding interval to 128 microframes, ep desc says 192 microframes [ 16.884396] [] ? notifier_call_chain+0x4d/0x70 [ 16.891397] [] drm_pci_init+0x11a/0x130 [drm] [ 16.898260] [] ? 0xa0124fff [ 16.904172] [] i915_init+0x66/0x68 [i915] [ 16.910666] [] do_one_initcall+0x3f/0x170 [ 16.917167] [] sys_init_module+0x8f/0x200 [ 16.923652] [] system_call_fastpath+0x16/0x1b [ 16.930548] ---[ end trace fa81da3bacf4c4b0 ]--- On Fri, Aug 10, 2012 at 1:16 PM, Daniel Vetter wrote: > On Fri, Aug 10, 2012 at 12:51:42PM -0400, Ben Guthro wrote: >> specifically, I get the following in my serial console - it is a >> warning...but seems to coincide with when standard vesa modes are >> switching over to the higer res KMS modes: > > Can you try to boot with i915.i915_enable_rc6=0 please? > -Daniel > >> >> [ 15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake >> wait timed out >> [ 15.897707] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). >> [ 15.905161] [drm] Driver supports precise vblank timestamp query. >> [ 15.912293] vgaarb: device changed decodes: >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem >> [ 15.943700] [ cut here ] >> [ 15.949041] WARNING: at >> /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1118 >> assert_fdi_tx+0x87/0x90 [i915]() >> [ 15.963591] Hardware name: Shark Bay Client platform >> [ 15.969288] FDI TX state assertion failure (expected off, current on) >> [ 15.976678] Modules linked in: crc32c_intel ahci(+) libahci >> ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp >> i2c_algo_bit intel_gtt video xhci_hcd >> [ 15.992621] Pid: 148, comm: modprobe Not tainted 3.6.0-orc #9 >> [ 15.993459] usb 1-5: new low-speed USB device number 2 using xhci_hcd >> [ 16.006609] Call Trace: >> [ 16.009462] [] warn_slowpath_common+0x7f/0xc0 >> [ 16.016356] [] warn_slowpath_fmt+0x46/0x50 >> [ 16.019911] usb 1-5: ep 0x81 - rounding interval to 64 microframes, >> ep desc says 80 microframes >> [ 16.032989] [] assert_fdi_tx+0x87/0x90 [i915] >> [ 16.040070] [] ironlake_crtc_disable+0x185/0x820 [i915] >> [ 16.047923] [] ironlake_crtc_dpms+0x8e/0xa0 [i915] >> [ 16.055302] [] intel_crtc_dpms+0x48/0x140 [i915] >> [ 16.061100] usbcore: registered new interface driver usbhid >> [ 16.061101] usbhid: USB HID core driver >> [ 16.073325] [] intel_crtc_disable+0x35/0xb0 [i915] >> [ 16.080700] [] >> drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] >> [ 16.090943] [] intel_modeset_init+0x6b7/0xf10 [i915] >> [ 16.098525] [] i915_
[Intel-gfx] [PATCH] drm/i915: ingore eDP bpc settings
Seems like I am a bit late for the party :) I can also confirm that [PATCH] drm/i915: Apply post-sync write for pipe control invalidates works. Tested-by: Bernhard Froemel Thanks Daniel! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: don't grab dev->struct_mutex for userspace forcewak
On Thu, 9 Aug 2012 22:33:58 +0200, Daniel Vetter wrote: > Since forcewake is now protected by a spinlock, we don't need to grab > dev->struct_mutex any more. This way we can also get rid of a stale > comment, noticed by Ben Widawsky while reviewing some locking changes. > > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson (Although I still wish it were not so) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
On 2012-08-10 09:25, Ben Guthro wrote: Hello, I've been attempting to get a Shark Bay / Haswell platform up & running, and have been having some difficulties that I'm hoping you all can possibly help with. I first tried the 3.5 kernel, and had some success after applying the following patch: https://patchwork.kernel.org/patch/1229541/ This seemed to be necessary to get the 0x0c26 PCI id to be loaded by i915, and use KMS. After doing this, I had some success, but things still would become unstable, and flash test patterns on the screen about every third boot. I figured that I would move on to the tip, and see if that fixed anything. However, at the tip, I cannot get i915 to display graphics at all - even with applying the patch above. I understand that this is still under development - but this seems like a regression from 3.5 Is there a codebase that I should be using for this testing? Yes it is the codebase you should use. It sounds like a regression, can you bisect it? Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
I'll try to do this early next week, and report back. On Fri, Aug 10, 2012 at 7:37 PM, Ben Widawsky wrote: > On 2012-08-10 09:25, Ben Guthro wrote: >> >> Hello, I've been attempting to get a Shark Bay / Haswell platform up & >> running, and have been having some difficulties that I'm hoping you >> all can possibly help with. >> >> I first tried the 3.5 kernel, and had some success after applying the >> following patch: >> https://patchwork.kernel.org/patch/1229541/ >> >> This seemed to be necessary to get the 0x0c26 PCI id to be loaded by >> i915, and use KMS. >> >> After doing this, I had some success, but things still would become >> unstable, and flash test patterns on the screen about every third >> boot. >> >> >> I figured that I would move on to the tip, and see if that fixed anything. >> >> However, at the tip, I cannot get i915 to display graphics at all - >> even with applying the patch above. >> >> >> I understand that this is still under development - but this seems >> like a regression from 3.5 >> Is there a codebase that I should be using for this testing? >> > > Yes it is the codebase you should use. It sounds like a regression, can you > bisect it? > > >> >> Ben >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > -- > Ben Widawsky, Intel Open Source Technology Center > > ___ > 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
