Re: [PATCH v3 05/16] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Daniel Vetter]

On Wed, Jul 5, 2017 at 7:50 PM, Peter Rosin  wrote:
>>> +retry:
>>> +ret = drm_modeset_lock_all_ctx(dev, );
>>
>> With atomic you don't need to grab locks, this is done behind the scenes
>> (as long as you handle the retry/backoff correctly). See the kerneldoc for
>> the various drm_atomic_get_*_state functions.
>
> It doesn't work if I remove it. What is the disconnect?

Good question, didn't spot this at first, but your backoff/retry logic
is proken. When typing drm_modeset_lock locking code please make sure
you've enabled both CONFIG_PROVE_LOCKING and
CONFIG_DEBUG_WW_MUTEX_SLOWPATH. Without these two it's really easy to
get this wrong. Please also read
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#kms-locking
carefully plus all the kernel-doc of the various hooks. This stuff is
a really tricky locking scheme, it takes a while to understand it and
implement it correctly. Which is why all the locking magic is in
shared code and for normal drivers no need think about it. For the
fundamental algorithm, you can also check out the docs for w/w mutexes
at https://www.kernel.org/doc/Documentation/locking/ww-mutex-design.txt

Might also help to read a bunch of the other locking paths again, with
my patches there's a few just in drm_fbdev_helper.c. I'll leave you
with these snippets here since I think this is fun to learn, but when
you're stuck I'm happy to help learn.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/6] drm: Add four ioctls for managing drm mode object leases [v3]

[Keith Packard]

Dave Airlie  writes:

> I think this needs a pad ^.

> And this.

Yup. Thanks!

>> +struct drm_mode_revoke_lease {
>> +   /** Unique ID of lessee
>> +*/
>> +   __u32 lessee_id;
>
> And this.

None of the other bare 32-bit ioctl structures are padded; I think
that's probably fine as they'll be 4 bytes on both 64-bit and 32-bit
machines.

-- 
-keith


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

Re: [PATCH 12/13] drm/exynos: Remove custom FB helper deferred setup

[Inki Dae]

2017년 07월 05일 00:18에 Daniel Vetter 이(가) 쓴 글:
> From: Thierry Reding 
> 
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.

Reviewed-by: Inki Dae 
Tested-by: Inki Dae 

Thanks,
Inki Dae

> 
> v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Signed-off-by: Thierry Reding  (v1)
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  6 --
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 +-
>  2 files changed, 5 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 35a8dfc93836..cab9e12d7846 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -395,8 +395,9 @@ static int exynos_drm_bind(struct device *dev)
>   /* init kms poll for handling hpd */
>   drm_kms_helper_poll_init(drm);
>  
> - /* force connectors detection */
> - drm_helper_hpd_irq_event(drm);
> + ret = exynos_drm_fbdev_init(drm);
> + if (ret)
> + goto err_cleanup_poll;
>  
>   /* register the DRM device */
>   ret = drm_dev_register(drm, 0);
> @@ -407,6 +408,7 @@ static int exynos_drm_bind(struct device *dev)
>  
>  err_cleanup_fbdev:
>   exynos_drm_fbdev_fini(drm);
> +err_cleanup_poll:
>   drm_kms_helper_poll_fini(drm);
>   exynos_drm_device_subdrv_remove(drm);
>  err_unbind_all:
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 641531243e04..c3a068409b48 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -183,24 +183,6 @@ static const struct drm_fb_helper_funcs 
> exynos_drm_fb_helper_funcs = {
>   .fb_probe = exynos_drm_fbdev_create,
>  };
>  
> -static bool exynos_drm_fbdev_is_anything_connected(struct drm_device *dev)
> -{
> - struct drm_connector *connector;
> - bool ret = false;
> -
> - mutex_lock(>mode_config.mutex);
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - if (connector->status != connector_status_connected)
> - continue;
> -
> - ret = true;
> - break;
> - }
> - mutex_unlock(>mode_config.mutex);
> -
> - return ret;
> -}
> -
>  int exynos_drm_fbdev_init(struct drm_device *dev)
>  {
>   struct exynos_drm_fbdev *fbdev;
> @@ -211,9 +193,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
>   if (!dev->mode_config.num_crtc || !dev->mode_config.num_connector)
>   return 0;
>  
> - if (!exynos_drm_fbdev_is_anything_connected(dev))
> - return 0;
> -
>   fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
>   if (!fbdev)
>   return -ENOMEM;
> @@ -304,8 +283,5 @@ void exynos_drm_output_poll_changed(struct drm_device 
> *dev)
>   struct exynos_drm_private *private = dev->dev_private;
>   struct drm_fb_helper *fb_helper = private->fb_helper;
>  
> - if (fb_helper)
> - drm_fb_helper_hotplug_event(fb_helper);
> - else
> - exynos_drm_fbdev_init(dev);
> + drm_fb_helper_hotplug_event(fb_helper);
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

[Dave Airlie]

From: Dave Airlie 

This adds kernel semaphore support to the command submission
interface in what should be a backwards compatible manner,
it adds a new command submission API.

Signed-off-by: Dave Airlie 
---
 amdgpu/amdgpu.h|  29 -
 amdgpu/amdgpu_cs.c | 118 +
 2 files changed, 138 insertions(+), 9 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 1901fa8..649b66e 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -369,6 +369,16 @@ struct amdgpu_cs_request {
struct amdgpu_cs_fence_info fence_info;
 };
 
+struct amdgpu_cs_request_syncobj {
+   /*
+*
+*/
+   uint32_t number_in_syncobj;
+   uint32_t number_out_syncobj;
+   uint32_t *in_syncobj;
+   uint32_t *out_syncobj;
+};
+
 /**
  * Structure which provide information about GPU VM MC Address space
  * alignments requirements
@@ -886,6 +896,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
 struct amdgpu_cs_request *ibs_request,
 uint32_t number_of_requests);
 
+int amdgpu_cs_submit_syncobj(amdgpu_context_handle context,
+uint64_t flags,
+struct amdgpu_cs_request *ibs_request,
+struct amdgpu_cs_request_syncobj *ibs_syncobj,
+uint32_t number_of_requests);
+
 /**
  *  Query status of Command Buffer Submission
  *
@@ -1328,8 +1344,19 @@ int amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle 
sem);
 */
 const char *amdgpu_get_marketing_name(amdgpu_device_handle dev);
 
+
+int amdgpu_cs_create_syncobj(amdgpu_device_handle dev,
+uint32_t *syncobj);
+int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
+uint32_t syncobj,
+int *shared_fd);
+int amdgpu_cs_import_syncobj(amdgpu_device_handle dev,
+int shared_fd,
+uint32_t *syncobj);
+int amdgpu_cs_destroy_syncobj(amdgpu_device_handle dev,
+ uint32_t syncobj);
+
 #ifdef __cplusplus
 }
 #endif
-
 #endif /* #ifdef _AMDGPU_H_ */
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 868eb7b..339c5f9 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -168,7 +168,8 @@ int amdgpu_cs_query_reset_state(amdgpu_context_handle 
context,
  * \sa amdgpu_cs_submit()
 */
 static int amdgpu_cs_submit_one(amdgpu_context_handle context,
-   struct amdgpu_cs_request *ibs_request)
+   struct amdgpu_cs_request *ibs_request,
+   struct amdgpu_cs_request_syncobj 
*syncobj_request)
 {
union drm_amdgpu_cs cs;
uint64_t *chunk_array;
@@ -176,10 +177,13 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
struct drm_amdgpu_cs_chunk_data *chunk_data;
struct drm_amdgpu_cs_chunk_dep *dependencies = NULL;
struct drm_amdgpu_cs_chunk_dep *sem_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *in_syncobj_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *out_syncobj_dependencies = NULL;
struct list_head *sem_list;
amdgpu_semaphore_handle sem, tmp;
-   uint32_t i, size, sem_count = 0;
+   uint32_t i, j, size, sem_count = 0;
bool user_fence;
+   uint32_t sem_size = 0;
int r = 0;
 
if (ibs_request->ip_type >= AMDGPU_HW_IP_NUM)
@@ -194,7 +198,11 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
}
user_fence = (ibs_request->fence_info.handle != NULL);
 
-   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1;
+   if (syncobj_request) {
+   sem_size += syncobj_request->number_in_syncobj ? 1 : 0;
+   sem_size += syncobj_request->number_out_syncobj ? 1 : 0;
+   }
+   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1 + sem_size;
 
chunk_array = alloca(sizeof(uint64_t) * size);
chunks = alloca(sizeof(struct drm_amdgpu_cs_chunk) * size);
@@ -306,6 +314,45 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
chunks[i].chunk_data = (uint64_t)(uintptr_t)sem_dependencies;
}
 
+   if (syncobj_request) {
+   if (syncobj_request->number_in_syncobj) {
+   in_syncobj_dependencies = malloc(sizeof(struct 
drm_amdgpu_cs_chunk_sem) * syncobj_request->number_in_syncobj);
+   if (!in_syncobj_dependencies) {
+   r = -ENOMEM;
+   goto error_unlock;
+   }
+   for (j = 0; j < syncobj_request->number_in_syncobj; 
j++) {
+   struct drm_amdgpu_cs_chunk_sem *dep = 
_syncobj_dependencies[j];
+   dep->handle = 

[PATCH] drm/syncobj: add sync obj wait interface. (v6)

[Dave Airlie]

From: Dave Airlie 

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

v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute zero = poll,
rewrite any/all code to have same operation for arrays
return -EINVAL for 0 fences.
v4.1: fixup fences allocation check, use u64_to_user_ptr
v5: move to sec/nsec, and use timespec64 for calcs.
v6: use -ETIME and drop the out status flag. (-ETIME
is suggested by ickle, I can feel a shed painting)

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

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5cecc97..d71b50d 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -157,3 +157,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e5681..385ce74 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 89441bc..2d5a7a1 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
 /*
  * Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -31,6 +33,9 @@
  * that contain an optional fence. The fence can be updated with a new
  * fence, or be NULL.
  *
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
  * syncobj's can be export to fd's and back, these fd's are opaque and
  * have no other use case, except passing the syncobj between processes.
  *
@@ -451,3 +456,140 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
>handle);
 }
+
+/**
+ * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute value
+ *
+ * @timeout_sec: timeout sec component, 0 for poll
+ * @timeout_nsec: timeout nsec component in ns, 0 for poll
+ * both must be 0 for poll.
+ *
+ * Calculate the timeout in jiffies from an absolute time in sec/nsec.
+ */
+static unsigned long drm_timeout_abs_to_jiffies(int64_t timeout_sec, uint64_t 
timeout_nsec)
+{
+   struct timespec64 abs_timeout, timeout, max_jiffy_timespec;
+   unsigned long timeout_jiffies;
+
+   /* make 0 timeout means poll - absolute 0 doesn't seem valid */
+   if (timeout_sec == 0 && timeout_nsec == 0)
+   return 0;
+
+   abs_timeout.tv_sec = timeout_sec;
+   abs_timeout.tv_nsec = timeout_nsec;
+
+   /* clamp timeout if it's to large */
+   if (!timespec64_valid_strict(_timeout))
+   return MAX_SCHEDULE_TIMEOUT - 1;
+
+   timeout = timespec64_sub(abs_timeout, ktime_to_timespec64(ktime_get()));
+   if (!timespec64_valid())
+   return 0;
+
+   jiffies_to_timespec64(MAX_JIFFY_OFFSET, _jiffy_timespec);
+   if (timespec64_compare(, _jiffy_timespec) >= 0)
+   return MAX_SCHEDULE_TIMEOUT - 1;
+
+   timeout_jiffies = timespec64_to_jiffies();
+   /*  clamp timeout to avoid infinite timeout */
+   if (timeout_jiffies >= MAX_SCHEDULE_TIMEOUT)
+   return MAX_SCHEDULE_TIMEOUT - 1;
+
+   return timeout_jiffies + 1;
+}
+
+static int drm_syncobj_wait_fences(struct drm_device *dev,
+  struct drm_file *file_private,
+  struct drm_syncobj_wait *wait,
+  struct dma_fence **fences)
+{
+   unsigned long timeout = drm_timeout_abs_to_jiffies(wait->timeout_sec, 

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Peter Rosin]

On 2017-07-05 08:08, Daniel Vetter wrote:
> On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
>> Hi!
>>
>> While trying to get CLUT support for the atmel_hlcdc driver, and
>> specifically for the emulated fbdev interface, I received some
>> push-back that my feeble in-driver attempts should be solved
>> by the core. This is my attempt to do it right.
>>
>> I have obviously not tested all of this with more than a compile,
>> but patches 1 through 5 are enough to make the atmel-hlcdc driver
>> do what I need. The rest is just lots of removals and cleanup made
>> possible by the improved core.
>>
>> Please test, I would not be surprised if I have fouled up some
>> bit-manipulation somewhere, or if I have misunderstood something
>> about atomics...
>>
>> Changes since v2:
>> - Added patch 1/16 which factors out pseudo-palette handling.
>> - Removed the if (cmap->start + cmap->len < cmap->start)
>>   sanity check on the assumption that the fbdev core handles it.
>> - Added patch 4/16 which factors out atomic state and commit
>>   handling from drm_atomic_helper_legacy_gamma_set to
>>   drm_mode_gamma_set_ioctl.
>> - Do one atomic commit for all affected crtc.
>> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
>>   the last patch).
>> - Cc list is getting long, so I have redused the list for the
>>   individual patches. If you would like to get the full series
>>   (or nothing at all) for the next round (if that is needed) just
>>   say so.
> 
> Is this still on top of my locking rework? I tried to apply patches 1-3,
> but there's minor conflicts ...
> -Daniel

v3 has the same base as v2. I collected your locking rework sometime
after june 21, you have perhaps changed things since? I saw an update
of that dpms patch you Cc me, but figured there were no significant
changes that I needed to handle since I didn't get the full set
this time either. A bad assumption it seems...

Anyway, the base I have for v3 (and v2) is linux next-20170621 plus
the following locking rework commits (in reverse order):

Author: Thierry Reding 
Date: Wed Jun 21 20:28:15 2017 +0200
Subject: drm/hisilicon: Remove custom FB helper deferred setup

Author: Thierry Reding 
Date: Wed Jun 21 20:28:14 2017 +0200
Subject: drm/exynos: Remove custom FB helper deferred setup

Author: Thierry Reding 
Date: Wed Jun 21 20:28:13 2017 +0200
Subject: drm/fb-helper: Support deferred setup

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:12 2017 +0200
Subject: drm/fb-helper: Split dpms handling into legacy and atomic paths

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:11 2017 +0200
Subject: drm/fb-helper: Stop using mode_config.mutex for internals

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:10 2017 +0200
Subject: drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:09 2017 +0200
Subject: drm/fb-helper: Push locking into pan_display_atomic|legacy

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:08 2017 +0200
Subject: drm/fb-helper: Drop locking from the vsync wait ioctl code

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:07 2017 +0200
Subject: drm/fb-helper: Push locking in fb_is_bound

Author: Thierry Reding 
Date: Wed Jun 21 20:28:06 2017 +0200
Subject: drm/fb-helper: Add top-level lock

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:05 2017 +0200
Subject: drm/i915: Drop FBDEV #ifdev in mst code

Author: Thierry Reding 
Date: Wed Jun 21 20:28:04 2017 +0200
Subject: drm/fb-helper: Push down modeset lock into FB helpers

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

Re: [RFC] clk: inherit display clocks enabled by bootloader

[Rajendra Nayak]

On 07/04/2017 11:21 PM, Rob Clark wrote:
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
> 
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and make corresponding fixups
> to clk enable/prepare_count and power-domain state so that these are
> not automatically disabled late in boot.
> 
> If bootloader is enabling display, and kernel is using efifb before
> real display driver is loaded (potentially from kernel module after
> userspace starts, in a typical distro kernel), we don't want to kill
> the clocks and power domains that are used by the display before
> userspace starts.
> 
> Second part will be (*waves hands*) for drm/msm to check if display
> related clocks are enabled when it is loaded, and if so use drm
> atomic framework's hooks to read back hw state to sync existing
> display state w/ software state, and skip the initial clk_enable.
> Therefore inheriting the enable done by bootloader.
> 
> Obviously this should be split up into multiple patches and many
> TODOs addressed.  But I guess this is enough for now to start
> discussing the approach, and in particular how drm and clock/pd
> drivers work together to handle handover from bootloader.
> 
> The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
> on leaf nodes.
> ---
> A bit hacky right now, but display survives clk_disable_unused()
> and genpd_power_off_unused().  It hangs just after that late in
> boot, which I'm still debugging (might be unrelated shenanigans).
> And haven't started on the drm/msm side of this.  But I figured
> it was half baked enough to send out for comments/ideas, or to
> see if anyone had some different idea about how to solve this.

Another RFC proposed around to handle similar situations is
https://lkml.org/lkml/2017/6/28/188

That one though, I guess deals with only regulator supplies for now.

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

[PATCH v3 11/16] drm: i915: remove dead code and pointless local lut storage

[Peter Rosin]

The driver stores lut values from the fbdev interface, and is able
to give them back, but does not appear to do anything with these
lut values. The generic fb helpers have replaced this function,
and may even have made the driver work for the C8 mode from the
fbdev interface. But that is untested.

Since the fb helpers .gamma_set and .gamma_get are obsolete,
remove the dead code.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/i915/intel_drv.h   |  1 -
 drivers/gpu/drm/i915/intel_fbdev.c | 31 ---
 2 files changed, 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d93efb4..bc7bfa0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -786,7 +786,6 @@ struct intel_crtc {
struct drm_crtc base;
enum pipe pipe;
enum plane plane;
-   u8 lut_r[256], lut_g[256], lut_b[256];
/*
 * Whether the crtc and the connected output pipeline is active. Implies
 * that crtc->enabled is set, i.e. the current mode configuration has
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 03347c6..5bac953 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -281,27 +281,6 @@ static int intelfb_create(struct drm_fb_helper *helper,
return ret;
 }
 
-/** Sets the color ramps on behalf of RandR */
-static void intel_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
-   u16 blue, int regno)
-{
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
-   intel_crtc->lut_r[regno] = red >> 8;
-   intel_crtc->lut_g[regno] = green >> 8;
-   intel_crtc->lut_b[regno] = blue >> 8;
-}
-
-static void intel_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 
*green,
-   u16 *blue, int regno)
-{
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
-   *red = intel_crtc->lut_r[regno] << 8;
-   *green = intel_crtc->lut_g[regno] << 8;
-   *blue = intel_crtc->lut_b[regno] << 8;
-}
-
 static struct drm_fb_helper_crtc *
 intel_fb_helper_crtc(struct drm_fb_helper *fb_helper, struct drm_crtc *crtc)
 {
@@ -370,7 +349,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_fb_helper_crtc *new_crtc;
-   struct intel_crtc *intel_crtc;
 
fb_conn = fb_helper->connector_info[i];
connector = fb_conn->connector;
@@ -412,13 +390,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
 
num_connectors_enabled++;
 
-   intel_crtc = to_intel_crtc(connector->state->crtc);
-   for (j = 0; j < 256; j++) {
-   intel_crtc->lut_r[j] = j;
-   intel_crtc->lut_g[j] = j;
-   intel_crtc->lut_b[j] = j;
-   }
-
new_crtc = intel_fb_helper_crtc(fb_helper,
connector->state->crtc);
 
@@ -519,8 +490,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
 
 static const struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.initial_config = intel_fb_initial_config,
-   .gamma_set = intel_crtc_fb_gamma_set,
-   .gamma_get = intel_crtc_fb_gamma_get,
.fb_probe = intelfb_create,
 };
 
-- 
2.1.4

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

[Bug 101596] Blender renders black UI elements

[bugzilla-daemon]

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

--- Comment #10 from Michel Dänzer  ---
Please send the patch to the mesa-dev mailing list for review.

-- 
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 05/16] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Peter Rosin]

On 2017-07-05 08:21, Daniel Vetter wrote:
> On Tue, Jul 04, 2017 at 12:37:01PM +0200, Peter Rosin wrote:
>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
>> completely obsolete.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/drm_fb_helper.c | 165 
>> +++-
>>  1 file changed, 94 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index b75b1f2..7f8199a 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -1257,27 +1257,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
>> drm_fb_helper *fb_helper,
>>  }
>>  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>>  
>> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>> - u16 blue, u16 regno, struct fb_info *info)
>> -{
>> -struct drm_fb_helper *fb_helper = info->par;
>> -struct drm_framebuffer *fb = fb_helper->fb;
>> -
>> -/*
>> - * The driver really shouldn't advertise pseudo/directcolor
>> - * visuals if it can't deal with the palette.
>> - */
>> -if (WARN_ON(!fb_helper->funcs->gamma_set ||
>> -!fb_helper->funcs->gamma_get))
>> -return -EINVAL;
>> -
>> -WARN_ON(fb->format->cpp[0] != 1);
>> -
>> -fb_helper->funcs->gamma_set(crtc, red, green, blue, regno);
>> -
>> -return 0;
>> -}
>> -
>>  static int setcmap_pseudo_palette(struct fb_cmap *cmap, struct fb_info 
>> *info)
>>  {
>>  u32 *palette = (u32 *)info->pseudo_palette;
>> @@ -1310,54 +1289,68 @@ static int setcmap_pseudo_palette(struct fb_cmap 
>> *cmap, struct fb_info *info)
>>  return 0;
>>  }
>>  
>> -/**
>> - * drm_fb_helper_setcmap - implementation for _ops.fb_setcmap
>> - * @cmap: cmap to set
>> - * @info: fbdev registered by the helper
>> - */
>> -int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info)
>> +static int setcmap_legacy(struct fb_cmap *cmap, struct fb_info *info)
>>  {
>>  struct drm_fb_helper *fb_helper = info->par;
>> -struct drm_device *dev = fb_helper->dev;
>> -const struct drm_crtc_helper_funcs *crtc_funcs;
>> -u16 *red, *green, *blue, *transp;
>>  struct drm_crtc *crtc;
>>  u16 *r, *g, *b;
>> -int i, j, rc = 0;
>> -int start;
>> +int i, ret = 0;
>>  
>> -if (oops_in_progress)
>> -return -EBUSY;
>> +for (i = 0; i < fb_helper->crtc_count; i++) {
>> +crtc = fb_helper->crtc_info[i].mode_set.crtc;
>> +if (!crtc->funcs->gamma_set || !crtc->gamma_size)
>> +return -EINVAL;
>>  
>> -mutex_lock(_helper->lock);
>> -if (!drm_fb_helper_is_bound(fb_helper)) {
>> -mutex_unlock(_helper->lock);
>> -return -EBUSY;
>> -}
>> +if (cmap->start + cmap->len > crtc->gamma_size)
>> +return -EINVAL;
>>  
>> -drm_modeset_lock_all(dev);
>> -if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
>> -rc = setcmap_pseudo_palette(cmap, info);
>> -goto out;
>> +r = crtc->gamma_store;
>> +g = r + crtc->gamma_size;
>> +b = g + crtc->gamma_size;
>> +
>> +memcpy(r + cmap->start, cmap->red, cmap->len * sizeof(*r));
>> +memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(*g));
>> +memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(*b));
>> +
>> +ret = crtc->funcs->gamma_set(crtc, r, g, b,
>> + crtc->gamma_size, NULL);
>> +if (ret)
>> +return ret;
>>  }
>>  
>> -for (i = 0; i < fb_helper->crtc_count; i++) {
>> -crtc = fb_helper->crtc_info[i].mode_set.crtc;
>> -crtc_funcs = crtc->helper_private;
>> +return ret;
>> +}
> 
> For the legacy path you need to keep the drm_modeset_lock_all (but only in
> setcmap_legacy). Otherwise this part here looks good.

Oops, didn't intend to zap that one. Thanks for catching!

>>  
>> -red = cmap->red;
>> -green = cmap->green;
>> -blue = cmap->blue;
>> -transp = cmap->transp;
>> -start = cmap->start;
>> +static int setcmap_atomic(struct fb_cmap *cmap, struct fb_info *info)
>> +{
>> +struct drm_fb_helper *fb_helper = info->par;
>> +struct drm_device *dev = fb_helper->dev;
>> +struct drm_modeset_acquire_ctx ctx;
>> +struct drm_crtc_state *crtc_state;
>> +struct drm_atomic_state *state;
>> +struct drm_crtc *crtc;
>> +u16 *r, *g, *b;
>> +int i, ret = 0;
>>  
>> -if (!crtc->gamma_size) {
>> -rc = -EINVAL;
>> +state = drm_atomic_state_alloc(dev);
>> +if (!state)
>> +return -ENOMEM;
>> +drm_modeset_acquire_init(, 0);
>> +retry:
>> +ret = drm_modeset_lock_all_ctx(dev, );
> 
> With atomic you don't need to grab locks, this is done behind 

Re: [PATCH 6/6] drm: Add four ioctls for managing drm mode object leases [v3]

[Dave Airlie]

> +/**
> + * Lease mode resources, creating another drm_master.
> + */
> +struct drm_mode_create_lease {
> +   /** Pointer to array of object ids (__u32) */
> +   __u64 object_ids;
> +   /** Number of object ids */
> +   __u32 object_count;
> +   /** flags for new FD (O_CLOEXEC, etc) */
> +   __u32 flags;
> +
> +   /** Return: unique identifier for lessee. */
> +   __u32 lessee_id;
> +   /** Return: file descriptor to new drm_master file */
> +   __u32 fd;
> +};
> +
> +/**
> + * List lesses from a drm_master
> + */
> +struct drm_mode_list_lessees {
> +   /** Number of lessees.
> +* On input, provides length of the array.
> +* On output, provides total number. No
> +* more than the input number will be written
> +* back, so two calls can be used to get
> +* the size and then the data.
> +*/
> +   __u32 count_lessees;
> +
> +   /** Pointer to lessees.
> +* pointer to __u64 array of lessee ids
> +*/
> +   __u64 lessees_ptr;
> +};

I think this needs a pad ^.

> +
> +/**
> + * Get leased objects
> + */
> +struct drm_mode_get_lease {
> +   /** Number of leased objects.
> +* On input, provides length of the array.
> +* On output, provides total number. No
> +* more than the input number will be written
> +* back, so two calls can be used to get
> +* the size and then the data.
> +*/
> +   __u32 count_objects;
> +
> +   /** Pointer to objects.
> +* pointer to __u32 array of object ids
> +*/
> +   __u64 objects_ptr;

And this.

> +};
> +
> +/**
> + * Revoke lease
> + */
> +struct drm_mode_revoke_lease {
> +   /** Unique ID of lessee
> +*/
> +   __u32 lessee_id;

And this.

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

Re: [Intel-gfx] [PATCH] intel/intel_chipset: Move IS_9XX below IS_GEN10.

[Rodrigo Vivi]

Patch pushed to libdrm master.

On Fri, Jun 30, 2017 at 2:28 PM, Rodrigo Vivi  wrote:
> No functional change. Just organizing the code
> so it gets clear for future platforms.
>
> Paulo deserves credits becuase he was the one
> that just noticed this IS_9XX was in the wrong position
> after CNL patches got introduced.
>
> Cc: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 
> ---
>  intel/intel_chipset.h | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 770d21f..3ff59ad 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -499,15 +499,6 @@
>  IS_GEMINILAKE(devid) || \
>  IS_COFFEELAKE(devid))
>
> -#define IS_9XX(dev)(IS_GEN3(dev) || \
> -IS_GEN4(dev) || \
> -IS_GEN5(dev) || \
> -IS_GEN6(dev) || \
> -IS_GEN7(dev) || \
> -IS_GEN8(dev) || \
> -IS_GEN9(dev) || \
> -IS_GEN10(dev))
> -
>  #define IS_CNL_Y(devid)((devid) == 
> PCI_CHIP_CANNONLAKE_Y_GT2_0 || \
>  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
>  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
> @@ -525,4 +516,13 @@
>
>  #define IS_GEN10(devid)(IS_CANNONLAKE(devid))
>
> +#define IS_9XX(dev)(IS_GEN3(dev) || \
> +IS_GEN4(dev) || \
> +IS_GEN5(dev) || \
> +IS_GEN6(dev) || \
> +IS_GEN7(dev) || \
> +IS_GEN8(dev) || \
> +IS_GEN9(dev) || \
> +IS_GEN10(dev))
> +
>  #endif /* _INTEL_CHIPSET_H */
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/6] drm: Add new LEASE debug level

[Keith Packard]

Separate out lease debugging from the core.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_drv.c | 3 ++-
 include/drm/drmP.h| 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb46a425..b65308a278ca 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -57,7 +57,8 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
 "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
 "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
-"\t\tBit 5 (0x20) will enable VBL messages (vblank code)");
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
+"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)");
 module_param_named(debug, drm_debug, int, 0600);
 
 static DEFINE_SPINLOCK(drm_minor_lock);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 39df16af7a4a..c3b6343557f4 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -145,6 +145,7 @@ struct pci_controller;
 #define DRM_UT_ATOMIC  0x10
 #define DRM_UT_VBL 0x20
 #define DRM_UT_STATE   0x40
+#define DRM_UT_LEASE   0x80
 
 /***/
 /** \name DRM template customization defaults */
@@ -259,6 +260,9 @@ struct pci_controller;
 #define DRM_DEBUG_VBL(fmt, ...)\
drm_printk(KERN_DEBUG, DRM_UT_VBL, fmt, ##__VA_ARGS__)
 
+#define DRM_DEBUG_LEASE(fmt, ...)  \
+   drm_printk(KERN_DEBUG, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+
 #define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, level, fmt, args...)\
 ({ \
static DEFINE_RATELIMIT_STATE(_rs,  \
-- 
2.11.0

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

[PATCH 5/6] drm: Check mode object lease status in all master ioctl paths [v2]

[Keith Packard]

Attempts to modify un-leased objects are rejected with an error.
Information returned about unleased objects is modified to make them
appear unusable and/or disconnected.

Changes for v2 as suggested by Daniel Vetter :

With the change in the __drm_mode_object_find API to pass the
file_priv along, we can now centralize most of the lease-based access
checks in that function.

A few places skip that API and require in-line checks.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_auth.c|  2 +-
 drivers/gpu/drm/drm_connector.c   |  5 +++--
 drivers/gpu/drm/drm_encoder.c |  8 +---
 drivers/gpu/drm/drm_mode_config.c | 32 +++-
 drivers/gpu/drm/drm_mode_object.c | 22 ++
 drivers/gpu/drm/drm_plane.c   |  8 +---
 drivers/gpu/drm/drm_vblank.c  | 18 --
 7 files changed, 71 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 541177c71d51..bab26b477738 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -310,7 +310,7 @@ void drm_master_release(struct drm_file *file_priv)
  */
 bool drm_is_current_master(struct drm_file *fpriv)
 {
-   return fpriv->is_master && fpriv->master == fpriv->minor->dev->master;
+   return fpriv->is_master && drm_lease_owner(fpriv->master) == 
fpriv->minor->dev->master;
 }
 EXPORT_SYMBOL(drm_is_current_master);
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index cd3c106dc5e2..436e99a2d5eb 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1295,7 +1295,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
encoder = drm_connector_get_encoder(connector);
-   if (encoder)
+   if (encoder && drm_lease_held(file_priv, encoder->base.id))
out_resp->encoder_id = encoder->base.id;
else
out_resp->encoder_id = 0;
@@ -1309,7 +1309,8 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
goto out_unref;
 
for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
-   if (connector->encoder_ids[i] != 0)
+   if (connector->encoder_ids[i] != 0 &&
+   drm_lease_held(file_priv, connector->encoder_ids[i]))
encoders_count++;
 
if ((out_resp->count_encoders >= encoders_count) && encoders_count) {
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 43f644844b83..6ad6416f2ede 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -226,7 +226,7 @@ int drm_mode_getencoder(struct drm_device *dev, void *data,
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
crtc = drm_encoder_get_crtc(encoder);
-   if (crtc)
+   if (crtc && drm_lease_held(file_priv, crtc->base.id))
enc_resp->crtc_id = crtc->base.id;
else
enc_resp->crtc_id = 0;
@@ -234,8 +234,10 @@ int drm_mode_getencoder(struct drm_device *dev, void *data,
 
enc_resp->encoder_type = encoder->encoder_type;
enc_resp->encoder_id = encoder->base.id;
-   enc_resp->possible_crtcs = encoder->possible_crtcs;
-   enc_resp->possible_clones = encoder->possible_clones;
+   enc_resp->possible_crtcs = drm_lease_filter_crtcs(file_priv,
+ 
encoder->possible_crtcs);
+   enc_resp->possible_clones = drm_lease_filter_encoders(file_priv,
+ 
encoder->possible_clones);
 
return 0;
 }
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..f7ceee2ae340 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -122,20 +122,24 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
count = 0;
crtc_id = u64_to_user_ptr(card_res->crtc_id_ptr);
drm_for_each_crtc(crtc, dev) {
-   if (count < card_res->count_crtcs &&
-   put_user(crtc->base.id, crtc_id + count))
-   return -EFAULT;
-   count++;
+   if (drm_lease_held(file_priv, crtc->base.id)) {
+   if (count < card_res->count_crtcs &&
+   put_user(crtc->base.id, crtc_id + count))
+   return -EFAULT;
+   count++;
+   }
}
card_res->count_crtcs = count;
 
count = 0;
encoder_id = u64_to_user_ptr(card_res->encoder_id_ptr);
drm_for_each_encoder(encoder, dev) {
-   if (count < card_res->count_encoders &&
-   put_user(encoder->base.id, encoder_id + count))
-   return -EFAULT;
- 

[PATCH 1/6] drm: Pass struct drm_file * to __drm_mode_object_find

[Keith Packard]

This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.

Suggested-by: Daniel Vetter 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c   | 16 
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c |  4 ++--
 drivers/gpu/drm/ast/ast_mode.c   |  2 +-
 drivers/gpu/drm/bochs/bochs_kms.c|  2 +-
 drivers/gpu/drm/cirrus/cirrus_mode.c |  2 +-
 drivers/gpu/drm/drm_atomic.c |  8 
 drivers/gpu/drm/drm_atomic_helper.c  |  2 +-
 drivers/gpu/drm/drm_color_mgmt.c |  4 ++--
 drivers/gpu/drm/drm_connector.c  |  2 +-
 drivers/gpu/drm/drm_crtc.c   |  8 
 drivers/gpu/drm/drm_crtc_internal.h  |  1 +
 drivers/gpu/drm/drm_encoder.c|  2 +-
 drivers/gpu/drm/drm_framebuffer.c|  9 +
 drivers/gpu/drm/drm_mode_object.c| 10 ++
 drivers/gpu/drm/drm_plane.c  | 14 +++---
 drivers/gpu/drm/drm_probe_helper.c   |  2 +-
 drivers/gpu/drm/drm_property.c   |  6 +++---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_overlay.c |  2 +-
 drivers/gpu/drm/i915/intel_sprite.c  |  2 +-
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c  |  4 ++--
 drivers/gpu/drm/radeon/r100.c|  2 +-
 drivers/gpu/drm/radeon/r600_cs.c |  2 +-
 drivers/gpu/drm/radeon/radeon_connectors.c   | 16 
 drivers/gpu/drm/udl/udl_connector.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  2 +-
 include/drm/drm_connector.h  |  3 ++-
 include/drm/drm_crtc.h   |  5 +++--
 include/drm/drm_encoder.h|  3 ++-
 include/drm/drm_framebuffer.h|  1 +
 include/drm/drm_mode_object.h|  2 ++
 include/drm/drm_plane.h  |  3 ++-
 include/drm/drm_property.h   |  3 ++-
 36 files changed, 84 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 8d1cf2d3e663..a6c17353e57d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -231,7 +231,7 @@ amdgpu_connector_update_scratch_regs(struct drm_connector 
*connector,
if (connector->encoder_ids[i] == 0)
break;
 
-   encoder = drm_encoder_find(connector->dev,
+   encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
if (!encoder)
continue;
@@ -256,7 +256,7 @@ amdgpu_connector_find_encoder(struct drm_connector 
*connector,
for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
if (connector->encoder_ids[i] == 0)
break;
-   encoder = drm_encoder_find(connector->dev,
+   encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
if (!encoder)
continue;
@@ -374,7 +374,7 @@ amdgpu_connector_best_single_encoder(struct drm_connector 
*connector)
 
/* pick the encoder ids */
if (enc_id)
-   return drm_encoder_find(connector->dev, enc_id);
+   return drm_encoder_find(connector->dev, NULL, enc_id);
return NULL;
 }
 
@@ -1079,7 +1079,7 @@ amdgpu_connector_dvi_detect(struct drm_connector 
*connector, bool force)
if (connector->encoder_ids[i] == 0)
break;
 
-   encoder = drm_encoder_find(connector->dev, 
connector->encoder_ids[i]);
+   encoder = drm_encoder_find(connector->dev, NULL, 
connector->encoder_ids[i]);
if (!encoder)
continue;
 
@@ -1136,7 +1136,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector 
*connector)
if (connector->encoder_ids[i] == 0)
break;
 
-   encoder = drm_encoder_find(connector->dev, 
connector->encoder_ids[i]);
+   encoder = drm_encoder_find(connector->dev, NULL, 
connector->encoder_ids[i]);
if (!encoder)
continue;
 
@@ -1155,7 +1155,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector 
*connector)
/* then check use digitial */
/* pick the first one */
if (enc_id)
-  

[PATCH 4/6] drm: Add drm_object lease infrastructure [v3]

[Keith Packard]

This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.

An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns' them.

A 'lessee' is a drm_master which is leasing objects from some other
drm_master. Each lessee holds the set of objects which it is leasing
from the lessor.

A 'lessor' is a drm_master which is leasing objects to another
drm_master. This is the same as the owner in the current code.

The set of objects any drm_master 'controls' is limited to the set of
objects it leases (for lessees) or all objects (for owners).

Objects not controlled by a drm_master cannot be modified through the
various state manipulating ioctls, and any state reported back to user
space will be edited to make them appear idle and/or unusable. For
instance, connectors always report 'disconnected', while encoders
report no possible crtcs or clones.

The full list of lessees leasing objects from an owner (either
directly, or indirectly through another lessee), can be searched from
an idr in the drm_master of the owner.

Changes for v2 as suggested by Daniel Vetter :

* Sub-leasing has been disabled.

* BUG_ON for lock checking replaced with lockdep_assert_held

* 'change' ioctl has been removed.

* Leased objects can always be controlled by the lessor; the
  'mask_lease' flag has been removed

* Checking for leased status has been simplified, replacing
  the drm_lease_check function with drm_lease_held.

Changes in v3, some suggested by Dave Airlie 

* Add revocation. This allows leases to be effectively revoked by
  removing all of the objects they have access to. The lease itself
  hangs around as it's hanging off a file.

* Free the leases IDR when the master is destroyed

* _drm_lease_held should look at lessees, not lessor

* Allow non-master files to check for lease status

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_auth.c|  29 +++-
 drivers/gpu/drm/drm_lease.c   | 376 ++
 include/drm/drm_auth.h|  20 +++
 include/drm/drm_lease.h   |  36 
 include/drm/drm_mode_object.h |   1 +
 6 files changed, 462 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_lease.c
 create mode 100644 include/drm/drm_lease.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e1841c..3a47f5ae6f16 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o
+   drm_syncobj.o drm_lease.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 7ff697389d74..541177c71d51 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -31,6 +31,7 @@
 #include 
 #include "drm_internal.h"
 #include "drm_legacy.h"
+#include 
 
 /**
  * DOC: master and authentication
@@ -93,7 +94,7 @@ int drm_authmagic(struct drm_device *dev, void *data,
return file ? 0 : -EINVAL;
 }
 
-static struct drm_master *drm_master_create(struct drm_device *dev)
+struct drm_master *drm_master_create(struct drm_device *dev)
 {
struct drm_master *master;
 
@@ -107,6 +108,14 @@ static struct drm_master *drm_master_create(struct 
drm_device *dev)
idr_init(>magic_map);
master->dev = dev;
 
+   /* initialize the tree of output resource lessees */
+   master->lessor = NULL;
+   master->lessee_id = 0;
+   INIT_LIST_HEAD(>lessees);
+   INIT_LIST_HEAD(>lessee_list);
+   idr_init(>leases);
+   idr_init(>lessee_idr);
+
return master;
 }
 
@@ -189,6 +198,12 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
goto out_unlock;
}
 
+   if (file_priv->master->lessor != NULL) {
+   DRM_DEBUG_LEASE("Attempt to set lessee %d as master\n", 
file_priv->master->lessee_id);
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
ret = drm_set_master(dev, file_priv, false);
 out_unlock:
mutex_unlock(>master_mutex);
@@ -270,6 +285,13 @@ void drm_master_release(struct drm_file *file_priv)
if (dev->master == file_priv->master)
drm_drop_master(dev, file_priv);
 out:
+   if (file_priv->is_master) {
+   /* Revoke any leases held by this or lessees, but only if
+* this is the "real" master
+*/
+   _drm_lease_revoke(master);
+   }
+
/* 

[PATCH 0/6] drm: Add mode object leases [v3]

[Keith Packard]

Here's a third version of my DRM mode object leases series. Since v2:

* Add revocation. This allows leases to be effectively revoked by
  removing all of the objects they have access to. The lease itself
  hangs around as it's hanging off a file.

* Allow non-master files to look at all DRM mode objects. This
  lets the Vulkan code provide information about the display
  environment before the lease is created.

* Free the leases IDR when the master is destroyed. Just a bug fix.

* _drm_lease_held should look at lessees, not lessor. Just a bug fix.

I've also rebased it to a more recent version of Dave's drm-next
branch.

With this and my CRTC-id based vblank series (posted separately), I'm
now running "real" applications on a leased output and can fully
support the following Vulkan extensions:

EXT_direct_mode_display
EXT_acquire_xlib_display
EXT_display_surface_counter
KEITHP_kms_display

-keith

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

[PATCH 2/6] drm: Allow render nodes to query display objects

[Keith Packard]

This allows an application to discover what display resources are
available before requesting a lease from the X server.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_ioctl.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e568176da9..a5a259964c7d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -613,27 +613,27 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
 
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANE, drm_mode_getplane, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANE, drm_mode_getplane, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPLANE, drm_mode_setplane, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl, 
DRM_MASTER|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_noop, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_noop, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY, 
drm_mode_connector_property_set_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
@@ -642,7 +642,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES, 
drm_mode_obj_get_properties_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES, 
drm_mode_obj_get_properties_ioctl, 
DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY, 
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),

[PATCH 6/6] drm: Add four ioctls for managing drm mode object leases [v3]

[Keith Packard]

drm_mode_create_lease

Creates a lease for a list of drm mode objects, returning an
fd for the new drm_master and a 64-bit identifier for the lessee

drm_mode_list_lesees

List the identifiers of the lessees for a master file

drm_mode_get_lease

List the leased objects for a master file

drm_mode_revoke_lease

Erase the set of objects managed by a lease.

This should suffice to at least create and query leases.

Changes for v2 as suggested by Daniel Vetter :

 * query ioctls only query the master associated with
   the provided file.

 * 'mask_lease' value has been removed

 * change ioctl has been removed.

Changes for v3 suggested in part by Dave Airlie 

 * Add revoke ioctl.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_ioctl.c |   4 +
 drivers/gpu/drm/drm_lease.c | 270 
 include/drm/drm_lease.h |  12 ++
 include/uapi/drm/drm.h  |   5 +
 include/uapi/drm/drm_mode.h |  64 +++
 5 files changed, 355 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a5a259964c7d..0a43e82d3f06 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, drm_mode_revoke_lease_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index a8bd4bdd2977..f233d8b488f2 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -23,6 +23,8 @@
 #define drm_for_each_lessee(lessee, lessor) \
list_for_each_entry((lessee), &(lessor)->lessees, lessee_list)
 
+static uint64_t drm_lease_idr_object;
+
 /**
  * drm_lease_owner - return ancestor owner drm_master
  * @master: drm_master somewhere within tree of lessees and lessors
@@ -374,3 +376,271 @@ void _drm_lease_revoke(struct drm_master *top)
}
}
 }
+
+/**
+ * drm_mode_create_lease_ioctl - create a new lease
+ * @dev: the drm device
+ * @data: pointer to struct drm_mode_create_lease
+ * @file_priv: the file being manipulated
+ *
+ * The master associated with the specified file will have a lease
+ * created containing the objects specified in the ioctl structure.
+ * A file descriptor will be allocated for that and returned to the
+ * application.
+ */
+int drm_mode_create_lease_ioctl(struct drm_device *dev,
+   void *data, struct drm_file *lessor_priv)
+{
+   struct drm_mode_create_lease *cl = data;
+   size_t object_count;
+   size_t o;
+   int ret = 0;
+   struct idr leases;
+   struct drm_master *lessor = lessor_priv->master;
+   struct drm_master *lessee = NULL;
+   struct file *lessee_file = NULL;
+   struct file *lessor_file = lessor_priv->filp;
+   struct drm_file *lessee_priv;
+   int fd = -1;
+
+   /* Do not allow sub-leases */
+   if (lessor->lessor)
+   return -EINVAL;
+
+   object_count = cl->object_count;
+   idr_init();
+
+   /* Allocate a file descriptor for the lease */
+   fd = get_unused_fd_flags(cl->flags & (O_CLOEXEC | O_NONBLOCK));
+
+   DRM_DEBUG_LEASE("Creating new lease\n");
+
+   /* Lookup the mode objects and add their IDs to the lease request */
+   for (o = 0; o < object_count; o++) {
+   __u32 object_id;
+
+   if (copy_from_user(_id,
+  u64_to_user_ptr(cl->object_ids) + o * sizeof 
(__u32),
+  sizeof (__u32))) {
+   ret = -EFAULT;
+   goto out_leases;
+   }
+   DRM_DEBUG_LEASE("Adding object %d to lease\n", object_id);
+
+   /* Just need to have something non-NULL here, it doesn't matter 
what */
+   ret = idr_alloc(, _lease_idr_object , object_id, 
object_id + 1, GFP_KERNEL);
+   if (ret < 0) {
+   DRM_DEBUG_LEASE("Object %d cannot be inserted into 
leases (%d)\n",
+   object_id, ret);
+   goto out_leases;
+   }
+   }
+
+   mutex_lock(>master_mutex);
+
+   

[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event

[Keith Packard]

This patch series provides a new interface which fixes three issues
with the current VBLANK_WAIT ioctl:

 1) CRTC indices to select a target.
 2) 32-bits of count resolution.
 3) Microsecond time resolution.

The first makes it quite difficult to use this interface from a leased
DRM device; without the ability to see all of the crtcs for a DRM
device, it's not possible to compute the right index into the array of
them for this interface.

2) and 3) prevent the API from matching the requirements for Vulkan,
which asks for 64-bits of counter and nano-second time resolution.

I've split this series into three pieces, the first two adjust the
internal APIs without exposing new functionality, the third adds the
new IOCTLs.

 [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time

This changes all DRM-level internal interfaces to 64-bit vblank
counters and nano-second time resolution. Changing the driver
interface to 64-bits seems like the right plan, but as no drivers
currently support anything wider than 32-bits, it may be that we don't
want to bother at this point.

 [PATCH 2/3] drm: Reorganize drm_pending_event to support future event

This sticks the vblank event in a union inside of the pending event
structure so that I can add another parallel event in the next
patch. Importantly, this required that I move the assignment of the
event crtc_id field from event deliver to event allocation. That
"shouldn't" matter, but it should also be looked at with some care.

 [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

With the internal APIs ready, this patch is pretty simple.

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

[PATCH 2/3] drm: Reorganize drm_pending_event to support future event types

[Keith Packard]

Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.

Assignments to the crtc_id field are now done when the event is
allocated, rather than when delievered. This way, delivery doesn't
need to have the crtc ID available.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_atomic.c |  7 ---
 drivers/gpu/drm/drm_plane.c  |  2 +-
 drivers/gpu/drm/drm_vblank.c | 27 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  4 ++--
 include/drm/drm_vblank.h |  8 +++-
 6 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0f336d23f9c..f569d7f03f3c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1839,7 +1839,7 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
  */
 
 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, uint64_t user_data)
+   struct drm_device *dev, struct drm_crtc *crtc, uint64_t 
user_data)
 {
struct drm_pending_vblank_event *e = NULL;
 
@@ -1849,7 +1849,8 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
 
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = user_data;
+   e->event.vbl.crtc_id = crtc->base.id;
+   e->event.vbl.user_data = user_data;
 
return e;
 }
@@ -2052,7 +2053,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) {
struct drm_pending_vblank_event *e;
 
-   e = create_vblank_event(dev, arg->user_data);
+   e = create_vblank_event(dev, crtc, arg->user_data);
if (!e)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c4350602..fe9f31285bc2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -918,7 +918,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = page_flip->user_data;
+   e->event.vbl.user_data = page_flip->user_data;
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);
if (ret) {
kfree(e);
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index f55f997c0b8f..9ae170857ef6 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -807,13 +807,18 @@ static void send_vblank_event(struct drm_device *dev,
struct drm_pending_vblank_event *e,
u64 seq, struct timespec *now)
 {
-   e->event.sequence = seq;
-   e->event.tv_sec = now->tv_sec;
-   e->event.tv_usec = now->tv_nsec / 1000;
-
-   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe,
-e->event.sequence);
-
+   switch (e->event.base.type) {
+   case DRM_EVENT_VBLANK:
+   case DRM_EVENT_FLIP_COMPLETE:
+   if (seq)
+   e->event.vbl.sequence = (u32) seq;
+   if (now) {
+   e->event.vbl.tv_sec = now->tv_sec;
+   e->event.vbl.tv_usec = now->tv_nsec / 1000;
+   }
+   break;
+   }
+   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
 }
 
@@ -865,7 +870,6 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
 
e->pipe = pipe;
e->sequence = drm_vblank_count(dev, pipe);
-   e->event.crtc_id = crtc->base.id;
list_add_tail(>base.link, >vblank_event_list);
 }
 EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
@@ -897,7 +901,6 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
now = get_drm_timestamp();
}
e->pipe = pipe;
-   e->event.crtc_id = crtc->base.id;
send_vblank_event(dev, e, seq, );
 }
 EXPORT_SYMBOL(drm_crtc_send_vblank_event);
@@ -1342,6 +1345,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
unsigned int pipe,
  union drm_wait_vblank *vblwait,
  struct drm_file *file_priv)
 {
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
struct drm_vblank_crtc *vblank = >vblank[pipe];
struct drm_pending_vblank_event *e;
struct timespec now;
@@ -1357,8 +1361,9 @@ static int drm_queue_vblank_event(struct drm_device *dev, 

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

[Keith Packard]

These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_internal.h |   6 ++
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_vblank.c   | 148 +
 include/drm/drm_vblank.h   |   1 +
 include/uapi/drm/drm.h |  32 +
 5 files changed, 189 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5cecc974d2f9..b68a193b7907 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -65,6 +65,12 @@ int drm_legacy_irq_control(struct drm_device *dev, void 
*data,
 int drm_legacy_modeset_ctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
+
+int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+
 /* drm_auth.c */
 int drm_getmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e568176da9..63016cf3e224 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, 
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 9ae170857ef6..93004b1bf84c 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -817,6 +817,12 @@ static void send_vblank_event(struct drm_device *dev,
e->event.vbl.tv_usec = now->tv_nsec / 1000;
}
break;
+   case DRM_EVENT_CRTC_SEQUENCE:
+   if (seq)
+   e->event.seq.sequence = seq;
+   if (now)
+   e->event.seq.time_ns = timespec_to_ns(now);
+   break;
}
trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
@@ -1516,6 +1522,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n", 
pipe, ret);
return ret;
}
+
seq = drm_vblank_count(dev, pipe);
 
switch (vblwait->request.type & _DRM_VBLANK_TYPES_MASK) {
@@ -1676,3 +1683,144 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
 }
 EXPORT_SYMBOL(drm_crtc_handle_vblank);
+
+/*
+ * Get crtc VBLANK count.
+ *
+ * \param dev DRM device
+ * \param data user arguement, pointing to a drm_crtc_get_sequence structure.
+ * \param file_priv drm file private for the user's open file descriptor
+ */
+
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_crtc *crtc;
+   int pipe;
+   struct drm_crtc_get_sequence *get_seq = data;
+   struct timespec now;
+
+   if (!dev->irq_enabled)
+   return -EINVAL;
+
+   crtc = drm_crtc_find(dev, get_seq->crtc_id);
+   if (!crtc)
+   return -ENOENT;
+
+   pipe = drm_crtc_index(crtc);
+
+   get_seq->sequence = drm_vblank_count_and_time(dev, pipe, );
+   get_seq->sequence_ns = timespec_to_ns();
+   return 0;
+}
+
+/*
+ * Queue a event for VBLANK sequence
+ *
+ * \param dev DRM device
+ * \param data user arguement, pointing to a drm_crtc_queue_sequence structure.
+ * \param file_priv drm file private for the user's open file descriptor
+ */
+
+int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_crtc *crtc;
+   struct drm_vblank_crtc *vblank;
+   int pipe;
+   struct drm_crtc_queue_sequence *queue_seq = data;
+   struct timespec now;
+   struct drm_pending_vblank_event *e;
+   u32 flags;
+   u64 seq;
+   u64 req_seq;
+   int ret;
+   unsigned long spin_flags;
+
+   if (!dev->irq_enabled)
+   return -EINVAL;
+
+   crtc = drm_crtc_find(dev, queue_seq->crtc_id);
+   if (!crtc)
+   return -ENOENT;
+
+   flags = queue_seq->flags;
+   /* Check valid flag bits */
+ 

[PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

[Keith Packard]

This modifies the datatypes used by the vblank code to provide both 64
bits of vblank count and to increase the resolution of the vblank
timestamp from microseconds to nanoseconds.

The driver interfaces have also been changed to return 64-bits of
vblank count; fortunately all of the code necessary to widen that value
was already included to handle devices returning fewer than 32-bits.

This will provide the necessary datatypes for the Vulkan API.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c  |   2 +-
 drivers/gpu/drm/drm_vblank.c | 159 ++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   2 +-
 drivers/gpu/drm/gma500/psb_drv.h |   2 +-
 drivers/gpu/drm/gma500/psb_irq.c |   2 +-
 drivers/gpu/drm/gma500/psb_irq.h |   2 +-
 drivers/gpu/drm/i915/i915_irq.c  |   4 +-
 drivers/gpu/drm/mga/mga_drv.h|   2 +-
 drivers/gpu/drm/mga/mga_irq.c|   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c  |   2 +-
 drivers/gpu/drm/r128/r128_drv.h  |   2 +-
 drivers/gpu/drm/r128/r128_irq.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_drv.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_kms.c  |   2 +-
 drivers/gpu/drm/tegra/dc.c   |   2 +-
 drivers/gpu/drm/via/via_drv.h|   2 +-
 drivers/gpu/drm/via/via_irq.c|   5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |   2 +-
 include/drm/drmP.h   |   2 +-
 include/drm/drm_crtc.h   |   2 +-
 include/drm/drm_drv.h|   4 +-
 include/drm/drm_vblank.h |  18 ++--
 24 files changed, 130 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e0adad590ecb..860f5e194864 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1979,7 +1979,7 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,
 int amdgpu_suspend(struct amdgpu_device *adev);
 int amdgpu_device_suspend(struct drm_device *dev, bool suspend, bool fbcon);
 int amdgpu_device_resume(struct drm_device *dev, bool resume, bool fbcon);
-u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
+u64 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 12497a40ef92..f8c814c9c91a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -922,7 +922,7 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,
  * Gets the frame count on the requested crtc (all asics).
  * Returns frame count on success, -EINVAL on failure.
  */
-u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe)
+u64 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe)
 {
struct amdgpu_device *adev = dev->dev_private;
int vpos, hpos, stat;
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 463e4d81fb0d..f55f997c0b8f 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -43,7 +43,7 @@
 
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, bool in_vblank_irq);
+ struct timespec *tvblank, bool in_vblank_irq);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -63,8 +63,8 @@ MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on 
timestamps [usecs]");
 MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic timestamps");
 
 static void store_vblank(struct drm_device *dev, unsigned int pipe,
-u32 vblank_count_inc,
-struct timeval *t_vblank, u32 last)
+u64 vblank_count_inc,
+struct timespec *t_vblank, u64 last)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
@@ -82,13 +82,13 @@ static void store_vblank(struct drm_device *dev, unsigned 
int pipe,
  * "No hw counter" fallback implementation of .get_vblank_counter() hook,
  * if there is no useable hardware frame counter available.
  */
-static u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe)
+static u64 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe)
 {
WARN_ON_ONCE(dev->max_vblank_count != 0);
return 0;
 }
 
-static u32 __get_vblank_counter(struct drm_device *dev, unsigned int pipe)
+static u64 __get_vblank_counter(struct drm_device *dev, unsigned int 

RE: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name

[Li, Samuel]

>  - above all, as-is make check will fail  
Right, I did not check that.

>  - keeping the radeon API symmetrical to the amdgpu one would a good idea
The issue is Radeon does not have a struct similar to amdgpu_device_handle. 
I think the current radeon API is simpler. Maybe a follow up change can change 
amdgpu's API similar to radeon.

>  - is adding yet another header really justified?
radeon_asic_id.h? That is going to be used by ddx/mesa.

Sam

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Wednesday, July 05, 2017 7:03 AM
> To: Li, Samuel 
> Cc: amd-gfx mailing list ; ML dri-devel  de...@lists.freedesktop.org>
> Subject: Re: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name
> 
> Hi Samuel,
> 
> On 30 June 2017 at 20:25, Samuel Li  wrote:
> > Change-Id: I24b6624789d1a9dc0fd3a446b0e6f21ed5183ff2
> > Signed-off-by: Samuel Li 
> > ---
> >  radeon/Makefile.am  |   6 +++
> >  radeon/Makefile.sources |   6 ++-
> >  radeon/radeon_asic_id.c | 106
> > 
> >  radeon/radeon_asic_id.h |  37 +
> >  4 files changed, 153 insertions(+), 2 deletions(-)  create mode
> > 100644 radeon/radeon_asic_id.c  create mode 100644
> > radeon/radeon_asic_id.h
> >
> > diff --git a/radeon/Makefile.am b/radeon/Makefile.am index
> > e241531..69407bc 100644
> > --- a/radeon/Makefile.am
> > +++ b/radeon/Makefile.am
> > @@ -30,6 +30,12 @@ AM_CFLAGS = \
> > $(PTHREADSTUBS_CFLAGS) \
> > -I$(top_srcdir)/include/drm
> >
> > +libdrmdatadir = @libdrmdatadir@
> > +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-
> f]+,' \
> > +   $(top_srcdir)/data/amdgpu.ids) AM_CPPFLAGS =
> > +-DRADEON_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\" \
> > +
> > +-
> DRADEON_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIE
> S)
> > +
> Reusing amdgpu.ids by libdrm_radeon is not so obvious. I'm wondering if
> adding a comment in the file [amdgpu.ids] may be a good idea.
> "File is used by $LIST" or "File has multiple users" or anything that
> hints/makes people look up the details.
> 
> Couple of other ideas/suggestions:
>  - above all, as-is make check will fail  
>  - keeping the radeon API symmetrical to the amdgpu one would a good idea
>  - is adding yet another header really justified?
> 
> -Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 1:12 PM, Chris Wilson 
wrote:

> the drm_file parameter is unused, so remove it.
>
> Signed-off-by: Chris Wilson 
> Cc: Dave Airlie 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++
>  drivers/gpu/drm/drm_syncobj.c  | 8 +++-
>  include/drm/drm_syncobj.h  | 3 +--
>  3 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index aeee6840e82b..8c73b91f0ddc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1069,10 +1069,8 @@ static void amdgpu_cs_post_dependencies(struct
> amdgpu_cs_parser *p)
>  {
> int i;
>
> -   for (i = 0; i < p->num_post_dep_syncobjs; ++i) {
> -   drm_syncobj_replace_fence(p->filp,
> p->post_dep_syncobjs[i],
> - p->fence);
> -   }
> +   for (i = 0; i < p->num_post_dep_syncobjs; ++i)
> +   drm_syncobj_replace_fence(p->post_dep_syncobjs[i],
> p->fence);
>  }
>
>  static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 89441bc78591..789ba0b37f7b 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -77,17 +77,15 @@ EXPORT_SYMBOL(drm_syncobj_find);
>
>  /**
>   * drm_syncobj_replace_fence - replace fence in a sync object.
> - * @file_private: drm file private pointer.
>   * @syncobj: Sync object to replace fence in
>   * @fence: fence to install in sync file.
>   *
>   * This replaces the fence on a sync object.
>   */
> -void drm_syncobj_replace_fence(struct drm_file *file_private,
> -  struct drm_syncobj *syncobj,
> +void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
>struct dma_fence *fence)
>  {
> -   struct dma_fence *old_fence = NULL;
> +   struct dma_fence *old_fence;
>

This change looks unrelated.  Valid, but unrelated. :-)

Having worked through your i915 syncobj patch, this definitely makes some
things a little bit nicer.

Reviewed-by: Jason Ekstrand 


>
> if (fence)
> dma_fence_get(fence);
> @@ -292,7 +290,7 @@ int drm_syncobj_import_sync_file_fence(struct
> drm_file *file_private,
> return -ENOENT;
> }
>
> -   drm_syncobj_replace_fence(file_private, syncobj, fence);
> +   drm_syncobj_replace_fence(syncobj, fence);
> dma_fence_put(fence);
> drm_syncobj_put(syncobj);
> return 0;
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 2c3610a4a074..89976da542b1 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -79,8 +79,7 @@ drm_syncobj_put(struct drm_syncobj *obj)
>
>  struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
>  u32 handle);
> -void drm_syncobj_replace_fence(struct drm_file *file_private,
> -  struct drm_syncobj *syncobj,
> +void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
>struct dma_fence *fence);
>  int drm_syncobj_fence_get(struct drm_file *file_private,
>   u32 handle,
> --
> 2.13.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92715] [IGT] [BYT-M/KBL/BSW/BXT/BDW/IVB] gem_reset_stats sub tests fail

[bugzilla-daemon]

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

Armando Antonio  changed:

   What|Removed |Added

Summary|[IGT]   |[IGT]
   |[BYT-M/KBL/BSW/BXT/BDW] |[BYT-M/KBL/BSW/BXT/BDW/IVB]
   |gem_reset_stats sub tests   |gem_reset_stats sub tests
   |fail|fail

-- 
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 92715] [IGT] [BYT-M/KBL/BSW/BXT/BDW] gem_reset_stats sub tests fail

[bugzilla-daemon]

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

--- Comment #27 from Armando Antonio  ---
The following test fail on IVB with latest configuration

Testlist

igt@gem_reset_stats@reset-count-bsd
igt@gem_reset_stats@reset-count-blt


Graphic Stack

Component: drm
tag: libdrm-2.4.81-24-g3095cc8
commit: 3095cc8eaba1aa87ad38c04ae2b1eabe30f7e16c
Component: cairo
tag: 1.15.6-2-g57b4050
commit: 57b40507dda3f58dfc8635548d606b86dc7bcf51
Component: intel-gpu-tools
tag: intel-gpu-tools-1.19-57-g6fcc8e8
commit: 6fcc8e8b247661c7950b998e0b95141ffbd6b833
Component: piglit
tag: piglit-v1
commit: c8f4fd9eeb298a2ef0855927f22634f794ef3eff
==
 Hardware
==
platform   : Ivy Bridge
motherboard model  : Inspiron660
motherboard id : 0XR1GT
form factor: Desktop
manufacturer   : DellInc.
cpu family : Core i5
cpu family id  : 6
cpu information: Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz
gpu card   : Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
memory ram : 7.7 GB
max memory ram : 8 GB
cpu thread : 4
cpu core   : 4
cpu model  : 58
cpu stepping   : 9
socket : Socket BGA1155
signature  : Type 0, Family 6, Model 58, Stepping 9
hard drive : 74GiB (80GB)
current cd clock frequency : 40 kHz
maximum cd clock frequency : 40 kHz
displays connected : VGA-1 HDMI-A-1

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

Re: [PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 2:13 PM, Jason Ekstrand  wrote:

> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf.  It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
> which containe a DRM syncobj and a flags parameter which specifies
> whether to wait on it or to signal it.  This implementation
> theoretically allows for both flags to be set in which case it waits on
> the dma_fence that was in the syncobj and then immediately replaces it
> with the dma_fence from the current execbuf.
>
> v2:
>  - Rebase on new syncobj API
> v3:
>  - Pull everything out into helpers
>  - Do all allocation in gem_execbuffer2
>  - Pack the flags in the bottom 2 bits of the drm_syncobj*
> ---
>  drivers/gpu/drm/i915/i915_drv.c|   3 +-
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 141
> -
>  include/uapi/drm/i915_drm.h|  30 +-
>  3 files changed, 166 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_
> drv.c
> index 9167a73..e6f7f49 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
> case I915_PARAM_HAS_EXEC_FENCE:
> case I915_PARAM_HAS_EXEC_CAPTURE:
> case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> /* For the time being all of these are always true;
>  * if some supported hardware does not have one of these
>  * features this value needs to be provided from
> @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
>  */
> .driver_features =
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME |
> -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_SYNCOBJ,
> .release = i915_driver_release,
> .open = i915_driver_open,
> .lastclose = i915_driver_lastclose,
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 929f275..4f97649 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -33,6 +33,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #include "i915_drv.h"
>  #include "i915_gem_clflush.h"
> @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct
> drm_i915_gem_execbuffer2 *exec)
> return false;
>
> /* Kernel clipping was a DRI1 misfeature */
> -   if (exec->num_cliprects || exec->cliprects_ptr)
> -   return false;
> +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> +   if (exec->num_cliprects || exec->cliprects_ptr)
> +   return false;
> +   }
>
> if (exec->DR4 == 0x) {
> DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> @@ -2114,11 +2117,120 @@ eb_select_engine(struct drm_i915_private
> *dev_priv,
> return engine;
>  }
>
> +static void __free_fence_array(struct drm_syncobj **fences, unsigned int
> n)
> +{
> +   while (n--)
> +   drm_syncobj_put(ptr_mask_bits(fences[n], 2));
> +   kvfree(fences);
> +}
> +
> +static struct drm_syncobj **get_fence_array(struct
> drm_i915_gem_execbuffer2 *args,
> +   struct drm_file *file)
> +{
> +   const unsigned int nfences = args->num_cliprects;
> +   struct drm_i915_gem_exec_fence __user *user;
> +   struct drm_syncobj **fences;
> +   unsigned int n;
> +   int err;
> +
> +   if (!(args->flags & I915_EXEC_FENCE_ARRAY))
> +   return NULL;
> +
> +   if (nfences > SIZE_MAX / sizeof(*fences))
> +   return ERR_PTR(-EINVAL);
> +
> +   user = u64_to_user_ptr(args->cliprects_ptr);
> +   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
> +   return ERR_PTR(-EFAULT);
> +
> +   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
> +   __GFP_NOWARN | GFP_TEMPORARY);
> +   if (!fences)
> +   return ERR_PTR(-ENOMEM);
> +
> +   for (n = 0; n < nfences; n++) {
> +   struct drm_i915_gem_exec_fence fence;
> +   struct drm_syncobj *syncobj;
> +
> +   if (__copy_from_user(, user++, sizeof(fence))) {
> +   err = -EFAULT;
> +   goto err;
> +   }
> +
> +   syncobj = drm_syncobj_find(file, fence.handle);
> +   if (!syncobj) {
> +   DRM_DEBUG("Invalid syncobj handle provided\n");
> +   err = -EINVAL;
> +   goto err;
> +   }
> +
> +   fences[n] = 

[PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

This commit adds support for waiting on or signaling DRM syncobjs as
part of execbuf.  It does so by hijacking the currently unused cliprects
pointer to instead point to an array of i915_gem_exec_fence structs
which containe a DRM syncobj and a flags parameter which specifies
whether to wait on it or to signal it.  This implementation
theoretically allows for both flags to be set in which case it waits on
the dma_fence that was in the syncobj and then immediately replaces it
with the dma_fence from the current execbuf.

v2:
 - Rebase on new syncobj API
v3:
 - Pull everything out into helpers
 - Do all allocation in gem_execbuffer2
 - Pack the flags in the bottom 2 bits of the drm_syncobj*
---
 drivers/gpu/drm/i915/i915_drv.c|   3 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 141 -
 include/uapi/drm/i915_drm.h|  30 +-
 3 files changed, 166 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9167a73..e6f7f49 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_FENCE:
case I915_PARAM_HAS_EXEC_CAPTURE:
case I915_PARAM_HAS_EXEC_BATCH_FIRST:
+   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
@@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
-   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
+   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
.release = i915_driver_release,
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 929f275..4f97649 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -33,6 +33,7 @@
 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 #include "i915_gem_clflush.h"
@@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
return false;
 
/* Kernel clipping was a DRI1 misfeature */
-   if (exec->num_cliprects || exec->cliprects_ptr)
-   return false;
+   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+   if (exec->num_cliprects || exec->cliprects_ptr)
+   return false;
+   }
 
if (exec->DR4 == 0x) {
DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
@@ -2114,11 +2117,120 @@ eb_select_engine(struct drm_i915_private *dev_priv,
return engine;
 }
 
+static void __free_fence_array(struct drm_syncobj **fences, unsigned int n)
+{
+   while (n--)
+   drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+   kvfree(fences);
+}
+
+static struct drm_syncobj **get_fence_array(struct drm_i915_gem_execbuffer2 
*args,
+   struct drm_file *file)
+{
+   const unsigned int nfences = args->num_cliprects;
+   struct drm_i915_gem_exec_fence __user *user;
+   struct drm_syncobj **fences;
+   unsigned int n;
+   int err;
+
+   if (!(args->flags & I915_EXEC_FENCE_ARRAY))
+   return NULL;
+
+   if (nfences > SIZE_MAX / sizeof(*fences))
+   return ERR_PTR(-EINVAL);
+
+   user = u64_to_user_ptr(args->cliprects_ptr);
+   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
+   return ERR_PTR(-EFAULT);
+
+   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
+   __GFP_NOWARN | GFP_TEMPORARY);
+   if (!fences)
+   return ERR_PTR(-ENOMEM);
+
+   for (n = 0; n < nfences; n++) {
+   struct drm_i915_gem_exec_fence fence;
+   struct drm_syncobj *syncobj;
+
+   if (__copy_from_user(, user++, sizeof(fence))) {
+   err = -EFAULT;
+   goto err;
+   }
+
+   syncobj = drm_syncobj_find(file, fence.handle);
+   if (!syncobj) {
+   DRM_DEBUG("Invalid syncobj handle provided\n");
+   err = -EINVAL;
+   goto err;
+   }
+
+   fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+   }
+
+   return fences;
+
+err:
+   __free_fence_array(fences, n);
+   return ERR_PTR(err);
+}
+
+static void put_fence_array(struct drm_i915_gem_execbuffer2 *args,
+   struct drm_syncobj **fences)
+{
+   if (!fences)
+   

[Bug 101656] Invalid signal timestamps with EGL_SYNC_NATIVE_FENCE_ANDROID on android

[bugzilla-daemon]

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

Rafael Antognolli  changed:

   What|Removed |Added

 QA Contact|mesa-dev@lists.freedesktop. |
   |org |
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|EGL |General
Product|Mesa|DRI
Version|17.1|DRI git

--- Comment #1 from Rafael Antognolli  ---
This bug is related to the discussion here:
https://lists.freedesktop.org/archives/intel-gfx/2017-February/119851.html

-- 
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 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #16 from Andy Furniss  ---
Created attachment 132467
  --> https://bugs.freedesktop.org/attachment.cgi?id=132467=edit
xrandr --verbose on 4.14-wip showing all modes

This is xrandr on 4.14-wip - the higher modes are shown, though the clocks
aren't  precise 100/110/120 - it's always been like this, I live in hope that
may get better one day!

I forgot to put earlier WRT 2 monitors, that HDMI-A-0 is physically connected,
but not seen as the TV is off, and as I said, 4.9 DC and all non DC kernels for
ages don't peg memclk high with the same setup.

-- 
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 v3 00/16] improve the fb_setcmap helper

[Daniel Vetter]

On Wed, Jul 05, 2017 at 10:09:21AM +0200, Peter Rosin wrote:
> On 2017-07-05 08:08, Daniel Vetter wrote:
> > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
> >> Hi!
> >>
> >> While trying to get CLUT support for the atmel_hlcdc driver, and
> >> specifically for the emulated fbdev interface, I received some
> >> push-back that my feeble in-driver attempts should be solved
> >> by the core. This is my attempt to do it right.
> >>
> >> I have obviously not tested all of this with more than a compile,
> >> but patches 1 through 5 are enough to make the atmel-hlcdc driver
> >> do what I need. The rest is just lots of removals and cleanup made
> >> possible by the improved core.
> >>
> >> Please test, I would not be surprised if I have fouled up some
> >> bit-manipulation somewhere, or if I have misunderstood something
> >> about atomics...
> >>
> >> Changes since v2:
> >> - Added patch 1/16 which factors out pseudo-palette handling.
> >> - Removed the if (cmap->start + cmap->len < cmap->start)
> >>   sanity check on the assumption that the fbdev core handles it.
> >> - Added patch 4/16 which factors out atomic state and commit
> >>   handling from drm_atomic_helper_legacy_gamma_set to
> >>   drm_mode_gamma_set_ioctl.
> >> - Do one atomic commit for all affected crtc.
> >> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
> >>   the last patch).
> >> - Cc list is getting long, so I have redused the list for the
> >>   individual patches. If you would like to get the full series
> >>   (or nothing at all) for the next round (if that is needed) just
> >>   say so.
> > 
> > Is this still on top of my locking rework? I tried to apply patches 1-3,
> > but there's minor conflicts ...
> > -Daniel
> 
> v3 has the same base as v2. I collected your locking rework sometime
> after june 21, you have perhaps changed things since? I saw an update
> of that dpms patch you Cc me, but figured there were no significant
> changes that I needed to handle since I didn't get the full set
> this time either. A bad assumption it seems...

There's a difference between my own private patches, and the maintainer
repo where stuff gets applied. But that explains why there was a conflict.

I plan to merge my locking changes tomorrow (they're reviewed and ready
now), I'll apply your patches after that. That should take care of the
conflicts.

Thanks, Daniel

> 
> Anyway, the base I have for v3 (and v2) is linux next-20170621 plus
> the following locking rework commits (in reverse order):
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:15 2017 +0200
> Subject: drm/hisilicon: Remove custom FB helper deferred setup
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:14 2017 +0200
> Subject: drm/exynos: Remove custom FB helper deferred setup
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:13 2017 +0200
> Subject: drm/fb-helper: Support deferred setup
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:12 2017 +0200
> Subject: drm/fb-helper: Split dpms handling into legacy and atomic paths
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:11 2017 +0200
> Subject: drm/fb-helper: Stop using mode_config.mutex for internals
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:10 2017 +0200
> Subject: drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:09 2017 +0200
> Subject: drm/fb-helper: Push locking into pan_display_atomic|legacy
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:08 2017 +0200
> Subject: drm/fb-helper: Drop locking from the vsync wait ioctl code
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:07 2017 +0200
> Subject: drm/fb-helper: Push locking in fb_is_bound
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:06 2017 +0200
> Subject: drm/fb-helper: Add top-level lock
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:05 2017 +0200
> Subject: drm/i915: Drop FBDEV #ifdev in mst code
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:04 2017 +0200
> Subject: drm/fb-helper: Push down modeset lock into FB helpers
> 
> Cheers,
> peda
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH] drm: Remove pending_read_domains and pending_write_domain

[Daniel Vetter]

On Wed, Jul 05, 2017 at 04:49:00PM +0100, Chris Wilson wrote:
> The last user of these (i915.ko) no longer does. We can slim down the
> core GEM object by removing the unused 8 bytes.
> 
> Signed-off-by: Chris Wilson 

Time to celebrate!

Applied, thanks.
-Daniel

> ---
>  include/drm/drm_gem.h | 15 ---
>  1 file changed, 15 deletions(-)
> 
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 663d80358057..4a9d231b4294 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -131,21 +131,6 @@ struct drm_gem_object {
>   uint32_t write_domain;
>  
>   /**
> -  * @pending_read_domains:
> -  *
> -  * While validating an exec operation, the
> -  * new read/write domain values are computed here.
> -  * They will be transferred to the above values
> -  * at the point that any cache flushing occurs
> -  */
> - uint32_t pending_read_domains;
> -
> - /**
> -  * @pending_write_domain: Write domain similar to @pending_read_domains.
> -  */
> - uint32_t pending_write_domain;
> -
> - /**
>* @dma_buf:
>*
>* dma-buf associated with this GEM object.
> -- 
> 2.13.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 11/13] drm/i915: Protect against deferred fbdev setup

[Daniel Vetter]

On Wed, Jul 05, 2017 at 12:08:15PM +0200, Maarten Lankhorst wrote:
> Op 04-07-17 om 17:18 schreef Daniel Vetter:
> > We could probably hit this already with our current async fbdev init,
> > but it's much easier to hit this with the new deferred fbdev setup
> > that I'm working on polishing.
> >
> > Cc: Maarten Lankhorst 
> > Reported-by: Maarten Lankhorst 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 580bd4f4a49e..a4224566ebca 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1931,7 +1931,7 @@ static int i915_gem_framebuffer_info(struct seq_file 
> > *m, void *data)
> > return ret;
> >  
> >  #ifdef CONFIG_DRM_FBDEV_EMULATION
> > -   if (dev_priv->fbdev) {
> > +   if (dev_priv->fbdev && dev_priv->fbdev->helper.fb) {
> > fbdev_fb = to_intel_framebuffer(dev_priv->fbdev->helper.fb);
> >  
> > seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier 
> > 0x%llx, refcount %d, obj ",
> 
> Since patch 10/13 makes it way more likely we don't allocate a FB, this patch 
> should be commited before it?

Yeah I think I need to reshuffle, and add the patch to remove the
ifbdev->vma check in output_changed too. I think I'll merge patches 1-9
tomorrow meanwhile.

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

[PATCH] drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

[Chris Wilson]

the drm_file parameter is unused, so remove it.

Signed-off-by: Chris Wilson 
Cc: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++
 drivers/gpu/drm/drm_syncobj.c  | 8 +++-
 include/drm/drm_syncobj.h  | 3 +--
 3 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index aeee6840e82b..8c73b91f0ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1069,10 +1069,8 @@ static void amdgpu_cs_post_dependencies(struct 
amdgpu_cs_parser *p)
 {
int i;
 
-   for (i = 0; i < p->num_post_dep_syncobjs; ++i) {
-   drm_syncobj_replace_fence(p->filp, p->post_dep_syncobjs[i],
- p->fence);
-   }
+   for (i = 0; i < p->num_post_dep_syncobjs; ++i)
+   drm_syncobj_replace_fence(p->post_dep_syncobjs[i], p->fence);
 }
 
 static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 89441bc78591..789ba0b37f7b 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -77,17 +77,15 @@ EXPORT_SYMBOL(drm_syncobj_find);
 
 /**
  * drm_syncobj_replace_fence - replace fence in a sync object.
- * @file_private: drm file private pointer.
  * @syncobj: Sync object to replace fence in
  * @fence: fence to install in sync file.
  *
  * This replaces the fence on a sync object.
  */
-void drm_syncobj_replace_fence(struct drm_file *file_private,
-  struct drm_syncobj *syncobj,
+void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
   struct dma_fence *fence)
 {
-   struct dma_fence *old_fence = NULL;
+   struct dma_fence *old_fence;
 
if (fence)
dma_fence_get(fence);
@@ -292,7 +290,7 @@ int drm_syncobj_import_sync_file_fence(struct drm_file 
*file_private,
return -ENOENT;
}
 
-   drm_syncobj_replace_fence(file_private, syncobj, fence);
+   drm_syncobj_replace_fence(syncobj, fence);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return 0;
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 2c3610a4a074..89976da542b1 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -79,8 +79,7 @@ drm_syncobj_put(struct drm_syncobj *obj)
 
 struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
 u32 handle);
-void drm_syncobj_replace_fence(struct drm_file *file_private,
-  struct drm_syncobj *syncobj,
+void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
   struct dma_fence *fence);
 int drm_syncobj_fence_get(struct drm_file *file_private,
  u32 handle,
-- 
2.13.2

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

[Bug 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #15 from Andy Furniss  ---
It seems the errors in the dmesg are created when I do xrandr --verbose.

-- 
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 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #14 from Andy Furniss  ---
Created attachment 132466
  --> https://bugs.freedesktop.org/attachment.cgi?id=132466=edit
xrandr --verbose higher clocks missing

-- 
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 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #13 from Andy Furniss  ---
Created attachment 132465
  --> https://bugs.freedesktop.org/attachment.cgi?id=132465=edit
dmesg on current staging memclk is stuck high + some errors

-- 
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 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #12 from Andy Furniss  ---
Hmm, so I just booted back into current staging to get a dmesg and xrandr and
ended up noticing 2 more issues.

My monitor is 1920x1080 and can do 120Hz but pref and used by default is 60Hz.

Issue 1 - I can't see 120Hz with xrandr, I normally can - but then I normally
use non DC kernels.

Issue 2 I see a few errors at the end of the dmesg =

[drm] dc_get_validate_context:resource validation failed, dc_status:6

-- 
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 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher  ---
(In reply to Andy Furniss from comment #10)
> Ugh, not 3.7s, I mean amd-staging-4.9s didn't peg memclk high. I don't still
> have all the 4.11s I've ever built so don't know when this started for them.

What sort of display(s) do you have and what modes are you using?  Mclk dpm is
disabled if there are multiple monitors or if the vblank period is too short to
support mclk switching.

-- 
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] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 11:42 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-07-05 19:32:21)
> > On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson 
> wrote:
> >
> > Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > > This commit adds support for waiting on or signaling DRM syncobjs
> as
> > > part of execbuf.  It does so by hijacking the currently unused
> cliprects
> > > pointer to instead point to an array of i915_gem_exec_fence structs
> > > which containe a DRM syncobj and a flags parameter which specifies
> > > whether to wait on it or to signal it.  This implementation
> > > theoretically allows for both flags to be set in which case it
> waits on
> > > the dma_fence that was in the syncobj and then immediately
> replaces it
> > > with the dma_fence from the current execbuf.
> > >
> > > Cc: Chris Wilson 
> > > ---
> > >
> > > Ideally, I'd like to get whatever kernel reviewing and/or merging
> is
> > > required to land the userspace bits ASAP.  That said, I understand
> that
> > > this is my first kernel patch and it's liable to have a few rounds
> of
> > > review before going in.  :-)
> > >
> > > The mesa branch for using this in Vulkan can be found here:
> > >
> > > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/
> anv-syncobj
> > >
> > >  drivers/gpu/drm/i915/i915_drv.c|  3 +-
> > >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97
> > --
> > >  include/uapi/drm/i915_drm.h| 30 -
> > >  3 files changed, 121 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_
> > drv.c
> > > index 9167a73..e6f7f49 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device
> *dev, void
> > *data,
> > > case I915_PARAM_HAS_EXEC_FENCE:
> > > case I915_PARAM_HAS_EXEC_CAPTURE:
> > > case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> > > +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> > > /* For the time being all of these are always true;
> > >  * if some supported hardware does not have one of
> these
> > >  * features this value needs to be provided from
> > > @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
> > >  */
> > > .driver_features =
> > > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> > DRIVER_PRIME |
> > > -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> > > +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> > DRIVER_SYNCOBJ,
> > > .release = i915_driver_release,
> > > .open = i915_driver_open,
> > > .lastclose = i915_driver_lastclose,
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm
> > /i915/i915_gem_execbuffer.c
> > > index 929f275..81b7b7b 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > @@ -33,6 +33,7 @@
> > >
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "i915_drv.h"
> > >  #include "i915_gem_clflush.h"
> > > @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(
> struct
> > drm_i915_gem_execbuffer2 *exec)
> > > return false;
> > >
> > > /* Kernel clipping was a DRI1 misfeature */
> > > -   if (exec->num_cliprects || exec->cliprects_ptr)
> > > -   return false;
> > > +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> > > +   if (exec->num_cliprects || exec->cliprects_ptr)
> > > +   return false;
> > > +   }
> > >
> > > if (exec->DR4 == 0x) {
> > > DRM_DEBUG("UXA submitting garbage DR4, fixing
> up\n");
> > > @@ -2118,12 +2121,15 @@ static int
> > >  i915_gem_do_execbuffer(struct drm_device *dev,
> > >struct drm_file *file,
> > >struct drm_i915_gem_execbuffer2 *args,
> > > -  struct drm_i915_gem_exec_object2 *exec)
> > > +  struct drm_i915_gem_exec_object2 *exec,
> > > +  struct drm_i915_gem_exec_fence *fences)
> > >  {
> > > struct i915_execbuffer eb;
> > > struct dma_fence *in_fence = NULL;
> > > struct sync_file *out_fence = NULL;
> > > +   struct drm_syncobj **syncobjs = NULL;
> > > int out_fence_fd = -1;
> > > +   unsigned int i;
> > > int err;
> >

[Bug 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #10 from Andy Furniss  ---
(In reply to Andy Furniss from comment #9)

> One nit I notice is I may not be comparing like with like as current and
> some older 4.11s I still have around all seem to peg memory clock high. 3.7s

Ugh, not 3.7s, I mean amd-staging-4.9s didn't peg memclk high. I don't still
have all the 4.11s I've ever built so don't know when this started for them.

-- 
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 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #9 from Andy Furniss  ---
Can't reproduce this on current amd-staging-4.11 will keep trying and close
soon if OK.

One nit I notice is I may not be comparing like with like as current and some
older 4.11s I still have around all seem to peg memory clock high. 3.7s I still
have don't do this, neither does non DC current kernel.

I'll search/file a separate bug for this one in coming days, it causes +10
degrees idle GPU temp.

-- 
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] i915: Add support for drm syncobjs

[Chris Wilson]

Quoting Jason Ekstrand (2017-07-05 19:32:21)
> On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson  
> wrote:
> 
> Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf.  It does so by hijacking the currently unused cliprects
> > pointer to instead point to an array of i915_gem_exec_fence structs
> > which containe a DRM syncobj and a flags parameter which specifies
> > whether to wait on it or to signal it.  This implementation
> > theoretically allows for both flags to be set in which case it waits on
> > the dma_fence that was in the syncobj and then immediately replaces it
> > with the dma_fence from the current execbuf.
> >
> > Cc: Chris Wilson 
> > ---
> >
> > Ideally, I'd like to get whatever kernel reviewing and/or merging is
> > required to land the userspace bits ASAP.  That said, I understand that
> > this is my first kernel patch and it's liable to have a few rounds of
> > review before going in.  :-)
> >
> > The mesa branch for using this in Vulkan can be found here:
> >
> > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/anv-syncobj
> >
> >  drivers/gpu/drm/i915/i915_drv.c            |  3 +-
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97
> --
> >  include/uapi/drm/i915_drm.h                | 30 -
> >  3 files changed, 121 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> b/drivers/gpu/drm/i915/i915_
> drv.c
> > index 9167a73..e6f7f49 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, 
> void
> *data,
> >         case I915_PARAM_HAS_EXEC_FENCE:
> >         case I915_PARAM_HAS_EXEC_CAPTURE:
> >         case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> > +       case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> >                 /* For the time being all of these are always true;
> >                  * if some supported hardware does not have one of these
> >                  * features this value needs to be provided from
> > @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
> >          */
> >         .driver_features =
> >             DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME |
> > -           DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> > +           DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_SYNCOBJ,
> >         .release = i915_driver_release,
> >         .open = i915_driver_open,
> >         .lastclose = i915_driver_lastclose,
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm
> /i915/i915_gem_execbuffer.c
> > index 929f275..81b7b7b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -33,6 +33,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_drv.h"
> >  #include "i915_gem_clflush.h"
> > @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct
> drm_i915_gem_execbuffer2 *exec)
> >                 return false;
> >
> >         /* Kernel clipping was a DRI1 misfeature */
> > -       if (exec->num_cliprects || exec->cliprects_ptr)
> > -               return false;
> > +       if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> > +               if (exec->num_cliprects || exec->cliprects_ptr)
> > +                       return false;
> > +       }
> >
> >         if (exec->DR4 == 0x) {
> >                 DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> > @@ -2118,12 +2121,15 @@ static int
> >  i915_gem_do_execbuffer(struct drm_device *dev,
> >                        struct drm_file *file,
> >                        struct drm_i915_gem_execbuffer2 *args,
> > -                      struct drm_i915_gem_exec_object2 *exec)
> > +                      struct drm_i915_gem_exec_object2 *exec,
> > +                      struct drm_i915_gem_exec_fence *fences)
> >  {
> >         struct i915_execbuffer eb;
> >         struct dma_fence *in_fence = NULL;
> >         struct sync_file *out_fence = NULL;
> > +       struct drm_syncobj **syncobjs = NULL;
> >         int out_fence_fd = -1;
> > +       unsigned int i;
> >         int err;
> >
> >         BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
> > @@ -2186,9 +2192,30 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >                 }
> >         }
> >
> > +       if (args->flags & I915_EXEC_FENCE_ARRAY) {
> > +               syncobjs = 

[Bug 101319] Tonga DC + UVD [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #1 from Andy Furniss  ---
Seems to have gone away with current amd-staging-4.11

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

[pull] amdgpu drm-next-4.13

[Alex Deucher]

Hi Dave,

Fixes for 4.13:
- Various fixes for Raven
- Various fixes for Vega10
- Stability fixes for KIQ
- Fix reloading the driver
- Fix S3 on vega10
- Misc other fixes

The following changes since commit 12d016626f99f48edbf5b006625b4e8c0de1eec7:

  Merge tag 'drm-amdkfd-next-2017-06-25' of 
git://people.freedesktop.org/~gabbayo/linux into drm-next (2017-06-28 17:09:27 
+1000)

are available in the git repository at:

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

for you to fetch changes up to 593f546eee2fdbe055380ee82de568c0a1775551:

  drm/amd/powerplay: fix bug fail to remove sysfs when rmmod amdgpu. 
(2017-07-05 13:18:50 -0400)


Alex Deucher (6):
  drm/amd/powerplay/cz: print message if smc message fails
  drm/amdgpu/psp: upper_32_bits/lower_32_bits for address setup
  drm/amdgpu: fix vblank_time when displays are off
  drm/amdgpu/cgs: always set reference clock in mode_info
  drm/amdgpu/gfx8: fix driver reload with KIQ
  drm/amdgpu/gfx9: fix driver reload with KIQ

Alex Xie (2):
  drm/amdgpu/cs: fix a typo in a comment
  drm/amdgpu: Make amdgpu_cs_parser_init static (v2)

Arnd Bergmann (1):
  drm/amdgpu: fix typo in amdgpu_debugfs_test_ib_init

Eric Huang (2):
  drm/amd/powerplay: change PPSMC_MSG_GetCurrPkgPwr for Vega10
  drm/amd/powerplay: power value format change for Vega10

Flora Cui (1):
  drm/amdgpu: Fix the exported always on CU bitmap

Hawking Zhang (4):
  drm/amdgpu: add mmhub pg init sequence on raven
  drm/amdgpu: add interface to enable/disable mmhub pg on raven
  drm/amdgpu: add new flag AMD_PG_SUPPORT_MMHUB
  drm/amdgpu: enable mmhub pg on raven

Huang Rui (1):
  drm/amdgpu: fix the memory corruption on S3

Jim Qu (1):
  drm/amd/amdgpu: move get memory type function from early init to sw init

John Brooks (2):
  drm/ttm: Fix use-after-free in ttm_bo_clean_mm
  drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplay

Michel Dänzer (1):
  amdgpu: Set cik/si_support to 1 by default if radeon isn't built

Nicolai Hähnle (1):
  drm/amdgpu/gfx9: support the amdgpu.disable_cu option

Rex Zhu (3):
  drm/amdgpu: fix vulkan test performance drop and hang on VI
  drm/amd/powerplay: add support for ATOM GFXCLK table v2.
  drm/amd/powerplay: fix bug fail to remove sysfs when rmmod amdgpu.

kbuild test robot (1):
  drm/amdgpu/gfx9: gfx_v9_0_enable_gfx_static_mg_power_gating() can be 
static

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  17 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|  19 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 100 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  81 ++-
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  |  16 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |   9 +
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 218 +
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h|   3 +
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c |  12 +-
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c  |  12 +-
 drivers/gpu/drm/amd/amdgpu/soc15.c |   3 +-
 drivers/gpu/drm/amd/include/amd_shared.h   |   1 +
 drivers/gpu/drm/amd/include/vi_structs.h   | 268 +
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  23 +-
 .../gpu/drm/amd/powerplay/hwmgr/vega10_pptable.h   |   9 +
 .../amd/powerplay/hwmgr/vega10_processpptables.c   |  42 +++-
 drivers/gpu/drm/amd/powerplay/inc/vega10_ppsmc.h   |   4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c   |   2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |   4 +-
 include/uapi/drm/amdgpu_drm.h  |   3 +
 28 files changed, 687 insertions(+), 197 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf.  It does so by hijacking the currently unused cliprects
> > pointer to instead point to an array of i915_gem_exec_fence structs
> > which containe a DRM syncobj and a flags parameter which specifies
> > whether to wait on it or to signal it.  This implementation
> > theoretically allows for both flags to be set in which case it waits on
> > the dma_fence that was in the syncobj and then immediately replaces it
> > with the dma_fence from the current execbuf.
> >
> > Cc: Chris Wilson 
> > ---
> >
> > Ideally, I'd like to get whatever kernel reviewing and/or merging is
> > required to land the userspace bits ASAP.  That said, I understand that
> > this is my first kernel patch and it's liable to have a few rounds of
> > review before going in.  :-)
> >
> > The mesa branch for using this in Vulkan can be found here:
> >
> > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/anv-syncobj
> >
> >  drivers/gpu/drm/i915/i915_drv.c|  3 +-
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97
> --
> >  include/uapi/drm/i915_drm.h| 30 -
> >  3 files changed, 121 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> > index 9167a73..e6f7f49 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev,
> void *data,
> > case I915_PARAM_HAS_EXEC_FENCE:
> > case I915_PARAM_HAS_EXEC_CAPTURE:
> > case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> > +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> > /* For the time being all of these are always true;
> >  * if some supported hardware does not have one of these
> >  * features this value needs to be provided from
> > @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
> >  */
> > .driver_features =
> > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME |
> > -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> > +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_SYNCOBJ,
> > .release = i915_driver_release,
> > .open = i915_driver_open,
> > .lastclose = i915_driver_lastclose,
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 929f275..81b7b7b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -33,6 +33,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_drv.h"
> >  #include "i915_gem_clflush.h"
> > @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct
> drm_i915_gem_execbuffer2 *exec)
> > return false;
> >
> > /* Kernel clipping was a DRI1 misfeature */
> > -   if (exec->num_cliprects || exec->cliprects_ptr)
> > -   return false;
> > +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> > +   if (exec->num_cliprects || exec->cliprects_ptr)
> > +   return false;
> > +   }
> >
> > if (exec->DR4 == 0x) {
> > DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> > @@ -2118,12 +2121,15 @@ static int
> >  i915_gem_do_execbuffer(struct drm_device *dev,
> >struct drm_file *file,
> >struct drm_i915_gem_execbuffer2 *args,
> > -  struct drm_i915_gem_exec_object2 *exec)
> > +  struct drm_i915_gem_exec_object2 *exec,
> > +  struct drm_i915_gem_exec_fence *fences)
> >  {
> > struct i915_execbuffer eb;
> > struct dma_fence *in_fence = NULL;
> > struct sync_file *out_fence = NULL;
> > +   struct drm_syncobj **syncobjs = NULL;
> > int out_fence_fd = -1;
> > +   unsigned int i;
> > int err;
> >
> > BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
> > @@ -2186,9 +2192,30 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > }
> > }
> >
> > +   if (args->flags & I915_EXEC_FENCE_ARRAY) {
> > +   syncobjs = kvmalloc_array(args->num_cliprects,
> > + sizeof(*syncobjs),
> > + __GFP_NOWARN | GFP_TEMPORARY |
> > + __GFP_ZERO);
> > +   if (syncobjs == NULL) {
> > +   DRM_DEBUG("Failed to allocate array of %d
> syncobjs\n",
> > + args->num_cliprects);
> > +   err = -ENOMEM;
> > +

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

[bugzilla-daemon]

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

--- Comment #32 from MirceaKitsune  ---
Thought I'd also post another detail that might be useful, I'm not sure how
much it relates to the freeze but better be safe than sorry; I have the
following two environment variables added to my ~/.profile file, which
basically tell Mesa to post errors to a log file:

export MESA_DEBUG=1
export MESA_LOG_FILE=/home/mircea/.mesa_stderr

There's one reoccurring line which keeps getting printed in there. It's added
periodically with no side effects, but I imagine it could still have some
relation to the trigger of the freeze:

Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture
image)

-- 
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 101596] Blender renders black UI elements

[bugzilla-daemon]

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

--- Comment #9 from Sebastian Parborg  ---
Thanks for fixing it, the patch seems to work nicely for me too.

-- 
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] i915: Add support for drm syncobjs

[Chris Wilson]

Quoting Jason Ekstrand (2017-07-05 18:21:22)
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf.  It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
> which containe a DRM syncobj and a flags parameter which specifies
> whether to wait on it or to signal it.  This implementation
> theoretically allows for both flags to be set in which case it waits on
> the dma_fence that was in the syncobj and then immediately replaces it
> with the dma_fence from the current execbuf.
> 
> Cc: Chris Wilson 
> ---
> 
> Ideally, I'd like to get whatever kernel reviewing and/or merging is
> required to land the userspace bits ASAP.  That said, I understand that
> this is my first kernel patch and it's liable to have a few rounds of
> review before going in.  :-)
> 
> The mesa branch for using this in Vulkan can be found here:
> 
> https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/anv-syncobj
> 
>  drivers/gpu/drm/i915/i915_drv.c|  3 +-
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97 
> --
>  include/uapi/drm/i915_drm.h| 30 -
>  3 files changed, 121 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9167a73..e6f7f49 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
> case I915_PARAM_HAS_EXEC_FENCE:
> case I915_PARAM_HAS_EXEC_CAPTURE:
> case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> /* For the time being all of these are always true;
>  * if some supported hardware does not have one of these
>  * features this value needs to be provided from
> @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
>  */
> .driver_features =
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
> -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
> .release = i915_driver_release,
> .open = i915_driver_open,
> .lastclose = i915_driver_lastclose,
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 929f275..81b7b7b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -33,6 +33,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "i915_drv.h"
>  #include "i915_gem_clflush.h"
> @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct 
> drm_i915_gem_execbuffer2 *exec)
> return false;
>  
> /* Kernel clipping was a DRI1 misfeature */
> -   if (exec->num_cliprects || exec->cliprects_ptr)
> -   return false;
> +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> +   if (exec->num_cliprects || exec->cliprects_ptr)
> +   return false;
> +   }
>  
> if (exec->DR4 == 0x) {
> DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> @@ -2118,12 +2121,15 @@ static int
>  i915_gem_do_execbuffer(struct drm_device *dev,
>struct drm_file *file,
>struct drm_i915_gem_execbuffer2 *args,
> -  struct drm_i915_gem_exec_object2 *exec)
> +  struct drm_i915_gem_exec_object2 *exec,
> +  struct drm_i915_gem_exec_fence *fences)
>  {
> struct i915_execbuffer eb;
> struct dma_fence *in_fence = NULL;
> struct sync_file *out_fence = NULL;
> +   struct drm_syncobj **syncobjs = NULL;
> int out_fence_fd = -1;
> +   unsigned int i;
> int err;
>  
> BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
> @@ -2186,9 +2192,30 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> }
> }
>  
> +   if (args->flags & I915_EXEC_FENCE_ARRAY) {
> +   syncobjs = kvmalloc_array(args->num_cliprects,
> + sizeof(*syncobjs),
> + __GFP_NOWARN | GFP_TEMPORARY |
> + __GFP_ZERO);
> +   if (syncobjs == NULL) {
> +   DRM_DEBUG("Failed to allocate array of %d syncobjs\n",
> + args->num_cliprects);
> +   err = -ENOMEM;
> +   goto err_out_fence;
> +   }
> +   for (i = 0; i < args->num_cliprects; i++) {
> +   syncobjs[i] = drm_syncobj_find(file, 
> fences[i].handle);
> +   if (!syncobjs[i]) {
> +

[Bug 101685] [amdgpu][tahiti xt] dota2 random crash

[bugzilla-daemon]

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

--- Comment #3 from Sylvain BERTRAND  ---
Same mesa binaries from up-to-date "beta" steamos: 17.1.2.

As far as I tested it, I cannot even play one dota2 game without the game
program randomly crashing in dota2 libparticles (radeon or amdgpu).

-- 
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] i915: Add support for drm syncobjs

[Jason Ekstrand]

This commit adds support for waiting on or signaling DRM syncobjs as
part of execbuf.  It does so by hijacking the currently unused cliprects
pointer to instead point to an array of i915_gem_exec_fence structs
which containe a DRM syncobj and a flags parameter which specifies
whether to wait on it or to signal it.  This implementation
theoretically allows for both flags to be set in which case it waits on
the dma_fence that was in the syncobj and then immediately replaces it
with the dma_fence from the current execbuf.

Cc: Chris Wilson 
---

Ideally, I'd like to get whatever kernel reviewing and/or merging is
required to land the userspace bits ASAP.  That said, I understand that
this is my first kernel patch and it's liable to have a few rounds of
review before going in.  :-)

The mesa branch for using this in Vulkan can be found here:

https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/anv-syncobj

 drivers/gpu/drm/i915/i915_drv.c|  3 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97 --
 include/uapi/drm/i915_drm.h| 30 -
 3 files changed, 121 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9167a73..e6f7f49 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_FENCE:
case I915_PARAM_HAS_EXEC_CAPTURE:
case I915_PARAM_HAS_EXEC_BATCH_FIRST:
+   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
@@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
-   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
+   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
.release = i915_driver_release,
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 929f275..81b7b7b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -33,6 +33,7 @@
 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 #include "i915_gem_clflush.h"
@@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
return false;
 
/* Kernel clipping was a DRI1 misfeature */
-   if (exec->num_cliprects || exec->cliprects_ptr)
-   return false;
+   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+   if (exec->num_cliprects || exec->cliprects_ptr)
+   return false;
+   }
 
if (exec->DR4 == 0x) {
DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
@@ -2118,12 +2121,15 @@ static int
 i915_gem_do_execbuffer(struct drm_device *dev,
   struct drm_file *file,
   struct drm_i915_gem_execbuffer2 *args,
-  struct drm_i915_gem_exec_object2 *exec)
+  struct drm_i915_gem_exec_object2 *exec,
+  struct drm_i915_gem_exec_fence *fences)
 {
struct i915_execbuffer eb;
struct dma_fence *in_fence = NULL;
struct sync_file *out_fence = NULL;
+   struct drm_syncobj **syncobjs = NULL;
int out_fence_fd = -1;
+   unsigned int i;
int err;
 
BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
@@ -2186,9 +2192,30 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
}
 
+   if (args->flags & I915_EXEC_FENCE_ARRAY) {
+   syncobjs = kvmalloc_array(args->num_cliprects,
+ sizeof(*syncobjs),
+ __GFP_NOWARN | GFP_TEMPORARY |
+ __GFP_ZERO);
+   if (syncobjs == NULL) {
+   DRM_DEBUG("Failed to allocate array of %d syncobjs\n",
+ args->num_cliprects);
+   err = -ENOMEM;
+   goto err_out_fence;
+   }
+   for (i = 0; i < args->num_cliprects; i++) {
+   syncobjs[i] = drm_syncobj_find(file, fences[i].handle);
+   if (!syncobjs[i]) {
+   DRM_DEBUG("Invalid syncobj handle provided\n");
+   err = -EINVAL;
+   goto err_syncobjs;
+   }
+   }
+   }
+
err = eb_create();
if (err)
-   goto 

[Bug 101596] Blender renders black UI elements

[bugzilla-daemon]

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

Matias N. Goldberg  changed:

   What|Removed |Added

 CC||dark_syl...@yahoo.com.ar

--- Comment #8 from Matias N. Goldberg  ---
Created attachment 132462
  --> https://bugs.freedesktop.org/attachment.cgi?id=132462=edit
Patch to fix bug

This patch fixes the problem by correctly handling glDrawPixel & glBitmap
variations (both the cases where glDrawPixel was called before or after the
standard variation has been generated), and fixes Blender.

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

[PATCH] drm: Remove pending_read_domains and pending_write_domain

[Chris Wilson]

The last user of these (i915.ko) no longer does. We can slim down the
core GEM object by removing the unused 8 bytes.

Signed-off-by: Chris Wilson 
---
 include/drm/drm_gem.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 663d80358057..4a9d231b4294 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -131,21 +131,6 @@ struct drm_gem_object {
uint32_t write_domain;
 
/**
-* @pending_read_domains:
-*
-* While validating an exec operation, the
-* new read/write domain values are computed here.
-* They will be transferred to the above values
-* at the point that any cache flushing occurs
-*/
-   uint32_t pending_read_domains;
-
-   /**
-* @pending_write_domain: Write domain similar to @pending_read_domains.
-*/
-   uint32_t pending_write_domain;
-
-   /**
 * @dma_buf:
 *
 * dma-buf associated with this GEM object.
-- 
2.13.2

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

[Bug 101685] [amdgpu][tahiti xt] dota2 random crash

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Is this a regression?  If so, did you also change the mesa version you are
using?

-- 
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 101685] [amdgpu][tahiti xt] dota2 random crash

[bugzilla-daemon]

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

--- Comment #1 from Sylvain BERTRAND  ---
I was wrong, it's worse: linux 4.12 amdgpu and radeon do random crash dota2 the
same way (in libparticles). Both 4.12 modules are _significantly_ faster than
the stable 4.11 radeon while not crashing.

-- 
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 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

[bugzilla-daemon]

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

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

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Olaf H B from comment #0)
> 
> [8.642870] amdgpu: [powerplay] Can't find requested voltage id in
> vdd_dep_on_sclk table!

This is harmless.

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

[Bug 101695] mesa fails to compile illegal conversion of »int« in »radeon_bo_domain«

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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 101695] mesa fails to compile illegal conversion of »int« in »radeon_bo_domain«

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

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

--- Comment #2 from Gregor Münch  ---
Lets close the issue then.

-- 
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 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

[bugzilla-daemon]

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

--- Comment #31 from MirceaKitsune  ---
Created attachment 132448
  --> https://bugs.freedesktop.org/attachment.cgi?id=132448=edit
Screenshot of "top"

Lots of important new information on this freeze, which was of course ported to
the latest openSUSE Tumbleweed system packages and still works:

First and foremost, the problem does not happen in every session, and this is
not always influenced by updates! During an interval in which I installed
absolutely no relevant package changes, the following has happened: The freeze
occurred after about just 8 hours of uptime... after that I restarted the
machine, but then I had 4 days of uptime with no freeze! This leads me to
believe that certain applications or system actions prepare the system with a
"time bomb", which then causes switching between windows or desktops to produce
the freeze... however I have no way to know what mines the system and what
doesn't yet, as I use too many applications at once to figure out which might
be responsible.

Anyway another crash happened today. Once more I quickly hit Control + Alt + F1
to switch to a different runlevel; This caused the image to become corrupted on
the monitor, however the system remained responsive and didn't actually freeze.
So I went to my mother's computer and logged in via SSH, which indeed still
worked. I was able to issue a reboot command, which caused the image to briefly
unfreeze as the monitor turned on and off a few more times... I could see a few
KDE error messages about applications crashing, before the system actually went
ahead and rebooted successfully! However this is only possible if I switch to a
console quickly enough when noticing the freeze start to happen, if not the
whole machine freezes and not even SSH responds from other devices!

While I was in SSH, I decided to run "top" and take a screenshot of my
processes (while the computer was frozen and with corrupt image stuck on the
screen). I can't tell if anything is out of the ordinary such as a memory leak,
but I'm attaching a screenshot of it here.

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

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

[Ville Syrjälä]

On Wed, Jul 05, 2017 at 11:46:14AM +0300, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Tuesday 04 Jul 2017 15:44:02 Ville Syrjälä wrote:
> > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
> > > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> > >> From: Ville Syrjälä 
> > >> 
> > >> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> > >> 3D to 2D mode in a timely fashion if the source simply stops sending the
> > >> HDMI infoframe. The suggested workaround is to keep sending the
> > >> infoframe even when strictly not necessary (ie. no VIC and no S3D).
> > >> HDMI 1.4 does allow for this behaviour, stating that sending the
> > >> infoframe is optional in this case.
> > > 
> > > My impression from the specs is that it should be done only after
> > > switching from 3d to 2d mode.
> > > In such case we just need to remember previous mode, if it was 3d, empty
> > > VSIF infoframe should be still generated for 2seconds.
> > > No need to do guesses from EDID.
> > > Am I right, or just missing something?
> > 
> > This code has no idea about any 3D->2D transitions, trying to make it
> > do that would just result in a lot of complexity. Much easier to just
> > always send the infoframe.
> > 
> > >> The infoframe was first specified in HDMI 1.4, so in theory sinks
> > >> predating that may not appreciate us sending an uknown infoframe
> > >> their way. To avoid regressions let's try to determine if the sink
> > >> supports the infoframe or not. Unfortunately there's no direct way
> > >> to do that, so instead we'll just check if we managed to parse any
> > >> HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
> > >> sink will accept the infoframe. Also if the EDID contains the HDMI
> > >> 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
> > >> the infoframe.
> > >> Cc: Archit Taneja 
> > >> Cc: Andrzej Hajda 
> > >> Cc: Laurent Pinchart 
> > >> Cc: Inki Dae 
> > >> Cc: Joonyoung Shim 
> > >> Cc: Seung-Woo Kim 
> > >> Cc: Kyungmin Park 
> > >> Cc: CK Hu 
> > >> Cc: Philipp Zabel 
> > >> Cc: Ben Skeggs 
> > >> Cc: Mark Yao 
> > >> Cc: Benjamin Gaignard 
> > >> Cc: Vincent Abriou 
> > >> Cc: Shawn Guo 
> > >> Cc: Shashank Sharma 
> > >> Signed-off-by: Ville Syrjälä 
> > >> ---
> > >> 
> > >>  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
> > >>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
> > >>  drivers/gpu/drm/drm_edid.c| 32 ++--
> > >>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> > >>  drivers/gpu/drm/i915/intel_hdmi.c | 14 --
> > >>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
> > >>  drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
> > >>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
> > >>  drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
> > >>  drivers/gpu/drm/zte/zx_hdmi.c |  1 +
> > >>  include/drm/drm_connector.h   |  5 +
> > >>  include/drm/drm_edid.h|  1 +
> > >>  12 files changed, 55 insertions(+), 18 deletions(-)
> 
> [snip]
> 
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 2e55599816aa..c061dd5d25c0 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> 
> [snip]
> 
> > >> @@ -4452,6 +4458,7 @@ s3d_structure_from_display_mode(const struct
> > >> drm_display_mode *mode)> > 
> > >>   * drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI
> > >>   infoframe with
> > >>   * data from a DRM display mode
> > >>   * @frame: HDMI vendor infoframe
> > >> + * @connector: the connector
> > >>   * @mode: DRM display mode
> > >>   *
> > >>   * Note that there's is a need to send HDMI vendor infoframes only when
> > >>   using a
> > >> @@ -4462,8 +4469,15 @@ s3d_structure_from_display_mode(const struct
> > >> drm_display_mode *mode)
> > >>   */
> > >>  
> > >>  int
> > >>  drm_hdmi_vendor_infoframe_from_display_mode(struct
> > >>  hdmi_vendor_infoframe *frame,
> > >> +struct drm_connector 
> > >> *connector,
> > >>  const struct 
> > >> drm_display_mode
> > >>  *mode)
> > >>  {
> > >> +/*
> > >> + * FIXME: sil-sii8620 doesn't have a connector around when
> > >> + * we need one, so we have to be prepared for a NULL connector.
> > >> + */
> > >> +bool has_hdmi_infoframe = connector ?
> > >> +

Re: [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

[Ville Syrjälä]

On Wed, Jul 05, 2017 at 03:49:51PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/5/2017 3:46 PM, Ville Syrjälä wrote:
> > On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/4/2017 9:26 PM, Ville Syrjälä wrote:
> >>> On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote:
>  YCBCR420 modes are supported only on HDMI 2.0 capable sources.
>  This patch adds a drm helper to validate YCBCR420-only mode
>  on a particular connector. This function will help pruning
>  the YCBCR420-only modes from the connector's modelist.
> 
>  V5: Introduced the patch in series.
> 
>  Cc: Ville Syrjala 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/drm_edid.c |  3 ++-
> drivers/gpu/drm/drm_modes.c| 28 
> drivers/gpu/drm/drm_probe_helper.c |  4 
> include/drm/drm_edid.h |  1 +
> include/drm/drm_modes.h|  5 +
> 5 files changed, 40 insertions(+), 1 deletion(-)
> 
>  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>  index b879662..ad26c5e 100644
>  --- a/drivers/gpu/drm/drm_edid.c
>  +++ b/drivers/gpu/drm/drm_edid.c
>  @@ -2947,10 +2947,11 @@ u8 drm_match_cea_mode(const struct 
>  drm_display_mode *to_match)
> }
> EXPORT_SYMBOL(drm_match_cea_mode);
> 
>  -static bool drm_valid_cea_vic(u8 vic)
>  +bool drm_valid_cea_vic(u8 vic)
> {
>   return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
> }
>  +EXPORT_SYMBOL(drm_valid_cea_vic);
> 
> /**
>  * drm_get_cea_aspect_ratio - get the picture aspect ratio 
>  corresponding to
>  diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>  index f2493b9..3b53c8e3 100644
>  --- a/drivers/gpu/drm/drm_modes.c
>  +++ b/drivers/gpu/drm/drm_modes.c
>  @@ -1083,6 +1083,34 @@ drm_mode_validate_size(const struct 
>  drm_display_mode *mode,
> }
> EXPORT_SYMBOL(drm_mode_validate_size);
> 
>  +/**
>  + * drm_mode_ycbcr420_only - add 'ycbcr420-only' modes only when allowed
>  + * @mode: mode to check
>  + * @connector: drm connector under action
>  + *
>  + * This function is a helper which can be used to filter out any 
>  YCBCR420
>  + * only mode, when the source doesn't support it.
>  + *
>  + * Returns:
>  + * The mode status
>  + */
>  +enum drm_mode_status
>  +drm_mode_validate_ycbcr420(const struct drm_display_mode *mode,
>  +   struct drm_connector *connector)
>  +{
>  +u8 vic = drm_match_cea_mode(mode);
>  +enum drm_mode_status status = MODE_OK;
>  +struct drm_hdmi_info *hdmi = >display_info.hdmi;
>  +
>  +if (drm_valid_cea_vic(vic) && test_bit(vic, 
>  hdmi->y420_vdb_modes)) {
> >>> The drm_valid_cea_vic() check seems redundant to me.
> >>> Why do you think we need it?
> >> drm_match_cea_mode() returns 0 in case if a vic is not found. if we take
> >> that to test_bit() it will check bit 0
> >> and give wrong results.
> > Why would bit 0 be set? That would sound like a bug in the mode parsing.
> I know, and it wont be, but do we want to take the wrong VIC as input in 
> first place ? Many detailed modes, and non-cea modes
> will return 0 for VIC,

All non-cea modes will return 0.

> why should we bother checking them in map at the 
> first place ?

Checking the vic against some range is pointless work. Just
checking the bit blindly is the most optimal way.

> 
> - Shashank
> >> So first we have to check valid vic, this is
> >> also an additional check for YCBCR420 mode
> >> as they must have a valid vic
> >>> Also I don't think this will compile since we don't have
> >>> y420_vdb_modes[] yet.
> >> Ah, now I recall the reason I wanted to give you, when you asked me to
> >> move this patch, before we add ycbcr420 modes.
> >> So now this has to go after patch 5 right ? I would re-sequence
> >> accordingly.
> >>
> >> - Shashank
>  +if (!connector->ycbcr_420_allowed)
>  +status = MODE_NO_420;
>  +}
>  +
>  +return status;
>  +}
>  +EXPORT_SYMBOL(drm_mode_validate_ycbcr420);
>  +
> #define MODE_STATUS(status) [MODE_ ## status + 3] = #status
> 
> static const char * const drm_mode_status_names[] = {
>  diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>  b/drivers/gpu/drm/drm_probe_helper.c
>  index 00e6832..904966c 100644
>  --- a/drivers/gpu/drm/drm_probe_helper.c
>  +++ b/drivers/gpu/drm/drm_probe_helper.c
>  @@ -528,6 +528,10 @@ int drm_helper_probe_single_connector_modes(struct 
>  

Re: [PATCH 10/13] drm/fb-helper: Support deferred setup

[Maarten Lankhorst]

Op 04-07-17 om 17:18 schreef Daniel Vetter:
> FB helper code falls back to a 1024x768 mode if no outputs are connected
> or don't report back any modes upon initialization. This can be annoying
> because outputs that are added to FB helper later on can't be used with
> FB helper if they don't support a matching mode.
>
> The fallback is in place because VGA connectors can happen to report an
> unknown connection status even when they are in fact connected.
>
> Some drivers have custom solutions in place to defer FB helper setup
> until at least one output is connected. But the logic behind these
> solutions is always the same and there is nothing driver-specific about
> it, so a better alterative is to fix the FB helper core and add support
> for all drivers automatically.
>
> This patch adds support for deferred FB helper setup. It checks all the
> connectors for their connection status, and if all of them report to be
> disconnected marks the FB helper as needing deferred setup. Whet setup
> is deferred, the FB helper core will automatically retry setup after a
> hotplug event, and it will keep trying until it succeeds.
>
> v2: Rebase onto my entirely reworked fbdev helper locking. One big
> difference is that this version again drops the fbdev lock
> (which is now fb_helper->lock, but before this patch series it was
> mode_config->mutex), because register_framebuffer must be able to
> recurse back into fbdev helper code for the initial screen setup.
>
> v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
> return, I've fumbled that in the deferred setup case (Liviu).
>
> v4: I was blind, redo this all. __drm_fb_helper_initial_config
> shouldn't need to reacquire fb_helper->lock, that just confuses
> callers. I myself got confused by kernel_fb_helper_lock and somehow
> thought it's the same as fb_helper->lock. Tsk.
>
> Also simplify the logic a bit (we don't need two functions to probe
> connectors), we can stick much closer to the existing code. And update
> some comments I've spotted that are outdated.
>
> v5: Don't pass -EAGAIN to drivers, it's just an internal error code
> (Liviu).
>
> v6: Add _and_unlock suffix to clarify locking (Maarten)
If you remove intel_fbdev_output_poll_changed's null check for ifbdev->fb,
and apply 11 before this one, then for the first 11 patches:

Reviewed-by: Maarten Lankhorst 

It should probably be noted in this commit that this change results in no 
longer registering the intel fb if no output is connected,
in which case dummy fb is always used.

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

[Bug 101695] mesa fails to compile illegal conversion of »int« in »radeon_bo_domain«

[bugzilla-daemon]

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

--- Comment #1 from Christoph Haag  ---
https://cgit.freedesktop.org/mesa/mesa/commit/?id=156832ee2b22118f29ca93bf1b4cb4de3b329f3e
works for me.

-- 
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 12/14] drm/exynos: mic: clean up drm_bridge_add call

[Emil Velikov]

On 5 July 2017 at 10:14, Archit Taneja  wrote:
>
>
> On 07/05/2017 02:35 PM, Inki Dae wrote:
>>
>>
>>
>> 2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글:
>>>
>>>
>>>
>>> On 07/03/2017 02:12 PM, Inki Dae wrote:

 This patch removes unnecessary checking of return value.

 Ps. this patch depends on below one,
  http://www.spinics.net/lists/dri-devel/msg145687.html
>>>
>>>
>>> Will this one^ go via the exynos pull req or drm-misc? If there won't
>>> be any conflicts, we could get both the patches through drm-misc to
>>> keep things simple.
>>
>>
>> exynos pull it would be better. I will pick this up. :)
>
>
> If patch # 1/14 goes through drm-misc, and the exynos patch goes through
> exynos pull, the drm-misc branch would break. That's the reason I
> preferred the exynos patches to go via misc.
>
As mentioned in 1/14:

If 1/14 is applied before the rest of the series all the drivers
(addressed with 2-14) will fail to build.
I think...

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

Re: [PATCH libdrm] amdgpu: move asic id table to a separate file

[Emil Velikov]

On 5 July 2017 at 11:44, Chih-Wei Huang  wrote:
> 2017-07-05 17:35 GMT+08:00 Emil Velikov :
>> On 4 July 2017 at 07:40, Chih-Wei Huang  wrote:
>>>
>>> Unfortunately this patch breaks Android build
>>> since the two macros are not defined.
>>>
>>> Anyone is working on a fix?
>>> If not, I'll try to provide one.
>>>
>> Please send a patch. I doubt many of the AMD devs have an Android setup.
>> Do ensure that the amdgpu.ids file is installed and accessible.
>
> Yep. The first problem to prepare the patch is,
> where to install amdgpu.ids on Android?
> Is /system/etc/amdgpu.ids OK?
>
Personally I'd stick it alongside the pci.ids/usb.ids, but it's up-to
you really.
The library does not care about the filename/path - it's passed as a define.

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

Re: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name

[Emil Velikov]

Hi Samuel,

On 30 June 2017 at 20:25, Samuel Li  wrote:
> Change-Id: I24b6624789d1a9dc0fd3a446b0e6f21ed5183ff2
> Signed-off-by: Samuel Li 
> ---
>  radeon/Makefile.am  |   6 +++
>  radeon/Makefile.sources |   6 ++-
>  radeon/radeon_asic_id.c | 106 
> 
>  radeon/radeon_asic_id.h |  37 +
>  4 files changed, 153 insertions(+), 2 deletions(-)
>  create mode 100644 radeon/radeon_asic_id.c
>  create mode 100644 radeon/radeon_asic_id.h
>
> diff --git a/radeon/Makefile.am b/radeon/Makefile.am
> index e241531..69407bc 100644
> --- a/radeon/Makefile.am
> +++ b/radeon/Makefile.am
> @@ -30,6 +30,12 @@ AM_CFLAGS = \
> $(PTHREADSTUBS_CFLAGS) \
> -I$(top_srcdir)/include/drm
>
> +libdrmdatadir = @libdrmdatadir@
> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
> +   $(top_srcdir)/data/amdgpu.ids)
> +AM_CPPFLAGS = -DRADEON_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\" \
> +   -DRADEON_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)
> +
Reusing amdgpu.ids by libdrm_radeon is not so obvious. I'm wondering
if adding a comment in the file [amdgpu.ids] may be a good idea.
"File is used by $LIST" or "File has multiple users" or anything that
hints/makes people look up the details.

Couple of other ideas/suggestions:
 - above all, as-is make check will fail
 - keeping the radeon API symmetrical to the amdgpu one would a good idea
 - is adding yet another header really justified?

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

Re: [PATCH libdrm] amdgpu: move asic id table to a separate file

[Chih-Wei Huang]

2017-07-05 17:35 GMT+08:00 Emil Velikov :
> On 4 July 2017 at 07:40, Chih-Wei Huang  wrote:
>>
>> Unfortunately this patch breaks Android build
>> since the two macros are not defined.
>>
>> Anyone is working on a fix?
>> If not, I'll try to provide one.
>>
> Please send a patch. I doubt many of the AMD devs have an Android setup.
> Do ensure that the amdgpu.ids file is installed and accessible.

Yep. The first problem to prepare the patch is,
where to install amdgpu.ids on Android?
Is /system/etc/amdgpu.ids OK?

> JFYI: a similar work is coming on the radeon side, so keep an eye open.




-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

[Sharma, Shashank]

Regards

Shashank


On 7/5/2017 3:46 PM, Ville Syrjälä wrote:

On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/4/2017 9:26 PM, Ville Syrjälä wrote:

On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote:

YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds a drm helper to validate YCBCR420-only mode
on a particular connector. This function will help pruning
the YCBCR420-only modes from the connector's modelist.

V5: Introduced the patch in series.

Cc: Ville Syrjala 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c |  3 ++-
   drivers/gpu/drm/drm_modes.c| 28 
   drivers/gpu/drm/drm_probe_helper.c |  4 
   include/drm/drm_edid.h |  1 +
   include/drm/drm_modes.h|  5 +
   5 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b879662..ad26c5e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2947,10 +2947,11 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
   }
   EXPORT_SYMBOL(drm_match_cea_mode);
   
-static bool drm_valid_cea_vic(u8 vic)

+bool drm_valid_cea_vic(u8 vic)
   {
return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
   }
+EXPORT_SYMBOL(drm_valid_cea_vic);
   
   /**

* drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..3b53c8e3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1083,6 +1083,34 @@ drm_mode_validate_size(const struct drm_display_mode 
*mode,
   }
   EXPORT_SYMBOL(drm_mode_validate_size);
   
+/**

+ * drm_mode_ycbcr420_only - add 'ycbcr420-only' modes only when allowed
+ * @mode: mode to check
+ * @connector: drm connector under action
+ *
+ * This function is a helper which can be used to filter out any YCBCR420
+ * only mode, when the source doesn't support it.
+ *
+ * Returns:
+ * The mode status
+ */
+enum drm_mode_status
+drm_mode_validate_ycbcr420(const struct drm_display_mode *mode,
+  struct drm_connector *connector)
+{
+   u8 vic = drm_match_cea_mode(mode);
+   enum drm_mode_status status = MODE_OK;
+   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+   if (drm_valid_cea_vic(vic) && test_bit(vic, hdmi->y420_vdb_modes)) {

The drm_valid_cea_vic() check seems redundant to me.
Why do you think we need it?

drm_match_cea_mode() returns 0 in case if a vic is not found. if we take
that to test_bit() it will check bit 0
and give wrong results.

Why would bit 0 be set? That would sound like a bug in the mode parsing.
I know, and it wont be, but do we want to take the wrong VIC as input in 
first place ? Many detailed modes, and non-cea modes
will return 0 for VIC, why should we bother checking them in map at the 
first place ?


- Shashank

So first we have to check valid vic, this is
also an additional check for YCBCR420 mode
as they must have a valid vic

Also I don't think this will compile since we don't have
y420_vdb_modes[] yet.

Ah, now I recall the reason I wanted to give you, when you asked me to
move this patch, before we add ycbcr420 modes.
So now this has to go after patch 5 right ? I would re-sequence
accordingly.

- Shashank

+   if (!connector->ycbcr_420_allowed)
+   status = MODE_NO_420;
+   }
+
+   return status;
+}
+EXPORT_SYMBOL(drm_mode_validate_ycbcr420);
+
   #define MODE_STATUS(status) [MODE_ ## status + 3] = #status
   
   static const char * const drm_mode_status_names[] = {

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 00e6832..904966c 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -528,6 +528,10 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_pipeline(mode,
  connector);
+
+   if (mode->status == MODE_OK)
+   mode->status = drm_mode_validate_ycbcr420(mode,
+ connector);
}
   
   prune:

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 89c0062..b55b2a7 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -477,4 +477,5 @@ void drm_edid_get_monitor_name(struct edid *edid, char 
*name,
   struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh,
   bool rb);
+bool drm_valid_cea_vic(u8 vic);
   #endif /* __DRM_EDID_H__ */
diff --git 

Re: [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

[Ville Syrjälä]

On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/4/2017 9:26 PM, Ville Syrjälä wrote:
> > On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote:
> >> YCBCR420 modes are supported only on HDMI 2.0 capable sources.
> >> This patch adds a drm helper to validate YCBCR420-only mode
> >> on a particular connector. This function will help pruning
> >> the YCBCR420-only modes from the connector's modelist.
> >>
> >> V5: Introduced the patch in series.
> >>
> >> Cc: Ville Syrjala 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c |  3 ++-
> >>   drivers/gpu/drm/drm_modes.c| 28 
> >>   drivers/gpu/drm/drm_probe_helper.c |  4 
> >>   include/drm/drm_edid.h |  1 +
> >>   include/drm/drm_modes.h|  5 +
> >>   5 files changed, 40 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index b879662..ad26c5e 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -2947,10 +2947,11 @@ u8 drm_match_cea_mode(const struct 
> >> drm_display_mode *to_match)
> >>   }
> >>   EXPORT_SYMBOL(drm_match_cea_mode);
> >>   
> >> -static bool drm_valid_cea_vic(u8 vic)
> >> +bool drm_valid_cea_vic(u8 vic)
> >>   {
> >>return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
> >>   }
> >> +EXPORT_SYMBOL(drm_valid_cea_vic);
> >>   
> >>   /**
> >>* drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding 
> >> to
> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> >> index f2493b9..3b53c8e3 100644
> >> --- a/drivers/gpu/drm/drm_modes.c
> >> +++ b/drivers/gpu/drm/drm_modes.c
> >> @@ -1083,6 +1083,34 @@ drm_mode_validate_size(const struct 
> >> drm_display_mode *mode,
> >>   }
> >>   EXPORT_SYMBOL(drm_mode_validate_size);
> >>   
> >> +/**
> >> + * drm_mode_ycbcr420_only - add 'ycbcr420-only' modes only when allowed
> >> + * @mode: mode to check
> >> + * @connector: drm connector under action
> >> + *
> >> + * This function is a helper which can be used to filter out any YCBCR420
> >> + * only mode, when the source doesn't support it.
> >> + *
> >> + * Returns:
> >> + * The mode status
> >> + */
> >> +enum drm_mode_status
> >> +drm_mode_validate_ycbcr420(const struct drm_display_mode *mode,
> >> + struct drm_connector *connector)
> >> +{
> >> +  u8 vic = drm_match_cea_mode(mode);
> >> +  enum drm_mode_status status = MODE_OK;
> >> +  struct drm_hdmi_info *hdmi = >display_info.hdmi;
> >> +
> >> +  if (drm_valid_cea_vic(vic) && test_bit(vic, hdmi->y420_vdb_modes)) {
> > The drm_valid_cea_vic() check seems redundant to me.
> > Why do you think we need it?
> drm_match_cea_mode() returns 0 in case if a vic is not found. if we take 
> that to test_bit() it will check bit 0
> and give wrong results.

Why would bit 0 be set? That would sound like a bug in the mode parsing.

> So first we have to check valid vic, this is 
> also an additional check for YCBCR420 mode
> as they must have a valid vic
> > Also I don't think this will compile since we don't have
> > y420_vdb_modes[] yet.
> Ah, now I recall the reason I wanted to give you, when you asked me to 
> move this patch, before we add ycbcr420 modes.
> So now this has to go after patch 5 right ? I would re-sequence 
> accordingly.
> 
> - Shashank
> >> +  if (!connector->ycbcr_420_allowed)
> >> +  status = MODE_NO_420;
> >> +  }
> >> +
> >> +  return status;
> >> +}
> >> +EXPORT_SYMBOL(drm_mode_validate_ycbcr420);
> >> +
> >>   #define MODE_STATUS(status) [MODE_ ## status + 3] = #status
> >>   
> >>   static const char * const drm_mode_status_names[] = {
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> index 00e6832..904966c 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> @@ -528,6 +528,10 @@ int drm_helper_probe_single_connector_modes(struct 
> >> drm_connector *connector,
> >>if (mode->status == MODE_OK)
> >>mode->status = drm_mode_validate_pipeline(mode,
> >>  connector);
> >> +
> >> +  if (mode->status == MODE_OK)
> >> +  mode->status = drm_mode_validate_ycbcr420(mode,
> >> +connector);
> >>}
> >>   
> >>   prune:
> >> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> >> index 89c0062..b55b2a7 100644
> >> --- a/include/drm/drm_edid.h
> >> +++ b/include/drm/drm_edid.h
> >> @@ -477,4 +477,5 @@ void drm_edid_get_monitor_name(struct edid *edid, char 
> >> *name,
> >>   struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
> >>   int hsize, int vsize, int 

Re: [PATCH 11/13] drm/i915: Protect against deferred fbdev setup

[Maarten Lankhorst]

Op 04-07-17 om 17:18 schreef Daniel Vetter:
> We could probably hit this already with our current async fbdev init,
> but it's much easier to hit this with the new deferred fbdev setup
> that I'm working on polishing.
>
> Cc: Maarten Lankhorst 
> Reported-by: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 580bd4f4a49e..a4224566ebca 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1931,7 +1931,7 @@ static int i915_gem_framebuffer_info(struct seq_file 
> *m, void *data)
>   return ret;
>  
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
> - if (dev_priv->fbdev) {
> + if (dev_priv->fbdev && dev_priv->fbdev->helper.fb) {
>   fbdev_fb = to_intel_framebuffer(dev_priv->fbdev->helper.fb);
>  
>   seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier 
> 0x%llx, refcount %d, obj ",

Since patch 10/13 makes it way more likely we don't allocate a FB, this patch 
should be commited before it?

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

Re: [RFC] clk: inherit display clocks enabled by bootloader

[Rob Clark]

On Tue, Jul 4, 2017 at 11:27 PM, Rajendra Nayak  wrote:
>
>
> On 07/04/2017 11:21 PM, Rob Clark wrote:
>> The goal here is to support inheriting a display setup by bootloader,
>> although there may also be some non-display related use-cases.
>>
>> Rough idea is to add a flag for clks and power domains that might
>> already be enabled when kernel starts, and make corresponding fixups
>> to clk enable/prepare_count and power-domain state so that these are
>> not automatically disabled late in boot.
>>
>> If bootloader is enabling display, and kernel is using efifb before
>> real display driver is loaded (potentially from kernel module after
>> userspace starts, in a typical distro kernel), we don't want to kill
>> the clocks and power domains that are used by the display before
>> userspace starts.
>>
>> Second part will be (*waves hands*) for drm/msm to check if display
>> related clocks are enabled when it is loaded, and if so use drm
>> atomic framework's hooks to read back hw state to sync existing
>> display state w/ software state, and skip the initial clk_enable.
>> Therefore inheriting the enable done by bootloader.
>>
>> Obviously this should be split up into multiple patches and many
>> TODOs addressed.  But I guess this is enough for now to start
>> discussing the approach, and in particular how drm and clock/pd
>> drivers work together to handle handover from bootloader.
>>
>> The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
>> on leaf nodes.
>> ---
>> A bit hacky right now, but display survives clk_disable_unused()
>> and genpd_power_off_unused().  It hangs just after that late in
>> boot, which I'm still debugging (might be unrelated shenanigans).
>> And haven't started on the drm/msm side of this.  But I figured
>> it was half baked enough to send out for comments/ideas, or to
>> see if anyone had some different idea about how to solve this.
>
> Another RFC proposed around to handle similar situations is
> https://lkml.org/lkml/2017/6/28/188
>
> That one though, I guess deals with only regulator supplies for now.

Interesting.. although I do prefer it not being a static thing.  Ie.
depending on lk version and 'fastboot oem' params it may or may not
light up the display.  So detecting whether something is on at boot
is, imo, important.

(I haven't looked at regulators yet.. looks like it is all power
domains, at least on 8x16, not sure about others..)

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

Re: [PATCH v2.1 1/2] dt-bindings: display: rcar-du: Add a VSP channel index to the vsps DT property

[Geert Uytterhoeven]

On Sun, Jul 2, 2017 at 3:40 PM, Laurent Pinchart
 wrote:
> On some R-Car SoCs a single VSP can serve multiple DU channels through
> multiple LIF instances in the VSP. The current DT bindings don't support
> specifying that kind of SoC integration scheme. Extend them with a VSP
> channel index.
>
> Backward compatibility can be ensured in drivers by checking the length
> of the vsps property and setting the channel to 0 when the property
> doesn't contain channel indices.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/2] util: move some files to an ASIC neutral directory.

[Emil Velikov]

On 30 June 2017 at 20:24, Samuel Li  wrote:

Commit message should explain why we want this - aka "Will be reused
in radeon with a later commit"

> Change-Id: Iac1c4870253e8b8860a61b7cf175e7a25cc95921
> Signed-off-by: Samuel Li 
> ---
>  Makefile.sources |  10 +-
>  amdgpu/Makefile.am   |   3 +-
>  amdgpu/Makefile.sources  |   7 +-
>  amdgpu/amdgpu_asic_id.c  | 219 ---
>  amdgpu/amdgpu_device.c   |   7 +-
>  amdgpu/amdgpu_internal.h |  11 +-
>  amdgpu/util_hash.c   | 387 
> ---
>  amdgpu/util_hash.h   | 107 -
>  amdgpu/util_hash_table.c | 262 
>  amdgpu/util_hash_table.h |  73 -
>  util/util_asic_id.c  | 217 ++
>  util/util_asic_id.h  |  39 +
>  util/util_hash.c | 387 
> +++
>  util/util_hash.h | 107 +
>  util/util_hash_table.c   | 262 
>  util/util_hash_table.h   |  73 +
>  16 files changed, 1102 insertions(+), 1069 deletions(-)
>  delete mode 100644 amdgpu/amdgpu_asic_id.c
>  delete mode 100644 amdgpu/util_hash.c
>  delete mode 100644 amdgpu/util_hash.h
>  delete mode 100644 amdgpu/util_hash_table.c
>  delete mode 100644 amdgpu/util_hash_table.h
>  create mode 100644 util/util_asic_id.c
>  create mode 100644 util/util_asic_id.h
>  create mode 100644 util/util_hash.c
>  create mode 100644 util/util_hash.h
>  create mode 100644 util/util_hash_table.c
>  create mode 100644 util/util_hash_table.h
>
Please generate patches which move files around with git format-patch -M.


> diff --git a/Makefile.sources b/Makefile.sources
> index 10aa1d0..f2b0ec6 100644
> --- a/Makefile.sources
> +++ b/Makefile.sources
> @@ -10,12 +10,18 @@ LIBDRM_FILES := \
> libdrm_macros.h \
> libdrm_lists.h \
> util_double_list.h \
> -   util_math.h
> +   util_math.h \
> +   util/util_asic_id.c \
> +   util/util_hash.c \
> +   util/util_hash_table.c
>
>  LIBDRM_H_FILES := \
> libsync.h \
> xf86drm.h \
> -   xf86drmMode.h
> +   xf86drmMode.h \
> +   util/util_asic_id.h \
> +   util/util_hash.h \
> +   util/util_hash_table.h
>
The "H_FILES" are installed, which we don't want to do here. Please
move them to LIBDRM_FILES above.


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

Re: [PATCH v2] drm/exynos: mic: add a bridge at probe

[Hoegeun Kwon]

On 07/05/2017 05:18 PM, Inki Dae wrote:

This patch moves drm_bridge_add call into probe.

It doesn't need to call drm_bridge_add call every time
bind callback is called.

Changelog v2
- moved drm_bridge_remove call into remove callback.
- corrected description.

Suggested-by: Andrzej Hajda 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Inki Dae 


Reviewed-by: Hoegeun Kwon 

Best regards,
Hoegeun

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

Re: [PATCH libdrm] amdgpu: move asic id table to a separate file

[Emil Velikov]

On 4 July 2017 at 07:40, Chih-Wei Huang  wrote:
> 2017-06-12 17:50 GMT+08:00 Michel Dänzer :
>> From: Xiaojie Yuan 
>>
>> v2: fix an off by one error and leading white spaces
>> v3: use thread safe strtok_r(); initialize len before calling getline();
>> change printf() to drmMsg(); add initial amdgpu.ids
>> v4: integrate some recent internal changes, including format changes
>> v5: fix line number for empty/commented lines; realloc to save memory;
>> indentation changes
>> v6: remove a line error
>> v7: [Michel Dänzer]
>> * Move amdgpu.ids to new data directory
>> * Remove placeholder entries from amdgpu.ids
>> * Set libdrmdatadir variable in configure.ac instead of Makefile.am
>>   [Emil Velikov]
>> * Use isblank() instead of open-coding it [Emil Velikov]
>> * Don't leak asic_id_table memory if realloc fails [Emil Velikov]
>> * Check and bump table_max_size at the beginning of the while loop [Emil
>>   Velikov]
>> * Initialize table_max_size to the number of entries in data/amdgpu.ids
>>
>> Reviewed-by: Junwei Zhang 
>> Signed-off-by: Samuel Li 
>> Signed-off-by: Michel Dänzer 
>> ---
>>  Makefile.am  |   1 +
>>  amdgpu/Makefile.am   |   6 ++
>>  amdgpu/Makefile.sources  |   2 +-
>>  amdgpu/amdgpu_asic_id.c  | 219 
>> +++
>>  amdgpu/amdgpu_asic_id.h  | 165 ---
>>  amdgpu/amdgpu_device.c   |  28 --
>>  amdgpu/amdgpu_internal.h |  10 +++
>>  configure.ac |   4 +
>>  data/Makefile.am |  23 +
>>  data/amdgpu.ids  | 159 ++
>>  10 files changed, 444 insertions(+), 173 deletions(-)
>>  create mode 100644 amdgpu/amdgpu_asic_id.c
>>  delete mode 100644 amdgpu/amdgpu_asic_id.h
>>  create mode 100644 data/Makefile.am
>>  create mode 100644 data/amdgpu.ids
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index dfb8fcdb..7b86214e 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -109,6 +109,7 @@ SUBDIRS = \
>> $(TEGRA_SUBDIR) \
>> $(VC4_SUBDIR) \
>> $(ETNAVIV_SUBDIR) \
>> +   data \
>> tests \
>> $(MAN_SUBDIR)
>>
>> diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
>> index cf7bc1ba..3444883f 100644
>> --- a/amdgpu/Makefile.am
>> +++ b/amdgpu/Makefile.am
>> @@ -30,6 +30,12 @@ AM_CFLAGS = \
>> $(PTHREADSTUBS_CFLAGS) \
>> -I$(top_srcdir)/include/drm
>>
>> +libdrmdatadir = @libdrmdatadir@
>> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
>> +   $(top_srcdir)/data/amdgpu.ids)
>> +AM_CPPFLAGS = -DAMDGPU_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\" \
>> +   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)
>
> Unfortunately this patch breaks Android build
> since the two macros are not defined.
>
> Anyone is working on a fix?
> If not, I'll try to provide one.
>
Please send a patch. I doubt many of the AMD devs have an Android setup.
Do ensure that the amdgpu.ids file is installed and accessible.

JFYI: a similar work is coming on the radeon side, so keep an eye open.

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

Re: [PATCH v1 3/3] drm/panel: Add support for otm8009a panel driver

[Andrzej Hajda]

On 04.07.2017 18:30, Philippe CORNU wrote:
> This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD
> panel driver (MIPI-DSI video mode). The panel backlight is
> managed through the DSI link. This panel driver is used in
> several STM32 boards.
>
> Signed-off-by: Philippe CORNU 
> ---
>  drivers/gpu/drm/panel/Kconfig|   9 +
>  drivers/gpu/drm/panel/Makefile   |   1 +
>  drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 517 
> +++
>  3 files changed, 527 insertions(+)
>  create mode 100755 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d84a031..c1c9291 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -117,4 +117,13 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>  
> +config DRM_PANEL_ORISETECH_OTM8009A
> + tristate "Orise Tech otm8009a 480p dsi 2dl video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for Orise Tech OTM8009A
> +   480x800 DSI panel
> +
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 9f6610d..ac798f3 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += 
> panel-samsung-s6e8aa0.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
> \ No newline at end of file
> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> new file mode 100755
> index 000..7aefc09
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> @@ -0,0 +1,517 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2017
> + *
> + * Authors: Philippe Cornu 
> + *  Yannick Fertre 
> + *
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRV_NAME "orisetech_otm8009a"
> +
> +#define OTM8009A_BACKLIGHT_DEFAULT   240
> +#define OTM8009A_BACKLIGHT_MAX   255
> +
> +struct otm8009a {
> + struct device *dev;
> + struct drm_panel panel;
> + struct backlight_device *bl_dev;
> + struct gpio_desc *reset_gpio;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static const struct drm_display_mode default_mode = {
> + .clock = 32729,
> + .hdisplay = 480,
> + .hsync_start = 480 + 120,
> + .hsync_end = 480 + 120 + 63,
> + .htotal = 480 + 120 + 63 + 120,
> + .vdisplay = 800,
> + .vsync_start = 800 + 12,
> + .vsync_end = 800 + 12 + 12,
> + .vtotal = 800 + 12 + 12 + 12,
> + .vrefresh = 50,
> + .flags = 0,
> + .width_mm = 52,
> + .height_mm = 86,
> +};
> +
> +static inline struct otm8009a *panel_to_otm8009a(struct drm_panel *panel)
> +{
> + return container_of(panel, struct otm8009a, panel);
> +}
> +
> +static void otm8009a_dcs_write_buf(struct otm8009a *ctx, const void *data,
> +size_t len)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> + if (mipi_dsi_dcs_write_buffer(dsi, data, len) < 0)
> + DRM_WARN("mipi dsi dcs write buffer failed");

New line at the end of string.

I see another way of fighting with error handling, its drawback is that
failure does not prevent further execution.
Since I am lost what error handling pattern is currently accepted in
panels subsystem, I cannot advice if this should be changed.

> +}
> +
> +#define dcs_write_seq(seq...)\
> + do {\
> + static const u8 d[] = { seq };  \
> + otm8009a_dcs_write_buf(ctx, d, ARRAY_SIZE(d));  \
> + } while (0)

It is up to your preferences, but I think "do {} while(0)" construct is
kind of workaround and is obsoleted in favor of ({ ... }) statement
expressions[1].
More serious issue is that you are using ctx implicitly, it should be
added as macro argument.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

> +
> +static int otm8009a_init_sequence(struct otm8009a *ctx)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> + int ret;
> +
> + /*
> +  * CMD2_ENA1: Enter in Command 2 mode, enable write function of
> +  * Command 2 & enable parameter shift 

Re: [PATCH 12/14] drm/exynos: mic: clean up drm_bridge_add call

[Archit Taneja]

On 07/05/2017 02:35 PM, Inki Dae wrote:



2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글:



On 07/03/2017 02:12 PM, Inki Dae wrote:

This patch removes unnecessary checking of return value.

Ps. this patch depends on below one,
 http://www.spinics.net/lists/dri-devel/msg145687.html


Will this one^ go via the exynos pull req or drm-misc? If there won't
be any conflicts, we could get both the patches through drm-misc to
keep things simple.


exynos pull it would be better. I will pick this up. :)


If patch # 1/14 goes through drm-misc, and the exynos patch goes through
exynos pull, the drm-misc branch would break. That's the reason I
preferred the exynos patches to go via misc.

Thanks,
Archit



Thanks,
Inki Dae



Archit



Signed-off-by: Inki Dae 
---
   drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 +-
   1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 5ea6e3d..07bd7fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -458,11 +458,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
   mic->bridge.funcs = _bridge_funcs;
   mic->bridge.of_node = dev->of_node;
   -ret = drm_bridge_add(>bridge);
-if (ret) {
-DRM_ERROR("mic: Failed to add MIC to the global bridge list\n");
-return ret;
-}
+drm_bridge_add(>bridge);
 pm_runtime_enable(dev);
  




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

Re: [PATCH 12/14] drm/exynos: mic: clean up drm_bridge_add call

[Inki Dae]

2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글:
> 
> 
> On 07/03/2017 02:12 PM, Inki Dae wrote:
>> This patch removes unnecessary checking of return value.
>>
>> Ps. this patch depends on below one,
>> http://www.spinics.net/lists/dri-devel/msg145687.html
> 
> Will this one^ go via the exynos pull req or drm-misc? If there won't
> be any conflicts, we could get both the patches through drm-misc to
> keep things simple.

exynos pull it would be better. I will pick this up. :)

Thanks,
Inki Dae

> 
> Archit
> 
>>
>> Signed-off-by: Inki Dae 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 +-
>>   1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> index 5ea6e3d..07bd7fc 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> @@ -458,11 +458,7 @@ static int exynos_mic_probe(struct platform_device 
>> *pdev)
>>   mic->bridge.funcs = _bridge_funcs;
>>   mic->bridge.of_node = dev->of_node;
>>   -ret = drm_bridge_add(>bridge);
>> -if (ret) {
>> -DRM_ERROR("mic: Failed to add MIC to the global bridge list\n");
>> -return ret;
>> -}
>> +drm_bridge_add(>bridge);
>> pm_runtime_enable(dev);
>>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/14] drm/mediatek: hdmi: clean up drm_bridge_add call

[Archit Taneja]

On 07/03/2017 02:12 PM, Inki Dae wrote:

This patch removes unnecessary checking of return value.


Can I get an ack from the maintainers to get this pulled in
via drm-misc?

Thanks,
Archit



Signed-off-by: Inki Dae 
---
  drivers/gpu/drm/mediatek/mtk_hdmi.c | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0a4ffd7..62652ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1697,11 +1697,7 @@ static int mtk_drm_hdmi_probe(struct platform_device 
*pdev)
  
  	hdmi->bridge.funcs = _hdmi_bridge_funcs;

hdmi->bridge.of_node = pdev->dev.of_node;
-   ret = drm_bridge_add(>bridge);
-   if (ret) {
-   dev_err(dev, "failed to add bridge, ret = %d\n", ret);
-   return ret;
-   }
+   drm_bridge_add(>bridge);
  
  	ret = mtk_hdmi_clk_enable_audio(hdmi);

if (ret) {



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

Re: [PATCH 12/14] drm/exynos: mic: clean up drm_bridge_add call

[Archit Taneja]

On 07/03/2017 02:12 PM, Inki Dae wrote:

This patch removes unnecessary checking of return value.

Ps. this patch depends on below one,
http://www.spinics.net/lists/dri-devel/msg145687.html


Will this one^ go via the exynos pull req or drm-misc? If there won't
be any conflicts, we could get both the patches through drm-misc to
keep things simple.

Archit



Signed-off-by: Inki Dae 
---
  drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 5ea6e3d..07bd7fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -458,11 +458,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
mic->bridge.funcs = _bridge_funcs;
mic->bridge.of_node = dev->of_node;
  
-	ret = drm_bridge_add(>bridge);

-   if (ret) {
-   DRM_ERROR("mic: Failed to add MIC to the global bridge list\n");
-   return ret;
-   }
+   drm_bridge_add(>bridge);
  
  	pm_runtime_enable(dev);
  



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

Re: [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

[Laurent Pinchart]

Hi Ville,

On Tuesday 04 Jul 2017 15:44:02 Ville Syrjälä wrote:
> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
> > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> >> From: Ville Syrjälä 
> >> 
> >> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> >> 3D to 2D mode in a timely fashion if the source simply stops sending the
> >> HDMI infoframe. The suggested workaround is to keep sending the
> >> infoframe even when strictly not necessary (ie. no VIC and no S3D).
> >> HDMI 1.4 does allow for this behaviour, stating that sending the
> >> infoframe is optional in this case.
> > 
> > My impression from the specs is that it should be done only after
> > switching from 3d to 2d mode.
> > In such case we just need to remember previous mode, if it was 3d, empty
> > VSIF infoframe should be still generated for 2seconds.
> > No need to do guesses from EDID.
> > Am I right, or just missing something?
> 
> This code has no idea about any 3D->2D transitions, trying to make it
> do that would just result in a lot of complexity. Much easier to just
> always send the infoframe.
> 
> >> The infoframe was first specified in HDMI 1.4, so in theory sinks
> >> predating that may not appreciate us sending an uknown infoframe
> >> their way. To avoid regressions let's try to determine if the sink
> >> supports the infoframe or not. Unfortunately there's no direct way
> >> to do that, so instead we'll just check if we managed to parse any
> >> HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
> >> sink will accept the infoframe. Also if the EDID contains the HDMI
> >> 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
> >> the infoframe.
> >> Cc: Archit Taneja 
> >> Cc: Andrzej Hajda 
> >> Cc: Laurent Pinchart 
> >> Cc: Inki Dae 
> >> Cc: Joonyoung Shim 
> >> Cc: Seung-Woo Kim 
> >> Cc: Kyungmin Park 
> >> Cc: CK Hu 
> >> Cc: Philipp Zabel 
> >> Cc: Ben Skeggs 
> >> Cc: Mark Yao 
> >> Cc: Benjamin Gaignard 
> >> Cc: Vincent Abriou 
> >> Cc: Shawn Guo 
> >> Cc: Shashank Sharma 
> >> Signed-off-by: Ville Syrjälä 
> >> ---
> >> 
> >>  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
> >>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
> >>  drivers/gpu/drm/drm_edid.c| 32 ++--
> >>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >>  drivers/gpu/drm/i915/intel_hdmi.c | 14 --
> >>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
> >>  drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
> >>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
> >>  drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
> >>  drivers/gpu/drm/zte/zx_hdmi.c |  1 +
> >>  include/drm/drm_connector.h   |  5 +
> >>  include/drm/drm_edid.h|  1 +
> >>  12 files changed, 55 insertions(+), 18 deletions(-)

[snip]

> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 2e55599816aa..c061dd5d25c0 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c

[snip]

> >> @@ -4452,6 +4458,7 @@ s3d_structure_from_display_mode(const struct
> >> drm_display_mode *mode)> > 
> >>   * drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI
> >>   infoframe with
> >>   * data from a DRM display mode
> >>   * @frame: HDMI vendor infoframe
> >> + * @connector: the connector
> >>   * @mode: DRM display mode
> >>   *
> >>   * Note that there's is a need to send HDMI vendor infoframes only when
> >>   using a
> >> @@ -4462,8 +4469,15 @@ s3d_structure_from_display_mode(const struct
> >> drm_display_mode *mode)
> >>   */
> >>  
> >>  int
> >>  drm_hdmi_vendor_infoframe_from_display_mode(struct
> >>  hdmi_vendor_infoframe *frame,
> >> +  struct drm_connector *connector,
> >>const struct drm_display_mode
> >>*mode)
> >>  {
> >> +  /*
> >> +   * FIXME: sil-sii8620 doesn't have a connector around when
> >> +   * we need one, so we have to be prepared for a NULL connector.
> >> +   */
> >> +  bool has_hdmi_infoframe = connector ?
> >> +  >display_info.has_hdmi_infoframe : NULL;
> > 
> > I wonder if requiring connector is a good idea, I can imagine that this
> > function can be necessary in pure drm_encoder or non-terminal drm_bridge.
> 
> No decent way around it, unless we want to risk sending the infoframe to
> pre HDMI 1.4 sinks. Sounds like you have some kind of layering problem
> if 

[PATCH v2] drm/exynos: mic: add a bridge at probe

[Inki Dae]

This patch moves drm_bridge_add call into probe.

It doesn't need to call drm_bridge_add call every time
bind callback is called.

Changelog v2
- moved drm_bridge_remove call into remove callback.
- corrected description.

Suggested-by: Andrzej Hajda 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index e457205..16bbee8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -340,16 +340,10 @@ static int exynos_mic_bind(struct device *dev, struct 
device *master,
   void *data)
 {
struct exynos_mic *mic = dev_get_drvdata(dev);
-   int ret;
 
-   mic->bridge.funcs = _bridge_funcs;
-   mic->bridge.of_node = dev->of_node;
mic->bridge.driver_private = mic;
-   ret = drm_bridge_add(>bridge);
-   if (ret)
-   DRM_ERROR("mic: Failed to add MIC to the global bridge list\n");
 
-   return ret;
+   return 0;
 }
 
 static void exynos_mic_unbind(struct device *dev, struct device *master,
@@ -365,8 +359,6 @@ static void exynos_mic_unbind(struct device *dev, struct 
device *master,
 
 already_disabled:
mutex_unlock(_mutex);
-
-   drm_bridge_remove(>bridge);
 }
 
 static const struct component_ops exynos_mic_component_ops = {
@@ -461,6 +453,15 @@ static int exynos_mic_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, mic);
 
+   mic->bridge.funcs = _bridge_funcs;
+   mic->bridge.of_node = dev->of_node;
+
+   ret = drm_bridge_add(>bridge);
+   if (ret) {
+   DRM_ERROR("mic: Failed to add MIC to the global bridge list\n");
+   return ret;
+   }
+
pm_runtime_enable(dev);
 
ret = component_add(dev, _mic_component_ops);
@@ -479,8 +480,13 @@ static int exynos_mic_probe(struct platform_device *pdev)
 
 static int exynos_mic_remove(struct platform_device *pdev)
 {
+   struct exynos_mic *mic = platform_get_drvdata(pdev);
+
component_del(>dev, _mic_component_ops);
pm_runtime_disable(>dev);
+
+   drm_bridge_remove(>bridge);
+
return 0;
 }
 
-- 
1.9.1

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

[Bug 100399] Kernel invalid opcode on unbinding amdgpu

[bugzilla-daemon]

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

--- Comment #9 from jimijames.b...@gmail.com ---
(In reply to Michel Dänzer from comment #8)
> Make sure nothing else (e.g. gdm in Wayland mode) is using the GPU you're
> trying to unbind either. Something like
> 
>  sudo lsof /dev/dri/*
> 
> shows which process is using which GPU device(s).

I did that way back when I first discovered this bug. I'll do it again just to
make sure when I'm back with the computer that has the virtual machine and AMD
GPU in a couple weeks.

-- 
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 100399] Kernel invalid opcode on unbinding amdgpu

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
Make sure nothing else (e.g. gdm in Wayland mode) is using the GPU you're
trying to unbind either. Something like

 sudo lsof /dev/dri/*

shows which process is using which GPU device(s).

-- 
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 100399] Kernel invalid opcode on unbinding amdgpu

[bugzilla-daemon]

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

--- Comment #7 from jimijames.b...@gmail.com ---
(In reply to jimijames.bove from comment #6)
> Well, sort of. That option is what allows me to bind the card to amdgpu
> without X crashing (even though I've been told in the past that I shouldn't
> need that option for that functionality), but this bug--not being able to
> UNbind it from amdgpu--does not go away with that option.

Actually, sorry, I just remembered, I *don't* need that option anymore to bind
it to amdgpu while X is running. That did get fixed. But back then and also
right now, it still doesn't fix this bug.

-- 
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 100399] Kernel invalid opcode on unbinding amdgpu

[bugzilla-daemon]

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

--- Comment #6 from jimijames.b...@gmail.com ---
(In reply to Michel Dänzer from comment #5)
> (In reply to jimijames.bove from comment #4)
> > Before I switched to AMD, I was passing an NVidia GPU (GTX 660) into my
> > virtual machine, and I could unbind and rebind it between nouveau and
> > vfio-pci as much as I wanted. No trouble at all. Even while X was running,
> > once DRI3 support came.
> 
> You can still do that with DRI3, you just have to prevent Xorg from using
> the secondary GPU, e.g. via
> 
> Section "ServerFlags"
>Option  "AutoAddGPU" "off"
> EndSection
> 
> in /etc/X11/xorg.conf.

Well, sort of. That option is what allows me to bind the card to amdgpu without
X crashing (even though I've been told in the past that I shouldn't need that
option for that functionality), but this bug--not being able to UNbind it from
amdgpu--does not go away with that option.

-- 
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 101518] [BAT][SKL] WARNING: no modes for connector 48 when running igt@kms_setmode@basic-clone-single-crtc

[bugzilla-daemon]

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

--- Comment #6 from Martin Peres  ---
*** Bug 101519 has been marked as a duplicate of this bug. ***

-- 
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 101518] [BAT][SKL] WARNING: no modes for connector 48 when running igt@kms_setmode@basic-clone-single-crtc

[bugzilla-daemon]

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

Martin Peres  changed:

   What|Removed |Added

 CC||manasi.d.nav...@intel.com

--- Comment #5 from Martin Peres  ---
Manasi, now that you fixed the failing platform, could you have a look into
this IGT bug?

Basically, IGT does not know how to deal with the kernel pruning modes. Do we
want to simply ignore this possibility or do we want to be more robust to it?

At the very least, it would be nice to add a debug message saying that the
modes may all have been pruned, according to the DP spec.

-- 
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 100399] Kernel invalid opcode on unbinding amdgpu

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
(In reply to jimijames.bove from comment #4)
> Before I switched to AMD, I was passing an NVidia GPU (GTX 660) into my
> virtual machine, and I could unbind and rebind it between nouveau and
> vfio-pci as much as I wanted. No trouble at all. Even while X was running,
> once DRI3 support came.

You can still do that with DRI3, you just have to prevent Xorg from using the
secondary GPU, e.g. via

Section "ServerFlags"
   Option  "AutoAddGPU" "off"
EndSection

in /etc/X11/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

Re: [PATCH v4] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

[Hoegeun Kwon]

Hi Inki,

Could you check this patch? :D

Best regards,
Hoegeun

On 06/21/2017 07:51 PM, Hoegeun Kwon wrote:

Remove the error handling of bridge_node because the bridge_node is
optional.

For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is optional.

Signed-off-by: Hoegeun Kwon 
---

Hi all,

Thanks for Krzysztof's advice.

Changes for V4:
- Fixed the word('optional') from commit message.

Changes for V3:
- Removed the word('required') from commit message.

Changes for V2:
- Modified the commit message in more detail than before.

Best regards,
Hoegeun

  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index a11b795..6ee0dac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
return ret;
  
  	dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);

-   if (!dsi->bridge_node)
-   return -EINVAL;
  
  	return 0;

  }


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

Re: [PATCH 2/2] drm/exynos: mic: add a bridge at probe

[Hoegeun Kwon]

On 07/03/2017 04:27 PM, Inki Dae wrote:

This patch moves drm_bridge_add call into probe.

This change is required by DSI driver so that
the brige can be bound at DSI driver's probe.

Suggested-by: Andrzej Hajda 
Signed-off-by: Inki Dae 


Reviewed-by: Hoegeun Kwon 

Best regards,
Hoegeun

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

[Bug 100399] Kernel invalid opcode on unbinding amdgpu

[bugzilla-daemon]

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

--- Comment #4 from jimijames.b...@gmail.com ---
(In reply to Michel Dänzer from comment #3)
> FWIW, I don't think unbinding is supposed to be possible while Xorg (or
> anything else) is using the GPU. Sounds like there's something missing
> somewhere to prevent that.

Before I switched to AMD, I was passing an NVidia GPU (GTX 660) into my virtual
machine, and I could unbind and rebind it between nouveau and vfio-pci as much
as I wanted. No trouble at all. Even while X was running, once DRI3 support
came. I switched to AMD expecting the same functionality. Thankfully, not
having said functionality isn't the end of the world, but having to reboot my
computer every time I want to play a game in Windows right after playing a game
in Linux is exactly the kind of pain that I spent a summer setting up the VM to
avoid.

-- 
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 v5 09/17] drm: create hdmi output property

[Sharma, Shashank]

Regards

Shashank


On 7/5/2017 12:01 PM, Daniel Vetter wrote:

On Wed, Jul 05, 2017 at 11:39:30AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/4/2017 9:06 PM, Daniel Vetter wrote:

On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote:

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

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

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

PS: While doing modeset for YCBCR 420 only modes, this property is
  ignored, as those timings can be supported only in YCBCR 420
  output mode.

V2: Added description for the new variable to address build warning
V3: Rebase
V4: Rebase
V5: Added get_property counterpart to fix IGT BAT failures (BAT/CI)
  Danvet:
  - Add documentation for the new property
  - Create a sub-section for HDMI properties, and add documentation for
few more HDMI propeties. Added documentation for:
- Broadcast RGB
- aspect ratio

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 

Bunch more documentation nitpicks below. I'd personally also split up the
patch into documenting the existing props and adding the new format one.

In fact thats what I would do now. I dont want HDMI 2.0 patch series to get
blocked due to documentation, as with all the comments
it seems like some work. Lets do it in this way:
  - This patch series will add the documentation for hdmi_output_property
- I will send a separate patch which will collectively add documentation for
all standard HDMI properties.

Thanks, Daniel


---
   Documentation/gpu/drm-kms.rst   | 12 +++
   drivers/gpu/drm/drm_atomic.c|  4 +++
   drivers/gpu/drm/drm_atomic_helper.c |  4 +++
   drivers/gpu/drm/drm_connector.c | 69 
-
   drivers/gpu/drm/drm_crtc_internal.h |  1 +
   drivers/gpu/drm/drm_mode_config.c   |  4 +++
   drivers/gpu/drm/i915/intel_modes.c  | 13 +++
   include/drm/drm_connector.h | 18 ++
   include/drm/drm_mode_config.h   |  5 +++
   9 files changed, 129 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 3072841..dcdd6ff 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -508,6 +508,18 @@ Standard Connector Properties
   .. kernel-doc:: drivers/gpu/drm/drm_connector.c
  :doc: standard connector properties
+Standard HDMI Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: hdmi_output_format
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: aspect ratio property

I'd have just created 1 DOC: section titled "standard HDMI properties" and
listed all of them in 1 comment block. People often forget to add the
include stanza in the .rst files, having bigger comments helps with that.

But feel free to go either way.

Yes, this would be easier for me too, but this means I will have to add all
the documentation in one place, in one file, whether the respective
property is created at that place or not. I am not sure if everyone would be
ok with that during review. But if you think we should go ahead,
thanks for easing this up for me :-).

It might result in a minor merge conflict, but nothing bad should happen
if we put all the docs into one section.
Got it, so the cleanup patch will have doc for all DRM level HDMI 
property in one place !

+.. kernel-doc:: drivers/gpu/drm/i915/intel_modes.c
+   :doc: Broadcast RGB property

Please no generic properties documented in driver code.

Broadcast RGB property is created here, and also, while I was adding
documentation for it, I realized its kept in dev_priv, which is specific to
I915 driver, So its not generic too. I was not sure if that will be OK, if I
add an Intel specific property's description in DRM layer ?

It should be generic, but oh well it isn't. Either document it in the
core, or we'll leave this to the future when the create helper gets

Re: [PATCH v5 09/17] drm: create hdmi output property

[Daniel Vetter]

On Wed, Jul 05, 2017 at 11:39:30AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/4/2017 9:06 PM, Daniel Vetter wrote:
> > On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote:
> > > HDMI displays can support various output types, based on
> > > the color space and subsampling type. The possible
> > > outputs from a HDMI 2.0 monitor could be:
> > >   - RGB
> > >   - YCBCR 444
> > >   - YCBCR 422
> > >   - YCBCR 420
> > > 
> > > This patch adds a drm property "hdmi_output_format", using which,
> > > a user can specify its preference, for the HDMI output type. The
> > > output type enums are similar to the mentioned outputs above. To
> > > handle various subsampling of YCBCR output types, this property
> > > allows two special cases:
> > >   - DRM_HDMI_OUTPUT_YCBCR_HQ
> > > This indicates preferred output should be YCBCR output, with highest
> > > subsampling rate by the source/sink, which can be typically:
> > >   - ycbcr444
> > >   - ycbcr422
> > >   - ycbcr420
> > >   - DRM_HDMI_OUTPUT_YCBCR_LQ
> > > This indicates preferred output should be YCBCR output, with lowest
> > > subsampling rate supported by source/sink, which can be:
> > >   - ycbcr420
> > >   - ycbcr422
> > >   - ycbcr444
> > > 
> > > Default value of the property is set to 0 = RGB, so no changes if you
> > > dont set the property.
> > > 
> > > PS: While doing modeset for YCBCR 420 only modes, this property is
> > >  ignored, as those timings can be supported only in YCBCR 420
> > >  output mode.
> > > 
> > > V2: Added description for the new variable to address build warning
> > > V3: Rebase
> > > V4: Rebase
> > > V5: Added get_property counterpart to fix IGT BAT failures (BAT/CI)
> > >  Danvet:
> > >  - Add documentation for the new property
> > >  - Create a sub-section for HDMI properties, and add documentation for
> > >few more HDMI propeties. Added documentation for:
> > >   - Broadcast RGB
> > >   - aspect ratio
> > > 
> > > Cc: Ville Syrjala 
> > > Cc: Jose Abreu 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Shashank Sharma 
> > Bunch more documentation nitpicks below. I'd personally also split up the
> > patch into documenting the existing props and adding the new format one.
> In fact thats what I would do now. I dont want HDMI 2.0 patch series to get
> blocked due to documentation, as with all the comments
> it seems like some work. Lets do it in this way:
>  - This patch series will add the documentation for hdmi_output_property
> - I will send a separate patch which will collectively add documentation for
> all standard HDMI properties.
> > Thanks, Daniel
> > 
> > > ---
> > >   Documentation/gpu/drm-kms.rst   | 12 +++
> > >   drivers/gpu/drm/drm_atomic.c|  4 +++
> > >   drivers/gpu/drm/drm_atomic_helper.c |  4 +++
> > >   drivers/gpu/drm/drm_connector.c | 69 
> > > -
> > >   drivers/gpu/drm/drm_crtc_internal.h |  1 +
> > >   drivers/gpu/drm/drm_mode_config.c   |  4 +++
> > >   drivers/gpu/drm/i915/intel_modes.c  | 13 +++
> > >   include/drm/drm_connector.h | 18 ++
> > >   include/drm/drm_mode_config.h   |  5 +++
> > >   9 files changed, 129 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > > index 3072841..dcdd6ff 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -508,6 +508,18 @@ Standard Connector Properties
> > >   .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > >  :doc: standard connector properties
> > > +Standard HDMI Properties
> > > +-
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > +   :doc: hdmi_output_format
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > +   :doc: aspect ratio property
> > I'd have just created 1 DOC: section titled "standard HDMI properties" and
> > listed all of them in 1 comment block. People often forget to add the
> > include stanza in the .rst files, having bigger comments helps with that.
> > 
> > But feel free to go either way.
> Yes, this would be easier for me too, but this means I will have to add all
> the documentation in one place, in one file, whether the respective
> property is created at that place or not. I am not sure if everyone would be
> ok with that during review. But if you think we should go ahead,
> thanks for easing this up for me :-).

It might result in a minor merge conflict, but nothing bad should happen
if we put all the docs into one section.

> > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_modes.c
> > > +   :doc: Broadcast RGB property
> > Please no generic properties documented in driver code.
> Broadcast RGB property is created here, and also, while I was adding

Re: [PATCH v3 05/16] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Daniel Vetter]

On Tue, Jul 04, 2017 at 12:37:01PM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> completely obsolete.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 165 
> +++-
>  1 file changed, 94 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index b75b1f2..7f8199a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1257,27 +1257,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> drm_fb_helper *fb_helper,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>  
> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> -  u16 blue, u16 regno, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> -
> - /*
> -  * The driver really shouldn't advertise pseudo/directcolor
> -  * visuals if it can't deal with the palette.
> -  */
> - if (WARN_ON(!fb_helper->funcs->gamma_set ||
> - !fb_helper->funcs->gamma_get))
> - return -EINVAL;
> -
> - WARN_ON(fb->format->cpp[0] != 1);
> -
> - fb_helper->funcs->gamma_set(crtc, red, green, blue, regno);
> -
> - return 0;
> -}
> -
>  static int setcmap_pseudo_palette(struct fb_cmap *cmap, struct fb_info *info)
>  {
>   u32 *palette = (u32 *)info->pseudo_palette;
> @@ -1310,54 +1289,68 @@ static int setcmap_pseudo_palette(struct fb_cmap 
> *cmap, struct fb_info *info)
>   return 0;
>  }
>  
> -/**
> - * drm_fb_helper_setcmap - implementation for _ops.fb_setcmap
> - * @cmap: cmap to set
> - * @info: fbdev registered by the helper
> - */
> -int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info)
> +static int setcmap_legacy(struct fb_cmap *cmap, struct fb_info *info)
>  {
>   struct drm_fb_helper *fb_helper = info->par;
> - struct drm_device *dev = fb_helper->dev;
> - const struct drm_crtc_helper_funcs *crtc_funcs;
> - u16 *red, *green, *blue, *transp;
>   struct drm_crtc *crtc;
>   u16 *r, *g, *b;
> - int i, j, rc = 0;
> - int start;
> + int i, ret = 0;
>  
> - if (oops_in_progress)
> - return -EBUSY;
> + for (i = 0; i < fb_helper->crtc_count; i++) {
> + crtc = fb_helper->crtc_info[i].mode_set.crtc;
> + if (!crtc->funcs->gamma_set || !crtc->gamma_size)
> + return -EINVAL;
>  
> - mutex_lock(_helper->lock);
> - if (!drm_fb_helper_is_bound(fb_helper)) {
> - mutex_unlock(_helper->lock);
> - return -EBUSY;
> - }
> + if (cmap->start + cmap->len > crtc->gamma_size)
> + return -EINVAL;
>  
> - drm_modeset_lock_all(dev);
> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> - rc = setcmap_pseudo_palette(cmap, info);
> - goto out;
> + r = crtc->gamma_store;
> + g = r + crtc->gamma_size;
> + b = g + crtc->gamma_size;
> +
> + memcpy(r + cmap->start, cmap->red, cmap->len * sizeof(*r));
> + memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(*g));
> + memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(*b));
> +
> + ret = crtc->funcs->gamma_set(crtc, r, g, b,
> +  crtc->gamma_size, NULL);
> + if (ret)
> + return ret;
>   }
>  
> - for (i = 0; i < fb_helper->crtc_count; i++) {
> - crtc = fb_helper->crtc_info[i].mode_set.crtc;
> - crtc_funcs = crtc->helper_private;
> + return ret;
> +}

For the legacy path you need to keep the drm_modeset_lock_all (but only in
setcmap_legacy). Otherwise this part here looks good.

>  
> - red = cmap->red;
> - green = cmap->green;
> - blue = cmap->blue;
> - transp = cmap->transp;
> - start = cmap->start;
> +static int setcmap_atomic(struct fb_cmap *cmap, struct fb_info *info)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct drm_device *dev = fb_helper->dev;
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_crtc_state *crtc_state;
> + struct drm_atomic_state *state;
> + struct drm_crtc *crtc;
> + u16 *r, *g, *b;
> + int i, ret = 0;
>  
> - if (!crtc->gamma_size) {
> - rc = -EINVAL;
> + state = drm_atomic_state_alloc(dev);
> + if (!state)
> + return -ENOMEM;
> + drm_modeset_acquire_init(, 0);
> +retry:
> + ret = drm_modeset_lock_all_ctx(dev, );

With atomic you don't need to grab locks, this is done behind the scenes
(as long as you handle the retry/backoff correctly). See the kerneldoc for
the various drm_atomic_get_*_state functions.

> + if (ret)
> + goto 

Re: [PATCH v5 09/17] drm: create hdmi output property

[Sharma, Shashank]

Regards

Shashank


On 7/4/2017 9:06 PM, Daniel Vetter wrote:

On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote:

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

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

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

PS: While doing modeset for YCBCR 420 only modes, this property is
 ignored, as those timings can be supported only in YCBCR 420
 output mode.

V2: Added description for the new variable to address build warning
V3: Rebase
V4: Rebase
V5: Added get_property counterpart to fix IGT BAT failures (BAT/CI)
 Danvet:
 - Add documentation for the new property
 - Create a sub-section for HDMI properties, and add documentation for
   few more HDMI propeties. Added documentation for:
- Broadcast RGB
- aspect ratio

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 

Bunch more documentation nitpicks below. I'd personally also split up the
patch into documenting the existing props and adding the new format one.
In fact thats what I would do now. I dont want HDMI 2.0 patch series to 
get blocked due to documentation, as with all the comments

it seems like some work. Lets do it in this way:
 - This patch series will add the documentation for hdmi_output_property
- I will send a separate patch which will collectively add documentation 
for all standard HDMI properties.

Thanks, Daniel


---
  Documentation/gpu/drm-kms.rst   | 12 +++
  drivers/gpu/drm/drm_atomic.c|  4 +++
  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
  drivers/gpu/drm/drm_connector.c | 69 -
  drivers/gpu/drm/drm_crtc_internal.h |  1 +
  drivers/gpu/drm/drm_mode_config.c   |  4 +++
  drivers/gpu/drm/i915/intel_modes.c  | 13 +++
  include/drm/drm_connector.h | 18 ++
  include/drm/drm_mode_config.h   |  5 +++
  9 files changed, 129 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 3072841..dcdd6ff 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -508,6 +508,18 @@ Standard Connector Properties
  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
 :doc: standard connector properties
  
+Standard HDMI Properties

+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: hdmi_output_format
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: aspect ratio property

I'd have just created 1 DOC: section titled "standard HDMI properties" and
listed all of them in 1 comment block. People often forget to add the
include stanza in the .rst files, having bigger comments helps with that.

But feel free to go either way.
Yes, this would be easier for me too, but this means I will have to add 
all the documentation in one place, in one file, whether the respective
property is created at that place or not. I am not sure if everyone 
would be ok with that during review. But if you think we should go ahead,

thanks for easing this up for me :-).



+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_modes.c
+   :doc: Broadcast RGB property

Please no generic properties documented in driver code.
Broadcast RGB property is created here, and also, while I was adding 
documentation for it, I realized its kept in dev_priv, which is specific to
I915 driver, So its not generic too. I was not sure if that will be OK, 
if I add an Intel specific property's description in DRM layer ?

+
  Plane Composition Properties
  
  
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c

index 09ca662..adcb89d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = 

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Daniel Vetter]

On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
> Hi!
> 
> While trying to get CLUT support for the atmel_hlcdc driver, and
> specifically for the emulated fbdev interface, I received some
> push-back that my feeble in-driver attempts should be solved
> by the core. This is my attempt to do it right.
> 
> I have obviously not tested all of this with more than a compile,
> but patches 1 through 5 are enough to make the atmel-hlcdc driver
> do what I need. The rest is just lots of removals and cleanup made
> possible by the improved core.
> 
> Please test, I would not be surprised if I have fouled up some
> bit-manipulation somewhere, or if I have misunderstood something
> about atomics...
> 
> Changes since v2:
> - Added patch 1/16 which factors out pseudo-palette handling.
> - Removed the if (cmap->start + cmap->len < cmap->start)
>   sanity check on the assumption that the fbdev core handles it.
> - Added patch 4/16 which factors out atomic state and commit
>   handling from drm_atomic_helper_legacy_gamma_set to
>   drm_mode_gamma_set_ioctl.
> - Do one atomic commit for all affected crtc.
> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
>   the last patch).
> - Cc list is getting long, so I have redused the list for the
>   individual patches. If you would like to get the full series
>   (or nothing at all) for the next round (if that is needed) just
>   say so.

Is this still on top of my locking rework? I tried to apply patches 1-3,
but there's minor conflicts ...
-Daniel

> 
> Changes since v1:
> 
> - Rebased to next-20170621
> - Split 1/11 into a preparatory patch, a cleanup patch and then
>   the meat in 3/14.
> - Handle pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Removed the empty .gamma_get/.gamma_set fb helpers from the
>   armada driver that I had somehow managed to ignore but which
>   0day found real quick.
> - Be less judgemental on drivers only providing .gamma_get and
>   .gamma_set, but no .load_lut. That's actually a valid thing
>   to do if you only need pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Add a comment about colliding bitfields in the nouveau driver.
> - Remove gamma_set/gamma_get declarations from the radeon driver
>   (the definitions were removed in v1).
> 
> Cheers,
> peda
> 
> Peter Rosin (16):
>   drm/fb-helper: factor out pseudo-palette
>   drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap
>   drm/fb-helper: remove drm_fb_helper_save_lut_atomic
>   drm/color-mgmt: move atomic state/commit out from .gamma_set
>   drm/fb-helper: do a generic fb_setcmap helper in terms of crtc
> .gamma_set
>   drm: amd: remove dead code and pointless local lut storage
>   drm: armada: remove dead empty functions
>   drm: ast: remove dead code and pointless local lut storage
>   drm: cirrus: remove dead code and pointless local lut storage
>   drm: gma500: remove dead code and pointless local lut storage
>   drm: i915: remove dead code and pointless local lut storage
>   drm: mgag200: remove dead code and pointless local lut storage
>   drm: nouveau: remove dead code and pointless local lut storage
>   drm: radeon: remove dead code and pointless local lut storage
>   drm: stm: remove dead code and pointless local lut storage
>   drm: remove unused and redundant callbacks
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  24 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c|  25 +---
>  drivers/gpu/drm/armada/armada_crtc.c|  10 --
>  drivers/gpu/drm/armada/armada_crtc.h|   2 -
>  drivers/gpu/drm/armada/armada_fbdev.c   |   2 -
>  drivers/gpu/drm/ast/ast_drv.h   |   1 -
>  drivers/gpu/drm/ast/ast_fb.c|  20 ---
>  drivers/gpu/drm/ast/ast_mode.c  |  28 +---
>  drivers/gpu/drm/cirrus/cirrus_drv.h |   8 --
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |   2 -
>  drivers/gpu/drm/cirrus/cirrus_mode.c|  73 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  37 ++
>  drivers/gpu/drm/drm_color_mgmt.c|  27 +++-
>  drivers/gpu/drm/drm_fb_helper.c | 195 
> +---
>  drivers/gpu/drm/gma500/framebuffer.c|  22 
>  drivers/gpu/drm/gma500/gma_display.c|  34 ++---
>  drivers/gpu/drm/gma500/gma_display.h|   2 +-
>  drivers/gpu/drm/gma500/psb_intel_display.c  |   7 +-
>  drivers/gpu/drm/gma500/psb_intel_drv.h  |   1 -
>  drivers/gpu/drm/i915/intel_drv.h|   1 -
>  drivers/gpu/drm/i915/intel_fbdev.c  |  31 -
>  drivers/gpu/drm/mgag200/mgag200_drv.h   |   5 -
>  drivers/gpu/drm/mgag200/mgag200_fb.c|   2 -
>  drivers/gpu/drm/mgag200/mgag200_mode.c  |  64 +++--
>  

Re: [PATCH v3 01/16] drm/fb-helper: factor out pseudo-palette

[Daniel Vetter]

On Tue, Jul 04, 2017 at 12:40:16PM +0200, Peter Rosin wrote:
> On 2017-07-04 12:36, Peter Rosin wrote:
> > The pseudo-palette has nothing to do with the crtc, so move it
> > out of the crtc loop and update the palette once, then break out
> > early.
> > 
> > Signed-off-by: Peter Rosin 
> 
> Should of course be p...@axentia.se
> 
> I wonder when I managed to Ctrl-T that one?

fyi

git commit -s

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

Re: [PATCH v2 3/4] drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper

[Daniel Vetter]

On Tue, Jul 04, 2017 at 11:15:56PM +0200, Noralf Trønnes wrote:
> 
> Den 04.07.2017 17.28, skrev Daniel Vetter:
> > On Tue, Jul 04, 2017 at 05:00:46PM +0200, Noralf Trønnes wrote:
> > > Den 28.06.2017 19.12, skrev Daniel Vetter:
> > > > On Wed, Jun 28, 2017 at 04:26:23PM +0200, Noralf Trønnes wrote:
> > > > > Den 26.06.2017 11.43, skrev Daniel Vetter:
> > > > > > On Thu, Jun 08, 2017 at 05:14:34PM +0200, Noralf Trønnes wrote:
> > > > > > > Drm has no monochrome or greyscale support so add a conversion
> > > > > > > from the common format XR24.
> > > > > > > 
> > > > > > > Also reorder includes into the common order.
> > > > > > > 
> > > > > > > Signed-off-by: Noralf Trønnes 
> > > > > > > ---
> > > > > > > drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 74 
> > > > > > > +-
> > > > > > > include/drm/tinydrm/tinydrm-helpers.h  |  1 +
> > > > > > > 2 files changed, 73 insertions(+), 2 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> > > > > > > b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > > > > > > index d4cda33..75808bb 100644
> > > > > > > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > > > > > > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > > > > > > @@ -7,13 +7,15 @@
> > > > > > >  * (at your option) any later version.
> > > > > > >  */
> > > > > > > -#include 
> > > > > > > -#include 
> > > > > > > #include 
> > > > > > > +#include 
> > > > > > > #include 
> > > > > > > #include 
> > > > > > > #include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +
> > > > > > > static unsigned int spi_max;
> > > > > > > module_param(spi_max, uint, 0400);
> > > > > > > MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer 
> > > > > > > size");
> > > > > > > @@ -181,6 +183,74 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, 
> > > > > > > void *vaddr,
> > > > > > > EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
> > > > > > > /**
> > > > > > > + * tinydrm_xrgb_to_gray8 - Convert XRGB to grayscale
> > > > > > > + * @dst: 8-bit grayscale destination buffer
> > > > > > > + * @fb: DRM framebuffer
> > > > > > > + *
> > > > > > > + * Drm doesn't have native monochrome or grayscale support.
> > > > > > > + * Such drivers can announce the commonly supported XR24 format 
> > > > > > > to userspace
> > > > > > > + * and use this function to convert to the native format.
> > > > > > > + *
> > > > > > > + * Monochrome drivers will use the most significant bit,
> > > > > > > + * where 1 means foreground color and 0 background color.
> > > > > > > + *
> > > > > > > + * ITU BT.601 is used for the RGB -> luma (brightness) 
> > > > > > > conversion.
> > > > > > > + *
> > > > > > > + * Returns:
> > > > > > > + * Zero on success, negative error code on failure.
> > > > > > > + */
> > > > > > > +int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer 
> > > > > > > *fb)
> > > > > > I think it's ok to use this for backwards compat reasons with 
> > > > > > userspace
> > > > > > that simply expects xrgb, but adding monochrome fourcc codes to 
> > > > > > drm
> > > > > > isn't hard, and I think would be better to do that here.
> > > > > > 
> > > > > > There's also my comment from earlier that too much of tinydrm is in
> > > > > > tinydrm, and maybe we should move some of it out (we already have
> > > > > > tinydrm_xrgb_to_rgb565). But looks ok otherwise.
> > > > > I'm not sure that tinydrm_xrgb_to_rgb565 and 
> > > > > tinydrm_xrgb_to_gray8
> > > > > does fit in the core as-is, because they work around the fact that
> > > > > cma memory has uncached reads by buffering one pixel line at a time.
> > > > > 
> > > > > I have been aware that the cma library isn't really a prefect match 
> > > > > for
> > > > > tinydrm because of this (but it was easy to use). For tiny displays 
> > > > > this
> > > > > isn't really a performance problem to speak of, but I see now that it
> > > > > limits which gpus that I can import buffers from, since cma requires
> > > > > continous memory. This is probably the reason the Grain Media driver
> > > > > couldn't use tinydrm or that it needed that shmem thing.
> > > > Hm, might be good to port tinydrm to plain gem shmem objects? We have a
> > > > bunch of gem shmem based simple drivers know, so if helpers aren't as
> > > > comprehensive as with cma that can be fixed (and I'm trying other driver
> > > > submitters to volunteer for that already).
> > > > 
> > > > > I'll see if I can use gem/prime code from vgem coupled with prime 
> > > > > import
> > > > > code from udl. The spi core claims to do dma transfers on vmalloc
> > > > > addreses, so it seems possible.
> > > > Still feeling guilty for volunteering you for everything, but would be
> > > > awesome if you can make it happen. I think there's other drivers 
> > > > in-flight
> > > > (or even merged) which could benefit from parts