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 reset processing has
> finished.
>
> v2: Dropped the wake_up_all() from
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 Syrjälä
> > >
> > > GPU reset will drop all flips that are still
A few more fixes from Daniel.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Commented out and unneeded.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fb.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 987bc33..f4e0b88 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/
We still rely on a few LVDS bits, but restoring the enable bit can cause
trouble at this point, so don't.
v2: use the right mask to prevent restore (Daniel)
conditionalize on KMS support (Denial)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_suspend.c |8 ++--
1 file cha
This will poke userspace into probing for configuration changes that may
have occurred across suspend/resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/
With the other bits in place, we can do this safely.
v2: disable backlight on suspend to prevent premature enablement on resume
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 12 +---
drivers/gpu/drm/i915/intel_fb.c |3 +++
2 files changed, 12 insertions(+), 3 d
Needed for VT switchless resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3e6dadf..2bf076e 100644
-
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/i915/intel_sprite.c | 23 +++
2 files changed, 28 insert
On Fri, 15 Feb 2013 22:10:39 +0100
Daniel Vetter wrote:
> On Fri, Feb 15, 2013 at 12:42:32PM -0800, Jesse Barnes wrote:
> > We still rely on a few LVDS bits, but restoring the enable bit can cause
> > trouble at this point, so don't.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/
This will poke userspace into probing for configuration changes that may
have occurred across suspend/resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/
We still rely on a few LVDS bits, but restoring the enable bit can cause
trouble at this point, so don't.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_suspend.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/
On Fri, Feb 15, 2013 at 12:42:35PM -0800, Jesse Barnes wrote:
> With the other bits in place, we can do this safely.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.c |9 ++---
> drivers/gpu/drm/i915/intel_fb.c |3 +++
> 2 files changed, 9 insertions(+), 3 delet
On Fri, Feb 15, 2013 at 12:42:32PM -0800, Jesse Barnes wrote:
> We still rely on a few LVDS bits, but restoring the enable bit can cause
> trouble at this point, so don't.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_suspend.c |4 ++--
> 1 file changed, 2 insertions(+),
Commented out and unneeded.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fb.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 987bc33..f4e0b88 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/
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/i915/intel_sprite.c | 23 +++
2 files changed, 28 insert
With the other bits in place, we can do this safely.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |9 ++---
drivers/gpu/drm/i915/intel_fb.c |3 +++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915
Needed for VT switchless resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3e6dadf..2bf076e 100644
-
Fixed up the sprite bits to actually work, I had the tracking of the
state in the wrong place, which meant we'd use pre-modified bits on
resume, leading to breakage. The other patches are the same.
Thanks,
Jesse
___
Intel-gfx mailing list
Intel-gfx@lis
We still rely on a few LVDS bits, but restoring the enable bit can cause
trouble at this point, so don't.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_suspend.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/
This will poke userspace into probing for configuration changes that may
have occurred across suspend/resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/
With the other bits in place, we can do this safely.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |9 ++---
drivers/gpu/drm/i915/intel_fb.c |3 +++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915
Needed for VT switchless resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3e6dadf..2bf076e 100644
-
Commented out and unneeded.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fb.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 987bc33..f4e0b88 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/
Had to fix up a few things:
- LVDS blind restore from old suspend/resume code
- cursor restore
- sprite restore
Plus a couple of misc patches. Enough to make things work in X, though
our handling of sprites still needs improvement; I think our watermarks
are programmed out of order even tho
To be used to restore sprite state on resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|5 +
drivers/gpu/drm/i915/intel_sprite.c | 23 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i
On Thu, Feb 14, 2013 at 05:30:12PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/18 :
> > From: Ville Syrjälä
> >
> > HSW no longer has the PIPECONF bit for limited range RGB output.
> > Instead the pipe CSC unit must be used to perform that task.
> >
> > The CSC pre offset are set to 0, since the
On Fri, Feb 15, 2013 at 09:21:37PM +0100, Daniel Vetter wrote:
> We need to clear the local variable to get the refcounting right
> (since the reference drm_mode_setplane holds is transferred to the
> plane->fb pointer). But should be done _after_ we update the pointer.
>
> Breakage introduced in
On Fri, 15 Feb 2013 21:21:37 +0100
Daniel Vetter wrote:
> We need to clear the local variable to get the refcounting right
> (since the reference drm_mode_setplane holds is transferred to the
> plane->fb pointer). But should be done _after_ we update the pointer.
>
> Breakage introduced in
>
>
We need to clear the local variable to get the refcounting right
(since the reference drm_mode_setplane holds is transferred to the
plane->fb pointer). But should be done _after_ we update the pointer.
Breakage introduced in
commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
Author: Daniel Vetter
D
According to HSW PM Enabling guide, frequency bit was wrong.
Besides that, some setting values were different or not needed anymore on HSW.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 9 +++
drivers/gpu/drm/i915/intel_pm.c | 121
2
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
On Fri, Feb 15, 2013 at 06:35:30PM +0100, Daniel Vetter wrote:
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881
> Cc: sta...@vger.kernel.org
> Cc: Jani Nikula
> Tested-by: Jani Monoses
> Signed-off-by: Daniel Vetter
And merged right away ...
-Daniel
> ---
> drivers/gpu/drm/i915/in
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881
Cc: sta...@vger.kernel.org
Cc: Jani Nikula
Tested-by: Jani Monoses
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/
On Fri, 2013-02-15 at 13:36 -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If bit 0 of the features byte (0x18) is set to 0, then, according to
> the EDID spec, "the display is non-continuous frequency (multi-mode)
> and is only specified to accept the video timing formats that are
> listed
On Fri, Feb 15, 2013 at 08:17:58AM -0800, Jesse Barnes wrote:
> If PM_SLEEP is disabled, we need stub versions of these functions.
>
> v2: fix up struct device forward decl.
>
> Signed-off-by: Jesse Barnes
Ok, squashed into the old commit and tested. The trick is to disable
HIBERNATE and XEN su
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 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 mak
On Fri, 15 Feb 2013 11:05:26 +0100
Daniel Vetter wrote:
> On Thu, Feb 14, 2013 at 02:28:19PM -0800, Jesse Barnes wrote:
> > Well, I think we'll have to punt in quite a few configs due to hw
> > limitations about what can be changed without a full pipe shutdown, but
> > we can definitely do better
Hi Daniel,
On Fri, 15 Feb 2013 10:43:52 +0100 Daniel Vetter wrote:
>
> The patches in my next queue are fully reviewed and (should) have seen
> at least basic testing. The additional QA on top is just normal
> regression testing and about every 2 weeks a manual testing cycle for
> things like hot
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "pm_vt_switch_unregister" [drivers/video/fb.ko] undefined!
I have dropped the tree for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpLVsDkTPhcY.pg
Hi Daniel,
On Thu, 14 Feb 2013 15:19:53 +0100 Borislav Petkov wrote:
>
> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
> >
> > Since about a year ago we've switched drm/i915 to buffer around 2
> > weeks worth of patches so that we can do decent QA before breaking
> > everyone's
If PM_SLEEP is disabled, we need stub versions of these functions.
v2: fix up struct device forward decl.
Signed-off-by: Jesse Barnes
---
include/linux/pm.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 98310eb..e5da2f3 100644
---
On Fri, 15 Feb 2013 10:30:16 +0100
Daniel Vetter wrote:
> On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > After merging the drm-intel tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > ERROR: "pm_vt_switch_unregister" [drivers/video
On Fri, Feb 15, 2013 at 10:36 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If bit 0 of the features byte (0x18) is set to 0, then, according to
> the EDID spec, "the display is non-continuous frequency (multi-mode)
> and is only specified to accept the video timing formats that are
> listed i
From: Paulo Zanoni
If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, "the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certain Extension Blocks".
For more information,
On Fri, Feb 15, 2013 at 05:07:46PM +0200, ville.syrj...@linux.intel.com wrote:
> 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.
>
From: Ville Syrjälä
Do not use the TEST_HANG flag to determine whether page flip events are
used. Add a new TEST_NOEVENT flag that can be used to disable the use
of events instead.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
d
From: Ville Syrjälä
The flip-vs-panning-vs-hang is just like the regular flip-vs-panning
test, except it also hangs the GPU. This will test whether panning
works after a pending page flip has been cancelled by a GPU reset,
and also whether page flip events get delivered correctly.
Signed-off-by:
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.
The base address update will also generate a FLIP_DONE interrupt, which
will complete any
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
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 reset processing has
finished.
v2: Dropped the wake_up_all() from i915_handle_error() since
we no longer wait for pending flips with struct_mutex held.
S
Here are some more flip vs. reset handling fixes.
I think this series fixes all the usual hangs in the flip vs. reset handling.
It even sends out the page flip events to user space.
I can now run a GL game, stop the rings, wait for the reset to kick in, and
then go on playing as if nothing happen
On Fri, Feb 15, 2013 at 04:12:16PM +0200, Mika Kuoppala wrote:
> Ville Syrjälä writes:
>
> > On Mon, Feb 04, 2013 at 04:04:43PM +0200, Mika Kuoppala wrote:
> >> After hang check timer has declared gpu to be hang,
> >> rings are reset. In ring reset, when clearing
> >> request list, do post mortem
Ben Widawsky writes:
> Mostly just me talking outloud...
Much appreciated!
> On Mon, Feb 04, 2013 at 04:04:37PM +0200, Mika Kuoppala wrote:
>> If there was a batch chaining loop or infinite loop in the batchbuffer,
>> we didn't detect it as acthd and instdone kept changing in those cases
>> and
Ville Syrjälä writes:
> On Mon, Feb 04, 2013 at 04:04:43PM +0200, Mika Kuoppala wrote:
>> After hang check timer has declared gpu to be hang,
>> rings are reset. In ring reset, when clearing
>> request list, do post mortem analysis to find out
>> the guilty batch buffer.
>>
>> Select requests fo
On Fri, Feb 15, 2013 at 1:51 PM, Chris Wilson wrote:
> On Fri, Feb 15, 2013 at 12:18:49AM +, Chris Wilson wrote:
>> On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote:
>> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20
>> > and 5-9.
>> > Since we do all
On Fri, Feb 15, 2013 at 12:18:49AM +, Chris Wilson wrote:
> On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote:
> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> > 5-9.
> > Since we do all calculations based on them being register values (which are
On Thu, Feb 14, 2013 at 03:05:12PM -0800, Ben Widawsky wrote:
> Print out the HW context object information per ring. Even though the
> existing code only utilizes the render ring, it's simple enough to
> support future expansion.
>
> I had this in a patch somewhere in a rev of the original implem
On Thu, Feb 14, 2013 at 02:46:44PM -0800, Ben Widawsky wrote:
> On Thu, Feb 14, 2013 at 09:53:51PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The bit controlling whether PIPE_CONTROL DW/QW write targets
> > the global GTT or PPGTT moved moved from DW 2 bit 2 to
>
On Thu, Feb 14, 2013 at 02:51:19PM -0800, Ben Widawsky wrote:
> On Thu, Feb 14, 2013 at 07:46:07PM +0100, Daniel Vetter wrote:
> > Yet another remnant ... this might explain why l3 remapping didn't
> > really work on HSW.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
> > Spo
On Thu, Feb 14, 2013 at 02:28:19PM -0800, Jesse Barnes wrote:
> On Wed, 13 Feb 2013 12:32:03 +0100
> Daniel Vetter wrote:
>
> > Hi all
> >
> > So this is my old attempt to push our modeset infrastructure a bit further,
> > rebased on top of latest dinq. Originally I wanted to push this a bit
>
On Thu, Feb 14, 2013 at 10:14:56PM -0800, Ben Widawsky wrote:
> Mostly just me talking outloud...
>
> On Mon, Feb 04, 2013 at 04:04:37PM +0200, Mika Kuoppala wrote:
> > If there was a batch chaining loop or infinite loop in the batchbuffer,
> > we didn't detect it as acthd and instdone kept changi
On Fri, Feb 15, 2013 at 12:27 AM, Stephen Rothwell
wrote:
> Hi Daniel,
>
> On Thu, 14 Feb 2013 15:19:53 +0100 Borislav Petkov wrote:
>>
>> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
>> >
>> > Since about a year ago we've switched drm/i915 to buffer around 2
>> > weeks worth o
On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "pm_vt_switch_unregister" [drivers/video/fb.ko] undefined!
>
> I have dropped the tree for today.
Meh, that fail w
64 matches
Mail list logo
