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
---
drivers/gpu/drm/i915/i915_debugfs.c |5 -
i915_reg.h is messy enough without the extra stuff.
Signed-off-by: Ben Widawsky
---
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 100644
--- a/driv
Hi Daniel,
On Fri, 15 Feb 2013 08:16:26 -0800 Jesse Barnes
wrote:
>
> On Fri, 15 Feb 2013 10:30:16 +0100
> Daniel Vetter wrote:
>
> > On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-intel tree, today's linux-next build (x86_64
> > > allmodconfig
On Mon, Feb 18, 2013 at 10:03 AM, Daniel Vetter wrote:
> On Fri, Feb 15, 2013 at 01:23:08PM -0800, Jesse Barnes wrote:
>> A few more fixes from Daniel.
>
> So one thing that crossed my mind which we should at least quickly
> discuss: How is userspace supposed to notice the resume? On a lot of
> de
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 inte
From: Paulo Zanoni
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
- HDMI{B,C,D} and PCH_SD
From: Paulo Zanoni
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 people reading
our code
From: Paulo Zanoni
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
---
drivers/gpu/drm/i915/intel_dp.c | 66 --
drivers/gpu/drm/i915/intel_drv.h |1 +
From: Paulo Zanoni
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
---
drivers/gpu/drm/i915/i
From: Paulo Zanoni
Since basically every code called on these places comes from
intel_ddi.c
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 12 ++--
drivers/gpu/drm/i915/intel_hdmi.c |2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers
From: Paulo Zanoni
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
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/
From: Paulo Zanoni
We plan to treat GEN7_ERR_INT as an interrupt, so use this register
for the checks inside I915_WRITE. This way we can have the best of
both worlds: the error message with a register address and the
V2: Split in 2 patches: one for the macro, one for changing the
register, as re
From: Paulo Zanoni
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
---
drivers/gpu/drm/i915/i915_drv.c | 31 +++
1 file changed, 23 insertions(
From: Paulo Zanoni
Hi
All the patches on this series have already been sent to this mailing list
(maybe with different titles) and received comments, except for patch 5, which
was posted on pastebin by Daniel. This series contains new versions of the
patches with all the bikesheds applied.
Plea
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
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
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -192,15 +19
From: Ville Syrjälä
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ä
---
intel/intel_chipset.h | 310 +-
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
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
+++ b/lib/intel_chipset.h
@@ -25,6 +25,9 @@
*
*/
+#ifndef _IN
From: Ville Syrjälä
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ä
---
lib/intel_chipset.h | 308 ++--
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 li
On Fri, Feb 08, 2013 at 05:35:12PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This avoids polluting i915_write##x and also allows us to reuse code
> on i915_read##x.
>
> v2: Rebase
>
> Reviewed-by: Ben Widawsky (v1)
> Signed-off-by: Paulo Zanoni
Checkpatch complained about the macro
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
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vett
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 67 +
So far the assumption was that each dma scatter list entry contains only
a single page. This might not hold in the future, when we'll introduce
compact scatter lists, so prepare for this everywhere in the i915 code
where we walk such a list.
We'll fix the place _creating_ these lists separately in
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 patch
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 the assumption was that each scatter list entry contains a single
page. This might not hold in the future, when we'll introduce compact
scatter lists, so prepare for this here.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm
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
> ---
> drivers/gpu/drm/i915/intel_drv.h|5 +
> drivers/gpu/drm/
From: Ville Syrjälä
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 get its
page flip events and won
Here are the (hopefully) final versions of the page flip vs. GPU reset fixes.
They survive the i-g-t kms_flip flip-vs-modeset-vs-hang and
flip-vs-panning-vs-hang tests, as well as stopping the rings while a
fullscreen GL application is running under X.
Now that we finish the page flips explicitly
From: Ville Syrjälä
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 flip, and you
could end up with a
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
---
drivers/gpu/drm/i915/i915_drv.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
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:0
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 +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
From: Ville Syrjälä
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 has been submitted to the
ring
On Wed, Feb 13, 2013 at 07:40:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse wrote:
> > On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
> >> We already have the quirk entry for the mobile platform, but also
> >> reports on some desktop versions. So be p
On Fri, Feb 15, 2013 at 01:23:08PM -0800, Jesse Barnes wrote:
> A few more fixes from Daniel.
So one thing that crossed my mind which we should at least quickly
discuss: How is userspace supposed to notice the resume? On a lot of
desktops (and even Androids) the normal thing seems to be to draw th
From: Ville Syrjälä
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
register before finishing the pag
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.
> >
>
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 th
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ä
> > >
> > > Someone may be waiting for a flip that will
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ä
> >
> > If the interrupt handler were to process a previous vblank interrupt and
> > the following flip pending interrupt at the s
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ä
> >
> > If the interrupt handler were to process a previous vblank interrupt and
> > the following flip pending interrupt at the sam
On Mon, Feb 18, 2013 at 01:57:51PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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
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?
Am Montag, den 18.02.2013, 13:57 +0200 schrieb ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> 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.
»would complete« o
From: Ville Syrjälä
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
register before finishing the page
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
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
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:
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ä
> >
> > Someone may be waiting for a flip that will never complete due to a GPU
> > reset. Wake up all such waiters after the GPU
50 matches
Mail list logo
