[PATCH 14/14] mm: turn on vm_fault_t type checking

[Christoph Hellwig]

Switch vm_fault_t to point to an unsigned int with __bіtwise annotations.
This both catches any old ->fault or ->page_mkwrite instance with plain
compiler type checking, as well as finding more intricate problems with
sparse.

Signed-off-by: Christoph Hellwig 
---
 arch/alpha/mm/fault.c |  2 +-
 arch/arc/mm/fault.c   |  3 +-
 arch/arm/mm/fault.c   |  5 +-
 arch/arm64/mm/fault.c |  7 +-
 arch/hexagon/mm/vm_fault.c|  2 +-
 arch/ia64/mm/fault.c  |  2 +-
 arch/m68k/mm/fault.c  |  2 +-
 arch/microblaze/mm/fault.c|  2 +-
 arch/mips/mm/fault.c  |  2 +-
 arch/nds32/mm/fault.c |  2 +-
 arch/nios2/mm/fault.c |  2 +-
 arch/openrisc/mm/fault.c  |  2 +-
 arch/parisc/mm/fault.c|  2 +-
 arch/powerpc/include/asm/copro.h  |  2 +-
 arch/powerpc/mm/copro_fault.c |  2 +-
 arch/powerpc/mm/fault.c   | 10 +--
 arch/powerpc/platforms/cell/spufs/fault.c |  2 +-
 arch/riscv/mm/fault.c |  3 +-
 arch/s390/kernel/vdso.c   |  2 +-
 arch/s390/mm/fault.c  |  2 +-
 arch/sh/mm/fault.c|  2 +-
 arch/sparc/mm/fault_32.c  |  4 +-
 arch/sparc/mm/fault_64.c  |  3 +-
 arch/um/kernel/trap.c |  2 +-
 arch/unicore32/mm/fault.c | 10 +--
 arch/x86/entry/vdso/vma.c |  4 +-
 arch/x86/mm/fault.c   | 11 +--
 arch/xtensa/mm/fault.c|  2 +-
 drivers/dax/device.c  | 21 +++---
 drivers/gpu/drm/drm_vm.c  | 10 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |  2 +-
 drivers/gpu/drm/gma500/framebuffer.c  |  6 +-
 drivers/gpu/drm/gma500/gem.c  |  2 +-
 drivers/gpu/drm/gma500/psb_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  2 +-
 drivers/gpu/drm/i915/i915_gem.c   | 21 ++
 drivers/gpu/drm/msm/msm_drv.h |  2 +-
 drivers/gpu/drm/msm/msm_gem.c |  2 +-
 drivers/gpu/drm/qxl/qxl_ttm.c |  4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   |  2 +-
 drivers/gpu/drm/udl/udl_drv.h |  2 +-
 drivers/gpu/drm/udl/udl_gem.c |  2 +-
 drivers/gpu/drm/vc4/vc4_bo.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 drivers/hwtracing/intel_th/msu.c  |  2 +-
 drivers/iommu/amd_iommu_v2.c  |  2 +-
 drivers/iommu/intel-svm.c |  3 +-
 drivers/misc/cxl/fault.c  |  2 +-
 drivers/misc/ocxl/context.c   |  6 +-
 drivers/misc/ocxl/link.c  |  2 +-
 drivers/misc/ocxl/sysfs.c |  2 +-
 drivers/scsi/cxlflash/superpipe.c |  4 +-
 drivers/staging/ncpfs/mmap.c  |  2 +-
 drivers/xen/privcmd.c |  2 +-
 fs/9p/vfs_file.c  |  2 +-
 fs/afs/internal.h |  2 +-
 fs/afs/write.c|  2 +-
 fs/f2fs/file.c| 10 +--
 fs/fuse/file.c|  2 +-
 fs/gfs2/file.c|  2 +-
 fs/iomap.c|  2 +-
 fs/nfs/file.c |  4 +-
 fs/nilfs2/file.c  |  2 +-
 fs/proc/vmcore.c  |  2 +-
 fs/userfaultfd.c  |  4 +-
 fs/xfs/xfs_file.c | 12 ++--
 include/linux/huge_mm.h   | 13 ++--
 include/linux/hugetlb.h   |  2 +-
 include/linux/iomap.h |  4 +-
 include/linux/mm.h| 67 +
 include/linux/mm_types.h  |  5 +-
 include/linux/oom.h   |  2 +-
 include/linux/swapops.h   |  4 +-
 include/linux/userfaultfd_k.h |  5 +-
 ipc/shm.c |  2 +-
 kernel/events/core.c  |  4 +-
 mm/gup.c  |  7 +-
 mm/hmm.c  |  2 +-
 mm/huge_memory.c  | 29 
 mm/hugetlb.c  | 25 +++
 mm/internal.h |  2 +-
 mm/khugepaged.c   |  3 +-
 mm/ksm.c  |  2 +-
 mm/memory.c   | 88 ---
 mm/mmap.c |  4 +-
 mm/shmem.c|  9 +--
 samples/vfio-mdev/mbochs.c|  4 +-
 virt/kvm/kvm_main.c   |  2 +-
 91 files 

[PATCH 10/14] vgem: separate errno from VM_FAULT_* values

[Christoph Hellwig]

And streamline the code in vgem_fault with early returns so that it is
a little bit more readable.

Signed-off-by: Christoph Hellwig 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 51 +++--
 1 file changed, 23 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 2524ff116f00..a261e0aab83a 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -61,12 +61,13 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
kfree(vgem_obj);
 }
 
-static int vgem_gem_fault(struct vm_fault *vmf)
+static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_vgem_gem_object *obj = vma->vm_private_data;
/* We don't use vmf->pgoff since that has the fake offset */
unsigned long vaddr = vmf->address;
+   struct page *page;
int ret;
loff_t num_pages;
pgoff_t page_offset;
@@ -85,35 +86,29 @@ static int vgem_gem_fault(struct vm_fault *vmf)
ret = 0;
}
mutex_unlock(>pages_lock);
-   if (ret) {
-   struct page *page;
-
-   page = shmem_read_mapping_page(
-   file_inode(obj->base.filp)->i_mapping,
-   page_offset);
-   if (!IS_ERR(page)) {
-   vmf->page = page;
-   ret = 0;
-   } else switch (PTR_ERR(page)) {
-   case -ENOSPC:
-   case -ENOMEM:
-   ret = VM_FAULT_OOM;
-   break;
-   case -EBUSY:
-   ret = VM_FAULT_RETRY;
-   break;
-   case -EFAULT:
-   case -EINVAL:
-   ret = VM_FAULT_SIGBUS;
-   break;
-   default:
-   WARN_ON(PTR_ERR(page));
-   ret = VM_FAULT_SIGBUS;
-   break;
-   }
+   if (!ret)
+   return 0;
+
+   page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
+   page_offset);
+   if (!IS_ERR(page)) {
+   vmf->page = page;
+   return 0;
+   }
 
+   switch (PTR_ERR(page)) {
+   case -ENOSPC:
+   case -ENOMEM:
+   return VM_FAULT_OOM;
+   case -EBUSY:
+   return VM_FAULT_RETRY;
+   case -EFAULT:
+   case -EINVAL:
+   return VM_FAULT_SIGBUS;
+   default:
+   WARN_ON(PTR_ERR(page));
+   return VM_FAULT_SIGBUS;
}
-   return ret;
 }
 
 static const struct vm_operations_struct vgem_gem_vm_ops = {
-- 
2.17.0

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

[PATCH 13/14] mm: move arch specific VM_FAULT_* flags to mm.h

[Christoph Hellwig]

Various architectures define their own internal flags.  Not sure a public
header like mm.h is a good place, but keeping them inside the arch code
with possible conflicts also seems like a bad idea.  Maybe we just need
to stop overloading the value instead.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/mm/fault.c   | 3 ---
 arch/arm64/mm/fault.c | 3 ---
 arch/s390/mm/fault.c  | 6 --
 arch/unicore32/mm/fault.c | 3 ---
 include/linux/mm.h| 7 +++
 5 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 32034543f49c..b696eabccf60 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -201,9 +201,6 @@ void do_bad_area(unsigned long addr, unsigned int fsr, 
struct pt_regs *regs)
 }
 
 #ifdef CONFIG_MMU
-#define VM_FAULT_BADMAP0x01
-#define VM_FAULT_BADACCESS 0x02
-
 /*
  * Check that the permissions on the VMA allow for the fault which occurred.
  * If we encountered a write fault, we must have write permission, otherwise
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 91c53a7d2575..3d0b1f8eacce 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -318,9 +318,6 @@ static void do_bad_area(unsigned long addr, unsigned int 
esr, struct pt_regs *re
}
 }
 
-#define VM_FAULT_BADMAP0x01
-#define VM_FAULT_BADACCESS 0x02
-
 static int __do_page_fault(struct mm_struct *mm, unsigned long addr,
   unsigned int mm_flags, unsigned long vm_flags,
   struct task_struct *tsk)
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index e074480d3598..48c781ae25d0 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -44,12 +44,6 @@
 #define __SUBCODE_MASK 0x0600
 #define __PF_RES_FIELD 0x8000ULL
 
-#define VM_FAULT_BADCONTEXT0x01
-#define VM_FAULT_BADMAP0x02
-#define VM_FAULT_BADACCESS 0x04
-#define VM_FAULT_SIGNAL0x08
-#define VM_FAULT_PFAULT0x10
-
 enum fault_type {
KERNEL_FAULT,
USER_FAULT,
diff --git a/arch/unicore32/mm/fault.c b/arch/unicore32/mm/fault.c
index 381473412937..6c3c1a82925f 100644
--- a/arch/unicore32/mm/fault.c
+++ b/arch/unicore32/mm/fault.c
@@ -148,9 +148,6 @@ void do_bad_area(unsigned long addr, unsigned int fsr, 
struct pt_regs *regs)
__do_kernel_fault(mm, addr, fsr, regs);
 }
 
-#define VM_FAULT_BADMAP0x01
-#define VM_FAULT_BADACCESS 0x02
-
 /*
  * Check that the permissions on the VMA allow for the fault which occurred.
  * If we encountered a write fault, we must have write permission, otherwise
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 338b8a1afb02..64d09e3afc24 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1250,6 +1250,13 @@ static inline void clear_page_pfmemalloc(struct page 
*page)
 * and needs fsync() to complete (for
 * synchronous page faults in DAX) */
 
+/* Only for use in architecture specific page fault handling: */
+#define VM_FAULT_BADMAP0x01
+#define VM_FAULT_BADACCESS 0x02
+#define VM_FAULT_BADCONTEXT0x04
+#define VM_FAULT_SIGNAL0x08
+#define VM_FAULT_PFAULT0x10
+
 #define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV | \
 VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE | \
 VM_FAULT_FALLBACK)
-- 
2.17.0

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

[PATCH 12/14] lustre: separate errno from VM_FAULT_* values

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 .../staging/lustre/lustre/llite/llite_mmap.c  | 37 +++
 .../lustre/lustre/llite/vvp_internal.h|  2 +-
 2 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_mmap.c 
b/drivers/staging/lustre/lustre/llite/llite_mmap.c
index 214b07554e62..061d98871959 100644
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -231,23 +231,18 @@ static int ll_page_mkwrite0(struct vm_area_struct *vma, 
struct page *vmpage,
return result;
 }
 
-static inline int to_fault_error(int result)
+static inline vm_fault_t to_fault_error(int result)
 {
switch (result) {
case 0:
-   result = VM_FAULT_LOCKED;
-   break;
+   return VM_FAULT_LOCKED;
case -EFAULT:
-   result = VM_FAULT_NOPAGE;
-   break;
+   return VM_FAULT_NOPAGE;
case -ENOMEM:
-   result = VM_FAULT_OOM;
-   break;
+   return VM_FAULT_OOM;
default:
-   result = VM_FAULT_SIGBUS;
-   break;
+   return VM_FAULT_SIGBUS;
}
-   return result;
 }
 
 /**
@@ -261,7 +256,7 @@ static inline int to_fault_error(int result)
  * \retval VM_FAULT_ERROR on general error
  * \retval NOPAGE_OOM not have memory for allocate new page
  */
-static int ll_fault0(struct vm_area_struct *vma, struct vm_fault *vmf)
+static vm_fault_t ll_fault0(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
struct lu_env  *env;
struct cl_io*io;
@@ -269,7 +264,7 @@ static int ll_fault0(struct vm_area_struct *vma, struct 
vm_fault *vmf)
struct page  *vmpage;
unsigned long   ra_flags;
int   result = 0;
-   int   fault_ret = 0;
+   vm_fault_tfault_ret = 0;
u16 refcheck;
 
env = cl_env_get();
@@ -323,7 +318,7 @@ static int ll_fault0(struct vm_area_struct *vma, struct 
vm_fault *vmf)
return fault_ret;
 }
 
-static int ll_fault(struct vm_fault *vmf)
+static vm_fault_t ll_fault(struct vm_fault *vmf)
 {
int count = 0;
bool printed = false;
@@ -364,7 +359,7 @@ static int ll_fault(struct vm_fault *vmf)
return result;
 }
 
-static int ll_page_mkwrite(struct vm_fault *vmf)
+static vm_fault_t ll_page_mkwrite(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
int count = 0;
@@ -390,22 +385,16 @@ static int ll_page_mkwrite(struct vm_fault *vmf)
switch (result) {
case 0:
LASSERT(PageLocked(vmf->page));
-   result = VM_FAULT_LOCKED;
-   break;
+   return VM_FAULT_LOCKED;
case -ENODATA:
case -EAGAIN:
case -EFAULT:
-   result = VM_FAULT_NOPAGE;
-   break;
+   return VM_FAULT_NOPAGE;
case -ENOMEM:
-   result = VM_FAULT_OOM;
-   break;
+   return VM_FAULT_OOM;
default:
-   result = VM_FAULT_SIGBUS;
-   break;
+   return VM_FAULT_SIGBUS;
}
-
-   return result;
 }
 
 /**
diff --git a/drivers/staging/lustre/lustre/llite/vvp_internal.h 
b/drivers/staging/lustre/lustre/llite/vvp_internal.h
index 7d3abb43584a..c194966a3d82 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_internal.h
+++ b/drivers/staging/lustre/lustre/llite/vvp_internal.h
@@ -83,7 +83,7 @@ struct vvp_io {
/**
 * fault API used bitflags for return code.
 */
-   unsigned intft_flags;
+   vm_fault_tft_flags;
/**
 * check that flags are from filemap_fault
 */
-- 
2.17.0

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

[PATCH 11/14] ttm: separate errno from VM_FAULT_* values

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 42 +
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 8eba95b3c737..255e7801f62c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -43,10 +43,11 @@
 
 #define TTM_BO_VM_NUM_PREFAULT 16
 
-static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
+static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
 {
-   int ret = 0;
+   vm_fault_t ret = 0;
+   int err = 0;
 
if (likely(!bo->moving))
goto out_unlock;
@@ -77,8 +78,8 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
/*
 * Ordinary wait.
 */
-   ret = dma_fence_wait(bo->moving, true);
-   if (unlikely(ret != 0)) {
+   err = dma_fence_wait(bo->moving, true);
+   if (unlikely(err != 0)) {
ret = (ret != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
VM_FAULT_NOPAGE;
goto out_unlock;
@@ -104,7 +105,7 @@ static unsigned long ttm_bo_io_mem_pfn(struct 
ttm_buffer_object *bo,
+ page_offset;
 }
 
-static int ttm_bo_vm_fault(struct vm_fault *vmf)
+static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
@@ -115,7 +116,8 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
unsigned long pfn;
struct ttm_tt *ttm = NULL;
struct page *page;
-   int ret;
+   vm_fault_t ret;
+   int err;
int i;
unsigned long address = vmf->address;
struct ttm_mem_type_manager *man =
@@ -128,9 +130,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
 * for reserve, and if it fails, retry the fault after waiting
 * for the buffer to become unreserved.
 */
-   ret = ttm_bo_reserve(bo, true, true, NULL);
-   if (unlikely(ret != 0)) {
-   if (ret != -EBUSY)
+   err = ttm_bo_reserve(bo, true, true, NULL);
+   if (unlikely(err != 0)) {
+   if (err != -EBUSY)
return VM_FAULT_NOPAGE;
 
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
@@ -162,8 +164,8 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
 
if (bdev->driver->fault_reserve_notify) {
-   ret = bdev->driver->fault_reserve_notify(bo);
-   switch (ret) {
+   err = bdev->driver->fault_reserve_notify(bo);
+   switch (err) {
case 0:
break;
case -EBUSY:
@@ -191,13 +193,13 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
goto out_unlock;
}
 
-   ret = ttm_mem_io_lock(man, true);
-   if (unlikely(ret != 0)) {
+   err = ttm_mem_io_lock(man, true);
+   if (unlikely(err != 0)) {
ret = VM_FAULT_NOPAGE;
goto out_unlock;
}
-   ret = ttm_mem_io_reserve_vm(bo);
-   if (unlikely(ret != 0)) {
+   err = ttm_mem_io_reserve_vm(bo);
+   if (unlikely(err != 0)) {
ret = VM_FAULT_SIGBUS;
goto out_io_unlock;
}
@@ -265,21 +267,21 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
 
if (vma->vm_flags & VM_MIXEDMAP)
-   ret = vm_insert_mixed(, address,
+   err = vm_insert_mixed(, address,
__pfn_to_pfn_t(pfn, PFN_DEV));
else
-   ret = vm_insert_pfn(, address, pfn);
+   err = vm_insert_pfn(, address, pfn);
 
/*
 * Somebody beat us to this PTE or prefaulting to
 * an already populated PTE, or prefaulting error.
 */
 
-   if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
+   if (unlikely((err == -EBUSY) || (err != 0 && i > 0)))
break;
-   else if (unlikely(ret != 0)) {
+   else if (unlikely(err != 0)) {
ret =
-   (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
+   (err == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
goto out_io_unlock;
}
 
-- 
2.17.0

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

[PATCH 06/14] btrfs: separate errno from VM_FAULT_* values

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 fs/btrfs/ctree.h |  2 +-
 fs/btrfs/inode.c | 19 ++-
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 1485cd130e2b..02a0de73c1d1 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -3203,7 +3203,7 @@ int btrfs_merge_bio_hook(struct page *page, unsigned long 
offset,
 size_t size, struct bio *bio,
 unsigned long bio_flags);
 void btrfs_set_range_writeback(void *private_data, u64 start, u64 end);
-int btrfs_page_mkwrite(struct vm_fault *vmf);
+vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf);
 int btrfs_readpage(struct file *file, struct page *page);
 void btrfs_evict_inode(struct inode *inode);
 int btrfs_write_inode(struct inode *inode, struct writeback_control *wbc);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ec9db248c499..f4f03f0f4556 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8824,7 +8824,7 @@ static void btrfs_invalidatepage(struct page *page, 
unsigned int offset,
  * beyond EOF, then the page is guaranteed safe against truncation until we
  * unlock the page.
  */
-int btrfs_page_mkwrite(struct vm_fault *vmf)
+vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf)
 {
struct page *page = vmf->page;
struct inode *inode = file_inode(vmf->vma->vm_file);
@@ -8836,7 +8836,8 @@ int btrfs_page_mkwrite(struct vm_fault *vmf)
char *kaddr;
unsigned long zero_start;
loff_t size;
-   int ret;
+   vm_fault_t ret;
+   int err;
int reserved = 0;
u64 reserved_space;
u64 page_start;
@@ -8858,14 +8859,14 @@ int btrfs_page_mkwrite(struct vm_fault *vmf)
 * end up waiting indefinitely to get a lock on the page currently
 * being processed by btrfs_page_mkwrite() function.
 */
-   ret = btrfs_delalloc_reserve_space(inode, _reserved, page_start,
+   err = btrfs_delalloc_reserve_space(inode, _reserved, page_start,
   reserved_space);
-   if (!ret) {
-   ret = file_update_time(vmf->vma->vm_file);
+   if (!err) {
+   err = file_update_time(vmf->vma->vm_file);
reserved = 1;
}
-   if (ret) {
-   if (ret == -ENOMEM)
+   if (err) {
+   if (err == -ENOMEM)
ret = VM_FAULT_OOM;
else /* -ENOSPC, -EIO, etc */
ret = VM_FAULT_SIGBUS;
@@ -8927,9 +8928,9 @@ int btrfs_page_mkwrite(struct vm_fault *vmf)
  EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
  0, 0, _state);
 
-   ret = btrfs_set_extent_delalloc(inode, page_start, end, 0,
+   err = btrfs_set_extent_delalloc(inode, page_start, end, 0,
_state, 0);
-   if (ret) {
+   if (err) {
unlock_extent_cached(io_tree, page_start, page_end,
 _state);
ret = VM_FAULT_SIGBUS;
-- 
2.17.0

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

[PATCH 09/14] ubifs: separate errno from VM_FAULT_* values

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 fs/ubifs/file.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index 1acb2ff505e6..7c1a2e1c3de5 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -1513,7 +1513,7 @@ static int ubifs_releasepage(struct page *page, gfp_t 
unused_gfp_flags)
  * mmap()d file has taken write protection fault and is being made writable.
  * UBIFS must ensure page is budgeted for.
  */
-static int ubifs_vm_page_mkwrite(struct vm_fault *vmf)
+static vm_fault_t ubifs_vm_page_mkwrite(struct vm_fault *vmf)
 {
struct page *page = vmf->page;
struct inode *inode = file_inode(vmf->vma->vm_file);
@@ -1521,6 +1521,7 @@ static int ubifs_vm_page_mkwrite(struct vm_fault *vmf)
struct timespec now = current_time(inode);
struct ubifs_budget_req req = { .new_page = 1 };
int err, update_time;
+   vm_fault_t ret = 0;
 
dbg_gen("ino %lu, pg %lu, i_size %lld", inode->i_ino, page->index,
i_size_read(inode));
@@ -1601,8 +1602,8 @@ static int ubifs_vm_page_mkwrite(struct vm_fault *vmf)
unlock_page(page);
ubifs_release_budget(c, );
if (err)
-   err = VM_FAULT_SIGBUS;
-   return err;
+   ret = VM_FAULT_SIGBUS;
+   return ret;
 }
 
 static const struct vm_operations_struct ubifs_file_vm_ops = {
-- 
2.17.0

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

[PATCH 03/14] dax: make the dax_iomap_fault prototype consistent

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 include/linux/dax.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/dax.h b/include/linux/dax.h
index dc65ece825ee..a292bccdc274 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -183,7 +183,7 @@ void dax_flush(struct dax_device *dax_dev, void *addr, 
size_t size);
 
 ssize_t dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,
const struct iomap_ops *ops);
-int dax_iomap_fault(struct vm_fault *vmf, enum page_entry_size pe_size,
+vm_fault_t dax_iomap_fault(struct vm_fault *vmf, enum page_entry_size pe_size,
pfn_t *pfnp, int *errp, const struct iomap_ops *ops);
 vm_fault_t dax_finish_sync_fault(struct vm_fault *vmf,
enum page_entry_size pe_size, pfn_t pfn);
-- 
2.17.0

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

[PATCH 08/14] ocfs2: separate errno from VM_FAULT_* values

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 fs/ocfs2/mmap.c | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/fs/ocfs2/mmap.c b/fs/ocfs2/mmap.c
index fb9a20e3d608..e75c1fc5333e 100644
--- a/fs/ocfs2/mmap.c
+++ b/fs/ocfs2/mmap.c
@@ -44,11 +44,11 @@
 #include "ocfs2_trace.h"
 
 
-static int ocfs2_fault(struct vm_fault *vmf)
+static vm_fault_t ocfs2_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
sigset_t oldset;
-   int ret;
+   vm_fault_t ret;
 
ocfs2_block_signals();
ret = filemap_fault(vmf);
@@ -59,10 +59,10 @@ static int ocfs2_fault(struct vm_fault *vmf)
return ret;
 }
 
-static int __ocfs2_page_mkwrite(struct file *file, struct buffer_head *di_bh,
-   struct page *page)
+static vm_fault_t __ocfs2_page_mkwrite(struct file *file,
+   struct buffer_head *di_bh, struct page *page)
 {
-   int ret = VM_FAULT_NOPAGE;
+   vm_fault_t ret = VM_FAULT_NOPAGE;
struct inode *inode = file_inode(file);
struct address_space *mapping = inode->i_mapping;
loff_t pos = page_offset(page);
@@ -71,6 +71,7 @@ static int __ocfs2_page_mkwrite(struct file *file, struct 
buffer_head *di_bh,
struct page *locked_page = NULL;
void *fsdata;
loff_t size = i_size_read(inode);
+   int err;
 
last_index = (size - 1) >> PAGE_SHIFT;
 
@@ -105,12 +106,12 @@ static int __ocfs2_page_mkwrite(struct file *file, struct 
buffer_head *di_bh,
if (page->index == last_index)
len = ((size - 1) & ~PAGE_MASK) + 1;
 
-   ret = ocfs2_write_begin_nolock(mapping, pos, len, OCFS2_WRITE_MMAP,
+   err = ocfs2_write_begin_nolock(mapping, pos, len, OCFS2_WRITE_MMAP,
   _page, , di_bh, page);
-   if (ret) {
-   if (ret != -ENOSPC)
-   mlog_errno(ret);
-   if (ret == -ENOMEM)
+   if (err) {
+   if (err != -ENOSPC)
+   mlog_errno(err);
+   if (err == -ENOMEM)
ret = VM_FAULT_OOM;
else
ret = VM_FAULT_SIGBUS;
@@ -121,20 +122,21 @@ static int __ocfs2_page_mkwrite(struct file *file, struct 
buffer_head *di_bh,
ret = VM_FAULT_NOPAGE;
goto out;
}
-   ret = ocfs2_write_end_nolock(mapping, pos, len, len, fsdata);
-   BUG_ON(ret != len);
+   err = ocfs2_write_end_nolock(mapping, pos, len, len, fsdata);
+   BUG_ON(err != len);
ret = VM_FAULT_LOCKED;
 out:
return ret;
 }
 
-static int ocfs2_page_mkwrite(struct vm_fault *vmf)
+static vm_fault_t ocfs2_page_mkwrite(struct vm_fault *vmf)
 {
struct page *page = vmf->page;
struct inode *inode = file_inode(vmf->vma->vm_file);
struct buffer_head *di_bh = NULL;
sigset_t oldset;
-   int ret;
+   vm_fault_t ret = 0;
+   int err;
 
sb_start_pagefault(inode->i_sb);
ocfs2_block_signals();
@@ -144,10 +146,10 @@ static int ocfs2_page_mkwrite(struct vm_fault *vmf)
 * node. Taking the data lock will also ensure that we don't
 * attempt page truncation as part of a downconvert.
 */
-   ret = ocfs2_inode_lock(inode, _bh, 1);
-   if (ret < 0) {
+   err = ocfs2_inode_lock(inode, _bh, 1);
+   if (err < 0) {
mlog_errno(ret);
-   if (ret == -ENOMEM)
+   if (err == -ENOMEM)
ret = VM_FAULT_OOM;
else
ret = VM_FAULT_SIGBUS;
-- 
2.17.0

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

[PATCH 07/14] ext4: separate errno from VM_FAULT_* values

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 fs/ext4/ext4.h  |  4 ++--
 fs/ext4/inode.c | 30 +++---
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index fa52b7dd4542..48592d0edf3e 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2463,8 +2463,8 @@ extern int ext4_writepage_trans_blocks(struct inode *);
 extern int ext4_chunk_trans_blocks(struct inode *, int nrblocks);
 extern int ext4_zero_partial_blocks(handle_t *handle, struct inode *inode,
 loff_t lstart, loff_t lend);
-extern int ext4_page_mkwrite(struct vm_fault *vmf);
-extern int ext4_filemap_fault(struct vm_fault *vmf);
+extern vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf);
+extern vm_fault_t ext4_filemap_fault(struct vm_fault *vmf);
 extern qsize_t *ext4_get_reserved_space(struct inode *inode);
 extern int ext4_get_projid(struct inode *inode, kprojid_t *projid);
 extern void ext4_da_update_reserve_space(struct inode *inode,
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 95bc48f5c88b..fe49045a2832 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -6106,27 +6106,27 @@ static int ext4_bh_unmapped(handle_t *handle, struct 
buffer_head *bh)
return !buffer_mapped(bh);
 }
 
-int ext4_page_mkwrite(struct vm_fault *vmf)
+vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct page *page = vmf->page;
loff_t size;
unsigned long len;
-   int ret;
+   vm_fault_t ret;
struct file *file = vma->vm_file;
struct inode *inode = file_inode(file);
struct address_space *mapping = inode->i_mapping;
handle_t *handle;
get_block_t *get_block;
-   int retries = 0;
+   int retries = 0, err;
 
sb_start_pagefault(inode->i_sb);
file_update_time(vma->vm_file);
 
down_read(_I(inode)->i_mmap_sem);
 
-   ret = ext4_convert_inline_data(inode);
-   if (ret)
+   err = ext4_convert_inline_data(inode);
+   if (err)
goto out_ret;
 
/* Delalloc case is easy... */
@@ -6134,9 +6134,9 @@ int ext4_page_mkwrite(struct vm_fault *vmf)
!ext4_should_journal_data(inode) &&
!ext4_nonda_switch(inode->i_sb)) {
do {
-   ret = block_page_mkwrite(vma, vmf,
+   err = block_page_mkwrite(vma, vmf,
   ext4_da_get_block_prep);
-   } while (ret == -ENOSPC &&
+   } while (err == -ENOSPC &&
   ext4_should_retry_alloc(inode->i_sb, ));
goto out_ret;
}
@@ -6181,8 +6181,8 @@ int ext4_page_mkwrite(struct vm_fault *vmf)
ret = VM_FAULT_SIGBUS;
goto out;
}
-   ret = block_page_mkwrite(vma, vmf, get_block);
-   if (!ret && ext4_should_journal_data(inode)) {
+   err = block_page_mkwrite(vma, vmf, get_block);
+   if (!err && ext4_should_journal_data(inode)) {
if (ext4_walk_page_buffers(handle, page_buffers(page), 0,
  PAGE_SIZE, NULL, do_journal_get_write_access)) {
unlock_page(page);
@@ -6193,24 +6193,24 @@ int ext4_page_mkwrite(struct vm_fault *vmf)
ext4_set_inode_state(inode, EXT4_STATE_JDATA);
}
ext4_journal_stop(handle);
-   if (ret == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, ))
+   if (err == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, ))
goto retry_alloc;
 out_ret:
-   ret = block_page_mkwrite_return(ret);
+   ret = block_page_mkwrite_return(err);
 out:
up_read(_I(inode)->i_mmap_sem);
sb_end_pagefault(inode->i_sb);
return ret;
 }
 
-int ext4_filemap_fault(struct vm_fault *vmf)
+vm_fault_t ext4_filemap_fault(struct vm_fault *vmf)
 {
struct inode *inode = file_inode(vmf->vma->vm_file);
-   int err;
+   vm_fault_t ret;
 
down_read(_I(inode)->i_mmap_sem);
-   err = filemap_fault(vmf);
+   ret = filemap_fault(vmf);
up_read(_I(inode)->i_mmap_sem);
 
-   return err;
+   return ret;
 }
-- 
2.17.0

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

[PATCH 01/14] orangefs: don't return errno values from ->fault

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 fs/orangefs/file.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c
index 26358efbf794..b4a25cd4f3fa 100644
--- a/fs/orangefs/file.c
+++ b/fs/orangefs/file.c
@@ -528,18 +528,16 @@ static long orangefs_ioctl(struct file *file, unsigned 
int cmd, unsigned long ar
return ret;
 }
 
-static int orangefs_fault(struct vm_fault *vmf)
+static vm_fault_t orangefs_fault(struct vm_fault *vmf)
 {
struct file *file = vmf->vma->vm_file;
int rc;
-   rc = orangefs_inode_getattr(file->f_mapping->host, 0, 1,
-   STATX_SIZE);
-   if (rc == -ESTALE)
-   rc = -EIO;
+
+   rc = orangefs_inode_getattr(file->f_mapping->host, 0, 1, STATX_SIZE);
if (rc) {
gossip_err("%s: orangefs_inode_getattr failed, "
"rc:%d:.\n", __func__, rc);
-   return rc;
+   return VM_FAULT_SIGBUS;
}
return filemap_fault(vmf);
 }
-- 
2.17.0

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

[PATCH 05/14] ceph: untangle ceph_filemap_fault

[Christoph Hellwig]

Streamline the code to have a somewhat natural flow, and separate the
errno values from the VM_FAULT_* values.

Signed-off-by: Christoph Hellwig 
---
 fs/ceph/addr.c | 100 +
 1 file changed, 51 insertions(+), 49 deletions(-)

diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 5f7ad3d0df2e..6e80894ca073 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -1428,15 +1428,18 @@ static void ceph_restore_sigs(sigset_t *oldset)
 /*
  * vm ops
  */
-static int ceph_filemap_fault(struct vm_fault *vmf)
+static vm_fault_t ceph_filemap_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct inode *inode = file_inode(vma->vm_file);
+   struct address_space *mapping = inode->i_mapping;
struct ceph_inode_info *ci = ceph_inode(inode);
struct ceph_file_info *fi = vma->vm_file->private_data;
-   struct page *pinned_page = NULL;
+   struct page *pinned_page = NULL, *page;
loff_t off = vmf->pgoff << PAGE_SHIFT;
-   int want, got, ret;
+   int want, got, err = 0;
+   vm_fault_t ret = 0;
+   bool did_fault = false;
sigset_t oldset;
 
ceph_block_sigs();
@@ -1449,9 +1452,9 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
want = CEPH_CAP_FILE_CACHE;
 
got = 0;
-   ret = ceph_get_caps(ci, CEPH_CAP_FILE_RD, want, -1, , _page);
-   if (ret < 0)
-   goto out_restore;
+   err = ceph_get_caps(ci, CEPH_CAP_FILE_RD, want, -1, , _page);
+   if (err < 0)
+   goto out_errno;
 
dout("filemap_fault %p %llu~%zd got cap refs on %s\n",
 inode, off, (size_t)PAGE_SIZE, ceph_cap_string(got));
@@ -1462,8 +1465,8 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
ceph_add_rw_context(fi, _ctx);
ret = filemap_fault(vmf);
ceph_del_rw_context(fi, _ctx);
-   } else
-   ret = -EAGAIN;
+   did_fault = true;
+   }
 
dout("filemap_fault %p %llu~%zd dropping cap refs on %s ret %d\n",
 inode, off, (size_t)PAGE_SIZE, ceph_cap_string(got), ret);
@@ -1471,57 +1474,55 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
put_page(pinned_page);
ceph_put_cap_refs(ci, got);
 
-   if (ret != -EAGAIN)
+   if (did_fault)
goto out_restore;
 
/* read inline data */
if (off >= PAGE_SIZE) {
/* does not support inline data > PAGE_SIZE */
ret = VM_FAULT_SIGBUS;
+   goto out_restore;
+   }
+
+   page = find_or_create_page(mapping, 0,
+   mapping_gfp_constraint(mapping, ~__GFP_FS));
+   if (!page) {
+   ret = VM_FAULT_OOM;
+   goto out_inline;
+   }
+
+   err = __ceph_do_getattr(inode, page, CEPH_STAT_CAP_INLINE_DATA, true);
+   if (err < 0 || off >= i_size_read(inode)) {
+   unlock_page(page);
+   put_page(page);
+   if (err < 0)
+   goto out_errno;
+   ret = VM_FAULT_SIGBUS;
} else {
-   int ret1;
-   struct address_space *mapping = inode->i_mapping;
-   struct page *page = find_or_create_page(mapping, 0,
-   mapping_gfp_constraint(mapping,
-   ~__GFP_FS));
-   if (!page) {
-   ret = VM_FAULT_OOM;
-   goto out_inline;
-   }
-   ret1 = __ceph_do_getattr(inode, page,
-CEPH_STAT_CAP_INLINE_DATA, true);
-   if (ret1 < 0 || off >= i_size_read(inode)) {
-   unlock_page(page);
-   put_page(page);
-   if (ret1 < 0)
-   ret = ret1;
-   else
-   ret = VM_FAULT_SIGBUS;
-   goto out_inline;
-   }
-   if (ret1 < PAGE_SIZE)
-   zero_user_segment(page, ret1, PAGE_SIZE);
+   if (err < PAGE_SIZE)
+   zero_user_segment(page, err, PAGE_SIZE);
else
flush_dcache_page(page);
SetPageUptodate(page);
vmf->page = page;
ret = VM_FAULT_MAJOR | VM_FAULT_LOCKED;
-out_inline:
-   dout("filemap_fault %p %llu~%zd read inline data ret %d\n",
-inode, off, (size_t)PAGE_SIZE, ret);
}
+
+out_inline:
+   dout("filemap_fault %p %llu~%zd read inline data ret %d\n",
+inode, off, (size_t)PAGE_SIZE, ret);
 out_restore:
ceph_restore_sigs();
-   if (ret < 0)
-   ret = (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
-
return ret;
+out_errno:
+   ret = (err == -ENOMEM) 

[PATCH 02/14] fs: make the filemap_page_mkwrite prototype consistent

[Christoph Hellwig]

!CONFIG_MMU version didn't agree with the rest of the kernel..

Signed-off-by: Christoph Hellwig 
---
 mm/filemap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 52517f28e6f4..cf21ced98eff 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2748,7 +2748,7 @@ int generic_file_readonly_mmap(struct file *file, struct 
vm_area_struct *vma)
return generic_file_mmap(file, vma);
 }
 #else
-int filemap_page_mkwrite(struct vm_fault *vmf)
+vm_fault_t filemap_page_mkwrite(struct vm_fault *vmf)
 {
return -ENOSYS;
 }
-- 
2.17.0

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

[PATCH 04/14] mm: remove the unused device_private_entry_fault export

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 kernel/memremap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/memremap.c b/kernel/memremap.c
index db4e1a373e5f..59ee3b604b39 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -65,7 +65,6 @@ int device_private_entry_fault(struct vm_area_struct *vma,
 */
return page->pgmap->page_fault(vma, addr, page, flags, pmdp);
 }
-EXPORT_SYMBOL(device_private_entry_fault);
 #endif /* CONFIG_DEVICE_PRIVATE */
 
 static void pgmap_radix_release(struct resource *res, unsigned long end_pgoff)
-- 
2.17.0

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

vm_fault_t conversion, for real

[Christoph Hellwig]

Hi all,

this series tries to actually turn vm_fault_t into a type that can be
typechecked and checks the fallout instead of sprinkling random
annotations without context.

The first one fixes a real bug in orangefs, the second and third fix
mismatched existing vm_fault_t annotations on the same function, the
fourth removes an unused export that was in the chain.  The remainder
until the last one do some not quite trivial conversions, and the last
one does the trivial mass annotation and flips vm_fault_t to a __bitwise
unsigned int - the unsigned means we also get plain compiler type
checking for the new ->fault signature even without sparse.

This has survived an x86 allyesconfig build, and got a SUCCESS from the
buildbot that I don't really trust - I'm pretty sure there are bits
and pieces hiding in other architectures that it hasn't caught up to.

The sparse annotations are manuall verified for the core MM code and
a few other interesting bits (e.g. DAX and the x86 fault code)

The series is against linux-next as of 2018/05/15 to make sure any
annotations in subsystem trees are picked up.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

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

--- Comment #2 from Roland Scheidegger  ---
I suppose it crashes in the jit-compiled code (debug symbols should help with
identifying that, but not help any further if that's the case).
Can you print out the faulting instruction (gdb x/i address or so)?
Also, if that would be some SSE instruction, try to see if the memory operand
is aligned (or just not addressable).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Grodzovsky, Andrey]

Yeah, that what I am not sure about... It's lockless in a sense of single 
producer single consumer but not for multiple concurrent producers... So now I 
think this spinlock should stay there... It just looked useless to me at first 
sight...

Andrey


From: Zhou, David(ChunMing)
Sent: 15 May 2018 23:04:44
To: Grodzovsky, Andrey; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian
Subject: Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.



On 2018年05月16日 03:31, Andrey Grodzovsky wrote:
> Signed-off-by: Andrey Grodzovsky 
> ---
>   drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
>   include/drm/gpu_scheduler.h   | 1 -
>   2 files changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 1f1dd70..2569a63 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -140,7 +140,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
>   entity->last_scheduled = NULL;
>
>   spin_lock_init(>rq_lock);
> - spin_lock_init(>queue_lock);
>   spsc_queue_init(>job_queue);
>
>   atomic_set(>fence_seq, 0);
> @@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct drm_sched_job 
> *sched_job,
>
>   trace_drm_sched_job(sched_job, entity);
>
> - spin_lock(>queue_lock);
>   first = spsc_queue_push(>job_queue, _job->queue_node);
>
> - spin_unlock(>queue_lock);
Is your spsc safely to be added simultaneously?

Regards,
David Zhou
> -
>   /* first job wakes up scheduler */
>   if (first) {
>   /* Add the entity to the run queue */
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 350a62c..683eb65 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -56,7 +56,6 @@ struct drm_sched_entity {
>   spinlock_t  rq_lock;
>   struct drm_gpu_scheduler*sched;
>
> - spinlock_t  queue_lock;
>   struct spsc_queue   job_queue;
>
>   atomic_tfence_seq;

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

[PATCH 3/3] drm/vkms: Add extra information about vkms

[Rodrigo Siqueira]

Add the following additional information: authors and description in
Kconfig.

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/Kconfig | 8 ++--
 drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0893b1d8ede7..a16efdea00fa 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -213,10 +213,14 @@ config DRM_VGEM
  If M is selected the module will be called vgem.
 
 config DRM_VKMS
-   tristate "Virtual KMS"
+   tristate "Virtual KMS (EXPERIMENTAL)"
depends on DRM
+   default n
help
- Choose this option to get a virtual kernal mode-setting driver.
+ Virtual Kernel Mode-Setting (VKMS) is used for testing or for
+ running GPU in a headless machines. Choose this option to get
+ a VKMS.
+
  If M is selected the module will be called vkms.
 
 source "drivers/gpu/drm/exynos/Kconfig"
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 11e0569807bd..07f53f095562 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -105,5 +105,7 @@ static void __exit vkms_exit(void)
 module_init(vkms_init);
 module_exit(vkms_exit);
 
+MODULE_AUTHOR("Haneen Mohammed ");
+MODULE_AUTHOR("Rodrigo Siqueira ");
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
-- 
2.17.0

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

[PATCH 1/3] drm/vkms: Add basic CRTC initialization

[Rodrigo Siqueira]

This commit adds the essential infrastructure for managing CRTCs which
is composed of: a new data struct for output data information, a
function for basic modeset initialization, and the operation to create
planes. Due to the introduction of a new initialization function,
connectors were moved from vkms_drv.c to vkms_display.c.

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vkms/Makefile   |   2 +-
 drivers/gpu/drm/vkms/vkms_display.c | 108 
 drivers/gpu/drm/vkms/vkms_drv.c |  41 +--
 drivers/gpu/drm/vkms/vkms_drv.h |  26 ++-
 drivers/gpu/drm/vkms/vkms_plane.c   |  46 
 5 files changed, 180 insertions(+), 43 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_display.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c

diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 2aef948d3a34..f747e2a3a6f4 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -1,3 +1,3 @@
-vkms-y := vkms_drv.o
+vkms-y := vkms_drv.o vkms_plane.o vkms_display.o
 
 obj-$(CONFIG_DRM_VKMS) += vkms.o
diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
b/drivers/gpu/drm/vkms/vkms_display.c
new file mode 100644
index ..b20b41f9590b
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_display.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "vkms_drv.h"
+#include 
+#include 
+
+#define XRES_MIN32
+#define YRES_MIN32
+
+#define XRES_DEF  1024
+#define YRES_DEF   768
+
+#define XRES_MAX  8192
+#define YRES_MAX  8192
+
+static const struct drm_mode_config_funcs vkms_mode_funcs = {
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+static const struct drm_crtc_funcs vkms_crtc_funcs = {
+   .set_config = drm_atomic_helper_set_config,
+   .destroy= drm_crtc_cleanup,
+   .page_flip  = drm_atomic_helper_page_flip,
+   .reset  = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
+};
+
+static void vkms_connector_destroy(struct drm_connector *connector)
+{
+   drm_connector_unregister(connector);
+   drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs vkms_connector_funcs = {
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = vkms_connector_destroy,
+};
+
+static int vkms_output_init(struct vkms_device *vkmsdev)
+{
+   struct vkms_output *output = >output;
+   struct drm_device *dev = >drm;
+   struct drm_connector *connector = >connector;
+   struct drm_crtc *crtc = >crtc;
+   struct drm_plane *primary;
+   int ret;
+
+   primary = vkms_plane_init(vkmsdev);
+   if (IS_ERR(primary))
+   return PTR_ERR(primary);
+
+   ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL,
+   _crtc_funcs, NULL);
+   if (ret) {
+   DRM_ERROR("Failed to init CRTC\n");
+   goto err_crtc;
+   }
+   primary->crtc = crtc;
+
+   ret = drm_connector_init(dev, connector, _connector_funcs,
+DRM_MODE_CONNECTOR_VIRTUAL);
+   if (ret) {
+   DRM_ERROR("Failed to init connector\n");
+   goto err_connector;
+   }
+
+   ret = drm_connector_register(connector);
+   if (ret) {
+   DRM_ERROR("Failed to register connector\n");
+   goto err_connector_register;
+   }
+
+   drm_mode_config_reset(dev);
+
+   return 0;
+
+err_connector_register:
+   drm_connector_cleanup(connector);
+
+err_connector:
+   drm_crtc_cleanup(crtc);
+
+err_crtc:
+   drm_plane_cleanup(primary);
+   return ret;
+}
+
+int vkms_modeset_init(struct vkms_device *vkmsdev)
+{
+   struct drm_device *dev = >drm;
+
+   drm_mode_config_init(dev);
+   dev->mode_config.funcs = _mode_funcs;
+   dev->mode_config.min_width = XRES_MIN;
+   dev->mode_config.min_height = YRES_MIN;
+   dev->mode_config.max_width = XRES_MAX;
+   dev->mode_config.max_height = YRES_MAX;
+
+   return vkms_output_init(vkmsdev);
+}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 35517b09538e..11e0569807bd 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -6,9 +6,7 @@
  */
 
 #include 
-#include 
 #include 
-#include 
 #include "vkms_drv.h"
 
 #define DRIVER_NAME"vkms"
@@ -52,21 +50,6 @@ static struct drm_driver vkms_driver = {
   

[PATCH 0/3] Expanding the basic vkms features

[Rodrigo Siqueira]

This series of patches add a centralized initialization mechanism, a
single CRTC with a plane, an encoder, and extra module information. 

Rodrigo Siqueira (3):
  drm/vkms: Add basic CRTC initialization
  drm/vkms: Add encoder initialization
  drm/vkms: Add extra information about vkms

 drivers/gpu/drm/Kconfig |   8 +-
 drivers/gpu/drm/vkms/Makefile   |   2 +-
 drivers/gpu/drm/vkms/vkms_display.c | 133 
 drivers/gpu/drm/vkms/vkms_drv.c |  43 +
 drivers/gpu/drm/vkms/vkms_drv.h |  28 +-
 drivers/gpu/drm/vkms/vkms_plane.c   |  46 ++
 6 files changed, 215 insertions(+), 45 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_display.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c

-- 
2.17.0

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

[PATCH 2/3] drm/vkms: Add encoder initialization

[Rodrigo Siqueira]

This commit adds a single and simple virtual encoder to VKMS.

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vkms/vkms_display.c | 25 +
 drivers/gpu/drm/vkms/vkms_drv.h |  2 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
b/drivers/gpu/drm/vkms/vkms_display.c
index b20b41f9590b..d6702128b5f7 100644
--- a/drivers/gpu/drm/vkms/vkms_display.c
+++ b/drivers/gpu/drm/vkms/vkms_display.c
@@ -44,11 +44,16 @@ static const struct drm_connector_funcs 
vkms_connector_funcs = {
.destroy = vkms_connector_destroy,
 };
 
+static const struct drm_encoder_funcs vkms_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
 static int vkms_output_init(struct vkms_device *vkmsdev)
 {
struct vkms_output *output = >output;
struct drm_device *dev = >drm;
struct drm_connector *connector = >connector;
+   struct drm_encoder *encoder = >encoder;
struct drm_crtc *crtc = >crtc;
struct drm_plane *primary;
int ret;
@@ -78,10 +83,30 @@ static int vkms_output_init(struct vkms_device *vkmsdev)
goto err_connector_register;
}
 
+   ret = drm_encoder_init(dev, encoder, _encoder_funcs,
+  DRM_MODE_ENCODER_VIRTUAL, NULL);
+   if (ret) {
+   DRM_ERROR("Failed to init encoder\n");
+   goto err_encoder;
+   }
+   encoder->possible_crtcs = 1;
+
+   ret = drm_mode_connector_attach_encoder(connector, encoder);
+   if (ret) {
+   DRM_ERROR("Failed to attach connector to encoder\n");
+   goto err_attach;
+   }
+
drm_mode_config_reset(dev);
 
return 0;
 
+err_attach:
+   drm_encoder_cleanup(encoder);
+
+err_encoder:
+   drm_connector_unregister(connector);
+
 err_connector_register:
drm_connector_cleanup(connector);
 
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 292bdea9c785..933eedc5b25b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 static const u32 vkms_formats[] = {
DRM_FORMAT_XRGB,
@@ -17,6 +18,7 @@ static const u32 vkms_formats[] = {
 
 struct vkms_output {
struct drm_crtc crtc;
+   struct drm_encoder encoder;
struct drm_connector connector;
 };
 
-- 
2.17.0

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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[zhoucm1]

On 2018年05月16日 03:31, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
  include/drm/gpu_scheduler.h   | 1 -
  2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
entity->last_scheduled = NULL;
  
  	spin_lock_init(>rq_lock);

-   spin_lock_init(>queue_lock);
spsc_queue_init(>job_queue);
  
  	atomic_set(>fence_seq, 0);

@@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct drm_sched_job 
*sched_job,
  
  	trace_drm_sched_job(sched_job, entity);
  
-	spin_lock(>queue_lock);

first = spsc_queue_push(>job_queue, _job->queue_node);
  
-	spin_unlock(>queue_lock);

Is your spsc safely to be added simultaneously?

Regards,
David Zhou

-
/* first job wakes up scheduler */
if (first) {
/* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
spinlock_t  rq_lock;
struct drm_gpu_scheduler*sched;
  
-	spinlock_t			queue_lock;

struct spsc_queue   job_queue;
  
  	atomic_t			fence_seq;


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

[Bug 101003] segfault with ideas test of glmark2

[bugzilla-daemon]

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

--- Comment #6 from Anthony Ciani  ---
Ditto.  Branches 17.2, 17.3 and 18.0 up to 18.0.3.

hardware is a 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices,
Inc. [AMD/ATI] RS482M [Mobility Radeon Xpress 200] [1002:5975]

Stack trace is the same, abbreviated for glmark2 -b ideas:
#0  0x7fdff96f3bb5 refill_pool (r300_dri.so)
#1  0x7fdff970971e rc_alloc_instruction (r300_dri.so)
#2  0x7fdff9701168 unroll_loop (r300_dri.so)
#3  0x7fdff97018cc rc_emulate_loops (r300_dri.so)
#4  0x7fdff96fcdd5 rc_run_compiler_passes (r300_dri.so)
#5  0x7fdff96fce85 rc_run_compiler (r300_dri.so)
#6  0x7fdff96f635c r3xx_compile_fragment_program (r300_dri.so)
#7  0x7fdff96e1aaf r300_translate_fragment_shader (r300_dri.so)
#8  0x7fdff96e291d r300_pick_fragment_shader (r300_dri.so)
#9  0x7fdff96ec8ef r300_validate_fragment_shader (r300_dri.so)
#10 0x7fdff96e355a r300_swtcl_draw_vbo (r300_dri.so)
#11 0x7fdff93156ef st_draw_vbo (r300_dri.so)
#12 0x7fdff92d8608 vbo_validated_drawrangeelements (r300_dri.so)
#13 0x7fdff92d8d7f vbo_exec_DrawElements (r300_dri.so)
#14 0x00455fde _ZN4Lamp4drawERN9LibMatrix6Stack4ES2_PKNS0_5tvec4IfEE
(glmark2)
#15 0x0047acba _ZN17SceneIdeasPrivate4drawEv (glmark2)
#16 0x0040efd1 _ZN8MainLoop4drawEv (glmark2)
#17 0x0040f76c _ZN8MainLoop4stepEv (glmark2)
#18 0x004110e0 _Z12do_benchmarkR6Canvas (glmark2)
#19 0x00406c80 main (glmark2)
#20 0x7fdffd2d8f2a __libc_start_main (libc.so.6)
#21 0x00408769 _start (glmark2)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

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

--- Comment #1 from Anthony Ciani  ---
Error occurs on two identical Dell Inspiron 1501's, one with 3GB of memory and
the other with 4GB.

00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI]
RS480/RS482/RS485 Host Bridge [1002:5950] (rev 10)
00:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx
PCI Bridge [int gfx] [1002:5a3f]
00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx
PCI Express Port 2 [1002:5a37]
00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx
PCI Express Port 3 [1002:5a38]
00:12.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB600
Non-Raid-5 SATA [1002:4380]
00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI0) [1002:4387]
00:13.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI1) [1002:4388]
00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI2) [1002:4389]
00:13.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI3) [1002:438a]
00:13.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI4) [1002:438b]
00:13.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
Controller (EHCI) [1002:4386]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus
Controller [1002:4385] (rev 14)
00:14.1 IDE interface [0101]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 IDE
[1002:438c]
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00
Azalia (Intel HDA) [1002:4383]
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 PCI to
LPC Bridge [1002:438d]
00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to
PCI Bridge [1002:4384]
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] RS482M [Mobility Radeon Xpress 200] [1002:5975]
05:00.0 Network controller [0280]: Broadcom Limited BCM4311 802.11b/g WLAN
[14e4:4311] (rev 01)
08:00.0 Ethernet controller [0200]: Broadcom Limited BCM4401-B0 100Base-TX
[14e4:170c] (rev 02)
08:01.0 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter [1180:0822] (rev 19)
08:01.1 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller
[1180:0843] (rev 01)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

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

Bug ID: 106533
   Summary: r300_dri.so SIGSEGV in llvm_pipeline_generic under
Cinnamon
   Product: Mesa
   Version: 18.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r300
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: anthonyjci...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Cinnamon issues SIGSEGV in (unknown function after) llvm_pipeline_generic.

Stack trace of thread 1400:
#0  0x7f5442209333 n/a (n/a)
#1  0x7f54554f7ed3 llvm_pipeline_generic (r300_dri.so)
#2  0x7f54554f83af llvm_middle_end_linear_run (r300_dri.so)
#3  0x7f5455415a54 vsplit_segment_simple_linear (r300_dri.so)
#4  0x7f545540e858 draw_pt_arrays (r300_dri.so)
#5  0x7f545540eca5 draw_vbo (r300_dri.so)
#6  0x7f5455636569 r300_swtcl_draw_vbo (r300_dri.so)
#7  0x7f54553fd6b7 cso_draw_arrays (r300_dri.so)
#8  0x7f5455268c31 st_draw_quad (r300_dri.so)
#9  0x7f5455252ff5 clear_with_quad (r300_dri.so)
#10 0x7f547287d224 _cogl_framebuffer_gl_clear (libcogl.so.20)
#11 0x7f54728c28da cogl_framebuffer_clear4f (libcogl.so.20)
#12 0x7f5472fe283c _clutter_stage_do_pick (libclutter-1.0.so.0)
#13 0x7f5472fbf3b9 _clutter_input_device_update (libclutter-1.0.so.0)
#14 0x7f5472fc801c _clutter_process_event (libclutter-1.0.so.0)
#15 0x7f5472fde940 _clutter_stage_process_queued_events
(libclutter-1.0.so.0)
#16 0x7f5472fca439 clutter_clock_dispatch (libclutter-1.0.so.0)
#17 0x7f546d9bab77 g_main_context_dispatch (libglib-2.0.so.0)
#18 0x7f546d9baf20 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#19 0x7f546d9bb232 g_main_loop_run (libglib-2.0.so.0)
#20 0x7f547539fe2c meta_run (libmuffin.so.0)
#21 0x55640d5edce0 main (cinnamon)
#22 0x7f546d3bcf2a __libc_start_main (libc.so.6)
#23 0x55640d5eddda _start (cinnamon)

Stack trace of thread 1405:
#0  0x7f546d486c6b __poll (libc.so.6)
#1  0x7f546d9bae99 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#2  0x7f546d9bafac g_main_context_iteration (libglib-2.0.so.0)
#3  0x7f546d9baff1 glib_worker_main (libglib-2.0.so.0)
#4  0x7f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x7f546d75950b start_thread (libpthread.so.0)
#6  0x7f546d49116f __clone (libc.so.6)

Stack trace of thread 1406:
#0  0x7f546d486c6b __poll (libc.so.6)
#1  0x7f546d9bae99 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#2  0x7f546d9bb232 g_main_loop_run (libglib-2.0.so.0)
#3  0x7f546dfa3b56 gdbus_shared_thread_func (libgio-2.0.so.0)
#4  0x7f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x7f546d75950b start_thread (libpthread.so.0)
#6  0x7f546d49116f __clone (libc.so.6)

Stack trace of thread 1407:
#0  0x7f546d486c6b __poll (libc.so.6)
#1  0x7f546d9bae99 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#2  0x7f546d9bafac g_main_context_iteration (libglib-2.0.so.0)
#3  0x7f545417042d dconf_gdbus_worker_thread (libdconfsettings.so)
#4  0x7f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x7f546d75950b start_thread (libpthread.so.0)
#6  0x7f546d49116f __clone (libc.so.6)

Stack trace of thread 1408:
#0  0x7f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x7f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x7f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x7f546892e06b _pt_root (libnspr4.so)
#4  0x7f546d75950b start_thread (libpthread.so.0)
#5  0x7f546d49116f __clone (libc.so.6)

Stack trace of thread 1409:
#0  0x7f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x7f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x7f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x7f546892e06b _pt_root (libnspr4.so)
#4  0x7f546d75950b start_thread (libpthread.so.0)
#5  0x7f546d49116f __clone (libc.so.6)

Stack trace of thread 1410:
#0  0x7f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x7f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x7f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x7f546892e06b _pt_root (libnspr4.so)
#4  0x7f546d75950b start_thread (libpthread.so.0)
#5  0x7f546d49116f __clone (libc.so.6)

Stack trace of thread 1411:
#0  0x7f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x7f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x7f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x7f546892e06b _pt_root (libnspr4.so)
#4  0x7f546d75950b start_thread (libpthread.so.0)
#5  0x7f546d49116f __clone (libc.so.6)

Stack trace of thread 1412:
#0  0x7f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x7f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  

Re: [Intel-gfx] [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

[kbuild test robot]

Hi Neil,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.17-rc5 next-20180515]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Neil-Armstrong/Add-ChromeOS-EC-CEC-Support/20180516-053811
base:   git://linuxtv.org/media_tree.git master
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   drivers/media/platform/cros-ec-cec/cros-ec-cec.c: In function 
'cros_ec_cec_get_notifier':
>> drivers/media/platform/cros-ec-cec/cros-ec-cec.c:232:33: error: 
>> 'pci_bus_type' undeclared (first use in this function); did you mean 
>> 'pci_pcie_type'?
   d = bus_find_device_by_name(_bus_type, NULL,
^~~~
pci_pcie_type
   drivers/media/platform/cros-ec-cec/cros-ec-cec.c:232:33: note: each 
undeclared identifier is reported only once for each function it appears in

vim +232 drivers/media/platform/cros-ec-cec/cros-ec-cec.c

   218  
   219  static int cros_ec_cec_get_notifier(struct device *dev,
   220  struct cec_notifier **notify)
   221  {
   222  int i;
   223  
   224  for (i = 0 ; i < ARRAY_SIZE(cec_dmi_match_table) ; ++i) {
   225  const struct cec_dmi_match *m = _dmi_match_table[i];
   226  
   227  if (dmi_match(DMI_SYS_VENDOR, m->sys_vendor) &&
   228  dmi_match(DMI_PRODUCT_NAME, m->product_name)) {
   229  struct device *d;
   230  
   231  /* Find the device, bail out if not yet 
registered */
 > 232  d = bus_find_device_by_name(_bus_type, NULL,
   233  m->devname);
   234  if (!d)
   235  return -EPROBE_DEFER;
   236  
   237  *notify = cec_notifier_get_conn(d, m->conn);
   238  return 0;
   239  }
   240  }
   241  
   242  /* Hardware support must be added in the cec_dmi_match_table */
   243  dev_warn(dev, "CEC notifier not configured for this 
hardware\n");
   244  
   245  return -ENODEV;
   246  }
   247  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106531] Age of Wonders 3 rendering failure on 18.1.0-rc

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
I believe it's related to  GL 3.1 compat being exposed. Oddly using 
MESA_GL_VERSION_OVERRIDE=3.1COMPAT fixes the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [kbuild-all] [RFC PATCH] drm/vkms: vkms_driver can be static

[Li, Philip]

> Subject: Re: [kbuild-all] [RFC PATCH] drm/vkms: vkms_driver can be static
> 
> On Tue, May 15, 2018 at 07:30:52PM +0800, kbuild test robot wrote:
> >
> > Fixes: 58d8108f080c ("drm/vkms: Introduce basic VKMS driver")
> > Signed-off-by: Fengguang Wu 
> 
> One thing I noticed while applying this: Your author (as recorded in the
> From: line) and your s-o-b don't match. Now I know that you're behind
> 0day, so it's ok, but our script gets annoyed and I need to overrule it
> with an -f flag.
> 
> Can you perhaps get the From: and S-o-b: lines into agreement so that a
> simple comparison works?
thanks for input, we the bot team has decided to use uniform From with the
address lkp recently, while the auto generated script is still using specific 
author's
signed-off-by.

> 
> Thanks, Daniel
> 
> > ---
> >  vkms_drv.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> b/drivers/gpu/drm/vkms/vkms_drv.c
> > index b1df08e..35517b09 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -40,7 +40,7 @@ static void vkms_release(struct drm_device *dev)
> > drm_dev_fini(>drm);
> >  }
> >
> > -struct drm_driver vkms_driver = {
> > +static struct drm_driver vkms_driver = {
> > .driver_features= DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_GEM,
> > .release= vkms_release,
> > .fops   = _driver_fops,
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> kbuild-all mailing list
> kbuild-...@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: Signed-off-by missing for commits in the drm tree

[Stephen Rothwell]

Hi all,

Commits

  f412e8307d0a ("drm/amd/display: Couple bug fixes in stats module")
  e09b6473c605 ("drm/amd/display: Rename encoder_info_packet to dc_info_packet")
  87943159f409 ("drm/amd/display: Only program MSA_TIMING_PARAM if it changed")

are missing a Signed-off-by from their author.

-- 
Cheers,
Stephen Rothwell


pgpZem5nh28Ft.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106531] Age of Wonders 3 rendering failure on 18.1.0-rc

[bugzilla-daemon]

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

Bug ID: 106531
   Summary: Age of Wonders 3 rendering failure on 18.1.0-rc
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jo...@lunarg.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 139582
  --> https://bugs.freedesktop.org/attachment.cgi?id=139582=edit
Picture of Age Of Wonders 3 rendering problem on 18.1.0-rc's

NOTE: This is for the 18.1 branch for the current RC's, you can reproduce this
bug on the radeonsi driver using the git tag 'mesa-18.1.0-rc4'. This bug has
NOT been replicated on the 18.0 branch.

Overview:
Age of Wonders 3 game displays large white squares on menu screen. No buttons
are available in menu screen. 

Steps To Reproduce:
Fire up Age of Wonders 3 in steam using radeonsi driver on 18.1.0-rc* releases.
The problem should present itself in the menu of the game.

Hardware: 
R9280, RX480, and R9Fury have this problem.

Builds:
This bug has been seen on Mesa RC's of 18.1.0 

Attached is a screenshot of the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [gabbayo:amdkfd-next 6/28] drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit declaration of function 'release_pages'; did you mean 'release_task'?

[Felix Kuehling]

We need to #include .


On 2018-05-15 09:44 AM, kbuild test robot wrote:
> tree:   git://people.freedesktop.org/~gabbayo/linux amdkfd-next
> head:   8feaccf71dd61f2201493068055e0d1d699014df
> commit: 5ae0283e831a94c714fce61063e4724baf364ef3 [6/28] drm/amdgpu: Add 
> userptr support for KFD
> config: sparc64-allmodconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 5ae0283e831a94c714fce61063e4724baf364ef3
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64 
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
> 'init_user_pages':
>>> drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit 
>>> declaration of function 'release_pages'; did you mean 'release_task'? 
>>> [-Werror=implicit-function-declaration]
>   release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>   ^
>   release_task
>cc1: some warnings being treated as errors
>
> vim +632 drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>
>561
>562/* Initializes user pages. It registers the MMU notifier and 
> validates
>563 * the userptr BO in the GTT domain.
>564 *
>565 * The BO must already be on the userptr_valid_list. Otherwise 
> an
>566 * eviction and restore may happen that leaves the new BO 
> unmapped
>567 * with the user mode queues running.
>568 *
>569 * Takes the process_info->lock to protect against concurrent 
> restore
>570 * workers.
>571 *
>572 * Returns 0 for success, negative errno for errors.
>573 */
>574static int init_user_pages(struct kgd_mem *mem, struct 
> mm_struct *mm,
>575   uint64_t user_addr)
>576{
>577struct amdkfd_process_info *process_info = 
> mem->process_info;
>578struct amdgpu_bo *bo = mem->bo;
>579struct ttm_operation_ctx ctx = { true, false };
>580int ret = 0;
>581
>582mutex_lock(_info->lock);
>583
>584ret = amdgpu_ttm_tt_set_userptr(bo->tbo.ttm, user_addr, 
> 0);
>585if (ret) {
>586pr_err("%s: Failed to set userptr: %d\n", 
> __func__, ret);
>587goto out;
>588}
>589
>590ret = amdgpu_mn_register(bo, user_addr);
>591if (ret) {
>592pr_err("%s: Failed to register MMU notifier: 
> %d\n",
>593   __func__, ret);
>594goto out;
>595}
>596
>597/* If no restore worker is running concurrently, 
> user_pages
>598 * should not be allocated
>599 */
>600WARN(mem->user_pages, "Leaking user_pages array");
>601
>602mem->user_pages = kvmalloc_array(bo->tbo.ttm->num_pages,
>603   sizeof(struct page 
> *),
>604   GFP_KERNEL | 
> __GFP_ZERO);
>605if (!mem->user_pages) {
>606pr_err("%s: Failed to allocate pages array\n", 
> __func__);
>607ret = -ENOMEM;
>608goto unregister_out;
>609}
>610
>611ret = amdgpu_ttm_tt_get_user_pages(bo->tbo.ttm, 
> mem->user_pages);
>612if (ret) {
>613pr_err("%s: Failed to get user pages: %d\n", 
> __func__, ret);
>614goto free_out;
>615}
>616
>617amdgpu_ttm_tt_set_user_pages(bo->tbo.ttm, 
> mem->user_pages);
>618
>619ret = amdgpu_bo_reserve(bo, true);
>620if (ret) {
>621pr_err("%s: Failed to reserve BO\n", __func__);
>622goto release_out;
>623}
>624amdgpu_ttm_placement_from_domain(bo, mem->domain);
>625ret = ttm_bo_validate(>tbo, >placement, );
>626if (ret)
>627pr_err("%s: failed to validate BO\n", __func__);
>628amdgpu_bo_unreserve(bo);
>629
>630release_out:
>631if (ret)
>  > 632release_pages(mem->user_pages, 
> bo->tbo.ttm->num_pages);
>

Re: [PATCH 3/3] drm/tinydrm: new driver for ILI9341 display panels

[Andy Shevchenko]

On Tue, May 15, 2018 at 4:43 AM, David Lechner  wrote:
> This adds a new driver for display panels that use the Ilitek ILI9341
> controller. It currently supports a single display panel, namely
> the YX240QV29-T (e.g. Adafruit 2.4" TFT).
>
> The init sequence is from the Adafruit Python library for the ILI9341
> controller. https://github.com/adafruit/Adafruit_Python_ILI9341

Some minor style nitpicks, otherwise LGTM

Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: David Lechner 
> ---
>  MAINTAINERS   |   6 +
>  drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
>  drivers/gpu/drm/tinydrm/Makefile  |   1 +
>  drivers/gpu/drm/tinydrm/ili9341.c | 239 ++
>  4 files changed, 256 insertions(+)
>  create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bc219de9cbee..ffa099abbd79 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4480,6 +4480,12 @@ S:   Maintained
>  F: drivers/gpu/drm/tinydrm/ili9225.c
>  F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
>
> +DRM DRIVER FOR ILITEK ILI9341 PANELS
> +M: David Lechner 
> +S: Maintained
> +F: drivers/gpu/drm/tinydrm/ili9341.c
> +F: Documentation/devicetree/bindings/display/ilitek,ili9341.txt
> +
>  DRM DRIVER FOR INTEL I810 VIDEO CARDS
>  S: Orphan / Obsolete
>  F: drivers/gpu/drm/i810/
> diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
> index 4592a5e3f20b..7a8008b0783f 100644
> --- a/drivers/gpu/drm/tinydrm/Kconfig
> +++ b/drivers/gpu/drm/tinydrm/Kconfig
> @@ -20,6 +20,16 @@ config TINYDRM_ILI9225
>
>   If M is selected the module will be called ili9225.
>
> +config TINYDRM_ILI9341
> +   tristate "DRM support for ILI9341 display panels"

> +   depends on DRM_TINYDRM && SPI

Can't we do something like

if SPI

...

endif

?

> +   select TINYDRM_MIPI_DBI
> +   help
> + DRM driver for the following Ilitek ILI9341 panels:
> + * YX240QV29-T 2.4" 240x320 TFT (Adafruit 2.4")
> +
> + If M is selected the module will be called ili9341.
> +
>  config TINYDRM_MI0283QT
> tristate "DRM support for MI0283QT"
> depends on DRM_TINYDRM && SPI
> diff --git a/drivers/gpu/drm/tinydrm/Makefile 
> b/drivers/gpu/drm/tinydrm/Makefile
> index 49a111929724..14d99080665a 100644
> --- a/drivers/gpu/drm/tinydrm/Makefile
> +++ b/drivers/gpu/drm/tinydrm/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)  += mipi-dbi.o
>
>  # Displays
>  obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
> +obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
>  obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
>  obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
>  obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
> diff --git a/drivers/gpu/drm/tinydrm/ili9341.c 
> b/drivers/gpu/drm/tinydrm/ili9341.c
> new file mode 100644
> index ..2ce4244a68c3
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/ili9341.c
> @@ -0,0 +1,239 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DRM driver for Ilitek ILI9341 panels
> + *
> + * Copyright 2018 David Lechner 
> + *
> + * Based on mi0283qt.c:
> + * Copyright 2016 Noralf Trønnes
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

> +#include 
> +#include 

Can it be in order?

> +#include 
> +#include 
> +#include 
> +
> +#define ILI9341_FRMCTR10xb1
> +#define ILI9341_DISCTRL0xb6
> +#define ILI9341_ETMOD  0xb7
> +
> +#define ILI9341_PWCTRL10xc0
> +#define ILI9341_PWCTRL20xc1
> +#define ILI9341_VMCTRL10xc5
> +#define ILI9341_VMCTRL20xc7
> +#define ILI9341_PWCTRLA0xcb
> +#define ILI9341_PWCTRLB0xcf
> +
> +#define ILI9341_PGAMCTRL   0xe0
> +#define ILI9341_NGAMCTRL   0xe1
> +#define ILI9341_DTCTRLA0xe8
> +#define ILI9341_DTCTRLB0xea
> +#define ILI9341_PWRSEQ 0xed
> +
> +#define ILI9341_EN3GAM 0xf2
> +#define ILI9341_PUMPCTRL   0xf7
> +
> +#define ILI9341_MADCTL_BGR BIT(3)
> +#define ILI9341_MADCTL_MV  BIT(5)
> +#define ILI9341_MADCTL_MX  BIT(6)
> +#define ILI9341_MADCTL_MY  BIT(7)
> +
> +static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
> +struct drm_crtc_state *crtc_state,
> +struct drm_plane_state *plane_state)
> +{
> +   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
> +   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
> +   u8 addr_mode;
> +   int ret;
> +
> +   DRM_DEBUG_KMS("\n");
> +
> +   ret = mipi_dbi_poweron_conditional_reset(mipi);
> +   if (ret < 0)
> +   return;
> +   if (ret == 

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #9 from mikhail.v.gavri...@gmail.com ---
(In reply to mikhail.v.gavrilov from comment #8)
> Created attachment 139581 [details]
> mpv verbose info for h264

[vd] Using software decoding.
Also hardware acceleration not used for h264 why?

$ gst-inspect-1.0 vaapi
Plugin Details:
  Name vaapi
  Description  VA-API based elements
  Filename /usr/lib64/gstreamer-1.0/libgstvaapi.so
  Version  1.14.0
  License  LGPL
  Source modulegstreamer-vaapi
  Source release date  2018-03-19
  Binary package   gstreamer-vaapi
  Origin URL  
http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer

  vaapimpeg2dec: VA-API MPEG2 decoder
  vaapih264dec: VA-API H264 decoder
  vaapivc1dec: VA-API VC1 decoder
  vaapih265dec: VA-API H265 decoder
  vaapipostproc: VA-API video postprocessing
  vaapidecodebin: VA-API Decode Bin
  vaapisink: VA-API sink
  vaapih265enc: VA-API H265 encoder
  vaapih264enc: VA-API H264 encoder

  9 features:
  +-- 9 elements

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #8 from mikhail.v.gavri...@gmail.com ---
Created attachment 139581
  --> https://bugs.freedesktop.org/attachment.cgi?id=139581=edit
mpv verbose info for h264

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #7 from mikhail.v.gavri...@gmail.com ---
(In reply to mikhail.v.gavrilov from comment #6)
> Created attachment 139580 [details]
> mpv verbose info

[vd] Using software decoding.
looks like hardware acceleration not used when playing VP9 video it's pity.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #6 from mikhail.v.gavri...@gmail.com ---
Created attachment 139580
  --> https://bugs.freedesktop.org/attachment.cgi?id=139580=edit
mpv verbose info

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [radeon-alex:amd-staging-drm-next 62/63] drivers/gpu/drm/amd/amdgpu/soc15.c:686:3-24: duplicated argument to & or |

[Julia Lawall]

Lines 686 and 688 seem to contain the same constant.

julia

On Wed, 16 May 2018, kbuild test robot wrote:

> CC: kbuild-...@01.org
> CC: dri-devel@lists.freedesktop.org
> TO: Alex Deucher 
>
> tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
> head:   dbf4f8b16fdef588f3d95fbb6d726dfe9663119b
> commit: 8251a44fae1ecc447975c442d4e0b5d6cf715d34 [62/63] drm/amdgpu: flag 
> Vega20 as experimental
> :: branch date: 2 hours ago
> :: commit date: 2 hours ago
>
> >> drivers/gpu/drm/amd/amdgpu/soc15.c:686:3-24: duplicated argument to & or |
>
> git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
> git remote update radeon-alex
> git checkout 8251a44fae1ecc447975c442d4e0b5d6cf715d34
> vim +686 drivers/gpu/drm/amd/amdgpu/soc15.c
>
> 220ab9bd1 Ken Wang  2017-03-06  605
> 220ab9bd1 Ken Wang  2017-03-06  606  static int 
> soc15_common_early_init(void *handle)
> 220ab9bd1 Ken Wang  2017-03-06  607  {
> 220ab9bd1 Ken Wang  2017-03-06  608   struct amdgpu_device *adev = 
> (struct amdgpu_device *)handle;
> 220ab9bd1 Ken Wang  2017-03-06  609
> 220ab9bd1 Ken Wang  2017-03-06  610   adev->smc_rreg = NULL;
> 220ab9bd1 Ken Wang  2017-03-06  611   adev->smc_wreg = NULL;
> 220ab9bd1 Ken Wang  2017-03-06  612   adev->pcie_rreg = 
> _pcie_rreg;
> 220ab9bd1 Ken Wang  2017-03-06  613   adev->pcie_wreg = 
> _pcie_wreg;
> 220ab9bd1 Ken Wang  2017-03-06  614   adev->uvd_ctx_rreg = 
> _uvd_ctx_rreg;
> 220ab9bd1 Ken Wang  2017-03-06  615   adev->uvd_ctx_wreg = 
> _uvd_ctx_wreg;
> 220ab9bd1 Ken Wang  2017-03-06  616   adev->didt_rreg = 
> _didt_rreg;
> 220ab9bd1 Ken Wang  2017-03-06  617   adev->didt_wreg = 
> _didt_wreg;
> 560460f28 Evan Quan 2017-07-03  618   adev->gc_cac_rreg = 
> _gc_cac_rreg;
> 560460f28 Evan Quan 2017-07-03  619   adev->gc_cac_wreg = 
> _gc_cac_wreg;
> 2f11fb028 Evan Quan 2017-07-04  620   adev->se_cac_rreg = 
> _se_cac_rreg;
> 2f11fb028 Evan Quan 2017-07-04  621   adev->se_cac_wreg = 
> _se_cac_wreg;
> 220ab9bd1 Ken Wang  2017-03-06  622
> 220ab9bd1 Ken Wang  2017-03-06  623   adev->asic_funcs = 
> _asic_funcs;
> 220ab9bd1 Ken Wang  2017-03-06  624
> 220ab9bd1 Ken Wang  2017-03-06  625   adev->rev_id = 
> soc15_get_rev_id(adev);
> 220ab9bd1 Ken Wang  2017-03-06  626   adev->external_rev_id = 0xFF;
> 220ab9bd1 Ken Wang  2017-03-06  627   switch (adev->asic_type) {
> 220ab9bd1 Ken Wang  2017-03-06  628   case CHIP_VEGA10:
> 220ab9bd1 Ken Wang  2017-03-06  629   adev->cg_flags = 
> AMD_CG_SUPPORT_GFX_MGCG |
> 220ab9bd1 Ken Wang  2017-03-06  630   
> AMD_CG_SUPPORT_GFX_MGLS |
> 220ab9bd1 Ken Wang  2017-03-06  631   
> AMD_CG_SUPPORT_GFX_RLC_LS |
> 220ab9bd1 Ken Wang  2017-03-06  632   
> AMD_CG_SUPPORT_GFX_CP_LS |
> 220ab9bd1 Ken Wang  2017-03-06  633   
> AMD_CG_SUPPORT_GFX_3D_CGCG |
> 220ab9bd1 Ken Wang  2017-03-06  634   
> AMD_CG_SUPPORT_GFX_3D_CGLS |
> 220ab9bd1 Ken Wang  2017-03-06  635   
> AMD_CG_SUPPORT_GFX_CGCG |
> 220ab9bd1 Ken Wang  2017-03-06  636   
> AMD_CG_SUPPORT_GFX_CGLS |
> 220ab9bd1 Ken Wang  2017-03-06  637   
> AMD_CG_SUPPORT_BIF_MGCG |
> 220ab9bd1 Ken Wang  2017-03-06  638   
> AMD_CG_SUPPORT_BIF_LS |
> 220ab9bd1 Ken Wang  2017-03-06  639   
> AMD_CG_SUPPORT_HDP_LS |
> 220ab9bd1 Ken Wang  2017-03-06  640   
> AMD_CG_SUPPORT_DRM_MGCG |
> 220ab9bd1 Ken Wang  2017-03-06  641   
> AMD_CG_SUPPORT_DRM_LS |
> 220ab9bd1 Ken Wang  2017-03-06  642   
> AMD_CG_SUPPORT_ROM_MGCG |
> 220ab9bd1 Ken Wang  2017-03-06  643   
> AMD_CG_SUPPORT_DF_MGCG |
> 220ab9bd1 Ken Wang  2017-03-06  644   
> AMD_CG_SUPPORT_SDMA_MGCG |
> 220ab9bd1 Ken Wang  2017-03-06  645   
> AMD_CG_SUPPORT_SDMA_LS |
> 220ab9bd1 Ken Wang  2017-03-06  646   
> AMD_CG_SUPPORT_MC_MGCG |
> 220ab9bd1 Ken Wang  2017-03-06  647   
> AMD_CG_SUPPORT_MC_LS;
> 220ab9bd1 Ken Wang  2017-03-06  648   adev->pg_flags = 0;
> 220ab9bd1 Ken Wang  2017-03-06  649   adev->external_rev_id = 
> 0x1;
> 220ab9bd1 Ken Wang  2017-03-06  650   break;
> 692069a1a Alex Deucher  2018-03-06  651   case CHIP_VEGA12:
> e4a387558 Evan Quan 2017-12-25  652   adev->cg_flags = 
> AMD_CG_SUPPORT_GFX_MGCG |
> e4a387558 Evan Quan 2017-12-25  653   
> AMD_CG_SUPPORT_GFX_MGLS |
> e4a387558 Evan Quan 2017-12-25  654   
> AMD_CG_SUPPORT_GFX_CGCG |
> e4a387558 Evan Quan 2017-12-25  

Re: [RFC PATCH 07/10] clk: rockchip: set clk-ddr to GET_RATE_NOCACHE.

[Stephen Boyd]

Quoting Enric Balletbo i Serra (2018-05-14 14:16:07)
> From: Derek Basehore 
> 
> This adds the flag to the clk-ddr in rockchip to not use the cached
> rate for get_rate. This is to handle timeout error conditions in SMC
> for the set rate function.

We need some more information here. Why does timeout error condition in
set_rate() matter for get_rate()?

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

[Bug 106430] GPU hang when played video with acceleration (vaapi)

[bugzilla-daemon]

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

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
Created attachment 139579
  --> https://bugs.freedesktop.org/attachment.cgi?id=139579=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: checkpatch strict minor updates

[Philippe Cornu]

Minor fixes detected with "scripts/checkpatch.pl --strict"

Signed-off-by: Philippe Cornu 
---
Detected when merging "drm: clarify adjusted_mode documentation for bridges"

 include/drm/drm_bridge.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 9917651a7fdd..70131ab57e8f 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -97,7 +97,7 @@ struct drm_bridge_funcs {
/**
 * @mode_fixup:
 *
-* This callback is used to validate and adjust a mode. The paramater
+* This callback is used to validate and adjust a mode. The parameter
 * mode is the display mode that should be fed to the next element in
 * the display chain, either the final _connector or the next
 * _bridge. The parameter adjusted_mode is the input mode the bridge
@@ -301,15 +301,15 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
  struct drm_bridge *previous);
 
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode);
 enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
   const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,
-   struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode);
 void drm_bridge_pre_enable(struct drm_bridge *bridge);
 void drm_bridge_enable(struct drm_bridge *bridge);
 
-- 
2.15.1

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

Re: [PATCH v2 09/11] docs: Fix some broken references

[Stephen Boyd]

Quoting Mauro Carvalho Chehab (2018-05-09 06:18:52)
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
> 
> Manually checked if the produced result is valid, removing a few
> false-positives.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---

>  drivers/clk/clk.c |  4 ++--
>  drivers/clk/ingenic/cgu.h |  2 +-

Acked-by: Stephen Boyd 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Andrey Grodzovsky]

Yea, I might need to give another thought to whether this  spinlock can 
actually be removed.


Andrey

On 05/15/2018 03:38 PM, Alex Deucher wrote:

On Tue, May 15, 2018 at 3:31 PM, Andrey Grodzovsky
 wrote:

Signed-off-by: Andrey Grodzovsky 

Please provide a better patch description.

Alex


---
  drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
  include/drm/gpu_scheduler.h   | 1 -
  2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
 entity->last_scheduled = NULL;

 spin_lock_init(>rq_lock);
-   spin_lock_init(>queue_lock);
 spsc_queue_init(>job_queue);

 atomic_set(>fence_seq, 0);
@@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct drm_sched_job 
*sched_job,

 trace_drm_sched_job(sched_job, entity);

-   spin_lock(>queue_lock);
 first = spsc_queue_push(>job_queue, _job->queue_node);

-   spin_unlock(>queue_lock);
-
 /* first job wakes up scheduler */
 if (first) {
 /* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
 spinlock_t  rq_lock;
 struct drm_gpu_scheduler*sched;

-   spinlock_t  queue_lock;
 struct spsc_queue   job_queue;

 atomic_tfence_seq;
--
2.7.4

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


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

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #5 from mikhail.v.gavri...@gmail.com ---
5) Opera browser still working as yesterday (GPU overheating, on the video card
all LED are glow + 200% CPU and more ...)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm SPDX updates

[Alex Deucher]

On Mon, May 14, 2018 at 12:31 PM, Daniel Vetter  wrote:
> On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel wrote:
>> On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote:
>> > > I haven't seen any comments in the week since I wrote this. I'm not
>> > > familiar with the process for the drm changes - so what are the usual 
>> > > next
>> > > steps? Do I need to submit all or part of this somewhere else? Or does
>> > > Dave simply take the series (since it has no executable code changes at
>> > > all)?
>> >
>> > There are a number of teams sending pull requests to Dave. One option would
>> > be to have it all go through the drm-misc tree. (CC'ing Daniel Vetter about
>> > that). Another option would perhaps be to send a pull request directly to
>> > Dave (Dave?) And finally, one option would be to rely on the maintainers of
>> > each submodule to take the patches that touch that module. If you go for
>> > this last option, I can surely take the patches that touch vmwgfx, and
>> > Christian the TTM patches.
>>
>> Again, since this involves no code changes, I think I'd prefer the path
>> directly via Dave, simply as it makes it more likely that none of them get
>> lost... assuming you are willing to do that, Dave, where would you like that 
>> PR?
>
> Cc: dri-devel and send it to Dave and you should be good. But I thought
> Alex pulled this all in now? In the end probably doesn't matter really if
> it gets merged twice :-)

Looks like Christian merged the ttm change and that is in my PR today.
For the others I think we were running into some issues with merging
them in our internal git tree (internal export control stuff) so feel
free to send a separate PR for them if you don't want to wait for us
to sort out the internal merge first.

Alex

>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/amdgpu: Skip drm_sched_entity realted ops for KIQ ring.

[Alex Deucher]

On Tue, May 15, 2018 at 3:31 PM, Andrey Grodzovsky
 wrote:
> Follwoing change 75fbed2 we need to skip KIQ ring when iterating
> amdgpu_ctx's scheduler entites.
>
> Signed-off-by: Andrey Grodzovsky 

Typo in the title: realted -> related
Typo in the description: Follwoing -> Following
Also expand on the reasoning a bit in the patch description.  E.g., we
never initialize or use the GPU scheduler for KIQ.
With those things fixes:
Reviewed-by: Alex Deucher 

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index 6741a62..744519b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -173,9 +173,14 @@ static void amdgpu_ctx_do_release(struct kref *ref)
>
> ctx = container_of(ref, struct amdgpu_ctx, refcount);
>
> -   for (i = 0; i < ctx->adev->num_rings; i++)
> +   for (i = 0; i < ctx->adev->num_rings; i++) {
> +
> +   if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
> +   continue;
> +
> drm_sched_entity_fini(>adev->rings[i]->sched,
> >rings[i].entity);
> +   }
>
> amdgpu_ctx_fini(ref);
>  }
> @@ -452,12 +457,17 @@ void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr 
> *mgr)
> if (!ctx->adev)
> return;
>
> -   for (i = 0; i < ctx->adev->num_rings; i++)
> +   for (i = 0; i < ctx->adev->num_rings; i++) {
> +
> +   if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
> +   continue;
> +
> if (kref_read(>refcount) == 1)
> 
> drm_sched_entity_do_release(>adev->rings[i]->sched,
>   >rings[i].entity);
> else
> DRM_ERROR("ctx %p is still alive\n", ctx);
> +   }
> }
>  }
>
> @@ -474,12 +484,17 @@ void amdgpu_ctx_mgr_entity_cleanup(struct 
> amdgpu_ctx_mgr *mgr)
> if (!ctx->adev)
> return;
>
> -   for (i = 0; i < ctx->adev->num_rings; i++)
> +   for (i = 0; i < ctx->adev->num_rings; i++) {
> +
> +   if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
> +   continue;
> +
> if (kref_read(>refcount) == 1)
> 
> drm_sched_entity_cleanup(>adev->rings[i]->sched,
> >rings[i].entity);
> else
> DRM_ERROR("ctx %p is still alive\n", ctx);
> +   }
> }
>  }
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Alex Deucher]

On Tue, May 15, 2018 at 3:31 PM, Andrey Grodzovsky
 wrote:
> Signed-off-by: Andrey Grodzovsky 

Please provide a better patch description.

Alex

> ---
>  drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
>  include/drm/gpu_scheduler.h   | 1 -
>  2 files changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 1f1dd70..2569a63 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -140,7 +140,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
> entity->last_scheduled = NULL;
>
> spin_lock_init(>rq_lock);
> -   spin_lock_init(>queue_lock);
> spsc_queue_init(>job_queue);
>
> atomic_set(>fence_seq, 0);
> @@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct drm_sched_job 
> *sched_job,
>
> trace_drm_sched_job(sched_job, entity);
>
> -   spin_lock(>queue_lock);
> first = spsc_queue_push(>job_queue, _job->queue_node);
>
> -   spin_unlock(>queue_lock);
> -
> /* first job wakes up scheduler */
> if (first) {
> /* Add the entity to the run queue */
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 350a62c..683eb65 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -56,7 +56,6 @@ struct drm_sched_entity {
> spinlock_t  rq_lock;
> struct drm_gpu_scheduler*sched;
>
> -   spinlock_t  queue_lock;
> struct spsc_queue   job_queue;
>
> atomic_tfence_seq;
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm-next has moved

[Dave Airlie]

Just in case anyone was wondering, I've been trialling using the dim
tools for managing drm-next this cycle,

git://git.freedesktop.org/git/drm/drm drm-next

https://cgit.freedesktop.org/drm/drm/

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

[PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Andrey Grodzovsky]

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
 include/drm/gpu_scheduler.h   | 1 -
 2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
entity->last_scheduled = NULL;
 
spin_lock_init(>rq_lock);
-   spin_lock_init(>queue_lock);
spsc_queue_init(>job_queue);
 
atomic_set(>fence_seq, 0);
@@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct drm_sched_job 
*sched_job,
 
trace_drm_sched_job(sched_job, entity);
 
-   spin_lock(>queue_lock);
first = spsc_queue_push(>job_queue, _job->queue_node);
 
-   spin_unlock(>queue_lock);
-
/* first job wakes up scheduler */
if (first) {
/* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
spinlock_t  rq_lock;
struct drm_gpu_scheduler*sched;
 
-   spinlock_t  queue_lock;
struct spsc_queue   job_queue;
 
atomic_tfence_seq;
-- 
2.7.4

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

[PATCH 1/2] drm/amdgpu: Skip drm_sched_entity realted ops for KIQ ring.

[Andrey Grodzovsky]

Follwoing change 75fbed2 we need to skip KIQ ring when iterating
amdgpu_ctx's scheduler entites.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 6741a62..744519b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -173,9 +173,14 @@ static void amdgpu_ctx_do_release(struct kref *ref)
 
ctx = container_of(ref, struct amdgpu_ctx, refcount);
 
-   for (i = 0; i < ctx->adev->num_rings; i++)
+   for (i = 0; i < ctx->adev->num_rings; i++) {
+
+   if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
+   continue;
+
drm_sched_entity_fini(>adev->rings[i]->sched,
>rings[i].entity);
+   }
 
amdgpu_ctx_fini(ref);
 }
@@ -452,12 +457,17 @@ void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr 
*mgr)
if (!ctx->adev)
return;
 
-   for (i = 0; i < ctx->adev->num_rings; i++)
+   for (i = 0; i < ctx->adev->num_rings; i++) {
+
+   if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
+   continue;
+
if (kref_read(>refcount) == 1)

drm_sched_entity_do_release(>adev->rings[i]->sched,
  >rings[i].entity);
else
DRM_ERROR("ctx %p is still alive\n", ctx);
+   }
}
 }
 
@@ -474,12 +484,17 @@ void amdgpu_ctx_mgr_entity_cleanup(struct amdgpu_ctx_mgr 
*mgr)
if (!ctx->adev)
return;
 
-   for (i = 0; i < ctx->adev->num_rings; i++)
+   for (i = 0; i < ctx->adev->num_rings; i++) {
+
+   if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
+   continue;
+
if (kref_read(>refcount) == 1)

drm_sched_entity_cleanup(>adev->rings[i]->sched,
>rings[i].entity);
else
DRM_ERROR("ctx %p is still alive\n", ctx);
+   }
}
 }
 
-- 
2.7.4

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

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Today (In reply to Christian König from comment #3)
> > $ mpv --hwdec=vaapi Downloads/WE\ GOT\ INTEL\'S\ PROTOTYPE\ GRAPHICS\
> > CARD.webm 
> > Playing: Downloads/WE GOT INTEL'S PROTOTYPE GRAPHICS CARD.webm
> >  (+) Video --vid=1 (*) (vp9 3840x2160 29.970fps)
> > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object
> > file: No such file or directory
> 
> "--hwdec=vaapi" and "Failed to open VDPAU backend"? Could it be that you
> have a setting which says to use VDPAU for displaying?

This morning on my distribution (Fedora 29) a lot of packages was upgraded.
After this upgrade, CPU load while playing 4K VP9 videos was decreased in two
times.
And most importantly, the GPU was stop heated like it was yesterday. (1-2 LED
only glow during playing video) And disappeared dropped frames.

But:
1) Error message "Failed to open VDPAU backend libvdpau_nvidia.so: cannot open
shared object file: No such file or directory" are still out. I am also want to
say that I not touched settings and don't know why mpv want load
libvdpau_nvidia.so library. May be you can help in where I can check this
settings.

2) Problem was gone only in mpv and Firefox (I am not checking another
players), but Totem still working as yesterday (GPU overheating, on the video
card all LED are glow + 200% CPU and more ...)

3) On Firefox and mpv I was note that happens new problem. This issue in
desyncing video and audio. The video is always late.

4) CPU loading during playing video was decreases in two times in some
applications as I said above, but I am curious about 100% CPU load it normal or
too much? I read somewhere that somebody's said that CPU load must does not
exceed 30% on the mobile CPU with IGPU during playing 4K video. It's true?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199693] [bisect 08810a4119aaebf6318f209ec5dd9828e969cba4] (pci runtime) System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

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

--- Comment #5 from Thomas Martitz (ku...@rockbox.org) ---
Created attachment 275999
  --> https://bugzilla.kernel.org/attachment.cgi?id=275999=edit
Patch making resume work

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199693] [bisect 08810a4119aaebf6318f209ec5dd9828e969cba4] (pci runtime) System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

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

--- Comment #4 from Thomas Martitz (ku...@rockbox.org) ---
Not necessarily, I'd say. Using the attached patch (I posted this to linux-pm,
too). Makes it work.

Also, I think it's another dev that affects amdgpu somehow, restricting the
above patch to amdgpu-bound devices does not fix the issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #12 from Harry Wentland  ---
Hi burak,

your stack is different. See dce110_opp_program_regamma_pwl vs
dce110_stream_encoder_update_hdmi_info_packets on the stack.

Can you open a new ticket?

Thanks,
Harry

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[gabbayo:amdkfd-next 19/28] drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:33:21: sparse: cast to restricted __le32

[kbuild test robot]

tree:   git://people.freedesktop.org/~gabbayo/linux amdkfd-next
head:   8feaccf71dd61f2201493068055e0d1d699014df
commit: ca750681bc4a897ffa7eed71a1e05762fb1f0a34 [19/28] drm/amdkfd: Add SOC15 
interrupt processing support
reproduce:
# apt-get install sparse
git checkout ca750681bc4a897ffa7eed71a1e05762fb1f0a34
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:33:21: sparse: cast to 
>> restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:34:21: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:35:17: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:36:16: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:61:21: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:62:21: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:63:17: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:64:16: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:65:22: sparse: cast to 
restricted __le32

vim +33 drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c

26  
27  
28  static bool event_interrupt_isr_v9(struct kfd_dev *dev,
29  const uint32_t *ih_ring_entry)
30  {
31  uint16_t source_id, client_id, pasid, vmid;
32  
  > 33  source_id = SOC15_SOURCE_ID_FROM_IH_ENTRY(ih_ring_entry);
34  client_id = SOC15_CLIENT_ID_FROM_IH_ENTRY(ih_ring_entry);
35  pasid = SOC15_PASID_FROM_IH_ENTRY(ih_ring_entry);
36  vmid = SOC15_VMID_FROM_IH_ENTRY(ih_ring_entry);
37  
38  if (pasid) {
39  const uint32_t *data = ih_ring_entry;
40  
41  pr_debug("client id 0x%x, source id %d, pasid 0x%x. raw 
data:\n",
42   client_id, source_id, pasid);
43  pr_debug("%8X, %8X, %8X, %8X, %8X, %8X, %8X, %8X.\n",
44   data[0], data[1], data[2], data[3],
45   data[4], data[5], data[6], data[7]);
46  }
47  
48  return (pasid != 0) &&
49  (source_id == SOC15_INTSRC_CP_END_OF_PIPE ||
50   source_id == SOC15_INTSRC_SDMA_TRAP ||
51   source_id == SOC15_INTSRC_SQ_INTERRUPT_MSG ||
52   source_id == SOC15_INTSRC_CP_BAD_OPCODE);
53  }
54  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon, amdgpu, ttm, and gpu scheduler drm-next-4.18

[Alex Deucher]

Hi Dave,

Main changes for 4.18.  I'd like to do a separate pull for vega20 later
this week or next.  Highlights:
- Reserve pre-OS scanout buffer during init for seemless transition from
  console to driver
- VEGAM support
- Improved GPU scheduler documentation
- Initial gfxoff support for raven
- SR-IOV fixes
- Default to non-AGP on PowerPC for radeon
- Fine grained clock voltage control for vega10
- Power profiles for vega10
- Further clean up of powerplay/driver interface
- Underlay fixes
- Display link bw updates
- Gamma fixes
- Scatter/Gather display support on CZ/ST
- Misc bug fixes and clean ups

The following changes since commit 871e899db19da3dbd17a5d263b555dc5b7d8fed5:

  Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2018-04-11 08:35:41 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.18

for you to fetch changes up to 8344c53f57057b42a5da87e9557c40fcda18fb7a:

  drm/scheduler: remove unused parameter (2018-05-15 13:44:27 -0500)


Alex Deucher (29):
  drm/amdgpu/sdma4: use a helper for SDMA_OP_POLL_REGMEM
  drm/amdgpu: add documentation on hwmon interfaces exposed (v3)
  drm/amdgpu: add asic need_full_reset callback
  drm/amdgpu/si: implement asic need_full_reset callback
  drm/amdgpu/cik: implement asic need_full_reset callback
  drm/amdgpu/vi: implement asic need_full_reset callback
  drm/amdgpu/soc15: implement asic need_full_reset callback
  drm/amdgpu: use new asic need_full_reset callback
  drm/amdgpu/gfx9: cache DB_DEBUG2 and make it available to userspace
  drm/amdgpu/powerplay: fix smu7_get_memory_type for fiji
  drm/amdgpu/powerplay: rename smu7_upload_mc_firmware
  drm/amdgpu: add emit_reg_write_reg_wait ring callback
  drm/amdgpu/gfx9: add emit_reg_write_reg_wait ring callback (v2)
  drm/amdgpu/sdma4: add emit_reg_write_reg_wait ring callback (v2)
  drm/amdgpu/uvd7: add emit_reg_write_reg_wait ring callback
  drm/amdgpu/vce4: add emit_reg_write_reg_wait ring callback
  drm/amdgpu/vcn1: add emit_reg_write_reg_wait ring callback
  drm/amdgpu/gmc9: use amdgpu_ring_emit_reg_write_reg_wait in gpu tlb flush
  drm/amdgpu/gmc: steal the appropriate amount of vram for fw hand-over (v3)
  drm/amdgpu: print the vbios version in the debugfs firmware info
  drm/amdgpu/pm: document power_dpm_force_performance_level
  drm/amdgpu/pm: document power_dpm_state
  drm/amdgpu/pm: document pp_table
  drm/amdgpu/pm: document pp_dpm_sclk pp_dpm_mclk pp_dpm_pcie (v2)
  drm/amdgpu/pm: document pp_power_profile_mode
  drm/amdgpu/pm: document pp_od_clk_voltage
  drm/amdgpu/powerplay: actually return the power with the new query
  drm/amdgpu: Add VEGAM support to the legacy DCE 11 module
  drm/amdgpu/gmc9: remove unused register defs

Andrey Grodzovsky (2):
  drm/amdgpu: Free VGA stolen memory as soon as possible.
  drm/amdgpu: Switch to interruptable wait to recover from ring hang.

Anthony Koo (19):
  drm/amd/display: Couple bug fixes in stats module
  drm/amd/display: Rename encoder_info_packet to dc_info_packet
  drm/amd/display: Only program MSA_TIMING_PARAM if it changed
  drm/amd/display: Program v_total_min/max after v_total_cntl
  drm/amd/display: Add vmax/min_sel prints to dcn10_log_hw_state
  drm/amd/display: csc updates require FULL update
  drm/amd/display: Updated HDR Static Metadata to directly take info packet 
raw
  drm/amd/display: Get rid of unused input_tf
  drm/amd/display: Remove unused fields
  drm/amd/display: Do not use os types
  drm/amd/display: csc_transform to dc_csc_transform
  drm/amd/display: Refactor color module
  drm/amd/display: move color_transfer_func to color mod
  drm/amd/display: Fix structure initialization of hdmi_info_packet
  drm/amd/display: Have DC manage its own allocation of gamma
  drm/amd/display: Do not create memory allocation if stats not enabled
  drm/amd/display: fix issue related to infopacket was not transmitted
  drm/amd/display: add some DTN logs for input and output tf
  drm/amd/display: update dtn logging and goldens

Bhawanpreet Lakha (3):
  drm/amd/display: Add debug prints for bandwidth calculations
  drm/amd/display: Correct print types in DC_LOGS
  drm/amd/display: Add Dynamic debug prints

Charlene Liu (3):
  drm/amd/display: add delay between panel pwr off to on.
  drm/amd/display: HDMI has no sound after Panel power off/on
  drm/amd/display: add cursor TTU CRQ related

Christian König (11):
  drm/amdgpu: use ctx bytes_moved
  drm/amdgpu: fix and cleanup cpu visible VRAM handling
  drm/ttm: keep a reference to transfer pipelined BOs
  drm/amdgpu: revert "add new bo flag that indicates BOs don't need 
fallback (v2)"
  drm/amdgpu: revert "Don't 

[Bug 104347] AMD RX 580: Hide/Show Chromium sometimes corrupts screen (see screenshot)

[bugzilla-daemon]

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

--- Comment #16 from Norbert Klar  ---
Found some articles from early 2017, and many RX4xx/5xx users report this
problem. Any chance to get a fix?

https://askubuntu.com/questions/910124/amd-graphics-rx-480-displaying-artifacts-in-17-04

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: rcar-du: Fix build failure

[Laurent Pinchart]

Commit 75a07f399cd4 ("drm: rcar-du: Zero-out sg_tables when duplicating
plane state") introduced a reference to the alpha field of struct
rcar_du_vsp_plane_state that got removed in commit 301a9b8d5456
("drm/rcar-du: Convert to the new generic alpha property"). The issue
stems from the merge of the two commits through separate branches and
breaks compilation of the driver. Fix it.

Fixes: 75a07f399cd4 ("drm: rcar-du: Zero-out sg_tables when duplicating plane 
state")
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 27a440886b17..c59f0cfabd33 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -314,7 +314,6 @@ rcar_du_vsp_plane_atomic_duplicate_state(struct drm_plane 
*plane)
return NULL;
 
__drm_atomic_helper_plane_duplicate_state(plane, >state);
-   copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
 
return >state;
 }
-- 
Regards,

Laurent Pinchart

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

Re: [RFC PATCH] drm/vkms: vkms_driver can be static

[Daniel Vetter]

On Tue, May 15, 2018 at 07:30:52PM +0800, kbuild test robot wrote:
> 
> Fixes: 58d8108f080c ("drm/vkms: Introduce basic VKMS driver")
> Signed-off-by: Fengguang Wu 

One thing I noticed while applying this: Your author (as recorded in the
From: line) and your s-o-b don't match. Now I know that you're behind
0day, so it's ok, but our script gets annoyed and I need to overrule it
with an -f flag.

Can you perhaps get the From: and S-o-b: lines into agreement so that a
simple comparison works?

Thanks, Daniel

> ---
>  vkms_drv.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index b1df08e..35517b09 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -40,7 +40,7 @@ static void vkms_release(struct drm_device *dev)
>   drm_dev_fini(>drm);
>  }
>  
> -struct drm_driver vkms_driver = {
> +static struct drm_driver vkms_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
>   .release= vkms_release,
>   .fops   = _driver_fops,

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #11 from burak  ---
H(In reply to Harry Wentland from comment #10)
> No worries. Don't hesitate to open a new ticket if your warning/error log
> seems to indicate amdgpu. I'd be happy to take a brief look.
> 
> Even if I won't have time to provide an immediate fix it will still allow me
> to better understand what problems people have with our driver and where we
> might need to spend more effort.

Hi, sorry to bother for closed issue but I am having exact same error on every
boot, I build kernel from master head of linus repo, fedora with Fury X gpu. Is
this related with my driver? i have xorg-x11-drv-amdgpu.x86_64  
(18.0.1-1.fc27)

 WARNING: CPU: 8 PID: 288 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0x108/0x150 [amdgpu]
[7.598040] Modules linked in: amdkfd amd_iommu_v2 amdgpu(+) chash gpu_sched
drm_kms_helper hid_logitech_hidpp ttm drm igb ptp crc32c_intel nvme pps_core
hid_logitech_dj hid_microsoft nvme_core dca i2c_algo_b
it
[7.598045] CPU: 8 PID: 288 Comm: kworker/8:1 Tainted: GW
4.17.0-rc5-1-burak+ #4
[7.598045] Hardware name: System manufacturer System Product Name/PRIME
X399-A, BIOS 0601 03/27/2018
[7.598047] Workqueue: events work_for_cpu_fn
[7.598073] RIP: 0010:generic_reg_update_ex+0x108/0x150 [amdgpu]
[7.598073] RSP: 0018:b82e475d3760 EFLAGS: 00010246
[7.598074] RAX: b82e475d3780 RBX: 937e1efdc000 RCX:

[7.598074] RDX: 00012390 RSI:  RDI:
937e21691d80
[7.598075] RBP: b82e475d37d0 R08:  R09:

[7.598075] R10: b82e475d37e8 R11: 0001 R12:
0001
[7.598075] R13:  R14: 937e1f5fc800 R15:
937e1e9ac000
[7.598076] FS:  () GS:937e3f40()
knlGS:
[7.598077] CS:  0010 DS:  ES:  CR0: 80050033
[7.598077] CR2: 7f830e34465e CR3: 00041fb9e000 CR4:
003406e0
[7.598078] Call Trace:
[7.598108]  dce110_stream_encoder_update_hdmi_info_packets+0x20e/0x3a0
[amdgpu]
[7.598135]  dc_stream_adjust_vmin_vmax+0xb3/0xf0 [amdgpu]
[7.598161]  set_freesync_on_streams.part.6+0x4d/0x250 [amdgpu]
[7.598187]  mod_freesync_notify_mode_change+0x11e/0x150 [amdgpu]
[7.598215]  amdgpu_dm_atomic_commit_tail+0x523/0xd00 [amdgpu]
[7.598240]  ? amdgpu_bo_pin_restricted+0x202/0x2c0 [amdgpu]
[7.598267]  ? dm_plane_helper_prepare_fb+0x19c/0x260 [amdgpu]
[7.598271]  commit_tail+0x3d/0x70 [drm_kms_helper]
[7.598274]  drm_atomic_helper_commit+0xfc/0x110 [drm_kms_helper]
[7.598277]  restore_fbdev_mode_atomic+0x1ac/0x210 [drm_kms_helper]
[7.598280]  drm_fb_helper_restore_fbdev_mode_unlocked+0x45/0x90
[drm_kms_helper]
[7.598283]  drm_fb_helper_set_par+0x29/0x50 [drm_kms_helper]
[7.598284]  fbcon_init+0x4d7/0x680
[7.598285]  visual_init+0xd5/0x130
[7.598286]  do_bind_con_driver+0x1f4/0x400
[7.598287]  do_take_over_console+0x7b/0x190
[7.598288]  do_fbcon_takeover+0x58/0xb0
[7.598289]  notifier_call_chain+0x47/0x70
[7.598291]  blocking_notifier_call_chain+0x3e/0x60
[7.598291]  ? down+0x12/0x50
[7.598292]  register_framebuffer+0x248/0x350
[7.598296]  __drm_fb_helper_initial_config_and_unlock+0x221/0x460
[drm_kms_helper]
[7.598320]  amdgpu_fbdev_init+0xc4/0xf0 [amdgpu]
[7.598344]  amdgpu_device_init+0xd56/0x1450 [amdgpu]
[7.598345]  ? kmalloc_order+0x14/0x40
[7.598368]  amdgpu_driver_load_kms+0x86/0x2b0 [amdgpu]
[7.598374]  drm_dev_register+0x132/0x1c0 [drm]
[7.598397]  amdgpu_pci_probe+0x13f/0x200 [amdgpu]
[7.598398]  local_pci_probe+0x42/0xa0
[7.598400]  work_for_cpu_fn+0x16/0x20
[7.598401]  process_one_work+0x175/0x360
[7.598402]  worker_thread+0x1c6/0x380
[7.598403]  ? process_one_work+0x360/0x360
[7.598404]  kthread+0x113/0x130
[7.598405]  ? kthread_create_worker_on_cpu+0x70/0x70

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

[Enric Balletbo Serra]

Hi Neil,

I suspect that this patch will conflict with some patches that will be
queued for 4.18 that also introduces new devices, well, for now I
don't see these merged in the Lee's tree.

Based on some reviews I got when I send a patch to this file ...

2018-05-15 17:29 GMT+02:00 Hans Verkuil :
> On 05/15/2018 04:42 PM, Neil Armstrong wrote:
>> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
>> when the CEC feature bit is present.
>>
>> Signed-off-by: Neil Armstrong 
>
> For what it is worth (not an MFD expert):
>
> Acked-by: Hans Verkuil 
>
> Thanks!
>
> Hans
>
>> ---
>>  drivers/mfd/cros_ec_dev.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
>> index eafd06f..57064ec 100644
>> --- a/drivers/mfd/cros_ec_dev.c
>> +++ b/drivers/mfd/cros_ec_dev.c
>> @@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
>> *ec)
>>   kfree(msg);
>>  }
>>
>> +static void cros_ec_cec_register(struct cros_ec_dev *ec)
>> +{
>> + int ret;
>> + struct mfd_cell cec_cell = {
>> + .name = "cros-ec-cec",
>> + };
>> +
>> + ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
>> + if (ret)
>> + dev_err(ec->dev, "failed to add EC CEC\n");
>> +}
>> +

Do not create a single function to only call mfd_add_devices, instead
do the following on top:

static const struct mfd_cell cros_ec_cec_cells[] = {
{ .name = "cros-ec-cec" }
};


>>  static int ec_device_probe(struct platform_device *pdev)
>>  {
>>   int retval = -ENOMEM;
>> @@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
>>   if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
>>   cros_ec_sensors_register(ec);
>>
>> + /* check whether this EC handles CEC. */
>> + if (cros_ec_check_features(ec, EC_FEATURE_CEC))
>> + cros_ec_cec_register(ec);
>> +

and use PLATFORM_DEVID_AUTO and the ARRAY_SIZE macro, something like this.

/* Check whether this EC instance handles CEC */
if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
  cros_ec_cec_cells,
  ARRAY_SIZE(cros_ec_cec_cells),
  NULL, 0, NULL);
if (retval)
dev_err(ec->dev, "failed to add cros-ec-cec device: %d\n",
 retval);
}

Best regards,
  Enric

>>   /* Take control of the lightbar from the EC. */
>>   lb_manual_suspend_ctrl(ec, 1);
>>
>>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106527] [amdgpu-pro] OpenCL corrupted memory on AMD R9 280X

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

Summary|OpenCL corrupted memory on  |[amdgpu-pro] OpenCL
   |AMD R9 280X |corrupted memory on AMD R9
   ||280X

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rcar-du: Fix rcar_du_of_init() stub

[Kieran Bingham]

Hi Laurent

Thanks for identifying this fault and posting the fix.

(+linux-renesas-soc)

On 15/05/18 16:57, Laurent Pinchart wrote:
> The rcar_du_of_init() function is supposed to be defined as a stub when
> CONFIG_DRM_RCAR_LVDS is disabled as the rcar_du_of.c file isn't compiled
> in that case. However, a bug in the configuration option check makes it
> a stub when CONFIG_DRM_RCAR_LVDS=m as well, which prevents legacy DTs
> from being fixed at boot time. Fix the configuration option check by
> using IS_ENABLED.
> 
> Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder 
> nodes")
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_of.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_of.h
> index c2e65a727e91..8dd3fbe96650 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_of.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.h
> @@ -11,7 +11,7 @@
>  
>  struct of_device_id;
>  
> -#ifdef CONFIG_DRM_RCAR_LVDS
> +#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS)
>  void __init rcar_du_of_init(const struct of_device_id *of_ids);
>  #else
>  static inline void rcar_du_of_init(const struct of_device_id *of_ids) { }
> 



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104598] vkmark with kwin compositing: Page flip failed: Cannot allocate memory

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|DRM/AMDgpu  |DRM/other

--- Comment #7 from Michel Dänzer  ---
Thanks, I was finally able to reproduce this. Seems like it's only reproducible
if the app runs at >= ~10K FPS.

It happens because the client submits so many PresentPixmap requests within a
single vertical blank period that the corresponding DRM vblank events fill up
the kernel DRM event queue. Then when the compositor sends a PresentPixmap
request, the page flip ioctl gets -ENOMEM from drm_event_reserve_init and
propagates it. (That the modesetting driver can't deal with this is its bug)

Options for addressing this:

The kernel might allow queuing page flip events even when the queue is full
with vblank events.

The xserver present code should be able to re-use a single DRM vblank event for
multiple client requests with the same target MSC.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

[Neil Armstrong]

On 15/05/2018 17:22, Hans Verkuil wrote:
> On 05/15/2018 04:42 PM, Neil Armstrong wrote:
>> In non device-tree world, we can need to get the notifier by the driver
>> name directly and eventually defer probe if not yet created.
>>
>> This patch adds a variant of the get function by using the device name
>> instead and will not create a notifier if not yet created.
>>
>> But the i915 driver exposes at least 2 HDMI connectors, this patch also
>> adds the possibility to add a connector name tied to the notifier device
>> to form a tuple and associate different CEC controllers for each HDMI
>> connectors.
> 
> The patch looks good, but I'm curious about this paragraph above.
> 
> Was this tested with devices with more than one HDMI output? Or only on
> laptops with a single physical HDMI output? If there are two or more
> outputs then I guess it is the HW designer that decides with output gets
> CEC support?

The driver exposes 2 HDMI connectors (I suspect one is connected to the USB-C 
alt mode mux along the DP port),
and only one connected has the CEC line connected to the Embedded Controller.

Neil

> 
> Regards,
> 
>   Hans
> 
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/media/cec/cec-notifier.c | 11 ---
>>  include/media/cec-notifier.h | 27 ---
>>  2 files changed, 32 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/media/cec/cec-notifier.c 
>> b/drivers/media/cec/cec-notifier.c
>> index 16dffa0..dd2078b 100644
>> --- a/drivers/media/cec/cec-notifier.c
>> +++ b/drivers/media/cec/cec-notifier.c
>> @@ -21,6 +21,7 @@ struct cec_notifier {
>>  struct list_head head;
>>  struct kref kref;
>>  struct device *dev;
>> +const char *conn;
>>  struct cec_adapter *cec_adap;
>>  void (*callback)(struct cec_adapter *adap, u16 pa);
>>  
>> @@ -30,13 +31,14 @@ struct cec_notifier {
>>  static LIST_HEAD(cec_notifiers);
>>  static DEFINE_MUTEX(cec_notifiers_lock);
>>  
>> -struct cec_notifier *cec_notifier_get(struct device *dev)
>> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char 
>> *conn)
>>  {
>>  struct cec_notifier *n;
>>  
>>  mutex_lock(_notifiers_lock);
>>  list_for_each_entry(n, _notifiers, head) {
>> -if (n->dev == dev) {
>> +if (n->dev == dev &&
>> +(!conn || !strcmp(n->conn, conn))) {
>>  kref_get(>kref);
>>  mutex_unlock(_notifiers_lock);
>>  return n;
>> @@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>>  if (!n)
>>  goto unlock;
>>  n->dev = dev;
>> +if (conn)
>> +n->conn = kstrdup(conn, GFP_KERNEL);
>>  n->phys_addr = CEC_PHYS_ADDR_INVALID;
>>  mutex_init(>lock);
>>  kref_init(>kref);
>> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>>  mutex_unlock(_notifiers_lock);
>>  return n;
>>  }
>> -EXPORT_SYMBOL_GPL(cec_notifier_get);
>> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>>  
>>  static void cec_notifier_release(struct kref *kref)
>>  {
>> @@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
>>  container_of(kref, struct cec_notifier, kref);
>>  
>>  list_del(>head);
>> +kfree(n->conn);
>>  kfree(n);
>>  }
>>  
>> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
>> index cf0add7..814eeef 100644
>> --- a/include/media/cec-notifier.h
>> +++ b/include/media/cec-notifier.h
>> @@ -20,8 +20,10 @@ struct cec_notifier;
>>  #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>>  
>>  /**
>> - * cec_notifier_get - find or create a new cec_notifier for the given 
>> device.
>> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
>> + * device and connector tuple.
>>   * @dev: device that sends the events.
>> + * @conn: the connector name from which the event occurs
>>   *
>>   * If a notifier for device @dev already exists, then increase the refcount
>>   * and return that notifier.
>> @@ -31,7 +33,8 @@ struct cec_notifier;
>>   *
>>   * Return NULL if the memory could not be allocated.
>>   */
>> -struct cec_notifier *cec_notifier_get(struct device *dev);
>> +struct cec_notifier *cec_notifier_get_conn(struct device *dev,
>> +   const char *conn);
>>  
>>  /**
>>   * cec_notifier_put - decrease refcount and delete when the refcount 
>> reaches 0.
>> @@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
>> struct cec_notifier *notifier);
>>  
>>  #else
>> -static inline struct cec_notifier *cec_notifier_get(struct device *dev)
>> +static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
>> + const char *conn)
>>  {
>>  /* A non-NULL pointer is expected on success */
>>  return (struct cec_notifier 

[PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

[Ayan Kumar Halder]

malidp_pm_suspend_late checks if the runtime status is not suspended
and if so, invokes malidp_runtime_pm_suspend which disables the
display engine/core interrupts and the clocks. It sets the runtime status
as suspended.

The difference between suspend() and suspend_late() is as follows:-
1. suspend() makes the device quiescent. In our case, we invoke the DRM
helper which disables the CRTC. This would have invoked runtime pm
suspend but the system suspend process disables runtime pm.
2. suspend_late() It continues the suspend operations of the drm device 
which was started by suspend(). In our case, it performs the same functionality
as runtime_suspend().

The complimentary functions are resume() and resume_early(). In the case of
resume_early(), we invoke malidp_runtime_pm_resume() which enables the clocks
and the interrupts. It sets the runtime status as active. If the device was
in runtime suspend mode before system suspend was called, pm_runtime_work()
will put the device back in runtime suspended mode( after the complete system
has been resumed).

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Rebased on top of earlier v3 patches, 

Changes in v2:-
- Removed the change id and modified the commit message
---
 drivers/gpu/drm/arm/malidp_drv.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 82221ea..c53b46a 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -768,8 +768,25 @@ static int __maybe_unused malidp_pm_resume(struct device 
*dev)
return 0;
 }
 
+static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
+{
+   if (!pm_runtime_status_suspended(dev)) {
+   malidp_runtime_pm_suspend(dev);
+   pm_runtime_set_suspended(dev);
+   }
+   return 0;
+}
+
+static int __maybe_unused malidp_pm_resume_early(struct device *dev)
+{
+   malidp_runtime_pm_resume(dev);
+   pm_runtime_set_active(dev);
+   return 0;
+}
+
 static const struct dev_pm_ops malidp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
malidp_pm_resume_early) \
SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, malidp_runtime_pm_resume, 
NULL)
 };
 
-- 
2.7.4

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

[PATCH v3 4/5] drm/arm/malidp: Set the output_depth register in modeset

[Ayan Kumar Halder]

One needs to store the value of the OUTPUT_DEPTH that one has parsed from
device tree, so that it can be restored on system resume. This value is
set in the modeset function as this gets reset when the system suspends.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Rebased the patch on top of the earlier v3 patches.

Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 1 +
 drivers/gpu/drm/arm/malidp_hw.c  | 4 
 drivers/gpu/drm/arm/malidp_hw.h  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 983b854..82221ea 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -603,6 +603,7 @@ static int malidp_bind(struct device *dev)
for (i = 0; i < MAX_OUTPUT_CHANNELS; i++)
out_depth = (out_depth << 8) | (output_width[i] & 0xf);
malidp_hw_write(hwdev, out_depth, hwdev->hw->map.out_depth_base);
+   hwdev->output_color_depth = out_depth;
 
atomic_set(>config_valid, 0);
init_waitqueue_head(>wq);
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 3f53f7e8..52c7031 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -233,6 +233,8 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 {
u32 val = 0;
 
+   malidp_hw_write(hwdev, hwdev->output_color_depth,
+   hwdev->hw->map.out_depth_base);
malidp_hw_clearbits(hwdev, MALIDP500_DC_CLEAR_MASK, 
MALIDP500_DC_CONTROL);
if (mode->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= MALIDP500_HSYNCPOL;
@@ -457,6 +459,8 @@ static void malidp550_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 {
u32 val = MALIDP_DE_DEFAULT_PREFETCH_START;
 
+   malidp_hw_write(hwdev, hwdev->output_color_depth,
+   hwdev->hw->map.out_depth_base);
malidp_hw_write(hwdev, val, MALIDP550_DE_CONTROL);
/*
 * Mali-DP550 and Mali-DP650 encode the background color like this:
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 864fe92..6e3db57 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -228,6 +228,7 @@ struct malidp_hw_device {
 
u8 min_line_size;
u16 max_line_size;
+   u32 output_color_depth;
 
/* track the device PM state */
bool pm_suspended;
-- 
2.7.4

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

[PATCH v3 2/5] drm/arm/malidp: Split malidp interrupt initialization functions.

[Ayan Kumar Halder]

Malidp uses two interrupts ie 1. se_irq - used for memory writeback. 
 and 2. de_irq - used for display output.
Extract the hardware initialization part from malidp interrupt registration
ie (malidp_de_irq_init()/ malidp_se_irq_init()) into a separate function 
(ie malidp_de_irq_hw_init()/malidp_se_irq_hw_init())
which will be later invoked from runtime_pm_resume function when it needs
to re-enable the interrupts.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Squashed https://patchwork.kernel.org/patch/10357203/ and 
https://patchwork.kernel.org/patch/10357209/ into a single commit.
The reason being that although the two functions belong to different units
of malidp (ie scaling engine and display engine), the intent for splitting 
these functions remain the same.

Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_hw.c | 38 +-
 drivers/gpu/drm/arm/malidp_hw.h |  2 ++
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 8fb02f3..3f53f7e8 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -869,6 +869,23 @@ static irqreturn_t malidp_de_irq_thread_handler(int irq, 
void *arg)
return IRQ_HANDLED;
 }
 
+void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev)
+{
+   /* ensure interrupts are disabled */
+   malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_DE_BLOCK, 0x);
+   malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_DC_BLOCK, 0x);
+
+   /* first enable the DC block IRQs */
+   malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK,
+hwdev->hw->map.dc_irq_map.irq_mask);
+
+   /* now enable the DE block IRQs */
+   malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
+hwdev->hw->map.de_irq_map.irq_mask);
+}
+
 int malidp_de_irq_init(struct drm_device *drm, int irq)
 {
struct malidp_drm *malidp = drm->dev_private;
@@ -889,13 +906,7 @@ int malidp_de_irq_init(struct drm_device *drm, int irq)
return ret;
}
 
-   /* first enable the DC block IRQs */
-   malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK,
-hwdev->hw->map.dc_irq_map.irq_mask);
-
-   /* now enable the DE block IRQs */
-   malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
-hwdev->hw->map.de_irq_map.irq_mask);
+   malidp_de_irq_hw_init(hwdev);
 
return 0;
 }
@@ -941,6 +952,16 @@ static irqreturn_t malidp_se_irq(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev)
+{
+   /* ensure interrupts are disabled */
+   malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_SE_BLOCK, 0x);
+
+   malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK,
+hwdev->hw->map.se_irq_map.irq_mask);
+}
+
 static irqreturn_t malidp_se_irq_thread_handler(int irq, void *arg)
 {
return IRQ_HANDLED;
@@ -964,8 +985,7 @@ int malidp_se_irq_init(struct drm_device *drm, int irq)
return ret;
}
 
-   malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK,
-hwdev->hw->map.se_irq_map.irq_mask);
+   malidp_se_irq_hw_init(hwdev);
 
return 0;
 }
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 6607aba..864fe92 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -297,6 +297,8 @@ static inline void malidp_hw_enable_irq(struct 
malidp_hw_device *hwdev,
 }
 
 int malidp_de_irq_init(struct drm_device *drm, int irq);
+void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev);
+void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev);
 void malidp_de_irq_fini(struct malidp_hw_device *hwdev);
 int malidp_se_irq_init(struct drm_device *drm, int irq);
 void malidp_se_irq_fini(struct malidp_hw_device *hwdev);
-- 
2.7.4

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

[PATCH v3 1/5] drm/arm/malidp: Modified the prototype of malidp irq de-initializers

[Ayan Kumar Halder]

Malidp uses two interrupts ie 1. se_irq - used for memory writeback. 
 and 2. de_irq - used for display output.
'struct drm_device' is being replaced with 'struct malidp_hw_device'
as the function argument. The reason being the dependency of
malidp_de_irq_fini on 'struct drm_device' needs to be removed so as to
enable it to call from functions which receives 'struct malidp_hw_device'
as argument. Furthermore, there is no way to retrieve 'struct drm_device'
from 'struct malidp_hw_device'.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Squashed https://patchwork.kernel.org/patch/10357201/ and 
https://patchwork.kernel.org/patch/10308283/ into a single commit.
The reason being that although the two functions belong to different units
of malidp (ie scaling engine and display engine), the intent for modifying 
the prototype of these functions remain the same.

Changes in v2:-
- Removed the change id and modified the commit messages
---
 drivers/gpu/drm/arm/malidp_drv.c | 13 -
 drivers/gpu/drm/arm/malidp_hw.c  | 10 ++
 drivers/gpu/drm/arm/malidp_hw.h  |  4 ++--
 3 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4b0c4b4..f7a8beb 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -295,6 +295,8 @@ static int malidp_irq_init(struct platform_device *pdev)
 {
int irq_de, irq_se, ret = 0;
struct drm_device *drm = dev_get_drvdata(>dev);
+   struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
 
/* fetch the interrupts from DT */
irq_de = platform_get_irq_byname(pdev, "DE");
@@ -314,7 +316,7 @@ static int malidp_irq_init(struct platform_device *pdev)
 
ret = malidp_se_irq_init(drm, irq_se);
if (ret) {
-   malidp_de_irq_fini(drm);
+   malidp_de_irq_fini(hwdev);
return ret;
}
 
@@ -651,8 +653,8 @@ static int malidp_bind(struct device *dev)
 fbdev_fail:
pm_runtime_get_sync(dev);
 vblank_fail:
-   malidp_se_irq_fini(drm);
-   malidp_de_irq_fini(drm);
+   malidp_se_irq_fini(hwdev);
+   malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
 irq_init_fail:
component_unbind_all(dev, drm);
@@ -681,14 +683,15 @@ static void malidp_unbind(struct device *dev)
 {
struct drm_device *drm = dev_get_drvdata(dev);
struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
 
drm_dev_unregister(drm);
drm_fb_cma_fbdev_fini(drm);
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
drm_crtc_vblank_off(>crtc);
-   malidp_se_irq_fini(drm);
-   malidp_de_irq_fini(drm);
+   malidp_se_irq_fini(hwdev);
+   malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index e4d9ebc..8fb02f3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -900,11 +900,8 @@ int malidp_de_irq_init(struct drm_device *drm, int irq)
return 0;
 }
 
-void malidp_de_irq_fini(struct drm_device *drm)
+void malidp_de_irq_fini(struct malidp_hw_device *hwdev)
 {
-   struct malidp_drm *malidp = drm->dev_private;
-   struct malidp_hw_device *hwdev = malidp->dev;
-
malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK,
  hwdev->hw->map.de_irq_map.irq_mask);
malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK,
@@ -973,11 +970,8 @@ int malidp_se_irq_init(struct drm_device *drm, int irq)
return 0;
 }
 
-void malidp_se_irq_fini(struct drm_device *drm)
+void malidp_se_irq_fini(struct malidp_hw_device *hwdev)
 {
-   struct malidp_drm *malidp = drm->dev_private;
-   struct malidp_hw_device *hwdev = malidp->dev;
-
malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK,
  hwdev->hw->map.se_irq_map.irq_mask);
 }
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index a242e97..6607aba 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -297,9 +297,9 @@ static inline void malidp_hw_enable_irq(struct 
malidp_hw_device *hwdev,
 }
 
 int malidp_de_irq_init(struct drm_device *drm, int irq);
-void malidp_de_irq_fini(struct drm_device *drm);
+void malidp_de_irq_fini(struct malidp_hw_device *hwdev);
 int malidp_se_irq_init(struct drm_device *drm, int irq);
-void malidp_se_irq_fini(struct drm_device *drm);
+void malidp_se_irq_fini(struct malidp_hw_device *hwdev);
 
 u8 malidp_hw_get_format_id(const struct malidp_hw_regmap *map,
   u8 layer_id, u32 format);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v3 3/5] drm/arm/malidp: Enable/disable interrupts in runtime pm

[Ayan Kumar Halder]

Display and scaling engine interrupts need to be disabled when the
runtime pm invokes malidp_runtime_pm_suspend(). Conversely, they
need to be enabled in malidp_runtime_pm_resume().

This patch depends on:
https://lkml.org/lkml/2017/5/15/695

Signed-off-by: Ayan Kumar Halder 
Signed-off-by: Alexandru-Cosmin Gheorghe 
Reported-by: Alexandru-Cosmin Gheorghe 

---
Changes in v3:-
- Abandoned https://patchwork.kernel.org/patch/10357213/ bacause scaling (aka 
writeback) interrupts are enabled or disabled when a commit posts a scene 
with or without writeback framebuffer respectively. This causes an issue in the
following sequence:-
(It is to be noted that scaling engine interrupts are used for writeback)
1. Commit with writeback attached.
2. Before writeback finishes, commit without writeback, which calls 
disable_writeback -> disable scaling interrupts (ie clears the scaling
interrupt mask).
3. Scaling (ie for writeback completion) interrupt is called for commit
 in step 1. However, as the scaling interrupt mask has been cleared by
step 2, so writeback completion is not signalled to userspace app. 
This is a BUG.

Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f7a8beb..983b854 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -470,6 +470,8 @@ static int malidp_runtime_pm_suspend(struct device *dev)
/* we can only suspend if the hardware is in config mode */
WARN_ON(!hwdev->hw->in_config_mode(hwdev));
 
+   malidp_se_irq_fini(hwdev);
+   malidp_de_irq_fini(hwdev);
hwdev->pm_suspended = true;
clk_disable_unprepare(hwdev->mclk);
clk_disable_unprepare(hwdev->aclk);
@@ -488,6 +490,8 @@ static int malidp_runtime_pm_resume(struct device *dev)
clk_prepare_enable(hwdev->aclk);
clk_prepare_enable(hwdev->mclk);
hwdev->pm_suspended = false;
+   malidp_de_irq_hw_init(hwdev);
+   malidp_se_irq_hw_init(hwdev);
 
return 0;
 }
-- 
2.7.4

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

[PATCH v3 0/5] Enhance support for system and runtime power management on malidp.

[Ayan Kumar Halder]

This patch series enhances and fixes certain issues relevant to system and
runtime power management on malidp.

---
Changes in v3:
- Squashed some commits. 
- Fixed an issue related to writeback.
  Reported-by: Alexandru-Cosmin Gheorghe 

Changes in v2:
- Removed the change ids and modified some commit messages

---
Ayan Kumar Halder (5):
  drm/arm/malidp: Modified the prototype of malidp irq de-initializers
  drm/arm/malidp: Split malidp interrupt initialization functions.
  drm/arm/malidp: Enable/disable interrupts in runtime pm
  drm/arm/malidp: Set the output_depth register in modeset
  drm/arm/malidp: Added the late system pm functions

 drivers/gpu/drm/arm/malidp_drv.c | 35 +++
 drivers/gpu/drm/arm/malidp_hw.c  | 52 +++-
 drivers/gpu/drm/arm/malidp_hw.h  |  7 --
 3 files changed, 70 insertions(+), 24 deletions(-)

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

Re: [PATCH v2 1/2] drm/etnaviv: switch MMU page tables to writecombine memory

[Philipp Zabel]

On Tue, 2018-05-08 at 15:23 +0200, Lucas Stach wrote:
> We are likely to write multiple page entries at once and already ensure
> proper write buffer flushing before GPU submit, so this improves CPU
> time usage in the submit path without any downsides.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-intel-next

[Daniel Vetter]

"... should _not_ take this as a personal failure ..." is what I meant
of course. Worst possible oversight :-/
-Daniel

On Tue, May 15, 2018 at 4:58 PM, Daniel Vetter  wrote:
> Imo we should take this as a personal failure of anyone, things
> happen. Instead this is a good opportunity to improve our scripts, to
> make sure we catch this in the future.
>
> Cheers, Daniel
>
> On Tue, May 15, 2018 at 3:16 PM, Wang, Zhi A  wrote:
>> Hi:
>>
>> I am truly sorry for the mess. It's actual my fault of solving a patch 
>> dependency by rebasing. Jani was trying to help me to catch the deadline, I 
>> am very appreciated for Jani's help and I am quite sorry for letting Jani 
>> experience this failure. He tried to help but I fail him. As a new guy of 
>> managing the pull request and maintenance, I need to learn more and improve 
>> our working flow to prevent this happen in future. Sorry for the 
>> inconvenience.
>>
>> Thanks,
>> Zhi.
>>
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, May 15, 2018 12:56 PM
>> To: Dave Airlie 
>> Cc: Daniel Vetter ; Jani Nikula 
>> ; Joonas Lahtinen 
>> ; Vivi, Rodrigo ; 
>> Sean Paul ; Gustavo Padovan ; 
>> Maarten Lankhorst ; 
>> dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; 
>> dim-to...@lists.freedesktop.org; Wang, Zhi A ; Zhenyu 
>> Wang ; Srinivas, Vidya 
>> Subject: [PULL] drm-intel-next
>>
>>
>> Hi Dave -
>>
>> So this one contains the problematic pull from gvt. It's got both a 
>> backmerge and a rebase. I spotted the rebase, but intentionally let it slide 
>> due to the deadline closing, and then completely missed the backmerge. I 
>> don't know what I was thinking. My bad, sorry.
>>
>> We'll need to improve our workflows with the gvt team.
>>
>> Anyway, here's the pull, wrinkles and all, as discussed on IRC. Let us know 
>> if you can tolerate it, or if we need to rewrite history.
>>
>> BR,
>> Jani.
>>
>>
>> PS. Regarding the changelog, Vidya Srinivas  had a 
>> huge role in the NV12 work, but alas I failed to give proper credit because 
>> the patches were based on earlier work by Chandra.
>>
>>
>> drm-intel-next-2018-05-14:
>> Last drm/i915 changes for v4.18:
>>
>> - NV12 enabling (Chandra, Maarten)
>> - ICL workarounds (Oscar)
>> - ICL basic DPLL enabling (Paulo)
>> - GVT updates
>> - DP link config refactoring (Jani)
>> - Module parameter to override DMC firmware (Jani)
>> - PSR updates (José, DK, Daniel, Ville)
>> - ICL DP vswing programming (Manasi)
>> - ICL DBuf slice updates (Mahesh)
>> - Selftest fixes and updates (Chris, Matthew, Oscar)
>> - Execlist fixes and updates (Chris)
>> - Stolen memory first 4k fix (Hans de Goede)
>> - wait_for fixes (Mika)
>> - Tons of GEM improvements (Chris)
>> - Plenty of other fixes and improvements (Everyone)
>> - Crappy changelog (Me)
>>
>> BR,
>> Jani.
>>
>> The following changes since commit 0ab390262c4920f26f8202063a268d5fc829728e:
>>
>>   Merge tag 'drm-misc-next-2018-04-26' of 
>> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-04-30 
>> 09:32:43 +1000)
>>
>> are available in the git repository at:
>>
>>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-05-14
>>
>> for you to fetch changes up to 01f83786f9ab9c8883ce634cb9a0de51086ad7ea:
>>
>>   drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300)
>>
>> 
>> Last drm/i915 changes for v4.18:
>>
>> - NV12 enabling (Chandra, Maarten)
>> - ICL workarounds (Oscar)
>> - ICL basic DPLL enabling (Paulo)
>> - GVT updates
>> - DP link config refactoring (Jani)
>> - Module parameter to override DMC firmware (Jani)
>> - PSR updates (José, DK, Daniel, Ville)
>> - ICL DP vswing programming (Manasi)
>> - ICL DBuf slice updates (Mahesh)
>> - Selftest fixes and updates (Chris, Matthew, Oscar)
>> - Execlist fixes and updates (Chris)
>> - Stolen memory first 4k fix (Hans de Goede)
>> - wait_for fixes (Mika)
>> - Tons of GEM improvements (Chris)
>> - Plenty of other fixes and improvements (Everyone)
>> - Crappy changelog (Me)
>>
>> 
>> Abhay Kumar (1):
>>   drm/i915/audio: set minimum CD clock to twice the BCLK
>>
>> Andy Shevchenko (1):
>>   i915: Convert to use match_string() helper
>>
>> Anusha Srivatsa (1):
>>   drm/i915/firmware: Correct URL for firmware
>>
>> Chandra Konduru (3):
>>   drm/i915: Add NV12 support to intel_framebuffer_init
>>   drm/i915: Add NV12 as supported format for primary plane
>>   drm/i915: Add NV12 as supported format for sprite plane
>>
>> Changbin Du (1):
>>   drm/i915/gvt: 

Re: [PATCH] drm: rcar-du: disable dtc graph-endpoint warnings on DT overlays

[Laurent Pinchart]

Hi Rob,

Thank you for the patch.

On Friday, 11 May 2018 17:33:23 EEST Rob Herring wrote:
> The rcar DT overlays are missing symetrical remote-endpoint properties
> in their graph nodes because the remote-endpoint is fixed up at
> run-time. Disable the dtc 'graph-endpoint' warnings when compiling these
> overlays. If this becomes a common problem for overlays, then perhaps
> this check needs to be disabled for all overlays.
> 
> Reported-by: Stephen Rothwell 
> Cc: Laurent Pinchart 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Rob Herring 

Acked-by: Laurent Pinchart 

> ---
> This needs to go thru my tree because it is dependent on the dtc update
> that adds the warning (perhaps we're going to need to add option
> checking for dtc).
> 
> Rob
> 
>  drivers/gpu/drm/rcar-du/Makefile | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile index 3e58ed93d5b1..2a3b8d7972b5 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -17,3 +17,10 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>  obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
>  obj-$(CONFIG_DRM_RCAR_DW_HDMI)   += rcar_dw_hdmi.o
>  obj-$(CONFIG_DRM_RCAR_LVDS)  += rcar_lvds.o
> +
> +# 'remote-endpoint' is fixed up at run-time
> +DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7791 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7793 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7795 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7796 += -Wno-graph_endpoint


-- 
Regards,

Laurent Pinchart



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

[PATCH] drm: rcar-du: Fix rcar_du_of_init() stub

[Laurent Pinchart]

The rcar_du_of_init() function is supposed to be defined as a stub when
CONFIG_DRM_RCAR_LVDS is disabled as the rcar_du_of.c file isn't compiled
in that case. However, a bug in the configuration option check makes it
a stub when CONFIG_DRM_RCAR_LVDS=m as well, which prevents legacy DTs
from being fixed at boot time. Fix the configuration option check by
using IS_ENABLED.

Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder nodes")
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_of.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.h 
b/drivers/gpu/drm/rcar-du/rcar_du_of.h
index c2e65a727e91..8dd3fbe96650 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_of.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.h
@@ -11,7 +11,7 @@
 
 struct of_device_id;
 
-#ifdef CONFIG_DRM_RCAR_LVDS
+#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS)
 void __init rcar_du_of_init(const struct of_device_id *of_ids);
 #else
 static inline void rcar_du_of_init(const struct of_device_id *of_ids) { }
-- 
Regards,

Laurent Pinchart

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

Re: [PULL] drm-intel-next

[Jani Nikula]

Agreed. Zhi, don't worry about it.

I think the main takeaways here are:

1) We need to improve the dim checks on git pulls. This is both for us
pulling gvt, and now that Dave's experimenting with dim, for him pulling
all the trees.

2) The GVT maintainers should consider using dim too. It would probably
require some tweaking for their needs, but I'm pretty sure the
safeguards would prove helpful.


BR,
Jani.


On Tue, 15 May 2018, Daniel Vetter  wrote:
> Imo we should take this as a personal failure of anyone, things
> happen. Instead this is a good opportunity to improve our scripts, to
> make sure we catch this in the future.
>
> Cheers, Daniel
>
> On Tue, May 15, 2018 at 3:16 PM, Wang, Zhi A  wrote:
>> Hi:
>>
>> I am truly sorry for the mess. It's actual my fault of solving a patch 
>> dependency by rebasing. Jani was trying to help me to catch the deadline, I 
>> am very appreciated for Jani's help and I am quite sorry for letting Jani 
>> experience this failure. He tried to help but I fail him. As a new guy of 
>> managing the pull request and maintenance, I need to learn more and improve 
>> our working flow to prevent this happen in future. Sorry for the 
>> inconvenience.
>>
>> Thanks,
>> Zhi.
>>
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, May 15, 2018 12:56 PM
>> To: Dave Airlie 
>> Cc: Daniel Vetter ; Jani Nikula 
>> ; Joonas Lahtinen 
>> ; Vivi, Rodrigo ; 
>> Sean Paul ; Gustavo Padovan ; 
>> Maarten Lankhorst ; 
>> dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; 
>> dim-to...@lists.freedesktop.org; Wang, Zhi A ; Zhenyu 
>> Wang ; Srinivas, Vidya 
>> Subject: [PULL] drm-intel-next
>>
>>
>> Hi Dave -
>>
>> So this one contains the problematic pull from gvt. It's got both a 
>> backmerge and a rebase. I spotted the rebase, but intentionally let it slide 
>> due to the deadline closing, and then completely missed the backmerge. I 
>> don't know what I was thinking. My bad, sorry.
>>
>> We'll need to improve our workflows with the gvt team.
>>
>> Anyway, here's the pull, wrinkles and all, as discussed on IRC. Let us know 
>> if you can tolerate it, or if we need to rewrite history.
>>
>> BR,
>> Jani.
>>
>>
>> PS. Regarding the changelog, Vidya Srinivas  had a 
>> huge role in the NV12 work, but alas I failed to give proper credit because 
>> the patches were based on earlier work by Chandra.
>>
>>
>> drm-intel-next-2018-05-14:
>> Last drm/i915 changes for v4.18:
>>
>> - NV12 enabling (Chandra, Maarten)
>> - ICL workarounds (Oscar)
>> - ICL basic DPLL enabling (Paulo)
>> - GVT updates
>> - DP link config refactoring (Jani)
>> - Module parameter to override DMC firmware (Jani)
>> - PSR updates (José, DK, Daniel, Ville)
>> - ICL DP vswing programming (Manasi)
>> - ICL DBuf slice updates (Mahesh)
>> - Selftest fixes and updates (Chris, Matthew, Oscar)
>> - Execlist fixes and updates (Chris)
>> - Stolen memory first 4k fix (Hans de Goede)
>> - wait_for fixes (Mika)
>> - Tons of GEM improvements (Chris)
>> - Plenty of other fixes and improvements (Everyone)
>> - Crappy changelog (Me)
>>
>> BR,
>> Jani.
>>
>> The following changes since commit 0ab390262c4920f26f8202063a268d5fc829728e:
>>
>>   Merge tag 'drm-misc-next-2018-04-26' of 
>> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-04-30 
>> 09:32:43 +1000)
>>
>> are available in the git repository at:
>>
>>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-05-14
>>
>> for you to fetch changes up to 01f83786f9ab9c8883ce634cb9a0de51086ad7ea:
>>
>>   drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300)
>>
>> 
>> Last drm/i915 changes for v4.18:
>>
>> - NV12 enabling (Chandra, Maarten)
>> - ICL workarounds (Oscar)
>> - ICL basic DPLL enabling (Paulo)
>> - GVT updates
>> - DP link config refactoring (Jani)
>> - Module parameter to override DMC firmware (Jani)
>> - PSR updates (José, DK, Daniel, Ville)
>> - ICL DP vswing programming (Manasi)
>> - ICL DBuf slice updates (Mahesh)
>> - Selftest fixes and updates (Chris, Matthew, Oscar)
>> - Execlist fixes and updates (Chris)
>> - Stolen memory first 4k fix (Hans de Goede)
>> - wait_for fixes (Mika)
>> - Tons of GEM improvements (Chris)
>> - Plenty of other fixes and improvements (Everyone)
>> - Crappy changelog (Me)
>>
>> 
>> Abhay Kumar (1):
>>   drm/i915/audio: set minimum CD clock to twice the BCLK
>>
>> Andy Shevchenko (1):
>>   i915: Convert to use match_string() helper
>>
>> Anusha Srivatsa (1):
>>   drm/i915/firmware: 

Re: [PATCH] drm: clarify adjusted_mode documentation for bridges

[Philippe CORNU]

Hi,

Applied on drm-misc-next.
Many thanks,
Philippe :-)

On 04/19/2018 07:00 PM, Archit Taneja wrote:
> 
> 
> On Thursday 19 April 2018 09:20 PM, Philippe CORNU wrote:
>> Hi Archit & Andrzej,
>>
>> May I ask you please a short review of this documentation update.
>> Many thanks
>> Philippe :-)
>>
>> On 04/09/2018 05:24 PM, Philippe Cornu wrote:
>>> This patch clarifies the adjusted_mode documentation
>>> for bridges.
>>>
> 
> Reviewed-by: Archit Taneja 
> 
>>> Signed-off-by: Philippe Cornu 
>>> Signed-off-by: Laurent Pinchart 
>>> ---
>>> This patch follows discussions in:
>>> - "drm: clarify adjusted_mode for a bridge connected to a crtc"
>>>  https://patchwork.freedesktop.org/patch/206801/
>>> - "drm: bridge: Constify mode arguments to bridge .mode_set() operation"
>>>  https://patchwork.freedesktop.org/patch/215449/
>>>
>>> include/drm/drm_bridge.h | 16 
>>> include/drm/drm_crtc.h   | 11 +++
>>> 2 files changed, 23 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index 3270fec46979..7d632c6a9214 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -178,6 +178,22 @@ struct drm_bridge_funcs {
>>>  * then this would be _encoder_helper_funcs.mode_set. The 
>>> display
>>>  * pipe (i.e.  clocks and timing signals) is off when this 
>>> function is
>>>  * called.
>>> +*
>>> +* The adjusted_mode parameter corresponds to the mode output by the 
>>> CRTC
>>> +* for the first bridge in the chain. It can be different from the mode
>>> +* parameter that contains the desired mode for the connector at the end
>>> +* of the bridges chain, for instance when the first bridge in the chain
>>> +* performs scaling. The adjusted mode is mostly useful for the first
>>> +* bridge in the chain and is likely irrelevant for the other bridges.
>>> +*
>>> +* For atomic drivers the adjusted_mode is the mode stored in
>>> +* _crtc_state.adjusted_mode.
>>> +*
>>> +* NOTE:
>>> +*
>>> +* If a need arises to store and access modes adjusted for other 
>>> locations
>>> +* than the connection between the CRTC and the first bridge, the DRM
>>> +* framework will have to be extended with DRM bridge states.
>>>  */
>>> void (*mode_set)(struct drm_bridge *bridge,
>>>  struct drm_display_mode *mode,
>>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>>> index a2d81d2907a9..65f749a9e9d3 100644
>>> --- a/include/drm/drm_crtc.h
>>> +++ b/include/drm/drm_crtc.h
>>> @@ -134,10 +134,13 @@ struct drm_crtc_state {
>>>  *
>>>  * Internal display timings which can be used by the driver to 
>>> handle
>>>  * differences between the mode requested by userspace in @mode 
>>> and what
>>> -* is actually programmed into the hardware. It is purely driver
>>> -* implementation defined what exactly this adjusted mode means. Usually
>>> -* it is used to store the hardware display timings used between the
>>> -* CRTC and encoder blocks.
>>> +* is actually programmed into the hardware.
>>> +*
>>> +* For drivers using drm_bridge, this stores the hardware display 
>>> timings
>>> +* used between the CRTC and the first bridge. For other drivers, the
>>> +* meaning of the adjusted_mode field is purely driver implementation
>>> +* defined information, and will usually be used to store the hardware
>>> +* display timings used between the CRTC and encoder blocks.
>>>  */
>>> struct drm_display_mode adjusted_mode;
>>> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

[Laurent Pinchart]

Hello,

On Tuesday, 15 May 2018 17:24:52 EEST kbuild test robot wrote:
> tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head:   c03987223c762e4a61142f0a9be6027bb181cdfa
> commit: 9037d4b98b255979c6636045794775f5a89cc623 [711/734] Merge branch
> 'drm/du/next' of git://linuxtv.org/pinchartl/media into drm-next config:
> arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross chmod +x ~/bin/make.cross
> git checkout 9037d4b98b255979c6636045794775f5a89cc623
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function 
'rcar_du_vsp_plane_atomic_duplicate_state':
> >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct
> >> rcar_du_vsp_plane_state' has no member named 'alpha'
>  copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
>  ^~
>drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:53: error: 'struct
> rcar_du_vsp_plane_state' has no member named 'alpha' copy->alpha =
> to_rcar_vsp_plane_state(plane->state)->alpha;
> ^~

This error is caused by a conflict between commit 75a07f399cd4 (drm: rcar-du: 
Zero-out sg_tables when duplicating plane state) present in my R-Car DU pull 
request sent for the DRM tree and commit 301a9b8d5456 ("drm/rcar-du: Convert 
to the new generic alpha property") present in drm-misc-next but not merged in 
the drm tree yet.

Dave, how would you like to handle this ? I can rebase my drm/du/next branch 
on top of your tree once you merge drm-misc-next and send a new pull request, 
but I'd like to avoid missing the v4.18 merge window. Another option would be 
to handle the error in the drm-misc-next merge. If there's an easier option, 
please let me know how I can help.

> vim +317 drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> 
> 6d62ef3a Laurent Pinchart 2015-09-07  303
> 6d62ef3a Laurent Pinchart 2015-09-07  304  static struct drm_plane_state *
> 6d62ef3a Laurent Pinchart 2015-09-07  305 
> rcar_du_vsp_plane_atomic_duplicate_state(struct drm_plane *plane) 6d62ef3a
> Laurent Pinchart 2015-09-07  306  {
> 6d62ef3a Laurent Pinchart 2015-09-07  307 struct rcar_du_vsp_plane_state
> *copy; 6d62ef3a Laurent Pinchart 2015-09-07  308
> 6d62ef3a Laurent Pinchart 2015-09-07  309 if (WARN_ON(!plane->state))
> 6d62ef3a Laurent Pinchart 2015-09-07  310 return NULL;
> 6d62ef3a Laurent Pinchart 2015-09-07  311
> 75a07f39 Laurent Pinchart 2018-01-17  312 copy = kzalloc(sizeof(*copy),
> GFP_KERNEL); 6d62ef3a Laurent Pinchart 2015-09-07  313if (copy == 
> NULL)
> 6d62ef3a Laurent Pinchart 2015-09-07  314 return NULL;
> 6d62ef3a Laurent Pinchart 2015-09-07  315
> 6d62ef3a Laurent Pinchart 2015-09-07  316 
>   __drm_atomic_helper_plane_duplicate_state(plane, >state); 75a07f39
> Laurent Pinchart 2018-01-17 @317  copy->alpha =
> to_rcar_vsp_plane_state(plane->state)->alpha; 6d62ef3a Laurent Pinchart
> 2015-09-07  318
> 6d62ef3a Laurent Pinchart 2015-09-07  319 return >state;
> 6d62ef3a Laurent Pinchart 2015-09-07  320  }
> 6d62ef3a Laurent Pinchart 2015-09-07  321
> 
> :: The code at line 317 was first introduced by commit
> :: 75a07f399cd43bc7fb41a13723fbe04e61c5c470 drm: rcar-du: Zero-out
> :: sg_tables when duplicating plane state
> :: 
> :: TO: Laurent Pinchart 
> :: CC: Laurent Pinchart 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology
> Center https://lists.01.org/pipermail/kbuild-all   Intel
> Corporation


-- 
Regards,

Laurent Pinchart



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

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Ville Syrjälä]

On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/i915/Kconfig  |  1 +
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>  3 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
>   select SYNC_FILE
>   select IOSF_MBI
>   select CRC32
> + select CEC_CORE if CEC_NOTIFIER
>   help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>   bool has_audio;
>   bool rgb_quant_range_selectable;
>   struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
>  };
>  
>  struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..e98103d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>   connected = true;
>   }
>  
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
>   return connected;
>  }
>  
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
> force)
>  {
>   enum drm_connector_status status;
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>  
>   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
> force)
>  
>   intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>  
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
>   return status;
>  }
>  
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
> *encoder,
>  
>  static void intel_hdmi_destroy(struct drm_connector *connector)
>  {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>   kfree(to_intel_connector(connector)->detect_edid);
>   drm_connector_cleanup(connector);
>   kfree(connector);
> @@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>   I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>   }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);

What are we doing with the connector name here? Those are not actually
guaranteed to be stable, and any change in the connector probe order
may cause the name to change.

> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
>  }
>  
>  void intel_hdmi_init(struct drm_i915_private *dev_priv,
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

[Hans Verkuil]

On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
> 
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
> 
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
> 
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
> 
> Signed-off-by: Neil Armstrong 
> ---



> +static SIMPLE_DEV_PM_OPS(cros_ec_cec_pm_ops,
> + cros_ec_cec_suspend, cros_ec_cec_resume);
> +
> +/*
> + * The Firmware only handles single CEC interface tied to a single HDMI

single CEC -> a single CEC

> + * connector we specify along the DRM device name handling the HDMI output

along -> along with

> + */
> +
> +struct cec_dmi_match {
> + char *sys_vendor;
> + char *product_name;
> + char *devname;
> + char *conn;
> +};
> +

Looks good!

Regards,

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

Re: [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

[Hans Verkuil]

On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
> 
> Signed-off-by: Neil Armstrong 

For what it is worth (not an MFD expert):

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/mfd/cros_ec_dev.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index eafd06f..57064ec 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
> *ec)
>   kfree(msg);
>  }
>  
> +static void cros_ec_cec_register(struct cros_ec_dev *ec)
> +{
> + int ret;
> + struct mfd_cell cec_cell = {
> + .name = "cros-ec-cec",
> + };
> +
> + ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
> + if (ret)
> + dev_err(ec->dev, "failed to add EC CEC\n");
> +}
> +
>  static int ec_device_probe(struct platform_device *pdev)
>  {
>   int retval = -ENOMEM;
> @@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
>   if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
>   cros_ec_sensors_register(ec);
>  
> + /* check whether this EC handles CEC. */
> + if (cros_ec_check_features(ec, EC_FEATURE_CEC))
> + cros_ec_cec_register(ec);
> +
>   /* Take control of the lightbar from the EC. */
>   lb_manual_suspend_ctrl(ec, 1);
>  
> 

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

Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Hans Verkuil]

On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
> 
> Signed-off-by: Stefan Adolfsson 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 42 +
>  include/linux/mfd/cros_ec.h |  2 +-
>  include/linux/mfd/cros_ec_commands.h| 80 
> +
>  3 files changed, 114 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..ba47f79 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,29 +504,53 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>  
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *msg,
> +int version, uint32_t size)
> +{
> + int ret;
> +
> + msg->version = version;
> + msg->command = EC_CMD_GET_NEXT_EVENT;
> + msg->insize = size;
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> + if (ret > 0) {
> + ec_dev->event_size = ret - 1;
> + memcpy(_dev->event_data, msg->data, size);
> + }
> +
> + return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
>   u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>   struct cros_ec_command *msg = (struct cros_ec_command *)
> + static int cmd_version = 1;
>   int ret;
>  
> + BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);

Use the define instead of hardcoding 16. I'm not really sure why you need this.
If cec_message uses the right define for the array size (see my comment below),
then this really can't go wrong, can it?

> +
>   if (ec_dev->suspended) {
>   dev_dbg(ec_dev->dev, "Device suspended.\n");
>   return -EHOSTDOWN;
>   }
>  
> - msg->version = 0;
> - msg->command = EC_CMD_GET_NEXT_EVENT;
> - msg->insize = sizeof(ec_dev->event_data);
> - msg->outsize = 0;
> + if (cmd_version == 1) {
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +   sizeof(ec_dev->event_data));
> + if (ret != EC_RES_INVALID_VERSION)
> + return ret;
>  
> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> - if (ret > 0) {
> - ec_dev->event_size = ret - 1;
> - memcpy(_dev->event_data, msg->data,
> -sizeof(ec_dev->event_data));
> + /* Fallback to version 0 for future send attempts */
> + cmd_version = 0;
>   }
>  
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +   sizeof(struct ec_response_get_next_event));
> +
>   return ret;
>  }
>  
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 2d4e23c..f3415eb 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
>   bool mkbp_event_supported;
>   struct blocking_notifier_head event_notifier;
>  
> - struct ec_response_get_next_event event_data;
> + struct ec_response_get_next_event_v1 event_data;
>   int event_size;
>   u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..18df466 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
>   EC_FEATURE_MOTION_SENSE_FIFO = 24,
>   /* EC has RTC feature that can be controlled by host commands */
>   EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
>  };
>  
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
>   /* EC sent a sysrq command */
>   EC_MKBP_EVENT_SYSRQ = 6,
>  
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
>   /* Number of MKBP events */
>   EC_MKBP_EVENT_COUNT,
>  };
> @@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
>   uint32_t   sysrq;
>  } __packed;
>  
> +union ec_response_get_next_data_v1 {
> + uint8_t   key_matrix[16];
> +
> + /* Unaligned */
> + uint32_t  host_event;
> +
> + uint32_t   buttons;
> + uint32_t   switches;
> + 

[Bug 199693] [bisect 08810a4119aaebf6318f209ec5dd9828e969cba4] (pci runtime) System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

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

Chen Yu (yu.c.c...@intel.com) changed:

   What|Removed |Added

 CC||r...@rjwysocki.net
 Regression|No  |Yes
Summary|System freeze after |[bisect
   |resuming from suspend   |08810a4119aaebf6318f209ec5d
   |(amdgpu)|d9828e969cba4] (pci
   ||runtime) System freeze
   ||after resuming from suspend
   || (amdgpu)

--- Comment #3 from Chen Yu (yu.c.c...@intel.com) ---
It looks like some pci devices(graphic) are not safe to be kept in runtime
suspended when doing suspend/resume.
Add Rafael too.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Hans Verkuil]

On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
> 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/gpu/drm/i915/Kconfig  |  1 +
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>  3 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
>   select SYNC_FILE
>   select IOSF_MBI
>   select CRC32
> + select CEC_CORE if CEC_NOTIFIER
>   help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>   bool has_audio;
>   bool rgb_quant_range_selectable;
>   struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
>  };
>  
>  struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..e98103d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>   connected = true;
>   }
>  
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
>   return connected;
>  }
>  
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
> force)
>  {
>   enum drm_connector_status status;
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>  
>   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
> force)
>  
>   intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>  
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
>   return status;
>  }
>  
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
> *encoder,
>  
>  static void intel_hdmi_destroy(struct drm_connector *connector)
>  {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>   kfree(to_intel_connector(connector)->detect_edid);
>   drm_connector_cleanup(connector);
>   kfree(connector);
> @@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>   I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>   }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
>  }
>  
>  void intel_hdmi_init(struct drm_i915_private *dev_priv,
> 

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

Re: [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

[Hans Verkuil]

On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
> 
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
> 
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.

The patch looks good, but I'm curious about this paragraph above.

Was this tested with devices with more than one HDMI output? Or only on
laptops with a single physical HDMI output? If there are two or more
outputs then I guess it is the HW designer that decides with output gets
CEC support?

Regards,

Hans

> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/media/cec/cec-notifier.c | 11 ---
>  include/media/cec-notifier.h | 27 ---
>  2 files changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/cec/cec-notifier.c 
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..dd2078b 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
>   struct list_head head;
>   struct kref kref;
>   struct device *dev;
> + const char *conn;
>   struct cec_adapter *cec_adap;
>   void (*callback)(struct cec_adapter *adap, u16 pa);
>  
> @@ -30,13 +31,14 @@ struct cec_notifier {
>  static LIST_HEAD(cec_notifiers);
>  static DEFINE_MUTEX(cec_notifiers_lock);
>  
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char 
> *conn)
>  {
>   struct cec_notifier *n;
>  
>   mutex_lock(_notifiers_lock);
>   list_for_each_entry(n, _notifiers, head) {
> - if (n->dev == dev) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
>   kref_get(>kref);
>   mutex_unlock(_notifiers_lock);
>   return n;
> @@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>   if (!n)
>   goto unlock;
>   n->dev = dev;
> + if (conn)
> + n->conn = kstrdup(conn, GFP_KERNEL);
>   n->phys_addr = CEC_PHYS_ADDR_INVALID;
>   mutex_init(>lock);
>   kref_init(>kref);
> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>   mutex_unlock(_notifiers_lock);
>   return n;
>  }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>  
>  static void cec_notifier_release(struct kref *kref)
>  {
> @@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
>   container_of(kref, struct cec_notifier, kref);
>  
>   list_del(>head);
> + kfree(n->conn);
>   kfree(n);
>  }
>  
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..814eeef 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,8 +20,10 @@ struct cec_notifier;
>  #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>  
>  /**
> - * cec_notifier_get - find or create a new cec_notifier for the given device.
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
>   * @dev: device that sends the events.
> + * @conn: the connector name from which the event occurs
>   *
>   * If a notifier for device @dev already exists, then increase the refcount
>   * and return that notifier.
> @@ -31,7 +33,8 @@ struct cec_notifier;
>   *
>   * Return NULL if the memory could not be allocated.
>   */
> -struct cec_notifier *cec_notifier_get(struct device *dev);
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> +const char *conn);
>  
>  /**
>   * cec_notifier_put - decrease refcount and delete when the refcount reaches 
> 0.
> @@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
>  struct cec_notifier *notifier);
>  
>  #else
> -static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> +  const char *conn)
>  {
>   /* A non-NULL pointer is expected on success */
>   return (struct cec_notifier *)0xdeadfeed;
> @@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct 
> cec_adapter *adap,
>  #endif
>  
>  /**
> + * cec_notifier_get - find or create a new cec_notifier for the given device.
> + * @dev: device that sends the events.
> + *
> + * If a notifier for device @dev already exists, then increase the refcount

[Bug 106529] Kernels 4.16+ confuse KDE wrt what the primary display is when waking up multiple displays

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #139577|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106529] Kernels 4.16+ confuse KDE wrt what the primary display is when waking up multiple displays

[bugzilla-daemon]

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

Mariusz Mazur  changed:

   What|Removed |Added

Summary|Kernels 4.16+ confuses KDE  |Kernels 4.16+ confuse KDE
   |wrt what the primary|wrt what the primary
   |display is when waking up   |display is when waking up
   |multiple displays   |multiple displays

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106529] Kernels 4.16+ confuses KDE wrt what the primary display is when waking up multiple displays

[bugzilla-daemon]

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

Bug ID: 106529
   Summary: Kernels 4.16+ confuses KDE wrt what the primary
display is when waking up multiple displays
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mariusz.g.ma...@gmail.com

Created attachment 139577
  --> https://bugs.freedesktop.org/attachment.cgi?id=139577=edit
ubuntu's 4.15 dmesg with amdgpu.dc_log=1

It appears that the display-handling code in 4.15+ (including 4.17-rc5) marks
any display not fully woken up as disconnected or something to that effect. So
when I have multiple monitors and they get woken up from sleep (doesn't matter
whether the computer was suspended or just idle for a long period), and my
primary display wakes up slower than the any of the other displays (and it
does), then for a few hundred ms KDE tries to change the primary display to the
one that first woke up (I'm guessing it thinks that's the only one available),
then changes its mind a bit later, when all displays wake up.

End result looks like crap and is not usable, since all my windows get
displaced. Here's how it looks like in practice:

Setup:
Radeon RX 560
Primary display: bottom right, displayport, on
Secondary display 1: left, hdmi, on
Secondary display 2: top right, dvi, off

Video of how it used to work, using 4.4.15:
https://www.youtube.com/watch?v=h7nMYbm5ZxU
Note how even though the left (secondary) display wakes up first, both
instantly display their proper desktops.

Video of how it works with ubuntu 18.04's default 4.15 kernel/4.16.7/4.17-rc5:
https://www.youtube.com/watch?v=VdVFNXPszSI
Note how when the left (secondary) display wakes up first, KDE decides that
this is probably the only display available, so tries to switch the primary
desktop to it, then a split second later the bottom right wakes up and KDE
knows *that* should be the primary according to the config, so it switches
back.

Attached is dmesg from ubuntu's 4.15 with dc_log=1. I put the computer to
sleep, then wake it up and get the behavior like in the video.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-intel-next

[Daniel Vetter]

Imo we should take this as a personal failure of anyone, things
happen. Instead this is a good opportunity to improve our scripts, to
make sure we catch this in the future.

Cheers, Daniel

On Tue, May 15, 2018 at 3:16 PM, Wang, Zhi A  wrote:
> Hi:
>
> I am truly sorry for the mess. It's actual my fault of solving a patch 
> dependency by rebasing. Jani was trying to help me to catch the deadline, I 
> am very appreciated for Jani's help and I am quite sorry for letting Jani 
> experience this failure. He tried to help but I fail him. As a new guy of 
> managing the pull request and maintenance, I need to learn more and improve 
> our working flow to prevent this happen in future. Sorry for the 
> inconvenience.
>
> Thanks,
> Zhi.
>
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, May 15, 2018 12:56 PM
> To: Dave Airlie 
> Cc: Daniel Vetter ; Jani Nikula 
> ; Joonas Lahtinen 
> ; Vivi, Rodrigo ; 
> Sean Paul ; Gustavo Padovan ; 
> Maarten Lankhorst ; 
> dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; 
> dim-to...@lists.freedesktop.org; Wang, Zhi A ; Zhenyu 
> Wang ; Srinivas, Vidya 
> Subject: [PULL] drm-intel-next
>
>
> Hi Dave -
>
> So this one contains the problematic pull from gvt. It's got both a backmerge 
> and a rebase. I spotted the rebase, but intentionally let it slide due to the 
> deadline closing, and then completely missed the backmerge. I don't know what 
> I was thinking. My bad, sorry.
>
> We'll need to improve our workflows with the gvt team.
>
> Anyway, here's the pull, wrinkles and all, as discussed on IRC. Let us know 
> if you can tolerate it, or if we need to rewrite history.
>
> BR,
> Jani.
>
>
> PS. Regarding the changelog, Vidya Srinivas  had a 
> huge role in the NV12 work, but alas I failed to give proper credit because 
> the patches were based on earlier work by Chandra.
>
>
> drm-intel-next-2018-05-14:
> Last drm/i915 changes for v4.18:
>
> - NV12 enabling (Chandra, Maarten)
> - ICL workarounds (Oscar)
> - ICL basic DPLL enabling (Paulo)
> - GVT updates
> - DP link config refactoring (Jani)
> - Module parameter to override DMC firmware (Jani)
> - PSR updates (José, DK, Daniel, Ville)
> - ICL DP vswing programming (Manasi)
> - ICL DBuf slice updates (Mahesh)
> - Selftest fixes and updates (Chris, Matthew, Oscar)
> - Execlist fixes and updates (Chris)
> - Stolen memory first 4k fix (Hans de Goede)
> - wait_for fixes (Mika)
> - Tons of GEM improvements (Chris)
> - Plenty of other fixes and improvements (Everyone)
> - Crappy changelog (Me)
>
> BR,
> Jani.
>
> The following changes since commit 0ab390262c4920f26f8202063a268d5fc829728e:
>
>   Merge tag 'drm-misc-next-2018-04-26' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-04-30 09:32:43 
> +1000)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-05-14
>
> for you to fetch changes up to 01f83786f9ab9c8883ce634cb9a0de51086ad7ea:
>
>   drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300)
>
> 
> Last drm/i915 changes for v4.18:
>
> - NV12 enabling (Chandra, Maarten)
> - ICL workarounds (Oscar)
> - ICL basic DPLL enabling (Paulo)
> - GVT updates
> - DP link config refactoring (Jani)
> - Module parameter to override DMC firmware (Jani)
> - PSR updates (José, DK, Daniel, Ville)
> - ICL DP vswing programming (Manasi)
> - ICL DBuf slice updates (Mahesh)
> - Selftest fixes and updates (Chris, Matthew, Oscar)
> - Execlist fixes and updates (Chris)
> - Stolen memory first 4k fix (Hans de Goede)
> - wait_for fixes (Mika)
> - Tons of GEM improvements (Chris)
> - Plenty of other fixes and improvements (Everyone)
> - Crappy changelog (Me)
>
> 
> Abhay Kumar (1):
>   drm/i915/audio: set minimum CD clock to twice the BCLK
>
> Andy Shevchenko (1):
>   i915: Convert to use match_string() helper
>
> Anusha Srivatsa (1):
>   drm/i915/firmware: Correct URL for firmware
>
> Chandra Konduru (3):
>   drm/i915: Add NV12 support to intel_framebuffer_init
>   drm/i915: Add NV12 as supported format for primary plane
>   drm/i915: Add NV12 as supported format for sprite plane
>
> Changbin Du (1):
>   drm/i915/gvt: Remove disable_warn_untrack and print untracked mmio with 
> debug level
>
> Chris Wilson (53):
>   drm/i915: Check whitelist registers across resets
>   drm/i915: Call i915_perf_fini() on init_hw error unwind
>   drm/i915: Move the priotree struct to its own headers
>   drm/i915: Rename priotree to sched
>   

Re: [PATCH v2 11/11] docs: fix broken references with multiple hints

[Steven Rostedt]

On Wed,  9 May 2018 10:18:54 -0300
Mauro Carvalho Chehab  wrote:


> diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
> index 7b6b1236ec2e..c292117b83a9 100644
> --- a/Documentation/trace/events.rst
> +++ b/Documentation/trace/events.rst
> @@ -8,7 +8,7 @@ Event Tracing
>  1. Introduction
>  ===
>  
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used
> +Tracepoints (see Documentation/trace/tracepoints.rst) can be used
>  without creating custom kernel modules to register probe functions
>  using the event tracing infrastructure.
>  
> diff --git a/Documentation/trace/tracepoint-analysis.rst 
> b/Documentation/trace/tracepoint-analysis.rst
> index b0c9c21f129d..716326b9f152 100644
> --- a/Documentation/trace/tracepoint-analysis.rst
> +++ b/Documentation/trace/tracepoint-analysis.rst
> @@ -6,7 +6,7 @@ Notes on Analysing Behaviour Using Events and Tracepoints
>  1. Introduction
>  ===
>  
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used without
> +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without
>  creating custom kernel modules to register probe functions using the event
>  tracing infrastructure.
>  

> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index c94f466d57ef..19a690b559ca 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -4,7 +4,7 @@
>  /*
>   * Kernel Tracepoint API.
>   *
> - * See Documentation/trace/tracepoints.txt.
> + * See Documentation/trace/tracepoints.rst.
>   *
>   * Copyright (C) 2008-2014 Mathieu Desnoyers 
>   *

Acked-by: Steven Rostedt (VMware) 

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

[PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

[Neil Armstrong]

The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.

This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.

The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.

The controller will be tied to the HDMI CEC notifier by using the platform
DMI Data and the i915 device name and connector name.

Signed-off-by: Neil Armstrong 
---
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cros-ec-cec/Makefile  |   1 +
 drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 335 +++
 4 files changed, 349 insertions(+)
 create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
 create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..e55a8ed2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config VIDEO_CROS_EC_CEC
+   tristate "Chrome OS EC CEC driver"
+   depends on MFD_CROS_EC || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ If you say yes here you will get support for the
+ Chrome OS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..830696f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
 obj-y  += meson/
+
+obj-y  += cros-ec-cec/
diff --git a/drivers/media/platform/cros-ec-cec/Makefile 
b/drivers/media/platform/cros-ec-cec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c 
b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
new file mode 100644
index 000..aed3368
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rx_msg: storage for a received message
+ */
+struct cros_ec_cec {
+   struct cros_ec_device *cros_ec;
+   struct notifier_block notifier;
+   struct cec_adapter *adap;
+   struct cec_notifier *notify;
+   struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+   uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+   unsigned int len = cros_ec->event_size;
+
+   cros_ec_cec->rx_msg.len = len;
+   memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+   cec_received_msg(cros_ec_cec->adap, _ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+   uint32_t events = cros_ec->event_data.data.cec_events;
+
+   if (events & EC_MKBP_CEC_SEND_OK)
+   cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+   /* FW takes care of all retries, tell core to avoid more retries */
+   if (events & EC_MKBP_CEC_SEND_FAILED)
+   cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+   struct cros_ec_cec *cros_ec_cec;
+   struct cros_ec_device *cros_ec;
+
+   cros_ec_cec = container_of(nb, struct cros_ec_cec, notifier);
+ 

[PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

[Neil Armstrong]

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.

Signed-off-by: Neil Armstrong 
---
 drivers/mfd/cros_ec_dev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index eafd06f..57064ec 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
kfree(msg);
 }
 
+static void cros_ec_cec_register(struct cros_ec_dev *ec)
+{
+   int ret;
+   struct mfd_cell cec_cell = {
+   .name = "cros-ec-cec",
+   };
+
+   ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
+   if (ret)
+   dev_err(ec->dev, "failed to add EC CEC\n");
+}
+
 static int ec_device_probe(struct platform_device *pdev)
 {
int retval = -ENOMEM;
@@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
 
+   /* check whether this EC handles CEC. */
+   if (cros_ec_check_features(ec, EC_FEATURE_CEC))
+   cros_ec_cec_register(ec);
+
/* Take control of the lightbar from the EC. */
lb_manual_suspend_ctrl(ec, 1);
 
-- 
2.7.4

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

[PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Neil Armstrong]

The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.

Signed-off-by: Stefan Adolfsson 
Signed-off-by: Neil Armstrong 
---
 drivers/platform/chrome/cros_ec_proto.c | 42 +
 include/linux/mfd/cros_ec.h |  2 +-
 include/linux/mfd/cros_ec_commands.h| 80 +
 3 files changed, 114 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..ba47f79 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,29 +504,53 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
 }
 EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
 
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+  struct cros_ec_command *msg,
+  int version, uint32_t size)
+{
+   int ret;
+
+   msg->version = version;
+   msg->command = EC_CMD_GET_NEXT_EVENT;
+   msg->insize = size;
+   msg->outsize = 0;
+
+   ret = cros_ec_cmd_xfer(ec_dev, msg);
+   if (ret > 0) {
+   ec_dev->event_size = ret - 1;
+   memcpy(_dev->event_data, msg->data, size);
+   }
+
+   return ret;
+}
+
 static int get_next_event(struct cros_ec_device *ec_dev)
 {
u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
struct cros_ec_command *msg = (struct cros_ec_command *)
+   static int cmd_version = 1;
int ret;
 
+   BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
if (ec_dev->suspended) {
dev_dbg(ec_dev->dev, "Device suspended.\n");
return -EHOSTDOWN;
}
 
-   msg->version = 0;
-   msg->command = EC_CMD_GET_NEXT_EVENT;
-   msg->insize = sizeof(ec_dev->event_data);
-   msg->outsize = 0;
+   if (cmd_version == 1) {
+   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(ec_dev->event_data));
+   if (ret != EC_RES_INVALID_VERSION)
+   return ret;
 
-   ret = cros_ec_cmd_xfer(ec_dev, msg);
-   if (ret > 0) {
-   ec_dev->event_size = ret - 1;
-   memcpy(_dev->event_data, msg->data,
-  sizeof(ec_dev->event_data));
+   /* Fallback to version 0 for future send attempts */
+   cmd_version = 0;
}
 
+   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event));
+
return ret;
 }
 
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2d4e23c..f3415eb 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
bool mkbp_event_supported;
struct blocking_notifier_head event_notifier;
 
-   struct ec_response_get_next_event event_data;
+   struct ec_response_get_next_event_v1 event_data;
int event_size;
u32 host_event_wake_mask;
 };
diff --git a/include/linux/mfd/cros_ec_commands.h 
b/include/linux/mfd/cros_ec_commands.h
index f2edd99..18df466 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
EC_FEATURE_MOTION_SENSE_FIFO = 24,
/* EC has RTC feature that can be controlled by host commands */
EC_FEATURE_RTC = 27,
+   /* EC supports CEC commands */
+   EC_FEATURE_CEC = 35,
 };
 
 #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
/* EC sent a sysrq command */
EC_MKBP_EVENT_SYSRQ = 6,
 
+   /* Notify the AP that something happened on CEC */
+   EC_MKBP_CEC_EVENT = 8,
+
+   /* Send an incoming CEC message to the AP */
+   EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
 };
@@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
uint32_t   sysrq;
 } __packed;
 
+union ec_response_get_next_data_v1 {
+   uint8_t   key_matrix[16];
+
+   /* Unaligned */
+   uint32_t  host_event;
+
+   uint32_t   buttons;
+   uint32_t   switches;
+   uint32_t   sysrq;
+   uint32_t   cec_events;
+   uint8_tcec_message[16];
+} __packed;
+
 struct ec_response_get_next_event {
uint8_t event_type;
/* Followed by event data if any */
union ec_response_get_next_data data;
 } __packed;
 
+struct ec_response_get_next_event_v1 {
+   uint8_t event_type;
+   /* Followed by event data if any */
+   

[PATCH v2 0/5] Add ChromeOS EC CEC Support

[Neil Armstrong]

Hi All,

The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device registration in the ChromeOS EC MFD Driver
- Add the CEC related commands and events definitions into the EC MFD driver
- Add a way to get a CEC notifier with it's (optional) connector name
- Add the CEC notifier to the i915 HDMI driver
- Add the proper ChromeOS EC CEC Driver

The CEC notifier with the connector name is the tricky point, since even on
Device-Tree platforms, there is no way to distinguish between multiple HDMI
connectors from the same DRM driver. The solution I implemented is pretty
simple and only adds an optional connector name to eventually distinguish
an HDMI connector notifier from another if they share the same device.

Feel free to comment this patchset !

Changes since v1:
 - Added cec_notifier_put to intel_hdmi
 - Fixed all small reported issues on the EC CEC driver
 - Moved the cec_notifier_get out of the #if .. #else .. #endif

Changes since RFC:
 - Moved CEC sub-device registration after CEC commands and events definitions 
patch
 - Removed get_notifier_get_byname
 - Added CEC_CORE select into i915 Kconfig
 - Removed CEC driver fallback if notifier is not configured on HW, added 
explicit warn
 - Fixed CEC core return type on error
 - Moved to cros-ec-cec media platform directory
 - Use bus_find_device() to find the pci i915 device instead of 
get_notifier_get_byname()
 - Fix Logical Address setup
 - Added comment about HW support
 - Removed memset of msg structures

Neil Armstrong (5):
  media: cec-notifier: Get notifier by device and connector name
  drm/i915: hdmi: add CEC notifier to intel_hdmi
  mfd: cros-ec: Introduce CEC commands and events definitions.
  mfd: cros_ec_dev: Add CEC sub-device registration
  media: platform: Add Chrome OS EC CEC driver

 drivers/gpu/drm/i915/Kconfig |   1 +
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c|  12 +
 drivers/media/cec/cec-notifier.c |  11 +-
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cros-ec-cec/Makefile  |   1 +
 drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 335 +++
 drivers/mfd/cros_ec_dev.c|  16 ++
 drivers/platform/chrome/cros_ec_proto.c  |  42 ++-
 include/linux/mfd/cros_ec.h  |   2 +-
 include/linux/mfd/cros_ec_commands.h |  80 ++
 include/media/cec-notifier.h |  27 +-
 13 files changed, 526 insertions(+), 16 deletions(-)
 create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
 create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c

-- 
2.7.4

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

[PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/i915/Kconfig  |  1 +
 drivers/gpu/drm/i915/intel_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 12 
 3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd9588..2d65d56 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
select SYNC_FILE
select IOSF_MBI
select CRC32
+   select CEC_CORE if CEC_NOTIFIER
help
  Choose this option if you have a system that has "Intel Graphics
  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
+   struct cec_notifier *notifier;
 };
 
 struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..e98103d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
connected = true;
}
 
+   cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
+
return connected;
 }
 
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 {
enum drm_connector_status status;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
+
return status;
 }
 
@@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder,
 
 static void intel_hdmi_destroy(struct drm_connector *connector)
 {
+   if (intel_attached_hdmi(connector)->notifier)
+   cec_notifier_put(intel_attached_hdmi(connector)->notifier);
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
kfree(connector);
@@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
+
+   intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

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

[PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

[Neil Armstrong]

In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.

This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.

But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.

Signed-off-by: Neil Armstrong 
---
 drivers/media/cec/cec-notifier.c | 11 ---
 include/media/cec-notifier.h | 27 ---
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..dd2078b 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *dev;
+   const char *conn;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
 
@@ -30,13 +31,14 @@ struct cec_notifier {
 static LIST_HEAD(cec_notifiers);
 static DEFINE_MUTEX(cec_notifiers_lock);
 
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char 
*conn)
 {
struct cec_notifier *n;
 
mutex_lock(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_notifiers_lock);
return n;
@@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
if (!n)
goto unlock;
n->dev = dev;
+   if (conn)
+   n->conn = kstrdup(conn, GFP_KERNEL);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_notifiers_lock);
return n;
 }
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
 
 static void cec_notifier_release(struct kref *kref)
 {
@@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
container_of(kref, struct cec_notifier, kref);
 
list_del(>head);
+   kfree(n->conn);
kfree(n);
 }
 
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..814eeef 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,8 +20,10 @@ struct cec_notifier;
 #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
 
 /**
- * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
  * @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
  *
  * If a notifier for device @dev already exists, then increase the refcount
  * and return that notifier.
@@ -31,7 +33,8 @@ struct cec_notifier;
  *
  * Return NULL if the memory could not be allocated.
  */
-struct cec_notifier *cec_notifier_get(struct device *dev);
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+  const char *conn);
 
 /**
  * cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
   struct cec_notifier *notifier);
 
 #else
-static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+const char *conn)
 {
/* A non-NULL pointer is expected on success */
return (struct cec_notifier *)0xdeadfeed;
@@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct 
cec_adapter *adap,
 #endif
 
 /**
+ * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * @dev: device that sends the events.
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+   return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
  * cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
  *
  * @n: the CEC notifier
-- 
2.7.4

___
dri-devel mailing list

[drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   c03987223c762e4a61142f0a9be6027bb181cdfa
commit: 9037d4b98b255979c6636045794775f5a89cc623 [711/734] Merge branch 
'drm/du/next' of git://linuxtv.org/pinchartl/media into drm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 9037d4b98b255979c6636045794775f5a89cc623
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function 
'rcar_du_vsp_plane_atomic_duplicate_state':
>> drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct 
>> rcar_du_vsp_plane_state' has no member named 'alpha'
 copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
 ^~
   drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:53: error: 'struct 
rcar_du_vsp_plane_state' has no member named 'alpha'
 copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
^~

vim +317 drivers/gpu/drm/rcar-du/rcar_du_vsp.c

6d62ef3a Laurent Pinchart 2015-09-07  303  
6d62ef3a Laurent Pinchart 2015-09-07  304  static struct drm_plane_state *
6d62ef3a Laurent Pinchart 2015-09-07  305  
rcar_du_vsp_plane_atomic_duplicate_state(struct drm_plane *plane)
6d62ef3a Laurent Pinchart 2015-09-07  306  {
6d62ef3a Laurent Pinchart 2015-09-07  307   struct rcar_du_vsp_plane_state 
*copy;
6d62ef3a Laurent Pinchart 2015-09-07  308  
6d62ef3a Laurent Pinchart 2015-09-07  309   if (WARN_ON(!plane->state))
6d62ef3a Laurent Pinchart 2015-09-07  310   return NULL;
6d62ef3a Laurent Pinchart 2015-09-07  311  
75a07f39 Laurent Pinchart 2018-01-17  312   copy = kzalloc(sizeof(*copy), 
GFP_KERNEL);
6d62ef3a Laurent Pinchart 2015-09-07  313   if (copy == NULL)
6d62ef3a Laurent Pinchart 2015-09-07  314   return NULL;
6d62ef3a Laurent Pinchart 2015-09-07  315  
6d62ef3a Laurent Pinchart 2015-09-07  316   
__drm_atomic_helper_plane_duplicate_state(plane, >state);
75a07f39 Laurent Pinchart 2018-01-17 @317   copy->alpha = 
to_rcar_vsp_plane_state(plane->state)->alpha;
6d62ef3a Laurent Pinchart 2015-09-07  318  
6d62ef3a Laurent Pinchart 2015-09-07  319   return >state;
6d62ef3a Laurent Pinchart 2015-09-07  320  }
6d62ef3a Laurent Pinchart 2015-09-07  321  

:: The code at line 317 was first introduced by commit
:: 75a07f399cd43bc7fb41a13723fbe04e61c5c470 drm: rcar-du: Zero-out 
sg_tables when duplicating plane state

:: TO: Laurent Pinchart 
:: CC: Laurent Pinchart 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

Hi,

On 15/05/2018 14:56, Hans Verkuil wrote:
> On 05/15/18 14:46, Neil Armstrong wrote:
>> This patchs adds the cec_notifier feature to the intel_hdmi part
>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>> between each HDMI ports.
>> The changes will allow the i915 HDMI code to notify EDID and HPD changes
>> to an eventual CEC adapter.
> 
> You haven't figured yet out where to place the cec_notifier_put() call?
> Or did you forget?

I just figured it out, I was busy on the CEC driver and notifier, will re-spin 
a v2 with this and the other small fixes you requested.

Thanks,
Neil

> 
> Regards,
> 
>   Hans
> 
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/i915/Kconfig  |  1 +
>>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>>  drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
>>  3 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index dfd9588..2d65d56 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -23,6 +23,7 @@ config DRM_I915
>>  select SYNC_FILE
>>  select IOSF_MBI
>>  select CRC32
>> +select CEC_CORE if CEC_NOTIFIER
>>  help
>>Choose this option if you have a system that has "Intel Graphics
>>Media Accelerator" or "HD Graphics" integrated graphics,
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index d436858..b50e51b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -39,6 +39,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /**
>>   * __wait_for - magic wait macro
>> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>>  bool has_audio;
>>  bool rgb_quant_range_selectable;
>>  struct intel_connector *attached_connector;
>> +struct cec_notifier *notifier;
>>  };
>>  
>>  struct intel_dp_mst_encoder;
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 1baef4a..9b94d72 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>>  connected = true;
>>  }
>>  
>> +cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
>> +
>>  return connected;
>>  }
>>  
>> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, 
>> bool force)
>>  {
>>  enum drm_connector_status status;
>>  struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> +struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>>  
>>  DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>connector->base.id, connector->name);
>> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, 
>> bool force)
>>  
>>  intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>>  
>> +if (status != connector_status_connected)
>> +cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
>> +
>>  return status;
>>  }
>>  
>> @@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct 
>> intel_digital_port *intel_dig_port,
>>  u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>>  I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>>  }
>> +
>> +intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
>> +if (!intel_hdmi->notifier)
>> +DRM_DEBUG_KMS("CEC notifier get failed\n");
>>  }
>>  
>>  void intel_hdmi_init(struct drm_i915_private *dev_priv,
>>
> 

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

[Bug 106527] OpenCL corrupted memory on AMD R9 280X

[bugzilla-daemon]

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

Bug ID: 106527
   Summary: OpenCL corrupted memory on AMD R9 280X
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: riccardodema...@gmail.com

I am trying to use the AMD R9 280X (Tahiti) with the latest Ubuntu 18.04 and
AMDGPU-PRO driver.

OpenCL appears to work with 

export GPU_FORCE_64BIT_PTR=1

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

however the memory appears corrupted on the device resulting in random data
populating partially or entirely the buffers.

A simple OpenCL program is sufficient to show the problem:

https://github.com/rdemaria/opencl_simpletest

in my case.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 2/2] i915: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.

This requires also manipulationg ITC bit, as stated in
HDMI spec.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

v10:
 * Added usage description to HDMI properties kernel doc.

v11:
 * Created centralized function for filling HDMI AVI infoframe, based
   on correspondent DRM property value.

Acked-by: Hans Verkuil 
Acked-by: Daniel Vetter 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c   | 18 --
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..61ddb5871d8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..c12f7a18df11 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -460,8 +460,10 @@ static void intel_write_infoframe(struct drm_encoder 
*encoder,
intel_dig_port->write_infoframe(encoder, crtc_state, frame->any.type, 
buffer, len);
 }
 
+
 static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
-const struct intel_crtc_state 
*crtc_state)
+const struct intel_crtc_state 
*crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
const struct drm_display_mode *adjusted_mode =
@@ -491,6 +493,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   drm_hdmi_avi_infoframe_content_type(,
+   conn_state);
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -586,7 +591,7 @@ static void g4x_set_infoframes(struct drm_encoder *encoder,
I915_WRITE(reg, val);
POSTING_READ(reg);
 
-   intel_hdmi_set_avi_infoframe(encoder, crtc_state);
+   intel_hdmi_set_avi_infoframe(encoder, crtc_state, conn_state);
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state, conn_state);
 }
@@ -727,7 +732,7 @@ static void ibx_set_infoframes(struct drm_encoder *encoder,
I915_WRITE(reg, val);
POSTING_READ(reg);
 
-   

[PATCH v11 1/2] drm: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

v10:
 * Added usage description to HDMI properties kernel doc.

v11:
 * Created centralized function for filling HDMI AVI infoframe, based
   on correspondent DRM property value.

Acked-by: Hans Verkuil 
Acked-by: Daniel Vetter 
Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/drm-kms.rst|   6 ++
 Documentation/gpu/kms-properties.csv |   1 +
 drivers/gpu/drm/drm_atomic.c |   4 +
 drivers/gpu/drm/drm_connector.c  | 115 +++
 drivers/gpu/drm/drm_edid.c   |   8 ++
 include/drm/drm_connector.h  |  15 
 include/drm/drm_mode_config.h|   5 ++
 include/uapi/drm/drm_mode.h  |   7 ++
 8 files changed, 161 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1dffd1ac4cd4..e233c2626bd0 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -517,6 +517,12 @@ Standard Connector Properties
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: standard connector properties
 
+HDMI Specific Connector Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: HDMI connector properties
+
 Plane Composition Properties
 
 
diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 07ed22ea3bd6..bfde04eddd14 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3d9ae057a6cd..6c1e1e774517 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1270,6 +1270,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;