[PATCH] Fix drm vblank / irq in master
The changes that we discussed on irc are turning out to be slightly more difficult than I expected... In the meantime, I'd like to push this to master to get things more or less working again. One thing I discovered was that, at least on bsd, the signal handler gets installed / uninstalled pretty often right now. Each time that happens, we call drm_vblank_init and reset vblank_disable_allowed=0, meaning that a modeset or dpms must occur after the handler is installed each time to disable vblanks. This patch reverts most of my changes to i915's irq install / uninstall functions. It does move the drm_vblank_init and drm_vblank_cleanup calls to the drivers respective load / unload routines. Minor additional changes will be needed on the linux side. Mostly just remove the drm_vblank_cleanup call from you irq_uninstall path. I have made the driver changes to i915 and radeon so far, but I am only able to test intel. I'm still working to allow the irq handlers to be installed at load time, but that is slightly more complicated surgery, at least on the bsd side of the house... robert. -- Robert Noland <[EMAIL PROTECTED]> 2Hip Networks diff --git a/bsd-core/drmP.h b/bsd-core/drmP.h index 326b220..e65b7e0 100644 --- a/bsd-core/drmP.h +++ b/bsd-core/drmP.h @@ -933,6 +933,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc); void drm_vblank_put(struct drm_device *dev, int crtc); int drm_vblank_wait(struct drm_device *dev, unsigned int *vbl_seq); int drm_vblank_init(struct drm_device *dev, int num_crtcs); +void drm_vblank_cleanup(struct drm_device *dev); void drm_vbl_send_signals(struct drm_device *dev, int crtc); int drm_modeset_ctl(struct drm_device *dev, void *data, struct drm_file *file_priv); diff --git a/bsd-core/drm_irq.c b/bsd-core/drm_irq.c index 6e21d41..76809e6 100644 --- a/bsd-core/drm_irq.c +++ b/bsd-core/drm_irq.c @@ -96,7 +96,7 @@ static void vblank_disable_fn(void *arg) } } -static void drm_vblank_cleanup(struct drm_device *dev) +void drm_vblank_cleanup(struct drm_device *dev) { unsigned long irqflags; @@ -295,8 +295,6 @@ int drm_irq_uninstall(struct drm_device *dev) #elif defined(__NetBSD__) || defined(__OpenBSD__) pci_intr_disestablish(&dev->pa.pa_pc, dev->irqh); #endif - drm_vblank_cleanup(dev); - return 0; } diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c index e57580f..9ab59ab 100644 --- a/shared-core/i915_dma.c +++ b/shared-core/i915_dma.c @@ -1027,24 +1027,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) dev->dev_private = (void *)dev_priv; - /* Add register map (needed for suspend/resume) */ - base = drm_get_resource_start(dev, mmio_bar); - size = drm_get_resource_len(dev, mmio_bar); - - ret = drm_addmap(dev, base, size, _DRM_REGISTERS, - _DRM_KERNEL | _DRM_DRIVER, &dev_priv->mmio_map); - -#ifdef __linux__ -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25) - intel_init_chipset_flush_compat(dev); -#endif - intel_opregion_init(dev); -#endif - - I915_WRITE16(HWSTAM, 0xeffe); - I915_WRITE16(IMR, 0x0); - I915_WRITE16(IER, 0x0); - DRM_SPININIT(&dev_priv->swaps_lock, "swap"); INIT_LIST_HEAD(&dev_priv->vbl_swaps.head); dev_priv->swaps_pending = 0; @@ -1060,14 +1042,19 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) dev_priv->vblank_pipe = DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B; dev->max_vblank_count = 0xff; /* only 24 bits of frame count */ - i915_enable_interrupt(dev); - DRM_INIT_WAITQUEUE(&dev_priv->irq_queue); + /* Add register map (needed for suspend/resume) */ + base = drm_get_resource_start(dev, mmio_bar); + size = drm_get_resource_len(dev, mmio_bar); - /* - * Initialize the hardware status page IRQ location. - */ + ret = drm_addmap(dev, base, size, _DRM_REGISTERS, + _DRM_KERNEL | _DRM_DRIVER, &dev_priv->mmio_map); - I915_WRITE(INSTPM, (1 << 5) | (1 << 21)); +#ifdef __linux__ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25) + intel_init_chipset_flush_compat(dev); +#endif + intel_opregion_init(dev); +#endif return ret; } @@ -1075,23 +1062,11 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) int i915_driver_unload(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; - u32 temp; - - if (dev_priv) { - dev_priv->vblank_pipe = 0; - - dev_priv->irq_enabled = 0; - I915_WRITE(HWSTAM, 0x); - I915_WRITE(IMR, 0x); - I915_WRITE(IER, 0x0); - - temp = I915_READ(PIPEASTAT); - I915_WRITE(PIPEASTAT, temp); - temp = I915_READ(PIPEBSTAT); - I915_WRITE(PIPEBSTAT, temp); - temp = I915_READ(IIR); - I915_WRITE(IIR, temp); - } + + DRM_SPINUNINIT(&dev_priv->user_irq_lock); + DRM_SPINUNINIT(&dev_priv->swaps_lock); + + drm_vblank_cleanup(dev); if (dev_priv->mmio_map) drm_rmmap(dev, dev_priv->mmio_map); diff --git a/shared-core/i915_drv.h b/shared-core/i915_drv.h index a77fcf0..421572c 100644 --- a/shared-core/i915_drv.h +++ b/shared-core/i915_drv.h @@ -307,7 +307,6 @@ extern irqreturn_t i915_driver_irq
Re: cursor handling and updates inside DRM
Stephane Marchesin escreveu: > On Fri, Jul 11, 2008 at 1:12 AM, Tiago Vignatti <[EMAIL PROTECTED]> wrote: >> Yeah, but the current design in the kms (i.e. DRM touching the >> registers) is not good as well. The pointer is jumping a lot -- much >> more than the "old" design -- because with a single device movement it >> emits a hundred of events and a lot of context switch is done. Not cool. >> > > Care to elaborate ? What you describe here sounds like an > implementation-specific issue, more than an issue with KMS. Okay, I lied here ;) The reason of the cursor jumping is not the number of context switches. Dave helped me to identify the real reason. Try to call a xrandr instance and move the mouse with kernel modesetting. xrandr will do DDC communication which will blocked X in the kernel. With my implementation of the X server using a separate thread to take care the input events this is _reduced_ because signals is not used to wake up the devices. Moreover, with the handling and update of the cursor inside the kernel all would work perfectly smooth (in fact I tried it with my proof-of-concept and it was confirmed). Thanks you, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X "Hangs" with RS690 + 2.6.26
Am Freitag 25 Juli 2008 12:12:59 schrieb Jerome Glisse: > This looks like usual engine lockup followed by CP lockup so > that DMA buffer age never get written and we run out of DMA > buffer thus freelist failing in infinite loop. > > I think we now know all the reason why we lockup, while a > fix could be made for old ioctl we believe the best plan is > to work on new ioctl with this fix in mind. I can't help but feel uneasy with that kind of plan. After all, do "we" *really* know what's going on? I always had the impression that we only knew things along the lines of "perhaps it's better to submit 3D stuff in indirect buffers". If you *really* know what causes the lockups, could you please document that? As in, what's the actual command processor sequence that is to blame? I know that running e.g. a Nexuiz demo + glxgears window above it is apparently a 100% guaranteed lockup on my system (R420). If you could share your progress in tracking down the sources of the lockups, I'd happily try to write a patch against the current system. cu, Nicolai signature.asc Description: This is a digitally signed message part. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM fixed compilation errors and warnings for 2.6.26
Hello All, Sorry for the delay in sending the updated patch.I appreciate your time to review and comment on the same. Fixed the conditional operator and its logic for checking the allocation of memory , white space between the pointers and cleaned up few warnings. Signed-off-by : Nagaraj SK <[EMAIL PROTECTED]> --- --- linux-2.6.26/drivers/char/drm/drm_memory.c2008-07-26 02:00:56.0 +0530 +++ linux-staging/drivers/char/drm/drm_memory.c2008-07-26 01:55:50.0 +0530 @@ -69,7 +69,8 @@ void *drm_realloc(void *oldpt, size_t ol { void *pt; -if (!(pt = kmalloc(size, GFP_KERNEL))) +pt = kmalloc(size, GFP_KERNEL); +if (!pt) return NULL; if (oldpt && oldsize) { memcpy(pt, oldpt, oldsize); @@ -80,7 +81,7 @@ void *drm_realloc(void *oldpt, size_t ol #if __OS_HAS_AGP static void *agp_remap(unsigned long offset, unsigned long size, - struct drm_device * dev) + struct drm_device *dev) { unsigned long *phys_addr_map, i, num_pages = PAGE_ALIGN(size) / PAGE_SIZE; @@ -103,9 +104,10 @@ static void *agp_remap(unsigned long off return NULL; /* - * OK, we're mapping AGP space on a chipset/platform on which memory accesses by - * the CPU do not get remapped by the GART. We fix this by using the kernel's - * page-table instead (that's probably faster anyhow...). + * OK, we're mapping AGP space on a chipset/platform on which memory + * accesses by the CPU do not get remapped by the GART. We fix this + * by using the kernel's page-table instead (that's probably + * faster anyhow...). */ /* note: use vmalloc() because num_pages could be large... */ page_map = vmalloc(num_pages * sizeof(struct page *)); @@ -123,32 +125,32 @@ static void *agp_remap(unsigned long off } /** Wrapper around agp_allocate_memory() */ -DRM_AGP_MEM *drm_alloc_agp(struct drm_device * dev, int pages, u32 type) +DRM_AGP_MEM *drm_alloc_agp(struct drm_device *dev, int pages, u32 type) { return drm_agp_allocate_memory(dev->agp->bridge, pages, type); } /** Wrapper around agp_free_memory() */ -int drm_free_agp(DRM_AGP_MEM * handle, int pages) +int drm_free_agp(DRM_AGP_MEM *handle, int pages) { return drm_agp_free_memory(handle) ? 0 : -EINVAL; } /** Wrapper around agp_bind_memory() */ -int drm_bind_agp(DRM_AGP_MEM * handle, unsigned int start) +int drm_bind_agp(DRM_AGP_MEM *handle, unsigned int start) { return drm_agp_bind_memory(handle, start); } /** Wrapper around agp_unbind_memory() */ -int drm_unbind_agp(DRM_AGP_MEM * handle) +int drm_unbind_agp(DRM_AGP_MEM *handle) { return drm_agp_unbind_memory(handle); } #else /* __OS_HAS_AGP */ static inline void *agp_remap(unsigned long offset, unsigned long size, - struct drm_device * dev) + struct drm_device *dev) { return NULL; } Thanks Nagaraj On Mon, Jul 21, 2008 at 7:24 AM, nagaraj s k <[EMAIL PROTECTED]> wrote: > Hi Daniel, > > Thanks for correcting me, i will work on this and try sending the patch > soon with the mentioned changes. > > On Sun, Jul 20, 2008 at 12:05 AM, Daniel Stone <[EMAIL PROTECTED]> > wrote: > >> On Sat, Jul 19, 2008 at 11:16:58PM +0530, nagaraj s k wrote: >> > @@ -69,7 +69,7 @@ void *drm_realloc(void *oldpt, size_t ol >> > { >> > void *pt; >> > >> > -if (!(pt = kmalloc(size, GFP_KERNEL))) >> > +if (!(pt == kmalloc(size, GFP_KERNEL))) >> > return NULL; >> > if (oldpt && oldsize) { >> > memcpy(pt, oldpt, oldsize); >> >> Er, this is absolutely not an error. You'll note that pt is >> uninitialised, and the odds of a specific piece of uninitialised memory >> pointing to exactly the location kmalloc returns are ... rather low. >> >> It could be rewritten for clarity as: >> pt = kmalloc(size, GFP_KERNEL); >> if (!pt) >>return NULL; >> >> But your patch means the function can practically never actually work. >> >> Cheers, >> Daniel >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iEYEARECAAYFAkiCM9UACgkQUVYB1rKAgJROuwCeLTSHMG6JQsPYPM+uYHEuGv1L >> 8rMAn21162gICH7wp60D07yYo3PBVM3p >> =ZRpc >> -END PGP SIGNATURE- >> >> > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X "Hangs" with RS690 + 2.6.26
On Fri, 25 Jul 2008 10:43:34 +0100 Jonathan McDowell <[EMAIL PROTECTED]> wrote: > Hi. > > I've started to see "hangs" with X on an ATI RS690 with a 2.6.26 kernel. > The symptoms are that load average goes up, X stops accepting keypresses > or mouse clicks, but the cursor still moves around the screen in > response to the mouse being moved. I can't switch to a VT but can ssh in > remotely to see that things are still running. I don't seem to be able > to kill X but "shutdown -r now" cleanly reboots. > > gdb fails to attach - complains about an internal error. strace shows > lots of ioctls against the DRM device all returning EBUSY. > > 2.6.25 appears to work fine. I originally had PAT enabled under 2.6.26 > but have seen a patch fixing that go into git, so disabled it for my > 2.6.26 kernel to see if that was the issue; no change AFAICT. > > Enabling DRM debug (echo 1 > /sys/module/drm/parameters/debug) gives > lots of output from radeon_freelist_get, after the following ioctl is > received: > > Jul 25 10:11:14 meepok kernel: [drm:drm_ioctl] pid=3302, cmd=0xc0406429, > nr=0x29 , dev 0xe200, auth=1 > > and then a returning NULL message. > > radeon driver is recent git - 1c5858484da4fb1c9bc3ac3b4d7a97863ab99730 > but I've seen it with older revisions too. > > It can take a couple of days for me to hit the problem, so a git bisect > could be a lengthy process. If anyone has any suggestions about faster > ways to track down the issue I'd like to hear them. > > Machine is a dual core AMD64 with 4GB of RAM running Debian unstable, > card is: > > 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690 [Radeon > X1200 Series] [1002:791e] > > Kernel configs at: > > http://the.earth.li/~noodles/radeon-2.6.26-hang/config-2.6.25 > http://the.earth.li/~noodles/radeon-2.6.26-hang/config-2.6.26 > > Debug log from enabling drm debug: > > http://the.earth.li/~noodles/radeon-2.6.26-hang/debug > > Full dmesg (no obvious errors): > > http://the.earth.li/~noodles/radeon-2.6.26-hang/meepok.dmesg > > Xorg log file (no obvious errors): > > http://the.earth.li/~noodles/radeon-2.6.26-hang/Xorg.0.log > > J. > This looks like usual engine lockup followed by CP lockup so that DMA buffer age never get written and we run out of DMA buffer thus freelist failing in infinite loop. I think we now know all the reason why we lockup, while a fix could be made for old ioctl we believe the best plan is to work on new ioctl with this fix in mind. So i don't think a bisect will help, there is certainly somethings that made this lockup more probable to happen on your config but best things is to fix lockup. If you really got time you can still do bisect and find out what makes this lockups more obvious on your config this could be helpfull to check that our theories are goods. Cheers, Jerome Glisse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X "Hangs" with RS690 + 2.6.26
> I've started to see "hangs" with X on an ATI RS690 with a 2.6.26 kernel. > The symptoms are that load average goes up, X stops accepting keypresses > or mouse clicks, but the cursor still moves around the screen in > response to the mouse being moved. I can't switch to a VT but can ssh in > remotely to see that things are still running. I don't seem to be able > to kill X but "shutdown -r now" cleanly reboots. > > radeon driver is recent git - 1c5858484da4fb1c9bc3ac3b4d7a97863ab99730 > but I've seen it with older revisions too. > > It can take a couple of days for me to hit the problem, so a git bisect > could be a lengthy process. If anyone has any suggestions about faster > ways to track down the issue I'd like to hear them. git log v2.6.25..v2.6.26 drivers/char/drm 5e35eff13f7dd0f5c1d82b3b4708b2f7a5f44113 5cfb6956073a9e42d44a26790b7800980634d037 d396db321bcaec54345e7e9e87cea8482d6ae3a8 259434acccbc823ee8bc00b2d2689d25e1fd d7463eb41d88a39de2653fd41857c4ccddb8707b 45e519052e8f583a709edd442a23f59581d3fe42 2735977b12cb0f113aae24afff04747b6d0f5bf1 3722bfc607d46275369865c02fe8694486d640b5 fa0d71b967506031f7cb08ced6095d1c4f988594 9f18409ea3d778a171a9505c0a849d846f352bd0 not sure if you wanna try reverting some of those and seeing which is the cause maybe.. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick schrieb: > 2. Decompressing textures for software fallbacks. As far as I'm aware, > all of the drivers still have some software fallbacks, so this support > is still required. > This decompression could be done by the hardware: Ortho projection, nearest-neighbour filtering, render a textured quad, read back from the buffer, use it in the software fallbacks. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJpLcACgkQbtUV+xsoLppYzwCdEsuuq8zA0JzhOiLdN9YEB/yX 0NUAn0kz0hX7Aso+g5K4hk5vTUEhtERi =ixX+ -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
X "Hangs" with RS690 + 2.6.26
Hi. I've started to see "hangs" with X on an ATI RS690 with a 2.6.26 kernel. The symptoms are that load average goes up, X stops accepting keypresses or mouse clicks, but the cursor still moves around the screen in response to the mouse being moved. I can't switch to a VT but can ssh in remotely to see that things are still running. I don't seem to be able to kill X but "shutdown -r now" cleanly reboots. gdb fails to attach - complains about an internal error. strace shows lots of ioctls against the DRM device all returning EBUSY. 2.6.25 appears to work fine. I originally had PAT enabled under 2.6.26 but have seen a patch fixing that go into git, so disabled it for my 2.6.26 kernel to see if that was the issue; no change AFAICT. Enabling DRM debug (echo 1 > /sys/module/drm/parameters/debug) gives lots of output from radeon_freelist_get, after the following ioctl is received: Jul 25 10:11:14 meepok kernel: [drm:drm_ioctl] pid=3302, cmd=0xc0406429, nr=0x29 , dev 0xe200, auth=1 and then a returning NULL message. radeon driver is recent git - 1c5858484da4fb1c9bc3ac3b4d7a97863ab99730 but I've seen it with older revisions too. It can take a couple of days for me to hit the problem, so a git bisect could be a lengthy process. If anyone has any suggestions about faster ways to track down the issue I'd like to hear them. Machine is a dual core AMD64 with 4GB of RAM running Debian unstable, card is: 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690 [Radeon X1200 Series] [1002:791e] Kernel configs at: http://the.earth.li/~noodles/radeon-2.6.26-hang/config-2.6.25 http://the.earth.li/~noodles/radeon-2.6.26-hang/config-2.6.26 Debug log from enabling drm debug: http://the.earth.li/~noodles/radeon-2.6.26-hang/debug Full dmesg (no obvious errors): http://the.earth.li/~noodles/radeon-2.6.26-hang/meepok.dmesg Xorg log file (no obvious errors): http://the.earth.li/~noodles/radeon-2.6.26-hang/Xorg.0.log J. -- "I put it down to corrosive groin sweat myself." -- John Burnham, asr This .sig brought to you by the letter N and the number 39 Product of the Republic of HuggieTag - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1 repost #1] DRM: don't enable irqs in locking
On Fri, Jul 25, 2008 at 6:42 PM, Jiri Slaby <[EMAIL PROTECTED]> wrote: > drm_lock_take(); and drm_lock_free(); are called from > drm_locked_tasklet_func(); which disables interrupts when grabbing its > spinlock. > > Don't allow these locking functions to re-enable interrupts when > the tasklet expects them disabled. I.e. use spin_lock_irqsave instead of > spin_lock_bh (with their unlock opposites). Hmm this has bounced through 2-3 variations.. Thomas any ideas what the final correct answer is? Dave. > > We will get such a warnings otherwise: > [ cut here ] > WARNING: at kernel/softirq.c:136 local_bh_enable_ip+0x8b/0xb0() > Modules linked in: arc4 ecb crypto_blkcipher cryptomgr crypto_algapi ath5k > usbhid mac80211 ohci1394 hid led_class floppy cfg80211 ff_memless ieee1394 > rtc_cmos evdev [last unloaded: freq_table] > Pid: 0, comm: swapper Not tainted 2.6.26-rc8-mm1_64 #427 > > Call Trace: >[] warn_on_slowpath+0x5f/0x90 > [...] > [] local_bh_enable_ip+0x8b/0xb0 > [] _spin_unlock_bh+0xf/0x20 > [] drm_lock_take+0x81/0xe0 > [] drm_locked_tasklet_func+0x4b/0xb0 > [] tasklet_hi_action+0x69/0xf0 > [] __do_softirq+0x84/0xf0 > [stack snipped] > > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> > Cc: David Airlie <[EMAIL PROTECTED]> > --- > drivers/gpu/drm/drm_lock.c | 12 +++- > 1 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c > index 0998723..79943e4 100644 > --- a/drivers/gpu/drm/drm_lock.c > +++ b/drivers/gpu/drm/drm_lock.c > @@ -196,10 +196,11 @@ int drm_unlock(struct drm_device *dev, void *data, > struct drm_file *file_priv) > int drm_lock_take(struct drm_lock_data *lock_data, > unsigned int context) > { > + unsigned long flags; >unsigned int old, new, prev; >volatile unsigned int *lock = &lock_data->hw_lock->lock; > > - spin_lock_bh(&lock_data->spinlock); > + spin_lock_irqsave(&lock_data->spinlock, flags); >do { >old = *lock; >if (old & _DRM_LOCK_HELD) > @@ -211,7 +212,7 @@ int drm_lock_take(struct drm_lock_data *lock_data, >} >prev = cmpxchg(lock, old, new); >} while (prev != old); > - spin_unlock_bh(&lock_data->spinlock); > + spin_unlock_irqrestore(&lock_data->spinlock, flags); > >if (_DRM_LOCKING_CONTEXT(old) == context) { >if (old & _DRM_LOCK_HELD) { > @@ -270,17 +271,18 @@ static int drm_lock_transfer(struct drm_lock_data > *lock_data, > */ > int drm_lock_free(struct drm_lock_data *lock_data, unsigned int context) > { > + unsigned long flags; >unsigned int old, new, prev; >volatile unsigned int *lock = &lock_data->hw_lock->lock; > > - spin_lock_bh(&lock_data->spinlock); > + spin_lock_irqsave(&lock_data->spinlock, flags); >if (lock_data->kernel_waiters != 0) { >drm_lock_transfer(lock_data, 0); >lock_data->idle_has_lock = 1; > - spin_unlock_bh(&lock_data->spinlock); > + spin_unlock_irqrestore(&lock_data->spinlock, flags); >return 1; >} > - spin_unlock_bh(&lock_data->spinlock); > + spin_unlock_irqrestore(&lock_data->spinlock, flags); > >do { >old = *lock; > -- > 1.5.6.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/1 repost #1] DRM: don't enable irqs in locking
drm_lock_take(); and drm_lock_free(); are called from drm_locked_tasklet_func(); which disables interrupts when grabbing its spinlock. Don't allow these locking functions to re-enable interrupts when the tasklet expects them disabled. I.e. use spin_lock_irqsave instead of spin_lock_bh (with their unlock opposites). We will get such a warnings otherwise: [ cut here ] WARNING: at kernel/softirq.c:136 local_bh_enable_ip+0x8b/0xb0() Modules linked in: arc4 ecb crypto_blkcipher cryptomgr crypto_algapi ath5k usbhid mac80211 ohci1394 hid led_class floppy cfg80211 ff_memless ieee1394 rtc_cmos evdev [last unloaded: freq_table] Pid: 0, comm: swapper Not tainted 2.6.26-rc8-mm1_64 #427 Call Trace: [] warn_on_slowpath+0x5f/0x90 [...] [] local_bh_enable_ip+0x8b/0xb0 [] _spin_unlock_bh+0xf/0x20 [] drm_lock_take+0x81/0xe0 [] drm_locked_tasklet_func+0x4b/0xb0 [] tasklet_hi_action+0x69/0xf0 [] __do_softirq+0x84/0xf0 [stack snipped] Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> Cc: David Airlie <[EMAIL PROTECTED]> --- drivers/gpu/drm/drm_lock.c | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c index 0998723..79943e4 100644 --- a/drivers/gpu/drm/drm_lock.c +++ b/drivers/gpu/drm/drm_lock.c @@ -196,10 +196,11 @@ int drm_unlock(struct drm_device *dev, void *data, struct drm_file *file_priv) int drm_lock_take(struct drm_lock_data *lock_data, unsigned int context) { + unsigned long flags; unsigned int old, new, prev; volatile unsigned int *lock = &lock_data->hw_lock->lock; - spin_lock_bh(&lock_data->spinlock); + spin_lock_irqsave(&lock_data->spinlock, flags); do { old = *lock; if (old & _DRM_LOCK_HELD) @@ -211,7 +212,7 @@ int drm_lock_take(struct drm_lock_data *lock_data, } prev = cmpxchg(lock, old, new); } while (prev != old); - spin_unlock_bh(&lock_data->spinlock); + spin_unlock_irqrestore(&lock_data->spinlock, flags); if (_DRM_LOCKING_CONTEXT(old) == context) { if (old & _DRM_LOCK_HELD) { @@ -270,17 +271,18 @@ static int drm_lock_transfer(struct drm_lock_data *lock_data, */ int drm_lock_free(struct drm_lock_data *lock_data, unsigned int context) { + unsigned long flags; unsigned int old, new, prev; volatile unsigned int *lock = &lock_data->hw_lock->lock; - spin_lock_bh(&lock_data->spinlock); + spin_lock_irqsave(&lock_data->spinlock, flags); if (lock_data->kernel_waiters != 0) { drm_lock_transfer(lock_data, 0); lock_data->idle_has_lock = 1; - spin_unlock_bh(&lock_data->spinlock); + spin_unlock_irqrestore(&lock_data->spinlock, flags); return 1; } - spin_unlock_bh(&lock_data->spinlock); + spin_unlock_irqrestore(&lock_data->spinlock, flags); do { old = *lock; -- 1.5.6.2 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel