[Bug 33296] New: gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 Summary: gnome-shell broken possibly due to glReadPixels() error Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: am at gmail.com Created an attachment (id=42232) --> (https://bugs.freedesktop.org/attachment.cgi?id=42232) gnome-shell (under gdb) output Hi! I've been testing gnome-shell from git (clutter, mutter etc. from git too). I initially got crashing as in https://bugs.freedesktop.org/show_bug.cgi?id=32918 I updated to latest xorg & mesa from ubuntu xorg-edgers PPA (mesa 7.11.0-git20110119), this fixes the crashing but mouse events now mostly do not work, and produce warnings like this: (mutter:28983): Clutter-WARNING **: The required ID of 12107392 does not refer to an existing actor; this usually implies that the pick() of an actor is not correctly implemented or that there is an error in the glReadPixels() implementation of the GL driver. Clutter bug on this issue: https://bugs.freedesktop.org//show_bug.cgi?id=24408 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: more intel drm issues (was Re: [git pull] drm intel only fixes)
On Thu, Jan 20, 2011 at 10:39 AM, Linus Torvalds torva...@linux-foundation.org wrote: Ok, so I have a new issue that I'm currently bisecting but that people may be able to figure out even befor emy bisect finishes. On my slow Atom netbook (that I'm planning on using as my traveling companion for LCA), suspend-to-RAM takes a long time with current git. It's quite noticeable - it used to be pretty much instant, now it takes three seconds. And it's all i915 graphics (although I haven't bisected it down fully, I've bisected it down to the drm merge). In the good case (like plain 2.6.37), a suspend event will look something like this:... PM: suspend of devices complete after 147.646 msecs but the i915 driver at some point made it take 3s: PM: suspend of devices complete after 3059.656 msecs which is definitely long enough to be worth fixing. Maybe the person responsible will go oh, that's obviously due to xyz, and just fix it. But I'll continue to bisect in case nobody steps up to admit to wasting time.. Rafael send out two patches earlier. Could be related. I was facing issue during resume. Attached are the two patches. You'll need to apply both. Len has suggested before to try to booting with acpi_sleep=nonvs which works as well for my case. Thanks, Jeff patch-resume1 Description: Binary data patch-resume2 Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/radeon/kms: Expose backlight class device for legacy LVDS encoder.
From: Michel Dänzer daen...@vmware.com
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
v2: Fix problems when CONFIG_BACKLIGHT_CLASS_DEVICE isn't defined.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel Dänzer daen...@vmware.com
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/gpu/drm/radeon/Kconfig |1 +
drivers/gpu/drm/radeon/radeon_connectors.c | 15 ++
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 257 ++-
drivers/gpu/drm/radeon/radeon_mode.h|6 +
4 files changed, 273 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 1c02d23..9746fee 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -1,6 +1,7 @@
config DRM_RADEON_KMS
bool Enable modesetting on radeon by default - NEW DRIVER
depends on DRM_RADEON
+ select BACKLIGHT_CLASS_DEVICE
help
Choose this option if you want kernel modesetting enabled by default.
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5b00f92..c474d78 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -40,6 +40,10 @@ radeon_atombios_connected_scratch_regs(struct drm_connector
*connector,
struct drm_encoder *encoder,
bool connected);
+extern void
+radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
+struct drm_connector *drm_connector);
+
void radeon_connector_hotplug(struct drm_connector *connector)
{
struct drm_device *dev = connector-dev;
@@ -1517,6 +1521,17 @@ radeon_add_legacy_connector(struct drm_device *dev,
connector-polled = DRM_CONNECTOR_POLL_HPD;
connector-display_info.subpixel_order = subpixel_order;
drm_sysfs_connector_add(connector);
+ if (connector_type == DRM_MODE_CONNECTOR_LVDS) {
+ struct drm_encoder *drm_encoder;
+
+ list_for_each_entry(drm_encoder,
dev-mode_config.encoder_list, head) {
+ struct radeon_encoder *radeon_encoder;
+
+ radeon_encoder = to_radeon_encoder(drm_encoder);
+ if (radeon_encoder-encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_LVDS)
+ radeon_legacy_backlight_init(radeon_encoder,
connector);
+ }
+ }
return;
failed:
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 59f834b..5b54268 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -28,6 +28,10 @@
#include radeon_drm.h
#include radeon.h
#include atom.h
+#include linux/backlight.h
+#ifdef CONFIG_PMAC_BACKLIGHT
+#include asm/backlight.h
+#endif
static void radeon_legacy_encoder_disable(struct drm_encoder *encoder)
{
@@ -39,7 +43,7 @@ static void radeon_legacy_encoder_disable(struct drm_encoder
*encoder)
radeon_encoder-active_device = 0;
}
-static void radeon_legacy_lvds_dpms(struct drm_encoder *encoder, int mode)
+static void radeon_legacy_lvds_update(struct drm_encoder *encoder, int mode)
{
struct drm_device *dev = encoder-dev;
struct radeon_device *rdev = dev-dev_private;
@@ -47,15 +51,23 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder
*encoder, int mode)
uint32_t lvds_gen_cntl, lvds_pll_cntl, pixclks_cntl, disp_pwr_man;
int panel_pwr_delay = 2000;
bool is_mac = false;
+ uint8_t backlight_level;
DRM_DEBUG_KMS(\n);
+ lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
+ backlight_level = (lvds_gen_cntl RADEON_LVDS_BL_MOD_LEVEL_SHIFT)
0xff;
+
if (radeon_encoder-enc_priv) {
if (rdev-is_atom_bios) {
struct radeon_encoder_atom_dig *lvds =
radeon_encoder-enc_priv;
panel_pwr_delay = lvds-panel_pwr_delay;
+ if (lvds-bl_dev)
+ backlight_level = lvds-backlight_level;
} else {
struct radeon_encoder_lvds *lvds =
radeon_encoder-enc_priv;
panel_pwr_delay = lvds-panel_pwr_delay;
+ if (lvds-bl_dev)
+ backlight_level = lvds-backlight_level;
}
}
@@ -82,11 +94,13 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder
*encoder, int mode)
lvds_pll_cntl = ~RADEON_LVDS_PLL_RESET;
WREG32(RADEON_LVDS_PLL_CNTL, lvds_pll_cntl);
- lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
- lvds_gen_cntl |=
Re: more intel drm issues (was Re: [git pull] drm intel only fixes)
On Wed, 19 Jan 2011 22:22:48 -0800, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua jeff.chua.li...@gmail.com wrote:
Rafael send out two patches earlier. Could be related. I was facing
issue during resume.
No, I'm aware of the rcu-synchronize thing, this isn't it. This is
really at the suspend stage, and I had bisected it down to the drm
changes.
In fact, by now I have bisected it down to a single commit. It's
another merge commit, which makes me a bit nervous (I bisected another
issue today, and it turned out to simply not be repeatable).
But this time the merge commit actually has a real conflict that got
fixed up in the merge, and the code around the conflict waits for
three seconds, and three seconds is also exactly how long the delay at
suspend time is. So I get the feeling that this time it's a real
issue, and what happened was that the merge may have been a mismerge.
Chris: as of commit 8d5203ca6253 (Merge branch 'drm-intel-fixes' into
drm-intel-next) I'm getting that 3-second delay at suspend time. And
the merge diff looks like this:
+struct drm_device *dev = ring-dev;
+struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long end;
-drm_i915_private_t *dev_priv = dev-dev_private;
u32 head;
- head = intel_read_status_page(ring, 4);
- if (head) {
- ring-head = head HEAD_ADDR;
- ring-space = ring-head - (ring-tail + 8);
- if (ring-space 0)
- ring-space += ring-size;
- if (ring-space = n)
- return 0;
- }
-
trace_i915_ring_wait_begin (dev);
end = jiffies + 3 * HZ;
do {
and that whole do-loop with a 3-second timeout makes me *very*
suspicious. It used to have (in _one_ of the parent branches) that
code before it to return early if there was space in the ring, now it
doesn't any more - and that merge co-incides with my suspend suddenly
taking 3 seconds.
The same check that is deleted does exist inside the loop too, but
there it has some extra code it in (compare to actual_head and so
on), so I wonder if the fast-case was somehow hiding this issue.
Right, the autoreported HEAD may have been already reset to 0 and so hit
the wraparound bug which caused it to exit early without actually
quiescing the ringbuffer.
Another possibility is that I added a 3s timeout waiting for a request if
IRQs were suspended:
commit b5ba177d8d71f011c23b1cabec99fdaddae65c4d
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Tue Dec 14 12:17:15 2010 +
drm/i915: Poll for seqno completion if IRQ is disabled
Both of those I think are symptoms of another problem, that perhaps during
suspend we are shutting down parts of the chip before idling?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33276] invalid enumerant during: Cubemap ID generation
https://bugs.freedesktop.org/show_bug.cgi?id=33276 --- Comment #8 from Michel Dänzer mic...@daenzer.net 2011-01-20 02:35:12 PST --- (In reply to comment #5) But debian doesn't have gallium driver in a repository, [...] Actually, the libgl1-mesa-dri package in Debian ships the Gallium driver as of version 7.9-1 in experimental. -- 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: 2.6.37: BUG at drivers/gpu/drm/i915/i915_gem.c:4190!
On Thu, 20 Jan 2011 11:49:18 +0100, Toralf Förster toralf.foers...@gmx.de wrote: Hello, after the following BUG the system crashed : ... 2011-01-12T10:31:59.597+01:00 n22 kernel: kernel BUG at drivers/gpu/drm/i915/i915_gem.c:4190! 2011-01-12T10:31:59.597+01:00 n22 kernel: invalid opcode: [#1] SMP 2011-01-12T10:31:59.597+01:00 n22 kernel: last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 2011-01-12T10:31:59.597+01:00 n22 kernel: Modules linked in: bridge stp llc ipt_MASQUERADE ipt_REJECT xt_recent xt_tcpudp nf_conntrack_ftp xt_state xt_limit ipt_LOG iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter xt_owner xt_multiport ip_tables x_tables snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss af_packet fuse hdaps input_polldev fbcon font bitblit softcursor acpi_cpufreq mperf dm_mod arc4 ecb crypto_blkcipher snd_hda_codec_conexant cryptomgr i915 snd_hda_intel drm_kms_helper aead crypto_algapi usbhid hid thinkpad_acpi snd_hda_codec snd_pcm drm iwlagn fb hwmon uhci_hcd ehci_hcd iwlcore fbdev snd_timer snd usbcore processor 8250_pci sr_mod e1000e intel_agp soundcore i2c_algo_bit wmi cfbcopyarea cfbimgblt i2c_i801 battery ac psmouse mac80211 cdrom evdev nvram intel_gtt agpgart video button i2c_core snd_page_alloc cfbfillrect thermal output nls_base cfg80211 rfkill 8250 serial_core [last unloaded: microcode] 2011-01-12T10:31:59.597+01:00 n22 kernel: 2011-01-12T10:31:59.597+01:00 n22 kernel: Pid: 5057, comm: X Not tainted 2.6.37 #4 6474B84/6474B84 2011-01-12T10:31:59.597+01:00 n22 kernel: EIP: 0060:[f89f9f6e] EFLAGS: 00013246 CPU: 0 2011-01-12T10:31:59.597+01:00 n22 kernel: EIP is at i915_gem_object_pin+0x15e/0x190 [i915] 2011-01-12T10:31:59.597+01:00 n22 kernel: EAX: 0003c47c EBX: f4cd95c0 ECX: EDX: 0003c000 2011-01-12T10:33:34.621+01:00 n22 syslog-ng[2754]: The current log file has a mismatching size/inode information, restarting from the beginning; filename='/proc/kmsg' 2011-01-12T10:33:34.648+01:00 n22 kernel: Linux version 2.6.37 (root@n22) (gcc version 4.4.4 (Gentoo 4.4.4-r2 p1.2, pie-0.4.5) ) #4 SMP Sun Jan 9 16:29:30 CET It's an old pin leak [https://bugzilla.kernel.org/show_bug.cgi?id=17181]. I keep finding little buglets that might contribute, but so far inconclusive. The latest one was: commit 0ba41e449fd0f45f5b29c1009020ab1b298bedda Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sat Jan 8 15:10:41 2011 + drm: Restore the old_fb upon modeset failure ... or else we may end up disabling the wrong framebuffer, leading to an OOPS, e.g: -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32312] openvg rendering is broken on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=32312 Sergey Kondakov virtuous...@gmail.com changed: What|Removed |Added Summary|openvg lion demo freezes |openvg rendering is broken |the system lockup GPU |on r600g |with r600g | -- 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: more intel drm issues (was Re: [git pull] drm intel only fixes)
On Thu, Jan 20, 2011 at 2:22 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua jeff.chua.li...@gmail.com wrote: Rafael send out two patches earlier. Could be related. I was facing issue during resume. No, I'm aware of the rcu-synchronize thing, this isn't it. This is really at the suspend stage, and I had bisected it down to the drm changes. In fact, by now I have bisected it down to a single commit. It's another merge commit, which makes me a bit nervous (I bisected another issue today, and it turned out to simply not be repeatable). But this time the merge commit actually has a real conflict that got fixed up in the merge, and the code around the conflict waits for three seconds, and three seconds is also exactly how long the delay at suspend time is. So I get the feeling that this time it's a real issue, and what happened was that the merge may have been a mismerge. I did see that once during suspend. But as you mentioned, 3 seconds, and it wasn't repeatable. It was at the first suspend right after reboot. Jeff ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33272] Kernel DRM/Radeon KMS BSOD on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=33272 Erdem U. Altinyurt spamjunkea...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #7 from Erdem U. Altinyurt spamjunkea...@gmail.com 2011-01-20 07:28:29 PST --- radeon module loaded and work as intended. I use modprobe radeon pcie_gen2=1 and it works Weird thing is that I enabled GEN1 on my MB bios. Mesa gives segmentation fault but could use KMS properly now. Sorry for disturbing. Thanks. -- 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 33272] Kernel DRM/Radeon KMS BSOD on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=33272 --- Comment #8 from Erdem U. Altinyurt spamjunkea...@gmail.com 2011-01-20 07:45:35 PST --- Created an attachment (id=42226) -- (https://bugs.freedesktop.org/attachment.cgi?id=42226) dmesg of HD3300+HD6850 Previous comment is wrong. Bug is not solved but I just enabled 790GX from bios with surround view So bug is not solved with that flag. modprobe radeon working now because of 790GX internal GPU. I attach the kernel messages. Might be useful to understand problem. KMS looks loaded... -- 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 33272] Kernel DRM/Radeon KMS BSOD on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=33272 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #42226|application/octet-stream|text/plain mime type|| Attachment #42226|0 |1 is patch|| -- 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 33272] Kernel DRM/Radeon KMS BSOD on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=33272 --- Comment #9 from Alex Deucher ag...@yahoo.com 2011-01-20 08:10:24 PST --- Does reverting this commit fix the issue: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=86f5c9edbb3bac37cc8cee6528a929005ba72aad -- 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: more intel drm issues (was Re: [git pull] drm intel only fixes)
On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: Right, the autoreported HEAD may have been already reset to 0 and so hit the wraparound bug which caused it to exit early without actually quiescing the ringbuffer. Yeah, that would explain the issue. Another possibility is that I added a 3s timeout waiting for a request if IRQs were suspended: No, if IRQ's are actually suspended here, then that codepath is totally buggy and would blow up (msleep() doesn't work, and jiffies wouldn't advance on UP). So that's not it. Both of those I think are symptoms of another problem, that perhaps during suspend we are shutting down parts of the chip before idling? That could be, but looking at the code, one thing strikes me: the _normal_ case (of just waiting for enough space in the ring buffer) doesn't need to use the exact case, but the wait for ring buffer to be totally empty does. Which means that the use of the fast-but-inaccurate 'head' sounds wrong for the wait for idle case. So can you explain the difference between intel_read_status_page(ring, 4); vs I915_READ_HEAD(ring); because from looking at the code, I get the notion that intel_read_status_page() may not be exact. But what happens if that inexact value matches our cached ring-actual_head, so we never even try to read the exact case? Does it _stay_ inexact for arbitrarily long times? If so, we might wait for the ring to empty forever (well, until the timeout - the behavior I see), even though the ring really _is_ empty. No? Also, isn't that head ring-actual_head buggy? What about the overflow case? Not that we care, because afaik, 'actual_head' is not actually used anywhere, so it should be called 'pointless_head'? That code looks suspiciously bogus. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote: the -rt patches change the console_semaphore to console_mutex. so a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() Why not just change the functionality of the existing function to be a mutex in the rt patches, instead of having to rename it everywhere? this commit makes things use more neutral function names which dont make implications about the underlying lock. the only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() Signed-off-by: Torben Hohn torb...@gmx.de CC: Thomas Gleixner t...@tglx.de I don't mind this rename, but is it really going to help anything out? What's the odds of the -rt portion of this patch ever making it to mainline? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
On Thu, Jan 20, 2011 at 08:34:48AM -0800, Greg KH wrote: On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote: the -rt patches change the console_semaphore to console_mutex. so a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() Why not just change the functionality of the existing function to be a mutex in the rt patches, instead of having to rename it everywhere? i hope that Thomas already did this in his upcoming -rt series. this commit makes things use more neutral function names which dont make implications about the underlying lock. the only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() Signed-off-by: Torben Hohn torb...@gmx.de CC: Thomas Gleixner t...@tglx.de I don't mind this rename, but is it really going to help anything out? What's the odds of the -rt portion of this patch ever making it to mainline? the -rt portion only changes the semaphore to a mutex. since the console_sem is used with mutex semantics, i dont see any reason, not to merge that portion too. i am just trying to shrink the -rt patch to make it more maintanable :) thanks, greg k-h -- torben Hohn ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: more intel drm issues (was Re: [git pull] drm intel only fixes)
On Thu, 20 Jan 2011 08:07:02 -0800, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: Right, the autoreported HEAD may have been already reset to 0 and so hit the wraparound bug which caused it to exit early without actually quiescing the ringbuffer. Yeah, that would explain the issue. Another possibility is that I added a 3s timeout waiting for a request if IRQs were suspended: No, if IRQ's are actually suspended here, then that codepath is totally buggy and would blow up (msleep() doesn't work, and jiffies wouldn't advance on UP). So that's not it. Both of those I think are symptoms of another problem, that perhaps during suspend we are shutting down parts of the chip before idling? That could be, but looking at the code, one thing strikes me: the _normal_ case (of just waiting for enough space in the ring buffer) doesn't need to use the exact case, but the wait for ring buffer to be totally empty does. Which means that the use of the fast-but-inaccurate 'head' sounds wrong for the wait for idle case. So can you explain the difference between intel_read_status_page(ring, 4); vs I915_READ_HEAD(ring); For I915_READ_HEAD, we need to wake up the GT power well, perform an uncached read from the register, and then power down. This takes on the order of a 100 microseconds (less if the GT is already powered up, etc). Instead a read from the status page is from cached memory. The caveat here is that value is only updated by the gfx engine when its HEAD crosses every 64k boundary. So quite rarely. because from looking at the code, I get the notion that intel_read_status_page() may not be exact. But what happens if that inexact value matches our cached ring-actual_head, so we never even try to read the exact case? Does it _stay_ inexact for arbitrarily long times? If so, we might wait for the ring to empty forever (well, until the timeout - the behavior I see), even though the ring really _is_ empty. No? Ah. Your analysis is spot on and this will cause a hang whilst polling if we enter the loop with the last known head the same as the reported value. Also, isn't that head ring-actual_head buggy? What about the overflow case? Not that we care, because afaik, 'actual_head' is not actually used anywhere, so it should be called 'pointless_head'? This is the one case that I think is handled correctly, ignoring all the other bugs. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33296] New: gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 Summary: gnome-shell broken possibly due to glReadPixels() error Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: sss...@gmail.com Created an attachment (id=42232) -- (https://bugs.freedesktop.org/attachment.cgi?id=42232) gnome-shell (under gdb) output Hi! I've been testing gnome-shell from git (clutter, mutter etc. from git too). I initially got crashing as in https://bugs.freedesktop.org/show_bug.cgi?id=32918 I updated to latest xorg mesa from ubuntu xorg-edgers PPA (mesa 7.11.0-git20110119), this fixes the crashing but mouse events now mostly do not work, and produce warnings like this: (mutter:28983): Clutter-WARNING **: The required ID of 12107392 does not refer to an existing actor; this usually implies that the pick() of an actor is not correctly implemented or that there is an error in the glReadPixels() implementation of the GL driver. Clutter bug on this issue: https://bugs.freedesktop.org//show_bug.cgi?id=24408 -- 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
[PATCH] drm/i915/ringbuffer: Fix use of stale HEAD position whilst polling for space
During suspend, Linus found that his machine would hang for 3 seconds,
and identified that intel_ring_buffer_wait() was the culprit:
Because from looking at the code, I get the notion that
intel_read_status_page() may not be exact. But what happens if that
inexact value matches our cached ring-actual_head, so we never even
try to read the exact case? Does it _stay_ inexact for arbitrarily
long times? If so, we might wait for the ring to empty forever (well,
until the timeout - the behavior I see), even though the ring really
_is_ empty.
As the reported HEAD position is only updated every time it crosses a
64k boundary, whilst draining the ring it is indeed likely to remain one
value. If that value matches the last known HEAD position, we never read
the true value from the register and so trigger a timeout.
Reported-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 40 ++
drivers/gpu/drm/i915/intel_ringbuffer.h |1 -
2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 51fbc5e..6218fa9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -34,6 +34,14 @@
#include i915_trace.h
#include intel_drv.h
+static inline int ring_space(struct intel_ring_buffer *ring)
+{
+ int space = (ring-head HEAD_ADDR) - (ring-tail + 8);
+ if (space 0)
+ space += ring-size;
+ return space;
+}
+
static u32 i915_gem_get_seqno(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
@@ -204,11 +212,9 @@ static int init_ring_common(struct intel_ring_buffer *ring)
if (!drm_core_check_feature(ring-dev, DRIVER_MODESET))
i915_kernel_lost_context(ring-dev);
else {
- ring-head = I915_READ_HEAD(ring) HEAD_ADDR;
+ ring-head = I915_READ_HEAD(ring);
ring-tail = I915_READ_TAIL(ring) TAIL_ADDR;
- ring-space = ring-head - (ring-tail + 8);
- if (ring-space 0)
- ring-space += ring-size;
+ ring-space = ring_space(ring);
}
return 0;
@@ -921,7 +927,7 @@ static int intel_wrap_ring_buffer(struct intel_ring_buffer
*ring)
}
ring-tail = 0;
- ring-space = ring-head - 8;
+ ring-space = ring_space(ring);
return 0;
}
@@ -933,20 +939,22 @@ int intel_wait_ring_buffer(struct intel_ring_buffer
*ring, int n)
unsigned long end;
u32 head;
+ /* If the reported head position has wrapped or hasn't advanced,
+* fallback to the slow and accurate path.
+*/
+ head = intel_read_status_page(ring, 4);
+ if (head ring-head) {
+ ring-head = head;
+ ring-space = ring_space(ring);
+ if (ring-space = n)
+ return 0;
+ }
+
trace_i915_ring_wait_begin (dev);
end = jiffies + 3 * HZ;
do {
- /* If the reported head position has wrapped or hasn't advanced,
-* fallback to the slow and accurate path.
-*/
- head = intel_read_status_page(ring, 4);
- if (head ring-actual_head)
- head = I915_READ_HEAD(ring);
- ring-actual_head = head;
- ring-head = head HEAD_ADDR;
- ring-space = ring-head - (ring-tail + 8);
- if (ring-space 0)
- ring-space += ring-size;
+ ring-head = I915_READ_HEAD(ring);
+ ring-space = ring_space(ring);
if (ring-space = n) {
trace_i915_ring_wait_end(dev);
return 0;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 61d5220..6d6fde8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -47,7 +47,6 @@ struct intel_ring_buffer {
struct drm_device *dev;
struct drm_i915_gem_object *obj;
- u32 actual_head;
u32 head;
u32 tail;
int space;
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33296] gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 --- Comment #1 from Sam Thursfield sss...@gmail.com 2011-01-20 09:45:23 PST --- Created an attachment (id=42233) -- (https://bugs.freedesktop.org/attachment.cgi?id=42233) 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 33296] gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 --- Comment #2 from Sam Thursfield sss...@gmail.com 2011-01-20 09:45:43 PST --- Created an attachment (id=42234) -- (https://bugs.freedesktop.org/attachment.cgi?id=42234) xorg.conf -- 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 33296] gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 --- Comment #3 from Sam Thursfield sss...@gmail.com 2011-01-20 09:46:15 PST --- Created an attachment (id=42235) -- (https://bugs.freedesktop.org/attachment.cgi?id=42235) 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
[Bug 24408] No mouse events in Clutter-based applications.
https://bugs.freedesktop.org/show_bug.cgi?id=24408 --- Comment #3 from Alex Deucher ag...@yahoo.com 2011-01-20 10:08:27 PST --- Is this still an issue with mesa 7.10 or git master? -- 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 33296] gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #42232|text/x-log |text/plain mime type|| Attachment #42232|0 |1 is patch|| -- 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
Broken locking in ttm_bo_swapout
I have a fairly simple opengl application running on nouveau. It effectively just plots a couple of very large images that change regularly. I've been getting an easily repeatable failure, hitting the BUG_ON(in_interrupt) in vfree() that is called during ttm_shrink_work(). Obviously vfree() is being called with a lock held... Looking at the locking up through the stack trace, there's an obvious mistake: There should be a: spin_lock(glob-lru_lock); before the continue in ttm_bo_swapout() in drivers/gpu/drm/ttm/ttm_bo.c --- ttm_bo.c~ 2011-01-05 00:50:19.0 + +++ ttm_bo.c2011-01-20 18:11:57.262813765 + @@ -1761,6 +1761,7 @@ static int ttm_bo_swapout(struct ttm_mem spin_unlock(glob-lru_lock); (void) ttm_bo_cleanup_refs(bo, false, false, false); kref_put(bo-list_kref, ttm_bo_release_list); + spin_lock(glob-lru_lock); continue; } That fixes the problem for me. Matthew ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24408] No mouse events in Clutter-based applications.
https://bugs.freedesktop.org/show_bug.cgi?id=24408 Alexandre Mazari sca...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #4 from Alexandre Mazari sca...@gmail.com 2011-01-20 11:55:27 PST --- Works here for a while now (rawhide's Clutter and 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 33296] gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 --- Comment #5 from Sam Thursfield sss...@gmail.com 2011-01-20 12:14:11 PST --- (In reply to comment #4) What 3D driver are you using? I would suggest trying the r300 gallium driver if you are using the r300 classic driver. I believe xorg-edgers is now shipping the Gallium driver: sam@haji:/opt/xorg/lib$ glxinfo | grep OpenGL OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV370 OpenGL version string: 2.1 Mesa 7.11-devel OpenGL shading language version string: 1.20 OpenGL extensions: -- 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 33301] New: dynpm doesn't downclock
https://bugs.freedesktop.org/show_bug.cgi?id=33301 Summary: dynpm doesn't downclock Product: DRI Version: XOrg 6.7.0 Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: cristikl...@gmail.com Hello, I have an ATI Mobility Radeon HD 2400. I am using Linux 2.6.37. Currently, dynpm does not down-clock the GPU for me. dmesg is filled with the following messages: [245199.552075] [drm:r600_pm_get_dynpm_state], Requested: e: 3 m: 4 p: 16 (about 10 messages / second) I attach a script with all the necessary details. Cristi. -- 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: more intel drm issues (was Re: [git pull] drm intel only fixes)
On Thu, Jan 20, 2011 at 9:51 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
So how about just doing this in the loop? It will mean that the
_first_ read uses the fast cached one (the common case, hopefully),
but then if we loop, we'll use the slow exact one.
(cut-and-paste, so whitespace isn't good):
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 03e3370..11bbfb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -961,6 +961,8 @@ int intel_wait_ring_buffer(struct
intel_ring_buffer *ring, int n)
msleep(1);
if (atomic_read(dev_priv-mm.wedged))
return -EAGAIN;
+ /* Force a re-read. FIXME: what if read_status_page
says 0 too */
+ ring-actual_head = 0;
} while (!time_after(jiffies, end));
trace_i915_ring_wait_end (dev);
return -EBUSY;
This makes no difference. And the reason is exactly that we get the
zero case that I had in the comment.
But THIS attached patch actually seems to fix the slow suspend for me.
I removed the accesses to actual_head, because that whole field
seems to not be used.
So it seems like the intel_read_status_page() thing returns zero
forever when suspending. Maybe you can explain why.
Linus
drivers/gpu/drm/i915/intel_ringbuffer.c |5 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h |1 -
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 03e3370..f6b9baa 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -928,6 +928,7 @@ static int intel_wrap_ring_buffer(struct intel_ring_buffer *ring)
int intel_wait_ring_buffer(struct intel_ring_buffer *ring, int n)
{
+ int reread = 0;
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long end;
@@ -940,9 +941,8 @@ int intel_wait_ring_buffer(struct intel_ring_buffer *ring, int n)
* fallback to the slow and accurate path.
*/
head = intel_read_status_page(ring, 4);
- if (head ring-actual_head)
+ if (reread)
head = I915_READ_HEAD(ring);
- ring-actual_head = head;
ring-head = head HEAD_ADDR;
ring-space = ring-head - (ring-tail + 8);
if (ring-space 0)
@@ -961,6 +961,7 @@ int intel_wait_ring_buffer(struct intel_ring_buffer *ring, int n)
msleep(1);
if (atomic_read(dev_priv-mm.wedged))
return -EAGAIN;
+ reread = 1;
} while (!time_after(jiffies, end));
trace_i915_ring_wait_end (dev);
return -EBUSY;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
index be9087e..5b0abfa 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -47,7 +47,6 @@ struct intel_ring_buffer {
struct drm_device *dev;
struct drm_i915_gem_object *obj;
- u32 actual_head;
u32 head;
u32 tail;
int space;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24802] Graphics errors with Radeon KMS driver on RV770
https://bugzilla.kernel.org/show_bug.cgi?id=24802 Robert Hooker sarv...@gmail.com changed: What|Removed |Added CC||sarv...@gmail.com --- Comment #5 from Robert Hooker sarv...@gmail.com 2011-01-20 20:45:59 --- This has been applied to 2.6.35 longterm, is it appropriate there given that it breaks userspace? Ubuntu started getting a large amount of bug reports about things being broken after updating to 2.6.35.10. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703553 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
On Thu, 20 Jan 2011 17:55:02 +0100 torbenh torb...@gmx.de wrote: On Thu, Jan 20, 2011 at 08:34:48AM -0800, Greg KH wrote: On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote: the -rt patches change the console_semaphore to console_mutex. so a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() Why not just change the functionality of the existing function to be a mutex in the rt patches, instead of having to rename it everywhere? i hope that Thomas already did this in his upcoming -rt series. this commit makes things use more neutral function names which dont make implications about the underlying lock. the only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() Signed-off-by: Torben Hohn torb...@gmx.de CC: Thomas Gleixner t...@tglx.de I don't mind this rename, but is it really going to help anything out? What's the odds of the -rt portion of this patch ever making it to mainline? the -rt portion only changes the semaphore to a mutex. since the console_sem is used with mutex semantics, i dont see any reason, not to merge that portion too. i am just trying to shrink the -rt patch to make it more maintanable :) Yeah, I think it's a better name and if we can indeed switch that semaphore to a mutex then that's a good thing to do. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33272] Kernel DRM/Radeon KMS BSOD on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=33272 --- Comment #10 from Erdem U. Altinyurt spamjunkea...@gmail.com 2011-01-20 13:19:08 PST --- Yes it fixed the problem. :) Now loads KMS thanks. Also I noticed a failure on module load. ... [drm] ib test succeeded in 0 usecs failed to evaluate ATIF got AE_BAD_PARAMETER [drm] Radeon Display Connectors [drm] Connector 0: ... I wish its not important. Thanks -- 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 33272] Kernel DRM/Radeon KMS BSOD on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=33272 Erdem U. Altinyurt spamjunkea...@gmail.com changed: What|Removed |Added Resolution|NOTABUG |FIXED -- 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 33272] Kernel DRM/Radeon KMS BSOD on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=33272 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | AssignedTo|dri-devel@lists.freedesktop |ag...@yahoo.com |.org| --- Comment #11 from Alex Deucher ag...@yahoo.com 2011-01-20 13:59:05 PST --- Created an attachment (id=42240) View: https://bugs.freedesktop.org/attachment.cgi?id=42240 Review: https://bugs.freedesktop.org/review?bug=33272attachment=42240 possible fix Can you try this patch instead of the revert? -- 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 26942] radeon: screen distortion on resume
https://bugzilla.kernel.org/show_bug.cgi?id=26942 --- Comment #5 from Alex Deucher alexdeuc...@gmail.com 2011-01-20 23:22:26 --- Can you dump regs 0x458 and 0x45c using avivotool after resume in the working and non-working states? (run as root): avivotool regmatch 0x458 avivotool regmatch 0x45c You can get avivotool here: http://cgit.freedesktop.org/~airlied/radeontool/ -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26942] radeon: screen distortion on resume
https://bugzilla.kernel.org/show_bug.cgi?id=26942
--- Comment #6 from Alex Deucher alexdeuc...@gmail.com 2011-01-20 23:29:07
---
Can you also attach your dmesg after resume with this patch:
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 4a20a62..c19ea3e 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -418,6 +418,8 @@ static void atombios_crtc_program_ss(struct drm_crtc *crtc,
memset(args, 0, sizeof(args));
+ DRM_INFO(atombios_crtc_program_ss: %d\n, enable);
+
if (ASIC_IS_DCE5(rdev)) {
args.v3.usSpreadSpectrumAmountFrac = 0;
args.v3.ucSpreadSpectrumType = ss-type;
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: simplify atom adjust pll setup
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/atombios_crtc.c | 22 +-
1 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index ebacad6..4a20a62 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -608,14 +608,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
args.v1.usPixelClock = cpu_to_le16(mode-clock
/ 10);
args.v1.ucTransmitterID =
radeon_encoder-encoder_id;
args.v1.ucEncodeMode = encoder_mode;
- if (encoder_mode == ATOM_ENCODER_MODE_DP) {
- if (ss_enabled)
- args.v1.ucConfig |=
-
ADJUST_DISPLAY_CONFIG_SS_ENABLE;
- } else if (encoder_mode ==
ATOM_ENCODER_MODE_LVDS) {
+ if (ss_enabled)
args.v1.ucConfig |=
ADJUST_DISPLAY_CONFIG_SS_ENABLE;
- }
atom_execute_table(rdev-mode_info.atom_context,
index, (uint32_t *)args);
@@ -626,12 +621,12 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
args.v3.sInput.ucTransmitterID =
radeon_encoder-encoder_id;
args.v3.sInput.ucEncodeMode = encoder_mode;
args.v3.sInput.ucDispPllConfig = 0;
+ if (ss_enabled)
+ args.v3.sInput.ucDispPllConfig |=
+ DISPPLL_CONFIG_SS_ENABLE;
if (radeon_encoder-devices
(ATOM_DEVICE_DFP_SUPPORT)) {
struct radeon_encoder_atom_dig *dig =
radeon_encoder-enc_priv;
if (encoder_mode ==
ATOM_ENCODER_MODE_DP) {
- if (ss_enabled)
-
args.v3.sInput.ucDispPllConfig |=
-
DISPPLL_CONFIG_SS_ENABLE;
args.v3.sInput.ucDispPllConfig
|=
DISPPLL_CONFIG_COHERENT_MODE;
/* 16200 or 27000 */
@@ -651,18 +646,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
}
} else if (radeon_encoder-devices
(ATOM_DEVICE_LCD_SUPPORT)) {
if (encoder_mode ==
ATOM_ENCODER_MODE_DP) {
- if (ss_enabled)
-
args.v3.sInput.ucDispPllConfig |=
-
DISPPLL_CONFIG_SS_ENABLE;
args.v3.sInput.ucDispPllConfig
|=
DISPPLL_CONFIG_COHERENT_MODE;
/* 16200 or 27000 */
args.v3.sInput.usPixelClock =
cpu_to_le16(dp_clock / 10);
- } else if (encoder_mode ==
ATOM_ENCODER_MODE_LVDS) {
- if (ss_enabled)
-
args.v3.sInput.ucDispPllConfig |=
-
DISPPLL_CONFIG_SS_ENABLE;
- } else {
+ } else if (encoder_mode !=
ATOM_ENCODER_MODE_LVDS) {
if (mode-clock 165000)
args.v3.sInput.ucDispPllConfig |=
DISPPLL_CONFIG_DUAL_LINK;
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33011] HDMI-A-1 Does not work after resume (But claims it does)
https://bugs.freedesktop.org/show_bug.cgi?id=33011 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #42000|text/x-log |text/plain mime type|| Attachment #42000|0 |1 is patch|| -- 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 33011] HDMI-A-1 Does not work after resume (But claims it does)
https://bugs.freedesktop.org/show_bug.cgi?id=33011 --- Comment #4 from Alex Deucher ag...@yahoo.com 2011-01-20 16:22:23 PST --- Does the LVDS come on when you resume? X may be getting confused and enabling the wrong displays on resume (LVDS+VGA rather than VGA+HDMI) since all are attached. Can you manually reconfigure things using xrandr after resume? -- 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: [Intel-gfx] [PATCH 2/5] i915: Add native backlight control
On Thu, Jan 20, 2011 at 03:13:49PM -0800, Andrew Morton wrote: On Fri, 21 Jan 2011 00:43:46 +0330 Ali Gholami Rudi aliqr...@gmail.com wrote: Ali Gholami Rudi aliqr...@gmail.com wrote: I tried to apply this patch but I get: drivers/gpu/drm/i915/intel_panel.c: In function 'intel_panel_setup_backlight': drivers/gpu/drm/i915/intel_panel.c:319: error: 'struct backlight_properties' has no member named 'type' drivers/gpu/drm/i915/intel_panel.c:319: error: 'BACKLIGHT_RAW' undeclared (first use in this function) drivers/gpu/drm/i915/intel_panel.c:319: error: (Each undeclared identifier is reported only once drivers/gpu/drm/i915/intel_panel.c:319: error: for each function it appears in.) After applying patch 1/5, the patch applied cleanly. Now I can change the brightness using /sys/class/backlight/intel_backlight/brightness. So it does fix my issue. So we have a patch ordering issue and the radeon-expose-backlight-class-device-for-legacy-lvds-encoder.patch build error. He applied 2/5, it didn't build, he applied 1/5 and it built? I don't think that's a patch ordering issue :) I think Michel's patch should fix the Radeon one. If not, can you drop that and keep the rest of the set? I'm travelling at the moment and won't have proper build access until the weekend. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/5] i915: Add native backlight control
On Fri, 21 Jan 2011 00:43:59 + Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Jan 20, 2011 at 03:13:49PM -0800, Andrew Morton wrote: On Fri, 21 Jan 2011 00:43:46 +0330 Ali Gholami Rudi aliqr...@gmail.com wrote: Ali Gholami Rudi aliqr...@gmail.com wrote: I tried to apply this patch but I get: drivers/gpu/drm/i915/intel_panel.c: In function 'intel_panel_setup_backlight': drivers/gpu/drm/i915/intel_panel.c:319: error: 'struct backlight_properties' has no member named 'type' drivers/gpu/drm/i915/intel_panel.c:319: error: 'BACKLIGHT_RAW' undeclared (first use in this function) drivers/gpu/drm/i915/intel_panel.c:319: error: (Each undeclared identifier is reported only once drivers/gpu/drm/i915/intel_panel.c:319: error: for each function it appears in.) After applying patch 1/5, the patch applied cleanly. Now I can change the brightness using /sys/class/backlight/intel_backlight/brightness. So it does fix my issue. So we have a patch ordering issue and the radeon-expose-backlight-class-device-for-legacy-lvds-encoder.patch build error. He applied 2/5, it didn't build, he applied 1/5 and it built? I don't think that's a patch ordering issue :) What, you expect reading skills? I think Michel's patch should fix the Radeon one. If not, can you drop that and keep the rest of the set? I'm travelling at the moment and won't have proper build access until the weekend. OK, I resurrected everything. I updated the new drivers/video/backlight/adp5520_bl.c, but there's a decent chance that unconverted drivers will sneak in. I trust they will still work OK? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/5] i915: Add native backlight control
On Thu, Jan 20, 2011 at 05:03:37PM -0800, Andrew Morton wrote: I updated the new drivers/video/backlight/adp5520_bl.c, but there's a decent chance that unconverted drivers will sneak in. I trust they will still work OK? They should fire a warning on registration but otherwise work. I'll send fixup patches for any I see. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/5] i915: Add native backlight control
( Original posting from [1] ) I have the backlight-type patchset for months in my patch-series (and maintained them if necessary against daily linux-next). Also the last series from 14-Jan-2011 (see 1-5 patch from [2] and the following ones at dri-devel ML). If you couldn't find the updated v2 radeon-backlight-type patch, here the extract from my patch-series: ... # Patch from https://patchwork.kernel.org/patch/491351/ + backlight-type/v2-drm-radeon-kms-Expose-backlight-class-device-for-legacy-LVDS-encoder.patch ... I can only speak for the radeon(-KMS) part with CONFIG_BACKLIGHT_CLASS_DEVICE=y set and against linux-next: It worked, it works. I am a bit angry that someone of the big 5 gets immediately an answer where mine is ignored [3]. So dear Mr. AKPM, if you can standstill for a few moments to answer only one of my questions, through which kernel-tree will this patchset walk trough? Thanks in advance. - Sedat - [1] http://lists.freedesktop.org/archives/dri-devel/2011-January/007378.html [2] http://lists.freedesktop.org/archives/dri-devel/2011-January/007168.html [3] http://lists.freedesktop.org/archives/dri-devel/2011-January/007193.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/5] i915: Add native backlight control
On Fri, 21 Jan 2011 06:36:54 +0100 Sedat Dilek sedat.di...@googlemail.com wrote: ( Original posting from [1] ) I have the backlight-type patchset for months in my patch-series (and maintained them if necessary against daily linux-next). Also the last series from 14-Jan-2011 (see 1-5 patch from [2] and the following ones at dri-devel ML). If you couldn't find the updated v2 radeon-backlight-type patch, here the extract from my patch-series: ... # Patch from https://patchwork.kernel.org/patch/491351/ + backlight-type/v2-drm-radeon-kms-Expose-backlight-class-device-for-legacy-LVDS-encoder.patch ... I can only speak for the radeon(-KMS) part with CONFIG_BACKLIGHT_CLASS_DEVICE=y set and against linux-next: It worked, it works. I am a bit angry that someone of the big 5 gets immediately an answer where mine is ignored [3]. Well, who were they sent to? If it was dri-devel then perhaps the people there felt it was inappropriate to their tree, or they were all busy fixing 100 regressions. If it was Richard then he's been distracted by other things for some time, which is why I recently started handling backlight and leds patches. If it was me then kick me, but I don't think it was. In general, if you think that patches aren't getting attention then let me know and send them to me - harassing people for you is part of my job description. So dear Mr. AKPM, if you can standstill for a few moments to answer only one of my questions, through which kernel-tree will this patchset walk trough? leds and backlight patches are presently getting merged into my tree and I'm sending them into Linus. I make sure that Richard sees them all and when he finds time he helps review them for us. They should turn up in linux-next too - we're working on that. This particular patch series is theoretically a bit late for 2.6.38, but if anyone thinks that's a wrong decision, feel free to explain why. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26942] radeon: screen distortion on resume
https://bugzilla.kernel.org/show_bug.cgi?id=26942 --- Comment #8 from Brett Witherspoon spo...@exherbo.org 2011-01-21 06:33:42 --- Created an attachment (id=44572) -- (https://bugzilla.kernel.org/attachment.cgi?id=44572) dmesg after resume with DRM_INFO patch -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
