[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #5 from Paul Menzel 2012-09-22 09:36:42 UTC --- (In reply to comment #4) > Patch sent to the dri-devel list [1]. > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-August/026476.html TLDR: A T60 with a 945GM/GMS(?) controller works without that patch with Linux 3.2.x. I am petrified. Testing this TV with a T60 and a different VGA cable (all pins populated, instead of Pin 9 missing) everything works fine (besides a little vertical shift to the right). :/ $ lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01) 15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller The read EDID is the same. $ xrandr -q --verbose […] VGA1 connected 1920x1080+0+0 (0xb9) normal (normal left inverted right x axis y axis) 1150mm x 650mm Identifier: 0x42 Timestamp: 222127 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: DVI1 CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 00001e6d010001010101 02130103687341780acf74a3574cb023 09484ca1080081806140454031400101 010101010101023a801871382d40582c 45007e8a421e011d007251d01e20 6e2855007e8a421e00fd003a 3e1e531a20202020202000fc 004c472054560a20202020202020001d 1920x1080 (0xb9) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz 1280x1024 (0x47) 108.0MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1280x720 (0xba) 74.2MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew0 clock 45.0KHz v: height 720 start 725 end 730 total 750 clock 60.0Hz 1024x768 (0x4c) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x4d) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 640x480 (0x4f) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 490 end
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #6 from Paul Menzel 2012-09-22 09:38:16 UTC --- Created attachment 67539 --> https://bugs.freedesktop.org/attachment.cgi?id=67539 `/var/log/Xorg.0.log` from T60 -- 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
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #7 from Paul Menzel 2012-09-22 09:39:18 UTC --- Created attachment 67540 --> https://bugs.freedesktop.org/attachment.cgi?id=67540 `xrandr -q --verbose` from T60 -- 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
[Bug 55217] New: [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 Bug #: 55217 Summary: [RS880] opengl not working anymore Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: micha...@gmx.org after updating mesa to latest git, i can not using opengl-apps anymore running glxgears give the following error message: EE r600_asm.c:121 r600_bytecode_get_num_operands - Need instruction operand number for 0xc testet with kernel 3.5.1 and 3.6.0-rc6 using xorg-server-1.12.2 and libdrm, mesa, xf86-video-ati from git removing xorg.conf gives the same error -- 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
Re: -next trees
Am Donnerstag, den 13.09.2012, 11:44 +1000 schrieb Dave Airlie: > Just a reminder to the subtree maintainers that I should be starting > to see signs of -next trees lining up soon, > > I've merged a bunch of patches from the list, but I'm sure I've forgotten > some, > I've got the 3 quirks from Paul that I'm iffy about due to the lack of > testing against VGA ports that ajax requested, but I could be turned. I am really sorry, but it looks like more testing is needed, so please revert them. :/ Testing on a T60 shows that it works out of the box. So it is either 915GM or cable problem. [1] I will answer to the single patches later on. […] Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5 signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #1 from Michael Lange 2012-09-22 09:48:57 UTC --- Created attachment 67541 --> https://bugs.freedesktop.org/attachment.cgi?id=67541 dmesg -- 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
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #2 from Michael Lange 2012-09-22 09:49:29 UTC --- Created attachment 67542 --> https://bugs.freedesktop.org/attachment.cgi?id=67542 Xorg.0.log -- 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
Re: [PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
Hi Eric, On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: > Hi Sascha, > > While testing against a video-enabled U-Boot on i.MX6, I found the issue > below. > [...] > > But ipu_crtc->imx_crtc gets initialized in this call, and > ipu_irq_handler() makes use of it. > > The U-Boot code doesn't enable interrupts, so it's not acking > along the way, and leaves bits set in IPU1_INT_STAT_15. > > I found that I can get around this in U-Boot by disabling the > LCD controller and acking all of the interrupts after disabling > the controller, but I haven't yet figured out where to tap into > cleanup_before_linux(). Passing over an enabled IPU from the bootloader to the kernel is (currently) not a supported usecase, so U-Boot should indeed disable it. That said, the kernel driver should make sure the IPU is sufficiently configured before the interrupts are enabled, so this seems to be a bug that deserves fixing. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 rbou...@hotmail.com changed: What|Removed |Added CC||rbou...@hotmail.com --- Comment #3 from rbou...@hotmail.com 2012-09-22 13:52:29 UTC --- Me too Also Unity on Ubuntu 12.04 displays black screen with only the mouse pointer. Switching to another virtual console or logging in Unity 2D works though. Radeon HD3450 (RV620) on Ubuntu 12.04 + OIBAF PPA -- 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
[Bug 54832] Piglit Regression: r300g swtcl 185ed21 draw: simplify index buffer specification
https://bugs.freedesktop.org/show_bug.cgi?id=54832 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Marek Olšák 2012-09-22 14:34:07 UTC --- I pushed the fix into master and 9.0. Closing. -- 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
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #4 from Alex Deucher 2012-09-22 14:52:35 UTC --- Can you bisect? -- 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
[Bug 42627] Hibernation fails to resume - Toshiba Satellite L755-161 notebook
https://bugzilla.kernel.org/show_bug.cgi?id=42627 --- Comment #23 from Harald Brennich 2012-09-22 15:47:19 --- Resume from hibernation also fails with kernel versions 3.5.4 and 3.6-rc6. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #5 from Michael Lange 2012-09-22 17:32:05 UTC --- sorry, but which PATH environment variables i have to set? LD_LIBRARY_PATH="~/mesa/src/glx" glxgears does not work -- 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
Re: [PATCH] drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
On Fri, Sep 21, 2012 at 08:56:27AM -0400, Josh Boyer wrote: > On Tue, Aug 28, 2012 at 4:50 PM, wrote: > > From: Jerome Glisse > > > > It seems some of those IGP dislike non dma32 page despite what > > documentation says. Fix regression since we allowed non dma32 > > pages. It seems it only affect some revision of those IGP chips > > as we don't know which one just force dma32 for all of them. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=785375 > > > > Signed-off-by: Jerome Glisse > > Cc: > > > This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f. I > don't see it queued up in the stable-queue, so I thought I'd point it > out in case it was missed. I am way behind on the drm patches for stable, I have a ton of them in my todo-queue, but have been traveling all week at a conference and haven't had the chance to get to them. Hopefully I'll be able to flush them all out next week, but don't worry, it's not lost. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: Use NULL instead of 0 for pointers
Fixes the following sparse warnings:
drivers/gpu/drm/udl/udl_transfer.c:129:50:
drivers/gpu/drm/udl/udl_transfer.c:130:50:
drivers/gpu/drm/udl/udl_transfer.c:131:45:
drivers/gpu/drm/udl/udl_transfer.c:132:61:
warning: Using plain integer as NULL pointer
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_transfer.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index b9320e2..f9fff65 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -126,10 +126,10 @@ static void udl_compress_hline16(
while ((pixel_end > pixel) &&
(cmd_buffer_end - MIN_RLX_CMD_BYTES > cmd)) {
- uint8_t *raw_pixels_count_byte = 0;
- uint8_t *cmd_pixels_count_byte = 0;
- const u8 *raw_pixel_start = 0;
- const u8 *cmd_pixel_start, *cmd_pixel_end = 0;
+ uint8_t *raw_pixels_count_byte = NULL;
+ uint8_t *cmd_pixels_count_byte = NULL;
+ const u8 *raw_pixel_start = NULL;
+ const u8 *cmd_pixel_start, *cmd_pixel_end = NULL;
prefetchw((void *) cmd); /* pull in one cache line at least */
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: Add missing static storage class specifiers in udl_fb.c
Fixes the following sparse warnings:
drivers/gpu/drm/udl/udl_fb.c:360:6: warning:
symbol 'udl_crtc_fb_gamma_set' was not declared. Should it be static?
drivers/gpu/drm/udl/udl_fb.c:365:6: warning:
symbol 'udl_crtc_fb_gamma_get' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_fb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 8f9d0bd..d06b93f 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -357,12 +357,12 @@ static struct fb_ops udlfb_ops = {
.fb_release = udl_fb_release,
};
-void udl_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
+static void udl_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno)
{
}
-void udl_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
+static void udl_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue, int regno)
{
*red = 0;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: Make udl_enc_destroy() static
Fixes the following sparse warning:
drivers/gpu/drm/udl/udl_encoder.c:19:6: warning:
symbol 'udl_enc_destroy' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_encoder.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_encoder.c
b/drivers/gpu/drm/udl/udl_encoder.c
index 0731ab2..0476bfe 100644
--- a/drivers/gpu/drm/udl/udl_encoder.c
+++ b/drivers/gpu/drm/udl/udl_encoder.c
@@ -16,7 +16,7 @@
#include "udl_drv.h"
/* dummy encoder */
-void udl_enc_destroy(struct drm_encoder *encoder)
+static void udl_enc_destroy(struct drm_encoder *encoder)
{
drm_encoder_cleanup(encoder);
kfree(encoder);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: Make udl_crtc_init() static
Fixes the following sparse warning:
drivers/gpu/drm/udl/udl_modeset.c:394:5: warning:
symbol 'udl_crtc_init' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_modeset.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 9159d48..8f25815 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -391,7 +391,7 @@ static const struct drm_crtc_funcs udl_crtc_funcs = {
.destroy = udl_crtc_destroy,
};
-int udl_crtc_init(struct drm_device *dev)
+static int udl_crtc_init(struct drm_device *dev)
{
struct drm_crtc *crtc;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] console: implement lockdep support for console_lock
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:
https://lkml.org/lkml/2012/8/21/36
Unfortunately the console_lock isn't a plain mutex and hence has no
lockdep support. Which resulted in a few days wasted of tracking down
this bug (complicated by the fact that printk doesn't show anything
when the console is locked) instead of noticing the bug much earlier
with the lockdep splat.
Hence I've figured I need to fix that for the next deadlock involving
console_lock - and with kms/drm growing ever more complex locking
that'll eventually happen.
Now the console_lock has rather funky semantics, so after a quick irc
discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
the original idead of switching to a real mutex (since it won't work)
and instead opted to annotate the console_lock with lockdep
information manually.
There are a few special cases:
- The console_lock state is protected by the console_sem, and usually
grabbed/dropped at _lock/_unlock time. But the suspend/resume code
drops the semaphore without dropping the console_lock (see
suspend_console/resume_console). But since the same thread that did
the suspend will do the resume, we don't need to fix up anything.
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk does a few other evil
tricks). So no issue there, either.
- The console_lock can also be acquired form irq context (but only
with a trylock). lockdep already handles that.
This all leaves us with annotating the normal console_lock, _unlock
and _trylock functions.
And yes, it works - simply unloading a drm kms driver resulted in
lockdep complaining about the deadlock in fbcon_deinit:
==
[ INFO: possible circular locking dependency detected ]
3.6.0-rc2+ #552 Not tainted
---
kms-reload/3577 is trying to acquire lock:
((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7
but task is already holding lock:
(console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] lock_acquire+0x95/0x105
[] console_lock+0x59/0x5b
[] fb_flashcursor+0x2e/0x12c
[] process_one_work+0x1d9/0x3b4
[] worker_thread+0x1a7/0x24b
[] kthread+0x7f/0x87
[] kernel_thread_helper+0x4/0x10
-> #0 ((&info->queue)){+.+...}:
[] __lock_acquire+0x999/0xcf6
[] lock_acquire+0x95/0x105
[] wait_on_work+0x3b/0xa7
[] __cancel_work_timer+0xbf/0x102
[] cancel_work_sync+0xb/0xd
[] fbcon_deinit+0x11c/0x1dc
[] bind_con_driver+0x145/0x263
[] unbind_con_driver+0x14f/0x195
[] store_bind+0x1ad/0x1c1
[] dev_attr_store+0x13/0x1f
[] sysfs_write_file+0xe9/0x121
[] vfs_write+0x9b/0xfd
[] sys_write+0x3e/0x6b
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((&info->queue));
lock(console_lock);
lock((&info->queue));
*** DEADLOCK ***
v2: Mark the lockdep_map static, noticed by Jani Nikula.
Cc: Dave Airlie
Cc: Thomas Gleixner
Cc: Alan Cox
Cc: Peter Zijlstra
Signed-off-by: Daniel Vetter
---
kernel/printk.c |9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/printk.c b/kernel/printk.c
index ed9af6a..e5c6dba 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -87,6 +87,12 @@ static DEFINE_SEMAPHORE(console_sem);
struct console *console_drivers;
EXPORT_SYMBOL_GPL(console_drivers);
+#ifdef CONFIG_LOCKDEP
+static struct lockdep_map console_lock_dep_map = {
+ .name = "console_lock"
+};
+#endif
+
/*
* This is used for debugging the mess that is the VT code by
* keeping track if we have the console semaphore held. It's
@@ -1916,6 +1922,7 @@ void console_lock(void)
return;
console_locked = 1;
console_may_schedule = 1;
+ mutex_acquire(&console_lock_dep_map, 0, 0, _RET_IP_);
}
EXPORT_SYMBOL(console_lock);
@@ -1937,6 +1944,7 @@ int console_trylock(void)
}
console_locked = 1;
console_may_schedule = 0;
+ mutex_acquire(&console_lock_dep_map, 0, 1, _RET_IP_);
return 1;
}
EXPORT_SYMBOL(console_trylock);
@@ -2097,6 +2105,7 @@ skip:
local_irq_restore(flags);
}
console_locked = 0;
+ mutex_release(&console_lock_dep_map, 1, _RET_IP_);
/* Release the exclusive_console once it is used */
if (unlikely(exclus
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #6 from Alex Deucher 2012-09-22 18:40:41 UTC --- Bisect is a git option to identify what commit caused a problem. Google for "git bisect". -- 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
[Bug 47801] New: Nouveau driver spams system log with messages about incorrect EDID data
https://bugzilla.kernel.org/show_bug.cgi?id=47801 Summary: Nouveau driver spams system log with messages about incorrect EDID data Product: Drivers Version: 2.5 Kernel Version: 3.5.4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: mies...@zabrze.zigzag.pl Regression: No Created an attachment (id=80731) --> (https://bugzilla.kernel.org/attachment.cgi?id=80731) dmesg information When booting linux, the log get spammed with information about incorrect EDID block, although EDID data accessible via /sys/... is correct. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47801] Nouveau driver spams system log with messages about incorrect EDID data
https://bugzilla.kernel.org/show_bug.cgi?id=47801 --- Comment #1 from Miroslaw Mieszczak 2012-09-22 19:11:43 --- Created an attachment (id=80741) --> (https://bugzilla.kernel.org/attachment.cgi?id=80741) Edid file from /sys/... folder -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #7 from Michael Lange 2012-09-22 19:33:01 UTC --- yes ... i have google for it ;) so i should bisect mesa-git, right? * i have clone the mesa-git with git clone git://anongit.freedesktop.org/git/mesa/mesa * cd mesa * git checkout 9aa8bac9 (i think this was working "date 2012-09-19") * ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float --disable-debug --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi --enable-xa --enable-xorg --with-dri-drivers= --with-gallium-drivers=,swrast,r600 --with-egl-platforms=x11,drm --enable-gallium-egl --enable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --enable-r600-llvm-compiler --disable-vdpau --enable-xvmc * make * now i would like testing mesa, but how? running glxgears uses the system-libs from /usr/lib64. with EGIT_COMMIT="9aa8bac98b823e8783bc3a06a6e5b23fbf8d87fb" emerge mesa i got a working mesa. -- 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
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #8 from Michael Lange 2012-09-22 19:35:57 UTC --- my system is working and running with a mesa-build from 2012-09-19 how i could test the mesa-build in my home-dir? -- 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
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #9 from Matt Turner 2012-09-22 20:34:51 UTC --- (In reply to comment #8) > my system is working and running with a mesa-build from 2012-09-19 > how i could test the mesa-build in my home-dir? You can set where to look for shared libraries by settings LD_LIBRARY_PATH=... and where to look for DRI drivers with LIBGL_DRIVERS_PATH=... E.g., LD_LIBRARY_PATH= LIBGL_DRIVERS_PATH= glxgears will run glxgears with your new Mesa. -- 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
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #10 from Marek Olšák 2012-09-22 20:59:42 UTC --- I can't reproduce this. Mesa master on RS880 is working fine here. -- 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
Re: -next trees
On 09/12/2012 08:44 PM, Dave Airlie wrote: > Ajax, I think Ian still has an open request on how to proceed with the > infoframes quirk nightmare. Indeed. On 08/30/2012 12:23 AM, Ian Pilcher wrote: > In terms of moving forward with the rest of the EDID quirk stuff, are > you OK with either of these options: > > * Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP. It won't > work "out of the box" with the Intel driver until that driver is > fixed to not send audio InfoFrames to non-HDMI displays (but anyone > who has the combination will be able to add their own quirk to make > it work). > > * Leave both flags, because both are accurate. The display is confused > by any InfoFrames (audio or AVI), and it is reporting non-existent > audio capabilities. The fact that the combination of the two flags > makes the display work with Intel GPUs is a happy/sad/neutral > accident, and the driver's behavior is still considered broken. > > (Essentially, this would mean just editing the comments to reflect the > above reasoning.) -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/exynos: Add match table for drm platform device
This patch is a part of moving the driver to support DT style probing
of exynos drm device. The compatible name should match with the
entry in the dtsi file.
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index d070719..495be89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -294,12 +294,23 @@ static int exynos_drm_platform_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id drm_device_dt_match[] = {
+ { .compatible = "samsung,exynos-drm-device"},
+ {},
+};
+MODULE_DEVICE_TABLE(of, drm_device_dt_match);
+#else
+#define drm_device_dt_match NULL
+#endif
+
static struct platform_driver exynos_drm_platform_driver = {
.probe = exynos_drm_platform_probe,
.remove = __devexit_p(exynos_drm_platform_remove),
.driver = {
.owner = THIS_MODULE,
.name = "exynos-drm",
+ .of_match_table = of_match_ptr(drm_device_dt_match),
},
};
--
1.7.0.4
[Bug 55206] this commit break r600 llvm shader compiler
https://bugs.freedesktop.org/show_bug.cgi?id=55206 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Tom Stellard 2012-09-22 00:07:10 UTC --- Fixed by commit bbb2ebe2fc073793c5129b164b61fe1b36dfc4b1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] radeon: Allow N x 1 x 1 surfaces for evergreen+
I think it would be cleaner to add a new SURF_TYPE for buffers and
only allow large npix_x for that (and adding all the necessary sanity
checks to disallow invalid values).
Also, if you want to use it in Mesa, you or somebody else should:
1) make a libdrm release
2) bump libdrm_radeon version requirement in Mesa's configure.ac
Marek
On Fri, Sep 21, 2012 at 10:23 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> This makes it possible to create a surface for a buffer.
> ---
> radeon/radeon_surface.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 80b1505..235f4ae 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -686,7 +686,8 @@ static int eg_surface_sanity(struct
> radeon_surface_manager *surf_man,
> unsigned tileb;
>
> /* check surface dimension */
> -if (surf->npix_x > 16384 || surf->npix_y > 16384 || surf->npix_z >
> 16384) {
> +if ((surf->npix_x > 16384 && (surf->npix_y != 1 || surf->npix_z != 1))
> ||
> +surf->npix_y > 16384 || surf->npix_z > 16384) {
> return -EINVAL;
> }
>
> --
> 1.7.11.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #5 from Paul Menzel 2012-09-22 09:36:42 UTC --- (In reply to comment #4) > Patch sent to the dri-devel list [1]. > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-August/026476.html TLDR: A T60 with a 945GM/GMS(?) controller works without that patch with Linux 3.2.x. I am petrified. Testing this TV with a T60 and a different VGA cable (all pins populated, instead of Pin 9 missing) everything works fine (besides a little vertical shift to the right). :/ $ lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01) 15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller The read EDID is the same. $ xrandr -q --verbose [?] VGA1 connected 1920x1080+0+0 (0xb9) normal (normal left inverted right x axis y axis) 1150mm x 650mm Identifier: 0x42 Timestamp: 222127 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: DVI1 CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 00001e6d010001010101 02130103687341780acf74a3574cb023 09484ca1080081806140454031400101 010101010101023a801871382d40582c 45007e8a421e011d007251d01e20 6e2855007e8a421e00fd003a 3e1e531a20202020202000fc 004c472054560a20202020202020001d 1920x1080 (0xb9) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz 1280x1024 (0x47) 108.0MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1280x720 (0xba) 74.2MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew0 clock 45.0KHz v: height 720 start 725 end 730 total 750 clock 60.0Hz 1024x768 (0x4c) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x4d) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 640x480 (0x4f) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 490 end
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #6 from Paul Menzel 2012-09-22 09:38:16 UTC --- Created attachment 67539 --> https://bugs.freedesktop.org/attachment.cgi?id=67539 `/var/log/Xorg.0.log` from T60 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #7 from Paul Menzel 2012-09-22 09:39:18 UTC --- Created attachment 67540 --> https://bugs.freedesktop.org/attachment.cgi?id=67540 `xrandr -q --verbose` from T60 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55217] New: [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 Bug #: 55217 Summary: [RS880] opengl not working anymore Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: michaell at gmx.org after updating mesa to latest git, i can not using opengl-apps anymore running glxgears give the following error message: EE r600_asm.c:121 r600_bytecode_get_num_operands - Need instruction operand number for 0xc testet with kernel 3.5.1 and 3.6.0-rc6 using xorg-server-1.12.2 and libdrm, mesa, xf86-video-ati from git removing xorg.conf gives the same error -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
-next trees
Am Donnerstag, den 13.09.2012, 11:44 +1000 schrieb Dave Airlie: > Just a reminder to the subtree maintainers that I should be starting > to see signs of -next trees lining up soon, > > I've merged a bunch of patches from the list, but I'm sure I've forgotten > some, > I've got the 3 quirks from Paul that I'm iffy about due to the lack of > testing against VGA ports that ajax requested, but I could be turned. I am really sorry, but it looks like more testing is needed, so please revert them. :/ Testing on a T60 shows that it works out of the box. So it is either 915GM or cable problem. [1] I will answer to the single patches later on. [?] Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120922/2747cde1/attachment.pgp>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #1 from Michael Lange 2012-09-22 09:48:57 UTC --- Created attachment 67541 --> https://bugs.freedesktop.org/attachment.cgi?id=67541 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #2 from Michael Lange 2012-09-22 09:49:29 UTC --- Created attachment 67542 --> https://bugs.freedesktop.org/attachment.cgi?id=67542 Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
Hi Eric, On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: > Hi Sascha, > > While testing against a video-enabled U-Boot on i.MX6, I found the issue > below. > [...] > > But ipu_crtc->imx_crtc gets initialized in this call, and > ipu_irq_handler() makes use of it. > > The U-Boot code doesn't enable interrupts, so it's not acking > along the way, and leaves bits set in IPU1_INT_STAT_15. > > I found that I can get around this in U-Boot by disabling the > LCD controller and acking all of the interrupts after disabling > the controller, but I haven't yet figured out where to tap into > cleanup_before_linux(). Passing over an enabled IPU from the bootloader to the kernel is (currently) not a supported usecase, so U-Boot should indeed disable it. That said, the kernel driver should make sure the IPU is sufficiently configured before the interrupts are enabled, so this seems to be a bug that deserves fixing. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 rboudot at hotmail.com changed: What|Removed |Added CC||rboudot at hotmail.com --- Comment #3 from rboudot at hotmail.com 2012-09-22 13:52:29 UTC --- Me too Also Unity on Ubuntu 12.04 displays black screen with only the mouse pointer. Switching to another virtual console or logging in Unity 2D works though. Radeon HD3450 (RV620) on Ubuntu 12.04 + OIBAF PPA -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 54832] Piglit Regression: r300g swtcl 185ed21 draw: simplify index buffer specification
https://bugs.freedesktop.org/show_bug.cgi?id=54832 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Marek Ol??k 2012-09-22 14:34:07 UTC --- I pushed the fix into master and 9.0. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #4 from Alex Deucher 2012-09-22 14:52:35 UTC --- Can you bisect? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42627] Hibernation fails to resume - Toshiba Satellite L755-161 notebook
https://bugzilla.kernel.org/show_bug.cgi?id=42627 --- Comment #23 from Harald Brennich 2012-09-22 15:47:19 --- Resume from hibernation also fails with kernel versions 3.5.4 and 3.6-rc6. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #5 from Michael Lange 2012-09-22 17:32:05 UTC --- sorry, but which PATH environment variables i have to set? LD_LIBRARY_PATH="~/mesa/src/glx" glxgears does not work -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/udl: Use NULL instead of 0 for pointers
Fixes the following sparse warnings:
drivers/gpu/drm/udl/udl_transfer.c:129:50:
drivers/gpu/drm/udl/udl_transfer.c:130:50:
drivers/gpu/drm/udl/udl_transfer.c:131:45:
drivers/gpu/drm/udl/udl_transfer.c:132:61:
warning: Using plain integer as NULL pointer
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_transfer.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index b9320e2..f9fff65 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -126,10 +126,10 @@ static void udl_compress_hline16(
while ((pixel_end > pixel) &&
(cmd_buffer_end - MIN_RLX_CMD_BYTES > cmd)) {
- uint8_t *raw_pixels_count_byte = 0;
- uint8_t *cmd_pixels_count_byte = 0;
- const u8 *raw_pixel_start = 0;
- const u8 *cmd_pixel_start, *cmd_pixel_end = 0;
+ uint8_t *raw_pixels_count_byte = NULL;
+ uint8_t *cmd_pixels_count_byte = NULL;
+ const u8 *raw_pixel_start = NULL;
+ const u8 *cmd_pixel_start, *cmd_pixel_end = NULL;
prefetchw((void *) cmd); /* pull in one cache line at least */
--
1.7.4.1
[PATCH] drm/udl: Add missing static storage class specifiers in udl_fb.c
Fixes the following sparse warnings:
drivers/gpu/drm/udl/udl_fb.c:360:6: warning:
symbol 'udl_crtc_fb_gamma_set' was not declared. Should it be static?
drivers/gpu/drm/udl/udl_fb.c:365:6: warning:
symbol 'udl_crtc_fb_gamma_get' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_fb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 8f9d0bd..d06b93f 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -357,12 +357,12 @@ static struct fb_ops udlfb_ops = {
.fb_release = udl_fb_release,
};
-void udl_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
+static void udl_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno)
{
}
-void udl_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
+static void udl_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue, int regno)
{
*red = 0;
--
1.7.4.1
[PATCH] drm/udl: Make udl_enc_destroy() static
Fixes the following sparse warning:
drivers/gpu/drm/udl/udl_encoder.c:19:6: warning:
symbol 'udl_enc_destroy' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_encoder.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_encoder.c
b/drivers/gpu/drm/udl/udl_encoder.c
index 0731ab2..0476bfe 100644
--- a/drivers/gpu/drm/udl/udl_encoder.c
+++ b/drivers/gpu/drm/udl/udl_encoder.c
@@ -16,7 +16,7 @@
#include "udl_drv.h"
/* dummy encoder */
-void udl_enc_destroy(struct drm_encoder *encoder)
+static void udl_enc_destroy(struct drm_encoder *encoder)
{
drm_encoder_cleanup(encoder);
kfree(encoder);
--
1.7.4.1
[PATCH] drm/udl: Make udl_crtc_init() static
Fixes the following sparse warning:
drivers/gpu/drm/udl/udl_modeset.c:394:5: warning:
symbol 'udl_crtc_init' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/udl/udl_modeset.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 9159d48..8f25815 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -391,7 +391,7 @@ static const struct drm_crtc_funcs udl_crtc_funcs = {
.destroy = udl_crtc_destroy,
};
-int udl_crtc_init(struct drm_device *dev)
+static int udl_crtc_init(struct drm_device *dev)
{
struct drm_crtc *crtc;
--
1.7.4.1
[PATCH] console: implement lockdep support for console_lock
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:
https://lkml.org/lkml/2012/8/21/36
Unfortunately the console_lock isn't a plain mutex and hence has no
lockdep support. Which resulted in a few days wasted of tracking down
this bug (complicated by the fact that printk doesn't show anything
when the console is locked) instead of noticing the bug much earlier
with the lockdep splat.
Hence I've figured I need to fix that for the next deadlock involving
console_lock - and with kms/drm growing ever more complex locking
that'll eventually happen.
Now the console_lock has rather funky semantics, so after a quick irc
discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
the original idead of switching to a real mutex (since it won't work)
and instead opted to annotate the console_lock with lockdep
information manually.
There are a few special cases:
- The console_lock state is protected by the console_sem, and usually
grabbed/dropped at _lock/_unlock time. But the suspend/resume code
drops the semaphore without dropping the console_lock (see
suspend_console/resume_console). But since the same thread that did
the suspend will do the resume, we don't need to fix up anything.
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk does a few other evil
tricks). So no issue there, either.
- The console_lock can also be acquired form irq context (but only
with a trylock). lockdep already handles that.
This all leaves us with annotating the normal console_lock, _unlock
and _trylock functions.
And yes, it works - simply unloading a drm kms driver resulted in
lockdep complaining about the deadlock in fbcon_deinit:
==
[ INFO: possible circular locking dependency detected ]
3.6.0-rc2+ #552 Not tainted
---
kms-reload/3577 is trying to acquire lock:
((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7
but task is already holding lock:
(console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] lock_acquire+0x95/0x105
[] console_lock+0x59/0x5b
[] fb_flashcursor+0x2e/0x12c
[] process_one_work+0x1d9/0x3b4
[] worker_thread+0x1a7/0x24b
[] kthread+0x7f/0x87
[] kernel_thread_helper+0x4/0x10
-> #0 ((&info->queue)){+.+...}:
[] __lock_acquire+0x999/0xcf6
[] lock_acquire+0x95/0x105
[] wait_on_work+0x3b/0xa7
[] __cancel_work_timer+0xbf/0x102
[] cancel_work_sync+0xb/0xd
[] fbcon_deinit+0x11c/0x1dc
[] bind_con_driver+0x145/0x263
[] unbind_con_driver+0x14f/0x195
[] store_bind+0x1ad/0x1c1
[] dev_attr_store+0x13/0x1f
[] sysfs_write_file+0xe9/0x121
[] vfs_write+0x9b/0xfd
[] sys_write+0x3e/0x6b
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((&info->queue));
lock(console_lock);
lock((&info->queue));
*** DEADLOCK ***
v2: Mark the lockdep_map static, noticed by Jani Nikula.
Cc: Dave Airlie
Cc: Thomas Gleixner
Cc: Alan Cox
Cc: Peter Zijlstra
Signed-off-by: Daniel Vetter
---
kernel/printk.c |9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/printk.c b/kernel/printk.c
index ed9af6a..e5c6dba 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -87,6 +87,12 @@ static DEFINE_SEMAPHORE(console_sem);
struct console *console_drivers;
EXPORT_SYMBOL_GPL(console_drivers);
+#ifdef CONFIG_LOCKDEP
+static struct lockdep_map console_lock_dep_map = {
+ .name = "console_lock"
+};
+#endif
+
/*
* This is used for debugging the mess that is the VT code by
* keeping track if we have the console semaphore held. It's
@@ -1916,6 +1922,7 @@ void console_lock(void)
return;
console_locked = 1;
console_may_schedule = 1;
+ mutex_acquire(&console_lock_dep_map, 0, 0, _RET_IP_);
}
EXPORT_SYMBOL(console_lock);
@@ -1937,6 +1944,7 @@ int console_trylock(void)
}
console_locked = 1;
console_may_schedule = 0;
+ mutex_acquire(&console_lock_dep_map, 0, 1, _RET_IP_);
return 1;
}
EXPORT_SYMBOL(console_trylock);
@@ -2097,6 +2105,7 @@ skip:
local_irq_restore(flags);
}
console_locked = 0;
+ mutex_release(&console_lock_dep_map, 1, _RET_IP_);
/* Release the exclusive_console once it is used */
if (unlikely(exclusive
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #6 from Alex Deucher 2012-09-22 18:40:41 UTC --- Bisect is a git option to identify what commit caused a problem. Google for "git bisect". -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 47801] New: Nouveau driver spams system log with messages about incorrect EDID data
https://bugzilla.kernel.org/show_bug.cgi?id=47801 Summary: Nouveau driver spams system log with messages about incorrect EDID data Product: Drivers Version: 2.5 Kernel Version: 3.5.4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: mieszcz at zabrze.zigzag.pl Regression: No Created an attachment (id=80731) --> (https://bugzilla.kernel.org/attachment.cgi?id=80731) dmesg information When booting linux, the log get spammed with information about incorrect EDID block, although EDID data accessible via /sys/... is correct. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 47801] Nouveau driver spams system log with messages about incorrect EDID data
https://bugzilla.kernel.org/show_bug.cgi?id=47801 --- Comment #1 from Miroslaw Mieszczak 2012-09-22 19:11:43 --- Created an attachment (id=80741) --> (https://bugzilla.kernel.org/attachment.cgi?id=80741) Edid file from /sys/... folder -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #7 from Michael Lange 2012-09-22 19:33:01 UTC --- yes ... i have google for it ;) so i should bisect mesa-git, right? * i have clone the mesa-git with git clone git://anongit.freedesktop.org/git/mesa/mesa * cd mesa * git checkout 9aa8bac9 (i think this was working "date 2012-09-19") * ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float --disable-debug --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi --enable-xa --enable-xorg --with-dri-drivers= --with-gallium-drivers=,swrast,r600 --with-egl-platforms=x11,drm --enable-gallium-egl --enable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --enable-r600-llvm-compiler --disable-vdpau --enable-xvmc * make * now i would like testing mesa, but how? running glxgears uses the system-libs from /usr/lib64. with EGIT_COMMIT="9aa8bac98b823e8783bc3a06a6e5b23fbf8d87fb" emerge mesa i got a working mesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #8 from Michael Lange 2012-09-22 19:35:57 UTC --- my system is working and running with a mesa-build from 2012-09-19 how i could test the mesa-build in my home-dir? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #9 from Matt Turner 2012-09-22 20:34:51 UTC --- (In reply to comment #8) > my system is working and running with a mesa-build from 2012-09-19 > how i could test the mesa-build in my home-dir? You can set where to look for shared libraries by settings LD_LIBRARY_PATH=... and where to look for DRI drivers with LIBGL_DRIVERS_PATH=... E.g., LD_LIBRARY_PATH= LIBGL_DRIVERS_PATH= glxgears will run glxgears with your new Mesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #10 from Marek Ol??k 2012-09-22 20:59:42 UTC --- I can't reproduce this. Mesa master on RS880 is working fine here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
-next trees
On 09/12/2012 08:44 PM, Dave Airlie wrote: > Ajax, I think Ian still has an open request on how to proceed with the > infoframes quirk nightmare. Indeed. On 08/30/2012 12:23 AM, Ian Pilcher wrote: > In terms of moving forward with the rest of the EDID quirk stuff, are > you OK with either of these options: > > * Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP. It won't > work "out of the box" with the Intel driver until that driver is > fixed to not send audio InfoFrames to non-HDMI displays (but anyone > who has the combination will be able to add their own quirk to make > it work). > > * Leave both flags, because both are accurate. The display is confused > by any InfoFrames (audio or AVI), and it is reporting non-existent > audio capabilities. The fact that the combination of the two flags > makes the display work with Intel GPUs is a happy/sad/neutral > accident, and the driver's behavior is still considered broken. > > (Essentially, this would mean just editing the comments to reflect the > above reasoning.) -- Ian Pilcher arequipeno at gmail.com "If you're going to shift my paradigm ... at least buy me dinner first."
[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
On 09/22/2012 03:17 AM, Sascha Hauer wrote: > Hi Eric, > > On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: >> Hi Sascha, >> >> >> But ipu_crtc->imx_crtc gets initialized in this call, and >> ipu_irq_handler() makes use of it. >> >> The U-Boot code doesn't enable interrupts, so it's not acking >> along the way, and leaves bits set in IPU1_INT_STAT_15. >> >> I found that I can get around this in U-Boot by disabling the >> LCD controller and acking all of the interrupts after disabling >> the controller, but I haven't yet figured out where to tap into >> cleanup_before_linux(). > > Passing over an enabled IPU from the bootloader to the kernel is > (currently) not a supported usecase, so U-Boot should indeed disable it. > That said, the kernel driver should make sure the IPU is sufficiently > configured before the interrupts are enabled, so this seems to be a bug > that deserves fixing. > Thanks Sascha, Patches for U-Boot are in process. http://lists.denx.de/pipermail/u-boot/2012-September/134807.html Regards, Eric
[Intel-gfx] [PATCH] console: implement lockdep support for console_lock
On Sat, Sep 22, 2012 at 07:52:11PM +0200, Daniel Vetter wrote:
> Dave Airlie recently discovered a locking bug in the fbcon layer,
> where a timer_del_sync (for the blinking cursor) deadlocks with the
> timer itself, since both (want to) hold the console_lock:
>
> https://lkml.org/lkml/2012/8/21/36
>
> Unfortunately the console_lock isn't a plain mutex and hence has no
> lockdep support. Which resulted in a few days wasted of tracking down
> this bug (complicated by the fact that printk doesn't show anything
> when the console is locked) instead of noticing the bug much earlier
> with the lockdep splat.
>
> Hence I've figured I need to fix that for the next deadlock involving
> console_lock - and with kms/drm growing ever more complex locking
> that'll eventually happen.
>
> Now the console_lock has rather funky semantics, so after a quick irc
> discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
> the original idead of switching to a real mutex (since it won't work)
> and instead opted to annotate the console_lock with lockdep
> information manually.
>
> There are a few special cases:
> - The console_lock state is protected by the console_sem, and usually
> grabbed/dropped at _lock/_unlock time. But the suspend/resume code
> drops the semaphore without dropping the console_lock (see
> suspend_console/resume_console). But since the same thread that did
> the suspend will do the resume, we don't need to fix up anything.
>
> - In the printk code there's a special trylock, only used to kick off
> the logbuffer printk'ing in console_unlock. But all that happens
> while lockdep is disable (since printk does a few other evil
> tricks). So no issue there, either.
>
> - The console_lock can also be acquired form irq context (but only
> with a trylock). lockdep already handles that.
>
> This all leaves us with annotating the normal console_lock, _unlock
> and _trylock functions.
>
> And yes, it works - simply unloading a drm kms driver resulted in
> lockdep complaining about the deadlock in fbcon_deinit:
>
> ==
> [ INFO: possible circular locking dependency detected ]
> 3.6.0-rc2+ #552 Not tainted
> ---
> kms-reload/3577 is trying to acquire lock:
> ((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7
>
> but task is already holding lock:
> (console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (console_lock){+.+.+.}:
>[] lock_acquire+0x95/0x105
>[] console_lock+0x59/0x5b
>[] fb_flashcursor+0x2e/0x12c
>[] process_one_work+0x1d9/0x3b4
>[] worker_thread+0x1a7/0x24b
>[] kthread+0x7f/0x87
>[] kernel_thread_helper+0x4/0x10
>
> -> #0 ((&info->queue)){+.+...}:
>[] __lock_acquire+0x999/0xcf6
>[] lock_acquire+0x95/0x105
>[] wait_on_work+0x3b/0xa7
>[] __cancel_work_timer+0xbf/0x102
>[] cancel_work_sync+0xb/0xd
>[] fbcon_deinit+0x11c/0x1dc
>[] bind_con_driver+0x145/0x263
>[] unbind_con_driver+0x14f/0x195
>[] store_bind+0x1ad/0x1c1
>[] dev_attr_store+0x13/0x1f
>[] sysfs_write_file+0xe9/0x121
>[] vfs_write+0x9b/0xfd
>[] sys_write+0x3e/0x6b
>[] system_call_fastpath+0x16/0x1b
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
>CPU0CPU1
>
> lock(console_lock);
>lock((&info->queue));
>lock(console_lock);
> lock((&info->queue));
>
> *** DEADLOCK ***
>
> v2: Mark the lockdep_map static, noticed by Jani Nikula.
>
> Cc: Dave Airlie
> Cc: Thomas Gleixner
> Cc: Alan Cox
> Cc: Peter Zijlstra
> Signed-off-by: Daniel Vetter
> ---
> kernel/printk.c |9 +
> 1 file changed, 9 insertions(+)
So I'm guessing I should take this through the tty tree, right? Any
objections to that for 3.7?
thanks,
greg k-h
