On Fri, Feb 15, 2013 at 11:53:14PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 05:07:44PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Someone may be waiting for a flip that will never complete due to a GPU
reset. Wake up all such
On Fri, Feb 15, 2013 at 11:47:52PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 06:56:03PM +0200, Ville Syrjälä wrote:
On Fri, Feb 15, 2013 at 03:28:33PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 05:07:46PM +0200, ville.syrj...@linux.intel.com
wrote:
From: Ville
On Mon, Feb 18, 2013 at 12:15:34PM +0200, Ville Syrjälä wrote:
On Fri, Feb 15, 2013 at 11:47:52PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 06:56:03PM +0200, Ville Syrjälä wrote:
On Fri, Feb 15, 2013 at 03:28:33PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 05:07:46PM
On Mon, Feb 18, 2013 at 10:47:37AM +, Chris Wilson wrote:
On Mon, Feb 18, 2013 at 12:15:34PM +0200, Ville Syrjälä wrote:
On Fri, Feb 15, 2013 at 11:47:52PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 06:56:03PM +0200, Ville Syrjälä wrote:
On Fri, Feb 15, 2013 at 03:28:33PM
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the interrupt handler were to process a previous vblank interrupt and
the following flip pending interrupt at the same time, the page flip
would be complete too soon.
To eliminate this race check the live pending flip status from the ISR
Am Montag, den 18.02.2013, 13:57 +0200 schrieb ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the interrupt handler were to process a previous vblank interrupt and
the following flip pending interrupt at the same time, the page flip
would be complete too
On Mon, Feb 18, 2013 at 01:50:26PM +0200, Ville Syrjälä wrote:
Can you send that as a patch for gen4? As I have a few people hitting
pageflip system hangs, but only on gen4 afaict.
I must admit that I'm confused now. Which model does Gen4 actually
follow, pending flip or flip done?
The
On Mon, Feb 18, 2013 at 01:57:51PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the interrupt handler were to process a previous vblank interrupt and
the following flip pending interrupt at the same time, the page flip
would be complete too
On Mon, Feb 18, 2013 at 01:07:53PM +0100, Paul Menzel wrote:
Am Montag, den 18.02.2013, 13:57 +0200 schrieb ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the interrupt handler were to process a previous vblank interrupt and
the following flip pending
On Mon, Feb 18, 2013 at 12:16:09PM +, Chris Wilson wrote:
On Mon, Feb 18, 2013 at 01:57:51PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the interrupt handler were to process a previous vblank interrupt and
the following flip
On Mon, Feb 18, 2013 at 11:58:23AM +0200, Ville Syrjälä wrote:
On Fri, Feb 15, 2013 at 11:53:14PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 05:07:44PM +0200, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Someone may be waiting for a
On Mon, Feb 18, 2013 at 02:27:24PM +0200, Ville Syrjälä wrote:
On Mon, Feb 18, 2013 at 12:16:09PM +, Chris Wilson wrote:
/* We detect FlipDone by looking for the change in PendingFlip from '1'
* to '0' on the following vblank, i.e. IIR has the Pendingflip
* asserted following the
On Thu, Feb 14, 2013 at 08:52:16AM -0800, Kenneth Graunke wrote:
On 02/14/2013 06:20 AM, Damien Lespiau wrote:
Turns out the new assembler that uses mesa's opcode emission hits the
path that automatically transforms MRF registers into GRF ones in the
exa_wm_src_projective shader.
The diff
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the interrupt handler were to process a previous vblank interrupt and
the following flip pending interrupt at the same time, the page flip
would be completed too soon.
To eliminate this race, check the live pending flip status from the ISR
From: Ville Syrjälä ville.syrj...@linux.intel.com
Use the gen3 logic for handling page flip interrupts on gen4.
Unfortuantely this kills the stall_check since that looks like it can
easily trigger too early. With the current logic the stall check would
kick in on the first vblank after the flip
On Mon, Feb 18, 2013 at 05:31:14PM +0200, Ville Syrjälä wrote:
On Mon, Feb 18, 2013 at 02:41:00PM +0200, Ville Syrjälä wrote:
On Mon, Feb 18, 2013 at 11:58:23AM +0200, Ville Syrjälä wrote:
On Fri, Feb 15, 2013 at 11:53:14PM +, Chris Wilson wrote:
On Fri, Feb 15, 2013 at 05:07:44PM
From: Ville Syrjälä ville.syrj...@linux.intel.com
Since obj-pending_flips was never set, intel_pipe_set_base() never
actually waited for pending page flips to complete.
We really do want to wait for the pending flips, because otherwise the
mmio surface base address update could overtake the
From: Ville Syrjälä ville.syrj...@linux.intel.com
GPU reset will drop all flips that are still in the ring. So after the
reset, call update_plane() for all CRTCs to make sure the primary
planes are scanning out from the correct buffer.
Also finish all pending flips. That means user space will
On Fri, Feb 15, 2013 at 01:23:10PM -0800, Jesse Barnes wrote:
To be used to restore sprite state on resume.
v2: move sprite tracking bits up so we don't track modified sprite state
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_drv.h|5 +
This series adds support for handling compact dma scatter lists to the
i915 driver. This is a dependency for the related upcoming change in the
PRIME interface:
http://www.spinics.net/lists/dri-devel/msg33917.html
v2:
- Add the sg_for_each_page macro to /lib/scatterlist instead of
drivers/drm.
So far we created a sparse dma scatter list for gem objects, where each
scatter list entry represented only a single page. In the future we'll
have to handle compact scatter lists too where each entry can consist of
multiple pages, for example for objects imported through PRIME.
The previous
The existing gtt setup code is correct - and so doesn't need to be fixed to
handle compact dma scatter lists similarly to the previous patches. Still,
take the for_each_sg_page macro into use, to get somewhat simpler code.
Signed-off-by: Imre Deak imre.d...@intel.com
---
On Mon, Feb 18, 2013 at 04:47:42PM +, Damien Lespiau wrote:
We already managed to get it out of sync (Haswell has been promoted out
of this option), so let's remove all mentions to platforms.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Queued for -next, thanks for the patch.
On Fri, Feb 08, 2013 at 05:35:12PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This avoids polluting i915_write##x and also allows us to reuse code
on i915_read##x.
v2: Rebase
Reviewed-by: Ben Widawsky b...@bwidawsk.net (v1)
Signed-off-by: Paulo Zanoni
The main thing here is to make the macros a bit safer by wrapping the
macro argument evaluations in parens.
Since that already touching huge portion of the file, I went a bit
further and make the whitespace style uniform throughout the file.
The other two small patches just unify the i-g-t and
From: Ville Syrjälä ville.syrj...@linux.intel.com
Protect the macro argument evaluations with parens.
This is already touching most lines, so while at it, fix up all white
space to uniform style throughout the file.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
lib/intel_chipset.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 6b4fab3..f703239 100755
--- a/lib/intel_chipset.h
+++
From: Ville Syrjälä ville.syrj...@linux.intel.com
Protect the macro argument evaluations with parens.
This is already touching most lines, so while at it, fix up all white
space to uniform style throughout the file.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
intel/intel_chipset.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 8af5acf..2760dc8 100644
---
From: Paulo Zanoni paulo.r.zan...@intel.com
This avoids polluting i915_write##x and also allows us to reuse code
on i915_read##x.
v2: Rebase
v3: Convert the macros to static functions
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 31
From: Paulo Zanoni paulo.r.zan...@intel.com
Otherwise, if the BIOS did anything wrong, our first I915_{WRITE,READ}
will give us unclaimed register messages.
V2: Even earlier.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58897
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by:
From: Paulo Zanoni paulo.r.zan...@intel.com
So use msecs_to_jiffies(10) to make the timeout the same as in the
!has_aux_irq case.
This patch was initially written by Daniel Vetter and posted on
pastebin a few weeks ago. I'm just bringing it to the mailing list.
Signed-off-by: Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com
This way we can remove some duplicated code and avoid more mistakes
and regressions with these registers in the future.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 66
From: Paulo Zanoni paulo.r.zan...@intel.com
Some (but not all) of the HDMI registers can be used to control sDVO,
so those registers have two names. IMHO, when we're talking about
HDMI, we really should call the HDMI control register hdmi_reg
instead of sdvox_reg, otherwise we'll just confuse
From: Paulo Zanoni paulo.r.zan...@intel.com
Some HDMI registers can be used for SDVO, so saying HDMIB should be
the same as saying SDVOB for a given HW generation. This was not
true and led to confusions and even a regression.
Previously we had:
- SDVO{B,C} defined as the Gen3+ registers
-
On Thu, Feb 07, 2013 at 11:00:13AM +0100, Daniel Vetter wrote:
On Wed, Feb 06, 2013 at 10:35:33PM +0100, David Härdeman wrote:
a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make
the sound go away (higher frame rates) or work (1080p30). So, it has
nothing to do with
Hi Daniel,
On Fri, 15 Feb 2013 08:16:26 -0800 Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 15 Feb 2013 10:30:16 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the drm-intel
i915_reg.h is messy enough without the extra stuff.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_reg.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 11fbeec..f7e7037
Previously FBC disabling due to per-chip default was logged as being
disabled per module parameter. Distinguish between the two.
v2: Don't even squawk in the debug log if FBC is explicitly disabled (Chris
Wilson).
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
39 matches
Mail list logo
