On Thu, Aug 08, 2013 at 02:44:23PM +0100, Chris Wilson wrote:
On Thu, Aug 08, 2013 at 03:12:06PM +0200, Daniel Vetter wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
If we get an error event really early in the driver setup sequence,
which gen3 is especially prone to with various
On Thu, Aug 08, 2013 at 10:28:52PM +0100, Damien Lespiau wrote:
Procrastinating... at least a small consolation prize:
5 files changed, 11 insertions(+), 104 deletions(-)
Queued for -next, thanks for the patches.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
On Thu, Aug 08, 2013 at 08:00:25PM +0100, Chris Wilson wrote:
A later patch adds yet another workaround for MI_SET_CONTEXT, at which
point we start to end up with more NOOPs than actual command dwords
along the non-workaround paths. It is time that we made the MI_SET_CONTEXT
a variable length
The '!' operation has higher precedence than the compare so probably
this test is never true.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a5a9959..0b9d9a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
There is an extra semi-colon here so we just leak and never unbind
anything.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 735f43f..a582540 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++
On Fri, Aug 09, 2013 at 12:43:02PM +0300, Dan Carpenter wrote:
The '!' operation has higher precedence than the compare so probably
this test is never true.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
On Fri, Aug 09, 2013 at 12:43:02PM +0300, Dan Carpenter wrote:
The '!' operation has higher precedence than the compare so probably
this test is never true.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
On Fri, Aug 09, 2013 at 11:41:26AM +0200, Daniel Vetter wrote:
On Thu, Aug 08, 2013 at 08:00:25PM +0100, Chris Wilson wrote:
A later patch adds yet another workaround for MI_SET_CONTEXT, at which
point we start to end up with more NOOPs than actual command dwords
along the non-workaround
On Fri, Aug 09, 2013 at 12:44:11PM +0300, Dan Carpenter wrote:
There is an extra semi-colon here so we just leak and never unbind
anything.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index
The '!' here was not intended. Since '!' has higher precedence than
compare, it means the check is never true.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
v2: My first patch was wrong.
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index
On Fri, Aug 09, 2013 at 01:07:31PM +0300, Dan Carpenter wrote:
The '!' here was not intended. Since '!' has higher precedence than
compare, it means the check is never true.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
The
The display engine has unique coherency rules such that it requires
special handling to ensure that all writes to cursors, scanouts and
sprites are clflushed. This patch introduces the infrastructure to
simply track when an object is being accessed by the display engine.
v2: Explain the
As mentioned in the previous commit, reads and writes from both the CPU
and GPU go through the LLC. This gives us coherency between the CPU and
GPU irrespective of the attribute settings either device sets. We can
use to avoid having to clflush even uncached memory.
Except for the scanout.
The
On Fri, Aug 09, 2013 at 12:25:09PM +0100, Chris Wilson wrote:
The display engine has unique coherency rules such that it requires
special handling to ensure that all writes to cursors, scanouts and
sprites are clflushed. This patch introduces the infrastructure to
simply track when an object
On Fri, Aug 09, 2013 at 12:26:45PM +0100, Chris Wilson wrote:
As mentioned in the previous commit, reads and writes from both the CPU
and GPU go through the LLC. This gives us coherency between the CPU and
GPU irrespective of the attribute settings either device sets. We can
use to avoid
On Wed, Aug 07, 2013 at 01:29:53PM -0700, Jesse Barnes wrote:
Chris's machine would be a good regression test for this. If it works
for him too, I think we should push it.
Well, the good news is that it adds another HDMI connection. The bad
news is that the hardware refuses to acknowledge my
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb-obj is in the display domain, which
incurs a cache flush to ensure no dirt is left on the scanout.
From: Ville Syrjälä ville.syrj...@linux.intel.com
Due to a misplaced memset(), we never actually enabled the FBC WM on HSW.
Move the memset() to happen a bit earlier, so that it won't clobber
results-enable_fbc_wm.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
On Fri, Aug 09, 2013 at 01:29:33PM +0300, Ville Syrjälä wrote:
On Fri, Aug 09, 2013 at 01:07:31PM +0300, Dan Carpenter wrote:
The '!' here was not intended. Since '!' has higher precedence than
compare, it means the check is never true.
Signed-off-by: Dan Carpenter
Ryan noticed that on his board, HDMI was wired up to port C but not
exposed by the kernel, which had only expected DP on that port. Fix
that up by enumerating both ports if possible.
Tested-by: Matsumura, Ryan ryan.matsum...@intel.com
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
On Fri, Aug 09, 2013 at 09:34:35AM -0700, Jesse Barnes wrote:
Ryan noticed that on his board, HDMI was wired up to port C but not
exposed by the kernel, which had only expected DP on that port. Fix
that up by enumerating both ports if possible.
Tested-by: Matsumura, Ryan
2013/8/9 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Due to a misplaced memset(), we never actually enabled the FBC WM on HSW.
Move the memset() to happen a bit earlier, so that it won't clobber
results-enable_fbc_wm.
Signed-off-by: Ville Syrjälä
Hi all,
New testing cycle, new features:
- Cleanup of the old crtc helper callbacks, all encoders are now converted
to the i915 modeset infrastructure.
- Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is
prep work to eventually get things going for nuclear pageflips
On Fri, Aug 09, 2013 at 03:13:22PM +0100, Chris Wilson wrote:
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb-obj is in the display domain,
From: Paulo Zanoni paulo.r.zan...@intel.com
On SNB/IVB/VLV we only call gen6_rps_irq_handler if one of the IIR
bits set is part of GEN6_PM_RPS_EVENTS, but at gen6_rps_irq_handler we
add all the enabled IIR bits to the work queue, not only the ones that
are part of GEN6_PM_RPS_EVENTS. But then
From: Paulo Zanoni paulo.r.zan...@intel.com
Because hsw_pm_irq_handler does exactly what gen6_rps_irq_handler does
and also processes the 2 additional VEBOX bits. So merge those
functions and wrap the VEBOX bits on an IS_HASWELL check. This HSW
check isn't really necessary since the bits are
From: Paulo Zanoni paulo.r.zan...@intel.com
It seems we've been doing this ever since we started processing the
RPS events on a work queue, on commit drm/i915: move gen6 rps
handling to workqueue, 4912d04193733a825216b926ffd290fada88ab07.
The problem is: when we add work to the queue, instead of
On Fri, Aug 09, 2013 at 09:17:11PM +0200, Daniel Vetter wrote:
On Fri, Aug 09, 2013 at 03:13:22PM +0100, Chris Wilson wrote:
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
From: Paulo Zanoni paulo.r.zan...@intel.com
This patch allows PC8+ states on Haswell. These states can only be
reached when all the display outputs are disabled, and they allow some
more power savings.
The fact that the graphics device is allowing PC8+ doesn't mean that
the machine will actually
Quick note...
On Fri, Aug 09, 2013 at 05:10:05PM -0300, Paulo Zanoni wrote:
+ WARN_ON(!mutex_is_locked(dev_priv-pc8.lock));
Preferred form is now lockdep_assert_held(dev_priv-pc8.lock);
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Aug 09, 2013 at 05:10:05PM -0300, Paulo Zanoni wrote:
+/* Disable interrupts so we can allow Package C8+. */
+void hsw_pc8_disable_interrupts(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long irqflags;
+
+
2013/8/9 Chris Wilson ch...@chris-wilson.co.uk:
On Fri, Aug 09, 2013 at 05:10:05PM -0300, Paulo Zanoni wrote:
+/* Disable interrupts so we can allow Package C8+. */
+void hsw_pc8_disable_interrupts(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
2013/8/9 Chris Wilson ch...@chris-wilson.co.uk:
Quick note...
On Fri, Aug 09, 2013 at 05:10:05PM -0300, Paulo Zanoni wrote:
+ WARN_ON(!mutex_is_locked(dev_priv-pc8.lock));
Preferred form is now lockdep_assert_held(dev_priv-pc8.lock);
Should I also convert all our other usages of
This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
(drm/i915: load boot context at driver init time)
This bit breaks hardware video decode for me after resume.
Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed,
On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
(drm/i915: load boot context at driver init time)
This bit breaks hardware video decode for me after resume.
Signed-off-by: Stéphane Marchesin
The conditional is usually a recoverable driver bug, and so WARNing, and
preventing the drm_mm code from doing potential damage (BUG) is
desirable.
This issue was hit and fixed twice while developing the i915 multiple
address space code. The first fix is the patch just before this, and is
hit on
In upcoming code, it will be possible for a vma to have been created,
but no space reserved for it in the address space. The drm_mm semantics
are such that trying to remove an unallocated node is not allowed.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 3
Cleanup the map and fenceable setting during bind to make more sense,
and not check i915_is_ggtt() 2 unnecessary times
Recommended-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 16 +++-
1 file changed, 7
I just noticed in our code we don't really check the assertion, and
given some of the code I am changing in this area, I feel a WARN is very
nice to have.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Ben Widawsky b...@bwidawsk.net
In order to transition more of our code over to using a VMA instead of
an OBJ, VM pair - we must have the vma accessible at execbuf time. Up
until now, we've only had a VMA when actually binding an object.
The previous patch helped handle the distinction on
40 matches
Mail list logo
