[drm-intel:for-linux-next 4/5] include/linux/compiler.h:529:38: error: call to '__compiletime_assert_1626' declared with attribute error: BUILD_BUG_ON failed: (fast_timeout_us) > 50000

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   bea4e4a4f831df1c104be60b3caa7205ba1bb4f9
commit: 1d1a9774e40414148ecebbdb713746bfb6f9a561 [4/5] drm/i915: Extend 
intel_wait_for_register_fw() with fast timeout
config: x86_64-randconfig-h0-04080942 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 1d1a9774e40414148ecebbdb713746bfb6f9a561
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/drm/drm.h:41,
from include/uapi/drm/i915_drm.h:30,
from drivers/gpu/drm/i915/i915_drv.h:33,
from drivers/gpu/drm/i915/intel_uncore.c:24:
   drivers/gpu/drm/i915/intel_uncore.c: In function 
'__intel_wait_for_register_fw':
>> include/linux/compiler.h:529:38: error: call to '__compiletime_assert_1626' 
>> declared with attribute error: BUILD_BUG_ON failed: (fast_timeout_us) > 5
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:512:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^
   include/linux/compiler.h:529:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^
>> drivers/gpu/drm/i915/intel_drv.h:91:2: note: in expansion of macro 
>> 'BUILD_BUG_ON'
 BUILD_BUG_ON((US) > 5); \
 ^
>> drivers/gpu/drm/i915/intel_uncore.c:1626:9: note: in expansion of macro 
>> '_wait_for_atomic'
  ret = _wait_for_atomic(done, fast_timeout_us, 0);
^

vim +/__compiletime_assert_1626 +529 include/linux/compiler.h

9a8ab1c3 Daniel Santos  2013-02-21  523   *
9a8ab1c3 Daniel Santos  2013-02-21  524   * In tradition of POSIX assert, this 
macro will break the build if the
9a8ab1c3 Daniel Santos  2013-02-21  525   * supplied condition is *false*, 
emitting the supplied error message if the
9a8ab1c3 Daniel Santos  2013-02-21  526   * compiler has support to do so.
9a8ab1c3 Daniel Santos  2013-02-21  527   */
9a8ab1c3 Daniel Santos  2013-02-21  528  #define compiletime_assert(condition, 
msg) \
9a8ab1c3 Daniel Santos  2013-02-21 @529 _compiletime_assert(condition, 
msg, __compiletime_assert_, __LINE__)
9a8ab1c3 Daniel Santos  2013-02-21  530  
47933ad4 Peter Zijlstra 2013-11-06  531  #define 
compiletime_assert_atomic_type(t)  \
47933ad4 Peter Zijlstra 2013-11-06  532 
compiletime_assert(__native_word(t),\

:: The code at line 529 was first introduced by commit
:: 9a8ab1c39970a4938a72d94e6fd13be88a797590 bug.h, compiler.h: introduce 
compiletime_assert & BUILD_BUG_ON_MSG

:: TO: Daniel Santos 
:: CC: Linus Torvalds 

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

drm-tip/drm-tip boot: 119 boots: 3 failed, 115 passed with 1 offline (v4.11-rc5-1802-g2d286312feeb)

[kernelci . org bot]

drm-tip/drm-tip boot: 119 boots: 3 failed, 115 passed with 1 offline 
(v4.11-rc5-1802-g2d286312feeb)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1802-g2d286312feeb/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1802-g2d286312feeb/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1802-g2d286312feeb
Git Commit: 2d286312feebdb0f9957929732e228dab644ef7a
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 17 unique boards, 10 SoC families, 23 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

allmodconfig+CONFIG_OF=n
minnowboard-max: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99515] SIGSEGV MAPERR on Android nougat-x86 with mesa 17.0.0rc

[bugzilla-daemon]

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

Mauro Rossi  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Mauro Rossi  ---
Hi,

commit ce27b27 "radeon: initialize hole variable before calling container_of"
solves the issue and should be backported to mesa 13.0 and mesa 17.0 branches
to have this bug resolved in next maintenance releases.

Tested with nougat-x86 on HD7750 and HD7950

Mauro

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

drm-tip/drm-tip boot: 120 boots: 3 failed, 115 passed with 2 offline (v4.11-rc5-1801-gc9c537bbdea4)

[kernelci . org bot]

drm-tip/drm-tip boot: 120 boots: 3 failed, 115 passed with 2 offline 
(v4.11-rc5-1801-gc9c537bbdea4)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1801-gc9c537bbdea4/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1801-gc9c537bbdea4/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1801-gc9c537bbdea4
Git Commit: c9c537bbdea40e52ffd1e144edd3a915f8e8572f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 17 unique boards, 10 SoC families, 26 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

allmodconfig+CONFIG_OF=n:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100616] With Radeon HD 8550M system freezes when running 3D application

[bugzilla-daemon]

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

--- Comment #1 from Arham Amouei  ---
I also tried

DRI_PRIME=1 glxgears

It doesn't freeze, but shows nothing.

-- 
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 100614] GPU HANG: ecode 9:0:0xef9ffffd, in chrome [1777], reason: Ring hung, action: reset

[bugzilla-daemon]

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

raviky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

-- 
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 100616] With Radeon HD 8550M system freezes when running 3D application

[bugzilla-daemon]

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

Bug ID: 100616
   Summary: With Radeon HD 8550M system freezes when running 3D
application
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: erham...@yahoo.com

Created attachment 130753
  --> https://bugs.freedesktop.org/attachment.cgi?id=130753=edit
dmesg output

My laptop has hybrid graphics.

Output of "lspci | grep AMD":

"0a:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun LE
[Radeon HD 8550M / R5 M230] (rev ff)"

I use an application called "Visual Molecular Dynamics", which opens an OpenGL
window and renders 3D images. There is no problem when using the integrated
GPU. But when I run the application using DRI_PRIME=1, the system freezes when
the OpenGL window is being opened. I need to use the dedicated GPU, because the
integrated GPU isn't powerful enough for my work.

OS: Ubuntu 16.04 64bit, with last updates

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

drm-tip/drm-tip boot: 117 boots: 5 failed, 111 passed with 1 offline (v4.11-rc5-1799-ge0a6f97889aa)

[kernelci . org bot]

drm-tip/drm-tip boot: 117 boots: 5 failed, 111 passed with 1 offline 
(v4.11-rc5-1799-ge0a6f97889aa)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1799-ge0a6f97889aa/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1799-ge0a6f97889aa/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1799-ge0a6f97889aa
Git Commit: e0a6f97889aa13307cd9112c1a7c6be7f7114f9b
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 17 unique boards, 10 SoC families, 27 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5422-odroidxu3:
lab-collabora: new failure (last pass: v4.11-rc5-1780-g7373a000996b)

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

allmodconfig+CONFIG_OF=n
minnowboard-max: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
exynos5422-odroidxu3: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:for-linux-next 4/5] drivers/gpu//drm/i915/intel_uncore.c:1626: error: call to '__compiletime_assert_1626' declared with attribute error: BUILD_BUG_ON failed: (fast_timeout_us) > 50000

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   bea4e4a4f831df1c104be60b3caa7205ba1bb4f9
commit: 1d1a9774e40414148ecebbdb713746bfb6f9a561 [4/5] drm/i915: Extend 
intel_wait_for_register_fw() with fast timeout
config: x86_64-randconfig-s1-04080500 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 1d1a9774e40414148ecebbdb713746bfb6f9a561
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/intel_uncore.c: In function 
'__intel_wait_for_register_fw':
>> drivers/gpu//drm/i915/intel_uncore.c:1626: error: call to 
>> '__compiletime_assert_1626' declared with attribute error: BUILD_BUG_ON 
>> failed: (fast_timeout_us) > 5

vim +/__compiletime_assert_1626 +1626 drivers/gpu//drm/i915/intel_uncore.c

  1620  #define done (((reg_value = I915_READ_FW(reg)) & mask) == value)
  1621  int ret;
  1622  
  1623  if (fast_timeout_us > 10)
  1624  ret = _wait_for(done, fast_timeout_us, 10);
  1625  else
> 1626  ret = _wait_for_atomic(done, fast_timeout_us, 0);
  1627  if (ret)
  1628  ret = wait_for(done, slow_timeout_ms);
  1629  if (out_value)

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

[PATCH v2] dma-buf: Implement simple read/write vfs ops

[Chris Wilson]

It is expected that processes will pass dma-buf fd between drivers, and
only using the fd themselves for mmaping and synchronisation ioctls.
However, it may be convenient for an application to read/write into the
dma-buf, for instance a test case to check the internal
dma_buf->ops->kmap interface. There may also be a small advantage to
avoiding the mmap() for very simple/small operations.

Note in particular, synchronisation with the device is left to the
caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
inside the read/write, so that the user can avoid synchronisation if
they so choose.

v2: Lots of little fixes, plus a real llseek() implements so that the
first basic little test cases work!

Testcase: igt/prime_rw
Signed-off-by: Chris Wilson 
Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 drivers/dma-buf/dma-buf.c | 108 +++---
 1 file changed, 93 insertions(+), 15 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 1ce7974a28a3..6e6e35c660c7 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -100,28 +100,104 @@ static int dma_buf_mmap_internal(struct file *file, 
struct vm_area_struct *vma)
 
 static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
 {
-   struct dma_buf *dmabuf;
-   loff_t base;
+   struct dma_buf *dmabuf = file->private_data;
 
if (!is_dma_buf_file(file))
return -EBADF;
 
-   dmabuf = file->private_data;
+   return fixed_size_llseek(file, offset, whence, dmabuf->size);
+}
 
-   /* only support discovering the end of the buffer,
-  but also allow SEEK_SET to maintain the idiomatic
-  SEEK_END(0), SEEK_CUR(0) pattern */
-   if (whence == SEEK_END)
-   base = dmabuf->size;
-   else if (whence == SEEK_SET)
-   base = 0;
-   else
-   return -EINVAL;
+static ssize_t dma_buf_read(struct file *file,
+   char __user *ubuf, size_t remain,
+   loff_t *offset)
+{
+   struct dma_buf *dmabuf = file->private_data;
+   unsigned long idx;
+   unsigned int start;
+   size_t total;
 
-   if (offset != 0)
-   return -EINVAL;
+   if (!is_dma_buf_file(file))
+   return -EBADF;
+
+   total = 0;
+   idx = *offset >> PAGE_SHIFT;
+   start = offset_in_page(*offset);
+   while (remain) {
+   unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+   unsigned int copied;
+   void *vaddr;
+
+   if (*offset >= dmabuf->size)
+   return total;
+
+   vaddr = dma_buf_kmap(dmabuf, idx);
+   if (!vaddr)
+   return total ?: -EIO;
+
+   copied = copy_to_user(ubuf, vaddr + start, len);
+   dma_buf_kunmap(dmabuf, idx, vaddr);
+
+   total += copied ?: len;
+   if (copied) {
+   *offset += copied;
+   return total ?: -EFAULT;
+   }
+
+   remain -= len;
+   *offset += len;
+   ubuf += len;
+   start = 0;
+   idx++;
+   }
+
+   return total;
+}
+
+static ssize_t dma_buf_write(struct file *file,
+const char __user *ubuf, size_t remain,
+loff_t *offset)
+{
+   struct dma_buf *dmabuf = file->private_data;
+   unsigned long idx;
+   unsigned int start;
+   size_t total;
+
+   if (!is_dma_buf_file(file))
+   return -EBADF;
+
+   total = 0;
+   idx = *offset >> PAGE_SHIFT;
+   start = offset_in_page(*offset);
+   while (remain) {
+   unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+   unsigned int copied;
+   void *vaddr;
+
+   if (*offset >= dmabuf->size)
+   return total;
+
+   vaddr = dma_buf_kmap(dmabuf, idx);
+   if (!vaddr)
+   return total ?: -EIO;
+
+   copied = copy_from_user(vaddr + start, ubuf, len);
+   dma_buf_kunmap(dmabuf, idx, vaddr);
+
+   total += copied ?: len;
+   if (copied) {
+   *offset += copied;
+   return total ?: -EFAULT;
+   }
+
+   remain -= len;
+   *offset += len;
+   ubuf += len;
+   start = 0;
+   idx++;
+   }
 
-   return base + offset;
+   return total;
 }
 
 /**
@@ -318,6 +394,8 @@ static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
   

Re: [RFC PATCH 2/2] drm/vgem: Enable dmabuf import interfaces

[Daniel Vetter]

On Fri, Apr 07, 2017 at 10:58:47AM -0700, Laura Abbott wrote:
> On 04/07/2017 09:58 AM, Chris Wilson wrote:
> > On Fri, Apr 07, 2017 at 09:18:30AM -0700, Laura Abbott wrote:
> >> On 04/07/2017 12:39 AM, Chris Wilson wrote:
> >>> On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
> 
>  Enable the GEM dma-buf import interfaces in addition to the export
>  interfaces. This lets vgem be used as a test source for other allocators
>  (e.g. Ion).
> 
>  +int vgem_gem_get_pages(struct drm_vgem_gem_object *obj)
>  +{
>  +struct page **pages;
>  +
>  +if (obj->pages)
>  +return 0;
>  +
>  +pages = drm_gem_get_pages(>base);
>  +if (IS_ERR(pages)) {
>  +return PTR_ERR(pages);
>  +}
>  +
>  +obj->pages = pages;
> >>>
> >>> That's a significant loss in functionality (it requires the entire
> >>> object to fit into physical memory at the same time and requires a large
> >>> vmalloc for 32b systems), for what? vgem only has the ability to mmap
> >>> and export a fd -- both of which you already have if you have the dmabuf
> >>> fd. The only extra interface is the signaling, which does not yet have a
> >>> direct correspondence on dmabuf.
> >>>
> >>> (An obvious way to keep both would be to move the get_pages to importing
> >>> and then differentiate in the faulthandler where to get the page from.)
> >>>
> >>
> >> Thanks for pointing this out. I'll look to keep the existing behavior.
> >>
> >>> Can you provide more details on how you are using vgem to justify the
> >>> changes? I'm also not particularly happy in losing testing of a virtual
> >>> platform device from our CI.
> >>> -Chris
> >>>
> >>
> >> There exists a test module in the Ion directory
> >> (drivers/staging/android/ion/ion_test.c) today but it's not actually
> >> Ion specific. It registers a platform device and then provides an
> >> ioctl interface to perform a dma_buf attach and map. I proposed
> >> moving this to a generic dma-buf test module
> >> (https://marc.info/?l=dri-devel=148952187004611=2) and Daniel
> >> suggested that this was roughly what vgem was supposed to do.
> > 
> > mmap(dma_buf_fd) gives you DMA_BUF_IOC_TEST_DMA_MAPPING, and that's the
> > only facility already available via vgem.
> > 
> 
> Not completely. It's possible to mmap a dma_buf fd without being
> attached to any device (the source of many caching headaches). Part of
> the goal is to verify that the attachment and map callbacks are
> working as expected.
> 
> > DMA_BUF_IOC_TEST_KERNEL_MAPPING would be equivalent to
> > read/write(dma_buf_fd).
> > 
> >> Adding the import methods for vgem covers all of what the
> >> Ion test was doing and we don't have to invent yet another ioctl
> >> interface and framework for attaching and mapping. 
> > 
> > I don't think it does :)
> > 
> > To muddy the waters further, I've also done something similar:
> > https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
> > https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c
> > 
> 
> Those do look familiar :)
> 
> > But this feels like a good enough reason for implementing read/write ops
> > for the dma-buf fd, and then we can test the dma_buf->ops->kmap on i915
> > as well, directly from i915.ko. Sounds fun, I'll see if I can cook
> > something up - and we can then see if that suits your testing as well.
> >  
> >> Can you clarify about what you mean about 'virtual platform device'?
> > 
> > vgem_device = drm_dev_alloc(_driver, NULL);
> > 
> > helps exercise some more corner cases of the drm core, that we have
> > unwittingly broken in the past.
> 
> Okay thanks for the explanation. I was debating putting the platform
> support behind a configuration option. I don't know if that would
> actually solve anything or just result in another configuration that
> doesn't get tested.

We could do both still, the drm core doesn't care about the device, it's
only used to place it in the right directoy in sysfs (well, minus the bugs
Chris mentioned). So having a NULL device for drm_dev_alloc while still
storing that fake platform device somewhere should be all fine (if we need
that fake platform dev for dma-buf testing).
-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

Re: [PULL] Last drm-misc-next pull for 4.12

[Sean Paul]

On Fri, Apr 07, 2017 at 04:58:54PM -0400, Sean Paul wrote:
> Hi Dave,
> Here's the last 4.12 pull request for drm-misc-next. It's quite noisy due to 
> us

Hi drm-misc committers,
Just a note that any fixes targetting 4.12 should now go through 
drm-misc-next-fixes
as drm-misc-next is moving on.

Sean

> pulling back rc5 in order to pick up some Synopsys media formats that we added
> in conjunction with Mauro.
> 
> drm-misc-next-2017-04-07:
> Last drm-misc-next pull req for 4.12
> 
> Core changes:
>  - fb_helper checkpatch cleanup and simplified _add_one_connector() (Thierry)
>  - drm_ioctl and drm_sysfs improved/gained documentation (Daniel)
>  - [ABI] Repurpose reserved field in drm_event_vblank for crtc_id (Ander)
>  - Plumb acquire ctx through legacy paths to avoid lock_all and legacy_backoff
>(Daniel)
>  - Add connector_atomic_check to check conn constraints on modeset (Maarten)
>  - Add drm_of_find_panel_or_bridge to remove boilerplate in drivers (Rob)
> 
> Driver changes:
>  - meson moved to drm-misc (Neil)
>  - Added support for Amlogic GX SoCs in dw-hdmi (Neil)
>  - Rockchip unbind actually cleans up the things bind initializes (Jeffy)
>  - A couple misc fixes in virtio, dw-hdmi
> 
> NOTE: this also includes a backmerge of drm-next as well rc5 (we needed vmwgfx
>   as well as the new synopsys media formats)
> 
> 
> Happy weekend,
> 
> Sean
> 
> 
> The following changes since commit e1b489d207c73e67810659a88c45b8db4bd62773:
> 
>   Merge tag 'omapdrm-4.12' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next 
> (2017-04-04 05:45:49 +1000)
> 
> are available in the git repository at:
> 
>   git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-04-07
> 
> for you to fetch changes up to c98cdff94a6a7877923dec1329c2b76d6247d076:
> 
>   Revert "drm: Don't allow interruptions when opening debugfs/crc" 
> (2017-04-07 16:18:28 -0400)
> 
> 
> Last drm-misc-next pull req for 4.12
> 
> Core changes:
>  - fb_helper checkpatch cleanup and simplified _add_one_connector() (Thierry)
>  - drm_ioctl and drm_sysfs improved/gained documentation (Daniel)
>  - [ABI] Repurpose reserved field in drm_event_vblank for crtc_id (Ander)
>  - Plumb acquire ctx through legacy paths to avoid lock_all and legacy_backoff
>(Daniel)
>  - Add connector_atomic_check to check conn constraints on modeset (Maarten)
>  - Add drm_of_find_panel_or_bridge to remove boilerplate in drivers (Rob)
> 
> Driver changes:
>  - meson moved to drm-misc (Neil)
>  - Added support for Amlogic GX SoCs in dw-hdmi (Neil)
>  - Rockchip unbind actually cleans up the things bind initializes (Jeffy)
>  - A couple misc fixes in virtio, dw-hdmi
> 
> NOTE: this also includes a backmerge of drm-next as well rc5 (we needed vmwgfx
>   as well as the new synopsys media formats)
> 
> 
> Aaron Armstrong Skomra (2):
>   HID: wacom: Don't add ghost interface as shared data
>   HID: wacom: call _query_tablet_data() for BAMBOO_TOUCH
> 
> Adam Wallis (1):
>   xhci: plat: Register shutdown for xhci_plat
> 
> Alan Stern (1):
>   USB: fix linked-list corruption in rh_call_control()
> 
> Alex Williamson (1):
>   drm/i915/kvmgt: Hold struct kvm reference
> 
> Alexander Kochetkov (2):
>   clockevents: Fix syntax error in clkevt-of macro
>   vmlinux.lds: Add __clkevt_of_table to kernel
> 
> Alexey Brodkin (2):
>   ARC: vdk: Fix support of UIO
>   ARCv2: SLC: Make sure busy bit is set properly on SLC flushing
> 
> Ander Conselvan de Oliveira (1):
>   drm: Pass CRTC ID in userspace vblank events
> 
> Andrzej Hajda (1):
>   pinctrl: samsung: Fix memory mapping code
> 
> Andy Adamson (3):
>   NFS cleanup struct nfs4_filelayout_segment
>   NFS store nfs4_deviceid in struct nfs4_filelayout_segment
>   NFS filelayout:call GETDEVICEINFO after pnfs_layout_process completes
> 
> Andy Shevchenko (1):
>   Revert "i2c: mux: pca954x: Add ACPI support for pca954x"
> 
> Andy Whitcroft (2):
>   xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
>   xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder
> 
> Arnaud Pouliquen (1):
>   ASoC: STI: Fix reader substream pointer set
> 
> Arnd Bergmann (4):
>   ASoC: mediatek: add I2C dependency for CS42XX8
>   irqchip/mvebu-odmi: Select GENERIC_MSI_IRQ_DOMAIN
>   scsi: lpfc: fix building without debugfs support
>   virtio_balloon: prevent uninitialized variable use
> 
> Baoquan He (1):
>   x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization
> 
> Bard Liao (6):
>   ASoC: rt5665: fix getting wrong work handler container
>   ASoC: rt5665: increase LDO level
>   ASoC: rt5665: Vref3 is necessary for Mono Amp
>   ASoC: rt5665: CLKDET is also a power of ASRC
>   ASoC: rt5665: fix define of RT5665_HP_DRIVER_5X
>   ASoC: rt5665: fix 

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1802-g2d286312feeb)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1802-g2d286312feeb)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1802-g2d286312feeb/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1802-g2d286312feeb
Git Commit: 2d286312feebdb0f9957929732e228dab644ef7a
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

drm-tip/drm-tip boot: 114 boots: 2 failed, 112 passed (v4.11-rc5-1786-g50ff2d4f1de4)

[kernelci . org bot]

drm-tip/drm-tip boot: 114 boots: 2 failed, 112 passed 
(v4.11-rc5-1786-g50ff2d4f1de4)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1786-g50ff2d4f1de4/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1786-g50ff2d4f1de4/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1786-g50ff2d4f1de4
Git Commit: 50ff2d4f1de470b3ceb6f716a3f57c46f9d57d27
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 17 unique boards, 10 SoC families, 21 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5422-odroidxu3:
lab-collabora: failing since 1 day (last pass: 
v4.11-rc5-1643-ge087f8395ca3 - first fail: v4.11-rc5-1782-g71610c69d4f3)

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
exynos5422-odroidxu3: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] Last drm-misc-next pull for 4.12

[Sean Paul]

Hi Dave,
Here's the last 4.12 pull request for drm-misc-next. It's quite noisy due to us
pulling back rc5 in order to pick up some Synopsys media formats that we added
in conjunction with Mauro.

drm-misc-next-2017-04-07:
Last drm-misc-next pull req for 4.12

Core changes:
 - fb_helper checkpatch cleanup and simplified _add_one_connector() (Thierry)
 - drm_ioctl and drm_sysfs improved/gained documentation (Daniel)
 - [ABI] Repurpose reserved field in drm_event_vblank for crtc_id (Ander)
 - Plumb acquire ctx through legacy paths to avoid lock_all and legacy_backoff
   (Daniel)
 - Add connector_atomic_check to check conn constraints on modeset (Maarten)
 - Add drm_of_find_panel_or_bridge to remove boilerplate in drivers (Rob)

Driver changes:
 - meson moved to drm-misc (Neil)
 - Added support for Amlogic GX SoCs in dw-hdmi (Neil)
 - Rockchip unbind actually cleans up the things bind initializes (Jeffy)
 - A couple misc fixes in virtio, dw-hdmi

NOTE: this also includes a backmerge of drm-next as well rc5 (we needed vmwgfx
  as well as the new synopsys media formats)


Happy weekend,

Sean


The following changes since commit e1b489d207c73e67810659a88c45b8db4bd62773:

  Merge tag 'omapdrm-4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next 
(2017-04-04 05:45:49 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-04-07

for you to fetch changes up to c98cdff94a6a7877923dec1329c2b76d6247d076:

  Revert "drm: Don't allow interruptions when opening debugfs/crc" (2017-04-07 
16:18:28 -0400)


Last drm-misc-next pull req for 4.12

Core changes:
 - fb_helper checkpatch cleanup and simplified _add_one_connector() (Thierry)
 - drm_ioctl and drm_sysfs improved/gained documentation (Daniel)
 - [ABI] Repurpose reserved field in drm_event_vblank for crtc_id (Ander)
 - Plumb acquire ctx through legacy paths to avoid lock_all and legacy_backoff
   (Daniel)
 - Add connector_atomic_check to check conn constraints on modeset (Maarten)
 - Add drm_of_find_panel_or_bridge to remove boilerplate in drivers (Rob)

Driver changes:
 - meson moved to drm-misc (Neil)
 - Added support for Amlogic GX SoCs in dw-hdmi (Neil)
 - Rockchip unbind actually cleans up the things bind initializes (Jeffy)
 - A couple misc fixes in virtio, dw-hdmi

NOTE: this also includes a backmerge of drm-next as well rc5 (we needed vmwgfx
  as well as the new synopsys media formats)


Aaron Armstrong Skomra (2):
  HID: wacom: Don't add ghost interface as shared data
  HID: wacom: call _query_tablet_data() for BAMBOO_TOUCH

Adam Wallis (1):
  xhci: plat: Register shutdown for xhci_plat

Alan Stern (1):
  USB: fix linked-list corruption in rh_call_control()

Alex Williamson (1):
  drm/i915/kvmgt: Hold struct kvm reference

Alexander Kochetkov (2):
  clockevents: Fix syntax error in clkevt-of macro
  vmlinux.lds: Add __clkevt_of_table to kernel

Alexey Brodkin (2):
  ARC: vdk: Fix support of UIO
  ARCv2: SLC: Make sure busy bit is set properly on SLC flushing

Ander Conselvan de Oliveira (1):
  drm: Pass CRTC ID in userspace vblank events

Andrzej Hajda (1):
  pinctrl: samsung: Fix memory mapping code

Andy Adamson (3):
  NFS cleanup struct nfs4_filelayout_segment
  NFS store nfs4_deviceid in struct nfs4_filelayout_segment
  NFS filelayout:call GETDEVICEINFO after pnfs_layout_process completes

Andy Shevchenko (1):
  Revert "i2c: mux: pca954x: Add ACPI support for pca954x"

Andy Whitcroft (2):
  xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
  xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder

Arnaud Pouliquen (1):
  ASoC: STI: Fix reader substream pointer set

Arnd Bergmann (4):
  ASoC: mediatek: add I2C dependency for CS42XX8
  irqchip/mvebu-odmi: Select GENERIC_MSI_IRQ_DOMAIN
  scsi: lpfc: fix building without debugfs support
  virtio_balloon: prevent uninitialized variable use

Baoquan He (1):
  x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization

Bard Liao (6):
  ASoC: rt5665: fix getting wrong work handler container
  ASoC: rt5665: increase LDO level
  ASoC: rt5665: Vref3 is necessary for Mono Amp
  ASoC: rt5665: CLKDET is also a power of ASRC
  ASoC: rt5665: fix define of RT5665_HP_DRIVER_5X
  ASoC: rt5665: fix wrong shift rt5665_if2_1_adc_in_enum

Bart Van Assche (3):
  scsi: scsi_dh_alua: Check scsi_device_get() return value
  scsi: scsi_dh_alua: Ensure that alua_activate() calls the completion 
function
  scsi: scsi_dh_alua: Warn if the first argument of alua_rtpg_queue() is 
NULL

Benjamin Coddington (1):
  NFS: Fix old dentry rehash after move

Bill Kuzeja (1):
  scsi: qla2xxx: Fix crash in qla2xxx_eh_abort on bad ptr

Bjorn Andersson (1):
 

[Bug 195231] Continuous messages of "*ERROR* UVD not responding, trying to reset the VCPU!!!" and frozen screen

[bugzilla-daemon]

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

--- Comment #10 from rbr...@gmail.com ---
Dear Alex and other developers,

On Thu, Apr 6, 2017 at 1:03 AM,   wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=195231
>
> --- Comment #9 from Rogério Brito (rbr...@ime.usp.br) ---
> (In reply to Alex Deucher from comment #2)
>> Please attach your xorg log and dmesg output.  Does appending radeon.runpm=0
>> on the kernel command line in grub help?
>
> Dear Alex and other developers, do you need any extra information from me? I
> will do my best to gather anything that may be helpful in fixing this bug.

I just installed Ubuntu's precompiled and unpatched kernel 4.11-rc5
and the messages of "UVD not responding" like in the subject persist,
also with the whole system hanging.

If I append radeon.runpm=0, the system does boot, but the messages are
still there. It is, though, taking ages to boot, compared to what it
used to be.

Once again, if anybody wants me to try any kernel, just tell me and I
will do my best.

I will update the information that I grab and/or those that people ask
me and put those at this bug on bugzilla
(https://bugzilla.kernel.org/show_bug.cgi?id=195231).


Thanks,

Rogério.

-- 
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 100614] GPU HANG: ecode 9:0:0xef9ffffd, in chrome [1777], reason: Ring hung, action: reset

[bugzilla-daemon]

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

Bug ID: 100614
   Summary: GPU HANG: ecode 9:0:0xef9d, in chrome [1777],
reason: Ring hung, action: reset
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ravi4tab...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 130752
  --> https://bugs.freedesktop.org/attachment.cgi?id=130752=edit
GPU crash dump saved to /sys/class/drm/card0/error

Encountered GPU hang on Chromebook while doing Google hangouts + video(youtube)
+ few (5) tabs opened simultaneously. Reproducility is nearly 20% but requires
overnight to reproduce this issue.

GPU crash dump saved to /sys/class/drm/card0/error and logs are attached.

Kernel log says:
2017-03-26T15:51:27.709098-07:00 INFO kernel: [ 8104.736419] [drm] stuck on
render ring
2017-03-26T15:51:27.709145-07:00 INFO kernel: [ 8104.737420] [drm] GPU HANG:
ecode 9:0:0xef9d, in chrome [1869], reason: Ring hung, action: reset
2017-03-26T15:51:27.709150-07:00 INFO kernel: [ 8104.737439] [drm] GPU hangs
can indicate a bug anywhere in the entire gfx stack, including userspace.


Few more details:
>From "change_card0_drm.20170406.193114.0.log" attachment, I saw it suffered GPU
command (MI_STORE_DATA_IMM) blocked in render ring and guess some batch buffers
from mesa cause this issue.
...
0x01028a90:  0x7a04: PIPE_CONTROL: no write, no depth stall, no RC
write flush, no inst flush
0x01028a94:  0x00101001:destination address
0x01028a98:  0x0080:immediate dword low
0x01028a9c:  0x:immediate dword high
0x01028aa8:  0x1042: MI_STORE_DATA_IMM 

[Bug 195283] amdgpu: desktop freezes with wine-staging and FS2002

[bugzilla-daemon]

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

fin4...@hotmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #2 from fin4...@hotmail.com ---
It was Mesa bug that is fixed in Oibaf ppa uploaded 2 hours ago.Game works ok
as before.

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

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings (v4.11-rc5-1801-gc9c537bbdea4)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings 
(v4.11-rc5-1801-gc9c537bbdea4)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1801-gc9c537bbdea4/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1801-gc9c537bbdea4
Git Commit: c9c537bbdea40e52ffd1e144edd3a915f8e8572f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

[pull] radeon and amdgpu drm-next-4.12

[Alex Deucher]

Hi Dave,

Just some bug fixes and vega10 updates for 4.12.

The following changes since commit 0168778115687486575a6831df865dbc4f5369fe:

  Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-04-07 05:49:12 +1000)

are available in the git repository at:

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

for you to fetch changes up to 32df87dff04833bbf53f1750f6c6048192ed29bf:

  drm/amdgpu: fix fence memory leak in wait_all_fence V2 (2017-04-07 15:15:45 
-0400)


Alex Deucher (1):
  drm/radeon: fix typo in bandwidth calculation

Christian König (1):
  drm/amdgpu: fix "fix 64bit division"

Christopher James Halse Rogers (5):
  drm/radeon: Fail fb creation from imported dma-bufs.
  drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
  drm/amdgpu: Refuse to pin or change acceptable domains of prime BOs to 
VRAM. (v2)
  drm/radeon: Maintain prime import/export refcount for BOs
  drm/radeon: Refuse to migrate a prime BO to VRAM. (v2)

Chunming Zhou (1):
  drm/amdgpu: fix fence memory leak in wait_all_fence V2

Junwei Zhang (1):
  drm/amdgpu: set vm size and block size by individual gmc by default (v3)

Mario Kleiner (2):
  drm/amdgpu: Make display watermark calculations more accurate
  drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark 
calculations.

Rex Zhu (2):
  drm/amd/powerplay: port newest process pptable code for vega10.
  drm/amd/powerplay: add fan controller table v11 support.

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  31 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|   5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  38 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   1 +
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  29 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  29 +-
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |  29 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  29 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  16 +-
 .../gpu/drm/amd/powerplay/hwmgr/vega10_pptable.h   |  50 
 .../amd/powerplay/hwmgr/vega10_processpptables.c   | 324 +++--
 .../amd/powerplay/hwmgr/vega10_processpptables.h   |  28 ++
 drivers/gpu/drm/radeon/r100.c  |   2 +-
 drivers/gpu/drm/radeon/radeon.h|   1 +
 drivers/gpu/drm/radeon/radeon_cs.c |  10 +
 drivers/gpu/drm/radeon/radeon_display.c|   6 +
 drivers/gpu/drm/radeon/radeon_gem.c|   4 +
 drivers/gpu/drm/radeon/radeon_object.c |   5 +
 drivers/gpu/drm/radeon/radeon_prime.c  |   6 +
 27 files changed, 455 insertions(+), 220 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm-tip/drm-tip boot: 115 boots: 4 failed, 110 passed with 1 offline (v4.11-rc5-1785-g5a74def41941)

[kernelci . org bot]

drm-tip/drm-tip boot: 115 boots: 4 failed, 110 passed with 1 offline 
(v4.11-rc5-1785-g5a74def41941)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1785-g5a74def41941/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1785-g5a74def41941/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1785-g5a74def41941
Git Commit: 5a74def419415233546c4e853a3f02bb31daee82
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 16 unique boards, 9 SoC families, 25 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

allmodconfig+CONFIG_OF=n
minnowboard-max: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: Implement simple read/write vfs ops

[Chris Wilson]

It is expected that processes will pass dma-buf fd between drivers, and
only using the fd themselves for mmaping and synchronisation ioctls.
However, it may be convenient for an application to read/write into the
dma-buf, for instance a test case to check the internal
dma_buf->ops->kmap interface. There may also be a small advantage to
avoiding the mmap() for very simple/small operations.

Note in particular, synchronisation with the device is left to the
caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
inside the read/write, so that the user can avoid synchronisation if
they so choose.

Signed-off-by: Chris Wilson 
Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 drivers/dma-buf/dma-buf.c | 88 +++
 1 file changed, 88 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 1ce7974a28a3..e4388d5258ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -124,6 +124,92 @@ static loff_t dma_buf_llseek(struct file *file, loff_t 
offset, int whence)
return base + offset;
 }
 
+static ssize_t dma_buf_read(struct file *file,
+   char __user *ubuf, size_t remain,
+   loff_t *offset)
+{
+   struct dma_buf *dmabuf = file->private_data;
+   unsigned long idx;
+   unsigned int start;
+   size_t written;
+
+   if (!is_dma_buf_file(file))
+   return -EBADF;
+
+   written = 0;
+   idx = *offset >> PAGE_SHIFT;
+   start = offset_in_page(*offset);
+   while (remain) {
+   unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+   unsigned int copied;
+   void *vaddr;
+
+   vaddr = dma_buf_kmap(dmabuf, idx);
+   if (!vaddr)
+   return written ?: -EIO;
+
+   copied = copy_to_user(vaddr, ubuf, len);
+   dma_buf_kunmap(dmabuf, idx, vaddr);
+
+   written += copied ?: len;
+   if (copied) {
+   *offset += copied;
+   return written ?: -EFAULT;
+   }
+
+   remain -= len;
+   *offset += len;
+   ubuf += len;
+   start = 0;
+   idx++;
+   }
+
+   return written;
+}
+
+static ssize_t dma_buf_write(struct file *file,
+const char __user *ubuf, size_t remain,
+loff_t *offset)
+{
+   struct dma_buf *dmabuf = file->private_data;
+   unsigned long idx;
+   unsigned int start;
+   size_t written;
+
+   if (!is_dma_buf_file(file))
+   return -EBADF;
+
+   written = 0;
+   idx = *offset >> PAGE_SHIFT;
+   start = offset_in_page(*offset);
+   while (remain) {
+   unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+   unsigned int copied;
+   void *vaddr;
+
+   vaddr = dma_buf_kmap(dmabuf, idx);
+   if (!vaddr)
+   return written ?: -EIO;
+
+   copied = copy_from_user(vaddr, ubuf, len);
+   dma_buf_kunmap(dmabuf, idx, vaddr);
+
+   written += copied ?: len;
+   if (copied) {
+   *offset += copied;
+   return written ?: -EFAULT;
+   }
+
+   remain -= len;
+   *offset += len;
+   ubuf += len;
+   start = 0;
+   idx++;
+   }
+
+   return written;
+}
+
 /**
  * DOC: fence polling
  *
@@ -318,6 +404,8 @@ static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
+   .read   = dma_buf_read,
+   .write  = dma_buf_write,
.poll   = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
 #ifdef CONFIG_COMPAT
-- 
2.11.0

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

[Bug 195283] amdgpu: desktop freezes with wine-staging and FS2002

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Most likely a mesa bug rather than a kernel bug.

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

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1799-ge0a6f97889aa)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1799-ge0a6f97889aa)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1799-ge0a6f97889aa/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1799-ge0a6f97889aa
Git Commit: e0a6f97889aa13307cd9112c1a7c6be7f7114f9b
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

[Bug 195283] New: amdgpu: desktop freezes with wine-staging and FS2002

[bugzilla-daemon]

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

Bug ID: 195283
   Summary: amdgpu: desktop freezes with wine-staging and FS2002
   Product: Drivers
   Version: 2.5
Kernel Version: 4.11-rc5
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: fin4...@hotmail.com
Regression: No

I updated Oibaf ppa Mesa git today and wine-staging 2.4. Before that MS Flight
Simulator 2002 did work without freezing the desktop. Now the desktop freezes
when  nearing takeoff speed and there is this in dmesg (via ssh):
[  142.466155] amdgpu :01:00.0: GPU fault detected: 147 0x04207702
[  142.466159] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001A6A84
[  142.466161] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C077002
[  142.466163] amdgpu :01:00.0: VM fault (0x02, vmid 6) at page 1731204,
read from 'SDM0' (0x53444d30) (119)
[  142.468214] amdgpu :01:00.0: GPU fault detected: 147 0x01580402
[  142.468217] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0010002B
[  142.468219] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0E004002
[  142.468221] amdgpu :01:00.0: VM fault (0x02, vmid 7) at page 1048619,
read from 'TC3' (0x54433300) (4)
[  142.468225] amdgpu :01:00.0: GPU fault detected: 147 0x01584402
[  142.468226] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00139F91
[  142.468227] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0E008002
[  142.468229] amdgpu :01:00.0: VM fault (0x02, vmid 7) at page 1286033,
read from 'TC2' (0x54433200) (8)

sudo reboot does not work. Must reboot the computer with the power button. My
System: Debian testing Xfce, Gigabyte Rx 460 2GB, Amd X4 845, 8GB 2133Mhz ddr3,
240GB sata ssd, Asus A88XM-E motherboard.

Freezing also with the ad5gf drm-next-wip kernel when it used kernel 4.10-rc5.

-- 
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] drm: Don't allow interruptions when opening debugfs/crc

[Chris Wilson]

On Fri, Apr 07, 2017 at 06:42:46PM +0200, Daniel Vetter wrote:
> On Fri, Apr 07, 2017 at 01:55:00PM +0200, Tomeu Vizoso wrote:
> > On 04/07/2017 01:17 PM, Chris Wilson wrote:
> > > The code does not like to be interrupted when waiting for the first
> > > vblank after opening a debugfs/crc channel, so don't.
> > > 
> > > [66285.716870] WARNING: CPU: 1 PID: 16615 at 
> > > drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm]
> > > [66285.716877] Modules linked in: i915 intel_powerclamp crct10dif_pclmul 
> > > crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd intel_gtt 
> > > i2c_algo_bit lpc_ich mfd_core drm_kms_helper syscopyarea sysfillrect 
> > > sysimgblt fb_sys_fops prime_numbers drm video button autofs4 sd_mod ahci 
> > > libahci libata i2c_i801 scsi_mod i2c_designware_platform 
> > > i2c_designware_core i2c_core
> > > [66285.716929] CPU: 1 PID: 16615 Comm: kms_frontbuffer Not tainted 
> > > 4.11.0-rc5+ #7
> > > [66285.716935] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F8 
> > > 03/02/2016
> > > [66285.716941] Call Trace:
> > > [66285.716955]  dump_stack+0x4d/0x6f
> > > [66285.716966]  __warn+0xc1/0xe0
> > > [66285.716975]  warn_slowpath_null+0x18/0x20
> > > [66285.717004]  crtc_crc_open+0x1d0/0x1f0 [drm]
> > > [66285.717014]  ? wake_atomic_t_function+0x50/0x50
> > > [66285.717024]  full_proxy_open+0xf0/0x1b0
> > > [66285.717032]  ? full_proxy_release+0x80/0x80
> > > [66285.717042]  do_dentry_open.isra.17+0x14b/0x2d0
> > > [66285.717051]  vfs_open+0x42/0x60
> > > [66285.717064]  path_openat+0x5e7/0x13d0
> > > [66285.717074]  ? refcount_dec_and_test+0x11/0x20
> > > [66285.717081]  ? down_read+0xd/0x30
> > > [66285.717087]  do_filp_open+0x85/0xf0
> > > [66285.717093]  ? __vfs_write+0x23/0x120
> > > [66285.717100]  ? __alloc_fd+0x3a/0x170
> > > [66285.717107]  do_sys_open+0x11e/0x1f0
> > > [66285.717113]  ? do_sys_open+0x11e/0x1f0
> > > [66285.717119]  SyS_openat+0xf/0x20
> > > [66285.717125]  entry_SYSCALL_64_fastpath+0x17/0x98
> > > [66285.717131] RIP: 0033:0x7f5f2235146a
> > > [66285.717135] RSP: 002b:7ffd892e6bc0 EFLAGS: 0246 ORIG_RAX: 
> > > 0101
> > > [66285.717142] RAX: ffda RBX:  RCX: 
> > > 7f5f2235146a
> > > [66285.717147] RDX:  RSI: 7ffd892e6c40 RDI: 
> > > 0006
> > > [66285.717151] RBP: 7ffd892e6b20 R08:  R09: 
> > > 000f
> > > [66285.717156] R10:  R11: 0246 R12: 
> > > 0001
> > > [66285.717161] R13: 7ffd892e6b10 R14: 0004 R15: 
> > > 007e61f4
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610
> > > Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from 
> > > open()")
> > > Signed-off-by: Chris Wilson 
> > > Cc: Tomeu Vizoso 
> > > Cc: Daniel Vetter 
> > 
> > Reviewed-by: Tomeu Vizoso 
> > 
> > Sounds good to me, there isn't any good reason for the wait to be
> > interruptible.
> 
> Applied to drm-misc-next, thanks.

Oh no. The other side is using wake_up_interruptible(), so only the
interruptible waiters are woken and not us anymore :(

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index aa13e734c9e5..1ec04f864437 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -354,7 +354,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool 
has_frame,
 
spin_unlock(>lock);
 
-   wake_up_interruptible(>wq);
+   wake_up(>wq);
 
return 0;
 }

Undoes the damage, or revert?
-Chris

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

Re: [PATCH v5 12/12] drm/drm_ioctl.c: Break ioctl when drm device not registered

[Daniel Vetter]

On Fri, Apr 07, 2017 at 05:24:59PM +0800, jeffy wrote:
> Hi Daniel,
> 
> On 04/07/2017 03:16 PM, Daniel Vetter wrote:
> > On Thu, Apr 06, 2017 at 08:31:25PM +0800, Jeffy Chen wrote:
> > > After unbinding drm, the user space may still owns the drm dev fd,
> > > and may still be able to call drm ioctl.
> > > 
> > > Add a sanity check here to prevent that from happening.
> > > 
> > > Signed-off-by: Jeffy Chen 
> > > ---
> > > 
> > > Changes in v5: None
> > > Changes in v4: None
> > > Changes in v3: None
> > > Changes in v2: None
> > > 
> > >   drivers/gpu/drm/drm_ioctl.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > index 7d6deaa..15beb11 100644
> > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > @@ -674,7 +674,7 @@ long drm_ioctl(struct file *filp,
> > > 
> > >   dev = file_priv->minor->dev;
> > > 
> > > - if (drm_device_is_unplugged(dev))
> > > + if (drm_device_is_unplugged(dev) || !dev->registered)
> > 
> > Shouldn't we instead automatically unplug the device in
> > drm_dev_unregister, instead of sprinkling tons of drm_device_is_unplugged
> > || !registered all over the place?
> > 
> it looks like the drm_unplug_dev would call drm_dev_unregister...
> maybe we can:
> 1/ replace the dev_unplug_dev in udl_drv.c to drm_dev_unregister
> 2/ call dev_unplug_dev in drm_dev_unregister, and remove drm_dev_unregister
> in dev_unplug_dev
> 3/ add a drm_plug_dev or drm_device_set_plugged, and call it in
> drm_dev_register

Yeah, sounds like a reasonable plan. I didn't review the full implications
of this because Fri evening :-) So pls double-check before you rewrite the
world ...

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

Re: [PATCH] drm: dw-hdmi: Implement the mode_fixup drm helper

[Daniel Vetter]

On Fri, Apr 07, 2017 at 02:17:43PM +0200, Romain Perier wrote:
> This helper is supposed to validate or reject the modeline before it
> applied by the mode setting. Currently this function has been dropped,
> it was previously set to a dummy function that always returned true. For
> both cases, this means that userspace can ask for a bad modeline that
> will be always accepted.
> 
> On some platforms, like Rockchip, the drm dw_hdmi-rockchip variant driver
> already implements the atomic_check drm helper, so mode_fixup cannot be
> handled and implemented there (as drm_atomic_helper relies on either
> atomic_check or mode_fixup).
> 
> This commit implements this helper. It only checks that this mode is
> correct from the connector point of view
> 
> Signed-off-by: Romain Perier 

Yup this is how it's supposed to be done, check bridge limits in the
bridge's mode_fixup hook.

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 22211ff..3bd0807 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1740,6 +1740,21 @@ static int dw_hdmi_bridge_attach(struct drm_bridge 
> *bridge)
>   return 0;
>  }
>  
> +
> +static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
> +   const struct drm_display_mode *orig_mode,
> +   struct drm_display_mode *mode)
> +{
> + struct dw_hdmi *hdmi = bridge->driver_private;
> + struct drm_connector *connector = >connector;
> + enum drm_mode_status status;
> +
> + status = dw_hdmi_connector_mode_valid(connector, mode);
> + if (status != MODE_OK)
> + return false;
> + return true;
> +}
> +
>  static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
>   struct drm_display_mode *orig_mode,
>   struct drm_display_mode *mode)
> @@ -1781,6 +1796,7 @@ static const struct drm_bridge_funcs 
> dw_hdmi_bridge_funcs = {
>   .enable = dw_hdmi_bridge_enable,
>   .disable = dw_hdmi_bridge_disable,
>   .mode_set = dw_hdmi_bridge_mode_set,
> + .mode_fixup = dw_hdmi_bridge_mode_fixup,
>  };
>  
>  static irqreturn_t dw_hdmi_i2c_irq(struct dw_hdmi *hdmi)
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm: dw-hdmi: Implement the mode_fixup drm helper

[Daniel Vetter]

On Fri, Apr 7, 2017 at 7:15 PM, Archit Taneja  wrote:
> On 4/7/2017 5:47 PM, Romain Perier wrote:
>>
>> This helper is supposed to validate or reject the modeline before it
>> applied by the mode setting. Currently this function has been dropped,
>> it was previously set to a dummy function that always returned true. For
>> both cases, this means that userspace can ask for a bad modeline that
>> will be always accepted.
>>
>> On some platforms, like Rockchip, the drm dw_hdmi-rockchip variant driver
>> already implements the atomic_check drm helper, so mode_fixup cannot be
>> handled and implemented there (as drm_atomic_helper relies on either
>> atomic_check or mode_fixup).
>>
>> This commit implements this helper. It only checks that this mode is
>> correct from the connector point of view
>
>
> We do have a atomic_check op in drm_connector_helper_funcs. I've
> rarely seen it being used, but it could be used to validate
> the mode w.r.t the connector, rather than checking it in the
> bridge's mode_fixup op.
>
> Daniel,
>
> Is it okay to use the connector's atomic_check to validate a mode.
> (by peeping into the new_crtc_state->mode?)

This new atomic_check is super-new, and only for validating properties
on the connector, before stuff like the routing or crtc is all set up.
So no, can't be used for that. mode_fixup on the bridge is indeed the
right place for limiting output specific stuff. Yes this is all a bit
awkward, but thus far no one volunteered to improve the helpers after
I explained the full nastiness of the situation ... I think we should
have some helpers that implement the mode_valid helper in terms of the
mode_fixup/atomic_check functions, but that's a bit tricky to get
right :(
-Daniel

>
> Thanks,
> Archit
>
>
>>
>> Signed-off-by: Romain Perier 
>> ---
>>  drivers/gpu/drm/bridge/dw-hdmi.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/dw-hdmi.c
>> index 22211ff..3bd0807 100644
>> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
>> @@ -1740,6 +1740,21 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
>> *bridge)
>> return 0;
>>  }
>>
>> +
>> +static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
>> + const struct drm_display_mode
>> *orig_mode,
>> + struct drm_display_mode *mode)
>> +{
>> +   struct dw_hdmi *hdmi = bridge->driver_private;
>> +   struct drm_connector *connector = >connector;
>> +   enum drm_mode_status status;
>> +
>> +   status = dw_hdmi_connector_mode_valid(connector, mode);
>> +   if (status != MODE_OK)
>> +   return false;
>> +   return true;
>> +}
>> +
>>  static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
>> struct drm_display_mode *orig_mode,
>> struct drm_display_mode *mode)
>> @@ -1781,6 +1796,7 @@ static const struct drm_bridge_funcs
>> dw_hdmi_bridge_funcs = {
>> .enable = dw_hdmi_bridge_enable,
>> .disable = dw_hdmi_bridge_disable,
>> .mode_set = dw_hdmi_bridge_mode_set,
>> +   .mode_fixup = dw_hdmi_bridge_mode_fixup,
>>  };
>>
>>  static irqreturn_t dw_hdmi_i2c_irq(struct dw_hdmi *hdmi)
>>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation



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

Re: [RFC PATCH 2/2] drm/vgem: Enable dmabuf import interfaces

[Laura Abbott]

On 04/07/2017 09:58 AM, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 09:18:30AM -0700, Laura Abbott wrote:
>> On 04/07/2017 12:39 AM, Chris Wilson wrote:
>>> On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:

 Enable the GEM dma-buf import interfaces in addition to the export
 interfaces. This lets vgem be used as a test source for other allocators
 (e.g. Ion).

 +int vgem_gem_get_pages(struct drm_vgem_gem_object *obj)
 +{
 +  struct page **pages;
 +
 +  if (obj->pages)
 +  return 0;
 +
 +  pages = drm_gem_get_pages(>base);
 +  if (IS_ERR(pages)) {
 +  return PTR_ERR(pages);
 +  }
 +
 +  obj->pages = pages;
>>>
>>> That's a significant loss in functionality (it requires the entire
>>> object to fit into physical memory at the same time and requires a large
>>> vmalloc for 32b systems), for what? vgem only has the ability to mmap
>>> and export a fd -- both of which you already have if you have the dmabuf
>>> fd. The only extra interface is the signaling, which does not yet have a
>>> direct correspondence on dmabuf.
>>>
>>> (An obvious way to keep both would be to move the get_pages to importing
>>> and then differentiate in the faulthandler where to get the page from.)
>>>
>>
>> Thanks for pointing this out. I'll look to keep the existing behavior.
>>
>>> Can you provide more details on how you are using vgem to justify the
>>> changes? I'm also not particularly happy in losing testing of a virtual
>>> platform device from our CI.
>>> -Chris
>>>
>>
>> There exists a test module in the Ion directory
>> (drivers/staging/android/ion/ion_test.c) today but it's not actually
>> Ion specific. It registers a platform device and then provides an
>> ioctl interface to perform a dma_buf attach and map. I proposed
>> moving this to a generic dma-buf test module
>> (https://marc.info/?l=dri-devel=148952187004611=2) and Daniel
>> suggested that this was roughly what vgem was supposed to do.
> 
> mmap(dma_buf_fd) gives you DMA_BUF_IOC_TEST_DMA_MAPPING, and that's the
> only facility already available via vgem.
> 

Not completely. It's possible to mmap a dma_buf fd without being
attached to any device (the source of many caching headaches). Part of
the goal is to verify that the attachment and map callbacks are
working as expected.

> DMA_BUF_IOC_TEST_KERNEL_MAPPING would be equivalent to
> read/write(dma_buf_fd).
> 
>> Adding the import methods for vgem covers all of what the
>> Ion test was doing and we don't have to invent yet another ioctl
>> interface and framework for attaching and mapping. 
> 
> I don't think it does :)
> 
> To muddy the waters further, I've also done something similar:
> https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
> https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c
> 

Those do look familiar :)

> But this feels like a good enough reason for implementing read/write ops
> for the dma-buf fd, and then we can test the dma_buf->ops->kmap on i915
> as well, directly from i915.ko. Sounds fun, I'll see if I can cook
> something up - and we can then see if that suits your testing as well.
>  
>> Can you clarify about what you mean about 'virtual platform device'?
> 
>   vgem_device = drm_dev_alloc(_driver, NULL);
> 
> helps exercise some more corner cases of the drm core, that we have
> unwittingly broken in the past.

Okay thanks for the explanation. I was debating putting the platform
support behind a configuration option. I don't know if that would
actually solve anything or just result in another configuration that
doesn't get tested.

> -Chris
> 

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

Re: [GIT PULL FOR v4.12] Renesas R-Car Gen3 DU HDMI support

[Thierry Reding]

On Tue, Apr 04, 2017 at 06:03:13PM +0200, Daniel Vetter wrote:
> On Tue, Apr 04, 2017 at 06:38:15PM +0300, Laurent Pinchart wrote:
> > Hi Thierry,
> > 
> > On Tuesday 04 Apr 2017 17:21:47 Thierry Reding wrote:
> > > On Tue, Apr 04, 2017 at 05:17:44PM +0300, Laurent Pinchart wrote:
> > > > Hi Dave,
> > > > 
> > > > The following changes since commit 
> > e1b489d207c73e67810659a88c45b8db4bd62773:
> > > >   Merge tag 'omapdrm-4.12' of
> > > > 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
> > > > (2017-04-04 05:45:49 +1000)
> > > > 
> > > > are available in the git repository at:
> > > >   git://linuxtv.org/pinchartl/media.git drm/next/du
> > > > 
> > > > for you to fetch changes up to 0dda563e571093f309d597cafaf7dd535496ecfb:
> > > >   drm: rcar-du: Add HDMI outputs to R8A7795 device description 
> > > > (2017-04-04
> > > > 
> > > > 17:04:21 +0300)
> > > > 
> > > > Note that the series contains 2 drm-panel patches since I need those to
> > > > unblock the rest of the rcar-du patches.
> > > > 
> > > > 
> > > > 
> > > > Jacopo Mondi (1):
> > > >   drm: rcar-du: Make sure the VSP is initialized on platforms that
> > > >   need it
> > > > 
> > > > Koji Matsuoka (3):
> > > >   drm: rcar-du: Add Gen3 HDMI encoder support
> > > >   drm: rcar-du: Add DPLL support
> > > >   drm: rcar-du: Add HDMI outputs to R8A7795 device description
> > > > 
> > > > Laurent Pinchart (17):
> > > >   devicetree/bindings: display: Document common panel properties
> > > >   devicetree/bindings: display: Add bindings for LVDS panels
> > > >   devicetree/bindings: display: Add bindings for two Mitsubishi 
> > > > panels
> > > >   drm: Add data transmission order bus flag
> > > >   drm: panels: Add LVDS panel driver
> > > 
> > > Can you please add an entry to MAINTAINERS for this. We've had our
> > > differences about this and the corresponding device tree bindings, but
> > > it looks as if Rob doesn't have any objections and I've been overruled.
> > > However, since I don't know where you want to take this I'm not going
> > > to be able to do a good job maintaining it.
> > 
> > I will do, sorry about missing it.
> > 
> > We certainly have different opinions on some matters related to panels, but 
> > please be assured that I had, and still have, no goal of overruling you for 
> > the sake of it. Some people might call me a utopian, but I believe 
> > collaboration is much better than confrontation :-) I would rather work 
> > with 
> > you on improving panel support in the kernel than working against each 
> > other.
> 
> Long term it might be good to group-maintain drm_panel within drm-misc.
> But we're still figuring this out, and e.g. for drm_bridge (which is
> similar situation, but with bigger drivers and more people) we're stil in
> the process of figuring out how to best run things. And who all
> might/should be listed as reviewers and who should all have commit rights.

Group maintainership seems like a good idea.

> Maybe once that has settled a bit more (in 1-2 releases perhaps) we could
> try to get a drm_panel group up, maybe together with a bit a discussion
> about what drm_panel is all about? At least looking back at some of the
> past discussions, slightly misalignment on goals seems like part of the
> reasons for disagreement here.

I'm not sure what you mean by misalignment on goals. I think the goal is
pretty well defined. If it isn't, I think we need to rectify that, and
the best way to do so seems to be to add better documentation.

Thierry


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

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1786-g50ff2d4f1de4)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1786-g50ff2d4f1de4)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1786-g50ff2d4f1de4/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1786-g50ff2d4f1de4
Git Commit: 50ff2d4f1de470b3ceb6f716a3f57c46f9d57d27
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

drm-tip/drm-tip boot: 118 boots: 1 failed, 116 passed with 1 offline (v4.11-rc5-1784-gc5d424760e9a)

[kernelci . org bot]

drm-tip/drm-tip boot: 118 boots: 1 failed, 116 passed with 1 offline 
(v4.11-rc5-1784-gc5d424760e9a)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1784-gc5d424760e9a/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1784-gc5d424760e9a/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1784-gc5d424760e9a
Git Commit: c5d424760e9a5d40f7024591d5e69f074711e7ff
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 17 unique boards, 10 SoC families, 22 builds out of 207

Boot Failure Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5422-odroidxu3: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

[Thierry Reding]

On Fri, Apr 07, 2017 at 05:44:15AM +1000, Dave Airlie wrote:
> On 5 April 2017 at 16:51, Laurent Pinchart
>  wrote:
> > As the DRM LVDS panel driver uses a different approach to DT bindings
> > compared to what Thierry Reding advocates, add a specific MAINTAINERS
> > entry to avoid bothering Thierry with requests related to that driver.
> 
> Could you document a bit more in the patch summary the finer points of
> panel/dt doctrine, as I haven't got as much knowledge as I'd like.
> 
> Just I believe, Thierry believes.

I'm somewhat surprised how we arrived at the current situation. A very
long time ago when we first discussed device tree bindings for panels, a
number of attempts were made to generically describe everything in
device tree. All of those attempts failed because you simply couldn't
describe all of the required properties in DT in a sane way.

Eventually everyone involved agreed that we would have to stick with the
device-specific compatible, and in the best case we would be able to
support many panels with a fairly generic driver. I think we did pretty
well with the panel-simple driver. It started out very simple and then
got improved over time as necessary to deal with more panels. And for
cases where it wasn't suitable we simply added a custom driver. That's a
completely natural way to write drivers. We do the same thing in other
areas, nothing special here.

Ever since the simple-panel binding was introduced, which is now about
3 1/2 years ago, people have kept asking why we couldn't simply put all
data in DT and why kernel drivers had to be modified in order to add
support for a new panel. I kept repeating myself a number of times until
I finally wrote it all up[0], after which it was enough to point people
to it. Still not everyone was convinced, but the people that were there
when we made the decision all agreed that this was still the right thing
to do. So, despite the many complaints I stuck to what we had agreed on
because I am convinced that it is the right thing to do.

Now we have arrived at a point where apparently that decision has been
revoked, and I don't understand what's changed. This puts me in a very
difficult position. All of a sudden it's okay to do what everyone has
been asking for the last three years, and I'm the jerk who told everyone
that it couldn't be done.

Maybe the discussions that we had back at the time are now far enough in
the past that people have forgotten about the earlier failures. I still
don't see how this new panel-lvds would be any more successful in
solving the problems we failed to solve with simple-panel. The issues
are still fundamentally the same. Now if this was a generic driver that
dealt with a different subset of panels because they are different, that
would've been okay with me. What I don't understand is why this has to
deviate from the simple-panel binding in fundamental ways. Now we've got
two bindings and we make life miserable for people because they have to
choose between the two.

Thierry

[0]: https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html


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

Re: [PATCH v5 00/12] drm: rockchip: Fix rockchip drm unbind crash error

[Sean Paul]

On Thu, Apr 06, 2017 at 08:31:13PM +0800, Jeffy Chen wrote:
> 
> Verified on rk3399 chromebook kevin:
> 1/ stop ui && pkill -9 frecon
> 2/ unbind/bind drm
> 
> Changes in v5:
> Fix wrong git account.
> 
> Changes in v4:
> Address Andrzej Hajda 's comments.
> 
> Changes in v3:
> Update commit message.
> Address Sean Paul 's comments.
> Update commit message.
> Address Sean Paul 's comments.
> Update commit message.
> Address Daniel Vetter 's comments.
> Update commit message.
> 
> Changes in v2:
> Fix some commit messages.
> 
> Jeffy Chen (12):
>   drm: bridge: analogix: Detach panel when unbinding analogix dp
>   drm: bridge: analogix: Unregister dp aux when unbinding
>   drm: bridge: analogix: Disable clock when unbinding
>   drm: bridge: analogix: Destroy connector & encoder when unbinding
>   drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
>   drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding
>   drm/rockchip: vop: Enable pm domain before vop_initial
>   drm/rockchip: vop: Unprepare clocks when unbinding
>   drm/rockchip: analogix_dp: Disable clock when unbinding
>   drm/rockchip: Reoder drm bind/unbind sequence
>   drm/rockchip: Shutdown all crtcs when unbinding drm

Hi Jeffy,
I've applied the first 11 patches from this set to -misc. The last patch
is still a work in progress.

Thanks,

Sean

>   drm/drm_ioctl.c: Break ioctl when drm device not registered
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 +++
>  drivers/gpu/drm/drm_ioctl.c|  2 +-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 10 +++--
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 50 
> --
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 33 ++
>  6 files changed, 67 insertions(+), 37 deletions(-)
> 
> -- 
> 2.1.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vmwgfx: Fix fbdev emulation using legacy functions

[Sean Paul]

On Fri, Apr 07, 2017 at 10:31:29AM +0200, Thomas Hellstrom wrote:
> Hi, Daniel.
> 
> It appears to work fine. Thanks!
> 
> Do you want to take it through drm-misc or want me to take it throuch
> vmwgfx-next?

Applied to drm-misc

Thanks,

Sean

> 
> Reviewed-by: Thomas Hellstrom 
> /Thomas
> 
> 
> 
> On 04/06/2017 10:02 PM, Daniel Vetter wrote:
> > I've broken this by removing the backoff handling from the
> > set_config2atomic helper in
> >
> > commit 38b6441e4e75c0b319cfe4d9364c1059fc1e3c2b
> > Author: Daniel Vetter 
> > Date:   Wed Mar 22 22:50:58 2017 +0100
> >
> > drm/atomic-helper: Remove the backoff hack from set_config
> >
> > Fixing this properly would mean we get to wire the acquire_ctx all the
> > way through vmwgfx fbdev code, and doing the same was tricky for the
> > shared fbdev layer. Probably much better to look into refactoring the
> > entire code to use the helpers, but since that's not a viable
> > long-term solution fix the issue by open-coding a vmwgfx version of
> > set_config, that does the legacy backoff dance internally.
> >
> > Note: Just compile-tested. The idea is to take
> > drm_mode_set_config_internal(), remove the "is this a legacy driver"
> > check, and whack the drm_atomic_legacy_backoff trickery at the end.
> > Since drm_atomic_legacy_backoff is for atomic commits only we need to
> > open-code it.
> >
> > Cc: Thomas Hellstrom 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 58 
> > --
> >  1 file changed, 56 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > index 09e120d50e65..6f4cb4678cbc 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > @@ -418,6 +418,60 @@ static int vmw_fb_compute_depth(struct 
> > fb_var_screeninfo *var,
> > return 0;
> >  }
> >  
> > +static int vmwgfx_set_config_internal(struct drm_mode_set *set)
> > +{
> > +   struct drm_crtc *crtc = set->crtc;
> > +   struct drm_framebuffer *fb;
> > +   struct drm_crtc *tmp;
> > +   struct drm_modeset_acquire_ctx *ctx;
> > +   struct drm_device *dev = set->crtc->dev;
> > +   int ret;
> > +
> > +   ctx = dev->mode_config.acquire_ctx;
> > +
> > +restart:
> > +   /*
> > +* NOTE: ->set_config can also disable other crtcs (if we steal all
> > +* connectors from it), hence we need to refcount the fbs across all
> > +* crtcs. Atomic modeset will have saner semantics ...
> > +*/
> > +   drm_for_each_crtc(tmp, dev)
> > +   tmp->primary->old_fb = tmp->primary->fb;
> > +
> > +   fb = set->fb;
> > +
> > +   ret = crtc->funcs->set_config(set, ctx);
> > +   if (ret == 0) {
> > +   crtc->primary->crtc = crtc;
> > +   crtc->primary->fb = fb;
> > +   }
> > +
> > +   drm_for_each_crtc(tmp, dev) {
> > +   if (tmp->primary->fb)
> > +   drm_framebuffer_get(tmp->primary->fb);
> > +   if (tmp->primary->old_fb)
> > +   drm_framebuffer_put(tmp->primary->old_fb);
> > +   tmp->primary->old_fb = NULL;
> > +   }
> > +
> > +   if (ret == -EDEADLK) {
> > +   dev->mode_config.acquire_ctx = NULL;
> > +
> > +retry_locking:
> > +   drm_modeset_backoff(ctx);
> > +
> > +   ret = drm_modeset_lock_all_ctx(dev, ctx);
> > +   if (ret)
> > +   goto retry_locking;
> > +
> > +   dev->mode_config.acquire_ctx = ctx;
> > +
> > +   goto restart;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static int vmw_fb_kms_detach(struct vmw_fb_par *par,
> >  bool detach_bo,
> >  bool unref_bo)
> > @@ -436,7 +490,7 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,
> > set.fb = NULL;
> > set.num_connectors = 0;
> > set.connectors = >con;
> > -   ret = drm_mode_set_config_internal();
> > +   ret = vmwgfx_set_config_internal();
> > if (ret) {
> > DRM_ERROR("Could not unset a mode.\n");
> > return ret;
> > @@ -578,7 +632,7 @@ static int vmw_fb_set_par(struct fb_info *info)
> > set.num_connectors = 1;
> > set.connectors = >con;
> >  
> > -   ret = drm_mode_set_config_internal();
> > +   ret = vmwgfx_set_config_internal();
> > if (ret)
> > goto out_unlock;
> >  
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Only take cursor locks when the cursor plane exists

[Sean Paul]

On Fri, Apr 07, 2017 at 06:48:17PM +0200, Daniel Vetter wrote:
> I thought I've fixed this, but maybe not. Anyway, clearly broken, and
> easy fix.
> 
> Cc: Tony Lindgren 
> Reported-by: Tony Lindgren 
> Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc")
> Cc: Harry Wentland 
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---

Applied to drm-misc

Thanks,

Sean

>  drivers/gpu/drm/drm_plane.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 838ca742a28b..fedd4d60d9cd 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -720,15 +720,15 @@ static int drm_mode_cursor_common(struct drm_device 
> *dev,
>   ret = drm_modeset_lock(>mutex, );
>   if (ret)
>   goto out;
> - ret = drm_modeset_lock(>cursor->mutex, );
> - if (ret)
> - goto out;
> -
>   /*
>* If this crtc has a universal cursor plane, call that plane's update
>* handler rather than using legacy cursor handlers.
>*/
>   if (crtc->cursor) {
> + ret = drm_modeset_lock(>cursor->mutex, );
> + if (ret)
> + goto out;
> +
>   ret = drm_mode_cursor_universal(crtc, req, file_priv, );
>   goto out;
>   }
> -- 
> 2.11.0

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: dw-hdmi: Implement the mode_fixup drm helper

[Archit Taneja]

Hi,

On 4/7/2017 5:47 PM, Romain Perier wrote:

This helper is supposed to validate or reject the modeline before it
applied by the mode setting. Currently this function has been dropped,
it was previously set to a dummy function that always returned true. For
both cases, this means that userspace can ask for a bad modeline that
will be always accepted.

On some platforms, like Rockchip, the drm dw_hdmi-rockchip variant driver
already implements the atomic_check drm helper, so mode_fixup cannot be
handled and implemented there (as drm_atomic_helper relies on either
atomic_check or mode_fixup).

This commit implements this helper. It only checks that this mode is
correct from the connector point of view


We do have a atomic_check op in drm_connector_helper_funcs. I've
rarely seen it being used, but it could be used to validate
the mode w.r.t the connector, rather than checking it in the
bridge's mode_fixup op.

Daniel,

Is it okay to use the connector's atomic_check to validate a mode.
(by peeping into the new_crtc_state->mode?)

Thanks,
Archit



Signed-off-by: Romain Perier 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 22211ff..3bd0807 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1740,6 +1740,21 @@ static int dw_hdmi_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }

+
+static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+   struct drm_connector *connector = >connector;
+   enum drm_mode_status status;
+
+   status = dw_hdmi_connector_mode_valid(connector, mode);
+   if (status != MODE_OK)
+   return false;
+   return true;
+}
+
 static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
struct drm_display_mode *orig_mode,
struct drm_display_mode *mode)
@@ -1781,6 +1796,7 @@ static const struct drm_bridge_funcs dw_hdmi_bridge_funcs 
= {
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
+   .mode_fixup = dw_hdmi_bridge_mode_fixup,
 };

 static irqreturn_t dw_hdmi_i2c_irq(struct dw_hdmi *hdmi)



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: dw-hdmi: Implement the mode_fixup drm helper

[Romain Perier]

This helper is supposed to validate or reject the modeline before it
applied by the mode setting. Currently this function has been dropped,
it was previously set to a dummy function that always returned true. For
both cases, this means that userspace can ask for a bad modeline that
will be always accepted.

On some platforms, like Rockchip, the drm dw_hdmi-rockchip variant driver
already implements the atomic_check drm helper, so mode_fixup cannot be
handled and implemented there (as drm_atomic_helper relies on either
atomic_check or mode_fixup).

This commit implements this helper. It only checks that this mode is
correct from the connector point of view

Signed-off-by: Romain Perier 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 22211ff..3bd0807 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1740,6 +1740,21 @@ static int dw_hdmi_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }
 
+
+static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+   struct drm_connector *connector = >connector;
+   enum drm_mode_status status;
+
+   status = dw_hdmi_connector_mode_valid(connector, mode);
+   if (status != MODE_OK)
+   return false;
+   return true;
+}
+
 static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
struct drm_display_mode *orig_mode,
struct drm_display_mode *mode)
@@ -1781,6 +1796,7 @@ static const struct drm_bridge_funcs dw_hdmi_bridge_funcs 
= {
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
+   .mode_fixup = dw_hdmi_bridge_mode_fixup,
 };
 
 static irqreturn_t dw_hdmi_i2c_irq(struct dw_hdmi *hdmi)
-- 
2.9.3

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

[PATCH 1/2] drm: dw-hdmi: add specific I2S and AHB functions for stream handling

[Romain Perier]

Currently, CTS+N is forced to zero as a workaround of the IP block for
i.MX platforms. This is requested in the datasheet of the corresponding
IP for AHB mode only. However, we have seen that it introduces glitches
or delays when playing a sound on HDMI for I2S mode. This proves that we
cannot keep the current functions for handling audio stream as-is if
these contain workaround that are specific to a mode.

This commit introduces two callbacks, one for each variant.
dw_hdmi_setup defines the right function depending on the detected
variant. Then, the exported functions dw_hdmi_audio_enable and
dw_hdmi_audio_disable calls the corresponding callbacks

Signed-off-by: Romain Perier 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 542d198..d34e0a5 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -166,6 +166,8 @@ struct dw_hdmi {
 
void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
u8 (*read)(struct dw_hdmi *hdmi, int offset);
+   void (*enable_audio)(struct dw_hdmi *hdmi);
+   void (*disable_audio)(struct dw_hdmi *hdmi);
 };
 
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -557,13 +559,34 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, 
unsigned int rate)
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
 
+void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
+{
+   hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
+}
+
+void dw_hdmi_ahb_audio_disable(struct dw_hdmi *hdmi)
+{
+   hdmi_set_cts_n(hdmi, hdmi->audio_cts, 0);
+}
+
+void dw_hdmi_i2s_audio_enable(struct dw_hdmi *hdmi)
+{
+   hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
+}
+
+
+void dw_hdmi_i2s_audio_disable(struct dw_hdmi *hdmi)
+{
+
+}
+
 void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
 {
unsigned long flags;
 
spin_lock_irqsave(>audio_lock, flags);
hdmi->audio_enable = true;
-   hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
+   hdmi->enable_audio(hdmi);
spin_unlock_irqrestore(>audio_lock, flags);
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_audio_enable);
@@ -574,7 +597,7 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
 
spin_lock_irqsave(>audio_lock, flags);
hdmi->audio_enable = false;
-   hdmi_set_cts_n(hdmi, hdmi->audio_cts, 0);
+   hdmi->disable_audio(hdmi);
spin_unlock_irqrestore(>audio_lock, flags);
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
@@ -2114,6 +2137,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
audio.irq = irq;
audio.hdmi = hdmi;
audio.eld = hdmi->connector.eld;
+   hdmi->enable_audio = dw_hdmi_ahb_audio_enable;
+   hdmi->disable_audio = dw_hdmi_ahb_audio_disable;
 
pdevinfo.name = "dw-hdmi-ahb-audio";
pdevinfo.data = 
@@ -2126,6 +2151,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
audio.hdmi  = hdmi;
audio.write = hdmi_writeb;
audio.read  = hdmi_readb;
+   hdmi->enable_audio = dw_hdmi_i2s_audio_enable;
+   hdmi->disable_audio = dw_hdmi_i2s_audio_disable;
 
pdevinfo.name = "dw-hdmi-i2s-audio";
pdevinfo.data = 
-- 
2.9.3

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

[PATCH 2/2] drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks

[Romain Perier]

Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
step E. and is kept enabled for later use. This clock should be enabled
and disabled along with the actual audio stream and not always on (that
is bad for PM). Futhermore, as described by the datasheet, the I2S
variant need to gate/ungate the clock when the stream is
enabled/disabled.

This commit adds a parameter to hdmi_audio_enable_clk() that controls
when the audio sample clock must be enabled or disabled. Then, it adds
the call to this function from dw_hdmi_i2s_audio_enable() and
dw_hdmi_i2s_audio_disable().

Signed-off-by: Romain Perier 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index d34e0a5..3bd0807 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -559,6 +559,12 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, 
unsigned int rate)
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
 
+static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
+{
+   hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
+ HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
+}
+
 void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
 {
hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
@@ -572,12 +578,13 @@ void dw_hdmi_ahb_audio_disable(struct dw_hdmi *hdmi)
 void dw_hdmi_i2s_audio_enable(struct dw_hdmi *hdmi)
 {
hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
+   hdmi_enable_audio_clk(hdmi, true);
 }
 
 
 void dw_hdmi_i2s_audio_disable(struct dw_hdmi *hdmi)
 {
-
+   hdmi_enable_audio_clk(hdmi, false);
 }
 
 void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
@@ -1365,11 +1372,6 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
}
 }
 
-static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
-{
-   hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
-}
-
 /* Workaround to clear the overflow condition */
 static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 {
@@ -1471,7 +1473,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 
/* HDMI Initialization Step E - Configure audio */
hdmi_clk_regenerator_update_pixel_clock(hdmi);
-   hdmi_enable_audio_clk(hdmi);
+   hdmi_enable_audio_clk(hdmi, true);
}
 
/* not for DVI mode */
-- 
2.9.3

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

[PATCH 0/2] drm: dw-hdmi: various improvements

[Romain Perier]

This set of patches split the stream handling functions in two parts. It
introduces new callbacks that are specific to each variant, one for I2S
and one for AHB.

Then, as requested by the datasheet for the I2S variant, it adds support
for gating the audio sampler clock when the audio stream is enabled and
disabled.

This patches series is the continuity of the following discussion:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493550.html

Romain Perier (2):
  drm: dw-hdmi: add specific I2S and AHB functions for stream handling
  drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks

 drivers/gpu/drm/bridge/dw-hdmi.c | 45 +---
 1 file changed, 37 insertions(+), 8 deletions(-)

-- 
2.9.3

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

[PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

[Andrea Arcangeli]

Waiting a RCU grace period only guarantees the work gets queued, but
until after the queued workqueue returns, there's no guarantee the
memory was actually freed. So flush the work to provide better
guarantees to the reclaim code in addition of waiting a RCU grace
period to pass.

Signed-off-by: Andrea Arcangeli 
---
 drivers/gpu/drm/i915/i915_gem.c  | 2 ++
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3982489..612fde3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4748,6 +4748,7 @@ int i915_gem_freeze(struct drm_i915_private *dev_priv)
 * running workqueue may wait on the struct_mutex.
 */
synchronize_rcu(); /* wait for our earlier RCU delayed slab frees */
+   flush_work(_priv->mm.free_work);
 
intel_runtime_pm_put(dev_priv);
 
@@ -4789,6 +4790,7 @@ int i915_gem_freeze_late(struct drm_i915_private 
*dev_priv)
mutex_unlock(_priv->drm.struct_mutex);
 
synchronize_rcu_expedited();
+   flush_work(_priv->mm.free_work);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index fea1454..30f79af 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -329,6 +329,7 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct 
shrink_control *sc)
 * blocked waiting on us to release struct_mutex.
 */
synchronize_rcu_expedited();
+   flush_work(_priv->mm.free_work);
 
return freed;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Michel Dänzer  writes:

> When no such special client (Steam?) is running, the desktop environment
> will try to use the HMD anyway, right? So the expected use case would be
> for the user to start a special client first and only plug in the HMD
> afterwards? That seems a bit inconvenient.

I'd love a better alternative, but this is the best I've come up
with.

Of course, it needn't be the actual VR client, it could be a stub
application that popped open a 'which app would you like to run on the
HMD' chooser of some kind, or even hooks in the desktop system that
managed that.

Suggestions very much encouraged.

-- 
-keith


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

Re: [PATCH] format-security: move static strings to const

[Kees Cook]

On Thu, Apr 6, 2017 at 1:48 AM, Jani Nikula  wrote:
> On Thu, 06 Apr 2017, Kees Cook  wrote:
>> While examining output from trial builds with -Wformat-security enabled,
>> many strings were found that should be defined as "const", or as a char
>> array instead of char pointer. This makes some static analysis easier,
>> by producing fewer false positives.
>>
>> As these are all trivial changes, it seemed best to put them all in
>> a single patch rather than chopping them up per maintainer.
>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index f6d4d9700734..1ff9d5912b83 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -2331,7 +2331,7 @@ EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
>>  int __init drm_fb_helper_modinit(void)
>>  {
>>  #if defined(CONFIG_FRAMEBUFFER_CONSOLE_MODULE) && !defined(CONFIG_EXPERT)
>> - const char *name = "fbcon";
>> + const char name[] = "fbcon";
>
> I'd always write the former out of habit. Why should I start using the
> latter? What makes it better?

For me, it's mainly two reasons: sizeof() and -Wformat-security behavior.

The compiler treats "sizeof" differently. E.g. "sizeof(var)" shows the
allocation size for the array, and pointer size for the char pointer.
When doing things like snprintf(buf, sizeof(buf), ...) will do the
right thing, etc. (This is a poor example for a _const_ string, but
the point is that some calculations still work better with the array
over the pointer.)

The other situation (which is why I noted this to change them) is that
gcc's handling of them is different when faced with -Wformat-security
since it doesn't like to believe that const char pointers are actually
const for the purposes of being a format string.

> What keeps the kernel from accumulating tons more of the former?

Right now, nothing. The good news is that they're relatively rare, and
I notice them when they're added (since I have a -Wformat-security
tree). We could add a warning to checkpatch for suggesting const char
var[] over const char *var, perhaps?

> Here's an interesting comparison of the generated code. I'm a bit
> surprised by what gcc does, I would have expected no difference, like
> clang. https://godbolt.org/g/OdqUvN

Here's your example with sizeof() added, if you're curious...
https://godbolt.org/g/U1zIZK

> The other changes adding const in this patch are, of course, good.

Thanks!

-Kees

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

Re: [PATCH v5 12/12] drm/drm_ioctl.c: Break ioctl when drm device not registered

[jeffy]

Hi Daniel,

On 04/07/2017 03:16 PM, Daniel Vetter wrote:

On Thu, Apr 06, 2017 at 08:31:25PM +0800, Jeffy Chen wrote:

After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.

Add a sanity check here to prevent that from happening.

Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/gpu/drm/drm_ioctl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7d6deaa..15beb11 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -674,7 +674,7 @@ long drm_ioctl(struct file *filp,

dev = file_priv->minor->dev;

-   if (drm_device_is_unplugged(dev))
+   if (drm_device_is_unplugged(dev) || !dev->registered)


Shouldn't we instead automatically unplug the device in
drm_dev_unregister, instead of sprinkling tons of drm_device_is_unplugged
|| !registered all over the place?


it looks like the drm_unplug_dev would call drm_dev_unregister...
maybe we can:
1/ replace the dev_unplug_dev in udl_drv.c to drm_dev_unregister
2/ call dev_unplug_dev in drm_dev_unregister, and remove 
drm_dev_unregister in dev_unplug_dev
3/ add a drm_plug_dev or drm_device_set_plugged, and call it in 
drm_dev_register



That should catch a few more issues where userspace might creep into the
driver after unregistering ...
-Daniel


return -ENODEV;

is_driver_ioctl = nr >= DRM_COMMAND_BASE && nr < DRM_COMMAND_END;
--
2.1.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 v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

[jeffy]

Hi Daniel,

On 04/07/2017 02:30 PM, Daniel Vetter wrote:

On Thu, Apr 6, 2017 at 1:09 PM, jeffy  wrote:


On 04/06/2017 04:26 PM, Daniel Vetter wrote:


On Wed, Apr 05, 2017 at 12:28:40PM -0400, Sean Paul wrote:


On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:


After unbinding drm, the userspace may still has a chance to access
gem buf.

Add a sanity check for a NULL dev_private to prevent that from
happening.



I still don't understand how this is happening. You're saying that these
hooks
can be called after rockchip_drm_unbind() has finished?



Yeah this is supposed to be impossible. If it isn't, we need to debug and
fix this properly. This smells like pretty bad duct-tape ...



it looks like after unbind, the user space may still own drm dev fd, and
could be able to call ioctl:
lrwx--. 1 chronos chronos 64 Mar 15 12:53 28 -> /dev/dri/card1 (deleted)

and the drm_unplug_dev may help it, maybe we should call it in unbind? or
just break drm_ioctl when drm_dev not registered?


Yes, by default unbind while userspace is running is totally broken in
drm. drm_unplug_dev would be the fix, but it's only used by udl and
not many use that. You might need to fix infrastructure up a bit.

please check this patch:
9667071 New  [v5,12/12] drm/drm_ioctl.c: Break ioctl when drm 
device not registered


For normal module unload the module reference will prevent unloading.
So why exactly do you care about the unbind use-case?

sometimes we use unbind/bind for testing ;)

-Daniel




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

drm_modeset_lock oops in next

[Tony Lindgren]

Hi,

Looks like current next now oopses at least for omapdrm
when starting X. Reverting commit d20afeb3e2f9 ("Merge
remote-tracking branch 'drm-misc/for-linux-next'") makes
things work again.

Any ideas what might be causing the oops below?

Regards,

Tony

8< --
Internal error: Oops: 5 [#1] SMP ARM
...
CPU: 1 PID: 1637 Comm: X Not tainted 4.11.0-rc5-next-20170407+ #488
Hardware name: Generic OMAP4 (Flattened Device Tree)
task: ec873180 task.stack: ec8b8000
PC is at __ww_mutex_lock.constprop.0+0x34/0x1054
LR is at lock_is_held_type+0x60/0xa8
pc : []lr : []psr: a013
   sp : ec8b9d18  ip : 0002  fp : edb2a800
r10: ec8b9dc0  r9 : edb2c800  r8 : ec88c400
r7 : ec8b9e1c  r6 : bf70f648  r5 : ec8b9dd8  r4 : 0010
r3 : 00400100  r2 : ec8b9cf8  r1 :   r0 : 
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: ac85c04a  DAC: 0051
Process X (pid: 1637, stack limit = 0xec8b8218)
...
[] (__ww_mutex_lock.constprop.0) from [] 
(ww_mutex_lock+0x44/0x54)
[] (ww_mutex_lock) from [] (drm_modeset_lock+0x60/0x110 
[drm])
[] (drm_modeset_lock [drm]) from [] 
(drm_mode_cursor_common+0x98/0x1f0 [drm])
[] (drm_mode_cursor_common [drm]) from [] 
(drm_mode_cursor_ioctl+0x58/0x60 [drm])
[] (drm_mode_cursor_ioctl [drm]) from [] 
(drm_ioctl+0x1d4/0x404 [drm])
[] (drm_ioctl [drm]) from [] (do_vfs_ioctl+0x90/0xa54)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x1c)
Code: e58d3018 ebe4cd4e e35a 0a02 (e5943044)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks

[Romain Perier]

Hello,


Le 07/04/2017 à 16:23, Neil Armstrong a écrit :
> On 04/07/2017 04:19 PM, Romain Perier wrote:
>> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
>> step E. and is kept enabled for later use. This clock should be enabled
>> and disabled along with the actual audio stream and not always on (that
>> is bad for PM). Futhermore, as described by the datasheet, the I2S
>> variant need to gate/ungate the clock when the stream is
>> enabled/disabled.
>>
>> This commit adds a parameter to hdmi_audio_enable_clk() that controls
>> when the audio sample clock must be enabled or disabled. Then, it adds
>> the call to this function from dw_hdmi_i2s_audio_enable() and
>> dw_hdmi_i2s_audio_disable().
>>
>> Signed-off-by: Romain Perier 
>> ---
>>  drivers/gpu/drm/bridge/dw-hdmi.c | 16 +---
>>  1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/dw-hdmi.c
>> index d34e0a5..3bd0807 100644
>> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
>> @@ -559,6 +559,12 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, 
>> unsigned int rate)
>>  }
>>  EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
>>  
>> +static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
>> +{
>> +hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>> +  HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
>> +}
>> +
>>  void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
>>  {
>>  hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
>> @@ -572,12 +578,13 @@ void dw_hdmi_ahb_audio_disable(struct dw_hdmi *hdmi)
>>  void dw_hdmi_i2s_audio_enable(struct dw_hdmi *hdmi)
>>  {
>>  hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
>> +hdmi_enable_audio_clk(hdmi, true);
>>  }
>>  
>>  
>>  void dw_hdmi_i2s_audio_disable(struct dw_hdmi *hdmi)
>>  {
>> -
>> +hdmi_enable_audio_clk(hdmi, false);
>>  }
> I think the NULL check is still valid if you fill this function, because the 
> IP also
> support other modes (SPDIF and GPA).

Ah, good point!

Thanks,
Romain

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

Re: [PATCH] drm: Only take cursor locks when the cursor plane exists

[Tony Lindgren]

* Daniel Vetter  [170407 09:50]:
> I thought I've fixed this, but maybe not. Anyway, clearly broken, and
> easy fix.
> 
> Cc: Tony Lindgren 
> Reported-by: Tony Lindgren 
> Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc")
> Cc: Harry Wentland 
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 

Thanks this fixes the issue with starting X with Linux next
for me:

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

Re: [Intel-gfx] [PATCH] drm: Only take cursor locks when the cursor plane exists

[Daniel Stone]

Reviewed-by: Daniel Stone 

[mobile email formatting apology here]

On Fri, 7 Apr 2017 at 5:48 pm, Daniel Vetter  wrote:

> I thought I've fixed this, but maybe not. Anyway, clearly broken, and
> easy fix.
>
> Cc: Tony Lindgren 
> Reported-by: Tony Lindgren 
> Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc")
> Cc: Harry Wentland 
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_plane.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 838ca742a28b..fedd4d60d9cd 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -720,15 +720,15 @@ static int drm_mode_cursor_common(struct drm_device
> *dev,
> ret = drm_modeset_lock(>mutex, );
> if (ret)
> goto out;
> -   ret = drm_modeset_lock(>cursor->mutex, );
> -   if (ret)
> -   goto out;
> -
> /*
>  * If this crtc has a universal cursor plane, call that plane's
> update
>  * handler rather than using legacy cursor handlers.
>  */
> if (crtc->cursor) {
> +   ret = drm_modeset_lock(>cursor->mutex, );
> +   if (ret)
> +   goto out;
> +
> ret = drm_mode_cursor_universal(crtc, req, file_priv,
> );
> goto out;
> }
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 2/2] drm/vgem: Enable dmabuf import interfaces

[Chris Wilson]

On Fri, Apr 07, 2017 at 09:18:30AM -0700, Laura Abbott wrote:
> On 04/07/2017 12:39 AM, Chris Wilson wrote:
> > On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
> >>
> >> Enable the GEM dma-buf import interfaces in addition to the export
> >> interfaces. This lets vgem be used as a test source for other allocators
> >> (e.g. Ion).
> >>
> >> +int vgem_gem_get_pages(struct drm_vgem_gem_object *obj)
> >> +{
> >> +  struct page **pages;
> >> +
> >> +  if (obj->pages)
> >> +  return 0;
> >> +
> >> +  pages = drm_gem_get_pages(>base);
> >> +  if (IS_ERR(pages)) {
> >> +  return PTR_ERR(pages);
> >> +  }
> >> +
> >> +  obj->pages = pages;
> > 
> > That's a significant loss in functionality (it requires the entire
> > object to fit into physical memory at the same time and requires a large
> > vmalloc for 32b systems), for what? vgem only has the ability to mmap
> > and export a fd -- both of which you already have if you have the dmabuf
> > fd. The only extra interface is the signaling, which does not yet have a
> > direct correspondence on dmabuf.
> > 
> > (An obvious way to keep both would be to move the get_pages to importing
> > and then differentiate in the faulthandler where to get the page from.)
> > 
> 
> Thanks for pointing this out. I'll look to keep the existing behavior.
> 
> > Can you provide more details on how you are using vgem to justify the
> > changes? I'm also not particularly happy in losing testing of a virtual
> > platform device from our CI.
> > -Chris
> > 
> 
> There exists a test module in the Ion directory
> (drivers/staging/android/ion/ion_test.c) today but it's not actually
> Ion specific. It registers a platform device and then provides an
> ioctl interface to perform a dma_buf attach and map. I proposed
> moving this to a generic dma-buf test module
> (https://marc.info/?l=dri-devel=148952187004611=2) and Daniel
> suggested that this was roughly what vgem was supposed to do.

mmap(dma_buf_fd) gives you DMA_BUF_IOC_TEST_DMA_MAPPING, and that's the
only facility already available via vgem.

DMA_BUF_IOC_TEST_KERNEL_MAPPING would be equivalent to
read/write(dma_buf_fd).

> Adding the import methods for vgem covers all of what the
> Ion test was doing and we don't have to invent yet another ioctl
> interface and framework for attaching and mapping. 

I don't think it does :)

To muddy the waters further, I've also done something similar:
https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c

But this feels like a good enough reason for implementing read/write ops
for the dma-buf fd, and then we can test the dma_buf->ops->kmap on i915
as well, directly from i915.ko. Sounds fun, I'll see if I can cook
something up - and we can then see if that suits your testing as well.
 
> Can you clarify about what you mean about 'virtual platform device'?

vgem_device = drm_dev_alloc(_driver, NULL);

helps exercise some more corner cases of the drm core, that we have
unwittingly broken in the past.
-Chris

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

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2017-04-03:
Last 4.12 feature pile:

GVT updates:
- Add mdev attribute group for per-vgpu info
- Time slice based vGPU scheduling QoS support (Gao Ping)
- Initial KBL support for E3 server (Han Xu)
- other misc.

i915:
- lots and lots of small fixes and improvements all over
- refactor fw_domain code (Chris Wilson)
- improve guc code (Oscar Mateo)
- refactor cursor/sprite code, precompute more for less overhead in
  the critical path (Ville)
- refactor guc/huc fw loading code a bit (Michal Wajdeczko)

Note: There's was a small mixup in the script, which is fixed again, but
caused some fun with the tagging of this one here. drm-tip says there's
some conflicts with -rc because git is confused, we should have resolved
them all already.

Cheers, Daniel


The following changes since commit 8bcad07a45637fb88e799466e4eee83859e8ffd3:

  drm/i915/gvt: fix error return check for copy_gma_to_hva() (2017-03-29 
13:38:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-testing-2017-04-03

for you to fetch changes up to ba515d3407dccfe3b4597f4afdaaf2ef1beb48e1:

  drm/i915: Update DRIVER_DATE to 20170403 (2017-04-03 07:52:18 +0200)


Last 4.12 feature pile:

GVT updates:
- Add mdev attribute group for per-vgpu info
- Time slice based vGPU scheduling QoS support (Gao Ping)
- Initial KBL support for E3 server (Han Xu)
- other misc.

i915:
- lots and lots of small fixes and improvements all over
- refactor fw_domain code (Chris Wilson)
- improve guc code (Oscar Mateo)
- refactor cursor/sprite code, precompute more for less overhead in
  the critical path (Ville)
- refactor guc/huc fw loading code a bit (Michal Wajdeczko)


Arnd Bergmann (1):
  drm/i915: split out check for noncontiguous pfn range

Ben Widawsky (1):
  drm/i915: Use LINEAR modifier instead of NONE

Chris Wilson (46):
  drm/i915: Reset tasklet back to execlists after disabling guc
  drm/i915: Skip force-wake for uncached mmio flush of GGTT writes
  drm/i915: Protect intel_engine_wakeup() for call from irq context
  drm/i915: intel_engine_init_global_seqno() requires atomic kmap
  drm/i915/execlists: Split the atomic test_and_clear_bit for irq handler
  drm/i915: Remove intel_ring.last_retired_head
  drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx 
allocations
  drm/i915: Actually pass the reclaim gfp_t along to shmemfs!
  drm/i915: Remove superfluous hw_flags from mi_set_context()
  drm/i915: Restore marking context objects as dirty on pinning
  drm/i915: Eliminate per-fw_domain i915 backpointer
  drm/i915: Use correct fw_domains during initialisation
  drm/i915: Use correct fw_domains during reset
  drm/i915: Skip unused fw_domains
  drm/i915: Remove posting-read for forcewake put
  drm/i915: All fw_domains share the same set/clear/reset values
  drm/i915: Drop uncore spinlock for reading debugfs forcewake counters
  drm/i915: Wait for all fences before installing an exclusive clflush fence
  drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)
  drm/i915/guc: Refactor the retrieval of guc_process_desc
  drm/i915: Disable MI_SET_CONTEXT psmi w/a for bdw
  drm/i915: Fix semaphore emission for BDW+ RCS ringbuffer emission
  drm/i915/execlists: Trim irq handler
  drm/i915: Check we have an wake device before flushing GTT writes
  drm/i915: Limit number of reads to stabilize rc6 counter reads
  drm/i915: Align "unfenced" tiled access on gen2, early gen3
  drm/i915: Fixup intel_write_status_page() for old CPUs without clflush
  drm/i915: Remove unused intel_flush_status_page()
  drm/i915: Use BIT() for computing the engine's flag
  drm/i915/execlists: Wrap tail pointer after reset tweaking
  drm/i915: Assert that the request->tail fits within the ring
  drm/i915: Refactor tests for validity of RING_TAIL
  drm/i915: Mark manually wedged engines as guilty
  drm/i915: Take rpm wakelock around debugfs/i915_gpu_info
  drm/i915: Avoid lock dropping between rescheduling
  Revert "drm/i915: Skip execlists_dequeue() early if the list is empty"
  drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
  drm/i915: Use a dummy timeline name for a signaled fence
  drm/i915: Drop verbose and archaic "ring" from our internal engine names
  drm/i915: Do request retirement before marking engines as wedged
  drm/i915: Suppress busy status for engines if wedged
  drm/i915: Move retire-requests into i915_gem_wait_for_idle()
  drm/i915: Wait for all engines to be idle as part of 
i915_gem_wait_for_idle()
  drm/i915: Remove redudant wait for each engine to idle from seqno wrap
  drm/i915: Combine reset_all_global_seqno() loops into one
  drm/i915: 

[PATCH] drm: Only take cursor locks when the cursor plane exists

[Daniel Vetter]

I thought I've fixed this, but maybe not. Anyway, clearly broken, and
easy fix.

Cc: Tony Lindgren 
Reported-by: Tony Lindgren 
Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc")
Cc: Harry Wentland 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 838ca742a28b..fedd4d60d9cd 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -720,15 +720,15 @@ static int drm_mode_cursor_common(struct drm_device *dev,
ret = drm_modeset_lock(>mutex, );
if (ret)
goto out;
-   ret = drm_modeset_lock(>cursor->mutex, );
-   if (ret)
-   goto out;
-
/*
 * If this crtc has a universal cursor plane, call that plane's update
 * handler rather than using legacy cursor handlers.
 */
if (crtc->cursor) {
+   ret = drm_modeset_lock(>cursor->mutex, );
+   if (ret)
+   goto out;
+
ret = drm_mode_cursor_universal(crtc, req, file_priv, );
goto out;
}
-- 
2.11.0

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

[GIT PULL] mediatek-drm-next for 4.12

[CK Hu]

Hi, Dave:

This series is MT2701 DRM support.

The following changes since commit
0168778115687486575a6831df865dbc4f5369fe:

  Merge branch 'drm-next-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2017-04-07
05:49:12 +1000)

are available in the git repository at:


  https://github.com/ckhu-mediatek/linux.git-tags.git drm-next-4.12

for you to fetch changes up to 84a5ead18e57e9018d3de0a5388be8f6c2686329:

  drm/mediatek: add support for Mediatek SoC MT2701 (2017-04-08 00:02:17
+0800)


shaoming chen (2):
  drm/mediatek: add dsi interrupt control
  drm/mediatek: add dsi transfer function

yt.s...@mediatek.com (10):
  dt-bindings: display: mediatek: update supported chips
  drm/mediatek: add helpers for coverting from the generic
components
  drm/mediatek: add *driver_data for different hardware settings
  drm/mediatek: add shadow register support
  drm/mediatek: add BLS component
  drm/mediatek: update display module connections
  drm/mediatek: cleaning up and refine
  drm/mediatek: add non-continuous clock mode and EOT packet control
  drm/mediatek: update DSI sub driver flow for sending commands to
panel
  drm/mediatek: add support for Mediatek SoC MT2701

 .../bindings/display/mediatek/mediatek,disp.txt|   2 +
 .../bindings/display/mediatek/mediatek,dsi.txt |   2 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c|  64 ++-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c   |  39 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  75 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 138 +++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h |   2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c|  69 ++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h|   2 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  54 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |   9 +
 drivers/gpu/drm/mediatek/mtk_dsi.c | 572
-
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c |  38 +-
 13 files changed, 828 insertions(+), 238 deletions(-)

Regards,
CK

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

Re: [PATCH] drm: Don't allow interruptions when opening debugfs/crc

[Daniel Vetter]

On Fri, Apr 07, 2017 at 01:55:00PM +0200, Tomeu Vizoso wrote:
> On 04/07/2017 01:17 PM, Chris Wilson wrote:
> > The code does not like to be interrupted when waiting for the first
> > vblank after opening a debugfs/crc channel, so don't.
> > 
> > [66285.716870] WARNING: CPU: 1 PID: 16615 at 
> > drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm]
> > [66285.716877] Modules linked in: i915 intel_powerclamp crct10dif_pclmul 
> > crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd intel_gtt i2c_algo_bit 
> > lpc_ich mfd_core drm_kms_helper syscopyarea sysfillrect sysimgblt 
> > fb_sys_fops prime_numbers drm video button autofs4 sd_mod ahci libahci 
> > libata i2c_i801 scsi_mod i2c_designware_platform i2c_designware_core 
> > i2c_core
> > [66285.716929] CPU: 1 PID: 16615 Comm: kms_frontbuffer Not tainted 
> > 4.11.0-rc5+ #7
> > [66285.716935] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F8 
> > 03/02/2016
> > [66285.716941] Call Trace:
> > [66285.716955]  dump_stack+0x4d/0x6f
> > [66285.716966]  __warn+0xc1/0xe0
> > [66285.716975]  warn_slowpath_null+0x18/0x20
> > [66285.717004]  crtc_crc_open+0x1d0/0x1f0 [drm]
> > [66285.717014]  ? wake_atomic_t_function+0x50/0x50
> > [66285.717024]  full_proxy_open+0xf0/0x1b0
> > [66285.717032]  ? full_proxy_release+0x80/0x80
> > [66285.717042]  do_dentry_open.isra.17+0x14b/0x2d0
> > [66285.717051]  vfs_open+0x42/0x60
> > [66285.717064]  path_openat+0x5e7/0x13d0
> > [66285.717074]  ? refcount_dec_and_test+0x11/0x20
> > [66285.717081]  ? down_read+0xd/0x30
> > [66285.717087]  do_filp_open+0x85/0xf0
> > [66285.717093]  ? __vfs_write+0x23/0x120
> > [66285.717100]  ? __alloc_fd+0x3a/0x170
> > [66285.717107]  do_sys_open+0x11e/0x1f0
> > [66285.717113]  ? do_sys_open+0x11e/0x1f0
> > [66285.717119]  SyS_openat+0xf/0x20
> > [66285.717125]  entry_SYSCALL_64_fastpath+0x17/0x98
> > [66285.717131] RIP: 0033:0x7f5f2235146a
> > [66285.717135] RSP: 002b:7ffd892e6bc0 EFLAGS: 0246 ORIG_RAX: 
> > 0101
> > [66285.717142] RAX: ffda RBX:  RCX: 
> > 7f5f2235146a
> > [66285.717147] RDX:  RSI: 7ffd892e6c40 RDI: 
> > 0006
> > [66285.717151] RBP: 7ffd892e6b20 R08:  R09: 
> > 000f
> > [66285.717156] R10:  R11: 0246 R12: 
> > 0001
> > [66285.717161] R13: 7ffd892e6b10 R14: 0004 R15: 
> > 007e61f4
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610
> > Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from 
> > open()")
> > Signed-off-by: Chris Wilson 
> > Cc: Tomeu Vizoso 
> > Cc: Daniel Vetter 
> 
> Reviewed-by: Tomeu Vizoso 
> 
> Sounds good to me, there isn't any good reason for the wait to be
> interruptible.

Applied to drm-misc-next, thanks.
-Daniel

> 
> Thanks,
> 
> Tomeu
> 
> > ---
> >  drivers/gpu/drm/drm_debugfs_crc.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> > b/drivers/gpu/drm/drm_debugfs_crc.c
> > index 1722d8f21449..aa13e734c9e5 100644
> > --- a/drivers/gpu/drm/drm_debugfs_crc.c
> > +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> > @@ -177,13 +177,9 @@ static int crtc_crc_open(struct inode *inode, struct 
> > file *filep)
> >  * guess when this particular piece of HW will be ready to start
> >  * generating CRCs.
> >  */
> > -   ret = wait_event_interruptible_lock_irq(crc->wq,
> > -   crtc_crc_data_count(crc),
> > -   crc->lock);
> > +   wait_event_lock_irq(crc->wq, crtc_crc_data_count(crc), crc->lock);
> > spin_unlock_irq(>lock);
> >  
> > -   WARN_ON(ret);
> > -
> > return 0;
> >  
> >  err_disable:
> > 
> 

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

[PATCH 05/11] drm: parse ycbcr 420 deep color information

[Shashank Sharma]

CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.

Cc: Ville Syrjälä 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 15 +++
 include/drm/drm_connector.h |  1 +
 include/drm/drm_edid.h  |  5 +
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d01b7df..828b781 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4151,6 +4151,19 @@ drm_default_rgb_quant_range(const struct 
drm_display_mode *mode)
 }
 EXPORT_SYMBOL(drm_default_rgb_quant_range);
 
+static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
+const u8 *db)
+{
+   struct drm_hdmi_info *info = >display_info.hdmi;
+
+   if (db[7] & DRM_EDID_YCBCR420_DC_48)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
+   if (db[7] & DRM_EDID_YCBCR420_DC_36)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
+   if (db[7] & DRM_EDID_YCBCR420_DC_30)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_30;
+}
+
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
 {
@@ -4191,6 +4204,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
scdc->scrambling.low_rates = true;
}
}
+
+   drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
 }
 
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index dbfa6a1..4545c6e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -136,6 +136,7 @@ struct drm_scdc {
 struct drm_hdmi_info {
/** @scdc: sink's scdc support and capabilities */
struct drm_scdc scdc;
+   u8 ycbcr420_dc_modes;
u64 ycbcr420_vcb_map;
 };
 
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c07eb81..a4d174e7 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -213,6 +213,11 @@ struct detailed_timing {
 #define DRM_EDID_HDMI_DC_30   (1 << 4)
 #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
 
+/* YCBCR 420 deep color modes */
+#define DRM_EDID_YCBCR420_DC_48  (1 << 6)
+#define DRM_EDID_YCBCR420_DC_36  (1 << 5)
+#define DRM_EDID_YCBCR420_DC_30  (1 << 4)
+
 /* ELD Header Block */
 #define DRM_ELD_HEADER_BLOCK_SIZE  4
 
-- 
2.7.4

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

[PATCH 06/11] drm: create hdmi output property

[Shashank Sharma]

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
 - RGB
 - YCBCR 444
 - YCBCR 422
 - YCBCR 420

This patch adds a drm property, using which, a userspace
can specify its preference, for the HDMI output type.
The output type enums are similar to the mentioned outputs
above. To handle various subsampling of YCBCR output types,
this property allows two special cases:
 - DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
 - ycbcr444
 - ycbcr422
 - ycbcr420
 - DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
 - ycbcr420
 - ycbcr422
 - ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c|  2 ++
 drivers/gpu/drm/drm_atomic_helper.c |  4 
 drivers/gpu/drm/drm_connector.c | 31 +++
 include/drm/drm_connector.h | 14 ++
 include/drm/drm_mode_config.h   |  5 +
 5 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506a..6ef34dc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1123,6 +1123,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 */
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719..fcba3c0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->hdmi_output !=
+   new_connector_state->hdmi_output)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9f84761..10201b1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
  config->edid_property,
  0);
 
+   if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
+   drm_object_attach_property(>base,
+  config->hdmi_output_property,
+  0);
+
drm_object_attach_property(>base,
  config->dpms_property, 0);
 
@@ -617,6 +622,25 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
 
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {
+   { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+   { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+   { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
+   { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr420" },
+   { DRM_HDMI_OUTPUT_YCBCR_HQ, "output_ycbcr_high_subsampling" },
+   { DRM_HDMI_OUTPUT_YCBCR_LQ, "output_ycbcr_low_subsampling" },
+};
+
+/**
+ * drm_get_hdmi_output_name - return a string for a given hdmi output enum
+ * @type: enum of output type
+ */
+const char *drm_get_hdmi_output_name(enum drm_hdmi_output_type type)
+{
+   return drm_hdmi_output_enum_list[type].name;
+}
+EXPORT_SYMBOL(drm_get_hdmi_output_name);
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -789,6 +813,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
 
+   prop = drm_property_create_enum(dev, 0, "hdmi_output_format",
+   drm_hdmi_output_enum_list,
+   

[PATCH 11/11] drm/i915: set colorspace for ycbcr outputs

[Shashank Sharma]

When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f0826a5..6999f63 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -472,6 +472,14 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
return;
}
 
+   ret = drm_hdmi_avi_infoframe_set_colorspace(,
+   adjusted_mode,
+   crtc_state->hdmi_output);
+   if (ret < 0) {
+   DRM_ERROR("couldn't fill AVI colorspace\n");
+   return;
+   }
+
drm_hdmi_avi_infoframe_quant_range(, adjusted_mode,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
-- 
2.7.4

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

[PATCH 04/11] drm: parse ycbcr420 vcb block

[Shashank Sharma]

HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.

One of these new blocks is: ycbcr420 vcb
- ycbcr420 video capability data (vcb) block: video modes which can be
  support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 etc)

This patch adds parsing and handling of ycbcr420-vcb in the DRM layer.
This block contains a bitmap about which mode, from among the list of
normal svd videomodes, can support ycbcr420 output too.

So if bit 0 from first vcb byte is set, means first video mode in the
svd list, can be supported in ycbcr420 output too. Bit 2 means second
video mode from svd list, and so on.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 80 +++--
 include/drm/drm_connector.h |  1 +
 2 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 64d8e2e..d01b7df 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2778,6 +2778,7 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define SPEAKER_BLOCK  0x04
 #define VIDEO_CAPABILITY_BLOCK 0x07
 #define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_4200x0F
 #define EDID_BASIC_AUDIO   (1 << 6)
 #define EDID_CEA_YCRCB444  (1 << 5)
 #define EDID_CEA_YCRCB422  (1 << 4)
@@ -3143,11 +3144,21 @@ static int
 do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
 {
int i, modes = 0;
+   u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map;
 
for (i = 0; i < len; i++) {
struct drm_display_mode *mode;
mode = drm_display_mode_from_vic_index(connector, db, len, i);
if (mode) {
+   /*
+* ycbcr420 capability block contains a bitmap which
+* gives the index of such CEA modes in VDB, which can
+* support ycbcr420 sampling output also.
+* For example, if the bit 0 in bitmap is set,
+* first mode in VDB can support ycbcr420 output too.
+*/
+   if (hdmi_420_cap_map & (1 << i))
+   mode->flags |= DRM_MODE_FLAG_420;
drm_mode_probed_add(connector, mode);
modes++;
}
@@ -3526,9 +3537,64 @@ static bool cea_db_is_hdmi_vdb420(const u8 *db)
return true;
 }
 
+static bool cea_db_is_hdmi_vcb420(const u8 *db)
+{
+   if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
+   return false;
+
+   if (cea_db_extended_tag(db) != VIDEO_CAP_BLOCK_420)
+   return false;
+
+   return true;
+}
+
 #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)
 
+static void drm_parse_vcb_420_bitmap(struct drm_connector *connector,
+const u8 *db)
+{
+   struct drm_display_info *info = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
+   u8 map_len = cea_db_payload_len(db) - 1;
+   u8 count;
+   u64 map = 0;
+
+   if (!db)
+   return;
+
+   if (map_len == 0) {
+   /* All CEA modes support ycbcr420 sampling also.*/
+   hdmi->ycbcr420_vcb_map = U64_MAX;
+   return;
+   }
+
+   /*
+* This map indicates which of the existing CEA block modes
+* from VDB can support YCBCR420 output too. So if bit=0 is
+* set, first mode from VDB can support YCBCR420 output too.
+* We will parse and keep this map, before parsing VDB itself
+* to avoid going through the same block again and again.
+*
+* Spec is not clear about max possible size of this block.
+* Clamping max bitmap block size at 8 bytes. Every byte can
+* address 8 CEA modes, in this way this map can address
+* 8*8 = first 64 SVDs.
+*/
+   if (map_len > 8)
+   map_len = 8;
+
+   for (count = 0; count < map_len; count++)
+   map = (db[2 + count] << 8 * count) | map;
+
+   if (map) {
+   DRM_DEBUG_KMS("Sink supports ycbcr 420\n");
+   info->color_formats |= DRM_COLOR_FORMAT_YCRCB420;
+   }
+
+   hdmi->ycbcr420_vcb_map = map;
+}
+
 static int
 add_cea_modes(struct drm_connector *connector, struct edid *edid)
 {
@@ -3561,6 +3627,8 @@ add_cea_modes(struct drm_connector *connector, struct 
edid *edid)
/* Add 4:2:0(only) modes present in EDID */
modes += 

[PATCH 07/11] drm: set output colorspace in AVI infoframe

[Shashank Sharma]

HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.

As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI infoframes.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 40 
 include/drm/drm_edid.h |  5 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 828b781..a02d35b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4734,6 +4734,46 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
 
 /**
+ * drm_hdmi_avi_infoframe_set_colorspace() - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output)
+{
+   switch (hdmi_output) {
+   case DRM_HDMI_OUTPUT_YCBCR444:
+   frame->colorspace = HDMI_COLORSPACE_YUV444;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR422:
+   frame->colorspace = HDMI_COLORSPACE_YUV422;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR420:
+   frame->colorspace = HDMI_COLORSPACE_YUV420;
+   frame->pixel_repeat = 0;
+   break;
+   case DRM_HDMI_OUTPUT_DEFAULT_RGB:
+   frame->colorspace = HDMI_COLORSPACE_RGB;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR_HQ:
+   case DRM_HDMI_OUTPUT_YCBCR_LQ:
+   case DRM_HDMI_OUTPUT_INVALID:
+   DRM_ERROR("Invalid HDMI output type\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
  * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
  *quantization range information
  * @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index a4d174e7..8980366 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,6 +329,7 @@ struct cea_sad {
 struct drm_encoder;
 struct drm_connector;
 struct drm_display_mode;
+enum drm_hdmi_output_type;
 
 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -351,6 +352,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2);
 int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output);
+int
 drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);
 void
-- 
2.7.4

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

[PATCH 10/11] drm/i915: prepare ycbcr420 modeset

[Shashank Sharma]

To get a ycbcr420 output from intel platforms, there are two
major steps:
- RGB->YCBCR conversion using a pipe CSC.
- Program PIPE_MISC register to generate a ycbcr420 output.
- Scaling down YCBCR444 samples to YCBCR420 samples using a pipe
  scaler.

This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
  scaler framework. This output is identified with bit 30
  of the scaler users bitmap.

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
 drivers/gpu/drm/i915/intel_display.c | 34 ++
 drivers/gpu/drm/i915/intel_drv.h | 10 +-
 drivers/gpu/drm/i915/intel_hdmi.c| 11 +++
 drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
 6 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 11b12f4..ecf28df 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5024,6 +5024,9 @@ enum {
 
 #define _PIPE_MISC_A   0x70030
 #define _PIPE_MISC_B   0x71030
+#define   PIPEMISC_YCBCR420_ENABLE (1<<27)
+#define   PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
+#define   PIPEMISC_OUTPUT_YCBCR(1<<11)
 #define   PIPEMISC_DITHER_BPC_MASK (7<<5)
 #define   PIPEMISC_DITHER_8_BPC(0<<5)
 #define   PIPEMISC_DITHER_10_BPC   (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 50fb1f7..592b0d2 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -187,6 +187,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
 
/* panel fitter case: assign as a crtc scaler */
scaler_id = _state->scaler_id;
+   } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+   name = "HDMI-OUTPUT";
+   idx = intel_crtc->base.base.id;
+
+   /* hdmi output case: needs a pipe scaler */
+   scaler_id = _state->scaler_id;
} else {
name = "PLANE";
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b03e5f3..5c4b342 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4611,6 +4611,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
(src_h != dst_w || src_w != dst_h):
(src_w != dst_w || src_h != dst_h);
 
+   if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+   && scaler_user == SKL_HDMI_OUTPUT_INDEX)
+   /* YCBCR 444 -> 420 conversion needs a scaler */
+   need_scaling = true;
+
/*
 * if plane is being disabled or scaler is no more required or force 
detach
 *  - free scaler binded to this plane/crtc
@@ -4658,6 +4663,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 }
 
 /**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+   const struct drm_display_mode *mode = >base.adjusted_mode;
+
+   return skl_update_scaler(state, !state->base.active,
+   SKL_HDMI_OUTPUT_INDEX, >scaler_state.scaler_id,
+   DRM_ROTATE_0, state->pipe_src_w, state->pipe_src_h,
+   mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
  * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
  *
  * @state: crtc's scaler state
@@ -8053,6 +8078,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
 
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
@@ -8078,6 +8104,14 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
 
+   if (hdmi_out) {
+   val |= PIPEMISC_OUTPUT_YCBCR;
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+   val |= 

[PATCH 08/11] drm/i915: handle ycbcr outputs

[Shashank Sharma]

This patch adds support for HDMI ycbcr outputs in i915 layer.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_display.c |   1 +
 drivers/gpu/drm/i915/intel_drv.h |   3 +
 drivers/gpu/drm/i915/intel_hdmi.c| 161 ++-
 3 files changed, 162 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b6b40cd..fc43a28 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11705,6 +11705,7 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+   PIPE_CONF_CHECK_I(hdmi_output);
 
PIPE_CONF_CHECK_I(has_audio);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 43ea748..98902d4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -738,6 +738,9 @@ struct intel_crtc_state {
 
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+   /* HDMI output type */
+   enum drm_hdmi_output_type hdmi_output;
 };
 
 struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 76d9e0d..40d3414 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1301,7 +1301,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
return status;
 }
 
-static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
+static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
+   enum drm_hdmi_output_type hdmi_out)
 {
struct drm_i915_private *dev_priv =
to_i915(crtc_state->base.crtc->dev);
@@ -1313,6 +1314,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (HAS_GMCH_DISPLAY(dev_priv))
return false;
 
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
+   /*
+* HDMI spec says YCBCR422 is 12bpc, but its not a deep
+* color format. So respect the spec, and not allow this
+* to be deep color
+*/
+   DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
+   return false;
+   }
+
/*
 * HDMI 12bpc affects the clocks, so it's only possible
 * when not cloning with other encoder types.
@@ -1333,6 +1344,136 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
return true;
 }
 
+static inline
+bool _check_ycbcr_mode_support(struct drm_display_mode *mode)
+{
+   return mode->flags & DRM_MODE_FLAG_420_MASK;
+}
+
+static inline
+bool _check_ycbcr_sink_support(struct drm_display_info *display,
+  enum drm_hdmi_output_type type)
+{
+   return display->color_formats & type;
+}
+
+static inline enum drm_hdmi_output_type
+_get_highest_quality_ycbcr_supported(struct drm_display_info *display,
+  struct drm_display_mode *mode)
+{
+   /*
+* Get the ycbcr output with the highest possible subsampling rate.
+* Preference should go as:
+* ycbcr 444
+* ycbcr 422
+* ycbcr 420
+*/
+   if (display->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+   return DRM_HDMI_OUTPUT_YCBCR444;
+   else if (display->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   return DRM_HDMI_OUTPUT_YCBCR422;
+   else if (display->color_formats & DRM_COLOR_FORMAT_YCRCB420 &&
+   _check_ycbcr_mode_support(mode))
+   return DRM_HDMI_OUTPUT_YCBCR420;
+   else {
+   DRM_ERROR("Sink does't support any YCBCR output\n");
+   return DRM_HDMI_OUTPUT_INVALID;
+   }
+}
+
+static inline enum drm_hdmi_output_type
+_get_lowest_quality_ycbcr_supported(struct drm_display_info *display,
+ struct drm_display_mode *mode)
+{
+   /*
+* Get the ycbcr output with the lowest possible subsampling rate.
+* Preference should go as:
+* ycbcr 420
+* ycbcr 422
+* ycbcr 444
+*/
+   if (display->color_formats & DRM_COLOR_FORMAT_YCRCB420 &&
+   _check_ycbcr_mode_support(mode))
+   return DRM_HDMI_OUTPUT_YCBCR420;
+   else if (display->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   return 

[PATCH 09/11] drm/i915: handle csc for ycbcr HDMI output

[Shashank Sharma]

To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.

Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.

This function adds a csc handler, to perform RGB->YCBCR conversion
as per recommended spec values.

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_color.c   | 49 +++-
 drivers/gpu/drm/i915/intel_display.c | 32 +++
 2 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 306c6b0..e677996 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,21 @@
 
 #define LEGACY_LUT_LENGTH  (sizeof(struct drm_color_lut) * 256)
 
+/* Post offset values for RGB->YCBCR conversion */
+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/* Direct spec values for RGB->YUV conversion matrix */
+#define CSC_RGB_TO_YUV_RU_GU 0x2D980B70
+#define CSC_RGB_TO_YUV_BU 0x3940
+
+#define CSC_RGB_TO_YUV_RY_GY 0xBEA89C58
+#define CSC_RGB_TO_YUV_BY 0x0800
+
+#define CSC_RGB_TO_YUV_RV_GV 0x08009E88
+#define CSC_RGB_TO_YUV_BV 0xB25E
+
 /*
  * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
  * format). This macro takes the coefficient we want transformed and the
@@ -91,6 +106,35 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t 
*input)
}
 }
 
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+{
+   int pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+   /* We don't use high values for conversion */
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   /* Program direct spec values for RGB to YCBCR conversion matrix */
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+   /* Spec postoffset values */
+   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+   I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+   I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+
+   /* CSC mode before gamma */
+   I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
 /* Set up the pipe CSC unit. */
 static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
 {
@@ -101,7 +145,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
 
-   if (crtc_state->ctm) {
+   if (intel_crtc_state->hdmi_output) {
+   i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+   return;
+   } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->data;
uint64_t input[9] = { 0, };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fc43a28..b03e5f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6206,6 +6206,29 @@ static void intel_crtc_compute_pixel_rate(struct 
intel_crtc_state *crtc_state)
ilk_pipe_pixel_rate(crtc_state);
 }
 
+static int intel_crtc_ycbcr_config(struct intel_crtc_state *state)
+{
+   struct drm_crtc_state *drm_state = >base;
+   struct drm_i915_private *dev_priv = to_i915(drm_state->crtc->dev);
+
+   /* YCBCR420 is supported only in HDMI 2.0 controllers */
+   if ((state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420) &&
+   !IS_GEMINILAKE(dev_priv)) {
+   DRM_ERROR("YCBCR420 output is not supported\n");
+   return -EINVAL;
+   }
+
+   /* We need CSC for output conversion from RGB->YCBCR */
+   if (drm_state->ctm) {
+   DRM_ERROR("YCBCR output and CTM is not possible together\n");
+   return -EINVAL;
+   }
+
+   DRM_DEBUG_DRIVER("Output %s can be supported\n",
+drm_get_hdmi_output_name(state->hdmi_output));
+   return 0;
+}
+
 static int intel_crtc_compute_config(struct intel_crtc *crtc,

[PATCH 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Shashank Sharma]

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
 drivers/gpu/drm/bridge/sii902x.c  |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
 drivers/gpu/drm/drm_edid.c| 12 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c |  5 -
 drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
 drivers/gpu/drm/tegra/hdmi.c  |  2 +-
 drivers/gpu/drm/tegra/sor.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
 include/drm/drm_edid.h|  3 ++-
 21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index daf003d..5dc3e95 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 3a72967..b70f077 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 6943f26..bcf9c75 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridge,
 
mutex_lock(>lock);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(, adjusted_mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(, adjusted_mode,
+  false);
if (err) {
DRM_ERROR("Failed to setup AVI infoframe: %d\n", err);

[PATCH 00/11] HDMI YCBCR output handling in DRM layer

[Shashank Sharma]

This patch series adds DRM layer support for YCBCR HDMI output handling.
The target HDMI YCBCR outputs are:
- YCBCR444
- YCBCR422
- YCBCR420

As YCBCR420 output is added in HDMI 2.0, this patch series also
contain few patches to handle new EDID extention blocks, added
for YCBCR420 modes (CEA-861-F)

First two patches, complete the CEA modedb in drm driver, by adding
new 4k modes. Current CEA modedb contains 64 modes only (VIC1-64), whereas
YCBCR420 output can support 4k modes, from VIC range 93-107. First patch
makes sure that it doesn't break existing HDMI 1.4 monitors, adding new
VICs.

Next 3 patches, parse and accomodate YCBCR420 suppor information from the
sink, and stores into display info strucure. This contains parsing YCBCR420
supported modes, and deep color information.

Next 2 patch create a property (hdmi_output) using which, as userspace can
set its preferred HDMI output from RGB, YCBCR444/422/420 etc. Default value
of the property is set to RGB(0) so that it doesnt affect existing
implementations. Other patch takes care of setting AVI IF colorspace as per
the selected output.

Last 3 patches contain implementation of YCBCR output in I915 HDMI subsystem.

Jose Abreu (1):
  drm: parse ycbcr 420 vdb block

Shashank Sharma (10):
  drm: Add HDMI 2.0 VIC support for AVI info-frames
  drm/edid: Complete CEA modedb(VIC 1-107)
  drm: parse ycbcr420 vcb block
  drm: parse ycbcr 420 deep color information
  drm: create hdmi output property
  drm: set output colorspace in AVI infoframe
  drm/i915: handle ycbcr outputs
  drm/i915: handle csc for ycbcr HDMI output
  drm/i915: prepare ycbcr420 modeset
  drm/i915: set colorspace for ycbcr outputs

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |   2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |   3 +-
 drivers/gpu/drm/bridge/sii902x.c  |   2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   2 +
 drivers/gpu/drm/drm_atomic_helper.c   |   4 +
 drivers/gpu/drm/drm_connector.c   |  31 +++
 drivers/gpu/drm/drm_edid.c| 416 +-
 drivers/gpu/drm/drm_modes.c   |  10 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h   |   3 +
 drivers/gpu/drm/i915/intel_atomic.c   |   6 +
 drivers/gpu/drm/i915/intel_color.c|  49 +++-
 drivers/gpu/drm/i915/intel_display.c  |  67 +
 drivers/gpu/drm/i915/intel_drv.h  |  13 +-
 drivers/gpu/drm/i915/intel_hdmi.c | 185 -
 drivers/gpu/drm/i915/intel_panel.c|   3 +-
 drivers/gpu/drm/i915/intel_sdvo.c |   3 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |   2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|   3 +-
 drivers/gpu/drm/radeon/radeon_audio.c |   2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |   2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|   2 +-
 drivers/gpu/drm/tegra/hdmi.c  |   2 +-
 drivers/gpu/drm/tegra/sor.c   |   2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|   2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |   2 +-
 include/drm/drm_connector.h   |  17 ++
 include/drm/drm_edid.h|  13 +-
 include/drm/drm_mode_config.h |   5 +
 include/uapi/drm/drm_mode.h   |   6 +
 34 files changed, 836 insertions(+), 33 deletions(-)

-- 
2.7.4

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

[PATCH 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

[Shashank Sharma]

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107

V3: Rebase on drm-tip, added R-B from Jose, Alex.
V4: Addressed review comments from Andrzej not to modify the
VIC filed for HDMI 1.4b sinks (by adding another patch).

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 215 +
 1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f982a42..8d98687 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1001,6 +1001,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, 

[PATCH 03/11] drm: parse ycbcr 420 vdb block

[Shashank Sharma]

From: Jose Abreu 

HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.

These new blocks are:
- ycbcr420 video data (vdb) block: video modes which can be supported
  only in ycbcr420 output mode.
- ycbcr420 video capability data (vcb) block: video modes which can be
  support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 etc)

This patch adds parsing and handling of ycbcr420-vdb in the DRM
layer.

This patch is a modified version of Jose's RFC patch:
https://patchwork.kernel.org/patch/9492327/
so the authorship is maintained.

Cc: Ville Syrjala 
Signed-off-by: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 54 +++--
 drivers/gpu/drm/drm_modes.c | 10 +++--
 include/drm/drm_connector.h |  1 +
 include/uapi/drm/drm_mode.h |  6 +
 4 files changed, 67 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8d98687..64d8e2e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2777,6 +2777,7 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define VENDOR_BLOCK0x03
 #define SPEAKER_BLOCK  0x04
 #define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
 #define EDID_BASIC_AUDIO   (1 << 6)
 #define EDID_CEA_YCRCB444  (1 << 5)
 #define EDID_CEA_YCRCB422  (1 << 4)
@@ -3278,6 +3279,32 @@ static int add_3d_struct_modes(struct drm_connector 
*connector, u16 structure,
return modes;
 }
 
+/* Modes which can be supported in ycbcr 420 format only */
+static int do_420_vdb_modes(struct drm_connector *connector, const u8 *svds,
+   u8 svds_len)
+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;
+   struct drm_display_info *info = >display_info;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svds[i] & 0x7f;
+
+   newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
+   if (!newmode)
+   break;
+
+   newmode->flags |= DRM_MODE_FLAG_420_ONLY;
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+
+   if (modes > 0)
+   info->color_formats |= DRM_COLOR_FORMAT_YCRCB420;
+   return modes;
+}
+
 /*
  * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
  * @connector: connector corresponding to the HDMI sink
@@ -3434,6 +3461,12 @@ cea_db_tag(const u8 *db)
 }
 
 static int
+cea_db_extended_tag(const u8 *db)
+{
+   return db[1];
+}
+
+static int
 cea_revision(const u8 *cea)
 {
return cea[1];
@@ -3482,6 +3515,17 @@ static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
return oui == HDMI_FORUM_IEEE_OUI;
 }
 
+static bool cea_db_is_hdmi_vdb420(const u8 *db)
+{
+   if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
+   return false;
+
+   if (cea_db_extended_tag(db) != VIDEO_DATA_BLOCK_420)
+   return false;
+
+   return true;
+}
+
 #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)
 
@@ -3507,10 +3551,16 @@ add_cea_modes(struct drm_connector *connector, struct 
edid *edid)
video = db + 1;
video_len = dbl;
modes += do_cea_modes(connector, video, dbl);
-   }
-   else if (cea_db_is_hdmi_vsdb(db)) {
+   } else if (cea_db_is_hdmi_vsdb(db)) {
hdmi = db;
hdmi_len = dbl;
+   } else if (cea_db_is_hdmi_vdb420(db)) {
+   const u8 *vdb420 = [2];
+   u8 vdb420_len = dbl - 1;
+
+   /* Add 4:2:0(only) modes present in EDID */
+   modes += do_420_vdb_modes(connector, vdb420,
+ vdb420_len);
}
}
}
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..10432f3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -987,6 +987,10 @@ bool drm_mode_equal_no_clocks(const struct 
drm_display_mode *mode1, const struct
(mode2->flags & DRM_MODE_FLAG_3D_MASK))
return false;
 
+   if ((mode1->flags & DRM_MODE_FLAG_420_MASK) !=
+   (mode2->flags & DRM_MODE_FLAG_420_MASK))
+   return false;
+
return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
 }
 

Re: DRM Display driver for Intel FPGA Video and Image Processing Suite

[Daniel Vetter]

On Thu, Apr 6, 2017 at 8:29 AM, Ong, Hean Loong
 wrote:
> Hi All,
>
> Any comments for the patch below?

Seems the same version that I already reviewed. My comment about not
sending inline was more for the next version, especially once it's
about applying the patch, attached patches are a bit of a pain (since
they break the tooling here).
-Daniel
>
> Thanks
>
> Hean Loong
>
> On Tue, 2017-04-04 at 04:01 +, Ong, Hean Loong wrote:
>> Hi All,
>>
>> Apologies for the attachment earlier. Below are the inline changes
>> for the patch
>>
>> From 0de293e3646a1780ed603cf8e1f2a19d9aebbe83 Mon Sep 17 00:00:00
>> 2001
>> From: Ong, Hean Loong 
>> Date: Thu, 30 Mar 2017 18:02:22 +0800
>> Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite Frame
>> Buffer II driver
>>
>> Signed-off-by: Ong, Hean Loong 
>> ---
>>  drivers/gpu/drm/Kconfig   |2 +
>>  drivers/gpu/drm/Makefile  |1 +
>>  drivers/gpu/drm/ivip/Kconfig  |   22 
>>  drivers/gpu/drm/ivip/Makefile |9 ++
>>  drivers/gpu/drm/ivip/intel_vip_conn.c |  145 ++
>>  drivers/gpu/drm/ivip/intel_vip_core.c |  215
>> +
>>  drivers/gpu/drm/ivip/intel_vip_crtc.c |  161
>> 
>>  drivers/gpu/drm/ivip/intel_vip_drv.h  |   55 +
>>  drivers/gpu/drm/ivip/intel_vip_of.c   |  146 ++
>>  9 files changed, 756 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/gpu/drm/ivip/Kconfig
>>  create mode 100644 drivers/gpu/drm/ivip/Makefile
>>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
>>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
>>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_crtc.c
>>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
>>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index ebfe840..c487507 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -167,6 +167,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
>>
>>  source "drivers/gpu/drm/i915/Kconfig"
>>
>> +source "drivers/gpu/drm/ivip/Kconfig"
>> +
>>  config DRM_VGEM
>>   tristate "Virtual GEM provider"
>>   depends on DRM
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index b9ae428..945cf53 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
>>  obj-$(CONFIG_DRM_MGA)+= mga/
>>  obj-$(CONFIG_DRM_I810)   += i810/
>>  obj-$(CONFIG_DRM_I915)   += i915/
>> +obj-$(CONFIG_DRM_IVIP)   += ivip/
>>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
>>  obj-$(CONFIG_DRM_VC4)  += vc4/
>>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>> diff --git a/drivers/gpu/drm/ivip/Kconfig
>> b/drivers/gpu/drm/ivip/Kconfig
>> new file mode 100644
>> index 000..ddf3cb5
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ivip/Kconfig
>> @@ -0,0 +1,22 @@
>> +config DRM_IVIP
>> +tristate "Intel FGPA Video and Image Processing"
>> +depends on DRM
>> +select DRM_GEM_CMA_HELPER
>> +select DRM_KMS_HELPER
>> +select DRM_KMS_FB_HELPER
>> +select DRM_KMS_CMA_HELPER
>> +help
>> +Choose this option if you have a Intel FPGA Arria 10
>> system
>> +and above with a Display Port IP. This does not
>> support legacy
>> +Intel FPGA Cyclone V display port. Currently only
>> single frame
>> +buffer is supported. Note that ACPI and X_86
>> architecture is yet
>> +to be supported.
>> +
>> +config DRM_IVIP_OF
>> +tristate "Intel FGPA Video and Image Processing Open
>> Firmware Systems"
>> +depends on DRM_IVIP && OF
>> +help
>> +Choose this option if the Intel FPGA system is using
>> Open
>> +Firmware systems (Arria 10). If M is selected the
>> module would
>> +be called ivip.
>> +
>> diff --git a/drivers/gpu/drm/ivip/Makefile
>> b/drivers/gpu/drm/ivip/Makefile
>> new file mode 100644
>> index 000..7be1e99
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ivip/Makefile
>> @@ -0,0 +1,9 @@
>> +#
>> +# Makefile for the drm device driver.  This driver provides support
>> for the
>> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>> +
>> +ccflags-y := -Iinclude/drm
>> +
>> +obj-$(CONFIG_DRM_IVIP_OF) += ivip.o
>> +ivip-objs := intel_vip_of.o intel_vip_core.o \
>> +intel_vip_conn.o intel_vip_crtc.o
>> diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
>> b/drivers/gpu/drm/ivip/intel_vip_conn.c
>> new file mode 100644
>> index 000..89ab587
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
>> @@ -0,0 +1,145 @@
>> +/*
>> + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
>> + * Frame Buffer II driver
>> + *
>> + * This driver 

Re: [RFC PATCH 2/2] drm/vgem: Enable dmabuf import interfaces

[Laura Abbott]

On 04/07/2017 12:39 AM, Chris Wilson wrote:
> On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
>>
>> Enable the GEM dma-buf import interfaces in addition to the export
>> interfaces. This lets vgem be used as a test source for other allocators
>> (e.g. Ion).
>>
>> +int vgem_gem_get_pages(struct drm_vgem_gem_object *obj)
>> +{
>> +struct page **pages;
>> +
>> +if (obj->pages)
>> +return 0;
>> +
>> +pages = drm_gem_get_pages(>base);
>> +if (IS_ERR(pages)) {
>> +return PTR_ERR(pages);
>> +}
>> +
>> +obj->pages = pages;
> 
> That's a significant loss in functionality (it requires the entire
> object to fit into physical memory at the same time and requires a large
> vmalloc for 32b systems), for what? vgem only has the ability to mmap
> and export a fd -- both of which you already have if you have the dmabuf
> fd. The only extra interface is the signaling, which does not yet have a
> direct correspondence on dmabuf.
> 
> (An obvious way to keep both would be to move the get_pages to importing
> and then differentiate in the faulthandler where to get the page from.)
> 

Thanks for pointing this out. I'll look to keep the existing behavior.

> Can you provide more details on how you are using vgem to justify the
> changes? I'm also not particularly happy in losing testing of a virtual
> platform device from our CI.
> -Chris
> 

There exists a test module in the Ion directory
(drivers/staging/android/ion/ion_test.c) today but it's not actually
Ion specific. It registers a platform device and then provides an
ioctl interface to perform a dma_buf attach and map. I proposed
moving this to a generic dma-buf test module
(https://marc.info/?l=dri-devel=148952187004611=2) and Daniel
suggested that this was roughly what vgem was supposed to do.

Adding the import methods for vgem covers all of what the
Ion test was doing and we don't have to invent yet another ioctl
interface and framework for attaching and mapping. 

Can you clarify about what you mean about 'virtual platform device'?


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

drm-tip/drm-tip boot: 119 boots: 2 failed, 117 passed (v4.11-rc5-1782-g71610c69d4f3)

[kernelci . org bot]

drm-tip/drm-tip boot: 119 boots: 2 failed, 117 passed 
(v4.11-rc5-1782-g71610c69d4f3)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1782-g71610c69d4f3/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1782-g71610c69d4f3/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1782-g71610c69d4f3
Git Commit: 71610c69d4f339a7d7eac2263743c14d592f3e9c
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 16 unique boards, 10 SoC families, 22 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5422-odroidxu3:
lab-collabora: new failure (last pass: v4.11-rc5-1643-ge087f8395ca3)

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
exynos5422-odroidxu3: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1785-g5a74def41941)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1785-g5a74def41941)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1785-g5a74def41941/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1785-g5a74def41941
Git Commit: 5a74def419415233546c4e853a3f02bb31daee82
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

drm-tip/drm-tip boot: 104 boots: 1 failed, 103 passed (v4.11-rc5-1780-g7373a000996b)

[kernelci . org bot]

drm-tip/drm-tip boot: 104 boots: 1 failed, 103 passed 
(v4.11-rc5-1780-g7373a000996b)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1780-g7373a000996b/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1780-g7373a000996b/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1780-g7373a000996b
Git Commit: 7373a000996bb20bbf3936bc79703bf08936a89c
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 16 unique boards, 10 SoC families, 21 builds out of 207

Boot Failure Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

[Chris Wilson]

On Fri, Apr 07, 2017 at 03:06:00PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> > On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > > Waiting a RCU grace period only guarantees the work gets queued, but
> > > until after the queued workqueue returns, there's no guarantee the
> > > memory was actually freed. So flush the work to provide better
> > > guarantees to the reclaim code in addition of waiting a RCU grace
> > > period to pass.
> > 
> > We are not allowed to call flush_work() from the shrinker, the workqueue
> > doesn't have and can't have the right reclaim flags.
> 
> I figured the flush_work had to be conditional to "unlock" being true
> too in the i915 shrinker (not only synchronize_rcu_expedited()), and I
> already fixed that bit, but I didn't think it would be a problem to
> wait for the workqueue as long as reclaim didn't recurse on the
> struct_mutex (it is a problem if unlock is false of course as we would
> be back to square one). I didn't get further hangs and I assume I've
> been running a couple of synchronize_rcu_expedited() and flush_work (I
> should add dynamic tracing to be sure).

Not getting hangs is a good sign, but lockdep doesn't like it:

[  460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418 
check_flush_dependency+0x92/0x130
[  460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H) is flushing 
!WQ_MEM_RECLAIM events:__i915_gem_free_work [i915]

If I allocated the workqueue with WQ_MEM_RELCAIM, it complains bitterly
as well.

> Also note, I didn't get any lockdep warning when I reproduced the
> workqueue hang in 4.11-rc5 so at least as far as lockdep is concerned
> there's no problem to call synchronize_rcu_expedited and it couldn't
> notice we were holding the struct_mutex while waiting for the new
> workqueue to run.

Yes, that is concerning. I think it's due to the coupling via
the struct completion that is not being picked up lockdep, and I hope
the "crossrelease" patches would fix the lack of warnings.

> Also note recursing on the lock (unlock false case) is something
> nothing else does, I'm not sure if it's worth the risk and if you
> shouldn't just call mutex_trylock in the shrinker instead of
> mutex_trylock_recursive. One thing was to recurse on the lock
> internally in the same context, but recursing through the whole
> reclaim is more dubious as safe.

We know. We don't use trylock in order to reduce the frequency of users'
oom. Peter added mutex_trylock_recursive() because we already were doing
recursive locking in the shrinker and although we know we shouldn't,
getting rid of the recursion is something we are doing, but slowly.

> You could start dropping objects and wiping vmas and stuff in the
> middle of some kmalloc/alloc_pages that doesn't expect it and then
> crash for other reasons. So this reclaim recursion model of the
> shinker is quite unique and quite challenging to proof as safe if you
> keep using mutex_trylock_recursive in i915_gem_shrinker_scan.

I know. Trying to stay on top of all the kmallocs under the struct_mutex
and being aware that the shrinker can and will undo your objects as you
work is a continual battle. And catches everyone working on i915.ko by
surprise. Our policy to avoid surprises is based around pin before alloc.
 
> Lock recursion in all other places could be dropped without runtime
> downsides, the only place mutex_trylock_recursive makes a design
> difference and makes sense to be used is in i915_gem_shrinker_scan,
> the rest are implementation issues not fundamental shrinker design and
> it'd be nice if those other mutex_trylock_recursive would all be
> removed and the only one that is left is in i915_gem_shrinker_scan and
> nowhere else (or to drop it also from i915_gem_shrinker_scan).

We do need it for shrinker_count as well. If we just report 0 objects,
the shrinker_scan callback will be skipped, iirc. All we do need it for
direct calls to i915_gem_shrink() which themselves may or may not be
underneath the struct_mutex at the time.

> mutex_trylock_recursive() should also be patched to use
> READ_ONCE(__mutex_owner(lock)) because currently it breaks C.

I don't follow,

static inline struct task_struct *__mutex_owner(struct mutex *lock)
{
return (struct task_struct *)(atomic_long_read(>owner) & ~0x07);
}

The atomic read is equivalent to READ_ONCE(). What's broken here? (I
guess strict aliasing and pointer cast?)

> In the whole kernel i915 and msm drm are the only two users of such
> function in fact.

Yes, Peter will continue to remind us to fix our code and complain until
it is.

> Another thing is what value return from i915_gem_shrinker_scan when
> unlock is false, and we can't possibly wait for the memory to be freed
> let alone for a rcu grace period. For various reasons I think it's
> safer to return the current "free" even if we could also return "0" in
> such case. There are different tradeoffs, returning "free" is 

Re: [PATCH] drm/vmwgfx: Fix fbdev emulation using legacy functions

[Daniel Vetter]

On Fri, Apr 07, 2017 at 10:31:29AM +0200, Thomas Hellstrom wrote:
> Hi, Daniel.
> 
> It appears to work fine. Thanks!

Oh sweet, tbh I didn't expect this kind of blind typing without a clear
theory to work out so well :-) Did you test this with
CONFIG_DEBUG_WW_MUTEX_SLOWPATH? Just to make sure I didn't botch up the
retry path.

> Do you want to take it through drm-misc or want me to take it throuch
> vmwgfx-next?

Sean will pick it up before he does the final 4.12 -misc pull later today,
so that this vmwgfx regression is resolved.

> Reviewed-by: Thomas Hellstrom 

Thanks for testing
-Daniel

> /Thomas
> 
> 
> 
> On 04/06/2017 10:02 PM, Daniel Vetter wrote:
> > I've broken this by removing the backoff handling from the
> > set_config2atomic helper in
> >
> > commit 38b6441e4e75c0b319cfe4d9364c1059fc1e3c2b
> > Author: Daniel Vetter 
> > Date:   Wed Mar 22 22:50:58 2017 +0100
> >
> > drm/atomic-helper: Remove the backoff hack from set_config
> >
> > Fixing this properly would mean we get to wire the acquire_ctx all the
> > way through vmwgfx fbdev code, and doing the same was tricky for the
> > shared fbdev layer. Probably much better to look into refactoring the
> > entire code to use the helpers, but since that's not a viable
> > long-term solution fix the issue by open-coding a vmwgfx version of
> > set_config, that does the legacy backoff dance internally.
> >
> > Note: Just compile-tested. The idea is to take
> > drm_mode_set_config_internal(), remove the "is this a legacy driver"
> > check, and whack the drm_atomic_legacy_backoff trickery at the end.
> > Since drm_atomic_legacy_backoff is for atomic commits only we need to
> > open-code it.
> >
> > Cc: Thomas Hellstrom 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 58 
> > --
> >  1 file changed, 56 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > index 09e120d50e65..6f4cb4678cbc 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > @@ -418,6 +418,60 @@ static int vmw_fb_compute_depth(struct 
> > fb_var_screeninfo *var,
> > return 0;
> >  }
> >  
> > +static int vmwgfx_set_config_internal(struct drm_mode_set *set)
> > +{
> > +   struct drm_crtc *crtc = set->crtc;
> > +   struct drm_framebuffer *fb;
> > +   struct drm_crtc *tmp;
> > +   struct drm_modeset_acquire_ctx *ctx;
> > +   struct drm_device *dev = set->crtc->dev;
> > +   int ret;
> > +
> > +   ctx = dev->mode_config.acquire_ctx;
> > +
> > +restart:
> > +   /*
> > +* NOTE: ->set_config can also disable other crtcs (if we steal all
> > +* connectors from it), hence we need to refcount the fbs across all
> > +* crtcs. Atomic modeset will have saner semantics ...
> > +*/
> > +   drm_for_each_crtc(tmp, dev)
> > +   tmp->primary->old_fb = tmp->primary->fb;
> > +
> > +   fb = set->fb;
> > +
> > +   ret = crtc->funcs->set_config(set, ctx);
> > +   if (ret == 0) {
> > +   crtc->primary->crtc = crtc;
> > +   crtc->primary->fb = fb;
> > +   }
> > +
> > +   drm_for_each_crtc(tmp, dev) {
> > +   if (tmp->primary->fb)
> > +   drm_framebuffer_get(tmp->primary->fb);
> > +   if (tmp->primary->old_fb)
> > +   drm_framebuffer_put(tmp->primary->old_fb);
> > +   tmp->primary->old_fb = NULL;
> > +   }
> > +
> > +   if (ret == -EDEADLK) {
> > +   dev->mode_config.acquire_ctx = NULL;
> > +
> > +retry_locking:
> > +   drm_modeset_backoff(ctx);
> > +
> > +   ret = drm_modeset_lock_all_ctx(dev, ctx);
> > +   if (ret)
> > +   goto retry_locking;
> > +
> > +   dev->mode_config.acquire_ctx = ctx;
> > +
> > +   goto restart;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static int vmw_fb_kms_detach(struct vmw_fb_par *par,
> >  bool detach_bo,
> >  bool unref_bo)
> > @@ -436,7 +490,7 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,
> > set.fb = NULL;
> > set.num_connectors = 0;
> > set.connectors = >con;
> > -   ret = drm_mode_set_config_internal();
> > +   ret = vmwgfx_set_config_internal();
> > if (ret) {
> > DRM_ERROR("Could not unset a mode.\n");
> > return ret;
> > @@ -578,7 +632,7 @@ static int vmw_fb_set_par(struct fb_info *info)
> > set.num_connectors = 1;
> > set.connectors = >con;
> >  
> > -   ret = drm_mode_set_config_internal();
> > +   ret = vmwgfx_set_config_internal();
> > if (ret)
> > goto out_unlock;
> >  
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list

drm-tip/drm-tip boot: 97 boots: 1 failed, 96 passed (v4.11-rc5-1777-gfdc0fa0d6347)

[kernelci . org bot]

drm-tip/drm-tip boot: 97 boots: 1 failed, 96 passed 
(v4.11-rc5-1777-gfdc0fa0d6347)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1777-gfdc0fa0d6347/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1777-gfdc0fa0d6347/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1777-gfdc0fa0d6347
Git Commit: fdc0fa0d6347cadec14396a172a98636e9dfebc0
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 15 unique boards, 9 SoC families, 20 builds out of 207

Boot Failure Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm: zte: add VGA driver support

[Sean Paul]

On Fri, Apr 07, 2017 at 11:02:33AM +0800, Shawn Guo wrote:
> On Thu, Apr 06, 2017 at 01:12:51PM -0400, Sean Paul wrote:
> > On Thu, Apr 06, 2017 at 11:01:10PM +0800, Shawn Guo wrote:
> > > +static int zx_vga_connector_get_modes(struct drm_connector *connector)
> > > +{
> > > + struct zx_vga *vga = to_zx_vga(connector);
> > > + unsigned long flags;
> > > + struct edid *edid;
> > > + int ret;
> > > +
> > > + /*
> > > +  * Clear both detection bits to switch I2C bus from device
> > > +  * detecting to EDID reading.
> > > +  */
> > > + spin_lock_irqsave(>lock, flags);
> > > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
> > > + spin_unlock_irqrestore(>lock, flags);
> > > +
> > > + edid = drm_get_edid(connector, >ddc->adap);
> > > + if (!edid)
> > > + return 0;
> > > +
> > > + /*
> > > +  * As edid reading succeeds, device must be connected, so we set
> > > +  * up detection bit for unplug interrupt here.
> > > +  */
> > > + spin_lock_irqsave(>lock, flags);
> > > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, VGA_DETECT_SEL_HAS_DEVICE);
> > > + spin_unlock_irqrestore(>lock, flags);
> > > +
> > > + drm_mode_connector_update_edid_property(connector, edid);
> > > + ret = drm_add_edid_modes(connector, edid);
> > > + kfree(edid);
> > > +
> > > + return ret;
> > > +}
> 
> 
> 
> > > +static irqreturn_t zx_vga_irq_handler(int irq, void *dev_id)
> > > +{
> > > + struct zx_vga *vga = dev_id;
> > > + u32 status;
> > > +
> > > + status = zx_readl(vga->mmio + VGA_I2C_STATUS);
> > > +
> > > + /* Clear interrupt status */
> > > + zx_writel_mask(vga->mmio + VGA_I2C_STATUS, VGA_CLEAR_IRQ,
> > > +VGA_CLEAR_IRQ);
> > > +
> > > + if (status & VGA_DEVICE_CONNECTED) {
> > > + /*
> > > +  * Since VGA_DETECT_SEL bits need to be reset for switching DDC
> > > +  * bus from device detection to EDID read, rather than setting
> > > +  * up HAS_DEVICE bit here, we need to do that in .get_modes
> > > +  * hook for unplug detecting after EDID read succeeds.
> > > +  */
> > > + vga->connected = true;
> > > + return IRQ_WAKE_THREAD;
> > > + }
> > > +
> > > + if (status & VGA_DEVICE_DISCONNECTED) {
> > > + spin_lock(>lock);
> > > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL,
> > > +   VGA_DETECT_SEL_NO_DEVICE);
> > > + spin_unlock(>lock);
> > 
> > I think you still have the race here. If you get a disconnect between 
> > get_edid
> > successfully finishing, and resetting the DETECT_SEL register, you will end 
> > up
> > with the device being disconnected and DETECT_SEL == 
> > VGA_DETECT_SEL_HAS_DEVICE.
> > 
> > In order to close this, you'll need to hold the lock across the edid read.
> 
> We cannot hold a spin lock across the EDID read procedure, which does
> sleep.

Yeah, this is a pretty common problem. We usually use a mutex in conjunction
with a work function to handle this type of thing.

> 
> When you suggested to have a lock for DETECT_SEL register access, I
> thought we are accessing it in a read-modify-write way and thus agreed
> to add a lock.  However, I just found that it's not the case actually.
> All the accesses to the register are single direct write.
> 
> And here is my understanding about the condition you described above.
> Once DETECT_SEL register gets reset (both bits cleared), the hardware
> switches DDC bus for EDID read, and hotplug detection will stop working
> right away (this is how ZTE hardware works).  That said, if we get a
> disconnect before drm_get_edid() successfully finishes, two points:
> 
> - The irq handler will not be triggered, so it will not get a chance to
>   update DETECT_SEL register.

Ah, this was the missing piece I needed. I hadn't realized that the first
VGA_AUTO_DETECT_SEL write in get_modes disabled the irq. 


> - The drm_get_edid() fails, and .get_modes returns with both detect bits
>   kept cleared.
> 
> I think what we can do better in this case is that we should set the
> device state into disconnected, before returning from .get_modes,
> something like the code below.  But still, I do not see we need a lock
> for that.

Yep, agreed. Can you also please add to your comment in the !edid case,
something like:

* Locking is not required here since the only other place to write this register
* (and connected var) is the irq handler. The irq handler is disabled because
* we've cleared AUTO_DETECT_SEL above.

Thanks for walking me through this.

Sean

> 
> Shawn
> 
> static int zx_vga_connector_get_modes(struct drm_connector *connector)
> {
> struct zx_vga *vga = to_zx_vga(connector);
> unsigned long flags;
> struct edid *edid;
> int ret;
> 
> /*
>  * Clear both detection bits to switch I2C bus from device
>  * detecting to EDID reading.
>  */
> zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
> 
> edid = drm_get_edid(connector, >ddc->adap);
> if (!edid) {
> /*
>   

Re: [PATCH 2/2] drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks

[Neil Armstrong]

On 04/07/2017 04:19 PM, Romain Perier wrote:
> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
> step E. and is kept enabled for later use. This clock should be enabled
> and disabled along with the actual audio stream and not always on (that
> is bad for PM). Futhermore, as described by the datasheet, the I2S
> variant need to gate/ungate the clock when the stream is
> enabled/disabled.
> 
> This commit adds a parameter to hdmi_audio_enable_clk() that controls
> when the audio sample clock must be enabled or disabled. Then, it adds
> the call to this function from dw_hdmi_i2s_audio_enable() and
> dw_hdmi_i2s_audio_disable().
> 
> Signed-off-by: Romain Perier 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index d34e0a5..3bd0807 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -559,6 +559,12 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, 
> unsigned int rate)
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
>  
> +static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
> +{
> + hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
> +   HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
> +}
> +
>  void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
>  {
>   hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
> @@ -572,12 +578,13 @@ void dw_hdmi_ahb_audio_disable(struct dw_hdmi *hdmi)
>  void dw_hdmi_i2s_audio_enable(struct dw_hdmi *hdmi)
>  {
>   hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
> + hdmi_enable_audio_clk(hdmi, true);
>  }
>  
>  
>  void dw_hdmi_i2s_audio_disable(struct dw_hdmi *hdmi)
>  {
> -
> + hdmi_enable_audio_clk(hdmi, false);
>  }

I think the NULL check is still valid if you fill this function, because the IP 
also
support other modes (SPDIF and GPA).

>  
>  void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
> @@ -1365,11 +1372,6 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
> *hdmi)
>   }
>  }
>  
> -static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
> -{
> - hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
> -}
> -
>  /* Workaround to clear the overflow condition */
>  static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
>  {
> @@ -1471,7 +1473,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>  
>   /* HDMI Initialization Step E - Configure audio */
>   hdmi_clk_regenerator_update_pixel_clock(hdmi);
> - hdmi_enable_audio_clk(hdmi);
> + hdmi_enable_audio_clk(hdmi, true);
>   }
>  
>   /* not for DVI mode */
> 

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

Re: [PATCH 1/2] drm: dw-hdmi: add specific I2S and AHB functions for stream handling

[Neil Armstrong]

On 04/07/2017 04:19 PM, Romain Perier wrote:
> Currently, CTS+N is forced to zero as a workaround of the IP block for
> i.MX platforms. This is requested in the datasheet of the corresponding
> IP for AHB mode only. However, we have seen that it introduces glitches
> or delays when playing a sound on HDMI for I2S mode. This proves that we
> cannot keep the current functions for handling audio stream as-is if
> these contain workaround that are specific to a mode.
> 
> This commit introduces two callbacks, one for each variant.
> dw_hdmi_setup defines the right function depending on the detected
> variant. Then, the exported functions dw_hdmi_audio_enable and
> dw_hdmi_audio_disable calls the corresponding callbacks

Thanks for the patch, I'll test it on the Amlogic platform.

> 
> Signed-off-by: Romain Perier 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 542d198..d34e0a5 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -166,6 +166,8 @@ struct dw_hdmi {
>  
>   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
>   u8 (*read)(struct dw_hdmi *hdmi, int offset);
> + void (*enable_audio)(struct dw_hdmi *hdmi);
> + void (*disable_audio)(struct dw_hdmi *hdmi);
>  };
>  
>  #define HDMI_IH_PHY_STAT0_RX_SENSE \
> @@ -557,13 +559,34 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, 
> unsigned int rate)
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
>  
> +void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
> +{
> + hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
> +}
> +
> +void dw_hdmi_ahb_audio_disable(struct dw_hdmi *hdmi)
> +{
> + hdmi_set_cts_n(hdmi, hdmi->audio_cts, 0);
> +}
> +
> +void dw_hdmi_i2s_audio_enable(struct dw_hdmi *hdmi)
> +{
> + hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
> +}
> +
> +
> +void dw_hdmi_i2s_audio_disable(struct dw_hdmi *hdmi)
> +{
> +
> +}

For this one, it would be better to set it to NULL then check for NULL...

> +
>  void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
>  {
>   unsigned long flags;
>  
>   spin_lock_irqsave(>audio_lock, flags);
>   hdmi->audio_enable = true;
> - hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
> + hdmi->enable_audio(hdmi);

if (hdmi->enable_audio)
hdmi->enable_audio(hdmi);

for consistency...

>   spin_unlock_irqrestore(>audio_lock, flags);
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_enable);
> @@ -574,7 +597,7 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>  
>   spin_lock_irqsave(>audio_lock, flags);
>   hdmi->audio_enable = false;
> - hdmi_set_cts_n(hdmi, hdmi->audio_cts, 0);
> + hdmi->disable_audio(hdmi);

if (hdmi->disable_audio)
hdmi->disable_audio(hdmi);

>   spin_unlock_irqrestore(>audio_lock, flags);
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
> @@ -2114,6 +2137,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   audio.irq = irq;
>   audio.hdmi = hdmi;
>   audio.eld = hdmi->connector.eld;
> + hdmi->enable_audio = dw_hdmi_ahb_audio_enable;
> + hdmi->disable_audio = dw_hdmi_ahb_audio_disable;
>  
>   pdevinfo.name = "dw-hdmi-ahb-audio";
>   pdevinfo.data = 
> @@ -2126,6 +2151,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   audio.hdmi  = hdmi;
>   audio.write = hdmi_writeb;
>   audio.read  = hdmi_readb;
> + hdmi->enable_audio = dw_hdmi_i2s_audio_enable;
> + hdmi->disable_audio = dw_hdmi_i2s_audio_disable;
>  
>   pdevinfo.name = "dw-hdmi-i2s-audio";
>   pdevinfo.data = 
> 

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

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1784-gc5d424760e9a)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1784-gc5d424760e9a)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1784-gc5d424760e9a/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1784-gc5d424760e9a
Git Commit: c5d424760e9a5d40f7024591d5e69f074711e7ff
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

drm-tip/drm-tip boot: 78 boots: 1 failed, 77 passed (v4.11-rc5-1776-g5aa5296d0b57)

[kernelci . org bot]

drm-tip/drm-tip boot: 78 boots: 1 failed, 77 passed 
(v4.11-rc5-1776-g5aa5296d0b57)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1776-g5aa5296d0b57/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1776-g5aa5296d0b57/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1776-g5aa5296d0b57
Git Commit: 5aa5296d0b577748312afc42e0b4ed3680da7288
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 13 unique boards, 9 SoC families, 20 builds out of 207

Boot Failure Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100611] [ALL][BAT][bisected] all systems on CI fails on certain test

[bugzilla-daemon]

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

--- Comment #3 from Jani Saarinen  ---
Whilelisted on CI.

-- 
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 100611] [ALL][BAT][bisected] all systems on CI fails on certain test

[bugzilla-daemon]

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

Petri Latvala  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Petri Latvala  ---
(In reply to Daniel Stone from comment #1)
> Patch on list:
> https://lists.freedesktop.org/archives/intel-gfx/2017-April/125407.html

And is now in git.

-- 
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 100611] [ALL][BAT][bisected] all systems on CI fails on certain test

[bugzilla-daemon]

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

Petri Latvala  changed:

   What|Removed |Added

   Assignee|conselv...@gmail.com|dri-devel@lists.freedesktop
   ||.org
  Component|libdrm  |IGT

-- 
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 5/5] i915: fence workqueue optimization

[Andrea Arcangeli]

On Fri, Apr 07, 2017 at 10:58:38AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:47AM +0200, Andrea Arcangeli wrote:
> > Insist to run llist_del_all() until the free_list is found empty, this
> > may avoid having to schedule more workqueues.
> 
> The work will already be scheduled (everytime we add the first element,
> the work is scheduled, and the scheduled bit is cleared before the work
> is executed). So we aren't saving the kworker from having to process
> another work, but we may make that having nothing to do. The question is
> whether we want to trap the kworker here, and presumably you will also want
> to add a cond_resched() between passes.

Yes it is somewhat dubious in the two event only case, but it will
save kworker in case of more events if there is a flood of
llist_add. It just looked fast enough but it's up to you, it's a
cmpxchg more for each intel_atomic_helper_free_state. If it's unlikely
more work is added, it's better to drop it. Agree about
cond_resched() if we keep it.

The same issue exists in __i915_gem_free_work, but I guess it's more
likely there that by the time __i915_gem_free_objects returns the
free_list isn't empty anymore because __i915_gem_free_objects has a
longer runtime but then you may want to re-evaluate that too as it's
slower for the two llist_add in a row case and only pays off from the
third.

while ((freed = llist_del_all(>mm.free_list)))
__i915_gem_free_objects(i915, freed);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Don't allow interruptions when opening debugfs/crc

[Ville Syrjälä]

On Fri, Apr 07, 2017 at 12:17:12PM +0100, Chris Wilson wrote:
> The code does not like to be interrupted when waiting for the first
> vblank after opening a debugfs/crc channel, so don't.
> 
> [66285.716870] WARNING: CPU: 1 PID: 16615 at 
> drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm]
> [66285.716877] Modules linked in: i915 intel_powerclamp crct10dif_pclmul 
> crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd intel_gtt i2c_algo_bit 
> lpc_ich mfd_core drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops 
> prime_numbers drm video button autofs4 sd_mod ahci libahci libata i2c_i801 
> scsi_mod i2c_designware_platform i2c_designware_core i2c_core
> [66285.716929] CPU: 1 PID: 16615 Comm: kms_frontbuffer Not tainted 
> 4.11.0-rc5+ #7
> [66285.716935] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F8 
> 03/02/2016
> [66285.716941] Call Trace:
> [66285.716955]  dump_stack+0x4d/0x6f
> [66285.716966]  __warn+0xc1/0xe0
> [66285.716975]  warn_slowpath_null+0x18/0x20
> [66285.717004]  crtc_crc_open+0x1d0/0x1f0 [drm]
> [66285.717014]  ? wake_atomic_t_function+0x50/0x50
> [66285.717024]  full_proxy_open+0xf0/0x1b0
> [66285.717032]  ? full_proxy_release+0x80/0x80
> [66285.717042]  do_dentry_open.isra.17+0x14b/0x2d0
> [66285.717051]  vfs_open+0x42/0x60
> [66285.717064]  path_openat+0x5e7/0x13d0
> [66285.717074]  ? refcount_dec_and_test+0x11/0x20
> [66285.717081]  ? down_read+0xd/0x30
> [66285.717087]  do_filp_open+0x85/0xf0
> [66285.717093]  ? __vfs_write+0x23/0x120
> [66285.717100]  ? __alloc_fd+0x3a/0x170
> [66285.717107]  do_sys_open+0x11e/0x1f0
> [66285.717113]  ? do_sys_open+0x11e/0x1f0
> [66285.717119]  SyS_openat+0xf/0x20
> [66285.717125]  entry_SYSCALL_64_fastpath+0x17/0x98
> [66285.717131] RIP: 0033:0x7f5f2235146a
> [66285.717135] RSP: 002b:7ffd892e6bc0 EFLAGS: 0246 ORIG_RAX: 
> 0101
> [66285.717142] RAX: ffda RBX:  RCX: 
> 7f5f2235146a
> [66285.717147] RDX:  RSI: 7ffd892e6c40 RDI: 
> 0006
> [66285.717151] RBP: 7ffd892e6b20 R08:  R09: 
> 000f
> [66285.717156] R10:  R11: 0246 R12: 
> 0001
> [66285.717161] R13: 7ffd892e6b10 R14: 0004 R15: 
> 007e61f4
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610
> Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from 
> open()")
> Signed-off-by: Chris Wilson 
> Cc: Tomeu Vizoso 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_debugfs_crc.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 1722d8f21449..aa13e734c9e5 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -177,13 +177,9 @@ static int crtc_crc_open(struct inode *inode, struct 
> file *filep)
>* guess when this particular piece of HW will be ready to start
>* generating CRCs.
>*/
> - ret = wait_event_interruptible_lock_irq(crc->wq,
> - crtc_crc_data_count(crc),
> - crc->lock);
> + wait_event_lock_irq(crc->wq, crtc_crc_data_count(crc), crc->lock);

What if the crc never gets produced? The first read will block if
the user asked it to block, so I don't really see the point of this
wait at all.

Seems to me that the crc thing needs to be pimped work better in cases
where the crtc is disabled. Currently it's kinda trying to hide a bit
too much to be useful for observing the hardware behaviour during crtc
enable/disable. I have definitely used it in the past to observe that,
but I'm not sure the current thing really works for that anymore.

>   spin_unlock_irq(>lock);
>  
> - WARN_ON(ret);
> -
>   return 0;
>  
>  err_disable:
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 100611] [ALL][BAT][bisected] all systems on CI fails on certain test

[bugzilla-daemon]

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

Jani Saarinen  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |conselv...@gmail.com
   |.org|

-- 
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 100611] [ALL][BAT][bisected] all systems on CI fails on certain test

[bugzilla-daemon]

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

Bug ID: 100611
   Summary: [ALL][BAT][bisected] all systems on CI fails on
certain test
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jani.saari...@intel.com

On CI test igt@kms_frontbuffer_tracking@basic started failing

https://intel-gfx-ci.01.org/CI/igt@kms_frontbuffer_track...@basic.html

Was bisected to:
commit 890d43a6a8d091211b82dd432af5e0a38472ffa6
Author: Ander Conselvan de Oliveira 
Date:   Mon Aug 17 16:21:24 2015 +0300

 Add CRTC ID to vblank event

 When using the atomic API, one request can span multiple CRTCs, however
 one event is generated per CRTC. As we cannot disambiguate the CRTC 
with
 user data (since we only have one piece of user data to pass in), newer
 kernels can include the CRTC ID in the page flip event.

 Add a new vfunc to dispatch vblank events carrying a CRTC ID to clients
 who negotiate a higher interface version.

 [daniels: Rebased, include new cap, call page_flip_handler if it is set
   but page_flip_handler2 isn't even on newer contexts, write a
   commit message.]

 v2: Split into separate commit.

 Signed-off-by: Ander Conselvan de Oliveira 

 Signed-off-by: Daniel Stone 
 Reviewed-by: Maarten Lankhorst 

-- 
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/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

[Andrea Arcangeli]

On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > Waiting a RCU grace period only guarantees the work gets queued, but
> > until after the queued workqueue returns, there's no guarantee the
> > memory was actually freed. So flush the work to provide better
> > guarantees to the reclaim code in addition of waiting a RCU grace
> > period to pass.
> 
> We are not allowed to call flush_work() from the shrinker, the workqueue
> doesn't have and can't have the right reclaim flags.

I figured the flush_work had to be conditional to "unlock" being true
too in the i915 shrinker (not only synchronize_rcu_expedited()), and I
already fixed that bit, but I didn't think it would be a problem to
wait for the workqueue as long as reclaim didn't recurse on the
struct_mutex (it is a problem if unlock is false of course as we would
be back to square one). I didn't get further hangs and I assume I've
been running a couple of synchronize_rcu_expedited() and flush_work (I
should add dynamic tracing to be sure).

Also note, I didn't get any lockdep warning when I reproduced the
workqueue hang in 4.11-rc5 so at least as far as lockdep is concerned
there's no problem to call synchronize_rcu_expedited and it couldn't
notice we were holding the struct_mutex while waiting for the new
workqueue to run.

Also note recursing on the lock (unlock false case) is something
nothing else does, I'm not sure if it's worth the risk and if you
shouldn't just call mutex_trylock in the shrinker instead of
mutex_trylock_recursive. One thing was to recurse on the lock
internally in the same context, but recursing through the whole
reclaim is more dubious as safe.

You could start dropping objects and wiping vmas and stuff in the
middle of some kmalloc/alloc_pages that doesn't expect it and then
crash for other reasons. So this reclaim recursion model of the
shinker is quite unique and quite challenging to proof as safe if you
keep using mutex_trylock_recursive in i915_gem_shrinker_scan.

Lock recursion in all other places could be dropped without runtime
downsides, the only place mutex_trylock_recursive makes a design
difference and makes sense to be used is in i915_gem_shrinker_scan,
the rest are implementation issues not fundamental shrinker design and
it'd be nice if those other mutex_trylock_recursive would all be
removed and the only one that is left is in i915_gem_shrinker_scan and
nowhere else (or to drop it also from i915_gem_shrinker_scan).

mutex_trylock_recursive() should also be patched to use
READ_ONCE(__mutex_owner(lock)) because currently it breaks C.

In the whole kernel i915 and msm drm are the only two users of such
function in fact.

Another thing is what value return from i915_gem_shrinker_scan when
unlock is false, and we can't possibly wait for the memory to be freed
let alone for a rcu grace period. For various reasons I think it's
safer to return the current "free" even if we could also return "0" in
such case. There are different tradeoffs, returning "free" is less
likely to trigger an early OOM as the VM thinks it's still making
progress and in fact it will get more free memory shortly, while
returning SHRINK_STOP would also be an option and it would insist more
on the other slabs so it would be more reliable at freeing memory
timely, but it would be more at risk of early OOM. I think returning
"free" is the better tradeoff of the two, but I suggest to add a
comment as it's not exactly obvious what is better.

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

Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

[Laurent Pinchart]

Hi Geert and Rob,

On Thursday 16 Mar 2017 21:59:04 Geert Uytterhoeven wrote:
> On Thu, Mar 16, 2017 at 9:56 PM, Rob Herring  wrote:
> > On Thu, Mar 16, 2017 at 09:13:16AM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Mar 15, 2017 at 6:01 PM, Rob Herring  wrote:
> >>> On Mon, Mar 06, 2017 at 05:25:56PM +0100, Geert Uytterhoeven wrote:
>  Document the optional properties for describing module resets, to
>  support resetting display channels and LVDS encoders on R-Car Gen2 and
>  Gen3.
>  
>  Signed-off-by: Geert Uytterhoeven 
>  ---
>  See "[v2,1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset
>  control support" (https://patchwork.kernel.org/patch/9536627/) for the
>  format of a reset specifier in the Renesas CPG/MSSR case.
>  
>  E.g. "resets = < 310>;"
>  
>  v2:
>    - s/phandles/phandle/.
>  
>  ---
>  
>   Documentation/devicetree/bindings/display/renesas,du.txt | 10 
>   1 file changed, 10 insertions(+)
>  
>  diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>  b/Documentation/devicetree/bindings/display/renesas,du.txt index
>  1a02f099a0ff0a3a..3db418c827193e82 100644
>  --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>  +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>  @@ -36,6 +36,16 @@ Required Properties:
> When supplied they must be named "dclkin.x" with "x" being the
> input clock numerical index.
>  
>  +Optional properties:
>  +  - resets: A list of phandle + reset-specifier pairs, one for each
>  entry in
>  +the reset-names property.
>  +  - reset-names: Names of the resets. This property is
>  model-dependent.
>  +- R8A779[0123456] use one reset for a group of one or more
>  successive
>  +  channels, and one reset per LVDS encoder (if available). The
>  resets
>  +  must be named "du.x" with "x" being the numerical index of the
>  lowest
>  +  channel in the group. The LVDS resets must be named "lvds.x"
>  with "x"
>  +  being the LVDS encoder numerical index.
> >>> 
> >>> LVDS is not a separate block?
> >> 
> >> Well... from a hardware point of view, the LVDS encoders and DU channels
> >> are all separate blocks (they have separate reg blocks, clocks, and
> >> resets). But due to the dependencies between the blocks, they're modeled
> >> in DT as a single device, with multiple reg, clocks, and resets
> >> properties.
> >
> > Dependencies being DRM requirement of wanting a single device with
> > sub-devices or some h/w dependencies? The former shouldn't define your
> > binding.
> 
> Hardware dependencies. Laurent can tell you more about them (when he'll
> be back).

I believe we could model the LVDS encoder as a separate DT node. It was 
probably a historical mistake (that would however need to be confirmed, I 
haven't double-checked all details). Obviously I can't break backward 
compatibility, so we're kind of stuck :-S

-- 
Regards,

Laurent Pinchart

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

Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

[Ville Syrjälä]

On Fri, Apr 07, 2017 at 12:06:26PM +0200, Gerd Hoffmann wrote:
> On Fr, 2017-04-07 at 11:45 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > Hmm. Maybe it's still possible to salvage something by redefining the
> > > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it
> > > > might still result in something usable.
> > > 
> > > Also at least for the virtual machine use case this doesn't buy us much.
> > > The drm drivers (at least the ones used on both big and little endian
> > > guests) support only 32 bpp + depth 24 formats.  And for these we don't
> > > need a "other endian" flag because we have fourcc codes for all sorts of
> > > byte orders (i.e. DRM_FORMAT_XRGB little endian ==
> > > DRM_FORMAT_BGRX big endian).
> > 
> > Yeah, those could be handled without the flag. But when mixed with any
> > other format the code would look a bit weird IMO.
> 
> Well, there is a reason only the 32bpp formats are supported.  With
> those you just adjust your color shifts and you are done.  No need to
> actually byte-swap.  In contrast handling 16bpp formats (5:6:5 or 5:5:5)
> with the non-native byte order is a PITA.

Yes, which is why I wanted to make the format endianness explicit from
the start so that you wouldn't have to guess whether you need to byte
swap or not.

> 
> The other reason of course is that this is the default format these
> days.
> 
> So, do any "other formats" exist where the byteswapped variant is used
> in practice?

I'm expecting people to move past 8bpc at some point. It's definitely
not enough for HDR stuff and whatnot. Even video content is already
moving to 10bpc.

So I think the question is better phrased as do mixed endian systems
exist? Or even if they do, does anyone care about them?

Also if someone goes and changes the DRM_FORMATs to follow host
endianness, they definitely have to figure out how to handle all
the YCbCr formats as well.

> Or can we just drop DRM_FORMAT_BIG_ENDIAN?
> 
> > So my idea with the
> > flag was that if you display is big endian you always have the flag, and
> > then you don't have to think so much which way the bytes go for each
> > format. Less special casing is good IMO.
> 
> Having two valid fourcc (DRM_FORMAT_XRGB + (DRM_FORMAT_BGRX |
> DRM_FORMAT_BIG_ENDIAN)) for the same format is confusing IMO.  And I
> doubt that it'll be properly implemented everywhere.

I think it would be if people actually handled any of the other formats.
It's a real shame these 8:8:8:8 formats were invented in the first place.
They allow people to be overly lazy and ignore endianness issues until
it's too late to fix things.

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

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1782-g71610c69d4f3)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1782-g71610c69d4f3)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1782-g71610c69d4f3/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1782-g71610c69d4f3
Git Commit: 71610c69d4f339a7d7eac2263743c14d592f3e9c
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

[Bug 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

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

Matt Corallo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Matt Corallo  ---
Fixed in stable/LTS/mainline.

-- 
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: [RFC v2 07/11] vb2: dma-contig: Remove redundant sgt_base field

[Sakari Ailus]

Hi Shuah,

On Mon, Mar 27, 2017 at 04:51:40PM -0600, Shuah Khan wrote:
> On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
>  wrote:
> > From: Sakari Ailus 
> >
> > The struct vb2_dc_buf contains two struct sg_table fields: sgt_base and
> > dma_sgt. The former is used by DMA-BUF buffers whereas the latter is used
> > by USERPTR.
> >
> > Unify the two, leaving dma_sgt.
> 
> I think this patch should be split in two.
> 
> 1. Unifying dma_sgt and sgt_base
> 
> >
> > MMAP buffers do not need cache flushing since they have been allocated
> > using dma_alloc_coherent().
> 
> 2. That uses vec to check for checking for no flush needed condition.

I can split this, sure. A non-NULL vec indicates a USERPTR buffer. Before
this patch, non-NULL buf->dma_sgt did the same.

> 
> >
> > Signed-off-by: Sakari Ailus 
> > ---
> > Changes since v1:
> >
> > - Test for MMAP or DMABUF type through the vec field instead of the now
> >   gone vma field.
> 
> What is this gone vma field? Did I miss a patch in the series that
> makes this change? This check that is changed used dma_sgt and
> db_attach vma
> 

The field existed on bc0195aad0daa2ad5b0d76cce22b167bc3435590, i.e. v4.2-rc2
from which the earlier version of this patch was rebased from.

> These comments don't agree with the code change.
> 
> > - Move the vec field to a USERPTR section in struct vb2_dc_buf, where
> >   the vma field was located.
> > ---
> >  drivers/media/v4l2-core/videobuf2-dma-contig.c | 25 
> > +
> >  1 file changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> > b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> > index fb6a177be461..2a00d12ffee2 100644
> > --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> > +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> > @@ -30,12 +30,13 @@ struct vb2_dc_buf {
> > unsigned long   attrs;
> > enum dma_data_direction dma_dir;
> > struct sg_table *dma_sgt;
> > -   struct frame_vector *vec;
> >
> > /* MMAP related */
> > struct vb2_vmarea_handler   handler;
> > atomic_trefcount;
> > -   struct sg_table *sgt_base;
> > +
> > +   /* USERPTR related */
> > +   struct frame_vector *vec;
> >
> > /* DMABUF related */
> > struct dma_buf_attachment   *db_attach;
> > @@ -95,7 +96,7 @@ static void vb2_dc_prepare(void *buf_priv)
> > struct sg_table *sgt = buf->dma_sgt;
> >
> > /* DMABUF exporter will flush the cache for us */
> > -   if (!sgt || buf->db_attach)
> > +   if (!buf->vec)
> > return;
> 
> With the unification dma_sgt is valid for MMAP buffers after 
> vb2_dma_sg_alloc()
> if dma_sgt is not null, sync happens - the patch description doesn't seem to 
> be
> in sync with the change.

I'm not sure what you're referring to. The condition for sync is changed to
use buf->vec instead, i.e. the functionality is not affected.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings (v4.11-rc5-1780-g7373a000996b)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings 
(v4.11-rc5-1780-g7373a000996b)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1780-g7373a000996b/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1780-g7373a000996b
Git Commit: 7373a000996bb20bbf3936bc79703bf08936a89c
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

Re: [PATCHv6 03/10] exynos_hdmi: add CEC notifier support

[Andrzej Hajda]

On 31.03.2017 14:20, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Implement the CEC notifier support to allow CEC drivers to
> be informed when there is a new physical address.
>
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> Acked-by: Daniel Vetter 
> Acked-by: Krzysztof Kozlowski 

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 88ccc0469316..bc4c8d0a66f4 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -43,6 +43,8 @@
>  
>  #include 
>  
> +#include 
> +
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_crtc.h"
>  
> @@ -119,6 +121,7 @@ struct hdmi_context {
>   booldvi_mode;
>   struct delayed_work hotplug_work;
>   struct drm_display_mode current_mode;
> + struct cec_notifier *notifier;
>   const struct hdmi_driver_data   *drv_data;
>  
>   void __iomem*regs;
> @@ -822,6 +825,7 @@ static enum drm_connector_status hdmi_detect(struct 
> drm_connector *connector,
>   if (gpiod_get_value(hdata->hpd_gpio))
>   return connector_status_connected;
>  
> + cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
>   return connector_status_disconnected;
>  }
>  
> @@ -860,6 +864,7 @@ static int hdmi_get_modes(struct drm_connector *connector)
>   edid->width_cm, edid->height_cm);
>  
>   drm_mode_connector_update_edid_property(connector, edid);
> + cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
>  
>   ret = drm_add_edid_modes(connector, edid);
>  
> @@ -1503,6 +1508,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
>   if (funcs && funcs->disable)
>   (*funcs->disable)(crtc);
>  
> + cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
>   cancel_delayed_work(>hotplug_work);
>  
>   hdmiphy_disable(hdata);
> @@ -1878,15 +1884,22 @@ static int hdmi_probe(struct platform_device *pdev)
>   }
>   }
>  
> + hdata->notifier = cec_notifier_get(>dev);
> + if (hdata->notifier == NULL) {
> + ret = -ENOMEM;
> + goto err_hdmiphy;
> + }
> +
>   pm_runtime_enable(dev);
>  
>   ret = component_add(>dev, _component_ops);
>   if (ret)
> - goto err_disable_pm_runtime;
> + goto err_notifier_put;
>  
>   return ret;
>  
> -err_disable_pm_runtime:
> +err_notifier_put:
> + cec_notifier_put(hdata->notifier);
>   pm_runtime_disable(dev);
>  
>  err_hdmiphy:
> @@ -1905,9 +1918,11 @@ static int hdmi_remove(struct platform_device *pdev)
>   struct hdmi_context *hdata = platform_get_drvdata(pdev);
>  
>   cancel_delayed_work_sync(>hotplug_work);
> + cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
>  
>   component_del(>dev, _component_ops);
>  
> + cec_notifier_put(hdata->notifier);
>   pm_runtime_disable(>dev);
>  
>   if (!IS_ERR(hdata->reg_hdmi_en))


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

[PATCH libdrm v2 1/2] etnaviv: sync uapi header

[Philipp Zabel]

Import the etnaviv header changes from kernel commits 9ad59fea162c
("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
("drm/etnaviv: submit support for out-fences") for fence fd support.

The drm_etnaviv_gem_submit structure was extended to include a flags
field, new flags for in-fence and out-fence fds and an input/output
fence fd field.

This is one-way backwards compatible because old userspace code passing
a short structure not including the flags field to new kernels will
cause the remaining fields to be zero-filled. New userspace code must
make sure to only pass the short structure to old kernels, though.

Not generated using make headers_install, since the drm/etnaviv_drm.h
uapi header is not installed yet by the kernel.
Copied from the airlied/drm-next commit 78ec187f64fa.

Signed-off-by: Philipp Zabel 
Reviewed-by: Christian Gmeiner 
---
v2: improved commit message
---
 etnaviv/etnaviv_drm.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/etnaviv/etnaviv_drm.h b/etnaviv/etnaviv_drm.h
index 2584c1cc..76f6f78a 100644
--- a/etnaviv/etnaviv_drm.h
+++ b/etnaviv/etnaviv_drm.h
@@ -154,6 +154,12 @@ struct drm_etnaviv_gem_submit_bo {
  * one or more cmdstream buffers.  This allows for conditional execution
  * (context-restore), and IB buffers needed for per tile/bin draw cmds.
  */
+#define ETNA_SUBMIT_NO_IMPLICIT 0x0001
+#define ETNA_SUBMIT_FENCE_FD_IN 0x0002
+#define ETNA_SUBMIT_FENCE_FD_OUT0x0004
+#define ETNA_SUBMIT_FLAGS  (ETNA_SUBMIT_NO_IMPLICIT | \
+ETNA_SUBMIT_FENCE_FD_IN | \
+ETNA_SUBMIT_FENCE_FD_OUT)
 #define ETNA_PIPE_3D  0x00
 #define ETNA_PIPE_2D  0x01
 #define ETNA_PIPE_VG  0x02
@@ -167,6 +173,8 @@ struct drm_etnaviv_gem_submit {
__u64 bos;/* in, ptr to array of submit_bo's */
__u64 relocs; /* in, ptr to array of submit_reloc's */
__u64 stream; /* in, ptr to cmdstream */
+   __u32 flags;  /* in, mask of ETNA_SUBMIT_x */
+   __s32 fence_fd;   /* in/out, fence fd (see ETNA_SUBMIT_FENCE_FD_x) 
*/
 };
 
 /* The normal way to synchronize with the GPU is just to CPU_PREP on
-- 
2.11.0

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

[PATCH libdrm v2 2/2] etnaviv: add fence fd support

[Philipp Zabel]

Add etna_cmd_stream_flush2 with in-fence fd and out-fence fd support for
explicit fencing.

Signed-off-by: Philipp Zabel 
Reviewed-by: Eric Engestrom 
Reviewed-by: Christian Gmeiner 
---
v2: renamed etna_cmd_stream_flush_explicit to etna_cmd_stream_flush2
---
 etnaviv/etnaviv_cmd_stream.c | 33 +
 etnaviv/etnaviv_drmif.h  |  2 ++
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
index 9ce3f363..3c7b0ed6 100644
--- a/etnaviv/etnaviv_cmd_stream.c
+++ b/etnaviv/etnaviv_cmd_stream.c
@@ -177,7 +177,8 @@ static uint32_t bo2idx(struct etna_cmd_stream *stream, 
struct etna_bo *bo,
return idx;
 }
 
-static void flush(struct etna_cmd_stream *stream)
+static void flush(struct etna_cmd_stream *stream, int in_fence_fd,
+ int *out_fence_fd)
 {
struct etna_cmd_stream_priv *priv = etna_cmd_stream_priv(stream);
int ret, id = priv->pipe->id;
@@ -194,8 +195,22 @@ static void flush(struct etna_cmd_stream *stream)
.stream_size = stream->offset * 4, /* in bytes */
};
 
+   if (in_fence_fd != -1) {
+   req.flags |= ETNA_SUBMIT_FENCE_FD_IN | ETNA_SUBMIT_NO_IMPLICIT;
+   req.fence_fd = in_fence_fd;
+   }
+
+   if (out_fence_fd)
+   req.flags |= ETNA_SUBMIT_FENCE_FD_OUT;
+
+   /*
+* Pass the complete submit structure only if flags are set. Otherwise,
+* only pass the fields up to, but not including the flags field for
+* backwards compatiblity with older kernels.
+*/
ret = drmCommandWriteRead(gpu->dev->fd, DRM_ETNAVIV_GEM_SUBMIT,
-   , sizeof(req));
+   , req.flags ? sizeof(req) :
+   offsetof(struct drm_etnaviv_gem_submit, flags));
 
if (ret)
ERROR_MSG("submit failed: %d (%s)", ret, strerror(errno));
@@ -208,11 +223,21 @@ static void flush(struct etna_cmd_stream *stream)
bo->current_stream = NULL;
etna_bo_del(bo);
}
+
+   if (out_fence_fd)
+   *out_fence_fd = req.fence_fd;
 }
 
 void etna_cmd_stream_flush(struct etna_cmd_stream *stream)
 {
-   flush(stream);
+   flush(stream, -1, NULL);
+   reset_buffer(stream);
+}
+
+void etna_cmd_stream_flush2(struct etna_cmd_stream *stream, int in_fence_fd,
+   int *out_fence_fd)
+{
+   flush(stream, in_fence_fd, out_fence_fd);
reset_buffer(stream);
 }
 
@@ -220,7 +245,7 @@ void etna_cmd_stream_finish(struct etna_cmd_stream *stream)
 {
struct etna_cmd_stream_priv *priv = etna_cmd_stream_priv(stream);
 
-   flush(stream);
+   flush(stream, -1, NULL);
etna_pipe_wait(priv->pipe, priv->last_timestamp, 5000);
reset_buffer(stream);
 }
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 8119baad..87704acd 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -142,6 +142,8 @@ struct etna_cmd_stream *etna_cmd_stream_new(struct 
etna_pipe *pipe, uint32_t siz
 void etna_cmd_stream_del(struct etna_cmd_stream *stream);
 uint32_t etna_cmd_stream_timestamp(struct etna_cmd_stream *stream);
 void etna_cmd_stream_flush(struct etna_cmd_stream *stream);
+void etna_cmd_stream_flush2(struct etna_cmd_stream *stream, int in_fence_fd,
+   int *out_fence_fd);
 void etna_cmd_stream_finish(struct etna_cmd_stream *stream);
 
 static inline uint32_t etna_cmd_stream_avail(struct etna_cmd_stream *stream)
-- 
2.11.0

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

Re: [PATCH v5 04/12] drm: bridge: analogix: Destroy connector & encoder when unbinding

[Andrzej Hajda]

On 06.04.2017 14:31, Jeffy Chen wrote:
> Normally we do this in drm_mode_config_cleanup. But:
> 1/ analogix dp's connector is allocated in bind, and freed after unbind.
> So we need to destroy it in unbind to avoid further access.
> 2/ the drm bridge is attached in bind, and detached in encoder cleanup.
> So we need to destroy encoder in unbind.
>
> Signed-off-by: Jeffy Chen 

In general drm core should free drm resources, doing it in component can
hurt some day. Maybe it would be good to move some stuff from
bind/unbind to probe/remove if necessary, to allow connector and encoder
to live little bit longer, and be destroyed by drm core. This is just
suggestion, I am not familiar enough with the driver to make stronger
statements :)

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej


> ---
>
> Changes in v5: None
> Changes in v4:
> Address Andrzej Hajda 's comments.
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index d05ade4..4c758ed 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1439,6 +1439,8 @@ void analogix_dp_unbind(struct device *dev, struct 
> device *master,
>   struct analogix_dp_device *dp = dev_get_drvdata(dev);
>  
>   analogix_dp_bridge_disable(dp->bridge);
> + dp->connector.funcs->destroy(>connector);
> + dp->encoder->funcs->destroy(dp->encoder);
>  
>   if (dp->plat_data->panel) {
>   if (drm_panel_unprepare(dp->plat_data->panel))


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

Re: [PATCH] drm: Don't allow interruptions when opening debugfs/crc

[Tomeu Vizoso]

On 04/07/2017 01:17 PM, Chris Wilson wrote:
> The code does not like to be interrupted when waiting for the first
> vblank after opening a debugfs/crc channel, so don't.
> 
> [66285.716870] WARNING: CPU: 1 PID: 16615 at 
> drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm]
> [66285.716877] Modules linked in: i915 intel_powerclamp crct10dif_pclmul 
> crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd intel_gtt i2c_algo_bit 
> lpc_ich mfd_core drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops 
> prime_numbers drm video button autofs4 sd_mod ahci libahci libata i2c_i801 
> scsi_mod i2c_designware_platform i2c_designware_core i2c_core
> [66285.716929] CPU: 1 PID: 16615 Comm: kms_frontbuffer Not tainted 
> 4.11.0-rc5+ #7
> [66285.716935] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F8 
> 03/02/2016
> [66285.716941] Call Trace:
> [66285.716955]  dump_stack+0x4d/0x6f
> [66285.716966]  __warn+0xc1/0xe0
> [66285.716975]  warn_slowpath_null+0x18/0x20
> [66285.717004]  crtc_crc_open+0x1d0/0x1f0 [drm]
> [66285.717014]  ? wake_atomic_t_function+0x50/0x50
> [66285.717024]  full_proxy_open+0xf0/0x1b0
> [66285.717032]  ? full_proxy_release+0x80/0x80
> [66285.717042]  do_dentry_open.isra.17+0x14b/0x2d0
> [66285.717051]  vfs_open+0x42/0x60
> [66285.717064]  path_openat+0x5e7/0x13d0
> [66285.717074]  ? refcount_dec_and_test+0x11/0x20
> [66285.717081]  ? down_read+0xd/0x30
> [66285.717087]  do_filp_open+0x85/0xf0
> [66285.717093]  ? __vfs_write+0x23/0x120
> [66285.717100]  ? __alloc_fd+0x3a/0x170
> [66285.717107]  do_sys_open+0x11e/0x1f0
> [66285.717113]  ? do_sys_open+0x11e/0x1f0
> [66285.717119]  SyS_openat+0xf/0x20
> [66285.717125]  entry_SYSCALL_64_fastpath+0x17/0x98
> [66285.717131] RIP: 0033:0x7f5f2235146a
> [66285.717135] RSP: 002b:7ffd892e6bc0 EFLAGS: 0246 ORIG_RAX: 
> 0101
> [66285.717142] RAX: ffda RBX:  RCX: 
> 7f5f2235146a
> [66285.717147] RDX:  RSI: 7ffd892e6c40 RDI: 
> 0006
> [66285.717151] RBP: 7ffd892e6b20 R08:  R09: 
> 000f
> [66285.717156] R10:  R11: 0246 R12: 
> 0001
> [66285.717161] R13: 7ffd892e6b10 R14: 0004 R15: 
> 007e61f4
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610
> Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from 
> open()")
> Signed-off-by: Chris Wilson 
> Cc: Tomeu Vizoso 
> Cc: Daniel Vetter 

Reviewed-by: Tomeu Vizoso 

Sounds good to me, there isn't any good reason for the wait to be
interruptible.

Thanks,

Tomeu

> ---
>  drivers/gpu/drm/drm_debugfs_crc.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 1722d8f21449..aa13e734c9e5 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -177,13 +177,9 @@ static int crtc_crc_open(struct inode *inode, struct 
> file *filep)
>* guess when this particular piece of HW will be ready to start
>* generating CRCs.
>*/
> - ret = wait_event_interruptible_lock_irq(crc->wq,
> - crtc_crc_data_count(crc),
> - crc->lock);
> + wait_event_lock_irq(crc->wq, crtc_crc_data_count(crc), crc->lock);
>   spin_unlock_irq(>lock);
>  
> - WARN_ON(ret);
> -
>   return 0;
>  
>  err_disable:
> 

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