dri-devel May 2013

dri-devel@lists.freedesktop.org

116 participants
705 discussions

[PATCH] radeon: add RADEON_SURF_FMASK flag which disables 2D->1D tiling transition
by Marek Olšák 09 May '13

09 May '13

I will release a new version of libdrm after this is committed. --- radeon/radeon_surface.c | 9 ++++++--- radeon/radeon_surface.h | 1 + 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 288b5e2..56012da 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -158,7 +158,8 @@ static void surf_minify(struct radeon_surface *surf, surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w; surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h; surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d; - if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) { + if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D && + !(surf->flags & RADEON_SURF_FMASK)) { if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) { surflevel->mode = RADEON_SURF_MODE_1D; return; @@ -564,7 +565,8 @@ static void eg_surf_minify(struct radeon_surface *surf, surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w; surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h; surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d; - if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) { + if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D && + !(surf->flags & RADEON_SURF_FMASK)) { if (surflevel->nblk_x < mtilew || surflevel->nblk_y < mtileh) { surflevel->mode = RADEON_SURF_MODE_1D; return; @@ -1458,7 +1460,8 @@ static void si_surf_minify_2d(struct radeon_surface *surf, surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d; } - if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) { + if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D && + !(surf->flags & RADEON_SURF_FMASK)) { if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) { surflevel->mode = RADEON_SURF_MODE_1D; return; diff --git a/radeon/radeon_surface.h b/radeon/radeon_surface.h index 2babfd7..bbed56f 100644 --- a/radeon/radeon_surface.h +++ b/radeon/radeon_surface.h @@ -56,6 +56,7 @@ #define RADEON_SURF_SBUFFER (1 << 18) #define RADEON_SURF_HAS_SBUFFER_MIPTREE (1 << 19) #define RADEON_SURF_HAS_TILE_MODE_INDEX (1 << 20) +#define RADEON_SURF_FMASK (1 << 21) #define RADEON_SURF_GET(v, field) (((v) >> RADEON_SURF_ ## field ## _SHIFT) & RADEON_SURF_ ## field ## _MASK) #define RADEON_SURF_SET(v, field) (((v) & RADEON_SURF_ ## field ## _MASK) << RADEON_SURF_ ## field ## _SHIFT) -- 1.7.10.4

2 1

[PATCH 11/12] drm: DRM should depend on HAS_DMA
by Geert Uytterhoeven 09 May '13

09 May '13

If NO_DMA=y: drivers/built-in.o: In function `__drm_pci_free': drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `drm_pci_alloc': drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `drm_gem_unmap_dma_buf': drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `drm_gem_map_dma_buf': drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg' Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b16c50e..38f1228 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -6,7 +6,7 @@ # menuconfig DRM tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA select HDMI select I2C select I2C_ALGOBIT -- 1.7.0.4

1 0

[PATCH 0/4] mgag200 fixes
by Christopher Harvey 09 May '13

09 May '13

The Following should be CC'd to stable: * drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register * drm/mgag200: Fix framebuffer base address programming The others are bug fixes, but aren't critical. I'm sitting on some hardware cursor code that depends on all of these patches before it can go in. I'm aiming for 3.11 for the hardware cursor support. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to jiffies drm/mgag200: Fix framebuffer base address programming drivers/gpu/drm/mgag200/mgag200_mode.c | 90 ++++++++++++++++++++-------------- 1 file changed, 52 insertions(+), 38 deletions(-) -- 1.8.1.5

1 5

[PATCH] qxl: fix bug with object eviction and update area
by Dave Airlie 09 May '13

09 May '13

From: Dave Airlie <airlied(a)redhat.com> if the surface is evicted, this validation will happen to the wrong place, I noticed this with other work I was doing, haven't seen it go wrong in practice. Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/qxl/qxl_ioctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c index 04b64f9..6db7370 100644 --- a/drivers/gpu/drm/qxl/qxl_ioctl.c +++ b/drivers/gpu/drm/qxl/qxl_ioctl.c @@ -294,6 +294,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev, void *data, goto out; if (!qobj->pin_count) { + qxl_ttm_placement_from_domain(qobj, qobj->type); ret = ttm_bo_validate(&qobj->tbo, &qobj->placement, true, false); if (unlikely(ret)) -- 1.8.2.1

1 0

[PATCH v2 0/4] *** SUBJECT HERE ***
by Christopher Harvey 08 May '13

08 May '13

I forgot to include some acked and tested-by lines in v1 of this series. No code changes in v2. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to jiffies drm/mgag200: Fix framebuffer base address programming drivers/gpu/drm/mgag200/mgag200_mode.c | 90 ++++++++++++++++++++-------------- 1 file changed, 52 insertions(+), 38 deletions(-) -- 1.8.1.5

1 4

[PATCH] drm: refactor call to request_module
by Kees Cook 08 May '13

08 May '13

This reduces the size of the stack frame when calling request_module(). Performing the sprintf before the call is not needed. Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/gpu/drm/drm_encoder_slave.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_encoder_slave.c b/drivers/gpu/drm/drm_encoder_slave.c index 48c52f7..0cfb60f 100644 --- a/drivers/gpu/drm/drm_encoder_slave.c +++ b/drivers/gpu/drm/drm_encoder_slave.c @@ -54,16 +54,12 @@ int drm_i2c_encoder_init(struct drm_device *dev, struct i2c_adapter *adap, const struct i2c_board_info *info) { - char modalias[sizeof(I2C_MODULE_PREFIX) - + I2C_NAME_SIZE]; struct module *module = NULL; struct i2c_client *client; struct drm_i2c_encoder_driver *encoder_drv; int err = 0; - snprintf(modalias, sizeof(modalias), - "%s%s", I2C_MODULE_PREFIX, info->type); - request_module(modalias); + request_module("%s%s", I2C_MODULE_PREFIX, info->type); client = i2c_new_device(adap, info); if (!client) { -- 1.7.9.5 -- Kees Cook Chrome OS Security

2 2

[PULL] drm-intel-fixes
by Daniel Vetter 08 May '13

08 May '13

Hi Dave, A few intel fixes for smaller issues and one revert for an sdv hack which we've wanted to kill anyway. Plus two drm patches included for your convenience, both regression fixers for mine own screw-ups. Cheers, Daniel The following changes since commit 43b27290dd42b40f3f23f49677a7faa5a4eb1eff: drm/i915: correct the calculation of first_pd_entry_in_global_pt (2013-04-27 14:07:16 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 3ab9c63705cb7b1b9f83ddce725d8bd9ef7c66a9: drm/i915: hsw: fix link training for eDP on port-A (2013-05-04 10:24:56 +0200) ---------------------------------------------------------------- Chris Wilson (1): drm/i915: Always normalize return timeout for wait_timeout_ioctl Daniel Vetter (3): drm/mm: fix dump table BUG drm: don't check modeset locks in panic handler Revert "drm/i915: revert eDP bpp clamping code changes" Imre Deak (1): drm/i915: hsw: fix link training for eDP on port-A Ville Syrjälä (1): drm/i915: Fix pipe enabled mask for pipe C in WM calculations drivers/gpu/drm/drm_crtc.c | 4 ++ drivers/gpu/drm/drm_mm.c | 34 +++++++++-------- drivers/gpu/drm/i915/i915_gem.c | 8 ++-- drivers/gpu/drm/i915/intel_ddi.c | 5 +++ drivers/gpu/drm/i915/intel_dp.c | 77 ++++++++++++++++++++++++-------------- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 44 +++++++++++----------- 7 files changed, 101 insertions(+), 72 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

1 1

DMA mapping API abuse in exynos-drm
by Tomasz Figa 08 May '13

08 May '13

Hi, Recently I've been working a bit on a DRM driver for the GPU of Samsung S3C6410 SoCs, which required me to familiarize a bit with exynos-drm, as it already contains a KMS driver which is compatible with the SoC I'm working with, making it a good place to put my driver in. Reading through exynos_drm_buf.c I stumbled across following (a bit long) piece of code: dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &buf->dma_attrs); nr_pages = buf->size >> PAGE_SHIFT; if (!is_drm_iommu_supported(dev)) { dma_addr_t start_addr; unsigned int i = 0; buf->pages = kzalloc(sizeof(struct page) * nr_pages, GFP_KERNEL); if (!buf->pages) { DRM_ERROR("failed to allocate pages.\n"); return -ENOMEM; } buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size, &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs); if (!buf->kvaddr) { DRM_ERROR("failed to allocate buffer.\n"); kfree(buf->pages); return -ENOMEM; } start_addr = buf->dma_addr; while (i < nr_pages) { buf->pages[i] = phys_to_page(start_addr); start_addr += PAGE_SIZE; i++; } } else { buf->pages = dma_alloc_attrs(dev->dev, buf->size, &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs); if (!buf->pages) { DRM_ERROR("failed to allocate buffer.\n"); return -ENOMEM; } } buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages); if (!buf->sgt) { DRM_ERROR("failed to get sg table.\n"); ret = -ENOMEM; goto err_free_attrs; } Notice that the value returned by dma_alloc_attrs() is assumed by this code to be either a kernel virtual address (in !is_drm_iommu_supported() case) or struct pages ** (in is_drm_iommu_supported() case), which seemed a bit worrying to me, making me do a more in depth research on how dma_alloc_attrs works. This, in turn, led me to following excerpt of Documentation/DMA- attributes.txt : DMA_ATTR_NO_KERNEL_MAPPING -------------------------- DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel virtual mapping for the allocated buffer. On some architectures creating such mapping is non-trivial task and consumes very limited resources (like kernel virtual address space or dma consistent address space). Buffers allocated with this attribute can be only passed to user space by calling dma_mmap_attrs(). By using this API, you are guaranteeing that you won't dereference the pointer returned by dma_alloc_attr(). You can threat it as a cookie that must be passed to dma_mmap_attrs() and dma_free_attrs(). Make sure that both of these also get this attribute set on each call. of which the following sentence is the most relevant: By using this API, you are guaranteeing that you won't dereference the pointer returned by dma_alloc_attr(). This statement is obviously ignored by buffer allocation code of exynos- drm. A simple git blame revealed that this brokenness has been introduced by commit: 4744ad2 drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute and later fixed a bit by following depending patches (because the original patch apparently broke any allocations without IOMMU): c704f1b drm/exynos: consider no iommu support to console framebuffer 694be45 drm/exynos: consider buffer allocation without iommu Now, the real question is whether my reasoning is incorrect (sorry for the noise then) or this is really a bug which needs to be fixed? Best regards, Tomasz

3 2

linux-next: manual merge of the drm-intel tree with Linus' tree
by Stephen Rothwell 08 May '13

08 May '13

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915: Make data/link N value power of two") from Linus' tree and commit e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines") from the drm-intel tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Daniel, I assume all this stuff being added to the drm-intel tree is going upstream very soon? -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au diff --cc drivers/gpu/drm/i915/i915_reg.h index 83f9c26,a470103..0000000 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@@ -2648,18 -2768,19 +2768,19 @@@ * which is after the LUTs, so we want the bytes for our color format. * For our current usage, this is always 3, one byte for R, G and B. */ - #define _PIPEA_GMCH_DATA_M 0x70050 - #define _PIPEB_GMCH_DATA_M 0x71050 + #define _PIPEA_DATA_M_G4X 0x70050 + #define _PIPEB_DATA_M_G4X 0x71050 /* Transfer unit size for display port - 1, default is 0x3f (for TU size 64) */ -#define PIPE_GMCH_DATA_M_TU_SIZE_MASK (0x3f << 25) -#define PIPE_GMCH_DATA_M_TU_SIZE_SHIFT 25 +#define TU_SIZE(x) (((x)-1) << 25) /* default size 64 */ +#define TU_SIZE_MASK (0x3f << 25) + #define TU_SIZE_SHIFT 25 -#define PIPE_GMCH_DATA_M_MASK (0xffffff) +#define DATA_LINK_M_N_MASK (0xffffff) +#define DATA_LINK_N_MAX (0x800000) - #define _PIPEA_GMCH_DATA_N 0x70054 - #define _PIPEB_GMCH_DATA_N 0x71054 + #define _PIPEA_DATA_N_G4X 0x70054 + #define _PIPEB_DATA_N_G4X 0x71054 -#define PIPE_GMCH_DATA_N_MASK (0xffffff) /* * Computing Link M and N values for the Display Port link @@@ -2672,16 -2793,18 +2793,16 @@@ * Attributes and VB-ID. */ - #define _PIPEA_DP_LINK_M 0x70060 - #define _PIPEB_DP_LINK_M 0x71060 + #define _PIPEA_LINK_M_G4X 0x70060 + #define _PIPEB_LINK_M_G4X 0x71060 -#define PIPEA_DP_LINK_M_MASK (0xffffff) - #define _PIPEA_DP_LINK_N 0x70064 - #define _PIPEB_DP_LINK_N 0x71064 + #define _PIPEA_LINK_N_G4X 0x70064 + #define _PIPEB_LINK_N_G4X 0x71064 -#define PIPEA_DP_LINK_N_MASK (0xffffff) - #define PIPE_GMCH_DATA_M(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_M, _PIPEB_GMCH_DATA_M) - #define PIPE_GMCH_DATA_N(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_N, _PIPEB_GMCH_DATA_N) - #define PIPE_DP_LINK_M(pipe) _PIPE(pipe, _PIPEA_DP_LINK_M, _PIPEB_DP_LINK_M) - #define PIPE_DP_LINK_N(pipe) _PIPE(pipe, _PIPEA_DP_LINK_N, _PIPEB_DP_LINK_N) + #define PIPE_DATA_M_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_M_G4X, _PIPEB_DATA_M_G4X) + #define PIPE_DATA_N_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_N_G4X, _PIPEB_DATA_N_G4X) + #define PIPE_LINK_M_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_M_G4X, _PIPEB_LINK_M_G4X) + #define PIPE_LINK_N_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_N_G4X, _PIPEB_LINK_N_G4X) /* Display & cursor control */

2 2

[Bug 63979] New: s3tc not working with radeonsi driver
by bugzilla-daemon＠freedesktop.org 07 May '13

07 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=63979 Priority: medium Bug ID: 63979 Assignee: dri-devel(a)lists.freedesktop.org Summary: s3tc not working with radeonsi driver Severity: normal Classification: Unclassified OS: All Reporter: kallisti5(a)unixzen.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa s3tc doesn't work when using the radeonsi driver. Example: kallisti5@eris ~ :) $ find /usr/lib -name "radeonsi*" /usr/lib/xorg/modules/dri/radeonsi_dri.so kallisti5@eris ~ :) $ glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on AMD TAHITI No EXT_texture_compress (aka s3tc) kallisti5@eris ~ :) $ glxinfo | grep EXT_texture_compress Move radeonsi driver somewhere else forcing fallback to swpipe: kallisti5@eris ~ :( $ sudo mv /usr/lib/xorg/modules/dri/radeonsi_dri.so /tmp/ Now using llvmpipe: kallisti5@eris ~ :) $ glxinfo | grep renderer libGL error: failed to load driver: radeonsi libGL error: Try again with LIBGL_DEBUG=verbose for more details. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) s3tc now working: kallisti5@eris ~ :) $ glxinfo | grep EXT_texture_compress libGL error: failed to load driver: radeonsi libGL error: Try again with LIBGL_DEBUG=verbose for more details. GL_EXT_texture_array, GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_latc, GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, kallisti5@eris ~ :) $ -- You are receiving this mail because: You are the assignee for the bug.

1 5

← Newer
1
...
62
63
64
65
66
67
68
...
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