dri-devel November 2014

dri-devel@lists.freedesktop.org

182 participants
1119 discussions

[Bug 87791] New: radeonsi lockup and oops
by bugzilla-daemon＠bugzilla.kernel.org 06 Nov '14

06 Nov '14

https://bugzilla.kernel.org/show_bug.cgi?id=87791 Bug ID: 87791 Summary: radeonsi lockup and oops Product: Drivers Version: 2.5 Kernel Version: 3.17 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: acab(a)digitalfuture.… [View More]it Regression: No Created attachment 156761 --> https://bugzilla.kernel.org/attachment.cgi?id=156761&action=edit lockup example (no oops) After upgrading mesa from mesa-10.3.0 to mesa-10.3.1 the Radeon HD 7700 card locks up several times a day without any specific trigger (or reliable way to reproduce it). Xorg appears frozen with just the mouse pointer moving. It's not even possible to switch to a VT, however everything else works just fine. At any given time the X bt looks like this: Thread 2 (Thread 0x7fe8147be700 (LWP 2415)): #0 0x00007fe81b4d911c in pthread_cond_wait () from /lib64/libpthread.so.0 #1 0x00007fe816a807a3 in ?? () from /usr/lib64/dri/radeonsi_dri.so #2 0x00007fe816a7ffc7 in ?? () from /usr/lib64/dri/radeonsi_dri.so #3 0x00007fe81b4d5083 in start_thread () from /lib64/libpthread.so.0 #4 0x00007fe81b9da3ad in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fe81d607880 (LWP 2380)): #0 0x00007fe81b9836e9 in __memcpy_sse2_unaligned () from /lib64/libc.so.6 #1 0x00007fe816857a46 in ?? () from /usr/lib64/dri/radeonsi_dri.so #2 0x00007fe816858742 in ?? () from /usr/lib64/dri/radeonsi_dri.so #3 0x00007fe816859452 in ?? () from /usr/lib64/dri/radeonsi_dri.so #4 0x00007fe8168abf13 in ?? () from /usr/lib64/dri/radeonsi_dri.so #5 0x00007fe8168ac993 in ?? () from /usr/lib64/dri/radeonsi_dri.so #6 0x00007fe81684ad74 in ?? () from /usr/lib64/dri/radeonsi_dri.so #7 0x00007fe81684c510 in ?? () from /usr/lib64/dri/radeonsi_dri.so #8 0x00007fe81a58b883 in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #9 0x00007fe81a58c64e in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #10 0x00007fe81a58d160 in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #11 0x00007fe81a58d81c in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #12 0x00007fe81a56c674 in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #13 0x00007fe81a56cd84 in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #14 0x00007fe81a56dd5e in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #15 0x00007fe81a56e6ba in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #16 0x0000000000563e2d in miCopyRegion () #17 0x00000000005643b6 in miDoCopy () #18 0x00007fe81a56e6fd in ?? () from /usr/lib64/xorg/modules/libglamoregl.so #19 0x0000000000511828 in ?? () #20 0x0000000000432291 in ?? () #21 0x0000000000435d3e in ?? () #22 0x0000000000439b6a in ?? () #23 0x00007fe81b913a65 in __libc_start_main () from /lib64/libc.so.6 #24 0x000000000042531e in _start () -- You are receiving this mail because: You are watching the assignee of the bug. [View Less]

1 7

[PATCH 1/3] drm/tegra: Fix error handling cleanup
by Thierry Reding 06 Nov '14

06 Nov '14

From: Thierry Reding <treding(a)nvidia.com> The DRM driver's ->load() implementation didn't do a good job (no job at all really) cleaning up on failure. Fix that by undoing any prior setup when an error occurs. This requires a bit of rework to make it possible to clean up fbdev midway. This was tested by injecting errors at various points during the initialization sequence and verifying that error cleanup didn't crash and no memory leaked (using kmemleak). Reported-by: Stéphane … [View More]Marchesin <marcheu(a)google.com> Reported-by: Sean Paul <seanpaul(a)google.com> Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/gpu/drm/tegra/drm.c | 20 ++++++++++++++++---- drivers/gpu/drm/tegra/drm.h | 1 + drivers/gpu/drm/tegra/fb.c | 20 +++++++++++++++++--- 3 files changed, 34 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 59736bb810cd..e1632fb03a89 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -42,13 +42,13 @@ static int tegra_drm_load(struct drm_device *drm, unsigned long flags) err = tegra_drm_fb_prepare(drm); if (err < 0) - return err; + goto config; drm_kms_helper_poll_init(drm); err = host1x_device_init(device); if (err < 0) - return err; + goto fbdev; /* * We don't use the drm_irq_install() helpers provided by the DRM @@ -59,13 +59,25 @@ static int tegra_drm_load(struct drm_device *drm, unsigned long flags) err = drm_vblank_init(drm, drm->mode_config.num_crtc); if (err < 0) - return err; + goto device; err = tegra_drm_fb_init(drm); if (err < 0) - return err; + goto vblank; return 0; + +vblank: + drm_vblank_cleanup(drm); +device: + host1x_device_exit(device); +fbdev: + drm_kms_helper_poll_fini(drm); + tegra_drm_fb_free(drm); +config: + drm_mode_config_cleanup(drm); + kfree(tegra); + return err; } static int tegra_drm_unload(struct drm_device *drm) diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h index b994c017971d..ef2faaef5936 100644 --- a/drivers/gpu/drm/tegra/drm.h +++ b/drivers/gpu/drm/tegra/drm.h @@ -288,6 +288,7 @@ bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer); int tegra_fb_get_tiling(struct drm_framebuffer *framebuffer, struct tegra_bo_tiling *tiling); int tegra_drm_fb_prepare(struct drm_device *drm); +void tegra_drm_fb_free(struct drm_device *drm); int tegra_drm_fb_init(struct drm_device *drm); void tegra_drm_fb_exit(struct drm_device *drm); #ifdef CONFIG_DRM_TEGRA_FBDEV diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c index 3513d12d5aa1..0474241ac2a4 100644 --- a/drivers/gpu/drm/tegra/fb.c +++ b/drivers/gpu/drm/tegra/fb.c @@ -289,6 +289,11 @@ static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm) return fbdev; } +static void tegra_fbdev_free(struct tegra_fbdev *fbdev) +{ + kfree(fbdev); +} + static int tegra_fbdev_init(struct tegra_fbdev *fbdev, unsigned int preferred_bpp, unsigned int num_crtc, @@ -322,7 +327,7 @@ fini: return err; } -static void tegra_fbdev_free(struct tegra_fbdev *fbdev) +static void tegra_fbdev_exit(struct tegra_fbdev *fbdev) { struct fb_info *info = fbdev->base.fbdev; @@ -345,7 +350,7 @@ static void tegra_fbdev_free(struct tegra_fbdev *fbdev) } drm_fb_helper_fini(&fbdev->base); - kfree(fbdev); + tegra_fbdev_free(fbdev); } void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev) @@ -393,6 +398,15 @@ int tegra_drm_fb_prepare(struct drm_device *drm) return 0; } +void tegra_drm_fb_free(struct drm_device *drm) +{ +#ifdef CONFIG_DRM_TEGRA_FBDEV + struct tegra_drm *tegra = drm->dev_private; + + tegra_fbdev_free(tegra->fbdev); +#endif +} + int tegra_drm_fb_init(struct drm_device *drm) { #ifdef CONFIG_DRM_TEGRA_FBDEV @@ -413,6 +427,6 @@ void tegra_drm_fb_exit(struct drm_device *drm) #ifdef CONFIG_DRM_TEGRA_FBDEV struct tegra_drm *tegra = drm->dev_private; - tegra_fbdev_free(tegra->fbdev); + tegra_fbdev_exit(tegra->fbdev); #endif } -- 2.1.3 [View Less]

2 4

-next plans/status
by Dave Airlie 06 Nov '14

06 Nov '14

So since -rc5/6 cutoff last merge windows was so successful from my POV, I think I'll keep trucking with the idea. Things I have on my radar for this window, outside normal driver pull requests: a) rockchip drm - this needs IOMMU driver merged first so I can even compile it, on hold but shouldn't be a problem if the iommu driver gets merged somewhere first. b) atmel hlcdc - where are we on the precursor patches for this? c) atomic - Daniel seems to have done a good job pulling the helpers … [View More]

5 4

Re: [lm-sensors] Kaveri [and Radeon] temps
by Guenter Roeck 06 Nov '14

06 Nov '14

On Wed, Nov 05, 2014 at 04:15:54PM -0500, James Cloos wrote: > I'm getting odd temp readings on an A8-7600 with 3.3.4 and Linus' > current kernel. > > Eg, the gpu temp shows up when (mostly) idle as: > > radeon-pci-0008 > Adapter: PCI adapter > temp1: -1.0°C (crit = +120.0°C, hyst = +90.0°C) > The driver for the Radeon chips is maintained by the radeon driver maintainers, so you might want to ask at dri-devel(a)lists.freedesktop.org (copied with this … [View More]

3 3

[PATCH v2 1/2] of: Add vendor prefix for HannStar Display Corporation
by Philipp Zabel 06 Nov '14

06 Nov '14

Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- Changes since v1: - Rebased onto v3.18-rc1 --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..9863039 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -64,6 +64,7 @@ … [View More]

3 4

[Bug 80365] New: [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed
by bugzilla-daemon＠freedesktop.org 06 Nov '14

06 Nov '14

https://bugs.freedesktop.org/show_bug.cgi?id=80365 Priority: medium Bug ID: 80365 Assignee: dri-devel(a)lists.freedesktop.org Summary: [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed Severity: normal Classification: Unclassified OS: Linux (All) Reporter: neatnoise(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.2 … [View More]

1 2

[Bug 71134] New: AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
by bugzilla-daemon＠freedesktop.org 06 Nov '14

06 Nov '14

https://bugs.freedesktop.org/show_bug.cgi?id=71134 Priority: medium Bug ID: 71134 Assignee: dri-devel(a)lists.freedesktop.org Summary: AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues Severity: normal Classification: Unclassified OS: Linux (All) Reporter: neatnoise(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git … [View More] Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 88495 --> https://bugs.freedesktop.org/attachment.cgi?id=88495&action=edit dmesg Hello, I would like to report a list of issues I've run into after some time of using mesa gallium driver for AMD Radeon 7790 (BONAIRE Sea Islands chip). Used components: OS: Gentoo User space packages: media-libs/mesa git sys-devel/llvm git x11-libs/libdrm git x11-libs/glamor git x11-drivers/xf86-video-ati git x11-base/xorg-server 1.14.3 Linux Kernel: 3.12.0-rc7 Rendering issues (tested with window managers: metacity and compiz): - rendering corruption while scrolling web pages even if inbrowser hardware acceleration is disabled (in Chrome as well as in Firefox). There is kind of pixel offset on the diagonal of rendered web page and corruption of images, borders (it happens only while scrolling). - Taking screenshot and using gksu (I'm using gnome 2 environment) results in huge rendering slow down (about 1 fps). I have to reload a window manager to fix this issue. - Introduced dpm to Sea Islands in 3.12 kernel (while enabled) leads to image corruption when moving windows, playing videos (in a browser and a video player), scrolling websites. The corrupted image shows as flickering and messing around parts of the screen. The rendered image is ok only if nothing happens on the screen. - anisotropic filtering doesn't seem to work (tested in sauerbraten game). After applaying there is no visual difference between bilinear filtering and anisotropic filtering. Stability issues: - Any use of OpenGL hardware acceleration after few minutes leads to GPU lockup (from basic OpenGL games like sauerbraten, inbrowser hardware acceleration, to compiz window manager). Glamor + metacity seems to work without GPU lockups. - Playing videos in mplayer (VO: [vdpau]) also leads to a GPU lockup from time to time. The same happens in firefox browser while playing youtube videos in uvd decoding + flash Performance issues: - I get much less fps compared to my old card - Radeon 4850 (r600g driver) even if the clocks are manually set to a maximal frequency. - Compiz with basic effects is sometimes not fluent - drops to less than 30 fps especially when there are more windows opened. I would like attach any GPU lockup logs but dmesg doesn't leave any trace. More than half of lockups are not recoverable and I have to reboot the computer. Screens and logs are in the attachments. Thank you for any help in resolving these issues. -- You are receiving this mail because: You are the assignee for the bug. [View Less]

1 8

[PATCH] drm/exynos: resolve infinite loop issue on multi-platform
by Inki Dae 06 Nov '14

06 Nov '14

This patch resolves temporarily infinite loop issue incurred when Exynos drm driver is enabled and multi-platform kernel is used by registering Exynos drm device object only in case of Exynos SoC. So this patch will be replaced with more generic way later. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/… [View More]

3 4

[PATCH] drm/exynos/dsi: simplify hotplug code
by Andrzej Hajda 06 Nov '14

06 Nov '14

Exynos DSI driver uses DSI bus attach/detach callbacks to implement panel hotplug mechanism. The patch moves panel attachment code from .detect callback to DSI bus callbacks. It makes the code simpler and more straightforward. The patch removes also redundant and lock unprotected dpms_off call from unbind code. Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> --- Hi, This patch simplifies drm part of hotplug mechanism in dsi attach/detach callbacks. It also fixes minor bug with … [View More]unprotected dpms_off call, which is unneccesary anyway. But the main reason I have looked at this code again is to show that we do not need zombie panels, we can kill panels properly if we have hot plug/unplug callbacks. And it is quite simple: we just need to take mode_config.mutex locks to synchronize dsi callbacks with drm, nothing more. It works nicely because of two things: - panel callbacks are called always under this lock, - callbacks are installed after drmdev creation and deinstalled before drmdev destroy - this way we assure drmdev is always present in callbacks. Regards Andrzej drivers/gpu/drm/exynos/exynos_drm_dsi.c | 61 ++++++++++++++++++++------------- 1 file changed, 38 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index 5e38d15..60306c1 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -271,7 +271,6 @@ struct exynos_dsi { struct exynos_drm_display display; struct mipi_dsi_host dsi_host; struct drm_connector connector; - struct device_node *panel_node; struct drm_panel *panel; struct device *dev; @@ -1147,9 +1146,10 @@ static int exynos_dsi_init(struct exynos_dsi *dsi) static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi) { + struct device_node *panel_node = dsi->panel->dev->of_node; int ret; - dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0); + dsi->te_gpio = of_get_named_gpio(panel_node, "te-gpios", 0); if (!gpio_is_valid(dsi->te_gpio)) { dev_err(dsi->dev, "no te-gpios specified\n"); ret = dsi->te_gpio; @@ -1194,14 +1194,28 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host, struct mipi_dsi_device *device) { struct exynos_dsi *dsi = host_to_dsi(host); + struct drm_device *drm_dev = dsi->connector.dev; + bool changed = false; dsi->lanes = device->lanes; dsi->format = device->format; dsi->mode_flags = device->mode_flags; - dsi->panel_node = device->dev.of_node; - if (dsi->connector.dev) - drm_helper_hpd_irq_event(dsi->connector.dev); + mutex_lock(&drm_dev->mode_config.mutex); + + dsi->panel = of_drm_find_panel(device->dev.of_node); + if (dsi->panel) { + drm_panel_attach(dsi->panel, &dsi->connector); + if (drm_dev->mode_config.poll_enabled) { + dsi->connector.status = connector_status_connected; + changed = true; + } + } + + mutex_unlock(&drm_dev->mode_config.mutex); + + if (changed) + drm_kms_helper_hotplug_event(drm_dev); /* * This is a temporary solution and should be made by more generic way. @@ -1223,13 +1237,29 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host *host, struct mipi_dsi_device *device) { struct exynos_dsi *dsi = host_to_dsi(host); + struct drm_device *drm_dev = dsi->connector.dev; + struct exynos_drm_display *display = dev_get_drvdata(dsi->dev); + bool changed = false; exynos_dsi_unregister_te_irq(dsi); - dsi->panel_node = NULL; + mutex_lock(&drm_dev->mode_config.mutex); + + display->ops->dpms(display, DRM_MODE_DPMS_OFF); + + if (dsi->panel) { + drm_panel_detach(dsi->panel); + dsi->panel = NULL; + if (drm_dev->mode_config.poll_enabled) { + dsi->connector.status = connector_status_disconnected; + changed = true; + } + } + + mutex_unlock(&drm_dev->mode_config.mutex); - if (dsi->connector.dev) - drm_helper_hpd_irq_event(dsi->connector.dev); + if (changed) + drm_kms_helper_hotplug_event(drm_dev); return 0; } @@ -1425,19 +1455,6 @@ exynos_dsi_detect(struct drm_connector *connector, bool force) { struct exynos_dsi *dsi = connector_to_dsi(connector); - if (!dsi->panel) { - dsi->panel = of_drm_find_panel(dsi->panel_node); - if (dsi->panel) - drm_panel_attach(dsi->panel, &dsi->connector); - } else if (!dsi->panel_node) { - struct exynos_drm_display *display; - - display = platform_get_drvdata(to_platform_device(dsi->dev)); - exynos_dsi_dpms(display, DRM_MODE_DPMS_OFF); - drm_panel_detach(dsi->panel); - dsi->panel = NULL; - } - if (dsi->panel) return connector_status_connected; @@ -1660,8 +1677,6 @@ static void exynos_dsi_unbind(struct device *dev, struct device *master, struct exynos_drm_display *display = dev_get_drvdata(dev); struct exynos_dsi *dsi = display_to_dsi(display); - exynos_dsi_dpms(display, DRM_MODE_DPMS_OFF); - mipi_dsi_host_unregister(&dsi->dsi_host); } -- 1.9.1 [View Less]

2 2

[PATCH 0/2] make imx hdmi publicly used by dw hdmi compatible platform
by Andy Yan 06 Nov '14

06 Nov '14

From: Andy yan <andy.yan(a)rock-chips.com> We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly difference, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only access by word), 4K support(imx6 doesn't support 4k, but rk3288 does). To reuse the imx-hdmi driver, we do this patch set: patch (1): split out imx-soc code … [View More]

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2014