[PATCH] install irq at load time
This is what I am testing on FreeBSD right now, to install the irq
handlers at load time. The linux side could do something like this
also. This approach doesn't change the assumptions of the drivers and
so doesn't require touching driver code.
robert.
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_drv.c b/bsd-core/drm_drv.c
index 9bd6079..57d293c 100644
--- a/bsd-core/drm_drv.c
+++ b/bsd-core/drm_drv.c
@@ -580,6 +580,14 @@ static int drm_load(struct drm_device *dev)
goto error;
}
+ if (dev-driver.use_irq) {
+ retcode = drm_irq_install(dev);
+ if (retcode != 0) {
+ DRM_ERROR(Couldn't setup irq\n);
+ goto error;
+ }
+ }
+
DRM_INFO(Initialized %s %d.%d.%d %s\n,
dev-driver.name,
dev-driver.major,
@@ -651,9 +659,14 @@ static void drm_unload(struct drm_device *dev)
dev-agp = NULL;
}
+ if (dev-driver.use_irq)
+ drm_irq_uninstall(dev);
+
if (dev-driver.unload != NULL)
dev-driver.unload(dev);
+ drm_vblank_cleanup(dev);
+
delete_unrhdr(dev-drw_unrhdr);
drm_mem_uninit();
diff --git a/bsd-core/drm_irq.c b/bsd-core/drm_irq.c
index 6e21d41..8febf5a 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,7 +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;
}
@@ -303,26 +302,15 @@ int drm_irq_uninstall(struct drm_device *dev)
int drm_control(struct drm_device *dev, void *data, struct drm_file *file_priv)
{
drm_control_t *ctl = data;
- int err;
switch ( ctl-func ) {
case DRM_INST_HANDLER:
- /* Handle drivers whose DRM used to require IRQ setup but the
- * no longer does.
- */
- if (!dev-driver.use_irq)
- return 0;
if (dev-if_version DRM_IF_VERSION(1, 2)
ctl-irq != dev-irq)
return EINVAL;
- return drm_irq_install(dev);
+ return 0;
case DRM_UNINST_HANDLER:
- if (!dev-driver.use_irq)
- return 0;
- DRM_LOCK();
- err = drm_irq_uninstall(dev);
- DRM_UNLOCK();
- return err;
+ return 0;
default:
return EINVAL;
}
-
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
nopfn removal in Linus's 2.6 tree
Hi everyone, In drm commit b44f2da380e78769b58c751e81f376f0fa1f48aa from May 7, Dave Airlie alludes to the fact that nopfn is going to eventually be removed from the kernel. I pulled and guilt today's git. It looks like that change has dropped. Linux kernel commit is 0d71d10a4252a3938e6b70189bc776171c02e076. Reverting that seems to work cleanly. Just a heads up, since I hit this build issue today! Thanks, Ross -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 - 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 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:
IRQ [8023813f] warn_on_slowpath+0x5f/0x90
[...]
[8023e1fb] local_bh_enable_ip+0x8b/0xb0
[8055b2cf] _spin_unlock_bh+0xf/0x20
[803b0bd1] drm_lock_take+0x81/0xe0
[803b006b] drm_locked_tasklet_func+0x4b/0xb0
[8023daf9] tasklet_hi_action+0x69/0xf0
[8023e3e4] __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=100url=/
--
___
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:
IRQ [8023813f] warn_on_slowpath+0x5f/0x90
[...]
[8023e1fb] local_bh_enable_ip+0x8b/0xb0
[8055b2cf] _spin_unlock_bh+0xf/0x20
[803b0bd1] drm_lock_take+0x81/0xe0
[803b006b] drm_locked_tasklet_func+0x4b/0xb0
[8023daf9] tasklet_hi_action+0x69/0xf0
[8023e3e4] __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=100url=/
--
___
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=100url=/ -- ___ 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=100url=/ -- ___ 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=100url=/ -- ___ 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=100url=/ -- ___ 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=100url=/--
___
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=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
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=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[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_handler(DRM_IRQ_ARGS);
extern
