Message: 2 Date: Thu, 3 Mar 2011 16:51:28 -0800 From: Jesse Barnes jbarnes@virtuousgeek.org Subject: Re: vblank problem (and proposed fix) on crtc > 1 To: Ilija Hadzic ihadzic@research.bell-labs.com Cc: dri-devel@lists.freedesktop.org Message-ID: 20110303165128.495158c9@jbarnes-vaio.home Content-Type: text/plain; charset=US-ASCII
On Thu, 3 Mar 2011 17:34:53 -0600 (CST) Ilija Hadzic ihadzic@research.bell-labs.com wrote:
The fix/improvement I propose is to extend the request.type field in drmVBlank structure with additional 5 bits that I call high_crtc (there are lots of unused bits in that field). 5 bits covers for 32 CRTCs, which seems to be the hard limit imposed by various parts of the Xorg and DDX (e.g. possible_crtcs mask in the display descriptor, and the like). If high_crtc is zero, then DRM (kernel module) looks at the primary/secondary flag and maps them to crtc 0 and 1 (backwards compatibility with older DDX or DDX for other device that does not use the new high_crtc field). If it's not zero then it means that the higher CRTC number is specified by DDX (i.e. userland is a new DDX) and vblank is waited on the specified CRTC (this is used only for crtc > 1, crtc 0 and 1, still use the old style).
Yeah, I think that should work, though another option would be to just add a new ioctl. That would make compat checking easy for new code; it could just call the new ioctl and if that returned -ENOTTY it could fall back to the old one and throw away the CRTC info or complain if the count was too high.
But you're right that when we re-wrote the code we fixed it to handle > 2 CRTCs, so it should be mostly ready for that (modulo testing, which it sounds like you're doing already).
Jesse
I'm all for it! On evergreen and other recent radeon's, swapbuffers can become really ugly without this extension.
As far as i can see, the vblank wait ioctl() is the only place (at least for GLX/X/ddx don't know about the other api's like EGL or libkms), that needs fixing for > 2 crtc's and these patches should do it fine. Code also looks correct to me.
Maybe a new ddx could check the (bumped) drm abi version number to decide if it should use the new or old method to protect against the "new ddx on old kernel" case?
Add a ...
Reviewed-by: Mario Kleiner mario.kleiner@tuebingen.mpg.de
...and a big ...
Acked-by: Mario Kleiner mario.kleiner@tuebingen.mpg.de
if you wish. Maybe it would be even possible to slip the small kernel patch into 2.6.38-rc? It is rather a bugfix than a new feature. -mario
Message: 3 Date: Thu, 3 Mar 2011 17:38:04 -0800 (PST) From: bugzilla-daemon@freedesktop.org Subject: [Bug 34588] Screen corruption when running gtkperf on awesomewm To: dri-devel@lists.freedesktop.org Message-ID: 20110304013804.C9B4F130009@annarchy.freedesktop.org Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=34588
--- Comment #2 from Jeff Cook jeff@deserettechnology.com 2011-03-03 17:38:04 PST --- Yes, disabling tiling fixes it.
I just tried this today and it is still occurring in new git builds. I guess it is probably a dupe of the linked bug. I haven't tested a git build of X yet, which apparently is the source of the bug.
-- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi? tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
Message: 4 Date: Thu, 3 Mar 2011 21:04:03 -0500 From: Matt Turner mattst88@gmail.com Subject: [PATCH] modeprint.c: use PRIu64 for printing uint64_t To: dri-devel@lists.freedesktop.org Message-ID: 1299204243-12379-1-git-send-email-mattst88@gmail.com
Signed-off-by: Matt Turner mattst88@gmail.com
tests/modeprint/modeprint.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c index 09b8df0..545ff40 100644 --- a/tests/modeprint/modeprint.c +++ b/tests/modeprint/modeprint.c @@ -36,6 +36,7 @@ #include <stdint.h> #include <unistd.h> #include <string.h> +#include <inttypes.h>
#include "xf86drm.h" #include "xf86drmMode.h" @@ -101,7 +102,7 @@ int printProperty(int fd, drmModeResPtr res, drmModePropertyPtr props, uint64_t if (props->count_values) { printf("\tvalues :"); for (j = 0; j < props->count_values; j++)
printf(" %llu", props->values[j]);
printf(" %" PRIu64, props->values[j]);@@ -116,7 +117,7 @@ int printProperty(int fd, drmModeResPtr res, drmModePropertyPtr props, uint64_t printf("blob is %d length, %08X\n", blob->length, *(uint32_t *) blob->data); drmModeFreePropertyBlob(blob); } else {
printf("error getting blob %llu\n", value);
printf("error getting blob %" PRIu64 "\n", value);}
} else {
@@ -132,7 +133,7 @@ int printProperty(int fd, drmModeResPtr res, drmModePropertyPtr props, uint64_t if (props->count_enums && name) { printf("\tcon_value : %s\n", name); } else {
printf("\tcon_value : %lld\n", value);
printf("\tcon_value : %" PRIu64 "\n", value);-- 1.7.3.4
Message: 5 Date: Thu, 3 Mar 2011 21:20:52 -0500 From: Matt Turner mattst88@gmail.com Subject: [PATCH] don't try to build modetest without libkms To: dri-devel@lists.freedesktop.org Message-ID: 1299205252-24952-1-git-send-email-mattst88@gmail.com
Signed-off-by: Matt Turner mattst88@gmail.com
tests/Makefile.am | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am index ebf4853..01ca8b4 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -16,9 +16,6 @@ if HAVE_LIBKMS SUBDIRS += kmstest endif
-if HAVE_INTEL -endif
if HAVE_LIBUDEV
check_LTLIBRARIES = libdrmtest.la @@ -50,9 +47,13 @@ TESTS = \ SUBDIRS += vbltest $(NULL)
if HAVE_INTEL +if HAVE_LIBKMS +SUBDIRS += \
- modetest
+endif
SUBDIRS += \ modeprint \
- modetest \ $(NULL)
TESTS += \
1.7.3.4
Message: 6 Date: Fri, 4 Mar 2011 07:53:15 +0100 (CET) From: "Indan Zupancic" indan@nul.nu Subject: Re: [PATCH] fix backlight brightness on intel LVDS panel after reopening lid To: "Linus Torvalds" torvalds@linux-foundation.org Cc: Linux Kernel Mailing List linux-kernel@vger.kernel.org, DRI mailing list dri-devel@lists.freedesktop.org, Alex Riesen raa.lkml@gmail.com, Tino Keitel tino.keitel@tikei.de, stable@kernel.org Message-ID: 3e6f092bd0aa54fd6b9eb524f6c87ecf.squirrel@webmail.greenhost.nl Content-Type: text/plain;charset=UTF-8
Hello,
On Wed, February 23, 2011 02:09, Linus Torvalds wrote:
On Tue, Feb 22, 2011 at 2:31 PM, Tino Keitel tino.keitel@tikei.de wrote:
I just tried 2.6.38-rc6 on my ThinkPad X61s without any other DRM related patches, and my backlight issue is gone.
I applied Indan's fix in -rc6 (commit 951f3512dba5), since it had several testers and seemed to simplify the code nicely too.
Sadly, as so often in life, it's not correct. At this point I'm not sure if it's better to revert that patch and add a correct one, or to just fix it up. The end result is the same I suppose. I've also found more documentation, namely: ACPI_IGD_OpRegion_Spec.pdf, which has the ASLE stuff in intel_opregion.c, and VOL_1_graphics_core.pdf, which mentions LBPC (I was looking at 3 before). Apparently the undocumented stuff the old code did was correct. What I don't understand is how BIOS makers could know about those bits.
The good side is that that big warning in my patch description is invalid, something else was going on: The BIOS used LBPC to set and restore brightness, while the driver only used BLC_PWM_CTL after my patch.
All credits to Intel for making something simple as backlight control as stupid and complex as possible:
- It has two registers to control brightness, sometimes one is used,
sometimes the other, sometimes both, and it's unknown what the BIOS uses, and it's undefined what registers are restored by the BIOS after reboot/resume.
- When using ACPI and ASLE, the kernel requests a brightness change
via a standard ACPI method, which in turns lets the BIOS generate an ASLE interrupt, which is handled by the driver. The brightness to set is between 0 and 255, and the driver is supposed to store the current brightness in another register. That register stores the brightness in percentages, which is used by the BIOS to restore brightness. How it does that is undefined, so it can use either register. So the BIOS obviously knows how to change the brightness, and it's still seemed like a good idea to bother the driver with it. The ASLE interface is a mess.
All in all, after my patch, systems using ASLE and a BIOS storing the brightness in LBPC stopped working. The reason it works without ASLE is because the brightness is never changed by the driver, the backlight is only enabled or disabled.
I'd love to clean up the whole backlight mess, but it's too late in the RC cycle to do that.
So please revert my patch and apply Takashi Iwai's, which fixes the most immediate bug without changing anything else. This should go in stable too.
From f6b8a45b9544072e6ddbb944a4c03a9ec8cbca3a Mon Sep 17 00:00:00 2001 From: Takashi
Iwai tiwai@suse.de Date: Mon, 21 Feb 2011 14:19:27 +0100 Subject: [PATCH] drm/i915: Fix calculation of backlight value in combined mode
The commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870 drm/i915: Refactor panel backlight controls causes a regression for GM45 that is using the combined mode for controlling the backlight brightness. The commit introduced a wrong bit shift for computing the current backlight level.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=672946 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Signed-off-by: Takashi Iwai tiwai@suse.de Cc: stable@kernel.org
drivers/gpu/drm/i915/intel_panel.c | 1 - 1 file changed, 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -176,7 +176,6 @@ val &= ~1; pci_read_config_byte(dev->pdev, PCI_LBPC, &lbpc); val *= lbpc;
val >>= 1;
Message: 7 Date: Thu, 3 Mar 2011 21:01:52 +0100 From: Paolo Ornati ornati@gmail.com Subject: Re: [2.6.38-rc6] G965: i915 Hangcheck timer elapsed... GPU hung (not reproducible) To: Nick Bowler nbowler@elliptictech.com Cc: Andrew Morton akpm@linux-foundation.org, Linux Kernel Mailing List linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Message-ID: 20110303210152.5750c239@gmail.com Content-Type: text/plain; charset=US-ASCII
On Wed, 2 Mar 2011 19:43:26 -0500 Nick Bowler nbowler@elliptictech.com wrote:
So you might want to try again with the latest git xf86-video- intel and see if it still happens.
xf86-video-intel bug or not the kernel should be able to reset the GPU I think... (I'm using KMS).
Anyway I'm using 2.6.38-rcX on this PC for a month, and it happened only once. This is the complete list of 2.6.38 based kernel I've used an when (login time):
Sun Jan 30 09:00:04 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Sun Jan 30 15:52:14 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Mon Jan 31 20:01:29 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Tue Feb 1 19:31:05 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Wed Feb 2 19:39:28 CET 2011 -- Linux tux 2.6.38-rc3 Thu Feb 3 19:22:14 CET 2011 -- Linux tux 2.6.38-rc3 Fri Feb 4 20:14:07 CET 2011 -- Linux tux 2.6.38-rc3 Sat Feb 5 08:09:57 CET 2011 -- Linux tux 2.6.38-rc3 Sun Feb 6 09:28:15 CET 2011 -- Linux tux 2.6.38-rc3 Sun Feb 6 13:09:55 CET 2011 -- Linux tux 2.6.38-rc3 Mon Feb 7 19:31:43 CET 2011 -- Linux tux 2.6.38-rc3 Tue Feb 8 19:56:27 CET 2011 -- Linux tux 2.6.38-rc3 Wed Feb 9 20:09:37 CET 2011 -- Linux tux 2.6.38-rc4 Fri Feb 11 20:01:20 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 09:16:32 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 12:28:23 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 14:39:15 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:05:29 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:20:37 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:23:49 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 20:44:18 CET 2011 -- Linux tux 2.6.38-rc4 Sun Feb 13 08:40:09 CET 2011 -- Linux tux 2.6.38-rc4 Sun Feb 13 13:11:28 CET 2011 -- Linux tux 2.6.38-rc4 Mon Feb 14 20:20:12 CET 2011 -- Linux tux 2.6.38-rc4 Tue Feb 15 20:28:22 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 19 08:55:51 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 19 09:56:02 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 13:50:37 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 18:05:28 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 20:12:05 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sun Feb 20 08:57:19 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sun Feb 20 18:05:43 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Mon Feb 21 20:22:51 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Tue Feb 22 20:02:13 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Wed Feb 23 20:06:45 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Thu Feb 24 20:15:23 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Fri Feb 25 20:04:37 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Sat Feb 26 09:18:44 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sat Feb 26 19:45:28 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 09:12:54 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 <--- GPU hung ;) Sun Feb 27 09:32:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 15:32:46 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 17:38:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Mon Feb 28 21:00:49 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Tue Mar 1 20:25:01 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Thu Mar 3 20:27:57 CET 2011 -- Linux tux 2.6.38-rc6-00212-g3e1f235
I'll see if it happens again...
-- Paolo Ornati Linux 2.6.38-rc6-00212-g3e1f235 on x86_64
Message: 8 Date: Fri, 4 Mar 2011 02:34:25 -0800 (PST) From: bugzilla-daemon@freedesktop.org Subject: [Bug 34929] [r300g] slowdown with r300g threading To: dri-devel@lists.freedesktop.org Message-ID: 20110304103425.80AC2130009@annarchy.freedesktop.org Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=34929
--- Comment #6 from Fabio Pedretti fabio.ped@libero.it 2011-03-04 02:34:24 PST --- (In reply to comment #5)
Come on, you cannot decently compare performance when running under GDB... GDB has its own thread overhead
The point is that on my system, for whatever reason, r300g threading make every application I tried slower (or at least not faster), with or without gdb. Running it under gdb amplifies the problem and may be a useful test case to further debug the problem to who, instead, got the speedups, possibly because on his system the thread management overhead is less than the benefit from using two CPU cores. Maybe it's possible to leave the thread always open without opening/exiting it many times.
-- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi? tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
End of dri-devel Digest, Vol 12, Issue 16
********************************************************************* Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany
e-mail: mario.kleiner@tuebingen.mpg.de office: +49 (0)7071/601-1623 fax: +49 (0)7071/601-616 www: http://www.kyb.tuebingen.mpg.de/~kleinerm ********************************************************************* "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." (Richard Feynman)