Re: drm/radeon/r600: CS parser updates perhaps broke 3d
From: Alex Deucher alexdeuc...@gmail.com On Sun, Nov 15, 2009 at 4:30 PM, Mikko Vinni wrote: Commenting out the following line added by commit a39533b gives 3d back on this board. But is this a correct fix, or should I just try with newer userspace? I have something new enough to have working direct rendering but not new enough to support KMS on this radeon (Arch Linux's stable versions). Somebody asked about a similar-looking problem today on Arch Linux forums (http://bbs.archlinux.org/viewtopic.php?pid=656417, message #192). NACK. Update mesa. The fix is in the 7.6 and master branches. The driver needs to emit a reloc for that register and it isn't being used yet anyway. Updating seems to have cured the problem. I had some 7.6 version installed (7.6-2 of mesa and ati-dri and whatever packages Arch developers have split from the same source). The git version from master branch looks good so far. Thanks Mikko Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.32-rc7-git1: Reported regressions 2.6.30 - 2.6.31
On 11/16/2009 04:58 PM, Rafael J. Wysocki wrote: This message contains a list of some regressions introduced between 2.6.30 and 2.6.31, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14181 Subject : b43 causes panic at ifconfig down / shutdown Submitter : Jeremy Huddleston jerem...@freedesktop.org Date : 2009-09-15 18:34 (63 days old) This one is fixed by commit d50bae33d1358b909ade05ae121d83d3a60ab63f in mainline. The patch was also sent to stable. Larry -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21472] EnablePageFlip hangs the system with xpress 200M in 3d games
http://bugs.freedesktop.org/show_bug.cgi?id=21472 Fabio fabio@libero.it changed: What|Removed |Added CC||david.hag...@gmail.com --- Comment #2 from Fabio fabio@libero.it 2009-11-17 00:14:42 PST --- *** Bug 15019 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15019] Googleearth locks up radeon R300 card
http://bugs.freedesktop.org/show_bug.cgi?id=15019 Fabio fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #13 from Fabio fabio@libero.it 2009-11-17 00:14:42 PST --- (In reply to comment #12) Unfortunately, I no longer have the system that was showing the symptoms, so I can no longer test this bug. OK, there is anyway a similar bug for this problem. Marking as duplicate. *** This bug has been marked as a duplicate of bug 21472 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22195] app crashed to desktop with Radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=22195 --- Comment #10 from Fabio fabio@libero.it 2009-11-17 01:02:28 PST --- Can you try with Ubuntu 9.10? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14628] drm/ksm - s2disk - resume - [drm:r100_ring_test] *ERROR* radeon: ring test failed
http://bugzilla.kernel.org/show_bug.cgi?id=14628 Jérôme Glisse gli...@freedesktop.org changed: What|Removed |Added CC||gli...@freedesktop.org --- Comment #1 from Jérôme Glisse gli...@freedesktop.org 2009-11-17 09:05:14 --- I don't think we can call this a regression, KMS + AGP likely never worked properly on this particular platform. Nevertheless it's a bug. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25114] [R600] Nexuiz 2.5.2 crashes on demo5 (Silver City), errors on demo piece-o-cake too
http://bugs.freedesktop.org/show_bug.cgi?id=25114 --- Comment #3 from darkbasic darkbas...@gmail.com 2009-11-17 02:27:16 PST --- The patch solved the problem with Silver City, but the warnings in piece-o-cake still remains. Thank you, Darkbasic -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14628] drm/ksm - s2disk - resume - [drm:r100_ring_test] *ERROR* radeon: ring test failed
http://bugzilla.kernel.org/show_bug.cgi?id=14628 --- Comment #2 from Christian Hartmann corno...@googlemail.com 2009-11-17 10:27:12 --- Created an attachment (id=23813) -- (http://bugzilla.kernel.org/attachment.cgi?id=23813) lspci Linux oddysseus 2.6.32-rc7 #1 Mon Nov 16 16:24:25 CET 2009 i686 GNU/Linux lspci (after resume) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] New: touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 Summary: touhou 11/12 run very slow in wine Product: Mesa Version: 7.6 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: walkerallen...@googlemail.com The bug was already described in http://bugs.winehq.org/show_bug.cgi?id=18232 To reiterate: touhou 6-10 run fine in wine at full speed, but touhou 11/12 run very slow hogging X (80-90% for me in top). The hardware requirements for the games are very low so it shouldn't happen. system: archlinux 64bit 32bit wine 1.1.33 kernel 2.6.31.6 radeon X1550 mesa 7.6 xf86-video-ati 6.12.99.git20091014 As I don't know how to delve deeper into X I can't find out what is actually happening. But because it's a 3d 'heavy' game I fill the bugreport for now against mesa/radeon. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. thanks, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/17 Kristian Høgsberg k...@bitplanet.net: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. For the record, I don't think my concerns were adressed. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/17 Stephane Marchesin marche...@icps.u-strasbg.fr: 2009/11/17 Kristian Høgsberg k...@bitplanet.net: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. For the record, I don't think my concerns were adressed. You're right, of course. However, my libdrm proposal wasn't an attempt to change how we work, it was merely a re-organisation of the drm.git repo to better reflect and support the de facto workflow. Whether we want libdrm in the kernel tree or not is a different discussion from this, as I see it. It may or may not be a good idea, but I'd rather not block this clean up on that discussion ;-) cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/i915: Add page flipping ioctl
This adds a page flipping ioctl to the KMS API. The ioctl takes an fb ID
and a ctrc ID and flips the crtc to the given fb at the next vblank.
The ioctl returns immediately but the flip doesn't happen until after
any rendering that's currently queued up against the new framebuffer
is done. After submitting a page flip, any execbuffer involving the
old front buffer will block until the flip is completed.
Optionally, a vblank event can be generated when the swap eventually
happens.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/drm_crtc.c | 69
drivers/gpu/drm/drm_drv.c |1 +
include/drm/drm.h |1 +
include/drm/drm_crtc.h | 16 ++
include/drm/drm_mode.h | 33 +
5 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ee0cde1..ac2fa19 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2479,3 +2479,72 @@ out:
mutex_unlock(dev-mode_config.mutex);
return ret;
}
+
+int drm_mode_page_flip_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_crtc_page_flip *page_flip = data;
+ struct drm_mode_object *obj;
+ struct drm_crtc *crtc;
+ struct drm_framebuffer *fb;
+ struct drm_pending_vblank_event *e = NULL;
+ unsigned long flags;
+ int ret = -EINVAL;
+
+ if (page_flip-flags ~DRM_MODE_PAGE_FLIP_FLAGS ||
+ page_flip-reserved != 0)
+ return -EINVAL;
+
+ mutex_lock(dev-mode_config.mutex);
+ obj = drm_mode_object_find(dev, page_flip-crtc_id,
DRM_MODE_OBJECT_CRTC);
+ if (!obj)
+ goto out;
+ crtc = obj_to_crtc(obj);
+
+ if (crtc-funcs-page_flip == NULL)
+ goto out;
+
+ obj = drm_mode_object_find(dev, page_flip-fb_id, DRM_MODE_OBJECT_FB);
+ if (!obj)
+ goto out;
+ fb = obj_to_fb(obj);
+
+ if (page_flip-flags DRM_MODE_PAGE_FLIP_EVENT) {
+ ret = -ENOMEM;
+ spin_lock_irqsave(dev-event_lock, flags);
+ if (file_priv-event_space sizeof e-event) {
+ spin_unlock_irqrestore(dev-event_lock, flags);
+ goto out;
+ }
+ file_priv-event_space -= sizeof e-event;
+ spin_unlock_irqrestore(dev-event_lock, flags);
+
+ e = kzalloc(sizeof *e, GFP_KERNEL);
+ if (e == NULL) {
+ spin_lock_irqsave(dev-event_lock, flags);
+ file_priv-event_space += sizeof e-event;
+ spin_unlock_irqrestore(dev-event_lock, flags);
+ goto out;
+ }
+
+ e-event.base.type = DRM_EVENT_VBLANK;
+ e-event.base.length = sizeof e-event;
+ e-event.user_data = page_flip-user_data;
+ e-base.event = e-event.base;
+ e-base.file_priv = file_priv;
+ e-base.destroy =
+ (void (*) (struct drm_pending_event *)) kfree;
+ }
+
+ ret = crtc-funcs-page_flip(crtc, fb, e);
+ if (ret) {
+ spin_lock_irqsave(dev-event_lock, flags);
+ file_priv-event_space += sizeof e-event;
+ spin_unlock_irqrestore(dev-event_lock, flags);
+ kfree(e);
+ }
+
+out:
+ mutex_unlock(dev-mode_config.mutex);
+ return ret;
+}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a75ca63..672f473 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -145,6 +145,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/include/drm/drm.h b/include/drm/drm.h
index fa6d915..3919a4f 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -687,6 +687,7 @@ struct drm_gem_open {
#define DRM_IOCTL_MODE_GETFB DRM_IOWR(0xAD, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_ADDFB DRM_IOWR(0xAE, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_RMFBDRM_IOWR(0xAF, unsigned int)
+#define DRM_IOCTL_MODE_PAGE_FLIP DRM_IOWR(0xB0, struct
drm_mode_crtc_page_flip)
/**
* Device specific ioctls should only be in their respective headers
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfcc60d..8cf59fc 100644
--- a/include/drm/drm_crtc.h
[PATCH 2/2] Add intel implementation of the pageflip ioctl
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/i915_gem.c | 64 +-
drivers/gpu/drm/i915/i915_irq.c | 10 ++
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_display.c | 233 +-
drivers/gpu/drm/i915/intel_drv.h |3 +
6 files changed, 290 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 835625b..7c5b05e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -536,6 +536,10 @@ typedef struct drm_i915_private {
/* indicate whether the LVDS_BORDER should be enabled or not */
unsigned int lvds_border_bits;
+ struct drm_crtc *plane_to_crtc_mapping[2];
+ struct drm_crtc *pipe_to_crtc_mapping[2];
+ wait_queue_head_t pending_flip_queue;
+
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
@@ -635,6 +639,13 @@ struct drm_i915_gem_object {
* Advice: are the backing pages purgeable?
*/
int madv;
+
+ /**
+* Number of crtcs where this object is currently the fb, but
+* will be page flipped away on the next vblank. When it
+* reaches 0, dev_priv-pending_flip_queue will be woken up.
+*/
+ atomic_t pending_flip;
};
/**
@@ -826,6 +837,7 @@ void i915_gem_free_all_phys_object(struct drm_device *dev);
int i915_gem_object_get_pages(struct drm_gem_object *obj);
void i915_gem_object_put_pages(struct drm_gem_object *obj);
void i915_gem_release(struct drm_device * dev, struct drm_file *file_priv);
+void i915_gem_object_flush_write_domain(struct drm_gem_object *obj);
void i915_gem_shrinker_init(void);
void i915_gem_shrinker_exit(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2065b8f..22dd6c3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2771,6 +2771,22 @@ i915_gem_object_flush_cpu_write_domain(struct
drm_gem_object *obj)
old_write_domain);
}
+void
+i915_gem_object_flush_write_domain(struct drm_gem_object *obj)
+{
+ switch (obj-write_domain) {
+ case I915_GEM_DOMAIN_GTT:
+ i915_gem_object_flush_gtt_write_domain(obj);
+ break;
+ case I915_GEM_DOMAIN_CPU:
+ i915_gem_object_flush_cpu_write_domain(obj);
+ break;
+ default:
+ i915_gem_object_flush_gpu_write_domain(obj);
+ break;
+ }
+}
+
/**
* Moves a single object to the GTT read, and possibly write domain.
*
@@ -3536,6 +3552,41 @@ i915_gem_check_execbuffer (struct
drm_i915_gem_execbuffer *exec,
return 0;
}
+static int
+i915_gem_wait_for_pending_flip(struct drm_device *dev,
+ struct drm_gem_object **object_list,
+ int count)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj_priv;
+ DEFINE_WAIT(wait);
+ int i, ret = 0;
+
+ for (;;) {
+ prepare_to_wait(dev_priv-pending_flip_queue,
+ wait, TASK_INTERRUPTIBLE);
+ for (i = 0; i count; i++) {
+ obj_priv = object_list[i]-driver_private;
+ if (atomic_read(obj_priv-pending_flip) 0)
+ break;
+ }
+ if (i == count)
+ break;
+
+ if (!signal_pending(current)) {
+ mutex_unlock(dev-struct_mutex);
+ schedule();
+ mutex_lock(dev-struct_mutex);
+ continue;
+ }
+ ret = -ERESTARTSYS;
+ break;
+ }
+ finish_wait(dev_priv-pending_flip_queue, wait);
+
+ return ret;
+}
+
int
i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -3551,7 +3602,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
int ret, ret2, i, pinned = 0;
uint64_t exec_offset;
uint32_t seqno, flush_domains, reloc_index;
- int pin_tries;
+ int pin_tries, flips;
#if WATCH_EXEC
DRM_INFO(buffers_ptr %d buffer_count %d len %08x\n,
@@ -3623,6 +3674,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
}
/* Look up object handles */
+ flips = 0;
for (i = 0; i args-buffer_count; i++) {
object_list[i] = drm_gem_object_lookup(dev, file_priv,
exec_list[i].handle);
@@ -3641,6 +3693,14 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
goto err;
}
Re: RFC: libdrm repo
[oops, with reply-all this time] On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 9 Nov 2009 17:46:44 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). Btw the kernel releases every 3 months. That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing and we'd hook on to that good testing crowd. Right now libdrm releases are virtually invisible to the OSS people. There's no serious development, no RCs, etc. Since wee can't even pretend to do proper releases, I'd say hook on to the kernel's as those work. I don't see big advantages to packaging it with the kernel, mainly disadvantages. I don't think it'll get wider testing if it's in the kernel, and I don't think compatibility will be easier to maintain. FWIW, you gave me the opposite argument when you decided that DRM development should happen in the kernel. Back then you used to say that we'd get more testers that way. Which one should I believe? There's a big downside too, since it makes packaging much harder. Distros typically stick with one kernel for a relatively long time, but if they want to pick up a libdrm fix unrelated to a new DRM interface (like the one Remi pointed out) they'll have to grab a recent kernel, extract libdrm, and make sure it works with their current kernel (which may involve some extra work if new DRM interfaces have gone in too). Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24950] Build of mesa-git fails sometimes (no rule to make target compiler/libr300compiler.a)
http://bugs.freedesktop.org/show_bug.cgi?id=24950 --- Comment #9 from Brian Paul brian.e.p...@gmail.com 2009-11-17 10:23:55 PST --- Committed to master: cf65d81cf1eb031384f7e8bfe849ce59c458f27e -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tue, 17 Nov 2009 18:53:22 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 9 Nov 2009 17:46:44 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). Btw the kernel releases every 3 months. That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing and we'd hook on to that good testing crowd. Right now libdrm releases are virtually invisible to the OSS people. There's no serious development, no RCs, etc. Since wee can't even pretend to do proper releases, I'd say hook on to the kernel's as those work. I don't see big advantages to packaging it with the kernel, mainly disadvantages. I don't think it'll get wider testing if it's in the kernel, and I don't think compatibility will be easier to maintain. FWIW, you gave me the opposite argument when you decided that DRM development should happen in the kernel. Back then you used to say that we'd get more testers that way. Which one should I believe? Testers for kernel code, yes. Testers for libdrm code, no. When I install a new kernel I don't typically install new headers and all the other junk that comes with the new kernel, I just install the vmlinuz and make a new initrd if necessary. I don't think I'm alone. But even if we concede that libdrm would get more testers if included in the kernel, there are still other issues to deal with. There's a big downside too, since it makes packaging much harder. Distros typically stick with one kernel for a relatively long time, but if they want to pick up a libdrm fix unrelated to a new DRM interface (like the one Remi pointed out) they'll have to grab a recent kernel, extract libdrm, and make sure it works with their current kernel (which may involve some extra work if new DRM interfaces have gone in too). Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Presumably they'd want the last released version... Anyway I'm just dubious about moving most userland code into the kernel; udev, klibc, etc. I think it makes more things harder than it does easier. But like Kristian said, it's really a separate discussion from making a more standalone libdrm repo. Nothing stops you (or anyone else) from taking that new repo and proposing it for inclusion in the kernel. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24950] Build of mesa-git fails sometimes (no rule to make target compiler/libr300compiler.a)
http://bugs.freedesktop.org/show_bug.cgi?id=24950 Konstantin ernestoguev...@gmx.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Konstantin ernestoguev...@gmx.net 2009-11-17 10:42:22 PST --- Commited to Master - Status: Fixed -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/2] drm/i915: add GETPARAM request for page flipping
From c27e509840589cf4c175f615ec6e3d48e05944c5 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@jbarnes-desktop.localdomain
Date: Wed, 18 Nov 2009 04:31:47 +
Subject: [PATCH] drm/i915: add GETPARAM request for page flipping
Add a GETPARAM request for checking if page flipping is supported.
Useful for the 2D driver to enable the flipping path.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
include/drm/i915_drm.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 093146b..419b399 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -810,6 +810,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_OVERLAY:
value = dev_priv-overlay ? 1 : 0;
break;
+ case I915_PARAM_HAS_PAGEFLIPPING:
+ value = 1;
+ break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c900499..1b4f3a5 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -271,6 +271,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_GEM 5
#define I915_PARAM_NUM_FENCES_AVAIL 6
#define I915_PARAM_HAS_OVERLAY 7
+#define I915_PARAM_HAS_PAGEFLIPPING 8
typedef struct drm_i915_getparam {
int param;
--
1.6.1.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: APPLE_object_purgeable [v2]
Chris, It looks like this extension depends on the drm_intel_bo_madvise() function which isn't in a released version of libdrm yet. Correct? If so, I'd like to hold off on applying this patch to Mesa until there's a new libdrm. -Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: deal with connectors sourced to the same encoder
From f0c914fcbd1d178214b624438810ad32e3328fe2 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 17 Nov 2009 15:44:01 -0500
Subject: [PATCH] drm/radeon/kms: deal with connectors sourced to the
same encoder
Some systems have multiple connectors connected to the same encoder;
e.g., DVI and HDMI connected to the same encoder with the same ddc
line. Since we expose connectors as xrandr outputs, randr treats them
separately which results in it trying to source the same encoder to
different crtcs. If we have an HDMI and DVI-D port on the same encoder,
pick the one to be considered connected based on the edid (HDMI if edid
indicates HDMI, DVI otherwise).
Should fix fdo bug 25150
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_connectors.c | 33
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index ac54f90..a7a5e74 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -734,6 +734,39 @@ static enum drm_connector_status
radeon_dvi_detect(struct drm_connector *connect
ret = connector_status_disconnected;
} else
ret = connector_status_connected;
+
+ /* multiple connectors on the same encoder with the
same ddc line
+* This tends to be HDMI and DVI on the same encoder
with the
+* same ddc line. If the edid says HDMI, consider the
HDMI port
+* connected and the DVI port disconnected. If the
edid doesn't
+* say HDMI, vice versa.
+*/
+ if (radeon_connector-shared_ddc
connector_status_connected) {
+ struct drm_device *dev = connector-dev;
+ struct drm_connector *list_connector;
+ struct radeon_connector *list_radeon_connector;
+ list_for_each_entry(list_connector,
dev-mode_config.connector_list, head) {
+ if (connector == list_connector)
+ continue;
+ list_radeon_connector =
to_radeon_connector(list_connector);
+ if (radeon_connector-devices ==
list_radeon_connector-devices) {
+ if
(drm_detect_hdmi_monitor(radeon_connector-edid)) {
+ if
(connector-connector_type == DRM_MODE_CONNECTOR_DVID) {
+
kfree(radeon_connector-edid);
+
radeon_connector-edid = NULL;
+ ret =
connector_status_disconnected;
+ }
+ } else {
+ if
((connector-connector_type == DRM_MODE_CONNECTOR_HDMIA) ||
+
(connector-connector_type == DRM_MODE_CONNECTOR_HDMIB)) {
+
kfree(radeon_connector-edid);
+
radeon_connector-edid = NULL;
+ ret =
connector_status_disconnected;
+ }
+ }
+ }
+ }
+ }
}
}
--
1.5.6.3
From f0c914fcbd1d178214b624438810ad32e3328fe2 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 17 Nov 2009 15:44:01 -0500
Subject: [PATCH] drm/radeon/kms: deal with connectors sourced to the same encoder
Some systems have multiple connectors connected to the same encoder;
e.g., DVI and HDMI connected to the same encoder with the same ddc
line. Since we expose connectors as xrandr outputs, randr treats them
separately which results in it trying to source the same encoder to
different crtcs. If we have an HDMI and DVI-D port on the same encoder,
pick the one to be considered connected based on the edid (HDMI if edid
indicates HDMI, DVI otherwise).
Should fix fdo bug 25150
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_connectors.c | 33
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index
[Bug 14628] drm/ksm - s2disk - resume - [drm:r100_ring_test] *ERROR* radeon: ring test failed
http://bugzilla.kernel.org/show_bug.cgi?id=14628 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added Blocks|14230 | Regression|Yes |No --- Comment #3 from Rafael J. Wysocki r...@sisk.pl 2009-11-17 21:53:56 --- (In reply to comment #1) I don't think we can call this a regression, KMS + AGP likely never worked properly on this particular platform. Nevertheless it's a bug. OK, dropping from the list of recent regressions. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch for 2.6.32? 3/3] drm/radeon/kms: fix oops when set_base is call with no FB
From: Jerome Glisse jgli...@redhat.com
Just do nothing if crct_set_base() is called with no FB.
The oops happens when the user switches between X vt or in some case
when changing mode.
Signed-off-by: Jerome Glisse jgli...@redhat.com
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/radeon/atombios_crtc.c |7 +--
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff -puN
drivers/gpu/drm/radeon/atombios_crtc.c~drm-radeon-kms-fix-oops-when-set_base-is-call-with-no-fb
drivers/gpu/drm/radeon/atombios_crtc.c
---
a/drivers/gpu/drm/radeon/atombios_crtc.c~drm-radeon-kms-fix-oops-when-set_base-is-call-with-no-fb
+++ a/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -578,8 +578,11 @@ int atombios_crtc_set_base(struct drm_cr
uint64_t fb_location;
uint32_t fb_format, fb_pitch_pixels, tiling_flags;
- if (!crtc-fb)
- return -EINVAL;
+ /* no fb bound */
+ if (!crtc-fb) {
+ DRM_DEBUG(No FB bound\n);
+ return 0;
+ }
radeon_fb = to_radeon_framebuffer(crtc-fb);
diff -puN
drivers/gpu/drm/radeon/radeon_legacy_crtc.c~drm-radeon-kms-fix-oops-when-set_base-is-call-with-no-fb
drivers/gpu/drm/radeon/radeon_legacy_crtc.c
---
a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c~drm-radeon-kms-fix-oops-when-set_base-is-call-with-no-fb
+++ a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -408,6 +408,11 @@ int radeon_crtc_set_base(struct drm_crtc
uint32_t gen_cntl_reg, gen_cntl_val;
DRM_DEBUG(\n);
+ /* no fb bound */
+ if (!crtc-fb) {
+ DRM_DEBUG(No FB bound\n);
+ return 0;
+ }
radeon_fb = to_radeon_framebuffer(crtc-fb);
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch for 2.6.32? 2/3] drm: make sure page protections are updated after changing vm_flags
From: Jeremy Fitzhardinge jer...@goop.org Some architectures compute -vm_page_prot depending on -vm_flags, so we need to update the protections after adjusting the flags. AFAIK this only affects running X under Xen; without this patch you get lots of coloured blobs on the screen, or maybe a complete lockup. Or anything really. But that still depends on lots of out-of-tree stuff, so I don't think there are any consequences for anyone else. But it is wrong in principle. Reported-by: Jan Beulich jbeul...@novell.com Signed-off-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com Cc: Dave Airlie airl...@linux.ie Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/gpu/drm/drm_gem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/gpu/drm/drm_gem.c~drm-make-sure-page-protections-are-updated-after-changing-vm_flags drivers/gpu/drm/drm_gem.c --- a/drivers/gpu/drm/drm_gem.c~drm-make-sure-page-protections-are-updated-after-changing-vm_flags +++ a/drivers/gpu/drm/drm_gem.c @@ -552,7 +552,7 @@ int drm_gem_mmap(struct file *filp, stru vma-vm_flags |= VM_RESERVED | VM_IO | VM_PFNMAP | VM_DONTEXPAND; vma-vm_ops = obj-dev-driver-gem_vm_ops; vma-vm_private_data = map-handle; - vma-vm_page_prot = pgprot_writecombine(vma-vm_page_prot); + vma-vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma-vm_flags)); /* Take a ref for this mapping of the object, so that the fault * handler can dereference the mmap offset's pointer to the object. _ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch for 2.6.32? 1/3] drivers/gpu/drm/i915/i915_dma.c: fix unused var
From: Andrew Morton a...@linux-foundation.org
drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used
uninitialized in this function
Partly this is because gcc isn't smart enough. But `ll_base' does get used
uninitialised in the DRM_DEBUG() call.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Eric Anholt e...@anholt.net
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/i915/i915_dma.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN
drivers/gpu/drm/i915/i915_dma.c~drivers-gpu-drm-i915-i915_dmac-fix-unused-var
drivers/gpu/drm/i915/i915_dma.c
---
a/drivers/gpu/drm/i915/i915_dma.c~drivers-gpu-drm-i915-i915_dmac-fix-unused-var
+++ a/drivers/gpu/drm/i915/i915_dma.c
@@ -,7 +,8 @@ static void i915_setup_compression(struc
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_mm_node *compressed_fb, *compressed_llb;
- unsigned long cfb_base, ll_base;
+ unsigned long cfb_base;
+ unsigned long ll_base = 0;
/* Leave 1M for line length buffer misc. */
compressed_fb = drm_mm_search_free(dev_priv-vram, size, 4096, 0);
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: add quirk for Acer laptop
From 50698aab33d947171324e52f9678d975cd54d94a Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 17 Nov 2009 17:12:10 -0500
Subject: [PATCH] drm/radeon/kms: add quirk for Acer laptop
DVI-I port is actually DVI-D
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index cd07c0e..74bc8df 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -172,6 +172,15 @@ static bool radeon_atom_apply_quirks(struct
drm_device *dev,
}
}
+ /* Acer laptop reports DVI-D as DVI-I */
+ if ((dev-pdev-device == 0x95c4)
+ (dev-pdev-subsystem_vendor == 0x1025)
+ (dev-pdev-subsystem_device == 0x013c)) {
+ if ((*connector_type == DRM_MODE_CONNECTOR_DVII)
+ (supported_device == ATOM_DEVICE_DFP1_SUPPORT))
+ *connector_type = DRM_MODE_CONNECTOR_DVID;
+ }
+
return true;
}
--
1.5.6.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add quirk for Acer laptop
now with non-mangled patch.
On Tue, Nov 17, 2009 at 5:19 PM, Alex Deucher alexdeuc...@gmail.com wrote:
From 50698aab33d947171324e52f9678d975cd54d94a Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 17 Nov 2009 17:12:10 -0500
Subject: [PATCH] drm/radeon/kms: add quirk for Acer laptop
DVI-I port is actually DVI-D
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c | 9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index cd07c0e..74bc8df 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -172,6 +172,15 @@ static bool radeon_atom_apply_quirks(struct
drm_device *dev,
}
}
+ /* Acer laptop reports DVI-D as DVI-I */
+ if ((dev-pdev-device == 0x95c4)
+ (dev-pdev-subsystem_vendor == 0x1025)
+ (dev-pdev-subsystem_device == 0x013c)) {
+ if ((*connector_type == DRM_MODE_CONNECTOR_DVII)
+ (supported_device == ATOM_DEVICE_DFP1_SUPPORT))
+ *connector_type = DRM_MODE_CONNECTOR_DVID;
+ }
+
return true;
}
--
1.5.6.3
From 50698aab33d947171324e52f9678d975cd54d94a Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 17 Nov 2009 17:12:10 -0500
Subject: [PATCH] drm/radeon/kms: add quirk for Acer laptop
DVI-I port is actually DVI-D
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c
index cd07c0e..74bc8df 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -172,6 +172,15 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
}
}
+ /* Acer laptop reports DVI-D as DVI-I */
+ if ((dev-pdev-device == 0x95c4)
+ (dev-pdev-subsystem_vendor == 0x1025)
+ (dev-pdev-subsystem_device == 0x013c)) {
+ if ((*connector_type == DRM_MODE_CONNECTOR_DVII)
+ (supported_device == ATOM_DEVICE_DFP1_SUPPORT))
+ *connector_type = DRM_MODE_CONNECTOR_DVID;
+ }
+
return true;
}
--
1.5.6.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 1/5] drm/via: add pci id for VIA VX800 chipset
From: Thomas Schlichter thomas.schlich...@web.de
The VIA DRM module is able to accelerate 2D video on the VX800 chipset,
thus add the corresponding PCI ID. Accelerated 3D video is not
implemented.
The modified VIA DRM module was tested with X.Org openchrome driver on a
Samsung NC20 netbook. Video playback with xine requires nearly 30% less
CPU cycles.
Signed-off-by: Thomas Schlichter thomas.schlich...@web.de
Cc: Dave Airlie airl...@redhat.com
Cc: Alex Deucher alexdeuc...@gmail.com
Cc: Eric Anholt e...@anholt.net
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
include/drm/drm_pciids.h |1 +
1 file changed, 1 insertion(+)
diff -puN include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset
include/drm/drm_pciids.h
--- a/include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset
+++ a/include/drm/drm_pciids.h
@@ -477,6 +477,7 @@
{0x1106, 0x3343, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x1106, 0x3230, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
{0x1106, 0x3157, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_PRO_GROUP_A}, \
+ {0x1106, 0x1122, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
{0, 0, 0}
#define i810_PCI_IDS \
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 3/5] drm: kill more unused DRM macros
From: Andres Salomon dilin...@collabora.co.uk
There are a few more macros in drmP.h that are unused; DRM_GET_PRIV_SAREA,
DRM_ARRAY_SIZE, and DRM_WAITCOUNT can go away completely.
Unfortunately, DRM_COPY is still used in one place, but we can at least
move it to where it's used. It's an awful looking macro..
[akpm: fix overeagerness]
Signed-off-by: Andres Salomon dilin...@collabora.co.uk
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/drm_drv.c | 12
include/drm/drmP.h| 23 ---
2 files changed, 12 insertions(+), 23 deletions(-)
diff -puN drivers/gpu/drm/drm_drv.c~drm-kill-more-unused-drm-macros
drivers/gpu/drm/drm_drv.c
--- a/drivers/gpu/drm/drm_drv.c~drm-kill-more-unused-drm-macros
+++ a/drivers/gpu/drm/drm_drv.c
@@ -366,6 +366,18 @@ module_init(drm_core_init);
module_exit(drm_core_exit);
/**
+ * Copy and IOCTL return string to user space
+ */
+#define DRM_COPY(name, value) \
+ len = strlen(value); \
+ if (len name##_len) len = name##_len; \
+ name##_len = strlen(value); \
+ if (len name) {\
+ if (copy_to_user(name, value, len)) \
+ return -EFAULT; \
+ }
+
+/**
* Get version information
*
* \param inode device inode.
diff -puN include/drm/drmP.h~drm-kill-more-unused-drm-macros include/drm/drmP.h
--- a/include/drm/drmP.h~drm-kill-more-unused-drm-macros
+++ a/include/drm/drmP.h
@@ -255,19 +255,8 @@ extern void drm_ut_debug_printk(unsigned
#define DRM_LEFTCOUNT(x) (((x)-rp + (x)-count - (x)-wp) % ((x)-count + 1))
#define DRM_BUFCOUNT(x) ((x)-count - DRM_LEFTCOUNT(x))
-#define DRM_WAITCOUNT(dev,idx) DRM_BUFCOUNT(dev-queuelist[idx]-waitlist)
#define DRM_IF_VERSION(maj, min) (maj 16 | min)
-/**
- * Get the private SAREA mapping.
- *
- * \param _dev DRM device.
- * \param _ctx context number.
- * \param _map output mapping.
- */
-#define DRM_GET_PRIV_SAREA(_dev, _ctx, _map) do { \
- (_map) = (_dev)-context_sareas[_ctx]; \
-} while(0)
/**
* Test that the hardware lock is held by the caller, returning otherwise.
@@ -287,18 +276,6 @@ do {
\
} while (0)
/**
- * Copy and IOCTL return string to user space
- */
-#define DRM_COPY( name, value )
\
- len = strlen( value ); \
- if ( len name##_len ) len = name##_len; \
- name##_len = strlen( value ); \
- if ( len name ) {\
- if ( copy_to_user( name, value, len ) ) \
- return -EFAULT; \
- }
-
-/**
* Ioctl function type.
*
* \param inode device inode.
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 2/5] drm: kill some unused DRM_PROC macros from drmP.h
From: Andres Salomon dilin...@collabora.co.uk
i915_gem_proc.c appears to have been the last user of the DRM_PROC_*
macros, and it has gone away. The macros should die as well.
Signed-off-by: Andres Salomon dilin...@collabora.co.uk
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
include/drm/drmP.h | 10 --
1 file changed, 10 deletions(-)
diff -puN include/drm/drmP.h~drm-kill-some-unused-drm_proc-macros-from-drmph
include/drm/drmP.h
--- a/include/drm/drmP.h~drm-kill-some-unused-drm_proc-macros-from-drmph
+++ a/include/drm/drmP.h
@@ -245,16 +245,6 @@ extern void drm_ut_debug_printk(unsigned
#endif
-#define DRM_PROC_LIMIT (PAGE_SIZE-80)
-
-#define DRM_PROC_PRINT(fmt, arg...)\
- len += sprintf(buf[len], fmt , ##arg); \
- if (len DRM_PROC_LIMIT) { *eof = 1; return len - offset; }
-
-#define DRM_PROC_PRINT_RET(ret, fmt, arg...) \
- len += sprintf(buf[len], fmt , ##arg); \
- if (len DRM_PROC_LIMIT) { ret; *eof = 1; return len - offset; }
-
/*...@}*/
/***/
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 4/5] drm: replace DRM_COPY macro w/ a function
From: Andres Salomon dilin...@collabora.co.uk
Don't inline it; the compiler can figure it out. Comments added that are
based upon my interpretation of the code. Hopefully they're correct. :)
Signed-off-by: Andres Salomon dilin...@collabora.co.uk
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/drm_drv.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff -puN drivers/gpu/drm/drm_drv.c~drm-replace-drm_copy-macro-w-a-function
drivers/gpu/drm/drm_drv.c
--- a/drivers/gpu/drm/drm_drv.c~drm-replace-drm_copy-macro-w-a-function
+++ a/drivers/gpu/drm/drm_drv.c
@@ -368,14 +368,25 @@ module_exit(drm_core_exit);
/**
* Copy and IOCTL return string to user space
*/
-#define DRM_COPY(name, value) \
- len = strlen(value); \
- if (len name##_len) len = name##_len; \
- name##_len = strlen(value); \
- if (len name) {\
- if (copy_to_user(name, value, len)) \
- return -EFAULT; \
- }
+static int drm_copy_field(char *buf, size_t *buf_len, const char *value)
+{
+ int len;
+
+ /* don't overflow userbuf */
+ len = strlen(value);
+ if (len *buf_len)
+ len = *buf_len;
+
+ /* let userspace know exact length of driver value (which could be
+* larger than the userspace-supplied buffer) */
+ *buf_len = strlen(value);
+
+ /* finally, try filling in the userbuf */
+ if (len buf)
+ if (copy_to_user(buf, value, len))
+ return -EFAULT;
+ return 0;
+}
/**
* Get version information
@@ -392,14 +403,13 @@ static int drm_version(struct drm_device
struct drm_file *file_priv)
{
struct drm_version *version = data;
- int len;
version-version_major = dev-driver-major;
version-version_minor = dev-driver-minor;
version-version_patchlevel = dev-driver-patchlevel;
- DRM_COPY(version-name, dev-driver-name);
- DRM_COPY(version-date, dev-driver-date);
- DRM_COPY(version-desc, dev-driver-desc);
+ drm_copy_field(version-name, version-name_len, dev-driver-name);
+ drm_copy_field(version-date, version-date_len, dev-driver-date);
+ drm_copy_field(version-desc, version-desc_len, dev-driver-desc);
return 0;
}
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 5/5] drm: check return values in drm_version
From: Andres Salomon dilin...@collabora.co.uk
In drm_version, actually check the results from function calls so that
we're not potentially passing garbage back to userspace.
Signed-off-by: Andres Salomon dilin...@collabora.co.uk
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/drm_drv.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff -puN drivers/gpu/drm/drm_drv.c~drm-check-return-values-in-drm_version
drivers/gpu/drm/drm_drv.c
--- a/drivers/gpu/drm/drm_drv.c~drm-check-return-values-in-drm_version
+++ a/drivers/gpu/drm/drm_drv.c
@@ -403,15 +403,21 @@ static int drm_version(struct drm_device
struct drm_file *file_priv)
{
struct drm_version *version = data;
+ int err;
version-version_major = dev-driver-major;
version-version_minor = dev-driver-minor;
version-version_patchlevel = dev-driver-patchlevel;
- drm_copy_field(version-name, version-name_len, dev-driver-name);
- drm_copy_field(version-date, version-date_len, dev-driver-date);
- drm_copy_field(version-desc, version-desc_len, dev-driver-desc);
+ err = drm_copy_field(version-name, version-name_len,
+ dev-driver-name);
+ if (!err)
+ err = drm_copy_field(version-date, version-date_len,
+ dev-driver-date);
+ if (!err)
+ err = drm_copy_field(version-desc, version-desc_len,
+ dev-driver-desc);
- return 0;
+ return err;
}
/**
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 1/5] drm/via: add pci id for VIA VX800 chipset
On Wed, Nov 18, 2009 at 8:41 AM, a...@linux-foundation.org wrote:
From: Thomas Schlichter thomas.schlich...@web.de
The VIA DRM module is able to accelerate 2D video on the VX800 chipset,
thus add the corresponding PCI ID. Accelerated 3D video is not
implemented.
The modified VIA DRM module was tested with X.Org openchrome driver on a
Samsung NC20 netbook. Video playback with xine requires nearly 30% less
CPU cycles.
I think this was an mtrr missing workaround,
I think we dropped this in favour of fixing things properly, correct
me if I'm wrong.
Thomas?
Dave.
Signed-off-by: Thomas Schlichter thomas.schlich...@web.de
Cc: Dave Airlie airl...@redhat.com
Cc: Eric Anholt e...@anholt.net
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
include/drm/drm_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff -puN include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset
include/drm/drm_pciids.h
--- a/include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset
+++ a/include/drm/drm_pciids.h
@@ -477,6 +477,7 @@
{0x1106, 0x3343, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x1106, 0x3230, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
{0x1106, 0x3157, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_PRO_GROUP_A}, \
+ {0x1106, 0x1122, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
{0, 0, 0}
#define i810_PCI_IDS \
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] Add intel implementation of the pageflip ioctl
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
*cough* checkpatch.pl *cough*.
Dave.
---
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/i915_gem.c | 64 +-
drivers/gpu/drm/i915/i915_irq.c | 10 ++
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_display.c | 233
+-
drivers/gpu/drm/i915/intel_drv.h |3 +
6 files changed, 290 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 835625b..7c5b05e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -536,6 +536,10 @@ typedef struct drm_i915_private {
/* indicate whether the LVDS_BORDER should be enabled or not */
unsigned int lvds_border_bits;
+ struct drm_crtc *plane_to_crtc_mapping[2];
+ struct drm_crtc *pipe_to_crtc_mapping[2];
+ wait_queue_head_t pending_flip_queue;
+
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
@@ -635,6 +639,13 @@ struct drm_i915_gem_object {
* Advice: are the backing pages purgeable?
*/
int madv;
+
+ /**
+ * Number of crtcs where this object is currently the fb, but
+ * will be page flipped away on the next vblank. When it
+ * reaches 0, dev_priv-pending_flip_queue will be woken up.
+ */
+ atomic_t pending_flip;
};
/**
@@ -826,6 +837,7 @@ void i915_gem_free_all_phys_object(struct drm_device
*dev);
int i915_gem_object_get_pages(struct drm_gem_object *obj);
void i915_gem_object_put_pages(struct drm_gem_object *obj);
void i915_gem_release(struct drm_device * dev, struct drm_file *file_priv);
+void i915_gem_object_flush_write_domain(struct drm_gem_object *obj);
void i915_gem_shrinker_init(void);
void i915_gem_shrinker_exit(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2065b8f..22dd6c3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2771,6 +2771,22 @@ i915_gem_object_flush_cpu_write_domain(struct
drm_gem_object *obj)
old_write_domain);
}
+void
+i915_gem_object_flush_write_domain(struct drm_gem_object *obj)
+{
+ switch (obj-write_domain) {
+ case I915_GEM_DOMAIN_GTT:
+ i915_gem_object_flush_gtt_write_domain(obj);
+ break;
+ case I915_GEM_DOMAIN_CPU:
+ i915_gem_object_flush_cpu_write_domain(obj);
+ break;
+ default:
+ i915_gem_object_flush_gpu_write_domain(obj);
+ break;
+ }
+}
+
/**
* Moves a single object to the GTT read, and possibly write domain.
*
@@ -3536,6 +3552,41 @@ i915_gem_check_execbuffer (struct
drm_i915_gem_execbuffer *exec,
return 0;
}
+static int
+i915_gem_wait_for_pending_flip(struct drm_device *dev,
+struct drm_gem_object **object_list,
+int count)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj_priv;
+ DEFINE_WAIT(wait);
+ int i, ret = 0;
+
+ for (;;) {
+ prepare_to_wait(dev_priv-pending_flip_queue,
+ wait, TASK_INTERRUPTIBLE);
+ for (i = 0; i count; i++) {
+ obj_priv = object_list[i]-driver_private;
+ if (atomic_read(obj_priv-pending_flip) 0)
+ break;
+ }
+ if (i == count)
+ break;
+
+ if (!signal_pending(current)) {
+ mutex_unlock(dev-struct_mutex);
+ schedule();
+ mutex_lock(dev-struct_mutex);
+ continue;
+ }
+ ret = -ERESTARTSYS;
+ break;
+ }
+ finish_wait(dev_priv-pending_flip_queue, wait);
+
+ return ret;
+}
+
int
i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -3551,7 +3602,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
int ret, ret2, i, pinned = 0;
uint64_t exec_offset;
uint32_t seqno, flush_domains, reloc_index;
- int pin_tries;
+ int pin_tries, flips;
#if WATCH_EXEC
DRM_INFO(buffers_ptr %d buffer_count %d len %08x\n,
@@ -3623,6 +3674,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
}
/* Look up object handles */
+ flips = 0;
for (i = 0; i args-buffer_count; i++) {
object_list[i] = drm_gem_object_lookup(dev, file_priv,
exec_list[i].handle);
@@ -3641,6 +3693,14 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
goto err;
Re: is avoiding compat ioctls possible?
On Fri, Oct 30, 2009 at 8:13 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 30 October 2009, Dave Airlie wrote:
Btw when I mentioned ioctls I meant more than radeon, all the KMS
ioctls in the common drm_crtc.c file suffer from this problem as well.
Hence why I still believe either my drm specific inline or something
more generic (granted I can see why a generic solution would be ugly).
You patch below does suffer from a lot of #ifdefs and cut-n-paste
that is a lot better suited to doing in an inline or macro. We can then
comment that inline saying if anyone else does this we will be most
unhappy.
I think it would be better to do a conversion of the pointers in
a separate compat handler, but then call the regular function, which
in case of drm already take a kernel pointer. That would be much simpler
than the compat_alloc_user_space tricks in the current code and
also cleaner than trying to handle both cases in one function using
is_compat_task().
See the (not even compile-tested) example below as an illustration
of what I think you should do. If you convert all functions in
drm_ioc32.c to this scheme, you can replace drm_compat_ioctl and
drm_compat_ioctls[] with drm_generic_compat_ioctl.
I just got back out from F12 push to look at lkml again ;-)
My main problem which no-one seem to address with all these compat ioctls
is they suck for maintainance, adding the compat_ptr hacks into the actual
ioctls is much easier to maintain in that I can see in the code where we've done
these and if code flow has to change I can deal with it all in one place.
Doing all these out-of-line hidden over here in a separate file just
seems crazy,
and I'm having trouble wondering why ppl consider it a better idea at all.
It adds probably 1000 more LOC versus one inline with a decent name used
inline to replace current casting in the driver.
If the ioctl flow or interface changes someone has to remember about all
of these (granted this is unlikely since we pretty much set them in stone).
Dave.
Arnd
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 282d9fd..334345b 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -1040,6 +1040,122 @@ static int compat_drm_wait_vblank(struct file *file,
unsigned int cmd,
return 0;
}
+static int compat_drm_mode_getblob_ioctl(struct drm_device *dev,
+ struct drm_mode_get_blob __user *out_resp_user,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_blob out_resp;
+ int ret;
+
+ ret = copy_from_user(out_resp, out_resp_user, sizeof(out_resp))
+ if (ret)
+ return -EFAULT;
+
+ out_resp.data = (unsigned long)compat_ptr(out_resp.data);
+
+ ret = drm_mode_getblob_ioctl(dev, out_resp, file_priv);
+ if (ret)
+ return ret;
+
+ ret = copy_to_user(out_resp_user, out_resp, sizeof(out_resp))
+ if (ret)
+ return -EFAULT;
+ return 0;
+}
+
+static int compat_drm_mode_gamma_set_ioctl(struct drm_device *dev,
+ struct drm_mode_crtc_lut __user *crtc_lut_user,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_crtc_lut crtc_lut;
+
+ ret = copy_from_user(crtc_lut, crtc_lut_user, sizeof(crtc_lut))
+ if (ret)
+ return -EFAULT;
+
+ crtc_lut.red = (unsigned long)compat_ptr(crtc_lut.red);
+ crtc_lut.green = (unsigned long)compat_ptr(crtc_lut.green);
+ crtc_lut.blue = (unsigned long)compat_ptr(crtc_lut.blue);
+
+ ret = drm_mode_gamma_set_ioctl(dev, crtc_lut, file_priv);
+
+ return ret;
+}
+
+static int compat_drm_mode_gamma_get_ioctl(struct drm_device *dev,
+ struct drm_mode_crtc_lut __user *crtc_lut_user,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_crtc_lut crtc_lut;
+
+ ret = copy_from_user(crtc_lut, crtc_lut_user, sizeof(crtc_lut))
+ if (ret)
+ return -EFAULT;
+
+ crtc_lut.red = (unsigned long)compat_ptr(crtc_lut.red);
+ crtc_lut.green = (unsigned long)compat_ptr(crtc_lut.green);
+ crtc_lut.blue = (unsigned long)compat_ptr(crtc_lut.blue);
+
+ ret = drm_mode_gamma_get_ioctl(dev, crtc_lut, file_priv);
+
+ return ret;
+}
+
+static int drm_generic_compat_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
+{
+ struct drm_file *file_priv = filp-private_data;
+ struct drm_device *dev = file_priv-minor-dev;
+ unsigned int nr = DRM_IOCTL_NR(cmd);
+ int ret;
+
+ atomic_inc(dev-ioctl_count);
+ atomic_inc(dev-counts[_DRM_STAT_IOCTLS]);
+ ++file_priv-ioctl_count;
+
+ if ((nr = DRM_CORE_IOCTL_COUNT)
+ ((nr DRM_COMMAND_BASE) || (nr = DRM_COMMAND_END)))
+ goto err_i1;
Re: [PATCH 1/3] drm/radeon: Give userspace more accurate information about available memory.
2009/8/5 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Signed-off-by: Michel Dänzer daen...@vmware.com Hi Michel, sorry I lost this when we got stuck with fb reallocations. One problem is this now underreports, I think you can just remove gart table + fbcon from VRAM, userspace allocates the pinned front + cursor buffers so should in theory know about it, though maybe we need to be a bit smarter for a multi-seat case where two X server could allocate pinned frontbuffer separate to each other. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25156] New: Using wine on ati open source drivers causes rotated textures in Wow
http://bugs.freedesktop.org/show_bug.cgi?id=25156 Summary: Using wine on ati open source drivers causes rotated textures in Wow Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: wjer...@shaw.ca Created an attachment (id=31288) -- (http://bugs.freedesktop.org/attachment.cgi?id=31288) 3D Texture corruption FACT: When loading World of Warcraft into a Linux computer on the AMD64 architecture using the wine binary compatibility layer the screen loads up with all textures rotated. I am using Kubuntu Karmic kernel 2.6.31. I tried Mesa/DRI versions from 7.4 to 7.7-devel and every kernel in between and all respond the same way. I also tried to see if the problem persisted in i686 architecture, but it is fine in 32bit. Using the 32bit kernel and libraries rendered everything perfectly in Kubuntu Intrepid on the 2.6.27 kernel with good acceleration. I opened a launchpad bug prior and the url is: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/455628 I am triaging the bug here, since someone from another architecture has also reported similar issues from amd64 as well. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25156] Using wine on ati open source drivers causes rotated textures in Wow
http://bugs.freedesktop.org/show_bug.cgi?id=25156 --- Comment #1 from Jeremy Wilkins wjer...@shaw.ca 2009-11-17 21:55:57 PST --- Created an attachment (id=31289) -- (http://bugs.freedesktop.org/attachment.cgi?id=31289) Xorg Log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25156] Using wine on ati open source drivers causes rotated textures in Wow
http://bugs.freedesktop.org/show_bug.cgi?id=25156 --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-17 23:04:00 PST --- This is a known problem. Disable Full screen glow effect and Depth effect for now. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
