[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"

My NV96 does not resume from suspend to ram (the screen stays black, magic sysrq keys do work) with the current linus git kernel, i bisected it to the following commit. drm/nv50/fifo: prevent races between clients updating playlists b5096566f6e1ee2b88324772f020ae9bc0cfa9a0 It's not obvious to me

[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"

My NV96 does not resume from suspend to ram (the screen stays black, magic sysrq keys do work) with the current linus git kernel, i bisected it to the following commit. drm/nv50/fifo: prevent races between clients updating playlists b5096566f6e1ee2b88324772f020ae9bc0cfa9a0 It's not obvious to me

[PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov wrote: > +#define RADEON_PT_OFFSET(_rdev) \ > + (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * > RADEON_PDE_SIZE)) Shouldn't that be _rdev too? Also a few lines above that you use rdev instead of _rdev. I didn't check the whole th

Re: [PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov wrote: > +#define RADEON_PT_OFFSET(_rdev) \ > + (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * > RADEON_PDE_SIZE)) Shouldn't that be _rdev too? Also a few lines above that you use rdev instead of _rdev. I didn't check the whole thi

[Nouveau] [bisected] nouveau: "Failed to idle channel x" after resume

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky wrote: > On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote: >> On 2012-08-08 08:18 +0200, Sven Joachim wrote: >> >> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote: >> > >> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote: >> >>> No

Re: [Nouveau] [bisected] nouveau: "Failed to idle channel x" after resume

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky wrote: > On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote: >> On 2012-08-08 08:18 +0200, Sven Joachim wrote: >> >> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote: >> > >> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote: >> >>> Not

[PATCH] nouveau: Add irq waiting as alternative to busywait

On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst wrote: > A way to trigger an irq will be needed for optimus support since > cpu-waiting isn't always viable there. This could also be nice for > power saving on since cpu would no longer have to spin, and > performance might improve slightly on c

Re: [PATCH] nouveau: Add irq waiting as alternative to busywait

On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst wrote: > A way to trigger an irq will be needed for optimus support since > cpu-waiting isn't always viable there. This could also be nice for > power saving on since cpu would no longer have to spin, and > performance might improve slightly on c

Linux 3.4-rc4

On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov wrote: > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote: >> On 2012-04-28 02:19 -0400, Alex Deucher wrote: >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler >> > wrote: >> > > Hi Ben, >> > > >> > > On 2012-04-27 15:20 +1000, Ben Skeg

Re: Linux 3.4-rc4

On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov wrote: > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote: >> On 2012-04-28 02:19 -0400, Alex Deucher wrote: >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler >> > wrote: >> > > Hi Ben, >> > > >> > > On 2012-04-27 15:20 +1000, Ben Skeg

BUG: drm_crtc_helper_set_config does not work

On Fri, Mar 9, 2012 at 5:28 PM, Yufeng Shen wrote: > On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis > wrote: >> On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen wrote: >>> So a simple case of ?disabling a CRTC and then re-enabling it. >>> >>> Disabling: &g

Re: BUG: drm_crtc_helper_set_config does not work

On Fri, Mar 9, 2012 at 5:28 PM, Yufeng Shen wrote: > On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis wrote: >> On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen wrote: >>> So a simple case of  disabling a CRTC and then re-enabling it. >>> >>> Disabling: >&

BUG: drm_crtc_helper_set_config does not work

On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen wrote: > So a simple case of ?disabling a CRTC and then re-enabling it. > > Disabling: > > CRTC X is originally connected to output Y > > 1. XRRSetCrtcConfig() ? ?is called to disable CRTC ?X > > 2. drm_helper_connector_dpms() ? then gets called on the c

Re: BUG: drm_crtc_helper_set_config does not work

On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen wrote: > So a simple case of  disabling a CRTC and then re-enabling it. > > Disabling: > > CRTC X is originally connected to output Y > > 1. XRRSetCrtcConfig()    is called to disable CRTC  X > > 2. drm_helper_connector_dpms()   then gets called on the c

KMS cursor BO semantics

On Fri, Nov 11, 2011 at 8:10 PM, Maarten Maathuis wrote: > On Fri, Nov 11, 2011 at 7:17 PM, James Simmons > wrote: >> >>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: >>> > I'm not sure whether / how you handle the case of hardware r

KMS cursor BO semantics

On Fri, Nov 11, 2011 at 7:17 PM, James Simmons wrote: > >> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: >> > I'm not sure whether / how you handle the case of hardware render to >> > cursor surfaces on i915, but it seems to me like if a lot of drivers >> > need to implement d

Re: KMS cursor BO semantics

On Fri, Nov 11, 2011 at 8:10 PM, Maarten Maathuis wrote: > On Fri, Nov 11, 2011 at 7:17 PM, James Simmons wrote: >> >>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: >>> > I'm not sure whether / how you handle the case of hardware render to

Re: KMS cursor BO semantics

On Fri, Nov 11, 2011 at 7:17 PM, James Simmons wrote: > >> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: >> > I'm not sure whether / how you handle the case of hardware render to >> > cursor surfaces on i915, but it seems to me like if a lot of drivers >> > need to implement dr

KMS cursor BO semantics

On Fri, Nov 4, 2011 at 11:59 PM, Thomas Hellstrom wrote: > On 11/04/2011 11:49 PM, Maarten Maathuis wrote: >> >> On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom >> ?wrote: >> >>> >>> On 11/04/2011 04:34 PM, Daniel Vetter wrote: >>> >

KMS cursor BO semantics

On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom wrote: > On 11/04/2011 04:34 PM, Daniel Vetter wrote: >> >> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: >> >>> >>> Hi. >>> >>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: >>> >>> Some hardware (v

Re: KMS cursor BO semantics

On Fri, Nov 4, 2011 at 11:59 PM, Thomas Hellstrom wrote: > On 11/04/2011 11:49 PM, Maarten Maathuis wrote: >> >> On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom >>  wrote: >> >>> >>> On 11/04/2011 04:34 PM, Daniel Vetter wrote: >>> >

Re: KMS cursor BO semantics

On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom wrote: > On 11/04/2011 04:34 PM, Daniel Vetter wrote: >> >> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: >> >>> >>> Hi. >>> >>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: >>> >>> Some hardware (vm

nouveau page_flip function implement not wait vblank, which cause screen garbage

2011/10/25 chris : > Can anyone give a suggestion, is wait-vblank fully implemented in > page_flip() for nouveau drm driver? > > > At 2011-10-24 14:30:55,chris? wrote: > > Dear, > > I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel > code, git drm 2.4.36. > ? When I run th

Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

2011/10/25 chris : > Can anyone give a suggestion, is wait-vblank fully implemented in > page_flip() for nouveau drm driver? > > > At 2011-10-24 14:30:55,chris  wrote: > > Dear, > > I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel > code, git drm 2.4.36. >   When I run th

Broken locking in ttm_bo_swapout

On Thu, Jan 20, 2011 at 7:53 PM, Matthew Bullock wrote: > I have a fairly simple opengl application running on nouveau. It effectively > just plots a couple of very large images that change regularly. > > I've been getting an easily repeatable failure, hitting the > BUG_ON(in_interrupt) in vfree()

Re: Broken locking in ttm_bo_swapout

On Thu, Jan 20, 2011 at 7:53 PM, Matthew Bullock wrote: > I have a fairly simple opengl application running on nouveau. It effectively > just plots a couple of very large images that change regularly. > > I've been getting an easily repeatable failure, hitting the > BUG_ON(in_interrupt) in vfree()

[PATCH 2/2] nouveau: Acknowledge HPD irq in handler, not bottom half

On Wed, Nov 10, 2010 at 11:51 PM, Andrew Lutomirski wrote: > On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote: >> On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote: >>> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote: >>> > On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote: >>

Re: [PATCH 2/2] nouveau: Acknowledge HPD irq in handler, not bottom half

On Wed, Nov 10, 2010 at 11:51 PM, Andrew Lutomirski wrote: > On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote: >> On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote: >>> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote: >>> > On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote: >>

[PATCH]: nouveau and radeon checkstack fixes

On Sat, May 22, 2010 at 2:30 AM, Prarit Bhargava wrote: > Fixes linux-next & linux-2.6 checkstack warnings: > > drivers/gpu/drm/nouveau/nv40_graph.c: In function `nv40_graph_init': > drivers/gpu/drm/nouveau/nv40_graph.c:400: warning: the frame size of 1184 > bytes is larger than 1024 bytes > driv

Re: [PATCH]: nouveau and radeon checkstack fixes

On Sat, May 22, 2010 at 2:30 AM, Prarit Bhargava wrote: > Fixes linux-next & linux-2.6 checkstack warnings: > > drivers/gpu/drm/nouveau/nv40_graph.c: In function `nv40_graph_init': > drivers/gpu/drm/nouveau/nv40_graph.c:400: warning: the frame size of 1184 > bytes is larger than 1024 bytes > driv