dri-devel December 2012

dri-devel@lists.freedesktop.org

121 participants
687 discussions

[PATCH] drm: tegra: Use framebuffer pitch as line stride
by Thierry Reding 04 Dec '12

04 Dec '12

Instead of using the stride derived from the display mode, use the pitch associated with the currently active framebuffer. This fixes a bug where the LCD display content would be skewed when enabling HDMI with a video mode different from that of the LCD. Signed-off-by: Thierry Reding <thierry.reding(a)avionic-design.de> --- drivers/gpu/drm/tegra/dc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 94686e5..41cde76 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -218,7 +218,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc, } bpp = crtc->fb->bits_per_pixel / 8; - win.stride = win.outw * bpp; + win.stride = crtc->fb->pitches[0]; /* program window registers */ value = tegra_dc_readl(dc, DC_CMD_DISPLAY_WINDOW_HEADER); -- 1.8.0

6 12

[PATCH] drm/radeon: add a CS flag END_OF_FRAME
by Marek Olšák 03 Dec '12

03 Dec '12

No version bump is required because setting the flag on older DRM has no effect. This only reserves the bit and doesn't use it. I assume we will use it for buffer eviction heuristics. Signed-off-by: Marek Olšák <maraeo(a)gmail.com> --- include/uapi/drm/radeon_drm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h index 4766c0f..0c8a62c 100644 --- a/include/uapi/drm/radeon_drm.h +++ b/include/uapi/drm/radeon_drm.h @@ -913,6 +913,7 @@ struct drm_radeon_gem_va { /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */ #define RADEON_CS_KEEP_TILING_FLAGS 0x01 #define RADEON_CS_USE_VM 0x02 +#define RADEON_CS_END_OF_FRAME 0x04 /* a hint from userspace which CS is the last one */ /* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the ring type */ #define RADEON_CS_RING_GFX 0 #define RADEON_CS_RING_COMPUTE 1 -- 1.7.10.4

2 1

[PATCH] drm/radeon: use cached memory when evicting for vram on non agp
by j.glisse＠gmail.com 03 Dec '12

03 Dec '12

From: Jerome Glisse <jglisse(a)redhat.com> Force the use of cached memory when evicting from vram on non agp hardware. Also force write combine on agp hw. This is to insure the minimum cache type change when allocating memory and improving memory eviction especialy on pci/pcie hw. Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/radeon_object.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index b91118c..3f9f3bb 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -88,10 +88,20 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain) if (domain & RADEON_GEM_DOMAIN_VRAM) rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_VRAM; - if (domain & RADEON_GEM_DOMAIN_GTT) - rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT; - if (domain & RADEON_GEM_DOMAIN_CPU) - rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM; + if (domain & RADEON_GEM_DOMAIN_GTT) { + if (rbo->rdev->flags & RADEON_IS_AGP) { + rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_TT; + } else { + rbo->placements[c++] = TTM_PL_FLAG_CACHED | TTM_PL_FLAG_TT; + } + } + if (domain & RADEON_GEM_DOMAIN_CPU) { + if (rbo->rdev->flags & RADEON_IS_AGP) { + rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_TT; + } else { + rbo->placements[c++] = TTM_PL_FLAG_CACHED | TTM_PL_FLAG_TT; + } + } if (!c) rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM; rbo->placement.num_placement = c; -- 1.7.11.7

3 2

[Bug 40552] New: r200 crashes in glclear when running the wine d3d tests.
by bugzilla-daemon＠freedesktop.org 03 Dec '12

03 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=40552 Summary: r200 crashes in glclear when running the wine d3d tests. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: stefandoesinger(a)gmx.at Created an attachment (id=50813) --> (https://bugs.freedesktop.org/attachment.cgi?id=50813) last log lines, assertion and backtrace. When running the Wine(www.winehq.org) ddraw/d3d unit tests with r200 they crash due to a failing assertion. The clear is done on a texture attached to a framebuffer. It looks like Mesa is falling back to software, the SW renderer is trying to map the texture into memory and this triggers the assertion. I have not been able to reproduce this in a stand-alone application yet. I'll attach a backtrace and the failing assertion. I'll also file a bug report for the fact that r200 falls back to software at all, I think the hardware could do this clear just fine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 35095] New: [r300g] More screen corruption in WoW with HyperZ enabled.
by bugzilla-daemon＠freedesktop.org 02 Dec '12

02 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=35095 Summary: [r300g] More screen corruption in WoW with HyperZ enabled. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: rankincj(a)googlemail.com There is now a large horizontal swathe of corruption across the middle of the entire screen. This corruption vanishes as soon as I stop exporting RADEON_HYPERZ. This corruption appears with my M66GL (RV530 class) (but not with my RV350), and is very recent - probably since the most recent HyperZ patches. Basically, the corruption looks like lots of little tiles are missing from the picture. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 18

[PATCH -next] drm: tegra: fix missing unlock on error
by Wei Yongjun 02 Dec '12

02 Dec '12

From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> Add the missing unlock before return from function host1x_drm_init() and host1x_drm_exit() in the error handling case. Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> --- drivers/gpu/drm/tegra/host1x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tegra/host1x.c b/drivers/gpu/drm/tegra/host1x.c index bdb97a5..39629e6 100644 --- a/drivers/gpu/drm/tegra/host1x.c +++ b/drivers/gpu/drm/tegra/host1x.c @@ -176,6 +176,7 @@ int host1x_drm_init(struct host1x *host1x, struct drm_device *drm) dev_err(host1x->dev, "DRM setup failed for %s: %d\n", dev_name(client->dev), err); + mutex_unlock(&host1x->clients_lock); return err; } } @@ -203,6 +204,7 @@ int host1x_drm_exit(struct host1x *host1x) dev_err(host1x->dev, "DRM cleanup failed for %s: %d\n", dev_name(client->dev), err); + mutex_unlock(&host1x->clients_lock); return err; } }

2 1

i915 error hangcheck timer elapsed
by Stefan Roas 02 Dec '12

02 Dec '12

Hi there, I've been experiencing X.org hangups for a few month (cannot remember when exactly it started) that are related to the i915 driver. demsg output when the hangup occurs is always the following: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! [drm:i915_reset] *ERROR* Failed to reset chip. System Information: Dell Latitude E5500 Debian stable with vanilla 3.6.8 kernel lspci -vv output for the graphic card is: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0263 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 45 Region 0: Memory at f6c00000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at efe8 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 4122 Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 During the time I lived with the hangup happening, I realized a rather reliable way of reproducing the problem. Which would be to boot up and log into a graphical session, then wait for a few minutes (could run pretty much every program except firefox or a movie player), finally firing up either firefox or mplayer and I got the hang. As I had some spare time on my hands this weekend and a pretty reliable way of reproducing the problem i gave git bisect a try nailing down the commit that broke i915 for me. It came up with commit dabdfe021ab1e985e6566009c774fb03f14b568e Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Mon Mar 26 10:10:27 2012 +0200 drm/i915: Avoid using mappable space for relocation processing through the CPU We try to avoid writing the relocations through the uncached GTT, if the buffer is currently in the CPU write domain and so will be flushed out to main memory afterwards anyway. Also on SandyBridge we can safely write to the pages in cacheable memory, so long as the buffer is LLC mapped. In either of these cases, we therefore do not need to force the reallocation of the buffer into the mappable region of the GTT, reducing the aperture pressure. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> as the culprit. I've undone that commit on 3.6.8 and couldn't reproduce the problem since then. Unfortunately I know close to nothing about graphic cards or drm, so I'm not sure that just undoing those changes is the right thing to do, but I hope it helps you to come up with the right(tm) solution. If you need any additional information or me testing some more suitable fix, let me now. Best regards, Stefan -- Stefan Roas sroas(a)roath.org Joh.-Seb.-Bach-Str. 4 D-91083 Baiersdorf ------------------------------------------------------------------- Key fingerprint = 557C 99BE 865B 1463 2A44 7936 C662 8970 4DA5 50B8

2 1

[Bug 33648] New: Black line in Lightsmark with Z compression enabled (RV530)
by bugzilla-daemon＠freedesktop.org 02 Dec '12

02 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=33648 Summary: Black line in Lightsmark with Z compression enabled (RV530) Product: Mesa Version: git Platform: Other URL: http://dee.cz/lightsmark/Lightsmark2008.2.0.tar.bz2 OS/Version: All Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: drakkk(a)centrum.cz After recent zbuffer compression rework Lightsmark is the only remaining app I've tested which is still not working properly here on RV530. There is a thick black line across the screen in some scenes, particularly: "no radiosity","soft shadows", "penumbra shadows" and the last scene. Maybe this is a known issue and there are many open bugs about HyperZ, however according to db299a9f8244d53d9041fcdbd396a77ebe1f9e3e comment RV530 should just work. So I'm reporting it isn't. Also this is not a regression, it was much worse before and this is the only remaining issue here. To be sure this isn't HiZ issue I've changed line 367 in r300_chipset.c to "caps->hiz_ram = 0;" and it haven't changed anything. r300: AA compression: NO, Z compression: YES, HiZ: NO -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

Re: Brightness control fails between 3.6.8 and 3.7.0-rc7 (Intel 915/Dell Vostro 3560)
by Daniel Vetter 02 Dec '12

02 Dec '12

Including a bunch more lists to the cc. On Sun, Dec 2, 2012 at 12:42 PM, Daniel Vetter <daniel.vetter(a)ffwll.ch> wrote: > On Sun, Dec 2, 2012 at 12:32 PM, Tom St Denis <tstdenis(a)elliptictech.com> wrote: >> I've narrowed it down to sometime between v3.6.8 and v3.7-rc1. So none of the v3.7 series will work with this GPU/panel. > > Hm, that's still a few hundred relevant commits intermingled with a > few thousand that likely don't matter ;-) Can you please attempt a > kernel bisect with git? For a nice howto check out > http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find… > > Also, can you please check which of the different backlight controls > in /sys/class/backlight work on 3.6 (and whether any of them still > work on 3.7)? > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

2 3

[PATCH -next] gma500: medfield: fix potential NULL pointer dereference in mdfld_dsi_brightness_init()
by Wei Yongjun 02 Dec '12

02 Dec '12

From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> The dereference to 'sender' should be moved below the NULL test. Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> --- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c b/drivers/gpu/drm/gma500/mdfld_dsi_output.c index 637dd84..478f8b9 100644 --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c @@ -92,8 +92,8 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config *dsi_config, int pipe) { struct mdfld_dsi_pkg_sender *sender = mdfld_dsi_get_pkg_sender(dsi_config); - struct drm_device *dev = sender->dev; - struct drm_psb_private *dev_priv = dev->dev_private; + struct drm_device *dev; + struct drm_psb_private *dev_priv; u32 gen_ctrl_val; if (!sender) { @@ -101,6 +101,8 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config *dsi_config, int pipe) return; } + dev = sender->dev; + dev_priv = dev->dev_private; /* Set default display backlight value to 85% (0xd8)*/ mdfld_dsi_send_mcs_short(sender, write_display_brightness, 0xd8, 1, true);

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2012