Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove duplicate cache workaround
On Wed, Oct 03, 2012 at 07:34:21PM -0700, Ben Widawsky wrote:
This is already achieved in init_clock gating, and is probably the
result of a bad merge from Daniel. I'm too tired to bet on him making a
mistake though.
CC: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Citing from the commit message that added this 2nd copy that you've just
removed:
This cannot be done in gen6_init_clock_gating with most of the other
workaround bits; the render ring needs to exist. Otherwise, the
register write gets dropped on the floor (one printk will show it
changed, but a second printk immediately following shows the value
reverts to the old one).
Congrats, you've removed the wrong copy ;-)
Now I suspect not all of the w/a patches currently floating have seen
level of testing, and I'd wager a few suffer from the same. So I think we
need checks in i-g-t. Eric has started this with the intel_reg_checker
tool, but we lack an aweful lot of recent workarounds. Also, we need to
integrate a call to this tool in the testsuite, once at least at the
beginning somewhere (to check boot-up state) but also in ZZ_hangman (in
case the reset botched things up). We really should add a suspend/resume
testcase in there, too ...
Cheers, Daniel
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 984a0c5..625a348 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -521,14 +521,6 @@ static int init_render_ring(struct intel_ring_buffer
*ring)
}
if (IS_GEN6(dev)) {
- /* From the Sandybridge PRM, volume 1 part 3, page 24:
- * If this bit is set, STCunit will have LRA as replacement
- * policy. [...] This bit must be reset. LRA replacement
- * policy is not supported.
- */
- I915_WRITE(CACHE_MODE_0,
-_MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
-
/* This is not explicitly set for GEN6, so read the register.
* see intel_ring_mi_set_context() for why we care.
* TODO: consider explicitly setting the bit for GEN5
--
1.7.12.2
--
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] [pull] drm-intel-fixes
Hi Dave, Bigger -fixes pile, mostly because I've included Ajax' DP dongle stuff, as discussed on irc. Otherwise just small things: - regression fix to finally make 6bpc auto-dither on dp work (Jani) - reinstate an snb ctx w/a that accidentally got lost in a rework (Chris) - fixup the DP train sequence, logic-goof-up uncovered by Coverty (Chris) - fix set_caching locking (Ben) - fix spurious segfault on con-current gtt mmap faulting (Dimitry and Mika) - some pageflip correctness fixes (still hunting down some issues, but these are the worst offenders of confused code that we've tracked down thus far) from Chris and me - fixup swizzling settings on vlv (Jesse) As usual, all reproducible issue have grown neat testcases in i-g-t (where feasible ofc). I've also had some w/a patches from Jesse in -fixes, but they've blown up on my snb. So I've dropped the entire pile as too risky. Cheers, Daniel The following changes since commit f531dcb23f9a5c6ad77e451459df965dc9a0c0c8: drm/i915: Wrap external callers to IPS state with appropriate locks (2012-09-26 09:24:54 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 95cb1b02b0f8e690cbcc479924573b4fb26c2e8f: drm/i915: don't frob the vblank ts in finish_page_flip (2012-10-04 10:33:43 +0200) Adam Jackson (6): drm: Export drm_probe_ddc() drm/dp: Update DPCD defines drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/i915/dp: Be smarter about connection sense for branch devices drm/dp: Document DP spec versions for various DPCD registers drm/dp: Make sink count DP 1.2 aware Ben Widawsky (1): drm/i915: Fix set_caching locking Chris Wilson (3): drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a drm/i915: Flush the pending flips on the CRTC before modification drm/i915: Try harder to complete DP training pattern 1 Daniel Vetter (2): drm/i915: call drm_handle_vblank before finish_page_flip drm/i915: don't frob the vblank ts in finish_page_flip Dmitry Rogozhkin (1): drm/i915: EBUSY status handling added to i915_gem_fault(). Jani Nikula (1): drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag Jesse Barnes (1): drm/i915: set swizzling to none on VLV Mika Kuoppala (1): drm/i915: print warning if vmi915_gem_fault error is not handled drivers/gpu/drm/drm_edid.c |3 +- drivers/gpu/drm/i915/i915_gem.c | 14 +++-- drivers/gpu/drm/i915/i915_gem_context.c |2 +- drivers/gpu/drm/i915/i915_gem_tiling.c |5 +- drivers/gpu/drm/i915/i915_irq.c | 16 ++--- drivers/gpu/drm/i915/intel_display.c| 52 drivers/gpu/drm/i915/intel_dp.c | 73 +- drivers/gpu/drm/i915/intel_drv.h|2 + include/drm/drm_crtc.h |1 + include/drm/drm_dp_helper.h | 101 +-- 10 files changed, 194 insertions(+), 75 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 4/4] drm/i915: Fix GT_MODE default value
On Wed, Oct 03, 2012 at 07:34:24PM -0700, Ben Widawsky wrote: I can't even find how I figured this might be needed anymore. But sure enough, the value I'm reading back on platforms doesn't match what the docs recommends. It seemed to fix Chris' GT1 in limited testing as well. Tested-by: Chris Wilson ch...@chris-wilson.co.uk Merged to -fixes, with the missing sob line forged. -Daniel --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_pm.c | 5 + 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 37e62e0..4c1f461 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -531,6 +531,9 @@ # define VS_TIMER_DISPATCH (1 6) # define MI_FLUSH_ENABLE (1 12) +#define GEN6_GT_MODE 0x20d0 +#define GEN6_GT_MODE_HI(1 9) + #define GFX_MODE 0x02520 #define GFX_MODE_GEN70x0229c #define RING_MODE_GEN7(ring) ((ring)-mmio_base+0x29c) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 8aafa45..e0574f9 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3446,6 +3446,11 @@ static void gen6_init_clock_gating(struct drm_device *dev) DISPPLANE_TRICKLE_FEED_DISABLE); intel_flush_display_plane(dev_priv, pipe); } + + /* The default value should be 0x200 according to docs, but the two + * platforms I checked have a 0 for this. (Maybe BIOS overrides?) */ + I915_WRITE(GEN6_GT_MODE, _MASKED_BIT_DISABLE(0x)); + I915_WRITE(GEN6_GT_MODE, _MASKED_BIT_ENABLE(GEN6_GT_MODE_HI)); } static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) -- 1.7.12.2 ___ 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/47] drm/i915: enable and disable PIPE_CLK_SEL at the right time
On Tue, Oct 2, 2012 at 9:51 PM, Paulo Zanoni przan...@gmail.com wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Previously we were enabling it at mode_set but never disabling. Let's follow the mode set sequence. Apart from the same patch reordering mentioned in patch 2: Reviewed-by: Damien Lespiau damien.lesp...@intel.com -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [pull] drm-intel-fixes
Hi Dave, One more, as discussed on irc. Bigger -fixes pile, mostly because I've included Ajax' DP dongle stuff, as discussed on irc. Otherwise just small things: - regression fix to finally make 6bpc auto-dither on dp work (Jani) - reinstate an snb ctx w/a that accidentally got lost in a rework (Chris) - fixup the DP train sequence, logic-goof-up uncovered by Coverty (Chris) - fix set_caching locking (Ben) - fix spurious segfault on con-current gtt mmap faulting (Dimitry and Mika) - some pageflip correctness fixes (still hunting down some issues, but these are the worst offenders of confused code that we've tracked down thus far) from Chris and me - fixup swizzling settings on vlv (Jesse) - gt_mode w/a from Ben added, fixes snb gt1 rc6+hw ctx hangs. Cheers, Daniel The following changes since commit f531dcb23f9a5c6ad77e451459df965dc9a0c0c8: drm/i915: Wrap external callers to IPS state with appropriate locks (2012-09-26 09:24:54 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to ff4978207836d342d0f95641c506dc08cc402317: drm/i915: Fix GT_MODE default value (2012-10-04 13:12:32 +0200) Adam Jackson (6): drm: Export drm_probe_ddc() drm/dp: Update DPCD defines drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/i915/dp: Be smarter about connection sense for branch devices drm/dp: Document DP spec versions for various DPCD registers drm/dp: Make sink count DP 1.2 aware Ben Widawsky (2): drm/i915: Fix set_caching locking drm/i915: Fix GT_MODE default value Chris Wilson (3): drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a drm/i915: Flush the pending flips on the CRTC before modification drm/i915: Try harder to complete DP training pattern 1 Daniel Vetter (2): drm/i915: call drm_handle_vblank before finish_page_flip drm/i915: don't frob the vblank ts in finish_page_flip Dmitry Rogozhkin (1): drm/i915: EBUSY status handling added to i915_gem_fault(). Jani Nikula (1): drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag Jesse Barnes (1): drm/i915: set swizzling to none on VLV Mika Kuoppala (1): drm/i915: print warning if vmi915_gem_fault error is not handled drivers/gpu/drm/drm_edid.c |3 +- drivers/gpu/drm/i915/i915_gem.c | 14 +++-- drivers/gpu/drm/i915/i915_gem_context.c |2 +- drivers/gpu/drm/i915/i915_gem_tiling.c |5 +- drivers/gpu/drm/i915/i915_irq.c | 16 ++--- drivers/gpu/drm/i915/i915_reg.h |3 + drivers/gpu/drm/i915/intel_display.c| 52 drivers/gpu/drm/i915/intel_dp.c | 73 +- drivers/gpu/drm/i915/intel_drv.h|2 + drivers/gpu/drm/i915/intel_pm.c |5 ++ include/drm/drm_crtc.h |1 + include/drm/drm_dp_helper.h | 101 +-- 12 files changed, 202 insertions(+), 75 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 1/3] drm: Add an expose 3d modes property
On Thu, Sep 27, 2012 at 07:41:06PM +0100, Damien Lespiau wrote:
From: Damien Lespiau damien.lesp...@intel.com
The expose 3D modes property can be attached to connectors to allow
user space to indicate it can deal with 3D modes and that the drm driver
should expose those 3D modes.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
I've thought a bit more about this and I don't like the connector prop so
much any more:
- connector properties stick around, so if you mix up your userspace
things could go wrong (e.g. i-g-t tests and ddx).
- connector properties are exposed to users by default.
- it makes little sense for userspace to not enable this on all
connectors.
So I think a per-file_priv option to not filter out 3d modes would be
better suited.
We don't yet have any driver-agnostic ioctl yet for such things, so would
require a bit more work ...
-Daniel
---
drivers/gpu/drm/drm_crtc.c | 35 ++-
include/drm/drm_crtc.h | 6 ++
include/drm/drm_mode.h | 4
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..10a289c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -841,6 +841,35 @@ int drm_mode_create_tv_properties(struct drm_device
*dev, int num_modes,
}
EXPORT_SYMBOL(drm_mode_create_tv_properties);
+static const struct drm_prop_enum_list expose_3d_modes_list[] =
+{
+ { DRM_MODE_EXPOSE_3D_MODES_OFF, Off },
+ { DRM_MODE_EXPOSE_3D_MODES_ON, On }
+};
+
+/**
+ * drm_mode_create_s3d_properties - create stereo 3D properties
+ * @dev: DRM device
+ *
+ * This functions create properties that are used by the stereo 3D code.
Those
+ * properties must be attached to the desired connectors afterwards.
+ */
+int drm_mode_create_s3d_properties(struct drm_device *dev)
+{
+ struct drm_property *prop;
+
+ if (dev-mode_config.s3d_expose_modes_property)
+ return 0;
+
+ prop = drm_property_create_enum(dev, 0, expose 3D modes,
+ expose_3d_modes_list,
+ ARRAY_SIZE(expose_3d_modes_list));
+ dev-mode_config.s3d_expose_modes_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_s3d_properties);
+
/**
* drm_mode_create_scaling_mode_property - create scaling mode property
* @dev: DRM device
@@ -3170,12 +3199,16 @@ static int drm_mode_connector_set_obj_prop(struct
drm_mode_object *obj,
{
int ret = -EINVAL;
struct drm_connector *connector = obj_to_connector(obj);
+ struct drm_device *dev = connector-dev;
/* Do DPMS ourselves */
- if (property == connector-dev-mode_config.dpms_property) {
+ if (property == dev-mode_config.dpms_property) {
if (connector-funcs-dpms)
(*connector-funcs-dpms)(connector, (int)value);
ret = 0;
+ } else if (property == dev-mode_config.s3d_expose_modes_property) {
+ connector-expose_3d_modes = value;
+ ret = 0;
} else if (connector-funcs-set_property)
ret = connector-funcs-set_property(connector, property,
value);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..34372cb 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -578,6 +578,8 @@ struct drm_connector {
/* requested DPMS state */
int dpms;
+ int expose_3d_modes;
+
void *helper_private;
/* forced on connector */
@@ -802,6 +804,9 @@ struct drm_mode_config {
struct drm_property *tv_saturation_property;
struct drm_property *tv_hue_property;
+ /* Stereo 3D properties */
+ struct drm_property *s3d_expose_modes_property;
+
/* Optional properties */
struct drm_property *scaling_mode_property;
struct drm_property *dithering_mode_property;
@@ -950,6 +955,7 @@ extern int drm_property_add_enum(struct drm_property
*property, int index,
extern int drm_mode_create_dvi_i_properties(struct drm_device *dev);
extern int drm_mode_create_tv_properties(struct drm_device *dev, int
num_formats,
char *formats[]);
+extern int drm_mode_create_s3d_properties(struct drm_device *dev);
extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
extern int drm_mode_create_dithering_property(struct drm_device *dev);
extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 3d6301b..45b19c6 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -83,6 +83,10 @@
#define DRM_MODE_DIRTY_ON 1
#define DRM_MODE_DIRTY_ANNOTATE 2
+/* Expose 3D modes */
+#define DRM_MODE_EXPOSE_3D_MODES_OFF 0
+#define DRM_MODE_EXPOSE_3D_MODES_ON 1
+
struct drm_mode_modeinfo {
__u32
Re: [Intel-gfx] [PATCH 1/3] drm: Add an expose 3d modes property
On Thu, 2012-10-04 at 15:35 +0200, Daniel Vetter wrote: On Thu, Sep 27, 2012 at 07:41:06PM +0100, Damien Lespiau wrote: From: Damien Lespiau damien.lesp...@intel.com The expose 3D modes property can be attached to connectors to allow user space to indicate it can deal with 3D modes and that the drm driver should expose those 3D modes. Signed-off-by: Damien Lespiau damien.lesp...@intel.com I've thought a bit more about this and I don't like the connector prop so much any more: - connector properties stick around, so if you mix up your userspace things could go wrong (e.g. i-g-t tests and ddx). - connector properties are exposed to users by default. - it makes little sense for userspace to not enable this on all connectors. So I think a per-file_priv option to not filter out 3d modes would be better suited. We don't yet have any driver-agnostic ioctl yet for such things, so would require a bit more work ... This would be useful for the monotonic time stamp support too. At the moment the client would have to set a flag whether it wants real or raw timestamp for each wait-for-vblank and page-flip ioctl, though what it really needs is a one time setting. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/47] drm/i915: pipe and planes should be disabled on haswell_crtc_mode_set
On Tue, Oct 2, 2012 at 9:51 PM, Paulo Zanoni przan...@gmail.com wrote: @@ -5356,8 +5361,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc, haswell_set_pipeconf(crtc, adjusted_mode, dither); - intel_wait_for_vblank(dev, pipe); - I guess this hunk could go into a separate commit. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/47] drm/i915: add haswell_crtc_mode_set
On Tue, Oct 2, 2012 at 9:51 PM, Paulo Zanoni przan...@gmail.com wrote:
+static int haswell_crtc_mode_set(struct drm_crtc *crtc,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode,
+int x, int y,
+struct drm_framebuffer *fb)
+{
..
+ if (IS_HASWELL(dev))
+ if (!intel_ddi_pll_mode_set(crtc, adjusted_mode-clock))
+ return -EINVAL;
I know the patch is going to be re-ordered, but IS_HASWELL() can be
dropped when adding intel_ddi_pll_mode_set() back.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: TLB invalidation with MI_FLUSH_SW requires a post-sync op
On Thu, 4 Oct 2012 10:32:13 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Oct 03, 2012 at 09:20:20AM +0200, Daniel Vetter wrote: On Tue, Oct 02, 2012 at 05:14:53PM -0700, Ben Widawsky wrote: s/MI_FLUSH_SW/MI_FLUSH_DW/ Applied, with spelling fixed. Thanks for patchreview. This hard-hangs my snb here when X starts (so probably on the very first batch). Impressive! I've dropped this one from -fixes. And since no one piped up that the other w/a patches fix anything, I've moved those two I've merged already to dinq. Yeah not -fixes material. But it fixes i-g-t on VLV and *should* fix issues we may not have seen yet on IVB, so we need to figure this one out. Totally unrelated, I think I'll instate harsher rules for w/a patches: 1. w/a patches only go in through -fixes if they indeed fix an issue we (or a bug reporter) can reproduce. Yeah, that's fine. 2. w/a patches need testcases, too. Either a register check added to i-g-t or if it's a runtime thing, a runtime assert at a nice place (where feasible, ofc). A register check isn't that useful imo. A real test case would be ideal, but given how hard some of these issues are to hit, it's unrealistic to spend weeks writing a test case for a workaround that's already been documented to fix a specific issue. 3. I'll randomly stall patches to bring 2. up to par for existing workarounds. Btw if you want to take this to its logical conclusion, we also shouldn't be fixing issues that are obvious from code review but people haven't hit in practice (this goes for a good chunk of the code churn in our driver involving cleanups and fixes for potential non-issues). And that's not even including test case development for any patch claiming it fixes anything. That said, I definitely agree we want to add more test cases. Just don't block applying known workaround fixes or other stuff on those test cases. Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: TLB invalidation with MI_FLUSH_SW requires a post-sync op
On Thu, Oct 4, 2012 at 4:39 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: 2. w/a patches need testcases, too. Either a register check added to i-g-t or if it's a runtime thing, a runtime assert at a nice place (where feasible, ofc). A register check isn't that useful imo. A real test case would be ideal, but given how hard some of these issues are to hit, it's unrealistic to spend weeks writing a test case for a workaround that's already been documented to fix a specific issue. That's pretty because of Ben's w/a patch to remove the w/a from the part of the init sequence where the write sticks, and keep it at the place where the write doesn't stick. Similarly, we've sometimes managed to apply w/a not correctly after gpu reset or resume. Exactly since for many of these we won't ever have a good test-case, we should at least make sure that we actually succeed in setting the right values everywhere. Shockingly, we've failed even at that :( 3. I'll randomly stall patches to bring 2. up to par for existing workarounds. Btw if you want to take this to its logical conclusion, we also shouldn't be fixing issues that are obvious from code review but people haven't hit in practice (this goes for a good chunk of the code churn in our driver involving cleanups and fixes for potential non-issues). And that's not even including test case development for any patch claiming it fixes anything. And most of those actually go through dinq, at least if the exact impact is unclear and there's no testcase or bug to demonstrate the issue. My gripes here are purely for pushing too much w/a patches to -fixes, since both your patches and Ben's had regressions that hang machines. Hence my grumpiness. That said, I definitely agree we want to add more test cases. Just don't block applying known workaround fixes or other stuff on those test cases. Sure, I'll usually try to come up with a random distribution not biased against stuff that fixes real bugs ;-) But even for bugfixes I want testcases first (as always, if feasible ofc), since ppl are so easily distracted (and writing testcase is a royal pain). 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 1/4] drm/i915: Remove duplicate cache workaround
On Thu, 4 Oct 2012 09:01:17 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Oct 03, 2012 at 07:34:21PM -0700, Ben Widawsky wrote:
This is already achieved in init_clock gating, and is probably the
result of a bad merge from Daniel. I'm too tired to bet on him making a
mistake though.
CC: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Citing from the commit message that added this 2nd copy that you've just
removed:
This cannot be done in gen6_init_clock_gating with most of the other
workaround bits; the render ring needs to exist. Otherwise, the
register write gets dropped on the floor (one printk will show it
changed, but a second printk immediately following shows the value
reverts to the old one).
Congrats, you've removed the wrong copy ;-)
Would you be willing to verify this again? There is some interesting
information in the bspec that leads me to believe you've jumped to the
wrong conclusion regarding whether or not the render ring needs to
exist (I think there are other preconditions that I can workaround a
bit better).
Now I suspect not all of the w/a patches currently floating have seen
level of testing, and I'd wager a few suffer from the same.
Just to clarify a bit here: I don't have an SNB here with me, so the
patches themselves were only booted with an IVB. I didn't test the ILK
patch at all because I don't have one to test with also. I did test
patch 2, and 4 on Jesse's machine (1 is obviously not testable without
the kernel actually running)
So I think we
need checks in i-g-t. Eric has started this with the intel_reg_checker
tool, but we lack an aweful lot of recent workarounds. Also, we need to
integrate a call to this tool in the testsuite, once at least at the
beginning somewhere (to check boot-up state) but also in ZZ_hangman (in
case the reset botched things up). We really should add a suspend/resume
testcase in there, too ...
I'll leave this discussion to the mail thread started on patch 10.
Cheers, Daniel
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 984a0c5..625a348 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -521,14 +521,6 @@ static int init_render_ring(struct intel_ring_buffer
*ring)
}
if (IS_GEN6(dev)) {
- /* From the Sandybridge PRM, volume 1 part 3, page 24:
-* If this bit is set, STCunit will have LRA as replacement
-* policy. [...] This bit must be reset. LRA replacement
-* policy is not supported.
-*/
- I915_WRITE(CACHE_MODE_0,
- _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
-
/* This is not explicitly set for GEN6, so read the register.
* see intel_ring_mi_set_context() for why we care.
* TODO: consider explicitly setting the bit for GEN5
--
1.7.12.2
--
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] [pull] drm-intel-fixes
On Thu, Oct 04, 2012 at 03:21:47PM +0200, Daniel Vetter wrote: Hi Dave, One more, as discussed on irc. Bigger -fixes pile, mostly because I've included Ajax' DP dongle stuff, as discussed on irc. Otherwise just small things: - regression fix to finally make 6bpc auto-dither on dp work (Jani) - reinstate an snb ctx w/a that accidentally got lost in a rework (Chris) - fixup the DP train sequence, logic-goof-up uncovered by Coverty (Chris) - fix set_caching locking (Ben) - fix spurious segfault on con-current gtt mmap faulting (Dimitry and Mika) - some pageflip correctness fixes (still hunting down some issues, but these are the worst offenders of confused code that we've tracked down thus far) from Chris and me - fixup swizzling settings on vlv (Jesse) - gt_mode w/a from Ben added, fixes snb gt1 rc6+hw ctx hangs. I've failed to add cc: stable to the snb gt1 fix. Pull updated: The following changes since commit f531dcb23f9a5c6ad77e451459df965dc9a0c0c8: drm/i915: Wrap external callers to IPS state with appropriate locks (2012-09-26 09:24:54 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to f8f2ac9a76b0f80a6763ca316116a7bab8486997: drm/i915: Fix GT_MODE default value (2012-10-04 18:44:13 +0200) Adam Jackson (6): drm: Export drm_probe_ddc() drm/dp: Update DPCD defines drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/i915/dp: Be smarter about connection sense for branch devices drm/dp: Document DP spec versions for various DPCD registers drm/dp: Make sink count DP 1.2 aware Ben Widawsky (2): drm/i915: Fix set_caching locking drm/i915: Fix GT_MODE default value Chris Wilson (3): drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a drm/i915: Flush the pending flips on the CRTC before modification drm/i915: Try harder to complete DP training pattern 1 Daniel Vetter (2): drm/i915: call drm_handle_vblank before finish_page_flip drm/i915: don't frob the vblank ts in finish_page_flip Dmitry Rogozhkin (1): drm/i915: EBUSY status handling added to i915_gem_fault(). Jani Nikula (1): drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag Jesse Barnes (1): drm/i915: set swizzling to none on VLV Mika Kuoppala (1): drm/i915: print warning if vmi915_gem_fault error is not handled drivers/gpu/drm/drm_edid.c |3 +- drivers/gpu/drm/i915/i915_gem.c | 14 +++-- drivers/gpu/drm/i915/i915_gem_context.c |2 +- drivers/gpu/drm/i915/i915_gem_tiling.c |5 +- drivers/gpu/drm/i915/i915_irq.c | 16 ++--- drivers/gpu/drm/i915/i915_reg.h |3 + drivers/gpu/drm/i915/intel_display.c| 52 drivers/gpu/drm/i915/intel_dp.c | 73 +- drivers/gpu/drm/i915/intel_drv.h|2 + drivers/gpu/drm/i915/intel_pm.c |5 ++ include/drm/drm_crtc.h |1 + include/drm/drm_dp_helper.h | 101 +-- 12 files changed, 202 insertions(+), 75 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] [RFC] [PATCH 00/14] HPD/connector-polling rework
On Thu, Oct 04, 2012 at 12:07:01PM -0400, Alex Deucher wrote: On Thu, May 24, 2012 at 3:26 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, I've got fed up with our sorry state of connector detection and rampant edid re and rere-reading. This patch series lays the groundwork in the drm helpers so that drivers can avoid all this madness (at least on working hw) and properly cache the edid. With the additional changes for drm/i915, the edid is now read _once_ per plug event (or at boot-up/resume time). A further step would be to integrate the hotplug handling into the driver itself and only call -detect on the connectors for which the irq handler received a hotplug event. By adding POLL_FORCE drivers can get back the old behaviour of calling -detect every time probe_single_connector is called from userspace. I've splattered that over all drivers where I've thought it might be required. Note though that setting this doesn't avoid all regressions - the regular output poll work will still ignore any connectors with POLL_HPD set. If a driver/hw with broken hpd got away due to this, this will break stuff. But that should be easy to fix by admitting the defeat and setting POLL_CONNECT|DISCONNECT directly. If other people want to convert over their drivers, the following steps are required: - Ensure that the connector status is unknown every time the driver could have missed a hpd event (e.g. after resume). drm_mode_config_reset will do that for you. - Drop the POLL_FORCE flag for connectors where hdp is fully reliable. - Implement edid caching - that's a nice way to figure out whether hpd is actually reliable, because if it isn't, this step will ensure that you get bug reports because the the edid won't ever get updated ;-) - Optionally teach the driver some smarts about which specific connectors actually got a hotplug event. Mostly useful on cheap hw (like intel's) that can't distinguish between hdmi and dp without trying some aux channel transfers. As you can guess from the patch series, I've discovered the hard way that i915 sdvo support is totally broken. Tested on most of the intel machines I have and also quickly on my radeon hd5000. Comments, flames, ideas and test reports highly welcome. This set looks good to me. Do you have plans to revive this? At least the common drm ones are much better than what we currently have. The issue I've meanwhile discovered with hpd handling is that we really need the smarts in the driver to only do probing on native hdmi/dp outputs if we have a hpd irq for that specific port: Since we have 2 encoders for the same port, if e.g. dp is enabled and we do edid probing on the hdmi encoder/connector the display might get unhappy, which can happen even with these patches applied e.g. when pluggin in a 2nd display. So the new plan (for 3.8 hopefully) is to revamp the i915-internal hpd handling and keep on using the crtc helper stuff. For connectors with reliable hpd we'd simply return the tracked stated in -detect without touching the hw at all. So I don't think we need any changes in the hotplug/polling helper code. And looking again at these patches, they're a rather decent kludge and it's probably better to do this all in the drivers. Since the helper code sets the force parameter to false for all the background polling, you can just return any driver-internal cached state. And when force=true you could invalidate that cached state or do some additional (more expensive) detection. In short: No plans to revive this, but certainly plans to improve the drm/i915 hpd handling. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: paper over a pipe-enable vs pageflip race
I've discovered this on my ivb machine while stress-testing the new flip_tests. Only harmful effect observed is that the timestamp is a bit bogus. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 67912fe..9cecfd7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3253,6 +3253,16 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc) if (HAS_PCH_CPT(dev)) intel_cpt_verify_modeset(dev, intel_crtc-pipe); + + /* +* There seems to be a race in PCH platform hw (at least on some +* outputs) where an enabled pipe still completes any pageflip right +* away (as if the pipe is off) instead of waiting for vblank. As soon +* as the first vblank happend, everything works as expected. Hence just +* wait for one vblank before returning to avoid strange things +* happening. +*/ + intel_wait_for_vblank(dev, intel_crtc-pipe); } static void ironlake_crtc_disable(struct drm_crtc *crtc) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Document that we are implementing WaDisableBackToBackFlipFix
From: Damien Lespiau damien.lesp...@intel.com For the next person that checks these kind of things, without having to dig up the register definition. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_pm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 62fe848..3d219ec 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3541,6 +3541,7 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); + /* WaDisableBackToBackFlipFix */ I915_WRITE(IVB_CHICKEN3, CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); @@ -3621,6 +3622,7 @@ static void valleyview_init_clock_gating(struct drm_device *dev) I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); + /* WaDisableBackToBackFlipFix */ I915_WRITE(IVB_CHICKEN3, CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); -- 1.7.7.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Remove the WaDisableBackToBackFlipFix w/a for Haswell
From: Damien Lespiau damien.lesp...@intel.com This workaround is only valid for IVB and VLV and the write triggers an error on HSW. Signed-off-by: Damien Lespiau damien.lesp...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_pm.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 3d219ec..d0403e8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3479,10 +3479,6 @@ static void haswell_init_clock_gating(struct drm_device *dev) I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); - I915_WRITE(IVB_CHICKEN3, - CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | - CHICKEN3_DGMG_DONE_FIX_DISABLE); - /* Apply the WaDisableRHWOOptimizationForRenderHang workaround. */ I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1, GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC); -- 1.7.7.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document that we are implementing WaDisableBackToBackFlipFix
2012/10/4 Damien Lespiau damien.lesp...@gmail.com: From: Damien Lespiau damien.lesp...@intel.com For the next person that checks these kind of things, without having to dig up the register definition. Signed-off-by: Damien Lespiau damien.lesp...@intel.com Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_pm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 62fe848..3d219ec 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3541,6 +3541,7 @@ static void ivybridge_init_clock_gating(struct drm_device *dev) I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); + /* WaDisableBackToBackFlipFix */ I915_WRITE(IVB_CHICKEN3, CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); @@ -3621,6 +3622,7 @@ static void valleyview_init_clock_gating(struct drm_device *dev) I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); + /* WaDisableBackToBackFlipFix */ I915_WRITE(IVB_CHICKEN3, CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | CHICKEN3_DGMG_DONE_FIX_DISABLE); -- 1.7.7.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove the WaDisableBackToBackFlipFix w/a for Haswell
2012/10/4 Damien Lespiau damien.lesp...@gmail.com: From: Damien Lespiau damien.lesp...@intel.com This workaround is only valid for IVB and VLV and the write triggers an error on HSW. In other words: the register does not exist anymore. It would be nice if we could volunteer someone to check the other workarounds on the same function. The registers may exist but the WAs may not be needed anymore. Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_pm.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 3d219ec..d0403e8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3479,10 +3479,6 @@ static void haswell_init_clock_gating(struct drm_device *dev) I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); - I915_WRITE(IVB_CHICKEN3, - CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE | - CHICKEN3_DGMG_DONE_FIX_DISABLE); - /* Apply the WaDisableRHWOOptimizationForRenderHang workaround. */ I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1, GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC); -- 1.7.7.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 problems with suspend to disk
On Thu, Oct 04, 2012 at 08:20:17PM +0100, Hugo Mills wrote: Hi, On 3.6, I've got a problem with my video driver after resuming from suspend-to-disk: the lower part of the display flickers, rapidly but irregularly (think of a neon sign in a bad film noir), flicking between the correct display and... something else, it's hard to see what. Shutting the lid of the machine (to trigger a suspend-to-ram) and waking it up again fixes the flicker. In syslogs, I have nothing obvious on suspend, and this warning on resume: Oct 4 19:53:04 ruth kernel: [ 2892.184086] [ cut here ] Oct 4 19:53:04 ruth kernel: [ 2892.184114] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() Oct 4 19:53:04 ruth kernel: [ 2892.184115] Hardware name: 0196CTO Oct 4 19:53:04 ruth kernel: [ 2892.184117] pipe B assertion failure (expected off, current on) Oct 4 19:53:04 ruth kernel: [ 2892.184188] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd fscache sunrpc ext4 jbd2 mbcache loop arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant coretemp i915 snd_hda_intel snd_hda_codec drm_kms_helper iwlwifi snd_hwdep snd_pcm snd_page_alloc joydev snd_seq snd_seq_device snd_timer kvm_intel drm i2c_algo_bit thinkpad_acpi acpi_cpufreq nvram btusb bluetooth kvm crc16 cfg80211 microcode psmouse evdev i2c_i801 video rfkill wmi mperf i2c_core snd battery ac processor soundcore button btrfs crc32c libcrc32c zlib_deflate sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif ums_realtek usb_storage uas thermal thermal_sys ahci libahci libata uhci_hcd scsi_mod ehci_hcd r8169 mii usbcore usb_common Oct 4 19:53:04 ruth kernel: [ 2892.184198] Pid: 4117, comm: kworker/u:3 Not tainted 3.6.0 #14 Oct 4 19:53:04 ruth kernel: [ 2892.184199] Call Trace: Oct 4 19:53:04 ruth kernel: [ 2892.184207] [8102bdc5] ? warn_slowpath_common+0x78/0x8c Oct 4 19:53:04 ruth kernel: [ 2892.184213] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184216] [8102be71] ? warn_slowpath_fmt+0x45/0x4a Oct 4 19:53:04 ruth kernel: [ 2892.184221] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184238] [a03fdae0] ? intel_crtc_disable+0x52/0x86 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184245] [a0273e47] ? drm_helper_disable_unused_functions+0xd0/0xfb [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184250] [a027461e] ? drm_helper_resume_force_mode+0xf1/0xff [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184254] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184264] [a03dc17f] ? i915_drm_thaw+0xd4/0x10b [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184274] [a03dc4fc] ? i915_resume+0x3b/0x50 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184279] [81193f21] ? pci_legacy_resume+0x39/0x39 Oct 4 19:53:04 ruth kernel: [ 2892.184284] [812196f7] ? dpm_run_callback.isra.5+0x26/0x54 Oct 4 19:53:04 ruth kernel: [ 2892.184289] [81219fe1] ? device_resume+0xd0/0x110 Oct 4 19:53:04 ruth kernel: [ 2892.184292] [8121a035] ? async_resume+0x14/0x38 Oct 4 19:53:04 ruth kernel: [ 2892.184296] [8104b070] ? async_run_entry_fn+0x9d/0x175 Oct 4 19:53:04 ruth kernel: [ 2892.184300] [81041a1a] ? process_one_work+0x184/0x2a3 Oct 4 19:53:04 ruth kernel: [ 2892.184304] [810426f1] ? worker_thread+0x1fe/0x29f Oct 4 19:53:04 ruth kernel: [ 2892.184307] [810424f3] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184310] [810424f3] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184315] [81045adf] ? kthread+0x67/0x6f Oct 4 19:53:04 ruth kernel: [ 2892.184319] [812fe774] ? kernel_thread_helper+0x4/0x10 Oct 4 19:53:04 ruth kernel: [ 2892.184324] [81045a78] ? kthread_freezable_should_stop+0x3c/0x3c Oct 4 19:53:04 ruth kernel: [ 2892.184327] [812fe770] ? gs_change+0xb/0xb Oct 4 19:53:04 ruth kernel: [ 2892.184328] ---[ end trace 4e63ed9ed8ebc493 ]--- Hardware is a Lenovo Thinkpad Edge13, lspci says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) aka 00:02.0 0300: 8086:2a42 (rev 07) Let me know if you need more information. I can probably manage a bisect if necessary -- it's easily repeatable as a bug. Before you do a bisect, can you try the drm-intel-fixes branch from http://cgit.freedesktop.org/~danvet/drm-intel or a bit more risky, latest upstream git? That contains a completely rewritten modeset code, which might fix this already. To fix the breakage on
Re: [Intel-gfx] [PATCH 02/47] drm/i915: enable and disable DDI_FUNC_CTL at the right time
2012/10/3 Lespiau, Damien damien.lesp...@intel.com:
On Tue, Oct 2, 2012 at 9:51 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And the right time is exactly after/before changing PIPE_CONF. See the
documentation about the mode set sequence.
This code is not inside any encoder-specific callback because
DDI_FUNC_CTL is part of the pipe, so it is used by all encoders.
Apart from the reordering of this patch with [PATCH 07/47] drm/i915:
add haswell_crtc_mode_set,
This patch has nothing to do with patch 07. This patch touches
ironlake_crtc_{enable,disable}, not ironlake_crtc_mode_set. We did not
fork ironlake_crtc_{enable,disable} since the haswell-specific changes
are too small.
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
Thanks for the review :)
--
Damien
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove duplicate cache workaround
On Thu, 4 Oct 2012 09:01:17 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Oct 03, 2012 at 07:34:21PM -0700, Ben Widawsky wrote:
This is already achieved in init_clock gating, and is probably the
result of a bad merge from Daniel. I'm too tired to bet on him making a
mistake though.
CC: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Citing from the commit message that added this 2nd copy that you've just
removed:
This cannot be done in gen6_init_clock_gating with most of the other
workaround bits; the render ring needs to exist. Otherwise, the
register write gets dropped on the floor (one printk will show it
changed, but a second printk immediately following shows the value
reverts to the old one).
Congrats, you've removed the wrong copy ;-)
On further thought, I think we need to investigate the original issue
here more anyway. I've been speaking with Ken, and neither of us really
understand why the later write is required (it seems he authored the
original patch). I think we all agree we'd like to jam these kind of
workarounds into the clock gating functions (even though that is now a
terrible name for it). Ken has tried this patch locally, and it works
fine.
It seems Matt Turner has the original machine, so it'd be great if he
can test this patch. Matt this is the t420s you got from Ken.
Now I suspect not all of the w/a patches currently floating have seen
level of testing, and I'd wager a few suffer from the same. So I think we
need checks in i-g-t. Eric has started this with the intel_reg_checker
tool, but we lack an aweful lot of recent workarounds. Also, we need to
integrate a call to this tool in the testsuite, once at least at the
beginning somewhere (to check boot-up state) but also in ZZ_hangman (in
case the reset botched things up). We really should add a suspend/resume
testcase in there, too ...
Cheers, Daniel
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 984a0c5..625a348 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -521,14 +521,6 @@ static int init_render_ring(struct intel_ring_buffer
*ring)
}
if (IS_GEN6(dev)) {
- /* From the Sandybridge PRM, volume 1 part 3, page 24:
-* If this bit is set, STCunit will have LRA as replacement
-* policy. [...] This bit must be reset. LRA replacement
-* policy is not supported.
-*/
- I915_WRITE(CACHE_MODE_0,
- _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
-
/* This is not explicitly set for GEN6, so read the register.
* see intel_ring_mi_set_context() for why we care.
* TODO: consider explicitly setting the bit for GEN5
--
1.7.12.2
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
