dri-devel May 2013

dri-devel@lists.freedesktop.org

116 participants
705 discussions

[Bug 42678] New: [3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec
by bugzilla-daemon＠bugzilla.kernel.org 12 Jul '13

12 Jul '13

https://bugzilla.kernel.org/show_bug.cgi?id=42678 Summary: [3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec Product: Drivers Version: 2.5 Kernel Version: 3.3-rc1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: maciej.rutecki(a)gmail.com CC: florian(a)mickler.org, just.for.lkml(a)googlemail.com, rjw(a)sisk.pl, maciej.rutecki(a)gmail.com Regression: Yes Subject : [3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec Submitter : Torsten Kaiser <just.for.lkml(a)googlemail.com> Date : 2012-01-21 19:03 Message-ID : CAPVoSvSXMvRb=1itu9DjF+s=6zfAChvUxS-x=b8EV9kOZinNpA(a)mail.gmail.com References : http://marc.info/?l=linux-kernel&m=132717279606670&w=2 This entry is being used for tracking a regression from 3.2. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 23

[Bug 44772] New: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
by bugzilla-daemon＠freedesktop.org 11 Jul '13

11 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=44772 Bug #: 44772 Summary: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes Classification: Unclassified Product: DRI Version: XOrg CVS Platform: All OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: h.judt(a)gmx.at Resuming after hibernation fails sometimes. After reading the snapshot (the percentage reached 100%), the screen would switch back, but instead the monitor goes black and turns off and the complete system hangs. No ssh or sysreq keys work, everything is dead. Some things I noticed that might help: * It does not occur with nomodeset=1. * You don't need X to reproduce this, just console with modesetting enabled is enough. * It is not reproducible reliably, but the likelyness that it will occur is unfortunately not small (I'd say 3-4 out of 10 attempts). * The fastboot kernel parameter is not related to it. That is all with vanilla kernel. Now enter tuxonice, because it provides more information. Tuxonice reads the atomic copy first (20%..40%..60%..80%->100%). Now, it would switch on tuxoniceui and show the progress for reading in the caches. However, in the problem case the switch does not happen, because the system hangs as described for the vanilla kernel (no ssh, sysreq). At this point, one has to push the reset button to reboot. However, tuxonice has a nice feature: It will detect the image, and that it has resumed from this image before. It then asks the user whether he wants to try resuming from that same image again or remove the image and continue booting. If one presses 'C' to resume from the image, this time everything works and the system is fully functional. In fact, it's a 100% chance that the screen does not get black or the system freezes. The issue does not occur at certain cycles, sometimes three hibernation->resume cycles go well, then the fourth and fifth will not work, then the next four are ok and so on... So, I believe there is some issue with hardware initialization and hibernation. It might be that something does not really finish in time. What could there be wrong? This is with vanilla-3.2-rc5 and 3.2-rc7-tuxonice (see http://git.tuxonice.net/?p=tuxonice-head.git;a=summary), but I guess all 3.2-rc kernels will show the same problem. I had troubles hibernating with vanilla-3.2-final, so I could not test this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 12

[Bug 43114] New: Can't set high engine clock for RadeonHD 6620G
by bugzilla-daemon＠bugzilla.kernel.org 04 Jul '13

04 Jul '13

https://bugzilla.kernel.org/show_bug.cgi?id=43114 Summary: Can't set high engine clock for RadeonHD 6620G Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: runetmember(a)gmail.com Regression: No APU model: A8-3500M with Radeon HD 6620G. Laptop model: Acer Aspire 7560G. According to official specs of this APU http://www.amd.com/us/products/notebook/apu/mainstream/Pages/mainstream.asp… https://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units#c… GPU core clock on high profile should be 444 MHz, but even when I set high profile manually ~# cat /sys/class/drm/card0/device/power_method profile ~# cat /sys/class/drm/card0/device/power_profile high GPU core clock is not 444 MHz anyway, even below 200 MHz: ~$ cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 200000 kHz current engine clock: 7990 kHz default memory clock: 667000 kHz Maybe output of radeon_pm_info is incorrect, because change between different profiles and dynpm make no difference in radeon_pm_info information. Reproduceable with Linux 3.2 and Linux 3.4rc3. dmesg of 3.4rc3 boot process attached. Is there any additional information I need to provide? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 4

[Bug 63520] New: r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
by bugzilla-daemon＠freedesktop.org 01 Jul '13

01 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=63520 Priority: medium Bug ID: 63520 Assignee: dri-devel(a)lists.freedesktop.org Summary: r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: pj_beers(a)hotmail.com Hardware: x86 (IA32) Status: NEW Version: 9.0 Component: Drivers/Gallium/r300 Product: Mesa Created attachment 77936 --> https://bugs.freedesktop.org/attachment.cgi?id=77936&action=edit Bad rendering screen 1 Since mesa-9.0, light is rendered incorrectly in the Penumbra games (Overture, Black Plague, Requiem). I find it hard to describe so I've included two good and two bad screenshots from two scenes to illustrate the problem. For, fixing this bug would mean rendering of light sources as in the "good" screenshots. I've bisected (between mesa-8.0 and mesa-9.0) and the first bad commit is 134a0a5ff88851c971fb95863317f640b5b9fa3a , r300/compiler: Use the smart scheduler for r300 cards. I then checked out current master and reverting this commit fixes the problem in master. I compiled mesa with the following options: --with-dri-drivers="radeon,swrast" --with-gallium-drivers="r300,swrast" --enable-gallium-llvm --enable-texture-float --enable-gallium-g3dvl --enable-glx-tls --enable-motif --enable-xvmc My system is Slackware 14.0 with kernel 3.7.6, libdrm-2.4.42 and xf86-video-ati-7.1.0. -- You are receiving this mail because: You are the assignee for the bug.

1 26

[PATCH] drm/omap: change "!CONFIG_FB_OMAP2" to "!FB_OMAP2"
by Paul Bolle 28 Jun '13

28 Jun '13

Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- Untested. Perhaps the first test that people with access to the relevant hardware might do, is to test _before applying this patch_ with FB_OMAP2 set. Perhaps this negative dependency isn't needed at all. Or is it obvious? drivers/gpu/drm/omapdrm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index 09f65dc..45875a0 100644 --- a/drivers/gpu/drm/omapdrm/Kconfig +++ b/drivers/gpu/drm/omapdrm/Kconfig @@ -1,7 +1,7 @@ config DRM_OMAP tristate "OMAP DRM" - depends on DRM && !CONFIG_FB_OMAP2 + depends on DRM && !FB_OMAP2 depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM depends on OMAP2_DSS select DRM_KMS_HELPER -- 1.7.11.7

5 5

[PATCH] gpu/host1x: Remove DRIVER_BUS_PLATFORM from driver_features
by Laurent Pinchart 27 Jun '13

27 Jun '13

From: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> DRIVER_BUS_PLATFORM is not a DRM driver feature flag, it must not be set in the driver's driver_features field. Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> --- drivers/gpu/host1x/drm/drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c index 2b561c9..e658a2a 100644 --- a/drivers/gpu/host1x/drm/drm.c +++ b/drivers/gpu/host1x/drm/drm.c @@ -605,7 +605,7 @@ static void tegra_debugfs_cleanup(struct drm_minor *minor) #endif struct drm_driver tegra_drm_driver = { - .driver_features = DRIVER_BUS_PLATFORM | DRIVER_MODESET | DRIVER_GEM, + .driver_features = DRIVER_MODESET | DRIVER_GEM, .load = tegra_drm_load, .unload = tegra_drm_unload, .open = tegra_drm_open, -- Regards, Laurent Pinchart

3 3

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list
by ville.syrjala＠linux.intel.com 23 Jun '13

23 Jun '13

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Having both modes can be beneficial for video playback cases. If you can match the video framerate exactly, and the audio and video clocks come from the same source, you should be able to avoid dropped/repeated frames without expensive operations such as resampling the audio to match video output rate. Rather than add both variants based on the CEA extension short video descriptors in do_cea_modes(), add only one variant there. Once all the EDID has been fully probed, do a loop over the entire probed mode list, during which we add the other variants for all modes that match CEA modes. This allows us to match modes that didn't come via the CEA short video descriptors. For example one Samsung TV here doesn't have the 640x480-60 mode as a SVD, but instead it's specified via a detailed timing descriptor. Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- A few people requested this. Originally I was a bit opposed to it, but when I thought about it a bit more I figured if the audio and video clocks come from the same source (or happen to be close enough w/o significant drift), this could provide a better A/V sync w/o resampling tricks. drivers/gpu/drm/drm_edid.c | 102 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 88 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 9e62bbe..e8d17ee 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2321,6 +2321,31 @@ u8 *drm_find_cea_extension(struct edid *edid) } EXPORT_SYMBOL(drm_find_cea_extension); +/* + * Calculate the alternate clock for the CEA mode + * (60Hz vs. 59.94Hz etc.) + */ +static unsigned int +cea_mode_alternate_clock(const struct drm_display_mode *cea_mode) +{ + unsigned int clock = cea_mode->clock; + + if (cea_mode->vrefresh % 6 != 0) + return clock; + + /* + * edid_cea_modes contains the 59.94Hz + * variant for 240 and 480 line modes, + * and the 60Hz variant otherwise. + */ + if (cea_mode->vdisplay == 240 || cea_mode->vdisplay == 480) + clock = clock * 1001 / 1000; + else + clock = DIV_ROUND_UP(clock * 1000, 1001); + + return clock; +} + /** * drm_match_cea_mode - look for a CEA mode matching given mode * @to_match: display mode @@ -2339,21 +2364,9 @@ u8 drm_match_cea_mode(const struct drm_display_mode *to_match) const struct drm_display_mode *cea_mode = &edid_cea_modes[mode]; unsigned int clock1, clock2; - clock1 = clock2 = cea_mode->clock; - /* Check both 60Hz and 59.94Hz */ - if (cea_mode->vrefresh % 6 == 0) { - /* - * edid_cea_modes contains the 59.94Hz - * variant for 240 and 480 line modes, - * and the 60Hz variant otherwise. - */ - if (cea_mode->vdisplay == 240 || - cea_mode->vdisplay == 480) - clock1 = clock1 * 1001 / 1000; - else - clock2 = DIV_ROUND_UP(clock2 * 1000, 1001); - } + clock1 = cea_mode->clock; + clock2 = cea_mode_alternate_clock(cea_mode); if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) || KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) && @@ -2364,6 +2377,66 @@ u8 drm_match_cea_mode(const struct drm_display_mode *to_match) } EXPORT_SYMBOL(drm_match_cea_mode); +static int +add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid) +{ + struct drm_device *dev = connector->dev; + struct drm_display_mode *mode, *tmp; + LIST_HEAD(list); + int modes = 0; + + /* Don't add CEA modes if the CEA extension block is missing */ + if (!drm_find_cea_extension(edid)) + return 0; + + /* + * Go through all probed modes and create a new mode + * with the alternate clock for certain CEA modes. + */ + list_for_each_entry(mode, &connector->probed_modes, head) { + const struct drm_display_mode *cea_mode; + struct drm_display_mode *newmode; + u8 cea_mode_idx = drm_match_cea_mode(mode) - 1; + unsigned int clock1, clock2; + + if (cea_mode_idx >= ARRAY_SIZE(edid_cea_modes)) + continue; + + cea_mode = &edid_cea_modes[cea_mode_idx]; + + clock1 = cea_mode->clock; + clock2 = cea_mode_alternate_clock(cea_mode); + + if (clock1 == clock2) + continue; + + if (mode->clock != clock1 && mode->clock != clock2) + continue; + + newmode = drm_mode_duplicate(dev, cea_mode); + if (!newmode) + continue; + + /* + * The current mode could be either variant. Make + * sure to pick the "other" clock for the new mode. + */ + if (mode->clock != clock1) + newmode->clock = clock1; + else + newmode->clock = clock2; + + list_add_tail(&newmode->head, &list); + } + + list_for_each_entry_safe(mode, tmp, &list, head) { + list_del(&mode->head); + drm_mode_probed_add(connector, mode); + modes++; + } + + return modes; +} static int do_cea_modes (struct drm_connector *connector, u8 *db, u8 len) @@ -2946,6 +3019,7 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF) num_modes += add_inferred_modes(connector, edid); num_modes += add_cea_modes(connector, edid); + num_modes += add_alternate_cea_modes(connector, edid); if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) edid_fixup_preferred(connector, quirks); -- 1.8.1.5

5 9

[Bug 58021] New: [BISECTED] nouveau, nv50: External VGA not detected anymore
by bugzilla-daemon＠bugzilla.kernel.org 20 Jun '13

20 Jun '13

https://bugzilla.kernel.org/show_bug.cgi?id=58021 Summary: [BISECTED] nouveau, nv50: External VGA not detected anymore Product: Drivers Version: 2.5 Kernel Version: 3.7.0-rc4+ - 3.9 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: wippbox(a)gmx.net Regression: No Created an attachment (id=101211) --> (https://bugzilla.kernel.org/attachment.cgi?id=101211) dmesg for last good commit I have a lenove thinkpad T61p with a NVIDIA Corporation G84GLM [Quadro FX 570M]. When connecting my external VGA monitor my monitor is no more detected properly: > cat /sys/class/drm/card0-VGA-1/status gives now "disconnected" Last good commit is ef22c8bb7b3fac45919b7fde412d36d1a8367d51 drm/nv50/disp: call into core to handle dac/sor power state changes First bad commit is 7ebb38b556485449bfaa506a196439f6a6fd6ebd drm/nv50/disp: call into core for dac load detection The responsible function is nv50_dac_detect in drivers/gpu/drm/nouveau/nv50_dac.c (moved to drivers/gpu/drm/nouveau/nv50_display.c in more recent kernels). Also tried a 3.9.1 kernel. The problem still remains. However, replacing nv50_dac_detect with the corresponding version from the last good commit fixed the problem (tried a 3.8.10 kernel). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 7

[PATCH 0/7] drm/i915: fbdev mode restoration improvements
by ville.syrjala＠linux.intel.com 19 Jun '13

19 Jun '13

This series attempts to make sure we turn off any cursor and sprite planes when we restore the fbdev mode. Some of this stuff depends on the other series I just posted: '[PATCH 0/6] drm/i915: Unfify some modeset sequences' I also noticed some crap when looking at the code, so I slapped on a few cleanups to the end

5 24

[PATCH v3 0/3] Prime helpers
by Aaron Plattner 19 Jun '13

19 Jun '13

This series adds helper functions that abstract the core parts of .gem_prime_import and .gem_prime_export so that drivers don't have to worry about the low-level details. These helpers are optional. A driver can use them by plugging in drm_gem_prime_import and drm_gem_prime_export into the drm_driver structure, or it can bypass them by plugging in its own functions. The first patch adds these helpers, and the later patches switch three drivers over to using them. This version of the series addresses concerns raised by Daniel Vetter, and to leave the vmap locking and refcounting to the dma-buf core code. It also drops Exynos from the series since its driver diverged between when I first sent out this series and now. This series depends on commit 90b6e90cb03352a352015ca213ac9f4fab3308f3 of the for-next branch of git://git.linaro.org/people/sumitsemwal/linux-dma-buf Aaron Plattner (3): drm: add prime helpers drm/nouveau: use prime helpers drm/radeon: use prime helpers Documentation/DocBook/drm.tmpl | 4 + drivers/gpu/drm/drm_prime.c | 186 +++++++++++++++++++++++++++++++- drivers/gpu/drm/nouveau/nouveau_bo.h | 1 - drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 - drivers/gpu/drm/nouveau/nouveau_gem.h | 10 +- drivers/gpu/drm/nouveau/nouveau_prime.c | 173 ++++------------------------- drivers/gpu/drm/radeon/radeon.h | 1 - drivers/gpu/drm/radeon/radeon_drv.c | 21 ++-- drivers/gpu/drm/radeon/radeon_prime.c | 170 ++++------------------------- include/drm/drmP.h | 12 +++ 11 files changed, 270 insertions(+), 319 deletions(-) -- 1.8.1.1

4 14

← Newer
1
...
44
45
46
47
48
49
50
...
71
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2013