Re: [PATCH 1/2] Remove Intel drivers from linux-core
On Sat, Feb 14, 2009 at 11:24:18PM +0200, Pekka Paalanen wrote: From 29d3f6e9c1258736c3199834b293b8128faef2ad Mon Sep 17 00:00:00 2001 From: Pekka Paalanen p...@iki.fi Date: Sat, 14 Feb 2009 21:49:08 +0200 Subject: [PATCH] Remove Intel drivers from linux-core Both i810 and i915 DRM Linux kernel specific sources are removed. Intel developers have stated, that their DRM development continues elsewhere in some Linux kernel trees. This makes the code in drm.git just dead weight. This removal allows further cleanup of compatibility code. shared-core and bsd-core are left untouched. Personally i'd also kill bsd-core, since it's outdates and contains so much shit we don't want. Then again Robert may have something to say bout this. -0- -- who is still slacking on getting a fd.o account. -- I brake for chezlogs! -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing nv from drm git
On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote: Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Please do. I'm wondering if we should prune i915 now that it's not developed in drm.git anymore. -0- -- Now is the time for all good men to come to. -- Walt Kelly -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Intel DDX pageflipping code removal
[ the first iteration of this mail appears to have vanished, so here's a
resend ]
Hi,
The following patch series removes the pageflipping infrastructure from
the Intel DDX, since it has been deprecated and broken for quite some
time. Some build fixes for non-linux and one bugfix are also attached.
The equvalent patch for mesa should be going out just after this.
jbarnes has had a look at these, but some more eyes would be nice. I'd
like this to get in before 2.6 is released (preferably as part of that
release).
Patch series is attached since i'm having some perl-module problems here
which break git send-email
Any comments? If no problems could someone push it for me
Cheers,
-0-
--
Why is the alphabet in that order? Is it because of that song?
-- Stephen Wright
From 9792c20e6de544cea7232c41a8ec4c88aef671ab Mon Sep 17 00:00:00 2001
From: Owain G. Ainsworth o...@openbsd.org
Date: Tue, 13 Jan 2009 17:02:59 +
Subject: [PATCH] use ifdef __linux__ where needed.
since modesetting is compiled by default now, ifdef __linux__ the linux
only includes and ioctls.
---
src/i830_driver.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index 3e27b07..1ddea00 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -1228,7 +1228,9 @@ i830SetHotkeyControl(ScrnInfoPtr pScrn, int mode)
* DRM mode setting Linux only at this point... later on we could
* add a wrapper here.
*/
+#ifdef __linux__
#include linux/kd.h
+#endif
static Bool i830_kernel_mode_enabled(ScrnInfoPtr pScrn)
{
@@ -1254,7 +1256,9 @@ static Bool i830_kernel_mode_enabled(ScrnInfoPtr pScrn)
if (ret)
return FALSE;
+#ifdef __linux__
ioctl(xf86Info.consoleFd, KDSETMODE, KD_TEXT);
+#endif
return TRUE;
}
--
1.6.0.5
From e9860d4fc088bb78fd684d9996ef9185b647a1b4 Mon Sep 17 00:00:00 2001
From: Owain G. Ainsworth o...@openbsd.org
Date: Tue, 13 Jan 2009 17:09:00 +
Subject: [PATCH] Remove triple-buffering support
It never worked with any upstream linux kernel, and is quite heavily
deprecated. A new solution based around DRI2 will probably be
forthcoming. Pageflipping itself is next.
---
man/intel.man | 15 +--
src/i830.h|2 --
src/i830_accel.c |5 -
src/i830_dri.c| 32 +---
src/i830_driver.c |8
src/i830_memory.c | 11 ---
src/i830_xaa.c|6 --
7 files changed, 6 insertions(+), 73 deletions(-)
diff --git a/man/intel.man b/man/intel.man
index 00aa1be..2359624 100644
--- a/man/intel.man
+++ b/man/intel.man
@@ -153,23 +153,10 @@ Default for i810: this option is not used.
.BI Option \*qPageFlip\*q \*q boolean \*q
Enable support for page flipping. This should improve 3D performance at the
potential cost of worse performance with mixed 2D/3D. Also note that this gives
-no benefit without corresponding support in the Mesa 3D driver and may not give
-the full benefit without triple buffering (see
-.B Option \*qTripleBuffer\*q
-).
+no benefit without corresponding support in the Mesa 3D driver
Default for i810: The option is not used.
Default for i830 and above: Disabled (This option is currently unstable).
.TP
-.BI Option \*qTripleBuffer\*q \*q boolean \*q
-Enable support for triple buffering. This should improve 3D performance at the
-potential cost of worse performance with mixed 2D/3D. Also note that this gives
-no benefit without corresponding support in the Mesa 3D driver and may not give
-any benefit without page flipping either (see
-.B Option \*qPageFlip\*q
-).
-Default for i810: The option is not used.
-Default for i830 and above: Disabled.
-.TP
.BI Option \*qAccelMethod\*q \*q string \*q
Choose acceleration architecture, either XAA or EXA. XAA is the old
XFree86 based acceleration architecture. EXA is a newer and simpler
diff --git a/src/i830.h b/src/i830.h
index 25bf482..94bcce7 100644
--- a/src/i830.h
+++ b/src/i830.h
@@ -461,7 +461,6 @@ typedef struct _I830Rec {
#ifdef XF86DRI
i830_memory *back_buffer;
- i830_memory *third_buffer;
i830_memory *depth_buffer;
i830_memory *textures; /** Compatibility texture memory */
i830_memory *memory_manager;/** DRI memory manager
aperture */
@@ -484,7 +483,6 @@ typedef struct _I830Rec {
Bool NeedRingBufferLow;
Bool allowPageFlip;
- Bool TripleBuffer;
Bool tiling;
Bool fb_compression;
diff --git a/src/i830_accel.c b/src/i830_accel.c
index 7dff714..1c8b7aa 100644
--- a/src/i830_accel.c
+++ b/src/i830_accel.c
@@ -255,11 +255,6 @@ I830SelectBuffer(ScrnInfoPtr pScrn, int buffer)
if (pI830-back_buffer-tiling == TILE_YMAJOR)
return FALSE;
break;
- case I830_SELECT_THIRD:
- pI830-bufferOffset = pI830-third_buffer-offset;
- if (pI830-third_buffer-tiling == TILE_YMAJOR)
-return FALSE;
- break;
case I830_SELECT_DEPTH:
pI830-bufferOffset =
[PATCH] Remove drmModeReplaceFb after it was removed from the kernel.
Probably should bump major after this, since it made it to a release.
From 14558d90eb615c729f88ea54cae636df2ee90dfa Mon Sep 17 00:00:00 2001
From: Owain G. Ainsworth o...@openbsd.org
Date: Sun, 11 Jan 2009 19:02:07 +
Subject: [PATCH] Remove drmModeReplaceFb after it was removed from the kernel.
It is impossible to replace the original semantics of this call purely
in userland, since the fb_id would change.
after discussion with Dr_Jakob
Signed-Off-By: Owain Ainsworth o...@openbsd.org
---
libdrm/xf86drmMode.c | 21 -
libdrm/xf86drmMode.h |7 ---
2 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index f481428..6ec7d59 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -628,27 +628,6 @@ int drmCheckModesettingSupported(const char *busid)
}
-int drmModeReplaceFB(int fd, uint32_t buffer_id,
-uint32_t width, uint32_t height, uint8_t depth,
-uint8_t bpp, uint32_t pitch, uint32_t bo_handle)
-{
- struct drm_mode_fb_cmd f;
- int ret;
-
- f.width = width;
- f.height = height;
- f.pitch = pitch;
- f.bpp = bpp;
- f.depth = depth;
- f.handle = bo_handle;
- f.fb_id = buffer_id;
-
- if ((ret = drmIoctl(fd, DRM_IOCTL_MODE_REPLACEFB, f)))
- return ret;
-
- return 0;
-}
-
int drmModeCrtcGetGamma(int fd, uint32_t crtc_id, uint32_t size,
uint16_t *red, uint16_t *green, uint16_t *blue)
{
diff --git a/libdrm/xf86drmMode.h b/libdrm/xf86drmMode.h
index 965b7be..378afe4 100644
--- a/libdrm/xf86drmMode.h
+++ b/libdrm/xf86drmMode.h
@@ -180,13 +180,6 @@ extern int drmModeAddFB(int fd, uint32_t width, uint32_t
height, uint8_t depth,
*/
extern int drmModeRmFB(int fd, uint32_t bufferId);
-/**
- * Replace a framebuffer object with a new one - for resizing the screen.
- */
-extern int drmModeReplaceFB(int fd, uint32_t buffer_id,
- uint32_t width, uint32_t height, uint8_t depth,
- uint8_t bpp, uint32_t pitch, uint32_t bo_handle);
-
/*
* Crtc functions
*/
--
1.6.0.5
--
She liked him; he was a man of many qualities, even if most of them
were bad.
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: Remove racy delayed vblank swap ioctl.
On Tue, Nov 04, 2008 at 12:54:03PM -0800, Eric Anholt wrote: When userland detected that this ioctl was supported (by version number check), it used it in a racy way -- dispatch delayed swap, wait for vblank, continue rendering. As there was no mechanism for it to wait for the swap to finish, sometimes it would render before the swap and garbage would be displayed on the screen. Oh my yes... I've been seein that a lot on openbsd. The drm_lock latency with userland was quite high, so I would see stuff being half drawn (this was shown by flickering in glxgears, and things like quake having enemies and items flickering in and out of view) I've been trying to fix that, but mostly been considering just removing the interface. Nice to see i'm not alone :) By removing the ioctl and returning -EINVAL, userland returns to its previous, correct rendering path of waiting for a vblank then dispatching a swap. The only path that could have used this ioctl correctly was page flipping, which relied on only one client running and emitting wait-for-vblank-before-rendering in the command stream. That path also falls back correctly, at the performance cost of not being able to queue up rendering before the flip occurs. I agree. And the patch looks correct. However, there's more stuff that can go away here: - dev_priv-swaps_lock (and spinlock_init/destroy) - dev_priv-pending_swaps (and initialisation) - dev_priv-vbl_swaps (and initialisation) - the definition of vbl_swap_t - the tasklet interface and assorted locking and function pointers. - Nothing in drm git or the linux kernel would use it after this change. making it dead code. the less stuff clogging up the source and making it harder to read the better. Otherwise, looks fine. A similar diff running on openbsd seems to work well. Cheers, -0- -- Utility is when you have one telephone, luxury is when you have two, opulence is when you have three -- and paradise is when you have none. -- Doug Larson - 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=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: Remove racy delayed vblank swap ioctl.
On Tue, Nov 04, 2008 at 06:46:09PM -0800, Eric Anholt wrote: When userland detected that this ioctl was supported (by version number check), it used it in a racy way -- dispatch delayed swap, wait for vblank, continue rendering. As there was no mechanism for it to wait for the swap to finish, sometimes it would render before the swap and garbage would be displayed on the screen. By removing the ioctl and returning -EINVAL, userland returns to its previous, correct rendering path of waiting for a vblank then dispatching a swap. The only path that could have used this ioctl correctly was page flipping, which relied on only one client running and emitting wait-for-vblank-before-rendering in the command stream. That path also falls back correctly, at the performance cost of not being able to queue up rendering before the flip occurs. Much better! This and the tasklet removal diff look pretty much the same as I came up with on ``that other os''. All fine by me. -- Larkinson's Law: All laws are basically false. - 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=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1] Adapt on_each_cpu
On Thu, Aug 07, 2008 at 04:08:49PM -0700, Eric Anholt wrote: a) BSD I'd like to hear Robert's concerns here, but I've been working with some of the BSD folks lately, and it seems like the main concerns are: 1) making it easy for contributors to identify which portions of code are shared 2) licensing Since both the BSDs and Linux effectively copy code out of the DRM repo and into their respective kernel trees at this point, having the actual repo based on one of them shouldn't be an issue as long as both 1 and 2 are handled. The remaining compat macros could probably just be wrapped in some sort of Linux equivalent (DRM_SPINUNLOCK-spin_unlock, what's the difference?), or we could annotate things for the BSD guys to run scripts over. As it stands, they still have to go over things by hand anyway... As an ex-BSD kernel maintainer, I stood against moving to a linux kernel-based tree for a long time. For a long time I felt like I was the only guy holding back the move. I couldn't get NetBSD to work in the upstream tree, and it sounds like OpenBSD's following the same route, so maybe I was doing it wrong all along in trying to have one tree for all OSes to share. As the OpenBSD maintainer it's probably time I mention my reasons for working out of tree. It's quite simple really, In my experience of porting over the code, I found that the BSDs, while similar, are no where near identical, and in the end the level of #ifdefing in the bsd-core area just got insane, it made maintainance a nightmare. So I started working out of tree. If i find a general bug, I reformat against git and send the patch upstream. Otherwise, I watch what happens to git and merge it into my kernel tree along with any OpenBSD specific changes i've needed. This is more like the way the BSDs have shared code for a while now. I know myself and Robert differ on our opinions here, though. I find it better to be able to go over things by hand, it means I better understand what I'm merging, anyway. For that reason, i'm not against master going to a linux kernel tree, since it would change my process very minimally. As long as the licensing doesn't change (IMHO drm is essentially a part of X, and thus should be X11/MIT licensed), I'm fine with it. Process-wise, I'm in agreement with Dave Airlie, that master should track what's in linus' tree, with the rest on branches. Also, I think vblank-rework is now stable enough to go upstream, i've found it has started to work quite nicely. Just my 2p, -0- -- There's no easy quick way out, we're gonna have to live through our whole lives, win, lose, or draw. -- Walt Kelly - 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=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] BSD: drm_locked_task may sleep in an interrupt handler, fix
that.
Reply-To:
Hi,
I just commited a similar fix for this to OpenBSD. Sleeping in interrupt
handlers is bad. just do the same a the linux code does and flag the
handler to be dealt with on unlock.
I don't have a freebsd machine around, so I don't know if this even
compiles, but the general method has been tested and proven to be sound.
Cheers,
-0-
--
Distinctive, adj.:
A different color or shape than our competitors.
From 6ae185635d7fcc971dafe2e6e6624efde183c9eb Mon Sep 17 00:00:00 2001
From: Owain Gordon Ainsworth [EMAIL PROTECTED]
Date: Mon, 7 Jul 2008 17:23:48 +0100
Subject: [PATCH] BSD: change drm_locked_task*() to use the same scheme as linux.
The current code can sleep in an interrupt handler, that is bad. So
instead if we can't grab the lock, flag it and run the tasklet on
unlock.
---
bsd-core/drmP.h |1 +
bsd-core/drm_drv.c |1 +
bsd-core/drm_irq.c | 45 +++--
bsd-core/drm_lock.c |7 +++
4 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/bsd-core/drmP.h b/bsd-core/drmP.h
index 88ea4e6..65d7fae 100644
--- a/bsd-core/drmP.h
+++ b/bsd-core/drmP.h
@@ -739,6 +739,7 @@ struct drm_device {
struct mtxdev_lock; /* protects everything else */
#endif
DRM_SPINTYPE drw_lock;
+ DRM_SPINTYPE tsk_lock;
/* Usage Counters */
int open_count; /* Outstanding files open */
diff --git a/bsd-core/drm_drv.c b/bsd-core/drm_drv.c
index 740a8b5..9bd6079 100644
--- a/bsd-core/drm_drv.c
+++ b/bsd-core/drm_drv.c
@@ -206,6 +206,7 @@ int drm_attach(device_t nbdev, drm_pci_id_list_t *idlist)
mtx_init(dev-irq_lock, drmirq, NULL, MTX_DEF);
mtx_init(dev-vbl_lock, drmvbl, NULL, MTX_DEF);
mtx_init(dev-drw_lock, drmdrw, NULL, MTX_DEF);
+ mtx_init(dev-tsk_lock, drmtsk, NULL, MTX_DEF);
#endif
id_entry = drm_find_description(pci_get_vendor(dev-device),
diff --git a/bsd-core/drm_irq.c b/bsd-core/drm_irq.c
index c3ecd28..d0c3d69 100644
--- a/bsd-core/drm_irq.c
+++ b/bsd-core/drm_irq.c
@@ -578,41 +578,42 @@ static void drm_locked_task(void *context, int pending
__unused)
{
struct drm_device *dev = context;
- DRM_LOCK();
- for (;;) {
- int ret;
-
- if (drm_lock_take(dev-lock.hw_lock-lock,
- DRM_KERNEL_CONTEXT))
- {
- dev-lock.file_priv = NULL; /* kernel owned */
- dev-lock.lock_time = jiffies;
- atomic_inc(dev-counts[_DRM_STAT_LOCKS]);
- break; /* Got lock */
- }
+ DRM_SPINLOCK(dev-tsk_lock);
- /* Contention */
-#if defined(__FreeBSD__) __FreeBSD_version 50
- ret = mtx_sleep((void *)dev-lock.lock_queue, dev-dev_lock,
- PZERO | PCATCH, drmlk2, 0);
-#else
- ret = tsleep((void *)dev-lock.lock_queue, PZERO | PCATCH,
- drmlk2, 0);
-#endif
- if (ret != 0)
- return;
+ DRM_LOCK(); /* XXX drm_lock_take() should do it's own locking */
+ if (dev-locked_task_call == NULL ||
+ drm_lock_take(dev-lock.hw_lock-lock, DRM_KERNEL_CONTEXT) == 0) {
+ DRM_UNLOCK();
+ DRM_SPINUNLOCK(dev-tsk_lock);
+ return;
}
+
+ dev-lock.file_priv = NULL; /* kernel owned */
+ dev-lock.lock_time = jiffies;
+ atomic_inc(dev-counts[_DRM_STAT_LOCKS]);
+
DRM_UNLOCK();
dev-locked_task_call(dev);
drm_lock_free(dev, dev-lock.hw_lock-lock, DRM_KERNEL_CONTEXT);
+
+ dev-locked_task_call == NULL;
+
+ DRM_SPINUNLOCK(dev-tsk_lock);
}
void
drm_locked_tasklet(struct drm_device *dev,
void (*tasklet)(struct drm_device *dev))
{
+ DRM_SPINLOCK(dev-tsk_lock);
+ if (dev-locked_task_call != NULL) {
+ DRM_SPINUNLOCK(dev-tsk_lock);
+ return;
+ }
+
dev-locked_task_call = tasklet;
+ DRM_SPINUNLOCK(dev-tsk_lock);
taskqueue_enqueue(taskqueue_swi, dev-locked_task);
}
diff --git a/bsd-core/drm_lock.c b/bsd-core/drm_lock.c
index 9101dec..80ebb71 100644
--- a/bsd-core/drm_lock.c
+++ b/bsd-core/drm_lock.c
@@ -180,6 +180,13 @@ int drm_unlock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
_DRM_LOCKING_CONTEXT(dev-lock.hw_lock-lock) != lock-context)
return EINVAL;
+ DRM_SPINLOCK(dev-tsk_lock);
+ if (dev-locked_task_call != NULL) {
+ dev-locked_task_call(dev);
+ dev-locked_task_call = NULL;
+ }
+ DRM_SPINUNLOCK(dev-tsk_lock);
+
atomic_inc(dev-counts[_DRM_STAT_UNLOCKS]);
DRM_LOCK();
--
1.5.5.2
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
[PATCH] The DRM and the bsds.
Hi guys,
By means of introduction: I'm the guy attempting to port the DRM so that
it'll run on OpenBSD. So far things are going fairly well (I don't know
how many hours i've sunk into this though). The code isn't all in our
cvs tree since it's currently locked for release. In fact the difference
between the cvs tree and what i'm using locally is rather large.
However, I thought it was about time i started sending patches back
(i've been putting it off since things weren't 100%). As a first patch,
this fixes the freebsd codepath a bit by removing some deadlocks, the
functions affected only touch the lock on a few of their exit points,
this makes sure that the lock is dealt with properly on all of them.
This isn't tested on freebsd (I don't have a system running it), also
the current drm tree wouldn't compile on freebsd since the vblank
changes I'm debugging some patches to fix that, too. Patch is attached
inline after the rest of this mail.
For anyone interested, here's the current status of DRI on openbsd:
- SiS apparently works (i've not heard from the guy testing it for a while
though).
- 965 (G965 and GM965) is mostly ok, but there are a few instabilities
(the hardware registers get out of sync and X crashes). There's
obviously a deadlock there also, since also sometimes things get
utterly buggered and X locks up trying to get the hardware lock (the
mouse moves, but all events get dropped as being out of order). Both of
these can be triggered by multiple renderers, and moving the application
around a lot.
However, it works well enough to things like glxgears to work most of
the time, and i've spent several hours playing quake2 in gl mode without
problems. Also glxgears intermittenly segfaults at startup (in memcpy
from realloc from emit_op3fn. I can provide backtraces to anyone who
wants it).
- some other intels work.
- r200 works when forced to pci mode. In agp mode it loops in
wait_for_cp_idle on X startup. I've not tested this in a while, but that
certainly seems to be the case most times.
- radeon (r100), starts but i'm told glxgears always crashes (in
choose_emit_func) every time. as with other glx apps. Again this was
pci-mode.
- r300 seems to work well so far, I've an PCIE X800SE that i've not been
able to crash yet. However I only started playing with it recently and
haven't tried anything heavy on it yet.
I haven't even started on the TTM yet, but it's on my todo list.
Regards,
Owain
([EMAIL PROTECTED])
--
The goal of science is to build better mousetraps.
The goal of nature is to build better mice.
From 427430ef790f80431f372d0340c7c710c8bee1ae Mon Sep 17 00:00:00 2001
From: Owain Ainsworth [EMAIL PROTECTED]
Date: Thu, 6 Mar 2008 17:52:27 +
Subject: [PATCH] Fix up some locking issues in the bsd port. Kill some
deadlocks.
drm_add_magic:
remove superfluous locking calls (some bsds mutexes aren't
recursive. we already call it locked.
drm_bufs.c:
drm_addmap: we start the function call locked. make sure we leave it
locked. While i'm here deal with failed ioremap();
addbufs_*: make sure that we restore locking to what's expected upon
return.
drm_drawable.c:
prevent freeing NULL (i've seen this happen), in drm_update_draw, also
add an unlock before one of the return conditions.
drm_vm.c
make sure that we unlock before return. but remove one locking call that
never will be reached.
---
bsd-core/drm_auth.c |2 --
bsd-core/drm_bufs.c | 47 +--
bsd-core/drm_drawable.c | 12
bsd-core/drm_vm.c |3 +--
4 files changed, 46 insertions(+), 18 deletions(-)
diff --git a/bsd-core/drm_auth.c b/bsd-core/drm_auth.c
index aa8238c..fdc2d77 100644
--- a/bsd-core/drm_auth.c
+++ b/bsd-core/drm_auth.c
@@ -79,7 +79,6 @@ static int drm_add_magic(drm_device_t *dev, drm_file_t *priv,
drm_magic_t magic)
entry-priv = priv;
entry-next = NULL;
- DRM_LOCK();
if (dev-magiclist[hash].tail) {
dev-magiclist[hash].tail-next = entry;
dev-magiclist[hash].tail = entry;
@@ -87,7 +86,6 @@ static int drm_add_magic(drm_device_t *dev, drm_file_t *priv,
drm_magic_t magic)
dev-magiclist[hash].head = entry;
dev-magiclist[hash].tail = entry;
}
- DRM_UNLOCK();
return 0;
}
diff --git a/bsd-core/drm_bufs.c b/bsd-core/drm_bufs.c
index 9b58c59..b72b9c1 100644
--- a/bsd-core/drm_bufs.c
+++ b/bsd-core/drm_bufs.c
@@ -149,8 +149,10 @@ int drm_addmap(drm_device_t * dev, unsigned long offset,
unsigned long size,
* initialization necessary.
*/
map = malloc(sizeof(*map), M_DRM, M_ZERO | M_NOWAIT);
- if ( !map )
+ if ( !map ) {
+ DRM_LOCK();
return ENOMEM;
+ }
map-offset = offset;
map-size = size;
@@ -160,6 +162,10 @@ int drm_addmap(drm_device_t * dev
