Message: 2
Date: Thu, 3 Mar 2011 16:51:28 -0800
From: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
Subject: Re: vblank problem (and proposed fix) on crtc > 1
To: Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx>
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <20110303165128.495158c9@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx> 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
------------------------------
Message: 3
Date: Thu, 3 Mar 2011 17:38:04 -0800 (PST)
From: bugzilla-daemon@xxxxxxxxxxxxxxx
Subject: [Bug 34588] Screen corruption when running gtkperf on
awesomewm
To: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <20110304013804.C9B4F130009@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=34588
--- Comment #2 from Jeff Cook <jeff@xxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxx>
Subject: [PATCH] modeprint.c: use PRIu64 for printing uint64_t
To: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <1299204243-12379-1-git-send-email-mattst88@xxxxxxxxx>
Signed-off-by: Matt Turner <mattst88@xxxxxxxxx>
---
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]);
printf("\n");
}
@@ -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@xxxxxxxxx>
Subject: [PATCH] don't try to build modetest without libkms
To: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <1299205252-24952-1-git-send-email-mattst88@xxxxxxxxx>
Signed-off-by: Matt Turner <mattst88@xxxxxxxxx>
---
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@xxxxxx>
Subject: Re: [PATCH] fix backlight brightness on intel LVDS panel
after reopening lid
To: "Linus Torvalds" <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, DRI
mailing list <dri-devel@xxxxxxxxxxxxxxxxxxxxx>, Alex Riesen
<raa.lkml@xxxxxxxxx>, Tino Keitel <tino.keitel@xxxxxxxx>,
stable@xxxxxxxxxx
Message-ID:
<3e6f092bd0aa54fd6b9eb524f6c87ecf.squirrel@xxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxx> 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@xxxxxxx>
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@xxxxxxx>
Cc: <stable@xxxxxxxxxx>
---
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@xxxxxxxxx>
Subject: Re: [2.6.38-rc6] G965: i915 Hangcheck timer elapsed... GPU
hung (not reproducible)
To: Nick Bowler <nbowler@xxxxxxxxxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing
List <linux-kernel@xxxxxxxxxxxxxxx>, dri-devel@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <20110303210152.5750c239@xxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII
On Wed, 2 Mar 2011 19:43:26 -0500
Nick Bowler <nbowler@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
Subject: [Bug 34929] [r300g] slowdown with r300g threading
To: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <20110304103425.80AC2130009@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=34929
--- Comment #6 from Fabio Pedretti <fabio.ped@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
End of dri-devel Digest, Vol 12, Issue 16
*****************************************
