[patch -next] drm/prime: double lock typo

[Dan Carpenter]

There is a typo so deadlocks on error instead of unlocking.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7ae2bfc..276d470 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -552,7 +552,7 @@ fail:
 */
drm_gem_handle_delete(file_priv, *handle);
 out_unlock:
-   mutex_lock(&dev->object_name_lock);
+   mutex_unlock(&dev->object_name_lock);
 out_put:
dma_buf_put(dma_buf);
mutex_unlock(&file_priv->prime.lock);

Re: [Nouveau] [PATCH] drm/nouveau: do not move buffers when not needed

[Martin Peres]

On 15/07/2013 10:39, Maarten Lankhorst wrote:

Op 15-07-13 08:05, Ben Skeggs schreef:

On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
 wrote:

I have no idea what this bogus restriction on placement is, but it breaks 
decoding 1080p
VDPAU at boot speed. With this patch applied I only need to bump the vdec clock 
to
get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves.

It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size.

What configuration does the buffer that's getting moved here have
exactly?  The placement restriction isn't necessary on GF8, the rest
of the restrictions may currently be required still however.

= vdpau on NVC0 with tiling. I upload the raw bitstream to a tiling bo. This is 
ok because

the vm hides all the tiling translations, and the engines will read the raw 
bitstream correctly.
8<---
This prevents buffer moves from being done on NV50+, where remapping is not 
needed because
the bar has its own VM, instead of only having the first BAR1-size chunk of 
VRAM accessible.
nouveau_bo_tile_layout is always 0 on < NV_50.

Signed-off-by: Maarten Lankhorst 
There are still some rendering issues on my nvc4, but the framerate is 
much smoother than it was before this patch.


Tested-by: Martin Peres 

---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index d506da5..762bfcd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct 
ttm_buffer_object *bo)
struct nouveau_device *device = nv_device(drm->device);
u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
  
-	/* as long as the bo isn't in vram, and isn't tiled, we've got

-* nothing to do here.
+   /*
+* if the bo is not in vram, or remapping can be done (nv50+)
+* do not worry about placement, any location is valid
 */
-   if (bo->mem.mem_type != TTM_PL_VRAM) {
-   if (nv_device(drm->device)->card_type < NV_50 ||
-   !nouveau_bo_tile_layout(nvbo))
-   return 0;
-   }
+   if (nv_device(drm->device)->card_type >= NV_50 ||
+   bo->mem.mem_type != TTM_PL_VRAM)
+   return 0;
  
  	/* make sure bo is in mappable vram */

if (bo->mem.start + bo->mem.num_pages < mappable)

___
Nouveau mailing list
nouv...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


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

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi K?rkk?inen 
> > Tested-by: Pasi K?rkk?inen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> Not it really isn't appropriate..
> 
> You'd have to call call nouveau_vm_map_sg_table instead, the only place that 
> doesn't handle that correctly
> is where it's not expected to be called.
> 
> Here, have a completely untested patch to fix things...
> 

Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify the 
patch a bit to make it apply there.. 
I've attached the modified copy that applies to 3.10.9, hopefully I did the 
backport correctly.

With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and I 
get this error in dmesg:

[   76.105643] nouveau W[ DRM] Trying to create a fb in vram with 
valid_domains=0004

Does that help? 


-- Pasi

-- next part --
A non-text attachment was scrubbed...
Name: nouveau_test_fix_null_deref_v3.10.patch
Type: text/x-diff
Size: 1202 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/b13e064d/attachment.patch>

[Bug 68391] [radeonsi] Crash unigine-sanctuary

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

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

--- Comment #4 from Rafael Castillo  ---
i can confirm my hd7770 give the same error in xonotic 7.0 in some worlds too

LLVM ERROR: ran out of registers during register allocation
 and gdb can't backtrace either

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/94e80dd9/attachment.html>

[PATCH -next v2] drm/rcar-du: remove redundant dev_err call in rcar_du_lvdsenc_get_resources()

[Wei Yongjun]

From: Wei Yongjun 

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
error message and check for return value of platform_get_resource_byname().

Signed-off-by: Wei Yongjun 
---
v1 -> v2; remove return value check of platform_get_resource_byname()
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index a0f6a17..fe1f6f5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -144,18 +144,9 @@ static int rcar_du_lvdsenc_get_resources(struct 
rcar_du_lvdsenc *lvds,
sprintf(name, "lvds.%u", lvds->index);

mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
-   if (mem == NULL) {
-   dev_err(&pdev->dev, "failed to get memory resource for %s\n",
-   name);
-   return -EINVAL;
-   }
-
lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
-   if (lvds->mmio == NULL) {
-   dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
-   name);
-   return -ENOMEM;
-   }
+   if (IS_ERR(lvds->mmio))
+   return PTR_ERR(lvds->mmio);

lvds->clock = devm_clk_get(&pdev->dev, name);
if (IS_ERR(lvds->clock)) {

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

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

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

--- Comment #2 from adam777 at gmail.com ---
Well, I've learned of bisect right about now, so not efficiently, I suppose.
That being said, with a few pointers, I'm willing to try.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/723e41d9/attachment.html>

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

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

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

--- Comment #36 from Alex Deucher  ---
Starting with kernel 3.11 you can enable the dynamic power management hardware
on the gpu by booting with radeon.dpm=1 on the kernel command line in grub. 
You will also need the latest smc firmware for your card.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/4240de21/attachment.html>

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

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

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

--- Comment #35 from Neil Connolly  ---
I have the same overheating problem with a Sony Vaio i5 with ATI Redeon 5400
graphics.
Idle temperature quickly rises to 70oC and then any desktop activity takes the
temperature into the 80's. Running a video fullscreen causes the machine to
shutdown.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/2595cecf/attachment.html>

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

[bugzilla-daemon]

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

--- Comment #5 from Tom Stellard  ---
Created attachment 84544
  --> https://bugs.freedesktop.org/attachment.cgi?id=84544&action=edit
LLVM Patch #3

If you apply all three of these patches, does it fix the crash?

-- 
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 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

[bugzilla-daemon]

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

--- Comment #4 from Tom Stellard  ---
Created attachment 84543
  --> https://bugs.freedesktop.org/attachment.cgi?id=84543&action=edit
Patch #2

-- 
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

[PATCH] drm/radeon: Support render nodes

[David Herrmann]

Hi

On Fri, Aug 23, 2013 at 3:45 PM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> Enable support for drm render nodes for radeon by flagging the ioctls that
> are safe and just needed for rendering.
>
> Signed-off-by: Christian K?nig 

Looks good to me. I queued it locally. v3 will include it. If there's
no v3, I think Dave will pick it up from the list.

Thanks
David

> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |2 +-
>  drivers/gpu/drm/radeon/radeon_kms.c |   22 +++---
>  2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 1f93dd5..dffbb78 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -384,7 +384,7 @@ static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_USE_AGP |
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> -   DRIVER_PRIME,
> +   DRIVER_PRIME | DRIVER_RENDER,
> .dev_priv_size = 0,
> .load = radeon_driver_load_kms,
> .open = radeon_driver_open_kms,
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index b46a561..1593ee6 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -738,18 +738,18 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
> DRM_IOCTL_DEF_DRV(RADEON_SURF_ALLOC, radeon_surface_alloc_kms, 
> DRM_AUTH),
> DRM_IOCTL_DEF_DRV(RADEON_SURF_FREE, radeon_surface_free_kms, 
> DRM_AUTH),
> /* KMS */
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(RADEON_GEM_PREAD, radeon_gem_pread_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(RADEON_GEM_PWRITE, radeon_gem_pwrite_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>  };
>  int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
> --
> 1.7.9.5
>

Re: [patch -next] drm/prime: double lock typo

[Daniel Vetter]

On Fri, Aug 23, 2013 at 11:46:02PM +0300, Dan Carpenter wrote:
> There is a typo so deadlocks on error instead of unlocking.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7ae2bfc..276d470 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -552,7 +552,7 @@ fail:
>*/
>   drm_gem_handle_delete(file_priv, *handle);
>  out_unlock:
> - mutex_lock(&dev->object_name_lock);
> + mutex_unlock(&dev->object_name_lock);

Duh. Unfortunately exercising error paths is pretty hard :( So thanks for
catching this.

Reviewed-by: Daniel Vetter 
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/6] drm/i915: Support render nodes

[Daniel Vetter]

On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian Høgsberg 
> 
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Kristian Høgsberg 
> Signed-off-by: David Herrmann 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>  2 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 0adfe40..ecf5ecd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
> @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
> DRM_AUTH|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
> DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
> DRM_UNLOCKED),

Those two here also need to work on render nodes. With that and REG_READ
also marked up like Chris said this is

Reviewed-by: Daniel Vetter 


> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>  

[PATCH] drm/radeon: Support render nodes

[Christian König]

From: Christian K?nig 

Enable support for drm render nodes for radeon by flagging the ioctls that
are safe and just needed for rendering.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_drv.c |2 +-
 drivers/gpu/drm/radeon/radeon_kms.c |   22 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 1f93dd5..dffbb78 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -384,7 +384,7 @@ static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
-   DRIVER_PRIME,
+   DRIVER_PRIME | DRIVER_RENDER,
.dev_priv_size = 0,
.load = radeon_driver_load_kms,
.open = radeon_driver_open_kms,
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index b46a561..1593ee6 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -738,18 +738,18 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(RADEON_SURF_ALLOC, radeon_surface_alloc_kms, 
DRM_AUTH),
DRM_IOCTL_DEF_DRV(RADEON_SURF_FREE, radeon_surface_free_kms, DRM_AUTH),
/* KMS */
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_PREAD, radeon_gem_pread_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(RADEON_GEM_PWRITE, radeon_gem_pwrite_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
-- 
1.7.9.5

[Bug 68391] [radeonsi] Crash unigine-sanctuary

[bugzilla-daemon]

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

--- Comment #4 from Rafael Castillo  ---
i can confirm my hd7770 give the same error in xonotic 7.0 in some worlds too

LLVM ERROR: ran out of registers during register allocation
 and gdb can't backtrace either

-- 
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

[PATCH -next v2] drm/rcar-du: remove redundant dev_err call in rcar_du_lvdsenc_get_resources()

[Laurent Pinchart]

On Friday 23 August 2013 21:15:16 Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
> error message and check for return value of platform_get_resource_byname().
> 
> Signed-off-by: Wei Yongjun 

Acked-by: Laurent Pinchart 

Dave, could you please pick the patch up ?

> ---
> v1 -> v2; remove return value check of platform_get_resource_byname()
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c index a0f6a17..fe1f6f5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -144,18 +144,9 @@ static int rcar_du_lvdsenc_get_resources(struct
> rcar_du_lvdsenc *lvds, sprintf(name, "lvds.%u", lvds->index);
> 
>   mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
> - if (mem == NULL) {
> - dev_err(&pdev->dev, "failed to get memory resource for %s\n",
> - name);
> - return -EINVAL;
> - }
> -
>   lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
> - if (lvds->mmio == NULL) {
> - dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
> - name);
> - return -ENOMEM;
> - }
> + if (IS_ERR(lvds->mmio))
> + return PTR_ERR(lvds->mmio);
> 
>   lvds->clock = devm_clk_get(&pdev->dev, name);
>   if (IS_ERR(lvds->clock)) {

-- 
Regards,

Laurent Pinchart

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[David Herrmann]

Hi

On Fri, Aug 23, 2013 at 2:34 PM, Christian K?nig
 wrote:
>> Feel free to send a patch to dri-devel or just let me know the ioctls
>> and I will include it in this series.
>
>
> Do you have a branch somewhere I can grab?
>
> That's a bit easier than applying the patchset from the list.

https://github.com/dvdhrm/linux/commits/rnodes
I rebase it on update, so don't "git pull" it.

Cheers
David

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Christian König]

> Feel free to send a patch to dri-devel or just let me know the ioctls
> and I will include it in this series.

Do you have a branch somewhere I can grab?

That's a bit easier than applying the patchset from the list.

Thanks,
Christian.

Am 23.08.2013 14:31, schrieb David Herrmann:
> Hi
>
> On Fri, Aug 23, 2013 at 1:28 PM, Christian K?nig
>  wrote:
>> Hi David,
>>
>> Am 23.08.2013 13:13, schrieb David Herrmann:
>>
>>> Hi
>>>
>>> I reduced the vma access-management patches to a minimum. I now do filp*
>>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>>> Hence,
>>> all gem drivers are safe now. For TTM drivers, I now use the already
>>> available
>>> verify_access() callback to get access to the underlying gem-object.
>>> Pretty
>>> simple.. Why hadn't I thought of that before?
>>>
>>> Long story short: All drivers using GEM are safe now. This leaves vmwgfx..
>>> But
>>> they do their own access-management, anyway.
>>>
>>> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
>>> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
>>> command-line or via sysfs _before_ loading a driver. Otherwise, render
>>> nodes
>>> will not be created.
>>>
>>> This allows us to test render-nodes and play with the API. I added FLINK
>>> for
>>> now so we can better test it. Not sure whether we should allow it in the
>>> end,
>>> though.
>>>
>>> Maybe we can get this into 3.11?
>>
>> A bit unlikely, but 3.12 should work fine.
> whoops, 3.12 of course.
>
>> I'm working on a project that can make good use of this, so if Alex doesn't
>> mind like to add the necessary radeon flags (should be only a few one liners
>> anyway).
> Feel free to send a patch to dri-devel or just let me know the ioctls
> and I will include it in this series.
>
> Regards
> David
>

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[David Herrmann]

Hi

On Fri, Aug 23, 2013 at 1:28 PM, Christian K?nig
 wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> all gem drivers are safe now. For TTM drivers, I now use the already
>> available
>> verify_access() callback to get access to the underlying gem-object.
>> Pretty
>> simple.. Why hadn't I thought of that before?
>>
>> Long story short: All drivers using GEM are safe now. This leaves vmwgfx..
>> But
>> they do their own access-management, anyway.
>>
>> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
>> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
>> command-line or via sysfs _before_ loading a driver. Otherwise, render
>> nodes
>> will not be created.
>>
>> This allows us to test render-nodes and play with the API. I added FLINK
>> for
>> now so we can better test it. Not sure whether we should allow it in the
>> end,
>> though.
>>
>> Maybe we can get this into 3.11?
>
>
> A bit unlikely, but 3.12 should work fine.

whoops, 3.12 of course.

> I'm working on a project that can make good use of this, so if Alex doesn't
> mind like to add the necessary radeon flags (should be only a few one liners
> anyway).

Feel free to send a patch to dri-devel or just let me know the ioctls
and I will include it in this series.

Regards
David

Re: [PATCH v2 5/6] drm/i915: Support render nodes

[Kristian Høgsberg]

On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson  wrote:
> On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
>> From: Kristian Høgsberg 
>>
>> Enable support for drm render nodes for i915 by flagging the ioctls that
>> are safe and just needed for rendering.
>>
>> Cc: Daniel Vetter 
>> Signed-off-by: Kristian Høgsberg 
>> Signed-off-by: David Herrmann 
>> ---
>>  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
>>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>>  2 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c 
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index 0adfe40..ecf5ecd 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>>   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
>> - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
>> + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
>> DRM_AUTH|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
>> @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
>> DRM_AUTH|DRM_UNLOCKED),
> execbuffer also
>
>> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
>> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
>> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
>> DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
>> DRM_UNLOCKED),
> set/get caching
>
>> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
>> DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

[bugzilla-daemon]

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

--- Comment #2 from adam...@gmail.com ---
Well, I've learned of bisect right about now, so not efficiently, I suppose.
That being said, with a few pointers, I'm willing to try.

-- 
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

[PATCH v2 5/6] drm/i915: Support render nodes

[Kristian Høgsberg]

On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson  
wrote:
> On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
>> From: Kristian H?gsberg 
>>
>> Enable support for drm render nodes for i915 by flagging the ioctls that
>> are safe and just needed for rendering.
>>
>> Cc: Daniel Vetter 
>> Signed-off-by: Kristian H?gsberg 
>> Signed-off-by: David Herrmann 
>> ---
>>  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
>>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>>  2 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c 
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index 0adfe40..ecf5ecd 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>>   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
>> - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
>> + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
>> DRM_AUTH|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
>> @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
>> DRM_AUTH|DRM_UNLOCKED),
> execbuffer also
>
>> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
>> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
>> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
>> DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
>> DRM_UNLOCKED),
> set/get caching
>
>> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
>> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>>   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
>> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
>> DRM_UNLOCKED),
>> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
>> DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_ge

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Martin Peres]

Le 23/08/2013 13:13, David Herrmann a ?crit :
> Hi
>
> I reduced the vma access-management patches to a minimum. I now do filp*
> tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
> all gem drivers are safe now. For TTM drivers, I now use the already available
> verify_access() callback to get access to the underlying gem-object. Pretty
> simple.. Why hadn't I thought of that before?
>
> Long story short: All drivers using GEM are safe now. This leaves vmwgfx.. But
> they do their own access-management, anyway.

Great! Thanks! Have you checked they are really safe with my "exploits"?
I'll have another round of review even if it looked good the last time I 
checked.
> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
> command-line or via sysfs _before_ loading a driver. Otherwise, render nodes
> will not be created.

By default, having the render nodes doesn't change the way the userspace
works at all. So, what is the point of protecting it behind a parameter?

Is it to make it clear this isn't part of the API yet? I would say that 
as long
as libdrm hasn't been updated, this isn't part of the API anyway.
> This allows us to test render-nodes and play with the API. I added FLINK for
> now so we can better test it. Not sure whether we should allow it in the end,
> though.

 From a security point of view, I don't think we should keep it as 
applications shouldn't
be trusted for not doing stupid things (because of code injection). So, 
unless we
plan on adding access control to flink via LSM, we shouldn't expose the 
feature
on render nodes.

 From a dev point of view, keeping it means that the XServer doesn't
have to know whether mesa supports render nodes or not. This is because
the authentication dance isn't available on render nodes so the x-server
has to tell mesa if it should authenticate or not. The other solution is 
to allow
the authentication ioctls on render nodes and just return 0 if this is a 
render node.
This way, we won't need any modification in mesa/xserver/dri2proto to pass
the information that no authentication is needed. In this solution, only 
libdrm and
the ddx should be modified to make use of the render node. That's not how I
did it on my render node patchset, can't remember why...

What do you guys think?
>
> Maybe we can get this into 3.11?

As long as we don't have to keep the interface stable (I don't want to 
expose flink
on render nodes), I'm all for pushing the code now. Otherwise, a kernel 
branch
somewhere is sufficient.

Do you plan on checking my userspace patches too? Those are enough to 
make use
of the render nodes on X, but I haven't tested that all the combinations 
of version
would still work. The libdrm work should be quite solid though (there 
are even libdrm
tests for the added functionalities :)).

Thanks for your work David!

[patch -next] drm/prime: double lock typo

[Dan Carpenter]

There is a typo so deadlocks on error instead of unlocking.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7ae2bfc..276d470 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -552,7 +552,7 @@ fail:
 */
drm_gem_handle_delete(file_priv, *handle);
 out_unlock:
-   mutex_lock(&dev->object_name_lock);
+   mutex_unlock(&dev->object_name_lock);
 out_put:
dma_buf_put(dma_buf);
mutex_unlock(&file_priv->prime.lock);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Christian König]

Hi David,

Am 23.08.2013 13:13, schrieb David Herrmann:
> Hi
>
> I reduced the vma access-management patches to a minimum. I now do filp*
> tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
> all gem drivers are safe now. For TTM drivers, I now use the already available
> verify_access() callback to get access to the underlying gem-object. Pretty
> simple.. Why hadn't I thought of that before?
>
> Long story short: All drivers using GEM are safe now. This leaves vmwgfx.. But
> they do their own access-management, anyway.
>
> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
> command-line or via sysfs _before_ loading a driver. Otherwise, render nodes
> will not be created.
>
> This allows us to test render-nodes and play with the API. I added FLINK for
> now so we can better test it. Not sure whether we should allow it in the end,
> though.
>
> Maybe we can get this into 3.11?

A bit unlikely, but 3.12 should work fine.

I'm working on a project that can make good use of this, so if Alex 
doesn't mind like to add the necessary radeon flags (should be only a 
few one liners anyway).

Cheers,
Christian.

> Regards
> David
>
> David Herrmann (4):
>drm/vma: add access management helpers
>drm/gem: implement vma access management
>drm: verify vma access in TTM+GEM drivers
>drm: implement experimental render nodes
>
> Kristian H?gsberg (1):
>drm/i915: Support render nodes
>
> Martin Peres (1):
>drm/nouveau: Support render nodes
>
>   Documentation/DocBook/drm.tmpl|  71 
>   drivers/gpu/drm/ast/ast_ttm.c |   4 +-
>   drivers/gpu/drm/cirrus/cirrus_ttm.c   |   4 +-
>   drivers/gpu/drm/drm_drv.c |  15 ++--
>   drivers/gpu/drm/drm_fops.c|  14 +--
>   drivers/gpu/drm/drm_gem.c |  18 
>   drivers/gpu/drm/drm_pci.c |   9 ++
>   drivers/gpu/drm/drm_platform.c|   9 ++
>   drivers/gpu/drm/drm_stub.c|  10 +++
>   drivers/gpu/drm/drm_usb.c |   9 ++
>   drivers/gpu/drm/drm_vma_manager.c | 155 
> ++
>   drivers/gpu/drm/i915/i915_dma.c   |  36 
>   drivers/gpu/drm/i915/i915_drv.c   |   3 +-
>   drivers/gpu/drm/mgag200/mgag200_ttm.c |   4 +-
>   drivers/gpu/drm/nouveau/nouveau_bo.c  |   4 +-
>   drivers/gpu/drm/nouveau/nouveau_drm.c |  24 +++---
>   drivers/gpu/drm/qxl/qxl_ttm.c |   4 +-
>   drivers/gpu/drm/radeon/radeon_ttm.c   |   4 +-
>   include/drm/drmP.h|   9 ++
>   include/drm/drm_vma_manager.h |  21 -
>   20 files changed, 373 insertions(+), 54 deletions(-)
>

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi Kärkkäinen 
> > Tested-by: Pasi Kärkkäinen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> Not it really isn't appropriate..
> 
> You'd have to call call nouveau_vm_map_sg_table instead, the only place that 
> doesn't handle that correctly
> is where it's not expected to be called.
> 
> Here, have a completely untested patch to fix things...
> 

Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify the 
patch a bit to make it apply there.. 
I've attached the modified copy that applies to 3.10.9, hopefully I did the 
backport correctly.

With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and I 
get this error in dmesg:

[   76.105643] nouveau W[ DRM] Trying to create a fb in vram with 
valid_domains=0004

Does that help? 


-- Pasi

--- linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c.orig	2013-07-01 01:13:29.0 +0300
+++ linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c	2013-08-23 19:56:52.038234281 +0300
@@ -137,18 +137,31 @@
 {
 	struct nouveau_framebuffer *nouveau_fb;
 	struct drm_gem_object *gem;
+	struct nouveau_bo *nvbo;
 	int ret;
 
 	gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
 	if (!gem)
 		return ERR_PTR(-ENOENT);
 
+	nvbo = nouveau_gem_object(gem);
+	if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
+		nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
+			" valid_domains=%08x\n", nvbo->valid_domains);
+		ret = -EINVAL;
+		drm_gem_object_unreference(gem);
+		return ERR_PTR(ret);
+	}
+
 	nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
-	if (!nouveau_fb)
+	if (!nouveau_fb) {
+		drm_gem_object_unreference(gem);
 		return ERR_PTR(-ENOMEM);
+	}
 
-	ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nouveau_gem_object(gem));
+	ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
 	if (ret) {
+		kfree(nouveau_fb);
 		drm_gem_object_unreference(gem);
 		return ERR_PTR(ret);
 	}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch 2/2] gpu: host1x: returning success instead of -ENOMEM

[Dan Carpenter]

There is a mistake here so it returns PTR_ERR(NULL) which is success
instead of -ENOMEM.

Signed-off-by: Dan Carpenter 
---
I can't compile this.

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc80766..6cf41da 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -466,9 +466,8 @@ static inline int copy_gathers(struct host1x_job *job, 
struct device *dev)
 &job->gather_copy,
 GFP_KERNEL);
if (!job->gather_copy_mapped) {
-   int err = PTR_ERR(job->gather_copy_mapped);
job->gather_copy_mapped = NULL;
-   return err;
+   return -ENOMEM;
}

job->gather_copy_size = size;

[patch 1/2] gpu: host1x: fix an integer overflow check

[Dan Carpenter]

Tegra is a 32 bit arch.  On 32 bit systems then size_t is 32 bits so
"total" will never be higher than UINT_MAX because of integer overflows.
We need cast to u64 first before doing the math.

Also the addition earlier:

unsigned int num_unpins = num_cmdbufs + num_relocs;

That can overflow as well, but I think it's still safe because we check
both "num_cmdbufs" and "num_relocs" again in this test.

Signed-off-by: Dan Carpenter 
---
This is something I spotted in code review.  I can't actually compile
this code.  I assume this overflow test has security implications.

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc80766..18a47f9 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -42,12 +42,12 @@ struct host1x_job *host1x_job_alloc(struct host1x_channel 
*ch,

/* Check that we're not going to overflow */
total = sizeof(struct host1x_job) +
-   num_relocs * sizeof(struct host1x_reloc) +
-   num_unpins * sizeof(struct host1x_job_unpin_data) +
-   num_waitchks * sizeof(struct host1x_waitchk) +
-   num_cmdbufs * sizeof(struct host1x_job_gather) +
-   num_unpins * sizeof(dma_addr_t) +
-   num_unpins * sizeof(u32 *);
+   (u64)num_relocs * sizeof(struct host1x_reloc) +
+   (u64)num_unpins * sizeof(struct host1x_job_unpin_data) +
+   (u64)num_waitchks * sizeof(struct host1x_waitchk) +
+   (u64)num_cmdbufs * sizeof(struct host1x_job_gather) +
+   (u64)num_unpins * sizeof(dma_addr_t) +
+   (u64)num_unpins * sizeof(u32 *);
if (total > ULONG_MAX)
return NULL;

[patch 2/2] gpu: host1x: returning success instead of -ENOMEM

[Stephen Warren]

On 08/23/2013 04:19 AM, Dan Carpenter wrote:
> There is a mistake here so it returns PTR_ERR(NULL) which is success
> instead of -ENOMEM.
> 
> Signed-off-by: Dan Carpenter 
> ---
> I can't compile this.

For the record, just do:

export CROSS_COMPILE=xxx
make ARCH=arm tegra_defconfig
make ARCH=arm zImage

The only slightly difficult part is getting a CROSS_COMPILE value. Many
distros ship at least some ARM cross-compiler in their standard
package-set these days, and if not, you can download the Linaro
compilers or go to ftp://ftp.kernel.org/pub/tools/crosstool/index.html.

[PATCH 10/16] drm/gem: implement mmap access management

[David Herrmann]

Hi

On Tue, Aug 13, 2013 at 11:05 PM, Daniel Vetter  wrote:
> On Tue, Aug 13, 2013 at 09:38:31PM +0200, David Herrmann wrote:
>> Implement automatic access management for mmap offsets for all GEM
>> drivers. This prevents user-space applications from "guessing" GEM BO
>> offsets and accessing buffers which they don't own.
>>
>> TTM drivers or other modesetting drivers with custom mm handling might
>> make use of GEM but don't need its mmap helpers. To avoid unnecessary
>> overhead, we limit GEM access management to drivers using DRIVER_GEM_MMAP.
>> So for TTM drivers GEM will not call any *_allow() or *_revoke() helpers.
>>
>> Signed-off-by: David Herrmann 
>
> Overall I'm not sold why we need the GEM_MMAP feature flag. Drivers that
> don't use drm_gem_mmap shouldn't get hurt with it if we ignore the little
> bit of useless overhead due to obj->vma_node. But they already have that
> anyway with obj->vma, so meh. And more incentives to move ttm over to the
> gem object manager completely ;-)
>
> One comment below.

I fixed both, the error-path and GEM_MMAP. Thanks!

Cheers
David

[PATCH v2 6/6] drm/nouveau: Support render nodes

[David Herrmann]

From: Martin Peres 

Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.

Cc: Ben Skeggs 
Cc: Maarten Lankhorst 
Signed-off-by: Martin Peres 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b29d04b..ab42a25 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -651,18 +651,18 @@ nouveau_drm_postclose(struct drm_device *dev, struct 
drm_file *fpriv)

 static const struct drm_ioctl_desc
 nouveau_ioctls[] = {
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam, 
DRM_UNLOCKED|DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, nouveau_abi16_ioctl_setparam, 
DRM_UNLOCKED|DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC, 
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE, 
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC, 
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC, 
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE, 
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC, 
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 };

 static const struct file_operations
@@ -684,7 +684,7 @@ static struct drm_driver
 driver = {
.driver_features =
DRIVER_USE_AGP |
-   DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME,
+   DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,

.load = nouveau_drm_load,
.unload = nouveau_drm_unload,
-- 
1.8.3.4

[PATCH v2 5/6] drm/i915: Support render nodes

[David Herrmann]

From: Kristian H?gsberg 

Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.

Cc: Daniel Vetter 
Signed-off-by: Kristian H?gsberg 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/i915/i915_dma.c | 36 ++--
 drivers/gpu/drm/i915/i915_drv.c |  3 ++-
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0adfe40..ecf5ecd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
@@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID, 
intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_

[PATCH v2 4/6] drm: implement experimental render nodes

[David Herrmann]

Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.

Compared to legacy clients, render clients no longer need any
authentication to perform client ioctls. Instead, user-space controls
render/client access to GPUs via filesystem access-modes on the
render-node. Once a render-node was opened, a client has full access to
the client/render operations on the GPU. However, no modesetting or ioctls
that affect global state are allowed on render nodes.

To prevent privilege-escalation, drivers must explicitly state that they
support render nodes. They must mark their render-only ioctls as
DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
support clients without any attached master.

If filesystem access-modes are not enough for fine-grained access control
to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
you may still fall-back to fd-passing from server to client (which allows
arbitrary access-control). However, note that revoking access is
currently impossible and unlikely to get implemented.

Note: Render clients no longer have any associated DRM-Master as they are
supposed to be independent of any server state. DRM core highly depends on
file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
Therefore, drivers must be very careful to not require DRM-Master if they
support DRIVER_RENDER.

So far render-nodes are protected by "drm_rnodes". As long as this
module-parameter is not set to 1, a driver will not create render nodes.
This allows us to experiment with the API a bit before we stabilize it.

Signed-off-by: David Herrmann 
---
 Documentation/DocBook/drm.tmpl | 71 ++
 drivers/gpu/drm/drm_drv.c  | 15 -
 drivers/gpu/drm/drm_fops.c | 14 -
 drivers/gpu/drm/drm_pci.c  |  9 ++
 drivers/gpu/drm/drm_platform.c |  9 ++
 drivers/gpu/drm/drm_stub.c | 10 ++
 drivers/gpu/drm/drm_usb.c  |  9 ++
 include/drm/drmP.h |  9 ++
 8 files changed, 132 insertions(+), 14 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 9fc8ed4..3a778bf 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -205,6 +205,12 @@
   Driver implements DRM PRIME buffer sharing.
 
   
+  
+DRIVER_RENDER
+
+  Driver supports dedicated render nodes.
+
+  
 
   
   
@@ -2644,6 +2650,71 @@ int (*resume) (struct drm_device *);
   info, since man pages should cover the rest.
 

+  
+
+
+  Render nodes
+  
+DRM core provides multiple character-devices for user-space to use.
+Depending on which device is opened, user-space can perform a different
+set of operations (mainly ioctls). The primary node is always created
+and called card. Additionally, a currently
+unused control node, called controlD is also
+created. The primary node provides all legacy operations and
+historically was the only interface used by userspace. With KMS, the
+control node was introduced. However, the planned KMS control interface
+has never been written and so the control node stays unused to date.
+  
+  
+With the increased use of offscreen renderers and GPGPU applications,
+clients no longer require running compositors or graphics servers to
+make use of a GPU. But the DRM API required unprivileged clients to
+authenticate to a DRM-Master prior to getting GPU access. To avoid this
+step and to grant clients GPU access without authenticating, render
+nodes were introduced. Render nodes solely serve render clients, that
+is, no modesetting or privileged ioctls can be issued on render nodes.
+Only non-global rendering commands are allowed. If a driver supports
+render nodes, it must advertise it via the DRIVER_RENDER
+DRM driver capability. If not supported, the primary node must be used
+for render clients together with the legacy drmAuth authentication
+procedure.
+  
+  
+If a driver advertises render node support, DRM core will create a
+separate render node called renderD. There will
+be one render node per device. No ioctls except for
+GEM_CLOSE, GEM_FLINK and PRIME-related ioctls
+will be allowed on this node. Especially GEM_OPEN will be
+explicitly prohibited. Render nodes are designed to avoid the
+buffer-leaks, which occur if clients guess the flink names or mmap
+offsets on the legacy interface. Additionally to this basic interface,
+drivers must mark their driver-dependent ren

[PATCH v2 3/6] drm: verify vma access in TTM+GEM drivers

[David Herrmann]

GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0. (note that verify_access() returns 0 on success, unlike
drm_vma_node_is_allowed() which returns "true").

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

Cc: Dave Airlie 
Cc: Alex Deucher 
Cc: Ben Skeggs 
Cc: Maarten Lankhorst 
Cc: Jerome Glisse 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/ast/ast_ttm.c | 4 +++-
 drivers/gpu/drm/cirrus/cirrus_ttm.c   | 4 +++-
 drivers/gpu/drm/mgag200/mgag200_ttm.c | 4 +++-
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 4 +++-
 drivers/gpu/drm/qxl/qxl_ttm.c | 4 +++-
 drivers/gpu/drm/radeon/radeon_ttm.c   | 4 +++-
 6 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index cf1c833..ae6c335 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -148,7 +148,9 @@ ast_bo_evict_flags(struct ttm_buffer_object *bo, struct 
ttm_placement *pl)

 static int ast_bo_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct ast_bo *astbo = ast_bo(bo);
+
+   return !drm_vma_node_is_allowed(&astbo->gem.vma_node, filp);
 }

 static int ast_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bf8a506..dd12b60 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -148,7 +148,9 @@ cirrus_bo_evict_flags(struct ttm_buffer_object *bo, struct 
ttm_placement *pl)

 static int cirrus_bo_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct cirrus_bo *cirrusbo = cirrus_bo(bo);
+
+   return !drm_vma_node_is_allowed(&cirrusbo->gem.vma_node, filp);
 }

 static int cirrus_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 6cf3fa0..a9f96b9 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -148,7 +148,9 @@ mgag200_bo_evict_flags(struct ttm_buffer_object *bo, struct 
ttm_placement *pl)

 static int mgag200_bo_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct mgag200_bo *mgabo = mgag200_bo(bo);
+
+   return !drm_vma_node_is_allowed(&mgabo->gem.vma_node, filp);
 }

 static int mgag200_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4e7ee5f..554a5af 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1260,7 +1260,9 @@ out:
 static int
 nouveau_bo_verify_access(struct ttm_buffer_object *bo, struct file *filp)
 {
-   return 0;
+   struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+   return !drm_vma_node_is_allowed(&nvbo->gem->vma_node, filp);
 }

 static int
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 1dfd84c..497fb6d 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -212,7 +212,9 @@ static void qxl_evict_flags(struct ttm_buffer_object *bo,

 static int qxl_verify_access(struct ttm_buffer_object *bo, struct file *filp)
 {
-   return 0;
+   struct qxl_bo *qbo = to_qxl_bo(bo);
+
+   return !drm_vma_node_is_allowed(&qbo->gem_base.vma_node, filp);
 }

 static int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 6c0ce89..072e2d7 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -203,7 +203,9 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo,

 static int radeon_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
+
+   return !drm_vma_node_is_allowed(&rbo->gem_base.vma_node, filp);
 }

 static void radeon_move_null(struct ttm_buffer_object *bo,
-- 
1.8.3.4

[PATCH v2 2/6] drm/gem: implement vma access management

[David Herrmann]

We implement automatic vma mmap() access management for all drivers using
gem_mmap. We use the vma manager to add each open-file that creates a
gem-handle to the vma-node of the underlying gem object. Once the handle
is destroyed, we drop the open-file again.

This allows us to use drm_vma_node_is_allowed() on _any_ gem object to see
whether an open-file is granted access. In drm_gem_mmap() we use this to
verify that unprivileged users cannot guess gem offsets and map arbitrary
buffers.

Note that this manages access for _all_ gem users (also TTM+GEM), but the
actual access checks are only done for drm_gem_mmap(). TTM drivers use the
TTM mmap helpers, which need to do that separately.

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_gem.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index d6122ae..b2d59b2 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -298,6 +298,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
spin_unlock(&filp->table_lock);

drm_gem_remove_prime_handles(obj, filp);
+   drm_vma_node_revoke(&obj->vma_node, filp->filp);

if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, filp);
@@ -357,6 +358,11 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
}
*handlep = ret;

+   ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
+   if (ret) {
+   drm_gem_handle_delete(file_priv, *handlep);
+   return ret;
+   }

if (dev->driver->gem_open_object) {
ret = dev->driver->gem_open_object(obj, file_priv);
@@ -701,6 +707,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
struct drm_device *dev = obj->dev;

drm_gem_remove_prime_handles(obj, file_priv);
+   drm_vma_node_revoke(&obj->vma_node, file_priv->filp);

if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, file_priv);
@@ -793,6 +800,10 @@ EXPORT_SYMBOL(drm_gem_vm_close);
  * the GEM object is not looked up based on its fake offset. To implement the
  * DRM mmap operation, drivers should use the drm_gem_mmap() function.
  *
+ * drm_gem_mmap_obj() assumes the user is granted access to the buffer while
+ * drm_gem_mmap() prevents unprivileged users from mapping random objects. So
+ * callers must verify access restrictions before calling this helper.
+ *
  * NOTE: This function has to be protected with dev->struct_mutex
  *
  * Return 0 or success or -EINVAL if the object size is smaller than the VMA
@@ -841,6 +852,9 @@ EXPORT_SYMBOL(drm_gem_mmap_obj);
  * Look up the GEM object based on the offset passed in (vma->vm_pgoff will
  * contain the fake offset we created when the GTT map ioctl was called on
  * the object) and map it with a call to drm_gem_mmap_obj().
+ *
+ * If the caller is not granted access to the buffer object, the mmap will fail
+ * with EACCES. Please see the vma manager for more information.
  */
 int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 {
@@ -861,6 +875,9 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
if (!node) {
mutex_unlock(&dev->struct_mutex);
return drm_mmap(filp, vma);
+   } else if (!drm_vma_node_is_allowed(node, filp)) {
+   mutex_unlock(&dev->struct_mutex);
+   return -EACCES;
}

obj = container_of(node, struct drm_gem_object, vma_node);
-- 
1.8.3.4

[PATCH v2 1/6] drm/vma: add access management helpers

[David Herrmann]

The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.

We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.

We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.

As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
 - Most times only a single filp is added per bo so we could use a static
   "struct file *main_filp" which is checked/added/removed first before we
   fall back to the rbtree+drm_vma_offset_file.
   This could be even done lockless with rcu.
 - Let user-space pass a hint whether mmap() should be supported on the
   bo and avoid access-management if not.
 - .. there are probably more ideas once we have benchmarks ..

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_gem.c |   1 +
 drivers/gpu/drm/drm_vma_manager.c | 155 ++
 include/drm/drm_vma_manager.h |  21 +-
 3 files changed, 174 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1ce88c3..d6122ae 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -156,6 +156,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
kref_init(&obj->refcount);
obj->handle_count = 0;
obj->size = size;
+   drm_vma_node_reset(&obj->vma_node);
 }
 EXPORT_SYMBOL(drm_gem_private_object_init);

diff --git a/drivers/gpu/drm/drm_vma_manager.c 
b/drivers/gpu/drm/drm_vma_manager.c
index 3837481..63b4712 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +59,13 @@
  * must always be page-aligned (as usual).
  * If you want to get a valid byte-based user-space address for a given offset,
  * please see drm_vma_node_offset_addr().
+ *
+ * Additionally to offset management, the vma offset manager also handles 
access
+ * management. For every open-file context that is allowed to access a given
+ * node, you must call drm_vma_node_allow(). Otherwise, an mmap() call on this
+ * open-file with the offset of the node will fail with -EACCES. To revoke
+ * access again, use drm_vma_node_revoke(). However, the caller is responsible
+ * for destroying already existing mappings, if required.
  */

 /**
@@ -279,3 +287,150 @@ void drm_vma_offset_remove(struct drm_vma_offset_manager 
*mgr,
write_unlock(&mgr->vm_lock);
 }
 EXPORT_SYMBOL(drm_vma_offset_remove);
+
+/**
+ * drm_vma_node_allow - Add open-file to list of allowed users
+ * @node: Node to modify
+ * @filp: Open file to add
+ *
+ * Add @filp to the list of allowed open-files for this node. If @filp is
+ * already on this list, the ref-count is incremented.
+ *
+ * The list of allowed-users is preserved across drm_vma_offset_add() and
+ * drm_vma_offset_remove() calls. You may even call it if the node is currently
+ * not added to any offset-manager.
+ *
+ * You must remove all open-files the same number of times as you added them
+ * before destroying the node. Otherwise, you will leak memory.
+ *
+ * This is locked against concurrent access internally.
+ *
+ * RETURNS:
+ * 0 on success, negative error code on internal failure (out-of-mem)
+ */
+int drm_vma_node_allow(struct drm_vma_offset_node *node, struct file *filp)
+{
+   struct rb_node **iter;
+   struct rb_node *parent = NULL;
+   struct drm_vma_offset_file *new, *entry;
+   int ret = 0;
+
+   /* Preallocate entry to avoid atomic allocations below. It is quite
+* unlikely that an open-file is added twice to a single node so we
+* don't optimize for this case. OOM is checked below only if the entry
+* is actually used. */
+   new = kmalloc(sizeof(*entry), GFP_KERNEL);
+
+   write_lock(&node->vm_lock);
+
+   iter = &node->vm_files.rb_node;
+
+   while (likely(*iter)) {
+   parent = *iter;
+   entry = rb_entry(*iter, struct drm_vma_offset_file, vm_rb);
+
+   if (filp == entry->vm_filp) {
+   entry->vm_count++;
+   goto unlock;
+   } else if (filp > entry->vm_filp) {
+   iter = &(*iter)->rb_right;
+   } else {
+   iter = &(*iter)->rb_left;
+   }
+   }
+
+   if (!new) {
+   ret = -ENOMEM

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[David Herrmann]

Hi

I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify_access() callback to get access to the underlying gem-object. Pretty
simple.. Why hadn't I thought of that before?

Long story short: All drivers using GEM are safe now. This leaves vmwgfx.. But
they do their own access-management, anyway.

The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
command-line or via sysfs _before_ loading a driver. Otherwise, render nodes
will not be created.

This allows us to test render-nodes and play with the API. I added FLINK for
now so we can better test it. Not sure whether we should allow it in the end,
though.

Maybe we can get this into 3.11?

Regards
David

David Herrmann (4):
  drm/vma: add access management helpers
  drm/gem: implement vma access management
  drm: verify vma access in TTM+GEM drivers
  drm: implement experimental render nodes

Kristian H?gsberg (1):
  drm/i915: Support render nodes

Martin Peres (1):
  drm/nouveau: Support render nodes

 Documentation/DocBook/drm.tmpl|  71 
 drivers/gpu/drm/ast/ast_ttm.c |   4 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c   |   4 +-
 drivers/gpu/drm/drm_drv.c |  15 ++--
 drivers/gpu/drm/drm_fops.c|  14 +--
 drivers/gpu/drm/drm_gem.c |  18 
 drivers/gpu/drm/drm_pci.c |   9 ++
 drivers/gpu/drm/drm_platform.c|   9 ++
 drivers/gpu/drm/drm_stub.c|  10 +++
 drivers/gpu/drm/drm_usb.c |   9 ++
 drivers/gpu/drm/drm_vma_manager.c | 155 ++
 drivers/gpu/drm/i915/i915_dma.c   |  36 
 drivers/gpu/drm/i915/i915_drv.c   |   3 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c |   4 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   4 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c |  24 +++---
 drivers/gpu/drm/qxl/qxl_ttm.c |   4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   |   4 +-
 include/drm/drmP.h|   9 ++
 include/drm/drm_vma_manager.h |  21 -
 20 files changed, 373 insertions(+), 54 deletions(-)

-- 
1.8.3.4

[PATCH -next] drm/rcar-du: fix return value check in rcar_du_lvdsenc_get_resources()

[Laurent Pinchart]

Hello,

On Friday 23 August 2013 10:21:21 Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun 

Thank you for the patch.

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c index a0f6a17..f59cbc4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -151,11 +151,8 @@ static int rcar_du_lvdsenc_get_resources(struct
> rcar_du_lvdsenc *lvds, }
> 
>   lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);

devm_ioremap_resource() prints an error message when the second argument is 
NULL, so we can remove the error check after the 
platform_get_resource_byname() call as well. The resulting code could look 
like

mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
if (IS_ERR(lvds->mmio))
return PTR_ERR(lvds->mmio);

Could you please submit a v2 ?

> - if (lvds->mmio == NULL) {
> - dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
> - name);
> - return -ENOMEM;
> - }
> + if (IS_ERR(lvds->mmio))
> + return PTR_ERR(lvds->mmio);
> 
>   lvds->clock = devm_clk_get(&pdev->dev, name);
>   if (IS_ERR(lvds->clock)) {
-- 
Regards,

Laurent Pinchart

[PATCH] drm/nouveau/i2c: pass the function pointers in at creation time

[Ilia Mirkin]

i2c_bit_add_bus can call the pre_xfer function, which expects the func
pointer to be set. Pass in func to the port creation logic so that it is
set before i2c_bit_add_bus.

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

Reported-by: Hans-Peter Deifel 
Tested-by: Hans-Peter Deifel 
Signed-off-by: Ilia Mirkin 
---

This will only happen if i2c_algo_bit.bit_test=1.

 drivers/gpu/drm/nouveau/core/include/subdev/i2c.h |  8 +---
 drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
 drivers/gpu/drm/nouveau/core/subdev/i2c/base.c|  2 ++
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c|  4 ++--
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c|  4 ++--
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c|  4 ++--
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c|  8 
 drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c|  4 ++--
 8 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
index 888384c..7e4e277 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
@@ -39,8 +39,8 @@ struct nouveau_i2c_func {
int  (*drv_ctl)(struct nouveau_i2c_port *, int lane, int sw, int pe);
 };

-#define nouveau_i2c_port_create(p,e,o,i,a,d)   
\
-   nouveau_i2c_port_create_((p), (e), (o), (i), (a),  \
+#define nouveau_i2c_port_create(p,e,o,i,a,f,d) 
\
+   nouveau_i2c_port_create_((p), (e), (o), (i), (a), (f), \
 sizeof(**d), (void **)d)
 #define nouveau_i2c_port_destroy(p) ({ 
\
struct nouveau_i2c_port *port = (p);   \
@@ -53,7 +53,9 @@ struct nouveau_i2c_func {

 int nouveau_i2c_port_create_(struct nouveau_object *, struct nouveau_object *,
 struct nouveau_oclass *, u8,
-const struct i2c_algorithm *, int, void **);
+const struct i2c_algorithm *,
+const struct nouveau_i2c_func *,
+int, void **);
 void _nouveau_i2c_port_dtor(struct nouveau_object *);
 #define _nouveau_i2c_port_init nouveau_object_init
 #define _nouveau_i2c_port_fini nouveau_object_fini
diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
index dec94e9..4b195ac 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
@@ -118,7 +118,8 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
int ret;

ret = nouveau_i2c_port_create(parent, engine, oclass, index,
-&nouveau_i2c_aux_algo, &chan);
+ &nouveau_i2c_aux_algo, &anx9805_aux_func,
+ &chan);
*pobject = nv_object(chan);
if (ret)
return ret;
@@ -140,8 +141,6 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
algo->udelay = max(algo->udelay, 40);
}
-
-   chan->base.func = &anx9805_aux_func;
return 0;
 }

@@ -234,7 +233,8 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
int ret;

ret = nouveau_i2c_port_create(parent, engine, oclass, index,
-&anx9805_i2c_algo, &port);
+ &anx9805_i2c_algo, &anx9805_i2c_func,
+ &port);
*pobject = nv_object(port);
if (ret)
return ret;
@@ -256,8 +256,6 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
algo->udelay = max(algo->udelay, 40);
}
-
-   port->base.func = &anx9805_i2c_func;
return 0;
 }

diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
index 8ae2625..2895c19 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
@@ -95,6 +95,7 @@ nouveau_i2c_port_create_(struct nouveau_object *parent,
 struct nouveau_object *engine,
 struct nouveau_oclass *oclass, u8 index,
 const struct i2c_algorithm *algo,
+const struct nouveau_i2c_func *func,
 int size, void **pobject)
 {
struct nouveau_device *device = nv_device(parent);
@@ -112,6 +113,7 @@ nouveau_i2c_port_create_(struct nouveau_object *parent,
port->adapter.owner = THIS_MODULE;
port->adapter.dev.parent = &device->pdev->dev;
port->index = ind

[PATCH v2 5/6] drm/i915: Support render nodes

[Chris Wilson]

On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian H?gsberg 
> 
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Kristian H?gsberg 
> Signed-off-by: David Herrmann 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>  2 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 0adfe40..ecf5ecd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
> @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
> DRM_AUTH|DRM_UNLOCKED),
execbuffer also

> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
> DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
> DRM_UNLOCKED),
set/get caching

> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID, 
> intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
> - DRM_

Re: [patch 2/2] gpu: host1x: returning success instead of -ENOMEM

[Stephen Warren]

On 08/23/2013 04:19 AM, Dan Carpenter wrote:
> There is a mistake here so it returns PTR_ERR(NULL) which is success
> instead of -ENOMEM.
> 
> Signed-off-by: Dan Carpenter 
> ---
> I can't compile this.

For the record, just do:

export CROSS_COMPILE=xxx
make ARCH=arm tegra_defconfig
make ARCH=arm zImage

The only slightly difficult part is getting a CROSS_COMPILE value. Many
distros ship at least some ARM cross-compiler in their standard
package-set these days, and if not, you can download the Linaro
compilers or go to ftp://ftp.kernel.org/pub/tools/crosstool/index.html.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create

[Vikas Sajjan]

To address the case where physically contiguous memory MAY NOT be a mandatory
requirement for framebuffer for the application calling 
exynos_drm_gem_dumb_create,
the patch adds a feature to get non physically contiguous memory for 
framebuffer,
if physically contiguous memory allocation fails and if IOMMU is supported.

Signed-off-by: Vikas Sajjan 
Signed-off-by: Arun Kumar 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2eabe1a..66d1b40 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -17,6 +17,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_buf.h"
+#include "exynos_drm_iommu.h"

 static unsigned int convert_to_vm_err_msg(int msg)
 {
@@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,

exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
EXYNOS_BO_WC, args->size);
+   /*
+* If physically contiguous memory allocation fails and if IOMMU is
+* supported then try to get buffer from non physically contiguous
+* memory area.
+*/
+   if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
+   dev_warn(dev->dev, "contiguous FB allocation failed, falling 
back to non-contiguous\n");
+   exynos_gem_obj = exynos_drm_gem_create(dev,
+   EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
+   args->size);
+   }
+
if (IS_ERR(exynos_gem_obj))
return PTR_ERR(exynos_gem_obj);

-- 
1.7.9.5

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

Ben was on holidays for a week so a few nouveau regression fixes backed 
up, but they all seem necessary, otherwise one i915 and one gma500 fix.

Dave.

The following changes since commit 3387ed83943daf6cb1bb4195ae369067b9cd80ce:

  Merge tag 'drm-intel-fixes-2013-08-15' of 
git://people.freedesktop.org/~danvet/drm-intel (2013-08-19 13:49:20 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 4dd17ee95742f3e9fd55d07463981711a637bd20:

  Merge tag 'drm-intel-fixes-2013-08-23' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-23 
18:52:37 +1000)



Ben Skeggs (2):
  drm/nouveau/mc: fix race condition between constructor and request_irq()
  drm/nv04/disp: fix framebuffer pin refcounting

Chris Wilson (1):
  drm/i915: Invalidate TLBs for the rings after a reset

Dave Airlie (2):
  Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge tag 'drm-intel-fixes-2013-08-23' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Guillaume Clement (1):
  gma500: Fix SDVO turning off randomly

Ilia Mirkin (1):
  drm/nouveau/fb: fix null derefs in nv49 and nv4e init

Maarten Lankhorst (2):
  drm/nouveau/ltcg: fix ltcg memory initialization after suspend
  drm/nouveau/ltcg: fix allocating memory as free

Pali Roh?r (1):
  drm/nouveau: fix reclocking on nv40

 drivers/gpu/drm/gma500/psb_intel_sdvo.c  |  3 +-
 drivers/gpu/drm/i915/i915_reg.h  |  2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 12 +
 drivers/gpu/drm/nouveau/core/core/mm.c   |  4 ++
 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  7 +--
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c | 12 ++---
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c |  4 +-
 drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c  | 34 ++
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c|  6 ++-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv98.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nvc0.c|  3 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c  | 58 ++--
 drivers/gpu/drm/nouveau/dispnv04/disp.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_display.c|  3 ++
 drivers/gpu/drm/nouveau/nv40_pm.c|  2 +-
 18 files changed, 114 insertions(+), 49 deletions(-)

[PATCH v3 1/1] ARM: dts: AM33XX: Add LCDC info into am335x-evm

[Benoit Parrot]

Add LCDC device node in DT for am33xx
Add LCDC and Panel info in DT for am335x-evm

Changes in v3:
- rebase to 3.11-rc6

Changes in v2:
- remove redundant/unnecessary SoC specific setting in the board dts

Signed-off-by: Benoit Parrot 
---
 arch/arm/boot/dts/am335x-evm.dts |   72 ++
 arch/arm/boot/dts/am33xx.dtsi|9 +
 2 files changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..b0703f1 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -149,6 +149,40 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
+
+   lcd_pins_s0: lcd_pins_s0 {
+   pinctrl-single,pins = <
+   0x20 0x01   /* gpmc_ad8.lcd_data16, OUTPUT 
| MODE1 */
+   0x24 0x01   /* gpmc_ad9.lcd_data17, OUTPUT 
| MODE1 */
+   0x28 0x01   /* gpmc_ad10.lcd_data18, OUTPUT 
| MODE1 */
+   0x2c 0x01   /* gpmc_ad11.lcd_data19, OUTPUT 
| MODE1 */
+   0x30 0x01   /* gpmc_ad12.lcd_data20, OUTPUT 
| MODE1 */
+   0x34 0x01   /* gpmc_ad13.lcd_data21, OUTPUT 
| MODE1 */
+   0x38 0x01   /* gpmc_ad14.lcd_data22, OUTPUT 
| MODE1 */
+   0x3c 0x01   /* gpmc_ad15.lcd_data23, OUTPUT 
| MODE1 */
+   0xa0 0x00   /* lcd_data0.lcd_data0, OUTPUT 
| MODE0 */
+   0xa4 0x00   /* lcd_data1.lcd_data1, OUTPUT 
| MODE0 */
+   0xa8 0x00   /* lcd_data2.lcd_data2, OUTPUT 
| MODE0 */
+   0xac 0x00   /* lcd_data3.lcd_data3, OUTPUT 
| MODE0 */
+   0xb0 0x00   /* lcd_data4.lcd_data4, OUTPUT 
| MODE0 */
+   0xb4 0x00   /* lcd_data5.lcd_data5, OUTPUT 
| MODE0 */
+   0xb8 0x00   /* lcd_data6.lcd_data6, OUTPUT 
| MODE0 */
+   0xbc 0x00   /* lcd_data7.lcd_data7, OUTPUT 
| MODE0 */
+   0xc0 0x00   /* lcd_data8.lcd_data8, OUTPUT 
| MODE0 */
+   0xc4 0x00   /* lcd_data9.lcd_data9, OUTPUT 
| MODE0 */
+   0xc8 0x00   /* lcd_data10.lcd_data10, 
OUTPUT | MODE0 */
+   0xcc 0x00   /* lcd_data11.lcd_data11, 
OUTPUT | MODE0 */
+   0xd0 0x00   /* lcd_data12.lcd_data12, 
OUTPUT | MODE0 */
+   0xd4 0x00   /* lcd_data13.lcd_data13, 
OUTPUT | MODE0 */
+   0xd8 0x00   /* lcd_data14.lcd_data14, 
OUTPUT | MODE0 */
+   0xdc 0x00   /* lcd_data15.lcd_data15, 
OUTPUT | MODE0 */
+   0xe0 0x00   /* lcd_vsync.lcd_vsync, OUTPUT 
| MODE0 */
+   0xe4 0x00   /* lcd_hsync.lcd_hsync, OUTPUT 
| MODE0 */
+   0xe8 0x00   /* lcd_pclk.lcd_pclk, OUTPUT | 
MODE0 */
+   0xec 0x00   /* 
lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
+   >;
+   };
+
};

ocp {
@@ -311,6 +345,10 @@
};
};
};
+
+   lcdc: lcdc at 4830e000 {
+   status = "okay";
+   };
};

vbat: fixedregulator at 0 {
@@ -374,6 +412,40 @@
brightness-levels = <0 51 53 56 62 75 101 152 255>;
default-brightness-level = <8>;
};
+
+   panel {
+   compatible = "ti,tilcdc,panel";
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_pins_s0>;
+   panel-info {
+   ac-bias   = <255>;
+   ac-bias-intrpt= <0>;
+   dma-burst-sz  = <16>;
+   bpp   = <32>;
+   fdd   = <0x80>;
+   sync-edge = <0>;
+   sync-ctrl = <1>;
+   raster-order  = <0>;
+   fifo-th   = <0>;
+   };
+
+   display-timings {
+   800x480p62 {
+   clock-frequency = <3000>;
+   hactive = <800>;
+   vactive = <480>;
+   hfront-porch = <39>;
+   hback-porch = <39>;
+   hsync-len = <47>;
+   vback-porch = <29>;
+

[PATCH V3] i2c: move of helpers into the core

[Wolfram Sang]

On Thu, Aug 22, 2013 at 06:00:14PM +0200, Wolfram Sang wrote:
> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Felipe Balbi 
> Acked-by: Rafael J. Wysocki 
> Tested-by: Sylwester Nawrocki 
> Signed-off-by: Wolfram Sang 

Applied to for-next!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/a3c35475/attachment-0001.pgp>

[PULL] drm-intel-fixes

[Daniel Vetter]

Argh, forgotten to cc lists!

On Fri, Aug 23, 2013 at 10:42:37AM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Just one patch that soaked for quite a bit to fix a resume issue,
> resulting in gpu hangs (or worse) due to tlb containing garbage.
> 
> Cheers, Daniel
> 
> 
> The following changes since commit 63b66e5ba54b15a6592be00555d762db6db739ce:
> 
>   drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code 
> (2013-08-14 20:26:49 +0200)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~danvet/drm-intel 
> tags/drm-intel-fixes-2013-08-23
> 
> for you to fetch changes up to 884020bf3d2a3787a1cc6df902e98e0eec60330b:
> 
>   drm/i915: Invalidate TLBs for the rings after a reset (2013-08-18 19:37:41 
> +0200)
> 
> 
> Chris Wilson (1):
>   drm/i915: Invalidate TLBs for the rings after a reset
> 
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 12 
>  2 files changed, 14 insertions(+)
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

[bugzilla-daemon]

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

--- Comment #36 from Alex Deucher  ---
Starting with kernel 3.11 you can enable the dynamic power management hardware
on the gpu by booting with radeon.dpm=1 on the kernel command line in grub. 
You will also need the latest smc firmware for your card.

-- 
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 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

[bugzilla-daemon]

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

--- Comment #35 from Neil Connolly  ---
I have the same overheating problem with a Sony Vaio i5 with ATI Redeon 5400
graphics.
Idle temperature quickly rises to 70oC and then any desktop activity takes the
temperature into the 80's. Running a video fullscreen causes the machine to
shutdown.

-- 
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

[PATCH -next] drm/rcar-du: fix return value check in rcar_du_lvdsenc_get_resources()

[Wei Yongjun]

From: Wei Yongjun 

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index a0f6a17..f59cbc4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -151,11 +151,8 @@ static int rcar_du_lvdsenc_get_resources(struct 
rcar_du_lvdsenc *lvds,
}

lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
-   if (lvds->mmio == NULL) {
-   dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
-   name);
-   return -ENOMEM;
-   }
+   if (IS_ERR(lvds->mmio))
+   return PTR_ERR(lvds->mmio);

lvds->clock = devm_clk_get(&pdev->dev, name);
if (IS_ERR(lvds->clock)) {

[PATCH] drm/nouveau/i2c: pass the function pointers in at creation time

[Ilia Mirkin]

i2c_bit_add_bus can call the pre_xfer function, which expects the func
pointer to be set. Pass in func to the port creation logic so that it is
set before i2c_bit_add_bus.

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

Reported-by: Hans-Peter Deifel 
Tested-by: Hans-Peter Deifel 
Signed-off-by: Ilia Mirkin 
---

This will only happen if i2c_algo_bit.bit_test=1.

 drivers/gpu/drm/nouveau/core/include/subdev/i2c.h |  8 +---
 drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
 drivers/gpu/drm/nouveau/core/subdev/i2c/base.c|  2 ++
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c|  4 ++--
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c|  4 ++--
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c|  4 ++--
 drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c|  8 
 drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c|  4 ++--
 8 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
index 888384c..7e4e277 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
@@ -39,8 +39,8 @@ struct nouveau_i2c_func {
int  (*drv_ctl)(struct nouveau_i2c_port *, int lane, int sw, int pe);
 };
 
-#define nouveau_i2c_port_create(p,e,o,i,a,d)   
\
-   nouveau_i2c_port_create_((p), (e), (o), (i), (a),  \
+#define nouveau_i2c_port_create(p,e,o,i,a,f,d) 
\
+   nouveau_i2c_port_create_((p), (e), (o), (i), (a), (f), \
 sizeof(**d), (void **)d)
 #define nouveau_i2c_port_destroy(p) ({ 
\
struct nouveau_i2c_port *port = (p);   \
@@ -53,7 +53,9 @@ struct nouveau_i2c_func {
 
 int nouveau_i2c_port_create_(struct nouveau_object *, struct nouveau_object *,
 struct nouveau_oclass *, u8,
-const struct i2c_algorithm *, int, void **);
+const struct i2c_algorithm *,
+const struct nouveau_i2c_func *,
+int, void **);
 void _nouveau_i2c_port_dtor(struct nouveau_object *);
 #define _nouveau_i2c_port_init nouveau_object_init
 #define _nouveau_i2c_port_fini nouveau_object_fini
diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
index dec94e9..4b195ac 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
@@ -118,7 +118,8 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
int ret;
 
ret = nouveau_i2c_port_create(parent, engine, oclass, index,
-&nouveau_i2c_aux_algo, &chan);
+ &nouveau_i2c_aux_algo, &anx9805_aux_func,
+ &chan);
*pobject = nv_object(chan);
if (ret)
return ret;
@@ -140,8 +141,6 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
algo->udelay = max(algo->udelay, 40);
}
-
-   chan->base.func = &anx9805_aux_func;
return 0;
 }
 
@@ -234,7 +233,8 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
int ret;
 
ret = nouveau_i2c_port_create(parent, engine, oclass, index,
-&anx9805_i2c_algo, &port);
+ &anx9805_i2c_algo, &anx9805_i2c_func,
+ &port);
*pobject = nv_object(port);
if (ret)
return ret;
@@ -256,8 +256,6 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
algo->udelay = max(algo->udelay, 40);
}
-
-   port->base.func = &anx9805_i2c_func;
return 0;
 }
 
diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
index 8ae2625..2895c19 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
@@ -95,6 +95,7 @@ nouveau_i2c_port_create_(struct nouveau_object *parent,
 struct nouveau_object *engine,
 struct nouveau_oclass *oclass, u8 index,
 const struct i2c_algorithm *algo,
+const struct nouveau_i2c_func *func,
 int size, void **pobject)
 {
struct nouveau_device *device = nv_device(parent);
@@ -112,6 +113,7 @@ nouveau_i2c_port_create_(struct nouveau_object *parent,
port->adapter.owner = THIS_MODULE;
port->adapter.dev.parent = &device->pdev->dev;
port->index

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Alex Deucher]

On Fri, Aug 23, 2013 at 7:28 AM, Christian K?nig
 wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> all gem drivers are safe now. For TTM drivers, I now use the already
>> available
>> verify_access() callback to get access to the underlying gem-object.
>> Pretty
>> simple.. Why hadn't I thought of that before?
>>
>> Long story short: All drivers using GEM are safe now. This leaves vmwgfx..
>> But
>> they do their own access-management, anyway.
>>
>> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
>> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
>> command-line or via sysfs _before_ loading a driver. Otherwise, render
>> nodes
>> will not be created.
>>
>> This allows us to test render-nodes and play with the API. I added FLINK
>> for
>> now so we can better test it. Not sure whether we should allow it in the
>> end,
>> though.
>>
>> Maybe we can get this into 3.11?
>
>
> A bit unlikely, but 3.12 should work fine.
>
> I'm working on a project that can make good use of this, so if Alex doesn't
> mind like to add the necessary radeon flags (should be only a few one liners
> anyway).
>

No objections from me.

Alex

[PATCH v3 1/1] ARM: dts: AM33XX: Add LCDC info into am335x-evm

[Benoit Parrot]

Add LCDC device node in DT for am33xx
Add LCDC and Panel info in DT for am335x-evm

Changes in v3:
- rebase to 3.11-rc6

Changes in v2:
- remove redundant/unnecessary SoC specific setting in the board dts

Signed-off-by: Benoit Parrot 
---
 arch/arm/boot/dts/am335x-evm.dts |   72 ++
 arch/arm/boot/dts/am33xx.dtsi|9 +
 2 files changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..b0703f1 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -149,6 +149,40 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
+
+   lcd_pins_s0: lcd_pins_s0 {
+   pinctrl-single,pins = <
+   0x20 0x01   /* gpmc_ad8.lcd_data16, OUTPUT 
| MODE1 */
+   0x24 0x01   /* gpmc_ad9.lcd_data17, OUTPUT 
| MODE1 */
+   0x28 0x01   /* gpmc_ad10.lcd_data18, OUTPUT 
| MODE1 */
+   0x2c 0x01   /* gpmc_ad11.lcd_data19, OUTPUT 
| MODE1 */
+   0x30 0x01   /* gpmc_ad12.lcd_data20, OUTPUT 
| MODE1 */
+   0x34 0x01   /* gpmc_ad13.lcd_data21, OUTPUT 
| MODE1 */
+   0x38 0x01   /* gpmc_ad14.lcd_data22, OUTPUT 
| MODE1 */
+   0x3c 0x01   /* gpmc_ad15.lcd_data23, OUTPUT 
| MODE1 */
+   0xa0 0x00   /* lcd_data0.lcd_data0, OUTPUT 
| MODE0 */
+   0xa4 0x00   /* lcd_data1.lcd_data1, OUTPUT 
| MODE0 */
+   0xa8 0x00   /* lcd_data2.lcd_data2, OUTPUT 
| MODE0 */
+   0xac 0x00   /* lcd_data3.lcd_data3, OUTPUT 
| MODE0 */
+   0xb0 0x00   /* lcd_data4.lcd_data4, OUTPUT 
| MODE0 */
+   0xb4 0x00   /* lcd_data5.lcd_data5, OUTPUT 
| MODE0 */
+   0xb8 0x00   /* lcd_data6.lcd_data6, OUTPUT 
| MODE0 */
+   0xbc 0x00   /* lcd_data7.lcd_data7, OUTPUT 
| MODE0 */
+   0xc0 0x00   /* lcd_data8.lcd_data8, OUTPUT 
| MODE0 */
+   0xc4 0x00   /* lcd_data9.lcd_data9, OUTPUT 
| MODE0 */
+   0xc8 0x00   /* lcd_data10.lcd_data10, 
OUTPUT | MODE0 */
+   0xcc 0x00   /* lcd_data11.lcd_data11, 
OUTPUT | MODE0 */
+   0xd0 0x00   /* lcd_data12.lcd_data12, 
OUTPUT | MODE0 */
+   0xd4 0x00   /* lcd_data13.lcd_data13, 
OUTPUT | MODE0 */
+   0xd8 0x00   /* lcd_data14.lcd_data14, 
OUTPUT | MODE0 */
+   0xdc 0x00   /* lcd_data15.lcd_data15, 
OUTPUT | MODE0 */
+   0xe0 0x00   /* lcd_vsync.lcd_vsync, OUTPUT 
| MODE0 */
+   0xe4 0x00   /* lcd_hsync.lcd_hsync, OUTPUT 
| MODE0 */
+   0xe8 0x00   /* lcd_pclk.lcd_pclk, OUTPUT | 
MODE0 */
+   0xec 0x00   /* 
lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
+   >;
+   };
+
};
 
ocp {
@@ -311,6 +345,10 @@
};
};
};
+
+   lcdc: lcdc@4830e000 {
+   status = "okay";
+   };
};
 
vbat: fixedregulator@0 {
@@ -374,6 +412,40 @@
brightness-levels = <0 51 53 56 62 75 101 152 255>;
default-brightness-level = <8>;
};
+
+   panel {
+   compatible = "ti,tilcdc,panel";
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_pins_s0>;
+   panel-info {
+   ac-bias   = <255>;
+   ac-bias-intrpt= <0>;
+   dma-burst-sz  = <16>;
+   bpp   = <32>;
+   fdd   = <0x80>;
+   sync-edge = <0>;
+   sync-ctrl = <1>;
+   raster-order  = <0>;
+   fifo-th   = <0>;
+   };
+
+   display-timings {
+   800x480p62 {
+   clock-frequency = <3000>;
+   hactive = <800>;
+   vactive = <480>;
+   hfront-porch = <39>;
+   hback-porch = <39>;
+   hsync-len = <47>;
+   vback-porch = <29>;
+

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

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

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

--- Comment #1 from Michel D?nzer  ---
> All of the above (except UVD, of course) work fine under 9.1.6

Can you bisect?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/aef75d0e/attachment.html>

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

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

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

adam777 at gmail.com changed:

   What|Removed |Added

Version|unspecified |9.2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/6bffa659/attachment.html>

[Bug 68468] New: 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

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

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

  Priority: medium
Bug ID: 68468
  Assignee: dri-devel at lists.freedesktop.org
   Summary: 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: adam777 at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: Drivers/DRI/R600
   Product: Mesa

Using 9.2.0rc2 on a fully updated Arch Linux (running on [testing]), the system
will lock under the following conditions:
1. When playing a movied in mpv using UVD video decoding, the system will lock
as soon as mpv finish the initial loading process and playback is about to
begin.
2. When playing a game in Wine, system will lock after a few seconds of launch.
3. From time to time, the system will lock for no apparent reason (for example,
it happened when using Google Maps).

All of the above (except UVD, of course) work fine under 9.1.6

Mesa Version: (for rc1, but rc2 have the same behavior)

[adamdagan at admdgn ~]$ glxinfo | grep ^OpenGL | egrep 'version|renderer'
OpenGL renderer string: Gallium 0.4 on AMD RV710
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0-rc1
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0-rc1
OpenGL shading language version string: 1.30

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/790953eb/attachment.html>

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

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

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

--- Comment #3 from Peter Kraus  ---
RE: Emil:
Possibly. I couldn't get a screenshot of the corruption, mine looked a lot
different, but it's definitely possible.

RE: Alex:
I'll try when I get back home and have some time (ie tomorrow). I might try and
follow the bisect of bug 67887, to see whether it's indeed a duplicate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/90977b32/attachment.html>

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

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

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

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/019d76f7/attachment-0001.html>

Re: [PATCH] drm/radeon: Support render nodes

[David Herrmann]

Hi

On Fri, Aug 23, 2013 at 3:45 PM, Christian König
 wrote:
> From: Christian König 
>
> Enable support for drm render nodes for radeon by flagging the ioctls that
> are safe and just needed for rendering.
>
> Signed-off-by: Christian König 

Looks good to me. I queued it locally. v3 will include it. If there's
no v3, I think Dave will pick it up from the list.

Thanks
David

> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |2 +-
>  drivers/gpu/drm/radeon/radeon_kms.c |   22 +++---
>  2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 1f93dd5..dffbb78 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -384,7 +384,7 @@ static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_USE_AGP |
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> -   DRIVER_PRIME,
> +   DRIVER_PRIME | DRIVER_RENDER,
> .dev_priv_size = 0,
> .load = radeon_driver_load_kms,
> .open = radeon_driver_open_kms,
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index b46a561..1593ee6 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -738,18 +738,18 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
> DRM_IOCTL_DEF_DRV(RADEON_SURF_ALLOC, radeon_surface_alloc_kms, 
> DRM_AUTH),
> DRM_IOCTL_DEF_DRV(RADEON_SURF_FREE, radeon_surface_free_kms, 
> DRM_AUTH),
> /* KMS */
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(RADEON_GEM_PREAD, radeon_gem_pread_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(RADEON_GEM_PWRITE, radeon_gem_pwrite_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> -   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>  };
>  int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
> --
> 1.7.9.5
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:drm-next-3.12-wip 31/90] WARNING: kfree(NULL) is safe this check is probably not required

[Fengguang Wu]

Hi Alex,

FYI, there are new warnings show up in

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-3.12-wip
head:   21419df38d4ba010b1ea80e2f91b853c8c3de7e5
commit: 38306848032ac045ac5a5f3145271bc01176883e [31/90] drm/radeon/dpm: add 
support for parsing the atom powertune table

scripts/checkpatch.pl 
0001-drm-radeon-dpm-add-support-for-parsing-the-atom-powe.patch

WARNING: kfree(NULL) is safe this check is probably not required
#73: drivers/gpu/drm/radeon/r600_dpm.c:1079:
+   if (rdev->pm.dpm.dyn_state.cac_tdp_table)
+   kfree(rdev->pm.dpm.dyn_state.cac_tdp_table);

The warning also shows up in many of the follow up patches.

[radeon-alex:drm-next-3.12-wip 32/90] WARNING: kfree(NULL) is safe
[radeon-alex:drm-next-3.12-wip 35/90] WARNING: kfree(NULL) is safe
[radeon-alex:drm-next-3.12-wip 36/90] WARNING: kfree(NULL) is safe
[radeon-alex:drm-next-3.12-wip 38/90] WARNING: kfree(NULL) is safe
[radeon-alex:drm-next-3.12-wip 39/90] WARNING: kfree(NULL) is safe

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation

[PATCH] drm/radeon: Support render nodes

[Christian König]

From: Christian König 

Enable support for drm render nodes for radeon by flagging the ioctls that
are safe and just needed for rendering.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_drv.c |2 +-
 drivers/gpu/drm/radeon/radeon_kms.c |   22 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 1f93dd5..dffbb78 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -384,7 +384,7 @@ static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
-   DRIVER_PRIME,
+   DRIVER_PRIME | DRIVER_RENDER,
.dev_priv_size = 0,
.load = radeon_driver_load_kms,
.open = radeon_driver_open_kms,
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index b46a561..1593ee6 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -738,18 +738,18 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(RADEON_SURF_ALLOC, radeon_surface_alloc_kms, 
DRM_AUTH),
DRM_IOCTL_DEF_DRV(RADEON_SURF_FREE, radeon_surface_free_kms, DRM_AUTH),
/* KMS */
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_PREAD, radeon_gem_pread_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(RADEON_GEM_PWRITE, radeon_gem_pwrite_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_INFO, radeon_info_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
-- 
1.7.9.5

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

Re: [PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Alex Deucher]

On Fri, Aug 23, 2013 at 7:28 AM, Christian König
 wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> all gem drivers are safe now. For TTM drivers, I now use the already
>> available
>> verify_access() callback to get access to the underlying gem-object.
>> Pretty
>> simple.. Why hadn't I thought of that before?
>>
>> Long story short: All drivers using GEM are safe now. This leaves vmwgfx..
>> But
>> they do their own access-management, anyway.
>>
>> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
>> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
>> command-line or via sysfs _before_ loading a driver. Otherwise, render
>> nodes
>> will not be created.
>>
>> This allows us to test render-nodes and play with the API. I added FLINK
>> for
>> now so we can better test it. Not sure whether we should allow it in the
>> end,
>> though.
>>
>> Maybe we can get this into 3.11?
>
>
> A bit unlikely, but 3.12 should work fine.
>
> I'm working on a project that can make good use of this, so if Alex doesn't
> mind like to add the necessary radeon flags (should be only a few one liners
> anyway).
>

No objections from me.

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

Re: [PATCH -next v2] drm/rcar-du: remove redundant dev_err call in rcar_du_lvdsenc_get_resources()

[Laurent Pinchart]

On Friday 23 August 2013 21:15:16 Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
> error message and check for return value of platform_get_resource_byname().
> 
> Signed-off-by: Wei Yongjun 

Acked-by: Laurent Pinchart 

Dave, could you please pick the patch up ?

> ---
> v1 -> v2; remove return value check of platform_get_resource_byname()
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c index a0f6a17..fe1f6f5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -144,18 +144,9 @@ static int rcar_du_lvdsenc_get_resources(struct
> rcar_du_lvdsenc *lvds, sprintf(name, "lvds.%u", lvds->index);
> 
>   mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
> - if (mem == NULL) {
> - dev_err(&pdev->dev, "failed to get memory resource for %s\n",
> - name);
> - return -EINVAL;
> - }
> -
>   lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
> - if (lvds->mmio == NULL) {
> - dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
> - name);
> - return -ENOMEM;
> - }
> + if (IS_ERR(lvds->mmio))
> + return PTR_ERR(lvds->mmio);
> 
>   lvds->clock = devm_clk_get(&pdev->dev, name);
>   if (IS_ERR(lvds->clock)) {

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Christian König]

Feel free to send a patch to dri-devel or just let me know the ioctls
and I will include it in this series.


Do you have a branch somewhere I can grab?

That's a bit easier than applying the patchset from the list.

Thanks,
Christian.

Am 23.08.2013 14:31, schrieb David Herrmann:

Hi

On Fri, Aug 23, 2013 at 1:28 PM, Christian König
 wrote:

Hi David,

Am 23.08.2013 13:13, schrieb David Herrmann:


Hi

I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this.
Hence,
all gem drivers are safe now. For TTM drivers, I now use the already
available
verify_access() callback to get access to the underlying gem-object.
Pretty
simple.. Why hadn't I thought of that before?

Long story short: All drivers using GEM are safe now. This leaves vmwgfx..
But
they do their own access-management, anyway.

The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
command-line or via sysfs _before_ loading a driver. Otherwise, render
nodes
will not be created.

This allows us to test render-nodes and play with the API. I added FLINK
for
now so we can better test it. Not sure whether we should allow it in the
end,
though.

Maybe we can get this into 3.11?


A bit unlikely, but 3.12 should work fine.

whoops, 3.12 of course.


I'm working on a project that can make good use of this, so if Alex doesn't
mind like to add the necessary radeon flags (should be only a few one liners
anyway).

Feel free to send a patch to dri-devel or just let me know the ioctls
and I will include it in this series.

Regards
David




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

Re: [PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Christian König]

Hi David,

Am 23.08.2013 13:13, schrieb David Herrmann:

Hi

I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify_access() callback to get access to the underlying gem-object. Pretty
simple.. Why hadn't I thought of that before?

Long story short: All drivers using GEM are safe now. This leaves vmwgfx.. But
they do their own access-management, anyway.

The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
command-line or via sysfs _before_ loading a driver. Otherwise, render nodes
will not be created.

This allows us to test render-nodes and play with the API. I added FLINK for
now so we can better test it. Not sure whether we should allow it in the end,
though.

Maybe we can get this into 3.11?


A bit unlikely, but 3.12 should work fine.

I'm working on a project that can make good use of this, so if Alex 
doesn't mind like to add the necessary radeon flags (should be only a 
few one liners anyway).


Cheers,
Christian.


Regards
David

David Herrmann (4):
   drm/vma: add access management helpers
   drm/gem: implement vma access management
   drm: verify vma access in TTM+GEM drivers
   drm: implement experimental render nodes

Kristian Høgsberg (1):
   drm/i915: Support render nodes

Martin Peres (1):
   drm/nouveau: Support render nodes

  Documentation/DocBook/drm.tmpl|  71 
  drivers/gpu/drm/ast/ast_ttm.c |   4 +-
  drivers/gpu/drm/cirrus/cirrus_ttm.c   |   4 +-
  drivers/gpu/drm/drm_drv.c |  15 ++--
  drivers/gpu/drm/drm_fops.c|  14 +--
  drivers/gpu/drm/drm_gem.c |  18 
  drivers/gpu/drm/drm_pci.c |   9 ++
  drivers/gpu/drm/drm_platform.c|   9 ++
  drivers/gpu/drm/drm_stub.c|  10 +++
  drivers/gpu/drm/drm_usb.c |   9 ++
  drivers/gpu/drm/drm_vma_manager.c | 155 ++
  drivers/gpu/drm/i915/i915_dma.c   |  36 
  drivers/gpu/drm/i915/i915_drv.c   |   3 +-
  drivers/gpu/drm/mgag200/mgag200_ttm.c |   4 +-
  drivers/gpu/drm/nouveau/nouveau_bo.c  |   4 +-
  drivers/gpu/drm/nouveau/nouveau_drm.c |  24 +++---
  drivers/gpu/drm/qxl/qxl_ttm.c |   4 +-
  drivers/gpu/drm/radeon/radeon_ttm.c   |   4 +-
  include/drm/drmP.h|   9 ++
  include/drm/drm_vma_manager.h |  21 -
  20 files changed, 373 insertions(+), 54 deletions(-)




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

Re: [PATCH V3] i2c: move of helpers into the core

[Wolfram Sang]

On Thu, Aug 22, 2013 at 06:00:14PM +0200, Wolfram Sang wrote:
> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Felipe Balbi 
> Acked-by: Rafael J. Wysocki 
> Tested-by: Sylwester Nawrocki 
> Signed-off-by: Wolfram Sang 

Applied to for-next!


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

Re: [PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[David Herrmann]

Hi

On Fri, Aug 23, 2013 at 2:34 PM, Christian König
 wrote:
>> Feel free to send a patch to dri-devel or just let me know the ioctls
>> and I will include it in this series.
>
>
> Do you have a branch somewhere I can grab?
>
> That's a bit easier than applying the patchset from the list.

https://github.com/dvdhrm/linux/commits/rnodes
I rebase it on update, so don't "git pull" it.

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

[Bug 67800] Computer freezes after idle for several hours (trinity)

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

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

--- Comment #9 from Kertesz Laszlo  ---
I may have found a crude workaround for the freezing issue.
It seems that if i completely disable screensaver (it was turning the monitor
off with dpms after 4 minutes) and leave the monitor on permanently works. I
now have 1 day uptime.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/d65b5a2e/attachment.html>

Re: [PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[David Herrmann]

Hi

On Fri, Aug 23, 2013 at 1:28 PM, Christian König
 wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> all gem drivers are safe now. For TTM drivers, I now use the already
>> available
>> verify_access() callback to get access to the underlying gem-object.
>> Pretty
>> simple.. Why hadn't I thought of that before?
>>
>> Long story short: All drivers using GEM are safe now. This leaves vmwgfx..
>> But
>> they do their own access-management, anyway.
>>
>> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
>> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
>> command-line or via sysfs _before_ loading a driver. Otherwise, render
>> nodes
>> will not be created.
>>
>> This allows us to test render-nodes and play with the API. I added FLINK
>> for
>> now so we can better test it. Not sure whether we should allow it in the
>> end,
>> though.
>>
>> Maybe we can get this into 3.11?
>
>
> A bit unlikely, but 3.12 should work fine.

whoops, 3.12 of course.

> I'm working on a project that can make good use of this, so if Alex doesn't
> mind like to add the necessary radeon flags (should be only a few one liners
> anyway).

Feel free to send a patch to dri-devel or just let me know the ioctls
and I will include it in this series.

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

Re: [PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[Martin Peres]

Le 23/08/2013 13:13, David Herrmann a écrit :

Hi

I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify_access() callback to get access to the underlying gem-object. Pretty
simple.. Why hadn't I thought of that before?

Long story short: All drivers using GEM are safe now. This leaves vmwgfx.. But
they do their own access-management, anyway.


Great! Thanks! Have you checked they are really safe with my "exploits"?
I'll have another round of review even if it looked good the last time I 
checked.

The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
command-line or via sysfs _before_ loading a driver. Otherwise, render nodes
will not be created.


By default, having the render nodes doesn't change the way the userspace
works at all. So, what is the point of protecting it behind a parameter?

Is it to make it clear this isn't part of the API yet? I would say that 
as long

as libdrm hasn't been updated, this isn't part of the API anyway.

This allows us to test render-nodes and play with the API. I added FLINK for
now so we can better test it. Not sure whether we should allow it in the end,
though.


From a security point of view, I don't think we should keep it as 
applications shouldn't
be trusted for not doing stupid things (because of code injection). So, 
unless we
plan on adding access control to flink via LSM, we shouldn't expose the 
feature

on render nodes.

From a dev point of view, keeping it means that the XServer doesn't
have to know whether mesa supports render nodes or not. This is because
the authentication dance isn't available on render nodes so the x-server
has to tell mesa if it should authenticate or not. The other solution is 
to allow
the authentication ioctls on render nodes and just return 0 if this is a 
render node.

This way, we won't need any modification in mesa/xserver/dri2proto to pass
the information that no authentication is needed. In this solution, only 
libdrm and

the ddx should be modified to make use of the render node. That's not how I
did it on my render node patchset, can't remember why...

What do you guys think?


Maybe we can get this into 3.11?


As long as we don't have to keep the interface stable (I don't want to 
expose flink
on render nodes), I'm all for pushing the code now. Otherwise, a kernel 
branch

somewhere is sufficient.

Do you plan on checking my userspace patches too? Those are enough to 
make use
of the render nodes on X, but I haven't tested that all the combinations 
of version
would still work. The libdrm work should be quite solid though (there 
are even libdrm

tests for the added functionalities :)).

Thanks for your work David!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/6] drm/i915: Support render nodes

[Chris Wilson]

On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian Høgsberg 
> 
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Kristian Høgsberg 
> Signed-off-by: David Herrmann 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>  2 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 0adfe40..ecf5ecd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
> @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
> DRM_AUTH|DRM_UNLOCKED),
execbuffer also

> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
> DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
> DRM_UNLOCKED),
set/get caching

> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID, 
> intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
> - DRM_

Re: [PATCH 10/16] drm/gem: implement mmap access management

[David Herrmann]

Hi

On Tue, Aug 13, 2013 at 11:05 PM, Daniel Vetter  wrote:
> On Tue, Aug 13, 2013 at 09:38:31PM +0200, David Herrmann wrote:
>> Implement automatic access management for mmap offsets for all GEM
>> drivers. This prevents user-space applications from "guessing" GEM BO
>> offsets and accessing buffers which they don't own.
>>
>> TTM drivers or other modesetting drivers with custom mm handling might
>> make use of GEM but don't need its mmap helpers. To avoid unnecessary
>> overhead, we limit GEM access management to drivers using DRIVER_GEM_MMAP.
>> So for TTM drivers GEM will not call any *_allow() or *_revoke() helpers.
>>
>> Signed-off-by: David Herrmann 
>
> Overall I'm not sold why we need the GEM_MMAP feature flag. Drivers that
> don't use drm_gem_mmap shouldn't get hurt with it if we ignore the little
> bit of useless overhead due to obj->vma_node. But they already have that
> anyway with obj->vma, so meh. And more incentives to move ttm over to the
> gem object manager completely ;-)
>
> One comment below.

I fixed both, the error-path and GEM_MMAP. Thanks!

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

[PATCH v2 6/6] drm/nouveau: Support render nodes

[David Herrmann]

From: Martin Peres 

Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.

Cc: Ben Skeggs 
Cc: Maarten Lankhorst 
Signed-off-by: Martin Peres 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b29d04b..ab42a25 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -651,18 +651,18 @@ nouveau_drm_postclose(struct drm_device *dev, struct 
drm_file *fpriv)
 
 static const struct drm_ioctl_desc
 nouveau_ioctls[] = {
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam, 
DRM_UNLOCKED|DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, nouveau_abi16_ioctl_setparam, 
DRM_UNLOCKED|DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC, 
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE, 
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC, 
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC, 
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE, 
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC, 
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 };
 
 static const struct file_operations
@@ -684,7 +684,7 @@ static struct drm_driver
 driver = {
.driver_features =
DRIVER_USE_AGP |
-   DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME,
+   DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,
 
.load = nouveau_drm_load,
.unload = nouveau_drm_unload,
-- 
1.8.3.4

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

[PATCH v2 5/6] drm/i915: Support render nodes

[David Herrmann]

From: Kristian Høgsberg 

Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.

Cc: Daniel Vetter 
Signed-off-by: Kristian Høgsberg 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/i915/i915_dma.c | 36 ++--
 drivers/gpu/drm/i915/i915_drv.c |  3 ++-
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0adfe40..ecf5ecd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
@@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID, 
intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_

[PATCH v2 4/6] drm: implement experimental render nodes

[David Herrmann]

Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.

Compared to legacy clients, render clients no longer need any
authentication to perform client ioctls. Instead, user-space controls
render/client access to GPUs via filesystem access-modes on the
render-node. Once a render-node was opened, a client has full access to
the client/render operations on the GPU. However, no modesetting or ioctls
that affect global state are allowed on render nodes.

To prevent privilege-escalation, drivers must explicitly state that they
support render nodes. They must mark their render-only ioctls as
DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
support clients without any attached master.

If filesystem access-modes are not enough for fine-grained access control
to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
you may still fall-back to fd-passing from server to client (which allows
arbitrary access-control). However, note that revoking access is
currently impossible and unlikely to get implemented.

Note: Render clients no longer have any associated DRM-Master as they are
supposed to be independent of any server state. DRM core highly depends on
file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
Therefore, drivers must be very careful to not require DRM-Master if they
support DRIVER_RENDER.

So far render-nodes are protected by "drm_rnodes". As long as this
module-parameter is not set to 1, a driver will not create render nodes.
This allows us to experiment with the API a bit before we stabilize it.

Signed-off-by: David Herrmann 
---
 Documentation/DocBook/drm.tmpl | 71 ++
 drivers/gpu/drm/drm_drv.c  | 15 -
 drivers/gpu/drm/drm_fops.c | 14 -
 drivers/gpu/drm/drm_pci.c  |  9 ++
 drivers/gpu/drm/drm_platform.c |  9 ++
 drivers/gpu/drm/drm_stub.c | 10 ++
 drivers/gpu/drm/drm_usb.c  |  9 ++
 include/drm/drmP.h |  9 ++
 8 files changed, 132 insertions(+), 14 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 9fc8ed4..3a778bf 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -205,6 +205,12 @@
   Driver implements DRM PRIME buffer sharing.
 
   
+  
+DRIVER_RENDER
+
+  Driver supports dedicated render nodes.
+
+  
 
   
   
@@ -2644,6 +2650,71 @@ int (*resume) (struct drm_device *);
   info, since man pages should cover the rest.
 
 
+  
+
+
+  Render nodes
+  
+DRM core provides multiple character-devices for user-space to use.
+Depending on which device is opened, user-space can perform a different
+set of operations (mainly ioctls). The primary node is always created
+and called card. Additionally, a currently
+unused control node, called controlD is also
+created. The primary node provides all legacy operations and
+historically was the only interface used by userspace. With KMS, the
+control node was introduced. However, the planned KMS control interface
+has never been written and so the control node stays unused to date.
+  
+  
+With the increased use of offscreen renderers and GPGPU applications,
+clients no longer require running compositors or graphics servers to
+make use of a GPU. But the DRM API required unprivileged clients to
+authenticate to a DRM-Master prior to getting GPU access. To avoid this
+step and to grant clients GPU access without authenticating, render
+nodes were introduced. Render nodes solely serve render clients, that
+is, no modesetting or privileged ioctls can be issued on render nodes.
+Only non-global rendering commands are allowed. If a driver supports
+render nodes, it must advertise it via the DRIVER_RENDER
+DRM driver capability. If not supported, the primary node must be used
+for render clients together with the legacy drmAuth authentication
+procedure.
+  
+  
+If a driver advertises render node support, DRM core will create a
+separate render node called renderD. There will
+be one render node per device. No ioctls except for
+GEM_CLOSE, GEM_FLINK and PRIME-related ioctls
+will be allowed on this node. Especially GEM_OPEN will be
+explicitly prohibited. Render nodes are designed to avoid the
+buffer-leaks, which occur if clients guess the flink names or mmap
+offsets on the legacy interface. Additionally to this basic interface,
+drivers must mark their driver-dependent re

[PATCH v2 3/6] drm: verify vma access in TTM+GEM drivers

[David Herrmann]

GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0. (note that verify_access() returns 0 on success, unlike
drm_vma_node_is_allowed() which returns "true").

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

Cc: Dave Airlie 
Cc: Alex Deucher 
Cc: Ben Skeggs 
Cc: Maarten Lankhorst 
Cc: Jerome Glisse 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/ast/ast_ttm.c | 4 +++-
 drivers/gpu/drm/cirrus/cirrus_ttm.c   | 4 +++-
 drivers/gpu/drm/mgag200/mgag200_ttm.c | 4 +++-
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 4 +++-
 drivers/gpu/drm/qxl/qxl_ttm.c | 4 +++-
 drivers/gpu/drm/radeon/radeon_ttm.c   | 4 +++-
 6 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index cf1c833..ae6c335 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -148,7 +148,9 @@ ast_bo_evict_flags(struct ttm_buffer_object *bo, struct 
ttm_placement *pl)
 
 static int ast_bo_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct ast_bo *astbo = ast_bo(bo);
+
+   return !drm_vma_node_is_allowed(&astbo->gem.vma_node, filp);
 }
 
 static int ast_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bf8a506..dd12b60 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -148,7 +148,9 @@ cirrus_bo_evict_flags(struct ttm_buffer_object *bo, struct 
ttm_placement *pl)
 
 static int cirrus_bo_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct cirrus_bo *cirrusbo = cirrus_bo(bo);
+
+   return !drm_vma_node_is_allowed(&cirrusbo->gem.vma_node, filp);
 }
 
 static int cirrus_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 6cf3fa0..a9f96b9 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -148,7 +148,9 @@ mgag200_bo_evict_flags(struct ttm_buffer_object *bo, struct 
ttm_placement *pl)
 
 static int mgag200_bo_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct mgag200_bo *mgabo = mgag200_bo(bo);
+
+   return !drm_vma_node_is_allowed(&mgabo->gem.vma_node, filp);
 }
 
 static int mgag200_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4e7ee5f..554a5af 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1260,7 +1260,9 @@ out:
 static int
 nouveau_bo_verify_access(struct ttm_buffer_object *bo, struct file *filp)
 {
-   return 0;
+   struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+   return !drm_vma_node_is_allowed(&nvbo->gem->vma_node, filp);
 }
 
 static int
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 1dfd84c..497fb6d 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -212,7 +212,9 @@ static void qxl_evict_flags(struct ttm_buffer_object *bo,
 
 static int qxl_verify_access(struct ttm_buffer_object *bo, struct file *filp)
 {
-   return 0;
+   struct qxl_bo *qbo = to_qxl_bo(bo);
+
+   return !drm_vma_node_is_allowed(&qbo->gem_base.vma_node, filp);
 }
 
 static int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 6c0ce89..072e2d7 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -203,7 +203,9 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo,
 
 static int radeon_verify_access(struct ttm_buffer_object *bo, struct file 
*filp)
 {
-   return 0;
+   struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
+
+   return !drm_vma_node_is_allowed(&rbo->gem_base.vma_node, filp);
 }
 
 static void radeon_move_null(struct ttm_buffer_object *bo,
-- 
1.8.3.4

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

[PATCH v2 2/6] drm/gem: implement vma access management

[David Herrmann]

We implement automatic vma mmap() access management for all drivers using
gem_mmap. We use the vma manager to add each open-file that creates a
gem-handle to the vma-node of the underlying gem object. Once the handle
is destroyed, we drop the open-file again.

This allows us to use drm_vma_node_is_allowed() on _any_ gem object to see
whether an open-file is granted access. In drm_gem_mmap() we use this to
verify that unprivileged users cannot guess gem offsets and map arbitrary
buffers.

Note that this manages access for _all_ gem users (also TTM+GEM), but the
actual access checks are only done for drm_gem_mmap(). TTM drivers use the
TTM mmap helpers, which need to do that separately.

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_gem.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index d6122ae..b2d59b2 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -298,6 +298,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
spin_unlock(&filp->table_lock);
 
drm_gem_remove_prime_handles(obj, filp);
+   drm_vma_node_revoke(&obj->vma_node, filp->filp);
 
if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, filp);
@@ -357,6 +358,11 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
}
*handlep = ret;
 
+   ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
+   if (ret) {
+   drm_gem_handle_delete(file_priv, *handlep);
+   return ret;
+   }
 
if (dev->driver->gem_open_object) {
ret = dev->driver->gem_open_object(obj, file_priv);
@@ -701,6 +707,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
struct drm_device *dev = obj->dev;
 
drm_gem_remove_prime_handles(obj, file_priv);
+   drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
 
if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, file_priv);
@@ -793,6 +800,10 @@ EXPORT_SYMBOL(drm_gem_vm_close);
  * the GEM object is not looked up based on its fake offset. To implement the
  * DRM mmap operation, drivers should use the drm_gem_mmap() function.
  *
+ * drm_gem_mmap_obj() assumes the user is granted access to the buffer while
+ * drm_gem_mmap() prevents unprivileged users from mapping random objects. So
+ * callers must verify access restrictions before calling this helper.
+ *
  * NOTE: This function has to be protected with dev->struct_mutex
  *
  * Return 0 or success or -EINVAL if the object size is smaller than the VMA
@@ -841,6 +852,9 @@ EXPORT_SYMBOL(drm_gem_mmap_obj);
  * Look up the GEM object based on the offset passed in (vma->vm_pgoff will
  * contain the fake offset we created when the GTT map ioctl was called on
  * the object) and map it with a call to drm_gem_mmap_obj().
+ *
+ * If the caller is not granted access to the buffer object, the mmap will fail
+ * with EACCES. Please see the vma manager for more information.
  */
 int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 {
@@ -861,6 +875,9 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
if (!node) {
mutex_unlock(&dev->struct_mutex);
return drm_mmap(filp, vma);
+   } else if (!drm_vma_node_is_allowed(node, filp)) {
+   mutex_unlock(&dev->struct_mutex);
+   return -EACCES;
}
 
obj = container_of(node, struct drm_gem_object, vma_node);
-- 
1.8.3.4

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

[PATCH v2 1/6] drm/vma: add access management helpers

[David Herrmann]

The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.

We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.

We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.

As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
 - Most times only a single filp is added per bo so we could use a static
   "struct file *main_filp" which is checked/added/removed first before we
   fall back to the rbtree+drm_vma_offset_file.
   This could be even done lockless with rcu.
 - Let user-space pass a hint whether mmap() should be supported on the
   bo and avoid access-management if not.
 - .. there are probably more ideas once we have benchmarks ..

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_gem.c |   1 +
 drivers/gpu/drm/drm_vma_manager.c | 155 ++
 include/drm/drm_vma_manager.h |  21 +-
 3 files changed, 174 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1ce88c3..d6122ae 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -156,6 +156,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
kref_init(&obj->refcount);
obj->handle_count = 0;
obj->size = size;
+   drm_vma_node_reset(&obj->vma_node);
 }
 EXPORT_SYMBOL(drm_gem_private_object_init);
 
diff --git a/drivers/gpu/drm/drm_vma_manager.c 
b/drivers/gpu/drm/drm_vma_manager.c
index 3837481..63b4712 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +59,13 @@
  * must always be page-aligned (as usual).
  * If you want to get a valid byte-based user-space address for a given offset,
  * please see drm_vma_node_offset_addr().
+ *
+ * Additionally to offset management, the vma offset manager also handles 
access
+ * management. For every open-file context that is allowed to access a given
+ * node, you must call drm_vma_node_allow(). Otherwise, an mmap() call on this
+ * open-file with the offset of the node will fail with -EACCES. To revoke
+ * access again, use drm_vma_node_revoke(). However, the caller is responsible
+ * for destroying already existing mappings, if required.
  */
 
 /**
@@ -279,3 +287,150 @@ void drm_vma_offset_remove(struct drm_vma_offset_manager 
*mgr,
write_unlock(&mgr->vm_lock);
 }
 EXPORT_SYMBOL(drm_vma_offset_remove);
+
+/**
+ * drm_vma_node_allow - Add open-file to list of allowed users
+ * @node: Node to modify
+ * @filp: Open file to add
+ *
+ * Add @filp to the list of allowed open-files for this node. If @filp is
+ * already on this list, the ref-count is incremented.
+ *
+ * The list of allowed-users is preserved across drm_vma_offset_add() and
+ * drm_vma_offset_remove() calls. You may even call it if the node is currently
+ * not added to any offset-manager.
+ *
+ * You must remove all open-files the same number of times as you added them
+ * before destroying the node. Otherwise, you will leak memory.
+ *
+ * This is locked against concurrent access internally.
+ *
+ * RETURNS:
+ * 0 on success, negative error code on internal failure (out-of-mem)
+ */
+int drm_vma_node_allow(struct drm_vma_offset_node *node, struct file *filp)
+{
+   struct rb_node **iter;
+   struct rb_node *parent = NULL;
+   struct drm_vma_offset_file *new, *entry;
+   int ret = 0;
+
+   /* Preallocate entry to avoid atomic allocations below. It is quite
+* unlikely that an open-file is added twice to a single node so we
+* don't optimize for this case. OOM is checked below only if the entry
+* is actually used. */
+   new = kmalloc(sizeof(*entry), GFP_KERNEL);
+
+   write_lock(&node->vm_lock);
+
+   iter = &node->vm_files.rb_node;
+
+   while (likely(*iter)) {
+   parent = *iter;
+   entry = rb_entry(*iter, struct drm_vma_offset_file, vm_rb);
+
+   if (filp == entry->vm_filp) {
+   entry->vm_count++;
+   goto unlock;
+   } else if (filp > entry->vm_filp) {
+   iter = &(*iter)->rb_right;
+   } else {
+   iter = &(*iter)->rb_left;
+   }
+   }
+
+   if (!new) {
+   ret = -ENOM

[PATCH v2 0/6] DRM: VMA Access Management and Render Nodes

[David Herrmann]

Hi

I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify_access() callback to get access to the underlying gem-object. Pretty
simple.. Why hadn't I thought of that before?

Long story short: All drivers using GEM are safe now. This leaves vmwgfx.. But
they do their own access-management, anyway.

The 3 patches on top implement render-nodes. I added a "drm_rnodes" module
parameter to core drm. You need to pass "drm.rnodes=1" on the kernel
command-line or via sysfs _before_ loading a driver. Otherwise, render nodes
will not be created.

This allows us to test render-nodes and play with the API. I added FLINK for
now so we can better test it. Not sure whether we should allow it in the end,
though.

Maybe we can get this into 3.11?

Regards
David

David Herrmann (4):
  drm/vma: add access management helpers
  drm/gem: implement vma access management
  drm: verify vma access in TTM+GEM drivers
  drm: implement experimental render nodes

Kristian Høgsberg (1):
  drm/i915: Support render nodes

Martin Peres (1):
  drm/nouveau: Support render nodes

 Documentation/DocBook/drm.tmpl|  71 
 drivers/gpu/drm/ast/ast_ttm.c |   4 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c   |   4 +-
 drivers/gpu/drm/drm_drv.c |  15 ++--
 drivers/gpu/drm/drm_fops.c|  14 +--
 drivers/gpu/drm/drm_gem.c |  18 
 drivers/gpu/drm/drm_pci.c |   9 ++
 drivers/gpu/drm/drm_platform.c|   9 ++
 drivers/gpu/drm/drm_stub.c|  10 +++
 drivers/gpu/drm/drm_usb.c |   9 ++
 drivers/gpu/drm/drm_vma_manager.c | 155 ++
 drivers/gpu/drm/i915/i915_dma.c   |  36 
 drivers/gpu/drm/i915/i915_drv.c   |   3 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c |   4 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   4 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c |  24 +++---
 drivers/gpu/drm/qxl/qxl_ttm.c |   4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   |   4 +-
 include/drm/drmP.h|   9 ++
 include/drm/drm_vma_manager.h |  21 -
 20 files changed, 373 insertions(+), 54 deletions(-)

-- 
1.8.3.4

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

Re: [PATCH -next] drm/rcar-du: fix return value check in rcar_du_lvdsenc_get_resources()

[Laurent Pinchart]

Hello,

On Friday 23 August 2013 10:21:21 Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun 

Thank you for the patch.

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c index a0f6a17..f59cbc4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -151,11 +151,8 @@ static int rcar_du_lvdsenc_get_resources(struct
> rcar_du_lvdsenc *lvds, }
> 
>   lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);

devm_ioremap_resource() prints an error message when the second argument is 
NULL, so we can remove the error check after the 
platform_get_resource_byname() call as well. The resulting code could look 
like

mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
if (IS_ERR(lvds->mmio))
return PTR_ERR(lvds->mmio);

Could you please submit a v2 ?

> - if (lvds->mmio == NULL) {
> - dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
> - name);
> - return -ENOMEM;
> - }
> + if (IS_ERR(lvds->mmio))
> + return PTR_ERR(lvds->mmio);
> 
>   lvds->clock = devm_clk_get(&pdev->dev, name);
>   if (IS_ERR(lvds->clock)) {
-- 
Regards,

Laurent Pinchart

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

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #59 from Chu Viet Huong  ---
Created attachment 84489
  --> https://bugs.freedesktop.org/attachment.cgi?id=84489&action=edit
create success dmesg attachment

After remove generic driver xf86-video-vesa, it work fine :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/9d3772af/attachment.html>

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #58 from Chu Viet Huong  ---
Created attachment 84488
  --> https://bugs.freedesktop.org/attachment.cgi?id=84488&action=edit
create full dmesg attachment.

My same issue with RV730

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/e7d0254d/attachment.html>

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

Ben was on holidays for a week so a few nouveau regression fixes backed 
up, but they all seem necessary, otherwise one i915 and one gma500 fix.

Dave.

The following changes since commit 3387ed83943daf6cb1bb4195ae369067b9cd80ce:

  Merge tag 'drm-intel-fixes-2013-08-15' of 
git://people.freedesktop.org/~danvet/drm-intel (2013-08-19 13:49:20 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 4dd17ee95742f3e9fd55d07463981711a637bd20:

  Merge tag 'drm-intel-fixes-2013-08-23' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-23 
18:52:37 +1000)



Ben Skeggs (2):
  drm/nouveau/mc: fix race condition between constructor and request_irq()
  drm/nv04/disp: fix framebuffer pin refcounting

Chris Wilson (1):
  drm/i915: Invalidate TLBs for the rings after a reset

Dave Airlie (2):
  Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge tag 'drm-intel-fixes-2013-08-23' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Guillaume Clement (1):
  gma500: Fix SDVO turning off randomly

Ilia Mirkin (1):
  drm/nouveau/fb: fix null derefs in nv49 and nv4e init

Maarten Lankhorst (2):
  drm/nouveau/ltcg: fix ltcg memory initialization after suspend
  drm/nouveau/ltcg: fix allocating memory as free

Pali Rohár (1):
  drm/nouveau: fix reclocking on nv40

 drivers/gpu/drm/gma500/psb_intel_sdvo.c  |  3 +-
 drivers/gpu/drm/i915/i915_reg.h  |  2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 12 +
 drivers/gpu/drm/nouveau/core/core/mm.c   |  4 ++
 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  7 +--
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c | 12 ++---
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c |  4 +-
 drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c  | 34 ++
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c|  6 ++-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv98.c|  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nvc0.c|  3 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c  | 58 ++--
 drivers/gpu/drm/nouveau/dispnv04/disp.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_display.c|  3 ++
 drivers/gpu/drm/nouveau/nv40_pm.c|  2 +-
 18 files changed, 114 insertions(+), 49 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch 2/2] gpu: host1x: returning success instead of -ENOMEM

[Dan Carpenter]

There is a mistake here so it returns PTR_ERR(NULL) which is success
instead of -ENOMEM.

Signed-off-by: Dan Carpenter 
---
I can't compile this.

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc80766..6cf41da 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -466,9 +466,8 @@ static inline int copy_gathers(struct host1x_job *job, 
struct device *dev)
 &job->gather_copy,
 GFP_KERNEL);
if (!job->gather_copy_mapped) {
-   int err = PTR_ERR(job->gather_copy_mapped);
job->gather_copy_mapped = NULL;
-   return err;
+   return -ENOMEM;
}
 
job->gather_copy_size = size;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch 1/2] gpu: host1x: fix an integer overflow check

[Dan Carpenter]

Tegra is a 32 bit arch.  On 32 bit systems then size_t is 32 bits so
"total" will never be higher than UINT_MAX because of integer overflows.
We need cast to u64 first before doing the math.

Also the addition earlier:

unsigned int num_unpins = num_cmdbufs + num_relocs;

That can overflow as well, but I think it's still safe because we check
both "num_cmdbufs" and "num_relocs" again in this test.

Signed-off-by: Dan Carpenter 
---
This is something I spotted in code review.  I can't actually compile
this code.  I assume this overflow test has security implications.

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc80766..18a47f9 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -42,12 +42,12 @@ struct host1x_job *host1x_job_alloc(struct host1x_channel 
*ch,
 
/* Check that we're not going to overflow */
total = sizeof(struct host1x_job) +
-   num_relocs * sizeof(struct host1x_reloc) +
-   num_unpins * sizeof(struct host1x_job_unpin_data) +
-   num_waitchks * sizeof(struct host1x_waitchk) +
-   num_cmdbufs * sizeof(struct host1x_job_gather) +
-   num_unpins * sizeof(dma_addr_t) +
-   num_unpins * sizeof(u32 *);
+   (u64)num_relocs * sizeof(struct host1x_reloc) +
+   (u64)num_unpins * sizeof(struct host1x_job_unpin_data) +
+   (u64)num_waitchks * sizeof(struct host1x_waitchk) +
+   (u64)num_cmdbufs * sizeof(struct host1x_job_gather) +
+   (u64)num_unpins * sizeof(dma_addr_t) +
+   (u64)num_unpins * sizeof(u32 *);
if (total > ULONG_MAX)
return NULL;
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

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

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

--- Comment #3 from Alexandre Demers  ---
kernel 3.11.0-rc1 was experiencing a bug, but not the one seen in rc2 and
beyond. I'll dig on the "fix" that brought us to the state seen since rc2. If
nothing can be found, I'll go up the drm-next branch that was included in rc1.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/bd717ebd/attachment.html>

[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module

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

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

Eastern Heart  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Eastern Heart  ---


*** This bug has been marked as a duplicate of bug 60674 ***

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem

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

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

Eastern Heart  changed:

   What|Removed |Added

 CC||zxd123314 at hotmail.com

--- Comment #16 from Eastern Heart  ---
*** Bug 60741 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
> All of the above (except UVD, of course) work fine under 9.1.6

Can you bisect?

-- 
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

[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create

[Vikas Sajjan]

To address the case where physically contiguous memory MAY NOT be a mandatory
requirement for framebuffer for the application calling 
exynos_drm_gem_dumb_create,
the patch adds a feature to get non physically contiguous memory for 
framebuffer,
if physically contiguous memory allocation fails and if IOMMU is supported.

Signed-off-by: Vikas Sajjan 
Signed-off-by: Arun Kumar 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2eabe1a..66d1b40 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -17,6 +17,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_buf.h"
+#include "exynos_drm_iommu.h"
 
 static unsigned int convert_to_vm_err_msg(int msg)
 {
@@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
 
exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
EXYNOS_BO_WC, args->size);
+   /*
+* If physically contiguous memory allocation fails and if IOMMU is
+* supported then try to get buffer from non physically contiguous
+* memory area.
+*/
+   if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
+   dev_warn(dev->dev, "contiguous FB allocation failed, falling 
back to non-contiguous\n");
+   exynos_gem_obj = exynos_drm_gem_create(dev,
+   EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
+   args->size);
+   }
+
if (IS_ERR(exynos_gem_obj))
return PTR_ERR(exynos_gem_obj);
 
-- 
1.7.9.5

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

Re: [PULL] drm-intel-fixes

[Daniel Vetter]

Argh, forgotten to cc lists!

On Fri, Aug 23, 2013 at 10:42:37AM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Just one patch that soaked for quite a bit to fix a resume issue,
> resulting in gpu hangs (or worse) due to tlb containing garbage.
> 
> Cheers, Daniel
> 
> 
> The following changes since commit 63b66e5ba54b15a6592be00555d762db6db739ce:
> 
>   drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code 
> (2013-08-14 20:26:49 +0200)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~danvet/drm-intel 
> tags/drm-intel-fixes-2013-08-23
> 
> for you to fetch changes up to 884020bf3d2a3787a1cc6df902e98e0eec60330b:
> 
>   drm/i915: Invalidate TLBs for the rings after a reset (2013-08-18 19:37:41 
> +0200)
> 
> 
> Chris Wilson (1):
>   drm/i915: Invalidate TLBs for the rings after a reset
> 
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 12 
>  2 files changed, 14 insertions(+)
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

[bugzilla-daemon]

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

adam...@gmail.com changed:

   What|Removed |Added

Version|unspecified |9.2

-- 
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 68468] New: 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 68468
  Assignee: dri-devel@lists.freedesktop.org
   Summary: 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: adam...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: Drivers/DRI/R600
   Product: Mesa

Using 9.2.0rc2 on a fully updated Arch Linux (running on [testing]), the system
will lock under the following conditions:
1. When playing a movied in mpv using UVD video decoding, the system will lock
as soon as mpv finish the initial loading process and playback is about to
begin.
2. When playing a game in Wine, system will lock after a few seconds of launch.
3. From time to time, the system will lock for no apparent reason (for example,
it happened when using Google Maps).

All of the above (except UVD, of course) work fine under 9.1.6

Mesa Version: (for rc1, but rc2 have the same behavior)

[adamdagan@admdgn ~]$ glxinfo | grep ^OpenGL | egrep 'version|renderer'
OpenGL renderer string: Gallium 0.4 on AMD RV710
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0-rc1
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0-rc1
OpenGL shading language version string: 1.30

-- 
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 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

[bugzilla-daemon]

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

--- Comment #3 from Peter Kraus  ---
RE: Emil:
Possibly. I couldn't get a screenshot of the corruption, mine looked a lot
different, but it's definitely possible.

RE: Alex:
I'll try when I get back home and have some time (ie tomorrow). I might try and
follow the bisect of bug 67887, to see whether it's indeed a duplicate.

-- 
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 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

[bugzilla-daemon]

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

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
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