Re: [PATCH 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

[Laurent Pinchart]

Hi Noralf,

Thank you for the patches.

On Monday, 11 September 2017 17:31:54 EEST Noralf Trønnes wrote:
> Hi,
> 
> I want to start out by saying that this patchset is low priority for me
> and if no one has interest or time to review this, that is just fine. I
> was in the flow and just typed it out.
> 
> This patchset adds a way for fbdev emulation code to create a
> framebuffer that is backed by a dumb buffer. drm_fb_helper gets a
> drm_file to hang the objects on, drm_framebuffer_create_dumb() creates
> the framebuffer and drm_fb_helper_fini() destroys it.
> I have verified that all cma drivers supports dumb buffers, so
> converting the library should be fine for all.

Stupid question, what does this give us ? The series makes the call stack more 
complex (up to a point where I'm getting trouble just following it), what's 
the advantage that offsets that ?

With the exception of vmwgfx that does weird things I won't even try to 
understand, all drivers seem to use the drm_file object passed to the 
.dumb_create() operation just to register the GEM object handle. I wonder 
whether a better solution to use .dumb_create() for framebuffer emulation 
wouldn't be to move the GEM object handle registration from the .dumb_create() 
implementation to its caller in the core.

> A patch by David Herrmann from a year ago made this easy. It was the
> last piece in his work to make it possible to create a drm_file for
> in-kernel use, but it never got merged.
> 
> I've cc'ed intel-gfx since that will give CI runs of the core patches if
> I understood Daniel right.
> 
> Noralf.
> 
> David Herrmann (1):
>   drm: provide management functions for drm_file
> 
> Noralf Trønnes (7):
>   drm/framebuffer: Add drm_framebuffer_create_dumb()
>   drm/auth: Export drm_dropmaster_ioctl()
>   drm/fb-helper: Allocate a drm_file
>   drm/fb-cma-helper: Use drm_framebuffer_create_dumb()
>   drm/fb-cma-helper: Drop unnecessary fbdev buffer offset
>   drm/tinydrm: Use drm_fbdev_cma_init()
>   drm/fb-cma-helper: Remove drm_fbdev_cma_init_with_funcs()
> 
>  drivers/gpu/drm/drm_auth.c  |   1 +
>  drivers/gpu/drm/drm_fb_cma_helper.c | 111 ++
>  drivers/gpu/drm/drm_fb_helper.c |  22 +-
>  drivers/gpu/drm/drm_file.c  | 323 +++--
>  drivers/gpu/drm/drm_framebuffer.c   |  61 ++
>  drivers/gpu/drm/drm_internal.h  |   2 -
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c |   5 +-
>  include/drm/drm_auth.h  |   2 +
>  include/drm/drm_fb_helper.h |   9 +
>  include/drm/drm_file.h  |   2 +
>  include/drm/drm_framebuffer.h   |   4 +
>  11 files changed, 305 insertions(+), 237 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[zhoucm1]

Hi Marek,

You're doing same things with me, see my "introduce syncfile as fence 
reuturn" patch set, which makes things more simple, we just need to 
directly return syncfile fd to UMD when CS, then the fence UMD get will 
be always syncfile fd, UMD don't need to construct 
ip_type/ip_instance/ctx_id/ring any more, which also can pass to 
dependency and syncobj as well.


Regards,
David Zhou
On 2017年09月13日 04:42, Marek Olšák wrote:

From: Marek Olšák 

for being able to convert an amdgpu fence into one of the handles.
Mesa will use this.

Signed-off-by: Marek Olšák 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 61 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
  include/uapi/drm/amdgpu_drm.h   | 16 +
  5 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index b5c8b90..c15fa93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1308,6 +1308,8 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void 
*data,
  int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
  int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file 
*filp);
+int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
  int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, struct drm_file 
*filp);
  int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 7cb8a59..6dd719c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
   *Jerome Glisse 
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1311,6 +1312,66 @@ static struct dma_fence *amdgpu_cs_get_fence(struct 
amdgpu_device *adev,
return fence;
  }
  
+int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data,

+   struct drm_file *filp)
+{
+   struct amdgpu_device *adev = dev->dev_private;
+   struct amdgpu_fpriv *fpriv = filp->driver_priv;
+   union drm_amdgpu_fence_to_handle *info = data;
+   struct dma_fence *fence;
+   struct drm_syncobj *syncobj;
+   struct sync_file *sync_file;
+   int fd, r;
+
+   if (amdgpu_kms_vram_lost(adev, fpriv))
+   return -ENODEV;
+
+   fence = amdgpu_cs_get_fence(adev, filp, >in.fence);
+   if (IS_ERR(fence))
+   return PTR_ERR(fence);
+
+   switch (info->in.what) {
+   case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ:
+   r = drm_syncobj_create(, 0, fence);
+   dma_fence_put(fence);
+   if (r)
+   return r;
+   r = drm_syncobj_get_handle(filp, syncobj, >out.handle);
+   drm_syncobj_put(syncobj);
+   return r;
+
+   case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD:
+   r = drm_syncobj_create(, 0, fence);
+   dma_fence_put(fence);
+   if (r)
+   return r;
+   r = drm_syncobj_get_fd(syncobj, (int*)>out.handle);
+   drm_syncobj_put(syncobj);
+   return r;
+
+   case AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD:
+   fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fd < 0) {
+   dma_fence_put(fence);
+   return fd;
+   }
+
+   sync_file = sync_file_create(fence);
+   dma_fence_put(fence);
+   if (!sync_file) {
+   put_unused_fd(fd);
+   return -ENOMEM;
+   }
+
+   fd_install(fd, sync_file->file);
+   info->out.handle = fd;
+   return 0;
+
+   default:
+   return -EINVAL;
+   }
+}
+
  /**
   * amdgpu_cs_wait_all_fence - wait on all fences to signal
   *
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index d01aca6..1e38411 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -70,9 +70,10 @@
   * - 3.18.0 - Export gpu always on cu bitmap
   * - 3.19.0 - Add support for UVD MJPEG decode
   * - 3.20.0 - Add support for local BOs
+ * - 3.21.0 - Add DRM_AMDGPU_FENCE_TO_HANDLE ioctl
   */
  #define KMS_DRIVER_MAJOR  3
-#define KMS_DRIVER_MINOR   20
+#define KMS_DRIVER_MINOR   21
  #define KMS_DRIVER_PATCHLEVEL 0
  
  int amdgpu_vram_limit = 0;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 

[pull] amdgpu and ttm drm-next-4.14

[Alex Deucher]

Hi Dave,

A few fixes for 4.14.  Nothing too major.

The following changes since commit 7c0059dd832cc686bf0febefdcf8295cdd93007f:

  Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-next 
(2017-08-23 05:32:26 +1000)

are available in the git repository at:

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

for you to fetch changes up to 3d138c14c4174a2c80874a96935c87eee7c82ecf:

  drm/amdgpu: revert "fix deadlock of reservation between cs and gpu reset v2" 
(2017-09-12 22:16:31 -0400)


Alex Deucher (5):
  drm/amdgpu/gfx8: fix spelling typo in mqd allocation
  drm/amdgpu: add automatic per asic settings for gart_size
  drm/amdgpu: refine default gart size
  drm/amdgpu: move default gart size setting into gmc modules
  drm/amdgpu: set sched_hw_submission higher for KIQ (v3)

Christian König (6):
  drm/amdgpu: fix and cleanup shadow handling
  drm/amdgpu: discard commands of killed processes
  drm/amdgpu: remove the GART copy hack
  drm/amdgpu: fix amdgpu_ttm_bind
  drm/amdgpu: inline amdgpu_ttm_do_bind again
  drm/amdgpu: revert "fix deadlock of reservation between cs and gpu reset 
v2"

Christophe JAILLET (1):
  drm/amdgpu: check memory allocation failure

Colin Ian King (1):
  drm/amdgpu: remove duplicate return statement

Emily Deng (1):
  drm/amdgpu/virtual_dce: Virtual display doesn't support disable vblank 
immediately

Evan Quan (2):
  drm/amd/powerplay: unhalt mec after loading
  drm/amd/powerplay: ACG frequency added in PPTable

Felix Kuehling (1):
  drm/amdgpu: Fix huge page updates with CPU

Monk Liu (2):
  drm/ttm: fix missing inc bo_count
  drm/ttm:fix wrong decoding of bo_count

Roger He (1):
  drm/amd/amdgpu: fix BANK_SELECT on Vega10 (v2)

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c  |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c   | 12 
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h   |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 14 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|  5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 46 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   | 16 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 76 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|  4 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 46 ++---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 12 ++--
 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c   |  5 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 19 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  | 22 ++-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  | 21 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 16 -
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c|  5 +-
 drivers/gpu/drm/amd/include/vi_structs.h   |  4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 11 +++-
 drivers/gpu/drm/amd/powerplay/inc/smu9_driver_if.h |  6 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c |  3 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c  | 23 +--
 drivers/gpu/drm/ttm/ttm_bo.c   |  4 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c  |  1 +
 28 files changed, 236 insertions(+), 160 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|17.1|unspecified
 QA Contact|dri-devel@lists.freedesktop |
   |.org|
  Component|Drivers/Gallium/radeonsi|DRM/AMDgpu

--- Comment #7 from Michel Dänzer  ---
Looks like a display related issue in the kernel driver. Any chance you can try
an amd-staging kernel with DC enabled, to see if it happens with that as well?

-- 
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 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

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

[Bug 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer  ---
With xf86-video-amdgpu 1.3.0 or newer:

xrandr --output  --set TearFree on # or off / auto

-- 
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 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

--- Comment #6 from Niklas Haas  ---
Neat, thanks!

(I also noticed an _ICC_PROFILE setting there, I wonder if that refers to the
X11 atom or if there's some sort of built-in ICC profile querying mechanism
inherent to RandR anyway, offtopic)

-- 
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 2/2] drm/gem-fb-helper: Use debug message on gem lookup failure

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Monday, 11 September 2017 19:37:45 EEST Noralf Trønnes wrote:
> GEM lookup failure can easily be triggered by userspace so make
> it a debug message, not an error message.
> 
> Also remove unnecessary inner parentheses and fix alphabetical
> struct declaration order.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Noralf Trønnes 
> Reviewed-by: Daniel Vetter 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 ++--
>  include/drm/drm_gem_framebuffer_helper.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index e2ca002..9cf6566
> 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -157,7 +157,7 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev,
> struct drm_file *file,
> 
>   objs[i] = drm_gem_object_lookup(file, mode_cmd->handles[i]);
>   if (!objs[i]) {
> - DRM_DEV_ERROR(dev->dev, "Failed to lookup GEM\n");
> + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
>   ret = -ENOENT;
>   goto err_gem_object_put;
>   }
> @@ -235,7 +235,7 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
>   struct dma_buf *dma_buf;
>   struct dma_fence *fence;
> 
> - if ((plane->state->fb == state->fb) || !state->fb)
> + if (plane->state->fb == state->fb || !state->fb)
>   return 0;
> 
>   dma_buf = drm_gem_fb_get_obj(state->fb, 0)->dma_buf;
> diff --git a/include/drm/drm_gem_framebuffer_helper.h
> b/include/drm/drm_gem_framebuffer_helper.h index db9cfa0..5ca7cdc 100644
> --- a/include/drm/drm_gem_framebuffer_helper.h
> +++ b/include/drm/drm_gem_framebuffer_helper.h
> @@ -2,8 +2,8 @@
>  #define __DRM_GEM_FB_HELPER_H__
> 
>  struct drm_device;
> -struct drm_file;
>  struct drm_fb_helper_surface_size;
> +struct drm_file;
>  struct drm_framebuffer;
>  struct drm_framebuffer_funcs;
>  struct drm_gem_object;


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 1/2] drm/gem-fb-helper: Cleanup docs

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Monday, 11 September 2017 19:37:44 EEST Noralf Trønnes wrote:
> Make the docs read a little better.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Noralf Trønnes 
> Reviewed-by: Daniel Vetter 
> ---
> 
> Changes:
> Addressed Daniel's comments.
> 
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 25 ++---
> 1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index d54a083..e2ca002
> 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -27,18 +27,21 @@
>   * DOC: overview
>   *
>   * This library provides helpers for drivers that don't subclass
> - * _framebuffer and and use _gem_object for their backing storage.
> + * _framebuffer and use _gem_object for their backing storage.
>   *
>   * Drivers without additional needs to validate framebuffers can simply use
> - * drm_gem_fb_create() and everything is wired up automatically. But all -
> * parts can be used individually.
> + * drm_gem_fb_create() and everything is wired up automatically. Other
> drivers + * can use all parts independently.
>   */
> 
>  /**
>   * drm_gem_fb_get_obj() - Get GEM object for framebuffer
> - * @fb: The framebuffer
> + * @fb: framebuffer
>   * @plane: Which plane

Nitpicking, you should capitalize all entries or none.

>   *
> + * No additional reference is taken beyond the one that the _frambuffer
> + * already holds.
> + *
>   * Returns the GEM object for given framebuffer.
>   */
>  struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb,
> @@ -82,7 +85,7 @@ drm_gem_fb_alloc(struct drm_device *dev,
> 
>  /**
>   * drm_gem_fb_destroy - Free GEM backed framebuffer
> - * @fb: DRM framebuffer
> + * @fb: framebuffer
>   *
>   * Frees a GEM backed framebuffer with its backing buffer(s) and the
> structure
> * itself. Drivers can use this as their _framebuffer_funcs->destroy
> @@ -102,8 +105,8 @@
> EXPORT_SYMBOL(drm_gem_fb_destroy);
> 
>  /**
>   * drm_gem_fb_create_handle - Create handle for GEM backed framebuffer
> - * @fb: DRM framebuffer
> - * @file: drm file
> + * @fb: framebuffer
> + * @file: DRM file

I wonder why framebuffer doesn't need a DRM while file does :-)

>   * @handle: handle created
>   *
>   * Drivers can use this as their _framebuffer_funcs->create_handle
> @@ -124,7 +127,7 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
>   *  _mode_config_funcs.fb_create
>   *  callback
>   * @dev: DRM device
> - * @file: drm file for the ioctl call
> + * @file: DRM file for the ioctl call
>   * @mode_cmd: metadata from the userspace fb creation request
>   * @funcs: vtable to be used for the new framebuffer object
>   *
> @@ -194,7 +197,7 @@ static const struct drm_framebuffer_funcs
> drm_gem_fb_funcs = { /**
>   * drm_gem_fb_create() - _mode_config_funcs.fb_create callback function
> * @dev: DRM device
> - * @file: drm file for the ioctl call
> + * @file: DRM file for the ioctl call
>   * @mode_cmd: metadata from the userspace fb creation request
>   *
>   * If your hardware has special alignment or pitch requirements these
> should be @@ -214,11 +217,11 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_create);
>  /**
>   * drm_gem_fb_prepare_fb() - Prepare gem framebuffer
>   * @plane: Which plane
> - * @state: Plane state attach fence to
> + * @state: Plane state the fence will be attached to
>   *
>   * This can be used as the _plane_helper_funcs.prepare_fb hook.
>   *
> - * This function checks if the plane FB has an dma-buf attached, extracts
> + * This function checks if the plane FB has a dma-buf attached, extracts
>   * the exclusive fence and attaches it to plane state for the atomic helper
> * to wait on.
>   *
> --
> 2.7.4


-- 
Regards,

Laurent Pinchart

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

[Bug 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher  ---
(In reply to Niklas Haas from comment #4)
> How does this work? I'm not seeing anything related to TearFree or driver
> options in `xrandr --help`.
> 
> (Avoiding the use of a xorg.conf would indeed be nice, since it would
> prevent me from having to mess around with symlinks when switching between
> AMD and nvidia GPUs)

`xrandr --verbose` and look for the tearfree output property.  Then use xrandr
to adjust the property.  This was enabled fairly recently so your ddx may be
too old.

-- 
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 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

--- Comment #4 from Niklas Haas  ---
How does this work? I'm not seeing anything related to TearFree or driver
options in `xrandr --help`.

(Avoiding the use of a xorg.conf would indeed be nice, since it would prevent
me from having to mess around with symlinks when switching between AMD and
nvidia GPUs)

-- 
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 v3 4/6] [media] exynos-gsc: Add hardware rotation limits

[Hoegeun Kwon]

Hi Sylwester,

On 09/11/2017 06:35 PM, Sylwester Nawrocki wrote:

On 09/08/2017 08:02 AM, Hoegeun Kwon wrote:

The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon 
---
  drivers/media/platform/exynos-gsc/gsc-core.c | 96 


  1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c

index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  return IRQ_HANDLED;
  }
  -static struct gsc_pix_max gsc_v_100_max = {
+static struct gsc_pix_max gsc_v_5250_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2016,
+.real_rot_en_h= 2016,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2048,
+.real_rot_en_h= 2048,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
  .org_scaler_bypass_w= 8192,
  .org_scaler_bypass_h= 8192,
  .org_scaler_input_w= 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  .target_h= 2,  /* yuv420 : 2, others : 1 */
  };
  -static struct gsc_variant gsc_v_100_variant = {
-.pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+.pix_max= _v_5250_max,
  .pix_min= _v_100_min,
  .pix_align= _v_100_align,
  .in_buf_cnt= 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .local_sc_down= 2,
  };
  -static struct gsc_driverdata gsc_v_100_drvdata = {
+static struct gsc_variant gsc_v_5420_variant = {
+.pix_max= _v_5420_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+.pix_max= _v_5433_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
-[3] = _v_100_variant,
+[0] = _v_5250_variant,
+[1] = _v_5250_variant,
+[2] = _v_5250_variant,
+[3] = _v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = _v_5420_variant,
+[1] = _v_5420_variant,
  },
  .num_entities = 4,
  .clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static struct gsc_driverdata gsc_5433_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
+[0] = _v_5433_variant,
+[1] = _v_5433_variant,
+[2] = _v_5433_variant,
  },
  .num_entities = 3,
  .clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static const struct of_device_id exynos_gsc_match[] = {
  {
-.compatible = "samsung,exynos5-gsc",
-.data = _v_100_drvdata,


Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?



Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' and 5420 is '.real_rot_en_w/h = 
2048'.


So my opinion they must have different compatible.

Best 

Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

[Hoegeun Kwon]

On 09/10/2017 04:57 AM, kbuild test robot wrote:

Hi Hoegeun,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.13 next-20170908]
[cannot apply to drm-exynos/exynos-drm/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hoegeun-Kwon/drm-exynos-gsc-Support-the-hardware-rotation-limits/20170910-015155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 make.cross ARCH=arm

All errors (new ones prefixed by >>):


Error: arch/arm/boot/dts/exynos5250.dtsi:640.40-41 syntax error

FATAL ERROR: Unable to parse input tree


Thank you for your check.

This problem was caused by typos.
ver3 has been modified.

Best regards,
Hoegeun



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


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

[Bug 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
(In reply to Niklas Haas from comment #1)
> Seems like this is an expected behavior when TearFree is disabled. Manually
> enabling TearFree in xorg.conf appears to solve my issue.

You can dynamically enable tearfree per output using randr rather than messing
with your xorg.conf.

-- 
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 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

Niklas Haas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

-- 
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 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

--- Comment #2 from Niklas Haas  ---
(Including the P.s., I might add)

-- 
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 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

--- Comment #1 from Niklas Haas  ---
Seems like this is an expected behavior when TearFree is disabled. Manually
enabling TearFree in xorg.conf appears to solve my issue.

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

Re: [PATCH v3 0/2] drm/edid: transparent low-level override/firmware EDIDs

[Abdiel Janulgue]

On 09/12/2017 11:19 AM, Jani Nikula wrote:
> Patch 1 is v3 of [1]. There are no functional changes to the previous
> version, just a rebase and a slight refresh of the commit message and
> comments. I think the conclusion from the discussion was that this
> should work just fine. At least one user reported this helped with their
> audio woes with firmware EDID.
> 
> Patch 2 is an attempt to mitigate the problem of moving the
> edid_firmware module parameter from drm_kms_helper to drm. Not sure if
> it's too much or too little or just right. Need input here. Pedantically
> it should be part of patch 1, but this division should be easier to
> grasp in review.
> 
> BR,
> Jani.
> 
> 
> [1] 
> http://patchwork.freedesktop.org/patch/msgid/1487344854-18777-5-git-send-email-jani.nik...@intel.com
> 
> Cc: Abdiel Janulgue 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 

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

Re: [PATCH 1/2] drm: bridge: Add bindings for TI THS8134

[Laurent Pinchart]

Hi Linus,

Thank you for the patch.

On Friday, 1 September 2017 12:40:37 EEST Linus Walleij wrote:
> This adds device tree bindings for the Texas Instruments
> THS8134A and THS8134B VGA DACs by extending and renaming the
> existing bindings for THS8135.
> 
> These DACs are used for the VGA outputs on the ARM reference
> designs such as Integrator, Versatile and RealView.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Bartosz Golaszewski 
> Signed-off-by: Linus Walleij 
> ---
>  .../display/bridge/{ti,ths8135.txt => ti,ths813x.txt}| 12 ++---
>  1 file changed, 8 insertions(+), 4 deletions(-)
>  rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt =>
> ti,ths813x.txt} (73%)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> similarity index 73%
> rename from Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> rename to Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> index 6ec1a880ac18..608435f04796 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> @@ -1,11 +1,15 @@
> -THS8135 Video DAC
> --
> +THS8134 and THS8135 Video DAC
> +-
> 
> -This is the binding for Texas Instruments THS8135 Video DAC bridge.
> +This is the binding for Texas Instruments THS8134A, THS8134B and THS8135
> +Video DAC bridge.
> 
>  Required properties:
> 
> -- compatible: Must be "ti,ths8135"
> +- compatible: Must be one of
> +  "ti,ths8134a"
> +  "ti,ths8134b"
> +  "ti,ths8135"

As mentioned in the review of patch 2/2, would it make sense to also introduce 
a ti,ths813x compatible string ? I haven't checked the datasheets so the 
answer might very well be no.

>  Required nodes:


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/2] drm: bridge: Add THS8134A/B support to dumb VGA DAC

[Laurent Pinchart]

Hi Linus,

Thank you for the patch.

On Friday, 1 September 2017 12:40:58 EEST Linus Walleij wrote:
> This extends the dumb VGA DAC bridge to handle the THS8134A
> and THS8134B VGA DACs in addition to those already handled.
> 
> The THS8134A, THS8134B and as it turns out also THS8135 need to
> have data clocked out at the negative edge of the clock pulse,
> since they clock it into the DAC at the positive edge (so by
> then it needs to be stable) so we need some extra logic to flag
> this on the connector to the driver.
> 
> The semantics of the flag DRM_BUS_FLAG_PIXDATA_NEGEDGE in
>  clearly indicates that this flag tells
> when to *drive* the data, not when the receiver *reads* it,
> so the TI variants needs to be handled like this.
> 
> Introduce a variant struct and contain the information there,
> and add a bit of helpful comments about how this works so
> people will get it right when adding new DACs or connectiong
> new display drivers to DACs.
> 
> The fact that THS8135 might be working on some systems today
> is probably due to the fact that the display driver cannot
> configure when the data is clocked out and the electronics
> have simply been designed around it so it works anyways.
> 
> The phenomenon is very real on the ARM reference designs using
> PL111 where the hardware can control which edge to push out
> the data.
> 
> Cc: Laurent Pinchart 
> Cc: Bartosz Golaszewski 
> Cc: Maxime Ripard 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpu/drm/bridge/dumb-vga-dac.c | 62 ++--
>  1 file changed, 59 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 831a606c4706..6c2fdcb4fde1
> 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -12,6 +12,7 @@
> 
>  #include 
>  #include 
> +#include 

Nitpicking, could you keep header files alphabetically sorted ?

>  #include 
> 
>  #include 
> @@ -19,9 +20,20 @@
>  #include 
>  #include 
> 
> +/**
> + * struct vga_dac_variant - characteristics of the DAC

Nitpicking again, I'd call that vga_dac_info, but it's up to you.

> + * @posedge_clk: this DAC latches data into the DAC on the positive
> + *   edge of the clock pulse, which means that display controllers
> + *   need to clock it out on the negative edge
> + */
> +struct vga_dac_variant {
> + bool posedge_clk;

How about using DRM_BUS_FLAG_PIXDATA_NEGEDGE and DRM_BUS_FLAG_PIXDATA_POSEDGE 
explicitly instead of a bool ? For additional readability you could also 
rename the field to clk_edge_latch (or something similar), to remove the 
drive/latch ambiguity.

> +};
> +
>  struct dumb_vga {
>   struct drm_bridge   bridge;
>   struct drm_connectorconnector;
> + struct vga_dac_variant const *variant;
> 
>   struct i2c_adapter  *ddc;
>   struct regulator*vdd;
> @@ -67,6 +79,18 @@ static int dumb_vga_get_modes(struct drm_connector
> *connector) /* And prefer a mode pretty much anyone can handle */
>   drm_set_preferred_mode(connector, 1024, 768);
> 
> + if (vga->variant->posedge_clk)
> + /*
> +  * If the DAC latches the data into its registers on the
> +  * positive edge of the clock, the display driver needs to
> +  * drive the data out on the negative edge so it is
> +  * stable at the positive edge, so as to avoid flicker.

That's only true if there's no inverter on the board :-) I wonder how that 
could be modelled though.

> +  * Tell the driver that we want data on the negative edge
> +  */
> + connector->display_info.bus_flags |=
> + DRM_BUS_FLAG_PIXDATA_NEGEDGE;
> +
>   return ret;
>  }
> 
> @@ -183,6 +207,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
>   if (!vga)
>   return -ENOMEM;
>   platform_set_drvdata(pdev, vga);
> + vga->variant = of_device_get_match_data(>dev);
> 
>   vga->vdd = devm_regulator_get_optional(>dev, "vdd");
>   if (IS_ERR(vga->vdd)) {
> @@ -226,10 +251,41 @@ static int dumb_vga_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> +static const struct vga_dac_variant default_dac_variant = {
> + /*
> +  * These DACs read data on the negative edge. For example in the
> +  * ADV7123 datasheet (revision D, page 8) there is a timing diagram
> +  * making this clear.
> +  */
> + .posedge_clk = false,
> +};
> +
> +static const struct vga_dac_variant ti_ths_dac_variant = {
> + /* The TI DACs read the data on the positive edge of the CLK */
> + .posedge_clk = true,
> +};
> +
>  static const struct of_device_id dumb_vga_match[] = {
> - { .compatible = "dumb-vga-dac" },
> - { .compatible = "adi,adv7123" },
> - { .compatible = 

Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Laurent Pinchart]

Hi Hean Loong,

On Monday, 4 September 2017 09:09:11 EEST Ong, Hean Loong wrote:
> On Mon, 2017-08-28 at 13:06 +0800, Ong, Hean Loong wrote:
> > On Thu, 2017-08-24 at 12:39 +0300, Laurent Pinchart wrote:
> >> On Thursday, 24 August 2017 08:41:50 EEST Ong, Hean Loong wrote:
> >>> 
> >>> Hi Laurent,
> >>> 
> >>> I removed the examples for the HDMI in the draft below. The
> >>> connections between the VIP and Display Port IP or any display
> >>> connector are determined by HW logic. There are currently no SW
> >>> defined encoders or connectors that is connected to the AVALON-ST
> >>> other than the Intel VIP Frame Buffer II. Therefore there are no
> >>> examples for the Display Port encoder and connector.
> >> 
> >> But there must be an encoder, even if its default configuration
> >> makes it usable without a softwarer driver at the moment. As the
> >> encoder is there in hardware, it should be described in DT.
> > 
> > I attach some links regarding the simple example designs for the
> > Display Port IP
> > 
> > The link below has a example design of how the VIP is built along
> > with the Display Port IP  into the FPGA connected to the DDR RAM accessed
> > by ARM or any controller. Please look at the Introduction section of the
> > link below
> > http://www.alterawiki.com/wiki/DisplayPort_Design_Example_14.0_(RX_an
> > d_TX)#DisplayPort_IP_Core
> > 
> > The proposed design in the link above and the design we are
> > implementing are almost the same (FPGA part)
> > That the Intel(Altera) FPGA VIP is the sole interface for the ARM
> > controller to connect to via memory mapping on the DDR
> > 
> > Please go to Source Functional Description section in the PDF below.
> > It has information on how the encoder is built for the FPGA design of the
> > Display Port
> > https://www.altera.com/ja_JP/pdfs/literature/ug/ug_displayport.pdf
> > 
> > More information on the Display Port IP encoder could be found in the
> > link below. The Tx Transceiver interface has some information on how the
> > source clocks works in the FPGA tranceiver
> > https://www.altera.com/documentation/hco1410462777019.html#hco1410462
> > 323311
> 
> Would the information provided in the above links suffice to explain
> the relationship between DDR, VIP and Display Port IP ?

It does, thank you, and sorry for the late reply.

The documents you've provided show that the Display Port transmitter is an IP 
core in the FPGA, connected to the VIP output, and configurable from the ARM 
side through memory-mapped registers. It should thus be modelled in DT with a 
separate DT node, and connections should be modelled using the OF graph DT 
bindings, like you've done in the latest version of your patch series.

The Display Port transmitter should also have DT bindings, and a Linux kernel 
driver, but that can be submitted in a separate patch series.

-- 
Regards,

Laurent Pinchart

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

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

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

--- Comment #6 from Justin Mitzel  ---
Created attachment 134182
  --> https://bugs.freedesktop.org/attachment.cgi?id=134182=edit
Output of journalctl -k

Thought I'd add this for good measure.

-- 
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 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

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

--- Comment #5 from Justin Mitzel  ---
Created attachment 134181
  --> https://bugs.freedesktop.org/attachment.cgi?id=134181=edit
Current Xorg log

-- 
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 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

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

--- Comment #4 from Justin Mitzel  ---
Created attachment 134180
  --> https://bugs.freedesktop.org/attachment.cgi?id=134180=edit
The Dmesg output

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

Re: [PATCH v2 4/6] dt-bindings: host1x: Add Tegra186 information

[Rob Herring]

On Tue, Sep 05, 2017 at 11:43:04AM +0300, Mikko Perttunen wrote:
> Add the Tegra186-specific hypervisor-related register range
> properties.
> 
> Signed-off-by: Mikko Perttunen 
> ---
> v2:
> - Dropped incorrect note about cells properties.
> 
>  .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt   | 4 
> 
>  1 file changed, 4 insertions(+)

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

Re: [PATCHv7] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite

[Rob Herring]

On Tue, Sep 05, 2017 at 03:12:30PM +0800, Hean-Loong, Ong wrote:
> From: Ong Hean Loong 
> 
> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height and memory port width.
> The device tree binding only supports the Intel Arria10
> devkit and its variants. Vendor name retained as altr.
> 
> Signed-off-by: Ong, Hean Loong 
> ---

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

[Bug 102552] Null dereference due to not checking return value of util_format_description

[bugzilla-daemon]

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

--- Comment #8 from Pauk Denis  ---
I have sent version patch to mesa-...@lists.freedesktop.org.

https://patchwork.freedesktop.org/series/30086/

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

[PATCH libdrm 3/4] amdgpu: add amdgpu_cs_syncobj_wait

[Marek Olšák]

From: Marek Olšák 

---
 amdgpu/amdgpu.h| 20 
 amdgpu/amdgpu_cs.c | 12 
 2 files changed, 32 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b44b9b6..979acfc 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1354,6 +1354,26 @@ int amdgpu_cs_destroy_syncobj(amdgpu_device_handle dev,
  uint32_t syncobj);
 
 /**
+ *  Wait for one or all sync objects to signal.
+ *
+ * \param   dev- \c [in] self-explanatory
+ * \param   handles - \c [in] array of sync object handles
+ * \param   num_handles - \c [in] self-explanatory
+ * \param   timeout_nsec - \c [in] self-explanatory
+ * \param   flags   - \c [in] a bitmask of DRM_SYNCOBJ_WAIT_FLAGS_*
+ * \param   first_signaled - \c [in] self-explanatory
+ *
+ * \return   0 on success\n
+ *  -ETIME - Timeout
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
+  uint32_t *handles, unsigned num_handles,
+  int64_t timeout_nsec, unsigned flags,
+  uint32_t *first_signaled);
+
+/**
  *  Export kernel sync object to shareable fd.
  *
  * \param   dev   - \c [in] device handle
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 4a05536..2cde7bf 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -615,6 +615,18 @@ int amdgpu_cs_destroy_syncobj(amdgpu_device_handle dev,
return drmSyncobjDestroy(dev->fd, handle);
 }
 
+int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
+  uint32_t *handles, unsigned num_handles,
+  int64_t timeout_nsec, unsigned flags,
+  uint32_t *first_signaled)
+{
+   if (NULL == dev)
+   return -EINVAL;
+
+   return drmSyncobjWait(dev->fd, handles, num_handles, timeout_nsec,
+ flags, first_signaled);
+}
+
 int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
 uint32_t handle,
 int *shared_fd)
-- 
2.7.4

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

[PATCH libdrm 2/4] drm: add drmSyncobjWait wrapper

[Marek Olšák]

From: Marek Olšák 

---
 include/drm/drm.h | 24 
 xf86drm.c | 22 ++
 xf86drm.h |  3 +++
 3 files changed, 49 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index bf3674a..4da1667 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -694,6 +694,7 @@ struct drm_prime_handle {
 
 struct drm_syncobj_create {
__u32 handle;
+#define DRM_SYNCOBJ_CREATE_SIGNALED (1 << 0)
__u32 flags;
 };
 
@@ -712,6 +713,24 @@ struct drm_syncobj_handle {
__u32 pad;
 };
 
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+struct drm_syncobj_wait {
+   __u64 handles;
+   /* absolute timeout */
+   __s64 timeout_nsec;
+   __u32 count_handles;
+   __u32 flags;
+   __u32 first_signaled; /* only valid when not waiting all */
+   __u32 pad;
+};
+
+struct drm_syncobj_array {
+   __u64 handles;
+   __u32 count_handles;
+   __u32 pad;
+};
+
 #if defined(__cplusplus)
 }
 #endif
@@ -834,6 +853,9 @@ extern "C" {
 #define DRM_IOCTL_SYNCOBJ_DESTROY  DRM_IOWR(0xC0, struct 
drm_syncobj_destroy)
 #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)
+#define DRM_IOCTL_SYNCOBJ_WAIT DRM_IOWR(0xC3, struct drm_syncobj_wait)
+#define DRM_IOCTL_SYNCOBJ_RESETDRM_IOWR(0xC4, struct 
drm_syncobj_array)
+#define DRM_IOCTL_SYNCOBJ_SIGNAL   DRM_IOWR(0xC5, struct drm_syncobj_array)
 
 /**
  * Device specific ioctls should only be in their respective headers
@@ -876,6 +898,7 @@ struct drm_event_vblank {
 };
 
 /* typedef area */
+#ifndef __KERNEL__
 typedef struct drm_clip_rect drm_clip_rect_t;
 typedef struct drm_drawable_info drm_drawable_info_t;
 typedef struct drm_tex_region drm_tex_region_t;
@@ -917,6 +940,7 @@ typedef struct drm_agp_binding drm_agp_binding_t;
 typedef struct drm_agp_info drm_agp_info_t;
 typedef struct drm_scatter_gather drm_scatter_gather_t;
 typedef struct drm_set_version drm_set_version_t;
+#endif
 
 #if defined(__cplusplus)
 }
diff --git a/xf86drm.c b/xf86drm.c
index 6ea0112..8a32717 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4225,3 +4225,25 @@ int drmSyncobjExportSyncFile(int fd, uint32_t handle, 
int *sync_file_fd)
 *sync_file_fd = args.fd;
 return 0;
 }
+
+int drmSyncobjWait(int fd, uint32_t *handles, unsigned num_handles,
+  int64_t timeout_nsec, unsigned flags,
+  uint32_t *first_signaled)
+{
+   struct drm_syncobj_wait args;
+   int ret;
+
+   memclear(args);
+   args.handles = (intptr_t)handles;
+   args.timeout_nsec = timeout_nsec;
+   args.count_handles = num_handles;
+   args.flags = flags;
+
+   ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
+   if (ret < 0)
+   return ret;
+
+   if (first_signaled)
+   *first_signaled = args.first_signaled;
+   return ret;
+}
diff --git a/xf86drm.h b/xf86drm.h
index 2855a3e..ea650ef 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -860,6 +860,9 @@ extern int drmSyncobjFDToHandle(int fd, int obj_fd, 
uint32_t *handle);
 
 extern int drmSyncobjImportSyncFile(int fd, uint32_t handle, int sync_file_fd);
 extern int drmSyncobjExportSyncFile(int fd, uint32_t handle, int 
*sync_file_fd);
+extern int drmSyncobjWait(int fd, uint32_t *handles, unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
 
 #if defined(__cplusplus)
 }
-- 
2.7.4

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

[PATCH libdrm 1/4] amdgpu: add sync_file import and export functions

[Marek Olšák]

From: Marek Olšák 

---
 amdgpu/amdgpu.h| 30 ++
 amdgpu/amdgpu_cs.c | 20 
 2 files changed, 50 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 238b1aa..b44b9b6 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1383,6 +1383,36 @@ int amdgpu_cs_import_syncobj(amdgpu_device_handle dev,
 uint32_t *syncobj);
 
 /**
+ *  Export kernel sync object to a sync_file.
+ *
+ * \param   dev   - \c [in] device handle
+ * \param   syncobj- \c [in] sync object handle
+ * \param   sync_file_fd - \c [out] sync_file file descriptor.
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_export_sync_file(amdgpu_device_handle dev,
+  uint32_t syncobj,
+  int *sync_file_fd);
+
+/**
+ *  Import kernel sync object from a sync_file.
+ *
+ * \param   dev   - \c [in] device handle
+ * \param   syncobj- \c [in] sync object handle
+ * \param   sync_file_fd - \c [in] sync_file file descriptor.
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
+  uint32_t syncobj,
+  int sync_file_fd);
+
+/**
  *  Submit raw command submission to kernel
  *
  * \param   dev   - \c [in] device handle
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index dfba875..4a05536 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -635,6 +635,26 @@ int amdgpu_cs_import_syncobj(amdgpu_device_handle dev,
return drmSyncobjFDToHandle(dev->fd, shared_fd, handle);
 }
 
+int amdgpu_cs_syncobj_export_sync_file(amdgpu_device_handle dev,
+  uint32_t syncobj,
+  int *sync_file_fd)
+{
+   if (NULL == dev)
+   return -EINVAL;
+
+   return drmSyncobjExportSyncFile(dev->fd, syncobj, sync_file_fd);
+}
+
+int amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
+  uint32_t syncobj,
+  int sync_file_fd)
+{
+   if (NULL == dev)
+   return -EINVAL;
+
+   return drmSyncobjImportSyncFile(dev->fd, syncobj, sync_file_fd);
+}
+
 int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
 amdgpu_context_handle context,
 amdgpu_bo_list_handle bo_list_handle,
-- 
2.7.4

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

[PATCH libdrm 4/4] amdgpu: add amdgpu_cs_fence_to_handle

[Marek Olšák]

From: Marek Olšák 

---
 amdgpu/amdgpu.h  | 14 ++
 amdgpu/amdgpu_cs.c   | 22 ++
 include/drm/amdgpu_drm.h | 21 +
 3 files changed, 57 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 979acfc..23cde10 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1433,6 +1433,20 @@ int 
amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
   int sync_file_fd);
 
 /**
+ * Export an amdgpu fence as a handle (syncobj or fd).
+ *
+ * \param what AMDGPU_FENCE_TO_HANDLE_GET_{SYNCOBJ, FD}
+ * \param out_handle   returned handle
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ */
+int amdgpu_cs_fence_to_handle(amdgpu_device_handle dev,
+ struct amdgpu_cs_fence *fence,
+ uint32_t what,
+ uint32_t *out_handle);
+
+/**
  *  Submit raw command submission to kernel
  *
  * \param   dev   - \c [in] device handle
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 2cde7bf..9577d5c 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -713,3 +713,25 @@ void amdgpu_cs_chunk_fence_to_dep(struct amdgpu_cs_fence 
*fence,
dep->ctx_id = fence->context->id;
dep->handle = fence->fence;
 }
+
+int amdgpu_cs_fence_to_handle(amdgpu_device_handle dev,
+ struct amdgpu_cs_fence *fence,
+ uint32_t what,
+ uint32_t *out_handle)
+{
+   union drm_amdgpu_fence_to_handle fth = {0};
+   int r;
+
+   fth.in.fence.ctx_id = fence->context->id;
+   fth.in.fence.ip_type = fence->ip_type;
+   fth.in.fence.ip_instance = fence->ip_instance;
+   fth.in.fence.ring = fence->ring;
+   fth.in.fence.seq_no = fence->fence;
+   fth.in.what = what;
+
+   r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_FENCE_TO_HANDLE,
+   , sizeof(fth));
+   if (r == 0)
+   *out_handle = fth.out.handle;
+   return r;
+}
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index d9aa4a3..00f1b81 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -52,6 +52,7 @@ extern "C" {
 #define DRM_AMDGPU_GEM_USERPTR 0x11
 #define DRM_AMDGPU_WAIT_FENCES 0x12
 #define DRM_AMDGPU_VM  0x13
+#define DRM_AMDGPU_FENCE_TO_HANDLE 0x15
 
 #define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
 #define DRM_IOCTL_AMDGPU_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -67,6 +68,7 @@ extern "C" {
 #define DRM_IOCTL_AMDGPU_GEM_USERPTR   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
 #define DRM_IOCTL_AMDGPU_WAIT_FENCES   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
 #define DRM_IOCTL_AMDGPU_VMDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_VM, union drm_amdgpu_vm)
+#define DRM_IOCTL_AMDGPU_FENCE_TO_HANDLE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_FENCE_TO_HANDLE, union drm_amdgpu_fence_to_handle)
 
 #define AMDGPU_GEM_DOMAIN_CPU  0x1
 #define AMDGPU_GEM_DOMAIN_GTT  0x2
@@ -87,6 +89,8 @@ extern "C" {
 #define AMDGPU_GEM_CREATE_SHADOW   (1 << 4)
 /* Flag that allocating the BO should use linear VRAM */
 #define AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS  (1 << 5)
+/* Flag that BO is always valid in this VM */
+#define AMDGPU_GEM_CREATE_VM_ALWAYS_VALID  (1 << 6)
 
 struct drm_amdgpu_gem_create_in  {
/** the requested memory size */
@@ -513,6 +517,20 @@ struct drm_amdgpu_cs_chunk_sem {
__u32 handle;
 };
 
+#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ 0
+#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD  1
+#define AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD2
+
+union drm_amdgpu_fence_to_handle {
+   struct {
+   struct drm_amdgpu_fence fence;
+   __u32 what;
+   } in;
+   struct {
+   __u32 handle;
+   } out;
+};
+
 struct drm_amdgpu_cs_chunk_data {
union {
struct drm_amdgpu_cs_chunk_ib   ib_data;
@@ -764,6 +782,7 @@ struct drm_amdgpu_info_device {
__u64 max_memory_clock;
/* cu information */
__u32 cu_active_number;
+   /* NOTE: cu_ao_mask is INVALID, DON'T use it */
__u32 cu_ao_mask;
__u32 cu_bitmap[4][4];
/** Render backend pipe mask. One render backend is CB+DB. */
@@ -818,6 +837,8 @@ struct drm_amdgpu_info_device {
/* max gs wavefront per vgt*/
__u32 max_gs_waves_per_vgt;
__u32 _pad1;
+   /* always on cu bitmap */
+   __u32 cu_ao_bitmap[4][4];
 };
 
 struct drm_amdgpu_info_hw_ip {
-- 
2.7.4

___
dri-devel mailing list

[PATCH 1/3] drm/syncobj: extract two helpers from drm_syncobj_create

[Marek Olšák]

From: Marek Olšák 

For amdgpu.

drm_syncobj_create is renamed to drm_syncobj_create_as_handle, and new
helpers drm_syncobj_create and drm_syncobj_get_handle are added.

Signed-off-by: Marek Olšák 
---
 drivers/gpu/drm/drm_syncobj.c | 49 +++
 include/drm/drm_syncobj.h |  4 
 2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0422b8c..0bb1741 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -262,8 +262,14 @@ void drm_syncobj_free(struct kref *kref)
 }
 EXPORT_SYMBOL(drm_syncobj_free);
 
-static int drm_syncobj_create(struct drm_file *file_private,
- u32 *handle, uint32_t flags)
+/**
+ * drm_syncobj_create - create a new syncobj
+ * @out_syncobj: returned syncobj
+ * @flags: DRM_SYNCOBJ_* flags
+ * @fence: if non-NULL, the syncobj will represent this fence
+ */
+int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
+  struct dma_fence *fence)
 {
int ret;
struct drm_syncobj *syncobj;
@@ -284,6 +290,25 @@ static int drm_syncobj_create(struct drm_file 
*file_private,
}
}
 
+   if (fence)
+   drm_syncobj_replace_fence(syncobj, fence);
+
+   *out_syncobj = syncobj;
+   return 0;
+}
+EXPORT_SYMBOL(drm_syncobj_create);
+
+/**
+ * drm_syncobj_get_handle - get a handle from a syncobj
+ */
+int drm_syncobj_get_handle(struct drm_file *file_private,
+  struct drm_syncobj *syncobj, u32 *handle)
+{
+   int ret;
+
+   /* take a reference to put in the idr */
+   drm_syncobj_get(syncobj);
+
idr_preload(GFP_KERNEL);
spin_lock(_private->syncobj_table_lock);
ret = idr_alloc(_private->syncobj_idr, syncobj, 1, 0, GFP_NOWAIT);
@@ -299,6 +324,22 @@ static int drm_syncobj_create(struct drm_file 
*file_private,
*handle = ret;
return 0;
 }
+EXPORT_SYMBOL(drm_syncobj_get_handle);
+
+static int drm_syncobj_create_as_handle(struct drm_file *file_private,
+   u32 *handle, uint32_t flags)
+{
+   int ret;
+   struct drm_syncobj *syncobj;
+
+   ret = drm_syncobj_create(, flags, NULL);
+   if (ret)
+   return ret;
+
+   ret = drm_syncobj_get_handle(file_private, syncobj, handle);
+   drm_syncobj_put(syncobj);
+   return ret;
+}
 
 static int drm_syncobj_destroy(struct drm_file *file_private,
   u32 handle)
@@ -522,8 +563,8 @@ drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
if (args->flags & ~DRM_SYNCOBJ_CREATE_SIGNALED)
return -EINVAL;
 
-   return drm_syncobj_create(file_private,
- >handle, args->flags);
+   return drm_syncobj_create_as_handle(file_private,
+   >handle, args->flags);
 }
 
 int
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index c00fee5..e7f0035 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -136,5 +136,9 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
   u32 handle,
   struct dma_fence **fence);
 void drm_syncobj_free(struct kref *kref);
+int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
+  struct dma_fence *fence);
+int drm_syncobj_get_handle(struct drm_file *file_private,
+  struct drm_syncobj *syncobj, u32 *handle);
 
 #endif
-- 
2.7.4

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

[PATCH 2/3] drm/syncobj: add a new helper drm_syncobj_get_fd

[Marek Olšák]

From: Marek Olšák 

Signed-off-by: Marek Olšák 
---
 drivers/gpu/drm/drm_syncobj.c | 33 +++--
 include/drm/drm_syncobj.h |  1 +
 2 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0bb1741..62adc7a 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -386,33 +386,38 @@ static int drm_syncobj_alloc_file(struct drm_syncobj 
*syncobj)
return 0;
 }
 
-static int drm_syncobj_handle_to_fd(struct drm_file *file_private,
-   u32 handle, int *p_fd)
+int drm_syncobj_get_fd(struct drm_syncobj *syncobj, int *p_fd)
 {
-   struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
int ret;
int fd;
 
-   if (!syncobj)
-   return -EINVAL;
-
fd = get_unused_fd_flags(O_CLOEXEC);
-   if (fd < 0) {
-   drm_syncobj_put(syncobj);
+   if (fd < 0)
return fd;
-   }
 
if (!syncobj->file) {
ret = drm_syncobj_alloc_file(syncobj);
-   if (ret)
-   goto out_put_fd;
+   if (ret) {
+   put_unused_fd(fd);
+   return ret;
+   }
}
fd_install(fd, syncobj->file);
-   drm_syncobj_put(syncobj);
*p_fd = fd;
return 0;
-out_put_fd:
-   put_unused_fd(fd);
+}
+EXPORT_SYMBOL(drm_syncobj_get_fd);
+
+static int drm_syncobj_handle_to_fd(struct drm_file *file_private,
+   u32 handle, int *p_fd)
+{
+   struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
+   int ret;
+
+   if (!syncobj)
+   return -EINVAL;
+
+   ret = drm_syncobj_get_fd(syncobj, p_fd);
drm_syncobj_put(syncobj);
return ret;
 }
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index e7f0035..43e2f38 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -140,5 +140,6 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj, 
uint32_t flags,
   struct dma_fence *fence);
 int drm_syncobj_get_handle(struct drm_file *file_private,
   struct drm_syncobj *syncobj, u32 *handle);
+int drm_syncobj_get_fd(struct drm_syncobj *syncobj, int *p_fd);
 
 #endif
-- 
2.7.4

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

[PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Marek Olšák]

From: Marek Olšák 

for being able to convert an amdgpu fence into one of the handles.
Mesa will use this.

Signed-off-by: Marek Olšák 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 61 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
 include/uapi/drm/amdgpu_drm.h   | 16 +
 5 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index b5c8b90..c15fa93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1308,6 +1308,8 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void 
*data,
 int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
 int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp);
+int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
 int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, struct drm_file 
*filp);
 int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 7cb8a59..6dd719c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
  *Jerome Glisse 
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1311,6 +1312,66 @@ static struct dma_fence *amdgpu_cs_get_fence(struct 
amdgpu_device *adev,
return fence;
 }
 
+int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp)
+{
+   struct amdgpu_device *adev = dev->dev_private;
+   struct amdgpu_fpriv *fpriv = filp->driver_priv;
+   union drm_amdgpu_fence_to_handle *info = data;
+   struct dma_fence *fence;
+   struct drm_syncobj *syncobj;
+   struct sync_file *sync_file;
+   int fd, r;
+
+   if (amdgpu_kms_vram_lost(adev, fpriv))
+   return -ENODEV;
+
+   fence = amdgpu_cs_get_fence(adev, filp, >in.fence);
+   if (IS_ERR(fence))
+   return PTR_ERR(fence);
+
+   switch (info->in.what) {
+   case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ:
+   r = drm_syncobj_create(, 0, fence);
+   dma_fence_put(fence);
+   if (r)
+   return r;
+   r = drm_syncobj_get_handle(filp, syncobj, >out.handle);
+   drm_syncobj_put(syncobj);
+   return r;
+
+   case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD:
+   r = drm_syncobj_create(, 0, fence);
+   dma_fence_put(fence);
+   if (r)
+   return r;
+   r = drm_syncobj_get_fd(syncobj, (int*)>out.handle);
+   drm_syncobj_put(syncobj);
+   return r;
+
+   case AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD:
+   fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fd < 0) {
+   dma_fence_put(fence);
+   return fd;
+   }
+
+   sync_file = sync_file_create(fence);
+   dma_fence_put(fence);
+   if (!sync_file) {
+   put_unused_fd(fd);
+   return -ENOMEM;
+   }
+
+   fd_install(fd, sync_file->file);
+   info->out.handle = fd;
+   return 0;
+
+   default:
+   return -EINVAL;
+   }
+}
+
 /**
  * amdgpu_cs_wait_all_fence - wait on all fences to signal
  *
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index d01aca6..1e38411 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -70,9 +70,10 @@
  * - 3.18.0 - Export gpu always on cu bitmap
  * - 3.19.0 - Add support for UVD MJPEG decode
  * - 3.20.0 - Add support for local BOs
+ * - 3.21.0 - Add DRM_AMDGPU_FENCE_TO_HANDLE ioctl
  */
 #define KMS_DRIVER_MAJOR   3
-#define KMS_DRIVER_MINOR   20
+#define KMS_DRIVER_MINOR   21
 #define KMS_DRIVER_PATCHLEVEL  0
 
 int amdgpu_vram_limit = 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index d31777b..b09d315 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1021,6 +1021,7 @@ const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(AMDGPU_VM, amdgpu_vm_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(AMDGPU_BO_LIST, amdgpu_bo_list_ioctl, 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Pandiyan, Dhinakaran]

On Tue, 2017-09-12 at 19:08 +, Pandiyan, Dhinakaran wrote:
> On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > > > Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> > > > set power states for downstream sinks. Apart from giving us the ability
> > > > to set power state for individual sinks, this fixes the below test for
> > > > me
> > > > 
> > > > $ xrandr --display :0 --output DP-2-2-8 --off
> > > > $ xrandr --display :0 --output DP-2-2-1 --off
> > > > $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> > > > $ xrandr --display :0 --output DP-2-2-1 --auto
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Lyude 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_ddi.c| 6 --
> > > >  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
> > > >  2 files changed, 8 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 1da3bb2cc4b4..8aebacc0aa31 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > > intel_encoder *encoder,
> > > > intel_prepare_dp_ddi_buffers(encoder);
> > > >  
> > > > intel_ddi_init_dp_buf_reg(encoder);
> > > > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > > +   if (!link_mst)
> > > > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > > intel_dp_start_link_train(intel_dp);
> > > > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > > > intel_dp_stop_link_train(intel_dp);
> > > > @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
> > > > intel_encoder *intel_encoder,
> > > > if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> > > > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > >  
> > > > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > > +   if (old_crtc_state && old_conn_state)
> > > > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > 
> > > I would make that
> > > !intel_crtc_has_type(DP_MST)
> > > 

old_crtc_state, which intel_crtc_has_type() needs, is NULL for MST and
the reason Maarten provided in his commit is

" We also shouldn't pass crtc_state, because in that case the
  disabling sequence may potentially be different depending on
  which crtc is disabled last. Nice way to introduce bugs.
"
I am not 100% sure I understand the concern. But since that change was
intentional I guess we can use the NULL values, like I've done, to
identify the mst sinks. I am open to ideas.



> > > > }
> > > >  
> > > > val = I915_READ(DDI_BUF_CTL(port));
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > index 8e3aad0ea60b..81e63724e24b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > @@ -167,12 +167,11 @@ static void intel_mst_post_disable_dp(struct 
> > > > intel_encoder *encoder,
> > > > intel_dp->active_mst_links--;
> > > >  
> > > > intel_mst->connector = NULL;
> > > > -   if (intel_dp->active_mst_links == 0) {
> > > > +   if (intel_dp->active_mst_links == 0)
> > > > intel_dig_port->base.post_disable(_dig_port->base,
> > > >   NULL, NULL);
> > > > -
> > > > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > > -   }
> > > > +   drm_dp_send_power_updown_phy(_dp->mst_mgr, 
> > > > connector->port,
> > > > +false);
> > > 
> > > One thing that bothers me here is whether we'll start getting bogus link
> > > training requests during shutdown since we'll do the D3 only after the
> > > stream has been stopped. If you'll look at commit 7618138d8b40
> > > ("drm/i915/ddi: Avoid long delays during system suspend / eDP
> > > disabling") Imre explicitly moved the D3 earlier for SST to avoid this.
> > > 
> 
> Interesting, that patch makes a lot of sense.
> 
> > > Hmm. Actually by the time we call mst_post_disable() we should have
> > > deallocated the VC etc. so the current stream should be already
> > > terminated at that point. So I think we should be able to do the
> > > PHY_POWER_DOWN before we shut down the link, just like we do for SST.
> > 
> > Might also be nice to add comments near all the D3 calls to document
> > that the order we use is there to prevent the sink from complaining
> > about link loss when we shut down the link. Otherwise someone might
> > get tempted 

[Bug 196733] GM107 video card displays blank screen after 4.12 update with error EDID checksum

[bugzilla-daemon]

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

Liberty (mrlhwlibe...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #2 from Liberty (mrlhwlibe...@gmail.com) ---
Yes, verified working on 4.13. Closing this bug!

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Pandiyan, Dhinakaran]

On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > > Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> > > set power states for downstream sinks. Apart from giving us the ability
> > > to set power state for individual sinks, this fixes the below test for
> > > me
> > > 
> > > $ xrandr --display :0 --output DP-2-2-8 --off
> > > $ xrandr --display :0 --output DP-2-2-1 --off
> > > $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> > > $ xrandr --display :0 --output DP-2-2-1 --auto
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: Lyude 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c| 6 --
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
> > >  2 files changed, 8 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 1da3bb2cc4b4..8aebacc0aa31 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > intel_encoder *encoder,
> > >   intel_prepare_dp_ddi_buffers(encoder);
> > >  
> > >   intel_ddi_init_dp_buf_reg(encoder);
> > > - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > + if (!link_mst)
> > > + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > >   intel_dp_start_link_train(intel_dp);
> > >   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > >   intel_dp_stop_link_train(intel_dp);
> > > @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
> > > intel_encoder *intel_encoder,
> > >   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> > >   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > >  
> > > - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > + if (old_crtc_state && old_conn_state)
> > > + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > 
> > I would make that
> > !intel_crtc_has_type(DP_MST)
> > 
> > >   }
> > >  
> > >   val = I915_READ(DDI_BUF_CTL(port));
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 8e3aad0ea60b..81e63724e24b 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -167,12 +167,11 @@ static void intel_mst_post_disable_dp(struct 
> > > intel_encoder *encoder,
> > >   intel_dp->active_mst_links--;
> > >  
> > >   intel_mst->connector = NULL;
> > > - if (intel_dp->active_mst_links == 0) {
> > > + if (intel_dp->active_mst_links == 0)
> > >   intel_dig_port->base.post_disable(_dig_port->base,
> > > NULL, NULL);
> > > -
> > > - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > - }
> > > + drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
> > > +  false);
> > 
> > One thing that bothers me here is whether we'll start getting bogus link
> > training requests during shutdown since we'll do the D3 only after the
> > stream has been stopped. If you'll look at commit 7618138d8b40
> > ("drm/i915/ddi: Avoid long delays during system suspend / eDP
> > disabling") Imre explicitly moved the D3 earlier for SST to avoid this.
> > 

Interesting, that patch makes a lot of sense.

> > Hmm. Actually by the time we call mst_post_disable() we should have
> > deallocated the VC etc. so the current stream should be already
> > terminated at that point. So I think we should be able to do the
> > PHY_POWER_DOWN before we shut down the link, just like we do for SST.
> 
> Might also be nice to add comments near all the D3 calls to document
> that the order we use is there to prevent the sink from complaining
> about link loss when we shut down the link. Otherwise someone might
> get tempted to reorder things as a cleanup or something.
> 

Sure.

> > 
> > >  }
> > >  
> > >  static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
> > > @@ -197,6 +196,7 @@ static void intel_mst_pre_enable_dp(struct 
> > > intel_encoder *encoder,
> > >  
> > >   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > >  
> > > + drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
> > >   if (intel_dp->active_mst_links == 0)
> > >   intel_dig_port->base.pre_enable(_dig_port->base,
> > >   pipe_config, NULL);
> > > -- 
> > > 2.11.0
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
dri-devel mailing 

[Bug 102659] Radeon 7970M Lockup

[bugzilla-daemon]

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

--- Comment #3 from vilsol2...@gmail.com ---
To add to my original. I have been using this laptop on Win for a while, and it
still works just fine, so I am sure it is not the GPU at fault.

-- 
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 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

--- Comment #3 from Krzysztof Nowicki (kri...@op.pl) ---
(In reply to Gerd Hoffmann from comment #2)
> can you check whenever this patch fixes it?
> 
> https://www.kraxel.org/cgit/linux/commit/?h=drm-qxl-
> atomic=b16a0bb7a9d54d9dd256059b35adf6f96fddc22e

I have applied this patch against a clean 4.12.0 and unfortunately the problem
is still easily reproducible.

-- 
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/vmwgfx: remove DRM_ERROR message, stops log spamming

[Emil Velikov]

On 12 September 2017 at 18:47, Colin Ian King  wrote:
> On 12/09/17 18:42, Thomas Hellstrom wrote:
>> Hi, Colin,
>>
>> On 09/12/2017 07:35 PM, Colin King wrote:
>>> From: Colin Ian King 
>>>
>>> mmap'ing the device multiple times will spam the kernel log with the
>>> DRM_ERROR message about illegal mmap'ing the old fifo space.
>> How are you hitting this? Multiple mappings should be fine as long as
>> mapping offsets are correct,
>> so hitting this message should indicate that the user-space app is doing
>> something seriously wrong, and
>> having it present in the log should probably help more than it hurts.
>>
>> /Thomas
>
> Good question.  I hit similar issues with the drm qxl driver when
> running some kernel regression tests with stress-ng [1]. I realize this
> is an artificial test scenario so it is definitely not a typical
> use-case, however, sync the illegal mmapping will return -EINVAL the
> application will pick up that this is an error without the need of
> spotting it in the kernel log. And a user space application can perform
> many millions of these invalid mmaps causing kernel log spamming.
>
FWIW I'm the one to "blame" here - pointing Colin to drop the message.

Two reasons come to mind:
 - there is a unwritten rule that roughly says "user input should not
cause kernel log spam"
 - out of all the DRM drivers only QXL and VMWGFX print a message,
with a patch addressing the former

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

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Colin Ian King]

On 12/09/17 18:42, Thomas Hellstrom wrote:
> Hi, Colin,
> 
> On 09/12/2017 07:35 PM, Colin King wrote:
>> From: Colin Ian King 
>>
>> mmap'ing the device multiple times will spam the kernel log with the
>> DRM_ERROR message about illegal mmap'ing the old fifo space.
> How are you hitting this? Multiple mappings should be fine as long as
> mapping offsets are correct,
> so hitting this message should indicate that the user-space app is doing
> something seriously wrong, and
> having it present in the log should probably help more than it hurts.
> 
> /Thomas

Good question.  I hit similar issues with the drm qxl driver when
running some kernel regression tests with stress-ng [1]. I realize this
is an artificial test scenario so it is definitely not a typical
use-case, however, sync the illegal mmapping will return -EINVAL the
application will pick up that this is an error without the need of
spotting it in the kernel log. And a user space application can perform
many millions of these invalid mmaps causing kernel log spamming.

[1] http://kernel.ubuntu.com/~cking/stress-ng/

> 
> 
> 
>> Since
>> the mmap'ing will fail with an -EINVAL there is no need to emit this
>> message, so just remove it.
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> index e771091d2cd3..1e633c602fb1 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> @@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct
>> vm_area_struct *vma)
>>   struct drm_file *file_priv;
>>   struct vmw_private *dev_priv;
>>   -if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {
>> -DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
>> +if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
>>   return -EINVAL;
>> -}
>> file_priv = filp->private_data;
>>   dev_priv = vmw_priv(file_priv->minor->dev);
> 
> 

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

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Thomas Hellstrom]

Hi, Colin,

On 09/12/2017 07:35 PM, Colin King wrote:

From: Colin Ian King 

mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space.
How are you hitting this? Multiple mappings should be fine as long as 
mapping offsets are correct,
so hitting this message should indicate that the user-space app is doing 
something seriously wrong, and

having it present in the log should probably help more than it hurts.

/Thomas




Since
the mmap'ing will fail with an -EINVAL there is no need to emit this
message, so just remove it.

Signed-off-by: Colin Ian King 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index e771091d2cd3..1e633c602fb1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
struct drm_file *file_priv;
struct vmw_private *dev_priv;
  
-	if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {

-   DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
+   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
  
  	file_priv = filp->private_data;

dev_priv = vmw_priv(file_priv->minor->dev);



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

Re: [PATCHv3 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Ville Syrjälä]

On Mon, Sep 11, 2017 at 01:25:45PM +0200, Hans Verkuil wrote:
> 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 
> Tested-by: Carlos Santa 
> ---
>  drivers/gpu/drm/Kconfig  |  10 ++
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/drm_dp_cec.c | 301 
> +++
>  include/drm/drm_dp_helper.h  |  24 
>  4 files changed, 336 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83cb2a88c204..1f2708df5c4e 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -120,6 +120,16 @@ 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 "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> + select CEC_CORE
> + 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 they often do not hook up the CEC pin.
> +
>  config DRM_TTM
>   tristate
>   depends on DRM && MMU
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 24a066e1841c..c6552c62049e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -40,6 +40,7 @@ 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
>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
>  
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> new file mode 100644
> index ..b831bb72c932
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -0,0 +1,301 @@
> +/*
> + * 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 
> +
> +/*
> + * Unfortunately it turns out that we have a chicken-and-egg situation
> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> + * Parade PS176), but they do not wire up the CEC pin, thus making CEC
> + * useless.
> + *
> + * Sadly there is no way for this driver to know this. What happens is
> + * that a /dev/cecX device is created that is isolated and unable to see
> + * any of the other CEC devices. Quite literally the CEC wire is cut
> + * (or in this case, never connected in the first place).
> + *
> + * I suspect that the reason so few adapters support this is that this
> + * tunneling protocol was never supported by any OS. So there was no
> + * easy way of testing it, and no incentive to correctly wire up the
> + * CEC pin.
> + *
> + * Hopefully by creating this driver it will be easier for vendors to
> + * finally fix their adapters and test the CEC functionality.
> + *
> + * I keep a list of known working adapters here:
> + *
> + * https://hverkuil.home.xs4all.nl/cec-status.txt
> + *
> + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
> + * and is not yet listed there.
> + */
> +
> +/**
> + * DOC: dp cec helpers
> + *
> + * These functions take care of supporting the CEC-Tunneling-over-AUX
> + * feature of DisplayPort-to-HDMI adapters.
> + */
> +
> +static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
> +{
> + struct drm_dp_aux *aux 

[PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Colin King]

From: Colin Ian King 

mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space. Since
the mmap'ing will fail with an -EINVAL there is no need to emit this
message, so just remove it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index e771091d2cd3..1e633c602fb1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
struct drm_file *file_priv;
struct vmw_private *dev_priv;
 
-   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {
-   DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
+   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
 
file_priv = filp->private_data;
dev_priv = vmw_priv(file_priv->minor->dev);
-- 
2.14.1

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

[PATCH][V2] drm: qxl: remove pr_info message, stops log spamming

[Colin King]

From: Colin Ian King 

Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:

int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");

for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED, fd, 0);
if (m != MAP_FAILED)
munmap(m, 4096);
}
}

Stop the spamming by removing the pr_info message. Since the mmap'ing
returns -EINVAL there is no need for the pr_info message.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 7ecf8a4b9fe6..0f50c0b25a58 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -123,11 +123,8 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
struct qxl_device *qdev;
int r;
 
-   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
-   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
-   __func__, vma->vm_pgoff);
+   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
 
file_priv = filp->private_data;
qdev = file_priv->minor->dev->dev_private;
-- 
2.14.1

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

[Bug 102684] Monitor sometimes cuts to black after idling overnight

[bugzilla-daemon]

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

Bug ID: 102684
   Summary: Monitor sometimes cuts to black after idling overnight
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bugs.freedesk...@haasn.xyz

This is a rather difficult issue to reproduce. After leaving my PC idle
overnight (monitor turned off) and waking up the next day, I noticed an odd
issue started happening: The monitor started randomly cutting to black for a
second. It was not entirely unpredictable: it seemed to happen especially when
I triggered a seek in `mpv` -perhaps because this either recreated the
framebuffer or recreated some video textures, I'm not entirely sure. Restarting
X seems to have fixed it. The GPU was in power mode 'auto' overnight.

It sort of reminds me of similar issues I had with the nvidia drivers some
years ago, where leaving them in 'adaptive' performance mode overnight caused
them to fail switching frequencies the next day. Leaving them in 'performance'
mode overnight solved that issue; but it has also been since fixed. But that
was an issue actually related to the performance scaling, whereas this seems
more like an issue with the display connection in general.

I'm not sure where else to take this - I can try reproducing it the next time I
go to sleep, I guess, just to see if it will happen again. Apart from that, I'm
pretty much blind debuggin here.

Xorg version is 1.19.3, mesa version is 17.2, kernel version is 4.12.4, device
is a Sapphire RX 560.

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

[PATCH 4.4 25/31] drm/bridge: adv7511: Re-write the i2c address before EDID probing

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 

commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.

I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors on
HiKey.

Investigating further, it turns out that some of the register
state in hardware is getting lost, as the device registers are
reset when the chip is powered down.

Thus this patch simply re-writes the i2c address to the
ADV7511_REG_EDID_I2C_ADDR register to ensure its properly set
before we try to read the EDID data.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-7-git-send-email-john.stu...@linaro.org
Signed-off-by: Thong Ho 
Signed-off-by: Nhan Nguyen 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i2c/adv7511.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -51,6 +51,10 @@ struct adv7511 {
struct gpio_desc *gpio_pd;
 };
 
+static const int edid_i2c_addr = 0x7e;
+static const int packet_i2c_addr = 0x70;
+static const int cec_i2c_addr = 0x78;
+
 static struct adv7511 *encoder_to_adv7511(struct drm_encoder *encoder)
 {
return to_encoder_slave(encoder)->slave_priv;
@@ -606,6 +610,9 @@ static int adv7511_get_modes(struct drm_
 ADV7511_INT1_DDC_ERROR);
}
adv7511->current_edid_segment = -1;
+   /* Reset the EDID_I2C_ADDR register as it might be cleared */
+   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+   edid_i2c_addr);
}
 
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
@@ -881,10 +888,6 @@ static int adv7511_parse_dt(struct devic
return 0;
 }
 
-static const int edid_i2c_addr = 0x7e;
-static const int packet_i2c_addr = 0x70;
-static const int cec_i2c_addr = 0x78;
-
 static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id 
*id)
 {
struct adv7511_link_config link_config;


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

[PATCH 4.4 24/31] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 

commit 6d5104c5a6b56385426e15047050584794bb6254 upstream.

In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent noticed
that the DRM documentation suggests that
drm_kms_helper_hotplug_event() should be used instead.

Thus this patch replaces drm_helper_hpd_irq_event() with
drm_kms_helper_hotplug_event(), which requires we update the
connector.status entry and only call _hotplug_event() when the
status changes.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-3-git-send-email-john.stu...@linaro.org
Signed-off-by: Thong Ho 
Signed-off-by: Nhan Nguyen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i2c/adv7511.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -435,8 +435,21 @@ static bool adv7511_hpd(struct adv7511 *
 static void adv7511_hpd_work(struct work_struct *work)
 {
struct adv7511 *adv7511 = container_of(work, struct adv7511, hpd_work);
+   enum drm_connector_status status;
+   unsigned int val;
+   int ret;
+   ret = regmap_read(adv7511->regmap, ADV7511_REG_STATUS, );
+   if (ret < 0)
+   status = connector_status_disconnected;
+   else if (val & ADV7511_STATUS_HPD)
+   status = connector_status_connected;
+   else
+   status = connector_status_disconnected;
 
-   drm_helper_hpd_irq_event(adv7511->connector.dev);
+   if (adv7511->connector.status != status) {
+   adv7511->connector.status = status;
+   drm_kms_helper_hotplug_event(adv7511->connector.dev);
+   }
 }
 
 static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)


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

[PATCH 4.4 23/31] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 

commit 518cb7057a59b9441336d2e88a396d52b6ab0cce upstream.

I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't happening and the code would time out and fail.

Digging deeper, I found this was due to the fact that
IRQs were disabled as we were running in IRQ context from
the HPD signal.

Thus this patch changes the logic to handle the HPD signal
via a work_struct so we can be out of irq context.

With this patch, the EDID probing on hotplug does not time
out.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-2-git-send-email-john.stu...@linaro.org
Signed-off-by: Thong Ho 
Signed-off-by: Nhan Nguyen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i2c/adv7511.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -36,7 +36,10 @@ struct adv7511 {
bool edid_read;
 
wait_queue_head_t wq;
+   struct work_struct hpd_work;
+
struct drm_encoder *encoder;
+   struct drm_connector connector;
 
bool embedded_sync;
enum adv7511_sync_polarity vsync_polarity;
@@ -429,6 +432,13 @@ static bool adv7511_hpd(struct adv7511 *
return false;
 }
 
+static void adv7511_hpd_work(struct work_struct *work)
+{
+   struct adv7511 *adv7511 = container_of(work, struct adv7511, hpd_work);
+
+   drm_helper_hpd_irq_event(adv7511->connector.dev);
+}
+
 static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
 {
unsigned int irq0, irq1;
@@ -446,7 +456,7 @@ static int adv7511_irq_process(struct ad
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
 
if (process_hpd && irq0 & ADV7511_INT0_HDP && adv7511->encoder)
-   drm_helper_hpd_irq_event(adv7511->encoder->dev);
+   schedule_work(>hpd_work);
 
if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
adv7511->edid_read = true;
@@ -922,6 +932,8 @@ static int adv7511_probe(struct i2c_clie
if (!adv7511->i2c_edid)
return -ENOMEM;
 
+   INIT_WORK(>hpd_work, adv7511_hpd_work);
+
if (i2c->irq) {
init_waitqueue_head(>wq);
 


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

[Bug 102683] mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs

[bugzilla-daemon]

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

Bug ID: 102683
   Summary: mpv confuses the frequency scaling, leading to
freqyency flapping and missed vsyncs
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bugs.freedesk...@haasn.xyz

When rendering e.g. 24 Hz video on 60 Hz, `mpv`'s usage pattern consists of one
“fresh” frame (e.g. 20ms rendering time) followed by two “redraw” frames, each
of which are essentially just blits/mixes of already-rendered frames. This
results in a high-low-low-high-low GPU activity pattern.

Apparently this confuses the GPU frequency scaling quite heavily, which leads
to bad performance (under-scaling), inconsistent performance (“flapping” SCLK)
and missed vblanks (delayed/dropped frames and vsync jitter as measured by
mpv). If I `watch -n0.1 cat /sys/kernel/debug/dri/*/amdgpu_pm_info`, I can see
it varying wildly between `SCLK: 500 MHz` and `SCLK: 1000 MHz`, as the reported
`GPU Load:` varies between 0% and 100% from frame to frame. I can consistently
solve the issue by setting `power_dpm_force_performance_level` to `high`.

A graphical explanation of the issue, with mpv performance graphs:
`auto`: https://0x0.st/7qz.jpg
`high`: https://0x0.st/7qi.jpg

This is not just cosmetic, since it results in an increase in the number of
missed vsyncs, due to the occasional spikes. I've also had a different user
report significantly worse performance with 'auto', even more extreme than my
example: https://0x0.st/7Aw.jpg (Note: the third step in this image, going from
10k ms to 5k ms is due to switching from mesa 17.2 to 17.1; but that's an
unrelated, cosmetic bug). Using 'auto' makes mpv completely unusable for this
user.

I expect the solution would be adding a tiny bit of (top-weighted) smoothing of
this performance state / GPU load estimation across frames. The nvidia driver,
for example, gets this right: If I alter between 'high' performance and 'low'
performance states, it recognizes that and sticks to 'high' performance mode,
instead of varying the frequency wildly like amdgpu. This results in very flat
graphs, much like the 'high' screenshot I uploaded.

Kernel version is 4.12.4, mesa version is 17.2.0, device is a Sapphire RX 560.

-- 
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 1/2] drm: bridge: Add bindings for TI THS8134

[Rob Herring]

On Fri, Sep 01, 2017 at 11:40:37AM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Texas Instruments
> THS8134A and THS8134B VGA DACs by extending and renaming the
> existing bindings for THS8135.
> 
> These DACs are used for the VGA outputs on the ARM reference
> designs such as Integrator, Versatile and RealView.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Bartosz Golaszewski 
> Signed-off-by: Linus Walleij 
> ---
>  .../display/bridge/{ti,ths8135.txt => ti,ths813x.txt}| 12 
> 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>  rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt => 
> ti,ths813x.txt} (73%)

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

[Bug 102681] OpenGL applications not vsyncing correctly when the window size doesn't perfectly match the screen

[bugzilla-daemon]

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

Bug ID: 102681
   Summary: OpenGL applications not vsyncing correctly when the
window size doesn't perfectly match the screen
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bugs.freedesk...@haasn.xyz
QA Contact: dri-devel@lists.freedesktop.org

I'm not exactly sure how to debug this; but basically, when I run OpenGL
applications in windowed mode (i.e. not stretched over the entire rect), I get
misaligned vsync (horizontal tearing). It still syncs to the monitor rate - it
just misses the actual vblank by quite a bit.

The horizontal tear location depends on the size and position of the window.
For small enough window sizes, the issue becomes les pronounced and eventually
goes away completely. I can reproduce it in at least two applications - mpv (my
primary testing method) and glxgears (although it's more difficult to spot in
glxgears due to the less ideal motion). The easiest way for me to reproduce it
is by just running `mpv --no-config https://0x0.st/7AL.mkv`.

I've tested a couple of mesa versions ranging from 17.0 to git master and could
not identify a difference, so I'm not sure if it's a regression or just a plain
bug. I'm also not sure if it's an issue in mesa or in the GPU driver. I did
notice a lot of dmesg spam after startup, but that seems to be “normal”:

e.g.
[  +0.000304] DMAR: DRHD: handling fault status reg 2
[  +0.000102] DMAR: [DMA Read] Request device [04:00.0] fault addr f4001aa000
[fault reason 06] PTE Read access is not set
[  +0.000170] DMAR: [DMA Read] Request device [04:00.0] fault addr f4001af000
[fault reason 06] PTE Read access is not set
[  +0.000169] DMAR: [DMA Read] Request device [04:00.0] fault addr f4001b5000
[fault reason 06] PTE Read access is not set
...
[  +0.068389] amdgpu: [powerplay] [AVFS] Something is broken. See log!
[  +0.002866] amdgpu: [powerplay] Can't find requested voltage id in
vdd_dep_on_sclk table!
[  +0.001712] amdgpu: [powerplay] VDDCI is larger than max VDDCI in VDDCI
Voltage Table!
[  +0.000152] amdgpu: [powerplay] VDDCI is larger than max VDDCI in VDDCI
Voltage Table!

I also noticed this error showing up relatively often (several times a day,
even while the machine is not in use):

[Sep12 17:58] DMAR: DRHD: handling fault status reg 40
[Sep12 17:59] DMAR: DRHD: handling fault status reg 40

Not sure if that's related to anything. The device I'm using is a Sapphire RX
560, the kernel version is 4.12.4. I have no ~/.drirc and the `amdgpu` module
settings are all left default.

P.s. I also noticed a strange issue where starting mpv in fullscreen and then
dragging the window to be slightly bigger causes it to start miscalculating the
texture stride and dumping garbage data onto the screen. Unfortunately, I can't
take a screenshot. I'm not sure if this is related, or a separated issue, but
it may provide a hint.

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Ville Syrjälä]

On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> > set power states for downstream sinks. Apart from giving us the ability
> > to set power state for individual sinks, this fixes the below test for
> > me
> > 
> > $ xrandr --display :0 --output DP-2-2-8 --off
> > $ xrandr --display :0 --output DP-2-2-1 --off
> > $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> > $ xrandr --display :0 --output DP-2-2-1 --auto
> > 
> > Cc: Ville Syrjälä 
> > Cc: Lyude 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c| 6 --
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
> >  2 files changed, 8 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 1da3bb2cc4b4..8aebacc0aa31 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> >  
> > intel_ddi_init_dp_buf_reg(encoder);
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > +   if (!link_mst)
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > intel_dp_start_link_train(intel_dp);
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
> > intel_encoder *intel_encoder,
> > if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >  
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > +   if (old_crtc_state && old_conn_state)
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> 
> I would make that
> !intel_crtc_has_type(DP_MST)
> 
> > }
> >  
> > val = I915_READ(DDI_BUF_CTL(port));
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 8e3aad0ea60b..81e63724e24b 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -167,12 +167,11 @@ static void intel_mst_post_disable_dp(struct 
> > intel_encoder *encoder,
> > intel_dp->active_mst_links--;
> >  
> > intel_mst->connector = NULL;
> > -   if (intel_dp->active_mst_links == 0) {
> > +   if (intel_dp->active_mst_links == 0)
> > intel_dig_port->base.post_disable(_dig_port->base,
> >   NULL, NULL);
> > -
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > -   }
> > +   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
> > +false);
> 
> One thing that bothers me here is whether we'll start getting bogus link
> training requests during shutdown since we'll do the D3 only after the
> stream has been stopped. If you'll look at commit 7618138d8b40
> ("drm/i915/ddi: Avoid long delays during system suspend / eDP
> disabling") Imre explicitly moved the D3 earlier for SST to avoid this.
> 
> Hmm. Actually by the time we call mst_post_disable() we should have
> deallocated the VC etc. so the current stream should be already
> terminated at that point. So I think we should be able to do the
> PHY_POWER_DOWN before we shut down the link, just like we do for SST.

Might also be nice to add comments near all the D3 calls to document
that the order we use is there to prevent the sink from complaining
about link loss when we shut down the link. Otherwise someone might
get tempted to reorder things as a cleanup or something.

> 
> >  }
> >  
> >  static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
> > @@ -197,6 +196,7 @@ static void intel_mst_pre_enable_dp(struct 
> > intel_encoder *encoder,
> >  
> > DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> >  
> > +   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
> > if (intel_dp->active_mst_links == 0)
> > intel_dig_port->base.pre_enable(_dig_port->base,
> > pipe_config, NULL);
> > -- 
> > 2.11.0
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Ville Syrjälä]

On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> set power states for downstream sinks. Apart from giving us the ability
> to set power state for individual sinks, this fixes the below test for
> me
> 
> $ xrandr --display :0 --output DP-2-2-8 --off
> $ xrandr --display :0 --output DP-2-2-1 --off
> $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> $ xrandr --display :0 --output DP-2-2-1 --auto
> 
> Cc: Ville Syrjälä 
> Cc: Lyude 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
>  2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1da3bb2cc4b4..8aebacc0aa31 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!link_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_start_link_train(intel_dp);
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
> @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct intel_encoder 
> *intel_encoder,
>   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + if (old_crtc_state && old_conn_state)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);

I would make that
!intel_crtc_has_type(DP_MST)

>   }
>  
>   val = I915_READ(DDI_BUF_CTL(port));
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 8e3aad0ea60b..81e63724e24b 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -167,12 +167,11 @@ static void intel_mst_post_disable_dp(struct 
> intel_encoder *encoder,
>   intel_dp->active_mst_links--;
>  
>   intel_mst->connector = NULL;
> - if (intel_dp->active_mst_links == 0) {
> + if (intel_dp->active_mst_links == 0)
>   intel_dig_port->base.post_disable(_dig_port->base,
> NULL, NULL);
> -
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> - }
> + drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
> +  false);

One thing that bothers me here is whether we'll start getting bogus link
training requests during shutdown since we'll do the D3 only after the
stream has been stopped. If you'll look at commit 7618138d8b40
("drm/i915/ddi: Avoid long delays during system suspend / eDP
disabling") Imre explicitly moved the D3 earlier for SST to avoid this.

Hmm. Actually by the time we call mst_post_disable() we should have
deallocated the VC etc. so the current stream should be already
terminated at that point. So I think we should be able to do the
PHY_POWER_DOWN before we shut down the link, just like we do for SST.

>  }
>  
>  static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
> @@ -197,6 +196,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>  
>   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>  
> + drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
>   if (intel_dp->active_mst_links == 0)
>   intel_dig_port->base.pre_enable(_dig_port->base,
>   pipe_config, NULL);
> -- 
> 2.11.0

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

Re: [PATCH v3 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Rob Herring]

On Thu, Aug 31, 2017 at 05:55:19PM +0200, Boris Brezillon wrote:
> Document the bindings used for the Cadence DSI bridge.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v3:
> - Fix clock names in the example
> - Document how to represent DSI devices that are controller through
>   an external bus like I2C or SPI
> 
> Changes in v2:
> - None
> ---
>  .../bindings/display/bridge/cdns,dsi.txt   | 109 
> +
>  1 file changed, 109 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

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

Re: [PATCH V3 00/23] drm/etnaviv: support performance counters

[Christian Gmeiner]

Hi Lucas

2017-09-11 15:10 GMT+02:00 Lucas Stach :
> Hi Christian,
>
> Am Donnerstag, den 31.08.2017, 18:08 +0200 schrieb Christian Gmeiner:
>> 2017-08-25 11:06 GMT+02:00 Christian Gmeiner :
>
> [...]
>
>> It looks like I have screwed up patches 03 and 04 - used v1 ones
>> instead of v2 :/
>> I will send out a tested v4 series on Tuesday next week as I am
>> currently in Sweden
>> and my device @home did not survived a reboot.
>>
>> Sorry if I wasted somebody's time.
>
> Any news about this? Do you have a fully working stack available
> somewhere, so I can test/validate the kernel changes?
>

All v4 stuf is on github, was tested and v4 kernel patches send out.

greets
--
Christian Gmeiner, MSc

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

[PATCH V4 22/23] drm/etnaviv: enable debug registers on demand

[Christian Gmeiner]

Some performance register are debug register and they need to
be enabled in order to be functional.

Signed-off-by: Christian Gmeiner 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 04acc3a64c3c..05122761c7f3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1348,6 +1348,11 @@ static void sync_point_perfmon_sample_pre(struct 
etnaviv_gpu *gpu,
val &= ~VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
 
+   /* enable debug register */
+   val = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
+   val &= ~VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS;
+   gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, val);
+
sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
 }
 
@@ -1366,6 +1371,11 @@ static void sync_point_perfmon_sample_post(struct 
etnaviv_gpu *gpu,
*pmr->bo_vma = pmr->sequence;
}
 
+   /* disable debug register */
+   val = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
+   val |= VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS;
+   gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, val);
+
/* enable clock gating */
val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
val |= VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
-- 
2.13.5

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

[PATCH V4 23/23] drm/etnaviv: submit supports performance monitor requests

[Christian Gmeiner]

We increment the minor driver version so userspace can detect perfmon support.

Signed-off-by: Christian Gmeiner 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 536760a9fef3..eec6c00f7f80 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -550,7 +550,7 @@ static struct drm_driver etnaviv_drm_driver = {
.desc   = "etnaviv DRM",
.date   = "20151214",
.major  = 1,
-   .minor  = 1,
+   .minor  = 2,
 };
 
 /*
-- 
2.13.5

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

[PATCH V4 20/23] drm/etnaviv: add MC perf domain

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index fa9b5f4b0ccb..2345c71e164a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -347,6 +347,29 @@ static const struct etnaviv_pm_domain doms[] = {
_reg_read
}
}
+   },
+   {
+   .name = "MC",
+   .profile_read = VIVS_MC_PROFILE_MC_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG2,
+   .nr_signals = 3,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "TOTAL_READ_REQ_8B_FROM_PIPELINE",
+   
VIVS_MC_PROFILE_CONFIG2_MC_TOTAL_READ_REQ_8B_FROM_PIPELINE,
+   _reg_read
+   },
+   {
+   "TOTAL_READ_REQ_8B_FROM_IP",
+   
VIVS_MC_PROFILE_CONFIG2_MC_TOTAL_READ_REQ_8B_FROM_IP,
+   _reg_read
+   },
+   {
+   "TOTAL_WRITE_REQ_8B_FROM_PIPELINE",
+   
VIVS_MC_PROFILE_CONFIG2_MC_TOTAL_WRITE_REQ_8B_FROM_PIPELINE,
+   _reg_read
+   }
+   }
}
 };
 
-- 
2.13.5

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

[PATCH V4 19/23] drm/etnaviv: add TX perf domain

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 53 +++
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index ac92684ee7af..fa9b5f4b0ccb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -294,6 +294,59 @@ static const struct etnaviv_pm_domain doms[] = {
_reg_read
}
}
+   },
+   {
+   .name = "TX",
+   .profile_read = VIVS_MC_PROFILE_TX_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG1,
+   .nr_signals = 9,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "TOTAL_BILINEAR_REQUESTS",
+   
VIVS_MC_PROFILE_CONFIG1_TX_TOTAL_BILINEAR_REQUESTS,
+   _reg_read
+   },
+   {
+   "TOTAL_TRILINEAR_REQUESTS",
+   
VIVS_MC_PROFILE_CONFIG1_TX_TOTAL_TRILINEAR_REQUESTS,
+   _reg_read
+   },
+   {
+   "TOTAL_DISCARDED_TEXTURE_REQUESTS",
+   
VIVS_MC_PROFILE_CONFIG1_TX_TOTAL_DISCARDED_TEXTURE_REQUESTS,
+   _reg_read
+   },
+   {
+   "TOTAL_TEXTURE_REQUESTS",
+   
VIVS_MC_PROFILE_CONFIG1_TX_TOTAL_TEXTURE_REQUESTS,
+   _reg_read
+   },
+   {
+   "MEM_READ_COUNT",
+   VIVS_MC_PROFILE_CONFIG1_TX_MEM_READ_COUNT,
+   _reg_read
+   },
+   {
+   "MEM_READ_IN_8B_COUNT",
+   VIVS_MC_PROFILE_CONFIG1_TX_MEM_READ_IN_8B_COUNT,
+   _reg_read
+   },
+   {
+   "CACHE_MISS_COUNT",
+   VIVS_MC_PROFILE_CONFIG1_TX_CACHE_MISS_COUNT,
+   _reg_read
+   },
+   {
+   "CACHE_HIT_TEXEL_COUNT",
+   
VIVS_MC_PROFILE_CONFIG1_TX_CACHE_HIT_TEXEL_COUNT,
+   _reg_read
+   },
+   {
+   "CACHE_MISS_TEXEL_COUNT",
+   
VIVS_MC_PROFILE_CONFIG1_TX_CACHE_MISS_TEXEL_COUNT,
+   _reg_read
+   }
+   }
}
 };
 
-- 
2.13.5

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

[PATCH V4 21/23] drm/etnaviv: need to disable clock gating when doing profiling

[Christian Gmeiner]

As done by Vivante kernel driver.

Signed-off-by: Christian Gmeiner 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 842b6642dcd6..04acc3a64c3c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1341,6 +1341,13 @@ static void sync_point_perfmon_sample(struct etnaviv_gpu 
*gpu,
 static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
struct etnaviv_event *event)
 {
+   u32 val;
+
+   /* disable clock gating */
+   val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
+   val &= ~VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
+   gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
+
sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
 }
 
@@ -1349,6 +1356,7 @@ static void sync_point_perfmon_sample_post(struct 
etnaviv_gpu *gpu,
 {
const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
unsigned int i;
+   u32 val;
 
sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
 
@@ -1357,6 +1365,11 @@ static void sync_point_perfmon_sample_post(struct 
etnaviv_gpu *gpu,
 
*pmr->bo_vma = pmr->sequence;
}
+
+   /* enable clock gating */
+   val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
+   val |= VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
+   gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
 }
 
 
-- 
2.13.5

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

[PATCH V4 18/23] drm/etnaviv: add RA perf domain

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index c32ad2608d4e..ac92684ee7af 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -251,6 +251,49 @@ static const struct etnaviv_pm_domain doms[] = {
_reg_read
}
}
+   },
+   {
+   .name = "RA",
+   .profile_read = VIVS_MC_PROFILE_RA_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG1,
+   .nr_signals = 7,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "VALID_PIXEL_COUNT",
+   VIVS_MC_PROFILE_CONFIG1_RA_VALID_PIXEL_COUNT,
+   _reg_read
+   },
+   {
+   "TOTAL_QUAD_COUNT",
+   VIVS_MC_PROFILE_CONFIG1_RA_TOTAL_QUAD_COUNT,
+   _reg_read
+   },
+   {
+   "VALID_QUAD_COUNT_AFTER_EARLY_Z",
+   
VIVS_MC_PROFILE_CONFIG1_RA_VALID_QUAD_COUNT_AFTER_EARLY_Z,
+   _reg_read
+   },
+   {
+   "TOTAL_PRIMITIVE_COUNT",
+   
VIVS_MC_PROFILE_CONFIG1_RA_TOTAL_PRIMITIVE_COUNT,
+   _reg_read
+   },
+   {
+   "PIPE_CACHE_MISS_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG1_RA_PIPE_CACHE_MISS_COUNTER,
+   _reg_read
+   },
+   {
+   "PREFETCH_CACHE_MISS_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG1_RA_PREFETCH_CACHE_MISS_COUNTER,
+   _reg_read
+   },
+   {
+   "CULLED_QUAD_COUNT",
+   VIVS_MC_PROFILE_CONFIG1_RA_CULLED_QUAD_COUNT,
+   _reg_read
+   }
+   }
}
 };
 
-- 
2.13.5

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

[PATCH V4 17/23] drm/etnaviv: add SE perf domain

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 43d1c4b0c01a..c32ad2608d4e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -233,6 +233,24 @@ static const struct etnaviv_pm_domain doms[] = {
_reg_read
}
}
+   },
+   {
+   .name = "SE",
+   .profile_read = VIVS_MC_PROFILE_SE_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG1,
+   .nr_signals = 2,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "CULLED_TRIANGLE_COUNT",
+   
VIVS_MC_PROFILE_CONFIG1_SE_CULLED_TRIANGLE_COUNT,
+   _reg_read
+   },
+   {
+   "CULLED_LINES_COUNT",
+   VIVS_MC_PROFILE_CONFIG1_SE_CULLED_LINES_COUNT,
+   _reg_read
+   }
+   }
}
 };
 
-- 
2.13.5

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

[PATCH V4 14/23] drm/etnaviv: add PE perf domain

[Christian Gmeiner]

We need to iterate over all pixel pipelines to get overall value.

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 212e1cee61fa..e01eb7447005 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -57,6 +57,25 @@ static u32 perf_reg_read(struct etnaviv_gpu *gpu,
return gpu_read(gpu, domain->profile_read);
 }
 
+static u32 pipe_reg_read(struct etnaviv_gpu *gpu,
+   const struct etnaviv_pm_domain *domain,
+   const struct etnaviv_pm_signal *signal)
+{
+   u32 clock = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
+   u32 value = 0;
+   unsigned i;
+
+   for (i = 0; i < gpu->identity.pixel_pipes; i++) {
+   clock &= ~(VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE__MASK);
+   clock |= VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE(i);
+   gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock);
+   gpu_write(gpu, domain->profile_config, signal->data);
+   value += gpu_read(gpu, domain->profile_read);
+   }
+
+   return value;
+}
+
 static const struct etnaviv_pm_domain doms[] = {
{
.name = "HI",
@@ -90,6 +109,39 @@ static const struct etnaviv_pm_domain doms[] = {
_reg_read
}
}
+   },
+   {
+   .name = "PE",
+   .profile_read = VIVS_MC_PROFILE_PE_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG0,
+   .nr_signals = 5,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "PIXEL_COUNT_KILLED_BY_COLOR_PIPE",
+   
VIVS_MC_PROFILE_CONFIG0_PE_PIXEL_COUNT_KILLED_BY_COLOR_PIPE,
+   _reg_read
+   },
+   {
+   "PIXEL_COUNT_KILLED_BY_DEPTH_PIPE",
+   
VIVS_MC_PROFILE_CONFIG0_PE_PIXEL_COUNT_KILLED_BY_DEPTH_PIPE,
+   _reg_read
+   },
+   {
+   "PIXEL_COUNT_DRAWN_BY_COLOR_PIPE",
+   
VIVS_MC_PROFILE_CONFIG0_PE_PIXEL_COUNT_DRAWN_BY_COLOR_PIPE,
+   _reg_read
+   },
+   {
+   "PIXEL_COUNT_DRAWN_BY_DEPTH_PIPE",
+   
VIVS_MC_PROFILE_CONFIG0_PE_PIXEL_COUNT_DRAWN_BY_DEPTH_PIPE,
+   _reg_read
+   },
+   {
+   "PIXELS_RENDERED_2D",
+   VIVS_MC_PROFILE_CONFIG0_PE_PIXELS_RENDERED_2D,
+   _reg_read
+   }
+   }
}
 };
 
-- 
2.13.5

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

[PATCH V4 15/23] drm/etnaviv: add SH perf domain

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 53 +++
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index e01eb7447005..f23bc056a680 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -142,6 +142,59 @@ static const struct etnaviv_pm_domain doms[] = {
_reg_read
}
}
+   },
+   {
+   .name = "SH",
+   .profile_read = VIVS_MC_PROFILE_SH_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG0,
+   .nr_signals = 9,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "SHADER_CYCLES",
+   VIVS_MC_PROFILE_CONFIG0_SH_SHADER_CYCLES,
+   _reg_read
+   },
+   {
+   "PS_INST_COUNTER",
+   VIVS_MC_PROFILE_CONFIG0_SH_PS_INST_COUNTER,
+   _reg_read
+   },
+   {
+   "RENDERED_PIXEL_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG0_SH_RENDERED_PIXEL_COUNTER,
+   _reg_read
+   },
+   {
+   "VS_INST_COUNTER",
+   VIVS_MC_PROFILE_CONFIG0_SH_VS_INST_COUNTER,
+   _reg_read
+   },
+   {
+   "RENDERED_VERTICE_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG0_SH_RENDERED_VERTICE_COUNTER,
+   _reg_read
+   },
+   {
+   "VTX_BRANCH_INST_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG0_SH_VTX_BRANCH_INST_COUNTER,
+   _reg_read
+   },
+   {
+   "VTX_TEXLD_INST_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG0_SH_VTX_TEXLD_INST_COUNTER,
+   _reg_read
+   },
+   {
+   "PXL_BRANCH_INST_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG0_SH_PXL_BRANCH_INST_COUNTER,
+   _reg_read
+   },
+   {
+   "PXL_TEXLD_INST_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG0_SH_PXL_TEXLD_INST_COUNTER,
+   _reg_read
+   }
+   }
}
 };
 
-- 
2.13.5

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

[PATCH V4 09/23] drm/etnaviv: add performance monitor request processing

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 16 
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 3ecedeed87bd..41e12f2a1dbd 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -16,6 +16,7 @@
  */
 
 #include "etnaviv_gpu.h"
+#include "etnaviv_perfmon.h"
 
 struct etnaviv_pm_domain;
 
@@ -98,3 +99,18 @@ int etnaviv_pm_req_validate(const struct 
drm_etnaviv_gem_submit_pmr *r)
 
return 0;
 }
+
+void etnaviv_perfmon_process(struct etnaviv_gpu *gpu,
+   const struct etnaviv_perfmon_request *pmr)
+{
+   const struct etnaviv_pm_domain *dom;
+   const struct etnaviv_pm_signal *sig;
+   u32 *bo = pmr->bo_vma;
+   u32 val;
+
+   dom = [pmr->domain];
+   sig = >signal[pmr->signal];
+   val = sig->sample(gpu, dom, sig);
+
+   *(bo + pmr->offset) = val;
+}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
index f20b69c942fc..f9c8d7ec8a9b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
@@ -42,4 +42,7 @@ int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
 
 int etnaviv_pm_req_validate(const struct drm_etnaviv_gem_submit_pmr *r);
 
+void etnaviv_perfmon_process(struct etnaviv_gpu *gpu,
+   const struct etnaviv_perfmon_request *pmr);
+
 #endif /* __ETNAVIV_PERFMON_H__ */
-- 
2.13.5

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

[PATCH V4 16/23] drm/etnaviv: add PA perf domain

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 38 +++
 1 file changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index f23bc056a680..43d1c4b0c01a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -195,6 +195,44 @@ static const struct etnaviv_pm_domain doms[] = {
_reg_read
}
}
+   },
+   {
+   .name = "PA",
+   .profile_read = VIVS_MC_PROFILE_PA_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG1,
+   .nr_signals = 6,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "INPUT_VTX_COUNTER",
+   VIVS_MC_PROFILE_CONFIG1_PA_INPUT_VTX_COUNTER,
+   _reg_read
+   },
+   {
+   "INPUT_PRIM_COUNTER",
+   VIVS_MC_PROFILE_CONFIG1_PA_INPUT_PRIM_COUNTER,
+   _reg_read
+   },
+   {
+   "OUTPUT_PRIM_COUNTER",
+   VIVS_MC_PROFILE_CONFIG1_PA_OUTPUT_PRIM_COUNTER,
+   _reg_read
+   },
+   {
+   "DEPTH_CLIPPED_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG1_PA_DEPTH_CLIPPED_COUNTER,
+   _reg_read
+   },
+   {
+   "TRIVIAL_REJECTED_COUNTER",
+   
VIVS_MC_PROFILE_CONFIG1_PA_TRIVIAL_REJECTED_COUNTER,
+   _reg_read
+   },
+   {
+   "CULLED_COUNTER",
+   VIVS_MC_PROFILE_CONFIG1_PA_CULLED_COUNTER,
+   _reg_read
+   }
+   }
}
 };
 
-- 
2.13.5

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

[PATCH V4 12/23] drm/etnaviv: use 'sync points' for performance monitor requests

[Christian Gmeiner]

With 'sync points' we can sample the reqeustes perform signals
before and/or after the submited command buffer.

Changes v2 -> v3:
- fixed indentation and init nr_events to 1

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 102 +++---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |   1 +
 2 files changed, 83 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index b65d7b9d247a..842b6642dcd6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1324,12 +1324,48 @@ void etnaviv_gpu_pm_put(struct etnaviv_gpu *gpu)
pm_runtime_put_autosuspend(gpu->dev);
 }
 
+static void sync_point_perfmon_sample(struct etnaviv_gpu *gpu,
+   struct etnaviv_event *event, unsigned int flags)
+{
+   const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
+   unsigned int i;
+
+   for (i = 0; i < cmdbuf->nr_pmrs; i++) {
+   const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
+
+   if (pmr->flags == flags)
+   etnaviv_perfmon_process(gpu, pmr);
+   }
+}
+
+static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
+   struct etnaviv_event *event)
+{
+   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
+}
+
+static void sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
+   struct etnaviv_event *event)
+{
+   const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
+   unsigned int i;
+
+   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
+
+   for (i = 0; i < cmdbuf->nr_pmrs; i++) {
+   const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
+
+   *pmr->bo_vma = pmr->sequence;
+   }
+}
+
+
 /* add bo's to gpu's ring, and kick gpu: */
 int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
struct etnaviv_gem_submit *submit, struct etnaviv_cmdbuf *cmdbuf)
 {
struct dma_fence *fence;
-   unsigned int event, i;
+   unsigned int i, nr_events = 1, event[3];
int ret;
 
ret = etnaviv_gpu_pm_get_sync(gpu);
@@ -1345,9 +1381,19 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
 *
 */
 
-   ret = event_alloc(gpu, 1, );
+   /*
+* if there are performance monitor requests we need to have
+* - a sync point to re-configure gpu and process ETNA_PM_PROCESS_PRE
+*   requests.
+* - a sync point to re-configure gpu, process ETNA_PM_PROCESS_POST 
requests
+*   and update the sequence number for userspace.
+*/
+   if (cmdbuf->nr_pmrs)
+   nr_events = 3;
+
+   ret = event_alloc(gpu, nr_events, event);
if (ret) {
-   DRM_ERROR("no free event\n");
+   DRM_ERROR("no free events\n");
goto out_pm_put;
}
 
@@ -1355,12 +1401,14 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
 
fence = etnaviv_gpu_fence_alloc(gpu);
if (!fence) {
-   event_free(gpu, event);
+   for (i = 0; i < nr_events; i++)
+   event_free(gpu, event[i]);
+
ret = -ENOMEM;
goto out_unlock;
}
 
-   gpu->event[event].fence = fence;
+   gpu->event[event[0]].fence = fence;
submit->fence = dma_fence_get(fence);
gpu->active_fence = submit->fence->seqno;
 
@@ -1370,7 +1418,19 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
gpu->lastctx = cmdbuf->ctx;
}
 
-   etnaviv_buffer_queue(gpu, event, cmdbuf);
+   if (cmdbuf->nr_pmrs) {
+   gpu->event[event[1]].sync_point = 
_point_perfmon_sample_pre;
+   gpu->event[event[1]].cmdbuf = cmdbuf;
+   etnaviv_sync_point_queue(gpu, event[1]);
+   }
+
+   etnaviv_buffer_queue(gpu, event[0], cmdbuf);
+
+   if (cmdbuf->nr_pmrs) {
+   gpu->event[event[2]].sync_point = 
_point_perfmon_sample_post;
+   gpu->event[event[2]].cmdbuf = cmdbuf;
+   etnaviv_sync_point_queue(gpu, event[2]);
+   }
 
cmdbuf->fence = fence;
list_add_tail(>node, >active_cmd_list);
@@ -1475,20 +1535,22 @@ static irqreturn_t irq_handler(int irq, void *data)
}
 
fence = gpu->event[event].fence;
-   gpu->event[event].fence = NULL;
-   dma_fence_signal(fence);
-
-   /*
-* Events can be processed out of order.  Eg,
-* - allocate and queue event 0
-* - allocate event 1
-* - event 0 completes, we process it
-* - allocate and queue event 0
-* - event 1 and event 0 complete
-* we can end up processing event 0 first, then 1.
-   

[PATCH V4 08/23] drm/etnaviv: copy pmrs from userspace

[Christian Gmeiner]

Changes from v1 -> v2:
- renamed submit_perfmon_request() to submit_perfmon_validate()
- extended flags validation
- added comment about offset 0
- moved assigment of cmdbuf->nr_pmrs below the copy_from_user of the pmrs.

Changes from v2 -> v3:
- fixed flags validation

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 69 +++-
 1 file changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 9c57b14dfcbf..1c1aad213e42 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -21,6 +21,7 @@
 #include "etnaviv_drv.h"
 #include "etnaviv_gpu.h"
 #include "etnaviv_gem.h"
+#include "etnaviv_perfmon.h"
 
 /*
  * Cmdstream submission:
@@ -283,6 +284,54 @@ static int submit_reloc(struct etnaviv_gem_submit *submit, 
void *stream,
return 0;
 }
 
+static int submit_perfmon_validate(struct etnaviv_gem_submit *submit,
+   struct etnaviv_cmdbuf *cmdbuf,
+   const struct drm_etnaviv_gem_submit_pmr *pmrs,
+   u32 nr_pms)
+{
+   u32 i;
+
+   for (i = 0; i < nr_pms; i++) {
+   const struct drm_etnaviv_gem_submit_pmr *r = pmrs + i;
+   struct etnaviv_gem_submit_bo *bo;
+   int ret;
+
+   ret = submit_bo(submit, r->read_idx, );
+   if (ret)
+   return ret;
+
+   /* at offset 0 a sequence number gets stored used for userspace 
sync */
+   if (r->read_offset == 0) {
+   DRM_ERROR("perfmon request: offset is 0");
+   return -EINVAL;
+   }
+
+   if (r->read_offset >= bo->obj->base.size - sizeof(u32)) {
+   DRM_ERROR("perfmon request: offset %u outside object", 
i);
+   return -EINVAL;
+   }
+
+   if (r->flags & ~(ETNA_PM_PROCESS_PRE | ETNA_PM_PROCESS_POST)) {
+   DRM_ERROR("perfmon request: flags are not valid");
+   return -EINVAL;
+   }
+
+   if (etnaviv_pm_req_validate(r)) {
+   DRM_ERROR("perfmon request: domain or signal not 
valid");
+   return -EINVAL;
+   }
+
+   cmdbuf->pmrs[i].flags = r->flags;
+   cmdbuf->pmrs[i].domain = r->domain;
+   cmdbuf->pmrs[i].signal = r->signal;
+   cmdbuf->pmrs[i].sequence = r->sequence;
+   cmdbuf->pmrs[i].offset = r->read_offset;
+   cmdbuf->pmrs[i].bo_vma = etnaviv_gem_vmap(>obj->base);
+   }
+
+   return 0;
+}
+
 static void submit_cleanup(struct etnaviv_gem_submit *submit)
 {
unsigned i;
@@ -306,6 +355,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
struct etnaviv_drm_private *priv = dev->dev_private;
struct drm_etnaviv_gem_submit *args = data;
struct drm_etnaviv_gem_submit_reloc *relocs;
+   struct drm_etnaviv_gem_submit_pmr *pmrs;
struct drm_etnaviv_gem_submit_bo *bos;
struct etnaviv_gem_submit *submit;
struct etnaviv_cmdbuf *cmdbuf;
@@ -347,11 +397,12 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
 */
bos = kvmalloc_array(args->nr_bos, sizeof(*bos), GFP_KERNEL);
relocs = kvmalloc_array(args->nr_relocs, sizeof(*relocs), GFP_KERNEL);
+   pmrs = kvmalloc_array(args->nr_pmrs, sizeof(*pmrs), GFP_KERNEL);
stream = kvmalloc_array(1, args->stream_size, GFP_KERNEL);
cmdbuf = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc,
ALIGN(args->stream_size, 8) + 8,
-   args->nr_bos, 0);
-   if (!bos || !relocs || !stream || !cmdbuf) {
+   args->nr_bos, args->nr_pmrs);
+   if (!bos || !relocs || !pmrs || !stream || !cmdbuf) {
ret = -ENOMEM;
goto err_submit_cmds;
}
@@ -373,6 +424,14 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
goto err_submit_cmds;
}
 
+   ret = copy_from_user(pmrs, u64_to_user_ptr(args->pmrs),
+args->nr_pmrs * sizeof(*pmrs));
+   if (ret) {
+   ret = -EFAULT;
+   goto err_submit_cmds;
+   }
+   cmdbuf->nr_pmrs = args->nr_pmrs;
+
ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
 args->stream_size);
if (ret) {
@@ -441,6 +500,10 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
if (ret)
goto out;
 
+   ret = submit_perfmon_validate(submit, cmdbuf, pmrs, args->nr_pmrs);
+   if (ret)
+   goto out;
+
memcpy(cmdbuf->vaddr, stream, args->stream_size);

[PATCH V4 10/23] drm/etnaviv: add 'sync point' support

[Christian Gmeiner]

In order to support performance counters in a sane way we need to provide
a method to sync the GPU with the CPU. The GPU can process multpile command
buffers/events per irq. With the help of a 'sync point' we can trigger an event
and stop the GPU/FE immediately. When the CPU is done with is processing it
simply needs to restart the FE and the GPU will process the command stream.

Changes from v1 -> v2:
- process sync point with a work item to keep irq as fast as possible

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 36 
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|  1 +
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 25 ++
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  6 ++
 4 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index ed9588f36bc9..9e7098e3207f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -250,6 +250,42 @@ void etnaviv_buffer_end(struct etnaviv_gpu *gpu)
}
 }
 
+/* Append a 'sync point' to the ring buffer. */
+void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu, unsigned int event)
+{
+   struct etnaviv_cmdbuf *buffer = gpu->buffer;
+   unsigned int waitlink_offset = buffer->user_size - 16;
+   u32 dwords, target;
+
+   /*
+* We need at most 3 dwords in the return target:
+* 1 event + 1 end + 1 wait + 1 link.
+*/
+   dwords = 4;
+   target = etnaviv_buffer_reserve(gpu, buffer, dwords);
+
+   /* Signal sync point event */
+   CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
+  VIVS_GL_EVENT_FROM_PE);
+
+   /* Stop the FE to 'pause' the GPU */
+   CMD_END(buffer);
+
+   /* Append waitlink */
+   CMD_WAIT(buffer);
+   CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
+   buffer->user_size - 4);
+
+   /*
+* Kick off the 'sync point' command by replacing the previous
+* WAIT with a link to the address in the ring buffer.
+*/
+   etnaviv_buffer_replace_wait(buffer, waitlink_offset,
+   VIV_FE_LINK_HEADER_OP_LINK |
+   VIV_FE_LINK_HEADER_PREFETCH(dwords),
+   target);
+}
+
 /* Append a command buffer to the ring buffer. */
 void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned int event,
struct etnaviv_cmdbuf *cmdbuf)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 058389f93b69..f6cdd694ca51 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -101,6 +101,7 @@ int etnaviv_gem_new_userptr(struct drm_device *dev, struct 
drm_file *file,
 u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu);
 u16 etnaviv_buffer_config_mmuv2(struct etnaviv_gpu *gpu, u32 mtlb_addr, u32 
safe_addr);
 void etnaviv_buffer_end(struct etnaviv_gpu *gpu);
+void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu, unsigned int event);
 void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned int event,
struct etnaviv_cmdbuf *cmdbuf);
 void etnaviv_validate_init(void);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 9372296b5b9c..1f5e6b3e1027 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -25,6 +25,7 @@
 #include "etnaviv_gpu.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_mmu.h"
+#include "etnaviv_perfmon.h"
 #include "common.xml.h"
 #include "state.xml.h"
 #include "state_hi.xml.h"
@@ -1359,6 +1360,7 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
}
 
gpu->event[event].fence = fence;
+   gpu->event[event].sync_point = NULL;
submit->fence = dma_fence_get(fence);
gpu->active_fence = submit->fence->seqno;
 
@@ -1404,6 +1406,23 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
return ret;
 }
 
+static void etnaviv_process_sync_point(struct etnaviv_gpu *gpu,
+   struct etnaviv_event *event)
+{
+   u32 addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
+
+   event->sync_point(gpu, event);
+   etnaviv_gpu_start_fe(gpu, addr + 2, 2);
+}
+
+static void pmrs_worker(struct work_struct *work)
+{
+   struct etnaviv_gpu *gpu = container_of(work, struct etnaviv_gpu,
+  pmrs_work);
+
+   etnaviv_process_sync_point(gpu, >event[gpu->pmrs_event]);
+}
+
 /*
  * Init/Cleanup:
  */
@@ -1450,6 +1469,11 @@ static irqreturn_t irq_handler(int irq, void *data)
 
dev_dbg(gpu->dev, "event %u\n", event);
 
+   if (gpu->event[event].sync_point) {
+   gpu->pmrs_event = event;
+   etnaviv_queue_work(gpu->drm, 

[PATCH V4 13/23] drm/etnaviv: add HI perf domain

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 55 +++
 1 file changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 41e12f2a1dbd..212e1cee61fa 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -17,6 +17,7 @@
 
 #include "etnaviv_gpu.h"
 #include "etnaviv_perfmon.h"
+#include "state_hi.xml.h"
 
 struct etnaviv_pm_domain;
 
@@ -31,11 +32,65 @@ struct etnaviv_pm_signal {
 
 struct etnaviv_pm_domain {
char name[64];
+
+   /* profile register */
+   u32 profile_read;
+   u32 profile_config;
+
u8 nr_signals;
const struct etnaviv_pm_signal *signal;
 };
 
+static u32 simple_reg_read(struct etnaviv_gpu *gpu,
+   const struct etnaviv_pm_domain *domain,
+   const struct etnaviv_pm_signal *signal)
+{
+   return gpu_read(gpu, signal->data);
+}
+
+static u32 perf_reg_read(struct etnaviv_gpu *gpu,
+   const struct etnaviv_pm_domain *domain,
+   const struct etnaviv_pm_signal *signal)
+{
+   gpu_write(gpu, domain->profile_config, signal->data);
+
+   return gpu_read(gpu, domain->profile_read);
+}
+
 static const struct etnaviv_pm_domain doms[] = {
+   {
+   .name = "HI",
+   .profile_read = VIVS_MC_PROFILE_HI_READ,
+   .profile_config = VIVS_MC_PROFILE_CONFIG2,
+   .nr_signals = 5,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "TOTAL_CYCLES",
+   VIVS_HI_PROFILE_TOTAL_CYCLES,
+   _reg_read
+   },
+   {
+   "IDLE_CYCLES",
+   VIVS_HI_PROFILE_IDLE_CYCLES,
+   _reg_read
+   },
+   {
+   "AXI_CYCLES_READ_REQUEST_STALLED",
+   
VIVS_MC_PROFILE_CONFIG2_HI_AXI_CYCLES_READ_REQUEST_STALLED,
+   _reg_read
+   },
+   {
+   "AXI_CYCLES_WRITE_REQUEST_STALLED",
+   
VIVS_MC_PROFILE_CONFIG2_HI_AXI_CYCLES_WRITE_REQUEST_STALLED,
+   _reg_read
+   },
+   {
+   "AXI_CYCLES_WRITE_DATA_STALLED",
+   
VIVS_MC_PROFILE_CONFIG2_HI_AXI_CYCLES_WRITE_DATA_STALLED,
+   _reg_read
+   }
+   }
+   }
 };
 
 int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
-- 
2.13.5

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

[PATCH V4 11/23] drm/etnaviv: clear alloced event

[Christian Gmeiner]

Results in less code as the users do not set every struct member to 0/NULL.

Signed-off-by: Christian Gmeiner 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 1f5e6b3e1027..b65d7b9d247a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1164,6 +1164,7 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned 
nr_events,
int event = find_first_zero_bit(gpu->event_bitmap, 
ETNA_NR_EVENTS);
 
events[i] = event;
+   memset(>event[event], 0, sizeof(struct etnaviv_event));
set_bit(event, gpu->event_bitmap);
}
 
@@ -1360,7 +1361,6 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
}
 
gpu->event[event].fence = fence;
-   gpu->event[event].sync_point = NULL;
submit->fence = dma_fence_get(fence);
gpu->active_fence = submit->fence->seqno;
 
-- 
2.13.5

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

[PATCH 00/23] drm/etnaviv: support performance counters

[Christian Gmeiner]

In a perfect world we would be able to read GPU registers of interest
via the command stream with a 'read-register' command/package. For perf
counters it is a must to read them synchronized with the GPU to put the
values in relation to a draw command. As Vivante GPUs do not provide this
functionality we need to emulate it in software.


We need to support three different kind of perf register types:

1) normal register
  This is the easierst case where we can simply read the register and we
  are done.

2) debug register
  We need to configure the mux register and then read the debug register value.

3) pipeline register
  We need to 'iterate' over all pixel pipes and sum up the values. The 
'iteration'
  is done by select the pipe of interest via HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE.
  There is also need to configure the mux register.


Allowing the userspace to do it all by its own feels quite error prone and not
future-proof. Thats why the kernel exports all performance domains and their
signals to the userspace via two new ioctls. So the kernel knows all performance
counters and how to sample them.

At the moment all performacne domains and signals get exported to all gpu pipe 
types,
but that can be changed in follow-up patches.

struct drm_etnaviv_gem_submit was extended to include so-called performance 
monitor
requests (pmrs). A request defines what domain and signal should be sampled 
(pre/post
draw cmdbuffer) and where to store the result.

The whole series can be found here:
https://github.com/austriancoder/linux/tree/perfmon-v4

The used libdrm and mesa branches to test this feature can be found here:
https://github.com/austriancoder/libdrm/commits/perfmon-v4
https://github.com/austriancoder/mesa/commits/perfmon-v4

GALLIUM_HUD=help will report following queries names:
fps
cpu
cpu0
cpu1
cpu2
cpu3
prims-emitted
draw-calls
rs-operations
hi-total-cyles
hi-idle-cyles
hi-axi-cycles-read-request-stalled
hi-axi-cycles-write-request-stalled
hi-axi-cycles-write-data-stalled
pe-pixel-count-killed-by-color-pipe
pe-pixel-count-killed-by-depth-pipe
pe-pixel-count-drawn-by-color-pipe
pe-pixel-count-drawn-by-depth-pipe
pe-pixels-rendered-2d
sh-shader-cycles
sh-ps-inst-counter
sh-rendered-pixel-counter
sh-vs-inst-counter
sh-rendered-vertice-counter
sh-vtx-branch-inst-counter
sh-vtx-texld-inst-counter
sh-plx-branch-inst-counter
sh-plx-texld-inst-counter
pa-input-vtx-counter
pa-input-prim-counter
pa-putput-prim-counter
pa-depth-clipped-counter
pa-trivial-rejected-counter
pa-culled-counter
se-culled-triangle-count
se-culled-lines-count
ra-valid-pixel-count
ra-total-quad-count
ra-valid-quad-count-after-early-z
ra-total-primitive-count
ra-pipe-cache-miss-counter
ra-prefetch-cache-miss-counter
ra-pculled-quad-count
tx-total-bilinear-requests
tx-total-trilinear-requests
tx-total-discarded-texutre-requests
tx-total-texutre-requests
tx-mem-read-count
tx-mem-read-in-8b-count
tx-cache-miss-count
tx-cache-hit-texel-count
tx-cache-miss-texel-count
mc-total-read-req-8b-from-pipeline
mc-total-read-req-8b-from-ip
mc-total-write-req-8b-from-pipeline

Changes v1 -> v2:
 - reworked events
 - reworked uapi
 - reworked enumeration of domains and signals
 - process sync point with a work item to keep irq as fast as possible
 - prevent GPU hang when reading pixel pipeline perf values
 - all SH perf counters are accessed via perf_reg_read(..)

Changes v2 -> v3:
 - reworked alloc_event(..)
 - fixed pmr flag validation

Changes v3 -> v4:
 - cherry picked the correct commits (patches 03 and 04)

Happy reviewing!

Christian Gmeiner (23):
  drm/etnaviv: use bitmap to keep track of events
  drm/etnaviv: make it possible to allocate multiple events
  drm/etnaviv: add infrastructure to query perf counter
  drm/etnaviv: add uapi for perfmon feature
  drm/etnaviv: add internal representation of perfmon_request
  drm/etnaviv: extend etnaviv_gpu_cmdbuf_new(..) with nr_pmrs
  drm/etnaviv: add performance monitor request validation
  drm/etnaviv: copy pmrs from userspace
  drm/etnaviv: add performance monitor request processing
  drm/etnaviv: add 'sync point' support
  drm/etnaviv: clear alloced event
  drm/etnaviv: use 'sync points' for performance monitor requests
  drm/etnaviv: add HI perf domain
  drm/etnaviv: add PE perf domain
  drm/etnaviv: add SH perf domain
  drm/etnaviv: add PA perf domain
  drm/etnaviv: add SE perf domain
  drm/etnaviv: add RA perf domain
  drm/etnaviv: add TX perf domain
  drm/etnaviv: add MC perf domain
  drm/etnaviv: need to disable clock gating when doing profiling
  drm/etnaviv: enable debug registers on demand
  drm/etnaviv: submit supports performance monitor requests

 drivers/gpu/drm/etnaviv/Makefile |   3 +-
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c |  36 +++
 

[PATCH V4 06/23] drm/etnaviv: extend etnaviv_gpu_cmdbuf_new(..) with nr_pmrs

[Christian Gmeiner]

This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number
of struct etnaviv_perfmon elements gets used.

Changes from v1 -> v2:
- make use of goto as requested by Lucas

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c|  2 +-
 4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c 
b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
index 633e0f07cbac..66ac79558bbd 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
@@ -19,6 +19,7 @@
 #include "etnaviv_cmdbuf.h"
 #include "etnaviv_gpu.h"
 #include "etnaviv_mmu.h"
+#include "etnaviv_perfmon.h"
 
 #define SUBALLOC_SIZE  SZ_256K
 #define SUBALLOC_GRANULE   SZ_4K
@@ -87,9 +88,10 @@ void etnaviv_cmdbuf_suballoc_destroy(struct 
etnaviv_cmdbuf_suballoc *suballoc)
 
 struct etnaviv_cmdbuf *
 etnaviv_cmdbuf_new(struct etnaviv_cmdbuf_suballoc *suballoc, u32 size,
-  size_t nr_bos)
+  size_t nr_bos, size_t nr_pmrs)
 {
struct etnaviv_cmdbuf *cmdbuf;
+   struct etnaviv_perfmon_request *pmrs;
size_t sz = size_vstruct(nr_bos, sizeof(cmdbuf->bo_map[0]),
 sizeof(*cmdbuf));
int granule_offs, order, ret;
@@ -98,6 +100,12 @@ etnaviv_cmdbuf_new(struct etnaviv_cmdbuf_suballoc 
*suballoc, u32 size,
if (!cmdbuf)
return NULL;
 
+   sz = sizeof(*pmrs) * nr_pmrs;
+   pmrs = kzalloc(sz, GFP_KERNEL);
+   if (!pmrs)
+   goto out_free_cmdbuf;
+
+   cmdbuf->pmrs = pmrs;
cmdbuf->suballoc = suballoc;
cmdbuf->size = size;
 
@@ -124,6 +132,10 @@ etnaviv_cmdbuf_new(struct etnaviv_cmdbuf_suballoc 
*suballoc, u32 size,
cmdbuf->vaddr = suballoc->vaddr + cmdbuf->suballoc_offset;
 
return cmdbuf;
+
+out_free_cmdbuf:
+   kfree(cmdbuf);
+   return NULL;
 }
 
 void etnaviv_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf)
@@ -139,6 +151,7 @@ void etnaviv_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf)
suballoc->free_space = 1;
mutex_unlock(>lock);
wake_up_all(>free_event);
+   kfree(cmdbuf->pmrs);
kfree(cmdbuf);
 }
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h 
b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
index 1b549f0d59a0..b6348b9f2a9d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
@@ -53,7 +53,7 @@ void etnaviv_cmdbuf_suballoc_destroy(struct 
etnaviv_cmdbuf_suballoc *suballoc);
 
 struct etnaviv_cmdbuf *
 etnaviv_cmdbuf_new(struct etnaviv_cmdbuf_suballoc *suballoc, u32 size,
-  size_t nr_bos);
+  size_t nr_bos, size_t nr_pmrs);
 void etnaviv_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf);
 
 u32 etnaviv_cmdbuf_get_va(struct etnaviv_cmdbuf *buf);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index ee7069e93eda..9c57b14dfcbf 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -350,7 +350,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
stream = kvmalloc_array(1, args->stream_size, GFP_KERNEL);
cmdbuf = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc,
ALIGN(args->stream_size, 8) + 8,
-   args->nr_bos);
+   args->nr_bos, 0);
if (!bos || !relocs || !stream || !cmdbuf) {
ret = -ENOMEM;
goto err_submit_cmds;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index d3b7e665eca9..9372296b5b9c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -721,7 +721,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
}
 
/* Create buffer: */
-   gpu->buffer = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc, PAGE_SIZE, 0);
+   gpu->buffer = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc, PAGE_SIZE, 0, 0);
if (!gpu->buffer) {
ret = -ENOMEM;
dev_err(gpu->dev, "could not create command buffer\n");
-- 
2.13.5

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

[PATCH V4 07/23] drm/etnaviv: add performance monitor request validation

[Christian Gmeiner]

Check if the selected domain and signal combination exists.

Signed-off-by: Christian Gmeiner 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 15 +++
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 5bc015194791..3ecedeed87bd 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -83,3 +83,18 @@ int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
 
return 0;
 }
+
+int etnaviv_pm_req_validate(const struct drm_etnaviv_gem_submit_pmr *r)
+{
+   const struct etnaviv_pm_domain *dom;
+
+   if (r->domain >= ARRAY_SIZE(doms))
+   return -EINVAL;
+
+   dom = [r->domain];
+
+   if (r->signal > dom->nr_signals)
+   return -EINVAL;
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
index 4b2b518cfd16..f20b69c942fc 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
@@ -40,4 +40,6 @@ int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
 int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
struct drm_etnaviv_pm_signal *signal);
 
+int etnaviv_pm_req_validate(const struct drm_etnaviv_gem_submit_pmr *r);
+
 #endif /* __ETNAVIV_PERFMON_H__ */
-- 
2.13.5

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

[PATCH V4 05/23] drm/etnaviv: add internal representation of perfmon_request

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h  |  4 
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 12 
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h 
b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
index 80d78076c679..1b549f0d59a0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
@@ -21,6 +21,7 @@
 
 struct etnaviv_gpu;
 struct etnaviv_cmdbuf_suballoc;
+struct etnaviv_perfmon_request;
 
 struct etnaviv_cmdbuf {
/* suballocator this cmdbuf is allocated from */
@@ -38,6 +39,9 @@ struct etnaviv_cmdbuf {
u32 exec_state;
/* per GPU in-flight list */
struct list_head node;
+   /* perfmon requests */
+   unsigned int nr_pmrs;
+   struct etnaviv_perfmon_request *pmrs;
/* BOs attached to this command buffer */
unsigned int nr_bos;
struct etnaviv_vram_mapping *bo_map[0];
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
index 4589cadc3a4f..4b2b518cfd16 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
@@ -22,6 +22,18 @@ struct etnaviv_gpu;
 struct drm_etnaviv_pm_domain;
 struct drm_etnaviv_pm_signal;
 
+struct etnaviv_perfmon_request
+{
+   u32 flags;
+   u8 domain;
+   u8 signal;
+   u32 sequence;
+
+   /* bo to store a value */
+   u32 *bo_vma;
+   u32 offset;
+};
+
 int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
struct drm_etnaviv_pm_domain *domain);
 
-- 
2.13.5

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

[PATCH V4 04/23] drm/etnaviv: add uapi for perfmon feature

[Christian Gmeiner]

Sadly we can not read any registers via command stream so we need
to extend the drm_etnaviv_gem_submit struct with performance monitor
requests. Those requests gets process before or after the actual
submitted command stream.

The Vivante kernel driver has a special ioctl to read all perfmon
registers at once and return it.

Changes from v1 -> v2:
- use a 16 bit value for signals
- fix padding issues

Signed-off-by: Christian Gmeiner 
---
 include/uapi/drm/etnaviv_drm.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
index c065c8308bbd..110cc73bf549 100644
--- a/include/uapi/drm/etnaviv_drm.h
+++ b/include/uapi/drm/etnaviv_drm.h
@@ -150,6 +150,19 @@ struct drm_etnaviv_gem_submit_bo {
__u64 presumed;   /* in/out, presumed buffer address */
 };
 
+/* performance monitor request (pmr) */
+#define ETNA_PM_PROCESS_PRE 0x0001
+#define ETNA_PM_PROCESS_POST0x0002
+struct drm_etnaviv_gem_submit_pmr {
+   __u32 flags;  /* in, when to process request 
(ETNA_PM_PROCESS_x) */
+   __u8  domain; /* in, pm domain */
+   __u8  pad;
+   __u16 signal; /* in, pm signal */
+   __u32 sequence;   /* in, sequence number */
+   __u32 read_offset;/* in, offset from read_bo */
+   __u32 read_idx;   /* in, index of read_bo buffer */
+};
+
 /* Each cmdstream submit consists of a table of buffers involved, and
  * one or more cmdstream buffers.  This allows for conditional execution
  * (context-restore), and IB buffers needed for per tile/bin draw cmds.
@@ -175,6 +188,9 @@ struct drm_etnaviv_gem_submit {
__u64 stream; /* in, ptr to cmdstream */
__u32 flags;  /* in, mask of ETNA_SUBMIT_x */
__s32 fence_fd;   /* in/out, fence fd (see ETNA_SUBMIT_FENCE_FD_x) 
*/
+   __u64 pmrs;   /* in, ptr to array of submit_pmr's */
+   __u32 nr_pmrs;/* in, number of submit_pmr's */
+   __u32 pad;
 };
 
 /* The normal way to synchronize with the GPU is just to CPU_PREP on
-- 
2.13.5

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

[PATCH V4 03/23] drm/etnaviv: add infrastructure to query perf counter

[Christian Gmeiner]

Make it possible that userspace can query all performance domains and
its signals. This information is needed to sample those signals via
submit ioctl.

At the moment no performance domain is available.

Changes from v1 -> v2:
 - use a 16 bit value for signals
 - fix padding issues
 - add id member to domain and signal struct

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/Makefile  |  3 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 37 ++
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 85 +++
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 31 +++
 include/uapi/drm/etnaviv_drm.h| 27 +-
 5 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h

diff --git a/drivers/gpu/drm/etnaviv/Makefile b/drivers/gpu/drm/etnaviv/Makefile
index 4f76c992043f..15c3bfa89a79 100644
--- a/drivers/gpu/drm/etnaviv/Makefile
+++ b/drivers/gpu/drm/etnaviv/Makefile
@@ -10,6 +10,7 @@ etnaviv-y := \
etnaviv_gpu.o \
etnaviv_iommu_v2.o \
etnaviv_iommu.o \
-   etnaviv_mmu.o
+   etnaviv_mmu.o \
+   etnaviv_perfmon.o
 
 obj-$(CONFIG_DRM_ETNAVIV)  += etnaviv.o
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 91e17aeee1da..536760a9fef3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -23,6 +23,7 @@
 #include "etnaviv_gpu.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_mmu.h"
+#include "etnaviv_perfmon.h"
 
 #ifdef CONFIG_DRM_ETNAVIV_REGISTER_LOGGING
 static bool reglog;
@@ -451,6 +452,40 @@ static int etnaviv_ioctl_gem_wait(struct drm_device *dev, 
void *data,
return ret;
 }
 
+static int etnaviv_ioctl_pm_query_dom(struct drm_device *dev, void *data,
+   struct drm_file *file)
+{
+   struct etnaviv_drm_private *priv = dev->dev_private;
+   struct drm_etnaviv_pm_domain *args = data;
+   struct etnaviv_gpu *gpu;
+
+   if (args->pipe >= ETNA_MAX_PIPES)
+   return -EINVAL;
+
+   gpu = priv->gpu[args->pipe];
+   if (!gpu)
+   return -ENXIO;
+
+   return etnaviv_pm_query_dom(gpu, args);
+}
+
+static int etnaviv_ioctl_pm_query_sig(struct drm_device *dev, void *data,
+   struct drm_file *file)
+{
+   struct etnaviv_drm_private *priv = dev->dev_private;
+   struct drm_etnaviv_pm_signal *args = data;
+   struct etnaviv_gpu *gpu;
+
+   if (args->pipe >= ETNA_MAX_PIPES)
+   return -EINVAL;
+
+   gpu = priv->gpu[args->pipe];
+   if (!gpu)
+   return -ENXIO;
+
+   return etnaviv_pm_query_sig(gpu, args);
+}
+
 static const struct drm_ioctl_desc etnaviv_ioctls[] = {
 #define ETNA_IOCTL(n, func, flags) \
DRM_IOCTL_DEF_DRV(ETNAVIV_##n, etnaviv_ioctl_##func, flags)
@@ -463,6 +498,8 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
ETNA_IOCTL(WAIT_FENCE,   wait_fence,   DRM_AUTH|DRM_RENDER_ALLOW),
ETNA_IOCTL(GEM_USERPTR,  gem_userptr,  DRM_AUTH|DRM_RENDER_ALLOW),
ETNA_IOCTL(GEM_WAIT, gem_wait, DRM_AUTH|DRM_RENDER_ALLOW),
+   ETNA_IOCTL(PM_QUERY_DOM, pm_query_dom, DRM_AUTH|DRM_RENDER_ALLOW),
+   ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_AUTH|DRM_RENDER_ALLOW),
 };
 
 static const struct vm_operations_struct vm_ops = {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
new file mode 100644
index ..5bc015194791
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2017 Etnaviv Project
+ * Copyright (C) 2017 Zodiac Inflight Innovations
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "etnaviv_gpu.h"
+
+struct etnaviv_pm_domain;
+
+struct etnaviv_pm_signal {
+   char name[64];
+   u32 data;
+
+   u32 (*sample)(struct etnaviv_gpu *gpu,
+ const struct etnaviv_pm_domain *domain,
+ const struct etnaviv_pm_signal *signal);
+};
+
+struct etnaviv_pm_domain {
+   char name[64];
+   u8 nr_signals;
+   const struct etnaviv_pm_signal *signal;
+};
+
+static const struct etnaviv_pm_domain doms[] = {
+};
+
+int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
+   struct drm_etnaviv_pm_domain *domain)
+{
+   const 

[PATCH V4 02/23] drm/etnaviv: make it possible to allocate multiple events

[Christian Gmeiner]

This makes it possible to allocate multiple events under the event
spinlock. This change is needed to support 'sync'-points.

Changes v2 -> v3:
- wait for the completion of all events
- use 10sec timeout regardless of the number of events
- removed validation if there are enough free events
- fixed return value evaluation of event_alloc(..) in etnaviv_gpu_submit(..)

Signed-off-by: Christian Gmeiner 

!fixup

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 47 +++
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fa9c7bd98e9c..d3b7e665eca9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1137,28 +1137,44 @@ int etnaviv_gpu_fence_sync_obj(struct 
etnaviv_gem_object *etnaviv_obj,
  * event management:
  */
 
-static unsigned int event_alloc(struct etnaviv_gpu *gpu)
+static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
+   unsigned int *events)
 {
-   unsigned long ret, flags;
-   unsigned int event;
+   unsigned long flags, timeout = msecs_to_jiffies(10 * 1);
+   unsigned i, acquired = 0;
 
-   ret = wait_for_completion_timeout(>event_free,
- msecs_to_jiffies(10 * 1));
-   if (!ret)
-   dev_err(gpu->dev, "wait_for_completion_timeout failed");
+   for (i = 0; i < nr_events; i++) {
+   unsigned long ret;
+
+   ret = wait_for_completion_timeout(>event_free, timeout);
+
+   if (!ret) {
+   dev_err(gpu->dev, "wait_for_completion_timeout failed");
+   goto out;
+   }
+
+   acquired++;
+   timeout = ret;
+   }
 
spin_lock_irqsave(>event_spinlock, flags);
 
-   /* find first free event */
-   event = find_first_zero_bit(gpu->event_bitmap, ETNA_NR_EVENTS);
-   if (event < ETNA_NR_EVENTS)
+   for (i = 0; i < nr_events; i++) {
+   int event = find_first_zero_bit(gpu->event_bitmap, 
ETNA_NR_EVENTS);
+
+   events[i] = event;
set_bit(event, gpu->event_bitmap);
-   else
-   event = ~0U;
+   }
 
spin_unlock_irqrestore(>event_spinlock, flags);
 
-   return event;
+   return 0;
+
+out:
+   for (i = 0; i < acquired; i++)
+   complete(>event_free);
+
+   return -EBUSY;
 }
 
 static void event_free(struct etnaviv_gpu *gpu, unsigned int event)
@@ -1327,10 +1343,9 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
 *
 */
 
-   event = event_alloc(gpu);
-   if (unlikely(event == ~0U)) {
+   ret = event_alloc(gpu, 1, );
+   if (ret) {
DRM_ERROR("no free event\n");
-   ret = -EBUSY;
goto out_pm_put;
}
 
-- 
2.13.5

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

[PATCH V4 01/23] drm/etnaviv: use bitmap to keep track of events

[Christian Gmeiner]

This is prep work to be able to allocate multiple events in one go.

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 31 +--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  6 --
 2 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index ada45fdd0eae..fa9c7bd98e9c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -739,10 +739,9 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
/* Setup event management */
spin_lock_init(>event_spinlock);
init_completion(>event_free);
-   for (i = 0; i < ARRAY_SIZE(gpu->event); i++) {
-   gpu->event[i].used = false;
+   bitmap_zero(gpu->event_bitmap, ETNA_NR_EVENTS);
+   for (i = 0; i < ARRAY_SIZE(gpu->event); i++)
complete(>event_free);
-   }
 
/* Now program the hardware */
mutex_lock(>lock);
@@ -926,7 +925,7 @@ static void recover_worker(struct work_struct *work)
struct etnaviv_gpu *gpu = container_of(work, struct etnaviv_gpu,
   recover_work);
unsigned long flags;
-   unsigned int i;
+   unsigned int i = 0;
 
dev_err(gpu->dev, "hangcheck recover!\n");
 
@@ -945,14 +944,12 @@ static void recover_worker(struct work_struct *work)
 
/* complete all events, the GPU won't do it after the reset */
spin_lock_irqsave(>event_spinlock, flags);
-   for (i = 0; i < ARRAY_SIZE(gpu->event); i++) {
-   if (!gpu->event[i].used)
-   continue;
+   for_each_set_bit_from(i, gpu->event_bitmap, ETNA_NR_EVENTS) {
dma_fence_signal(gpu->event[i].fence);
gpu->event[i].fence = NULL;
-   gpu->event[i].used = false;
complete(>event_free);
}
+   bitmap_zero(gpu->event_bitmap, ETNA_NR_EVENTS);
spin_unlock_irqrestore(>event_spinlock, flags);
gpu->completed_fence = gpu->active_fence;
 
@@ -1143,7 +1140,7 @@ int etnaviv_gpu_fence_sync_obj(struct etnaviv_gem_object 
*etnaviv_obj,
 static unsigned int event_alloc(struct etnaviv_gpu *gpu)
 {
unsigned long ret, flags;
-   unsigned int i, event = ~0U;
+   unsigned int event;
 
ret = wait_for_completion_timeout(>event_free,
  msecs_to_jiffies(10 * 1));
@@ -1153,13 +1150,11 @@ static unsigned int event_alloc(struct etnaviv_gpu *gpu)
spin_lock_irqsave(>event_spinlock, flags);
 
/* find first free event */
-   for (i = 0; i < ARRAY_SIZE(gpu->event); i++) {
-   if (gpu->event[i].used == false) {
-   gpu->event[i].used = true;
-   event = i;
-   break;
-   }
-   }
+   event = find_first_zero_bit(gpu->event_bitmap, ETNA_NR_EVENTS);
+   if (event < ETNA_NR_EVENTS)
+   set_bit(event, gpu->event_bitmap);
+   else
+   event = ~0U;
 
spin_unlock_irqrestore(>event_spinlock, flags);
 
@@ -1172,12 +1167,12 @@ static void event_free(struct etnaviv_gpu *gpu, 
unsigned int event)
 
spin_lock_irqsave(>event_spinlock, flags);
 
-   if (gpu->event[event].used == false) {
+   if (!test_bit(event, gpu->event_bitmap)) {
dev_warn(gpu->dev, "event %u is already marked as free",
 event);
spin_unlock_irqrestore(>event_spinlock, flags);
} else {
-   gpu->event[event].used = false;
+   clear_bit(event, gpu->event_bitmap);
spin_unlock_irqrestore(>event_spinlock, flags);
 
complete(>event_free);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 689cb8f3680c..70e6590aacdf 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -88,13 +88,14 @@ struct etnaviv_chip_identity {
 };
 
 struct etnaviv_event {
-   bool used;
struct dma_fence *fence;
 };
 
 struct etnaviv_cmdbuf_suballoc;
 struct etnaviv_cmdbuf;
 
+#define ETNA_NR_EVENTS 30
+
 struct etnaviv_gpu {
struct drm_device *drm;
struct thermal_cooling_device *cooling;
@@ -112,7 +113,8 @@ struct etnaviv_gpu {
u32 memory_base;
 
/* event management: */
-   struct etnaviv_event event[30];
+   DECLARE_BITMAP(event_bitmap, ETNA_NR_EVENTS);
+   struct etnaviv_event event[ETNA_NR_EVENTS];
struct completion event_free;
spinlock_t event_spinlock;
 
-- 
2.13.5

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

Re: [PATCH 2/6] drm/exynos: ipp: Add IPP v2 framework

[Emil Velikov]

Hi Marek,

Just a couple of small suggestions - this is by no means a proper review.

On 12 September 2017 at 09:08, Marek Szyprowski
 wrote:
> This patch adds Exynos IPP v2 subsystem and userspace API.
>
> New userspace API is focused ONLY on memory-to-memory image processing.
> The two remainging IPP operation modes (framebuffer writeback and
s/remainging/remaining/

> local-path output with image processing) can be implemented using
> standard DRM features: writeback connectors and additional DRM planes with
> scaling features.
>
> V2 IPP userspace API is not compatible with old IPP ioctls. This is a
> significant change, but the old IPP subsystem in mainline Linux kernel was
> partially disfunctional anyway and not used in any open-source project.
>
s/disfunctional/dysfunctional/

> V2 IPP userspace API is based on stateless approach, which much better fits
> to memory-to-memory image processing model. It also provides support for
> all image formats, which are both already defined in DRM API and supported
> by the existing IPP hardware modules.
>
> The API consists of the following ioctls:
> - DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
>   processing modules,
> - DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
>   formats of given IPP module,
> - DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
s/limitiations/limitations/


> +int exynos_drm_ipp_get_limits_ioctl(struct drm_device *dev, void *data,
> +   struct drm_file *file_priv)
> +{
> +   struct drm_exynos_ioctl_ipp_get_limits *resp = data;
> +   void __user *ptr = (void __user *)(unsigned long)resp->limits_ptr;
We have the u64_to_user_ptr helper for these casts. Please use it
through the codebase.


> +struct exynos_drm_param_map {
static const?

> +   unsigned int id;
> +   unsigned int size;
> +   unsigned int offset;
> +} exynos_drm_ipp_params_maps[] = {
> +   {
> +   DRM_EXYNOS_IPP_TASK_BUFFER | DRM_EXYNOS_IPP_TASK_TYPE_SOURCE,
> +   sizeof(struct drm_exynos_ipp_task_buffer),
> +   offsetof(struct exynos_drm_ipp_task, src.buf),
> +   }, {
> +   DRM_EXYNOS_IPP_TASK_BUFFER | 
> DRM_EXYNOS_IPP_TASK_TYPE_DESTINATION,
> +   sizeof(struct drm_exynos_ipp_task_buffer),
> +   offsetof(struct exynos_drm_ipp_task, dst.buf),
> +   }, {
> +   DRM_EXYNOS_IPP_TASK_RECTANGLE | 
> DRM_EXYNOS_IPP_TASK_TYPE_SOURCE,
> +   sizeof(struct drm_exynos_ipp_task_rect),
> +   offsetof(struct exynos_drm_ipp_task, src.rect),
> +   }, {
> +   DRM_EXYNOS_IPP_TASK_RECTANGLE | 
> DRM_EXYNOS_IPP_TASK_TYPE_DESTINATION,
> +   sizeof(struct drm_exynos_ipp_task_rect),
> +   offsetof(struct exynos_drm_ipp_task, dst.rect),
> +   }, {
> +   DRM_EXYNOS_IPP_TASK_TRANSFORM,
> +   sizeof(struct drm_exynos_ipp_task_transform),
> +   offsetof(struct exynos_drm_ipp_task, transform),
> +   }, {
> +   DRM_EXYNOS_IPP_TASK_ALPHA,
> +   sizeof(struct drm_exynos_ipp_task_alpha),
> +   offsetof(struct exynos_drm_ipp_task, alpha),
> +   },
> +};
> +
> +static int exynos_drm_ipp_task_set(struct exynos_drm_ipp_task *task,
> + struct drm_exynos_ioctl_ipp_commit *arg)
> +{
> +   unsigned int size = arg->params_size;
> +   void *p, *params;
> +   int ret = 0;
> +
> +   if (size > PAGE_SIZE)
> +   return -ERANGE;
> +
> +   p = kmalloc(size, GFP_KERNEL);
> +   if (!p)
> +   return -ENOMEM;
> +
> +   if (copy_from_user(p, (void __user *)(unsigned long)arg->params_ptr,
> +  size)) {
> +   ret = -EFAULT;
> +   DRM_DEBUG_DRIVER("Failed to copy configuration from 
> userspace\n");
> +   goto free;
> +   }
> +
> +   params = p;
> +   while (size) {
> +   struct exynos_drm_param_map *map = exynos_drm_ipp_params_maps;
I'd just drop this since...

> +   u32 *id = params;
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(exynos_drm_ipp_params_maps); i++)
... using ARRAY_SIZE(foo) only to access bar[] is quite misleading.

> +   if (map[i].id == *id)
> +   break;
> +
> +   if (i < ARRAY_SIZE(exynos_drm_ipp_params_maps) &&
> +   map[i].size <= size) {
> +   memcpy((void *)task + map[i].offset, params,
> +  map[i].size);
> +   params += map[i].size;
> +   size -= map[i].size;
> +   } else {
> +   ret = -EINVAL;
> +   goto free;
> +   }
Maybe flip the condition order?
if (!foo)
   ret = -EINVAL;
   goto xx;

Re: [PATCHv4 3/5] dt-bindings: document the CEC GPIO bindings

[Rob Herring]

On Thu, Aug 31, 2017 at 01:01:54PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Document the bindings for the cec-gpio module for hardware where the
> CEC line and optionally the HPD line are connected to GPIO lines.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/cec-gpio.txt | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
> b/Documentation/devicetree/bindings/media/cec-gpio.txt
> new file mode 100644
> index ..db20a7452dbd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
> @@ -0,0 +1,22 @@
> +* HDMI CEC GPIO driver
> +
> +The HDMI CEC GPIO module supports CEC implementations where the CEC line
> +is hooked up to a pull-up GPIO line and - optionally - the HPD line is
> +hooked up to another GPIO line.
> +
> +Required properties:
> +  - compatible: value must be "cec-gpio"
> +  - cec-gpio: gpio that the CEC line is connected to

cec-gpios

> +
> +Optional property:
> +  - hpd-gpio: gpio that the HPD line is connected to

hpd-gpios

However, HPD is already part of the HDMI connector binding. Having it in 
2 places would be wrong.

I think we should have either:

hdmi-connector {
compatible = 'hdmi-connector-a";
hpd-gpios = <...>;
cec-gpios = <...>;
ports {
// port to HDMI controller
...
};
};

Or:

hdmi-connector {
compatible = 'hdmi-connector-a";
hpd-gpios = <...>;
cec = <>;
... 
};

cec: cec-gpio {
compatible = "cec-gpio";
cec-gpios = <...>;
};

My preference is probably the former. The latter just helps create a 
device to bind to a driver, but DT is not the only way to create 
devices. Then again, if you have a phandle to real CEC controllers in 
the HDMI connector node, it may make sense to do the same thing with 
cec-gpio. 

> +
> +Example for the Raspberry Pi 3 where the CEC line is connected to
> +pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
> +connected to pin 11 aka BCM17:
> +
> +cec-gpio@7 {

unit address is not valid. Build your dts's with W=2.

> +   compatible = "cec-gpio";
> +   cec-gpio = < 7 GPIO_OPEN_DRAIN>;
> +   hpd-gpio = < 17 GPIO_ACTIVE_HIGH>;
> +};
> -- 
> 2.14.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Gerd Hoffmann]

On Tue, 2017-09-12 at 17:09 +0300, Dan Carpenter wrote:
> On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> > That said, I'm not sure how useful the information is - perhaps
> > it's
> > better to drop it all together?
> 
> Or a WARN_ONCE().

It's userspace calling into the driver with invalid parameters.

IMO we should never WARN_ONCE() on something userspace can trigger.

I'd suggest to just drop the message altogether, simply throwing EINVAL
at userspace is perfectly fine IMHO.

cheers,
  Gerd

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

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Dan Carpenter]

On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> That said, I'm not sure how useful the information is - perhaps it's
> better to drop it all together?

Or a WARN_ONCE().

regards,
dan carpenter

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

[Bug 102650] [CI][ALL] igt@sw_sync@timeline_closed - Failure waiting on unsignaled fence on closed timeline

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

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

--- Comment #2 from Chris Wilson  ---
commit c7e116007e907f32c18cc2669e2dc4046553c8e6 (HEAD, upstream/master)
Author: Chris Wilson 
Date:   Mon Sep 11 13:23:27 2017 +0100

igt/sw_sync: Fix up close(timeline) tests for unsignaled fences

Following

kernel commit ea4d5a270b57fa8d4871f372ca9b97b7697fdfda
Author: Dominik Behr 
Date:   Thu Sep 7 16:02:46 2017 -0300

dma-buf/sw_sync: force signal all unsignaled fences on dying timeline

To avoid hanging userspace components that might have been waiting on
the
active fences of the destroyed timeline we need to signal with error
all
remaining fences on such timeline.

This restore the default behaviour of the Android sw_sync framework,
which
Android still relies on. It was broken on the dma fence conversion a
few
years ago and never fixed.

unsignaled fences are now signaled and flagged with ENOENT when the
timeline is closed. Fixup timeline_closed_signaled to match.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102650
Signed-off-by: Chris Wilson 
Reviewed-by: Michał Winiarski 

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

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Emil Velikov]

Hi Colin,

On 12 September 2017 at 10:45, Colin King  wrote:
> From: Colin Ian King 
>
> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
> log with qxl_mmap information messages. The following example code
> illustrates this:
>
> int main(void)
> {
> int fd = open("/dev/dri/card0", O_RDONLY);
> if (fd == -1)
> err(1, "open failed");
>
> for (;;) {
> void *m = mmap(NULL, 4096, PROT_READ,
> MAP_SHARED, fd, 0);
> if (m != MAP_FAILED)
> munmap(m, 4096);
> }
> }
>
> Reduce the spamming by ratelimiting the pr_info messages.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 7ecf8a4b9fe6..6502e699f462 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -124,7 +124,7 @@ int qxl_mmap(struct file *filp, struct vm_area_struct 
> *vma)
> int r;
>
> if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
> -   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
> +   pr_info_ratelimited("%s: vma->vm_pgoff (%ld) < 
> DRM_FILE_PAGE_OFFSET\n",
Quick grep suggests that only qxl and vmwgfx produce any output in
this case, likely for the reasons you mentioned.

That said, I'm not sure how useful the information is - perhaps it's
better to drop it all together? Regardless of the route taken, vmwgfx
could use a similar fix.

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

Re: [PATCH v2 1/6] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting, v2.

[Emil Velikov]

On 12 September 2017 at 14:37, Maarten Lankhorst
 wrote:
> When we want to make drm_atomic_commit interruptible, there are a lot of
> places that call the lock function, which we don't have control over.
>
> Rather than trying to convert every single one, it's easier to toggle
> interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is
> called with DRM_MODESET_ACQUIRE_INTERRUPTIBLE, then we will perform
> interruptible waits in drm_modeset_lock and drm_modeset_backoff.
>
> Changes since v1:
> - Fix locking example in drm_modeset_lock.c to be compatible
>   with interruptible waiting (xexaxo) and make it default.
>   Uninterruptible waiting shouldn't happen except in corner cases,
>   but the example will still apply if the flag is removed.
> - Add drm_modeset_lock_single_interruptible() to documentation.
> - Fix dead link to removed drm_modeset_lock_interruptible() in
>   drm_modeset_lock().
>
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Daniel Vetter  #v1
> Cc: Emil Velikov 
Thanks for the documentation updates/fixes Maarten. FWIW the series is
Reviewed-by: Emil Velikov 

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

[PATCH v2 0/6] drm/atomic: Interruptible locks for everyone!

[Maarten Lankhorst]

drm_atomic_commit could previous have always failed when waits failed,
but locking was always done uninterruptibly. Add infrastructure to make
it possible for callers to choose interruptible locking, and convert the
5 most common ioctl's to use it.

All other atomic helpers can be converted when additional tests are added
to kms_atomic_interruptible.

Changes since last version:
- Small fixes to the preparation patch
- Convert setcrtc as well.

Maarten Lankhorst (6):
  drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible
waiting, v2.
  drm/atomic: Convert atomic ioctl locking to interruptible.
  drm/legacy: Convert cursor ioctl locking to interruptible.
  drm/legacy: Convert setplane ioctl locking to interruptible.
  drm/atomic: Convert pageflip ioctl locking to interruptible.
  drm/crtc: Convert setcrtc ioctl locking to interruptible.

 drivers/gpu/drm/drm_atomic.c   |  7 +--
 drivers/gpu/drm/drm_crtc.c |  7 +--
 drivers/gpu/drm/drm_debugfs_crc.c  |  2 +-
 drivers/gpu/drm/drm_modeset_lock.c | 96 +++---
 drivers/gpu/drm/drm_plane.c| 21 +
 include/drm/drm_modeset_lock.h | 12 +++--
 6 files changed, 77 insertions(+), 68 deletions(-)

-- 
2.14.1

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

[PATCH v2 6/6] drm/crtc: Convert setcrtc ioctl locking to interruptible.

[Maarten Lankhorst]

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5af25ce5bf7c..68b4e976d5e0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -577,7 +577,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
 
mutex_lock(>dev->mode_config.mutex);
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
ret = drm_modeset_lock_all_ctx(crtc->dev, );
if (ret)
@@ -717,8 +717,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
kfree(connector_set);
drm_mode_destroy(dev, mode);
if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
-- 
2.14.1

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

[PATCH v2 2/6] drm/atomic: Convert atomic ioctl locking to interruptible.

[Maarten Lankhorst]

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and
handle drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 75f5f74de9bf..366c56fe5f58 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2234,7 +2234,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
(arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
return -EINVAL;
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -2347,8 +2347,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 
if (ret == -EDEADLK) {
drm_atomic_state_clear(state);
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
 
drm_atomic_state_put(state);
-- 
2.14.1

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

[PATCH v2 4/6] drm/legacy: Convert setplane ioctl locking to interruptible.

[Maarten Lankhorst]

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index eef58595101c..803d67c22da2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -667,7 +667,7 @@ static int setplane_internal(struct drm_plane *plane,
struct drm_modeset_acquire_ctx ctx;
int ret;
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
ret = drm_modeset_lock_all_ctx(plane->dev, );
if (ret)
@@ -678,8 +678,9 @@ static int setplane_internal(struct drm_plane *plane,
 
 fail:
if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
-- 
2.14.1

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

[PATCH v2 5/6] drm/atomic: Convert pageflip ioctl locking to interruptible.

[Maarten Lankhorst]

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 803d67c22da2..72cba9805edc 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -987,7 +987,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return -EINVAL;
}
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
ret = drm_modeset_lock(>mutex, );
if (ret)
@@ -1076,8 +1076,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
crtc->primary->old_fb = NULL;
 
if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
 
drm_modeset_drop_locks();
-- 
2.14.1

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

[PATCH v2 3/6] drm/legacy: Convert cursor ioctl locking to interruptible.

[Maarten Lankhorst]

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 7a00351d5b5d..eef58595101c 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -834,7 +834,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
return -ENOENT;
}
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
ret = drm_modeset_lock(>mutex, );
if (ret)
@@ -876,8 +876,9 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
 out:
if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
 
drm_modeset_drop_locks();
-- 
2.14.1

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

[PATCH v2 1/6] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting, v2.

[Maarten Lankhorst]

When we want to make drm_atomic_commit interruptible, there are a lot of
places that call the lock function, which we don't have control over.

Rather than trying to convert every single one, it's easier to toggle
interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is
called with DRM_MODESET_ACQUIRE_INTERRUPTIBLE, then we will perform
interruptible waits in drm_modeset_lock and drm_modeset_backoff.

Changes since v1:
- Fix locking example in drm_modeset_lock.c to be compatible
  with interruptible waiting (xexaxo) and make it default.
  Uninterruptible waiting shouldn't happen except in corner cases,
  but the example will still apply if the flag is removed.
- Add drm_modeset_lock_single_interruptible() to documentation.
- Fix dead link to removed drm_modeset_lock_interruptible() in
  drm_modeset_lock().

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter  #v1
Cc: Emil Velikov 
---
 drivers/gpu/drm/drm_debugfs_crc.c  |  2 +-
 drivers/gpu/drm/drm_modeset_lock.c | 96 +++---
 include/drm/drm_modeset_lock.h | 12 +++--
 3 files changed, 57 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index f9e26dda56d6..9dd879589a2c 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -155,7 +155,7 @@ static int crtc_crc_open(struct inode *inode, struct file 
*filep)
int ret = 0;
 
if (drm_drv_uses_atomic_modeset(crtc->dev)) {
-   ret = drm_modeset_lock_interruptible(>mutex, NULL);
+   ret = drm_modeset_lock_single_interruptible(>mutex);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index af4e906c630d..e123497da0ca 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -39,23 +39,28 @@
  *
  * The basic usage pattern is to::
  *
- * drm_modeset_acquire_init()
+ * drm_modeset_acquire_init(ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE)
  * retry:
  * foreach (lock in random_ordered_set_of_locks) {
- * ret = drm_modeset_lock(lock, )
+ * ret = drm_modeset_lock(lock, ctx)
  * if (ret == -EDEADLK) {
- * drm_modeset_backoff();
- * goto retry;
+ * ret = drm_modeset_backoff(ctx);
+ * if (!ret)
+ * goto retry;
  * }
+ * if (ret)
+ * goto out;
  * }
  * ... do stuff ...
- * drm_modeset_drop_locks();
- * drm_modeset_acquire_fini();
+ * out:
+ * drm_modeset_drop_locks(ctx);
+ * drm_modeset_acquire_fini(ctx);
  *
  * If all that is needed is a single modeset lock, then the 
  * drm_modeset_acquire_ctx is not needed and the locking can be simplified
- * by passing a NULL instead of ctx in the drm_modeset_lock()
- * call and, when done, by calling drm_modeset_unlock().
+ * by passing a NULL instead of ctx in the drm_modeset_lock() call or
+ * calling  drm_modeset_lock_single_interruptible(). To unlock afterwards
+ * call drm_modeset_unlock().
  *
  * On top of these per-object locks using _mutex there's also an overall
  * _mode_config.mutex, for protecting everything else. Mostly this means
@@ -178,7 +183,11 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
 /**
  * drm_modeset_acquire_init - initialize acquire context
  * @ctx: the acquire context
- * @flags: for future
+ * @flags: 0 or %DRM_MODESET_ACQUIRE_INTERRUPTIBLE
+ *
+ * When passing %DRM_MODESET_ACQUIRE_INTERRUPTIBLE to @flags,
+ * all calls to drm_modeset_lock() will perform an interruptible
+ * wait.
  */
 void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
uint32_t flags)
@@ -186,6 +195,9 @@ void drm_modeset_acquire_init(struct 
drm_modeset_acquire_ctx *ctx,
memset(ctx, 0, sizeof(*ctx));
ww_acquire_init(>ww_ctx, _ww_class);
INIT_LIST_HEAD(>locked);
+
+   if (flags & DRM_MODESET_ACQUIRE_INTERRUPTIBLE)
+   ctx->interruptible = true;
 }
 EXPORT_SYMBOL(drm_modeset_acquire_init);
 
@@ -261,8 +273,19 @@ static inline int modeset_lock(struct drm_modeset_lock 
*lock,
return ret;
 }
 
-static int modeset_backoff(struct drm_modeset_acquire_ctx *ctx,
-   bool interruptible)
+/**
+ * drm_modeset_backoff - deadlock avoidance backoff
+ * @ctx: the acquire context
+ *
+ * If deadlock is detected (ie. drm_modeset_lock() returns -EDEADLK),
+ * you must call this function to drop all currently held locks and
+ * block until the contended lock becomes available.
+ *
+ * This function returns 0 on success, or -ERESTARTSYS if this context
+ * is initialized with %DRM_MODESET_ACQUIRE_INTERRUPTIBLE and the
+ * wait has been interrupted.
+ */
+int drm_modeset_backoff(struct drm_modeset_acquire_ctx *ctx)
 {
struct 

Re: [PATCH 10/10] drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes

[Andrzej Hajda]

On 12.09.2017 14:50, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Since HDMI can handle these modes despite of MIXER limitations lets
>> enable them.
> lets --> let's
>
> Reviewed-by: Tobias Jakobi 


Thanks for review, I will apply all your grammar/style suggestions in
next iteration.

Regards
Andrzej

>
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 5aae82b..108dccb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -1014,6 +1014,9 @@ static int mixer_mode_valid(struct exynos_drm_crtc 
>> *crtc,
>>  (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
>>  return MODE_OK;
>>  
>> +if ((w == 1024 && h == 768) || (w == 1280 && h == 1024))
>> +return MODE_OK;
>> +
>>  return MODE_BAD;
>>  }
>>  
>>
>
>
>

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

[PATCH i-g-t] tests: Add kms_atomic_interruptible test, v4.

[Maarten Lankhorst]

This tests the various parts of atomic that I want to make
interruptible. Running with --debug shows the stats from
__igt_sigiter_continue, which can be used to make sure that
we don't fall over.

The default igt kms helpers use drmIoctl, which is not intercepted
by igt_while_interruptible. Only igt_ioctl is. This means we have
to call the ioctls manually here.

Changes since v1:
- Implement interruptible DPMS checking too.
- Use igt_ioctl + igt_while_interruptible, instead of the signal helper
  shotgun.
Changes since v2:
- Bump whitespace to get rid of the weird double } at same indent.
- Use more newlines in the call to the atomic ioctl.
Changes since v3:
- Fix copyright on year. (Adrinael)
- Use do_ioctl instead of do_or_die(igt_ioctl) (ickle).
- Add test description. (Adrinael)

Signed-off-by: Maarten Lankhorst 
Cc: Daniel Stone 
Acked-by: Daniel Vetter  #v1
Reviewed-by: Petri Latvala 
[mlankhorst: Document sleep values (Adrinael)]
---
 lib/igt_kms.c|   3 +-
 lib/igt_kms.h|   1 +
 tests/Makefile.sources   |   1 +
 tests/kms_atomic_interruptible.c | 331 +++
 4 files changed, 335 insertions(+), 1 deletion(-)
 create mode 100644 tests/kms_atomic_interruptible.c

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 72fde792ba89..7bcafc072f70 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -186,7 +186,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
 
 const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
"scaling mode",
-   "CRTC_ID"
+   "CRTC_ID",
+   "DPMS"
 };
 
 /*
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index e5dc329b161e..3d1061fa08c8 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -114,6 +114,7 @@ extern const char *igt_crtc_prop_names[];
 enum igt_atomic_connector_properties {
IGT_CONNECTOR_SCALING_MODE = 0,
IGT_CONNECTOR_CRTC_ID,
+   IGT_CONNECTOR_DPMS,
IGT_NUM_CONNECTOR_PROPS
 };
 
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0f4e39af10a1..cf542df181a8 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -172,6 +172,7 @@ TESTS_progs = \
kms_3d \
kms_addfb_basic \
kms_atomic \
+   kms_atomic_interruptible \
kms_atomic_transition \
kms_busy \
kms_ccs \
diff --git a/tests/kms_atomic_interruptible.c b/tests/kms_atomic_interruptible.c
new file mode 100644
index ..4e06ee4e2d6b
--- /dev/null
+++ b/tests/kms_atomic_interruptible.c
@@ -0,0 +1,331 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * 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 "igt.h"
+#include "drmtest.h"
+#include "sw_sync.h"
+
+IGT_TEST_DESCRIPTION("Tests that interrupt various atomic ioctls.");
+
+enum plane_test_type
+{
+   test_legacy_modeset,
+   test_atomic_modeset,
+   test_legacy_dpms,
+   test_setplane,
+   test_setcursor,
+   test_pageflip
+};
+
+static int block_plane(igt_display_t *display, igt_output_t *output, enum 
plane_test_type test_type, igt_plane_t *plane)
+{
+   int timeline = sw_sync_timeline_create();
+
+   igt_fork(child, 1) {
+   /* Ignore the signal helper, we need to block indefinitely on 
the fence. */
+   signal(SIGCONT, SIG_IGN);
+
+   if (test_type == test_legacy_modeset || test_type == 
test_atomic_modeset) {
+   igt_output_set_pipe(output, PIPE_NONE);
+   igt_plane_set_fb(plane, NULL);
+   }
+   igt_plane_set_fence_fd(plane, 
sw_sync_timeline_create_fence(timeline, 1));
+
+   igt_display_commit2(display, COMMIT_ATOMIC);
+   }
+
+   return timeline;
+}
+
+static void unblock(int block)
+{
+   

Re: [PATCH 09/10] drm/exynos/hdmi: quirk for support mode timings conversion

[Andrzej Hajda]

On 12.09.2017 14:50, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
>> 720x480, 720x576, 1280x720, 1920x1080. Support for other modes
>> can be enabled by manipulating timings of HDMI. To do it
>> adjusted_mode should contain actual mode set on crtc.
>> With this patch it is possible to enable 1024x768 and 1280x1024
>> modes in MIXER.
> Reviewed-by: Tobias Jakobi 
>
> And some question below.
>
>
>> Suggested-by: Daniel Drake 
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 7225b65..4b081f6 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -1239,6 +1239,17 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
>> *hdata)
>>  static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
>>  {
>>  struct drm_display_mode *m = >encoder.crtc->state->mode;
>> +struct drm_display_mode *am = 
>> >encoder.crtc->state->adjusted_mode;
>> +int hquirk = 0;
>> +
>> +/*
>> + * In case video mode coming from CRTC differs from requested one HDMI
>> + * sometimes is able to almost properly perform conversion - only
>> + * first line is distorted.
>> + */
>> +if ((m->vdisplay != am->vdisplay) &&
>> +(m->hdisplay == 1280 || m->hdisplay == 1024))
>> +hquirk = 258;
> Can it even happen, that m->hdisplay is neither 1280 nor 1024 but "m->vdisplay
> != am->vdisplay" still holds?

1680x1050-60 for example, it works without quirks.

Regards
Andrzej

>
>
>
>>  hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
>>  hdmi_reg_writev(hdata, HDMI_V_LINE_0, 2, m->vtotal);
>> @@ -1332,8 +1343,8 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
>> *hdata)
>>  hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_6_0, 2, 0x);
>>  
>>  hdmi_reg_writev(hdata, HDMI_TG_H_FSZ_L, 2, m->htotal);
>> -hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay);
>> -hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay);
>> +hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay - 
>> hquirk);
>> +hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay + hquirk);
>>  hdmi_reg_writev(hdata, HDMI_TG_V_FSZ_L, 2, m->vtotal);
>>  if (hdata->drv_data == _hdmi_driver_data)
>>  hdmi_reg_writeb(hdata, HDMI_TG_DECON_EN, 1);
>>
>
>
>

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

Re: [PATCH 07/10] drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops

[Andrzej Hajda]

On 12.09.2017 14:41, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> crtc::mode_fixup callback is required by crtcs which use internally
>> different mode than requested by user - case of Exynos Mixer.
> "...which internally use a different..."
>
>
> Reviewed-by: Tobias Jakobi 
>
> With one suggestion below.
>
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +++
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  3 +++
>>  2 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 6ce0821..dc01342 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -95,8 +95,23 @@ static enum drm_mode_status exynos_crtc_mode_valid(struct 
>> drm_crtc *crtc,
>>  return MODE_OK;
>>  }
>>  
>> +static bool exynos_crtc_mode_fixup(struct drm_crtc *crtc,
>> +const struct drm_display_mode *mode,
>> +struct drm_display_mode *adjusted_mode)
>> +{
>> +struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> +
>> +if (exynos_crtc->ops->mode_fixup)
>> +return exynos_crtc->ops->mode_fixup(exynos_crtc, mode,
>> +adjusted_mode);
>> +
>> +return true;
>> +}
>> +
>> +
>>  static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
>>  .mode_valid = exynos_crtc_mode_valid,
>> +.mode_fixup = exynos_crtc_mode_fixup,
>>  .atomic_check   = exynos_crtc_atomic_check,
>>  .atomic_begin   = exynos_crtc_atomic_begin,
>>  .atomic_flush   = exynos_crtc_atomic_flush,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index cf131c2..e8bcc72 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -136,6 +136,9 @@ struct exynos_drm_crtc_ops {
>>  u32 (*get_vblank_counter)(struct exynos_drm_crtc *crtc);
>>  enum drm_mode_status (*mode_valid)(struct exynos_drm_crtc *crtc,
>>  const struct drm_display_mode *mode);
>> +bool (*mode_fixup)(struct exynos_drm_crtc *crtc,
>> +   const struct drm_display_mode *mode,
>> +   struct drm_display_mode *adjusted_mode);
> I'm always wary when I encounter a bool as return value, since to check what
> true/false actually encodes, I need to have some reference which I can check.
> Just go for an integer here and use standard convention that negative values 
> are
> errors?

It is forwarder for drm core op so I prefer to keep return values
consistent.

Regards
Andrzej

>
>
>
>>  int (*atomic_check)(struct exynos_drm_crtc *crtc,
>>  struct drm_crtc_state *state);
>>  void (*atomic_begin)(struct exynos_drm_crtc *crtc);
>>
>
>
>

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

Re: [PATCH 04/10] drm/exynos/mixer: fix mode validation code

[Andrzej Hajda]

On 12.09.2017 14:31, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Mode limitation checked in mixer driver affects only older HW.
>> Mixer in Exynos542x has no such limitations. While at it patch changes
>> validation callback to recently introduced mode_valid which is more
>> suitable for the check. Additionally little cleanup is performed.
> Reviewed-by: Tobias Jakobi 
>
> And some small suggestion below.
>
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 24 +++-
>>  1 file changed, 11 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index a87f60b..d530c18 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -1040,26 +1040,24 @@ static void mixer_disable(struct exynos_drm_crtc 
>> *crtc)
>>  clear_bit(MXR_BIT_POWERED, >flags);
>>  }
>>  
>> -/* Only valid for Mixer version 16.0.33.0 */
>> -static int mixer_atomic_check(struct exynos_drm_crtc *crtc,
>> -   struct drm_crtc_state *state)
>> +static int mixer_mode_valid(struct exynos_drm_crtc *crtc,
>> +const struct drm_display_mode *mode)
>>  {
>> -struct drm_display_mode *mode = >adjusted_mode;
>> -u32 w, h;
>> +struct mixer_context *ctx = crtc->ctx;
>> +u32 w = mode->hdisplay, h = mode->vdisplay;
>>  
>> -w = mode->hdisplay;
>> -h = mode->vdisplay;
>> +DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%d\n", w, h,
>> +mode->vrefresh, !!(mode->flags & DRM_MODE_FLAG_INTERLACE));
>>  
>> -DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%d\n",
>> -mode->hdisplay, mode->vdisplay, mode->vrefresh,
>> -(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>> +if (ctx->mxr_ver == MXR_VER_128_0_0_184)
>> +return MODE_OK;
>>  
>>  if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>>  (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>>  (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> I think it would be nice to have these aligned.

Yes, it should look better.

Regards
Andrzej


>
>
>> -return 0;
>> +return MODE_OK;
>>  
>> -return -EINVAL;
>> +return MODE_BAD;
>>  }
>>  
>>  static const struct exynos_drm_crtc_ops mixer_crtc_ops = {
>> @@ -1071,7 +1069,7 @@ static const struct exynos_drm_crtc_ops mixer_crtc_ops 
>> = {
>>  .update_plane   = mixer_update_plane,
>>  .disable_plane  = mixer_disable_plane,
>>  .atomic_flush   = mixer_atomic_flush,
>> -.atomic_check   = mixer_atomic_check,
>> +.mode_valid = mixer_mode_valid,
>>  };
>>  
>>  static const struct mixer_drv_data exynos5420_mxr_drv_data = {
>>
>
>
>

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

Re: [PATCH 01/10] drm/exynos/mixer: abstract out output mode setup code

[Andrzej Hajda]

Hi Tobias,

Thanks for review.


On 12.09.2017 14:29, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Mode setup code is called from video plane update and mixer plane update.
>> Lets group it together in mixer_commit function like in case of other
>> Exynos CRTCs.
> Minor typo: Lets --> Let's
>
> Reviewed-by: Tobias Jakobi 
>
> With some small question below.
>
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 ++---
>>  1 file changed, 18 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 0027554..499ebdc 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -473,6 +473,22 @@ static void mixer_stop(struct mixer_context *ctx)
>>  usleep_range(1, 12000);
>>  }
>>  
>> +static void mixer_commit(struct mixer_context *ctx)
>> +{
>> +struct drm_display_mode *mode = >crtc->base.state->adjusted_mode;
>> +
>> +/* setup display size */
>> +if (ctx->mxr_ver == MXR_VER_128_0_0_184) {
>> +u32 val  = MXR_MXR_RES_HEIGHT(mode->vdisplay)
>> + | MXR_MXR_RES_WIDTH(mode->hdisplay);
>> +mixer_reg_write(>mixer_res, MXR_RESOLUTION, val);
>> +}
>> +
>> +mixer_cfg_scan(ctx, mode->vdisplay);
>> +mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
>> +mixer_run(ctx);
>> +}
>> +
>>  static void vp_video_buffer(struct mixer_context *ctx,
>>  struct exynos_drm_plane *plane)
>>  {
>> @@ -553,11 +569,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
>>  vp_reg_write(res, VP_TOP_C_PTR, chroma_addr[0]);
>>  vp_reg_write(res, VP_BOT_C_PTR, chroma_addr[1]);
>>  
>> -mixer_cfg_scan(ctx, mode->vdisplay);
>> -mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
>>  mixer_cfg_layer(ctx, plane->index, priority, true);
>>  mixer_cfg_vp_blend(ctx);
>> -mixer_run(ctx);
>> +mixer_commit(ctx);
>>  
>>  spin_unlock_irqrestore(>reg_slock, flags);
>>  
>> @@ -638,14 +652,6 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx,
>>  mixer_reg_write(res, MXR_GRAPHIC_SPAN(win),
>>  fb->pitches[0] / fb->format->cpp[0]);
>>  
>> -/* setup display size */
>> -if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
>> -win == DEFAULT_WIN) {
>> -val  = MXR_MXR_RES_HEIGHT(mode->vdisplay);
>> -val |= MXR_MXR_RES_WIDTH(mode->hdisplay);
>> -mixer_reg_write(res, MXR_RESOLUTION, val);
>> -}
>> -
>>  val  = MXR_GRP_WH_WIDTH(state->src.w);
>>  val |= MXR_GRP_WH_HEIGHT(state->src.h);
>>  val |= MXR_GRP_WH_H_SCALE(x_ratio);
>> @@ -660,18 +666,15 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx,
>>  /* set buffer address to mixer */
>>  mixer_reg_write(res, MXR_GRAPHIC_BASE(win), dma_addr);
>>  
>> -mixer_cfg_scan(ctx, mode->vdisplay);
>> -mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
>>  mixer_cfg_layer(ctx, win, priority, true);
>>  mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
>> +mixer_commit(ctx);
> With this change, mixer_run() is now done before mixer_layer_update(). I just
> wanted to make sure that the order of operations isn't critical here.

It shoudn't matter, as it is between atomic_begin, which disables shadow
updates,
and atomic_flush, which re-enables them.

Regards
Andrzej

>
>
>
>>  /* layer update mandatory for mixer 16.0.33.0 */
>>  if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
>>  ctx->mxr_ver == MXR_VER_128_0_0_184)
>>  mixer_layer_update(ctx);
>>  
>> -mixer_run(ctx);
>> -
>>  spin_unlock_irqrestore(>reg_slock, flags);
>>  
>>  mixer_regs_dump(ctx);
>>
>
>
>

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