[Bug 101182] Reading amdgpu_pm_info causes stutter with Linux 4.12-rc

[bugzilla-daemon]

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

--- Comment #1 from Christoph Haag  ---
Created attachment 131501
  --> https://bugs.freedesktop.org/attachment.cgi?id=131501&action=edit
screenshot showing the stuttering in the HUD

-- 
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 08/37] drm/doc: Polish irq helper documentation

[Stefan Agner]

On 2017-05-24 07:51, Daniel Vetter wrote:
> Pull a (much shorter) overview into drm_irq.c, and instead put the
> callback documentation into in-line comments in drm_drv.h.

Looks good and just found all I needed to know to fix IRQ registration
in fsl dcu.

Reviewed-by: Stefan Agner 

> 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-internals.rst | 62 
> +
>  drivers/gpu/drm/drm_irq.c   | 30 +++---
>  drivers/gpu/drm/drm_vblank.c|  3 ++
>  include/drm/drmP.h  |  9 --
>  include/drm/drm_drv.h   | 33 ++--
>  5 files changed, 74 insertions(+), 63 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-internals.rst
> b/Documentation/gpu/drm-internals.rst
> index d218dd29221a..82b406d3d377 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -149,60 +149,14 @@ Device Instance and Driver Handling
>  Driver Load
>  ---
>  
> -IRQ Registration
> -
> -
> -The DRM core tries to facilitate IRQ handler registration and
> -unregistration by providing :c:func:`drm_irq_install()` and
> -:c:func:`drm_irq_uninstall()` functions. Those functions only
> -support a single interrupt per device, devices that use more than one
> -IRQs need to be handled manually.
> -
> -Managed IRQ Registration
> -
> -
> -:c:func:`drm_irq_install()` starts by calling the irq_preinstall
> -driver operation. The operation is optional and must make sure that the
> -interrupt will not get fired by clearing all pending interrupt flags or
> -disabling the interrupt.
> -
> -The passed-in IRQ will then be requested by a call to
> -:c:func:`request_irq()`. If the DRIVER_IRQ_SHARED driver feature
> -flag is set, a shared (IRQF_SHARED) IRQ handler will be requested.
> -
> -The IRQ handler function must be provided as the mandatory irq_handler
> -driver operation. It will get passed directly to
> -:c:func:`request_irq()` and thus has the same prototype as all IRQ
> -handlers. It will get called with a pointer to the DRM device as the
> -second argument.
> -
> -Finally the function calls the optional irq_postinstall driver
> -operation. The operation usually enables interrupts (excluding the
> -vblank interrupt, which is enabled separately), but drivers may choose
> -to enable/disable interrupts at a different time.
> -
> -:c:func:`drm_irq_uninstall()` is similarly used to uninstall an
> -IRQ handler. It starts by waking up all processes waiting on a vblank
> -interrupt to make sure they don't hang, and then calls the optional
> -irq_uninstall driver operation. The operation must disable all hardware
> -interrupts. Finally the function frees the IRQ by calling
> -:c:func:`free_irq()`.
> -
> -Manual IRQ Registration
> -'''
> -
> -Drivers that require multiple interrupt handlers can't use the managed
> -IRQ registration functions. In that case IRQs must be registered and
> -unregistered manually (usually with the :c:func:`request_irq()` and
> -:c:func:`free_irq()` functions, or their :c:func:`devm_request_irq()` and
> -:c:func:`devm_free_irq()` equivalents).
> -
> -When manually registering IRQs, drivers must not set the
> -DRIVER_HAVE_IRQ driver feature flag, and must not provide the
> -irq_handler driver operation. They must set the :c:type:`struct
> -drm_device ` irq_enabled field to 1 upon
> -registration of the IRQs, and clear it to 0 after unregistering the
> -IRQs.
> +IRQ Helper Library
> +~~
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_irq.c
> +   :doc: irq helpers
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_irq.c
> +   :export:
>  
>  Memory Manager Initialization
>  ~
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 28d736c3fcb4..3b04c25100ae 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -62,19 +62,39 @@
>  #include "drm_internal.h"
>  
>  /**
> + * DOC: irq helpers
> + *
> + * The DRM core provides very simple support helpers to enable IRQ
> handling on a
> + * device through the drm_irq_install() and drm_irq_uninstall() functions. 
> This
> + * only supports devices with a single interrupt on the main device stored in
> + * &drm_device.dev and set as the device paramter in drm_dev_alloc().
> + *
> + * These IRQ helpers are strictly optional. Drivers which roll their own only
> + * need to set &drm_device.irq_enabled to signal the DRM core that vblank
> + * interrupts are working. Since these helpers don't automatically clean up 
> the
> + * requested interrupt like e.g. devm_request_irq() they're not really
> + * recommended.
> + */
> +
> +/**
>   * drm_irq_install - install IRQ handler
>   * @dev: DRM device
>   * @irq: IRQ number to install the handler for
>   *
>   * Initializes the IRQ related data. Installs the handler, calling the driver
> - * irq_preinstall() and irq_postinstall() functions before and af

[Bug 99349] Failed to build shader (translation from TGSI)

[bugzilla-daemon]

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

--- Comment #5 from Gert Wollny  ---
Adding yet more debugging output, and so far it seems that there is only one
operation failing: a multiplication of two operands with a write mask of 0xF
(see log below). 

I also tested gzdoom like the poster I referenced in my last comment, but on my
machine it works fine. 

r600_asm.c:1297 r600_bytecode_add_alu_type - check_and_set_bank_swizzle
returned -1
r600_asm.c:1303 r600_bytecode_add_alu_type -   slot[0]: op: 2, bank_swizzle:0
bank_swizzle_force: 0
r600_asm.c:1303 r600_bytecode_add_alu_type -   slot[1]: op: 2, bank_swizzle:0
bank_swizzle_force: 0
r600_asm.c:1303 r600_bytecode_add_alu_type -   slot[2]: op: 2, bank_swizzle:0
bank_swizzle_force: 0
r600_asm.c:1303 r600_bytecode_add_alu_type -   slot[3]: op: 2, bank_swizzle:0
bank_swizzle_force: 0
r600_asm.c:1305 r600_bytecode_add_alu_type -   slot[4] = 0: 0
r600_shader.c:3979 tgsi_op2_s - Error in tgsi_op2_s, i = 3, lasti = 3,
r600_bytecode_add_alu returned  -1
r600_shader.c:3981 tgsi_op2_s -   op=2, num src registers: 2, write_mask=15
r600_shader.c:3983 tgsi_op2_s -   alu.dst: {sel: 15, chan: 3, clamp: 0, write:
1, rel: 0
r600_shader.c:3986 tgsi_op2_s -   alu.src0: {sel: 160, chan: 3, kc_bank:0
r600_shader.c:3988 tgsi_op2_s -   alu.src1: {sel: 535, chan: 3, kc_bank:0
r600_shader.c:3332 r600_shader_from_tgsi - Failed to build shader at
ctx.inst_info->process, chip class: 6, opcode: 7 result: -1
r600_shader.c:183 r600_pipe_shader_create - translation from TGSI failed !
r600_state_common.c:787 r600_shader_select - Failed to build shader variant
(type=1) -1

-- 
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 19/37] drm/fsl: Drop drm_vblank_cleanup

[Stefan Agner]

On 2017-05-24 07:51, Daniel Vetter wrote:
> Again cleanup before irq disabling doesn't really stop the races,
> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
> before everything gets cleaned up.

Hm, I already use the non-atomic drm_crtc_force_disable_all before, I
think that fixed the races I saw.

But I guess what you are saying instead of using
drm_crtc_force_disable_all I should use drm_atomic_helper_shutdown...?

Will try that.

FWIW,

Acked-by: Stefan Agner 

--
Stefan

> 
> Cc: Stefan Agner 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 6e00f4b267f1..b34d09b59eee 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -109,7 +109,6 @@ static int fsl_dcu_load(struct drm_device *dev,
> unsigned long flags)
>   drm_fbdev_cma_fini(fsl_dev->fbdev);
>  
>   drm_mode_config_cleanup(dev);
> - drm_vblank_cleanup(dev);
>   drm_irq_uninstall(dev);
>   dev->dev_private = NULL;
>  
> @@ -127,7 +126,6 @@ static void fsl_dcu_unload(struct drm_device *dev)
>   drm_fbdev_cma_fini(fsl_dev->fbdev);
>  
>   drm_mode_config_cleanup(dev);
> - drm_vblank_cleanup(dev);
>   drm_irq_uninstall(dev);
>  
>   dev->dev_private = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm: introduce sync objects (v3)

[Chris Wilson]

On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
> 
> There is also a generic wait obj API modelled on the vulkan
> wait API (with code modelled on some amdgpu code).
> 
> These objects can be converted to an opaque fd that can be
> passes between processes.
> 
> v2: rename reference/unreference to put/get (Chris)
> fix leaked reference (David Zhou)
> drop mutex in favour of cmpxchg (Chris)
> v3: cleanups from danvet, rebase on drm_fops rename
> check fd_flags is 0 in ioctls.
> 
> Reviewed-by: Sean Paul 
> Signed-off-by: Dave Airlie 
> ---
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 42d9f64..96c5c78 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -648,6 +648,7 @@ struct drm_gem_open {
>  #define DRM_CAP_ADDFB2_MODIFIERS 0x10
>  #define DRM_CAP_PAGE_FLIP_TARGET 0x11
>  #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
> +#define DRM_CAP_SYNCOBJ  0x13
>  
>  /** DRM_IOCTL_GET_CAP ioctl argument type */
>  struct drm_get_cap {
> @@ -697,6 +698,24 @@ struct drm_prime_handle {
>   __s32 fd;
>  };
>  
> +struct drm_syncobj_create {
> + __u32 handle;
> + __u32 flags;
> +};
> +
> +struct drm_syncobj_destroy {
> + __u32 handle;
> + __u32 pad;
> +};
> +
> +struct drm_syncobj_handle {
> + __u32 handle;
> + __u32 flags;
> +
> + __s32 fd;
> + __u32 pad;
> +};
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> @@ -815,6 +834,11 @@ extern "C" {
>  #define DRM_IOCTL_MODE_CREATEPROPBLOBDRM_IOWR(0xBD, struct 
> drm_mode_create_blob)
>  #define DRM_IOCTL_MODE_DESTROYPROPBLOB   DRM_IOWR(0xBE, struct 
> drm_mode_destroy_blob)
>  
> +#define DRM_IOCTL_SYNCOBJ_CREATE DRM_IOWR(0xBF, struct 
> drm_syncobj_create)
> +#define DRM_IOCTL_SYNCOBJ_DESTROYDRM_IOWR(0xC0, struct 
> drm_syncobj_destroy)

These two only need DRM_IOW.

> +#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD   DRM_IOWR(0xC1, struct 
> drm_syncobj_handle)
> +#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE   DRM_IOWR(0xC2, struct 
> drm_syncobj_handle)

With that,
Reviewed-by: Chris Wilson 
-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 2/5] drm/syncobj: add sync obj wait interface. (v3)

[Chris Wilson]

On Wed, May 24, 2017 at 05:06:12PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This interface will allow sync object to be used to back
> Vulkan fences. This API is pretty much the vulkan fence waiting
> API, and I've ported the code from amdgpu.
> 
> v2: accept relative timeout, pass remaining time back
> to userspace.
> v3: return to absolute timeouts.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_internal.h |   2 +
>  drivers/gpu/drm/drm_ioctl.c|   2 +
>  drivers/gpu/drm/drm_syncobj.c  | 164 
> +
>  include/uapi/drm/drm.h |  14 
>  4 files changed, 182 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 3fdef2c..53e3f6b 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device 
> *dev, void *data,
>  struct drm_file *file_private);
>  int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file_private);
> +int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file_private);
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index f1e5681..385ce74 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
> drm_syncobj_fd_to_handle_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
> +   DRM_UNLOCKED|DRM_RENDER_ALLOW),
>  };
>  
>  #define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index b611480..8b87594 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -1,5 +1,7 @@
>  /*
>   * Copyright 2017 Red Hat
> + * Parts ported from amdgpu (fence wait code).
> + * Copyright 2016 Advanced Micro Devices, Inc.
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a
>   * copy of this software and associated documentation files (the "Software"),
> @@ -31,6 +33,9 @@
>   * that contain an optional fence. The fence can be updated with a new
>   * fence, or be NULL.
>   *
> + * syncobj's can be waited upon, where it will wait for the underlying
> + * fence.
> + *
>   * syncobj's can be export to fd's and back, these fd's are opaque and
>   * have no other use case, except passing the syncobj between processes.
>   *
> @@ -375,3 +380,162 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
> void *data,
>   return drm_syncobj_fd_to_handle(file_private, args->fd,
>   &args->handle);
>  }
> +
> +
> +/**
> + * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute value
> + *
> + * @timeout_ns: timeout in ns
> + *
> + * Calculate the timeout in jiffies from an absolute timeout in ns.
> + */
> +unsigned long drm_timeout_abs_to_jiffies(uint64_t timeout_ns)

Not in any header or otherwise exported, so static?

> +{
> + unsigned long timeout_jiffies;
> + ktime_t timeout;
> +
> + /* clamp timeout if it's to large */
> + if (((int64_t)timeout_ns) < 0)
> + return MAX_SCHEDULE_TIMEOUT;
> +
> + timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
> + if (ktime_to_ns(timeout) < 0)
> + return 0;
> +
> + timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
> + /*  clamp timeout to avoid unsigned-> signed overflow */
> + if (timeout_jiffies > MAX_SCHEDULE_TIMEOUT )
> + return MAX_SCHEDULE_TIMEOUT - 1;

This about avoiding the conversion into an infinite timeout, right?
I think the comment is misleading (certainly doesn't explain
MAX_SCHEDULE_TIMEOUT-1) and the test should be >= MAX_SCHEDULE_TIMEOUT.

> +
> + return timeout_jiffies;

Timeouts tend to use timeout_jiffies + 1 to avoid the timer interrupt
screwing up the calculation, or just generally returning a fraction too
early.

> +}
> +
> +static int drm_syncobj_wait_all_fences(struct drm_device *dev,
> +struct drm_file *file_private,
> +struct drm_syncobj_wait *wait,
> +uint32_t *handles)
> +{
> + uint32_t i;
> + int ret;
> + unsigned long timeout = drm_timeout_abs_to_jiffies(wait->timeout_ns);

Also note that this doesn't handle timeout = 0 very gracefully with
multiple fences. (dma_fence_wait_timeout will convert that on return to
1). Hmm, by using an absolute timeout we can't pass into timeout=0 to do a
poll.

> +
> + for (i = 0; i < wait->count_handles; i++) {
> +  

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

[Chris Wilson]

On Wed, May 24, 2017 at 05:06:13PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This interface allows importing the fence from a sync_file into
> an existing drm sync object, or exporting the fence attached to
> an existing drm sync object into a new sync file object.
> 
> This should only be used to interact with sync files where necessary.
> 
> Reviewed-by: Sean Paul 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_syncobj.c | 64 
> +--
>  include/uapi/drm/drm.h|  2 ++
>  2 files changed, 64 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 8b87594..54d751e 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -50,6 +50,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_internal.h"
>  #include 
> @@ -276,6 +277,48 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
> *file_private,
>   return 0;
>  }
>  
> +int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
> +int fd, int handle)
> +{
> + struct dma_fence *fence = sync_file_get_fence(fd);
> + if (!fence)
> + return -EINVAL;
> +
> + return drm_syncobj_replace_fence(file_private, handle, fence);

Didn't replace_fence() acquire its own reference to fence, and so we
need to drop our reference afterwards?

> +}
> +
> +int drm_syncobj_export_sync_file(struct drm_file *file_private,
> +  int handle, int *p_fd)
> +{
> + int ret;
> + struct dma_fence *fence;
> + struct sync_file *sync_file;
> + int fd = get_unused_fd_flags(O_CLOEXEC);
> +
> + if (fd < 0)
> + return fd;
> +
> + ret = drm_syncobj_fence_get(file_private, handle, &fence);
> + if (ret)
> + goto err_put_fd;
> +
> + sync_file = sync_file_create(fence);

Could move dma_fence_put() here and so drop the err_fence_put.

> + if (!sync_file) {
> + ret = -EINVAL;
> + goto err_fence_put;
> + }
> +
> + fd_install(fd, sync_file->file);
> +
> + dma_fence_put(fence);
> + *p_fd = fd;
> + return 0;
> +err_fence_put:
> + dma_fence_put(fence);
> +err_put_fd:
> + put_unused_fd(fd);
> + return ret;
> +}
>  /**
>   * drm_syncobj_open - initalizes syncobj file-private structures at devnode 
> open time
>   * @dev: drm_device which is being opened by userspace
> @@ -358,9 +401,17 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
> void *data,
>   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
>   return -ENODEV;
>  
> - if (args->pad || args->flags)
> + if (args->pad)
> + return -EINVAL;
> +
> + if (args->flags != 0 &&
> + args->flags != 
> DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE)
>   return -EINVAL;

DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_AS_SYNC_FILE ?

I'm sure if the addition of FENCE makes it any clearer in the
import/export names. The conversion of import is syncobj -> sync_file
and vice versa.
-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

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

[bugzilla-daemon]

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

--- Comment #4 from beta990 (francois5...@gmail.com) ---
Created attachment 256713
  --> https://bugzilla.kernel.org/attachment.cgi?id=256713&action=edit
dmesg

-- 
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 195737] AMDGPU: incorrect monitor position on Xorg

[bugzilla-daemon]

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

--- Comment #5 from beta990 (francois5...@gmail.com) ---
Created attachment 256715
  --> https://bugzilla.kernel.org/attachment.cgi?id=256715&action=edit
Xorg-log

-- 
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 195737] AMDGPU: incorrect monitor position on Xorg

[bugzilla-daemon]

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

--- Comment #6 from beta990 (francois5...@gmail.com) ---
Created attachment 256717
  --> https://bugzilla.kernel.org/attachment.cgi?id=256717&action=edit
Screen

-- 
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 195737] AMDGPU: incorrect monitor position on Xorg

[bugzilla-daemon]

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

--- Comment #7 from beta990 (francois5...@gmail.com) ---
Sorry for the delay. I've added the requested logs and provided a photo of what
is happening on my screen atm. when using AMDGPU.

Thanks and please let me know if more info is needed. :)

-- 
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 195737] AMDGPU: incorrect monitor position on Xorg

[bugzilla-daemon]

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

beta990 (francois5...@gmail.com) changed:

   What|Removed |Added

 Kernel Version|4.10.13 |4.11.2

-- 
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 98874] amdgpu: [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, [drm] IP block:5 is hang

[bugzilla-daemon]

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

Matthias Nagel  changed:

   What|Removed |Added

Summary|Desktop suddenly freezes,   |amdgpu:
   |login via ssh possible, no  |[drm:amdgpu_job_timedout]
   |error messages, unable to   |*ERROR* ring gfx timeout,
   |power off   |[drm] IP block:5 is hang

-- 
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 99349] Failed to build shader (translation from TGSI)

[bugzilla-daemon]

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

--- Comment #6 from Gert Wollny  ---
The actual instruction failing is 

   MUL TEMP[11], CONST[26], CONST[23]

i.e. the multiplication of two constants.

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

Re: [PATCH v2 3/5] drm/bridge/synopsys: Add MIPI DSI host controller bridge

[Archit Taneja]

Hi Philippe,

Thanks a lot for creating a bridge driver for this.

Copying some Hisilicon and Rockchip folks so that they can consider adapting to 
this.

Some comments below.

On 05/19/2017 08:50 PM, Philippe CORNU wrote:

Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.

Signed-off-by: Philippe CORNU 
---
 drivers/gpu/drm/bridge/synopsys/Kconfig   |9 +
 drivers/gpu/drm/bridge/synopsys/Makefile  |2 +
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 1024 +
 3 files changed, 1035 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 40d2827..d7fbdff 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -21,3 +21,12 @@ config DRM_DW_HDMI_I2S_AUDIO
help
  Support the I2S Audio interface which is part of the Synopsys
  Designware HDMI block.
+
+config DRM_DW_MIPI_DSI
+   tristate "Synopsys DesignWare MIPI DSI host controller bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   help
+ Choose this if you want to use the Synopsys DesignWare MIPI DSI host
+ controller bridge.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a6..5f57d36 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,5 @@
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+
+obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw-mipi-dsi.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
new file mode 100644
index 000..041f564
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -0,0 +1,1024 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Modified by Philippe Cornu 
+ * This generic Synopsys Designware MIPI DSI host driver is based on the
+ * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DSI_VERSION0x00
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VID(vid)   (((vid) & 0x3) << 0)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define EN18_LOOSELY   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define EN_CRC_RX  BIT(4)
+#define EN_ECC_RX  BIT(3)
+#define EN_BTA BIT(2)
+#define EN_EOTP_RX BIT(1)
+#define EN_EOTP_TX BIT(0)
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define FRAME_BTA_ACK  BIT(14)
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
+#define VID_MODE_TYPE_BURST0x2
+#define VID_MODE_TYPE_MASK 0x3
+
+#define DSI_VID_PKT_SIZE   

[Bug 101185] System hang during piglit tests

[bugzilla-daemon]

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

Bug ID: 101185
   Summary: System hang during piglit tests
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: kep...@gmx.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 131505
  --> https://bugs.freedesktop.org/attachment.cgi?id=131505&action=edit
crash logs and piglit result json

I was running "piglit run tests/quick results/quick" yesterday and system
suddenly stopped responding at test 36216/39353. I was forced to do 5 second
power switch shut down. Today I ran the test again and it didn't hang the
system but stopped progressing at 38239/39353 where I did Ctrl-C. Attached is
backtrace of crashes. 

$ inxi -G
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Tonga PRO [Radeon R9 285/380]
   Display Server: X.Org 1.19.3 driver: amdgpu
   Resolution: 1920x1080@60.00hz, 1920x1080@60.00hz
   GLX Renderer: Gallium 0.4 on AMD TONGA (DRM 3.15.0 /
4.12.0-rc1-g2ea659a9ef48, LLVM 5.0.0)
   GLX Version: 3.0 Mesa 17.2.0-devel (git-1586768e74)

-- 
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 101182] Reading amdgpu_pm_info causes stutter with Linux 4.12-rc

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #2 from Alex Deucher  ---
amdgpu_pm_info exposes power statistics now which causes a small delay to
sample the power usage.  If you want to poll the current clocks, there is an
ioctl interface to query this information.

-- 
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 101182] Reading amdgpu_pm_info causes stutter with Linux 4.12-rc

[bugzilla-daemon]

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

--- Comment #3 from Christoph Haag  ---
Can this be done asynchronously in the driver so it doesn't impact the
rendering of 3D applications?

-- 
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 195737] AMDGPU: incorrect monitor position on Xorg

[bugzilla-daemon]

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

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

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
setting amdgpu.audio=0 should work around it. Audio support for SI in amdgpu
will land upstream for 4.13

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

[RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD

[Hans Verkuil]

From: Hans Verkuil 

Document the new CEC_CAP_NEEDS_HPD capability.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
index a0e961f11017..6d7bf7bef3eb 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
@@ -113,6 +113,14 @@ returns the information to the application. The ioctl 
never fails.
   - 0x0020
   - The CEC hardware can monitor all messages, not just directed and
broadcast messages.
+* .. _`CEC-CAP-NEEDS-HPD`:
+
+  - ``CEC_CAP_NEEDS_HPD``
+  - 0x0040
+  - The CEC hardware is only active if the HDMI Hotplug Detect pin is
+high. This makes it impossible to use CEC to wake up displays that
+   set the HPD pin low when in standby mode, but keep the CEC bus
+   alive.
 
 
 
-- 
2.11.0

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

[RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
protocol.

This patch series is based on v4.12-rc2.

The first four patches add support for a new CEC capability which is
needed for these devices and for two helper functions.

Then the DP CEC registers are added using Clint's patch.

The core CEC tunneling support is added to drm_dp_cec.c.

And finally this is hooked up in the i915 driver.

Ideally the cec driver is created and destroyed whenever the DP-to-HDMI
adapter is connected/disconnected, but I have not been a able to find
a way to distinguish between connecting/disconnecting the HDMI cable
and connecting/disconnecting the actual DP-to-HDMI adapter.

My current approach is to check the CEC tunneling support whenever a new
display is connected:

- if CEC tunneling is supported, but no CEC adapter exists, then create one.
- if CEC tunneling is not supported, then unregister the CEC adapter if one
  was created earlier.
- if CEC tunneling is supported and the capabilities are identical to the
  existing CEC adapter, then leave it be.
- if CEC tunneling is supported and the capabilities are different to the
  existing CEC adapter, then unregister that CEC adapter and register a
  new one.

This works well, but it would be much nicer if I would just know when the
DP adapter is disconnected as opposed to when the HDMI cable is disconnected
from the adapter. Suggestions are welcome.

The other remaining problem is that there are DP/USB-C to HDMI adapters that
support CEC tunneling in the chipset, but where the CEC pin is simply never
hooked up. From the point of view of the driver CEC is supported, but you'll
never see any other devices.

I am considering sending a CEC POLL message to logical address 0 (the TV)
to detect if the CEC pin is connected, but this is not 100% guaranteed to
work. This can be put under a kernel config option, though.

I think I need to do something for this since of the 5 USB-C to HDMI
adapters I've tested that set the CEC tunneling capability, only 2 have
the CEC pin hooked up. So this seems to be quite common.

I have tested this with my Intel NUC7i5BNK and with the two working
USB-C to HDMI adapters that I have found:

a Samsung EE-PW700 adapter and a Kramer ADC-U31C/HF adapter (I think that's
the model, I need to confirm this).

As usual the specifications of these adapters never, ever tell you whether
this is supported or not :-( It's trial and error to find one that works. In
fact, of the 10 USB-C to HDMI adapters I tested 5 didn't support CEC tunneling
at all, and of the remaining 5 only two had the CEC pin hooked up and so
actually worked.

BTW, all adapters that supported CEC tunneling used the Parade PS176 chip.

Output of cec-ctl -S (discovers the CEC topology):

$ cec-ctl -S
Driver Info:
Driver Name: i915
Adapter Name   : DPDDC-C
Capabilities   : 0x007e
Logical Addresses
Transmit
Passthrough
Remote Control Support
Monitor All
Driver version : 4.12.0
Available Logical Addresses: 4
Physical Address   : 3.0.0.0
Logical Address Mask   : 0x0010
CEC Version: 2.0
Vendor ID  : 0x000c03 (HDMI)
OSD Name   : 'Playback'
Logical Addresses  : 1 (Allow RC Passthrough)

  Logical Address  : 4 (Playback Device 1)
Primary Device Type: Playback
Logical Address Type   : Playback
All Device Types   : Playback
RC TV Profile  : None
Device Features:
None

System Information for device 0 (TV) from device 4 (Playback Device 1):
CEC Version: 1.4
Physical Address   : 0.0.0.0
Primary Device Type: TV
Vendor ID  : 0xf0 (Samsung)
OSD Name   : TV
Menu Language  : eng
Power Status   : On

Topology:

0.0.0.0: TV
3.0.0.0: Playback Device 1

Regards,

Hans

Clint Taylor (1):
  drm/cec: Add CEC over Aux register definitions

Hans Verkuil (6):
  cec: add CEC_CAP_NEEDS_HPD
  cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD
  cec: add cec_s_phys_addr_from_edid helper function
  cec: add cec_phys_addr_invalidate() helper function
  drm: add support for DisplayPort CEC-Tunneling-over-AUX
  drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

 .../media/uapi/cec/cec-ioc-adap-g-caps.rst |   8 +
 drivers/gpu/drm/Kconfig|   3 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/drm_dp_cec.c   | 196 +
 drivers/gpu/drm/

[RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

From: Hans Verkuil 

Implement support for this DisplayPort feature.

The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the previous one, then the old cec device is
unregistered and a new one is registered to replace the old one.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/i915/Kconfig| 11 ++
 drivers/gpu/drm/i915/intel_dp.c | 46 +
 2 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index a5cd5dacf055..f317b13a1409 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
  Choose this option if you want to enable KVMGT support for
  Intel GVT-g.
 
+config DRM_I915_DP_CEC
+   tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
+   depends on DRM_I915 && CEC_CORE
+   select DRM_DP_CEC
+   help
+ Choose this option if you want to enable HDMI CEC support for
+ DisplayPort/USB-C to HDMI adapters.
+
+ Note: not all adapters support this feature, and even for those
+ that do support this often do not hook up the CEC pin.
+
 menu "drm/i915 Debugging"
 depends on DRM_I915
 depends on EXPERT
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ee77b519835c..38e17ee2548d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
 static void
 intel_dp_aux_fini(struct intel_dp *intel_dp)
 {
+   cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
 }
 
@@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return -EINVAL;
 }
 
+static bool
+intel_dp_check_cec_status(struct intel_dp *intel_dp)
+{
+   bool handled = false;
+
+   for (;;) {
+   u8 cec_irq;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(&intel_dp->aux,
+   DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
+   &cec_irq);
+   if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
+   return handled;
+
+   cec_irq &= ~DP_CEC_IRQ;
+   drm_dp_cec_irq(&intel_dp->aux);
+   handled = true;
+
+   ret = drm_dp_dpcd_writeb(&intel_dp->aux,
+DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
+cec_irq);
+   if (ret < 0)
+   return handled;
+   }
+}
+
 static void
 intel_dp_retrain_link(struct intel_dp *intel_dp)
 {
@@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
else
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
 }
 
 static void
@@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
 
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+   cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
 
intel_dp->has_audio = false;
 }
@@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
 
/* Can't disconnect eDP, but you can close the lid... */
-   if (is_edp(intel_dp))
+   if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
-   else if (intel_digital_port_connected(to_i915(dev),
- dp_to_dig_port(intel_dp)))
+   } else if (intel_digital_port_connected(to_i915(dev),
+   dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
-   else
+   if (status == connector_status_connected)
+   drm_dp_cec_configure_adapter(&intel_dp->aux,
+intel_dp->aux.name, dev->dev);
+   } else {
status = connector_status_disconnected;
+   }
 
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5080,6 +5115,9 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
 
intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
 
+   if (intel_dp->aux.cec_adap)
+   intel_dp_check_cec_status(intel_dp);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_sta

[RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions

[Hans Verkuil]

From: Clint Taylor 

Adding DPCD register definitions from the DP 1.3 specification for CEC
over AUX support.

V2: Add DP_ prefix to all defines.
V3: missed prefixes from the ESI1 defines

Cc: Jani Nikula 

Reviewed-by: Jani Nikula 
Signed-off-by: Clint Taylor 
Signed-off-by: Jani Nikula 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1492703263-11494-1-git-send-email-clinton.a.tay...@intel.com
---
 include/drm/drm_dp_helper.h | 59 +
 1 file changed, 59 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..3f4ad709534e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -603,6 +603,9 @@
 #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0   0x2003   /* 1.2 */
 
 #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1   0x2004   /* 1.2 */
+# define DP_RX_GTC_MSTR_REQ_STATUS_CHANGE(1 << 0)
+# define DP_LOCK_ACQUISITION_REQUEST (1 << 1)
+# define DP_CEC_IRQ  (1 << 2)
 
 #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
 
@@ -636,6 +639,62 @@
 # define DP_VSC_EXT_CEA_SDP_SUPPORTED  (1 << 6)  /* DP 1.4 */
 # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7)  /* DP 1.4 */
 
+/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
+#define DP_CEC_TUNNELING_CAPABILITY0x3000
+# define DP_CEC_TUNNELING_CAPABLE   (1 << 0)
+# define DP_CEC_SNOOPING_CAPABLE(1 << 1)
+# define DP_CEC_MULTIPLE_LA_CAPABLE (1 << 2)
+
+#define DP_CEC_TUNNELING_CONTROL   0x3001
+# define DP_CEC_TUNNELING_ENABLE(1 << 0)
+# define DP_CEC_SNOOPING_ENABLE (1 << 1)
+
+#define DP_CEC_RX_MESSAGE_INFO 0x3002
+# define DP_CEC_RX_MESSAGE_LEN_MASK (0xf << 0)
+# define DP_CEC_RX_MESSAGE_LEN_SHIFT0
+# define DP_CEC_RX_MESSAGE_HPD_STATE(1 << 4)
+# define DP_CEC_RX_MESSAGE_HPD_LOST (1 << 5)
+# define DP_CEC_RX_MESSAGE_ACKED(1 << 6)
+# define DP_CEC_RX_MESSAGE_ENDED(1 << 7)
+
+#define DP_CEC_TX_MESSAGE_INFO 0x3003
+# define DP_CEC_TX_MESSAGE_LEN_MASK (0xf << 0)
+# define DP_CEC_TX_MESSAGE_LEN_SHIFT0
+# define DP_CEC_TX_RETRY_COUNT_MASK (0x7 << 4)
+# define DP_CEC_TX_RETRY_COUNT_SHIFT4
+# define DP_CEC_TX_MESSAGE_SEND (1 << 7)
+
+#define DP_CEC_TUNNELING_IRQ_FLAGS 0x3004
+# define DP_CEC_RX_MESSAGE_INFO_VALID   (1 << 0)
+# define DP_CEC_RX_MESSAGE_OVERFLOW (1 << 1)
+# define DP_CEC_TX_MESSAGE_SENT (1 << 4)
+# define DP_CEC_TX_LINE_ERROR   (1 << 5)
+# define DP_CEC_TX_ADDRESS_NACK_ERROR   (1 << 6)
+# define DP_CEC_TX_DATA_NACK_ERROR  (1 << 7)
+
+#define DP_CEC_LOGICAL_ADDRESS_MASK0x300E /* 0x300F word */
+# define DP_CEC_LOGICAL_ADDRESS_0   (1 << 0)
+# define DP_CEC_LOGICAL_ADDRESS_1   (1 << 1)
+# define DP_CEC_LOGICAL_ADDRESS_2   (1 << 2)
+# define DP_CEC_LOGICAL_ADDRESS_3   (1 << 3)
+# define DP_CEC_LOGICAL_ADDRESS_4   (1 << 4)
+# define DP_CEC_LOGICAL_ADDRESS_5   (1 << 5)
+# define DP_CEC_LOGICAL_ADDRESS_6   (1 << 6)
+# define DP_CEC_LOGICAL_ADDRESS_7   (1 << 7)
+#define DP_CEC_LOGICAL_ADDRESS_MASK_2  0x300F /* 0x300E word */
+# define DP_CEC_LOGICAL_ADDRESS_8   (1 << 0)
+# define DP_CEC_LOGICAL_ADDRESS_9   (1 << 1)
+# define DP_CEC_LOGICAL_ADDRESS_10  (1 << 2)
+# define DP_CEC_LOGICAL_ADDRESS_11  (1 << 3)
+# define DP_CEC_LOGICAL_ADDRESS_12  (1 << 4)
+# define DP_CEC_LOGICAL_ADDRESS_13  (1 << 5)
+# define DP_CEC_LOGICAL_ADDRESS_14  (1 << 6)
+# define DP_CEC_LOGICAL_ADDRESS_15  (1 << 7)
+
+#define DP_CEC_RX_MESSAGE_BUFFER   0x3010
+#define DP_CEC_TX_MESSAGE_BUFFER   0x3020
+#define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
+
 /* DP 1.2 Sideband message defines */
 /* peer device type - DP 1.2a Table 2-92 */
 #define DP_PEER_DEVICE_NONE0x0
-- 
2.11.0

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

[RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD

[Hans Verkuil]

From: Hans Verkuil 

Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set
then the hardware can only use CEC if the HDMI Hotplug Detect pin
is high. Such hardware cannot handle the corner case in the CEC specification
where it is possible to transmit messages even if no hotplug signal is
present (needed for some displays that turn off the HPD when in standby,
but still have CEC enabled).

Typically hardware that needs this capability have the HPD wired to the CEC
block, often to a 'power' or 'active' pin.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 20 ++--
 drivers/media/cec/cec-api.c  |  5 -
 drivers/media/cec/cec-core.c |  1 +
 include/media/cec.h  |  1 +
 include/uapi/linux/cec.h |  2 ++
 5 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index f5fe01c9da8a..303de0d25d2b 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -366,6 +366,8 @@ int cec_thread_func(void *_adap)
 * transmit should be canceled.
 */
err = 
wait_event_interruptible_timeout(adap->kthread_waitq,
+   (adap->needs_hpd &&
+(!adap->is_configured && 
!adap->is_configuring)) ||
kthread_should_stop() ||
(!adap->transmitting &&
 !list_empty(&adap->transmit_queue)),
@@ -381,7 +383,9 @@ int cec_thread_func(void *_adap)
 
mutex_lock(&adap->lock);
 
-   if (kthread_should_stop()) {
+   if ((adap->needs_hpd &&
+(!adap->is_configured && !adap->is_configuring)) ||
+   kthread_should_stop()) {
cec_flush(adap);
goto unlock;
}
@@ -647,7 +651,7 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct 
cec_msg *msg,
return -EINVAL;
}
if (!adap->is_configured && !adap->is_configuring) {
-   if (msg->msg[0] != 0xf0) {
+   if (adap->needs_hpd || msg->msg[0] != 0xf0) {
dprintk(1, "%s: adapter is unconfigured\n", __func__);
return -ENONET;
}
@@ -1126,7 +1130,9 @@ static int cec_config_log_addr(struct cec_adapter *adap,
  */
 static void cec_adap_unconfigure(struct cec_adapter *adap)
 {
-   WARN_ON(adap->ops->adap_log_addr(adap, CEC_LOG_ADDR_INVALID));
+   if (!adap->needs_hpd ||
+   adap->phys_addr != CEC_PHYS_ADDR_INVALID)
+   WARN_ON(adap->ops->adap_log_addr(adap, CEC_LOG_ADDR_INVALID));
adap->log_addrs.log_addr_mask = 0;
adap->is_configuring = false;
adap->is_configured = false;
@@ -1355,6 +1361,8 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 
phys_addr, bool block)
if (phys_addr == adap->phys_addr || adap->devnode.unregistered)
return;
 
+   dprintk(1, "new physical address %x.%x.%x.%x\n",
+   cec_phys_addr_exp(phys_addr));
if (phys_addr == CEC_PHYS_ADDR_INVALID ||
adap->phys_addr != CEC_PHYS_ADDR_INVALID) {
adap->phys_addr = CEC_PHYS_ADDR_INVALID;
@@ -1364,7 +1372,7 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 
phys_addr, bool block)
if (adap->monitor_all_cnt)
WARN_ON(call_op(adap, adap_monitor_all_enable, false));
mutex_lock(&adap->devnode.lock);
-   if (list_empty(&adap->devnode.fhs))
+   if (adap->needs_hpd || list_empty(&adap->devnode.fhs))
WARN_ON(adap->ops->adap_enable(adap, false));
mutex_unlock(&adap->devnode.lock);
if (phys_addr == CEC_PHYS_ADDR_INVALID)
@@ -1372,7 +1380,7 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 
phys_addr, bool block)
}
 
mutex_lock(&adap->devnode.lock);
-   if (list_empty(&adap->devnode.fhs) &&
+   if ((adap->needs_hpd || list_empty(&adap->devnode.fhs)) &&
adap->ops->adap_enable(adap, true)) {
mutex_unlock(&adap->devnode.lock);
return;
@@ -1380,7 +1388,7 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 
phys_addr, bool block)
 
if (adap->monitor_all_cnt &&
call_op(adap, adap_monitor_all_enable, true)) {
-   if (list_empty(&adap->devnode.fhs))
+   if (adap->needs_hpd || list_empty(&adap->devnode.fhs))
WARN_ON(adap->ops->adap_enable(adap, false));
mutex_unlock(&adap->devnode.lock);
return;
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index 0860fb458757..1359c3977101 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -202,7 +202,8 @@ static long cec_transmit(stru

[RFC PATCH 3/7] cec: add cec_s_phys_addr_from_edid helper function

[Hans Verkuil]

From: Hans Verkuil 

This function simplifies the integration of CEC in DRM drivers.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 14 ++
 include/media/cec.h  |  9 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 303de0d25d2b..1b9537d8d24b 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include 
+
 #include "cec-priv.h"
 
 static void cec_fill_msg_report_features(struct cec_adapter *adap,
@@ -1412,6 +1414,18 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16 
phys_addr, bool block)
 }
 EXPORT_SYMBOL_GPL(cec_s_phys_addr);
 
+void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
+  const struct edid *edid)
+{
+   u16 pa = CEC_PHYS_ADDR_INVALID;
+
+   if (edid && edid->extensions)
+   pa = cec_get_edid_phys_addr((const u8 *)edid,
+   EDID_LENGTH * (edid->extensions + 1), NULL);
+   cec_s_phys_addr(adap, pa, false);
+}
+EXPORT_SYMBOL_GPL(cec_s_phys_addr_from_edid);
+
 /*
  * Called from either the ioctl or a driver to set the logical addresses.
  *
diff --git a/include/media/cec.h b/include/media/cec.h
index b08edb31508f..9989cdb58bd8 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -207,6 +207,8 @@ static inline bool cec_is_sink(const struct cec_adapter 
*adap)
 #define cec_phys_addr_exp(pa) \
((pa) >> 12), ((pa) >> 8) & 0xf, ((pa) >> 4) & 0xf, (pa) & 0xf
 
+struct edid;
+
 #if IS_ENABLED(CONFIG_CEC_CORE)
 struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps, u8 available_las);
@@ -218,6 +220,8 @@ int cec_s_log_addrs(struct cec_adapter *adap, struct 
cec_log_addrs *log_addrs,
bool block);
 void cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr,
 bool block);
+void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
+  const struct edid *edid);
 int cec_transmit_msg(struct cec_adapter *adap, struct cec_msg *msg,
 bool block);
 
@@ -327,6 +331,11 @@ static inline void cec_s_phys_addr(struct cec_adapter 
*adap, u16 phys_addr,
 {
 }
 
+static inline void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
+const struct edid *edid)
+{
+}
+
 static inline u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
 unsigned int *offset)
 {
-- 
2.11.0

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

[RFC PATCH 4/7] cec: add cec_phys_addr_invalidate() helper function

[Hans Verkuil]

From: Hans Verkuil 

Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID.

Signed-off-by: Hans Verkuil 
---
 include/media/cec.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/media/cec.h b/include/media/cec.h
index 9989cdb58bd8..6123a5eec540 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -361,4 +361,9 @@ static inline int cec_phys_addr_validate(u16 phys_addr, u16 
*parent, u16 *port)
 
 #endif
 
+static inline void cec_phys_addr_invalidate(struct cec_adapter *adap)
+{
+   cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
+}
+
 #endif /* _MEDIA_CEC_H */
-- 
2.11.0

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

[RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Hans Verkuil]

From: Hans Verkuil 

This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.

Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/Kconfig  |   3 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_cec.c | 196 +++
 include/drm/drm_dp_helper.h  |  24 ++
 4 files changed, 224 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 78d7fc0ebb57..dd771ce8a3d0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE
  default case is N. Details and instructions how to build your own
  EDID data are given in Documentation/EDID/HOWTO.txt.
 
+config DRM_DP_CEC
+   bool
+
 config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59f0f9b696eb..22f1a17dfc8a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -34,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
drm_scdc_helper.o
 
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..44c544ba53cb
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,196 @@
+/*
+ * DisplayPort CEC-Tunneling-over-AUX support
+ *
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   ssize_t err = 0;
+
+   if (enable)
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL,
+DP_CEC_TUNNELING_ENABLE);
+   else
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, 0);
+   return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   u8 mask[2] = { 0x00, 0x80 };
+   ssize_t err;
+
+   if (addr != CEC_LOG_ADDR_INVALID) {
+   u16 la_mask = adap->log_addrs.log_addr_mask;
+
+   la_mask |= 0x8000 | (1 << addr);
+   mask[0] = la_mask & 0xff;
+   mask[1] = la_mask >> 8;
+   }
+   err = drm_dp_dpcd_write(aux, DP_CEC_LOGICAL_ADDRESS_MASK, mask, 2);
+   return (addr != CEC_LOG_ADDR_INVALID && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
+   u32 signal_free_time, struct cec_msg *msg)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   unsigned int retries = attempts - 1;
+   ssize_t err;
+
+   err = drm_dp_dpcd_write(aux, DP_CEC_TX_MESSAGE_BUFFER,
+   msg->msg, msg->len);
+   if (err < 0)
+   return err;
+
+   if (retries > 5)
+   retries = 5;
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TX_MESSAGE_INFO,
+(msg->len - 1) | (retries << 4) |
+DP_CEC_TX_MESSAGE_SEND);
+   return err < 0 ? err : 0;
+}
+
+static int drm_dp_cec_adap_monitor_all_enable(struct cec_adapter *adap,
+ bool enable)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   ssize_t err;
+   u8 val;
+
+   if (!(adap->capabilities & CEC_CAP_MONITOR_ALL))
+   return 0;
+
+   err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CONTROL, &val);
+   if (err >= 0) 

Re: [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX

[Mike Lothian]

Hi

Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C
connector and no displayport

Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working
based on your testing?

I've been putting off buying one until I knew 4K@60Hz would work, CEC would
be nice to have too

Thanks

Mike

On Thu, 25 May 2017 at 16:06 Hans Verkuil  wrote:

> From: Hans Verkuil 
>
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> protocol.
>
> This patch series is based on v4.12-rc2.
>
> The first four patches add support for a new CEC capability which is
> needed for these devices and for two helper functions.
>
> Then the DP CEC registers are added using Clint's patch.
>
> The core CEC tunneling support is added to drm_dp_cec.c.
>
> And finally this is hooked up in the i915 driver.
>
> Ideally the cec driver is created and destroyed whenever the DP-to-HDMI
> adapter is connected/disconnected, but I have not been a able to find
> a way to distinguish between connecting/disconnecting the HDMI cable
> and connecting/disconnecting the actual DP-to-HDMI adapter.
>
> My current approach is to check the CEC tunneling support whenever a new
> display is connected:
>
> - if CEC tunneling is supported, but no CEC adapter exists, then create
> one.
> - if CEC tunneling is not supported, then unregister the CEC adapter if one
>   was created earlier.
> - if CEC tunneling is supported and the capabilities are identical to the
>   existing CEC adapter, then leave it be.
> - if CEC tunneling is supported and the capabilities are different to the
>   existing CEC adapter, then unregister that CEC adapter and register a
>   new one.
>
> This works well, but it would be much nicer if I would just know when the
> DP adapter is disconnected as opposed to when the HDMI cable is
> disconnected
> from the adapter. Suggestions are welcome.
>
> The other remaining problem is that there are DP/USB-C to HDMI adapters
> that
> support CEC tunneling in the chipset, but where the CEC pin is simply never
> hooked up. From the point of view of the driver CEC is supported, but
> you'll
> never see any other devices.
>
> I am considering sending a CEC POLL message to logical address 0 (the TV)
> to detect if the CEC pin is connected, but this is not 100% guaranteed to
> work. This can be put under a kernel config option, though.
>
> I think I need to do something for this since of the 5 USB-C to HDMI
> adapters I've tested that set the CEC tunneling capability, only 2 have
> the CEC pin hooked up. So this seems to be quite common.
>
> I have tested this with my Intel NUC7i5BNK and with the two working
> USB-C to HDMI adapters that I have found:
>
> a Samsung EE-PW700 adapter and a Kramer ADC-U31C/HF adapter (I think that's
> the model, I need to confirm this).
>
> As usual the specifications of these adapters never, ever tell you whether
> this is supported or not :-( It's trial and error to find one that works.
> In
> fact, of the 10 USB-C to HDMI adapters I tested 5 didn't support CEC
> tunneling
> at all, and of the remaining 5 only two had the CEC pin hooked up and so
> actually worked.
>
> BTW, all adapters that supported CEC tunneling used the Parade PS176 chip.
>
> Output of cec-ctl -S (discovers the CEC topology):
>
> $ cec-ctl -S
> Driver Info:
> Driver Name: i915
> Adapter Name   : DPDDC-C
> Capabilities   : 0x007e
> Logical Addresses
> Transmit
> Passthrough
> Remote Control Support
> Monitor All
> Driver version : 4.12.0
> Available Logical Addresses: 4
> Physical Address   : 3.0.0.0
> Logical Address Mask   : 0x0010
> CEC Version: 2.0
> Vendor ID  : 0x000c03 (HDMI)
> OSD Name   : 'Playback'
> Logical Addresses  : 1 (Allow RC Passthrough)
>
>   Logical Address  : 4 (Playback Device 1)
> Primary Device Type: Playback
> Logical Address Type   : Playback
> All Device Types   : Playback
> RC TV Profile  : None
> Device Features:
> None
>
> System Information for device 0 (TV) from device 4 (Playback
> Device 1):
> CEC Version: 1.4
> Physical Address   : 0.0.0.0
> Primary Device Type: TV
> Vendor ID  : 0xf0 (Samsung)
> OSD Name   : TV
> Menu Language  : eng
> Power Status   : On
>
> Topology:
>
> 0.0.0.0: TV
> 3.0.0.0: Playback Device 1
>
> Regards,
>
> Hans
>
> Clint Taylor (1):
>   drm/cec: Add CEC over Aux register definitions
>
> Hans Verkuil (6):
> 

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[Sean Paul]

On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
> The system would crash when trying to alloc zero sized gem buffer:
> [6.712435] Unable to handle kernel NULL pointer dereference at virtual 
> address 0010 <--ZERO_SIZE_PTR
> ...
> [6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec

It's unfortunate that you didn't include the entire stack trace. From code
inspection, it seems like the 0 size comes from the fb_probe path? Is there
somewhere in the helpers that you could check the mode is sane so all drivers
can benefit?

Sean

> 
> Signed-off-by: Jeffy Chen 
> ---
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index df9e570..8917922 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -315,6 +315,11 @@ struct rockchip_gem_object *
>   struct drm_gem_object *obj;
>   int ret;
>  
> + if (!size) {
> + DRM_ERROR("gem buffer size is zero\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
>   size = round_up(size, PAGE_SIZE);
>  
>   rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
> -- 
> 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: [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX

[Hans Verkuil]

On 05/25/2017 05:30 PM, Mike Lothian wrote:
> Hi
> 
> Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C 
> connector and no displayport 
> 
> Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working 
> based on your testing?
> 
> I've been putting off buying one until I knew 4K@60Hz would work, CEC would 
> be nice to have too

We have done a lot of testing of USB-C to HDMI adapters and many are awful.
Admittedly, we have a special requirement that the adapter shouldn't enable 
HDCP if
the sink doesn't support HDCP. For whatever reason many of these adapters 
enable HDCP
regardless, making them useless for video conferencing where you are not 
allowed to
share HDCP encrypted video. Besides that issue many also have bad signal 
integrity
or the voltage of the 5V pin is below the allowed minimum voltage.

The best is the Club 3D CAC-1504, but that is one that doesn't hook up the
CEC pin :-( That's a shame since this one was fully within the HDMI 
specifications.

If you want CEC, then the Samsung EE-PW700 is best.

BTW, the Kramer adapter I mentioned below is indeed the ADC-U31C/HF model.

There are some more adapters that I can test next week, and I'll see if I can 
also
test a bunch of (mini-)DP to HDMI adapters.

Regards,

Hans

> 
> Thanks
> 
> Mike
> 
> On Thu, 25 May 2017 at 16:06 Hans Verkuil  > wrote:
> 
> From: Hans Verkuil  >
> 
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> protocol.
> 
> This patch series is based on v4.12-rc2.
> 
> The first four patches add support for a new CEC capability which is
> needed for these devices and for two helper functions.
> 
> Then the DP CEC registers are added using Clint's patch.
> 
> The core CEC tunneling support is added to drm_dp_cec.c.
> 
> And finally this is hooked up in the i915 driver.
> 
> Ideally the cec driver is created and destroyed whenever the DP-to-HDMI
> adapter is connected/disconnected, but I have not been a able to find
> a way to distinguish between connecting/disconnecting the HDMI cable
> and connecting/disconnecting the actual DP-to-HDMI adapter.
> 
> My current approach is to check the CEC tunneling support whenever a new
> display is connected:
> 
> - if CEC tunneling is supported, but no CEC adapter exists, then create 
> one.
> - if CEC tunneling is not supported, then unregister the CEC adapter if 
> one
>   was created earlier.
> - if CEC tunneling is supported and the capabilities are identical to the
>   existing CEC adapter, then leave it be.
> - if CEC tunneling is supported and the capabilities are different to the
>   existing CEC adapter, then unregister that CEC adapter and register a
>   new one.
> 
> This works well, but it would be much nicer if I would just know when the
> DP adapter is disconnected as opposed to when the HDMI cable is 
> disconnected
> from the adapter. Suggestions are welcome.
> 
> The other remaining problem is that there are DP/USB-C to HDMI adapters 
> that
> support CEC tunneling in the chipset, but where the CEC pin is simply 
> never
> hooked up. From the point of view of the driver CEC is supported, but 
> you'll
> never see any other devices.
> 
> I am considering sending a CEC POLL message to logical address 0 (the TV)
> to detect if the CEC pin is connected, but this is not 100% guaranteed to
> work. This can be put under a kernel config option, though.
> 
> I think I need to do something for this since of the 5 USB-C to HDMI
> adapters I've tested that set the CEC tunneling capability, only 2 have
> the CEC pin hooked up. So this seems to be quite common.
> 
> I have tested this with my Intel NUC7i5BNK and with the two working
> USB-C to HDMI adapters that I have found:
> 
> a Samsung EE-PW700 adapter and a Kramer ADC-U31C/HF adapter (I think 
> that's
> the model, I need to confirm this).
> 
> As usual the specifications of these adapters never, ever tell you whether
> this is supported or not :-( It's trial and error to find one that works. 
> In
> fact, of the 10 USB-C to HDMI adapters I tested 5 didn't support CEC 
> tunneling
> at all, and of the remaining 5 only two had the CEC pin hooked up and so
> actually worked.
> 
> BTW, all adapters that supported CEC tunneling used the Parade PS176 chip.
> 
> Output of cec-ctl -S (discovers the CEC topology):
> 
> $ cec-ctl -S
> Driver Info:
> Driver Name: i915
> Adapter Name   : DPDDC-C
> Capabilities   : 0x007e
> Logical Addresses
> Transmit
> Passthrough
> Remote Control Support
> Monitor All
> Driver version : 

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

[Christian König]

Am 25.05.2017 um 10:47 schrieb Chris Wilson:

On Wed, May 24, 2017 at 05:06:12PM +1000, Dave Airlie wrote:

From: Dave Airlie 

This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.

v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.

Signed-off-by: Dave Airlie 
---
  drivers/gpu/drm/drm_internal.h |   2 +
  drivers/gpu/drm/drm_ioctl.c|   2 +
  drivers/gpu/drm/drm_syncobj.c  | 164 +
  include/uapi/drm/drm.h |  14 
  4 files changed, 182 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 3fdef2c..53e3f6b 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
  int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e5681..385ce74 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
  };
  
  #define DRM_CORE_IOCTL_COUNT	ARRAY_SIZE( drm_ioctls )

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index b611480..8b87594 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
  /*
   * Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
   *
   * Permission is hereby granted, free of charge, to any person obtaining a
   * copy of this software and associated documentation files (the "Software"),
@@ -31,6 +33,9 @@
   * that contain an optional fence. The fence can be updated with a new
   * fence, or be NULL.
   *
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
   * syncobj's can be export to fd's and back, these fd's are opaque and
   * have no other use case, except passing the syncobj between processes.
   *
@@ -375,3 +380,162 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
&args->handle);
  }
+
+
+/**
+ * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute value
+ *
+ * @timeout_ns: timeout in ns
+ *
+ * Calculate the timeout in jiffies from an absolute timeout in ns.
+ */
+unsigned long drm_timeout_abs_to_jiffies(uint64_t timeout_ns)

Not in any header or otherwise exported, so static?


That function should be exported and the version we have in amdgpu 
replaced by using this instead.


But feel free to make it static for now, I can take care of the cleanup 
later on.


Christian.




+{
+   unsigned long timeout_jiffies;
+   ktime_t timeout;
+
+   /* clamp timeout if it's to large */
+   if (((int64_t)timeout_ns) < 0)
+   return MAX_SCHEDULE_TIMEOUT;
+
+   timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
+   if (ktime_to_ns(timeout) < 0)
+   return 0;
+
+   timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
+   /*  clamp timeout to avoid unsigned-> signed overflow */
+   if (timeout_jiffies > MAX_SCHEDULE_TIMEOUT )
+   return MAX_SCHEDULE_TIMEOUT - 1;

This about avoiding the conversion into an infinite timeout, right?
I think the comment is misleading (certainly doesn't explain
MAX_SCHEDULE_TIMEOUT-1) and the test should be >= MAX_SCHEDULE_TIMEOUT.


+
+   return timeout_jiffies;

Timeouts tend to use timeout_jiffies + 1 to avoid the timer interrupt
screwing up the calculation, or just generally returning a fraction too
early.


+}
+
+static int drm_syncobj_wait_all_fences(struct drm_device *dev,
+  struct drm_file *file_private,
+  struct drm_syncobj_wait *wait,
+  uint32_t *handles)
+{
+   uint32_t i;
+   int ret;
+   unsigned long timeout = drm_timeout_abs_to_jiffies(wait->timeout_ns);

Also note that this doesn't handle timeout = 0 very gracefully with
multiple fences. (dma_fence_wait_timeout will convert that on return to
1). Hmm, by using an absolute timeout

[Bug 101189] Latest git fails to compile with radeon

[bugzilla-daemon]

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

Bug ID: 101189
   Summary: Latest git fails to compile with radeon
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: comeon@getbackinthe.kitchen
QA Contact: dri-devel@lists.freedesktop.org

It seems that commit de9dd4f9f1bb5984c554d0acf7d2592951ecc53f introduced a bug
in which you were not able to compile radeon drivers. The latest git currently
fails to build with:

/var/tmp/portage/media-libs/mesa-/work/mesa-/src/amd/common/ac_gpu_info.h:31:20:
fatal error: amdgpu.h: No such file or directory

I'm building mesa- on Gentoo. My use flags are: 
USE="classic d3d9 dri3 egl gallium gbm gles2 llvm nptl opencl pax_kernel pic
vaapi vdpau wayland xa -bindist -debug -gles1 -openmax -osmesa (-selinux)
-unwind% -valgrind -vulkan -xvmc" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="i965
intel r600 radeon (-freedreno) -i915 -imx -nouveau -r100 -r200 -r300 -radeonsi
(-vc4) (-vivante) -vmware"

-- 
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 101190] building gallium/R600 fails due to missing amdgpu.h

[bugzilla-daemon]

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

Bug ID: 101190
   Summary: building gallium/R600 fails due to missing amdgpu.h
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: aceli...@atlas.sk
QA Contact: dri-devel@lists.freedesktop.org

Since some days I can't compile Mesa git due to the following error:

 CC   common/common_libamd_common_la-ac_gpu_info.lo
In file included from common/ac_gpu_info.c:26:0:
common/ac_gpu_info.h:31:20: fatal error: amdgpu.h: No such file or directory
compilation terminated.
make[4]: *** [Makefile:936: common/common_libamd_common_la-ac_gpu_info.lo]
Error 1
make[4]: Leaving directory 'mesa-git/src/amd'
make[3]: *** [Makefile:738: all] Error 2
make[3]: Leaving directory 'mesa-git/src/amd'
make[2]: *** [Makefile:850: all-recursive] Error 1
make[2]: Leaving directory 'mesa-git/src'
make[1]: *** [Makefile:641: all] Error 2
make[1]: Leaving directory 'mesa-git/src'
make: *** [Makefile:641: all-recursive] Error 1

Build was working fine some 2 weeks ago.

This is strange as I do not want to compile AMDGPU driver, I am compiling r600
(for a rv710 card). I have selected these drivers:
--with-dri-drivers="" --with-gallium-drivers="r600,swrast"

Even if compiling r600 needed amdgpu.h, I do have that in
/usr/include/libdrm/amdgpu.h . So it may be just the including does not work
right.

-- 
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 10/13] drm/msm: Support multiple ringbuffers

[Jordan Crouse]

On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote:
> -#define rbmemptr(adreno_gpu, member)  \
> +#define _sizeof(member) \
> + sizeof(((struct adreno_rbmemptrs *) 0)->member[0])
> +
> +#define _base(adreno_gpu, member)  \
>   ((adreno_gpu)->memptrs_iova + offsetof(struct adreno_rbmemptrs, member))
>  
> +#define rbmemptr(adreno_gpu, index, member) \
> + (_base((adreno_gpu), member) + ((index) * _sizeof(member)))
> +
>  struct adreno_rbmemptrs {
> - volatile uint32_t rptr;
> - volatile uint32_t fence;
> + volatile uint32_t rptr[MSM_GPU_MAX_RINGS];
> + volatile uint32_t fence[MSM_GPU_MAX_RINGS];
>  };

I'm looking for opinions on moving this to a per-ring buffer object. It would be
a lot simpler to understand but it would cost us a page per ring as opposed
to the 1 page we use now.

Looking ahead we are going to want to start using trace messages in conjunction
with tools like systrace:

(https://developer.android.com/studio/profile/systrace-commandline.html)

This will involve tracking the always on counter value at start/retire for each
outstanding submit on each ring. I *think* we could fit those values into the
existing rmemptrs buffer if we wanted to but I can't imagine these would be the
last runtime statistics we would gather.

I guess I'm leaning toward the per-ring solution but I'll listen to anybody
argue that the memory usage isn't worth it.

Jordan

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

[pull] radeon and amdgpu drm-fixes-4.12

[Alex Deucher]

Hi Dave,

A bunch of bug fixes:
- Fix display flickering on some chips at high refresh rates
- suspend/resume fix
- hotplug fix
- a couple of segfault fixes for certain cases

The following changes since commit d51aff16e821a755c242e14168f5d4601199eafd:

  Merge branch 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld into 
drm-fixes (2017-05-20 06:00:49 +1000)

are available in the git repository at:

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

for you to fetch changes up to b62ce397675502325d4282924bf70cfb6a005c3a:

  drm/amdgpu: fix null point error when rmmod amdgpu. (2017-05-25 12:53:25 
-0400)


Alex Deucher (4):
  drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)
  drm/radeon/ci: disable mclk switching for high refresh rates (v2)
  drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)
  drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

Christian König (1):
  drm/amdgpu: fix fundamental suspend/resume issue

Chunming Zhou (1):
  drm/amdgpu: fix NULL pointer panic of emit_gds_switch

Dan Carpenter (1):
  drm/amd/powerplay: fix a signedness bugs

Lyude (1):
  drm/radeon: Unbreak HPD handling for r600+

Rex Zhu (1):
  drm/amdgpu: fix null point error when rmmod amdgpu.

 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  7 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 24 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  6 
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 16 ++-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 32 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  2 +-
 drivers/gpu/drm/radeon/ci_dpm.c|  6 
 drivers/gpu/drm/radeon/cik.c   |  4 +--
 drivers/gpu/drm/radeon/evergreen.c |  4 +--
 drivers/gpu/drm/radeon/r600.c  |  2 +-
 drivers/gpu/drm/radeon/si.c|  4 +--
 15 files changed, 85 insertions(+), 68 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 10/13] drm/msm: Support multiple ringbuffers

[Rob Clark]

On Thu, May 25, 2017 at 1:25 PM, Jordan Crouse  wrote:
> On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote:
>> -#define rbmemptr(adreno_gpu, member)  \
>> +#define _sizeof(member) \
>> + sizeof(((struct adreno_rbmemptrs *) 0)->member[0])
>> +
>> +#define _base(adreno_gpu, member)  \
>>   ((adreno_gpu)->memptrs_iova + offsetof(struct adreno_rbmemptrs, 
>> member))
>>
>> +#define rbmemptr(adreno_gpu, index, member) \
>> + (_base((adreno_gpu), member) + ((index) * _sizeof(member)))
>> +
>>  struct adreno_rbmemptrs {
>> - volatile uint32_t rptr;
>> - volatile uint32_t fence;
>> + volatile uint32_t rptr[MSM_GPU_MAX_RINGS];
>> + volatile uint32_t fence[MSM_GPU_MAX_RINGS];
>>  };
>
> I'm looking for opinions on moving this to a per-ring buffer object. It would 
> be
> a lot simpler to understand but it would cost us a page per ring as opposed
> to the 1 page we use now.

Well, I guess sub-allocation is an option.. we don't *have* to do a
page-per memptrs struct just to have separate struct per pring.

Just turn the single rbmemptrs allocation into an memptrs[MAX_RINGS]..

BR,
-R

> Looking ahead we are going to want to start using trace messages in 
> conjunction
> with tools like systrace:
>
> (https://developer.android.com/studio/profile/systrace-commandline.html)
>
> This will involve tracking the always on counter value at start/retire for 
> each
> outstanding submit on each ring. I *think* we could fit those values into the
> existing rmemptrs buffer if we wanted to but I can't imagine these would be 
> the
> last runtime statistics we would gather.
>
> I guess I'm leaning toward the per-ring solution but I'll listen to anybody
> argue that the memory usage isn't worth it.
>
> Jordan
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

[Sean Paul]

Hi Dave,
A handful of fixes for you this week, nothing overly complex. The pull is noisy
because it includes -rc2.

Due to some process miscommunications, Lukas fast-forwarded -fixes and merged
the radeon patch without R-b. Patrik also merged the gma500 patch directly
without review. Daniel has added safeguards in dim to prevent this from 
happening
in the future. I have run the branch through my usual testing as well as 
reviewed
the patches to ensure everything is above-board.


drm-misc-fixes-2017-05-25:
Core Changes:
- Don't drop vblank reference more than once in cases of ww retry (Daniel)

Driver Changes:
- radeon: Fix oops during radeon probe trying to reference wrong device (Lukas)
- qxl: Avoid sleeping while in atomic context on cursor update (Gabriel)
- gma500: Use VBT mode instead of pre-programmed mode for LVDS (Patrik)

Cc: Lukas Wunner 
Cc: Gabriel Krisman Bertazi 
Cc: Daniel Vetter 
Cc: Patrik Jakobsson 

Cheers, Sean


The following changes since commit d51aff16e821a755c242e14168f5d4601199eafd:

  Merge branch 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld into 
drm-fixes (2017-05-20 06:00:49 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-05-25

for you to fetch changes up to 82bc9a42cf854fdf63155759c0aa790bd1f361b0:

  drm/gma500/psb: Actually use VBT mode when it is found (2017-05-23 22:01:07 
+0200)


Core Changes:
- Don't drop vblank reference more than once in cases of ww retry (Daniel)

Driver Changes:
- radeon: Fix oops during radeon probe trying to reference wrong device (Lukas)
- qxl: Avoid sleeping while in atomic context on cursor update (Gabriel)
- gma500: Use VBT mode instead of pre-programmed mode for LVDS (Patrik)

Cc: Lukas Wunner 
Cc: Gabriel Krisman Bertazi 
Cc: Daniel Vetter 
Cc: Patrik Jakobsson 


Adam Ford (1):
  ARM: dts: LogicPD Torpedo: Fix camera pin mux

Al Viro (2):
  fix unsafe_put_user()
  osf_wait4(): fix infoleak

Alan Stern (2):
  USB: ene_usb6250: fix DMA to the stack
  USB: xhci: fix lock-inversion problem

Alexandre Belloni (2):
  watchdog: sama5d4: fix WDDIS handling
  watchdog: sama5d4: fix race condition

Andreas Kemnade (1):
  ARM: dts: gta04: fix polarity of clocks for mcbsp4

Andrey Korolyov (1):
  USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs

Anthony Mallet (1):
  USB: serial: ftdi_sio: fix setting latency for unprivileged users

Anton Bondarenko (1):
  usb: core: fix potential memory leak in error path during hcd creation

Ard Biesheuvel (1):
  i2c: designware: don't infer timings described by ACPI from clock rate

Arnd Bergmann (14):
  ARM: omap2+: make omap4_get_cpu1_ns_pa_addr declaration usable
  Merge tag 'v4.11-next-fixes' of https://github.com/mbgg/linux-mediatek 
into fixes
  Merge tag 'renesas-fixes-for-v4.12' of 
https://git.kernel.org/.../horms/renesas into fixes
  Merge tag 'mvebu-dt64-4.12-3' of git://git.infradead.org/linux-mvebu into 
fixes
  Merge tag 'mvebu-arm64-4.12-1' of git://git.infradead.org/linux-mvebu 
into fixes
  Merge branch 'tee/initial-merge' into fixes
  tee: add ARM_SMCCC dependency
  soc: imx: add PM dependency for IMX7_PM_DOMAINS
  staging: fsl-dpaa2/eth: add ETHERNET dependency
  iommu/mediatek: Include linux/dma-mapping.h
  watchdog: orion: fix compile-test dependencies
  ARM: remove duplicate 'const' annotations'
  firmware: ti_sci: fix strncat length check
  arm64: dts: rockchip: fix include reference

Bart Van Assche (1):
  scsi: scsi_lib: Add #include 

Baruch Siach (4):
  ARM: dts: bcm2835: fix uart0 pinctrl node names
  ARM: dts: bcm2835: fix i2c0 pins
  ARM: dts: bcm2835: fix uart0/uart1 pins
  ARM: dts: bcm2835: add index to the ethernet alias

Bjørn Mork (1):
  USB: serial: qcserial: add more Lenovo EM74xx device IDs

Bogdan Mirea (1):
  usb: gadget: gserial: check if console kthread exists

Chris Brandt (2):
  usb: r8a66597-hcd: decrease timeout
  usb: r8a66597-hcd: select a different endpoint on timeout

Christoffer Dall (2):
  KVM: arm/arm64: Fix bug when registering redist iodevs
  KVM: arm/arm64: Hold slots_lock when unregistering kvm io bus devices

Christoph Hellwig (1):
  scsi: MAINTAINERS: update OSD entries

Christophe JAILLET (1):
  firmware: Google VPD: Fix memory allocation error handling

Colin Ian King (2):
  scsi: lpfc: ensure els_wq is being checked before destroying it
  scsi: pmcraid: remove redundant check to see if request_size is less than 
zero

Dan Carpenter (4):
  scsi: lpfc: double lock typo in lpfc_ns_rsp()
  scsi: qedf: Cleanup the type of io_log->op
  kvm: nVMX: off by one in vmx_write_pml_buffer()
  KVM: Silence underflow warning in avic_get_physical_id_entry()

Dan Williams (2):
 

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #38 from intermedi...@hotmail.com  ---
[   12.980953] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device
[   12.982746] [drm:.gfx_v6_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: ib test
failed (scratch(0x2140)=0xCAFEDEAD)
[   12.982890] [drm:.amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed
testing IB on GFX ring (-22).
[   12.982999] [drm:.amdgpu_device_init [amdgpu]] *ERROR* ib ring test failed
(-22).
[   13.296975] [drm] Initialized amdgpu 3.10.0 20150101 for :01:00.0 on
minor 0
[   34.022373] [drm] : dce_v6_0_afmt_setmode no impl 
[  569.726065] [drm] IH: HPD1
[  570.299355] [drm] IH: HPD1


Qoriq PPC64 Fedora Server 25
:-( :-(

-- 
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/6] drm/i915: update cursors asynchronously through atomic

[Gustavo Padovan]

2017-05-25 Chris Wilson :

> On Thu, May 25, 2017 at 01:41:33AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Add support to async updates of cursors by using the new atomic
> > interface for that. Basically what this commit does is do what
> > intel_legacy_cursor_update() did but through atomic.
> > 
> > v3:
> > - set correct vma to new state for cleanup
> > - move size checks back to drivers (Ville Syrjälä)
> > 
> > v2:
> > - move fb setting to core and use new state (Eric Anholt)
> 
> Please do cc this series to intel-gfx@ so that our CI can pick up and
> check that the cursors do remain async.

Indeed, I'll resend the whole series adding the cc.

Gustavo

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

[PATCH RESEND 0/6] drm/atomic: add async plane update

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

Resending to include intel-gfx@ and get the patches picked up by CI.

New version of the patches after the comments from Archit. Full details
and the previous discussion can be found here:

https://www.spinics.net/lists/dri-devel/msg141337.html

I'm not including the uAPI patch here, because we don't have any userspace
for it yet.

Please review. Thanks!

Gustavo

--
Gustavo Padovan (6):
  drm/atomic: initial support for asynchronous plane update
  drm/i915: update cursors asynchronously through atomic
  drm/i915: remove intel_cursor_plane_funcs
  drm/msm: update cursors asynchronously through atomic
  drm/msm: remove mdp5_cursor_plane_funcs
  drm/vc4: update cursors asynchronously through atomic

 drivers/gpu/drm/drm_atomic.c  |  65 +++
 drivers/gpu/drm/drm_atomic_helper.c   |  35 ++
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +
 drivers/gpu/drm/i915/intel_display.c  | 160 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 175 +++---
 drivers/gpu/drm/msm/msm_atomic.c  |   6 +
 drivers/gpu/drm/vc4/vc4_plane.c   |  99 ++---
 include/drm/drm_atomic.h  |   2 +
 include/drm/drm_atomic_helper.h   |   2 +
 include/drm/drm_modeset_helper_vtables.h  |  48 
 10 files changed, 355 insertions(+), 310 deletions(-)

-- 
2.9.4

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

[PATCH RESEND 2/6] drm/i915: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.

v3:
- set correct vma to new state for cleanup
- move size checks back to drivers (Ville Syrjälä)

v2:
- move fb setting to core and use new state (Eric Anholt)

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +++
 drivers/gpu/drm/i915/intel_display.c  | 149 +-
 2 files changed, 97 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index cfb4729..974c91f 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -246,11 +246,84 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int intel_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_crtc_state *crtc_state = crtc->state;
+
+   if (plane->type != DRM_PLANE_TYPE_CURSOR)
+   return -EINVAL;
+
+   /*
+* When crtc is inactive or there is a modeset pending,
+* wait for it to complete in the slowpath
+*/
+   if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
+   return -EINVAL;
+
+   /*
+* If any parameters change that may affect watermarks,
+* take the slowpath. Only changing fb or position should be
+* in the fastpath.
+*/
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb != !state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void intel_plane_atomic_async_update(struct drm_plane *plane,
+   struct drm_plane_state *new_state)
+{
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_framebuffer *old_fb;
+   struct i915_vma *old_vma;
+
+   old_vma = to_intel_plane_state(plane->state)->vma;
+   old_fb = plane->state->fb;
+
+   i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
+ intel_plane->frontbuffer_bit);
+
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+   plane->state->fb = new_state->fb;
+   *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
+
+   to_intel_plane_state(new_state)->vma = old_vma;
+   new_state->fb = old_fb;
+
+   if (plane->state->visible) {
+   trace_intel_update_plane(plane, to_intel_crtc(crtc));
+   intel_plane->update_plane(plane,
+ to_intel_crtc_state(crtc->state),
+ to_intel_plane_state(plane->state));
+   } else {
+   trace_intel_disable_plane(plane, to_intel_crtc(crtc));
+   intel_plane->disable_plane(plane, crtc);
+   }
+
+   mutex_lock(&plane->dev->struct_mutex);
+   intel_cleanup_plane_fb(plane, new_state);
+   mutex_unlock(&plane->dev->struct_mutex);
+}
+
 const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
.atomic_check = intel_plane_atomic_check,
.atomic_update = intel_plane_atomic_update,
+   .atomic_async_check = intel_plane_atomic_async_check,
+   .atomic_async_update = intel_plane_atomic_async_update,
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 207f144..7f4c8d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13010,6 +13010,26 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
 
+   /*
+* The atomic async update fast path takes care
+* of avoiding the vblank waits for simple cursor
+* movement and flips. For cursor on/off and size changes,
+* we want to perform the vblank waits so that watermark
+* updates happen during the correct frames. Gen9+ have
+* double buffered watermarks and so shouldn't need this.
+*/
+   if (state->async_update) {
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (

[PATCH RESEND 5/6] drm/msm: remove mdp5_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 07106c1..794ca07 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -247,19 +247,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
 };
 
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = mdp5_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_set_property = mdp5_plane_atomic_set_property,
-   .atomic_get_property = mdp5_plane_atomic_get_property,
-   .reset = mdp5_plane_reset,
-   .atomic_duplicate_state = mdp5_plane_duplicate_state,
-   .atomic_destroy_state = mdp5_plane_destroy_state,
-   .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
 static int mdp5_plane_prepare_fb(struct drm_plane *plane,
 struct drm_plane_state *new_state)
 {
@@ -,16 +1098,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
 
spin_lock_init(&mdp5_plane->pipe_lock);
 
-   if (type == DRM_PLANE_TYPE_CURSOR)
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   &mdp5_cursor_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
-   else
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   &mdp5_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
+   ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_plane_funcs,
+  mdp5_plane->formats,
+  mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
 
-- 
2.9.4

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

[PATCH RESEND 3/6] drm/i915: remove intel_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7f4c8d3..ee75165 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13418,17 +13418,6 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
 };
 
-static const struct drm_plane_funcs intel_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = intel_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_get_property = intel_plane_atomic_get_property,
-   .atomic_set_property = intel_plane_atomic_set_property,
-   .atomic_duplicate_state = intel_plane_duplicate_state,
-   .atomic_destroy_state = intel_plane_destroy_state,
-};
-
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13675,7 +13664,7 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
cursor->disable_plane = intel_disable_cursor_plane;
 
ret = drm_universal_plane_init(&dev_priv->drm, &cursor->base,
-  0, &intel_cursor_plane_funcs,
+  0, &intel_plane_funcs,
   intel_cursor_formats,
   ARRAY_SIZE(intel_cursor_formats),
   DRM_PLANE_TYPE_CURSOR,
-- 
2.9.4

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

[PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update

[Gustavo Padovan]

From: Gustavo Padovan 

In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.

This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.

For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.

v4:
- fix state->crtc NULL check (Archit Taneja)

v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)

v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)

Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_atomic.c | 65 
 drivers/gpu/drm/drm_atomic_helper.c  | 35 +
 include/drm/drm_atomic.h |  2 +
 include/drm/drm_atomic_helper.h  |  2 +
 include/drm/drm_modeset_helper_vtables.h | 48 +++
 5 files changed, 152 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index be62774..2a0c297 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
+static bool drm_atomic_async_check(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_commit *commit;
+   struct drm_plane *__plane, *plane = NULL;
+   struct drm_plane_state *__plane_state, *plane_state = NULL;
+   const struct drm_plane_helper_funcs *funcs;
+   int i, j, n_planes = 0;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+   n_planes++;
+   plane = __plane;
+   plane_state = __plane_state;
+   }
+
+   /* FIXME: we support only single plane updates for now */
+   if (!plane || n_planes != 1)
+   return false;
+
+   if (!plane_state->crtc)
+   return false;
+
+   funcs = plane->helper_private;
+   if (!funcs->atomic_async_update)
+   return false;
+
+   if (plane_state->fence)
+   return false;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (plane->crtc != crtc)
+   continue;
+
+   spin_lock(&crtc->commit_lock);
+   commit = list_first_entry_or_null(&crtc->commit_list,
+ struct drm_crtc_commit,
+ commit_entry);
+   if (!commit) {
+   spin_unlock(&crtc->commit_lock);
+   continue;
+   }
+   spin_unlock(&crtc->commit_lock);
+
+   if (!crtc->state->state)
+   continue;
+
+   for_each_plane_in_state(crtc->state->state, __plane,
+   __plane_state, j) {
+   if (__plane == plane)
+   return false;
+   }
+   }
+
+   return !funcs->atomic_async_check(plane, plane_state);
+}
+
 static void drm_atomic_crtc_print_state(struct drm_printer *p,
const struct drm_crtc_state *state)
 {
@@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
 
+   if (state->legacy_cursor_update)
+   state->async_update = drm_atomic_async_check(state);
+
return ret;
 }
 EXPORT_SYMBOL(drm_atomic_check_only);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 

[PATCH RESEND 4/6] drm/msm: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.

v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
 drivers/gpu/drm/msm/msm_atomic.c  |   6 ++
 2 files changed, 69 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index a38c5fe..07106c1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
 
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
-   struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   int crtc_x, int crtc_y,
-   unsigned int crtc_w, unsigned int crtc_h,
-   uint32_t src_x, uint32_t src_y,
-   uint32_t src_w, uint32_t src_h,
-   struct drm_modeset_acquire_ctx *ctx);
-
 static struct mdp5_kms *get_kms(struct drm_plane *plane)
 {
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
 };
 
 static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = mdp5_update_cursor_plane_legacy,
+   .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+   state->crtc);
+   if (WARN_ON(!crtc_state))
+   return -EINVAL;
+
+   if (!crtc_state->active)
+   return -EINVAL;
+
+   mdp5_state = to_mdp5_plane_state(state);
+
+   /* don't use fast path if we don't have a hwpipe allocated yet */
+   if (!mdp5_state->hwpipe)
+   return -EINVAL;
+
+   /* only allow changing of position(crtc x/y or src x/y) in fast path */
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb ||
+   plane->state->fb != state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+  struct drm_plane_state *new_state)
+{
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+
+   if (plane_enabled(new_state)) {
+   struct mdp5_ctl *ctl;
+   struct mdp5_pipeline *pipeline =
+   mdp5_crtc_get_pipeline(plane->crtc);
+   int ret;
+
+   ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+   &new_state->src, &new_state->dst);
+   WARN_ON(ret < 0);
+
+   ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+   mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+   }
+
+   *to_mdp5_plane_state(plane->state) =
+   *to_mdp5_plane_state(new_state);
+}
+
 static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+   .atomic_async_check = mdp5_plane_atomic_async_check,
+   .atomic_async_update = mdp5_plane_atomic_async_update,
 };
 
 static void set_scanout_locked(struct mdp5_kms *mdp5_kms,
@@ -997,84 +1050,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
return ret;
 }
 
-static int

[PATCH RESEND 6/6] drm/vc4: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Tested-by: Robert Foss 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 99 +++--
 1 file changed, 35 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index d34cd53..05e9f5f 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -735,70 +735,38 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
 }
 
-static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
-   .atomic_check = vc4_plane_atomic_check,
-   .atomic_update = vc4_plane_atomic_update,
-};
-
-static void vc4_plane_destroy(struct drm_plane *plane)
-{
-   drm_plane_helper_disable(plane);
-   drm_plane_cleanup(plane);
-}
-
-/* Implements immediate (non-vblank-synced) updates of the cursor
- * position, or falls back to the atomic helper otherwise.
- */
-static int
-vc4_update_plane(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx)
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
 {
-   struct drm_plane_state *plane_state;
-   struct vc4_plane_state *vc4_state;
-
-   if (plane != crtc->cursor)
-   goto out;
-
-   plane_state = plane->state;
-   vc4_state = to_vc4_plane_state(plane_state);
+   if (plane != state->crtc->cursor)
+   return -EINVAL;
 
-   if (!plane_state)
-   goto out;
+   if (!plane->state)
+   return -EINVAL;
 
/* No configuring new scaling in the fast path. */
-   if (crtc_w != plane_state->crtc_w ||
-   crtc_h != plane_state->crtc_h ||
-   src_w != plane_state->src_w ||
-   src_h != plane_state->src_h) {
-   goto out;
+   if (state->crtc_w != plane->state->crtc_w ||
+   state->crtc_h != plane->state->crtc_h ||
+   state->src_w != plane->state->src_w ||
+   state->src_h != plane->state->src_h) {
+   return -EINVAL;
}
 
-   if (fb != plane_state->fb) {
-   drm_atomic_set_fb_for_plane(plane->state, fb);
-   vc4_plane_async_set_fb(plane, fb);
-   }
+   return 0;
+}
 
-   /* Set the cursor's position on the screen.  This is the
-* expected change from the drm_mode_cursor_universal()
-* helper.
-*/
-   plane_state->crtc_x = crtc_x;
-   plane_state->crtc_y = crtc_y;
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+   struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
 
-   /* Allow changing the start position within the cursor BO, if
-* that matters.
-*/
-   plane_state->src_x = src_x;
-   plane_state->src_y = src_y;
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
 
-   /* Update the display list based on the new crtc_x/y. */
-   vc4_plane_atomic_check(plane, plane_state);
+   if (plane->state->fb != new_state->fb)
+   vc4_plane_async_set_fb(plane, new_state->fb);
 
/* Note that we can't just call vc4_plane_write_dlist()
 * because that would smash the context data that the HVS is
@@ -810,20 +778,23 @@ vc4_update_plane(struct drm_plane *plane,
   &vc4_state->hw_dlist[vc4_state->pos2_offset]);
writel(vc4_state->dlist[vc4_state->ptr0_offset],
   &vc4_state->hw_dlist[vc4_state->ptr0_offset]);
+}
 
-   return 0;
+static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
+   .atomic_check = vc4_plane_atomic_check,
+   .atomic_update = vc4_plane_atomic_update,
+   .atomic_async_check = vc4_plane_atomic_async_check,
+   .atomic_async_update = vc4_plane_atomic_async_update,
+};
 
-out:
-   return drm_atomic_helper_update_plane(plane, crtc, fb,
- crtc_x, crtc_y,
- crtc_w, crtc_h,
- src_x, src_y,
-  

[PATCH v2] drm/exynos: dsi: Remove bridge node reference in removal

[Hoegeun Kwon]

Since bridge node is referenced during in the probe, it should be
released on removal.

Suggested-by: Andrzej Hajda 
Signed-off-by: Hoegeun Kwon 
---
Hi Inki,

This patch seems to have been forgotten... :)

Changes for V2:

- Checked for rebase 4.12-rc2

Best regards,
Hoegeun

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 698a824..a11b795 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1805,6 +1805,10 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 
 static int exynos_dsi_remove(struct platform_device *pdev)
 {
+   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
+
+   of_node_put(dsi->bridge_node);
+
pm_runtime_disable(&pdev->dev);
 
component_del(&pdev->dev, &exynos_dsi_component_ops);
-- 
1.9.1

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

Re: [PATCH v2] drm/exynos: dsi: Remove bridge node reference in removal

[Inki Dae]

2017년 05월 26일 10:02에 Hoegeun Kwon 이(가) 쓴 글:
> Since bridge node is referenced during in the probe, it should be
> released on removal.
> 
> Suggested-by: Andrzej Hajda 
> Signed-off-by: Hoegeun Kwon 
> ---
> Hi Inki,
> 
> This patch seems to have been forgotten... :)

Yeah, forgot this. Merged.

Thanks,
Inki Dae

> 
> Changes for V2:
> 
> - Checked for rebase 4.12-rc2
> 
> Best regards,
> Hoegeun
> 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 698a824..a11b795 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1805,6 +1805,10 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>  
>  static int exynos_dsi_remove(struct platform_device *pdev)
>  {
> + struct exynos_dsi *dsi = platform_get_drvdata(pdev);
> +
> + of_node_put(dsi->bridge_node);
> +
>   pm_runtime_disable(&pdev->dev);
>  
>   component_del(&pdev->dev, &exynos_dsi_component_ops);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 00/10] Introduce new mode validation callbacks

[Jose Abreu]

NOTE: In this version I just did a rebase onto today's drm-next and
added the tags we've collected plus the changelog plus the missing
maintainers that I forgot to cc in previous version :/

This series is a follow up from the discussion at [1]. We start by
introducing crtc->mode_valid(), encoder->mode_valid() and
bridge->mode_valid() callbacks which will be used in followup
patches and also by cleaning the documentation a little bit. This
patch is available at [2] and the series depends on it.

We proceed by introducing new helpers to call this new callbacks
at 1/10.

At 2/10 a helper function is introduced that calls all mode_valid()
from a set of bridges.

Next, at 3/10 we modify the connector probe helper so that only modes
which are supported by a given bridge+encoder+crtc combination are
probbed.

At 4/10 we call all the mode_valid() callbacks for a given pipeline,
except the connector->mode_valid one, so that the mode is validated.
This is done before calling mode_fixup().

Finally, from 5/10 to 10/10 we use the new callbacks in drivers that
can implement it.

[1] https://patchwork.kernel.org/patch/9702233/
[2] https://lists.freedesktop.org/archives/dri-devel/2017-May/141761.html

Jose Abreu (10):
  drm: Add drm_{crtc/encoder/connector}_mode_valid()
  drm: Introduce drm_bridge_mode_valid()
  drm: Use new mode_valid() helpers in connector probe helper
  drm: Use mode_valid() in atomic modeset
  drm: arcpgu: Use crtc->mode_valid() callback
  drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback
  drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback
  drm/arm: malidp: Use crtc->mode_valid() callback
  drm/atmel-hlcdc: Use crtc->mode_valid() callback
  drm: vc4: Use crtc->mode_valid() and encoder->mode_valid() callbacks

Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Laurent Pinchart 

 drivers/gpu/drm/arc/arcpgu_crtc.c  |  29 ---
 drivers/gpu/drm/arm/malidp_crtc.c  |  11 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   9 +--
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |  13 ++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  40 +++---
 drivers/gpu/drm/drm_atomic_helper.c|  76 +-
 drivers/gpu/drm/drm_bridge.c   |  33 
 drivers/gpu/drm/drm_crtc_helper_internal.h |  13 +++
 drivers/gpu/drm/drm_probe_helper.c | 105 -
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |   4 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.c  |   2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c|   2 +-
 drivers/gpu/drm/vc4/vc4_crtc.c |  13 ++-
 drivers/gpu/drm/vc4/vc4_dpi.c  |  13 ++-
 include/drm/bridge/dw_hdmi.h   |   2 +-
 include/drm/drm_bridge.h   |   2 +
 16 files changed, 280 insertions(+), 87 deletions(-)

-- 
1.9.1


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

[PATCH v5 07/10] drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback

[Jose Abreu]

Now that we have a callback to check if bridge supports a given mode
we can use it in Synopsys Designware HDMI bridge so that we restrict
the number of probbed modes to the ones we can actually display.

Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.

NOTE: Only compile tested
NOTE 2: I also had to change the pdata declaration of mode_valid
custom callback so that the passed modes are const. I also changed
in the platforms I found. Not even compiled it though.

Signed-off-by: Jose Abreu 
Acked-by: Neil Armstrong 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
Cc: Philipp Zabel 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Mark Yao 
Cc: Heiko Stuebner 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 40 +
 drivers/gpu/drm/imx/dw_hdmi-imx.c   |  4 +--
 drivers/gpu/drm/meson/meson_dw_hdmi.c   |  2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 include/drm/bridge/dw_hdmi.h|  2 +-
 5 files changed, 17 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 8737de8..038dc43 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1907,24 +1907,6 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return ret;
 }
 
-static enum drm_mode_status
-dw_hdmi_connector_mode_valid(struct drm_connector *connector,
-struct drm_display_mode *mode)
-{
-   struct dw_hdmi *hdmi = container_of(connector,
-  struct dw_hdmi, connector);
-   enum drm_mode_status mode_status = MODE_OK;
-
-   /* We don't support double-clocked modes */
-   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
-   return MODE_BAD;
-
-   if (hdmi->plat_data->mode_valid)
-   mode_status = hdmi->plat_data->mode_valid(connector, mode);
-
-   return mode_status;
-}
-
 static void dw_hdmi_connector_force(struct drm_connector *connector)
 {
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
@@ -1950,7 +1932,6 @@ static void dw_hdmi_connector_force(struct drm_connector 
*connector)
 
 static const struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs 
= {
.get_modes = dw_hdmi_connector_get_modes,
-   .mode_valid = dw_hdmi_connector_mode_valid,
.best_encoder = drm_atomic_helper_best_encoder,
 };
 
@@ -1973,18 +1954,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)
+static enum drm_mode_status dw_hdmi_bridge_mode_valid(struct drm_bridge 
*bridge,
+ const struct 
drm_display_mode *mode)
 {
struct dw_hdmi *hdmi = bridge->driver_private;
struct drm_connector *connector = &hdmi->connector;
-   enum drm_mode_status status;
+   enum drm_mode_status mode_status = MODE_OK;
 
-   status = dw_hdmi_connector_mode_valid(connector, mode);
-   if (status != MODE_OK)
-   return false;
-   return true;
+   /* We don't support double-clocked modes */
+   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+   return MODE_BAD;
+
+   if (hdmi->plat_data->mode_valid)
+   mode_status = hdmi->plat_data->mode_valid(connector, mode);
+
+   return mode_status;
 }
 
 static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
@@ -2028,7 +2012,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge 
*bridge)
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
-   .mode_fixup = dw_hdmi_bridge_mode_fixup,
+   .mode_valid = dw_hdmi_bridge_mode_valid,
 };
 
 static irqreturn_t dw_hdmi_i2c_irq(struct dw_hdmi *hdmi)
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index f039641..5f561c8 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -148,7 +148,7 @@ static int dw_hdmi_imx_atomic_check(struct drm_encoder 
*encoder,
 };
 
 static enum drm_mode_status imx6q_hdmi_mode_valid(struct drm_connector *con,
- struct drm_display_mode *mode)
+ const struct drm_display_mode 
*mode)
 {
if (mode->clock < 13500)
return MODE_CLOCK_LOW;
@@ -160,7 +160,7 @@ static enum drm_mode_status imx6q_hdmi_mode_valid(struct 
drm_connector *con,
 }
 
 static enum drm_mode_status imx6dl_hdmi_mode_valid(struct drm_connector *con,
-

[PATCH v5 04/10] drm: Use mode_valid() in atomic modeset

[Jose Abreu]

This patches makes use of the new mode_valid() callbacks introduced
previously to validate the full video pipeline when modesetting.

This calls the connector->mode_valid(), encoder->mode_valid(),
bridge->mode_valid() and crtc->mode_valid() so that we can
make sure that the mode will be accepted in every components.

Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Reviewed-by: Andrzej Hajda 
Cc: Carlos Palminha 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Laurent Pinchart 

Changes v1->v2:
- Removed call to connector->mode_valid (Ville, Daniel)
- Changed function name (Ville)
- Use for_each_new_connector_in_state (Ville)
- Do not validate if connector and mode didn't change (Ville)
- Use new helpers to call mode_valid

Signed-off-by: Jose Abreu 
---
 drivers/gpu/drm/drm_atomic_helper.c | 76 +++--
 1 file changed, 73 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 6426339..21afca4 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 
+#include "drm_crtc_helper_internal.h"
 #include "drm_crtc_internal.h"
 
 /**
@@ -452,6 +453,69 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
return 0;
 }
 
+static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
+   struct drm_encoder *encoder,
+   struct drm_crtc *crtc,
+   struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret;
+
+   ret = drm_encoder_mode_valid(encoder, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] mode_valid() failed\n",
+   encoder->base.id, encoder->name);
+   return ret;
+   }
+
+   ret = drm_bridge_mode_valid(encoder->bridge, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[BRIDGE] mode_valid() failed\n");
+   return ret;
+   }
+
+   ret = drm_crtc_mode_valid(crtc, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode_valid() failed\n",
+   crtc->base.id, crtc->name);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int
+mode_valid(struct drm_atomic_state *state)
+{
+   struct drm_connector_state *conn_state;
+   struct drm_connector *connector;
+   int i;
+
+   for_each_new_connector_in_state(state, connector, conn_state, i) {
+   struct drm_encoder *encoder = conn_state->best_encoder;
+   struct drm_crtc *crtc = conn_state->crtc;
+   struct drm_crtc_state *crtc_state;
+   enum drm_mode_status mode_status;
+   struct drm_display_mode *mode;
+
+   if (!crtc || !encoder)
+   continue;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   continue;
+   if (!crtc_state->mode_changed && 
!crtc_state->connectors_changed)
+   continue;
+
+   mode = &crtc_state->mode;
+
+   mode_status = mode_valid_path(connector, encoder, crtc, mode);
+   if (mode_status != MODE_OK)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /**
  * drm_atomic_helper_check_modeset - validate state object for modeset changes
  * @dev: DRM device
@@ -466,13 +530,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
  * 2. &drm_connector_helper_funcs.atomic_check to validate the connector state.
  * 3. If it's determined a modeset is needed then all connectors on the 
affected crtc
  *crtc are added and &drm_connector_helper_funcs.atomic_check is run on 
them.
- * 4. &drm_bridge_funcs.mode_fixup is called on all encoder bridges.
- * 5. &drm_encoder_helper_funcs.atomic_check is called to validate any encoder 
state.
+ * 4. &drm_encoder_helper_funcs.mode_valid, &drm_bridge_funcs.mode_valid and
+ *&drm_crtc_helper_funcs.mode_valid are called on the affected components.
+ * 5. &drm_bridge_funcs.mode_fixup is called on all encoder bridges.
+ * 6. &drm_encoder_helper_funcs.atomic_check is called to validate any encoder 
state.
  *This function is only called when the encoder will be part of a 
configured crtc,
  *it must not be used for implementing connector property validation.
  *If this function is NULL, &drm_atomic_encoder_helper_funcs.mode_fixup is 
called
  *instead.
- * 6. &drm_crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
with crtc constraints.
+ * 7. &drm_crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
with crtc constraints.
  *
  * &drm_

[PATCH v5 10/10] drm: vc4: Use crtc->mode_valid() and encoder->mode_valid() callbacks

[Jose Abreu]

Now that we have a callback to check if crtc and encoder supports a
given mode we can use it in vc4 so that we restrict the number of
probbed modes to the ones we can actually display.

Also, remove the mode_fixup() calls as these are no longer needed
because mode_valid() will be called before.

NOTE: Not even compiled tested

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Eric Anholt 
Cc: David Airlie 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 13 ++---
 drivers/gpu/drm/vc4/vc4_dpi.c  | 13 ++---
 2 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 1b4dbe9..20703c8 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -542,18 +542,17 @@ static void vc4_crtc_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);
 }
 
-static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
+static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
+   const struct drm_display_mode 
*mode)
 {
/* Do not allow doublescan modes from user space */
-   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) {
+   if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
DRM_DEBUG_KMS("[CRTC:%d] Doublescan mode rejected.\n",
  crtc->base.id);
-   return false;
+   return MODE_NO_DBLESCAN;
}
 
-   return true;
+   return MODE_OK;
 }
 
 static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
@@ -863,7 +862,7 @@ static void vc4_crtc_destroy_state(struct drm_crtc *crtc,
.mode_set_nofb = vc4_crtc_mode_set_nofb,
.disable = vc4_crtc_disable,
.enable = vc4_crtc_enable,
-   .mode_fixup = vc4_crtc_mode_fixup,
+   .mode_valid = vc4_crtc_mode_valid,
.atomic_check = vc4_crtc_atomic_check,
.atomic_flush = vc4_crtc_atomic_flush,
 };
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index c6d7039..61958ab 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -330,20 +330,19 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
*encoder)
}
 }
 
-static bool vc4_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static enum drm_mode_status vc4_dpi_encoder_mode_valid(struct drm_encoder 
*encoder,
+  const struct 
drm_display_mode *mode)
 {
-   if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
+   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+   return MODE_NO_INTERLACE;
 
-   return true;
+   return MODE_OK;
 }
 
 static const struct drm_encoder_helper_funcs vc4_dpi_encoder_helper_funcs = {
.disable = vc4_dpi_encoder_disable,
.enable = vc4_dpi_encoder_enable,
-   .mode_fixup = vc4_dpi_encoder_mode_fixup,
+   .mode_valid = vc4_dpi_encoder_mode_valid,
 };
 
 static const struct of_device_id vc4_dpi_dt_match[] = {
-- 
1.9.1


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

[PATCH v5 02/10] drm: Introduce drm_bridge_mode_valid()

[Jose Abreu]

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.

Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Cc: Carlos Palminha 
Cc: Ville Syrjälä 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);
 
 /**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls &drm_bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
  * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,
-- 
1.9.1


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

[PATCH v5 05/10] drm: arcpgu: Use crtc->mode_valid() callback

[Jose Abreu]

Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.

This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly this clock
does not support all the needed ranges.

Also, remove the atomic_check() callback as mode_valid() callback
will be called before.

Signed-off-by: Jose Abreu 
Reviewed-by: Alexey Brodkin 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Laurent Pinchart 

Changes v4->v5:
- Change commit message to "arcpgu" (Alexey)
Changes v3->v4:
- Do not use aux function (Laurent)

---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a959..99fbdae 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -64,6 +64,19 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };
 
+enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode 
*mode)
+{
+   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+   long rate, clk_rate = mode->clock * 1000;
+
+   rate = clk_round_rate(arcpgu->clk, clk_rate);
+   if (rate != clk_rate)
+   return MODE_NOCLOCK;
+
+   return MODE_OK;
+}
+
 static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -129,20 +142,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
  ~ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
-{
-   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
-   struct drm_display_mode *mode = &state->adjusted_mode;
-   long rate, clk_rate = mode->clock * 1000;
-
-   rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return -EINVAL;
-
-   return 0;
-}
-
 static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
  struct drm_crtc_state *state)
 {
@@ -158,6 +157,7 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
+   .mode_valid = arc_pgu_crtc_mode_valid,
.mode_set   = drm_helper_crtc_mode_set,
.mode_set_base  = drm_helper_crtc_mode_set_base,
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
@@ -165,7 +165,6 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
-   .atomic_check   = arc_pgu_crtc_atomic_check,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
 
-- 
1.9.1


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

[PATCH v5 01/10] drm: Add drm_{crtc/encoder/connector}_mode_valid()

[Jose Abreu]

Add a new helper to call crtc->mode_valid, connector->mode_valid
and encoder->mode_valid callbacks.

Suggested-by: Ville Syrjälä 
Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Reviewed-by: Andrzej Hajda 
Cc: Carlos Palminha 
Cc: Dave Airlie 

Changes v2->v3:
- Move helpers to drm_probe_helper.c (Daniel)
- Squeeze patches that introduce helpers into a single
one (Daniel)

Signed-off-by: Jose Abreu 
---
 drivers/gpu/drm/drm_crtc_helper_internal.h | 13 ++
 drivers/gpu/drm/drm_probe_helper.c | 38 ++
 2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h 
b/drivers/gpu/drm/drm_crtc_helper_internal.h
index 28295e5..97dfe20 100644
--- a/drivers/gpu/drm/drm_crtc_helper_internal.h
+++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
@@ -26,7 +26,11 @@
  * implementation details and are not exported to drivers.
  */
 
+#include 
+#include 
 #include 
+#include 
+#include 
 
 /* drm_fb_helper.c */
 #ifdef CONFIG_DRM_FBDEV_EMULATION
@@ -62,4 +66,13 @@ static inline int drm_dp_aux_register_devnode(struct 
drm_dp_aux *aux)
 static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
 {
 }
+
+/* drm_probe_helper.c */
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode);
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode 
*mode);
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode);
+
 #endif
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 1b0c14a..f01abdc 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -38,6 +38,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "drm_crtc_helper_internal.h"
 
 /**
  * DOC: output probing helper overview
@@ -113,6 +116,41 @@ static int drm_helper_probe_add_cmdline_mode(struct 
drm_connector *connector)
return 1;
 }
 
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+   const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+
+   if (!crtc_funcs || !crtc_funcs->mode_valid)
+   return MODE_OK;
+
+   return crtc_funcs->mode_valid(crtc, mode);
+}
+
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+{
+   const struct drm_encoder_helper_funcs *encoder_funcs =
+   encoder->helper_private;
+
+   if (!encoder_funcs || !encoder_funcs->mode_valid)
+   return MODE_OK;
+
+   return encoder_funcs->mode_valid(encoder, mode);
+}
+
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   const struct drm_connector_helper_funcs *connector_funcs =
+   connector->helper_private;
+
+   if (!connector_funcs || !connector_funcs->mode_valid)
+   return MODE_OK;
+
+   return connector_funcs->mode_valid(connector, mode);
+}
+
 #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
 /**
  * drm_kms_helper_poll_enable - re-enable output polling.
-- 
1.9.1


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

Re: [PATCH] drm/i915: prevent generating unusable gvt build which no mpt module is selected

[Du, Changbin]

Hi, Jani, just relized you are in i915 team. :)

> > +menu "Intel GVT-g graphics virtualization host support"
> > +   depends on DRM_I915
> > +   depends on 64BIT
> > +
> >  config DRM_I915_GVT
> > -bool "Enable Intel GVT-g graphics virtualization host support"
> > -depends on DRM_I915
> > -depends on 64BIT
> > -default n
> > -help
> > +   bool "Enable Intel GVT-g graphics virtualization host support"
> > +   default n
> > +   depends on DRM_I915_GVT_KVMGT
> > +   help
> 
> With this change, you can't actually change this config option. It's
> purely subject to CONFIG_DRM_I915_GVT_KVMGT. You need to enable KVMGT to
> even see this option, but enabling it will enable this one too. You
> can't disable this before you disable KVMGT, but then disabling KVMGT
> will disable this one too. This config option becomes pointless as a
> visible option. Which isn't all that bad, considering
> Documentation/kbuild/kconfig-language.txt:
>
Jani, this is by design in this patch. We will add another xengt hypervisor glue
layer to support XenGT. After that, enable DRM_I915_GVT only if at least one of
KVMGT or XENGT enabled or both. Also it doesn't make sense that we only build
KVMGT/XenGT module without DRM_I915_GVT.

Such mechanism is not as straigforward as two simple 'choice', so I agree with
'choice' if you prefer it. As you said, it is not a big problem.

>   Note:
>   select should be used with care. select will force
>   a symbol to a value without visiting the dependencies.
>   By abusing select you are able to select a symbol FOO even
>   if FOO depends on BAR that is not set.
>   In general use select only for non-visible symbols
>   (no prompts anywhere) and for symbols with no dependencies.
>   That will limit the usefulness but on the other hand avoid
>   the illegal configurations all over.
> 
Yes, we should always be carefull with 'select' and should not use it if
possible. So here I must create a 'menu' to ensure its safety.

> BR,
> Jani.
> 
> >   Choose this option if you want to enable Intel GVT-g graphics
> >   virtualization technology host support with integrated graphics.
> >   With GVT-g, it's possible to have one integrated graphics
> > @@ -116,13 +119,14 @@ config DRM_I915_GVT
> >  
> >  config DRM_I915_GVT_KVMGT
> > tristate "Enable KVM/VFIO support for Intel GVT-g"
> > -   depends on DRM_I915_GVT
> > +   select DRM_I915_GVT
> > depends on KVM
> > depends on VFIO_MDEV && VFIO_MDEV_DEVICE
> > default n
> > help
> >   Choose this option if you want to enable KVMGT support for
> >   Intel GVT-g.
> > +endmenu
> >  
> >  menu "drm/i915 Debugging"
> >  depends on DRM_I915
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Thanks,
Changbin Du


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

[PATCH v5 03/10] drm: Use new mode_valid() helpers in connector probe helper

[Jose Abreu]

This changes the connector probe helper function to use the new
encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
helper callbacks to validate the modes.

The new callbacks are optional so the behaviour remains the same
if they are not implemented. If they are, then the code loops
through all the connector's encodersXbridgesXcrtcs and calls the
callback.

If at least a valid encoderXbridgeXcrtc combination is found which
accepts the mode then the function returns MODE_OK.

Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Cc: Carlos Palminha 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 

Changes v3->v4:
- Change function name (Laurent)
Changes v2->v3:
- Call also bridge->mode_valid (Daniel)
Changes v1->v2:
- Use new helpers suggested by Ville
- Change documentation (Daniel)

---
 drivers/gpu/drm/drm_probe_helper.c | 67 +++---
 1 file changed, 63 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index f01abdc..00e6832 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -83,6 +83,61 @@
return MODE_OK;
 }
 
+static enum drm_mode_status
+drm_mode_validate_pipeline(struct drm_display_mode *mode,
+   struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   uint32_t *ids = connector->encoder_ids;
+   enum drm_mode_status ret = MODE_OK;
+   unsigned int i;
+
+   /* Step 1: Validate against connector */
+   ret = drm_connector_mode_valid(connector, mode);
+   if (ret != MODE_OK)
+   return ret;
+
+   /* Step 2: Validate against encoders and crtcs */
+   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+   struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
+   struct drm_crtc *crtc;
+
+   if (!encoder)
+   continue;
+
+   ret = drm_encoder_mode_valid(encoder, mode);
+   if (ret != MODE_OK) {
+   /* No point in continuing for crtc check as this encoder
+* will not accept the mode anyway. If all encoders
+* reject the mode then, at exit, ret will not be
+* MODE_OK. */
+   continue;
+   }
+
+   ret = drm_bridge_mode_valid(encoder->bridge, mode);
+   if (ret != MODE_OK) {
+   /* There is also no point in continuing for crtc check
+* here. */
+   continue;
+   }
+
+   drm_for_each_crtc(crtc, dev) {
+   if (!drm_encoder_crtc_ok(encoder, crtc))
+   continue;
+
+   ret = drm_crtc_mode_valid(crtc, mode);
+   if (ret == MODE_OK) {
+   /* If we get to this point there is at least
+* one combination of encoder+crtc that works
+* for this mode. Lets return now. */
+   return ret;
+   }
+   }
+   }
+
+   return ret;
+}
+
 static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
 {
struct drm_cmdline_mode *cmdline_mode;
@@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
  *- drm_mode_validate_flag() checks the modes against basic connector
  *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
  *- the optional &drm_connector_helper_funcs.mode_valid helper can perform
- *  driver and/or hardware specific checks
+ *  driver and/or sink specific checks
+ *- the optional &drm_crtc_helper_funcs.mode_valid,
+ *  &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid
+ *  helpers can perform driver and/or source specific checks which are also
+ *  enforced by the modeset/atomic helpers
  *
  * 5. Any mode whose status is not OK is pruned from the connector's modes 
list,
  *accompanied by a debug message indicating the reason for the mode's
@@ -466,9 +525,9 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_flag(mode, mode_flags);
 
-   if (mode->status == MODE_OK && connector_funcs->mode_valid)
-   mode->status = connector_funcs->mode_valid(connector,
-  mode);
+   if (mode->status == MODE_OK)
+   mode->status = drm_mode_validate_pipeline(mode,
+ connector);
}
 
 prune:
-- 
1.9.1

[PATCH v5 08/10] drm/arm: malidp: Use crtc->mode_valid() callback

[Jose Abreu]

Now that we have a callback to check if crtc supports a given mode
we can use it in malidp so that we restrict the number of probbed
modes to the ones we can actually display.

Also, remove the mode_fixup() callback as this is no longer needed
because mode_valid() will be called before.

NOTE: Not even compiled tested

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: David Airlie 
---
 drivers/gpu/drm/arm/malidp_crtc.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 9446a67..4bb38a2 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -22,9 +22,8 @@
 #include "malidp_drv.h"
 #include "malidp_hw.h"
 
-static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static enum drm_mode_status malidp_crtc_mode_valid(struct drm_crtc *crtc,
+  const struct 
drm_display_mode *mode)
 {
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
@@ -40,11 +39,11 @@ static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
if (rate != req_rate) {
DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
 req_rate);
-   return false;
+   return MODE_NOCLOCK;
}
}
 
-   return true;
+   return MODE_OK;
 }
 
 static void malidp_crtc_enable(struct drm_crtc *crtc)
@@ -408,7 +407,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = {
-   .mode_fixup = malidp_crtc_mode_fixup,
+   .mode_valid = malidp_crtc_mode_valid,
.enable = malidp_crtc_enable,
.disable = malidp_crtc_disable,
.atomic_check = malidp_crtc_atomic_check,
-- 
1.9.1


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

[PATCH v5 06/10] drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback

[Jose Abreu]

Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.

Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.

NOTE: Only compile tested.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
---
 drivers/gpu/drm/bridge/analogix-anx78xx.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..cf69a1c 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1061,18 +1061,17 @@ static int anx78xx_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }
 
-static bool anx78xx_bridge_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+enum drm_mode_status anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode 
*mode)
 {
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
+   return MODE_NO_INTERLACE;
 
/* Max 1200p at 5.4 Ghz, one lane */
if (mode->clock > 154000)
-   return false;
+   return MODE_CLOCK_HIGH;
 
-   return true;
+   return MODE_OK;
 }
 
 static void anx78xx_bridge_disable(struct drm_bridge *bridge)
@@ -1129,7 +1128,7 @@ static void anx78xx_bridge_enable(struct drm_bridge 
*bridge)
 
 static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
.attach = anx78xx_bridge_attach,
-   .mode_fixup = anx78xx_bridge_mode_fixup,
+   .mode_valid = anx78xx_bridge_mode_valid,
.disable = anx78xx_bridge_disable,
.mode_set = anx78xx_bridge_mode_set,
.enable = anx78xx_bridge_enable,
-- 
1.9.1


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

[PATCH v5 09/10] drm/atmel-hlcdc: Use crtc->mode_valid() callback

[Jose Abreu]

Now that we have a callback to check if crtc supports a given mode
we can use it in atmel-hlcdc so that we restrict the number of probbed
modes to the ones we can actually display.

Also, remove the mode_fixup() callback as this is no longer needed
because mode_valid() will be called before.

NOTE: Not even compiled tested

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Boris Brezillon 
Cc: David Airlie 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 53bfa56..bdfe74e 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -140,13 +140,12 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
drm_crtc *c)
   cfg);
 }
 
-static bool atmel_hlcdc_crtc_mode_fixup(struct drm_crtc *c,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
+static enum drm_mode_status atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
+   const struct 
drm_display_mode *mode)
 {
struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
 
-   return atmel_hlcdc_dc_mode_valid(crtc->dc, adjusted_mode) == MODE_OK;
+   return atmel_hlcdc_dc_mode_valid(crtc->dc, mode);
 }
 
 static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
@@ -315,7 +314,7 @@ static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc 
*crtc,
 }
 
 static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
-   .mode_fixup = atmel_hlcdc_crtc_mode_fixup,
+   .mode_valid = atmel_hlcdc_crtc_mode_valid,
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
-- 
1.9.1


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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #20 from Michel Dänzer (mic...@daenzer.net) ---
Flora, why did you add me to Cc? I get notifications via the dri-devel mailing
list.

-- 
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/rockchip: Don't allow zero sized gem buffer

[jeffy]

Hi sean,

On 05/25/2017 11:30 PM, Sean Paul wrote:

On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:

The system would crash when trying to alloc zero sized gem buffer:
[6.712435] Unable to handle kernel NULL pointer dereference at virtual address 
0010 <--ZERO_SIZE_PTR
...
[6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec


It's unfortunate that you didn't include the entire stack trace. From code
inspection, it seems like the 0 size comes from the fb_probe path? Is there
somewhere in the helpers that you could check the mode is sane so all drivers
can benefit?


hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that 
we have a custom ioctl for userspace to create gem buffer(the same as 
exynos drm), which might get the the 0 size.


but on upstream kernel, it could only be called by dump_create, and the 
drm_mode_create_dumb_ioctl already did the size check.


will resent this patch, and rewrite the commit message, thanx.



Sean



Signed-off-by: Jeffy Chen 
---

  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..8917922 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -315,6 +315,11 @@ struct rockchip_gem_object *
struct drm_gem_object *obj;
int ret;

+   if (!size) {
+   DRM_ERROR("gem buffer size is zero\n");
+   return ERR_PTR(-EINVAL);
+   }
+
size = round_up(size, PAGE_SIZE);

rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
--
2.1.4






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

Re: [GIT PULL] exynos-drm-fixes

[Dave Airlie]

On 19 May 2017 at 19:33, Inki Dae  wrote:
> Hi Dave,
>
>a little bit big cleanups but this fixes some timeout issue
>at wait-for-vblank, fixups to dt broken issue and trivial cleanups.
>
>Please kindly let me know if there is any problem.

Can we make this smaller, if I'd been happy for next I'd have pulled
it, but I'm not sure
I want to take all of this at this stage.

Anything that fixes a regression in 4.11/12 would be mostly what I
want, not so much
the cleanups.

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

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.

Thanks,
Archit



Best regards
---
Kuninori Morimoto



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

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

On 05/26/2017 09:46 AM, Archit Taneja wrote:

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.


Ah, I just saw the dependence on the previous patches.

Mark,

Please feel free to pull this to the asoc tree. You can add my Ack:

Acked-by: Archit Taneja 

Thanks,
Archit



Thanks,
Archit



Best regards
---
Kuninori Morimoto





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

Re: [PATCH v5 02/10] drm: Introduce drm_bridge_mode_valid()

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.



Reviewed-by: Archit Taneja 


Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Cc: Carlos Palminha 
Cc: Ville Syrjälä 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls &drm_bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
  * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,



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

Re: [PATCH v5 06/10] drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.

Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.



Reviewed-by: Archit Taneja 


NOTE: Only compile tested.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
---
 drivers/gpu/drm/bridge/analogix-anx78xx.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..cf69a1c 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1061,18 +1061,17 @@ static int anx78xx_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }

-static bool anx78xx_bridge_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+enum drm_mode_status anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode 
*mode)
 {
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
+   return MODE_NO_INTERLACE;

/* Max 1200p at 5.4 Ghz, one lane */
if (mode->clock > 154000)
-   return false;
+   return MODE_CLOCK_HIGH;

-   return true;
+   return MODE_OK;
 }

 static void anx78xx_bridge_disable(struct drm_bridge *bridge)
@@ -1129,7 +1128,7 @@ static void anx78xx_bridge_enable(struct drm_bridge 
*bridge)

 static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
.attach = anx78xx_bridge_attach,
-   .mode_fixup = anx78xx_bridge_mode_fixup,
+   .mode_valid = anx78xx_bridge_mode_valid,
.disable = anx78xx_bridge_disable,
.mode_set = anx78xx_bridge_mode_set,
.enable = anx78xx_bridge_enable,



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

[git pull] drm fixes for v4.12-rc3

[Dave Airlie]

Hi Linus,

Not a whole lot happening here, a set of amdgpu fixes and one core
deadlock fix, and some misc drivers fixes.

Dave.


The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc3

for you to fetch changes up to bc1f0e04da20473d6feab0cd9ac638a348d5:

  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-05-26
11:51:55 +1000)


misc and amdgpu fixes


Alex Deucher (4):
  drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)
  drm/radeon/ci: disable mclk switching for high refresh rates (v2)
  drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)
  drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

Christian König (1):
  drm/amdgpu: fix fundamental suspend/resume issue

Chunming Zhou (1):
  drm/amdgpu: fix NULL pointer panic of emit_gds_switch

Dan Carpenter (1):
  drm/amd/powerplay: fix a signedness bugs

Daniel Vetter (1):
  drm: Fix deadlock retry loop in page_flip_ioctl

Dave Airlie (2):
  Merge tag 'drm-misc-fixes-2017-05-25' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Gabriel Krisman Bertazi (1):
  drm: qxl: Delay entering atomic context during cursor update

Lukas Wunner (1):
  drm/radeon: Fix oops upon driver load on PowerXpress laptops

Lyude (1):
  drm/radeon: Unbreak HPD handling for r600+

Patrik Jakobsson (1):
  drm/gma500/psb: Actually use VBT mode when it is found

Rex Zhu (1):
  drm/amdgpu: fix null point error when rmmod amdgpu.

 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  7 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 24 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  6 
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 16 ++-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 32 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  2 +-
 drivers/gpu/drm/drm_plane.c|  5 ++--
 drivers/gpu/drm/gma500/psb_intel_lvds.c| 18 +++-
 drivers/gpu/drm/qxl/qxl_display.c  |  4 +--
 drivers/gpu/drm/radeon/ci_dpm.c|  6 
 drivers/gpu/drm/radeon/cik.c   |  4 +--
 drivers/gpu/drm/radeon/evergreen.c |  4 +--
 drivers/gpu/drm/radeon/r600.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c|  2 +-
 drivers/gpu/drm/radeon/si.c|  4 +--
 19 files changed, 102 insertions(+), 80 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm: introduce sync objects (v3)

[Dave Airlie]

On 25 May 2017 at 18:30, Chris Wilson  wrote:
> On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote:
>> From: Dave Airlie 
>>
>> Sync objects are new toplevel drm object, that contain a
>> pointer to a fence. This fence can be updated via command
>> submission ioctls via drivers.
>>
>> There is also a generic wait obj API modelled on the vulkan
>> wait API (with code modelled on some amdgpu code).
>>
>> These objects can be converted to an opaque fd that can be
>> passes between processes.
>>
>> v2: rename reference/unreference to put/get (Chris)
>> fix leaked reference (David Zhou)
>> drop mutex in favour of cmpxchg (Chris)
>> v3: cleanups from danvet, rebase on drm_fops rename
>> check fd_flags is 0 in ioctls.
>>
>> Reviewed-by: Sean Paul 
>> Signed-off-by: Dave Airlie 
>> ---
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index 42d9f64..96c5c78 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
>> @@ -648,6 +648,7 @@ struct drm_gem_open {
>>  #define DRM_CAP_ADDFB2_MODIFIERS 0x10
>>  #define DRM_CAP_PAGE_FLIP_TARGET 0x11
>>  #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
>> +#define DRM_CAP_SYNCOBJ  0x13
>>
>>  /** DRM_IOCTL_GET_CAP ioctl argument type */
>>  struct drm_get_cap {
>> @@ -697,6 +698,24 @@ struct drm_prime_handle {
>>   __s32 fd;
>>  };
>>
>> +struct drm_syncobj_create {
>> + __u32 handle;
>> + __u32 flags;
>> +};
>> +
>> +struct drm_syncobj_destroy {
>> + __u32 handle;
>> + __u32 pad;
>> +};
>> +
>> +struct drm_syncobj_handle {
>> + __u32 handle;
>> + __u32 flags;
>> +
>> + __s32 fd;
>> + __u32 pad;
>> +};
>> +
>>  #if defined(__cplusplus)
>>  }
>>  #endif
>> @@ -815,6 +834,11 @@ extern "C" {
>>  #define DRM_IOCTL_MODE_CREATEPROPBLOBDRM_IOWR(0xBD, struct 
>> drm_mode_create_blob)
>>  #define DRM_IOCTL_MODE_DESTROYPROPBLOB   DRM_IOWR(0xBE, struct 
>> drm_mode_destroy_blob)
>>
>> +#define DRM_IOCTL_SYNCOBJ_CREATE DRM_IOWR(0xBF, struct 
>> drm_syncobj_create)
>> +#define DRM_IOCTL_SYNCOBJ_DESTROYDRM_IOWR(0xC0, struct 
>> drm_syncobj_destroy)
>
> These two only need DRM_IOW.

They do now, but at least create takes some flags, destroy is probably
fine. are we okay to change these flags later?

I can never remember and I'd rather not have to think about it too much.
>
> With that,
> Reviewed-by: Chris Wilson 

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

Re: [PULL] drm-misc-fixes

[Lukas Wunner]

On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote:
> The pull is noisy because it includes -rc2.

Looks like I've caused another fine mess by fast-forwarding -fixes. :-(

I followed the docs in drm-misc.rst which say:

* Fast-forward (when possible) `-fixes` to each released -rc kernel tag, to
  keep it current. We try to avoid backmerges for bugfix branches, and rebasing
  isn't an option with multiple committers.

How do you actually handle this?  Fast-forward only if Dave has already
done so himself?

Thanks,

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

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[Christoph Hellwig]

On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
> Hi sean,
> 
> On 05/25/2017 11:30 PM, Sean Paul wrote:
> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
> > > The system would crash when trying to alloc zero sized gem buffer:
> > > [6.712435] Unable to handle kernel NULL pointer dereference at 
> > > virtual address 0010 <--ZERO_SIZE_PTR
> > > ...
> > > [6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec
> > 
> > It's unfortunate that you didn't include the entire stack trace. From code
> > inspection, it seems like the 0 size comes from the fb_probe path? Is there
> > somewhere in the helpers that you could check the mode is sane so all 
> > drivers
> > can benefit?
> 
> hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that we
> have a custom ioctl for userspace to create gem buffer(the same as exynos
> drm), which might get the the 0 size.
> 
> but on upstream kernel, it could only be called by dump_create, and the
> drm_mode_create_dumb_ioctl already did the size check.
> 
> will resent this patch, and rewrite the commit message, thanx.

That suggests that this patch isn't needed at all.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-misc-fixes

[Dave Airlie]

On 26 May 2017 at 15:30, Lukas Wunner  wrote:
> On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote:
>> The pull is noisy because it includes -rc2.
>
> Looks like I've caused another fine mess by fast-forwarding -fixes. :-(
>
> I followed the docs in drm-misc.rst which say:
>
> * Fast-forward (when possible) `-fixes` to each released -rc kernel tag, to
>   keep it current. We try to avoid backmerges for bugfix branches, and 
> rebasing
>   isn't an option with multiple committers.
>
> How do you actually handle this?  Fast-forward only if Dave has already
> done so himself?

As long as I'm warned in the pull request I often fast forward to the
base if my tree is clean,
just to avoid the pull request having noise in it.

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

Re: [PULL] drm-misc-fixes

[Daniel Vetter]

On Thu, May 25, 2017 at 7:44 PM, Sean Paul  wrote:
> The pull is noisy
> because it includes -rc2.

dim has you covered for this, in case you've rolled forward but Dave
hasn't yet, you can regenerate against linus upstream branch for a
cleaner pull (but still warn Dave ofc):

$ dim pull-request drm-misc-next origin/master

Cheers, Daniel
-- 
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: [PATCH] dim: Enforce review requirements

[Daniel Vetter]

On Thu, May 25, 2017 at 7:37 AM, Lukas Wunner  wrote:
> On Wed, May 24, 2017 at 11:28:12AM +0200, Daniel Vetter wrote:
>> We can't check this when applying (since r-b/a-b tags often get added
>> afterwards), but we can check this when pushing. This only looks at
>> patches authored by the pusher.
>
> BTW, can we also have a rule that large drivers (i.e. with a large user
> base) are required to provide at least one person at all times (or at
> least outside the merge window) who is able to review fixes, push them
> to the driver's repo and send a timely pull to Dave?
>
> On multiple occasions I've seen Dave send a fixes pull with an apology
> along the lines of "a bit more than usual at this time of the cycle
> because it includes two weeks worth of driver XYZ fixes".

AMD is already planning to swtich to a group/committer model, I just
discussed that with Alex. That takes care of the huge drivers
(intel/amd) and the small ones (if they are in drm-misc). No idea what
we'll end up doing with the medium sized drivers, but I guess that's a
discussion for the next months/years ...
-Daniel
-- 
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: Maintaining small drm drivers

[Daniel Vetter]

On Thu, May 25, 2017 at 1:09 AM, Patrik Jakobsson
 wrote:
> On Wed, May 24, 2017 at 9:52 PM, Daniel Vetter  wrote:
>> On Wed, May 24, 2017 at 6:57 PM, Patrik Jakobsson
>>  wrote:
>>> Hi Dave and Daniel,
>>>
>>> We had a little mishap this morning when I had pushed a fix for gma500
>>> into drm-misc-fixes without first getting someone to review it. The
>>> patch have been on the list for over a month and I don't feel like I
>>> have enough karma to force someone to review it. Since I'm the only
>>> one actively reviewing gma500 stuff I've effectively locked myself out
>>> from submitting patches for the driver. Sure, sometimes others help
>>> out and that is ofc appreciated.
>>>
>>> As you suggested Daniel, I could trade light-weight reviews with
>>> someone else. At first it sounds reasonable but when I think about it
>>> it's rather bad. Why should I sell my r-b tags cheap in order to get
>>> patches into the driver I'm maintaining? This model seems broken.
>>> Doing quick reviews because you trust the author is not a good idea.
>>> It defeats the purpose and soils the value of your r-b tag (learned
>>> from my own mistakes).
>>>
>>> In the case of gma500 I'm exaggerating the problem a bit but others
>>> will run into the same issue at some point. So my question is, can we
>>> scrap the requirements for an r-b tag in drivers with only one
>>> continuously active developer or at least make it more "soft"? Other
>>> ideas are welcome.
>>
>> I had a really long discussion about this topic in private with
>> another maintainer who expressed some unhappiness about the drm-misc
>> review model. Yes it looks a bit silly that you have to trade review,
>> but in the end if you think it's necessary to review other
>> submissions, then imo you also need to get your own patches reviewed
>> or at least sanity-checked.
>
> Thanks for replying Daniel.
>
> I agree with your reasoning but we're looking at the problem from two
> different perspectives. It's not silly to require review per se. My
> patches also deserves review but the problem is that I cannot count on
> getting it and I don't think I should be stealing time from others
> (you included) who's time is better spent elsewhere.


Did you ping other drm-misc maintainers on irc? Did you ping
Sean/Jani/me as ultim fallback reviewers? Yes sometimes getting that
review takes a bit of time, especially if the collaboration hasn't
been established yet.

> Currently I get to choose between bad (patches without good review) or
> worse (no patches at all). Unfortunately I cannot pick bad because of
> the r-b tag requirement. Also, I review gma500 patches because it is
> expected of me and because I can. Not because I think the quality is
> worse than mine. I'd love to get reviews back but so far people just
> drop their patches and run.
>
>>
>> That's why drm-intel, drm-misc and anything else I'll ever maintain
>> will have a hard&solid rule to never push my own stuff (or anyone else
>> with commit rights) without review. No exceptions.
>
> That works when dealing with i915 and drm core (and other bigger
> drivers). You have a decent group of people who are technically
> qualified with personal and professional incentives to review your
> patches. It's easy to have high standards when they are not being
> challenged.
>
> On the gma500 team there's me and a bunch of frustrated users. What I
> would like to do is to continue shrinking the codebase and fix up the
> most obvious mistakes to make it more maintainable and let it live a
> couple of more years. I will likely have some time to do that again
> soon. Not because it's very important but because it's fun and makes a
> small group of people happy. Adding a bunch of process to this makes
> it less fun and reduces my output.

Find another smaller driver in need of some cleanup (we can add more
to drm-misc), cross review. Yes it's a bit of work (see above), but at
least from the drm subsystem pov the end result will be worth it,
since more code sharing and more collaboration gives us a much
stronger community.

>> In my opinion, as a maintainer of a part of the linux kernel your job
>> is to be the steward of the code and contributors/community around it,
>> not be the lord with special priviledges like being able to push
>> unreviewed patches or nacking contributions just because you're the
>> maintainer. And yes, part of the rules behind drm-misc is to make sure
>> that even single-maintainer drivers do collaborate, because with most
>> drivers sooner or later there will be other contributors.
>
> Right now I'm the lord of a mess but with less privileges than the
> contributors. They at least get their patches reviewed and included.
> Sounds more like I'm the fool ;)
>
> Sure, I can nack peoples patches but where's the fun in that. Nacking
> is never the easy choice since it requires justification and thus more
> work. I certainly don't see it as a privilege.
>
>> So at least from my side, yes there's an agenda behind th

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[Daniel Vetter]

On Fri, May 26, 2017 at 7:52 AM, Christoph Hellwig  wrote:
> On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
>> Hi sean,
>>
>> On 05/25/2017 11:30 PM, Sean Paul wrote:
>> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
>> > > The system would crash when trying to alloc zero sized gem buffer:
>> > > [6.712435] Unable to handle kernel NULL pointer dereference at 
>> > > virtual address 0010 <--ZERO_SIZE_PTR
>> > > ...
>> > > [6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec
>> >
>> > It's unfortunate that you didn't include the entire stack trace. From code
>> > inspection, it seems like the 0 size comes from the fb_probe path? Is there
>> > somewhere in the helpers that you could check the mode is sane so all 
>> > drivers
>> > can benefit?
>>
>> hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that we
>> have a custom ioctl for userspace to create gem buffer(the same as exynos
>> drm), which might get the the 0 size.
>>
>> but on upstream kernel, it could only be called by dump_create, and the
>> drm_mode_create_dumb_ioctl already did the size check.
>>
>> will resent this patch, and rewrite the commit message, thanx.
>
> That suggests that this patch isn't needed at all.

Yes, not needed for upstream. But next time around pls include the
entire backtrace (or at least the relevant parts), not just the last
line, so that we can figure this out directly.

Thanks, Daniel
-- 
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: [PATCH 36/37] drm/zte: Drop drm_vblank_cleanup

[Daniel Vetter]

On Thu, May 25, 2017 at 5:01 AM, Shawn Guo  wrote:
> On Wed, May 24, 2017 at 04:52:11PM +0200, Daniel Vetter wrote:
>> It again looks all cargo-culted for no good reasons.
>
> drm_vblank_cleanup() is called to release the resources allocated by
> drm_vblank_init().  I think that's the reason, no?

Pls read the code and the last patch in this series. The drm core
already calls drm_vblank_cleanup for you, the only reason it was
exported was to handle certain usersmodesetting fallback scenarios in
radeon.ko.
-Daniel
-- 
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