dri-devel September 2013

dri-devel@lists.freedesktop.org

153 participants
824 discussions

[Bug 43341] New: CoreBreach: Crash in r600_update_derived_state
by bugzilla-daemon＠freedesktop.org 19 Sep '13

19 Sep '13

https://bugs.freedesktop.org/show_bug.cgi?id=43341 Bug #: 43341 Summary: CoreBreach: Crash in r600_update_derived_state Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se Created attachment 53956 --> https://bugs.freedesktop.org/attachment.cgi?id=53956 backtrace Hi, The game CoreBreach crashes when the ships guns are fired, or when the walls of the racetrack are hit. This only happens when Post Processing is turned on (which it is by default). The crash happens with both git master and in Mesa 7.11.1. The game is so far only available as a beta: http://phoronix.com/forums/showthread.php?65016-A-New-Commercial-Game-For-L… A backtrace is attached. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.2 -- xserver: 1.11.1.902 -- mesa: c8db5a3d535c347193556c0d4a8fad83d96be184 -- drm: 2.4.27 -- kernel: 3.1.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

[3.12-rc1 regression] X fails to start on Latitude E6510 w/ NOUVEAU DRM driver
by Mikael Pettersson 19 Sep '13

19 Sep '13

Dell Latitude E6510, CONFIG_DRM_NOUVEAU, 64-bit Fedora 17 user-space, Xorg drivers, and 01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev a2). With 3.11 X starts fine, with 3.12-rc1 it fails with the following in Xorg.0.log: ... [ 56.819] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so [ 56.842] (II) Module nouveau: vendor="X.Org Foundation" [ 56.842] compiled for 1.12.2, module version = 0.0.16 [ 56.842] Module class: X.Org Video Driver [ 56.842] ABI class: X.Org Video Driver, version 12.0 [ 56.842] (II) NOUVEAU driver [ 56.842] (II) NOUVEAU driver for NVIDIA chipset families : [ 56.842] RIVA TNT (NV04) [ 56.842] RIVA TNT2 (NV05) [ 56.842] GeForce 256 (NV10) [ 56.842] GeForce 2 (NV11, NV15) [ 56.842] GeForce 4MX (NV17, NV18) [ 56.842] GeForce 3 (NV20) [ 56.842] GeForce 4Ti (NV25, NV28) [ 56.842] GeForce FX (NV3x) [ 56.842] GeForce 6 (NV4x) [ 56.842] GeForce 7 (G7x) [ 56.842] GeForce 8 (G8x) [ 56.842] GeForce GTX 200 (NVA0) [ 56.842] GeForce GTX 400 (NVC0) [ 56.842] (--) using VT number 7 [ 56.845] drmOpenDevice: node name is /dev/dri/card0 [ 56.845] drmOpenDevice: open result is 9, (OK) [ 56.845] drmOpenByBusid: Searching for BusID pci:0000:01:00.0 [ 56.845] drmOpenDevice: node name is /dev/dri/card0 [ 56.845] drmOpenDevice: open result is 9, (OK) [ 56.845] drmOpenByBusid: drmOpenMinor returns 9 [ 56.845] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 [ 56.845] (EE) [drm] failed to open device [ 56.845] (EE) No devices detected. With 3.11 one instead sees: ... [ 33.879] drmOpenByBusid: drmOpenMinor returns 9 [ 33.879] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 [ 33.879] (II) [drm] nouveau interface version: 1.1.1 [ 33.879] (II) Loading sub module "dri" ... There are no messages in the kernel's log that indicate any problem. stracing xinit shows: 964 open("/dev/dri/card0", O_RDWR) = 9 964 write(0, "[ 1120.365] ", 13) = 13 964 write(0, "drmOpenDevice: open result is 9,"..., 38) = 38 964 write(0, "[ 1120.365] ", 13) = 13 964 write(0, "drmOpenByBusid: drmOpenMinor ret"..., 39) = 39 964 ioctl(9, 0xc0106407, 0x7fffda0d4800) = 0 964 ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0 964 ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0 964 write(0, "[ 1120.365] ", 13) = 13 964 write(0, "drmOpenByBusid: drmGetBusid repo"..., 53) = 53 964 ioctl(9, 0xc0086420, 0x7fffda0d4870) = -1 EINVAL (Invalid argument) 964 fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0 964 fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0 964 close(9) = 0 964 write(0, "[ 1120.366] ", 13) = 13 964 write(0, "(EE) [drm] failed to open device"..., 33) = 33 So it looke like that ioctl 0xc0086420 is the culprit. Any ideas? I may have time to try a bisection tomorrow.

1 1

[PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed
by Archit Taneja 19 Sep '13

19 Sep '13

omapdrm established connections for omap_dss_device devices when probed. It should also be responsible to disconnect the devices. Keeping the devices connected can prevent the panel driver modules from unloading, it can also cause problems when omapdrm is re-inserted. Signed-off-by: Archit Taneja <archit(a)ti.com> --- drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 45fbb1c..44a1203 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum omap_channel channel) return false; } +static void omap_disconnect_dssdevs(void) +{ + struct omap_dss_device *dssdev = NULL; + + for_each_dss_dev(dssdev) + dssdev->driver->disconnect(dssdev); +} static int omap_connect_dssdevs(void) { @@ -110,10 +117,7 @@ cleanup: * if we are deferring probe, we disconnect the devices we previously * connected */ - dssdev = NULL; - - for_each_dss_dev(dssdev) - dssdev->driver->disconnect(dssdev); + omap_disconnect_dssdevs(); return r; } @@ -688,6 +692,8 @@ static int pdev_remove(struct platform_device *device) DBG(""); drm_platform_exit(&omap_drm_driver, device); + omap_disconnect_dssdevs(); + platform_driver_unregister(&omap_dmm_driver); return 0; } -- 1.8.1.2

2 2

[PATCH 1/2] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
by Archit Taneja 19 Sep '13

19 Sep '13

Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require regulators. The output's connect op tries to get a regulator which may not exist yet because it might get registered later in the kernel boot. omapdrm currently ignores those panels which return a non zero value when connected. A better approach would be for omapdrm to request for probe deferral if a panel's connect op returns -EPROBE_DEFER. The connecting of panels is moved very early in the the drm device's probe before anything else is initialized. When we enter omap_modeset_init(), we have a set of panels that have been connected. We now proceed with registering only those panels which are already connected. Checking whether the panel has a driver or whether it has get_timing/read_edid ops in omap_modeset_init() are redundant with the new display model. These can be removed since a dssdev device will always have a driver associated with it, and all dssdev drivers have a get_timings op. This fixes boot with omapdrm on an omap4 panda ES board. The regulators used by HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized as it's pins are not configured because pinctrl is yet to probe. Signed-off-by: Archit Taneja <archit(a)ti.com> --- drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +++ drivers/gpu/drm/omapdrm/omap_drv.c | 64 ++++++++++++++++++++++++------------- drivers/gpu/drm/omapdrm/omap_drv.h | 1 + 3 files changed, 48 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c index 0fd2eb1..9c01311 100644 --- a/drivers/gpu/drm/omapdrm/omap_crtc.c +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c @@ -623,6 +623,11 @@ void omap_crtc_pre_init(void) dss_install_mgr_ops(&mgr_ops); } +void omap_crtc_pre_uninit(void) +{ + dss_uninstall_mgr_ops(); +} + /* initialize crtc */ struct drm_crtc *omap_crtc_init(struct drm_device *dev, struct drm_plane *plane, enum omap_channel channel, int id) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 2603d90..45fbb1c 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -87,6 +87,37 @@ static bool channel_used(struct drm_device *dev, enum omap_channel channel) return false; } +static int omap_connect_dssdevs(void) +{ + int r; + struct omap_dss_device *dssdev = NULL; + + for_each_dss_dev(dssdev) { + r = dssdev->driver->connect(dssdev); + if (r == -EPROBE_DEFER) { + omap_dss_put_device(dssdev); + goto cleanup; + } else if (r) { + dev_warn(dssdev->dev, "could not connect display: %s\n", + dssdev->name); + } + } + + return 0; + +cleanup: + /* + * if we are deferring probe, we disconnect the devices we previously + * connected + */ + dssdev = NULL; + + for_each_dss_dev(dssdev) + dssdev->driver->disconnect(dssdev); + + return r; +} + static int omap_modeset_init(struct drm_device *dev) { struct omap_drm_private *priv = dev->dev_private; @@ -95,9 +126,6 @@ static int omap_modeset_init(struct drm_device *dev) int num_mgrs = dss_feat_get_num_mgrs(); int num_crtcs; int i, id = 0; - int r; - - omap_crtc_pre_init(); drm_mode_config_init(dev); @@ -119,26 +147,8 @@ static int omap_modeset_init(struct drm_device *dev) enum omap_channel channel; struct omap_overlay_manager *mgr; - if (!dssdev->driver) { - dev_warn(dev->dev, "%s has no driver.. skipping it\n", - dssdev->name); - continue; - } - - if (!(dssdev->driver->get_timings || - dssdev->driver->read_edid)) { - dev_warn(dev->dev, "%s driver does not support " - "get_timings or read_edid.. skipping it!\n", - dssdev->name); + if (!omapdss_device_is_connected(dssdev)) continue; - } - - r = dssdev->driver->connect(dssdev); - if (r) { - dev_err(dev->dev, "could not connect display: %s\n", - dssdev->name); - continue; - } encoder = omap_encoder_init(dev, dssdev); @@ -656,9 +666,19 @@ static void pdev_shutdown(struct platform_device *device) static int pdev_probe(struct platform_device *device) { + int r; + if (omapdss_is_initialized() == false) return -EPROBE_DEFER; + omap_crtc_pre_init(); + + r = omap_connect_dssdevs(); + if (r) { + omap_crtc_pre_uninit(); + return r; + } + DBG("%s", device->name); return drm_platform_init(&omap_drm_driver, device); } diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h b/drivers/gpu/drm/omapdrm/omap_drv.h index 30b95b7..cb86cb3 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.h +++ b/drivers/gpu/drm/omapdrm/omap_drv.h @@ -158,6 +158,7 @@ enum omap_channel omap_crtc_channel(struct drm_crtc *crtc); int omap_crtc_apply(struct drm_crtc *crtc, struct omap_drm_apply *apply); void omap_crtc_pre_init(void); +void omap_crtc_pre_uninit(void); struct drm_crtc *omap_crtc_init(struct drm_device *dev, struct drm_plane *plane, enum omap_channel channel, int id); -- 1.8.1.2

1 0

[PULL] drm-intel-fixes
by Daniel Vetter 19 Sep '13

19 Sep '13

Hi Dave, Looks like I'm just a bit late with my -fixes pull request. Some more dealock fixes around pageflips and gpu hangs, fixes for hsw hangs when doing modesets/dpms. And a few minor things to rectify issues with our modeset state tracking which the checker spotted. Nothing yet for the vgaarb fun (can I just wish that one away?) and we seem to have some minor fun with the new shrinker stuff - still discussing that with Dave Chinner. Cheers, Daniel The following changes since commit 6e1b4fdad5157bb9e88777d525704aba24389bee: drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done (2013-09-06 23:27:03 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-09-19 for you to fetch changes up to f2f5f771c5fc0fa252cde3d0d0452dcc785cc17a: drm/i915: Don't enable the cursor on a disable pipe (2013-09-18 10:00:30 +0200) ---------------------------------------------------------------- Chris Wilson (1): drm/i915: Track pfit enable state separately from size Daniel Vetter (5): drm/i915: fix wait_for_pending_flips vs gpu hang deadlock drm/i915/sdvo: Fully translate sync flags in the dtd->mode conversion drm/i915/sdvo: Robustify the dtd<->drm_mode conversions drm/i915/dvo: set crtc timings again for panel fixed modes drm/i915: kill set_need_resched Jani Nikula (1): drm/i915: do not update cursor in crtc mode set Takashi Iwai (1): drm/i915: Use proper print format for debug prints Ville Syrjälä (1): drm/i915: Don't enable the cursor on a disable pipe drivers/gpu/drm/i915/i915_gem.c | 11 +++--- drivers/gpu/drm/i915/i915_irq.c | 68 ++++++++++++++++++++++++++++-------- drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 42 +++++++++++----------- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_dvo.c | 2 ++ drivers/gpu/drm/i915/intel_panel.c | 1 + drivers/gpu/drm/i915/intel_pm.c | 6 ++-- drivers/gpu/drm/i915/intel_sdvo.c | 63 +++++++++++++++++++-------------- 9 files changed, 122 insertions(+), 74 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

1 0

[PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
by Daniel Vetter 19 Sep '13

19 Sep '13

The drm/i915 gpu driver loves to hang onto as much memory as it can - we cache pinned pages, dma mappings and obviously also gpu address space bindings of buffer objects. On top of that userspace has its own opportunistic cache which is managed by an madvise-like ioctl to tell the kernel which objects are purgeable and which are actually used. This is to cache userspace mmapings and a bit of other metadata about buffer objects needed to be able to hit fastpaths even on fresh objects. We have routine encounters with the OOM killer due to all this crave for memory. The latest one seems to be an artifact of the mm core trying really hard to balance page lru evictions with shrinking caches: The shrinker in drm/i915 doesn't actually free memory, but only drops all the dma mappings and page refcounts so that the backing storage (which is just shmemfs nodes) can actually be evicted. Which means that if the core mm hasn't found anything to evict from the page lru (most likely because drm/i915 has pinned down everything available) it will also not shrink any of the caches. Which leads to a premature OOM while still tons of pages used by gpu buffer objects could be swapped out. For a quick hack I've added a shrink-me-harder flag to make sure there's at least a bit of forward progress. It seems to work. I've called the flag evicts_to_page_lru, but that might just be uninformed me talking ... We should also probably have something with a bit more smarts to be more aggressive when in a tight spot and avoid the minimal shrinking when it's not really required, so maybe take scan_control->priority into account somehow. But since I utterly lack clue I've figured sending out a quick rfc first is better. Also, this needs to be rebased to the new shrinker api in 3.12, I simply haven't rolled my trees forward yet. In any case I just want to get the discussion started on this. Cc: Glauber Costa <glommer(a)gmail.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Rik van Riel <riel(a)redhat.com> Cc: Mel Gorman <mgorman(a)suse.de> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.cz> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69247 Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/i915/i915_gem.c | 1 + include/linux/shrinker.h | 14 ++++++++++++++ mm/vmscan.c | 4 ++++ 3 files changed, 19 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index d80f33d..7481d0a 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4582,6 +4582,7 @@ i915_gem_load(struct drm_device *dev) dev_priv->mm.inactive_shrinker.shrink = i915_gem_inactive_shrink; dev_priv->mm.inactive_shrinker.seeks = DEFAULT_SEEKS; + dev_priv->mm.inactive_shrinker.evicts_to_page_lru = true; register_shrinker(&dev_priv->mm.inactive_shrinker); } diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h index ac6b8ee..361cc2d 100644 --- a/include/linux/shrinker.h +++ b/include/linux/shrinker.h @@ -32,6 +32,20 @@ struct shrinker { int seeks; /* seeks to recreate an obj */ long batch; /* reclaim batch size, 0 = default */ + /* + * Some shrinkers (especially gpu drivers using gem as backing storage) + * hold onto gobloads of pinned pagecache memory (from shmem nodes). + * When those caches get shrunk the memory only gets unpin and so is + * available to be evicted with the page launderer. + * + * The problem is that the core mm tries to balance eviction from the + * page lru with shrinking caches. So if there's nothing on the page lru + * to evict we'll never shrink the gpu driver caches and so will OOM + * despite tons of memory used by gpu buffer objects that could be + * swapped out. Setting this flag ensures forward progress. + */ + bool evicts_to_page_lru; + /* These are for internal use */ struct list_head list; atomic_long_t nr_in_batch; /* objs pending delete */ diff --git a/mm/vmscan.c b/mm/vmscan.c index 2cff0d4..d81f6e0 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control *shrink, total_scan = max_pass; } + /* Always try to shrink a bit to make forward progress. */ + if (shrinker->evicts_to_page_lru) + total_scan = max_t(long, total_scan, batch_size); + /* * We need to avoid excessive windup on filesystem shrinkers * due to large numbers of GFP_NOFS allocations causing the -- 1.8.4.rc3

4 8

[PATCH 1/1] drm/exynos: Fix trivial typo in exynos_drm_fimd.c
by Sachin Kamat 19 Sep '13

19 Sep '13

Fixed a trivial typo. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 868a14d..5d5b97d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -31,7 +31,7 @@ #include "exynos_drm_iommu.h" /* - * FIMD is stand for Fully Interactive Mobile Display and + * FIMD stands for Fully Interactive Mobile Display and * as a display controller, it transfers contents drawn on memory * to a LCD Panel through Display Interfaces such as RGB or * CPU Interface. -- 1.7.9.5

1 0

[Bug 69543] New: Radeon EXAPixmaps don't work with stretched XRender pictures
by bugzilla-daemon＠freedesktop.org 18 Sep '13

18 Sep '13

https://bugs.freedesktop.org/show_bug.cgi?id=69543 Priority: medium Bug ID: 69543 Assignee: dri-devel(a)lists.freedesktop.org Summary: Radeon EXAPixmaps don't work with stretched XRender pictures Severity: normal Classification: Unclassified OS: Linux (All) Reporter: jujibo(a)gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI There is garbage on screen with some stretched XRender pictures with radeon driver and enabled EXAPixmaps, see for example MSEide without xorg.conf http://sourceforge.net/projects/mseide-msegui/ MSEgui uses stretched one pixel width or height pixmaps in order to draw linear color gradients. If you add Option "EXAPixmaps" "off" in Section "Device" of xorg.conf display is OK but performance falls. Same problem using NOUVEAU driver. I can't figure out how disable EXAPixmaps for nouveau driver. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.

1 6

[PATCH libdrm] radeon: Fix 1D tiling for CIK
by Michel Dänzer 18 Sep '13

18 Sep '13

From: Michel Dänzer <michel.daenzer(a)amd.com> The main difference is that the tiling mode index changed for 1D tiled depth/stencil surfaces. Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> --- include/drm/radeon_drm.h | 15 +++++++++++++++ radeon/radeon_surface.c | 15 ++++++++++++--- 2 files changed, 27 insertions(+), 3 deletions(-) diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h index 86cef15..533c3dc 100644 --- a/include/drm/radeon_drm.h +++ b/include/drm/radeon_drm.h @@ -1004,4 +1004,19 @@ struct drm_radeon_info { #define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3 #define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2 +#define CIK_TILE_MODE_COLOR_LINEAR_ALIGNED 8 +#define CIK_TILE_MODE_COLOR_1D 13 +#define CIK_TILE_MODE_COLOR_1D_SCANOUT 9 +#define CIK_TILE_MODE_COLOR_2D_8BPP 14 +#define CIK_TILE_MODE_COLOR_2D_16BPP 15 +#define CIK_TILE_MODE_COLOR_2D_32BPP 16 +#define CIK_TILE_MODE_COLOR_2D_64BPP 17 +#define CIK_TILE_MODE_COLOR_2D_SCANOUT_16BPP 11 +#define CIK_TILE_MODE_COLOR_2D_SCANOUT_32BPP 12 +#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5 +#define CIK_TILE_MODE_DEPTH_STENCIL_2D 0 +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_2AA 3 +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_4AA 3 +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_8AA 2 + #endif diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 818e26a..1710e34 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -1382,10 +1382,16 @@ static int si_surface_sanity(struct radeon_surface_manager *surf_man, break; case RADEON_SURF_MODE_1D: if (surf->flags & RADEON_SURF_SBUFFER) { - *stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D; + if (surf_man->family >= CHIP_BONAIRE) + *stencil_tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D; + else + *stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D; } if (surf->flags & RADEON_SURF_ZBUFFER) { - *tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D; + if (surf_man->family >= CHIP_BONAIRE) + *tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D; + else + *tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D; } else if (surf->flags & RADEON_SURF_SCANOUT) { *tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT; } else { @@ -1643,7 +1649,10 @@ static int si_surface_init_2d(struct radeon_surface_manager *surf_man, tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT; break; case SI_TILE_MODE_DEPTH_STENCIL_2D: - tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D; + if (surf_man->family >= CHIP_BONAIRE) + tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D; + else + tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D; break; default: return -EINVAL; -- 1.8.4.rc3

3 5

[PATCH 1/3] drm/radeon/cik: Fix printing of client name on VM protection fault
by Michel Dänzer 18 Sep '13

18 Sep '13

From: Michel Dänzer <michel.daenzer(a)amd.com> The string is encoded from the MSB to the LSB of the register. Cc: stable(a)vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> --- drivers/gpu/drm/radeon/cik.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index a77b593..4f1f419 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -4721,12 +4721,13 @@ static void cik_vm_decode_fault(struct radeon_device *rdev, u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT; u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT; u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT; - char *block = (char *)&mc_client; + char block[5] = { mc_client >> 24, (mc_client >> 16) & 0xff, + (mc_client >> 8) & 0xff, mc_client & 0xff, 0 }; - printk("VM fault (0x%02x, vmid %d) at page %u, %s from %s (%d)\n", + printk("VM fault (0x%02x, vmid %d) at page %u, %s from '%s' (0x%08x) (%d)\n", protections, vmid, addr, (status & MEMORY_CLIENT_RW_MASK) ? "write" : "read", - block, mc_id); + block, mc_client, mc_id); } /** -- 1.8.4.rc3

2 6

← Newer
1
...
67
68
69
70
71
72
73
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2013