Re: [PATCH] exynos: add C++ support to exynos_drmif header

[Tobias Jakobi]

Emil Velikov wrote:
> FTR, only the installed headers (~50) need the extern C guard.
> None of that is not a blocker for this patch, so I've just pushed it to 
> master.
Thanks Emil. I'll see what I can do about the other ones.

- Tobias


> Thanks!
> Emil
> 

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

[Bug 100593] corruption in total war warhammer when using mesa 17.1 - git

[bugzilla-daemon]

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

--- Comment #4 from Gašper Sedej  ---
Hi. I also found some "shader color corruptions" on r9 270. 
I am using ubuntu 16.04 + kernel 4.11 + oibaf-ppa

Having issues with unigine (valley/heaven), The long dark and compiz window
shadow.

Screenshots
http://imgur.com/a/LaHdh

-- 
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: [Intel-gfx] [PATCH 06/11] drm: create hdmi output property

[kbuild test robot]

Hi Shashank,

[auto build test WARNING on next-20170407]
[cannot apply to drm/drm-next drm-intel/for-linux-next tegra/for-next v4.9-rc8 
v4.9-rc7 v4.9-rc6 v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'fops'
   include/drm/drm_connector.h:142: warning: No description found for parameter 
'ycbcr420_dc_modes'
   include/drm/drm_connector.h:142: warning: No description found for parameter 
'ycbcr420_vcb_map'
>> include/drm/drm_connector.h:346: warning: No description found for parameter 
>> 'hdmi_output'
   include/drm/drm_color_mgmt.h:1: warning: no structured comments found
   drivers/gpu/drm/drm_plane_helper.c:403: warning: No description found for 
parameter 'ctx'
   drivers/gpu/drm/drm_plane_helper.c:404: warning: No description found for 
parameter 'ctx'
   drivers/gpu/drm/i915/intel_lpe_au

Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G

[Fabio Estevam]

Thierry/Rob,

On Tue, Feb 7, 2017 at 10:48 PM, Fabio Estevam  wrote:
> On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring  wrote:
>
>> Except I have no way of knowing whether: a) you omitted a supply
>> because you don't (yet) care, b) the panel has a single supply and you
>> are using power-supply or c) the panel has multiple supplies and your
>> binding is wrong.
>>
>> I can only eliminate A if you list the supplies. Just need something
>> like "power-supply : see simple-panel.txt". I've still got to go read
>> the panel spec if I really want to check the binding.
>
> Just checked the panel datasheet at
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf and it lists two
> supplies:
> DVDD (Digital power supply) and AVDD (Analog power supply).
>
> Our dts was just providing a single 'power-supply' which referred to a
> GPIO enabled regulator that drives DVDD.
>
> So it seems we missed to pass AVDD (not software controlled in our
> case, but we need to describe it in dts anyway).
>
> Does this mean we cannot use simple-panel for this particular panel
> and we should add a separate driver for it?

Please confirm if we need to create a separate driver for this panel, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] exynos: add C++ support to exynos_drmif header

[Emil Velikov]

On 5 April 2017 at 17:23, Tobias Jakobi  wrote:
> Hello Eric,
>
>
> Eric Engestrom wrote:
>> On Wednesday, 2017-04-05 16:22:24 +0200, Tobias Jakobi wrote:
>>> Add the usual extern "C" when compiling in C++ mode.
>>
>> Thanks, but why specifically this header? The other exynos/*.h headers
>> also lack the c++ mangling guard.
> I'm currently writing a small C++ project using the
> exynos_bo_{create,destroy}() calls, and noticed this.
>
>> A quick grep shows that only 15/101 headers in libdrm have it.
>> Can I interest you in fixing a few more headers? :)
> Not at the moment.
>
FTR, only the installed headers (~50) need the extern C guard.
None of that is not a blocker for this patch, so I've just pushed it to master.

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

[ANNOUNCE] libdrm 2.4.79

[Marek Olšák]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Marek Olšák (1):
  configure.ac: bump version for release

Samuel Pitoiset (1):
  amdgpu: allow to query GPU sensor related information

git tag: libdrm-2.4.79

https://dri.freedesktop.org/libdrm/libdrm-2.4.79.tar.bz2
MD5:  84ba6e8e6c97d2684938eb949e6dfdf8  libdrm-2.4.79.tar.bz2
SHA1: 0dd194538c90619146a83a65f2074564e1a14d55  libdrm-2.4.79.tar.bz2
SHA256: c6aaf319293bce38023e9a637471b0f45c93c807d2a279060d741fc7a2e5b197  
libdrm-2.4.79.tar.bz2
SHA512: 
62d6dbdf5e4e73e948fcb128a3ee76c88843d0aabf0af5751526829e9b95cff151a121af88ba9625acc7f5bc4ecfa71f9a3762005d5da76cff1d91dfc8ea8ea7
  libdrm-2.4.79.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.79.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.79.tar.gz
MD5:  d1acf4cf8e5292c92810a411d2e30e22  libdrm-2.4.79.tar.gz
SHA1: 499145711583fce61ed8b2da5c5caa459c95a775  libdrm-2.4.79.tar.gz
SHA256: 7f2594fb5d636e083f7765bfea62a43fcd7c5a12b8aa4f0552fb8fd12aa388a7  
libdrm-2.4.79.tar.gz
SHA512: 
1ce0d29dc2071c5f3b02a80cc005ef2cfaa4fb90efff4d5e6688dcce728653c5c6726ff6b954c77537a87a98119cdce62d084b34e56b2cdb5e8cf1dfb772218c
  libdrm-2.4.79.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.79.tar.gz.sig

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJY6UJ2AAoJEP3RXVrO8PKx7scIAKqNPcmUcI3/ukhefz2V2vTx
21FRaqgIlq4DrPmSxnSqm3klYPhbgA9T7bfuItXasjTwyZHaRWQnr4A8Lnv8b2nb
K8XZ7P7XKEKldah03S6DIRxy2XXzREFfuo9V3cCXYjMTqGl7j0Evf48jjrvnhr3G
voJiCkHyLshyONuoeTxV7k4xz6qYCKCZOO15oF0ot0Q8aX+jDxkLewaOlMFNam1m
jmmyzfyp4DwxitrfaIpXuScToEZragYjArakrqoxhNR2MS1PqYxtB/GaxI9IWCLT
lgWJRloRFlcT/B6C5F+0djiNBoq4fqLctLqdb4nBHvKiWsiYtmvkdt97b5029Z8=
=rvyS
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Emil Velikov]

On 7 April 2017 at 13:06, Philipp Zabel  wrote:
> 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.
IIRC all the other drivers should already install the header, so we
want to fix this, right?
If we're too late for this kernel cycle, we will land the patch as-is.

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

[Bug 92432] GPU HANG: ecode 6:0:0x00675c57, in Xorg [1341], reason: Ring hung, action: reset

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
Product|DRI |Mesa
 QA Contact|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 Resolution|--- |WORKSFORME
  Component|DRM/Intel   |Drivers/DRI/i915
 Status|NEEDINFO|RESOLVED

--- Comment #3 from Chris Wilson  ---
Batch buffer corruption (looks like the invalid memset), likely fixed by an
update to mesa.

-- 
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 libdrm v2 2/2] etnaviv: add fence fd support

[Emil Velikov]

On 7 April 2017 at 13:06, Philipp Zabel  wrote:
> 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

Please add the new symbol to etnaviv/etnaviv-symbol-check.

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

Re: [Intel-gfx] [PATCH 05/11] drm: parse ycbcr 420 deep color information

[kbuild test robot]

Hi Shashank,

[auto build test WARNING on next-20170407]
[cannot apply to drm/drm-next drm-intel/for-linux-next tegra/for-next v4.9-rc8 
v4.9-rc7 v4.9-rc6 v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'fops'
>> include/drm/drm_connector.h:142: warning: No description found for parameter 
>> 'ycbcr420_dc_modes'
   include/drm/drm_connector.h:142: warning: No description found for parameter 
'ycbcr420_vcb_map'
   include/drm/drm_color_mgmt.h:1: warning: no structured comments found
   drivers/gpu/drm/drm_plane_helper.c:403: warning: No description found for 
parameter 'ctx'
   drivers/gpu/drm/drm_plane_helper.c:404: warning: No description found for 
parameter 'ctx'
   drivers/gpu/drm/i915/intel_lpe_audio.c:343: warning: No description found 
for parameter 'dp_output'
   drivers/gpu/drm/i915/int

Re: [PATCHv3 17/22] staging: android: ion: Collapse internal header files

[Emil Velikov]

Hi Laura,

Couple of trivial nitpicks below.

On 3 April 2017 at 19:57, Laura Abbott  wrote:

> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -1,5 +1,5 @@
>  /*
> - * drivers/staging/android/ion/ion.h
> + * drivers/staging/android/ion/ion_priv.h
Does not match the actual filename.

>   *
>   * Copyright (C) 2011 Google, Inc.
>   *
> @@ -14,24 +14,26 @@
>   *
>   */
>
> -#ifndef _LINUX_ION_H
> -#define _LINUX_ION_H
> +#ifndef _ION_PRIV_H
> +#define _ION_PRIV_H
>
Ditto.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
>
>  #include "../uapi/ion.h"
>
You don't want to use "../" in includes. Perhaps address with another
patch, if you haven't already ?

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

Re: [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

[Chris Wilson]

On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote:
> Am 08.04.2017 um 18:26 schrieb Chris Wilson:
> >Reserve 0 for general use a token meaning that the fence doesn't belong
> >to an ordered timeline (fence context).
> 
> NAK, we kept context allocation cheap to avoid exactly that.

However, they result in very sparse mappings.

> Please elaborate further why it should be necessary now.

Because I want to efficiently exclude them from comparisons as
demonstrated by this small series as there may be several hundred such
fences as dependencies for this job.
-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 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

[Christian König]

Am 08.04.2017 um 18:26 schrieb Chris Wilson:

Reserve 0 for general use a token meaning that the fence doesn't belong
to an ordered timeline (fence context).


NAK, we kept context allocation cheap to avoid exactly that.

Please elaborate further why it should be necessary now.

Regards,
Christian.


Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Joonas Lahtinen 
Cc: "Christian König" 
Cc: Alex Deucher 
---
  drivers/dma-buf/dma-fence.c | 4 +++-
  include/linux/dma-fence.h   | 2 ++
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0918d3f003d6..0646357ea350 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -36,8 +36,10 @@ EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
   * fence context, this allows checking if fences belong to the same
   * context or not. One device can have multiple separate contexts,
   * and they're used if some engine can run independently of another.
+ *
+ * 0 is excluded and treated as a special DMA_FENCE_NO_CONTEXT.
   */
-static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
+static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
  
  /**

   * dma_fence_context_alloc - allocate an array of fence contexts
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 6048fa404e57..adfdc7fdd9c3 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -455,6 +455,8 @@ static inline signed long dma_fence_wait(struct dma_fence 
*fence, bool intr)
return ret < 0 ? ret : 0;
  }
  
+#define DMA_FENCE_NO_CONTEXT ((u64)0)

+
  u64 dma_fence_context_alloc(unsigned num);
  
  #define DMA_FENCE_TRACE(f, fmt, args...) \



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

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

[Emil Velikov]

Hi Shashank,

On 7 April 2017 at 17:39, Shashank Sharma  wrote:

> +   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))
Since map is u64 you really want to use something like (1ull << i)
here. Otherwise you'll get a 32 bit value, regardless of i.


> +   for (count = 0; count < map_len; count++)
> +   map = (db[2 + count] << 8 * count) | map;
> +
The above issue is applicable here as well. With a small nitpick the
whole thing will read

map |= (u64)db[2 + count] << (8 * count);


> --- 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;
> +   u64 ycbcr420_vcb_map;
As pointed by the kbuild robot - you really want to document the field.

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

[Bug 195295] USB device insertion turns on discrete Radeon GPU

[bugzilla-daemon]

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

Eugene Shalygin (eugene.shaly...@gmail.com) changed:

   What|Removed |Added

 Regression|No  |Yes

-- 
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 195295] New: USB device insertion turns on discrete Radeon GPU

[bugzilla-daemon]

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

Bug ID: 195295
   Summary: USB device insertion turns on discrete Radeon GPU
   Product: Drivers
   Version: 2.5
Kernel Version: 4.10.8
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: eugene.shaly...@gmail.com
Regression: No

When I plug in any USB device dGPU turns on an never turns off until reboot.

# lspci 
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor
Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High
Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #1 (rev d5)
00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #2 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #4 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family
6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus
Controller (rev 05)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Neptune XT [Radeon HD 8970M] (rev ff)
03:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI
Bridge [Cheetah Express] (rev 01)
04:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b
OHCI Controller [Cheetah Express] (rev 01)
05:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411 PCI
Express Card Reader (rev 01)
05:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
PCI Express Gigabit Ethernet Controller (rev 0a)
06:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)

-- 
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 boot: 112 boots: 4 failed, 107 passed with 1 offline (v4.11-rc5-1802-g102e51aa6d5b)

[kernelci . org bot]

drm-tip/drm-tip boot: 112 boots: 4 failed, 107 passed with 1 offline 
(v4.11-rc5-1802-g102e51aa6d5b)

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

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1802-g102e51aa6d5b
Git Commit: 102e51aa6d5b1d5defdf8adde6ee39b40fd6d519
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 16 unique boards, 9 SoC families, 24 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-1802-g2d286312feeb)

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

tinyconfig
minnowboard-max: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-snow: 1 failed lab

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

[Bug 71789] [r300g] Visuals not found in (default) depth = 24

[bugzilla-daemon]

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

--- Comment #37 from Marek Olšák  ---
You can try "git am -3 ...". If that doesn't help, then I don't know.

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

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

[Daniel Vetter]

On Sat, Apr 8, 2017 at 7:41 AM, Ong, Hean Loong
 wrote:
> Hi Daniel
>
> Thanks for the time and patience for reviewing my changes. I would ensure 
> that subsequent patches will not have the same mail problems.
>
> I have some question on the validation methods. Since my drivers are 
> processing the images with an FPGA would running the tests with 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation 
> be relevant?

igt testcases automatically skip when they don't apply for a given
platform/driver. They might need some bugfixes if your driver is a
completely new case, but it should work.

> The display images are streamed to the monitor via a Display Port connector 
> thus I don' t think it is virtual. The FPGA is programmed to run with a 
> proprietary Display Port IP. The driver just feeds it with display data.

Well, it looked like a virtual driver (since the real DP handling is
somewhere else like you explain). And since it works like a virtual
driver we could extract a helper library to reduce duplicated code.
Virtual driver here means "just feeds display data to something else
that handles the real output handling duties". That applies to
virtualized gpus, but also to your case here.

Btw a small ascii-art block diagram for your driver hw architecture to
explain stuff like this would be awesome (but it either into a code
comment or into the commit message).

> I would take your advice in implementing it in the small drivers, but since 
> its new are there any special cases that I would have to look out for in 
> implementing this driver in the drm-misc ?

Small drivers is only about how to maintain it once it's merged, not
about the code itself. We assume/hope that people who submit drivers
stay around for helping maintaining it going forward (but if that
doesn't happen, also no big deal).
-Daniel

>
>>-Original Message-
>>From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
>>Daniel
>>Vetter
>>Sent: Saturday, April 8, 2017 12:32 AM
>>To: Ong, Hean Loong 
>>Cc: Vetter, Daniel ; airl...@linux.ie; dri-
>>de...@lists.freedesktop.org
>>Subject: Re: DRM Display driver for Intel FPGA Video and Image Processing 
>>Suite
>>
>>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)+= 

[PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

[Chris Wilson]

Reserve 0 for general use a token meaning that the fence doesn't belong
to an ordered timeline (fence context).

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Joonas Lahtinen 
Cc: "Christian König" 
Cc: Alex Deucher 
---
 drivers/dma-buf/dma-fence.c | 4 +++-
 include/linux/dma-fence.h   | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0918d3f003d6..0646357ea350 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -36,8 +36,10 @@ EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
  * fence context, this allows checking if fences belong to the same
  * context or not. One device can have multiple separate contexts,
  * and they're used if some engine can run independently of another.
+ *
+ * 0 is excluded and treated as a special DMA_FENCE_NO_CONTEXT.
  */
-static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
+static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
 
 /**
  * dma_fence_context_alloc - allocate an array of fence contexts
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 6048fa404e57..adfdc7fdd9c3 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -455,6 +455,8 @@ static inline signed long dma_fence_wait(struct dma_fence 
*fence, bool intr)
return ret < 0 ? ret : 0;
 }
 
+#define DMA_FENCE_NO_CONTEXT ((u64)0)
+
 u64 dma_fence_context_alloc(unsigned num);
 
 #define DMA_FENCE_TRACE(f, fmt, args...) \
-- 
2.11.0

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

[PATCH 3/3] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 33 +
 drivers/gpu/drm/i915/i915_gem_request.h |  2 ++
 lib/radix-tree.c|  1 +
 3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 313cdff7c6dd..c184f1d26f25 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -606,6 +606,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 
i915_priotree_init(>priotree);
 
+   INIT_RADIX_TREE(>waits, GFP_KERNEL);
INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
req->engine = engine;
@@ -723,6 +724,27 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
return 0;
 
+   /* Squash repeated waits to the same timelines, picking the latest */
+   if (fence->context != DMA_FENCE_NO_CONTEXT) {
+   void __rcu **slot;
+
+   slot = radix_tree_lookup_slot(>waits, fence->context);
+   if (!slot) {
+   ret = radix_tree_insert(>waits,
+   fence->context, fence);
+   if (ret)
+   return ret;
+   } else {
+   struct dma_fence *old =
+   rcu_dereference_protected(*slot, true);
+
+   if (!dma_fence_is_later(fence, old))
+   return 0;
+
+   radix_tree_replace_slot(>waits, slot, fence);
+   }
+   }
+
if (dma_fence_is_i915(fence))
return i915_gem_request_await_request(req, to_request(fence));
 
@@ -843,6 +865,15 @@ static void i915_gem_mark_busy(const struct 
intel_engine_cs *engine)
   round_jiffies_up_relative(HZ));
 }
 
+static void free_radixtree(struct radix_tree_root *root)
+{
+   struct radix_tree_iter iter;
+   void __rcu **slot;
+
+   radix_tree_for_each_slot(slot, root, , 0)
+   radix_tree_iter_delete(root, , slot);
+}
+
 /*
  * NB: This function is not allowed to fail. Doing so would mean the the
  * request is not being tracked for completion but the work itself is
@@ -943,6 +974,8 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
+
+   free_radixtree(>waits);
 }
 
 static unsigned long local_clock_us(unsigned int *cpu)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index a211c53c813f..638899b9c170 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -137,6 +137,8 @@ struct drm_i915_gem_request {
struct i915_priotree priotree;
struct i915_dependency dep;
 
+   struct radix_tree_root waits;
+
/** GEM sequence number associated with this request on the
 * global execution timeline. It is zero when the request is not
 * on the HW queue (i.e. not on the engine timeline list).
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 691a9ad48497..84cccf7138c4 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -2022,6 +2022,7 @@ void radix_tree_iter_delete(struct radix_tree_root *root,
if (__radix_tree_delete(root, iter->node, slot))
iter->index = iter->next_index;
 }
+EXPORT_SYMBOL(radix_tree_iter_delete);
 
 /**
  * radix_tree_delete_item - delete an item from a radix tree
-- 
2.11.0

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

[PATCH 2/3] drm/i915: Mark up clflushes as belonging to an unordered timeline (NO_CONTEXT)

[Chris Wilson]

2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special context (0 / DMA_FENCE_NO_CONTEXT) to
mean unordered.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 --
 drivers/gpu/drm/i915/i915_gem_clflush.c | 8 +---
 drivers/gpu/drm/i915/i915_gem_clflush.h | 1 -
 3 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b210acc3d0b4..6dacc5c21889 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4681,8 +4681,6 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 
mutex_lock(_priv->drm.struct_mutex);
 
-   i915_gem_clflush_init(dev_priv);
-
if (!i915.enable_execlists) {
dev_priv->gt.resume = intel_legacy_submission_resume;
dev_priv->gt.cleanup_engine = intel_engine_cleanup;
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index ffd01e02fe94..57ee389c665f 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -27,7 +27,6 @@
 #include "i915_gem_clflush.h"
 
 static DEFINE_SPINLOCK(clflush_lock);
-static u64 clflush_context;
 
 struct clflush {
struct dma_fence dma; /* Must be first for dma_fence_free() */
@@ -157,7 +156,7 @@ void i915_gem_clflush_object(struct drm_i915_gem_object 
*obj,
dma_fence_init(>dma,
   _clflush_ops,
   _lock,
-  clflush_context,
+  DMA_FENCE_NO_CONTEXT,
   0);
i915_sw_fence_init(>wait, i915_clflush_notify);
 
@@ -182,8 +181,3 @@ void i915_gem_clflush_object(struct drm_i915_gem_object 
*obj,
GEM_BUG_ON(obj->base.write_domain != I915_GEM_DOMAIN_CPU);
}
 }
-
-void i915_gem_clflush_init(struct drm_i915_private *i915)
-{
-   clflush_context = dma_fence_context_alloc(1);
-}
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.h 
b/drivers/gpu/drm/i915/i915_gem_clflush.h
index b62d61a2d15f..2455a7820937 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.h
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.h
@@ -28,7 +28,6 @@
 struct drm_i915_private;
 struct drm_i915_gem_object;
 
-void i915_gem_clflush_init(struct drm_i915_private *i915);
 void i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 unsigned int flags);
 #define I915_CLFLUSH_FORCE BIT(0)
-- 
2.11.0

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

Re: [PATCH v2 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()

[Inki Dae]

2017-03-29 20:55 GMT+09:00 Tobias Jakobi :
> Hello Daniel,
>
> I'm not getting any response from the Exynos DRM maintainer concerning
> this patch. Since this is just a simple cleanup, and Andrzej has already
> review, could you perhaps merge it through drm-misc?
>

Sorry for late. Confirmed just now. This patch is a trivial thing so
will be merged soon.

Thanks,
Inki Dae

> With best wishes,
> Tobias
>
>
>
> Tobias Jakobi wrote:
>> Convert if-statements to switch statement. Removes
>> duplicated code.
>>
>> Reviewed-by: Andrzej Hajda 
>> Signed-off-by: Tobias Jakobi 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 30 --
>>  1 file changed, 8 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 72143ac..41d0c36 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -382,29 +382,14 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>> *ctx, unsigned int height)
>>   struct mixer_resources *res = >mixer_res;
>>   u32 val;
>>
>> - if (height == 480) {
>> + switch (height) {
>> + case 480:
>> + case 576:
>>   val = MXR_CFG_RGB601_0_255;
>> - } else if (height == 576) {
>> - val = MXR_CFG_RGB601_0_255;
>> - } else if (height == 720) {
>> - val = MXR_CFG_RGB709_16_235;
>> - mixer_reg_write(res, MXR_CM_COEFF_Y,
>> - (1 << 30) | (94 << 20) | (314 << 10) |
>> - (32 << 0));
>> - mixer_reg_write(res, MXR_CM_COEFF_CB,
>> - (972 << 20) | (851 << 10) | (225 << 0));
>> - mixer_reg_write(res, MXR_CM_COEFF_CR,
>> - (225 << 20) | (820 << 10) | (1004 << 0));
>> - } else if (height == 1080) {
>> - val = MXR_CFG_RGB709_16_235;
>> - mixer_reg_write(res, MXR_CM_COEFF_Y,
>> - (1 << 30) | (94 << 20) | (314 << 10) |
>> - (32 << 0));
>> - mixer_reg_write(res, MXR_CM_COEFF_CB,
>> - (972 << 20) | (851 << 10) | (225 << 0));
>> - mixer_reg_write(res, MXR_CM_COEFF_CR,
>> - (225 << 20) | (820 << 10) | (1004 << 0));
>> - } else {
>> + break;
>> + case 720:
>> + case 1080:
>> + default:
>>   val = MXR_CFG_RGB709_16_235;
>>   mixer_reg_write(res, MXR_CM_COEFF_Y,
>>   (1 << 30) | (94 << 20) | (314 << 10) |
>> @@ -413,6 +398,7 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx, 
>> unsigned int height)
>>   (972 << 20) | (851 << 10) | (225 << 0));
>>   mixer_reg_write(res, MXR_CM_COEFF_CR,
>>   (225 << 20) | (820 << 10) | (1004 << 0));
>> + break;
>>   }
>>
>>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>
>
> ___
> 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] drm/exynos: mixer: document YCbCr magic numbers

[Inki Dae]

2017-03-29 20:56 GMT+09:00 Tobias Jakobi :
> Hello Daniel,
>
> same question here. Patch doesn't introduce any functional changes (just
> adds code documentation), so can you merge it through drm-misc?
>

Sorry for late. Confirmed just now. I will check it on next Monday.

Thanks,
Inki Dae

> With best wishes,
> Tobias
>
>
> Tobias Jakobi wrote:
>> The output stage of the mixer uses YCbCr for the internal
>> computations, which is the reason that some registers take
>> YCbCr related data as input. In particular this applies
>> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>>
>> Document the formatting of the data which we write to
>> these registers.
>>
>> While at it, unify wording of comments in the register header.
>>
>> Reviewed-by: Andrzej Hajda 
>> Signed-off-by: Tobias Jakobi 
>> ---
>> Changes in v2:
>> - use floating point values as input for the macros, as
>>   suggested by Andrzej
>> - the floating point values have been tuned to exactly match
>>   the values that are currently used
>>
>> Changes in v3:
>> - use only three digit values (pointed out by Andrzej)
>>
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 +
>>  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
>>  2 files changed, 30 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 41d0c36..9648dd5 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -45,6 +45,22 @@
>>  #define MIXER_WIN_NR 3
>>  #define VP_DEFAULT_WIN   2
>>
>> +/*
>> + * Mixer color space conversion coefficient triplet.
>> + * Used for CSC from RGB to YCbCr.
>> + * Each coefficient is a 10-bit fixed point number with
>> + * sign and no integer part, i.e.
>> + * [0:8] = fractional part (representing a value y = x / 2^9)
>> + * [9] = sign
>> + * Negative values are encoded with two's complement.
>> + */
>> +#define MXR_CSC_C(x) ((int)((x) * 512.0) & 0x3ff)
>> +#define MXR_CSC_CT(a0, a1, a2) \
>> +  ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1) << 10) | (MXR_CSC_C(a2) << 0))
>> +
>> +/* YCbCr value, used for mixer background color configuration. */
>> +#define MXR_YCBCR_VAL(y, cb, cr) (((y) << 16) | ((cb) << 8) | ((cr) << 0))
>> +
>>  /* The pixelformats that are natively supported by the mixer. */
>>  #define MXR_FORMAT_RGB5654
>>  #define MXR_FORMAT_ARGB1555  5
>> @@ -391,13 +407,14 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>> *ctx, unsigned int height)
>>   case 1080:
>>   default:
>>   val = MXR_CFG_RGB709_16_235;
>> + /* Configure the BT.709 CSC matrix for full range RGB. */
>>   mixer_reg_write(res, MXR_CM_COEFF_Y,
>> - (1 << 30) | (94 << 20) | (314 << 10) |
>> - (32 << 0));
>> + MXR_CSC_CT( 0.184,  0.614,  0.063) |
>> + MXR_CM_COEFF_RGB_FULL);
>>   mixer_reg_write(res, MXR_CM_COEFF_CB,
>> - (972 << 20) | (851 << 10) | (225 << 0));
>> + MXR_CSC_CT(-0.102, -0.338,  0.440));
>>   mixer_reg_write(res, MXR_CM_COEFF_CR,
>> - (225 << 20) | (820 << 10) | (1004 << 0));
>> + MXR_CSC_CT( 0.440, -0.399, -0.040));
>>   break;
>>   }
>>
>> @@ -715,10 +732,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
>>   /* reset default layer priority */
>>   mixer_reg_write(res, MXR_LAYER_CFG, 0);
>>
>> - /* setting background color */
>> - mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
>> - mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
>> - mixer_reg_write(res, MXR_BG_COLOR2, 0x008080);
>> + /* set all background colors to RGB (0,0,0) */
>> + mixer_reg_write(res, MXR_BG_COLOR0, MXR_YCBCR_VAL(0, 128, 128));
>> + mixer_reg_write(res, MXR_BG_COLOR1, MXR_YCBCR_VAL(0, 128, 128));
>> + mixer_reg_write(res, MXR_BG_COLOR2, MXR_YCBCR_VAL(0, 128, 128));
>>
>>   if (test_bit(MXR_BIT_VP_ENABLED, >flags)) {
>>   /* configuration of Video Processor Registers */
>> diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
>> b/drivers/gpu/drm/exynos/regs-mixer.h
>> index 7f22df5..c311f57 100644
>> --- a/drivers/gpu/drm/exynos/regs-mixer.h
>> +++ b/drivers/gpu/drm/exynos/regs-mixer.h
>> @@ -140,11 +140,11 @@
>>  #define MXR_INT_EN_VSYNC (1 << 11)
>>  #define MXR_INT_EN_ALL   (0x0f << 8)
>>
>> -/* bit for MXR_INT_STATUS */
>> +/* bits for MXR_INT_STATUS */
>>  #define MXR_INT_CLEAR_VSYNC  (1 << 11)
>>  #define MXR_INT_STATUS_VSYNC (1 << 0)
>>
>> -/* bit for MXR_LAYER_CFG */
>> +/* bits for MXR_LAYER_CFG */
>>  #define MXR_LAYER_CFG_GRP1_VAL(x)MXR_MASK_VAL(x, 11, 8)
>>  #define MXR_LAYER_CFG_GRP1_MASK  

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Inki Dae]

2017-04-07 20:40 GMT+09:00 Tobias Jakobi :
> Hello Inki,
>
>
> Inki Dae wrote:
>> Hello Tobias,
>>
>>
>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>>> Hello Inki,
>>>
>>>
>>> Inki Dae wrote:
 This patch removes unnecessary descriptions on
 exynos_drm_crtc structure and adds one description
 which specifies what pipe_clk member does.

 pipe_clk support had been added by below patch without any description,
  drm/exynos: add support for pipeline clock to the framework
>>> I would put the commit id here. That makes it easier to look up the
>>> commit your refer to.
>>>
>>>
 Signed-off-by: Inki Dae 
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index 527bf1d..b0462cc 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -152,12 +152,10 @@ struct exynos_drm_clk {
   *
   * @base: crtc object.
   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
 - * @enabled: if the crtc is enabled or not
 - * @event: vblank event that is currently queued for flip
 - * @wait_update: wait all pending planes updates to finish
 - * @pending_update: number of pending plane updates in this crtc
   * @ops: pointer to callbacks for exynos drm specific functionality
   * @ctx: A pointer to the crtc's implementation specific context
 + * @pipe_clk: A pipe clock structure which includes a callback function
 + for enabling DP clock of FIMD and HDMI PHY clock.
>>> This is wrong/inconsistent with the rest of the documentation. pipe_clk
>>> is not a struct, but a pointer.
>>>
>>> I would suggest to follow. Just document that we have a pointer to >> escription> here (compare docu for 'ops' and 'ctx').
>>> And then put the later bits ("...callback function for enabling DP
>>> clock...") directly to the definition of 'struct exynos_drm_clk' (which
>>> is currently lacking any kind of docu).
>>
>> Thanks for pointing it out. My mistake. :)
>>
>> How about this simply?
>> "A pointer to exynos_drm_clk structure for enabling and disabling DP clock 
>> of FIMD and HDMI PHY clocks"
> Not what I meant. You're describing 'struct exynos_drm_clk', and that
> does not belong here. If you describe 'struct exynos_drm_clk', then this
> should go in front of the struct's definition.
>
> How abouting something like this in front of the struct's definition::
>> /*
>>  * Exynos DRM pipeline clock structure.
>>  *
>>  * @enable: callback to enable/disable the clock.
>>  *
>>  * Used for proper clock synchronization of components belonging
>>  * to the same pipeline. Used e.g. for enabling the DP clock of
>>  * the FIMD or the HDMI PHY clock.
>>  */
>> struct exynos_drm_clk {
>> 
>
> For 'pipe_clk' I would just go with this:
>> @pipe_clk: A pointet to the crtc's pipeline clock.

More simple and looks better.

Thanks,
Inki Dae

>
> I hope this helps.
>
> - Tobias
>
>
>> Thanks,
>> Inki Dae
>>
>>>
>>>
>>> - Tobias
>>>
   */
  struct exynos_drm_crtc {
 struct drm_crtc base;

>>>
>>>
>>>
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[kbuild test robot]

Hi Shashank,

[auto build test WARNING on next-20170407]
[cannot apply to drm/drm-next drm-intel/for-linux-next tegra/for-next v4.9-rc8 
v4.9-rc7 v4.9-rc6 v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'fops'
>> include/drm/drm_connector.h:141: warning: No description found for parameter 
>> 'ycbcr420_vcb_map'
   include/drm/drm_color_mgmt.h:1: warning: no structured comments found
   drivers/gpu/drm/drm_plane_helper.c:403: warning: No description found for 
parameter 'ctx'
   drivers/gpu/drm/drm_plane_helper.c:404: warning: No description found for 
parameter 'ctx'
   drivers/gpu/drm/i915/intel_lpe_audio.c:343: warning: No description found 
for parameter 'dp_output'
   drivers/gpu/drm/i915/intel_lpe_audio.c:343: warning: No description found 
for parameter 'link_rate'
   drivers/gpu/drm/i915

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

[kernelci . org bot]

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

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

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1802-g102e51aa6d5b
Git Commit: 102e51aa6d5b1d5defdf8adde6ee39b40fd6d519
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 71789] [r300g] Visuals not found in (default) depth = 24

[bugzilla-daemon]

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

--- Comment #36 from richard  ---
wheezy only have mesa 8 available, but videoplayback would be very nice please.
don't know how to change colour depth as there is no xorg.conf.
thank you very much

-- 
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 71789] [r300g] Visuals not found in (default) depth = 24

[bugzilla-daemon]

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

--- Comment #35 from richard  ---
Hello ,

how can i apply this patch?
I am using Powermac G5 7,3 with Radeon9650, Debian Wheezy, kernel 3.2.6
it gives

 dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode'
[1.137001] radeonfb: Found Open Firmware ROM Image
[1.137015] radeonfb: Retrieved PLL infos from Open Firmware
[   25.042791] [drm] Loading R300 Microcode
[   25.111223] platform radeon_cp.0: firmware: agent loaded radeon/R300_cp.bin
into memory


after installing firmware-linux-nonfree.
Video playback is blue (no video shown) when using mplayer, mpv, vlc .. but
html5 playback on youtube works normal (bit slow, though).

-- 
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 PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

[Hans Verkuil]

On 04/08/2017 12:11 PM, Hans Verkuil wrote:
> Hi Tomi,
> 
> On 05/10/2016 01:36 PM, Tomi Valkeinen wrote:
>> Hi Hans,
>>
>> On 29/04/16 12:39, Hans Verkuil wrote:
>>> From: Hans Verkuil 
>>>
>>> As long as there is a valid physical address in the EDID and the omap
>>> CEC support is enabled, then we keep ls_oe_gpio on to ensure the CEC
>>> signal is passed through the tpd12s015.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> Suggested-by: Tomi Valkeinen 
>>> ---
>>>  drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 -
>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
>>> b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
>>> index 916a899..efbba23 100644
>>> --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
>>> +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
>>> @@ -16,6 +16,7 @@
>>>  #include 
>>>  #include 
>>>  
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -65,6 +66,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev,
>>> return;
>>>  
>>> gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);
>>> +   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
>>>  
>>> dst->src = NULL;
>>> dssdev->dst = NULL;
>>> @@ -142,6 +144,7 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
>>>  {
>>> struct panel_drv_data *ddata = to_panel_data(dssdev);
>>> struct omap_dss_device *in = ddata->in;
>>> +   bool valid_phys_addr = 0;
>>> int r;
>>>  
>>> if (!gpiod_get_value_cansleep(ddata->hpd_gpio))
>>> @@ -151,7 +154,15 @@ static int tpd_read_edid(struct omap_dss_device 
>>> *dssdev,
>>>  
>>> r = in->ops.hdmi->read_edid(in, edid, len);
>>>  
>>> -   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
>>> +#ifdef CONFIG_OMAP2_DSS_HDMI_CEC
>>> +   /*
>>> +* In order to support CEC this pin should remain high
>>> +* as long as the EDID has a valid physical address.
>>> +*/
>>> +   valid_phys_addr =
>>> +   cec_get_edid_phys_addr(edid, r, NULL) != CEC_PHYS_ADDR_INVALID;
>>> +#endif
>>> +   gpiod_set_value_cansleep(ddata->ls_oe_gpio, valid_phys_addr);
>>>  
>>> return r;
>>>  }
>>
>> I think this works, but... Maybe it would be cleaner to have the LS_OE
>> enabled if a cable is connected. That's actually what we had earlier,
>> but I removed that due to a race issue:
>>
>> a87a6d6b09de3118e5679c2057b99b7791b7673b ("OMAPDSS: encoder-tpd12s015:
>> Fix race issue with LS_OE"). Now, with CEC, there's need to have LS_OE
>> enabled even after reading the EDID, so I think it's better to go back
>> to the old model (after fixing the race issue, of course =).
> 
> So, this is a bit of a blast from the past since the omap4 CEC development
> has been on hold for almost a year. But I am about to resume my work on this
> now that the CEC framework was merged.
> 
> The latest code is here, if you are interested:
> 
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=panda-cec
> 
> It's pretty much unchanged from the version I posted a year ago, just rebased.
> 
> But before I continue with this I have one question for you. First some
> background:
> 
> There is a special corner case (and I wasn't aware of that a year ago!) where
> it is allowed to send a CEC message when there is *no HPD*.
> 
> The reason is that some displays turn off the hotplug detect pin when they go
> into standby or when another input is active. The only way to communicate with
> such displays is via CEC.
> 
> The problem is that without a HPD there is no EDID and basically no way for an
> HDMI transmitter to detect that something is connected at all, unless you are
> using CEC.
> 
> What this means is that if we want to implement this on the omap4 the CEC 
> support
> has to be on all the time.
> 
> We have seen modern displays that behave like this, so this is a real issue. 
> And
> this corner case is specifically allowed by the CEC specification: the Poll,
> Image/Text View On and the Active Source messages can be sent to a TV even 
> when
> there is no HPD in order to turn on the display if it was in standby and to 
> make
> us the active input.
> 
> The CEC framework in the kernel supports this starting with 4.12 (this code is
> in the panda-cec branch above).
> 
> If this *can't* be supported by the omap4, then I will likely have to add a 
> CEC
> capability to signal to the application that this specific corner case is not
> supported.

FYI: I've just added support for this to the panda-cec branch. CEC on the omap4
now works again, but you can't send CEC messages as long as there is no valid
physical address.

Regards,

Hans

> 
> I just did some tests with omap4 and I my impression is that this can't be
> supported: when the HPD goes away it seems like most/all of the HDMI blocks 
> are
> all powered off and any attempt to even access the CEC registers will fail.
> 
> 

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Greg Kroah-Hartman]

On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
> Hi,
> 
> This is v3 of the series to do some serious Ion cleanup in preparation for
> moving out of staging. I didn't hear much on v2 so I'm going to assume
> people are okay with the series as is. I know there were still some open
> questions about moving away from /dev/ion but in the interest of small
> steps I'd like to go ahead and merge this series assuming there are no more
> major objections. More work can happen on top of this.

I've applied patches 3-11 as those were independant of the CMA changes.
I'd like to take the rest, including the CMA changes, but I need an ack
from someone dealing with the -mm tree before I can do that.

Or, if they just keep ignoring it, I guess I can take them :)

thanks,

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

[Bug 100618] Dead Island crash after starting a new game

[bugzilla-daemon]

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

at...@t-online.de changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=85564

-- 
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 100618] Dead Island crash after starting a new game

[bugzilla-daemon]

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

at...@t-online.de changed:

   What|Removed |Added

Summary|Dead Island |Dead Island crash after
   ||starting a new game

-- 
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 100618] Dead Island

[bugzilla-daemon]

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

Bug ID: 100618
   Summary: Dead Island
   Product: Mesa
   Version: 17.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: at...@t-online.de
QA Contact: dri-devel@lists.freedesktop.org

After you choose a character, the game loads for a few seconds and then it
crashes. Graphic card is an AMD R7 260X. Tried Mesa 12.0.6 and 17.0.3 via
padoka stable ppa. Could be related to #85564
https://bugs.freedesktop.org/show_bug.cgi?id=85564

-- 
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 PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

[Hans Verkuil]

Hi Tomi,

On 05/10/2016 01:36 PM, Tomi Valkeinen wrote:
> Hi Hans,
> 
> On 29/04/16 12:39, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> As long as there is a valid physical address in the EDID and the omap
>> CEC support is enabled, then we keep ls_oe_gpio on to ensure the CEC
>> signal is passed through the tpd12s015.
>>
>> Signed-off-by: Hans Verkuil 
>> Suggested-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
>> b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
>> index 916a899..efbba23 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -65,6 +66,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev,
>>  return;
>>  
>>  gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);
>> +gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
>>  
>>  dst->src = NULL;
>>  dssdev->dst = NULL;
>> @@ -142,6 +144,7 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
>>  {
>>  struct panel_drv_data *ddata = to_panel_data(dssdev);
>>  struct omap_dss_device *in = ddata->in;
>> +bool valid_phys_addr = 0;
>>  int r;
>>  
>>  if (!gpiod_get_value_cansleep(ddata->hpd_gpio))
>> @@ -151,7 +154,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
>>  
>>  r = in->ops.hdmi->read_edid(in, edid, len);
>>  
>> -gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
>> +#ifdef CONFIG_OMAP2_DSS_HDMI_CEC
>> +/*
>> + * In order to support CEC this pin should remain high
>> + * as long as the EDID has a valid physical address.
>> + */
>> +valid_phys_addr =
>> +cec_get_edid_phys_addr(edid, r, NULL) != CEC_PHYS_ADDR_INVALID;
>> +#endif
>> +gpiod_set_value_cansleep(ddata->ls_oe_gpio, valid_phys_addr);
>>  
>>  return r;
>>  }
> 
> I think this works, but... Maybe it would be cleaner to have the LS_OE
> enabled if a cable is connected. That's actually what we had earlier,
> but I removed that due to a race issue:
> 
> a87a6d6b09de3118e5679c2057b99b7791b7673b ("OMAPDSS: encoder-tpd12s015:
> Fix race issue with LS_OE"). Now, with CEC, there's need to have LS_OE
> enabled even after reading the EDID, so I think it's better to go back
> to the old model (after fixing the race issue, of course =).

So, this is a bit of a blast from the past since the omap4 CEC development
has been on hold for almost a year. But I am about to resume my work on this
now that the CEC framework was merged.

The latest code is here, if you are interested:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=panda-cec

It's pretty much unchanged from the version I posted a year ago, just rebased.

But before I continue with this I have one question for you. First some
background:

There is a special corner case (and I wasn't aware of that a year ago!) where
it is allowed to send a CEC message when there is *no HPD*.

The reason is that some displays turn off the hotplug detect pin when they go
into standby or when another input is active. The only way to communicate with
such displays is via CEC.

The problem is that without a HPD there is no EDID and basically no way for an
HDMI transmitter to detect that something is connected at all, unless you are
using CEC.

What this means is that if we want to implement this on the omap4 the CEC 
support
has to be on all the time.

We have seen modern displays that behave like this, so this is a real issue. And
this corner case is specifically allowed by the CEC specification: the Poll,
Image/Text View On and the Active Source messages can be sent to a TV even when
there is no HPD in order to turn on the display if it was in standby and to make
us the active input.

The CEC framework in the kernel supports this starting with 4.12 (this code is
in the panda-cec branch above).

If this *can't* be supported by the omap4, then I will likely have to add a CEC
capability to signal to the application that this specific corner case is not
supported.

I just did some tests with omap4 and I my impression is that this can't be
supported: when the HPD goes away it seems like most/all of the HDMI blocks are
all powered off and any attempt to even access the CEC registers will fail.

Changing this looks to be non-trivial if not impossible.

Can you confirm that that isn't possible? If you think this can be done, then
I'd appreciate if you can give me a few pointers.

Regards,

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

[Bug 100593] corruption in total war warhammer when using mesa 17.1 - git

[bugzilla-daemon]

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

tarp...@gmx.de changed:

   What|Removed |Added

 Attachment #130714|0   |1
is obsolete||

--- Comment #3 from tarp...@gmx.de ---
Created attachment 130754
  --> https://bugs.freedesktop.org/attachment.cgi?id=130754=edit
Warhammer glitch padoka ppa after update on 2017-04-08

The padoka ppa was updated today

Changes:
mesa1:17.1~git170407201100.c05cf9c~x~padoka0Paulo Dias (9 hours
ago)
mesa1:17.1~git170407201100.c05cf9c~y~padoka0Paulo Dias (9 hours
ago)
libdrm  2.4.78+git1704072009.047aba1~x~padoka0  Paulo Dias (9 hours ago)
libdrm  2.4.78+git1704072009.047aba1~y~padoka0  Paulo Dias (9 hours ago) 

Now both padoka and oibaf show the same error.

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

Re: drm_modeset_lock oops in next

[Maarten Lankhorst]

Hey,

Op 07-04-17 om 17:56 schreef 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?
Looks like fallout from the acquire_ctx patches?

Could you test the below?

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 838ca742a28b..2c5b5bf68e3d 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -720,15 +720,16 @@ 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;
}

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