[Bug 50232] New: screen redraw is wrong in sauerbraten with the llvm compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50232

 Bug #: 50232
   Summary: screen redraw is wrong in sauerbraten with the llvm
compiler
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: aaalmosss at gmail.com


Ghost images of the previous frames stay on the screen. This seems to be
independent of the quality settings in the game.

This is printed to the console:
Warning: R600 LLVM backend does not support indirect adressing.  Falling back
to TGSI backend.

Tested with sauerbraten 0.0.20100728.dfsg+repack-3 (debian unstable) and mesa
7a75e7d6e85d27e102ff7e15583c33b1ce282fe4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 5/7] nouveau: add PRIME support

[Alex Deucher]

On Tue, May 22, 2012 at 8:50 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This adds prime->fd and fd->prime support to nouveau,
> it passes the SG object to TTM, and then populates the
> GART entries using it.
>
> v2: add stubbed kmap + use new function to fill out pages array
> for faulting + add reimport test.
>
> Signed-off-by: Dave Airlie 

Once again, not familair with nv gart, but the code is pretty much the
same as other asics...

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/nouveau/Makefile ? ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/nouveau/nouveau_bo.c ? ? ?| ? 42 ++--
> ?drivers/gpu/drm/nouveau/nouveau_channel.c | ? ?2 +-
> ?drivers/gpu/drm/nouveau/nouveau_drv.c ? ? | ? ?8 ++-
> ?drivers/gpu/drm/nouveau/nouveau_drv.h ? ? | ? 10 ++-
> ?drivers/gpu/drm/nouveau/nouveau_fence.c ? | ? ?2 +-
> ?drivers/gpu/drm/nouveau/nouveau_gem.c ? ? | ? ?6 +-
> ?drivers/gpu/drm/nouveau/nouveau_mem.c ? ? | ? ?2 +-
> ?drivers/gpu/drm/nouveau/nouveau_prime.c ? | ?163 
> +
> ?drivers/gpu/drm/nouveau/nouveau_sgdma.c ? | ? ?5 +-
> ?drivers/gpu/drm/nouveau/nouveau_vm.c ? ? ?| ? 57 ++
> ?drivers/gpu/drm/nouveau/nouveau_vm.h ? ? ?| ? ?6 +-
> ?drivers/gpu/drm/nouveau/nv04_crtc.c ? ? ? | ? ?2 +-
> ?drivers/gpu/drm/nouveau/nv50_crtc.c ? ? ? | ? ?4 +-
> ?drivers/gpu/drm/nouveau/nv50_evo.c ? ? ? ?| ? ?4 +-
> ?drivers/gpu/drm/nouveau/nvd0_display.c ? ?| ? ?6 +-
> ?16 files changed, 296 insertions(+), 25 deletions(-)
> ?create mode 100644 drivers/gpu/drm/nouveau/nouveau_prime.c
>
> diff --git a/drivers/gpu/drm/nouveau/Makefile 
> b/drivers/gpu/drm/nouveau/Makefile
> index 1a2ad7e..01f1335 100644
> --- a/drivers/gpu/drm/nouveau/Makefile
> +++ b/drivers/gpu/drm/nouveau/Makefile
> @@ -37,7 +37,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o 
> nouveau_channel.o nouveau_mem.o \
> ? ? ? ? ? ? nv50_calc.o \
> ? ? ? ? ? ? nv04_pm.o nv40_pm.o nv50_pm.o nva3_pm.o nvc0_pm.o \
> ? ? ? ? ? ? nv50_vram.o nvc0_vram.o \
> - ? ? ? ? ? ?nv50_vm.o nvc0_vm.o
> + ? ? ? ? ? ?nv50_vm.o nvc0_vm.o nouveau_prime.o
>
> ?nouveau-$(CONFIG_DRM_NOUVEAU_DEBUG) += nouveau_debugfs.o
> ?nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 81599d6..4435e11 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -89,12 +89,17 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
> ?int
> ?nouveau_bo_new(struct drm_device *dev, int size, int align,
> ? ? ? ? ? ? ? uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
> + ? ? ? ? ? ? ?struct sg_table *sg,
> ? ? ? ? ? ? ? struct nouveau_bo **pnvbo)
> ?{
> ? ? ? ?struct drm_nouveau_private *dev_priv = dev->dev_private;
> ? ? ? ?struct nouveau_bo *nvbo;
> ? ? ? ?size_t acc_size;
> ? ? ? ?int ret;
> + ? ? ? int type = ttm_bo_type_device;
> +
> + ? ? ? if (sg)
> + ? ? ? ? ? ? ? type = ttm_bo_type_sg;
>
> ? ? ? ?nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL);
> ? ? ? ?if (!nvbo)
> @@ -120,8 +125,8 @@ nouveau_bo_new(struct drm_device *dev, int size, int 
> align,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sizeof(struct nouveau_bo));
>
> ? ? ? ?ret = ttm_bo_init(_priv->ttm.bdev, >bo, size,
> - ? ? ? ? ? ? ? ? ? ? ? ? ttm_bo_type_device, >placement,
> - ? ? ? ? ? ? ? ? ? ? ? ? align >> PAGE_SHIFT, 0, false, NULL, acc_size, NULL,
> + ? ? ? ? ? ? ? ? ? ? ? ? type, >placement,
> + ? ? ? ? ? ? ? ? ? ? ? ? align >> PAGE_SHIFT, 0, false, NULL, acc_size, sg,
> ? ? ? ? ? ? ? ? ? ? ? ? ?nouveau_bo_del_ttm);
> ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ?/* ttm will call nouveau_bo_del_ttm if it fails.. */
> @@ -817,9 +822,14 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
> struct ttm_mem_reg *new_mem)
> ? ? ? ? ? ? ? ?} else
> ? ? ? ? ? ? ? ?if (new_mem && new_mem->mem_type == TTM_PL_TT &&
> ? ? ? ? ? ? ? ? ? ?nvbo->page_shift == vma->vm->spg_shift) {
> - ? ? ? ? ? ? ? ? ? ? ? nouveau_vm_map_sg(vma, 0, new_mem->
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? num_pages << PAGE_SHIFT,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new_mem->mm_node);
> + ? ? ? ? ? ? ? ? ? ? ? if (((struct nouveau_mem *)new_mem->mm_node)->sg)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? nouveau_vm_map_sg_table(vma, 0, new_mem->
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? num_pages << PAGE_SHIFT,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new_mem->mm_node);
> + ? ? ? ? ? ? ? ? ? ? ? else
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? nouveau_vm_map_sg(vma, 0, new_mem->
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? num_pages << PAGE_SHIFT,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new_mem->mm_node);
> ? ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ? ? ? ?nouveau_vm_unmap(vma);
> ? ? ? ? ? ? ? ?}
> @@ -1058,10 +1068,19 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
> ? ? ? ?struct drm_device *dev;
> ? ? ? ?unsigned i;
> ? ? ? ?int r;
> + ? ? ? bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> ? ? ? ?if (ttm->state != tt_unpopulated)
> ? ? ? ? ? ? ? ?return 0;

[PATCH 3/7] udl: add prime fd->handle support.

[Alex Deucher]

On Tue, May 22, 2012 at 8:50 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> udl can only be used as an output offload so doesn't need to support
> handle->fd direction.
>
> Signed-off-by: Dave Airlie 

I'm not real familiar with udl, but the code seems straight-forward.

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/udl/udl_drv.c | ? ?6 +++-
> ?drivers/gpu/drm/udl/udl_drv.h | ? ?3 ++
> ?drivers/gpu/drm/udl/udl_fb.c ?| ? ?9 +
> ?drivers/gpu/drm/udl/udl_gem.c | ? 75 
> +
> ?4 files changed, 92 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 82e6921..4d02c46 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -57,7 +57,7 @@ static const struct file_operations udl_driver_fops = {
> ?};
>
> ?static struct drm_driver driver = {
> - ? ? ? .driver_features = DRIVER_MODESET | DRIVER_GEM,
> + ? ? ? .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
> ? ? ? ?.load = udl_driver_load,
> ? ? ? ?.unload = udl_driver_unload,
>
> @@ -70,6 +70,10 @@ static struct drm_driver driver = {
> ? ? ? ?.dumb_map_offset = udl_gem_mmap,
> ? ? ? ?.dumb_destroy = udl_dumb_destroy,
> ? ? ? ?.fops = _driver_fops,
> +
> + ? ? ? .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> + ? ? ? .gem_prime_import = udl_gem_prime_import,
> +
> ? ? ? ?.name = DRIVER_NAME,
> ? ? ? ?.desc = DRIVER_DESC,
> ? ? ? ?.date = DRIVER_DATE,
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 96820d0..fccd361 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -66,6 +66,7 @@ struct udl_gem_object {
> ? ? ? ?struct drm_gem_object base;
> ? ? ? ?struct page **pages;
> ? ? ? ?void *vmapping;
> + ? ? ? struct sg_table *sg;
> ?};
>
> ?#define to_udl_bo(x) container_of(x, struct udl_gem_object, base)
> @@ -118,6 +119,8 @@ int udl_gem_init_object(struct drm_gem_object *obj);
> ?void udl_gem_free_object(struct drm_gem_object *gem_obj);
> ?struct udl_gem_object *udl_gem_alloc_object(struct drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?size_t size);
> +struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct dma_buf *dma_buf);
>
> ?int udl_gem_vmap(struct udl_gem_object *obj);
> ?void udl_gem_vunmap(struct udl_gem_object *obj);
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 4d9c3a5..a029ee3 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -593,11 +593,20 @@ udl_fb_user_fb_create(struct drm_device *dev,
> ? ? ? ?struct drm_gem_object *obj;
> ? ? ? ?struct udl_framebuffer *ufb;
> ? ? ? ?int ret;
> + ? ? ? uint32_t size;
>
> ? ? ? ?obj = drm_gem_object_lookup(dev, file, mode_cmd->handles[0]);
> ? ? ? ?if (obj == NULL)
> ? ? ? ? ? ? ? ?return ERR_PTR(-ENOENT);
>
> + ? ? ? size = mode_cmd->pitches[0] * mode_cmd->height;
> + ? ? ? size = ALIGN(size, PAGE_SIZE);
> +
> + ? ? ? if (size > obj->size) {
> + ? ? ? ? ? ? ? DRM_ERROR("object size not sufficient for fb %d %zu %d %d\n", 
> size, obj->size, mode_cmd->pitches[0], mode_cmd->height);
> + ? ? ? ? ? ? ? return ERR_PTR(-ENOMEM);
> + ? ? ? }
> +
> ? ? ? ?ufb = kzalloc(sizeof(*ufb), GFP_KERNEL);
> ? ? ? ?if (ufb == NULL)
> ? ? ? ? ? ? ? ?return ERR_PTR(-ENOMEM);
> diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> index 92f19ef..40efd32 100644
> --- a/drivers/gpu/drm/udl/udl_gem.c
> +++ b/drivers/gpu/drm/udl/udl_gem.c
> @@ -9,6 +9,7 @@
> ?#include "drmP.h"
> ?#include "udl_drv.h"
> ?#include 
> +#include 
>
> ?struct udl_gem_object *udl_gem_alloc_object(struct drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?size_t size)
> @@ -161,6 +162,12 @@ static void udl_gem_put_pages(struct udl_gem_object *obj)
> ? ? ? ?int page_count = obj->base.size / PAGE_SIZE;
> ? ? ? ?int i;
>
> + ? ? ? if (obj->base.import_attach) {
> + ? ? ? ? ? ? ? drm_free_large(obj->pages);
> + ? ? ? ? ? ? ? obj->pages = NULL;
> + ? ? ? ? ? ? ? return;
> + ? ? ? }
> +
> ? ? ? ?for (i = 0; i < page_count; i++)
> ? ? ? ? ? ? ? ?page_cache_release(obj->pages[i]);
>
> @@ -195,6 +202,9 @@ void udl_gem_free_object(struct drm_gem_object *gem_obj)
> ?{
> ? ? ? ?struct udl_gem_object *obj = to_udl_bo(gem_obj);
>
> + ? ? ? if (gem_obj->import_attach)
> + ? ? ? ? ? ? ? drm_prime_gem_destroy(gem_obj, obj->sg);
> +
> ? ? ? ?if (obj->vmapping)
> ? ? ? ? ? ? ? ?udl_gem_vunmap(obj);
>
> @@ -239,3 +249,68 @@ unlock:
> ? ? ? ?mutex_unlock(>struct_mutex);
> ? ? ? ?return ret;
> ?}
> +
> +static int udl_prime_create(struct drm_device *dev,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? size_t size,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? struct sg_table *sg,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? struct udl_gem_object **obj_p)
> +{
> + ? ? ? struct udl_gem_object *obj;
> + ? ? ? int npages;
> + ? ? ? int i;
> + ? ? ? struct scatterlist *iter;
> +
> + ? ? ? npages = size / PAGE_SIZE;
> +
> + ? ? ? *obj_p = 

[PATCH 7/7] drm/radeon: add PRIME support (v2)

[Alex Deucher]

On Tue, May 22, 2012 at 8:50 AM, Dave Airlie  wrote:
> From: Alex Deucher 
>
> This adds prime->fd and fd->prime support to radeon.
> It passes the sg object to ttm and then populates
> the gart entries using it.
>
> Compile tested only.
>
> v2: stub kmap + use new helpers + add reimporting
>
> Signed-off-by: Alex Deucher 
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/Makefile ? ? ? ? ? ? | ? ?2 +-
> ?drivers/gpu/drm/radeon/evergreen_blit_kms.c | ? ?2 +-
> ?drivers/gpu/drm/radeon/r600.c ? ? ? ? ? ? ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/r600_blit_kms.c ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_benchmark.c ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_device.c ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_drv.c ? ? ? ? | ? 14 ++-
> ?drivers/gpu/drm/radeon/radeon_gart.c ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_gem.c ? ? ? ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_object.c ? ? ?| ? ?6 +-
> ?drivers/gpu/drm/radeon/radeon_object.h ? ? ?| ? ?7 +-
> ?drivers/gpu/drm/radeon/radeon_prime.c ? ? ? | ?176 
> +++
> ?drivers/gpu/drm/radeon/radeon_ring.c ? ? ? ?| ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_sa.c ? ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_test.c ? ? ? ?| ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_ttm.c ? ? ? ? | ? 16 ++-
> ?drivers/gpu/drm/radeon/si.c ? ? ? ? ? ? ? ? | ? ?6 +-
> ?17 files changed, 232 insertions(+), 25 deletions(-)
> ?create mode 100644 drivers/gpu/drm/radeon/radeon_prime.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 1efb6eb..a6598fd 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> ? ? ? ?evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
> evergreen_blit_kms.o \
> ? ? ? ?evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
> ? ? ? ?atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o 
> \
> - ? ? ? si_blit_shaders.o
> + ? ? ? si_blit_shaders.o radeon_prime.o
>
> ?radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
> ?radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
> b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
> index 30f0480..1e96bd4 100644
> --- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
> +++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
> @@ -668,7 +668,7 @@ int evergreen_blit_init(struct radeon_device *rdev)
> ? ? ? ?obj_size = ALIGN(obj_size, 256);
>
> ? ? ? ?r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
> RADEON_GEM_DOMAIN_VRAM,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >r600_blit.shader_obj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >r600_blit.shader_obj);
> ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ?DRM_ERROR("evergreen failed to allocate shader\n");
> ? ? ? ? ? ? ? ?return r;
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index ab5d6f2..f388a1d 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -1231,7 +1231,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
> ? ? ? ?if (rdev->vram_scratch.robj == NULL) {
> ? ? ? ? ? ? ? ?r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?>vram_scratch.robj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >vram_scratch.robj);
> ? ? ? ? ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ? ? ? ? ?return r;
> ? ? ? ? ? ? ? ?}
> @@ -2769,7 +2769,7 @@ int r600_ih_ring_alloc(struct radeon_device *rdev)
> ? ? ? ? ? ? ? ?r = radeon_bo_create(rdev, rdev->ih.ring_size,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? PAGE_SIZE, true,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? RADEON_GEM_DOMAIN_GTT,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?>ih.ring_obj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >ih.ring_obj);
> ? ? ? ? ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ? ? ? ? ?DRM_ERROR("radeon: failed to create ih ring buffer 
> (%d).\n", r);
> ? ? ? ? ? ? ? ? ? ? ? ?return r;
> diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
> b/drivers/gpu/drm/radeon/r600_blit_kms.c
> index ef20822..03b6e0d 100644
> --- a/drivers/gpu/drm/radeon/r600_blit_kms.c
> +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
> @@ -552,7 +552,7 @@ int r600_blit_init(struct radeon_device *rdev)
> ? ? ? ?obj_size = ALIGN(obj_size, 256);
>
> ? ? ? ?r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
> RADEON_GEM_DOMAIN_VRAM,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >r600_blit.shader_obj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >r600_blit.shader_obj);
> ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ?DRM_ERROR("r600 failed to allocate shader\n");
> ? ? ? ? ? ? ? ?return r;
> diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
> b/drivers/gpu/drm/radeon/radeon_benchmark.c
> index fef7b72..364f5b1 100644
> --- a/drivers/gpu/drm/radeon/radeon_benchmark.c
> +++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
> @@ -103,7 +103,7 @@ static 

[PATCH 4/7] ttm: add prime sharing support to TTM (v2)

[Alex Deucher]

On Tue, May 22, 2012 at 8:50 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This adds the ability for ttm common code to take an SG table
> and use it as the backing for a slave TTM object.
>
> The drivers can then populate their GTT tables using the SG object.
>
> v2: make sure to setup VM for sg bos as well.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/nouveau/nouveau_bo.c ? ? | ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_object.c ? | ? ?2 +-
> ?drivers/gpu/drm/ttm/ttm_bo.c ? ? ? ? ? ? | ? 17 +++--
> ?drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | ? ?2 +-
> ?include/drm/ttm/ttm_bo_api.h ? ? ? ? ? ? | ? ?9 -
> ?include/drm/ttm/ttm_bo_driver.h ? ? ? ? ?| ? ?2 ++
> ?6 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 12ce044..81599d6 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -121,7 +121,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int 
> align,
>
> ? ? ? ?ret = ttm_bo_init(_priv->ttm.bdev, >bo, size,
> ? ? ? ? ? ? ? ? ? ? ? ? ?ttm_bo_type_device, >placement,
> - ? ? ? ? ? ? ? ? ? ? ? ? align >> PAGE_SHIFT, 0, false, NULL, acc_size,
> + ? ? ? ? ? ? ? ? ? ? ? ? align >> PAGE_SHIFT, 0, false, NULL, acc_size, NULL,
> ? ? ? ? ? ? ? ? ? ? ? ? ?nouveau_bo_del_ttm);
> ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ?/* ttm will call nouveau_bo_del_ttm if it fails.. */
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index df6a4db..1affbc9 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -155,7 +155,7 @@ retry:
> ? ? ? ?mutex_lock(>vram_mutex);
> ? ? ? ?r = ttm_bo_init(>mman.bdev, >tbo, size, type,
> ? ? ? ? ? ? ? ? ? ? ? ?>placement, page_align, 0, !kernel, NULL,
> - ? ? ? ? ? ? ? ? ? ? ? acc_size, _ttm_bo_destroy);
> + ? ? ? ? ? ? ? ? ? ? ? acc_size, NULL, _ttm_bo_destroy);
> ? ? ? ?mutex_unlock(>vram_mutex);
> ? ? ? ?if (unlikely(r != 0)) {
> ? ? ? ? ? ? ? ?if (r != -ERESTARTSYS) {
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 1f5c67c..36792bd 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -343,6 +343,16 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
> bool zero_alloc)
> ? ? ? ? ? ? ? ?if (unlikely(bo->ttm == NULL))
> ? ? ? ? ? ? ? ? ? ? ? ?ret = -ENOMEM;
> ? ? ? ? ? ? ? ?break;
> + ? ? ? case ttm_bo_type_sg:
> + ? ? ? ? ? ? ? bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << 
> PAGE_SHIFT,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? page_flags | 
> TTM_PAGE_FLAG_SG,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? glob->dummy_read_page);
> + ? ? ? ? ? ? ? if (unlikely(bo->ttm == NULL)) {
> + ? ? ? ? ? ? ? ? ? ? ? ret = -ENOMEM;
> + ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? bo->ttm->sg = bo->sg;
> + ? ? ? ? ? ? ? break;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?pr_err("Illegal buffer object type\n");
> ? ? ? ? ? ? ? ?ret = -EINVAL;
> @@ -1169,6 +1179,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> ? ? ? ? ? ? ? ?bool interruptible,
> ? ? ? ? ? ? ? ?struct file *persistent_swap_storage,
> ? ? ? ? ? ? ? ?size_t acc_size,
> + ? ? ? ? ? ? ? struct sg_table *sg,
> ? ? ? ? ? ? ? ?void (*destroy) (struct ttm_buffer_object *))
> ?{
> ? ? ? ?int ret = 0;
> @@ -1223,6 +1234,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> ? ? ? ?bo->seq_valid = false;
> ? ? ? ?bo->persistent_swap_storage = persistent_swap_storage;
> ? ? ? ?bo->acc_size = acc_size;
> + ? ? ? bo->sg = sg;
> ? ? ? ?atomic_inc(>glob->bo_count);
>
> ? ? ? ?ret = ttm_bo_check_placement(bo, placement);
> @@ -1233,7 +1245,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> ? ? ? ? * For ttm_bo_type_device buffers, allocate
> ? ? ? ? * address space from the device.
> ? ? ? ? */
> - ? ? ? if (bo->type == ttm_bo_type_device) {
> + ? ? ? if (bo->type == ttm_bo_type_device ||
> + ? ? ? ? ? bo->type == ttm_bo_type_sg) {
> ? ? ? ? ? ? ? ?ret = ttm_bo_setup_vm(bo);
> ? ? ? ? ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ? ? ? ? ?goto out_err;
> @@ -1312,7 +1325,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
>
> ? ? ? ?ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?buffer_start, interruptible,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? persistent_swap_storage, acc_size, NULL);
> + ? ? ? ? ? ? ? ? ? ? ? ? persistent_swap_storage, acc_size, NULL, NULL);
> ? ? ? ?if (likely(ret == 0))
> ? ? ? ? ? ? ? ?*p_bo = bo;
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index a37abb5..22bf9a2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -1567,7 +1567,7 @@ int vmw_dmabuf_init(struct vmw_private *dev_priv,
> ? ? ? ?ret = ttm_bo_init(bdev, _bo->base, size,
> ? ? ? ? ? ? ? ? ? ? ? 

[PATCH 1/7] drm/prime: introduce sg->pages/addr arrays helper

[Alex Deucher]

On Tue, May 22, 2012 at 8:49 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> the ttm drivers need this currently, in order to get fault handling
> working and efficient.
>
> It also allows addrs to be NULL for devices like udl.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/drm_prime.c | ? 36 
> ?include/drm/drmP.h ? ? ? ? ?| ? ?2 ++
> ?2 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 1bdf2b5..20dbf2c 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -227,6 +227,42 @@ out:
> ?}
> ?EXPORT_SYMBOL(drm_prime_pages_to_sg);
>
> +/* export an sg table into an array of pages and addresses
> + ? this is currently required by the TTM driver in order to do correct fault
> + ? handling */
> +int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
> **pages,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_t *addrs, int max_pages)
> +{
> + ? ? ? unsigned count;
> + ? ? ? struct scatterlist *sg;
> + ? ? ? struct page *page;
> + ? ? ? u32 len, offset;
> + ? ? ? int pg_index;
> + ? ? ? dma_addr_t addr;
> +
> + ? ? ? pg_index = 0;
> + ? ? ? for_each_sg(sgt->sgl, sg, sgt->nents, count) {
> + ? ? ? ? ? ? ? len = sg->length;
> + ? ? ? ? ? ? ? offset = sg->offset;
> + ? ? ? ? ? ? ? page = sg_page(sg);
> + ? ? ? ? ? ? ? addr = sg_dma_address(sg);
> +
> + ? ? ? ? ? ? ? while (len > 0) {
> + ? ? ? ? ? ? ? ? ? ? ? if (WARN_ON(pg_index >= max_pages))
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return -1;
> + ? ? ? ? ? ? ? ? ? ? ? pages[pg_index] = page;
> + ? ? ? ? ? ? ? ? ? ? ? if (addrs)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? addrs[pg_index] = addr;
> +
> + ? ? ? ? ? ? ? ? ? ? ? page++;
> + ? ? ? ? ? ? ? ? ? ? ? addr += PAGE_SIZE;
> + ? ? ? ? ? ? ? ? ? ? ? len -= PAGE_SIZE;
> + ? ? ? ? ? ? ? ? ? ? ? pg_index++;
> + ? ? ? ? ? ? ? }
> + ? ? ? }
> + ? ? ? return 0;
> +}
> +EXPORT_SYMBOL(drm_prime_sg_to_page_addr_arrays);
> ?/* helper function to cleanup a GEM/prime object */
> ?void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg)
> ?{
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 15d9179..31ad880 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1558,6 +1558,8 @@ extern int drm_prime_handle_to_fd_ioctl(struct 
> drm_device *dev, void *data,
> ?extern int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_file *file_priv);
>
> +extern int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct 
> page **pages,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_addr_t *addrs, int max_pages);
> ?extern struct sg_table *drm_prime_pages_to_sg(struct page **pages, int 
> nr_pages);
> ?extern void drm_prime_gem_destroy(struct drm_gem_object *obj, struct 
> sg_table *sg);
>
> --
> 1.7.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

GPU lockup dumping

[Jerome Glisse]

On Thu, May 17, 2012 at 6:07 PM,   wrote:
> Ok this time is final version, i added a bunch of flags to cmd buffer
> to make the userspace tools life easier.
>
> Cheers,
> Jerome
>

So updated libdrm patch :
http://people.freedesktop.org/~glisse/lockup/0001-radeon-add-rati-dumping-helper.patch

Also updated git://people.freedesktop.org/~glisse/joujou and now you
can replay a gpu lockup file captured with those patch on r6xx hw.

Example captured from the kernel (i manualy edited the file to fix
what was causing the lockup so you can replay it safely).
http://people.freedesktop.org/~glisse/lockup/lockup-dump.rati

Also improved the text conversion see :

http://people.freedesktop.org/~glisse/lockup/lockup-dump.tati

Will do r7xx and the evergreen/cayman. But i do think that the kernel
patch are good as is.

Cheers,
Jerome

[PATCH] dma-buf: add get_dma_buf()

[Daniel Vetter]

On Tue, May 22, 2012 at 5:00 PM, Tomasz Stanislawski
 wrote:
> On 05/22/2012 04:32 PM, Daniel Vetter wrote:
>> On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote:
>>> Hi,
>>> I think I discovered an interesting issue with dma_buf.
>>> I found out that dma_buf_fd does not increase reference
>>> count for dma_buf::file. This leads to potential kernel
>>> crash triggered by user space. Please, take a look on
>>> the scenario below:
>>>
>>> The applications spawns two thread. One of them is exporting DMABUF.
>>>
>>> ? ? ? Thread I ? ? ? ? | ? Thread II ? ? ? | Comments
>>> ---+---+---
>>> dbuf = dma_buf_export ?| ? ? ? ? ? ? ? ? ? | dma_buf is creates, refcount 
>>> is 1
>>> fd = dma_buf_fd(dbuf) ?| ? ? ? ? ? ? ? ? ? | assume fd is set to 42, 
>>> refcount is still 1
>>> ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ?close(42) ? ?| The file descriptor is closed 
>>> asynchronously, dbuf's refcount drops to 0
>>> ? ? ? ? ? ? ? ? ? ? ? ?| ?dma_buf_release ?| dbuf structure is freed, dbuf 
>>> becomes a dangling pointer
>>> int size = dbuf->size; | ? ? ? ? ? ? ? ? ? | the dbuf is dereferenced, 
>>> causing a kernel crash
>>> ---+---+---
>>>
>>> I think that the problem could be fixed in two ways.
>>> a) forcing driver developer to call get_dma_buf just before calling 
>>> dma_buf_fd.
>>> b) increasing dma_buf->file's reference count at dma_buf_fd
>>>
>>> I prefer solution (b) because it prevents symmetry between dma_buf_fd and 
>>> close.
>>> I mean that dma_buf_fd increases reference count, close decreases it.
>>>
>>> What is your opinion about the issue?
>>
>> I guess most exporters would like to hang onto the exported dma_buf a bit
>> and hence need a reference (e.g. to cache the dma_buf as long as the
>> underlying buffer object exists). So I guess we can change the semantics
>> of dma_buf_fd from transferring the reference you currently have (and
>> hence forbidding any further access by the caller) to grabbing a reference
>> of it's on for the fd that is created.
>> -Daniel
>
> Hi Daniel,
> Would it be simpler, safer and more intuitive if dma_buf_fd increased
> dmabuf->file's reference counter?

That's actually what I wanted to say. Message seems to have been lost
in transit ;-)
-Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

[PATCH] dma-buf: add get_dma_buf()

[Tomasz Stanislawski]

On 05/22/2012 04:32 PM, Daniel Vetter wrote:
> On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote:
>> Hi,
>> I think I discovered an interesting issue with dma_buf.
>> I found out that dma_buf_fd does not increase reference
>> count for dma_buf::file. This leads to potential kernel
>> crash triggered by user space. Please, take a look on
>> the scenario below:
>>
>> The applications spawns two thread. One of them is exporting DMABUF.
>>
>>   Thread I |   Thread II   | Comments
>> ---+---+---
>> dbuf = dma_buf_export  |   | dma_buf is creates, refcount is 
>> 1
>> fd = dma_buf_fd(dbuf)  |   | assume fd is set to 42, 
>> refcount is still 1
>>|  close(42)| The file descriptor is closed 
>> asynchronously, dbuf's refcount drops to 0
>>|  dma_buf_release  | dbuf structure is freed, dbuf 
>> becomes a dangling pointer
>> int size = dbuf->size; |   | the dbuf is dereferenced, 
>> causing a kernel crash
>> ---+---+---
>>
>> I think that the problem could be fixed in two ways.
>> a) forcing driver developer to call get_dma_buf just before calling 
>> dma_buf_fd.
>> b) increasing dma_buf->file's reference count at dma_buf_fd
>>
>> I prefer solution (b) because it prevents symmetry between dma_buf_fd and 
>> close.
>> I mean that dma_buf_fd increases reference count, close decreases it.
>>
>> What is your opinion about the issue?
> 
> I guess most exporters would like to hang onto the exported dma_buf a bit
> and hence need a reference (e.g. to cache the dma_buf as long as the
> underlying buffer object exists). So I guess we can change the semantics
> of dma_buf_fd from transferring the reference you currently have (and
> hence forbidding any further access by the caller) to grabbing a reference
> of it's on for the fd that is created.
> -Daniel

Hi Daniel,
Would it be simpler, safer and more intuitive if dma_buf_fd increased
dmabuf->file's reference counter?

Regards,
Tomasz Stanislawski

[PATCH 7/7] drm/radeon: add PRIME support (v2)

[Jerome Glisse]

On Tue, May 22, 2012 at 8:50 AM, Dave Airlie  wrote:
> From: Alex Deucher 
>
> This adds prime->fd and fd->prime support to radeon.
> It passes the sg object to ttm and then populates
> the gart entries using it.
>
> Compile tested only.
>
> v2: stub kmap + use new helpers + add reimporting
>
> Signed-off-by: Alex Deucher 
> Signed-off-by: Dave Airlie 
Reviewed-by: Jerome Glisse 
> ---
> ?drivers/gpu/drm/radeon/Makefile ? ? ? ? ? ? | ? ?2 +-
> ?drivers/gpu/drm/radeon/evergreen_blit_kms.c | ? ?2 +-
> ?drivers/gpu/drm/radeon/r600.c ? ? ? ? ? ? ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/r600_blit_kms.c ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_benchmark.c ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_device.c ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_drv.c ? ? ? ? | ? 14 ++-
> ?drivers/gpu/drm/radeon/radeon_gart.c ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_gem.c ? ? ? ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_object.c ? ? ?| ? ?6 +-
> ?drivers/gpu/drm/radeon/radeon_object.h ? ? ?| ? ?7 +-
> ?drivers/gpu/drm/radeon/radeon_prime.c ? ? ? | ?176 
> +++
> ?drivers/gpu/drm/radeon/radeon_ring.c ? ? ? ?| ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_sa.c ? ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_test.c ? ? ? ?| ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_ttm.c ? ? ? ? | ? 16 ++-
> ?drivers/gpu/drm/radeon/si.c ? ? ? ? ? ? ? ? | ? ?6 +-
> ?17 files changed, 232 insertions(+), 25 deletions(-)
> ?create mode 100644 drivers/gpu/drm/radeon/radeon_prime.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 1efb6eb..a6598fd 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> ? ? ? ?evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
> evergreen_blit_kms.o \
> ? ? ? ?evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
> ? ? ? ?atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o 
> \
> - ? ? ? si_blit_shaders.o
> + ? ? ? si_blit_shaders.o radeon_prime.o
>
> ?radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
> ?radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
> b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
> index 30f0480..1e96bd4 100644
> --- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
> +++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
> @@ -668,7 +668,7 @@ int evergreen_blit_init(struct radeon_device *rdev)
> ? ? ? ?obj_size = ALIGN(obj_size, 256);
>
> ? ? ? ?r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
> RADEON_GEM_DOMAIN_VRAM,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >r600_blit.shader_obj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >r600_blit.shader_obj);
> ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ?DRM_ERROR("evergreen failed to allocate shader\n");
> ? ? ? ? ? ? ? ?return r;
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index ab5d6f2..f388a1d 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -1231,7 +1231,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
> ? ? ? ?if (rdev->vram_scratch.robj == NULL) {
> ? ? ? ? ? ? ? ?r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?>vram_scratch.robj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >vram_scratch.robj);
> ? ? ? ? ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ? ? ? ? ?return r;
> ? ? ? ? ? ? ? ?}
> @@ -2769,7 +2769,7 @@ int r600_ih_ring_alloc(struct radeon_device *rdev)
> ? ? ? ? ? ? ? ?r = radeon_bo_create(rdev, rdev->ih.ring_size,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? PAGE_SIZE, true,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? RADEON_GEM_DOMAIN_GTT,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?>ih.ring_obj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >ih.ring_obj);
> ? ? ? ? ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ? ? ? ? ?DRM_ERROR("radeon: failed to create ih ring buffer 
> (%d).\n", r);
> ? ? ? ? ? ? ? ? ? ? ? ?return r;
> diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
> b/drivers/gpu/drm/radeon/r600_blit_kms.c
> index ef20822..03b6e0d 100644
> --- a/drivers/gpu/drm/radeon/r600_blit_kms.c
> +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
> @@ -552,7 +552,7 @@ int r600_blit_init(struct radeon_device *rdev)
> ? ? ? ?obj_size = ALIGN(obj_size, 256);
>
> ? ? ? ?r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
> RADEON_GEM_DOMAIN_VRAM,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >r600_blit.shader_obj);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL, >r600_blit.shader_obj);
> ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ?DRM_ERROR("r600 failed to allocate shader\n");
> ? ? ? ? ? ? ? ?return r;
> diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
> b/drivers/gpu/drm/radeon/radeon_benchmark.c
> index fef7b72..364f5b1 100644
> --- a/drivers/gpu/drm/radeon/radeon_benchmark.c
> +++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
> @@ -103,7 +103,7 @@ static void 

[PATCH 4/7] ttm: add prime sharing support to TTM (v2)

[Jerome Glisse]

On Tue, May 22, 2012 at 8:50 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This adds the ability for ttm common code to take an SG table
> and use it as the backing for a slave TTM object.
>
> The drivers can then populate their GTT tables using the SG object.
>
> v2: make sure to setup VM for sg bos as well.
>
> Signed-off-by: Dave Airlie 
Reviewed-by: Jerome Glisse 

> ---
> ?drivers/gpu/drm/nouveau/nouveau_bo.c ? ? | ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_object.c ? | ? ?2 +-
> ?drivers/gpu/drm/ttm/ttm_bo.c ? ? ? ? ? ? | ? 17 +++--
> ?drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | ? ?2 +-
> ?include/drm/ttm/ttm_bo_api.h ? ? ? ? ? ? | ? ?9 -
> ?include/drm/ttm/ttm_bo_driver.h ? ? ? ? ?| ? ?2 ++
> ?6 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 12ce044..81599d6 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -121,7 +121,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int 
> align,
>
> ? ? ? ?ret = ttm_bo_init(_priv->ttm.bdev, >bo, size,
> ? ? ? ? ? ? ? ? ? ? ? ? ?ttm_bo_type_device, >placement,
> - ? ? ? ? ? ? ? ? ? ? ? ? align >> PAGE_SHIFT, 0, false, NULL, acc_size,
> + ? ? ? ? ? ? ? ? ? ? ? ? align >> PAGE_SHIFT, 0, false, NULL, acc_size, NULL,
> ? ? ? ? ? ? ? ? ? ? ? ? ?nouveau_bo_del_ttm);
> ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ?/* ttm will call nouveau_bo_del_ttm if it fails.. */
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index df6a4db..1affbc9 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -155,7 +155,7 @@ retry:
> ? ? ? ?mutex_lock(>vram_mutex);
> ? ? ? ?r = ttm_bo_init(>mman.bdev, >tbo, size, type,
> ? ? ? ? ? ? ? ? ? ? ? ?>placement, page_align, 0, !kernel, NULL,
> - ? ? ? ? ? ? ? ? ? ? ? acc_size, _ttm_bo_destroy);
> + ? ? ? ? ? ? ? ? ? ? ? acc_size, NULL, _ttm_bo_destroy);
> ? ? ? ?mutex_unlock(>vram_mutex);
> ? ? ? ?if (unlikely(r != 0)) {
> ? ? ? ? ? ? ? ?if (r != -ERESTARTSYS) {
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 1f5c67c..36792bd 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -343,6 +343,16 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
> bool zero_alloc)
> ? ? ? ? ? ? ? ?if (unlikely(bo->ttm == NULL))
> ? ? ? ? ? ? ? ? ? ? ? ?ret = -ENOMEM;
> ? ? ? ? ? ? ? ?break;
> + ? ? ? case ttm_bo_type_sg:
> + ? ? ? ? ? ? ? bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << 
> PAGE_SHIFT,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? page_flags | 
> TTM_PAGE_FLAG_SG,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? glob->dummy_read_page);
> + ? ? ? ? ? ? ? if (unlikely(bo->ttm == NULL)) {
> + ? ? ? ? ? ? ? ? ? ? ? ret = -ENOMEM;
> + ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? bo->ttm->sg = bo->sg;
> + ? ? ? ? ? ? ? break;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?pr_err("Illegal buffer object type\n");
> ? ? ? ? ? ? ? ?ret = -EINVAL;
> @@ -1169,6 +1179,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> ? ? ? ? ? ? ? ?bool interruptible,
> ? ? ? ? ? ? ? ?struct file *persistent_swap_storage,
> ? ? ? ? ? ? ? ?size_t acc_size,
> + ? ? ? ? ? ? ? struct sg_table *sg,
> ? ? ? ? ? ? ? ?void (*destroy) (struct ttm_buffer_object *))
> ?{
> ? ? ? ?int ret = 0;
> @@ -1223,6 +1234,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> ? ? ? ?bo->seq_valid = false;
> ? ? ? ?bo->persistent_swap_storage = persistent_swap_storage;
> ? ? ? ?bo->acc_size = acc_size;
> + ? ? ? bo->sg = sg;
> ? ? ? ?atomic_inc(>glob->bo_count);
>
> ? ? ? ?ret = ttm_bo_check_placement(bo, placement);
> @@ -1233,7 +1245,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> ? ? ? ? * For ttm_bo_type_device buffers, allocate
> ? ? ? ? * address space from the device.
> ? ? ? ? */
> - ? ? ? if (bo->type == ttm_bo_type_device) {
> + ? ? ? if (bo->type == ttm_bo_type_device ||
> + ? ? ? ? ? bo->type == ttm_bo_type_sg) {
> ? ? ? ? ? ? ? ?ret = ttm_bo_setup_vm(bo);
> ? ? ? ? ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ? ? ? ? ?goto out_err;
> @@ -1312,7 +1325,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
>
> ? ? ? ?ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?buffer_start, interruptible,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? persistent_swap_storage, acc_size, NULL);
> + ? ? ? ? ? ? ? ? ? ? ? ? persistent_swap_storage, acc_size, NULL, NULL);
> ? ? ? ?if (likely(ret == 0))
> ? ? ? ? ? ? ? ?*p_bo = bo;
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index a37abb5..22bf9a2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -1567,7 +1567,7 @@ int vmw_dmabuf_init(struct vmw_private *dev_priv,
> ? ? ? ?ret = ttm_bo_init(bdev, _bo->base, size,
> ? ? ? ? ? ? ? ? ? ? ? 

[PATCH] dma-buf: add get_dma_buf()

[Daniel Vetter]

On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote:
> Hi,
> I think I discovered an interesting issue with dma_buf.
> I found out that dma_buf_fd does not increase reference
> count for dma_buf::file. This leads to potential kernel
> crash triggered by user space. Please, take a look on
> the scenario below:
> 
> The applications spawns two thread. One of them is exporting DMABUF.
> 
>   Thread I |   Thread II   | Comments
> ---+---+---
> dbuf = dma_buf_export  |   | dma_buf is creates, refcount is 1
> fd = dma_buf_fd(dbuf)  |   | assume fd is set to 42, refcount 
> is still 1
>|  close(42)| The file descriptor is closed 
> asynchronously, dbuf's refcount drops to 0
>|  dma_buf_release  | dbuf structure is freed, dbuf 
> becomes a dangling pointer
> int size = dbuf->size; |   | the dbuf is dereferenced, 
> causing a kernel crash
> ---+---+---
> 
> I think that the problem could be fixed in two ways.
> a) forcing driver developer to call get_dma_buf just before calling 
> dma_buf_fd.
> b) increasing dma_buf->file's reference count at dma_buf_fd
> 
> I prefer solution (b) because it prevents symmetry between dma_buf_fd and 
> close.
> I mean that dma_buf_fd increases reference count, close decreases it.
> 
> What is your opinion about the issue?

I guess most exporters would like to hang onto the exported dma_buf a bit
and hence need a reference (e.g. to cache the dma_buf as long as the
underlying buffer object exists). So I guess we can change the semantics
of dma_buf_fd from transferring the reference you currently have (and
hence forbidding any further access by the caller) to grabbing a reference
of it's on for the fd that is created.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

kernel 3.4.0 oops

[Andrei Popa]

On Tue, 2012-05-22 at 12:57 +0200, Daniel Vetter wrote:

> Ok, I've tried to reproduce this on my ilk here but couldn't hit the
> issue. A few things:
> - Your gpu dies. Please dig out the versions of mesa, libdrm and
>   xf86-video-intel you're using.
> - Is this a regression?
> - Do you see any other bad side-effects of this besides the WARN in dmesg?
> - Also, can you please enable printk timestamps with CONFIG_PRINTK_TIME
>   and grab a new dmesg? The relative timings of the things going on would
>   be very interesting.
> 
> Thanks, Daniel

This oops is only on xen dom0. This is the first time I try xen.
xf86-video-intel-2.17.0-r3
mesa-7.11.2
libdrm-2.4.27

c00fff] could not be reserved
[2.993645] system 00:01: Plug and Play ACPI device, IDs PNP0c02
(active)
[2.993720] pnp 00:02: [io  0x-0x001f]
[2.993722] pnp 00:02: [io  0x0081-0x0091]
[2.993723] pnp 00:02: [io  0x0093-0x009f]
[2.993725] pnp 00:02: [io  0x00c0-0x00df]
[2.993726] pnp 00:02: [dma 4]
[2.993754] pnp 00:02: Plug and Play ACPI device, IDs PNP0200
(active)
[2.993760] pnp 00:03: [mem 0xff00-0x]
[2.993785] pnp 00:03: Plug and Play ACPI device, IDs INT0800
(active)
[2.993869] pnp 00:04: [mem 0xfed0-0xfed003ff]
[2.993906] pnp 00:04: Plug and Play ACPI device, IDs PNP0103
(active)
[2.993917] pnp 00:05: [io  0x00f0]
[2.993921] xen: registering gsi 13 triggering 1 polarity 0
[2.993927] xen_map_pirq_gsi: returning irq 13 for gsi 13
[2.993929] xen: --> pirq=13 -> irq=13 (gsi=13)
[2.993937] pnp 00:05: [irq 13]
[2.993966] pnp 00:05: Plug and Play ACPI device, IDs PNP0c04
(active)
[2.993976] pnp 00:06: [io  0x002e-0x002f]
[2.993978] pnp 00:06: [io  0x004e-0x004f]
[2.993979] pnp 00:06: [io  0x0061]
[2.993980] pnp 00:06: [io  0x0063]
[2.993982] pnp 00:06: [io  0x0065]
[2.993983] pnp 00:06: [io  0x0067]
[2.993984] pnp 00:06: [io  0x0070]
[2.993986] pnp 00:06: [io  0x0080]
[2.993987] pnp 00:06: [io  0x0092]
[2.993988] pnp 00:06: [io  0x00b2-0x00b3]
[2.993990] pnp 00:06: [io  0x0200-0x027f]
[2.993991] pnp 00:06: [io  0x1000-0x100f]
[2.993993] pnp 00:06: [io  0x]
[2.993994] pnp 00:06: [io  0x]
[2.993995] pnp 00:06: [io  0x0400-0x047f]
[2.993997] pnp 00:06: [io  0x0500-0x057f]
[2.993998] pnp 00:06: [io  0xef80-0xef9f]
[2.994057] system 00:06: [io  0x0200-0x027f] has been reserved
[2.994060] system 00:06: [io  0x1000-0x100f] has been reserved
[2.994062] system 00:06: [io  0x] has been reserved
[2.994064] system 00:06: [io  0x] has been reserved
[2.994066] system 00:06: [io  0x0400-0x047f] has been reserved
[2.994068] system 00:06: [io  0x0500-0x057f] has been reserved
[2.994070] system 00:06: [io  0xef80-0xef9f] has been reserved
[2.994073] system 00:06: Plug and Play ACPI device, IDs PNP0c02
(active)
[2.994082] pnp 00:07: [io  0x0070-0x0077]
[2.994084] xen: registering gsi 8 triggering 1 polarity 0
[2.994086] xen_map_pirq_gsi: returning irq 8 for gsi 8
[2.994088] xen: --> pirq=8 -> irq=8 (gsi=8)
[2.994092] pnp 00:07: [irq 8]
[2.994121] pnp 00:07: Plug and Play ACPI device, IDs PNP0b00
(active)
[2.994130] pnp 00:08: [io  0x0060]
[2.994131] pnp 00:08: [io  0x0064]
[2.994132] xen: registering gsi 1 triggering 1 polarity 0
[2.994134] xen_map_pirq_gsi: returning irq 1 for gsi 1
[2.994136] xen: --> pirq=1 -> irq=1 (gsi=1)
[2.994140] pnp 00:08: [irq 1]
[2.994169] pnp 00:08: Plug and Play ACPI device, IDs PNP0303
(active)
[2.994176] xen: registering gsi 12 triggering 1 polarity 0
[2.994178] xen_map_pirq_gsi: returning irq 12 for gsi 12
[2.994180] xen: --> pirq=12 -> irq=12 (gsi=12)
[2.994184] pnp 00:09: [irq 12]
[2.994215] pnp 00:09: Plug and Play ACPI device, IDs SYN0168 SYN0100
SYN0002 PNP0f13 (active)
[2.994406] xen: registering gsi 23 triggering 1 polarity 0
[2.994417] xen: --> pirq=23 -> irq=23 (gsi=23)
[2.994421] pnp 00:0a: [irq 23]
[2.994460] pnp 00:0a: Plug and Play ACPI device, IDs HPQ0004
(active)
[2.994584] pnp 00:0b: [bus ff]
[2.994628] pnp 00:0b: Plug and Play ACPI device, IDs PNP0a03
(active)
[2.994708] pnp: PnP ACPI: found 12 devices
[2.994710] ACPI: ACPI bus type pnp unregistered
[3.000822] PM-Timer failed consistency check  (0x0xff) -
aborting.
[3.000832] pci :44:00.0: no compatible bridge window for [mem
0xfffe-0x pref]
[3.000873] pci :00:1c.1: bridge window [mem
0x0010-0x000f 64bit pref] to [bus 02-42] add_size 20
[3.000924] pci :00:1c.1: res[9]=[mem 0x0010-0x000f 64bit
pref] get_res_add_size add_size 20
[3.000929] pci :00:1c.1: BAR 9: assigned [mem
0xd4b0-0xd4cf 64bit pref]
[3.000932] pci :00:1c.0: PCI bridge to [bus 01-01]
[3.000942] pci :00:1c.0:   bridge window [mem
0xd480-0xd48f]
[3.000959] pci :00:1c.1: PCI bridge to [bus 

[Bug 43272] pink/purple line displays to the left of the screen

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43272





--- Comment #5 from Alex Deucher   2012-05-22 
16:24:51 ---
The purple line is caused by setting the digital encoder into HDMI mode and
then not sending the proper infoframes.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 43272] pink/purple line displays to the left of the screen

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43272


Paulo Zanoni  changed:

   What|Removed |Added

 CC||przanoni at gmail.com




--- Comment #4 from Paulo Zanoni   2012-05-22 16:22:35 
---
Just a note that might help debugging: I see a purple vertical line on the left
hand side of the screen when I send AVI InfoFrames to a DVI monitor.

Also, when I do this, some modes don't work, other modes look really buggy.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] dma-buf: add get_dma_buf()

[Dave Airlie]

On Tue, May 22, 2012 at 4:05 PM, Daniel Vetter  wrote:
> On Tue, May 22, 2012 at 5:00 PM, Tomasz Stanislawski
>  wrote:
>> On 05/22/2012 04:32 PM, Daniel Vetter wrote:
>>> On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote:
 Hi,
 I think I discovered an interesting issue with dma_buf.
 I found out that dma_buf_fd does not increase reference
 count for dma_buf::file. This leads to potential kernel
 crash triggered by user space. Please, take a look on
 the scenario below:

 The applications spawns two thread. One of them is exporting DMABUF.

 ? ? ? Thread I ? ? ? ? | ? Thread II ? ? ? | Comments
 ---+---+---
 dbuf = dma_buf_export ?| ? ? ? ? ? ? ? ? ? | dma_buf is creates, refcount 
 is 1
 fd = dma_buf_fd(dbuf) ?| ? ? ? ? ? ? ? ? ? | assume fd is set to 42, 
 refcount is still 1
 ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ?close(42) ? ?| The file descriptor is closed 
 asynchronously, dbuf's refcount drops to 0
 ? ? ? ? ? ? ? ? ? ? ? ?| ?dma_buf_release ?| dbuf structure is freed, dbuf 
 becomes a dangling pointer
 int size = dbuf->size; | ? ? ? ? ? ? ? ? ? | the dbuf is dereferenced, 
 causing a kernel crash
 ---+---+---

 I think that the problem could be fixed in two ways.
 a) forcing driver developer to call get_dma_buf just before calling 
 dma_buf_fd.
 b) increasing dma_buf->file's reference count at dma_buf_fd

 I prefer solution (b) because it prevents symmetry between dma_buf_fd and 
 close.
 I mean that dma_buf_fd increases reference count, close decreases it.

 What is your opinion about the issue?
>>>
>>> I guess most exporters would like to hang onto the exported dma_buf a bit
>>> and hence need a reference (e.g. to cache the dma_buf as long as the
>>> underlying buffer object exists). So I guess we can change the semantics
>>> of dma_buf_fd from transferring the reference you currently have (and
>>> hence forbidding any further access by the caller) to grabbing a reference
>>> of it's on for the fd that is created.
>>> -Daniel
>>
>> Hi Daniel,
>> Would it be simpler, safer and more intuitive if dma_buf_fd increased
>> dmabuf->file's reference counter?
>
> That's actually what I wanted to say. Message seems to have been lost
> in transit ;-)

Now I've thought about it and Tomasz has pointed it out I agree,

Now we just have to work out when to drop that reference, which I
don't see anyone addressing :-)

I love lifetime rules.

Dave.

[no subject]

[Lars-Peter Clausen]

On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> Hi All,
> 
> The following adds a drm/kms driver for the Freescale i.MX LCDC
> controller. Most notable change to the last SDRM based version is that
> the SDRM layer has been removed and the driver now is purely i.MX
> specific. I hope that this is more acceptable now.
> 
> Another change is that the probe is now devicetree based. For now I
> took the easy way out and only put an edid blob into the devicetree.
> I haven't documented the binding yet, I would add that when the rest
> is considered ok.
> 
> Comments very welcome.
> 

Hi,

I really liked the sdrm layer. At least some bits of it. I've been working
on a "simple" DRM driver as well. The hardware has no fancy acceleration
features, just a simple buffer and some scanout logic. I'm basically using
the same gem buffer structure and the buffer is also allocated using
dma_alloc_writecombine, which means we can probably share all of the GEM
handling code and probably also most of the fbdev code. I also started with
the Exynos GEM code as a template, but reworked it later to be more like the
UDL code, which made it a bit more compact. I think it would be a good idea
to put at least the GEM handling in some common code as I expect that we'll
see more similar "simple" DRM drivers pop up.

The code in question can be found at
https://github.com/lclausen-adi/linux-2.6/commit/87a8fd6b98317c7a486846cc8405d0bd68d8

Btw. the imx-drm.h is missing in your patch.

- Lars

> Thanks
>  Sascha
> 
> 
> Sascha Hauer (2):
>   DRM: add Freescale i.MX LCDC driver
>   pcm038 lcdc support
> 
>  arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
>  arch/arm/boot/dts/imx27.dtsi   |7 +
>  arch/arm/mach-imx/clock-imx27.c|1 +
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/imx/Kconfig|   18 +
>  drivers/gpu/drm/imx/Makefile   |8 +
>  drivers/gpu/drm/imx/imx-drm-core.c |  745 
> 
>  drivers/gpu/drm/imx/imx-fb.c   |  179 +++
>  drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
>  drivers/gpu/drm/imx/imx-gem.c  |  343 +
>  drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
>  drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
>  13 files changed, 2363 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/Kconfig
>  create mode 100644 drivers/gpu/drm/imx/Makefile
>  create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fb.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
>  create mode 100644 drivers/gpu/drm/imx/imx-gem.c
>  create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
>  create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #9 from Andre Heider  2012-05-22 09:03:31 
PDT ---
Merely pointing out what I noticed, which might be unrelated to its correctness
;)
And that's that the handler itself triggers thread b) and hence might deadlock,
unrelated to additional users.
But if I'm indeed seeing ghosts please ignore the false alarm.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43272] pink/purple line displays to the left of the screen

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43272





--- Comment #3 from Damien Churchill   2012-05-22 15:56:10 
---
Looks like I do, I'll have to wait until I get back from work to see whether
that fixes it, thanks!

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 43272] pink/purple line displays to the left of the screen

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43272


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #2 from Alex Deucher   2012-05-22 
15:54:37 ---
Did you enable hdmi audio?  Try making sure radeon.audio=0

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] dma-buf: add get_dma_buf()

[Tomasz Stanislawski]

Hi,
I think I discovered an interesting issue with dma_buf.
I found out that dma_buf_fd does not increase reference
count for dma_buf::file. This leads to potential kernel
crash triggered by user space. Please, take a look on
the scenario below:

The applications spawns two thread. One of them is exporting DMABUF.

  Thread I |   Thread II   | Comments
---+---+---
dbuf = dma_buf_export  |   | dma_buf is creates, refcount is 1
fd = dma_buf_fd(dbuf)  |   | assume fd is set to 42, refcount 
is still 1
   |  close(42)| The file descriptor is closed 
asynchronously, dbuf's refcount drops to 0
   |  dma_buf_release  | dbuf structure is freed, dbuf 
becomes a dangling pointer
int size = dbuf->size; |   | the dbuf is dereferenced, causing 
a kernel crash
---+---+---

I think that the problem could be fixed in two ways.
a) forcing driver developer to call get_dma_buf just before calling dma_buf_fd.
b) increasing dma_buf->file's reference count at dma_buf_fd

I prefer solution (b) because it prevents symmetry between dma_buf_fd and close.
I mean that dma_buf_fd increases reference count, close decreases it.

What is your opinion about the issue?

Regards,
Tomasz Stanislawski



On 03/16/2012 05:04 PM, Rob Clark wrote:
> From: Rob Clark 
> 
> Works in a similar way to get_file(), and is needed in cases such as
> when the exporter needs to also keep a reference to the dmabuf (that
> is later released with a dma_buf_put()), and possibly other similar
> cases.
> 
> Signed-off-by: Rob Clark 
> ---

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #8 from m.b.lankhorst at gmail.com 2012-05-22 08:46:31 PDT ---
You're complaining about undefined behavior in a destruction handler?

When you call radeon_drm_cs_destroy, you better make damned well sure you've
finished using it first, you have bigger problems than a deadlock otherwise.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #7 from Andre Heider  2012-05-22 08:42:42 
PDT ---
Well, I just skimmed over the patch, so maybe I'm missing something, but what
I'm seeing is: 2 threads
a) runs radeon_drm_cs_destroy()
b) runs radeon_drm_cs_emit_ioctl()

When e.g. a context switch occurs on thread a) between 1) and 2) then thread b)
can run pipe_semaphore_signal(>flush_completed) before a) runs
pipe_semaphore_wait(>flush_completed).
The former will effectively be a noop since no other thread is waiting and the
latter will block forever.
No?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43272] New: pink/purple line displays to the left of the screen

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43272

   Summary: pink/purple line displays to the left of the screen
   Product: Drivers
   Version: 2.5
Kernel Version: 3.4.0
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: low
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: damoxc at gmail.com
Regression: Yes


Ever since the upgrade to 3.3 I've had a pinkish purple vertical line down the
left hand side of the screen that's probably 2-5px wide. It happens early in
the boot process (I imagine as soon as KMS in engaged). I've had a look through
the boot log but can't see anything suspect, but then I don't really know what
I'm looking for.

Anyone who can give some help in where to look for additional information to
help resolve this would be most appreciated.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 1/2] DRM: add Freescale i.MX LCDC driver

[Rob Clark]

just a few comments from a cursory review..  I need a bit more time
for a more in-depth review but that won't be tonight so I thought I'd
send what I have so far..


On Fri, May 18, 2012 at 6:27 AM, Sascha Hauer  wrote:
> Signed-off-by: Sascha Hauer 
> ---
> ?drivers/gpu/drm/Kconfig ? ? ? ? ? ? ? ? ? ?| ? ?2 +
> ?drivers/gpu/drm/Makefile ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/gpu/drm/imx/Kconfig ? ? ? ? ? ? ? ?| ? 18 +
> ?drivers/gpu/drm/imx/Makefile ? ? ? ? ? ? ? | ? ?8 +
> ?drivers/gpu/drm/imx/imx-drm-core.c ? ? ? ? | ?745 
> 
> ?drivers/gpu/drm/imx/imx-fb.c ? ? ? ? ? ? ? | ?179 +++
> ?drivers/gpu/drm/imx/imx-fbdev.c ? ? ? ? ? ?| ?275 ++
> ?drivers/gpu/drm/imx/imx-gem.c ? ? ? ? ? ? ?| ?343 +
> ?drivers/gpu/drm/imx/imx-lcdc-crtc.c ? ? ? ?| ?517 +++
> ?drivers/gpu/drm/imx/imx-parallel-display.c | ?228 +
> ?10 files changed, 2316 insertions(+)
> ?create mode 100644 drivers/gpu/drm/imx/Kconfig
> ?create mode 100644 drivers/gpu/drm/imx/Makefile
> ?create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
> ?create mode 100644 drivers/gpu/drm/imx/imx-fb.c
> ?create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
> ?create mode 100644 drivers/gpu/drm/imx/imx-gem.c
> ?create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
> ?create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index e354bc0..759502c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -186,3 +186,5 @@ source "drivers/gpu/drm/vmwgfx/Kconfig"
> ?source "drivers/gpu/drm/gma500/Kconfig"
>
> ?source "drivers/gpu/drm/udl/Kconfig"
> +
> +source "drivers/gpu/drm/imx/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index c20da5b..6569d8d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -42,4 +42,5 @@ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
> ?obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> ?obj-$(CONFIG_DRM_GMA500) += gma500/
> ?obj-$(CONFIG_DRM_UDL) += udl/
> +obj-$(CONFIG_DRM_IMX) += imx/
> ?obj-y ? ? ? ? ? ? ? ? ?+= i2c/
> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> new file mode 100644
> index 000..5fc3a44
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/Kconfig
> @@ -0,0 +1,18 @@
> +config DRM_IMX
> + ? ? ? tristate "DRM Support for Freescale i.MX"
> + ? ? ? select DRM_KMS_HELPER
> + ? ? ? depends on DRM && ARCH_MXC
> +
> +config DRM_IMX_FB_HELPER
> + ? ? ? tristate "provide legacy framebuffer /dev/fb0"
> + ? ? ? depends on DRM_IMX
> +
> +config DRM_IMX_LCDC
> + ? ? ? tristate "DRM Support for Freescale i.MX1 and i.MX2"
> + ? ? ? depends on DRM_IMX
> + ? ? ? help
> + ? ? ? ? Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 processor.

do you have something like cpu_is_imx2() type macros?  It would be
preferable not to have a compile time config option for building for
certain hw versions.  Ie. on OMAP we could do something like 'if
(cpu_is_omap3xxx()) { ... }' if there was something that needed to be
done different on omap3 family of devices.  This way you could choose
to build a kernel supporting either a single omap variants, or all
omap variants.

> +
> +config DRM_IMX_PARALLEL_DISPLAY
> + ? ? ? tristate "Support for parallel displays"
> + ? ? ? depends on DRM_IMX
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> new file mode 100644
> index 000..0f7c038
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -0,0 +1,8 @@
> +
> +imxdrm-objs := imx-drm-core.o imx-fb.o imx-gem.o
> +
> +obj-$(CONFIG_DRM_IMX) += imxdrm.o
> +
> +obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += imx-parallel-display.o
> +obj-$(CONFIG_DRM_IMX_LCDC) += imx-lcdc-crtc.o
> +obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> new file mode 100644
> index 000..29f5f10
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -0,0 +1,745 @@
> +/*
> + * simple drm driver
> + *
> + * Copyright (C) 2011 Sascha Hauer, Pengutronix
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-drm.h"
> +
> +#define MAX_CRTC ? ? ? 4
> +
> +struct imx_drm_device {
> + ? ? ? struct drm_device ? ? ? ? ? ? ? ? ? ? ? *drm;
> + ? ? ? struct device ? ? ? ? ? ? ? ? ? ? ? ? ? *dev;
> + ? ? ? struct list_head ? ? ? ? ? ? ? ? ? ? ? 

[Bug 50208] X does not start on Linux kernel 3.2.0-24, works on 3.0.0-19

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50208

--- Comment #1 from S?rgio M. Basto  2012-05-22 08:25:05 
PDT ---
man , kernel 3.4 is out

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/i915: no lvds quirk for HP t5740e Thin Client

[Jan-Benedict Glaw]

Hi!

This box has DisplayPort and VGA, but no LVDS. Product specs are at
http://h10010.www1.hp.com/wwpc/us/en/sm/WF25a/12454-12454-321959-338927-3640406-4282707.html?dnr=1
and dmidecode output can be found at 
http://www.getslash.de/bug_attachments/dmidecode-t5740e.txt

Signed-off-by: Jan-Benedict Glaw 
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 9c71183..9fadd64 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -747,6 +747,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
},
{
.callback = intel_no_lvds_dmi_callback,
+   .ident = "Hewlett-Packard HP t5740e Thin Client",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin Client"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
.ident = "Hewlett-Packard t5745",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
-- 
1.7.10

-- 
Getslash GmbH, Bahnhofstra?e 16, 59302 Oelde
Tel: +49-2522-834349-5Fax: +49-2522-834349-1
http://www.getslash.de
Sitz der Gesellschaft: Oelde
Handelsregister: Amtsgericht M?nster, HRB 11911
Ust-Id-Nr.: DE 815060326
Gesch?ftsf?hrung: Andre Peitz, Tobias Hanisch 

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #6 from m.b.lankhorst at gmail.com 2012-05-22 07:44:12 PDT ---
What do you mean? flush_completed is always explicitly signalled before the
flush thread is exiting, see right before the 'return NULL'

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 6/7] i915: add dmabuf/prime buffer sharing support.

[Chris Wilson]

On Tue, 22 May 2012 13:50:03 +0100, Dave Airlie  wrote:
> From: Daniel Vetter 
> 
> This adds handle->fd and fd->handle support to i915, this is to allow
> for offloading of rendering in one direction and outputs in the other.
> 
> v2 from Daniel Vetter:
> - fixup conflicts with the prepare/finish gtt prep work.
> - implement ppgtt binding support.
> 
> Note that we have squat i-g-t testcoverage for any of the lifetime and
> access rules dma_buf/prime support brings along. And there are quite a
> few intricate situations here.
> 
> Also note that the integration with the existing code is a bit
> hackish, especially around get_gtt_pages and put_gtt_pages. It imo
> would be easier with the prep code from Chris Wilson's unbound series,
> but that is for 3.6.
> 
> Also note that I didn't bother to put the new prepare/finish gtt hooks
> to good use by moving the dma_buf_map/unmap_attachment calls in there
> (like we've originally planned for).
> 
> Last but not least this patch is only compile-tested, but I've changed
> very little compared to Dave Airlie's version. So there's a decent
> chance v2 on drm-next works as well as v1 on 3.4-rc.
> 
> v3: Right when I've hit sent I've noticed that I've screwed up one
> obj->sg_list (for dmar support) and obj->sg_table (for prime support)
> disdinction. We should be able to merge these 2 paths, but that's
> material for another patch.
> 
> v4: fix the error reporting bugs pointed out by ickle.
> 
> v5: fix another error, and stop non-gtt mmaps on shared objects
> stop pread/pwrite on imported objects, add fake kmap

Everything up to this point looks reasonable wrt i915. We obviously need
to lift a few of the restrictions for i915 introduced here and protect
dma-buf objects from the shrinker/truncate.  In fact we need to add a
guard to i915_gem_object_truncate in this patch to prevent one such
explosion. Wrt to the shrinker and the leak of exported pages, that
should be managed by the unbound page tracking which is queued for
review this cycle (right Daniel? ;). That just leaves fixing up
pread/pwrite and fixing the other guards that will interact sorely with
stolen (also non-shmem backed) objects.
-Chris

> Signed-off-by: Dave Airlie 
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/Makefile  |3 +-
>  drivers/gpu/drm/i915/i915_drv.c|8 ++-
>  drivers/gpu/drm/i915/i915_drv.h|   11 ++
>  drivers/gpu/drm/i915/i915_gem.c|   37 +++-
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  171 
> 
>  drivers/gpu/drm/i915/i915_gem_gtt.c|   15 +++-
>  6 files changed, 239 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0ca7f76..2e9268d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -38,7 +38,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
> dvo_ch7017.o \
> dvo_ivch.o \
> dvo_tfp410.o \
> -   dvo_sil164.o
> +   dvo_sil164.o \
> +   i915_gem_dmabuf.o

Since we need another chunk to this patch, can you please add this file
in the i915_gem_*.c block.

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] backlight: initialize struct backlight_properties properly

[Andrew Morton]

On Mon, 21 May 2012 09:24:35 +0200
Corentin Chary  wrote:

> In all these files, the .power field was never correctly initialized.
> 
> ...
>
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
>   else
>   return -ENODEV;
>  
> + memset(, 0, sizeof(props));

This code is all still quite fragile.  What happens if we add a new
field to backlight_properties?  We need to go edit a zillion drivers?

There are two ways of fixing this:

a) write and use

void backlight_properties_init(struct backlight_properties *props,
int type, int max_brightness, etc);

   or

b) edit all sites to do

struct backlight_properties bl_props = {
.type = BACKLIGHT_RAW,
.max_brighness = intel_panel_get_max_backlight(dev),
.power = FB_BLANK_UNBLANK,
};

they're largely equivalent - the struct will be zeroed out and
then certain fields will be initialised.  a) is a bit better because
some future field may not want the all-zeroes pattern (eg, a spinlock).

But they're both better than what we have now!

[RFC 05/13] v4l: vb2-dma-contig: add support for DMABUF exporting

[Tomasz Stanislawski]

Hi Laurent,

Sorry for the late reply.
Thank you very much for noticing the issue.

 +static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv)
 +{
 +  struct vb2_dc_buf *buf = buf_priv;
 +  struct dma_buf *dbuf;
 +
 +  if (buf->dma_buf)
 +  return buf->dma_buf;
>>>
>>> Can't there be a race condition here if the user closes the DMABUF file
>>> handle before vb2 core calls dma_buf_fd() ?
>>
>> The user cannot access the file until it is associated with a file
>> descriptor. How can the user close it? Could you give me a more detailed
>> description of this potential race condition?
> 
> Let's assume the V4L2 buffer has already been exported once. buf->dma_buf is 
> set to a non-NULL value, and the application has an open file handle for the 
> buffer. The application then tries to export the buffer a second time. 
> vb2_dc_get_dmabuf() gets called, checks buf->dma_buf and returns it as it's 
> non-NULL. Right after that, before the vb2 core calls dma_buf_fd() on the 
> struct dma_buf, the application closes the file handle to the exported 
> buffer. 
> The struct dma_buf object gets freed, as the reference count drops to 0.

I am not sure if reference counter drops to 0 in this case. Notice that after
first dma_buf_export the dma_buf's refcnt is 1, after first dma_buf_fd it goes
to 2. After closing a file handle the refcnt drops back to 1 so the file
(and dma_buf) is not released. Therefore IMO there no dangling pointer issue.

However it looks that there is a circular reference between vb2_dc_buf and 
dma_buf.
vb2_dc_buf::dma_buf is pointing to dma_buf with reference taken at 
dma_buf_export.
On the other hand the dma_buf->priv is pointing to vb2_dc_buf with reference
taken at atomic_inc(>refcount) in vb2_dc_get_dmabuf.

The circular reference leads into resource leakage.
The problem could be fixed by dropping caching of dma_buf pointer.
The new dma_buf would be created and exported at every export event.
The dma_buf_put would be called in vb2_expbuf just after
successful dma_buf_fd.

Do you have any ideas how I could deal with resource leakage/dangling problems
without creating a new dma_buf instance at every export event?

Regards,
Tomasz Stanislawski


> vb2 core will then try to call dma_buf_fd() on a dma_buf object that has been 
> freed.
> 
 +  /* dmabuf keeps reference to vb2 buffer */
 +  atomic_inc(>refcount);
 +  dbuf = dma_buf_export(buf, _dc_dmabuf_ops, buf->size, 0);
 +  if (IS_ERR(dbuf)) {
 +  atomic_dec(>refcount);
 +  return NULL;
 +  }
 +
 +  buf->dma_buf = dbuf;
 +
 +  return dbuf;
 +}
> 

[PATCH 7/7] drm/radeon: add PRIME support (v2)

[Dave Airlie]

From: Alex Deucher 

This adds prime->fd and fd->prime support to radeon.
It passes the sg object to ttm and then populates
the gart entries using it.

Compile tested only.

v2: stub kmap + use new helpers + add reimporting

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/Makefile |2 +-
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +-
 drivers/gpu/drm/radeon/r600.c   |4 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c  |2 +-
 drivers/gpu/drm/radeon/radeon_benchmark.c   |4 +-
 drivers/gpu/drm/radeon/radeon_device.c  |2 +-
 drivers/gpu/drm/radeon/radeon_drv.c |   14 ++-
 drivers/gpu/drm/radeon/radeon_gart.c|2 +-
 drivers/gpu/drm/radeon/radeon_gem.c |4 +-
 drivers/gpu/drm/radeon/radeon_object.c  |6 +-
 drivers/gpu/drm/radeon/radeon_object.h  |7 +-
 drivers/gpu/drm/radeon/radeon_prime.c   |  176 +++
 drivers/gpu/drm/radeon/radeon_ring.c|4 +-
 drivers/gpu/drm/radeon/radeon_sa.c  |2 +-
 drivers/gpu/drm/radeon/radeon_test.c|4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c |   16 ++-
 drivers/gpu/drm/radeon/si.c |6 +-
 17 files changed, 232 insertions(+), 25 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_prime.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 1efb6eb..a6598fd 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
evergreen_blit_kms.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
-   si_blit_shaders.o
+   si_blit_shaders.o radeon_prime.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 30f0480..1e96bd4 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -668,7 +668,7 @@ int evergreen_blit_init(struct radeon_device *rdev)
obj_size = ALIGN(obj_size, 256);

r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
RADEON_GEM_DOMAIN_VRAM,
-   >r600_blit.shader_obj);
+NULL, >r600_blit.shader_obj);
if (r) {
DRM_ERROR("evergreen failed to allocate shader\n");
return r;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index ab5d6f2..f388a1d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1231,7 +1231,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
if (rdev->vram_scratch.robj == NULL) {
r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
 PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
->vram_scratch.robj);
+NULL, >vram_scratch.robj);
if (r) {
return r;
}
@@ -2769,7 +2769,7 @@ int r600_ih_ring_alloc(struct radeon_device *rdev)
r = radeon_bo_create(rdev, rdev->ih.ring_size,
 PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_GTT,
->ih.ring_obj);
+NULL, >ih.ring_obj);
if (r) {
DRM_ERROR("radeon: failed to create ih ring buffer 
(%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index ef20822..03b6e0d 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -552,7 +552,7 @@ int r600_blit_init(struct radeon_device *rdev)
obj_size = ALIGN(obj_size, 256);

r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
RADEON_GEM_DOMAIN_VRAM,
-   >r600_blit.shader_obj);
+NULL, >r600_blit.shader_obj);
if (r) {
DRM_ERROR("r600 failed to allocate shader\n");
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index fef7b72..364f5b1 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -103,7 +103,7 @@ static void radeon_benchmark_move(struct radeon_device 
*rdev, unsigned size,
int time;

n = RADEON_BENCHMARK_ITERATIONS;
-   r = radeon_bo_create(rdev, size, PAGE_SIZE, true, sdomain, );
+   r = radeon_bo_create(rdev, size, 

[PATCH 6/7] i915: add dmabuf/prime buffer sharing support.

[Dave Airlie]

From: Daniel Vetter 

This adds handle->fd and fd->handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.

v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.

Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.

Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.

Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).

Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.

v3: Right when I've hit sent I've noticed that I've screwed up one
obj->sg_list (for dmar support) and obj->sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.

v4: fix the error reporting bugs pointed out by ickle.

v5: fix another error, and stop non-gtt mmaps on shared objects
stop pread/pwrite on imported objects, add fake kmap

Signed-off-by: Dave Airlie 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/Makefile  |3 +-
 drivers/gpu/drm/i915/i915_drv.c|8 ++-
 drivers/gpu/drm/i915/i915_drv.h|   11 ++
 drivers/gpu/drm/i915/i915_gem.c|   37 +++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  171 
 drivers/gpu/drm/i915/i915_gem_gtt.c|   15 +++-
 6 files changed, 239 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ca7f76..2e9268d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -38,7 +38,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
  dvo_ch7017.o \
  dvo_ivch.o \
  dvo_tfp410.o \
- dvo_sil164.o
+ dvo_sil164.o \
+ i915_gem_dmabuf.o

 i915-$(CONFIG_COMPAT)   += i915_ioc32.o

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7b967d5..238a521 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1039,7 +1039,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
-   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM,
+   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
.open = i915_driver_open,
@@ -1062,6 +1062,12 @@ static struct drm_driver driver = {
.gem_init_object = i915_gem_init_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
+
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = i915_gem_prime_export,
+   .gem_prime_import = i915_gem_prime_import,
+
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_mmap_gtt,
.dumb_destroy = i915_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11c7a6a..377c21f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -940,6 +940,8 @@ struct drm_i915_gem_object {
struct scatterlist *sg_list;
int num_sg;

+   /* prime dma-buf support */
+   struct sg_table *sg_table;
/**
 * Used for performing relocations during execbuffer insertion.
 */
@@ -1245,6 +1247,8 @@ int __must_check i915_gem_object_unbind(struct 
drm_i915_gem_object *obj);
 void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
 void i915_gem_lastclose(struct drm_device *dev);

+int i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
+ gfp_t gfpmask);
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int __must_check i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
@@ -1342,6 +1346,13 @@ i915_gem_get_unfenced_gtt_alignment(struct drm_device 
*dev,
 int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);

+struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);
+
+struct dma_buf *i915_gem_prime_export(struct drm_device *dev,

[PATCH 5/7] nouveau: add PRIME support

[Dave Airlie]

From: Dave Airlie 

This adds prime->fd and fd->prime support to nouveau,
it passes the SG object to TTM, and then populates the
GART entries using it.

v2: add stubbed kmap + use new function to fill out pages array
for faulting + add reimport test.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/Makefile  |2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   42 ++--
 drivers/gpu/drm/nouveau/nouveau_channel.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c |8 ++-
 drivers/gpu/drm/nouveau/nouveau_drv.h |   10 ++-
 drivers/gpu/drm/nouveau/nouveau_fence.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c |6 +-
 drivers/gpu/drm/nouveau/nouveau_mem.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_prime.c   |  163 +
 drivers/gpu/drm/nouveau/nouveau_sgdma.c   |5 +-
 drivers/gpu/drm/nouveau/nouveau_vm.c  |   57 ++
 drivers/gpu/drm/nouveau/nouveau_vm.h  |6 +-
 drivers/gpu/drm/nouveau/nv04_crtc.c   |2 +-
 drivers/gpu/drm/nouveau/nv50_crtc.c   |4 +-
 drivers/gpu/drm/nouveau/nv50_evo.c|4 +-
 drivers/gpu/drm/nouveau/nvd0_display.c|6 +-
 16 files changed, 296 insertions(+), 25 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_prime.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 1a2ad7e..01f1335 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -37,7 +37,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o 
nouveau_mem.o \
 nv50_calc.o \
 nv04_pm.o nv40_pm.o nv50_pm.o nva3_pm.o nvc0_pm.o \
 nv50_vram.o nvc0_vram.o \
-nv50_vm.o nvc0_vm.o
+nv50_vm.o nvc0_vm.o nouveau_prime.o

 nouveau-$(CONFIG_DRM_NOUVEAU_DEBUG) += nouveau_debugfs.o
 nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 81599d6..4435e11 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -89,12 +89,17 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
 int
 nouveau_bo_new(struct drm_device *dev, int size, int align,
   uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
+  struct sg_table *sg,
   struct nouveau_bo **pnvbo)
 {
struct drm_nouveau_private *dev_priv = dev->dev_private;
struct nouveau_bo *nvbo;
size_t acc_size;
int ret;
+   int type = ttm_bo_type_device;
+
+   if (sg)
+   type = ttm_bo_type_sg;

nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL);
if (!nvbo)
@@ -120,8 +125,8 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
   sizeof(struct nouveau_bo));

ret = ttm_bo_init(_priv->ttm.bdev, >bo, size,
- ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size, NULL,
+ type, >placement,
+ align >> PAGE_SHIFT, 0, false, NULL, acc_size, sg,
  nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
@@ -817,9 +822,14 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem)
} else
if (new_mem && new_mem->mem_type == TTM_PL_TT &&
nvbo->page_shift == vma->vm->spg_shift) {
-   nouveau_vm_map_sg(vma, 0, new_mem->
- num_pages << PAGE_SHIFT,
- new_mem->mm_node);
+   if (((struct nouveau_mem *)new_mem->mm_node)->sg)
+   nouveau_vm_map_sg_table(vma, 0, new_mem->
+ num_pages << PAGE_SHIFT,
+ new_mem->mm_node);
+   else
+   nouveau_vm_map_sg(vma, 0, new_mem->
+ num_pages << PAGE_SHIFT,
+ new_mem->mm_node);
} else {
nouveau_vm_unmap(vma);
}
@@ -1058,10 +1068,19 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
struct drm_device *dev;
unsigned i;
int r;
+   bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);

if (ttm->state != tt_unpopulated)
return 0;

+   if (slave && ttm->sg) {
+   /* make userspace faulting work */
+   drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
+ttm_dma->dma_address, 
ttm->num_pages);
+   ttm->state = tt_unbound;
+   return 0;
+   }
+
dev_priv = 

[PATCH 4/7] ttm: add prime sharing support to TTM (v2)

[Dave Airlie]

From: Dave Airlie 

This adds the ability for ttm common code to take an SG table
and use it as the backing for a slave TTM object.

The drivers can then populate their GTT tables using the SG object.

v2: make sure to setup VM for sg bos as well.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 drivers/gpu/drm/radeon/radeon_object.c   |2 +-
 drivers/gpu/drm/ttm/ttm_bo.c |   17 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |2 +-
 include/drm/ttm/ttm_bo_api.h |9 -
 include/drm/ttm/ttm_bo_driver.h  |2 ++
 6 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 12ce044..81599d6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -121,7 +121,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,

ret = ttm_bo_init(_priv->ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size,
+ align >> PAGE_SHIFT, 0, false, NULL, acc_size, NULL,
  nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index df6a4db..1affbc9 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -155,7 +155,7 @@ retry:
mutex_lock(>vram_mutex);
r = ttm_bo_init(>mman.bdev, >tbo, size, type,
>placement, page_align, 0, !kernel, NULL,
-   acc_size, _ttm_bo_destroy);
+   acc_size, NULL, _ttm_bo_destroy);
mutex_unlock(>vram_mutex);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1f5c67c..36792bd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -343,6 +343,16 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
if (unlikely(bo->ttm == NULL))
ret = -ENOMEM;
break;
+   case ttm_bo_type_sg:
+   bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << 
PAGE_SHIFT,
+ page_flags | 
TTM_PAGE_FLAG_SG,
+ glob->dummy_read_page);
+   if (unlikely(bo->ttm == NULL)) {
+   ret = -ENOMEM;
+   break;
+   }
+   bo->ttm->sg = bo->sg;
+   break;
default:
pr_err("Illegal buffer object type\n");
ret = -EINVAL;
@@ -1169,6 +1179,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bool interruptible,
struct file *persistent_swap_storage,
size_t acc_size,
+   struct sg_table *sg,
void (*destroy) (struct ttm_buffer_object *))
 {
int ret = 0;
@@ -1223,6 +1234,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->seq_valid = false;
bo->persistent_swap_storage = persistent_swap_storage;
bo->acc_size = acc_size;
+   bo->sg = sg;
atomic_inc(>glob->bo_count);

ret = ttm_bo_check_placement(bo, placement);
@@ -1233,7 +1245,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
 * For ttm_bo_type_device buffers, allocate
 * address space from the device.
 */
-   if (bo->type == ttm_bo_type_device) {
+   if (bo->type == ttm_bo_type_device ||
+   bo->type == ttm_bo_type_sg) {
ret = ttm_bo_setup_vm(bo);
if (ret)
goto out_err;
@@ -1312,7 +1325,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,

ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
buffer_start, interruptible,
-   persistent_swap_storage, acc_size, NULL);
+ persistent_swap_storage, acc_size, NULL, NULL);
if (likely(ret == 0))
*p_bo = bo;

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index a37abb5..22bf9a2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -1567,7 +1567,7 @@ int vmw_dmabuf_init(struct vmw_private *dev_priv,
ret = ttm_bo_init(bdev, _bo->base, size,
  ttm_bo_type_device, placement,
  0, 0, interruptible,
- NULL, acc_size, bo_free);
+ NULL, acc_size, NULL, bo_free);
return ret;
 }

diff --git 

[PATCH 3/7] udl: add prime fd->handle support.

[Dave Airlie]

From: Dave Airlie 

udl can only be used as an output offload so doesn't need to support
handle->fd direction.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_drv.c |6 +++-
 drivers/gpu/drm/udl/udl_drv.h |3 ++
 drivers/gpu/drm/udl/udl_fb.c  |9 +
 drivers/gpu/drm/udl/udl_gem.c |   75 +
 4 files changed, 92 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 82e6921..4d02c46 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -57,7 +57,7 @@ static const struct file_operations udl_driver_fops = {
 };

 static struct drm_driver driver = {
-   .driver_features = DRIVER_MODESET | DRIVER_GEM,
+   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.load = udl_driver_load,
.unload = udl_driver_unload,

@@ -70,6 +70,10 @@ static struct drm_driver driver = {
.dumb_map_offset = udl_gem_mmap,
.dumb_destroy = udl_dumb_destroy,
.fops = _driver_fops,
+
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_import = udl_gem_prime_import,
+
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 96820d0..fccd361 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -66,6 +66,7 @@ struct udl_gem_object {
struct drm_gem_object base;
struct page **pages;
void *vmapping;
+   struct sg_table *sg;
 };

 #define to_udl_bo(x) container_of(x, struct udl_gem_object, base)
@@ -118,6 +119,8 @@ int udl_gem_init_object(struct drm_gem_object *obj);
 void udl_gem_free_object(struct drm_gem_object *gem_obj);
 struct udl_gem_object *udl_gem_alloc_object(struct drm_device *dev,
size_t size);
+struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);

 int udl_gem_vmap(struct udl_gem_object *obj);
 void udl_gem_vunmap(struct udl_gem_object *obj);
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 4d9c3a5..a029ee3 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -593,11 +593,20 @@ udl_fb_user_fb_create(struct drm_device *dev,
struct drm_gem_object *obj;
struct udl_framebuffer *ufb;
int ret;
+   uint32_t size;

obj = drm_gem_object_lookup(dev, file, mode_cmd->handles[0]);
if (obj == NULL)
return ERR_PTR(-ENOENT);

+   size = mode_cmd->pitches[0] * mode_cmd->height;
+   size = ALIGN(size, PAGE_SIZE);
+
+   if (size > obj->size) {
+   DRM_ERROR("object size not sufficient for fb %d %zu %d %d\n", 
size, obj->size, mode_cmd->pitches[0], mode_cmd->height);
+   return ERR_PTR(-ENOMEM);
+   }
+
ufb = kzalloc(sizeof(*ufb), GFP_KERNEL);
if (ufb == NULL)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 92f19ef..40efd32 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -9,6 +9,7 @@
 #include "drmP.h"
 #include "udl_drv.h"
 #include 
+#include 

 struct udl_gem_object *udl_gem_alloc_object(struct drm_device *dev,
size_t size)
@@ -161,6 +162,12 @@ static void udl_gem_put_pages(struct udl_gem_object *obj)
int page_count = obj->base.size / PAGE_SIZE;
int i;

+   if (obj->base.import_attach) {
+   drm_free_large(obj->pages);
+   obj->pages = NULL;
+   return;
+   }
+
for (i = 0; i < page_count; i++)
page_cache_release(obj->pages[i]);

@@ -195,6 +202,9 @@ void udl_gem_free_object(struct drm_gem_object *gem_obj)
 {
struct udl_gem_object *obj = to_udl_bo(gem_obj);

+   if (gem_obj->import_attach)
+   drm_prime_gem_destroy(gem_obj, obj->sg);
+
if (obj->vmapping)
udl_gem_vunmap(obj);

@@ -239,3 +249,68 @@ unlock:
mutex_unlock(>struct_mutex);
return ret;
 }
+
+static int udl_prime_create(struct drm_device *dev,
+   size_t size,
+   struct sg_table *sg,
+   struct udl_gem_object **obj_p)
+{
+   struct udl_gem_object *obj;
+   int npages;
+   int i;
+   struct scatterlist *iter;
+
+   npages = size / PAGE_SIZE;
+
+   *obj_p = NULL;
+   obj = udl_gem_alloc_object(dev, npages * PAGE_SIZE);
+   if (!obj)
+   return -ENOMEM;
+
+   obj->sg = sg;
+   obj->pages = drm_malloc_ab(npages, sizeof(struct page *));
+   if (obj->pages == NULL) {
+   DRM_ERROR("obj pages is NULL %d\n", npages);
+   return -ENOMEM;
+   }
+
+   

[PATCH 2/7] drm/prime: add exported buffers to current fprivs imported buffer list (v2)

[Dave Airlie]

From: Dave Airlie 

If userspace attempts to import a buffer it exported on the same device,
we need to return the same GEM handle for it, not a new handle pointing
at the same GEM object.

v2: move removals into a single fn, no need to set to NULL. (Chris Wilson)

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_gem.c   |   21 +++--
 drivers/gpu/drm/drm_prime.c |   12 
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 72ba075..d58e69d 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -201,6 +201,19 @@ free:
 }
 EXPORT_SYMBOL(drm_gem_object_alloc);

+static void
+drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp)
+{
+   if (obj->import_attach) {
+   drm_prime_remove_imported_buf_handle(>prime,
+   obj->import_attach->dmabuf);
+   }
+   if (obj->export_dma_buf) {
+   drm_prime_remove_imported_buf_handle(>prime,
+   obj->export_dma_buf);
+   }
+}
+
 /**
  * Removes the mapping from handle to filp for this object.
  */
@@ -233,9 +246,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(>object_idr, handle);
spin_unlock(>table_lock);

-   if (obj->import_attach)
-   drm_prime_remove_imported_buf_handle(>prime,
-   obj->import_attach->dmabuf);
+   drm_gem_remove_prime_handles(obj, filp);

if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, filp);
@@ -530,9 +541,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj->dev;

-   if (obj->import_attach)
-   drm_prime_remove_imported_buf_handle(_priv->prime,
-   obj->import_attach->dmabuf);
+   drm_gem_remove_prime_handles(obj, file_priv);

if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, file_priv);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 20dbf2c..f546ff9 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -68,6 +68,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
 {
struct drm_gem_object *obj;
void *buf;
+   int ret;

obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj)
@@ -100,6 +101,17 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
obj->export_dma_buf = buf;
*prime_fd = dma_buf_fd(buf, flags);
}
+   /* if we've exported this buffer the cheat and add it to the import list
+* so we get the correct handle back
+*/
+   ret = drm_prime_add_imported_buf_handle(_priv->prime,
+   obj->export_dma_buf, handle);
+   if (ret) {
+   drm_gem_object_unreference_unlocked(obj);
+   mutex_unlock(_priv->prime.lock);
+   return ret;
+   }
+
mutex_unlock(_priv->prime.lock);
return 0;
 }
-- 
1.7.6

[PATCH 1/7] drm/prime: introduce sg->pages/addr arrays helper

[Dave Airlie]

From: Dave Airlie 

the ttm drivers need this currently, in order to get fault handling
working and efficient.

It also allows addrs to be NULL for devices like udl.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_prime.c |   36 
 include/drm/drmP.h  |2 ++
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1bdf2b5..20dbf2c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -227,6 +227,42 @@ out:
 }
 EXPORT_SYMBOL(drm_prime_pages_to_sg);

+/* export an sg table into an array of pages and addresses
+   this is currently required by the TTM driver in order to do correct fault
+   handling */
+int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages,
+dma_addr_t *addrs, int max_pages)
+{
+   unsigned count;
+   struct scatterlist *sg;
+   struct page *page;
+   u32 len, offset;
+   int pg_index;
+   dma_addr_t addr;
+
+   pg_index = 0;
+   for_each_sg(sgt->sgl, sg, sgt->nents, count) {
+   len = sg->length;
+   offset = sg->offset;
+   page = sg_page(sg);
+   addr = sg_dma_address(sg);
+
+   while (len > 0) {
+   if (WARN_ON(pg_index >= max_pages))
+   return -1;
+   pages[pg_index] = page;
+   if (addrs)
+   addrs[pg_index] = addr;
+
+   page++;
+   addr += PAGE_SIZE;
+   len -= PAGE_SIZE;
+   pg_index++;
+   }
+   }
+   return 0;
+}
+EXPORT_SYMBOL(drm_prime_sg_to_page_addr_arrays);
 /* helper function to cleanup a GEM/prime object */
 void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg)
 {
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 15d9179..31ad880 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1558,6 +1558,8 @@ extern int drm_prime_handle_to_fd_ioctl(struct drm_device 
*dev, void *data,
 extern int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);

+extern int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,
+   dma_addr_t *addrs, int max_pages);
 extern struct sg_table *drm_prime_pages_to_sg(struct page **pages, int 
nr_pages);
 extern void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table 
*sg);

-- 
1.7.6

[Linaro-mm-sig] [PATCH] dma-buf: add initial vmap documentation

[Chris Wilson]

On Tue, 22 May 2012 13:34:38 +0100, Dave Airlie  wrote:
> From: Dave Airlie 

Inline comment for one sentence that made no sense.

> Signed-off-by: Dave Airlie 
> ---
>  Documentation/dma-buf-sharing.txt |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 3bbd5c5..98e9fa0 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -300,6 +300,17 @@ Access to a dma_buf from the kernel context involves 
> three steps:
> Note that these calls need to always succeed. The exporter needs to 
> complete
> any preparations that might fail in begin_cpu_access.
>  
> +   For some circumstances the overhead of kmap can be too high, a vmap 
> interface
> +   is introduced. This interface shouldn't be used very carefully, as vmalloc
This interface should be used carefully.

Sparingly would also be appropriate, though in less regular usage than
carefully.

> +   space is a limited resources on many architectures.
> +
> +   Interfaces:
> +  void *dma_buf_vmap(struct dma_buf *dmabuf)
> +  void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> +
> +   This call can fail if there is no vmap support in the exporter, or if it
> +   runs out of vmalloc space. Fallback to kmap should be implemented.
> +
>  3. Finish access

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 11465] Linux-2.6.27-rc5, drm errors in log

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=11465


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 11465] Linux-2.6.27-rc5, drm errors in log

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=11465


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE
 Regression|--- |No




--- Comment #6 from Alan   2012-05-22 13:41:09 ---
Marking as obsolete, if this is incorrect please re-open this bug against a
modern 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.

[PATCH] dma-buf: add initial vmap documentation

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 Documentation/dma-buf-sharing.txt |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 3bbd5c5..98e9fa0 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -300,6 +300,17 @@ Access to a dma_buf from the kernel context involves three 
steps:
Note that these calls need to always succeed. The exporter needs to complete
any preparations that might fail in begin_cpu_access.

+   For some circumstances the overhead of kmap can be too high, a vmap 
interface
+   is introduced. This interface shouldn't be used very carefully, as vmalloc
+   space is a limited resources on many architectures.
+
+   Interfaces:
+  void *dma_buf_vmap(struct dma_buf *dmabuf)
+  void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+
+   This call can fail if there is no vmap support in the exporter, or if it
+   runs out of vmalloc space. Fallback to kmap should be implemented.
+
 3. Finish access

When the importer is done accessing the range specified in begin_cpu_access,
-- 
1.7.6

[PATCH v3] scatterlist: add sg_alloc_table_from_pages function

[Andrew Morton]

On Mon, 21 May 2012 16:01:50 +0200
Tomasz Stanislawski  wrote:

> >> +int sg_alloc_table_from_pages(struct sg_table *sgt,
> >> +  struct page **pages, unsigned int n_pages,
> >> +  unsigned long offset, unsigned long size,
> >> +  gfp_t gfp_mask)
> > 
> > I guess a 32-bit n_pages is OK.  A 16TB IO seems enough ;)
> > 
> 
> Do you think that 'unsigned long' for offset is too big?
> 
> Ad n_pages. Assuming that Moore's law holds it will take
> circa 25 years before the limit of 16 TB is reached :) for
> high-end scatterlist operations.
> Or I can change the type of n_pages to 'unsigned long' now at
> no cost :).

By then it will be Someone Else's Problem ;)

> >> +{
> >> +  unsigned int chunks;
> >> +  unsigned int i;
> > 
> > erk, please choose a different name for this.  When a C programmer sees
> > "i", he very much assumes it has type "int".  Making it unsigned causes
> > surprise.
> > 
> > And don't rename it to "u"!  Let's give it a nice meaningful name.  pageno?
> > 
> 
> The problem is that 'i' is  a natural name for a loop counter.

It's also the natural name for an integer.  If a C programmer sees "i",
he thinks "int".  It's a Fortran thing ;)

> AFAIK, in the kernel code developers try to avoid Hungarian notation.
> A name of a variable should reflect its purpose, not its type.
> I can change the name of 'i' to 'pageno' and 'j' to 'pageno2' (?)
> but I think it will make the code less reliable.

Well, one could do something radical such as using "p".

kernel 3.4.0 oops

[Andrei Popa]

On Tue, 2012-05-22 at 10:33 +0100, Chris Wilson wrote:
> I think I encountered this bug whilst developing "drm/i915:
> Asynchronously unpin the old framebuffer after the next vblank". Try
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index afab263..9b94871 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1865,6 +1865,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>   goto err_unpin;
>  
>   i915_gem_object_pin_fence(obj);
> + drm_gem_object_reference(>base);
>  
>   dev_priv->mm.interruptible = true;
>   return 0;
> @@ -1880,6 +1881,7 @@ void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
>  {
>   i915_gem_object_unpin_fence(obj);
>   i915_gem_object_unpin(obj);
> + drm_gem_object_unreference(>base);
>  }
> -Chris

With this patch my computer freezes when I start X.
Only "ALT+SysRq+b" works.

kernel 3.4.0 oops

[Daniel Vetter]

On Tue, May 22, 2012 at 01:02:53PM +0300, Andrei Popa wrote:
> On Tue, 2012-05-22 at 11:20 +0200, Daniel Vetter wrote:
> 
> > Can you please attach the complete dmesg that contains this WARN
> > backtrace? Depending upon how we ended up here, we should get more stuff
> > (which would be pretty important to know to correctly diagnose the bug).
> > -Daniel
> 
> The oops happens in X(KDE) when I run:
> # xrandr -d :0 --output LVDS1 --off --noprimary
> # xrandr -d :0 --output VGA1 --mode 1280x1024 --refresh 75
> (I have a laptop and an external monitor connected to the laptop VGA
> port; with the above commands I close the laptop LCD and I only use the
> external VGA  display).

Ok, I've tried to reproduce this on my ilk here but couldn't hit the
issue. A few things:
- Your gpu dies. Please dig out the versions of mesa, libdrm and
  xf86-video-intel you're using.
- Is this a regression?
- Do you see any other bad side-effects of this besides the WARN in dmesg?
- Also, can you please enable printk timestamps with CONFIG_PRINTK_TIME
  and grab a new dmesg? The relative timings of the things going on would
  be very interesting.

Thanks, Daniel
> 
> Below is dmesg output.
> 3hot D3cold
> pci :00:1c.5: [8086:3b4c] type 01 class 0x060400
> pci :00:1c.5: PME# supported from D0 D3hot D3cold
> pci :00:1d.0: [8086:3b34] type 00 class 0x0c0320
> pci :00:1d.0: reg 10: [mem 0xd4908000-0xd49083ff]
> pci :00:1d.0: PME# supported from D0 D3hot D3cold
> pci :00:1e.0: [8086:2448] type 01 class 0x060401
> pci :00:1f.0: [8086:3b0b] type 00 class 0x060100
> pci :00:1f.2: [8086:3b2f] type 00 class 0x010601
> pci :00:1f.2: reg 10: [io  0x5028-0x502f]
> pci :00:1f.2: reg 14: [io  0x503c-0x503f]
> pci :00:1f.2: reg 18: [io  0x5020-0x5027]
> pci :00:1f.2: reg 1c: [io  0x5038-0x503b]
> pci :00:1f.2: reg 20: [io  0x5000-0x501f]
> pci :00:1f.2: reg 24: [mem 0xd4907000-0xd49077ff]
> pci :00:1f.2: PME# supported from D3hot
> pci :00:1f.6: [8086:3b32] type 00 class 0x118000
> pci :00:1f.6: reg 10: [mem 0xd4906000-0xd4906fff 64bit]
> pci :00:1c.0: PCI bridge to [bus 01-01]
> pci :00:1c.0:   bridge window [mem 0xd480-0xd48f]
> pci :00:1c.1: PCI bridge to [bus 02-42]
> pci :00:1c.1:   bridge window [io  0x3000-0x4fff]
> pci :00:1c.1:   bridge window [mem 0xd080-0xd47f]
> pci :43:00.0: [1814:3090] type 00 class 0x028000
> pci :43:00.0: reg 10: [mem 0xd070-0xd070]
> pci :00:1c.3: PCI bridge to [bus 43-43]
> pci :00:1c.3:   bridge window [mem 0xd070-0xd07f]
> pci :44:00.0: [10ec:8168] type 00 class 0x02
> pci :44:00.0: reg 10: [io  0x2000-0x20ff]
> pci :44:00.0: reg 18: [mem 0xd0404000-0xd0404fff 64bit pref]
> pci :44:00.0: reg 20: [mem 0xd040-0xd0403fff 64bit pref]
> pci :44:00.0: reg 30: [mem 0xfffe-0x pref]
> pci :44:00.0: supports D1 D2
> pci :44:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> pci :00:1c.5: PCI bridge to [bus 44-44]
> pci :00:1c.5:   bridge window [io  0x2000-0x2fff]
> pci :00:1c.5:   bridge window [mem 0xd060-0xd06f]
> pci :00:1c.5:   bridge window [mem 0xd040-0xd04f 64bit pref]
> pci :00:1e.0: PCI bridge to [bus 45-45] (subtractive decode)
> pci :00:1e.0:   bridge window [mem 0xd050-0xd05f]
> pci :00:1e.0:   bridge window [io  0x-0x0cf7] (subtractive
> decode)
> pci :00:1e.0:   bridge window [io  0x0d00-0x] (subtractive
> decode)
> pci :00:1e.0:   bridge window [mem 0x000a-0x000b]
> (subtractive decode)
> pci :00:1e.0:   bridge window [mem 0xc000-0xdfff]
> (subtractive decode)
> pci :00:1e.0:   bridge window [mem 0xf000-0xfedf]
> (subtractive decode)
> pci :00:1e.0:   bridge window [mem 0xfee01000-0x]
> (subtractive decode)
> pci_bus :00: on NUMA node 0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP06._PRT]
>  pci:00: Requesting ACPI _OSC control (0x1d)
>  pci:00: ACPI _OSC control (0x1d) granted
> ACPI: PCI Root Bridge [CPBG] (domain  [bus ff])
> PCI host bridge to bus :ff
> pci :ff:00.0: [8086:2c62] type 00 class 0x06
> pci :ff:00.1: [8086:2d01] type 00 class 0x06
> pci :ff:02.0: [8086:2d10] type 00 class 0x06
> pci :ff:02.1: [8086:2d11] type 00 class 0x06
> pci :ff:02.2: [8086:2d12] type 00 class 0x06
> pci :ff:02.3: [8086:2d13] type 00 class 0x06
> pci_bus :ff: on NUMA node 0
>  pci:ff: Requesting ACPI _OSC control (0x1d)
>  pci:ff: ACPI _OSC request failed (AE_NOT_FOUND), returned control
> mask: 0x1d
> ACPI _OSC control for PCIe not granted, disabling ASPM
> 

[Bug 50230] New: offset mapping in nexuiz results in bad texturing with the llvm compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50230

 Bug #: 50230
   Summary: offset mapping in nexuiz results in bad texturing with
the llvm compiler
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: aaalmosss at gmail.com


tested with nexuiz 2.5.2 and mesa 7a75e7d6e85d27e102ff7e15583c33b1ce282fe4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 10930] Oops on reboot with two Radeons

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=10930


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 10930] Oops on reboot with two Radeons

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=10930


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 10930] Oops on reboot with two Radeons

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=10930


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
 Regression|--- |No




--- Comment #2 from Alan   2012-05-22 12:35:00 ---
Marking obsolete, if this is incorrect please try a modern kernel, re-open and
update the kernel version

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] gpu: schedule gma500 stub driver for feature removal

[Alex Deucher]

On Mon, May 21, 2012 at 11:15 AM, Lee, Chun-Yi  
wrote:
> In v3.3, the gma500 drm driver moved from staging to drm group by
> Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
> brightness well and don't need gma500 stub driver anymore.
>
> So, my plan is remove gma500 stub driver at Dec. 2012.


December 2013?

Alex

>
> Signed-off-by: Lee, Chun-Yi 
> ---
> ?Documentation/feature-removal-schedule.txt | ? 11 +++
> ?1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/feature-removal-schedule.txt 
> b/Documentation/feature-removal-schedule.txt
> index a0ffac0..219d6f1 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -524,3 +524,14 @@ Files: ? ? arch/arm/mach-at91/at91cap9.c
> ?Why: ? The code is not actively maintained and platforms are now hard to 
> find.
> ?Who: ? Nicolas Ferre 
> ? ? ? ?Jean-Christophe PLAGNIOL-VILLARD 
> +
> +
> +
> +What: ?Intel GMA500 Stub Driver
> +When: ?December 2012
> +Why: ? In v3.3, the gma500 drm driver moved from staging to drm group by
> + ? ? ? Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
> + ? ? ? brightness well and don't need gma500 stub driver anymore.
> +
> + ? ? ? So, my plan is remove gma500 stub driver at Dec. 2012.
> +Who: ? Lee, Chun-Yi 
> --
> 1.6.0.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50208] New: X does not start on Linux kernel 3.2.0-24, works on 3.0.0-19

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50208

 Bug #: 50208
   Summary: X does not start on Linux kernel 3.2.0-24, works on
3.0.0-19
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: freedesktop at teknico.net


Created attachment 61952
  --> https://bugs.freedesktop.org/attachment.cgi?id=61952
Archive with "Xorg.log" and "dmesg" logs for both versions, and "lspci -v" and
"glxinfo" for 3.0.0-19

Operating system: Ubuntu 12.04
Linux kernel: 3.2.0-24-generic-pae
libdrm-radeon1: 2.4.32-1ubuntu1
xserver-xorg: 1:7.6+12ubuntu1
xserver-xorg-video-radeon: 1:6.14.99~git20111219.aacbd629-0ubuntu2
Notebook: Dell Studio XPS 1640
Graphics card: AMD/ATI Mobility Radeon HD3670
RAM memory size: 4GB

X does not start: after some flicker, the screen remains black.

X starts correctly, with OpenGL and DRI, with kernel 3.0.0-19-generic-pae.

Attached archive with "Xorg.log" and "dmesg" logs for both versions, and "lspci
-v" and "glxinfo" for 3.0.0-19.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #5 from Andre Heider  2012-05-22 04:36:26 
PDT ---
This looks dangerous:

1) pipe_semaphore_signal(>flush_queued);
2) pipe_semaphore_wait(>flush_completed);
3) pipe_thread_wait(cs->thread);

There's no guarantee that pipe_semaphore_signal(>flush_completed) in
radeon_drm_cs_emit_ioctl() is executed after 2).
Getting rid of 2) should fix that and it would be safe since 3) blocks until
radeon_drm_cs_emit_ioctl() returns.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

kernel 3.4.0 oops

[Daniel Vetter]

On Mon, May 21, 2012 at 07:33:10PM +0300, Andrei Popa wrote:
> Hi,
> 
> With kernel 3.4.0 and xen I got the following oops.
> 
> Grub is setup like this:
> menuentry 'vmlinuz-3.4.0' --class gnu-linux --class gnu --class os {
> insmod part_gpt
> insmod ext2
> set root='(/dev/sda,gpt2)'
> search --no-floppy --fs-uuid --set=root
> 56f0f4f0-eb04-438a-97e4-c955e4b34137
> multiboot /boot/xen.gz
> module /boot/vmlinuz-3.4.0 root=/dev/sda2 ro
> libahci.ignore_sss=1 quiet rootfstype=ext4 acpi_sleep=s3_bios
> usbcore.autosuspend=1 i915.i915_enable_rc6=1 rootdelay=1 fastboot
> resume=/dev/sdb2 resume2=/dev/sdb2 raid=noautodetect
> }
> 
> [ cut here ]
> WARNING: at drivers/gpu/drm/i915/i915_gem.c:2410
> i915_gem_object_put_fence+0x9c/0xb0()
> Hardware name: HP ProBook 4320s
> Modules linked in: rt2800pci eeprom_93cx6 rt2x00pci rt2800lib rt2x00lib
> mac80211 psmouse cfg80211 r8169
> Pid: 1034, comm: X Not tainted 3.4.0 #2
> Call Trace:
> [] ? warn_slowpath_common+0x7b/0xc0
> [] ? i915_gem_object_put_fence+0x9c/0xb0
> [] ? i915_gem_object_unbind+0x91/0x1f0
> [] ? i915_gem_free_object_tail+0x19/0xc0
> [] ? intel_user_framebuffer_destroy+0x68/0x70
> [] ? drm_fb_release+0x73/0x90
> [] ? drm_release+0x5c8/0x6f0
> [] ? _raw_spin_lock+0x14/0x20
> [] ? fput+0xdd/0x260
> [] ? filp_close+0x5f/0x90
> [] ? put_files_struct+0xbd/0x140
> [] ? call_rwsem_wake+0x17/0x30
> [] ? do_exit+0x684/0x8e0
> [] ? _raw_spin_lock+0x14/0x20
> [] ? dput+0x198/0x1a0
> [] ? vfsmount_lock_local_lock+0x24/0x30
> [] ? do_group_exit+0x53/0xc0
> [] ? sys_exit_group+0x12/0x20
> [] ? error_exit+0x2a/0x60
> [] ? system_call_fastpath+0x16/0x1b
> ---[ end trace 73252172cb6d3543 ]---

Can you please attach the complete dmesg that contains this WARN
backtrace? Depending upon how we ended up here, we should get more stuff
(which would be pretty important to know to correctly diagnose the bug).
-Daniel

> 
> 
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 3.4.0 Kernel Configuration
> #
> CONFIG_64BIT=y
> # CONFIG_X86_32 is not set
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_HAVE_LATENCYTOP_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> # CONFIG_RWSEM_GENERIC_SPINLOCK is not set
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_DEFAULT_IDLE=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_X86_HT=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi
> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9
> -fcall-saved-r10 -fcall-saved-r11"
> # CONFIG_KTIME_SCALAR is not set
> CONFIG_ARCH_CPU_PROBE_RELEASE=y
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_HAVE_IRQ_WORK=y
> CONFIG_IRQ_WORK=y
> 
> #
> # General setup
> #
> CONFIG_EXPERIMENTAL=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> CONFIG_LOCALVERSION=""
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_BSD_PROCESS_ACCT_V3=y
> CONFIG_FHANDLE=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_GENERIC_HARDIRQS=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> 
> #
> # RCU Subsystem
> #
> CONFIG_TREE_PREEMPT_RCU=y
> CONFIG_PREEMPT_RCU=y
> CONFIG_RCU_FANOUT=32
> # CONFIG_RCU_FANOUT_EXACT is not set
> CONFIG_RCU_FAST_NO_HZ=y
> # CONFIG_TREE_RCU_TRACE 

[PATCH 2/2] pcm038 lcdc support

[Dave Airlie]

On Fri, May 18, 2012 at 4:13 PM, Sascha Hauer  wrote:
> On Fri, May 18, 2012 at 10:03:54AM -0400, Adam Jackson wrote:
>> On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote:
>>
>> > + ? ? ? ? ? ? ? ? ? edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 11 50 54
>> > +
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? /* est timings */
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00 00
>> > +
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? /* std timings */
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00
>> > +
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? /* detailed timings */
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 
>> > 00 00 1E
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 
>> > 20 20 20
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 
>> > 0a 20 20
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 
>> > 0a 20 20
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? 00 20];
>>
>> This EDID block claims to be a Samsung SyncMaster, which isn't really
>> the right thing to do. ?The question is what to call it instead. ?Red
>> Hat has a PNP ID we can use for virtual EDID blocks like this if we
>> want, I'd want to set up a little database to keep track of them but
>> that's pretty trivial.
>
> Sorry, should have mentioned this in the commit log. This in fact is a
> hacked version of my office monitor. This patch is more meant as a usage
> example and not for upstream. I don't know yet if it's even acceptable
> to put edid data into the devicetree. I saw some discussion about it,
> but also about some generic display description, which I would prefer.
>
> BTW is there a more convenient tool than a hex editor around to generate
> edid data? I only found some windows tools

Some basic stuff in Documentation/EDID/ but yeah don't know of
anything graphical for Linux.

Dave.

kernel 3.4.0 oops

[Chris Wilson]

On Tue, 22 May 2012 11:20:44 +0200, Daniel Vetter  wrote:
> On Mon, May 21, 2012 at 07:33:10PM +0300, Andrei Popa wrote:
> > Hi,
> > 
> > With kernel 3.4.0 and xen I got the following oops.
> > 
> > Grub is setup like this:
> > menuentry 'vmlinuz-3.4.0' --class gnu-linux --class gnu --class os {
> > insmod part_gpt
> > insmod ext2
> > set root='(/dev/sda,gpt2)'
> > search --no-floppy --fs-uuid --set=root
> > 56f0f4f0-eb04-438a-97e4-c955e4b34137
> > multiboot /boot/xen.gz
> > module /boot/vmlinuz-3.4.0 root=/dev/sda2 ro
> > libahci.ignore_sss=1 quiet rootfstype=ext4 acpi_sleep=s3_bios
> > usbcore.autosuspend=1 i915.i915_enable_rc6=1 rootdelay=1 fastboot
> > resume=/dev/sdb2 resume2=/dev/sdb2 raid=noautodetect
> > }
> > 
> > [ cut here ]
> > WARNING: at drivers/gpu/drm/i915/i915_gem.c:2410
> > i915_gem_object_put_fence+0x9c/0xb0()
> > Hardware name: HP ProBook 4320s
> > Modules linked in: rt2800pci eeprom_93cx6 rt2x00pci rt2800lib rt2x00lib
> > mac80211 psmouse cfg80211 r8169
> > Pid: 1034, comm: X Not tainted 3.4.0 #2
> > Call Trace:
> > [] ? warn_slowpath_common+0x7b/0xc0
> > [] ? i915_gem_object_put_fence+0x9c/0xb0
> > [] ? i915_gem_object_unbind+0x91/0x1f0
> > [] ? i915_gem_free_object_tail+0x19/0xc0
> > [] ? intel_user_framebuffer_destroy+0x68/0x70
> > [] ? drm_fb_release+0x73/0x90
> > [] ? drm_release+0x5c8/0x6f0
> > [] ? _raw_spin_lock+0x14/0x20
> > [] ? fput+0xdd/0x260
> > [] ? filp_close+0x5f/0x90
> > [] ? put_files_struct+0xbd/0x140
> > [] ? call_rwsem_wake+0x17/0x30
> > [] ? do_exit+0x684/0x8e0
> > [] ? _raw_spin_lock+0x14/0x20
> > [] ? dput+0x198/0x1a0
> > [] ? vfsmount_lock_local_lock+0x24/0x30
> > [] ? do_group_exit+0x53/0xc0
> > [] ? sys_exit_group+0x12/0x20
> > [] ? error_exit+0x2a/0x60
> > [] ? system_call_fastpath+0x16/0x1b
> > ---[ end trace 73252172cb6d3543 ]---
> 
> Can you please attach the complete dmesg that contains this WARN
> backtrace? Depending upon how we ended up here, we should get more stuff
> (which would be pretty important to know to correctly diagnose the bug).

I think I encountered this bug whilst developing "drm/i915:
Asynchronously unpin the old framebuffer after the next vblank". Try

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index afab263..9b94871 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1865,6 +1865,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
goto err_unpin;

i915_gem_object_pin_fence(obj);
+   drm_gem_object_reference(>base);

dev_priv->mm.interruptible = true;
return 0;
@@ -1880,6 +1881,7 @@ void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
 {
i915_gem_object_unpin_fence(obj);
i915_gem_object_unpin(obj);
+   drm_gem_object_unreference(>base);
 }
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

m.b.lankhorst at gmail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from m.b.lankhorst at gmail.com 2012-05-22 03:26:10 PDT ---
Woops, looks like I just did overkill.

pthread_detach is not needed after a pthread_join, so just remove the
pipe_thread_destroy call.

I was probably looking at win32 too much at the time, where a thread handle has
to be closed after you wait for the thread to terminate.

I posted the patch to mesa-dev, but in any case shouldn't libpthread be at
least handling this slightly more gracefully than a crash?

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 2239059..168f455 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -469,7 +469,6 @@ static void radeon_drm_cs_destroy(struct radeon_winsys_cs
*rcs)
 pipe_semaphore_signal(>flush_queued);
 pipe_semaphore_wait(>flush_completed);
 pipe_thread_wait(cs->thread);
-pipe_thread_destroy(cs->thread);
 }
 pipe_semaphore_destroy(>flush_queued);
 pipe_semaphore_destroy(>flush_completed);

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

Michel D?nzer  changed:

   What|Removed |Added

 CC||m.b.lankhorst at gmail.com
  Component|Drivers/DRI/R600|Drivers/Gallium/r600

--- Comment #3 from Michel D?nzer  2012-05-22 03:11:05 
PDT ---
Maarten, any ideas?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #2 from Karl Tomlinson  2012-05-22 
02:50:17 PDT ---
Bisection gives good: 3b3d2e53bc11f9b5fbda812953700b216cd8ab93
bad:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=210ddf0819b5acf87a614214b6d4b02193aafa4a

(Bug still exists in git 8a933e36d1f91d3b8a5377a8d23c2dcdd403e8ad.)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50149] Faulty shaders on RS600

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50149

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #61932|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Intel-gfx] [PATCH 2/4] drm/i915: clarify preferred sdvo input mode code

[Daniel Vetter]

On Tue, Apr 10, 2012 at 01:18:13PM +0100, Chris Wilson wrote:
> On Tue, 10 Apr 2012 13:55:47 +0200, Daniel Vetter  
> wrote:
> > - kill intel_sdvo->input_dtd, it's only used as a temporary variable,
> >   we store the preferred input mode in the adjusted mode at mode_fixup
> >   time.
> > - rename the function to make it clear what we want it to do (get the
> >   preferred mode) and say in a comment what it unfortunately does as a
> >   side-effect (set the new output timings).
> > 
> > Signed-Off-by: Daniel Vetter 
> 
> Patches 2-4: Reviewed-by: Chris Wilson 
I've queued patches 2&3 for -next, thanks for the review. I'll propably
redo patch 4 with the new constants once the interlaced fixup is merged
back into -next.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[RFC v2 5/5] drm: Add NVIDIA Tegra support

[Terje Bergström]

On 21.05.2012 16:58, Thierry Reding wrote:

> I agree that reflecting the hardware hierarchy within the device tree makes
> sense. I'll need to add some code to tear down child devices in the cleanup
> path, but that shouldn't be too difficult.
> 
> However, adding a whole bus_type implementation would pretty much duplicate
> the platform bus code. I guess host1x could just provide struct host1x_client
> a set of corresponding APIs to create them, request channels, etc.


Hi,

There is a reason for existence of bus_type in Linux kernel. It exposes
the various busses to developers, and give a framework for drivers to
work in. It just makes the drivers easier to develop, and makes the big
picture easier to understand.

The problem is that bus_type is cumbersome to implement, and most
implementations seem to duplicate significant amount of code from
platform bus. This is the problem that we should tackle.

If I manage to get the boilerplate code in nvhost for bus_type small
enough, that's the structure we should use. If bus_type is just
inherently fat and broken, I'll need to migrate nvhost away from it.

Terje

[PATCH] backlight: initialize struct backlight_properties properly

[Jingoo Han]

On Mon, May 21, 2012 at 04:25 PM +, Corentin Chary wrote:

> 
> In all these files, the .power field was never correctly initialized.
> 
> Signed-off-by: Corentin Chary 

It looks good.

Best regards,
Jingoo Han

> ---
>  drivers/gpu/drm/i915/intel_panel.c  |1 +
>  drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
>  drivers/platform/x86/toshiba_acpi.c |1 +
>  drivers/video/backlight/da903x_bl.c |1 +
>  drivers/video/backlight/pcf50633-backlight.c|1 +
>  drivers/video/backlight/wm831x_bl.c |1 +
>  drivers/video/omap2/displays/panel-acx565akm.c  |1 +
>  7 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index 48177ec..ec4a1e0 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
>   else
>   return -ENODEV;
> 
> + memset(, 0, sizeof(props));
>   props.type = BACKLIGHT_RAW;
>   props.max_brightness = intel_panel_get_max_backlight(dev);
>   dev_priv->backlight =
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 42db254..a0c8222 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -369,6 +369,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder 
> *radeon_encoder,
>   goto error;
>   }
> 
> + memset(, 0, sizeof(props));
>   props.max_brightness = MAX_RADEON_LEVEL;
>   props.type = BACKLIGHT_RAW;
>   bd = backlight_device_register("radeon_bl", _connector->kdev,
> diff --git a/drivers/platform/x86/toshiba_acpi.c 
> b/drivers/platform/x86/toshiba_acpi.c
> index bde32de..d680bb2 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -1095,6 +1095,7 @@ static int __devinit 
> toshiba_acpi_setup_backlight(struct toshiba_acpi_dev *dev)
>   ret = get_tr_backlight_status(dev, );
>   dev->tr_backlight_supported = !ret;
> 
> + memset(, 0, sizeof(props));
>   props.type = BACKLIGHT_PLATFORM;
>   props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
> 
> diff --git a/drivers/video/backlight/da903x_bl.c 
> b/drivers/video/backlight/da903x_bl.c
> index 30e1968..573c7ec 100644
> --- a/drivers/video/backlight/da903x_bl.c
> +++ b/drivers/video/backlight/da903x_bl.c
> @@ -136,6 +136,7 @@ static int da903x_backlight_probe(struct platform_device 
> *pdev)
>   da903x_write(data->da903x_dev, DA9034_WLED_CONTROL2,
>   DA9034_WLED_ISET(pdata->output_current));
> 
> + memset(, 0, sizeof(props));
>   props.type = BACKLIGHT_RAW;
>   props.max_brightness = max_brightness;
>   bl = backlight_device_register(pdev->name, data->da903x_dev, data,
> diff --git a/drivers/video/backlight/pcf50633-backlight.c 
> b/drivers/video/backlight/pcf50633-backlight.c
> index c65853c..c092159 100644
> --- a/drivers/video/backlight/pcf50633-backlight.c
> +++ b/drivers/video/backlight/pcf50633-backlight.c
> @@ -111,6 +111,7 @@ static int __devinit pcf50633_bl_probe(struct 
> platform_device *pdev)
>   if (!pcf_bl)
>   return -ENOMEM;
> 
> + memset(_props, 0, sizeof(bl_props));
>   bl_props.type = BACKLIGHT_RAW;
>   bl_props.max_brightness = 0x3f;
>   bl_props.power = FB_BLANK_UNBLANK;
> diff --git a/drivers/video/backlight/wm831x_bl.c 
> b/drivers/video/backlight/wm831x_bl.c
> index 5d365de..9e5517a 100644
> --- a/drivers/video/backlight/wm831x_bl.c
> +++ b/drivers/video/backlight/wm831x_bl.c
> @@ -194,6 +194,7 @@ static int wm831x_backlight_probe(struct platform_device 
> *pdev)
>   data->current_brightness = 0;
>   data->isink_reg = isink_reg;
> 
> + memset(, 0, sizeof(props));
>   props.type = BACKLIGHT_RAW;
>   props.max_brightness = max_isel;
>   bl = backlight_device_register("wm831x", >dev, data,
> diff --git a/drivers/video/omap2/displays/panel-acx565akm.c 
> b/drivers/video/omap2/displays/panel-
> acx565akm.c
> index d26f37a..74e7cf0 100644
> --- a/drivers/video/omap2/displays/panel-acx565akm.c
> +++ b/drivers/video/omap2/displays/panel-acx565akm.c
> @@ -532,6 +532,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
> 
>   /*--- Backlight control */
> 
> + memset(, 0, sizeof(props));
>   props.fb_blank = FB_BLANK_UNBLANK;
>   props.power = FB_BLANK_UNBLANK;
>   props.type = BACKLIGHT_RAW;
> --
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] nouveau_drv.c: notify when KMS is disabled

[Arvydas Sidorenko]

On nouveau init whenever VGA fallback is used no notification is given
in dmesg.

Signed-off-by: Arvydas Sidorenko 
---
 drivers/gpu/drm/nouveau/nouveau_drv.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 4f2030b..ea90d60 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -473,8 +473,10 @@ static int __init nouveau_init(void)
nouveau_modeset = 1;
}

-   if (!nouveau_modeset)
+   if (!nouveau_modeset) {
+   DRM_INFO("nouveau KMS disabled");
return 0;
+   }

nouveau_register_dsm_handler();
return drm_pci_init(, _pci_driver);
-- 
1.7.8.6

[Bug 42984] scrabled video with nouveau drivers on mac mini (320m)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42984





--- Comment #14 from garegin   2012-05-22 01:13:00 ---
it's not dithering. the whole image is garbled. it's not a line pattern.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[RFC v2 5/5] drm: Add NVIDIA Tegra support

[Jon Mayo]

On Wed, Apr 25, 2012 at 2:45 AM, Thierry Reding
 wrote:
> This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> currently has rudimentary GEM support and can run a console on the
> framebuffer as well as X using the xf86-video-modesetting driver. Only
> the RGB output is supported.
>
> HDMI support was taken from NVIDIA's Linux kernel tree but it doesn't
> quite work. EDID data can be retrieved but the output doesn't properly
> activate the connected TV.
>
> The DSI and TVO outputs and the HOST1X driver are just stubs that setup
> the corresponding resources but don't do anything useful yet.
>

Nice work Thierry, I'm happy with the display programming bits. I
think the pll_p enable/disable problem with RGB is better fixed when
we have some fancier clock infrastructure. I have some ideas how it
could be fixed now, but given that I want to see pll_p or pll_d /
pll_d2 selected automatically based on final clock, I'd rather hold
off on fixing things that are not really broken that going to be
replaced anyways. You can save a little power by leaving D pll's off,
and the logic to do it isn't hard and fairly safe to hard code into
the driver instead of trying to represent it in DT. (FYI - pll_d2 is a
Tegra3 feature, this way you can do things like run DSI and HDMI with
low jitter, instead of trying to take over pll_c for HDMI, which
deprives other modules of the clock freedom)

I have more DSI devices on Tegra3 than on Tegra2, so I'm putting
Tegra3 support near the top of my TODO list, because in my mind
getting forward progress on DSI support depends on it. HDMI
programming is not too tough, it's mostly loading calibrated magic
values into some SOR registers. The values are different for T20 and
T30 series (same fields, just needed different calibration).

--
"If you give someone a program, you will frustrate them for a day; if
you teach them how to program, you will frustrate them for a
lifetime." ? David Leinweber

[PATCH] gpu: schedule gma500 stub driver for feature removal

[Lee, Chun-Yi]

In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.

So, my plan is remove gma500 stub driver at Dec. 2012.

Cc: randy.dunlap at oracle.com
Cc: mjg59 at srcf.ucam.org
Cc: gregkh at suse.de
Cc: trenn at suse.de
Cc: Valdis.Kletnieks at vt.edu
Cc: Dennis.Jansen at web.de
Cc: airlied at redhat.com
Cc: eric at anholt.net
Cc: alexdeucher at gmail.com
Cc: bskeggs at redhat.com
Cc: chris at chris-wilson.co.uk
Signed-off-by: Lee, Chun-Yi 
---
 Documentation/feature-removal-schedule.txt |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index a0ffac0..219d6f1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c
 Why:   The code is not actively maintained and platforms are now hard to find.
 Who:   Nicolas Ferre 
Jean-Christophe PLAGNIOL-VILLARD 
+
+
+
+What:  Intel GMA500 Stub Driver
+When:  December 2012
+Why:   In v3.3, the gma500 drm driver moved from staging to drm group by
+   Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
+   brightness well and don't need gma500 stub driver anymore.
+
+   So, my plan is remove gma500 stub driver at Dec. 2012.
+Who:   Lee, Chun-Yi 
-- 
1.6.0.2

[PATCH] gpu: schedule gma500 stub driver for feature removal

[Lee, Chun-Yi]

In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.

So, my plan is remove gma500 stub driver at Dec. 2012.

Signed-off-by: Lee, Chun-Yi 
---
 Documentation/feature-removal-schedule.txt |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index a0ffac0..219d6f1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c
 Why:   The code is not actively maintained and platforms are now hard to find.
 Who:   Nicolas Ferre 
Jean-Christophe PLAGNIOL-VILLARD 
+
+
+
+What:  Intel GMA500 Stub Driver
+When:  December 2012
+Why:   In v3.3, the gma500 drm driver moved from staging to drm group by
+   Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
+   brightness well and don't need gma500 stub driver anymore.
+
+   So, my plan is remove gma500 stub driver at Dec. 2012.
+Who:   Lee, Chun-Yi 
-- 
1.6.0.2

Re: [Intel-gfx] [PATCH 2/4] drm/i915: clarify preferred sdvo input mode code

[Daniel Vetter]

On Tue, Apr 10, 2012 at 01:18:13PM +0100, Chris Wilson wrote:
 On Tue, 10 Apr 2012 13:55:47 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
  - kill intel_sdvo-input_dtd, it's only used as a temporary variable,
we store the preferred input mode in the adjusted mode at mode_fixup
time.
  - rename the function to make it clear what we want it to do (get the
preferred mode) and say in a comment what it unfortunately does as a
side-effect (set the new output timings).
  
  Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 Patches 2-4: Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
I've queued patches 23 for -next, thanks for the review. I'll propably
redo patch 4 with the new constants once the interlaced fixup is merged
back into -next.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: schedule gma500 stub driver for feature removal

[Lee, Chun-Yi]

In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.

So, my plan is remove gma500 stub driver at Dec. 2012.

Signed-off-by: Lee, Chun-Yi j...@suse.com
---
 Documentation/feature-removal-schedule.txt |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index a0ffac0..219d6f1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c
 Why:   The code is not actively maintained and platforms are now hard to find.
 Who:   Nicolas Ferre nicolas.fe...@atmel.com
Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+
+
+
+What:  Intel GMA500 Stub Driver
+When:  December 2012
+Why:   In v3.3, the gma500 drm driver moved from staging to drm group by
+   Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
+   brightness well and don't need gma500 stub driver anymore.
+
+   So, my plan is remove gma500 stub driver at Dec. 2012.
+Who:   Lee, Chun-Yi j...@novell.com
-- 
1.6.0.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: schedule gma500 stub driver for feature removal

[Lee, Chun-Yi]

In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.

So, my plan is remove gma500 stub driver at Dec. 2012.

Cc: randy.dun...@oracle.com
Cc: mj...@srcf.ucam.org
Cc: gre...@suse.de
Cc: tr...@suse.de
Cc: valdis.kletni...@vt.edu
Cc: dennis.jan...@web.de
Cc: airl...@redhat.com
Cc: e...@anholt.net
Cc: alexdeuc...@gmail.com
Cc: bske...@redhat.com
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
 Documentation/feature-removal-schedule.txt |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index a0ffac0..219d6f1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c
 Why:   The code is not actively maintained and platforms are now hard to find.
 Who:   Nicolas Ferre nicolas.fe...@atmel.com
Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+
+
+
+What:  Intel GMA500 Stub Driver
+When:  December 2012
+Why:   In v3.3, the gma500 drm driver moved from staging to drm group by
+   Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
+   brightness well and don't need gma500 stub driver anymore.
+
+   So, my plan is remove gma500 stub driver at Dec. 2012.
+Who:   Lee, Chun-Yi j...@novell.com
-- 
1.6.0.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] backlight: initialize struct backlight_properties properly

[Jingoo Han]

On Mon, May 21, 2012 at 04:25 PM +, Corentin Chary wrote:

 
 In all these files, the .power field was never correctly initialized.
 
 Signed-off-by: Corentin Chary corentin.ch...@gmail.com

It looks good.

Best regards,
Jingoo Han

 ---
  drivers/gpu/drm/i915/intel_panel.c  |1 +
  drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
  drivers/platform/x86/toshiba_acpi.c |1 +
  drivers/video/backlight/da903x_bl.c |1 +
  drivers/video/backlight/pcf50633-backlight.c|1 +
  drivers/video/backlight/wm831x_bl.c |1 +
  drivers/video/omap2/displays/panel-acx565akm.c  |1 +
  7 files changed, 7 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_panel.c 
 b/drivers/gpu/drm/i915/intel_panel.c
 index 48177ec..ec4a1e0 100644
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
   else
   return -ENODEV;
 
 + memset(props, 0, sizeof(props));
   props.type = BACKLIGHT_RAW;
   props.max_brightness = intel_panel_get_max_backlight(dev);
   dev_priv-backlight =
 diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
 b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
 index 42db254..a0c8222 100644
 --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
 +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
 @@ -369,6 +369,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder 
 *radeon_encoder,
   goto error;
   }
 
 + memset(props, 0, sizeof(props));
   props.max_brightness = MAX_RADEON_LEVEL;
   props.type = BACKLIGHT_RAW;
   bd = backlight_device_register(radeon_bl, drm_connector-kdev,
 diff --git a/drivers/platform/x86/toshiba_acpi.c 
 b/drivers/platform/x86/toshiba_acpi.c
 index bde32de..d680bb2 100644
 --- a/drivers/platform/x86/toshiba_acpi.c
 +++ b/drivers/platform/x86/toshiba_acpi.c
 @@ -1095,6 +1095,7 @@ static int __devinit 
 toshiba_acpi_setup_backlight(struct toshiba_acpi_dev *dev)
   ret = get_tr_backlight_status(dev, enabled);
   dev-tr_backlight_supported = !ret;
 
 + memset(props, 0, sizeof(props));
   props.type = BACKLIGHT_PLATFORM;
   props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
 
 diff --git a/drivers/video/backlight/da903x_bl.c 
 b/drivers/video/backlight/da903x_bl.c
 index 30e1968..573c7ec 100644
 --- a/drivers/video/backlight/da903x_bl.c
 +++ b/drivers/video/backlight/da903x_bl.c
 @@ -136,6 +136,7 @@ static int da903x_backlight_probe(struct platform_device 
 *pdev)
   da903x_write(data-da903x_dev, DA9034_WLED_CONTROL2,
   DA9034_WLED_ISET(pdata-output_current));
 
 + memset(props, 0, sizeof(props));
   props.type = BACKLIGHT_RAW;
   props.max_brightness = max_brightness;
   bl = backlight_device_register(pdev-name, data-da903x_dev, data,
 diff --git a/drivers/video/backlight/pcf50633-backlight.c 
 b/drivers/video/backlight/pcf50633-backlight.c
 index c65853c..c092159 100644
 --- a/drivers/video/backlight/pcf50633-backlight.c
 +++ b/drivers/video/backlight/pcf50633-backlight.c
 @@ -111,6 +111,7 @@ static int __devinit pcf50633_bl_probe(struct 
 platform_device *pdev)
   if (!pcf_bl)
   return -ENOMEM;
 
 + memset(bl_props, 0, sizeof(bl_props));
   bl_props.type = BACKLIGHT_RAW;
   bl_props.max_brightness = 0x3f;
   bl_props.power = FB_BLANK_UNBLANK;
 diff --git a/drivers/video/backlight/wm831x_bl.c 
 b/drivers/video/backlight/wm831x_bl.c
 index 5d365de..9e5517a 100644
 --- a/drivers/video/backlight/wm831x_bl.c
 +++ b/drivers/video/backlight/wm831x_bl.c
 @@ -194,6 +194,7 @@ static int wm831x_backlight_probe(struct platform_device 
 *pdev)
   data-current_brightness = 0;
   data-isink_reg = isink_reg;
 
 + memset(props, 0, sizeof(props));
   props.type = BACKLIGHT_RAW;
   props.max_brightness = max_isel;
   bl = backlight_device_register(wm831x, pdev-dev, data,
 diff --git a/drivers/video/omap2/displays/panel-acx565akm.c 
 b/drivers/video/omap2/displays/panel-
 acx565akm.c
 index d26f37a..74e7cf0 100644
 --- a/drivers/video/omap2/displays/panel-acx565akm.c
 +++ b/drivers/video/omap2/displays/panel-acx565akm.c
 @@ -532,6 +532,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
 
   /*--- Backlight control */
 
 + memset(props, 0, sizeof(props));
   props.fb_blank = FB_BLANK_UNBLANK;
   props.power = FB_BLANK_UNBLANK;
   props.type = BACKLIGHT_RAW;
 --
 1.7.9.5
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-fbdev in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau_drv.c: notify when KMS is disabled

[Arvydas Sidorenko]

On nouveau init whenever VGA fallback is used no notification is given
in dmesg.

Signed-off-by: Arvydas Sidorenko asi...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_drv.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 4f2030b..ea90d60 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -473,8 +473,10 @@ static int __init nouveau_init(void)
nouveau_modeset = 1;
}
 
-   if (!nouveau_modeset)
+   if (!nouveau_modeset) {
+   DRM_INFO(nouveau KMS disabled);
return 0;
+   }
 
nouveau_register_dsm_handler();
return drm_pci_init(driver, nouveau_pci_driver);
-- 
1.7.8.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support

[Terje Bergström]

On 21.05.2012 16:58, Thierry Reding wrote:

 I agree that reflecting the hardware hierarchy within the device tree makes
 sense. I'll need to add some code to tear down child devices in the cleanup
 path, but that shouldn't be too difficult.
 
 However, adding a whole bus_type implementation would pretty much duplicate
 the platform bus code. I guess host1x could just provide struct host1x_client
 a set of corresponding APIs to create them, request channels, etc.


Hi,

There is a reason for existence of bus_type in Linux kernel. It exposes
the various busses to developers, and give a framework for drivers to
work in. It just makes the drivers easier to develop, and makes the big
picture easier to understand.

The problem is that bus_type is cumbersome to implement, and most
implementations seem to duplicate significant amount of code from
platform bus. This is the problem that we should tackle.

If I manage to get the boilerplate code in nvhost for bus_type small
enough, that's the structure we should use. If bus_type is just
inherently fat and broken, I'll need to migrate nvhost away from it.

Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support

[Jon Mayo]

On Wed, Apr 25, 2012 at 2:45 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
 This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
 currently has rudimentary GEM support and can run a console on the
 framebuffer as well as X using the xf86-video-modesetting driver. Only
 the RGB output is supported.

 HDMI support was taken from NVIDIA's Linux kernel tree but it doesn't
 quite work. EDID data can be retrieved but the output doesn't properly
 activate the connected TV.

 The DSI and TVO outputs and the HOST1X driver are just stubs that setup
 the corresponding resources but don't do anything useful yet.


Nice work Thierry, I'm happy with the display programming bits. I
think the pll_p enable/disable problem with RGB is better fixed when
we have some fancier clock infrastructure. I have some ideas how it
could be fixed now, but given that I want to see pll_p or pll_d /
pll_d2 selected automatically based on final clock, I'd rather hold
off on fixing things that are not really broken that going to be
replaced anyways. You can save a little power by leaving D pll's off,
and the logic to do it isn't hard and fairly safe to hard code into
the driver instead of trying to represent it in DT. (FYI - pll_d2 is a
Tegra3 feature, this way you can do things like run DSI and HDMI with
low jitter, instead of trying to take over pll_c for HDMI, which
deprives other modules of the clock freedom)

I have more DSI devices on Tegra3 than on Tegra2, so I'm putting
Tegra3 support near the top of my TODO list, because in my mind
getting forward progress on DSI support depends on it. HDMI
programming is not too tough, it's mostly loading calibrated magic
values into some SOR registers. The values are different for T20 and
T30 series (same fields, just needed different calibration).

--
If you give someone a program, you will frustrate them for a day; if
you teach them how to program, you will frustrate them for a
lifetime. — David Leinweber
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] backlight: initialize struct backlight_properties properly

[Dave Airlie]

On Mon, May 21, 2012 at 8:24 AM, Corentin Chary
corentin.ch...@gmail.com wrote:
 In all these files, the .power field was never correctly initialized.

 Signed-off-by: Corentin Chary corentin.ch...@gmail.com
 ---
  drivers/gpu/drm/i915/intel_panel.c              |    1 +
  drivers/gpu/drm/radeon/radeon_legacy_encoders.c |    1 +

I've taken these two hunks into drm-next.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Initial DisplayPort OUI probing

[Dave Airlie]

On Mon, May 14, 2012 at 9:05 PM, Adam Jackson a...@redhat.com wrote:
 DisplayPort has an escape hatch by which devices can identify each other.
 I'm not super thrilled that it does, since that's just a clever way of
 getting the spec to explicitly bless interoperability bugs.  But it may
 be useful information when debugging link training problems, and there's
 a cute trick you can do on iMacs that I think will require knowing this
 information, so we may as well fill it in.

 Tested on a Lenovo T500 against a DP-VGA adaptor (which turns out to be
 an ST Microelectronics chip, who knew) and an HP LP2480zx (which does
 not advertise OUI support, but also harmlessly returns 0s for the OUI
 registers if you read them anyway).

I've taken this after I fixed nouveau compile you missed a struct on
the probe function,

So hopefully someone on nouveau + DP can see it works.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: kernel 3.4.0 oops

[Chris Wilson]

On Tue, 22 May 2012 11:20:44 +0200, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, May 21, 2012 at 07:33:10PM +0300, Andrei Popa wrote:
  Hi,
  
  With kernel 3.4.0 and xen I got the following oops.
  
  Grub is setup like this:
  menuentry 'vmlinuz-3.4.0' --class gnu-linux --class gnu --class os {
  insmod part_gpt
  insmod ext2
  set root='(/dev/sda,gpt2)'
  search --no-floppy --fs-uuid --set=root
  56f0f4f0-eb04-438a-97e4-c955e4b34137
  multiboot /boot/xen.gz
  module /boot/vmlinuz-3.4.0 root=/dev/sda2 ro
  libahci.ignore_sss=1 quiet rootfstype=ext4 acpi_sleep=s3_bios
  usbcore.autosuspend=1 i915.i915_enable_rc6=1 rootdelay=1 fastboot
  resume=/dev/sdb2 resume2=/dev/sdb2 raid=noautodetect
  }
  
  [ cut here ]
  WARNING: at drivers/gpu/drm/i915/i915_gem.c:2410
  i915_gem_object_put_fence+0x9c/0xb0()
  Hardware name: HP ProBook 4320s
  Modules linked in: rt2800pci eeprom_93cx6 rt2x00pci rt2800lib rt2x00lib
  mac80211 psmouse cfg80211 r8169
  Pid: 1034, comm: X Not tainted 3.4.0 #2
  Call Trace:
  [8107ae0b] ? warn_slowpath_common+0x7b/0xc0
  [814629dc] ? i915_gem_object_put_fence+0x9c/0xb0
  [81463e81] ? i915_gem_object_unbind+0x91/0x1f0
  [81463ff9] ? i915_gem_free_object_tail+0x19/0xc0
  [8146faa8] ? intel_user_framebuffer_destroy+0x68/0x70
  [8144e1d3] ? drm_fb_release+0x73/0x90
  [8143f888] ? drm_release+0x5c8/0x6f0
  [817cb654] ? _raw_spin_lock+0x14/0x20
  [8112c9bd] ? fput+0xdd/0x260
  [81128d8f] ? filp_close+0x5f/0x90
  [8107e5cd] ? put_files_struct+0xbd/0x140
  [81372787] ? call_rwsem_wake+0x17/0x30
  [8107edc4] ? do_exit+0x684/0x8e0
  [817cb654] ? _raw_spin_lock+0x14/0x20
  [81140bf8] ? dput+0x198/0x1a0
  [811469c4] ? vfsmount_lock_local_lock+0x24/0x30
  [8107f2b3] ? do_group_exit+0x53/0xc0
  [8107f332] ? sys_exit_group+0x12/0x20
  [817cc34a] ? error_exit+0x2a/0x60
  [817cc639] ? system_call_fastpath+0x16/0x1b
  ---[ end trace 73252172cb6d3543 ]---
 
 Can you please attach the complete dmesg that contains this WARN
 backtrace? Depending upon how we ended up here, we should get more stuff
 (which would be pretty important to know to correctly diagnose the bug).

I think I encountered this bug whilst developing drm/i915:
Asynchronously unpin the old framebuffer after the next vblank. Try

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index afab263..9b94871 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1865,6 +1865,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
goto err_unpin;
 
i915_gem_object_pin_fence(obj);
+   drm_gem_object_reference(obj-base);
 
dev_priv-mm.interruptible = true;
return 0;
@@ -1880,6 +1881,7 @@ void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
 {
i915_gem_object_unpin_fence(obj);
i915_gem_object_unpin(obj);
+   drm_gem_object_unreference(obj-base);
 }
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50149] Faulty shaders on RS600

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=50149

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #61932|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #2 from Karl Tomlinson bugs.freedesk...@karlt.net 2012-05-22 
02:50:17 PDT ---
Bisection gives good: 3b3d2e53bc11f9b5fbda812953700b216cd8ab93
bad:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=210ddf0819b5acf87a614214b6d4b02193aafa4a

(Bug still exists in git 8a933e36d1f91d3b8a5377a8d23c2dcdd403e8ad.)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] pcm038 lcdc support

[Dave Airlie]

On Fri, May 18, 2012 at 4:13 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
 On Fri, May 18, 2012 at 10:03:54AM -0400, Adam Jackson wrote:
 On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote:

  +                   edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
  +                           0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
  +                           11 50 54
  +
  +                           /* est timings */
  +                           00 00 00
  +
  +                           /* std timings */
  +                           00 00
  +                           00 00
  +                           00 00
  +                           00 00
  +                           00 00
  +                           00 00
  +                           00 00
  +                           00 00
  +
  +                           /* detailed timings */
  +                           05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 
  00 00 1E
  +                           00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 
  20 20 20
  +                           00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 
  0a 20 20
  +                           00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 
  0a 20 20
  +                           00 20];

 This EDID block claims to be a Samsung SyncMaster, which isn't really
 the right thing to do.  The question is what to call it instead.  Red
 Hat has a PNP ID we can use for virtual EDID blocks like this if we
 want, I'd want to set up a little database to keep track of them but
 that's pretty trivial.

 Sorry, should have mentioned this in the commit log. This in fact is a
 hacked version of my office monitor. This patch is more meant as a usage
 example and not for upstream. I don't know yet if it's even acceptable
 to put edid data into the devicetree. I saw some discussion about it,
 but also about some generic display description, which I would prefer.

 BTW is there a more convenient tool than a hex editor around to generate
 edid data? I only found some windows tools

Some basic stuff in Documentation/EDID/ but yeah don't know of
anything graphical for Linux.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 CC||m.b.lankho...@gmail.com
  Component|Drivers/DRI/R600|Drivers/Gallium/r600

--- Comment #3 from Michel Dänzer mic...@daenzer.net 2012-05-22 03:11:05 PDT 
---
Maarten, any ideas?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

m.b.lankho...@gmail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from m.b.lankho...@gmail.com 2012-05-22 03:26:10 PDT ---
Woops, looks like I just did overkill.

pthread_detach is not needed after a pthread_join, so just remove the
pipe_thread_destroy call.

I was probably looking at win32 too much at the time, where a thread handle has
to be closed after you wait for the thread to terminate.

I posted the patch to mesa-dev, but in any case shouldn't libpthread be at
least handling this slightly more gracefully than a crash?

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 2239059..168f455 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -469,7 +469,6 @@ static void radeon_drm_cs_destroy(struct radeon_winsys_cs
*rcs)
 pipe_semaphore_signal(cs-flush_queued);
 pipe_semaphore_wait(cs-flush_completed);
 pipe_thread_wait(cs-thread);
-pipe_thread_destroy(cs-thread);
 }
 pipe_semaphore_destroy(cs-flush_queued);
 pipe_semaphore_destroy(cs-flush_completed);

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: kernel 3.4.0 oops

[Daniel Vetter]

On Tue, May 22, 2012 at 01:02:53PM +0300, Andrei Popa wrote:
 On Tue, 2012-05-22 at 11:20 +0200, Daniel Vetter wrote:
 
  Can you please attach the complete dmesg that contains this WARN
  backtrace? Depending upon how we ended up here, we should get more stuff
  (which would be pretty important to know to correctly diagnose the bug).
  -Daniel
 
 The oops happens in X(KDE) when I run:
 # xrandr -d :0 --output LVDS1 --off --noprimary
 # xrandr -d :0 --output VGA1 --mode 1280x1024 --refresh 75
 (I have a laptop and an external monitor connected to the laptop VGA
 port; with the above commands I close the laptop LCD and I only use the
 external VGA  display).

Ok, I've tried to reproduce this on my ilk here but couldn't hit the
issue. A few things:
- Your gpu dies. Please dig out the versions of mesa, libdrm and
  xf86-video-intel you're using.
- Is this a regression?
- Do you see any other bad side-effects of this besides the WARN in dmesg?
- Also, can you please enable printk timestamps with CONFIG_PRINTK_TIME
  and grab a new dmesg? The relative timings of the things going on would
  be very interesting.

Thanks, Daniel
 
 Below is dmesg output.
 3hot D3cold
 pci :00:1c.5: [8086:3b4c] type 01 class 0x060400
 pci :00:1c.5: PME# supported from D0 D3hot D3cold
 pci :00:1d.0: [8086:3b34] type 00 class 0x0c0320
 pci :00:1d.0: reg 10: [mem 0xd4908000-0xd49083ff]
 pci :00:1d.0: PME# supported from D0 D3hot D3cold
 pci :00:1e.0: [8086:2448] type 01 class 0x060401
 pci :00:1f.0: [8086:3b0b] type 00 class 0x060100
 pci :00:1f.2: [8086:3b2f] type 00 class 0x010601
 pci :00:1f.2: reg 10: [io  0x5028-0x502f]
 pci :00:1f.2: reg 14: [io  0x503c-0x503f]
 pci :00:1f.2: reg 18: [io  0x5020-0x5027]
 pci :00:1f.2: reg 1c: [io  0x5038-0x503b]
 pci :00:1f.2: reg 20: [io  0x5000-0x501f]
 pci :00:1f.2: reg 24: [mem 0xd4907000-0xd49077ff]
 pci :00:1f.2: PME# supported from D3hot
 pci :00:1f.6: [8086:3b32] type 00 class 0x118000
 pci :00:1f.6: reg 10: [mem 0xd4906000-0xd4906fff 64bit]
 pci :00:1c.0: PCI bridge to [bus 01-01]
 pci :00:1c.0:   bridge window [mem 0xd480-0xd48f]
 pci :00:1c.1: PCI bridge to [bus 02-42]
 pci :00:1c.1:   bridge window [io  0x3000-0x4fff]
 pci :00:1c.1:   bridge window [mem 0xd080-0xd47f]
 pci :43:00.0: [1814:3090] type 00 class 0x028000
 pci :43:00.0: reg 10: [mem 0xd070-0xd070]
 pci :00:1c.3: PCI bridge to [bus 43-43]
 pci :00:1c.3:   bridge window [mem 0xd070-0xd07f]
 pci :44:00.0: [10ec:8168] type 00 class 0x02
 pci :44:00.0: reg 10: [io  0x2000-0x20ff]
 pci :44:00.0: reg 18: [mem 0xd0404000-0xd0404fff 64bit pref]
 pci :44:00.0: reg 20: [mem 0xd040-0xd0403fff 64bit pref]
 pci :44:00.0: reg 30: [mem 0xfffe-0x pref]
 pci :44:00.0: supports D1 D2
 pci :44:00.0: PME# supported from D0 D1 D2 D3hot D3cold
 pci :00:1c.5: PCI bridge to [bus 44-44]
 pci :00:1c.5:   bridge window [io  0x2000-0x2fff]
 pci :00:1c.5:   bridge window [mem 0xd060-0xd06f]
 pci :00:1c.5:   bridge window [mem 0xd040-0xd04f 64bit pref]
 pci :00:1e.0: PCI bridge to [bus 45-45] (subtractive decode)
 pci :00:1e.0:   bridge window [mem 0xd050-0xd05f]
 pci :00:1e.0:   bridge window [io  0x-0x0cf7] (subtractive
 decode)
 pci :00:1e.0:   bridge window [io  0x0d00-0x] (subtractive
 decode)
 pci :00:1e.0:   bridge window [mem 0x000a-0x000b]
 (subtractive decode)
 pci :00:1e.0:   bridge window [mem 0xc000-0xdfff]
 (subtractive decode)
 pci :00:1e.0:   bridge window [mem 0xf000-0xfedf]
 (subtractive decode)
 pci :00:1e.0:   bridge window [mem 0xfee01000-0x]
 (subtractive decode)
 pci_bus :00: on NUMA node 0
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP06._PRT]
  pci:00: Requesting ACPI _OSC control (0x1d)
  pci:00: ACPI _OSC control (0x1d) granted
 ACPI: PCI Root Bridge [CPBG] (domain  [bus ff])
 PCI host bridge to bus :ff
 pci :ff:00.0: [8086:2c62] type 00 class 0x06
 pci :ff:00.1: [8086:2d01] type 00 class 0x06
 pci :ff:02.0: [8086:2d10] type 00 class 0x06
 pci :ff:02.1: [8086:2d11] type 00 class 0x06
 pci :ff:02.2: [8086:2d12] type 00 class 0x06
 pci :ff:02.3: [8086:2d13] type 00 class 0x06
 pci_bus :ff: on NUMA node 0
  pci:ff: Requesting ACPI _OSC control (0x1d)
  pci:ff: ACPI _OSC request failed (AE_NOT_FOUND), returned control
 mask: 0x1d
 ACPI _OSC control for PCIe not granted, disabling ASPM
 ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 12 14 15)
 ACPI: PCI Interrupt Link 

[Bug 49198] glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

--- Comment #5 from Andre Heider a.hei...@gmail.com 2012-05-22 04:36:26 PDT 
---
This looks dangerous:

1) pipe_semaphore_signal(cs-flush_queued);
2) pipe_semaphore_wait(cs-flush_completed);
3) pipe_thread_wait(cs-thread);

There's no guarantee that pipe_semaphore_signal(cs-flush_completed) in
radeon_drm_cs_emit_ioctl() is executed after 2).
Getting rid of 2) should fix that and it would be safe since 3) blocks until
radeon_drm_cs_emit_ioctl() returns.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50208] New: X does not start on Linux kernel 3.2.0-24, works on 3.0.0-19

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=50208

 Bug #: 50208
   Summary: X does not start on Linux kernel 3.2.0-24, works on
3.0.0-19
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: freedesk...@teknico.net


Created attachment 61952
  -- https://bugs.freedesktop.org/attachment.cgi?id=61952
Archive with Xorg.log and dmesg logs for both versions, and lspci -v and
glxinfo for 3.0.0-19

Operating system: Ubuntu 12.04
Linux kernel: 3.2.0-24-generic-pae
libdrm-radeon1: 2.4.32-1ubuntu1
xserver-xorg: 1:7.6+12ubuntu1
xserver-xorg-video-radeon: 1:6.14.99~git20111219.aacbd629-0ubuntu2
Notebook: Dell Studio XPS 1640
Graphics card: AMD/ATI Mobility Radeon HD3670
RAM memory size: 4GB

X does not start: after some flicker, the screen remains black.

X starts correctly, with OpenGL and DRI, with kernel 3.0.0-19-generic-pae.

Attached archive with Xorg.log and dmesg logs for both versions, and lspci
-v and glxinfo for 3.0.0-19.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 05/13] v4l: vb2-dma-contig: add support for DMABUF exporting

[Tomasz Stanislawski]

Hi Laurent,

Sorry for the late reply.
Thank you very much for noticing the issue.

 +static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv)
 +{
 +  struct vb2_dc_buf *buf = buf_priv;
 +  struct dma_buf *dbuf;
 +
 +  if (buf-dma_buf)
 +  return buf-dma_buf;

 Can't there be a race condition here if the user closes the DMABUF file
 handle before vb2 core calls dma_buf_fd() ?

 The user cannot access the file until it is associated with a file
 descriptor. How can the user close it? Could you give me a more detailed
 description of this potential race condition?
 
 Let's assume the V4L2 buffer has already been exported once. buf-dma_buf is 
 set to a non-NULL value, and the application has an open file handle for the 
 buffer. The application then tries to export the buffer a second time. 
 vb2_dc_get_dmabuf() gets called, checks buf-dma_buf and returns it as it's 
 non-NULL. Right after that, before the vb2 core calls dma_buf_fd() on the 
 struct dma_buf, the application closes the file handle to the exported 
 buffer. 
 The struct dma_buf object gets freed, as the reference count drops to 0.

I am not sure if reference counter drops to 0 in this case. Notice that after
first dma_buf_export the dma_buf's refcnt is 1, after first dma_buf_fd it goes
to 2. After closing a file handle the refcnt drops back to 1 so the file
(and dma_buf) is not released. Therefore IMO there no dangling pointer issue.

However it looks that there is a circular reference between vb2_dc_buf and 
dma_buf.
vb2_dc_buf::dma_buf is pointing to dma_buf with reference taken at 
dma_buf_export.
On the other hand the dma_buf-priv is pointing to vb2_dc_buf with reference
taken at atomic_inc(buf-refcount) in vb2_dc_get_dmabuf.

The circular reference leads into resource leakage.
The problem could be fixed by dropping caching of dma_buf pointer.
The new dma_buf would be created and exported at every export event.
The dma_buf_put would be called in vb2_expbuf just after
successful dma_buf_fd.

Do you have any ideas how I could deal with resource leakage/dangling problems
without creating a new dma_buf instance at every export event?

Regards,
Tomasz Stanislawski


 vb2 core will then try to call dma_buf_fd() on a dma_buf object that has been 
 freed.
 
 +  /* dmabuf keeps reference to vb2 buffer */
 +  atomic_inc(buf-refcount);
 +  dbuf = dma_buf_export(buf, vb2_dc_dmabuf_ops, buf-size, 0);
 +  if (IS_ERR(dbuf)) {
 +  atomic_dec(buf-refcount);
 +  return NULL;
 +  }
 +
 +  buf-dma_buf = dbuf;
 +
 +  return dbuf;
 +}
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 10930] Oops on reboot with two Radeons

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=10930


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk
 Regression|--- |No




--- Comment #2 from Alan a...@lxorguk.ukuu.org.uk  2012-05-22 12:35:00 ---
Marking obsolete, if this is incorrect please try a modern kernel, re-open and
update the kernel version

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 10930] Oops on reboot with two Radeons

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=10930


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 10930] Oops on reboot with two Radeons

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=10930


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: add initial vmap documentation

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

Signed-off-by: Dave Airlie airl...@redhat.com
---
 Documentation/dma-buf-sharing.txt |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 3bbd5c5..98e9fa0 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -300,6 +300,17 @@ Access to a dma_buf from the kernel context involves three 
steps:
Note that these calls need to always succeed. The exporter needs to complete
any preparations that might fail in begin_cpu_access.
 
+   For some circumstances the overhead of kmap can be too high, a vmap 
interface
+   is introduced. This interface shouldn't be used very carefully, as vmalloc
+   space is a limited resources on many architectures.
+
+   Interfaces:
+  void *dma_buf_vmap(struct dma_buf *dmabuf)
+  void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+
+   This call can fail if there is no vmap support in the exporter, or if it
+   runs out of vmalloc space. Fallback to kmap should be implemented.
+
 3. Finish access
 
When the importer is done accessing the range specified in begin_cpu_access,
-- 
1.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] dma-buf: add initial vmap documentation

[Chris Wilson]

On Tue, 22 May 2012 13:34:38 +0100, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

Inline comment for one sentence that made no sense.

 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  Documentation/dma-buf-sharing.txt |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/dma-buf-sharing.txt 
 b/Documentation/dma-buf-sharing.txt
 index 3bbd5c5..98e9fa0 100644
 --- a/Documentation/dma-buf-sharing.txt
 +++ b/Documentation/dma-buf-sharing.txt
 @@ -300,6 +300,17 @@ Access to a dma_buf from the kernel context involves 
 three steps:
 Note that these calls need to always succeed. The exporter needs to 
 complete
 any preparations that might fail in begin_cpu_access.
  
 +   For some circumstances the overhead of kmap can be too high, a vmap 
 interface
 +   is introduced. This interface shouldn't be used very carefully, as vmalloc
This interface should be used carefully.

Sparingly would also be appropriate, though in less regular usage than
carefully.

 +   space is a limited resources on many architectures.
 +
 +   Interfaces:
 +  void *dma_buf_vmap(struct dma_buf *dmabuf)
 +  void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 +
 +   This call can fail if there is no vmap support in the exporter, or if it
 +   runs out of vmalloc space. Fallback to kmap should be implemented.
 +
  3. Finish access

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] udl: add prime fd-handle support.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

udl can only be used as an output offload so doesn't need to support
handle-fd direction.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/udl/udl_drv.c |6 +++-
 drivers/gpu/drm/udl/udl_drv.h |3 ++
 drivers/gpu/drm/udl/udl_fb.c  |9 +
 drivers/gpu/drm/udl/udl_gem.c |   75 +
 4 files changed, 92 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 82e6921..4d02c46 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -57,7 +57,7 @@ static const struct file_operations udl_driver_fops = {
 };
 
 static struct drm_driver driver = {
-   .driver_features = DRIVER_MODESET | DRIVER_GEM,
+   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.load = udl_driver_load,
.unload = udl_driver_unload,
 
@@ -70,6 +70,10 @@ static struct drm_driver driver = {
.dumb_map_offset = udl_gem_mmap,
.dumb_destroy = udl_dumb_destroy,
.fops = udl_driver_fops,
+
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_import = udl_gem_prime_import,
+
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 96820d0..fccd361 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -66,6 +66,7 @@ struct udl_gem_object {
struct drm_gem_object base;
struct page **pages;
void *vmapping;
+   struct sg_table *sg;
 };
 
 #define to_udl_bo(x) container_of(x, struct udl_gem_object, base)
@@ -118,6 +119,8 @@ int udl_gem_init_object(struct drm_gem_object *obj);
 void udl_gem_free_object(struct drm_gem_object *gem_obj);
 struct udl_gem_object *udl_gem_alloc_object(struct drm_device *dev,
size_t size);
+struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);
 
 int udl_gem_vmap(struct udl_gem_object *obj);
 void udl_gem_vunmap(struct udl_gem_object *obj);
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 4d9c3a5..a029ee3 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -593,11 +593,20 @@ udl_fb_user_fb_create(struct drm_device *dev,
struct drm_gem_object *obj;
struct udl_framebuffer *ufb;
int ret;
+   uint32_t size;
 
obj = drm_gem_object_lookup(dev, file, mode_cmd-handles[0]);
if (obj == NULL)
return ERR_PTR(-ENOENT);
 
+   size = mode_cmd-pitches[0] * mode_cmd-height;
+   size = ALIGN(size, PAGE_SIZE);
+
+   if (size  obj-size) {
+   DRM_ERROR(object size not sufficient for fb %d %zu %d %d\n, 
size, obj-size, mode_cmd-pitches[0], mode_cmd-height);
+   return ERR_PTR(-ENOMEM);
+   }
+
ufb = kzalloc(sizeof(*ufb), GFP_KERNEL);
if (ufb == NULL)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 92f19ef..40efd32 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -9,6 +9,7 @@
 #include drmP.h
 #include udl_drv.h
 #include linux/shmem_fs.h
+#include linux/dma-buf.h
 
 struct udl_gem_object *udl_gem_alloc_object(struct drm_device *dev,
size_t size)
@@ -161,6 +162,12 @@ static void udl_gem_put_pages(struct udl_gem_object *obj)
int page_count = obj-base.size / PAGE_SIZE;
int i;
 
+   if (obj-base.import_attach) {
+   drm_free_large(obj-pages);
+   obj-pages = NULL;
+   return;
+   }
+
for (i = 0; i  page_count; i++)
page_cache_release(obj-pages[i]);
 
@@ -195,6 +202,9 @@ void udl_gem_free_object(struct drm_gem_object *gem_obj)
 {
struct udl_gem_object *obj = to_udl_bo(gem_obj);
 
+   if (gem_obj-import_attach)
+   drm_prime_gem_destroy(gem_obj, obj-sg);
+
if (obj-vmapping)
udl_gem_vunmap(obj);
 
@@ -239,3 +249,68 @@ unlock:
mutex_unlock(dev-struct_mutex);
return ret;
 }
+
+static int udl_prime_create(struct drm_device *dev,
+   size_t size,
+   struct sg_table *sg,
+   struct udl_gem_object **obj_p)
+{
+   struct udl_gem_object *obj;
+   int npages;
+   int i;
+   struct scatterlist *iter;
+
+   npages = size / PAGE_SIZE;
+
+   *obj_p = NULL;
+   obj = udl_gem_alloc_object(dev, npages * PAGE_SIZE);
+   if (!obj)
+   return -ENOMEM;
+
+   obj-sg = sg;
+   obj-pages = drm_malloc_ab(npages, sizeof(struct page *));
+   if (obj-pages == NULL) {
+   DRM_ERROR(obj pages is NULL %d\n, npages);
+   return 

[PATCH 2/7] drm/prime: add exported buffers to current fprivs imported buffer list (v2)

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

If userspace attempts to import a buffer it exported on the same device,
we need to return the same GEM handle for it, not a new handle pointing
at the same GEM object.

v2: move removals into a single fn, no need to set to NULL. (Chris Wilson)

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_gem.c   |   21 +++--
 drivers/gpu/drm/drm_prime.c |   12 
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 72ba075..d58e69d 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -201,6 +201,19 @@ free:
 }
 EXPORT_SYMBOL(drm_gem_object_alloc);
 
+static void
+drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp)
+{
+   if (obj-import_attach) {
+   drm_prime_remove_imported_buf_handle(filp-prime,
+   obj-import_attach-dmabuf);
+   }
+   if (obj-export_dma_buf) {
+   drm_prime_remove_imported_buf_handle(filp-prime,
+   obj-export_dma_buf);
+   }
+}
+
 /**
  * Removes the mapping from handle to filp for this object.
  */
@@ -233,9 +246,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(filp-object_idr, handle);
spin_unlock(filp-table_lock);
 
-   if (obj-import_attach)
-   drm_prime_remove_imported_buf_handle(filp-prime,
-   obj-import_attach-dmabuf);
+   drm_gem_remove_prime_handles(obj, filp);
 
if (dev-driver-gem_close_object)
dev-driver-gem_close_object(obj, filp);
@@ -530,9 +541,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj-dev;
 
-   if (obj-import_attach)
-   drm_prime_remove_imported_buf_handle(file_priv-prime,
-   obj-import_attach-dmabuf);
+   drm_gem_remove_prime_handles(obj, file_priv);
 
if (dev-driver-gem_close_object)
dev-driver-gem_close_object(obj, file_priv);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 20dbf2c..f546ff9 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -68,6 +68,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
 {
struct drm_gem_object *obj;
void *buf;
+   int ret;
 
obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj)
@@ -100,6 +101,17 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
obj-export_dma_buf = buf;
*prime_fd = dma_buf_fd(buf, flags);
}
+   /* if we've exported this buffer the cheat and add it to the import list
+* so we get the correct handle back
+*/
+   ret = drm_prime_add_imported_buf_handle(file_priv-prime,
+   obj-export_dma_buf, handle);
+   if (ret) {
+   drm_gem_object_unreference_unlocked(obj);
+   mutex_unlock(file_priv-prime.lock);
+   return ret;
+   }
+
mutex_unlock(file_priv-prime.lock);
return 0;
 }
-- 
1.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/prime: introduce sg-pages/addr arrays helper

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

the ttm drivers need this currently, in order to get fault handling
working and efficient.

It also allows addrs to be NULL for devices like udl.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_prime.c |   36 
 include/drm/drmP.h  |2 ++
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1bdf2b5..20dbf2c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -227,6 +227,42 @@ out:
 }
 EXPORT_SYMBOL(drm_prime_pages_to_sg);
 
+/* export an sg table into an array of pages and addresses
+   this is currently required by the TTM driver in order to do correct fault
+   handling */
+int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages,
+dma_addr_t *addrs, int max_pages)
+{
+   unsigned count;
+   struct scatterlist *sg;
+   struct page *page;
+   u32 len, offset;
+   int pg_index;
+   dma_addr_t addr;
+
+   pg_index = 0;
+   for_each_sg(sgt-sgl, sg, sgt-nents, count) {
+   len = sg-length;
+   offset = sg-offset;
+   page = sg_page(sg);
+   addr = sg_dma_address(sg);
+
+   while (len  0) {
+   if (WARN_ON(pg_index = max_pages))
+   return -1;
+   pages[pg_index] = page;
+   if (addrs)
+   addrs[pg_index] = addr;
+
+   page++;
+   addr += PAGE_SIZE;
+   len -= PAGE_SIZE;
+   pg_index++;
+   }
+   }
+   return 0;
+}
+EXPORT_SYMBOL(drm_prime_sg_to_page_addr_arrays);
 /* helper function to cleanup a GEM/prime object */
 void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg)
 {
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 15d9179..31ad880 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1558,6 +1558,8 @@ extern int drm_prime_handle_to_fd_ioctl(struct drm_device 
*dev, void *data,
 extern int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
 
+extern int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,
+   dma_addr_t *addrs, int max_pages);
 extern struct sg_table *drm_prime_pages_to_sg(struct page **pages, int 
nr_pages);
 extern void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table 
*sg);
 
-- 
1.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] ttm: add prime sharing support to TTM (v2)

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This adds the ability for ttm common code to take an SG table
and use it as the backing for a slave TTM object.

The drivers can then populate their GTT tables using the SG object.

v2: make sure to setup VM for sg bos as well.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 drivers/gpu/drm/radeon/radeon_object.c   |2 +-
 drivers/gpu/drm/ttm/ttm_bo.c |   17 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |2 +-
 include/drm/ttm/ttm_bo_api.h |9 -
 include/drm/ttm/ttm_bo_driver.h  |2 ++
 6 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 12ce044..81599d6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -121,7 +121,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
 
ret = ttm_bo_init(dev_priv-ttm.bdev, nvbo-bo, size,
  ttm_bo_type_device, nvbo-placement,
- align  PAGE_SHIFT, 0, false, NULL, acc_size,
+ align  PAGE_SHIFT, 0, false, NULL, acc_size, NULL,
  nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index df6a4db..1affbc9 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -155,7 +155,7 @@ retry:
mutex_lock(rdev-vram_mutex);
r = ttm_bo_init(rdev-mman.bdev, bo-tbo, size, type,
bo-placement, page_align, 0, !kernel, NULL,
-   acc_size, radeon_ttm_bo_destroy);
+   acc_size, NULL, radeon_ttm_bo_destroy);
mutex_unlock(rdev-vram_mutex);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1f5c67c..36792bd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -343,6 +343,16 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
if (unlikely(bo-ttm == NULL))
ret = -ENOMEM;
break;
+   case ttm_bo_type_sg:
+   bo-ttm = bdev-driver-ttm_tt_create(bdev, bo-num_pages  
PAGE_SHIFT,
+ page_flags | 
TTM_PAGE_FLAG_SG,
+ glob-dummy_read_page);
+   if (unlikely(bo-ttm == NULL)) {
+   ret = -ENOMEM;
+   break;
+   }
+   bo-ttm-sg = bo-sg;
+   break;
default:
pr_err(Illegal buffer object type\n);
ret = -EINVAL;
@@ -1169,6 +1179,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bool interruptible,
struct file *persistent_swap_storage,
size_t acc_size,
+   struct sg_table *sg,
void (*destroy) (struct ttm_buffer_object *))
 {
int ret = 0;
@@ -1223,6 +1234,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo-seq_valid = false;
bo-persistent_swap_storage = persistent_swap_storage;
bo-acc_size = acc_size;
+   bo-sg = sg;
atomic_inc(bo-glob-bo_count);
 
ret = ttm_bo_check_placement(bo, placement);
@@ -1233,7 +1245,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
 * For ttm_bo_type_device buffers, allocate
 * address space from the device.
 */
-   if (bo-type == ttm_bo_type_device) {
+   if (bo-type == ttm_bo_type_device ||
+   bo-type == ttm_bo_type_sg) {
ret = ttm_bo_setup_vm(bo);
if (ret)
goto out_err;
@@ -1312,7 +1325,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
 
ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
buffer_start, interruptible,
-   persistent_swap_storage, acc_size, NULL);
+ persistent_swap_storage, acc_size, NULL, NULL);
if (likely(ret == 0))
*p_bo = bo;
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index a37abb5..22bf9a2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -1567,7 +1567,7 @@ int vmw_dmabuf_init(struct vmw_private *dev_priv,
ret = ttm_bo_init(bdev, vmw_bo-base, size,
  ttm_bo_type_device, placement,
  0, 0, interruptible,
- NULL, acc_size, bo_free);
+ NULL, acc_size, NULL, bo_free);
return 

[PATCH 6/7] i915: add dmabuf/prime buffer sharing support.

[Dave Airlie]

From: Daniel Vetter daniel.vet...@ffwll.ch

This adds handle-fd and fd-handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.

v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.

Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.

Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.

Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).

Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.

v3: Right when I've hit sent I've noticed that I've screwed up one
obj-sg_list (for dmar support) and obj-sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.

v4: fix the error reporting bugs pointed out by ickle.

v5: fix another error, and stop non-gtt mmaps on shared objects
stop pread/pwrite on imported objects, add fake kmap

Signed-off-by: Dave Airlie airl...@redhat.com
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/Makefile  |3 +-
 drivers/gpu/drm/i915/i915_drv.c|8 ++-
 drivers/gpu/drm/i915/i915_drv.h|   11 ++
 drivers/gpu/drm/i915/i915_gem.c|   37 +++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  171 
 drivers/gpu/drm/i915/i915_gem_gtt.c|   15 +++-
 6 files changed, 239 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ca7f76..2e9268d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -38,7 +38,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
  dvo_ch7017.o \
  dvo_ivch.o \
  dvo_tfp410.o \
- dvo_sil164.o
+ dvo_sil164.o \
+ i915_gem_dmabuf.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7b967d5..238a521 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1039,7 +1039,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
-   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM,
+   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
.open = i915_driver_open,
@@ -1062,6 +1062,12 @@ static struct drm_driver driver = {
.gem_init_object = i915_gem_init_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = i915_gem_vm_ops,
+
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = i915_gem_prime_export,
+   .gem_prime_import = i915_gem_prime_import,
+
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_mmap_gtt,
.dumb_destroy = i915_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11c7a6a..377c21f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -940,6 +940,8 @@ struct drm_i915_gem_object {
struct scatterlist *sg_list;
int num_sg;
 
+   /* prime dma-buf support */
+   struct sg_table *sg_table;
/**
 * Used for performing relocations during execbuffer insertion.
 */
@@ -1245,6 +1247,8 @@ int __must_check i915_gem_object_unbind(struct 
drm_i915_gem_object *obj);
 void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
 void i915_gem_lastclose(struct drm_device *dev);
 
+int i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
+ gfp_t gfpmask);
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int __must_check i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
@@ -1342,6 +1346,13 @@ i915_gem_get_unfenced_gtt_alignment(struct drm_device 
*dev,
 int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
 
+struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);
+
+struct dma_buf 

[PATCH 7/7] drm/radeon: add PRIME support (v2)

[Dave Airlie]

From: Alex Deucher alexander.deuc...@amd.com

This adds prime-fd and fd-prime support to radeon.
It passes the sg object to ttm and then populates
the gart entries using it.

Compile tested only.

v2: stub kmap + use new helpers + add reimporting

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/Makefile |2 +-
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +-
 drivers/gpu/drm/radeon/r600.c   |4 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c  |2 +-
 drivers/gpu/drm/radeon/radeon_benchmark.c   |4 +-
 drivers/gpu/drm/radeon/radeon_device.c  |2 +-
 drivers/gpu/drm/radeon/radeon_drv.c |   14 ++-
 drivers/gpu/drm/radeon/radeon_gart.c|2 +-
 drivers/gpu/drm/radeon/radeon_gem.c |4 +-
 drivers/gpu/drm/radeon/radeon_object.c  |6 +-
 drivers/gpu/drm/radeon/radeon_object.h  |7 +-
 drivers/gpu/drm/radeon/radeon_prime.c   |  176 +++
 drivers/gpu/drm/radeon/radeon_ring.c|4 +-
 drivers/gpu/drm/radeon/radeon_sa.c  |2 +-
 drivers/gpu/drm/radeon/radeon_test.c|4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c |   16 ++-
 drivers/gpu/drm/radeon/si.c |6 +-
 17 files changed, 232 insertions(+), 25 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_prime.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 1efb6eb..a6598fd 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
evergreen_blit_kms.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
-   si_blit_shaders.o
+   si_blit_shaders.o radeon_prime.o
 
 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 30f0480..1e96bd4 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -668,7 +668,7 @@ int evergreen_blit_init(struct radeon_device *rdev)
obj_size = ALIGN(obj_size, 256);
 
r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
RADEON_GEM_DOMAIN_VRAM,
-   rdev-r600_blit.shader_obj);
+NULL, rdev-r600_blit.shader_obj);
if (r) {
DRM_ERROR(evergreen failed to allocate shader\n);
return r;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index ab5d6f2..f388a1d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1231,7 +1231,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
if (rdev-vram_scratch.robj == NULL) {
r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
 PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
-rdev-vram_scratch.robj);
+NULL, rdev-vram_scratch.robj);
if (r) {
return r;
}
@@ -2769,7 +2769,7 @@ int r600_ih_ring_alloc(struct radeon_device *rdev)
r = radeon_bo_create(rdev, rdev-ih.ring_size,
 PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_GTT,
-rdev-ih.ring_obj);
+NULL, rdev-ih.ring_obj);
if (r) {
DRM_ERROR(radeon: failed to create ih ring buffer 
(%d).\n, r);
return r;
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index ef20822..03b6e0d 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -552,7 +552,7 @@ int r600_blit_init(struct radeon_device *rdev)
obj_size = ALIGN(obj_size, 256);
 
r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
RADEON_GEM_DOMAIN_VRAM,
-   rdev-r600_blit.shader_obj);
+NULL, rdev-r600_blit.shader_obj);
if (r) {
DRM_ERROR(r600 failed to allocate shader\n);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index fef7b72..364f5b1 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -103,7 +103,7 @@ static void radeon_benchmark_move(struct radeon_device 
*rdev, unsigned size,
int time;
 
n = RADEON_BENCHMARK_ITERATIONS;
-   r = radeon_bo_create(rdev, size, 

[PATCH 5/7] nouveau: add PRIME support

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This adds prime-fd and fd-prime support to nouveau,
it passes the SG object to TTM, and then populates the
GART entries using it.

v2: add stubbed kmap + use new function to fill out pages array
for faulting + add reimport test.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/nouveau/Makefile  |2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   42 ++--
 drivers/gpu/drm/nouveau/nouveau_channel.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c |8 ++-
 drivers/gpu/drm/nouveau/nouveau_drv.h |   10 ++-
 drivers/gpu/drm/nouveau/nouveau_fence.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c |6 +-
 drivers/gpu/drm/nouveau/nouveau_mem.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_prime.c   |  163 +
 drivers/gpu/drm/nouveau/nouveau_sgdma.c   |5 +-
 drivers/gpu/drm/nouveau/nouveau_vm.c  |   57 ++
 drivers/gpu/drm/nouveau/nouveau_vm.h  |6 +-
 drivers/gpu/drm/nouveau/nv04_crtc.c   |2 +-
 drivers/gpu/drm/nouveau/nv50_crtc.c   |4 +-
 drivers/gpu/drm/nouveau/nv50_evo.c|4 +-
 drivers/gpu/drm/nouveau/nvd0_display.c|6 +-
 16 files changed, 296 insertions(+), 25 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_prime.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 1a2ad7e..01f1335 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -37,7 +37,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o 
nouveau_mem.o \
 nv50_calc.o \
 nv04_pm.o nv40_pm.o nv50_pm.o nva3_pm.o nvc0_pm.o \
 nv50_vram.o nvc0_vram.o \
-nv50_vm.o nvc0_vm.o
+nv50_vm.o nvc0_vm.o nouveau_prime.o
 
 nouveau-$(CONFIG_DRM_NOUVEAU_DEBUG) += nouveau_debugfs.o
 nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 81599d6..4435e11 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -89,12 +89,17 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
 int
 nouveau_bo_new(struct drm_device *dev, int size, int align,
   uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
+  struct sg_table *sg,
   struct nouveau_bo **pnvbo)
 {
struct drm_nouveau_private *dev_priv = dev-dev_private;
struct nouveau_bo *nvbo;
size_t acc_size;
int ret;
+   int type = ttm_bo_type_device;
+
+   if (sg)
+   type = ttm_bo_type_sg;
 
nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL);
if (!nvbo)
@@ -120,8 +125,8 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
   sizeof(struct nouveau_bo));
 
ret = ttm_bo_init(dev_priv-ttm.bdev, nvbo-bo, size,
- ttm_bo_type_device, nvbo-placement,
- align  PAGE_SHIFT, 0, false, NULL, acc_size, NULL,
+ type, nvbo-placement,
+ align  PAGE_SHIFT, 0, false, NULL, acc_size, sg,
  nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
@@ -817,9 +822,14 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem)
} else
if (new_mem  new_mem-mem_type == TTM_PL_TT 
nvbo-page_shift == vma-vm-spg_shift) {
-   nouveau_vm_map_sg(vma, 0, new_mem-
- num_pages  PAGE_SHIFT,
- new_mem-mm_node);
+   if (((struct nouveau_mem *)new_mem-mm_node)-sg)
+   nouveau_vm_map_sg_table(vma, 0, new_mem-
+ num_pages  PAGE_SHIFT,
+ new_mem-mm_node);
+   else
+   nouveau_vm_map_sg(vma, 0, new_mem-
+ num_pages  PAGE_SHIFT,
+ new_mem-mm_node);
} else {
nouveau_vm_unmap(vma);
}
@@ -1058,10 +1068,19 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
struct drm_device *dev;
unsigned i;
int r;
+   bool slave = !!(ttm-page_flags  TTM_PAGE_FLAG_SG);
 
if (ttm-state != tt_unpopulated)
return 0;
 
+   if (slave  ttm-sg) {
+   /* make userspace faulting work */
+   drm_prime_sg_to_page_addr_arrays(ttm-sg, ttm-pages,
+ttm_dma-dma_address, 
ttm-num_pages);
+   ttm-state = tt_unbound;
+   return 0;
+   }
+
dev_priv = 

Re: [PATCH 6/7] i915: add dmabuf/prime buffer sharing support.

[Chris Wilson]

On Tue, 22 May 2012 13:50:03 +0100, Dave Airlie airl...@gmail.com wrote:
 From: Daniel Vetter daniel.vet...@ffwll.ch
 
 This adds handle-fd and fd-handle support to i915, this is to allow
 for offloading of rendering in one direction and outputs in the other.
 
 v2 from Daniel Vetter:
 - fixup conflicts with the prepare/finish gtt prep work.
 - implement ppgtt binding support.
 
 Note that we have squat i-g-t testcoverage for any of the lifetime and
 access rules dma_buf/prime support brings along. And there are quite a
 few intricate situations here.
 
 Also note that the integration with the existing code is a bit
 hackish, especially around get_gtt_pages and put_gtt_pages. It imo
 would be easier with the prep code from Chris Wilson's unbound series,
 but that is for 3.6.
 
 Also note that I didn't bother to put the new prepare/finish gtt hooks
 to good use by moving the dma_buf_map/unmap_attachment calls in there
 (like we've originally planned for).
 
 Last but not least this patch is only compile-tested, but I've changed
 very little compared to Dave Airlie's version. So there's a decent
 chance v2 on drm-next works as well as v1 on 3.4-rc.
 
 v3: Right when I've hit sent I've noticed that I've screwed up one
 obj-sg_list (for dmar support) and obj-sg_table (for prime support)
 disdinction. We should be able to merge these 2 paths, but that's
 material for another patch.
 
 v4: fix the error reporting bugs pointed out by ickle.
 
 v5: fix another error, and stop non-gtt mmaps on shared objects
 stop pread/pwrite on imported objects, add fake kmap

Everything up to this point looks reasonable wrt i915. We obviously need
to lift a few of the restrictions for i915 introduced here and protect
dma-buf objects from the shrinker/truncate.  In fact we need to add a
guard to i915_gem_object_truncate in this patch to prevent one such
explosion. Wrt to the shrinker and the leak of exported pages, that
should be managed by the unbound page tracking which is queued for
review this cycle (right Daniel? ;). That just leaves fixing up
pread/pwrite and fixing the other guards that will interact sorely with
stolen (also non-shmem backed) objects.
-Chris

 Signed-off-by: Dave Airlie airl...@redhat.com
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/Makefile  |3 +-
  drivers/gpu/drm/i915/i915_drv.c|8 ++-
  drivers/gpu/drm/i915/i915_drv.h|   11 ++
  drivers/gpu/drm/i915/i915_gem.c|   37 +++-
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  171 
 
  drivers/gpu/drm/i915/i915_gem_gtt.c|   15 +++-
  6 files changed, 239 insertions(+), 6 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c
 
 diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
 index 0ca7f76..2e9268d 100644
 --- a/drivers/gpu/drm/i915/Makefile
 +++ b/drivers/gpu/drm/i915/Makefile
 @@ -38,7 +38,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
 dvo_ch7017.o \
 dvo_ivch.o \
 dvo_tfp410.o \
 -   dvo_sil164.o
 +   dvo_sil164.o \
 +   i915_gem_dmabuf.o

Since we need another chunk to this patch, can you please add this file
in the i915_gem_*.c block.

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 11465] Linux-2.6.27-rc5, drm errors in log

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=11465


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE
 Regression|--- |No




--- Comment #6 from Alan a...@lxorguk.ukuu.org.uk  2012-05-22 13:41:09 ---
Marking as obsolete, if this is incorrect please re-open this bug against a
modern 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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel