On Thu, Mar 13, 2014 at 09:38:45AM -0400, Ilia Mirkin wrote:
> On Sun, Mar 9, 2014 at 10:51 AM, Marcin Slusarz
> wrote:
> > [ 326.168487] ==
> > [ 326.168491] [ INFO: possible circular locking dependency detected ]
> &g
[ 326.168487] ==
[ 326.168491] [ INFO: possible circular locking dependency detected ]
[ 326.168496] 3.13.6 #1270 Not tainted
[ 326.168500] ---
[ 326.168504] ldconfig/22297 is trying to
On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
> Op 25-03-13 19:14, Marcin Slusarz schreef:
> > On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
> >> Fixes 100% cpu usage when the exit interrupt never got acked.
> >>
> >&
On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
Op 25-03-13 19:14, Marcin Slusarz schreef:
On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
Fixes 100% cpu usage when the exit interrupt never got acked.
Signed-off-by: Maarten Lankhorst m.b.lankho
On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
> Fixes 100% cpu usage when the exit interrupt never got acked.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c
> b/drivers/gpu/drm/nouveau/core/core/falcon.c
> index
On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
Fixes 100% cpu usage when the exit interrupt never got acked.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c
b/drivers/gpu/drm/nouveau/core/core/falcon.c
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> > Dropping Tegra ML, it's not the place where Nouveau mails should go.
>
> $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
> ...
> linux-tegra
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
Dropping Tegra ML, it's not the place where Nouveau mails should go.
$ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
...
(event->priv, 0x61002c, (1 << head), (0 << head));
> + nv_mask(event->priv, 0x61002c, (4 << head), 0);
> }
>
> static int
>
It fixes vblank on my NVA8, thanks.
Tested-by: Marcin Slusarz
.
Tested-by: Marcin Slusarz marcin.slus...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Feb 20, 2013 at 03:47:05PM +0100, Jiri Slaby wrote:
> On 02/19/2013 08:07 AM, Marcin Slusarz wrote:
> >>> Crash/warning should be fixed by commit
> >>> cfd376b6bfccf33782a0748a9c70f7f752f8b869
> >>> "drm/nouveau/vm: fix memory corruption when
On Wed, Feb 20, 2013 at 03:47:05PM +0100, Jiri Slaby wrote:
On 02/19/2013 08:07 AM, Marcin Slusarz wrote:
Crash/warning should be fixed by commit
cfd376b6bfccf33782a0748a9c70f7f752f8b869
drm/nouveau/vm: fix memory corruption when pgt allocation fails.
Oh, thanks for the pointer. Could
On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
> On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
> > On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> > > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
> > >> Hi,
> > &
On Tue, Feb 19, 2013 at 10:09:12PM +0100, Michael Weirauch wrote:
> 2013/2/19 Marcin Slusarz :
> > Yay. It will probably fix
> > https://bugs.freedesktop.org/show_bug.cgi?id=59168.
> > (note: it doesn't apply on top of nouveau/master)
>
> Please correct me if I am wro
bably fix https://bugs.freedesktop.org/show_bug.cgi?id=59168.
(note: it doesn't apply on top of nouveau/master)
Reviewed-by: Marcin Slusarz
> ---
>
> diff --git a/drivers/gpu/drm/nouveau/nvc0_fence.c
> b/drivers/gpu/drm/nouveau/nvc0_fence.c
> index 85a0e78..4f46d8b 100644
> --- a/dri
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
> On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
> >> Hi,
> >>
> >> we have a report of WARNING from 3.7.6 in nouveau at
> >> dr
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
> Hi,
>
> we have a report of WARNING from 3.7.6 in nouveau at
> drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
> https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
>
> There is an order 4 allocation failure in nouveau_drm_open ->
fix https://bugs.freedesktop.org/show_bug.cgi?id=59168.
(note: it doesn't apply on top of nouveau/master)
Reviewed-by: Marcin Slusarz marcin.slus...@gmail.com
---
diff --git a/drivers/gpu/drm/nouveau/nvc0_fence.c
b/drivers/gpu/drm/nouveau/nvc0_fence.c
index 85a0e78..4f46d8b 100644
On Tue, Feb 19, 2013 at 10:09:12PM +0100, Michael Weirauch wrote:
2013/2/19 Marcin Slusarz marcin.slus...@gmail.com:
Yay. It will probably fix
https://bugs.freedesktop.org/show_bug.cgi?id=59168.
(note: it doesn't apply on top of nouveau/master)
Please correct me if I am wrong
On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
There is an order 4 allocation failure in nouveau_drm_open -
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https
On Sat, Feb 16, 2013 at 12:57:07AM +0200, Denys Fedoryshchenko wrote:
> Hi
>
> Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce
> 310M], latest rc, and got this.
> Please let me know if you need additional information.
It's harmless and already quieted down in Linus' tree
On Sat, Feb 16, 2013 at 12:57:07AM +0200, Denys Fedoryshchenko wrote:
Hi
Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce
310M], latest rc, and got this.
Please let me know if you need additional information.
It's harmless and already quieted down in Linus' tree (post
class.
Reported-by: Arend van Spriel
Reported-by: Peter Hurley
Reported-by: Maarten Lankhorst
Reported-by: Daniel J Blueman
Signed-off-by: Marcin Slusarz
Cc: stable at vger.kernel.org [3.7, but needs s/const ofuncs/ofuncs/ to build]
---
Lightly tested, only on NV4B and NVC1.
---
drivers/gpu
class.
Reported-by: Arend van Spriel ar...@broadcom.com
Reported-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reported-by: Daniel J Blueman dan...@quora.org
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: sta...@vger.kernel.org
On Sat, Jan 05, 2013 at 10:10:06AM +0100, Pontus Fuchs wrote:
> On 01/03/2013 08:12 PM, Marcin Slusarz wrote:
> > On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote:
> >> I bisected the problem down to this commit:
> >>
> >> 186ecad21: drm/nv50/dis
On Sat, Jan 05, 2013 at 10:10:06AM +0100, Pontus Fuchs wrote:
On 01/03/2013 08:12 PM, Marcin Slusarz wrote:
On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote:
I bisected the problem down to this commit:
186ecad21: drm/nv50/disp: move remaining interrupt handling into core
On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote:
> On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote:
> > Hi,
> >
> > Starting with 3.8rc1 I get a black screen when resuming after suspend.
> > The kernel is alive because I can switch to VT1 an
On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote:
> Hi,
>
> Starting with 3.8rc1 I get a black screen when resuming after suspend.
> The kernel is alive because I can switch to VT1 and reboot with
> ctrl-alt-delete.
>
> I bisected the problem down to this commit:
>
> 186ecad21:
On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote:
Hi,
Starting with 3.8rc1 I get a black screen when resuming after suspend.
The kernel is alive because I can switch to VT1 and reboot with
ctrl-alt-delete.
I bisected the problem down to this commit:
186ecad21:
On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote:
On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote:
Hi,
Starting with 3.8rc1 I get a black screen when resuming after suspend.
The kernel is alive because I can switch to VT1 and reboot with
ctrl-alt-delete
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
> Check that the AGP aperture can be mapped. This follows a similar change
> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
> the aperture can be mapped by the CPU.).
>
> The patch fixes the following error
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).
The patch fixes the following error seen on
On Mon, Dec 24, 2012 at 09:26:17PM +0100, balducci at units.it wrote:
> hello everybody,
>
> apologies if I am missing any blatant point; my knowledge about
> KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
> at the right place)
>
> Starting with kernel-3.7 I am not able to
On Mon, Dec 24, 2012 at 09:26:17PM +0100, baldu...@units.it wrote:
hello everybody,
apologies if I am missing any blatant point; my knowledge about
KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
at the right place)
Starting with kernel-3.7 I am not able to boot any
On Mon, Nov 12, 2012 at 06:14:05AM -0600, Kelly Doran wrote:
> Okay I have added two patches, one of them should fix the problem...
>
vblank-fix1.patch works, thanks.
Marcin
On Mon, Nov 12, 2012 at 06:14:05AM -0600, Kelly Doran wrote:
Okay I have added two patches, one of them should fix the problem...
vblank-fix1.patch works, thanks.
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Sun, Nov 11, 2012 at 07:26:17PM +0100, Marcin Slusarz wrote:
> On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:
> >
> >
> > Op 06-11-12 15:48, Kelly Doran schreef:
> > > The vblank on nvc0 was not working correctly and would freeze X, I managed
On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:
>
>
> Op 06-11-12 15:48, Kelly Doran schreef:
> > The vblank on nvc0 was not working correctly and would freeze X, I managed
> > to track it down and fix it with some help from m.b.lankhorst, see
> >
On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:
Op 06-11-12 15:48, Kelly Doran schreef:
The vblank on nvc0 was not working correctly and would freeze X, I managed
to track it down and fix it with some help from m.b.lankhorst, see
On Sun, Nov 11, 2012 at 07:26:17PM +0100, Marcin Slusarz wrote:
On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:
Op 06-11-12 15:48, Kelly Doran schreef:
The vblank on nvc0 was not working correctly and would freeze X, I managed
to track it down and fix it with some
On Tue, Nov 06, 2012 at 10:03:40PM +0800, Daniel J Blueman wrote:
> In 3.7-rc4, when starting X with the integrated GPU and suspending the
> discrete GPU,
> after one or more 32-bit applications are used (eg Skype) and X is stopped,
> we hit a panic.
>
> Prevent this by testing if the fini
On Tue, Nov 06, 2012 at 10:03:40PM +0800, Daniel J Blueman wrote:
In 3.7-rc4, when starting X with the integrated GPU and suspending the
discrete GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.
Prevent this by testing if the fini function is
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_memory.c | 1 -
include/drm/ttm/ttm_memory.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 479c6b0..dbc2def 100644
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c| 1 -
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 412486c..da7a985 100644
All drivers pass NULL here. ttm_buffer_object's field can still be set after
init, just like nouveau does.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 7 +++
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200
All drivers set it to 0 and nothing uses it.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 2
All drivers set it to 0 and nothing uses it.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ast/ast_ttm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 2
All drivers pass NULL here. ttm_buffer_object's field can still be set after
init, just like nouveau does.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ast/ast_ttm.c| 7 +++
drivers/gpu/drm/cirrus
It's unused.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c| 1 -
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm
It's unused.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_memory.c | 1 -
include/drm/ttm/ttm_memory.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> wrote:
> >
> > This looks like ACPI bug...
>
> I'm _shocked_ to hear that firmware would be fragile.
>
> Anyway, here's the #1 thing
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Pawe? Sikora wrote:
> On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > > On 20.10.2012, Marcin Slusarz wrote:
> > >
> > > > Try thi
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685
On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Paweł Sikora wrote:
On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
On 20.10.2012, Marcin Slusarz wrote:
Try this one.
It works, now I can boot again. However
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
This looks like ACPI bug...
I'm _shocked_ to hear that firmware would be fragile.
Anyway, here's the #1 thing to keep in mind about firmware
On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote:
> >
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top
> Tried it. Unfortunately, the crash remains the same as reported.
Try this one.
Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
---
From: Marcin Slusarz <marcin.slu
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
On 20.10.2012, Marcin Slusarz wrote:
Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:
[3.685909] [drm] Initialized i915 1.6.0
On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote:
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
On 20.10.2012, Marcin Slusarz wrote:
Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
On 20.10.2012, Marcin Slusarz wrote:
Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:
[3.685909] [drm] Initialized i915 1.6.0
It's a relic of "drm: Convert proc files to seq_file and introduce debugfs",
which wrongly converted DRM_INFO + sprintf to 2 seq_printfs.
Signed-off-by: Marcin Slusarz
Cc: Ben Gamari
Cc: Eric Anholt
---
drivers/gpu/drm/drm_info.c | 2 --
1 file changed, 2 deletions(-)
diff --git
It's a relic of drm: Convert proc files to seq_file and introduce debugfs,
which wrongly converted DRM_INFO + sprintf to 2 seq_printfs.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Ben Gamari bgam...@gmail.com
Cc: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/drm_info.c | 2 --
1
On Thu, Oct 11, 2012 at 07:29:15PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
>
On Thu, Oct 11, 2012 at 07:29:15PM -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
A helper that drivers can use to send vblank event after a pageflip.
If the driver doesn't support proper vblank irq based time/seqn then
just pass -1 for the pipe # to get do_gettimestamp() behavior
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> Add a helper fxn to send vblank event after pageflip, plus a handful
> of fixes for other issues that I noticed in the process.
FWIW, patches 1-5 and 7 (with a fix to 1st) are:
Reviewed-by: Ma
On Mon, Oct 08, 2012 at 02:50:39PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
>
On Mon, Oct 08, 2012 at 02:50:39PM -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
A helper that drivers can use to send vblank event after a pageflip.
If the driver doesn't support proper vblank irq based time/seqn then
just pass -1 for the pipe # to get do_gettimestamp() behavior
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
Add a helper fxn to send vblank event after pageflip, plus a handful
of fixes for other issues that I noticed in the process.
FWIW, patches 1-5 and 7 (with a fix to 1st) are:
Reviewed-by: Marcin Slusarz
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
libkms/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libkms/Makefile.am b/libkms/Makefile.am
index fa379a4..215450a 100644
--- a/libkms/Makefile.am
+++ b/libkms/Makefile.am
@@ -6,7 +6,7 @@ AM_CFLAGS
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Gl?ck wrote:
> I have managed to turn the crash into a WARN_ON, by adding this to the
> begin of nouveau_software_vblank():
>
> if (!psw) {
> WARN_ON(1);
> return;
> }
Yes, I know about it, but
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
I have managed to turn the crash into a WARN_ON, by adding this to the
begin of nouveau_software_vblank():
if (!psw) {
WARN_ON(1);
return;
}
Yes, I know about it, but this
On Mon, Jul 30, 2012 at 01:16:37PM +0200, Ortwin Gl?ck wrote:
> On 29.07.2012 22:15, Marcin Slusarz wrote:
> > No, the real problem is: with "noaccel" we don't register "software engine",
> > but vblank ISR relies on its existance and happily derefences NULL poin
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Gl?ck wrote:
> On 25.07.2012 20:42, Marcin Slusarz wrote:
> > Good, below patch should fix this panic.
> >
> > Note that you can hit an oops in drm_handle_vblank because patch from
> > http://lists.freedesktop.org/archive
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote:
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Gl?ck wrote:
> On 25.07.2012 20:42, Marcin Slusarz wrote:
> > Good, below patch should fix this panic.
> >
> > Note that you can hit an oops in drm_handle_vblank because patch from
> > http://lists.freedesktop.org/archive
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote:
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
nic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
has not been applied (yet?).
--
From: Marcin Slusarz <marcin.slus...@gmail.com>
Date: Wed, 25 Jul 2012 20:07:22 +0200
Subject: [PATCH] drm/nouveau: in
.html
has not been applied (yet?).
--
From: Marcin Slusarz marcin.slus...@gmail.com
Date: Wed, 25 Jul 2012 20:07:22 +0200
Subject: [PATCH] drm/nouveau: init vblank requests list
Fixes kernel panic when vblank interrupt triggers before first sync to vblank
request.
(Besides init, remove some relevant
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Gl?ck wrote:
> On 24.07.2012 19:00, Marcin Slusarz wrote:
> > Please post the crash log.
>
> Sorry, I was not precise: it boots until drm performs modesetting (so it
> seems). The screen goes black and the machine is dead. So the
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Gl?ck wrote:
> Hi,
>
> My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with
> 3.4. Bisected to the following commit:
>
> 20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit
> commit
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Glück wrote:
Hi,
My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with
3.4. Bisected to the following commit:
20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit
commit
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Glück wrote:
On 24.07.2012 19:00, Marcin Slusarz wrote:
Please post the crash log.
Sorry, I was not precise: it boots until drm performs modesetting (so it
seems). The screen goes black and the machine is dead. So there is
nothing I could
On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote:
>
> Patches 1 to 4 were sent to mesa-dev.
And you chose to ignore most of my comments.
Fine. Don't expect further reviews from me.
Marcin
On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote:
Patches 1 to 4 were sent to mesa-dev.
And you chose to ignore most of my comments.
Fine. Don't expect further reviews from me.
Marcin
___
dri-devel mailing list
On Thu, Jun 28, 2012 at 09:51:58PM +0200, Johannes Obermayr wrote:
These patches should be sent to dri-devel, not mesa-dev.
> ---
> xf86drm.c | 15 ++-
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 6ea068f..798f1fd 100644
> ---
On Thu, Jun 28, 2012 at 09:51:58PM +0200, Johannes Obermayr wrote:
These patches should be sent to dri-devel, not mesa-dev.
---
xf86drm.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..798f1fd 100644
---
On Sun, May 27, 2012 at 10:25:21PM +0200, Marcin Slusarz wrote:
> On Thu, May 24, 2012 at 08:09:41PM +0200, Bruno Pr?mont wrote:
> > I can easily trigger a crash in nouveau interrupt handler by unbinding
> > and rebinding the GPU.
> >
> > The command used:
> >
On Sun, May 27, 2012 at 10:25:21PM +0200, Marcin Slusarz wrote:
On Thu, May 24, 2012 at 08:09:41PM +0200, Bruno Prémont wrote:
I can easily trigger a crash in nouveau interrupt handler by unbinding
and rebinding the GPU.
The command used:
echo $pci_device nouveau/unbind
It crashed because Nouveau failed to disable vblank interrupt on unbind
and this interrupt triggered while drm was initializing vblank data.
Nouveau side was fixed by "drm/nv04/disp: disable vblank interrupts when
disabling display" by Ben Skeggs (3.5 merge window), drm side can be fixed
by
triggered while drm was initializing vblank data.
Nouveau side was fixed by drm/nv04/disp: disable vblank interrupts when
disabling display by Ben Skeggs (3.5 merge window), drm side can be fixed
by this:
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] drm: do not expose vblank data
On Thu, May 17, 2012 at 06:32:19AM -0600, Rob Clark wrote:
On Thu, May 17, 2012 at 4:31 AM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
The main requirement I have for this interface is for scanning out
using the USB gpu devices. Since these devices have to
On Thu, Apr 26, 2012 at 05:32:29PM +1000, Ben Skeggs wrote:
> On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
> > Overall idea:
> > Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> > handle them at ioctl level, reset the GPU and repeat las
On Thu, Apr 26, 2012 at 05:32:29PM +1000, Ben Skeggs wrote:
On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset
On Wed, Apr 25, 2012 at 11:20:36PM +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
>
> GPU reset is done by doing suspend / resume cycle
waits
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/Makefile |2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
drivers/gpu/drm/nouveau/nouveau_channel.c |5 +-
drivers/gpu/drm/nouveau/nouveau_drv.c | 56 ++-
drivers/gpu/drm/nouveau
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau
1 - 100 of 217 matches
Mail list logo
