RE: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
Hello Dave and Luc: Sorry for the trouble we made and thank you very much for your comment. We will (1) add inline comment for to the patch (2) explaination for the 2 new parameters (3) explaination of the ioctl. Moreover, we will attached the test log Xorg.0.log of the compatibility test with Openchrome driver. Hello Luc: Can I know which chipset should I use if I like to verify the DRM driver with UniChrome driver in SLED11? Is CX700M platform OK? Or CN700? Thanks and Best Regards = Bruce C. Chang(???) VIA Technologies, Inc. Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei Tel: +886-2-22185452 Ext 7323 Mobile: +886-968343824 Fax: +886-2-22186282 Skype: Bruce.C.Chang Email: brucech...@via.com.tw -Original Message- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Friday, September 11, 2009 9:58 AM To: Luc Verhaegen Cc: Bruce Chang; Joseph Chan; dri-devel@lists.sourceforge.net; Benjamin Pan (Fremont) Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI These patches break both free drivers out there. They not only break the API, they also require some of these ioctls to be used correctly for correct initialisation. There seems to be no attempt at working with these two drivers to fix this specific issue. I'm looking for the API break but not really seeing it, I can see additions to the API. So it would be good if you could take a minute and write some inline comments in a reply to the patch, so we can track it. The only one I'd worry about is the extending of drm_via_init_t with two new parameters. Granted if these ioctls are to be used by *chrome to workaround this bug as well, then it would be good if patches to those driver were made available so as to get correct operation. Otherwise these patches fail for the usual reasons, they actively revert a change made upstream (removing linux/types.h and reverting all that), also this should be one patch, we don't need .c and .h separate all the time, its also impossible to bisect across that sort of thing. Dave. No version was bumped, because i believe these are against the kernel copy of the drm, because for some reason the kernel copy never saw commit 659e9a091d3. These seem fixes that only VIAs own internal driver uses, and a scheme of shipping your own drm driver with your own xorg driver seems to be necessary. Luc Verhaegen. -- 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 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
On Fri, Sep 11, 2009 at 05:15:04PM +0800, brucech...@via.com.tw wrote: Hello Luc: Can I know which chipset should I use if I like to verify the DRM driver with UniChrome driver in SLED11? Is CX700M platform OK? Or CN700? Thanks and Best Regards The three devices currently fully supported are CLE266, KM400 and K8M800. Luc Verhaegen. -- 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 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
Hello Luc: Thanks you very much for your information. We will re-submit again and keep the drm_via_init_t API no change. Hope it can be more acceptable for you. Thanks and Best Regards = Bruce C. Chang(張祖明) VIA Technologies, Inc. Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei Tel: +886-2-22185452 Ext 7323 Mobile: +886-968343824 Fax: +886-2-22186282 Skype: Bruce.C.Chang Email: brucech...@via.com.tw -Original Message- From: Luc Verhaegen [mailto:l...@skynet.be] Sent: Friday, September 11, 2009 7:07 PM To: Bruce Chang Cc: airl...@gmail.com; Joseph Chan; dri-devel@lists.sourceforge.net; Benjamin Pan (Fremont) Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI On Fri, Sep 11, 2009 at 05:15:04PM +0800, brucech...@via.com.tw wrote: Hello Luc: Can I know which chipset should I use if I like to verify the DRM driver with UniChrome driver in SLED11? Is CX700M platform OK? Or CN700? Thanks and Best Regards The three devices currently fully supported are CLE266, KM400 and K8M800. Luc Verhaegen. -- 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 13683] Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
http://bugzilla.kernel.org/show_bug.cgi?id=13683 Jan Kreuzer kontrolla...@gmx.de changed: What|Removed |Added Kernel Version|2.6.31-rc8 |2.6.31-rc9 --- Comment #14 from Jan Kreuzer kontrolla...@gmx.de 2009-09-11 12:41:09 --- Ping. Still the same with 2.6.31-rc9 and 2.6.31 final. Also the same with airlieds drm-next tree. -- 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
Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
On Fri, Sep 11, 2009 at 05:54:34AM +0100, Dave Airlie wrote: What should the canonical source of such versioning information be? * This header file defines the interface, and this versioning included in the same headerfile should then niquely identify this interface. * driver builds against this header and should then require this version of the interface from the drm as well. It might choose to have some build time or run time workarounds if the developer decides to spend time on this, but it doesn't need to. No thats where you got it wrong, a driver should never *require* version of interface at runtime == version of interface at build time. We rarely make incompatible major number changes in the kernel drivers, (radeon kms being the first in my memory). DRM drivers ship in the kernel, not separately so dealing with inequality of version isn't optional. It is exactly such a major change that made this version numbering necessary in the header file. So from what I can see this solves a compile time problem, not a run time. Generally this has been solved in other ways, either requiring when the driver needs a newer version of the header it requires a new libdrm or when the driver needs a newer version of the header it ships it within itself. No it is not, the interfaces are not compatible. This patch will not be put in everywhere immediately. How does a graphics driver give the user a reason for why the whole thing came crashing down, while things worked just fine before the kernel update that joe user most likely will not immediately see as the reason for this breakage? I really do not see what the problem is with having the driver version carried around in the interface headerfile. X driver, mesa and drm driver build with that. drm claims this version. If this version is not compatible, both X driver and mesa can then try to handle this gracefully. If you choose to have the driver fail hard with an error message, then fine, it at least is better than having half the userbase complain that their drm wasn't initialised fully, for no visible reason. Its just not been required before and I'd like to understand why no-one else has had the requirement over the other 8 or so drm/dri drivers produced. Generally I think we avoid it because it links the build and runtime versioning, which isn't something that a driver should ever do. Isn't versioning a common scheme to be able to handle both run and build time compatibility in a halfdecent manner? What use is runtime-only or buildtime-only versioning? Are you against this because carrying a versioning information makes it possible to do major changes gracefully and therefor encourages major changes and therefor is totally unacceptable? That almost sounds like saying that people shouldn't use electricity at all because it could mean that a whole team of people in a nuclear power plant will end up doing the wrong thing, every few weeks. But if *chrome all agrees its a good plan, then I'll take a patch, it would be nice if TH signs off on it. We discussed it out fully 3.5 years ago, and TH committed it 3.5ys ago, and he has nicely kept up the version bumping since from his side. What is it that you still require here? Is this not an attempt? generally all patches to the drm go to this list first, yes maybe they should also go to *chrome lists, but maybe developers who care should be more involved with the dri process instead of having their own one on a list that is somewhere else. The questions we ask here are generally: a) does this break runtime ABI in a backwards incompatible manner? b) does this patch have major style problems. So far (b) is true, and you've stated (a) is true but I haven't seen the lines in via_drm.h where this is pointed out. a) https://bugzilla.novell.com/show_bug.cgi?id=521382#c0 where Reinhard Nissl clearly describes the lowlevel part of the problem (and where i, without a log, completely missed the far-reaching consequences of this; ie, no working drm at all.) The other question is whether the new API makes any sense, and I can't answer that, which is probably where we need you or Thomas to chime in and tell us why its technically incorrect. Dave. I cannot immediately answer this API thing either. I saw this bug report pointed at me, and only a bit later realised what really was going on. This patch was included very late, and we were never given a heads up on this, let alone told exactly what it fixes or how this can be reproduced. It just blatantly broke things, and then the only quick answer is: revert. Chances are that if this is looked at differently, everyone can become happy without a major version bump. If not, there should be a major version bump and all players should gracefully handle this. Luc Verhaegen. -- Let Crystal Reports handle the
[Bug 14139] Output to external monitor is broken
http://bugzilla.kernel.org/show_bug.cgi?id=14139 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|PATCH_ALREADY_AVAILABLE |CODE_FIX -- 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 13819] system freeze when switching to console
http://bugzilla.kernel.org/show_bug.cgi?id=13819 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #10 from Brian Paul brian.e.p...@gmail.com 2009-09-11 09:18:16 PST --- (In reply to comment #9) Created an attachment (id=29361) -- (http://bugs.freedesktop.org/attachment.cgi?id=29361) [details] small case This case simply render a rectangle area in stencil buffer with glDrawPixels(GL_STENCIL). then render a red rectangle to validate the result. This case works with software rendering, but not with i965 driver. This should be fixed as of mesa commit 9e6ae75cc8d6bff139aa21bda0aa682755ab7a7c For the other failures I need more information to know what's wrong. I've tested a variety of pixel transfer and pixel store modes with glDrawPixels(GL_DEPTH_COMPONENT) (which I suspect pxstore-depth.c and pxtrans-cidraw.c exercise) but haven't found any issues. -- 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] drm: Add async event synchronization for drmWaitVblank
This patch adds a new flag to the drmWaitVblank ioctl, which asks the drm
to return immediately and notify userspace when the specified vblank sequence
happens by sending an event back on the drm fd.
The event mechanism works with the other flags supported by the ioctls,
specifically, the vblank sequence can be specified relatively or absolutely,
and works for primary and seconday crtc.
The signal field of the vblank request is used to provide user data,
which will be sent back to user space in the vblank event.
Signed-off-by: Kristian Høgsberg k...@redhat.com
---
drivers/gpu/drm/drm_fops.c | 99 ++-
drivers/gpu/drm/drm_irq.c | 95 +
drivers/gpu/drm/drm_stub.c |2 +
drivers/gpu/drm/i915/i915_drv.c |1 +
include/drm/drm.h | 33 -
include/drm/drmP.h | 26 ++
6 files changed, 252 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 251bc0e..8430e13 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -257,6 +257,9 @@ static int drm_open_helper(struct inode *inode, struct file
*filp,
INIT_LIST_HEAD(priv-lhead);
INIT_LIST_HEAD(priv-fbs);
+ INIT_LIST_HEAD(priv-event_list);
+ init_waitqueue_head(priv-event_wait);
+ priv-event_space = 4096; /* set aside 4k for event buffer */
if (dev-driver-driver_features DRIVER_GEM)
drm_gem_open(dev, priv);
@@ -413,6 +416,30 @@ static void drm_master_release(struct drm_device *dev,
struct file *filp)
}
}
+static void drm_events_release(struct drm_file *file_priv)
+{
+ struct drm_device *dev = file_priv-minor-dev;
+ struct drm_pending_event *e, *et;
+ struct drm_pending_vblank_event *v, *vt;
+ unsigned long flags;
+
+ spin_lock_irqsave(dev-event_lock, flags);
+
+ /* Remove pending flips */
+ list_for_each_entry_safe(v, vt, dev-vblank_event_list, base.link)
+ if (v-base.file_priv == file_priv) {
+ list_del(v-base.link);
+ drm_vblank_put(dev, v-pipe);
+ v-base.destroy(v-base);
+ }
+
+ /* Remove unconsumed events */
+ list_for_each_entry_safe(e, et, file_priv-event_list, link)
+ e-destroy(e);
+
+ spin_unlock_irqrestore(dev-event_lock, flags);
+}
+
/**
* Release file.
*
@@ -451,6 +478,8 @@ int drm_release(struct inode *inode, struct file *filp)
if (file_priv-minor-master)
drm_master_release(dev, filp);
+ drm_events_release(file_priv);
+
if (dev-driver-driver_features DRIVER_GEM)
drm_gem_release(dev, file_priv);
@@ -544,9 +573,75 @@ int drm_release(struct inode *inode, struct file *filp)
}
EXPORT_SYMBOL(drm_release);
-/** No-op. */
+static bool
+drm_dequeue_event(struct drm_file *file_priv,
+ size_t total, size_t max, struct drm_pending_event **out)
+{
+ struct drm_device *dev = file_priv-minor-dev;
+ struct drm_pending_event *e;
+ unsigned long flags;
+ bool ret = false;
+
+ spin_lock_irqsave(dev-event_lock, flags);
+
+ *out = NULL;
+ if (list_empty(file_priv-event_list))
+ goto out;
+ e = list_first_entry(file_priv-event_list,
+struct drm_pending_event, link);
+ if (e-event-length + total max)
+ goto out;
+
+ file_priv-event_space += e-event-length;
+ list_del(e-link);
+ *out = e;
+ ret = true;
+
+ out:
+ spin_unlock_irqrestore(dev-event_lock, flags);
+
+ return ret;
+}
+
+ssize_t drm_read(struct file *filp, char __user *buffer,
+size_t count, loff_t *offset)
+{
+ struct drm_file *file_priv = filp-private_data;
+ struct drm_pending_event *e;
+ size_t total;
+ ssize_t ret;
+
+ ret = wait_event_interruptible(file_priv-event_wait,
+ !list_empty(file_priv-event_list));
+ if (ret 0)
+ return ret;
+
+ total = 0;
+ while (drm_dequeue_event(file_priv, total, count, e)) {
+ if (copy_to_user(buffer + total,
+e-event, e-event-length)) {
+ total = -EFAULT;
+ break;
+ }
+
+ total += e-event-length;
+ e-destroy(e);
+ }
+
+ return total;
+}
+EXPORT_SYMBOL(drm_read);
+
unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait)
{
- return 0;
+ struct drm_file *file_priv = filp-private_data;
+ unsigned int mask = 0;
+
+ poll_wait(filp, file_priv-event_wait, wait);
+
+ if (!list_empty(file_priv-event_list))
+ mask |= POLLIN | POLLRDNORM;
+
+ return mask;
}
[PATCH set] drm/radeon/kms: implement PM-required code
This patchset implements features needed to implement real power management. Last one (0005) even shows that it's possible to implement downclocking on DPMS_OFF with previous patches. It's just prove of working infrastructure, nothing acceptable to commit. However I hope it makes you decide commiting 0001-0004. Please review/test/commit. If you decide to apply last patch, just use: xset dpms force off -- Rafał Miłecki 0001-drm-radeon-kms-add-getting-clocks-values.patch Description: Binary data 0002-drm-radeon-kms-add-power-management-states-storage.patch Description: Binary data 0003-drm-radeon-kms-correct-min-and-max-chip-limits.patch Description: Binary data 0004-drm-radeon-kms-add-pm-state-setting-function-engin.patch Description: Binary data 0005-drm-radeon-kms-downclock-to-minimum-on-DPMS_OFF.patch Description: Binary data -- 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 common lvds modes in the ddc case
From 702fd0710dad9c2f7767e98f6b650a8481a33c93 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 11 Sep 2009 11:15:43 -0400
Subject: [PATCH] drm/radeon/kms: add common lvds modes in the ddc case
previous patch only handled the non-ddc case.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_connectors.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index c44871c..04ecb11 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -236,6 +236,10 @@ static int radeon_lvds_get_modes(struct
drm_connector *connector)
if (radeon_connector-ddc_bus) {
ret = radeon_ddc_get_modes(radeon_connector);
if (ret 0) {
+ encoder = radeon_best_single_encoder(connector);
+ if (encoder)
+ /* add scaled modes */
+ radeon_add_common_modes(encoder, connector);
return ret;
}
}
@@ -249,11 +253,10 @@ static int radeon_lvds_get_modes(struct
drm_connector *connector)
if (mode) {
ret = 1;
drm_mode_probed_add(connector, mode);
+ /* add scaled modes */
+ radeon_add_common_modes(encoder, connector);
}
- /* add scaled modes */
- radeon_add_common_modes(encoder, connector);
-
return ret;
}
--
1.5.6.3
From 702fd0710dad9c2f7767e98f6b650a8481a33c93 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 11 Sep 2009 11:15:43 -0400
Subject: [PATCH] drm/radeon/kms: add common lvds modes in the ddc case
previous patch only handled the non-ddc case.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_connectors.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index c44871c..04ecb11 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -236,6 +236,10 @@ static int radeon_lvds_get_modes(struct drm_connector *connector)
if (radeon_connector-ddc_bus) {
ret = radeon_ddc_get_modes(radeon_connector);
if (ret 0) {
+ encoder = radeon_best_single_encoder(connector);
+ if (encoder)
+/* add scaled modes */
+radeon_add_common_modes(encoder, connector);
return ret;
}
}
@@ -249,11 +253,10 @@ static int radeon_lvds_get_modes(struct drm_connector *connector)
if (mode) {
ret = 1;
drm_mode_probed_add(connector, mode);
+ /* add scaled modes */
+ radeon_add_common_modes(encoder, connector);
}
- /* add scaled modes */
- radeon_add_common_modes(encoder, connector);
-
return ret;
}
--
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] drm/radeon/kms/r600: fix blit dword count for non r6xx
From 1999443c55a989969ef0a9cc12167c058142ad3c Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Fri, 11 Sep 2009 12:02:03 -0400 Subject: [PATCH] drm/radeon/kms/r600: fix blit dword count for non r6xx rv6xx emits two extra dwords in the render target setup. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/r600_blit_kms.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c b/drivers/gpu/drm/radeon/r600_blit_kms.c index bbb0d61..1ebfd5a 100644 --- a/drivers/gpu/drm/radeon/r600_blit_kms.c +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c @@ -550,6 +550,12 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int size_bytes) int r; int ring_size; int max_size; + /* loops of emits 64 + fence emit possible */ + int dwords_per_loop = 76; + + /* set_render_target emits 2 extra dwords on rv6xx */ + if (rdev-family CHIP_R600 rdev-family CHIP_RV770) + dwords_per_loop += 2; /* 8 bpp vs 32 bpp for xfer unit */ if (size_bytes 3) @@ -560,8 +566,7 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int size_bytes) r = r600_vb_ib_get(rdev); WARN_ON(r); - /* loops of emits 64 + fence emit possible */ - ring_size = ((size_bytes + max_size) / max_size) * 78; + ring_size = ((size_bytes + max_size) / max_size) * dwords_per_loop; /* set default + shaders */ ring_size += 40; /* shaders + def state */ ring_size += 3; /* fence emit for VB IB */ -- 1.5.6.3 From 1999443c55a989969ef0a9cc12167c058142ad3c Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Fri, 11 Sep 2009 12:02:03 -0400 Subject: [PATCH] drm/radeon/kms/r600: fix blit dword count for non r6xx rv6xx emits two extra dwords in the render target setup. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/r600_blit_kms.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c b/drivers/gpu/drm/radeon/r600_blit_kms.c index bbb0d61..1ebfd5a 100644 --- a/drivers/gpu/drm/radeon/r600_blit_kms.c +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c @@ -550,6 +550,12 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int size_bytes) int r; int ring_size; int max_size; + /* loops of emits 64 + fence emit possible */ + int dwords_per_loop = 76; + + /* set_render_target emits 2 extra dwords on rv6xx */ + if (rdev-family CHIP_R600 rdev-family CHIP_RV770) + dwords_per_loop += 2; /* 8 bpp vs 32 bpp for xfer unit */ if (size_bytes 3) @@ -560,8 +566,7 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, int size_bytes) r = r600_vb_ib_get(rdev); WARN_ON(r); - /* loops of emits 64 + fence emit possible */ - ring_size = ((size_bytes + max_size) / max_size) * 78; + ring_size = ((size_bytes + max_size) / max_size) * dwords_per_loop; /* set default + shaders */ ring_size += 40; /* shaders + def state */ ring_size += 3; /* fence emit for VB IB */ -- 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] drm/radeon/kms: fix typo in quirks
From 465dbcc9e66b200e6ed453818ddbf30a263b2f95 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 11 Sep 2009 15:27:14 -0400
Subject: [PATCH] drm/radeon/kms: fix typo in quirks
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 4dff85b..aa756de 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -148,7 +148,7 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
(dev-pdev-subsystem_vendor == 0x1043)
(dev-pdev-subsystem_device == 0x01da)) {
if (*connector_type == DRM_MODE_CONNECTOR_HDMIA) {
- *connector_type = DRM_MODE_CONNECTOR_DVID;
+ *connector_type = DRM_MODE_CONNECTOR_DVII;
}
}
@@ -157,7 +157,7 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
(dev-pdev-subsystem_vendor == 0x1043)
(dev-pdev-subsystem_device == 0x01e2)) {
if (*connector_type == DRM_MODE_CONNECTOR_HDMIA) {
- *connector_type = DRM_MODE_CONNECTOR_DVID;
+ *connector_type = DRM_MODE_CONNECTOR_DVII;
}
}
--
1.5.6.3
From 465dbcc9e66b200e6ed453818ddbf30a263b2f95 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 11 Sep 2009 15:27:14 -0400
Subject: [PATCH] drm/radeon/kms: fix typo in quirks
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c
index 4dff85b..aa756de 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -148,7 +148,7 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
(dev-pdev-subsystem_vendor == 0x1043)
(dev-pdev-subsystem_device == 0x01da)) {
if (*connector_type == DRM_MODE_CONNECTOR_HDMIA) {
- *connector_type = DRM_MODE_CONNECTOR_DVID;
+ *connector_type = DRM_MODE_CONNECTOR_DVII;
}
}
@@ -157,7 +157,7 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
(dev-pdev-subsystem_vendor == 0x1043)
(dev-pdev-subsystem_device == 0x01e2)) {
if (*connector_type == DRM_MODE_CONNECTOR_HDMIA) {
- *connector_type = DRM_MODE_CONNECTOR_DVID;
+ *connector_type = DRM_MODE_CONNECTOR_DVII;
}
}
--
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
[Bug 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 Carl Worth cwo...@cworth.org changed: What|Removed |Added Keywords||NEEDINFO -- 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: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
No thats where you got it wrong, a driver should never *require* version of interface at runtime == version of interface at build time. We rarely make incompatible major number changes in the kernel drivers, (radeon kms being the first in my memory). DRM drivers ship in the kernel, not separately so dealing with inequality of version isn't optional. It is exactly such a major change that made this version numbering necessary in the header file. So from what I can see this solves a compile time problem, not a run time. Generally this has been solved in other ways, either requiring when the driver needs a newer version of the header it requires a new libdrm or when the driver needs a newer version of the header it ships it within itself. No it is not, the interfaces are not compatible. This patch will not be put in everywhere immediately. How does a graphics driver give the user a reason for why the whole thing came crashing down, while things worked just fine before the kernel update that joe user most likely will not immediately see as the reason for this breakage? Okay incompatible interfaces are not acceptable unless they are major version number changes. Minor or patch version changes should not break the kernel interface in any way unless its a major security hole being solved, and even then a major version bump is probably preferred. Userspace should always be able to work with the major number it expects, it can also place a lower bound on minor numbers if it wants, but it should not require an equality of minor or path. If we have shipped a minor version bump in the upstream kernel that breaks userspace point it out and I'll revert it. Now if a certain vendor ships kernel patches without testing or posting them upstream first, then there isn't much we can do except bitch at the clueless maintainers of that kernel. I really do not see what the problem is with having the driver version carried around in the interface headerfile. X driver, mesa and drm driver build with that. drm claims this version. If this version is not compatible, both X driver and mesa can then try to handle this gracefully. If you choose to have the driver fail hard with an error message, then fine, it at least is better than having half the userbase complain that their drm wasn't initialised fully, for no visible reason. The thing is the major number is all you should need to carry really, the userspace API isn't just defined by this header file, other thing internal to the module can affect the API like the command stream verifier. So the kernel could require a drm minor bump for some new verifier restriction, and this header file wouldn't change at all, or would just have a pointless version number bump. So the kernel version should not be tied directly to this file version either. Its just not been required before and I'd like to understand why no-one else has had the requirement over the other 8 or so drm/dri drivers produced. Generally I think we avoid it because it links the build and runtime versioning, which isn't something that a driver should ever do. Isn't versioning a common scheme to be able to handle both run and build time compatibility in a halfdecent manner? What use is runtime-only or buildtime-only versioning? Are you against this because carrying a versioning information makes it possible to do major changes gracefully and therefor encourages major changes and therefor is totally unacceptable? It doesn't allow for major version number changes gracefully at all, nothing does, if the kernel suddenly only produces a version 3.0 via drm API it will break all current VIA userspace drivers, this would never be acceptable *ever*. For KMS we have made an exception as its a requirement that people update userspace to enable KMS, but we've also made sure we enver enable these by deafult upstream, only at a distro level where hopefully they realise they need a compat userspace before turning stuff on. We discussed it out fully 3.5 years ago, and TH committed it 3.5ys ago, and he has nicely kept up the version bumping since from his side. What is it that you still require here? A clean updated patch to the kernel, but really nothing you've said convinces me in any way this isn't just an attempt to workaround a crap developemnt process where nobody is maintaining API compatability. Is this not an attempt? generally all patches to the drm go to this list first, yes maybe they should also go to *chrome lists, but maybe developers who care should be more involved with the dri process instead of having their own one on a list that is somewhere else. The questions we ask here are generally: a) does this break runtime ABI in a backwards incompatible manner? b) does this patch have major style problems. So far (b) is true, and you've stated (a) is true but I haven't seen the lines in
[PATCH 1/5] [drm]: make drm_mode_object_find typesafe
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ba728ad..78eeec7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -247,7 +247,8 @@ static void drm_mode_object_put(struct drm_device *dev,
mutex_unlock(dev-mode_config.idr_mutex);
}
-void *drm_mode_object_find(struct drm_device *dev, uint32_t id, uint32_t type)
+struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
+ uint32_t id, uint32_t type)
{
struct drm_mode_object *obj = NULL;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ae1e9e1..f4c0fbc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -699,7 +699,8 @@ extern void drm_mode_connector_detach_encoder(struct
drm_connector *connector,
struct drm_encoder *encoder);
extern bool drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-extern void *drm_mode_object_find(struct drm_device *dev, uint32_t id,
uint32_t type);
+extern struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
+ uint32_t id, uint32_t type);
/* IOCTLs */
extern int drm_mode_getresources(struct drm_device *dev,
void *data, struct drm_file *file_priv);
--
1.6.3.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 2/5] [drm/i915]: require_pipe_a helper functions
These will be used to ensure that the clock of pipe a is running
when the overlay is switched on. Programming logic more or less
directly ported over from userspace.
Also export the already existing helper function drm_encoder_crtc_ok.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc_helper.c|3 +-
drivers/gpu/drm/i915/intel_display.c | 83 ++
drivers/gpu/drm/i915/intel_drv.h |5 ++
include/drm/drm_crtc_helper.h|2 +
4 files changed, 92 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ff447f1..13afdfe 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -488,7 +488,7 @@ static void drm_setup_crtcs(struct drm_device *dev)
*
* Return false if @encoder can't be driven by @crtc, true otherwise.
*/
-static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
+bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
struct drm_crtc *crtc)
{
struct drm_device *dev;
@@ -509,6 +509,7 @@ static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
return true;
return false;
}
+EXPORT_SYMBOL(drm_encoder_crtc_ok);
/*
* Check the CRTC we're going to map each output to vs. its current
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 155719f..d0a74e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3069,6 +3069,89 @@ void intel_release_load_detect_pipe(struct intel_output
*intel_output, int dpms_
}
}
+/** Ensure that pipe A is enabled. Returns the crtc that runs pipe A or NULL
+ * if pipe A is already enabled */
+struct drm_crtc *intel_require_pipe_a_start(struct drm_device *dev,
+ int *dpms_mode)
+{
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
+ struct drm_connector *connector;
+ struct drm_crtc_helper_funcs *crtc_funcs;
+ struct intel_output *intel_output;
+
+ crtc = intel_get_crtc_from_pipe(dev, 0);
+ intel_crtc = to_intel_crtc(crtc);
+ BUG_ON(intel_crtc-pipe != 0);
+
+ if (crtc-enabled intel_crtc-dpms_mode == DRM_MODE_DPMS_ON)
+ return NULL;
+
+ DRM_DEBUG(i915: require PIPEA, switching on crtc ...\n);
+
+ *dpms_mode = intel_crtc-dpms_mode;
+
+ if (crtc-enabled intel_crtc-dpms_mode != DRM_MODE_DPMS_ON) {
+ /* just switch it on */
+ crtc_funcs = crtc-helper_private;
+ crtc_funcs-dpms(crtc, DRM_MODE_DPMS_ON);
+
+ return crtc;
+ }
+
+ if (!drm_helper_crtc_in_use(crtc)) {
+ /* look for an encoder/connector */
+ list_for_each_entry(connector,
+ dev-mode_config.connector_list, head) {
+ intel_output = to_intel_output(connector);
+
+ if (intel_output-enc.crtc)
+ /* don't steal connectors */
+ continue;
+
+ if (!drm_encoder_crtc_ok(intel_output-enc, crtc))
+ continue;
+
+ intel_output-enc.crtc = crtc;
+ break;
+ }
+ }
+
+ drm_crtc_helper_set_mode(crtc, load_detect_mode, 0, 0, crtc-fb);
+ WARN_ON(!crtc-enabled);
+
+ return crtc;
+}
+
+void intel_require_pipe_a_end(struct drm_device *dev,
+ struct drm_crtc *crtc,
+ int dpms_mode)
+{
+ struct drm_encoder_helper_funcs *encoder_funcs;
+ struct drm_encoder *encoder;
+ struct drm_crtc_helper_funcs *crtc_funcs;
+
+ if (!crtc)
+ return;
+
+ crtc_funcs = crtc-helper_private;
+
+ DRM_DEBUG(i915: require PIPEA, switching off crtc ...\n);
+
+ /* Switch crtc and output back off if necessary */
+ if (crtc-enabled dpms_mode != DRM_MODE_DPMS_ON) {
+ list_for_each_entry(encoder,
+ dev-mode_config.encoder_list, head) {
+ if (encoder-crtc != crtc)
+ continue;
+ encoder_funcs = encoder-helper_private;
+ encoder_funcs-dpms(encoder, dpms_mode);
+ }
+
+ crtc_funcs-dpms(crtc, dpms_mode);
+ }
+}
+
/* Returns the clock of the currently programmed mode of the given pipe. */
static int intel_crtc_clock_get(struct drm_device *dev, struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b9e47f1..33e6980 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -163,6 +163,11 @@ extern struct drm_crtc *intel_get_load_detect_pipe(struct
intel_output
[PATCH] drm/radeon/kms: cleanup - remove radeon_share.h
radeon_share.h was begining to give problem with include order in
respect of radeon.h. It's easier and also i think cleaner to move
what was in radeon_share.h into radeon.h. At the same time use the
extern keyword for function shared accross the module.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/r520.c |1 -
drivers/gpu/drm/radeon/r600.c |1 -
drivers/gpu/drm/radeon/r600_cs.c |1 -
drivers/gpu/drm/radeon/radeon.h | 93 ---
drivers/gpu/drm/radeon/radeon_share.h | 116 -
drivers/gpu/drm/radeon/rs400.c|1 -
drivers/gpu/drm/radeon/rv515.c|1 -
drivers/gpu/drm/radeon/rv770.c|1 -
9 files changed, 84 insertions(+), 132 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/radeon_share.h
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 92f9cb7..ced3322 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -31,7 +31,6 @@
#include radeon_reg.h
#include radeon.h
#include radeon_drm.h
-#include radeon_share.h
#include r100_track.h
#include r300d.h
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index ebd6b0f..0e1686d 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -28,7 +28,6 @@
#include drmP.h
#include radeon_reg.h
#include radeon.h
-#include radeon_share.h
/* r520,rv530,rv560,rv570,r580 depends on : */
void r100_hdp_reset(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d8fcef4..1bc2567 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -32,7 +32,6 @@
#include radeon_drm.h
#include radeon.h
#include radeon_mode.h
-#include radeon_share.h
#include r600d.h
#include avivod.h
#include atom.h
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 39bf634..33b89cd 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -27,7 +27,6 @@
*/
#include drmP.h
#include radeon.h
-#include radeon_share.h
#include r600d.h
#include avivod.h
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e314756..8cec5bf 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -50,7 +50,6 @@
#include linux/kref.h
#include radeon_mode.h
-#include radeon_share.h
#include radeon_reg.h
/*
@@ -640,11 +639,55 @@ struct radeon_asic {
void (*bandwidth_update)(struct radeon_device *rdev);
};
+/*
+ * Asic structures
+ */
struct r100_asic {
const unsigned *reg_safe_bm;
unsignedreg_safe_bm_size;
};
+struct r300_asic {
+ const unsigned *reg_safe_bm;
+ unsignedreg_safe_bm_size;
+};
+
+struct r600_asic {
+ unsigned max_pipes;
+ unsigned max_tile_pipes;
+ unsigned max_simds;
+ unsigned max_backends;
+ unsigned max_gprs;
+ unsigned max_threads;
+ unsigned max_stack_entries;
+ unsigned max_hw_contexts;
+ unsigned max_gs_threads;
+ unsigned sx_max_export_size;
+ unsigned sx_max_export_pos_size;
+ unsigned sx_max_export_smx_size;
+ unsigned sq_num_cf_insts;
+};
+
+struct rv770_asic {
+ unsigned max_pipes;
+ unsigned max_tile_pipes;
+ unsigned max_simds;
+ unsigned max_backends;
+ unsigned max_gprs;
+ unsigned max_threads;
+ unsigned max_stack_entries;
+ unsigned max_hw_contexts;
+ unsigned max_gs_threads;
+ unsigned sx_max_export_size;
+ unsigned sx_max_export_pos_size;
+ unsigned sx_max_export_smx_size;
+ unsigned sq_num_cf_insts;
+ unsigned sx_num_of_sets;
+ unsigned sc_prim_fifo_size;
+ unsigned sc_hiz_tile_fifo_size;
+ unsigned sc_earlyz_tile_fifo_fize;
+};
+
union radeon_asic_config {
struct r300_asicr300;
struct r100_asicr100;
@@ -935,9 +978,14 @@ static inline void radeon_ring_write(struct radeon_device
*rdev, uint32_t v)
#define radeon_bandwidth_update(rdev) (rdev)-asic-bandwidth_update((rdev))
/* Common functions */
-int radeon_modeset_init(struct radeon_device *rdev);
-void radeon_modeset_fini(struct radeon_device *rdev);
+extern int radeon_modeset_init(struct radeon_device *rdev);
+extern void radeon_modeset_fini(struct radeon_device *rdev);
extern bool radeon_card_posted(struct radeon_device *rdev);
+extern int radeon_clocks_init(struct radeon_device *rdev);
+extern void radeon_clocks_fini(struct radeon_device *rdev);
+extern void radeon_scratch_init(struct radeon_device *rdev);
+extern void radeon_surface_init(struct radeon_device *rdev);
+extern int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data);
/* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */
struct r100_mc_save {
[PATCH 3/5] [drm/i915]: add i915_lp_ring_sync helper
This just waits until the hw passed the current ring position with
cmd execution. This slightly changes the existing i915_wait_request
function to make uninterruptible waiting possible - no point in
returning to userspace while mucking around with the overlay, that
piece of hw is just too fragile.
Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
include/drm/drm_os_linux.h |2 +-
3 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77ed060..4dfc9d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -708,6 +708,7 @@ void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int i915_gem_do_init(struct drm_device *dev, unsigned long start,
unsigned long end);
int i915_gem_idle(struct drm_device *dev);
+int i915_lp_ring_sync(struct drm_device *dev);
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int i915_gem_object_set_to_gtt_domain(struct drm_gem_object *obj,
int write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 954fb69..00dbc2c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1738,12 +1738,8 @@ i915_gem_retire_work_handler(struct work_struct *work)
mutex_unlock(dev-struct_mutex);
}
-/**
- * Waits for a sequence number to be signaled, and cleans up the
- * request and object lists appropriately for that event.
- */
static int
-i915_wait_request(struct drm_device *dev, uint32_t seqno)
+i915_do_wait_request(struct drm_device *dev, uint32_t seqno, int interruptible)
{
drm_i915_private_t *dev_priv = dev-dev_private;
u32 ier;
@@ -1765,10 +1761,17 @@ i915_wait_request(struct drm_device *dev, uint32_t
seqno)
dev_priv-mm.waiting_gem_seqno = seqno;
i915_user_irq_get(dev);
- ret = wait_event_interruptible(dev_priv-irq_queue,
-
i915_seqno_passed(i915_get_gem_seqno(dev),
-seqno) ||
- dev_priv-mm.wedged);
+ if (interruptible)
+ ret = wait_event_interruptible(dev_priv-irq_queue,
+
i915_seqno_passed(i915_get_gem_seqno(dev),
+seqno) ||
+ dev_priv-mm.wedged);
+ else
+ wait_event(dev_priv-irq_queue,
+
i915_seqno_passed(i915_get_gem_seqno(dev),
+seqno) ||
+ dev_priv-mm.wedged);
+
i915_user_irq_put(dev);
dev_priv-mm.waiting_gem_seqno = 0;
}
@@ -1790,6 +1793,34 @@ i915_wait_request(struct drm_device *dev, uint32_t seqno)
return ret;
}
+/**
+ * Waits for a sequence number to be signaled, and cleans up the
+ * request and object lists appropriately for that event.
+ */
+static int
+i915_wait_request(struct drm_device *dev, uint32_t seqno)
+{
+ return i915_do_wait_request(dev, seqno, 1);
+}
+
+/**
+ * Waits for the ring to finish up to the latest request. Usefull for waiting
+ * for flip events, e.g for the overlay support. */
+int i915_lp_ring_sync(struct drm_device *dev)
+{
+ uint32_t seqno;
+ int ret;
+
+ seqno = i915_add_request(dev, NULL, 0);
+
+ if (seqno == 0)
+ return -ENOMEM;
+
+ ret = i915_do_wait_request(dev, seqno, 0);
+ BUG_ON(ret == -ERESTARTSYS);
+ return ret;
+}
+
static void
i915_gem_flush(struct drm_device *dev,
uint32_t invalidate_domains,
@@ -1856,7 +1887,7 @@ i915_gem_flush(struct drm_device *dev,
#endif
BEGIN_LP_RING(2);
OUT_RING(cmd);
- OUT_RING(0); /* noop */
+ OUT_RING(MI_NOOP);
ADVANCE_LP_RING();
}
}
diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 26641e9..3933691 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -123,5 +123,5 @@ do {
\
remove_wait_queue((queue), entry);\
} while (0)
-#define DRM_WAKEUP( queue ) wake_up_interruptible( queue )
+#define DRM_WAKEUP( queue ) wake_up( queue )
#define DRM_INIT_WAITQUEUE( queue ) init_waitqueue_head( queue )
--
1.6.3.3
--
Let Crystal
[PATCH 4/5] [drm/i915]: kill superflous IS_I855 macro
It is identical to I85X. Use that one instead.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_display.c |4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4dfc9d1..2573ee0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -845,7 +845,6 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
#define IS_I830(dev) ((dev)-pci_device == 0x3577)
#define IS_845G(dev) ((dev)-pci_device == 0x2562)
#define IS_I85X(dev) ((dev)-pci_device == 0x3582)
-#define IS_I855(dev) ((dev)-pci_device == 0x3582)
#define IS_I865G(dev) ((dev)-pci_device == 0x2572)
#define IS_I915G(dev) ((dev)-pci_device == 0x2582 || (dev)-pci_device ==
0x258a)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d0a74e5..b85a6cc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1741,7 +1741,7 @@ static int intel_get_core_clock_speed(struct drm_device
*dev)
}
} else if (IS_I865G(dev))
return 266000;
- else if (IS_I855(dev)) {
+ else if (IS_I85X(dev)) {
u16 hpllcc = 0;
/* Assume that the hardware is in the high speed state. This
* should be the default.
@@ -3902,7 +3902,7 @@ void intel_init_clock_gating(struct drm_device *dev)
dstate |= DSTATE_PLL_D3_OFF | DSTATE_GFX_CLOCK_GATING |
DSTATE_DOT_CLOCK_GATING;
I915_WRITE(D_STATE, dstate);
- } else if (IS_I855(dev) || IS_I865G(dev)) {
+ } else if (IS_I85X(dev) || IS_I865G(dev)) {
I915_WRITE(RENCLK_GATE_D1, SV_CLOCK_GATE_DISABLE);
} else if (IS_I830(dev)) {
I915_WRITE(DSPCLK_GATE_D, OVRUNIT_CLOCK_GATE_DISABLE);
--
1.6.3.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 5/5] [drm/i915] implement drmmode overlay support v3
This implements intel overlay support for kms via a device-specific
ioctl. Thomas Hellstrom brought up the idea of a general ioctl (on
dri-devel). We've reached the conclusion that such an infrastructure
only makes sense when multiple kms overlay implementations exists,
which atm don't (and it doesn't look like this is gonna change).
Open issues:
- Runs in sync with the gpu, i.e. unnecessary waiting. I've decided
to wait with this because the hw tends to hang when changing something
in this area. I left some dummy functions as infrastructure.
- polyphase filtering uses a static table.
- uses uninterruptible sleeps. Unfortunately the alternatives may
unnecessarily wedged the hw if/when we timeout too early (and
userspace only overloaded the batch buffers with stuff worth a few
secs of gpu time).
Changes since v1:
- fix off-by-one misconception on my side. This fixes fullscreen
playback.
Changes since v2:
- add underrun detection as spec'ed for i965.
- flush caches properly, fixing visual corruptions.
Tested-By: diego.abele...@gmail.com (on a 865G)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_dma.c |7 +
drivers/gpu/drm/i915/i915_drv.h |4 +
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 30 +
drivers/gpu/drm/i915/intel_overlay.c | 1293 ++
include/drm/i915_drm.h | 71 ++
8 files changed, 1434 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_overlay.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5269dfa..b2f030c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -22,6 +22,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_fb.o \
intel_tv.o \
intel_dvo.o \
+ intel_overlay.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
dvo_ivch.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9909505..5747e4c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -800,6 +800,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_NUM_FENCES_AVAIL:
value = dev_priv-num_fence_regs - dev_priv-fence_reg_start;
break;
+ case I915_PARAM_HAS_OVERLAY:
+ value = dev_priv-overlay ? 1 : 0;
+ break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
@@ -1345,6 +1348,8 @@ int i915_driver_unload(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
drm_mm_takedown(dev_priv-vram);
i915_gem_lastclose(dev);
+
+ intel_cleanup_overlay(dev);
}
pci_dev_put(dev_priv-bridge_dev);
@@ -1452,6 +1457,8 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF(DRM_I915_GEM_GET_TILING, i915_gem_get_tiling, 0),
DRM_IOCTL_DEF(DRM_I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
0),
DRM_IOCTL_DEF(DRM_I915_GET_PIPE_FROM_CRTC_ID,
intel_get_pipe_from_crtc_id, 0),
+ DRM_IOCTL_DEF(DRM_I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CONTROL_ALLOW),
+ DRM_IOCTL_DEF(DRM_I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW),
};
int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2573ee0..f8edd9d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -148,6 +148,7 @@ struct drm_i915_error_state {
struct timeval time;
};
+struct intel_overlay;
typedef struct drm_i915_private {
struct drm_device *dev;
@@ -206,6 +207,9 @@ typedef struct drm_i915_private {
struct intel_opregion opregion;
+ /* overlay */
+ struct intel_overlay *overlay;
+
/* LVDS info */
int backlight_duty_cycle; /* restore backlight to this value */
bool panel_wants_dither;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e38cd21..690afe2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -135,6 +135,7 @@
#define MI_NOOPMI_INSTR(0, 0)
#define MI_USER_INTERRUPT MI_INSTR(0x02, 0)
#define MI_WAIT_FOR_EVENT MI_INSTR(0x03, 0)
+#define MI_WAIT_FOR_OVERLAY_FLIP (116)
#define MI_WAIT_FOR_PLANE_B_FLIP (16)
#define MI_WAIT_FOR_PLANE_A_FLIP (12)
#define MI_WAIT_FOR_PLANE_A_SCANLINES (11)
@@ -146,6 +147,10 @@
#define MI_END_SCENE (1 4) /* flush binner and incr scene count */
#define MI_BATCH_BUFFER_ENDMI_INSTR(0x0a, 0)
#define MI_REPORT_HEAD MI_INSTR(0x07, 0)
[PATCH 0/5] kms overlay support v2
Hi all, Thanks to Jesse's hint I've finally fixed the visual corruptions. Patch series is against latest drm-next. I'll repost the ddx cleanups as soon as 2.9 is out of the door and the drmmode overlay implementation somewhen later, when the kernel side has hit a stable release. I've tried to summarize the outcomes of various discussion in the changelog. Please review and consider for .32. Thanks, Daniel Daniel Vetter (5): [drm]: make drm_mode_object_find typesafe [drm/i915]: require_pipe_a helper functions [drm/i915]: add i915_lp_ring_sync helper [drm/i915]: kill superflous IS_I855 macro [drm/i915] implement drmmode overlay support v3 drivers/gpu/drm/drm_crtc.c |3 +- drivers/gpu/drm/drm_crtc_helper.c|3 +- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/i915_dma.c |7 + drivers/gpu/drm/i915/i915_drv.h |6 +- drivers/gpu/drm/i915/i915_gem.c | 51 ++- drivers/gpu/drm/i915/i915_reg.h |5 + drivers/gpu/drm/i915/intel_display.c | 113 +++- drivers/gpu/drm/i915/intel_drv.h | 35 + drivers/gpu/drm/i915/intel_overlay.c | 1293 ++ include/drm/drm_crtc.h |3 +- include/drm/drm_crtc_helper.h|2 + include/drm/drm_os_linux.h |2 +- include/drm/i915_drm.h | 71 ++ 14 files changed, 1575 insertions(+), 20 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay.c -- 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: move mtrr range add and memory information
Move mtrr range and memory information printing to radeon_object_init,
this are memory information and initialization common to all GPU and
they better fit in this function. Will also prevent code duplication
with upcoming init path changes.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_device.c |8
drivers/gpu/drm/radeon/radeon_object.c |7 +++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 72f6262..07ef8b6 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -598,14 +598,6 @@ int radeon_device_init(struct radeon_device *rdev,
/* Get vram informations */
radeon_vram_info(rdev);
- /* Add an MTRR for the VRAM */
- rdev-mc.vram_mtrr = mtrr_add(rdev-mc.aper_base,
rdev-mc.aper_size,
- MTRR_TYPE_WRCOMB, 1);
- DRM_INFO(Detected VRAM RAM=%uM, BAR=%uM\n,
- (unsigned)(rdev-mc.mc_vram_size 20),
- (unsigned)(rdev-mc.aper_size 20));
- DRM_INFO(RAM width %dbits %cDR\n,
- rdev-mc.vram_width, rdev-mc.vram_is_ddr ? 'D'
: 'S');
/* Initialize memory controller (also test AGP) */
r = radeon_mc_init(rdev);
if (r) {
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index b85fb83..8992085 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -369,6 +369,13 @@ void radeon_object_force_delete(struct radeon_device *rdev)
int radeon_object_init(struct radeon_device *rdev)
{
+ /* Add an MTRR for the VRAM */
+ rdev-mc.vram_mtrr = mtrr_add(rdev-mc.aper_base, rdev-mc.aper_size,
+ MTRR_TYPE_WRCOMB, 1);
+ DRM_INFO(Detected VRAM RAM=%lluM, BAR=%lluM\n,
+ rdev-mc.mc_vram_size 20, rdev-mc.aper_size 20);
+ DRM_INFO(RAM width %dbits %cDR\n,
+ rdev-mc.vram_width, rdev-mc.vram_is_ddr ? 'D' : 'S');
return radeon_ttm_init(rdev);
}
--
1.6.4.2
--
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: Add async event synchronization for drmWaitVblank
On Fri, 11 Sep 2009 14:33:34 -0400 Kristian Høgsberg k...@bitplanet.net wrote: This patch adds a new flag to the drmWaitVblank ioctl, which asks the drm to return immediately and notify userspace when the specified vblank sequence happens by sending an event back on the drm fd. The event mechanism works with the other flags supported by the ioctls, specifically, the vblank sequence can be specified relatively or absolutely, and works for primary and seconday crtc. The signal field of the vblank request is used to provide user data, which will be sent back to user space in the vblank event. Signed-off-by: Kristian Høgsberg k...@redhat.com --- Looks nice, we should get this into 2.6.32. The last page flip patch should be approximately ready too right? IIRC the only thing left on the kernel side was to add some padding to the request struct; the rest was userland and driver specific stuff (though I'll have to go through the discussion to be sure). Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- 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 22271] On 64bit kernel(drm-next-radeon) ioctls from 32bit application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=22271 --- Comment #11 from Krzysztof A. Sobiecki sob...@gmail.com 2009-09-11 19:12:32 PST --- For drmRadeonCmdBuffer: -14 bug I have created separate bug #23626 -- 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
