date:20150505

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

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log as well.

-- 
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/20150505/aea554a7/attachment.html>

[PATCH 02/27] drm/bridge: ps8622: #include , depend on GPIOLIB

2015-05-05 Thread Geert Uytterhoeven

If GPIOLIB=n and asm-generic/gpio.h is not used:

drivers/gpu/drm/bridge/ps8622.c: In function âps8622_pre_enableâ:
drivers/gpu/drm/bridge/ps8622.c:368: error: implicit declaration of 
function âgpiod_set_valueâ
drivers/gpu/drm/bridge/ps8622.c: In function âps8622_probeâ:
drivers/gpu/drm/bridge/ps8622.c:584: error: implicit declaration of 
function âdevm_gpiod_getâ
drivers/gpu/drm/bridge/ps8622.c:584: warning: assignment makes pointer from 
integer without a cast
drivers/gpu/drm/bridge/ps8622.c:590: error: implicit declaration of 
function âgpiod_direction_outputâ
drivers/gpu/drm/bridge/ps8622.c:596: warning: assignment makes pointer from 
integer without a cast

Add the missing #include  to fix this.

As the resulting driver won't work with GPIOLIB=n anyway, make
DRM_PS8622 depend on GPIOLIB || COMPILE_TEST.

Signed-off-by: Geert Uytterhoeven 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/bridge/Kconfig  | 4 ++--
 drivers/gpu/drm/bridge/ps8622.c | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 6cdcd2ec4848edec..3e562d3f37973efc 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -14,8 +14,8 @@ config DRM_PTN3460

 config DRM_PS8622
tristate "Parade eDP/LVDS bridge"
-   depends on DRM
-   depends on OF
+   depends on DRM && OF
+   depends on GPIOLIB || COMPILE_TEST
select DRM_PANEL
select DRM_KMS_HELPER
select BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index e895aa7ea353164a..a9c38f8edf172bb9 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.9.1

[PATCH 01/27] drm/bridge: ptn3460: #include , depend on GPIOLIB

2015-05-05 Thread Geert Uytterhoeven

If GPIOLIB=n and asm-generic/gpio.h is not used:

drivers/gpu/drm/bridge/ptn3460.c: In function âptn3460_pre_enableâ:
drivers/gpu/drm/bridge/ptn3460.c:135: error: implicit declaration of 
function âgpiod_set_valueâ
drivers/gpu/drm/bridge/ptn3460.c: In function âptn3460_probeâ:
drivers/gpu/drm/bridge/ptn3460.c:333: error: implicit declaration of 
function âdevm_gpiod_getâ
drivers/gpu/drm/bridge/ptn3460.c:333: warning: assignment makes pointer 
from integer without a cast
drivers/gpu/drm/bridge/ptn3460.c:340: error: implicit declaration of 
function âgpiod_direction_outputâ
drivers/gpu/drm/bridge/ptn3460.c:346: warning: assignment makes pointer 
from integer without a cast

Add the missing #include  to fix this.

As the resulting driver won't work with GPIOLIB=n anyway, make
DRM_PTN3460 depend on GPIOLIB || COMPILE_TEST.

Signed-off-by: Geert Uytterhoeven 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/bridge/Kconfig   | 4 ++--
 drivers/gpu/drm/bridge/ptn3460.c | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index acef3223772cb899..6cdcd2ec4848edec 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -5,8 +5,8 @@ config DRM_DW_HDMI

 config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
-   depends on DRM
-   depends on OF
+   depends on DRM && OF
+   depends on GPIOLIB || COMPILE_TEST
select DRM_KMS_HELPER
select DRM_PANEL
---help---
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9d2f053382e1889a..63a09e4079f358ff 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -15,6 +15,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.9.1

[PATCH] drmPrime*: initialize output args to 0

2015-05-05 Thread Guillaume Desmottes

On Tue, 2015-05-05 at 16:12 +0100, Emil Velikov wrote:
> As mentioned before one could add the appropriate Valgrind
> annotations. Although using memclear() or this will do just fine :-)
> Any objections against memclear ? it will save us some head-scratching
> when/if someone decides to extend struct drm_prime_handle. If you and
> others are ok with it, I'll amend the patch locally before pushing in
> the next week or so.

Yeah memclear sounds like a good idea to me as well.


G.

[PATCH 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()

Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
This removes the knowledge about vmas and mmap_sem locking from exynos
driver. Also it fixes a problem that the function has been mapping user
provided address without holding mmap_sem.

Signed-off-by: Jan Kara 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 91 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 97 -
 2 files changed, 30 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 81a250830808..65eb38797fd3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t  dma_addr;
unsigned long   userptr;
unsigned long   size;
-   struct page **pages;
-   unsigned intnpages;
+   struct frame_vector *vec;
struct sg_table *sgt;
-   struct vm_area_struct   *vma;
atomic_trefcount;
boolin_pool;
boolout_of_list;
@@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device 
*drm_dev,
 {
struct g2d_cmdlist_userptr *g2d_userptr =
(struct g2d_cmdlist_userptr *)obj;
+   struct page **pages;

if (!obj)
return;
@@ -382,19 +381,21 @@ out:
exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
DMA_BIDIRECTIONAL);

-   exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
-   g2d_userptr->npages,
-   g2d_userptr->vma);
+   pages = frame_vector_pages(g2d_userptr->vec);
+   if (!IS_ERR(pages)) {
+   int i;

-   exynos_gem_put_vma(g2d_userptr->vma);
+   for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
+   set_page_dirty_lock(pages[i]);
+   }
+   put_vaddr_frames(g2d_userptr->vec);
+   frame_vector_destroy(g2d_userptr->vec);

if (!g2d_userptr->out_of_list)
list_del_init(&g2d_userptr->list);

sg_free_table(g2d_userptr->sgt);
kfree(g2d_userptr->sgt);
-
-   drm_free_large(g2d_userptr->pages);
kfree(g2d_userptr);
 }

@@ -413,6 +414,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
struct vm_area_struct *vma;
unsigned long start, end;
unsigned int npages, offset;
+   struct frame_vector *vec;
int ret;

if (!size) {
@@ -456,65 +458,37 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);

atomic_set(&g2d_userptr->refcount, 1);
+   g2d_userptr->size = size;

start = userptr & PAGE_MASK;
offset = userptr & ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) >> PAGE_SHIFT;
-   g2d_userptr->npages = npages;
+   vec = g2d_userptr->vec = frame_vector_create(npages);
+   if (!vec)
+   goto out_free;

-   pages = drm_calloc_large(npages, sizeof(struct page *));
-   if (!pages) {
-   DRM_ERROR("failed to allocate pages.\n");
-   ret = -ENOMEM;
-   goto err_free;
-   }
-
-   down_read(¤t->mm->mmap_sem);
-   vma = find_vma(current->mm, userptr);
-   if (!vma) {
-   up_read(¤t->mm->mmap_sem);
-   DRM_ERROR("failed to get vm region.\n");
+   ret = get_vaddr_frames(start, npages, 1, 1, vec);
+   if (ret != npages) {
+   DRM_ERROR("failed to get user pages from userptr.\n");
+   if (ret < 0)
+   goto err_destroy_framevec;
ret = -EFAULT;
-   goto err_free_pages;
+   goto err_put_framevec;
}
-
-   if (vma->vm_end < userptr + size) {
-   up_read(¤t->mm->mmap_sem);
-   DRM_ERROR("vma is too small.\n");
+   if (frame_vector_to_pages(vec) < 0) {
ret = -EFAULT;
-   goto err_free_pages;
+   goto err_put_framevec;
}

-   g2d_userptr->vma = exynos_gem_get_vma(vma);
-   if (!g2d_userptr->vma) {
-   up_read(¤t->mm->mmap_sem);
-   DRM_ERROR("failed to copy vma.\n");
-   ret = -ENOMEM;
-   goto err_free_pages;
-   }
-
-   g2d_userptr->size = size;
-
-   ret = exynos_gem_get_pages_from_userptr(start & PAGE_MASK,
-   npages, pages, vma);
-   if (ret < 0) {
-   up_read(¤t->mm->mmap_sem);
-   DRM_ERROR("failed to get user pages from userptr.\n");
-   goto err_put_vma;
-   }
-
-   up_read(¤t->mm->m

[PATCH 8/9] media: vb2: Remove unused functions

Conversion to the use of pinned pfns made some functions unused. Remove
them. Also there's no need to lock mmap_sem in __buf_prepare() anymore.

Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Jan Kara 
---
 drivers/media/v4l2-core/videobuf2-memops.c | 114 -
 include/media/videobuf2-memops.h   |   6 --
 2 files changed, 120 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
b/drivers/media/v4l2-core/videobuf2-memops.c
index 0ec186d41b9b..48c6a49c4928 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -23,120 +23,6 @@
 #include 

 /**
- * vb2_get_vma() - acquire and lock the virtual memory area
- * @vma:   given virtual memory area
- *
- * This function attempts to acquire an area mapped in the userspace for
- * the duration of a hardware operation. The area is "locked" by performing
- * the same set of operation that are done when process calls fork() and
- * memory areas are duplicated.
- *
- * Returns a copy of a virtual memory region on success or NULL.
- */
-struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma)
-{
-   struct vm_area_struct *vma_copy;
-
-   vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
-   if (vma_copy == NULL)
-   return NULL;
-
-   if (vma->vm_ops && vma->vm_ops->open)
-   vma->vm_ops->open(vma);
-
-   if (vma->vm_file)
-   get_file(vma->vm_file);
-
-   memcpy(vma_copy, vma, sizeof(*vma));
-
-   vma_copy->vm_mm = NULL;
-   vma_copy->vm_next = NULL;
-   vma_copy->vm_prev = NULL;
-
-   return vma_copy;
-}
-EXPORT_SYMBOL_GPL(vb2_get_vma);
-
-/**
- * vb2_put_userptr() - release a userspace virtual memory area
- * @vma:   virtual memory region associated with the area to be released
- *
- * This function releases the previously acquired memory area after a hardware
- * operation.
- */
-void vb2_put_vma(struct vm_area_struct *vma)
-{
-   if (!vma)
-   return;
-
-   if (vma->vm_ops && vma->vm_ops->close)
-   vma->vm_ops->close(vma);
-
-   if (vma->vm_file)
-   fput(vma->vm_file);
-
-   kfree(vma);
-}
-EXPORT_SYMBOL_GPL(vb2_put_vma);
-
-/**
- * vb2_get_contig_userptr() - lock physically contiguous userspace mapped 
memory
- * @vaddr: starting virtual address of the area to be verified
- * @size:  size of the area
- * @res_paddr: will return physical address for the given vaddr
- * @res_vma:   will return locked copy of struct vm_area for the given area
- *
- * This function will go through memory area of size @size mapped at @vaddr and
- * verify that the underlying physical pages are contiguous. If they are
- * contiguous the virtual memory area is locked and a @res_vma is filled with
- * the copy and @res_pa set to the physical address of the buffer.
- *
- * Returns 0 on success.
- */
-int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
-  struct vm_area_struct **res_vma, dma_addr_t *res_pa)
-{
-   struct mm_struct *mm = current->mm;
-   struct vm_area_struct *vma;
-   unsigned long offset, start, end;
-   unsigned long this_pfn, prev_pfn;
-   dma_addr_t pa = 0;
-
-   start = vaddr;
-   offset = start & ~PAGE_MASK;
-   end = start + size;
-
-   vma = find_vma(mm, start);
-
-   if (vma == NULL || vma->vm_end < end)
-   return -EFAULT;
-
-   for (prev_pfn = 0; start < end; start += PAGE_SIZE) {
-   int ret = follow_pfn(vma, start, &this_pfn);
-   if (ret)
-   return ret;
-
-   if (prev_pfn == 0)
-   pa = this_pfn << PAGE_SHIFT;
-   else if (this_pfn != prev_pfn + 1)
-   return -EFAULT;
-
-   prev_pfn = this_pfn;
-   }
-
-   /*
-* Memory is contigous, lock vma and return to the caller
-*/
-   *res_vma = vb2_get_vma(vma);
-   if (*res_vma == NULL)
-   return -ENOMEM;
-
-   *res_pa = pa + offset;
-   return 0;
-}
-EXPORT_SYMBOL_GPL(vb2_get_contig_userptr);
-
-/**
  * vb2_create_framevec() - map virtual addresses to pfns
  * @start: Virtual user address where we start mapping
  * @length:Length of a range to map
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index 2f0564ff5f31..830b5239fd8b 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -31,12 +31,6 @@ struct vb2_vmarea_handler {

 extern const struct vm_operations_struct vb2_common_vm_ops;

-int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
-  struct vm_area_struct **res_vma, dma_addr_t *res_pa);
-
-struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma);
-void vb2_put_vma(struct vm_area_struct *vma);
-
 struct frame_vector *vb2_create_framevec(unsigned long start

[PATCH 7/9] media: vb2: Convert vb2_dc_get_userptr() to use frame vector

Convert vb2_dc_get_userptr() to use frame vector infrastructure. When we
are doing that there's no need to allocate page array and some code can
be simplified.

Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Jan Kara 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 214 -
 1 file changed, 34 insertions(+), 180 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 620c4aa78881..e6cea452302b 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -32,15 +32,13 @@ struct vb2_dc_buf {
dma_addr_t  dma_addr;
enum dma_data_direction dma_dir;
struct sg_table *dma_sgt;
+   struct frame_vector *vec;

/* MMAP related */
struct vb2_vmarea_handler   handler;
atomic_trefcount;
struct sg_table *sgt_base;

-   /* USERPTR related */
-   struct vm_area_struct   *vma;
-
/* DMABUF related */
struct dma_buf_attachment   *db_attach;
 };
@@ -49,24 +47,6 @@ struct vb2_dc_buf {
 /*scatterlist table functions*/
 /*/

-
-static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
-   void (*cb)(struct page *pg))
-{
-   struct scatterlist *s;
-   unsigned int i;
-
-   for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
-   struct page *page = sg_page(s);
-   unsigned int n_pages = PAGE_ALIGN(s->offset + s->length)
-   >> PAGE_SHIFT;
-   unsigned int j;
-
-   for (j = 0; j < n_pages; ++j, ++page)
-   cb(page);
-   }
-}
-
 static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
 {
struct scatterlist *s;
@@ -429,92 +409,12 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv, 
unsigned long flags)
 /*   callbacks for USERPTR buffers   */
 /*/

-static inline int vma_is_io(struct vm_area_struct *vma)
-{
-   return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
-}
-
-static int vb2_dc_get_user_pfn(unsigned long start, int n_pages,
-   struct vm_area_struct *vma, unsigned long *res)
-{
-   unsigned long pfn, start_pfn, prev_pfn;
-   unsigned int i;
-   int ret;
-
-   if (!vma_is_io(vma))
-   return -EFAULT;
-
-   ret = follow_pfn(vma, start, &pfn);
-   if (ret)
-   return ret;
-
-   start_pfn = pfn;
-   start += PAGE_SIZE;
-
-   for (i = 1; i < n_pages; ++i, start += PAGE_SIZE) {
-   prev_pfn = pfn;
-   ret = follow_pfn(vma, start, &pfn);
-
-   if (ret) {
-   pr_err("no page for address %lu\n", start);
-   return ret;
-   }
-   if (pfn != prev_pfn + 1)
-   return -EINVAL;
-   }
-
-   *res = start_pfn;
-   return 0;
-}
-
-static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
-   int n_pages, struct vm_area_struct *vma,
-   enum dma_data_direction dma_dir)
-{
-   if (vma_is_io(vma)) {
-   unsigned int i;
-
-   for (i = 0; i < n_pages; ++i, start += PAGE_SIZE) {
-   unsigned long pfn;
-   int ret = follow_pfn(vma, start, &pfn);
-
-   if (!pfn_valid(pfn))
-   return -EINVAL;
-
-   if (ret) {
-   pr_err("no page for address %lu\n", start);
-   return ret;
-   }
-   pages[i] = pfn_to_page(pfn);
-   }
-   } else {
-   int n;
-
-   n = get_user_pages(current, current->mm, start & PAGE_MASK,
-   n_pages, dma_dir == DMA_FROM_DEVICE, 1, pages, NULL);
-   /* negative error means that no page was pinned */
-   n = max(n, 0);
-   if (n != n_pages) {
-   pr_err("got only %d of %d user pages\n", n, n_pages);
-   while (n)
-   put_page(pages[--n]);
-   return -EFAULT;
-   }
-   }
-
-   return 0;
-}
-
-static void vb2_dc_put_dirty_page(struct page *page)
-{
-   set_page_dirty_lock(page);
-   put_page(page);
-}
-
 static void vb2_dc_put_userptr(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
+   int i;
+   struct page **pages;

if (sgt) {
DEFINE_DMA_ATTRS(attrs);
@@ -526,15 +426,15 @@ static void vb2_dc_put_userptr(void *buf_priv)
 */
dma_unmap_sg_attrs(buf->dev, sgt->

[PATCH 6/9] media: vb2: Convert vb2_vmalloc_get_userptr() to use frame vector

Convert vb2_vmalloc_get_userptr() to use frame vector infrastructure.
When we are doing that there's no need to allocate page array and some
code can be simplified.

Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Jan Kara 
---
 drivers/media/v4l2-core/videobuf2-vmalloc.c | 94 +++--
 1 file changed, 36 insertions(+), 58 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 0ba40be21ebd..d2ce81fa2cdf 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -23,11 +23,9 @@

 struct vb2_vmalloc_buf {
void*vaddr;
-   struct page **pages;
-   struct vm_area_struct   *vma;
+   struct frame_vector *vec;
enum dma_data_direction dma_dir;
unsigned long   size;
-   unsigned intn_pages;
atomic_trefcount;
struct vb2_vmarea_handler   handler;
struct dma_buf  *dbuf;
@@ -76,10 +74,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx, 
unsigned long vaddr,
 enum dma_data_direction dma_dir)
 {
struct vb2_vmalloc_buf *buf;
-   unsigned long first, last;
-   int n_pages, offset;
-   struct vm_area_struct *vma;
-   dma_addr_t physp;
+   struct frame_vector *vec;
+   int n_pages, offset, i;

buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -88,53 +84,36 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx, 
unsigned long vaddr,
buf->dma_dir = dma_dir;
offset = vaddr & ~PAGE_MASK;
buf->size = size;
-
-   down_read(¤t->mm->mmap_sem);
-   vma = find_vma(current->mm, vaddr);
-   if (vma && (vma->vm_flags & VM_PFNMAP) && (vma->vm_pgoff)) {
-   if (vb2_get_contig_userptr(vaddr, size, &vma, &physp))
-   goto fail_pages_array_alloc;
-   buf->vma = vma;
-   buf->vaddr = (__force void *)ioremap_nocache(physp, size);
-   if (!buf->vaddr)
-   goto fail_pages_array_alloc;
+   vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
+   if (IS_ERR(vec))
+   goto fail_pfnvec_create;
+   buf->vec = vec;
+   n_pages = frame_vector_count(vec);
+   if (frame_vector_to_pages(vec) < 0) {
+   unsigned long *nums = frame_vector_pfns(vec);
+
+   /*
+* We cannot get page pointers for these pfns. Check memory is
+* physically contiguous and use direct mapping.
+*/
+   for (i = 1; i < n_pages; i++)
+   if (nums[i-1] + 1 != nums[i])
+   goto fail_map;
+   buf->vaddr = (__force void *)
+   ioremap_nocache(nums[0] << PAGE_SHIFT, size);
} else {
-   first = vaddr >> PAGE_SHIFT;
-   last  = (vaddr + size - 1) >> PAGE_SHIFT;
-   buf->n_pages = last - first + 1;
-   buf->pages = kzalloc(buf->n_pages * sizeof(struct page *),
-GFP_KERNEL);
-   if (!buf->pages)
-   goto fail_pages_array_alloc;
-
-   /* current->mm->mmap_sem is taken by videobuf2 core */
-   n_pages = get_user_pages(current, current->mm,
-vaddr & PAGE_MASK, buf->n_pages,
-dma_dir == DMA_FROM_DEVICE,
-1, /* force */
-buf->pages, NULL);
-   if (n_pages != buf->n_pages)
-   goto fail_get_user_pages;
-
-   buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1,
+   buf->vaddr = vm_map_ram(frame_vector_pages(vec), n_pages, -1,
PAGE_KERNEL);
-   if (!buf->vaddr)
-   goto fail_get_user_pages;
}
-   up_read(¤t->mm->mmap_sem);

+   if (!buf->vaddr)
+   goto fail_map;
buf->vaddr += offset;
return buf;

-fail_get_user_pages:
-   pr_debug("get_user_pages requested/got: %d/%d]\n", n_pages,
-buf->n_pages);
-   while (--n_pages >= 0)
-   put_page(buf->pages[n_pages]);
-   kfree(buf->pages);
-
-fail_pages_array_alloc:
-   up_read(¤t->mm->mmap_sem);
+fail_map:
+   vb2_destroy_framevec(vec);
+fail_pfnvec_create:
kfree(buf);

return NULL;
@@ -145,22 +124,21 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
struct vb2_vmalloc_buf *buf = buf_priv;
unsigned long vaddr = (unsigned long)buf->vaddr & PAGE_MASK;
unsigned int i;
+   struct page **pag

[PATCH 5/9] media: vb2: Convert vb2_dma_sg_get_userptr() to use frame vector

Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Jan Kara 
---
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 97 +-
 1 file changed, 15 insertions(+), 82 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index afd4b514affc..4ee1b3fbfe2a 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -38,6 +38,7 @@ struct vb2_dma_sg_buf {
struct device   *dev;
void*vaddr;
struct page **pages;
+   struct frame_vector *vec;
int offset;
enum dma_data_direction dma_dir;
struct sg_table sg_table;
@@ -51,7 +52,6 @@ struct vb2_dma_sg_buf {
unsigned intnum_pages;
atomic_trefcount;
struct vb2_vmarea_handler   handler;
-   struct vm_area_struct   *vma;

struct dma_buf_attachment   *db_attach;
 };
@@ -224,25 +224,17 @@ static void vb2_dma_sg_finish(void *buf_priv)
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
 }

-static inline int vma_is_io(struct vm_area_struct *vma)
-{
-   return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
-}
-
 static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size,
enum dma_data_direction dma_dir)
 {
struct vb2_dma_sg_conf *conf = alloc_ctx;
struct vb2_dma_sg_buf *buf;
-   unsigned long first, last;
-   int num_pages_from_user;
-   struct vm_area_struct *vma;
struct sg_table *sgt;
DEFINE_DMA_ATTRS(attrs);
+   struct frame_vector *vec;

dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, &attrs);
-
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return NULL;
@@ -253,63 +245,19 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, 
unsigned long vaddr,
buf->offset = vaddr & ~PAGE_MASK;
buf->size = size;
buf->dma_sgt = &buf->sg_table;
+   vec = vb2_create_framevec(vaddr, size, buf->dma_dir == DMA_FROM_DEVICE);
+   if (IS_ERR(vec))
+   goto userptr_fail_pfnvec;
+   buf->vec = vec;

-   first = (vaddr   & PAGE_MASK) >> PAGE_SHIFT;
-   last  = ((vaddr + size - 1) & PAGE_MASK) >> PAGE_SHIFT;
-   buf->num_pages = last - first + 1;
-
-   buf->pages = kzalloc(buf->num_pages * sizeof(struct page *),
-GFP_KERNEL);
-   if (!buf->pages)
-   goto userptr_fail_alloc_pages;
-
-   down_read(¤t->mm->mmap_sem);
-   vma = find_vma(current->mm, vaddr);
-   if (!vma) {
-   dprintk(1, "no vma for address %lu\n", vaddr);
-   goto userptr_fail_find_vma;
-   }
-
-   if (vma->vm_end < vaddr + size) {
-   dprintk(1, "vma at %lu is too small for %lu bytes\n",
-   vaddr, size);
-   goto userptr_fail_find_vma;
-   }
-
-   buf->vma = vb2_get_vma(vma);
-   if (!buf->vma) {
-   dprintk(1, "failed to copy vma\n");
-   goto userptr_fail_find_vma;
-   }
-
-   if (vma_is_io(buf->vma)) {
-   for (num_pages_from_user = 0;
-num_pages_from_user < buf->num_pages;
-++num_pages_from_user, vaddr += PAGE_SIZE) {
-   unsigned long pfn;
-
-   if (follow_pfn(vma, vaddr, &pfn)) {
-   dprintk(1, "no page for address %lu\n", vaddr);
-   break;
-   }
-   buf->pages[num_pages_from_user] = pfn_to_page(pfn);
-   }
-   } else
-   num_pages_from_user = get_user_pages(current, current->mm,
-vaddr & PAGE_MASK,
-buf->num_pages,
-buf->dma_dir == DMA_FROM_DEVICE,
-1, /* force */
-buf->pages,
-NULL);
-   up_read(¤t->mm->mmap_sem);
-
-   if (num_pages_from_user != buf->num_pages)
-   goto userptr_fail_get_user_pages;
+   buf->pages = frame_vector_pages(vec);
+   if (IS_ERR(buf->pages))
+   goto userptr_fail_sgtable;
+   buf->num_pages = frame_vector_count(vec);

if (sg_alloc_table_from_pages(buf->dma_sgt, buf->pages,
buf->num_pages, buf->offset, size, 0))
-   goto userptr_fail_alloc_table_from_pages;
+   goto userptr_fail_sgtable;

sgt = &buf->sg_table;
/*
@@ -323,19 +271,9 @@ static void *vb2_

[PATCH 4/9] vb2: Provide helpers for mapping virtual addresses

Provide simple helper functions to map virtual address range into an
array of pfns / pages.

Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Jan Kara 
---
 drivers/media/v4l2-core/videobuf2-memops.c | 58 ++
 include/media/videobuf2-memops.h   |  5 +++
 2 files changed, 63 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
b/drivers/media/v4l2-core/videobuf2-memops.c
index 81c1ad8b2cf1..0ec186d41b9b 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -137,6 +137,64 @@ int vb2_get_contig_userptr(unsigned long vaddr, unsigned 
long size,
 EXPORT_SYMBOL_GPL(vb2_get_contig_userptr);

 /**
+ * vb2_create_framevec() - map virtual addresses to pfns
+ * @start: Virtual user address where we start mapping
+ * @length:Length of a range to map
+ * @write: Should we map for writing into the area
+ *
+ * This function allocates and fills in a vector with pfns corresponding to
+ * virtual address range passed in arguments. If pfns have corresponding pages,
+ * page references are also grabbed to pin pages in memory. The function
+ * returns pointer to the vector on success and error pointer in case of
+ * failure. Returned vector needs to be freed via vb2_destroy_pfnvec().
+ */
+struct frame_vector *vb2_create_framevec(unsigned long start,
+unsigned long length,
+bool write)
+{
+   int ret;
+   unsigned long first, last;
+   unsigned long nr;
+   struct frame_vector *vec;
+
+   first = start >> PAGE_SHIFT;
+   last = (start + length - 1) >> PAGE_SHIFT;
+   nr = last - first + 1;
+   vec = frame_vector_create(nr);
+   if (!vec)
+   return ERR_PTR(-ENOMEM);
+   ret = get_vaddr_frames(start, nr, write, 1, vec);
+   if (ret < 0)
+   goto out_destroy;
+   /* We accept only complete set of PFNs */
+   if (ret != nr) {
+   ret = -EFAULT;
+   goto out_release;
+   }
+   return vec;
+out_release:
+   put_vaddr_frames(vec);
+out_destroy:
+   frame_vector_destroy(vec);
+   return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(vb2_create_framevec);
+
+/**
+ * vb2_destroy_framevec() - release vector of mapped pfns
+ * @vec:   vector of pfns / pages to release
+ *
+ * This releases references to all pages in the vector @vec (if corresponding
+ * pfns are backed by pages) and frees the passed vector.
+ */
+void vb2_destroy_framevec(struct frame_vector *vec)
+{
+   put_vaddr_frames(vec);
+   frame_vector_destroy(vec);
+}
+EXPORT_SYMBOL(vb2_destroy_framevec);
+
+/**
  * vb2_common_vm_open() - increase refcount of the vma
  * @vma:   virtual memory region for the mapping
  *
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index f05444ca8c0c..2f0564ff5f31 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -15,6 +15,7 @@
 #define _MEDIA_VIDEOBUF2_MEMOPS_H

 #include 
+#include 

 /**
  * vb2_vmarea_handler - common vma refcount tracking handler
@@ -36,5 +37,9 @@ int vb2_get_contig_userptr(unsigned long vaddr, unsigned long 
size,
 struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma);
 void vb2_put_vma(struct vm_area_struct *vma);

+struct frame_vector *vb2_create_framevec(unsigned long start,
+unsigned long length,
+bool write);
+void vb2_destroy_framevec(struct frame_vector *vec);

 #endif
-- 
2.1.4

[PATCH 3/9] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()

Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
hand made mapping of virtual address to physical address. Also the
function leaked page reference from get_user_pages() so fix that by
properly release the reference when omap_vout_buffer_release() is
called.

Signed-off-by: Jan Kara 
---
 drivers/media/platform/omap/omap_vout.c | 67 +++--
 1 file changed, 31 insertions(+), 36 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c 
b/drivers/media/platform/omap/omap_vout.c
index 17b189a81ec5..d3f6d82ccbc1 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -195,46 +195,34 @@ static int omap_vout_try_format(struct v4l2_pix_format 
*pix)
 }

 /*
- * omap_vout_uservirt_to_phys: This inline function is used to convert user
- * space virtual address to physical address.
+ * omap_vout_get_userptr: Convert user space virtual address to physical
+ * address.
  */
-static unsigned long omap_vout_uservirt_to_phys(unsigned long virtp)
+static int omap_vout_get_userptr(struct videobuf_buffer *vb, u32 virtp,
+u32 *physp)
 {
-   unsigned long physp = 0;
-   struct vm_area_struct *vma;
-   struct mm_struct *mm = current->mm;
+   struct frame_vector *vec;
+   int ret;

/* For kernel direct-mapped memory, take the easy way */
-   if (virtp >= PAGE_OFFSET)
-   return virt_to_phys((void *) virtp);
-
-   down_read(¤t->mm->mmap_sem);
-   vma = find_vma(mm, virtp);
-   if (vma && (vma->vm_flags & VM_IO) && vma->vm_pgoff) {
-   /* this will catch, kernel-allocated, mmaped-to-usermode
-  addresses */
-   physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp - vma->vm_start);
-   up_read(¤t->mm->mmap_sem);
-   } else {
-   /* otherwise, use get_user_pages() for general userland pages */
-   int res, nr_pages = 1;
-   struct page *pages;
+   if (virtp >= PAGE_OFFSET) {
+   *physp = virt_to_phys((void *)virtp);
+   return 0;
+   }

-   res = get_user_pages(current, current->mm, virtp, nr_pages, 1,
-   0, &pages, NULL);
-   up_read(¤t->mm->mmap_sem);
+   vec = frame_vector_create(1);
+   if (!vec)
+   return -ENOMEM;

-   if (res == nr_pages) {
-   physp =  __pa(page_address(&pages[0]) +
-   (virtp & ~PAGE_MASK));
-   } else {
-   printk(KERN_WARNING VOUT_NAME
-   "get_user_pages failed\n");
-   return 0;
-   }
+   ret = get_vaddr_frames(virtp, 1, 1, 0, vec);
+   if (ret != 1) {
+   frame_vector_destroy(vec);
+   return -EINVAL;
}
+   *physp = __pfn_to_phys(frame_vector_pfns(vec)[0]);
+   vb->priv = vec;

-   return physp;
+   return 0;
 }

 /*
@@ -788,11 +776,15 @@ static int omap_vout_buffer_prepare(struct videobuf_queue 
*q,
 * address of the buffer
 */
if (V4L2_MEMORY_USERPTR == vb->memory) {
+   int ret;
+
if (0 == vb->baddr)
return -EINVAL;
/* Physical address */
-   vout->queued_buf_addr[vb->i] = (u8 *)
-   omap_vout_uservirt_to_phys(vb->baddr);
+   ret = omap_vout_get_userptr(vb, vb->baddr,
+   (u32 *)&vout->queued_buf_addr[vb->i]);
+   if (ret < 0)
+   return ret;
} else {
unsigned long addr, dma_addr;
unsigned long size;
@@ -841,9 +833,12 @@ static void omap_vout_buffer_release(struct videobuf_queue 
*q,
struct omap_vout_device *vout = q->priv_data;

vb->state = VIDEOBUF_NEEDS_INIT;
+   if (vb->memory == V4L2_MEMORY_USERPTR && vb->priv) {
+   struct frame_vector *vec = vb->priv;

-   if (V4L2_MEMORY_MMAP != vout->memory)
-   return;
+   put_vaddr_frames(vec);
+   frame_vector_destroy(vec);
+   }
 }

 /*
-- 
2.1.4

[PATCH 2/9] mm: Provide new get_vaddr_frames() helper

Provide new function get_vaddr_frames().  This function maps virtual
addresses from given start and fills given array with page frame numbers of
the corresponding pages. If given start belongs to a normal vma, the function
grabs reference to each of the pages to pin them in memory. If start
belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
must make sure pfns aren't reused for anything else while he is using
them.

This function is created for various drivers to simplify handling of
their buffers.

Signed-off-by: Jan Kara 
---
 include/linux/mm.h |  44 +++
 mm/gup.c   | 213 +
 2 files changed, 257 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0755b9fd03a7..dcd1f02a78e9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 

 struct mempolicy;
 struct anon_vma;
@@ -1197,6 +1198,49 @@ long get_user_pages_unlocked(struct task_struct *tsk, 
struct mm_struct *mm,
int write, int force, struct page **pages);
 int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+
+/* Container for pinned pfns / pages */
+struct frame_vector {
+   unsigned int nr_allocated;  /* Number of frames we have space for */
+   unsigned int nr_frames; /* Number of frames stored in ptrs array */
+   bool got_ref;   /* Did we pin pages by getting page ref? */
+   bool is_pfns;   /* Does array contain pages or pfns? */
+   void *ptrs[0];  /* Array of pinned pfns / pages. Use
+* pfns_vector_pages() or pfns_vector_pfns()
+* for access */
+};
+
+struct frame_vector *frame_vector_create(unsigned int nr_frames);
+void frame_vector_destroy(struct frame_vector *vec);
+int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
+bool write, bool force, struct frame_vector *vec);
+void put_vaddr_frames(struct frame_vector *vec);
+int frame_vector_to_pages(struct frame_vector *vec);
+void frame_vector_to_pfns(struct frame_vector *vec);
+
+static inline unsigned int frame_vector_count(struct frame_vector *vec)
+{
+   return vec->nr_frames;
+}
+
+static inline struct page **frame_vector_pages(struct frame_vector *vec)
+{
+   if (vec->is_pfns) {
+   int err = frame_vector_to_pages(vec);
+
+   if (err)
+   return ERR_PTR(err);
+   }
+   return (struct page **)(vec->ptrs);
+}
+
+static inline unsigned long *frame_vector_pfns(struct frame_vector *vec)
+{
+   if (!vec->is_pfns)
+   frame_vector_to_pfns(vec);
+   return (unsigned long *)(vec->ptrs);
+}
+
 struct kvec;
 int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
struct page **pages);
diff --git a/mm/gup.c b/mm/gup.c
index 6297f6bccfb1..e99ff3e7f142 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -936,6 +936,219 @@ int __mm_populate(unsigned long start, unsigned long len, 
int ignore_errors)
return ret; /* 0 or negative error code */
 }

+/*
+ * get_vaddr_frames() - map virtual addresses to pfns
+ * @start: starting user address
+ * @nr_frames: number of pages / pfns from start to map
+ * @write: whether pages will be written to by the caller
+ * @force: whether to force write access even if user mapping is
+ * readonly. This will result in the page being COWed even
+ * in MAP_SHARED mappings. You do not want this.
+ * @vec:   structure which receives pages / pfns of the addresses mapped.
+ * It should have space for at least nr_frames entries.
+ *
+ * This function maps virtual addresses from @start and fills @vec structure
+ * with page frame numbers or page pointers to corresponding pages (choice
+ * depends on the type of the vma underlying the virtual address). If @start
+ * belongs to a normal vma, the function grabs reference to each of the pages
+ * to pin them in memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't
+ * touch page structures and the caller must make sure pfns aren't reused for
+ * anything else while he is using them.
+ *
+ * The function returns number of pages mapped which may be less than
+ * @nr_frames. In particular we stop mapping if there are more vmas of
+ * different type underlying the specified range of virtual addresses.
+ *
+ * This function takes care of grabbing mmap_sem as necessary.
+ */
+int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
+bool write, bool force, struct frame_vector *vec)
+{
+   struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
+   int ret = 0;
+   int err;
+   int locked = 1;
+
+   if (nr_frames == 0)
+   return 0;
+
+   if (WARN_ON_ONCE(nr_frames > vec->nr_allocated))
+

[PATCH 1/9] [media] vb2: Push mmap_sem down to memops

Currently vb2 core acquires mmap_sem just around call to
__qbuf_userptr(). However since commit f035eb4e976ef5 (videobuf2: fix
lockdep warning) it isn't necessary to acquire it so early as we no
longer have to drop queue mutex before acquiring mmap_sem. So push
acquisition of mmap_sem down into .get_userptr and .put_userptr memops
so that the semaphore is acquired for a shorter time and it is clearer
what it is needed for.

Signed-off-by: Jan Kara 
---
 drivers/media/v4l2-core/videobuf2-core.c   | 2 --
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 7 +++
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 6 ++
 drivers/media/v4l2-core/videobuf2-vmalloc.c| 6 +-
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 66ada01c796c..20cdbc0900ea 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1657,9 +1657,7 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
struct v4l2_buffer *b)
ret = __qbuf_mmap(vb, b);
break;
case V4L2_MEMORY_USERPTR:
-   down_read(¤t->mm->mmap_sem);
ret = __qbuf_userptr(vb, b);
-   up_read(¤t->mm->mmap_sem);
break;
case V4L2_MEMORY_DMABUF:
ret = __qbuf_dmabuf(vb, b);
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 644dec73d220..620c4aa78881 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -532,7 +532,9 @@ static void vb2_dc_put_userptr(void *buf_priv)
sg_free_table(sgt);
kfree(sgt);
}
+   down_read(¤t->mm->mmap_sem);
vb2_put_vma(buf->vma);
+   up_read(¤t->mm->mmap_sem);
kfree(buf);
 }

@@ -616,6 +618,7 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned 
long vaddr,
goto fail_buf;
}

+   down_read(¤t->mm->mmap_sem);
/* current->mm->mmap_sem is taken by videobuf2 core */
vma = find_vma(current->mm, vaddr);
if (!vma) {
@@ -642,6 +645,7 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned 
long vaddr,
if (ret) {
unsigned long pfn;
if (vb2_dc_get_user_pfn(start, n_pages, vma, &pfn) == 0) {
+   up_read(¤t->mm->mmap_sem);
buf->dma_addr = vb2_dc_pfn_to_dma(buf->dev, pfn);
buf->size = size;
kfree(pages);
@@ -651,6 +655,7 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned 
long vaddr,
pr_err("failed to get user pages\n");
goto fail_vma;
}
+   up_read(¤t->mm->mmap_sem);

sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt) {
@@ -713,10 +718,12 @@ fail_get_user_pages:
while (n_pages)
put_page(pages[--n_pages]);

+   down_read(¤t->mm->mmap_sem);
 fail_vma:
vb2_put_vma(buf->vma);

 fail_pages:
+   up_read(¤t->mm->mmap_sem);
kfree(pages); /* kfree is NULL-proof */

 fail_buf:
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 45c708e463b9..afd4b514affc 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -263,6 +263,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, 
unsigned long vaddr,
if (!buf->pages)
goto userptr_fail_alloc_pages;

+   down_read(¤t->mm->mmap_sem);
vma = find_vma(current->mm, vaddr);
if (!vma) {
dprintk(1, "no vma for address %lu\n", vaddr);
@@ -301,6 +302,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, 
unsigned long vaddr,
 1, /* force */
 buf->pages,
 NULL);
+   up_read(¤t->mm->mmap_sem);

if (num_pages_from_user != buf->num_pages)
goto userptr_fail_get_user_pages;
@@ -328,8 +330,10 @@ userptr_fail_get_user_pages:
if (!vma_is_io(buf->vma))
while (--num_pages_from_user >= 0)
put_page(buf->pages[num_pages_from_user]);
+   down_read(¤t->mm->mmap_sem);
vb2_put_vma(buf->vma);
 userptr_fail_find_vma:
+   up_read(¤t->mm->mmap_sem);
kfree(buf->pages);
 userptr_fail_alloc_pages:
kfree(buf);
@@ -362,7 +366,9 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
put_page(buf->pages[i]);
}
kfree(buf->pages);
+   down_read(¤t->mm->mmap_sem);
vb2_put_vma(buf->vma);
+   up_read(¤t->mm->mmap_sem);
kfree(buf);
 }

diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
b/drivers/media/v4l2-c

[PATCH 0/9 v3] Helper to abstract vma handling in media layer

  Hello,

  I'm sending the third version of my patch series to abstract vma handling
from the various media drivers. After this patch set drivers have to know much
less details about vmas, their types, and locking. Also quite some code is
removed from them. As a bonus drivers get automatically VM_FAULT_RETRY
handling. The primary motivation for this series is to remove knowledge about
mmap_sem locking from as many places a possible so that we can change it with
reasonable effort.

The core of the series is the new helper get_vaddr_frames() which is given a
virtual address and it fills in PFNs / struct page pointers (depending on VMA
type) into the provided array. If PFNs correspond to normal pages it also grabs
references to these pages. The difference from get_user_pages() is that this
function can also deal with pfnmap, and io mappings which is what the media
drivers need.

I have tested the patches with vivid driver so at least vb2 code got some
exposure. Conversion of other drivers was just compile-tested so I'd like to
ask respective maintainers if they could have a look.  Also I'd like to ask mm
folks to check patch 2/9 implementing the helper. Thanks!

Honza

Changes since v2:
* Renamed functions and structures as Mel suggested
* Other minor changes suggested by Mel
* Rebased on top of 4.1-rc2
* Changed functions to get pointer to array of pages / pfns to perform
  conversion if necessary. This fixes possible issue in the omap I may have
  introduced in v2 and generally makes the API less errorprone.

[RFC] How implement Secure Data Path ?

2015-05-05 Thread One Thousand Gnomes

> First what is Secure Data Path ? SDP is a set of hardware features to garanty
> that some memories regions could only be read and/or write by specific 
> hardware
> IPs. You can imagine it as a kind of memory firewall which grant/revoke
> accesses to memory per devices. Firewall configuration must be done in a 
> trusted
> environment: for ARM architecture we plan to use OP-TEE + a trusted
> application to do that.

It's not just an ARM feature so any basis for this in the core code
should be generic, whether its being enforced by ARM SDP, various Intel
feature sets or even via a hypervisor.

> I have try 2 "hacky" approachs with dma_buf:
> - add a secure field in dma_buf structure and configure firewall in
>   dma_buf_{map/unmap}_attachment() functions.

How is SDP not just another IOMMU. The only oddity here is that it
happens to configure buffers the CPU can't touch and it has a control
mechanism that is designed to cover big media corp type uses where the
threat model is that the system owner is the enemy. Why does anything care
about it being SDP, there are also generic cases this might be a useful
optimisation (eg knowing the buffer isn't CPU touched so you can optimise
cache flushing).

The control mechanism is a device/platform detail as with any IOMMU. It
doesn't matter who configures it or how, providing it happens.

We do presumably need some small core DMA changes - anyone trying to map
such a buffer into CPU space needs to get a warning or error but what
else ?

> >From buffer allocation point of view I also facing a problem because when 
> >v4l2
> or drm/kms are exporting buffers by using dma_buf they don't attaching
> themself on it and never call dma_buf_{map/unmap}_attachment(). This is not
> an issue in those framework while it is how dma_buf exporters are
> supposed to work.

Which could be addressed if need be.

So if "SDP" is just another IOMMU feature, just as stuff like IMR is on
some x86 devices, and hypervisor enforced protection is on assorted
platforms why do we need a special way to do it ? Is there anything
actually needed beyond being able to tell the existing DMA code that this
buffer won't be CPU touched and wiring it into the DMA operations for the
platform ?

Alan

i915 dma_map_sg return value

On Tue, May 05, 2015 at 09:42:44AM +0200, Volker Vogelhuber wrote:
> The documentation of the DMA-API writes the following about
> dma_map_sg:
> 
> "The implementation is free to merge several consecutive sglist entries
> into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
> consecutive sglist entries can be merged into one provided the first one
> ends and the second one starts on a page boundary - in fact this is a huge
> advantage for cards which either cannot do scatter-gather or have very
> limited number of scatter-gather entries) and returns the actual number
> of sg entries it mapped them to."
> 
> I wonder why the return value of dma_map_sg is not returned in any way
> from i915_gem_map_dma_buf. It only uses the return value for error
> checking.
> Can one be sure that in case of the i915 the nents value of the scatter
> gather table is always equal to the value returned by dma_map_sg?
> I'm asking because I want to use the sg table returned by
> i915_gem_map_dma_buf in my own kernel module and iterate over it
> using for_each_sg. And the example in the documentation of the DMA-API
> uses the return value of dma_map_sg when calling for_each_sg and not
> nents and it explicitly mentions:
> 
> "Then you should loop count times (note: this can be less than nents times)"

Hm, not looking at the return value of dma_map_sg is also how we use it
internally in i915_gem_gtt.c. Not sure why we get away with this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH 1/8] gpiolib: Add support for removing registered consumer lookup table

On Tue, May 05, 2015 at 11:45:05AM +0100, Lee Jones wrote:
> This is not how we submit subsequent patch-sets.

It is unfortunately how we handle patches on dri-devel&intel-gfx to be
able to cope with massive mail load. If everyone who submits to intel-gfx
would always resend the entire series for minor updates of som patches
we'd completely drown in the resulting flood.

> Please submit them as a whole, seperately from the first submission
> and with versioning information i.e. [PATCH v2 X/Y] Stuff ...
> 
> > In case we unload and load a driver module again that is registering a
> > lookup table, without this it will result in multiple entries. Provide
> > an option to remove the lookup table on driver unload
> > 
> > v2: Ccing maintainers
> > v3: Correct the subject line (Lee jones)
> 
> Change logs should go underneth the '---' and above the diffstat found
> below.

Again just style differences between subsystems, I generally want to have
those above the ---.
-Daniel
> 
> > Cc: Samuel Ortiz 
> > Cc: Linus Walleij 
> > Cc: Alexandre Courbot 
> > Cc: Thierry Reding 
> > Reviewed-by: Alexandre Courbot 
> > Signed-off-by: Shobhit Kumar 
> > ---
> >  drivers/gpio/gpiolib.c   | 13 +
> >  include/linux/gpio/machine.h |  1 +
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index 59eaa23..2420af9 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -1658,6 +1658,19 @@ void gpiod_add_lookup_table(struct 
> > gpiod_lookup_table *table)
> > mutex_unlock(&gpio_lookup_lock);
> >  }
> >  
> > +/**
> > + * gpiod_remove_lookup_table() - unregister GPIO device consumers
> > + * @table: table of consumers to unregister
> > + */
> > +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
> > +{
> > +   mutex_lock(&gpio_lookup_lock);
> > +
> > +   list_del(&table->list);
> > +
> > +   mutex_unlock(&gpio_lookup_lock);
> > +}
> > +
> >  static struct gpio_desc *of_find_gpio(struct device *dev, const char 
> > *con_id,
> >   unsigned int idx,
> >   enum gpio_lookup_flags *flags)
> > diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
> > index e270614..c0d712d 100644
> > --- a/include/linux/gpio/machine.h
> > +++ b/include/linux/gpio/machine.h
> > @@ -57,5 +57,6 @@ struct gpiod_lookup_table {
> >  }
> >  
> >  void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
> > +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
> >  
> >  #endif /* __LINUX_GPIO_MACHINE_H */
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org â Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers

On Tue, May 05, 2015 at 10:36:24AM -0400, Peter Hurley wrote:
> On 05/04/2015 12:52 AM, Mario Kleiner wrote:
> > On 04/16/2015 03:03 PM, Daniel Vetter wrote:
> >> On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wrote:
> >>> On 04/15/2015 01:31 PM, Daniel Vetter wrote:
>  On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
> > Hi Daniel,
> >
> > On 04/15/2015 03:17 AM, Daniel Vetter wrote:
> >> This was a bit too much cargo-culted, so lets make it solid:
> >> - vblank->count doesn't need to be an atomic, writes are always done
> >>under the protection of dev->vblank_time_lock. Switch to an unsigned
> >>long instead and update comments. Note that atomic_read is just a
> >>normal read of a volatile variable, so no need to audit all the
> >>read-side access specifically.
> >>
> >> - The barriers for the vblank counter seqlock weren't complete: The
> >>read-side was missing the first barrier between the counter read and
> >>the timestamp read, it only had a barrier between the ts and the
> >>counter read. We need both.
> >>
> >> - Barriers weren't properly documented. Since barriers only work if
> >>you have them on boths sides of the transaction it's prudent to
> >>reference where the other side is. To avoid duplicating the
> >>write-side comment 3 times extract a little store_vblank() helper.
> >>In that helper also assert that we do indeed hold
> >>dev->vblank_time_lock, since in some cases the lock is acquired a
> >>few functions up in the callchain.
> >>
> >> Spotted while reviewing a patch from Chris Wilson to add a fastpath to
> >> the vblank_wait ioctl.
> >>
> >> Cc: Chris Wilson 
> >> Cc: Mario Kleiner 
> >> Cc: Ville SyrjÃ¤lÃ¤ 
> >> Cc: Michel DÃ¤nzer 
> >> Signed-off-by: Daniel Vetter 
> >> ---
> >>   drivers/gpu/drm/drm_irq.c | 92 
> >> ---
> >>   include/drm/drmP.h|  8 +++--
> >>   2 files changed, 54 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> >> index c8a34476570a..23bfbc61a494 100644
> >> --- a/drivers/gpu/drm/drm_irq.c
> >> +++ b/drivers/gpu/drm/drm_irq.c
> >> @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, 
> >> drm_vblank_offdelay, int, 0600);
> >>   module_param_named(timestamp_precision_usec, 
> >> drm_timestamp_precision, int, 0600);
> >>   module_param_named(timestamp_monotonic, drm_timestamp_monotonic, 
> >> int, 0600);
> >>
> >> +static void store_vblank(struct drm_device *dev, int crtc,
> >> + unsigned vblank_count_inc,
> >> + struct timeval *t_vblank)
> >> +{
> >> +struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
> >> +u32 tslot;
> >> +
> >> +assert_spin_locked(&dev->vblank_time_lock);
> >> +
> >> +if (t_vblank) {
> >> +tslot = vblank->count + vblank_count_inc;
> >> +vblanktimestamp(dev, crtc, tslot) = *t_vblank;
> >> +}
> >> +
> >> +/*
> >> + * vblank timestamp updates are protected on the write side with
> >> + * vblank_time_lock, but on the read side done locklessly using a
> >> + * sequence-lock on the vblank counter. Ensure correct ordering 
> >> using
> >> + * memory barrriers. We need the barrier both before and also 
> >> after the
> >> + * counter update to synchronize with the next timestamp write.
> >> + * The read-side barriers for this are in 
> >> drm_vblank_count_and_time.
> >> + */
> >> +smp_wmb();
> >> +vblank->count += vblank_count_inc;
> >> +smp_wmb();
> >
> > The comment and the code are each self-contradictory.
> >
> > If vblank->count writes are always protected by vblank_time_lock 
> > (something I
> > did not verify but that the comment above asserts), then the trailing 
> > write
> > barrier is not required (and the assertion that it is in the comment is 
> > incorrect).
> >
> > A spin unlock operation is always a write barrier.
> 
>  Hm yeah. Otoh to me that's bordering on "code too clever for my own 
>  good".
>  That the spinlock is held I can assure. That no one goes around and does
>  multiple vblank updates (because somehow that code raced with the hw
>  itself) I can't easily assure with a simple assert or something similar.
>  It's not the case right now, but that can changes.
> >>>
> >>> The algorithm would be broken if multiple updates for the same vblank
> >>> count were allowed; that's why it checks to see if the vblank count has
> >>> not advanced before storing a new timestamp.
> >>>
> >>> Otherwise, the read side would not be able to determine that the
> >>> timestamp is valid

[RFC] How implement Secure Data Path ?

2015-05-05 Thread Benjamin Gaignard

Hello,

Since few months I'm looking for Linaro to how do Secure Data Path (SPD).
I have tried and implemented multiple thinks but I always facing architecture
issues so I would like to get your help to solve the problem.

First what is Secure Data Path ? SDP is a set of hardware features to garanty
that some memories regions could only be read and/or write by specific hardware
IPs. You can imagine it as a kind of memory firewall which grant/revoke
accesses to memory per devices. Firewall configuration must be done in a trusted
environment: for ARM architecture we plan to use OP-TEE + a trusted
application to do that.

One typical use case for SDP in a video playback which involve those elements:
decrypt -> video decoder -> transform -> display

decrypt output contains encoded data that need to be secure: only hardware video
decoder should be able to read them.
Hardware decoder output (decoded frame) can only be read by hardware
transform and
only hardware display can read transform output.
Video decoder and transform are v4l2 devices and display is a drm/kms device.

To be able to configure the firewall SDP need to know when each device need to
have access to memory (physical address and size) and in which direction (read
or write).
SDP also need a way to transfert information that memory is secure between
different frameworks and devices.
Obviously I also want to limit the impact of SDP in userland and kernel:
For example not change the way of how buffers are allocating or how
graph/pipeline
are setup.

When looking to all those constraints I have try to use dma_buf: it is a cross
frameworks and processes way to share buffers and, with
dma_buf_map_attachment() and dma_buf_unmap_attachment() functions, have an API
that provide the informations (device, memory, direction) to configure
the firewall.

I have try 2 "hacky" approachs with dma_buf:
- add a secure field in dma_buf structure and configure firewall in
  dma_buf_{map/unmap}_attachment() functions.
- overwrite dma_buf exporter ops to have a kind of nested calls which allow to
  configure firewall without impacting the exporter code.

The both solutions have architecture issues, the first one add a "metadata"
into dma_buf structure and calls to a specific SDP environment (OP-TEE +
trusted application) and second obvious break dma_buf coding rules
when overwriting
exporter ops.

>From buffer allocation point of view I also facing a problem because when v4l2
or drm/kms are exporting buffers by using dma_buf they don't attaching
themself on it and never call dma_buf_{map/unmap}_attachment(). This is not
an issue in those framework while it is how dma_buf exporters are
supposed to work.

Using an "external" allocator (like ION) solve this problem but I think in
this case we will have the same problem than for the "constraint aware
allocator" which has never been accepted.

The goal of this RFC is to share/test ideas to solve this problem which at
least impact v4l2 and drm/kms.
Any suggestions/inputs are welcome !

Regards,
Benjamin

[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver

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

Bug ID: 90320
Summary: Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in
screen with radeon kms driver
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: blocker
Priority: highest
Component: DRM/Radeon
Assignee: dri-devel at lists.freedesktop.org
Reporter: sibradzic at gmail.com

Created attachment 115550
--> https://bugs.freedesktop.org/attachment.cgi?id=115550&action=edit
dmesg 4.1 rc1

As soon as the radeon kms switches in from efifb, the screen goes blank for the
moment (no backlight), and then the backlight switches in, but the screen
remains black. External HDMI output works just fine. No X is involved, I can't
even see the kms console @ eDP. I can even control the backlight on the eDP
display, but all i get is the various shades of black. Fglrx works fine,
although it flickers wildly before the picture gets stable.

I've tried numerous things, like forcing EDID that was grabbed from fglrx,
disabling audio, applying all the DP training / backlight disabling patches as
in https://bugs.freedesktop.org/show_bug.cgi?id=73530, all to no avail.
Currently on linux 4.1rc1, tried 3.13, 3.16 & 3.19 as well, same issue.

Please help! I bought this laptop cause I prefer AMD, and was expecting Lenovo
to work great with Linux, but so far its broken. Ready to try some patches...

--
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/20150505/8a0360e9/attachment.html>

[Bug 90284] GPU lockup with DOTA2

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

Alex Deucher  changed:

   What|Removed |Added

  Component|DRM/Radeon  |Drivers/Gallium/radeonsi
Version|XOrg git|10.5
Product|DRI |Mesa
Summary|radeon crashes (ring 0  |GPU lockup with DOTA2
   |stall) with GPU fault   |
   |detected: 147, and *ERROR*  |
   |radeon: dpm resume failed.  |
 QA Contact||dri-devel at lists.freedesktop
   ||.org

-- 
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/20150505/3ec6e46a/attachment.html>

[PATCH] drmPrime*: initialize output args to 0

2015-05-05 Thread Emil Velikov

Hi Guillaume,

On 29 April 2015 at 09:16, Guillaume Desmottes
 wrote:
> Fix Valgrind errors because those memory was uninitialized.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=90194
> Signed-off-by: Guillaume Desmottes 
> ---
>  xf86drm.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index f7c45f8..01c398e 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2724,6 +2724,7 @@ int drmPrimeHandleToFD(int fd, uint32_t handle, 
> uint32_t flags, int *prime_fd)
> struct drm_prime_handle args;
> int ret;
>
> +   args.fd = -1;
> args.handle = handle;
> args.flags = flags;
> ret = drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args);
> @@ -2739,6 +2740,7 @@ int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t 
> *handle)
> struct drm_prime_handle args;
> int ret;
>
> +   args.handle = 0;
> args.fd = prime_fd;
> args.flags = 0;
> ret = drmIoctl(fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, &args);

As mentioned before one could add the appropriate Valgrind
annotations. Although using memclear() or this will do just fine :-)
Any objections against memclear ? it will save us some head-scratching
when/if someone decides to extend struct drm_prime_handle. If you and
others are ok with it, I'll amend the patch locally before pushing in
the next week or so.

Thanks
Emil

[PATCH] libgencec: Add userspace library for the generic CEC kernel interface

2015-05-05 Thread Emil Velikov

Hi Kamil,

It seems that you've only incorporated the libgencec.pc suggestion.
Did you change your mind about the others, found out something funny
with them (if so can you let me know what) or simply forgot about them
?

On 30 April 2015 at 11:25, Kamil Debski  wrote:
> Hi Emil,
>
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> owner at vger.kernel.org] On Behalf Of Emil Velikov
> Sent: Wednesday, April 29, 2015 5:00 PM
>>
>> Hi Kamil,
>>
>> Allow me to put a few suggestions:
>>
>> On 29 April 2015 at 11:02, Kamil Debski  wrote:

>> > diff --git a/m4/.gitkeep b/m4/.gitkeep new file mode 100644 index
>> > 000..e69de29
>> Haven't seen any projects doing this. Curious what the benefits of
>> keeping and empty folder might be ?
>
> When I run autoreconf -i it complained about missing m4 folder, hence I added
> this filler file such that the folder is created. Any suggestion on how to do
> this better?
>
Ahh yes - that lovely message. It turns out that older versions of
automake will even error out [1], rather than just printing out a
warning. A handy workaround would be to add a .gitignore (and a second
one in the top folder) list. Plus it will slim down the untracked
files list and let you clearly see when git add was missed :-)

Cheers
Emil

[1] https://bugzilla.redhat.com/show_bug.cgi?id=901333

[PATCH 5/8] drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM

On 04/29/2015 07:54 PM, Lee Jones wrote:
> On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> 
>> On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
>> entry for the same to be used by the consumer (Intel GFX)
>>
>> v2: Remove the lookup table on driver unload (Thierry)
>>
>> CC: Samuel Ortiz 
>> Cc: Linus Walleij 
>> Cc: Alexandre Courbot 
>> Cc: Thierry Reding 
>> Signed-off-by: Shobhit Kumar 
>> ---
>>  drivers/mfd/intel_soc_pmic_core.c | 12 
>>  1 file changed, 12 insertions(+)
> 
> How do you expect this set to be managed?

There are some dependencies on the look up table remove functionality in
earlier patches, so I think 3/8 can go in only after 1/8. Similarly 5/8
can go only after 2/8. Rest all can be independent. 

Regards
Shobhit

> 
> Acked-by: Lee Jones 
> 
>> diff --git a/drivers/mfd/intel_soc_pmic_core.c 
>> b/drivers/mfd/intel_soc_pmic_core.c
>> index f3d918e..a00ddd9 100644
>> --- a/drivers/mfd/intel_soc_pmic_core.c
>> +++ b/drivers/mfd/intel_soc_pmic_core.c
>> @@ -25,6 +25,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "intel_soc_pmic_core.h"
>>  
>>  /* Lookup table for the Panel Enable/Disable line as GPIO signals */
>> @@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
>>  },
>>  };
>>  
>> +/* PWM consumed by the Intel GFX */
>> +static struct pwm_lookup crc_pwm_lookup[] = {
>> +PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0, 
>> PWM_POLARITY_NORMAL),
>> +};
>> +
>>  static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>>  {
>>  struct gpio_desc *desc;
>> @@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client 
>> *i2c,
>>  /* Add lookup table binding for Panel Control to the GPIO Chip */
>>  gpiod_add_lookup_table(&panel_gpio_table);
>>  
>> +/* Add lookup table for crc-pwm */
>> +pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
>> +
>>  ret = mfd_add_devices(dev, -1, config->cell_dev,
>>config->n_cell_devs, NULL, 0,
>>regmap_irq_get_domain(pmic->irq_chip_data));
>> @@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client 
>> *i2c)
>>  /* Remove lookup table for Panel Control from the GPIO Chip */
>>  gpiod_remove_lookup_table(&panel_gpio_table);
>>  
>> +/* remove crc-pwm lookup table */
>> +pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
>> +
>>  mfd_remove_devices(&i2c->dev);
>>  
>>  return 0;
>

[PATCH 6/8] pwm: crc: Add Crystalcove (CRC) PWM driver

The Crystalcove PMIC controls PWM signals and this driver exports that
capability as a PWM chip driver. This is platform device implementtaion
of the drivers/mfd cell device for CRC PMIC

v2: Use the existing config callback with duty_ns and period_ns(Thierry)

v3: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/pwm/Kconfig   |   7 +++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-crc.c | 171 ++
 3 files changed, 179 insertions(+)
 create mode 100644 drivers/pwm/pwm-crc.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f4..954da3e 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -183,6 +183,13 @@ config PWM_LPC32XX
  To compile this driver as a module, choose M here: the module
  will be called pwm-lpc32xx.

+config PWM_CRC
+   bool "Intel Crystalcove (CRC) PWM support"
+   depends on X86 && INTEL_SOC_PMIC
+   help
+ Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
+ control.
+
 config PWM_LPSS
tristate "Intel LPSS PWM support"
depends on X86
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index ec50eb5..3d38fed 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_PWM_TIPWMSS) += pwm-tipwmss.o
 obj-$(CONFIG_PWM_TWL)  += pwm-twl.o
 obj-$(CONFIG_PWM_TWL_LED)  += pwm-twl-led.o
 obj-$(CONFIG_PWM_VT8500)   += pwm-vt8500.o
+obj-$(CONFIG_PWM_CRC)  += pwm-crc.o
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
new file mode 100644
index 000..987f3b4
--- /dev/null
+++ b/drivers/pwm/pwm-crc.c
@@ -0,0 +1,171 @@
+/*
+ * pwm-crc.c - Intel Crystal Cove PWM Driver
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Author: Shobhit Kumar 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PWM0_CLK_DIV   0x4B
+#define  PWM_OUTPUT_ENABLE (1<<7)
+#define  PWM_DIV_CLK_0 0x00 /* DIVIDECLK = BASECLK */
+#define  PWM_DIV_CLK_100   0x63 /* DIVIDECLK = BASECLK/100 */
+#define  PWM_DIV_CLK_128   0x7F /* DIVIDECLK = BASECLK/128 */
+
+#define PWM0_DUTY_CYCLE0x4E
+#define BACKLIGHT_EN   0x51
+
+#define PWM_MAX_LEVEL  0xFF
+
+#define PWM_BASE_CLK   6000/* 6 MHz */
+#define PWM_MAX_PERIOD_NS  21333 /* 46.875KHz */
+
+/**
+ * struct crystalcove_pwm - Crystal Cove PWM controller
+ * @chip: the abstract pwm_chip structure.
+ * @regmap: the regmap from the parent device.
+ */
+struct crystalcove_pwm {
+   struct pwm_chip chip;
+   struct platform_device *pdev;
+   struct regmap *regmap;
+};
+
+static inline struct crystalcove_pwm *to_crc_pwm(struct pwm_chip *pc)
+{
+   return container_of(pc, struct crystalcove_pwm, chip);
+}
+
+static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+
+   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+
+   return 0;
+}
+
+static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+
+   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+}
+
+static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+   struct device *dev = &crc_pwm->pdev->dev;
+   int level, percent;
+
+   if (period_ns > PWM_MAX_PERIOD_NS) {
+   dev_err(dev, "un-supported period_ns\n");
+   return -1;
+   }
+
+   if (pwm->period != period_ns) {
+   int clk_div;
+
+   /* changing the clk divisor, need to disable fisrt */
+   crc_pwm_disable(c, pwm);
+   clk_div = PWM_BASE_CLK * period_ns / 100;
+
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
+   clk_div | PWM_OUTPUT_ENABLE);
+
+   /* enable back */
+   crc_pwm_enable(c, pwm);
+   }
+
+   if (duty_ns > period_ns) {
+   dev_err(dev, "duty cycle cannot be greater than cycle 
period\n");
+   return -1;
+   }
+
+   /* change the pwm duty cycle */
+   percent = duty_ns * 100 / period_ns;
+   level = percent * PWM_MAX_LEVEL / 100;
+   regmap_write(crc_pwm->regmap,

[PATCH 5/8] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM

On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
entry for the same to be used by the consumer (Intel GFX)

v2: Remove the lookup table on driver unload (Thierry)

v3: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Acked-by: Lee Jones 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_core.c 
b/drivers/mfd/intel_soc_pmic_core.c
index f3d918e..a00ddd9 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_soc_pmic_core.h"

 /* Lookup table for the Panel Enable/Disable line as GPIO signals */
@@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
},
 };

+/* PWM consumed by the Intel GFX */
+static struct pwm_lookup crc_pwm_lookup[] = {
+   PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0, 
PWM_POLARITY_NORMAL),
+};
+
 static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 {
struct gpio_desc *desc;
@@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
/* Add lookup table binding for Panel Control to the GPIO Chip */
gpiod_add_lookup_table(&panel_gpio_table);

+   /* Add lookup table for crc-pwm */
+   pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
ret = mfd_add_devices(dev, -1, config->cell_dev,
  config->n_cell_devs, NULL, 0,
  regmap_irq_get_domain(pmic->irq_chip_data));
@@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)
/* Remove lookup table for Panel Control from the GPIO Chip */
gpiod_remove_lookup_table(&panel_gpio_table);

+   /* remove crc-pwm lookup table */
+   pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
mfd_remove_devices(&i2c->dev);

return 0;
-- 
2.1.0

[PATCH 4/8] mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC

Needed for PWM control suuported by the PMIC

v2: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Acked-by: Lee Jones 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_crc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index 4cc1b32..8839e25 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
{
.name = "crystal_cove_pmic",
},
+   {
+   .name = "crystal_cove_pwm",
+   },
 };

 static const struct regmap_config crystal_cove_regmap_config = {
-- 
2.1.0

[PATCH] gma500:Remove functions that are now deprecated and move to the newer functions in drm_dp_helper.c

2015-05-05 Thread Patrik Jakobsson

On Tue, May 5, 2015 at 12:29 AM, Nicholas Krause  wrote:
> This removes the deprecated functions,i2c_dp_aux_add_bus and
> i2c_dp_aux_prepare_bus and the only call in the function,
> cdv_intel_dp_i2c_init to i2c_dp_aux_add_bus respectfully.
> The call and use of these functions is now replaced alongside
> the removal of setting other values in the function,cdv_intel_dp_i2c_init
> to use the helper function, drm_dp_aux_register that can handle all this
> work internally.

You need to fill in the drm_dp_aux structure and implement a proper transfer
function. This patch would only break things. But the cdv dp output is already
broken on my system so it needs fixing first.

-Patrik

> Signed-off-by: Nicholas Krause 
> ---
>  drivers/gpu/drm/gma500/cdv_intel_dp.c | 42 
> ++-
>  1 file changed, 2 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
> b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> index 0fafb8e..c8c20fc 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> @@ -200,38 +200,6 @@ static const struct i2c_algorithm i2c_dp_aux_algo = {
> .functionality  = i2c_algo_dp_aux_functionality,
>  };
>
> -static void
> -i2c_dp_aux_reset_bus(struct i2c_adapter *adapter)
> -{
> -   (void) i2c_algo_dp_aux_address(adapter, 0, false);
> -   (void) i2c_algo_dp_aux_stop(adapter, false);
> -}
> -
> -static int
> -i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter)
> -{
> -   adapter->algo = &i2c_dp_aux_algo;
> -   adapter->retries = 3;
> -   i2c_dp_aux_reset_bus(adapter);
> -   return 0;
> -}
> -
> -/*
> - * FIXME: This is the old dp aux helper, gma500 is the last driver that 
> needs to
> - * be ported over to the new helper code in drm_dp_helper.c like i915 or 
> radeon.
> - */
> -static int __deprecated
> -i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
> -{
> -   int error;
> -
> -   error = i2c_dp_aux_prepare_bus(adapter);
> -   if (error)
> -   return error;
> -   error = i2c_add_adapter(adapter);
> -   return error;
> -}
> -
>  #define _wait_for(COND, MS, W) ({ \
>  unsigned long timeout__ = jiffies + msecs_to_jiffies(MS);   \
>  int ret__ = 0;  \
> @@ -275,6 +243,7 @@ struct cdv_intel_dp {
> int backlight_on_delay;
> int backlight_off_delay;
> struct drm_display_mode *panel_fixed_mode;  /* for eDP */
> +   struct drm_dp_aux aux;
> bool panel_on;
>  };
>
> @@ -855,18 +824,11 @@ cdv_intel_dp_i2c_init(struct gma_connector *connector,
> intel_dp->algo.running = false;
> intel_dp->algo.address = 0;
> intel_dp->algo.aux_ch = cdv_intel_dp_i2c_aux_ch;
> -
> memset(&intel_dp->adapter, '\0', sizeof (intel_dp->adapter));
> -   intel_dp->adapter.owner = THIS_MODULE;
> -   intel_dp->adapter.class = I2C_CLASS_DDC;
> -   strncpy (intel_dp->adapter.name, name, sizeof(intel_dp->adapter.name) 
> - 1);
> -   intel_dp->adapter.name[sizeof(intel_dp->adapter.name) - 1] = '\0';
> -   intel_dp->adapter.algo_data = &intel_dp->algo;
> -   intel_dp->adapter.dev.parent = connector->base.kdev;
>
> if (is_edp(encoder))
> cdv_intel_edp_panel_vdd_on(encoder);
> -   ret = i2c_dp_aux_add_bus(&intel_dp->adapter);
> +   ret = drm_dp_aux_register(&intel_dp->aux);
> if (is_edp(encoder))
> cdv_intel_edp_panel_vdd_off(encoder);
>
> --
> 2.1.4
>

[PATCH 3/8] mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal

On some Intel SoC platforms, the panel enable/disable signals are
controlled by CRC PMIC. Add those control as a new GPIO in a lookup
table for gpio-crystalcove chip during CRC driver load

v2: Make the lookup table static (Thierry)
Remove the lookup table during driver remove (Thierry)

v3: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Acked-by: Lee Jones 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_core.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_core.c 
b/drivers/mfd/intel_soc_pmic_core.c
index 7b50b6b..f3d918e 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -24,8 +24,19 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_soc_pmic_core.h"

+/* Lookup table for the Panel Enable/Disable line as GPIO signals */
+static struct gpiod_lookup_table panel_gpio_table = {
+   /* Intel GFX is consumer */
+   .dev_id = ":00:02.0",
+   .table = {
+   /* Panel EN/DISABLE */
+   GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
+   },
+};
+
 static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 {
struct gpio_desc *desc;
@@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
if (ret)
dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);

+   /* Add lookup table binding for Panel Control to the GPIO Chip */
+   gpiod_add_lookup_table(&panel_gpio_table);
+
ret = mfd_add_devices(dev, -1, config->cell_dev,
  config->n_cell_devs, NULL, 0,
  regmap_irq_get_domain(pmic->irq_chip_data));
@@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)

regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);

+   /* Remove lookup table for Panel Control from the GPIO Chip */
+   gpiod_remove_lookup_table(&panel_gpio_table);
+
mfd_remove_devices(&i2c->dev);

return 0;
-- 
2.1.0

[PATCH 2/8] pwm: core: Add support to remove registered consumer lookup tables

In case some drivers are unloading, they can remove lookup tables which
they would have registered during their load time to avoid redundant
entries if loaded again

v2: Ccing maintainers
v3: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/pwm/core.c  | 17 +
 include/linux/pwm.h |  5 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index ba34c7d..d2fe7c8d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -586,6 +586,23 @@ void pwm_add_table(struct pwm_lookup *table, size_t num)
 }

 /**
+ * pwm_remove_table() - un-register PWM device consumers
+ * @table: array of consumers to un-register
+ * @num: number of consumers in table
+ */
+void pwm_remove_table(struct pwm_lookup *table, size_t num)
+{
+   mutex_lock(&pwm_lookup_lock);
+
+   while (num--) {
+   list_del(&table->list);
+   table++;
+   }
+
+   mutex_unlock(&pwm_lookup_lock);
+}
+
+/**
  * pwm_get() - look up and request a PWM device
  * @dev: device for PWM consumer
  * @con_id: consumer name
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index e90628c..cfe2d8d 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -290,10 +290,15 @@ struct pwm_lookup {

 #if IS_ENABLED(CONFIG_PWM)
 void pwm_add_table(struct pwm_lookup *table, size_t num);
+void pwm_remove_table(struct pwm_lookup *table, size_t num);
 #else
 static inline void pwm_add_table(struct pwm_lookup *table, size_t num)
 {
 }
+
+static inline void pwm_remove_table(struct pwm_lookup *table, size_t num)
+{
+}
 #endif

 #ifdef CONFIG_PWM_SYSFS
-- 
2.1.0

[PATCH 1/8] gpiolib: Add support for removing registered consumer lookup table

In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload

v2: Ccing maintainers
v3: Correct the subject line (Lee jones)

Cc: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Reviewed-by: Alexandre Courbot 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpio/gpiolib.c   | 13 +
 include/linux/gpio/machine.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 59eaa23..2420af9 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1658,6 +1658,19 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table 
*table)
mutex_unlock(&gpio_lookup_lock);
 }

+/**
+ * gpiod_remove_lookup_table() - unregister GPIO device consumers
+ * @table: table of consumers to unregister
+ */
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
+{
+   mutex_lock(&gpio_lookup_lock);
+
+   list_del(&table->list);
+
+   mutex_unlock(&gpio_lookup_lock);
+}
+
 static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
  unsigned int idx,
  enum gpio_lookup_flags *flags)
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index e270614..c0d712d 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -57,5 +57,6 @@ struct gpiod_lookup_table {
 }

 void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);

 #endif /* __LINUX_GPIO_MACHINE_H */
-- 
2.1.0

[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers

2015-05-05 Thread Peter Hurley

On 05/05/2015 11:57 AM, Peter Hurley wrote:
> On 05/05/2015 11:42 AM, Daniel Vetter wrote:
>> I'm also somewhat confused about how you to a line across both cpus for
>> barriers because barriers only have cpu-local effects (which is why we
>> always need a barrier on both ends of a transaction).

I'm sorry if my barrier notation confuses you; I find that it clearly
identifies matching pairs.

Also, there is a distinction between "can be visible" and "must be visible";
the load and stores themselves are not cpu-local.

Regards,
Peter Hurley

[PATCH] qxl: rewrite framebuffer support

2015-05-05 Thread Gerd Hoffmann

Completely different approach:  Instead of encoding each and every
framebuffer update as spice operation simply update the shadow
framebuffer and maintain a dirty rectangle.  Also schedule a worker
to push an update for the dirty rectangle as spice operation.  Usually
a bunch of dirty rectangle updates are collected before the worker
actually runs.

What changes:  Updates get batched now.  Instead of sending tons of
small updates a few large ones are sent.  When the same region is
updated multiple times within a short timeframe (scrolling multiple
lines for example) we send a single update only.  Spice server has an
easier job now:  The dependency tree for display operations which spice
server maintains for lazy rendering is alot smaller now.  Spice server's
image compression probably works better too with the larger image blits.

Net effect:  framebuffer console @ qxldrmfb is an order of magnitude
faster now.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 275 +--
 1 file changed, 57 insertions(+), 218 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index f778c0e..6b6e57e 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -37,21 +37,6 @@

 #define QXL_DIRTY_DELAY (HZ / 30)

-#define QXL_FB_OP_FILLRECT 1
-#define QXL_FB_OP_COPYAREA 2
-#define QXL_FB_OP_IMAGEBLIT 3
-
-struct qxl_fb_op {
-   struct list_head head;
-   int op_type;
-   union {
-   struct fb_fillrect fr;
-   struct fb_copyarea ca;
-   struct fb_image ib;
-   } op;
-   void *img_data;
-};
-
 struct qxl_fbdev {
struct drm_fb_helper helper;
struct qxl_framebuffer  qfb;
@@ -66,7 +51,6 @@ struct qxl_fbdev {
/* dirty memory logging */
struct {
spinlock_t lock;
-   bool active;
unsigned x1;
unsigned y1;
unsigned x2;
@@ -105,23 +89,33 @@ static void qxl_fb_dirty_flush(struct fb_info *info)
struct qxl_device *qdev = qfbdev->qdev;
struct qxl_fb_image qxl_fb_image;
struct fb_image *image = &qxl_fb_image.fb_image;
+   unsigned long flags;
u32 x1, x2, y1, y2;

/* TODO: hard coding 32 bpp */
int stride = qfbdev->qfb.base.pitches[0];

+   spin_lock_irqsave(&qfbdev->dirty.lock, flags);
+
x1 = qfbdev->dirty.x1;
x2 = qfbdev->dirty.x2;
y1 = qfbdev->dirty.y1;
y2 = qfbdev->dirty.y2;
+   qfbdev->dirty.x1 = 0;
+   qfbdev->dirty.x2 = 0;
+   qfbdev->dirty.y1 = 0;
+   qfbdev->dirty.y2 = 0;
+
+   spin_unlock_irqrestore(&qfbdev->dirty.lock, flags);
+
/*
 * we are using a shadow draw buffer, at qdev->surface0_shadow
 */
qxl_io_log(qdev, "dirty x[%d, %d], y[%d, %d]", x1, x2, y1, y2);
image->dx = x1;
image->dy = y1;
-   image->width = x2 - x1;
-   image->height = y2 - y1;
+   image->width = x2 - x1 + 1;
+   image->height = y2 - y1 + 1;
image->fg_color = 0x; /* unused, just to avoid uninitialized
 warnings */
image->bg_color = 0;
@@ -136,10 +130,37 @@ static void qxl_fb_dirty_flush(struct fb_info *info)

qxl_fb_image_init(&qxl_fb_image, qdev, info, NULL);
qxl_draw_opaque_fb(&qxl_fb_image, stride);
-   qfbdev->dirty.x1 = 0;
-   qfbdev->dirty.x2 = 0;
-   qfbdev->dirty.y1 = 0;
-   qfbdev->dirty.y2 = 0;
+}
+
+static void qxl_dirty_update(struct qxl_fbdev *qfbdev,
+int x, int y, int width, int height)
+{
+   struct qxl_device *qdev = qfbdev->qdev;
+   unsigned long flags;
+   int x2, y2;
+
+   x2 = x + width - 1;
+   y2 = y + height - 1;
+
+   spin_lock_irqsave(&qfbdev->dirty.lock, flags);
+
+   if (qfbdev->dirty.y1 < y)
+   y = qfbdev->dirty.y1;
+   if (qfbdev->dirty.y2 > y2)
+   y2 = qfbdev->dirty.y2;
+   if (qfbdev->dirty.x1 < x)
+   x = qfbdev->dirty.x1;
+   if (qfbdev->dirty.x2 > x2)
+   x2 = qfbdev->dirty.x2;
+
+   qfbdev->dirty.x1 = x;
+   qfbdev->dirty.x2 = x2;
+   qfbdev->dirty.y1 = y;
+   qfbdev->dirty.y2 = y2;
+
+   spin_unlock_irqrestore(&qfbdev->dirty.lock, flags);
+
+   schedule_work(&qdev->fb_work);
 }

 static void qxl_deferred_io(struct fb_info *info,
@@ -162,234 +183,51 @@ static void qxl_deferred_io(struct fb_info *info,
if (min < max) {
y1 = min / info->fix.line_length;
y2 = (max / info->fix.line_length) + 1;
-
-   /* TODO: add spin lock? */
-   /* spin_lock_irqsave(&qfbdev->dirty.lock, flags); */
-   qfbdev->dirty.x1 = 0;
-   qfbdev->dirty.y1 = y1;
-   qfbdev->dirty.x2 = info->var.xres;
-   qfbdev->dirty.y2 = y2;
-   /* spin_unlock_irqrestore(&qfbdev->

[PATCH] gma500:Remove functions that are now deprecated and move to the newer functions in drm_dp_helper.c

2015-05-05 Thread Alan Cox

On Mon, 2015-05-04 at 18:29 -0400, Nicholas Krause wrote:
> This removes the deprecated functions,i2c_dp_aux_add_bus and 
> i2c_dp_aux_prepare_bus and the only call in the function,
> cdv_intel_dp_i2c_init to i2c_dp_aux_add_bus respectfully. 
> The call and use of these functions is now replaced alongside 
> the removal of setting other values in the function,cdv_intel_dp_i2c_init
> to use the helper function, drm_dp_aux_register that can handle all this 
> work internally.

Which devices have you tested this on ?

Alan

[PATCH v6 03/11] dts: exynos4412-odroid*: enable the HDMI CEC device

2015-05-05 Thread Krzysztof Kozłowski

2015-05-05 2:32 GMT+09:00 Kamil Debski :
> Add a dts node entry and enable the HDMI CEC device present in the Exynos4
> family of SoCs.
>
> Signed-off-by: Kamil Debski 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[PATCH v6 02/11] dts: exynos4: add node for the HDMI CEC device

2015-05-05 Thread Krzysztof Kozłowski

2015-05-05 2:32 GMT+09:00 Kamil Debski :
> This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.
>
> Signed-off-by: Kamil Debski 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[PATCH v6 01/11] dts: exynos4*: add HDMI CEC pin definition to pinctrl

2015-05-05 Thread Krzysztof Kozłowski

2015-05-05 2:32 GMT+09:00 Kamil Debski :
> Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
> Exynos4x12 SoCs. These are required by the HDMI CEC device.
>
> Signed-off-by: Kamil Debski 

Acked-by: Krzysztof Kozlowski 

Are there any objections to picking the DTS changes independently?

Best regards,
Krzysztof

[Bug 89405] radeon: ERROR invalid ioctl running weston-launch while X is running

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

--- Comment #5 from fosero at gmail.com ---
Created attachment 115545
  --> https://bugs.freedesktop.org/attachment.cgi?id=115545&action=edit
boot gdm on wayland connected through HDMI

-- 
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/20150505/b9b92693/attachment.html>

[Bug 89405] radeon: ERROR invalid ioctl running weston-launch while X is running

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

--- Comment #4 from fosero at gmail.com ---
Created attachment 115544
  --> https://bugs.freedesktop.org/attachment.cgi?id=115544&action=edit
boot into gdm on wayland connected through VGA

-- 
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/20150505/413ab292/attachment.html>

[Bug 89405] radeon: ERROR invalid ioctl running weston-launch while X is running

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

--- Comment #3 from fosero at gmail.com ---
Cairo with image backend makes no difference. I actually have no text console
either, but I'm pretty sure I run weston the right way. Weston and gdm
(wayland) run just fine, but just don't show up on the screen.

I actually think it's a general problem with initializing, since I have no text
console as well or plymouth splash if enabled. The machine is usually connected
trough HDMI to a nobrand HD720 TV. When I connect the same setup through VGA it
does give an image (however the image is positioned wrong). I explicitly
disable the VGA output when using HDMI trough the kernel command line :
 video=HDMI-A-1:1280x720 at 60 video=VGA-1:d radeon.audio=1 radeon.modeset=1
radeon.dpm=1 .

The weird thing is that if I start X it does show up and subsequent runs of
weston or gdm on wayland are just fine, so it just happens after a fresh boot.

Attached 2 more logs with drm.debug=0xe, one for a boot with HDMI and one for
boot with VGA into gdm on wayland.

By the way, the invalid ioctl message in #1 disappeared since switching to the
4.0 kernel.

-- 
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/20150505/fc5db8fd/attachment.html>

[PATCH] drm/amdkfd: allow unregister process with queues

On Tue, May 5, 2015 at 4:39 AM, Oded Gabbay  wrote:
> Sometimes we might unregister process that have queues, because we couldn't
> preempt the queues. Until now we blocked it with BUG_ON but instead just
> print it as debug.
>
> Reviewed-by: Ben Goz 
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 


> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 69af73f..7b1d510 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -430,9 +430,10 @@ static int unregister_process_nocpsch(struct 
> device_queue_manager *dqm,
>
> BUG_ON(!dqm || !qpd);
>
> -   BUG_ON(!list_empty(&qpd->queues_list));
> +   pr_debug("In func %s\n", __func__);
>
> -   pr_debug("kfd: In func %s\n", __func__);
> +   pr_debug("qpd->queues_list is %s\n",
> +   list_empty(&qpd->queues_list) ? "empty" : "not 
> empty");
>
> retval = 0;
> mutex_lock(&dqm->lock);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/amdkfd: make the sdma vm init to be asic specific

On Tue, May 5, 2015 at 5:03 AM, Oded Gabbay  wrote:
> Signed-off-by: Oded Gabbay 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c| 15 +--
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h|  3 +++
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c| 16 
> 
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c |  8 
>  4 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 69af73f..1eb1022 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -614,19 +614,6 @@ static void deallocate_sdma_queue(struct 
> device_queue_manager *dqm,
> set_bit(sdma_queue_id, (unsigned long *)&dqm->sdma_bitmap);
>  }
>
> -static void init_sdma_vm(struct device_queue_manager *dqm, struct queue *q,
> -   struct qcm_process_device *qpd)
> -{
> -   uint32_t value = SDMA_ATC;
> -
> -   if (q->process->is_32bit_user_mode)
> -   value |= SDMA_VA_PTR32 | get_sh_mem_bases_32(qpd_to_pdd(qpd));
> -   else
> -   value |= SDMA_VA_SHARED_BASE(get_sh_mem_bases_nybble_64(
> -   qpd_to_pdd(qpd)));
> -   q->properties.sdma_vm_addr = value;
> -}
> -
>  static int create_sdma_queue_nocpsch(struct device_queue_manager *dqm,
> struct queue *q,
> struct qcm_process_device *qpd)
> @@ -649,7 +636,7 @@ static int create_sdma_queue_nocpsch(struct 
> device_queue_manager *dqm,
> pr_debug(" sdma queue id: %d\n", q->properties.sdma_queue_id);
> pr_debug(" sdma engine id: %d\n", q->properties.sdma_engine_id);
>
> -   init_sdma_vm(dqm, q, qpd);
> +   dqm->ops_asic_specific.init_sdma_vm(dqm, q, qpd);
> retval = mqd->init_mqd(mqd, &q->mqd, &q->mqd_mem_obj,
> &q->gart_mqd_addr, &q->properties);
> if (retval != 0) {
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> index 650ae1c..57278e2 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> @@ -130,6 +130,9 @@ struct device_queue_manager_asic_ops {
>enum cache_policy alternate_policy,
>void __user 
> *alternate_aperture_base,
>uint64_t alternate_aperture_size);
> +   void(*init_sdma_vm)(struct device_queue_manager *dqm,
> +   struct queue *q,
> +   struct qcm_process_device *qpd);


Maybe call it, init_vm() in cause you need to do something queue
specific for other rings?  Either way, this series is:
Reviewed-by: Alex Deucher 

>  };
>
>  /**
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
> index 292d13f..9ce8a20 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
> @@ -33,12 +33,15 @@ static bool set_cache_memory_policy_cik(struct 
> device_queue_manager *dqm,
>  static int register_process_cik(struct device_queue_manager *dqm,
> struct qcm_process_device *qpd);
>  static int initialize_cpsch_cik(struct device_queue_manager *dqm);
> +static void init_sdma_vm(struct device_queue_manager *dqm, struct queue *q,
> +   struct qcm_process_device *qpd);
>
>  void device_queue_manager_init_cik(struct device_queue_manager_asic_ops *ops)
>  {
> ops->set_cache_memory_policy = set_cache_memory_policy_cik;
> ops->register_process = register_process_cik;
> ops->initialize = initialize_cpsch_cik;
> +   ops->init_sdma_vm = init_sdma_vm;
>  }
>
>  static uint32_t compute_sh_mem_bases_64bit(unsigned int top_address_nybble)
> @@ -129,6 +132,19 @@ static int register_process_cik(struct 
> device_queue_manager *dqm,
> return 0;
>  }
>
> +static void init_sdma_vm(struct device_queue_manager *dqm, struct queue *q,
> +   struct qcm_process_device *qpd)
> +{
> +   uint32_t value = SDMA_ATC;
> +
> +   if (q->process->is_32bit_user_mode)
> +   value |= SDMA_VA_PTR32 | get_sh_mem_bases_32(qpd_to_pdd(qpd));
> +   else
> +   value |= SDMA_VA_SHARED_BASE(get_sh_mem_bases_nybble_64(
> +   qpd_to_pdd(qpd)));
> +   q->properties.sdma_vm_addr = value;
> +}
> +
>  static int initialize_cpsch_cik(struct device_queue_manager *dqm)
>  {
>

[PATCH] drm/amdkfd: Initialize sdma vm when creating sdma queue

On Tue, May 5, 2015 at 4:40 AM, Oded Gabbay  wrote:
> From: Xihan Zhang 
>
> This patch fixes a bug where sdma vm wasn't initialized when
> an sdma queue was created in HWS mode.
>
> This caused GPUVM faults to appear on dmesg and it is one of the
> causes that SDMA queues are not working.
>
> Signed-off-by: Xihan Zhang 
> Reviewed-by: Ben Goz 
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 7b1d510..596ee5c 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -883,6 +883,8 @@ static int create_queue_cpsch(struct device_queue_manager 
> *dqm, struct queue *q,
> return -ENOMEM;
> }
>
> +   init_sdma_vm(dqm, q, qpd);
> +
> retval = mqd->init_mqd(mqd, &q->mqd, &q->mqd_mem_obj,
> &q->gart_mqd_addr, &q->properties);
> if (retval != 0)
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdkfd: Don't report local memory size

On Tue, May 5, 2015 at 4:40 AM, Oded Gabbay  wrote:
> This patch sets the local memory size that is reported to userspace to 0.
> This is done to make sure that userspace won't try to allocate local memory
> for HSA.
>
> As long as amdkfd doesn't support allocating local memory for HSA,
> we need this patch.
>
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> index 661c660..e469c4b 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> @@ -728,9 +728,9 @@ static ssize_t node_show(struct kobject *kobj, struct 
> attribute *attr,
> sysfs_show_32bit_prop(buffer, "max_engine_clk_fcompute",
> dev->gpu->kfd2kgd->get_max_engine_clock_in_mhz(
> dev->gpu->kgd));
> +
> sysfs_show_64bit_prop(buffer, "local_mem_size",
> -   dev->gpu->kfd2kgd->get_vmem_size(
> -   dev->gpu->kgd));
> +   (unsigned long long int) 0);
>
> sysfs_show_32bit_prop(buffer, "fw_version",
> dev->gpu->kfd2kgd->get_fw_version(
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/amdkfd: make the sdma vm init to be asic specific

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c| 15 +--
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h|  3 +++
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c| 16 
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c |  8 
 4 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 69af73f..1eb1022 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -614,19 +614,6 @@ static void deallocate_sdma_queue(struct 
device_queue_manager *dqm,
set_bit(sdma_queue_id, (unsigned long *)&dqm->sdma_bitmap);
 }

-static void init_sdma_vm(struct device_queue_manager *dqm, struct queue *q,
-   struct qcm_process_device *qpd)
-{
-   uint32_t value = SDMA_ATC;
-
-   if (q->process->is_32bit_user_mode)
-   value |= SDMA_VA_PTR32 | get_sh_mem_bases_32(qpd_to_pdd(qpd));
-   else
-   value |= SDMA_VA_SHARED_BASE(get_sh_mem_bases_nybble_64(
-   qpd_to_pdd(qpd)));
-   q->properties.sdma_vm_addr = value;
-}
-
 static int create_sdma_queue_nocpsch(struct device_queue_manager *dqm,
struct queue *q,
struct qcm_process_device *qpd)
@@ -649,7 +636,7 @@ static int create_sdma_queue_nocpsch(struct 
device_queue_manager *dqm,
pr_debug(" sdma queue id: %d\n", q->properties.sdma_queue_id);
pr_debug(" sdma engine id: %d\n", q->properties.sdma_engine_id);

-   init_sdma_vm(dqm, q, qpd);
+   dqm->ops_asic_specific.init_sdma_vm(dqm, q, qpd);
retval = mqd->init_mqd(mqd, &q->mqd, &q->mqd_mem_obj,
&q->gart_mqd_addr, &q->properties);
if (retval != 0) {
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
index 650ae1c..57278e2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -130,6 +130,9 @@ struct device_queue_manager_asic_ops {
   enum cache_policy alternate_policy,
   void __user *alternate_aperture_base,
   uint64_t alternate_aperture_size);
+   void(*init_sdma_vm)(struct device_queue_manager *dqm,
+   struct queue *q,
+   struct qcm_process_device *qpd);
 };

 /**
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
index 292d13f..9ce8a20 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
@@ -33,12 +33,15 @@ static bool set_cache_memory_policy_cik(struct 
device_queue_manager *dqm,
 static int register_process_cik(struct device_queue_manager *dqm,
struct qcm_process_device *qpd);
 static int initialize_cpsch_cik(struct device_queue_manager *dqm);
+static void init_sdma_vm(struct device_queue_manager *dqm, struct queue *q,
+   struct qcm_process_device *qpd);

 void device_queue_manager_init_cik(struct device_queue_manager_asic_ops *ops)
 {
ops->set_cache_memory_policy = set_cache_memory_policy_cik;
ops->register_process = register_process_cik;
ops->initialize = initialize_cpsch_cik;
+   ops->init_sdma_vm = init_sdma_vm;
 }

 static uint32_t compute_sh_mem_bases_64bit(unsigned int top_address_nybble)
@@ -129,6 +132,19 @@ static int register_process_cik(struct 
device_queue_manager *dqm,
return 0;
 }

+static void init_sdma_vm(struct device_queue_manager *dqm, struct queue *q,
+   struct qcm_process_device *qpd)
+{
+   uint32_t value = SDMA_ATC;
+
+   if (q->process->is_32bit_user_mode)
+   value |= SDMA_VA_PTR32 | get_sh_mem_bases_32(qpd_to_pdd(qpd));
+   else
+   value |= SDMA_VA_SHARED_BASE(get_sh_mem_bases_nybble_64(
+   qpd_to_pdd(qpd)));
+   q->properties.sdma_vm_addr = value;
+}
+
 static int initialize_cpsch_cik(struct device_queue_manager *dqm)
 {
return init_pipelines(dqm, get_pipes_num(dqm), get_first_pipe(dqm));
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
index 8b00ccf..4c15212 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
@@ -32,6 +32,8 @@ static bool set_cache_m

[PATCH 1/2] drm/amdkfd: Use new struct for asic specific ops

This patch creates a new structure for asic specific operations, instead
of using the existing structure of operations.

This is done to make the code flow more logic, readable and maintainable.

The change is done only to the device queue manager module at this point.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  | 18 +++---
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c  |  2 +-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c   |  2 +-
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
index 488f51d..650ae1c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -120,6 +120,18 @@ struct device_queue_manager_ops {
   uint64_t alternate_aperture_size);
 };

+struct device_queue_manager_asic_ops {
+   int (*register_process)(struct device_queue_manager *dqm,
+   struct qcm_process_device *qpd);
+   int (*initialize)(struct device_queue_manager *dqm);
+   bool(*set_cache_memory_policy)(struct device_queue_manager *dqm,
+  struct qcm_process_device *qpd,
+  enum cache_policy default_policy,
+  enum cache_policy alternate_policy,
+  void __user *alternate_aperture_base,
+  uint64_t alternate_aperture_size);
+};
+
 /**
  * struct device_queue_manager
  *
@@ -134,7 +146,7 @@ struct device_queue_manager_ops {

 struct device_queue_manager {
struct device_queue_manager_ops ops;
-   struct device_queue_manager_ops ops_asic_specific;
+   struct device_queue_manager_asic_ops ops_asic_specific;

struct mqd_manager  *mqds[KFD_MQD_TYPE_MAX];
struct packet_manager   packets;
@@ -157,8 +169,8 @@ struct device_queue_manager {
boolactive_runlist;
 };

-void device_queue_manager_init_cik(struct device_queue_manager_ops *ops);
-void device_queue_manager_init_vi(struct device_queue_manager_ops *ops);
+void device_queue_manager_init_cik(struct device_queue_manager_asic_ops *ops);
+void device_queue_manager_init_vi(struct device_queue_manager_asic_ops *ops);
 void program_sh_mem_settings(struct device_queue_manager *dqm,
struct qcm_process_device *qpd);
 int init_pipelines(struct device_queue_manager *dqm,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
index 5469efe..292d13f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
@@ -34,7 +34,7 @@ static int register_process_cik(struct device_queue_manager 
*dqm,
struct qcm_process_device *qpd);
 static int initialize_cpsch_cik(struct device_queue_manager *dqm);

-void device_queue_manager_init_cik(struct device_queue_manager_ops *ops)
+void device_queue_manager_init_cik(struct device_queue_manager_asic_ops *ops)
 {
ops->set_cache_memory_policy = set_cache_memory_policy_cik;
ops->register_process = register_process_cik;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
index 20553dc..8b00ccf 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
@@ -33,7 +33,7 @@ static int register_process_vi(struct device_queue_manager 
*dqm,
struct qcm_process_device *qpd);
 static int initialize_cpsch_vi(struct device_queue_manager *dqm);

-void device_queue_manager_init_vi(struct device_queue_manager_ops *ops)
+void device_queue_manager_init_vi(struct device_queue_manager_asic_ops *ops)
 {
pr_warn("amdkfd: VI DQM is not currently supported\n");

-- 
1.9.1

[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers

2015-05-05 Thread Peter Hurley

On 05/05/2015 11:42 AM, Daniel Vetter wrote:
> On Tue, May 05, 2015 at 10:36:24AM -0400, Peter Hurley wrote:
>> On 05/04/2015 12:52 AM, Mario Kleiner wrote:
>>> On 04/16/2015 03:03 PM, Daniel Vetter wrote:
 On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wrote:
> On 04/15/2015 01:31 PM, Daniel Vetter wrote:
>> On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
>>> Hi Daniel,
>>>
>>> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
 This was a bit too much cargo-culted, so lets make it solid:
 - vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile variable, so no need to audit all the
read-side access specifically.

 - The barriers for the vblank counter seqlock weren't complete: The
read-side was missing the first barrier between the counter read and
the timestamp read, it only had a barrier between the ts and the
counter read. We need both.

 - Barriers weren't properly documented. Since barriers only work if
you have them on boths sides of the transaction it's prudent to
reference where the other side is. To avoid duplicating the
write-side comment 3 times extract a little store_vblank() helper.
In that helper also assert that we do indeed hold
dev->vblank_time_lock, since in some cases the lock is acquired a
few functions up in the callchain.

 Spotted while reviewing a patch from Chris Wilson to add a fastpath to
 the vblank_wait ioctl.

 Cc: Chris Wilson 
 Cc: Mario Kleiner 
 Cc: Ville SyrjÃ¤lÃ¤ 
 Cc: Michel DÃ¤nzer 
 Signed-off-by: Daniel Vetter 
 ---
   drivers/gpu/drm/drm_irq.c | 92 
 ---
   include/drm/drmP.h|  8 +++--
   2 files changed, 54 insertions(+), 46 deletions(-)

 diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
 index c8a34476570a..23bfbc61a494 100644
 --- a/drivers/gpu/drm/drm_irq.c
 +++ b/drivers/gpu/drm/drm_irq.c
 @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, 
 drm_vblank_offdelay, int, 0600);
   module_param_named(timestamp_precision_usec, 
 drm_timestamp_precision, int, 0600);
   module_param_named(timestamp_monotonic, drm_timestamp_monotonic, 
 int, 0600);

 +static void store_vblank(struct drm_device *dev, int crtc,
 + unsigned vblank_count_inc,
 + struct timeval *t_vblank)
 +{
 +struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
 +u32 tslot;
 +
 +assert_spin_locked(&dev->vblank_time_lock);
 +
 +if (t_vblank) {
 +tslot = vblank->count + vblank_count_inc;
 +vblanktimestamp(dev, crtc, tslot) = *t_vblank;
 +}
 +
 +/*
 + * vblank timestamp updates are protected on the write side with
 + * vblank_time_lock, but on the read side done locklessly using a
 + * sequence-lock on the vblank counter. Ensure correct ordering 
 using
 + * memory barrriers. We need the barrier both before and also 
 after the
 + * counter update to synchronize with the next timestamp write.
 + * The read-side barriers for this are in 
 drm_vblank_count_and_time.
 + */
 +smp_wmb();
 +vblank->count += vblank_count_inc;
 +smp_wmb();
>>>
>>> The comment and the code are each self-contradictory.
>>>
>>> If vblank->count writes are always protected by vblank_time_lock 
>>> (something I
>>> did not verify but that the comment above asserts), then the trailing 
>>> write
>>> barrier is not required (and the assertion that it is in the comment is 
>>> incorrect).
>>>
>>> A spin unlock operation is always a write barrier.
>>
>> Hm yeah. Otoh to me that's bordering on "code too clever for my own 
>> good".
>> That the spinlock is held I can assure. That no one goes around and does
>> multiple vblank updates (because somehow that code raced with the hw
>> itself) I can't easily assure with a simple assert or something similar.
>> It's not the case right now, but that can changes.
>
> The algorithm would be broken if multiple updates for the same vblank
> count were allowed; that's why it checks to see if the vblank count has
> not advanced before storing a new timestamp.
>
> Otherwise, the read side would not be able

[PATCH 1/8] gpiolib: Add support for removing registered consumer lookup table

2015-05-05 Thread Lee Jones

This is not how we submit subsequent patch-sets.

Please submit them as a whole, seperately from the first submission
and with versioning information i.e. [PATCH v2 X/Y] Stuff ...

> In case we unload and load a driver module again that is registering a
> lookup table, without this it will result in multiple entries. Provide
> an option to remove the lookup table on driver unload
> 
> v2: Ccing maintainers
> v3: Correct the subject line (Lee jones)

Change logs should go underneth the '---' and above the diffstat found
below.

> Cc: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Reviewed-by: Alexandre Courbot 
> Signed-off-by: Shobhit Kumar 
> ---
>  drivers/gpio/gpiolib.c   | 13 +
>  include/linux/gpio/machine.h |  1 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 59eaa23..2420af9 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1658,6 +1658,19 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table 
> *table)
>   mutex_unlock(&gpio_lookup_lock);
>  }
>  
> +/**
> + * gpiod_remove_lookup_table() - unregister GPIO device consumers
> + * @table: table of consumers to unregister
> + */
> +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
> +{
> + mutex_lock(&gpio_lookup_lock);
> +
> + list_del(&table->list);
> +
> + mutex_unlock(&gpio_lookup_lock);
> +}
> +
>  static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
> unsigned int idx,
> enum gpio_lookup_flags *flags)
> diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
> index e270614..c0d712d 100644
> --- a/include/linux/gpio/machine.h
> +++ b/include/linux/gpio/machine.h
> @@ -57,5 +57,6 @@ struct gpiod_lookup_table {
>  }
>  
>  void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
> +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
>  
>  #endif /* __LINUX_GPIO_MACHINE_H */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 5/8] drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM

2015-05-05 Thread Lee Jones

On Tue, 05 May 2015, Shobhit Kumar wrote:

> On 04/29/2015 07:54 PM, Lee Jones wrote:
> > On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> > 
> >> On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
> >> entry for the same to be used by the consumer (Intel GFX)
> >>
> >> v2: Remove the lookup table on driver unload (Thierry)
> >>
> >> CC: Samuel Ortiz 
> >> Cc: Linus Walleij 
> >> Cc: Alexandre Courbot 
> >> Cc: Thierry Reding 
> >> Signed-off-by: Shobhit Kumar 
> >> ---
> >>  drivers/mfd/intel_soc_pmic_core.c | 12 
> >>  1 file changed, 12 insertions(+)
> > 
> > How do you expect this set to be managed?
> 
> There are some dependencies on the look up table remove functionality in
> earlier patches, so I think 3/8 can go in only after 1/8. Similarly 5/8
> can go only after 2/8. Rest all can be independent.   

Taking patches 'in order' is tough to coordinate and takes a very long
time.  The best thing to do is have all of the patches taken in via a
single tree at the same time.

> > Acked-by: Lee Jones 
> > 
> >> diff --git a/drivers/mfd/intel_soc_pmic_core.c 
> >> b/drivers/mfd/intel_soc_pmic_core.c
> >> index f3d918e..a00ddd9 100644
> >> --- a/drivers/mfd/intel_soc_pmic_core.c
> >> +++ b/drivers/mfd/intel_soc_pmic_core.c
> >> @@ -25,6 +25,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include "intel_soc_pmic_core.h"
> >>  
> >>  /* Lookup table for the Panel Enable/Disable line as GPIO signals */
> >> @@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
> >>},
> >>  };
> >>  
> >> +/* PWM consumed by the Intel GFX */
> >> +static struct pwm_lookup crc_pwm_lookup[] = {
> >> +  PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0, 
> >> PWM_POLARITY_NORMAL),
> >> +};
> >> +
> >>  static int intel_soc_pmic_find_gpio_irq(struct device *dev)
> >>  {
> >>struct gpio_desc *desc;
> >> @@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client 
> >> *i2c,
> >>/* Add lookup table binding for Panel Control to the GPIO Chip */
> >>gpiod_add_lookup_table(&panel_gpio_table);
> >>  
> >> +  /* Add lookup table for crc-pwm */
> >> +  pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> >> +
> >>ret = mfd_add_devices(dev, -1, config->cell_dev,
> >>  config->n_cell_devs, NULL, 0,
> >>  regmap_irq_get_domain(pmic->irq_chip_data));
> >> @@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client 
> >> *i2c)
> >>/* Remove lookup table for Panel Control from the GPIO Chip */
> >>gpiod_remove_lookup_table(&panel_gpio_table);
> >>  
> >> +  /* remove crc-pwm lookup table */
> >> +  pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> >> +
> >>mfd_remove_devices(&i2c->dev);
> >>  
> >>return 0;
> > 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH] drm/amdkfd: Initialize sdma vm when creating sdma queue

From: Xihan Zhang 

This patch fixes a bug where sdma vm wasn't initialized when
an sdma queue was created in HWS mode.

This caused GPUVM faults to appear on dmesg and it is one of the
causes that SDMA queues are not working.

Signed-off-by: Xihan Zhang 
Reviewed-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 7b1d510..596ee5c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -883,6 +883,8 @@ static int create_queue_cpsch(struct device_queue_manager 
*dqm, struct queue *q,
return -ENOMEM;
}

+   init_sdma_vm(dqm, q, qpd);
+
retval = mqd->init_mqd(mqd, &q->mqd, &q->mqd_mem_obj,
&q->gart_mqd_addr, &q->properties);
if (retval != 0)
-- 
1.9.1

[PATCH] drm/amdkfd: Don't report local memory size

This patch sets the local memory size that is reported to userspace to 0.
This is done to make sure that userspace won't try to allocate local memory
for HSA.

As long as amdkfd doesn't support allocating local memory for HSA,
we need this patch.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 661c660..e469c4b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -728,9 +728,9 @@ static ssize_t node_show(struct kobject *kobj, struct 
attribute *attr,
sysfs_show_32bit_prop(buffer, "max_engine_clk_fcompute",
dev->gpu->kfd2kgd->get_max_engine_clock_in_mhz(
dev->gpu->kgd));
+
sysfs_show_64bit_prop(buffer, "local_mem_size",
-   dev->gpu->kfd2kgd->get_vmem_size(
-   dev->gpu->kgd));
+   (unsigned long long int) 0);

sysfs_show_32bit_prop(buffer, "fw_version",
dev->gpu->kfd2kgd->get_fw_version(
-- 
1.9.1

[PATCH] drm/amdkfd: allow unregister process with queues

Sometimes we might unregister process that have queues, because we couldn't
preempt the queues. Until now we blocked it with BUG_ON but instead just
print it as debug.

Reviewed-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 69af73f..7b1d510 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -430,9 +430,10 @@ static int unregister_process_nocpsch(struct 
device_queue_manager *dqm,

BUG_ON(!dqm || !qpd);

-   BUG_ON(!list_empty(&qpd->queues_list));
+   pr_debug("In func %s\n", __func__);

-   pr_debug("kfd: In func %s\n", __func__);
+   pr_debug("qpd->queues_list is %s\n",
+   list_empty(&qpd->queues_list) ? "empty" : "not empty");

retval = 0;
mutex_lock(&dqm->lock);
-- 
1.9.1

[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers

2015-05-05 Thread Peter Hurley

On 05/04/2015 12:52 AM, Mario Kleiner wrote:
> On 04/16/2015 03:03 PM, Daniel Vetter wrote:
>> On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wrote:
>>> On 04/15/2015 01:31 PM, Daniel Vetter wrote:
 On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
> Hi Daniel,
>
> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
>> This was a bit too much cargo-culted, so lets make it solid:
>> - vblank->count doesn't need to be an atomic, writes are always done
>>under the protection of dev->vblank_time_lock. Switch to an unsigned
>>long instead and update comments. Note that atomic_read is just a
>>normal read of a volatile variable, so no need to audit all the
>>read-side access specifically.
>>
>> - The barriers for the vblank counter seqlock weren't complete: The
>>read-side was missing the first barrier between the counter read and
>>the timestamp read, it only had a barrier between the ts and the
>>counter read. We need both.
>>
>> - Barriers weren't properly documented. Since barriers only work if
>>you have them on boths sides of the transaction it's prudent to
>>reference where the other side is. To avoid duplicating the
>>write-side comment 3 times extract a little store_vblank() helper.
>>In that helper also assert that we do indeed hold
>>dev->vblank_time_lock, since in some cases the lock is acquired a
>>few functions up in the callchain.
>>
>> Spotted while reviewing a patch from Chris Wilson to add a fastpath to
>> the vblank_wait ioctl.
>>
>> Cc: Chris Wilson 
>> Cc: Mario Kleiner 
>> Cc: Ville SyrjÃ¤lÃ¤ 
>> Cc: Michel DÃ¤nzer 
>> Signed-off-by: Daniel Vetter 
>> ---
>>   drivers/gpu/drm/drm_irq.c | 92 
>> ---
>>   include/drm/drmP.h|  8 +++--
>>   2 files changed, 54 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index c8a34476570a..23bfbc61a494 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, 
>> drm_vblank_offdelay, int, 0600);
>>   module_param_named(timestamp_precision_usec, drm_timestamp_precision, 
>> int, 0600);
>>   module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 
>> 0600);
>>
>> +static void store_vblank(struct drm_device *dev, int crtc,
>> + unsigned vblank_count_inc,
>> + struct timeval *t_vblank)
>> +{
>> +struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
>> +u32 tslot;
>> +
>> +assert_spin_locked(&dev->vblank_time_lock);
>> +
>> +if (t_vblank) {
>> +tslot = vblank->count + vblank_count_inc;
>> +vblanktimestamp(dev, crtc, tslot) = *t_vblank;
>> +}
>> +
>> +/*
>> + * vblank timestamp updates are protected on the write side with
>> + * vblank_time_lock, but on the read side done locklessly using a
>> + * sequence-lock on the vblank counter. Ensure correct ordering 
>> using
>> + * memory barrriers. We need the barrier both before and also after 
>> the
>> + * counter update to synchronize with the next timestamp write.
>> + * The read-side barriers for this are in drm_vblank_count_and_time.
>> + */
>> +smp_wmb();
>> +vblank->count += vblank_count_inc;
>> +smp_wmb();
>
> The comment and the code are each self-contradictory.
>
> If vblank->count writes are always protected by vblank_time_lock 
> (something I
> did not verify but that the comment above asserts), then the trailing 
> write
> barrier is not required (and the assertion that it is in the comment is 
> incorrect).
>
> A spin unlock operation is always a write barrier.

 Hm yeah. Otoh to me that's bordering on "code too clever for my own good".
 That the spinlock is held I can assure. That no one goes around and does
 multiple vblank updates (because somehow that code raced with the hw
 itself) I can't easily assure with a simple assert or something similar.
 It's not the case right now, but that can changes.
>>>
>>> The algorithm would be broken if multiple updates for the same vblank
>>> count were allowed; that's why it checks to see if the vblank count has
>>> not advanced before storing a new timestamp.
>>>
>>> Otherwise, the read side would not be able to determine that the
>>> timestamp is valid by double-checking that the vblank count has not
>>> changed.
>>>
>>> And besides, even if the code looped without dropping the spinlock,
>>> the correct write order would still be observed because it would still
>>> be executing on the same cpu.
>>>
>>> My objection to the write memory

[PATCH] drm/radeon: fix userptr lockup

2015-05-05 Thread Christian König

From: Christian KÃ¶nig 

We shouldn't try to reserve and wait for a BO that isn't bound. Otherwise
we can run into a deadlock if we have a fault during binding the BO.

Signed-off-by: Christian KÃ¶nig 
---
 drivers/gpu/drm/radeon/radeon_mn.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
b/drivers/gpu/drm/radeon/radeon_mn.c
index 535bf40..eef006c 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -142,6 +142,9 @@ static void radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,

list_for_each_entry(bo, &node->bos, mn_list) {

+   if (!bo->tbo.ttm || bo->tbo.ttm->state != tt_bound)
+   continue;
+
r = radeon_bo_reserve(bo, true);
if (r) {
DRM_ERROR("(%ld) failed to reserve user bo\n", 
r);
-- 
1.9.1

[PATCH] drm/radeon: fix userptr lockup

On Tue, May 5, 2015 at 3:52 AM, Christian KÃ¶nig  
wrote:
> From: Christian KÃ¶nig 
>
> We shouldn't try to reserve and wait for a BO that isn't bound. Otherwise
> we can run into a deadlock if we have a fault during binding the BO.
>
> Signed-off-by: Christian KÃ¶nig 

Applied to my -fixes tree.

Thanks,

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_mn.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
> b/drivers/gpu/drm/radeon/radeon_mn.c
> index 535bf40..eef006c 100644
> --- a/drivers/gpu/drm/radeon/radeon_mn.c
> +++ b/drivers/gpu/drm/radeon/radeon_mn.c
> @@ -142,6 +142,9 @@ static void radeon_mn_invalidate_range_start(struct 
> mmu_notifier *mn,
>
> list_for_each_entry(bo, &node->bos, mn_list) {
>
> +   if (!bo->tbo.ttm || bo->tbo.ttm->state != tt_bound)
> +   continue;
> +
> r = radeon_bo_reserve(bo, true);
> if (r) {
> DRM_ERROR("(%ld) failed to reserve user 
> bo\n", r);
> --
> 1.9.1
>

[PATCH] drm/radeon: fix userptr BO unpin bug v2

On Tue, May 5, 2015 at 3:24 AM, Christian KÃ¶nig  
wrote:
> From: "monk.liu" 
>
> Fixing a memory leak with userptrs.
>
> v2: clean up the loop, use an iterator instead
>
> Signed-off-by: monk.liu 
> Signed-off-by: Christian KÃ¶nig 
> CC: stable at vger.kernel.org

Applied to my -fixes tree.

Alex


> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b292aca..921dd0f 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -591,7 +591,7 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt 
> *ttm)
>  {
> struct radeon_device *rdev = radeon_get_rdev(ttm->bdev);
> struct radeon_ttm_tt *gtt = (void *)ttm;
> -   struct scatterlist *sg;
> +   struct sg_page_iter sg_iter;
> int i;
>
> int write = !(gtt->userflags & RADEON_GEM_USERPTR_READONLY);
> @@ -605,9 +605,8 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt 
> *ttm)
> /* free the sg table and pages again */
> dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
>
> -   for_each_sg(ttm->sg->sgl, sg, ttm->sg->nents, i) {
> -   struct page *page = sg_page(sg);
> -
> +   for_each_sg_page(ttm->sg->sgl, &sg_iter, ttm->sg->nents, 0) {
> +   struct page *page = sg_page_iter_page(&sg_iter);
> if (!(gtt->userflags & RADEON_GEM_USERPTR_READONLY))
> set_page_dirty(page);
>
> --
> 1.9.1
>

[PATCH] drm/msm: fix unbalanced DRM framebuffer init/destroy

2015-05-05 Thread Stephane Viau

When msm_framebuffer_init() fails before calling drm_framebuffer_init(),
drm_framebuffer_cleanup() [called in msm_framebuffer_destroy()]
is still being called even though drm_framebuffer_init() was not
called for that buffer. Thus a NULL pointer derefencing:

[  247.529691] Unable to handle kernel NULL pointer dereference at virtual 
address 027c
...
[  247.563996] PC is at __mutex_lock_slowpath+0x94/0x3a8
...
[  247.823025] [] (__mutex_lock_slowpath) from [] 
(mutex_lock+0x20/0x3c)
[  247.831186] [] (mutex_lock) from [] 
(drm_framebuffer_cleanup+0x18/0x38)
[  247.839520] [] (drm_framebuffer_cleanup) from [] 
(msm_framebuffer_destroy+0x48/0x100)
[  247.849066] [] (msm_framebuffer_destroy) from [] 
(msm_framebuffer_init+0x1e8/0x228)
[  247.858439] [] (msm_framebuffer_init) from [] 
(msm_framebuffer_create+0x70/0x134)
[  247.867642] [] (msm_framebuffer_create) from [] 
(internal_framebuffer_create+0x67c/0x7b4)
[  247.877537] [] (internal_framebuffer_create) from [] 
(drm_mode_addfb2+0x20/0x98)
[  247.886650] [] (drm_mode_addfb2) from [] 
(drm_ioctl+0x240/0x420)
[  247.894378] [] (drm_ioctl) from [] 
(do_vfs_ioctl+0x4e4/0x5a4)
...

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/msm_fb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 6b573e6..c0f09d3 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -239,8 +239,7 @@ struct drm_framebuffer *msm_framebuffer_init(struct 
drm_device *dev,
return fb;

 fail:
-   if (fb)
-   msm_framebuffer_destroy(fb);
+   kfree(msm_fb);

return ERR_PTR(ret);
 }
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH 3/3] drm: simplify master cleanup

On Mon, May 04, 2015 at 03:47:13PM +0100, Chris Wilson wrote:
> On Mon, May 04, 2015 at 04:05:14PM +0200, David Herrmann wrote:
> > In drm_master_destroy() we _free_ the master object. There is no reason to
> > hold any locks while dropping its static members, nor do we have to reset
> > it to 0.
> > 
> > Furthermore, kfree() already does NULL checks, so call it directly on
> > master->unique and drop the redundant reset-code.
> > 
> > Signed-off-by: David Herrmann 
> Reviewed-by: Chris Wilson 

Both kernel and igt patches applied, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

i915 dma_map_sg return value

2015-05-05 Thread Volker Vogelhuber

The documentation of the DMA-API writes the following about
dma_map_sg:

"The implementation is free to merge several consecutive sglist entries
into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
consecutive sglist entries can be merged into one provided the first one
ends and the second one starts on a page boundary - in fact this is a huge
advantage for cards which either cannot do scatter-gather or have very
limited number of scatter-gather entries) and returns the actual number
of sg entries it mapped them to."

I wonder why the return value of dma_map_sg is not returned in any way
from i915_gem_map_dma_buf. It only uses the return value for error
checking.
Can one be sure that in case of the i915 the nents value of the scatter
gather table is always equal to the value returned by dma_map_sg?
I'm asking because I want to use the sg table returned by
i915_gem_map_dma_buf in my own kernel module and iterate over it
using for_each_sg. And the example in the documentation of the DMA-API
uses the return value of dma_map_sg when calling for_each_sg and not
nents and it explicitly mentions:

"Then you should loop count times (note: this can be less than nents times)"

Regards,
 Volker

[patch] drm/i915: checking IS_ERR() instead of NULL

On Thu, Apr 30, 2015 at 05:47:13PM +0300, Dan Carpenter wrote:
> On Thu, Apr 30, 2015 at 03:43:02PM +0100, Chris Wilson wrote:
> > On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote:
> > > We switched from calling i915_gem_alloc_context_obj() to calling
> > > i915_gem_alloc_object() so the error handling needs to be updated to
> > > check for NULL instead of IS_ERR().
> > 
> > I had a patch to change i915_gem_alloc_object() to report the correct
> > error rather than NULL - which can come in surprisingly handy at
> > times...
> 
> That also works, of course.  Send it.  :)

Doesn't seem to have shown up yet, I applied your patch meanwhile.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC] How implement Secure Data Path ?

2015-05-05 Thread Christoph Hellwig

On Tue, May 05, 2015 at 05:39:57PM +0200, Benjamin Gaignard wrote:
> Since few months I'm looking for Linaro to how do Secure Data Path (SPD).
> I have tried and implemented multiple thinks but I always facing architecture
> issues so I would like to get your help to solve the problem.
> 
> First what is Secure Data Path ? SDP is a set of hardware features to garanty
> that some memories regions could only be read and/or write by specific 
> hardware
> IPs. You can imagine it as a kind of memory firewall which grant/revoke
> accesses to memory per devices. Firewall configuration must be done in a 
> trusted
> environment: for ARM architecture we plan to use OP-TEE + a trusted
> application to do that.
> 
> One typical use case for SDP in a video playback which involve those elements:
> decrypt -> video decoder -> transform -> display

Sounds like a good enough reason not to implement it ever.

[PATCH v2] drm: fix a memleak on mutex failure path

On Tue, Apr 28, 2015 at 10:25:46AM +0300, Jani Nikula wrote:
> On Mon, 27 Apr 2015, green at linuxhacker.ru wrote:
> > From: Oleg Drokin 
> >
> > Need to free just allocated ctx allocation if we cannot
> > get our config mutex.
> >
> > This one has been flagged by kbuild bot all the way back in August,
> > but somehow nobody picked it up:
> > https://lists.01.org/pipermail/kbuild/2014-August/001691.html
> >
> > In addition there is another failure path that leaks the same
> > ctx reference that is fixed.
> >
> > Found with smatch.
> >
> > Signed-off-by: Oleg Drokin 
> > CC: Daniel Vetter 
> 
> Reviewed-by: Jani Nikula 

Applied to topic/drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/radeon: fix userptr BO unpin bug v2

2015-05-05 Thread Christian König

From: "monk.liu" 

Fixing a memory leak with userptrs.

v2: clean up the loop, use an iterator instead

Signed-off-by: monk.liu 
Signed-off-by: Christian KÃ¶nig 
CC: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b292aca..921dd0f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -591,7 +591,7 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
 {
struct radeon_device *rdev = radeon_get_rdev(ttm->bdev);
struct radeon_ttm_tt *gtt = (void *)ttm;
-   struct scatterlist *sg;
+   struct sg_page_iter sg_iter;
int i;

int write = !(gtt->userflags & RADEON_GEM_USERPTR_READONLY);
@@ -605,9 +605,8 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
/* free the sg table and pages again */
dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);

-   for_each_sg(ttm->sg->sgl, sg, ttm->sg->nents, i) {
-   struct page *page = sg_page(sg);
-
+   for_each_sg_page(ttm->sg->sgl, &sg_iter, ttm->sg->nents, 0) {
+   struct page *page = sg_page_iter_page(&sg_iter);
if (!(gtt->userflags & RADEON_GEM_USERPTR_READONLY))
set_page_dirty(page);

-- 
1.9.1

[Intel-gfx] [PATCH 3/5] drm: Possible lock priority escalation.

On Tue, May 05, 2015 at 06:45:30AM +, Antoine, Peter wrote:
> On Mon, 2015-05-04 at 15:56 +0200, Daniel Vetter wrote:
> > On Mon, Apr 27, 2015 at 07:52:46PM +0300, Ville SyrjÃ¤lÃ¤ wrote:
> > > On Thu, Apr 23, 2015 at 03:07:56PM +0100, Peter Antoine wrote:
> > > > If an application that has a driver lock created, wants the lock the
> > > > kernel context, it is not allowed to. If the call to drm_lock has a
> > > > context of 0, it is rejected. If you set the context to _DRM_LOCK_CONT
> > > > then call drm lock, it will pass the context == DRM_KERNEL_CONTEXT 
> > > > checks.
> > > > But as the DRM_LOCK_CONT bits are not part of the context id this allows
> > > > operations on the DRM_KERNEL_CONTEXT.
> > > > 
> > > > Issue: VIZ-5485
> > > > Signed-off-by: Peter Antoine 
> > 
> > If you're touching code with drm_legacy_ prefix of in such a file you've
> > ended up in the horrible corners of the dri1 dungeons and should head back
> > out pronto ;-)
> > 
> > If we can actually run into this code on production i915 then we need to
> > improve the locks at the door of these dungeons for kms drivers, not try
> > to fix up the mess behind them. That's just plain impossible.
> > 
> > If you want to make really sure we get this right some simple drm igt
> > tests to make sure these codepaths are really dead for kms driver might be
> > good. But otherwise we really can only annotate this as wontfix in
> > code security issue scanners.
> > -Daniel
> > 
> There is a test that covers this fix. This is a simple three line fix
> that stops a userspace driver locking the kernel context. Yes they are
> other problems with this code, but why are they stopping this patch that
> does a simple fix from going in?
> 
> I'll happily drop this patch if it causes more problems that it fixes.

Because we don't want to fix the legacy context crap but instead outright
disable it for everyone (well except nouveau) running in kms code. drm
legacy code really is broken by design, there's no way to fix it.

And worst case we'll end up breaking some old machines in some and then
have to deal with the regression. Which means I won't apply these patches
if we can somehow just disable all that code for i915.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock

On Tue, May 05, 2015 at 06:37:51AM +, Antoine, Peter wrote:
> On Mon, 2015-05-04 at 15:52 +0200, Daniel Vetter wrote:
> > On Tue, Apr 28, 2015 at 10:52:32AM +0100, chris at chris-wilson.co.uk wrote:
> > > On Tue, Apr 28, 2015 at 10:21:49AM +0100, Dave Gordon wrote:
> > > > On 24/04/15 06:52, Antoine, Peter wrote:
> > > > > I picked up this work due to the following Jira ticket created by the
> > > > > security team (on Android) and was asked to give it a second look and
> > > > > found a few more issues with the hw lock code.
> > > > > 
> > > > > https://jira01.devtools.intel.com/browse/GMINL-5388
> > > > > I/O control on /dev/dri/card0 crashes the kernel (0x4008642b)
> > > > > 
> > > > > It also stops Linux as it kills the driver, I guess it might be 
> > > > > possible
> > > > > to reload the gfx driver. On a unpatched system the test that is
> > > > > included in the issue or the igt test that has been posted for the 
> > > > > issue
> > > > > will show the problem.
> > > > > 
> > > > > I ran the test on an unpatched system here and the gui stopped and the
> > > > > keyboard stopped responding, so I rebooted. With the patched system I
> > > > > did not need to reboot.
> > > > > 
> > > > > Should I change the SIGTERM to SIGSEGV, not quite the same thing but
> > > > > tooling is better at handling a segfault than a SIGTERM and the
> > > > > application that calls this IOCTL is using an uninitialised hw lock so
> > > > > it is kind of the same as differencing an uninitialised pointer (kind
> > > > > of). Or, I could just remove it, but the bug has been in the code for 
> > > > > at
> > > > > least two years (and known about), and I would guess that any code 
> > > > > that
> > > > > is calling this is fuzzing the IOCTLs (as this is how the security 
> > > > > team
> > > > > found it) and we should reward them with a application exit.
> > > > > 
> > > > > Peter. 
> > > > 
> > > > SIGSEGV would be a better choice.
> > > > 
> > > > SIGTERM is normally sent by a user -- it's the default signal sent by
> > > > kill(1). It's also commonly used to tell a long-running daemon process
> > > > to tidy up and exit cleanly.
> > > > 
> > > > SIGSEGV commonly means "you accessed something that doesn't exist/isn't
> > > > mapped/you don't have permissions for". There are specific subcases that
> > > > can be indicated via the siginfo data; this is from the sigaction(1)
> > > > manpage:
> > > > 
> > > > The following values can be placed in si_code for a SIGSEGV signal:
> > > > 
> > > > SEGV_MAPERRaddress not mapped to object
> > > > 
> > > > SEGV_ACCERRinvalid permissions for mapped object
> > > > 
> > > > SIGBUS would also be a possibility but that's generally taken to mean
> > > > that an access got all the way to some physical bus and then faulted,
> > > > whereas SIGSEGV suggests the access was rejected during the
> > > > virtual-to-physical mapping process.
> > > 
> > > None of the above. Just return -EINVAL, -EPERM, -EACCESS as appropriate.
> > 
> > Seconded, we really don't want to be in the business of fixing up the drm
> > design mistakes of the past 15 years. As long as we can fully lock out
> > this particular dragon when running i915 we're imo good enough. The dri1
> > design of a kernel shim driver cooperating with the ums driver for hw
> > ownership is fundamentally unfixable.
> > 
> > Also we can't change any of it for drivers actually using it since it'll
> > break them, which is a big no-go.
> > -Daniel
> 
> I will remove it. But, If you are using this code path the driver/kernel
> will have crashed. It covers a NULL pointer deference, so we are not
> changing the API that anyone is actually using.

With ums/dri1 userspace can crash the kernel. That's pretty much by
design, and it's pretty much unfixable. Trying to fix up the obvious ones
like here is just cargo-culting. The only real option is to make
absolutely sure we can't ever reach these codepaths at all from kms
drivers like i915. Which tends to be a lot more work for auditing, but
will be much more useful.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions optional.

2015-05-05 Thread Dave Airlie

>
> Iirc it was in the ddx, and it was actually using the mmap code. Leftovers
> from ums, but unfortunately X crashes if we take them away. If I recall
> correctly nouveau was in staging still, but per Linus staging or not
> doesn't matter when distros are shipping with the code already. I did dig
> out the details way back out of curiosity, but lost them since then again.
> -Daniel

There were two different nouveau problems

a) old libdrm used contexts, it called drmCreateContext and drmDestroyContext
from what I could see.

b) old DDX used DRI1 functions, DRIOpenDRMMaster in the X server
when it wanted to use open, that function added maps with locks
and mapped them.

I get the impression this is case (b).

Dave.

No HDMI Audio with Radeon HD7750 on Acube Sam460ex AMCC powerpc 460ex board

2015-05-05 Thread Julian Margetson

:0x7750).
>> [2.585379] [drm] register mmio base: 0xe9000
>> [2.590143] [drm] register mmio size: 262144
>> [2.925520] ATOM BIOS: C44501
>> [2.928803] radeon 0001:81:00.0: VRAM: 1024M 0x -
>> 0x3FFF (1024M used)
>> [2.937725] radeon 0001:81:00.0: GTT: 1024M 0x4000 -
>> 0x7FFF
>> [2.945401] [drm] Detected VRAM RAM=1024M, BAR=256M
>> [2.950294] [drm] RAM width 128bits DDR
>> [2.954331] [TTM] Zone  kernel: Available graphics memory: 379212 kiB
>> [2.960822] [TTM] Zone highmem: Available graphics memory: 1034572 kiB
>> [2.967373] [TTM] Initializing pool allocator
>> [2.971766] [TTM] Initializing DMA pool allocator
>> [2.976604] [drm] radeon: 1024M of VRAM memory ready
>> [2.981610] [drm] radeon: 1024M of GTT memory ready.
>> [2.986651] [drm] Loading verde Microcode
>> [2.990757] radeon 0001:81:00.0: Direct firmware load for
>> radeon/verde_pfp.bin failed with error -2
>> [2.08] radeon 0001:81:00.0: Direct firmware load for
>> radeon/verde_me.bin failed with error -2
>> [3.008995] radeon 0001:81:00.0: Direct firmware load for
>> radeon/verde_ce.bin failed with error -2
>> [3.018041] radeon 0001:81:00.0: Direct firmware load for
>> radeon/verde_rlc.bin failed with error -2
>> [3.027184] radeon 0001:81:00.0: Direct firmware load for
>> radeon/verde_mc.bin failed with error -2
>> [3.036203] [drm] radeon/VERDE_mc2.bin: 31500 bytes
>> [3.041171] radeon 0001:81:00.0: Direct firmware load for
>> radeon/verde_smc.bin failed with error -2
>> [3.050278] [drm] Internal thermal controller with fan control
>> [3.056448] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0
>> [3.110566] [drm] radeon: dpm initialized
>> [3.114788] [drm] GART: num cpu pages 262144, num gpu pages 262144
>> [3.126445] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0
>> [3.171357] [drm] PCIE GART of 1024M enabled (table at
>> 0x00277000).
>> [3.178681] radeon 0001:81:00.0: WB enabled
>> [3.182925] radeon 0001:81:00.0: fence driver on ring 0 use gpu addr
>> 0x4c00 and cpu addr 0xffc01c00
>> [3.193045] radeon 0001:81:00.0: fence driver on ring 1 use gpu addr
>> 0x4c04 and cpu addr 0xffc01c04
>> [3.203167] radeon 0001:81:00.0: fence driver on ring 2 use gpu addr
>> 0x4c08 and cpu addr 0xffc01c08
>> [3.213287] radeon 0001:81:00.0: fence driver on ring 3 use gpu addr
>> 0x4c0c and cpu addr 0xffc01c0c
>> [3.223409] radeon 0001:81:00.0: fence driver on ring 4 use gpu addr
>> 0x4c10 and cpu addr 0xffc01c10
>> [3.255059] radeon 0001:81:00.0: fence driver on ring 5 use gpu addr
>> 0x00075a18 and cpu addr 0xf90b5a18
>> [3.265199] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [3.271837] [drm] Driver supports precise vblank timestamp query.
>> [3.277957] radeon 0001:81:00.0: radeon: MSI limited to 32-bit
>> [3.283833] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
>> [3.289927] [drm] radeon: irq initialized.
>> [4.047989] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
>> (scratch(0x850C)=0xCAFEDEAD)
>> [4.056845] radeon 0001:81:00.0: disabling GPU acceleration
>> [4.261053] [drm] Radeon Display Connectors
>> [4.265626] [drm] Connector 0:
>> [4.268744] [drm]   HDMI-A-1
>> [4.271735] [drm]   HPD4
>> [4.274313] [drm]   DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578 0x657c
>> 0x657c
>> [4.281755] [drm]   Encoders:
>> [4.284768] [drm] DFP1: INTERNAL_UNIPHY2
>> [4.289060] [drm] Connector 1:
>> [4.292125] [drm]   DVI-I-1
>> [4.294929] [drm]   HPD2
>> [4.297476] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
>> 0x656c
>> [4.304894] [drm]   Encoders:
>> [4.307872] [drm] DFP2: INTERNAL_UNIPHY
>> [4.312064] [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [4.465445] [drm] fb mappable at 0x80478000
>> [4.469662] [drm] vram apper at 0x8000
>> [4.473775] [drm] size 8294400
>> [4.476840] [drm] fb depth is 24
>> [4.480084] [drm]pitch is 7680
>> [4.759376] Console: switching to colour frame buffer device 240x67
>> [4.838736] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer device
>> [4.845560] radeon 0001:81:00.0: registered panic notifier
>> [4.856007] [drm] Initialized radeon 2.40.0 20080528 for 0001:81:00.0 on
>> minor 0
>>
>> [   31.335598] [drm:dce6_audio_get_pin] *ERROR* No connected audio pins
>> found!
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150505/86fa088f/attachment-0001.html>

[Intel-gfx] [PATCH 3/5] drm: Possible lock priority escalation.

2015-05-05 Thread Antoine, Peter

On Mon, 2015-05-04 at 15:56 +0200, Daniel Vetter wrote:
> On Mon, Apr 27, 2015 at 07:52:46PM +0300, Ville SyrjÃ¤lÃ¤ wrote:
> > On Thu, Apr 23, 2015 at 03:07:56PM +0100, Peter Antoine wrote:
> > > If an application that has a driver lock created, wants the lock the
> > > kernel context, it is not allowed to. If the call to drm_lock has a
> > > context of 0, it is rejected. If you set the context to _DRM_LOCK_CONT
> > > then call drm lock, it will pass the context == DRM_KERNEL_CONTEXT checks.
> > > But as the DRM_LOCK_CONT bits are not part of the context id this allows
> > > operations on the DRM_KERNEL_CONTEXT.
> > > 
> > > Issue: VIZ-5485
> > > Signed-off-by: Peter Antoine 
> 
> If you're touching code with drm_legacy_ prefix of in such a file you've
> ended up in the horrible corners of the dri1 dungeons and should head back
> out pronto ;-)
> 
> If we can actually run into this code on production i915 then we need to
> improve the locks at the door of these dungeons for kms drivers, not try
> to fix up the mess behind them. That's just plain impossible.
> 
> If you want to make really sure we get this right some simple drm igt
> tests to make sure these codepaths are really dead for kms driver might be
> good. But otherwise we really can only annotate this as wontfix in
> code security issue scanners.
> -Daniel
> 
There is a test that covers this fix. This is a simple three line fix
that stops a userspace driver locking the kernel context. Yes they are
other problems with this code, but why are they stopping this patch that
does a simple fix from going in?

I'll happily drop this patch if it causes more problems that it fixes.

Peter.

> > > ---
> > >  drivers/gpu/drm/drm_context.c | 6 +++---
> > >  drivers/gpu/drm/drm_lock.c| 4 ++--
> > >  2 files changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
> > > index 96350d1..1febcd3 100644
> > > --- a/drivers/gpu/drm/drm_context.c
> > > +++ b/drivers/gpu/drm/drm_context.c
> > > @@ -123,7 +123,7 @@ void drm_legacy_ctxbitmap_flush(struct drm_device 
> > > *dev, struct drm_file *file)
> > >  
> > >   list_for_each_entry_safe(pos, tmp, &dev->ctxlist, head) {
> > >   if (pos->tag == file &&
> > > - pos->handle != DRM_KERNEL_CONTEXT) {
> > > + _DRM_LOCKING_CONTEXT(pos->handle) != DRM_KERNEL_CONTEXT) {
> > >   if (dev->driver->context_dtor)
> > >   dev->driver->context_dtor(dev, pos->handle);
> > >  
> > > @@ -342,7 +342,7 @@ int drm_legacy_addctx(struct drm_device *dev, void 
> > > *data,
> > >   struct drm_ctx *ctx = data;
> > >  
> > >   ctx->handle = drm_legacy_ctxbitmap_next(dev);
> > > - if (ctx->handle == DRM_KERNEL_CONTEXT) {
> > > + if (_DRM_LOCKING_CONTEXT(ctx->handle) == DRM_KERNEL_CONTEXT) {
> > >   /* Skip kernel's context and get a new one. */
> > >   ctx->handle = drm_legacy_ctxbitmap_next(dev);
> > >   }
> > > @@ -449,7 +449,7 @@ int drm_legacy_rmctx(struct drm_device *dev, void 
> > > *data,
> > >   struct drm_ctx *ctx = data;
> > >  
> > >   DRM_DEBUG("%d\n", ctx->handle);
> > > - if (ctx->handle != DRM_KERNEL_CONTEXT) {
> > > + if (_DRM_LOCKING_CONTEXT(ctx->handle) != DRM_KERNEL_CONTEXT) {
> > >   if (dev->driver->context_dtor)
> > >   dev->driver->context_dtor(dev, ctx->handle);
> > >   drm_legacy_ctxbitmap_free(dev, ctx->handle);
> > 
> > How about just fixing the end parameter passed to idr_alloc()? AFAICS
> > that would take care of the context code.
> > 
> > Well, there are a few more issues with the code:
> > - not properly checking for negative return value from idr_alloc()
> > - leaking the ctx id on kmalloc() error
> > - pointless check for idr_alloc() returning 0 even though the min is 1
> > 
> > > diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
> > > index 070dd5d..94500930 100644
> > > --- a/drivers/gpu/drm/drm_lock.c
> > > +++ b/drivers/gpu/drm/drm_lock.c
> > > @@ -63,7 +63,7 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
> > >  
> > >   ++file_priv->lock_count;
> > 
> > While you're poking around this dungeopn, maybe you can kill lock_count?
> > We never seem to decrement it, and it's only checked in 
> > drm_legacy_i_have_hw_lock().
> > 
> > >  
> > > - if (lock->context == DRM_KERNEL_CONTEXT) {
> > > + if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
> > >   DRM_ERROR("Process %d using kernel context %d\n",
> > > task_pid_nr(current), lock->context);
> > >   return -EINVAL;
> > > @@ -153,7 +153,7 @@ int drm_legacy_unlock(struct drm_device *dev, void 
> > > *data, struct drm_file *file_
> > >   struct drm_lock *lock = data;
> > >   struct drm_master *master = file_priv->master;
> > >  
> > > - if (lock->context == DRM_KERNEL_CONTEXT) {
> > > + if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
> > >   DRM_ERROR("Process %d using

[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock

2015-05-05 Thread Antoine, Peter

On Mon, 2015-05-04 at 15:52 +0200, Daniel Vetter wrote:
> On Tue, Apr 28, 2015 at 10:52:32AM +0100, chris at chris-wilson.co.uk wrote:
> > On Tue, Apr 28, 2015 at 10:21:49AM +0100, Dave Gordon wrote:
> > > On 24/04/15 06:52, Antoine, Peter wrote:
> > > > I picked up this work due to the following Jira ticket created by the
> > > > security team (on Android) and was asked to give it a second look and
> > > > found a few more issues with the hw lock code.
> > > > 
> > > > https://jira01.devtools.intel.com/browse/GMINL-5388
> > > > I/O control on /dev/dri/card0 crashes the kernel (0x4008642b)
> > > > 
> > > > It also stops Linux as it kills the driver, I guess it might be possible
> > > > to reload the gfx driver. On a unpatched system the test that is
> > > > included in the issue or the igt test that has been posted for the issue
> > > > will show the problem.
> > > > 
> > > > I ran the test on an unpatched system here and the gui stopped and the
> > > > keyboard stopped responding, so I rebooted. With the patched system I
> > > > did not need to reboot.
> > > > 
> > > > Should I change the SIGTERM to SIGSEGV, not quite the same thing but
> > > > tooling is better at handling a segfault than a SIGTERM and the
> > > > application that calls this IOCTL is using an uninitialised hw lock so
> > > > it is kind of the same as differencing an uninitialised pointer (kind
> > > > of). Or, I could just remove it, but the bug has been in the code for at
> > > > least two years (and known about), and I would guess that any code that
> > > > is calling this is fuzzing the IOCTLs (as this is how the security team
> > > > found it) and we should reward them with a application exit.
> > > > 
> > > > Peter. 
> > > 
> > > SIGSEGV would be a better choice.
> > > 
> > > SIGTERM is normally sent by a user -- it's the default signal sent by
> > > kill(1). It's also commonly used to tell a long-running daemon process
> > > to tidy up and exit cleanly.
> > > 
> > > SIGSEGV commonly means "you accessed something that doesn't exist/isn't
> > > mapped/you don't have permissions for". There are specific subcases that
> > > can be indicated via the siginfo data; this is from the sigaction(1)
> > > manpage:
> > > 
> > > The following values can be placed in si_code for a SIGSEGV signal:
> > > 
> > > SEGV_MAPERRaddress not mapped to object
> > > 
> > > SEGV_ACCERRinvalid permissions for mapped object
> > > 
> > > SIGBUS would also be a possibility but that's generally taken to mean
> > > that an access got all the way to some physical bus and then faulted,
> > > whereas SIGSEGV suggests the access was rejected during the
> > > virtual-to-physical mapping process.
> > 
> > None of the above. Just return -EINVAL, -EPERM, -EACCESS as appropriate.
> 
> Seconded, we really don't want to be in the business of fixing up the drm
> design mistakes of the past 15 years. As long as we can fully lock out
> this particular dragon when running i915 we're imo good enough. The dri1
> design of a kernel shim driver cooperating with the ums driver for hw
> ownership is fundamentally unfixable.
> 
> Also we can't change any of it for drivers actually using it since it'll
> break them, which is a big no-go.
> -Daniel

I will remove it. But, If you are using this code path the driver/kernel
will have crashed. It covers a NULL pointer deference, so we are not
changing the API that anyone is actually using.

Peter.

[Bug 89405] radeon: ERROR invalid ioctl running weston-launch while X is running