Re: [PATCH 7/7] drm/ttm: enable swapout of per VM BOs during allocation and allows reaping of deleted BOs

[Thomas Hellstrom]

What about

"Enable recursive locking at swapout time to make it possible to swap 
out BOs that share the same reservation object."


Is "per VM BOs" an AMD specific name?  In that case, I'd avoid using it 
in the TTM code since most people have no idea what they are and why the 
need specific treatment in TTM.


/Thomas


On 12/20/2017 11:35 AM, Roger He wrote:

Change-Id: I1e87954564f38ad298bf6e4ff88c9f26f291a62d
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 15 +++
  drivers/gpu/drm/ttm/ttm_memory.c | 12 
  include/drm/ttm/ttm_bo_api.h |  3 ++-
  3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 313925c..ecb8916 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1686,18 +1686,20 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
   * A buffer object shrink method that tries to swap out the first
   * buffer object on the bo_global::swap_lru list.
   */
-int ttm_bo_swapout(struct ttm_bo_global *glob)
+int ttm_bo_swapout(struct ttm_bo_global *glob, struct ttm_operation_ctx *ctx)
  {
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+   bool locked;
unsigned i;
  
  	spin_lock(>lru_lock);

for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >swap_lru[i], swap) {
-   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
-   if (!ret)
+   if (ttm_bo_evict_swapout_allowable(bo, ctx, )) {
+   ret = 0;
break;
+   }
}
if (!ret)
break;
@@ -1773,7 +1775,12 @@ EXPORT_SYMBOL(ttm_bo_swapout);
  
  void ttm_bo_swapout_all(struct ttm_bo_device *bdev)

  {
-   while (ttm_bo_swapout(bdev->glob) == 0)
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
+
+   while (ttm_bo_swapout(bdev->glob, ) == 0)
;
  }
  EXPORT_SYMBOL(ttm_bo_swapout_all);
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 8df0755..8817b86 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -211,7 +211,7 @@ static bool ttm_zones_above_swap_target(struct 
ttm_mem_global *glob,
   */
  
  static void ttm_shrink(struct ttm_mem_global *glob, bool from_wq,

-  uint64_t extra)
+   uint64_t extra, struct ttm_operation_ctx *ctx)
  {
int ret;
  
@@ -219,7 +219,7 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool from_wq,
  
  	while (ttm_zones_above_swap_target(glob, from_wq, extra)) {

spin_unlock(>lock);
-   ret = ttm_bo_swapout(glob->bo_glob);
+   ret = ttm_bo_swapout(glob->bo_glob, ctx);
spin_lock(>lock);
if (unlikely(ret != 0))
break;
@@ -230,10 +230,14 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool 
from_wq,
  
  static void ttm_shrink_work(struct work_struct *work)

  {
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
struct ttm_mem_global *glob =
container_of(work, struct ttm_mem_global, work);
  
-	ttm_shrink(glob, true, 0ULL);

+   ttm_shrink(glob, true, 0ULL, );
  }
  
  static int ttm_mem_init_kernel_zone(struct ttm_mem_global *glob,

@@ -520,7 +524,7 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global 
*glob,
return -ENOMEM;
if (unlikely(count-- == 0))
return -ENOMEM;
-   ttm_shrink(glob, false, memory + (memory >> 2) + 16);
+   ttm_shrink(glob, false, memory + (memory >> 2) + 16, ctx);
}
  
  	return 0;

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 24a8db7..f1c74c2 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -752,7 +752,8 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file 
*filp,
  const char __user *wbuf, char __user *rbuf,
  size_t count, loff_t *f_pos, bool write);
  
-int ttm_bo_swapout(struct ttm_bo_global *glob);

+int ttm_bo_swapout(struct ttm_bo_global *glob,
+   struct ttm_operation_ctx *ctx);
  void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
  int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
  #endif



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

Re: [Intel-gfx] [PATCH] drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

[Chris Wilson]

Quoting Dave Airlie (2017-12-21 02:42:56)
> > @@ -494,12 +473,11 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
> > *file_private,
> > spin_unlock(_private->syncobj_table_lock);
> > idr_preload_end();
> >
> > -   if (ret < 0) {
> > -   fput(syncobj->file);
> > -   return ret;
> > -   }
> > -   *handle = ret;
> > -   return 0;
> > +   if (ret > 0)
> > +   *handle = ret;
> > +
> > +   fput(file);
> > +   return ret;
> >  }
> 
> This chunk breaks stuff, since it now returns the handle in ret if >
> 0, whereas before
> it returned 0.

So much for trying to squeeze it into single point of return.
Do we prefer return ret; or ret = 0 ?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] drm/ttm: add ttm_bo_evict_swapout_allowable to check bo is allowable to evict or swapout

[Thomas Hellstrom]

On 12/20/2017 11:35 AM, Roger He wrote:

extract this function since eviction and swapout share same logic


But it's only used in eviction?



Change-Id: I80a475a93fceed8d66d74a1832c815a0756341ac
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 29 +++--
  1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e7595b4..313925c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -706,6 +706,23 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
  }
  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
  
+static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,

+   struct ttm_operation_ctx *ctx, bool *locked)


Could we have a description in the code what this function actually 
does? admittedly

it checks whether a swapout or eviction is allowable, but it aso performs a
recursive tryreserve(), and that is of value to any future code reader.?

/Thomas



+{
+   bool ret = false;
+
+   *locked = false;
+   if (bo->resv == ctx->resv) {
+   if (ctx->allow_reserved_eviction || !list_empty(>ddestroy))
+   ret = true;
+   } else {
+   *locked = reservation_object_trylock(bo->resv);
+   ret = *locked;
+   }
+
+   return ret;
+}
+
  static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
   uint32_t mem_type,
   const struct ttm_place *place,
@@ -721,21 +738,13 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
-   if (bo->resv == ctx->resv) {
-   if (!ctx->allow_reserved_eviction &&
-   list_empty(>ddestroy))
-   continue;
-   } else {
-   locked = reservation_object_trylock(bo->resv);
-   if (!locked)
-   continue;
-   }
+   if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+   continue;
  
  			if (place && !bdev->driver->eviction_valuable(bo,

  place)) {
if (locked)
reservation_object_unlock(bo->resv);
-   locked = false;
continue;
}
break;



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

Re: [PATCH 1/7] drm/ttm: call ttm_bo_swapout directly when ttm shrink

[Thomas Hellstrom]

Roger,

5 out of 7 patches in this series are completely lacking a commit log 
message, and thats not OK. Really.


https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html#describe-your-changes

I'll review these, but IIRC the no_wait in the memory accounting code is 
different in that it doesn't allow sleeping,
whereas in the bo code we had originally had no_wait_gpu and also 
no_wait. (IIRC Maarten or Jerome removed the latter due to lack of 
users.) Seems like these patches confuse the to. At the very least that 
requires some form of motivation.


Also I wonder what testing is being performed on these changes prior to 
submission?
We have pretty high number of critical deployments out there, that we 
need to support.


/Thomas


On 12/20/2017 11:34 AM, Roger He wrote:

then remove superfluous functions

Change-Id: Iea020f0e30a239e0265e7a1500168c7d7f819bd9
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 21 +++-
  drivers/gpu/drm/ttm/ttm_memory.c | 12 ++-
  include/drm/ttm/ttm_bo_api.h |  1 +
  include/drm/ttm/ttm_bo_driver.h  |  1 -
  include/drm/ttm/ttm_memory.h | 69 +---
  5 files changed, 9 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 60bb5c1..fa57aa8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -42,7 +42,6 @@
  #include 
  #include 
  
-static int ttm_bo_swapout(struct ttm_mem_shrink *shrink);

  static void ttm_bo_global_kobj_release(struct kobject *kobj);
  
  static struct attribute ttm_bo_count = {

@@ -1454,7 +1453,6 @@ static void ttm_bo_global_kobj_release(struct kobject 
*kobj)
struct ttm_bo_global *glob =
container_of(kobj, struct ttm_bo_global, kobj);
  
-	ttm_mem_unregister_shrink(glob->mem_glob, >shrink);

__free_page(glob->dummy_read_page);
kfree(glob);
  }
@@ -1479,6 +1477,7 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
mutex_init(>device_list_mutex);
spin_lock_init(>lru_lock);
glob->mem_glob = bo_ref->mem_glob;
+   glob->mem_glob->bo_glob = glob;
glob->dummy_read_page = alloc_page(__GFP_ZERO | GFP_DMA32);
  
  	if (unlikely(glob->dummy_read_page == NULL)) {

@@ -1489,14 +1488,6 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
INIT_LIST_HEAD(>swap_lru[i]);
INIT_LIST_HEAD(>device_list);
-
-   ttm_mem_init_shrink(>shrink, ttm_bo_swapout);
-   ret = ttm_mem_register_shrink(glob->mem_glob, >shrink);
-   if (unlikely(ret != 0)) {
-   pr_err("Could not register buffer object swapout\n");
-   goto out_no_shrink;
-   }
-
atomic_set(>bo_count, 0);
  
  	ret = kobject_init_and_add(

@@ -1504,8 +1495,6 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
if (unlikely(ret != 0))
kobject_put(>kobj);
return ret;
-out_no_shrink:
-   __free_page(glob->dummy_read_page);
  out_no_drp:
kfree(glob);
return ret;
@@ -1688,11 +1677,8 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
   * A buffer object shrink method that tries to swap out the first
   * buffer object on the bo_global::swap_lru list.
   */
-
-static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
+int ttm_bo_swapout(struct ttm_bo_global *glob)
  {
-   struct ttm_bo_global *glob =
-   container_of(shrink, struct ttm_bo_global, shrink);
struct ttm_buffer_object *bo;
int ret = -EBUSY;
unsigned i;
@@ -1774,10 +1760,11 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
kref_put(>list_kref, ttm_bo_release_list);
return ret;
  }
+EXPORT_SYMBOL(ttm_bo_swapout);
  
  void ttm_bo_swapout_all(struct ttm_bo_device *bdev)

  {
-   while (ttm_bo_swapout(>glob->shrink) == 0)
+   while (ttm_bo_swapout(bdev->glob) == 0)
;
  }
  EXPORT_SYMBOL(ttm_bo_swapout_all);
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index e963749..9130bdf 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -214,26 +214,20 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool 
from_wq,
   uint64_t extra)
  {
int ret;
-   struct ttm_mem_shrink *shrink;
  
  	spin_lock(>lock);

-   if (glob->shrink == NULL)
-   goto out;
  
  	while (ttm_zones_above_swap_target(glob, from_wq, extra)) {

-   shrink = glob->shrink;
spin_unlock(>lock);
-   ret = shrink->do_shrink(shrink);
+   ret = ttm_bo_swapout(glob->bo_glob);
spin_lock(>lock);
if (unlikely(ret != 0))
-   goto out;
+   break;
}
-out:
+
spin_unlock(>lock);
  }
  
-

-
  static void ttm_shrink_work(struct 

[Bug 198221] nouveau DRM driver scheduling invalid work

[bugzilla-daemon]

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

--- Comment #3 from Petr Vandrovec (p...@vandrovec.name) ---
Created attachment 261285
  --> https://bugzilla.kernel.org/attachment.cgi?id=261285=edit
Bandaid to prevent processing of works not fully set up

I've attached bandaid that seems to fix crash on my system.

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

[PATCH] drm: move lease init after validation in drm_lease_create

[Keith Packard]

Patch bd36d3bab2e3d08f80766c86487090dbceed4651 fixed a deadlock in the
failure path of drm_lease_create. This made the partially initialized
lease object visible for a short window of time.

To avoid having the lessee state appear transiently, I've rearranged
the code so that the lessor fields are not filled in until the
parameters are all validated and the function will succeed.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_lease.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 59849f02e2ad..1402c0e71b03 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -220,17 +220,6 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
 
mutex_lock(>mode_config.idr_mutex);
 
-   /* Insert the new lessee into the tree */
-   id = idr_alloc(&(drm_lease_owner(lessor)->lessee_idr), lessee, 1, 0, 
GFP_KERNEL);
-   if (id < 0) {
-   error = id;
-   goto out_lessee;
-   }
-
-   lessee->lessee_id = id;
-   lessee->lessor = drm_master_get(lessor);
-   list_add_tail(>lessee_list, >lessees);
-
idr_for_each_entry(leases, entry, object) {
error = 0;
if (!idr_find(>mode_config.crtc_idr, object))
@@ -246,6 +235,17 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
}
}
 
+   /* Insert the new lessee into the tree */
+   id = idr_alloc(&(drm_lease_owner(lessor)->lessee_idr), lessee, 1, 0, 
GFP_KERNEL);
+   if (id < 0) {
+   error = id;
+   goto out_lessee;
+   }
+
+   lessee->lessee_id = id;
+   lessee->lessor = drm_master_get(lessor);
+   list_add_tail(>lessee_list, >lessees);
+
/* Move the leases over */
lessee->leases = *leases;
DRM_DEBUG_LEASE("new lessee %d %p, lessor %d %p\n", lessee->lessee_id, 
lessee, lessor->lessee_id, lessor);
-- 
2.15.1

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

Re: [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Jani Nikula]

On Wed, 20 Dec 2017, Dhinakaran Pandiyan  wrote:
> Occasionally there are LINK_ADDRESS sideband messages timing out with the
> Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> failures lead to the display not coming up on boot. Power cycling the port
> corresponding to the MST monitor's branch device and resending the message
> fixes the issue. I am not entirely sure if this is specific to my setup.
> However, as the power state is toggled conditionally on LINK_ADDRESS
> timeouts, this should not affect the working cases.

With stuff like this, I always wonder if catering for a failing setup
blocks us from improving working setups, because once we add this, we
can't regress it. For example, is there a valid scenario where we'd want
to fail fast here, instead of retrying?

Some nits below.

> Cc: Lyude 
> Cc: Dave Airlie 
> Cc: Jani Nikula 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa58d3c2..e06defcdcf18 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
>   int len;
>   struct drm_dp_sideband_msg_tx *txmsg;
>   int ret;
> + int attempts = 5;
>  
> - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
>   if (!txmsg)
>   return;
>  
> @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
>   }
>   (*mgr->cbs->hotplug)(mgr);
>   }
> + } else if (attempts--) {

You'll end up doing (attempts + 1) attempts, including the first one.

> + kfree(txmsg);

How about memset(txmsg, 0, sizoef(*txmsg)); here and move the goto label
down to avoid repeated allocations?

> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  false);
> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  true);
> + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);

Maybe do the debug message before you power down/up?

BR,
Jani.

> + goto retry;
>   } else {
>   mstb->link_address_sent = false;
> - DRM_DEBUG_KMS("link address failed %d\n", ret);
> + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
>   }
>  
>   kfree(txmsg);

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Dhinakaran Pandiyan]

Occasionally there are LINK_ADDRESS sideband messages timing out with the
Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
failures lead to the display not coming up on boot. Power cycling the port
corresponding to the MST monitor's branch device and resending the message
fixes the issue. I am not entirely sure if this is specific to my setup.
However, as the power state is toggled conditionally on LINK_ADDRESS
timeouts, this should not affect the working cases.

Cc: Lyude 
Cc: Dave Airlie 
Cc: Jani Nikula 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70dcfa58d3c2..e06defcdcf18 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct 
drm_dp_mst_topology_mgr *mgr,
int len;
struct drm_dp_sideband_msg_tx *txmsg;
int ret;
+   int attempts = 5;
 
-   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
+retry: txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
if (!txmsg)
return;
 
@@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct 
drm_dp_mst_topology_mgr *mgr,
}
(*mgr->cbs->hotplug)(mgr);
}
+   } else if (attempts--) {
+   kfree(txmsg);
+   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
+false);
+   drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
+true);
+   DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
+   goto retry;
} else {
mstb->link_address_sent = false;
-   DRM_DEBUG_KMS("link address failed %d\n", ret);
+   DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
}
 
kfree(txmsg);
-- 
2.11.0

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

[PATCH i-g-t 1/2] tests/kms_sequence: Add tests for new CRTC get/queue sequence ioctls [v2]

[Keith Packard]

These ioctls replace drmWaitVBlank and add ns time resolution and
64-bit sequence numbers to comply with the Vulkan API specifications.

The tests were derived from the existing kms_vblank tests with the
'wait' variant elided as the new API doesn't provide a mechanism for
blocking in the kernel.

v2: from Dave Airlie 

 * Add local definitions of new ioctls to avoid requiring latest
   libdrm.

 * Remove FIRST_PIXEL_OUT as that has been removed from the proposed
   kernel patches.

Signed-off-by: Keith Packard 
---
 lib/igt_kms.c  |   2 +-
 lib/igt_kms.h  |   1 +
 tests/Makefile.sources |   1 +
 tests/kms_sequence.c   | 317 +
 tests/meson.build  |   1 +
 5 files changed, 321 insertions(+), 1 deletion(-)
 create mode 100644 tests/kms_sequence.c

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 1242324e..f6ad3565 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2079,7 +2079,7 @@ report_dup:
}
 }
 
-static igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output)
+igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output)
 {
igt_display_t *display = output->display;
enum pipe pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index cfe646ae..8f270bfd 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -377,6 +377,7 @@ igt_plane_t *igt_output_get_plane(igt_output_t *output, int 
plane_idx);
 igt_plane_t *igt_output_get_plane_type(igt_output_t *output, int plane_type);
 igt_output_t *igt_output_from_connector(igt_display_t *display,
 drmModeConnector *connector);
+igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output);
 igt_plane_t *igt_pipe_get_plane_type(igt_pipe_t *pipe, int plane_type);
 
 void igt_pipe_request_out_fence(igt_pipe_t *pipe);
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index e4e06d01..485ed429 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -211,6 +211,7 @@ TESTS_progs = \
kms_tv_load_detect \
kms_universal_plane \
kms_vblank \
+   kms_sequence \
meta_test \
perf \
perf_pmu \
diff --git a/tests/kms_sequence.c b/tests/kms_sequence.c
new file mode 100644
index ..783dda25
--- /dev/null
+++ b/tests/kms_sequence.c
@@ -0,0 +1,317 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ * Copyright © 2017 Keith Packard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/** @file kms_sequence.c
+ *
+ * This is a test of drmCrtcGetSequence and drmCrtcQueueSequence
+ */
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "intel_bufmgr.h"
+
+IGT_TEST_DESCRIPTION("Test CrtcGetSequence and CrtcQueueSequence.");
+
+typedef struct {
+   igt_display_t display;
+   struct igt_fb primary_fb;
+   igt_output_t *output;
+   uint32_t crtc_id;
+   enum pipe pipe;
+   unsigned int flags;
+#define IDLE 1
+#define BUSY 2
+#define FORKED 4
+} data_t;
+
+struct local_drm_crtc_get_sequence {
+   __u32 crtc_id;
+   __u32 active;
+   __u64 sequence;
+   __u64 sequence_ns;
+};
+
+struct local_drm_crtc_queue_sequence {
+   __u32 crtc_id;
+   __u32 flags;
+   __u64 sequence;
+   __u64 user_data;
+};
+
+#define LOCAL_DRM_IOCTL_CRTC_GET_SEQUENCE DRM_IOWR(0x3b, struct 
local_drm_crtc_get_sequence)
+#define LOCAL_DRM_IOCTL_CRTC_QUEUE_SEQUENCE   DRM_IOWR(0x3c, struct 
local_drm_crtc_queue_sequence)
+
+#define LOCAL_DRM_CRTC_SEQUENCE_RELATIVE  0x0001  /* 
sequence is relative to current */
+#define LOCAL_DRM_CRTC_SEQUENCE_NEXT_ON_MISS  0x0002  /* Use 
next sequence if we've missed */
+
+struct local_drm_event_crtc_sequence {
+struct drm_eventbase;
+__u64   user_data;
+__s64   

[PATCH i-g-t 0/2] tests: Add tests for new sequence API and leases

[Keith Packard]

Both of these APIs are now in the kernel; it would be nice to have the
tests integrated into the test suite.

This includes an updated version of the kms_lease patch (v3) which
adapts to the final kernel API changes.

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

[PATCH i-g-t 2/2] tests/kms_lease: add tests for lease ioctls [v3]

[Keith Packard]

Validate that the leasing API creates leases that allow access to a
subset of the available resources and that lease revocation works.

v2: from Dave Airlie 

 * Update ioctl numbers to latest proposed values.
 * Fix commit message
 * Add tests for get_lease and list_lessees

v3: adapt to final kernel API

* Disable CAP_UNIVERSAL_PLANES before leasing so that we don't need to
  also include a plane.

* Zero out all of the ioctl structures so that any padding fields are
  set correctly.

* When listing a lease, expect 3 resources -- crtc, connector and plane.

Signed-off-by: Keith Packard 
---
 tests/Makefile.sources |   1 +
 tests/kms_lease.c  | 606 +
 tests/meson.build  |   1 +
 3 files changed, 608 insertions(+)
 create mode 100644 tests/kms_lease.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 485ed429..2bef7d68 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -189,6 +189,7 @@ TESTS_progs = \
kms_frontbuffer_tracking \
kms_hdmi_inject \
kms_invalid_dotclock \
+   kms_lease \
kms_legacy_colorkey \
kms_mmap_write_crc \
kms_mmio_vs_cs_flip \
diff --git a/tests/kms_lease.c b/tests/kms_lease.c
new file mode 100644
index ..2a6d82fb
--- /dev/null
+++ b/tests/kms_lease.c
@@ -0,0 +1,606 @@
+/*
+ * Copyright © 2017 Keith Packard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/** @file kms_lease.c
+ *
+ * This is a test of DRM leases
+ */
+
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+IGT_TEST_DESCRIPTION("Test of CreateLease.");
+
+struct local_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;
+};
+
+struct local_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;
+__u32 pad;
+
+/** Pointer to lessees.
+ * pointer to __u64 array of lessee ids
+ */
+__u64 lessees_ptr;
+};
+
+struct local_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;
+__u32 pad;
+
+/** Pointer to objects.
+ * pointer to __u32 array of object ids
+ */
+__u64 objects_ptr;
+};
+
+/**
+ * Revoke lease
+ */
+struct local_drm_mode_revoke_lease {
+/** Unique ID of lessee
+ */
+__u32 lessee_id;
+};
+
+
+#define LOCAL_DRM_IOCTL_MODE_CREATE_LEASE DRM_IOWR(0xC6, struct 
local_drm_mode_create_lease)
+#define LOCAL_DRM_IOCTL_MODE_LIST_LESSEES DRM_IOWR(0xC7, struct 
local_drm_mode_list_lessees)
+#define LOCAL_DRM_IOCTL_MODE_GET_LEASEDRM_IOWR(0xC8, struct 
local_drm_mode_get_lease)
+#define LOCAL_DRM_IOCTL_MODE_REVOKE_LEASE DRM_IOWR(0xC9, struct 
local_drm_mode_revoke_lease)
+
+typedef struct {
+   int fd;
+   uint32_t lessee_id;
+   igt_display_t display;
+   struct igt_fb primary_fb;
+   igt_output_t *output;
+   

[RFC 3/3] drm/msm: Don't subclass drm_atomic_state anymore

[Archit Taneja]

With the addition of "private_objs" in drm_atomic_state, we no longer
need to subclass drm_atomic_state to store state of share resources
that don't perfectly fit within planes/crtc/connector state information.
We can now save this state within drm_atomic_state itself using
the private objects.

Remove the infrastructure that allowed subclassing of drm_atomic_state
in the driver.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 46 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 22 
 drivers/gpu/drm/msm/msm_atomic.c| 31 --
 drivers/gpu/drm/msm/msm_drv.c   |  3 ---
 drivers/gpu/drm/msm/msm_kms.h   | 14 --
 5 files changed, 116 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index dabb58ad068c..c42a77713d74 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -70,42 +70,6 @@ static int mdp5_hw_init(struct msm_kms *kms)
return 0;
 }
 
-struct mdp5_state *mdp5_get_state(struct drm_atomic_state *s)
-{
-   struct msm_drm_private *priv = s->dev->dev_private;
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct msm_kms_state *state = to_kms_state(s);
-   struct mdp5_state *new_state;
-   int ret;
-
-   if (state->state)
-   return state->state;
-
-   ret = drm_modeset_lock(_kms->state_lock, s->acquire_ctx);
-   if (ret)
-   return ERR_PTR(ret);
-
-   new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
-   if (!new_state)
-   return ERR_PTR(-ENOMEM);
-
-   /* Copy state: */
-   new_state->hwpipe = mdp5_kms->state->hwpipe;
-   new_state->hwmixer = mdp5_kms->state->hwmixer;
-   if (mdp5_kms->smp)
-   new_state->smp = mdp5_kms->state->smp;
-
-   state->state = new_state;
-
-   return new_state;
-}
-
-static void mdp5_swap_state(struct msm_kms *kms, struct drm_atomic_state 
*state)
-{
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   swap(to_kms_state(state)->state, mdp5_kms->state);
-}
-
 /* Global/shared object state funcs */
 
 /*
@@ -315,7 +279,6 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank   = mdp5_enable_vblank,
.disable_vblank  = mdp5_disable_vblank,
-   .swap_state  = mdp5_swap_state,
.prepare_commit  = mdp5_prepare_commit,
.complete_commit = mdp5_complete_commit,
.wait_for_crtc_commit_done = mdp5_wait_for_crtc_commit_done,
@@ -814,8 +777,6 @@ static void mdp5_destroy(struct platform_device *pdev)
pm_runtime_disable(>dev);
 
drm_atomic_private_obj_fini(_kms->glob_base);
-
-   kfree(mdp5_kms->state);
 }
 
 static int construct_pipes(struct mdp5_kms *mdp5_kms, int cnt,
@@ -968,13 +929,6 @@ static int mdp5_init(struct platform_device *pdev, struct 
drm_device *dev)
mdp5_kms->dev = dev;
mdp5_kms->pdev = pdev;
 
-   drm_modeset_lock_init(_kms->state_lock);
-   mdp5_kms->state = kzalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
-   if (!mdp5_kms->state) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
ret = mdp5_global_obj_init(mdp5_kms);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 522ddb835593..6b9a7d091606 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -28,8 +28,6 @@
 #include "mdp5_ctl.h"
 #include "mdp5_smp.h"
 
-struct mdp5_state;
-
 struct mdp5_kms {
struct mdp_kms base;
 
@@ -49,12 +47,6 @@ struct mdp5_kms {
struct mdp5_cfg_handler *cfg;
uint32_t caps;  /* MDP capabilities (MDP_CAP_XXX bits) */
 
-   /**
-* Global atomic state.  Do not access directly, use mdp5_get_state()
-*/
-   struct mdp5_state *state;
-   struct drm_modeset_lock state_lock;
-
/*
 * Global private object state, Do not access directly, use
 * mdp5_global_get_state()
@@ -88,20 +80,6 @@ struct mdp5_kms {
 };
 #define to_mdp5_kms(x) container_of(x, struct mdp5_kms, base)
 
-/* Global atomic state for tracking resources that are shared across
- * multiple kms objects (planes/crtcs/etc).
- *
- * For atomic updates which require modifying global state,
- */
-struct mdp5_state {
-   struct mdp5_hw_pipe_state hwpipe;
-   struct mdp5_hw_mixer_state hwmixer;
-   struct mdp5_smp_state smp;
-};
-
-struct mdp5_state *__must_check
-mdp5_get_state(struct drm_atomic_state *s);
-
 /* Global private object state for tracking resources that are shared across
  * multiple kms objects (planes/crtcs/etc).
  */
diff --git 

[RFC 0/3] drm/msm: Avoid subclassing of drm_atomic_state

[Archit Taneja]

It's been recommended that we use drm_private_objs embedded in
drm_atomic_state to hold shared resources instead of subclassing
drm_atomic_state.

This will also help us in getting one step closer to using the
atomic commit helpers instead of the msm_atomic_commit() funcs
in msm_atomic.c

I've taken the drm_private_obj usage in drm_dp_mst_topology as
reference. I've put this as RFC because I want others to see if
the private_obj stuff is used correctly.

Archit Taneja (3):
  drm/msm/mdp5: Add global state as a private atomic object
  drm/msm/mdp5: Use the new private_obj state
  drm/msm: Don't subclass drm_atomic_state anymore

 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 104 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  29 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c |  12 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c  |  20 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c   |  17 +++--
 drivers/gpu/drm/msm/msm_atomic.c  |  31 -
 drivers/gpu/drm/msm/msm_drv.c |   3 -
 drivers/gpu/drm/msm/msm_kms.h |  14 
 8 files changed, 121 insertions(+), 109 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[RFC 1/3] drm/msm/mdp5: Add global state as a private atomic object

[Archit Taneja]

Global shared resources (hwpipes, hwmixers and SMP) for MDP5 are
implemented as a part of atomic state by subclassing drm_atomic_state.

The preferred approach is to use the drm_private_obj infrastructure
available in the atomic core.

mdp5_global_state is introduced as a drm atomic private object. The two
funcs mdp5_get_global_state() and mdp5_get_existing_global_state() are
the two variants that will be used to access mdp5_global_state.

This will replace the existing mdp5_state struct (which subclasses
drm_atomic_state) and the funcs around it. These will be removed later
once we mdp5_global_state is put to use everywhere.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 86 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 27 +++
 2 files changed, 113 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index f7c0698fec40..dfc4d81124d5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -106,6 +106,86 @@ static void mdp5_swap_state(struct msm_kms *kms, struct 
drm_atomic_state *state)
swap(to_kms_state(state)->state, mdp5_kms->state);
 }
 
+/* Global/shared object state funcs */
+
+/*
+ * This is a helper that returns the private state currently in operation.
+ * Note that this would return the "old_state" if called in the atomic check
+ * path, and the "new_state" after the atomic swap has been done.
+ */
+struct mdp5_global_state *
+mdp5_get_existing_global_state(struct mdp5_kms *mdp5_kms)
+{
+   return to_mdp5_global_state(mdp5_kms->glob_base.state);
+}
+
+/*
+ * This acquires the modeset lock set aside for global state, creates
+ * a new duplicated private object state.
+ */
+struct mdp5_global_state *mdp5_get_global_state(struct drm_atomic_state *s)
+{
+   struct msm_drm_private *priv = s->dev->dev_private;
+   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
+   struct drm_private_state *priv_state;
+   int ret;
+
+   ret = drm_modeset_lock(_kms->glob_state_lock, s->acquire_ctx);
+   if (ret)
+   return ERR_PTR(ret);
+
+   priv_state = drm_atomic_get_private_obj_state(s, _kms->glob_base);
+   if (IS_ERR(priv_state))
+   return ERR_CAST(priv_state);
+
+   return to_mdp5_global_state(priv_state);
+}
+
+static struct drm_private_state *
+mdp5_global_duplicate_state(struct drm_private_obj *obj)
+{
+   struct mdp5_global_state *state;
+
+   state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return NULL;
+
+   __drm_atomic_helper_private_obj_duplicate_state(obj, >base);
+
+   return >base;
+}
+
+static void mdp5_global_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+   struct mdp5_global_state *mdp5_state = to_mdp5_global_state(state);
+
+   kfree(mdp5_state);
+}
+
+static const struct drm_private_state_funcs mdp5_global_state_funcs = {
+   .atomic_duplicate_state = mdp5_global_duplicate_state,
+   .atomic_destroy_state = mdp5_global_destroy_state,
+};
+
+static int mdp5_global_obj_init(struct mdp5_kms *mdp5_kms)
+{
+   struct mdp5_global_state *state;
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return -ENOMEM;
+
+   drm_modeset_lock_init(_kms->glob_state_lock);
+
+   state->mdp5_kms = mdp5_kms;
+
+   drm_atomic_private_obj_init(_kms->glob_base,
+   >base,
+   _global_state_funcs);
+   return 0;
+}
+
 static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state 
*state)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
@@ -727,6 +807,8 @@ static void mdp5_destroy(struct platform_device *pdev)
if (mdp5_kms->rpm_enabled)
pm_runtime_disable(>dev);
 
+   drm_atomic_private_obj_fini(_kms->glob_base);
+
kfree(mdp5_kms->state);
 }
 
@@ -887,6 +969,10 @@ static int mdp5_init(struct platform_device *pdev, struct 
drm_device *dev)
goto fail;
}
 
+   ret = mdp5_global_obj_init(mdp5_kms);
+   if (ret)
+   goto fail;
+
mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys", "MDP5");
if (IS_ERR(mdp5_kms->mmio)) {
ret = PTR_ERR(mdp5_kms->mmio);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 9b3fe01089d1..522ddb835593 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -55,6 +55,13 @@ struct mdp5_kms {
struct mdp5_state *state;
struct drm_modeset_lock state_lock;
 
+   /*
+* Global private object state, Do not access directly, use
+* mdp5_global_get_state()
+*/
+   struct 

[RFC 2/3] drm/msm/mdp5: Use the new private_obj state

[Archit Taneja]

This replaces the usage of the subclassed atomic state (mdp5_state)
with a private_obj state embedded within drm_atomic_state. The latter
method is the preferred approach, since it's simpler to implement
and less prone to errors.

The new API replaces the older and equivalent mdp5_state usage in the
following pattern:
- References to "mdp5_kms->state" (i.e, the old/existing state) is
  replaced with mdp5_get_existing_global_state(). In the atomic_check
  path, this should be called with the glob_state_lock drm_modeset_lock
  alredy taken.
- References to "mdp5_get_state()" are replaced with
  mdp5_get_global_state(). This acquires glob_state_lock and uses
  drm_atomic_get_private_obj_state() to create a new duplicated state.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 10 --
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c | 12 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c  | 20 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c   | 17 -
 4 files changed, 37 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index dfc4d81124d5..dabb58ad068c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -190,20 +190,26 @@ static void mdp5_prepare_commit(struct msm_kms *kms, 
struct drm_atomic_state *st
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct device *dev = _kms->pdev->dev;
+   struct mdp5_global_state *global_state;
+
+   global_state = mdp5_get_existing_global_state(mdp5_kms);
 
pm_runtime_get_sync(dev);
 
if (mdp5_kms->smp)
-   mdp5_smp_prepare_commit(mdp5_kms->smp, _kms->state->smp);
+   mdp5_smp_prepare_commit(mdp5_kms->smp, _state->smp);
 }
 
 static void mdp5_complete_commit(struct msm_kms *kms, struct drm_atomic_state 
*state)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct device *dev = _kms->pdev->dev;
+   struct mdp5_global_state *global_state;
+
+   global_state = mdp5_get_existing_global_state(mdp5_kms);
 
if (mdp5_kms->smp)
-   mdp5_smp_complete_commit(mdp5_kms->smp, _kms->state->smp);
+   mdp5_smp_complete_commit(mdp5_kms->smp, _state->smp);
 
pm_runtime_put_autosuspend(dev);
 }
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c
index 8a00991f03c7..113e6b569562 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c
@@ -52,14 +52,14 @@ int mdp5_mixer_assign(struct drm_atomic_state *s, struct 
drm_crtc *crtc,
 {
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct mdp5_state *state = mdp5_get_state(s);
+   struct mdp5_global_state *global_state = mdp5_get_global_state(s);
struct mdp5_hw_mixer_state *new_state;
int i;
 
-   if (IS_ERR(state))
-   return PTR_ERR(state);
+   if (IS_ERR(global_state))
+   return PTR_ERR(global_state);
 
-   new_state = >hwmixer;
+   new_state = _state->hwmixer;
 
for (i = 0; i < mdp5_kms->num_hwmixers; i++) {
struct mdp5_hw_mixer *cur = mdp5_kms->hwmixers[i];
@@ -129,8 +129,8 @@ int mdp5_mixer_assign(struct drm_atomic_state *s, struct 
drm_crtc *crtc,
 
 void mdp5_mixer_release(struct drm_atomic_state *s, struct mdp5_hw_mixer 
*mixer)
 {
-   struct mdp5_state *state = mdp5_get_state(s);
-   struct mdp5_hw_mixer_state *new_state = >hwmixer;
+   struct mdp5_global_state *global_state = mdp5_get_global_state(s);
+   struct mdp5_hw_mixer_state *new_state = _state->hwmixer;
 
if (!mixer)
return;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c
index 2bfac3712685..88a8a86c95c7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c
@@ -22,18 +22,20 @@ struct mdp5_hw_pipe *mdp5_pipe_assign(struct 
drm_atomic_state *s,
 {
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct mdp5_state *state;
+   struct mdp5_global_state *new_global_state, *old_global_state;
struct mdp5_hw_pipe_state *old_state, *new_state;
struct mdp5_hw_pipe *hwpipe = NULL;
int i;
 
-   state = mdp5_get_state(s);
-   if (IS_ERR(state))
-   return ERR_CAST(state);
+   new_global_state = mdp5_get_global_state(s);
+   if (IS_ERR(new_global_state))
+   return ERR_CAST(new_global_state);
 
-   /* grab old_state after mdp5_get_state(), since now we hold lock: */
-   old_state = _kms->state->hwpipe;
-   new_state = >hwpipe;
+   /* grab old_state after 

RE: [PATCH 3/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc_page

[He, Roger]

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Wednesday, December 20, 2017 9:36 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/7] drm/ttm: use an operation ctx for 
ttm_mem_global_alloc_page

Commit message!

Am 20.12.2017 um 11:34 schrieb Roger He:
> Change-Id: I4104a12e09a374b6477a0dd5a8fce26dce27a746
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_memory.c | 15 ---
>   drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 +-
>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  8 ++--
>   include/drm/ttm/ttm_memory.h |  3 ++-
>   4 files changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c 
> b/drivers/gpu/drm/ttm/ttm_memory.c
> index 525d3b6..8df0755 100644
> --- a/drivers/gpu/drm/ttm/ttm_memory.c
> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> @@ -539,15 +539,14 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob, 
> uint64_t memory,
>   EXPORT_SYMBOL(ttm_mem_global_alloc);
>   
>   int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
> -   struct page *page, uint64_t size)
> +   struct page *page, uint64_t size,
> +   struct ttm_operation_ctx *ctx)
>   {
> -
> + int ret;
>   struct ttm_mem_zone *zone = NULL;
> - struct ttm_operation_ctx ctx = {
> - .interruptible = false,
> - .no_wait_gpu = false
> - };
> + bool tmp_no_wait_gpu = ctx->no_wait_gpu;

Mhm, please drop that. That the function might wait for the GPU even 
when the caller requested not to do so sounds like a bug to me.

Yes. I will remove this. Later I will send new patches. Will appreciate If 
Thomas can help to verify that.

Thanks
Roger(Hongbo.He)  
>   
> + ctx->no_wait_gpu = false;
>   /**
>* Page allocations may be registed in a single zone
>* only if highmem or !dma32.
> @@ -560,7 +559,9 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
>   if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
>   zone = glob->zone_kernel;
>   #endif
> - return ttm_mem_global_alloc_zone(glob, zone, size, );
> + ret = ttm_mem_global_alloc_zone(glob, zone, size, ctx);
> + ctx->no_wait_gpu = tmp_no_wait_gpu;
> + return ret;
>   }
>   
>   void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct 
> page *page, diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index b5ba644..8f93ff3 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -1061,6 +1061,10 @@ void ttm_page_alloc_fini(void)
>   int ttm_pool_populate(struct ttm_tt *ttm)
>   {
>   struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
> + struct ttm_operation_ctx ctx = {
> + .interruptible = false,
> + .no_wait_gpu = false
> + };
>   unsigned i;
>   int ret;
>   
> @@ -1076,7 +1080,7 @@ int ttm_pool_populate(struct ttm_tt *ttm)
>   
>   for (i = 0; i < ttm->num_pages; ++i) {
>   ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
> - PAGE_SIZE);
> + PAGE_SIZE, );
>   if (unlikely(ret != 0)) {
>   ttm_pool_unpopulate(ttm);
>   return -ENOMEM;
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index bda00b2..8aac86a 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -927,6 +927,10 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev)
>   {
>   struct ttm_tt *ttm = _dma->ttm;
>   struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
> + struct ttm_operation_ctx ctx = {
> + .interruptible = false,
> + .no_wait_gpu = false
> + };
>   unsigned long num_pages = ttm->num_pages;
>   struct dma_pool *pool;
>   enum pool_type type;
> @@ -962,7 +966,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev)
>   break;
>   
>   ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
> - pool->size);
> + pool->size, );
>   if (unlikely(ret != 0)) {
>   ttm_dma_unpopulate(ttm_dma, dev);
>   return -ENOMEM;
> @@ -998,7 +1002,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev)
>   }
>   
>   ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
> - pool->size);
> + pool->size, );
> 

linux-next: Signed-off-by missing for commits in the drm tree

[Stephen Rothwell]

Hi all,

Commits

  bb5cdf8d1c76 ("drm: omapdrm: Remove filename from header and fix copyright 
tag")
  d66c36a3ee79 ("drm: omapdrm: Simplify platform registration")

are missing a Signed-off-by from their committer.

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

[Bug 198221] nouveau DRM driver scheduling invalid work

[bugzilla-daemon]

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

Petr Vandrovec (p...@vandrovec.name) changed:

   What|Removed |Added

 Regression|No  |Yes

--- Comment #2 from Petr Vandrovec (p...@vandrovec.name) ---
I've built kernel with the change and give it some time, but I don't think that
it is a culprit.

I think that there is a race in how nouveau handles scheduled work:

This work being scheduled has func callback set to
nouveau_gem_object_delete_work(), which does its job, and then frees the work.

Now nouveau_cli_work_queue sets some work properties, adds work to the
cli->worker queue, and schedules work->cli->work.

But nouveau_cli_work might run between the moment work is added to cli->worker
queue and moment schedule_work(>cli->work) is issued.

In that case work dereference in nouveau_cli_work_fence will access freed work
memory, read garbage (0x0001 in this case), add offsetof(cli, work) of
0x1f8, and pass this garbage pointer into schedule_work().

I'm not entirely sure what are expectations for the work, but perhaps work
should be added to the cli->worker list from nouveau_cli_work_fence, rather
than by nouveau_cli_work_queue. 

Regression seems to be introduced by 814a23243bd2aaa9aafe03d85d0502a73be42b58,
"drm/nouveau: implement per-client delayed workqueue with fence support"

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

Re: [Intel-gfx] [PATCH] drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

[Dave Airlie]

> @@ -494,12 +473,11 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
> *file_private,
> spin_unlock(_private->syncobj_table_lock);
> idr_preload_end();
>
> -   if (ret < 0) {
> -   fput(syncobj->file);
> -   return ret;
> -   }
> -   *handle = ret;
> -   return 0;
> +   if (ret > 0)
> +   *handle = ret;
> +
> +   fput(file);
> +   return ret;
>  }

This chunk breaks stuff, since it now returns the handle in ret if >
0, whereas before
it returned 0.

Otherwise the vulkan tests all pass on it.

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

[Bug 198221] nouveau DRM driver scheduling invalid work

[bugzilla-daemon]

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

Ilia Mirkin (imir...@alum.mit.edu) changed:

   What|Removed |Added

 CC||imir...@alum.mit.edu

--- Comment #1 from Ilia Mirkin (imir...@alum.mit.edu) ---
There's a pretty big memory leak in the GEM object handler right now, fixed by

https://github.com/skeggsb/linux/commit/4ef928929987c19fff4d3c1650f139560ba1cc13

Doesn't seem identical to your issue, but perhaps the leak triggers this as a
secondary issue.

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

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Ilia Mirkin]

On Wed, Dec 20, 2017 at 6:22 PM, Kristian Kristensen
 wrote:
> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico 
> wrote:
>> On Wed, 20 Dec 2017 11:54:10 -0800
>> Kristian Høgsberg  wrote:
>> > I'd like to see concrete examples of actual display controllers
>> > supporting more format layouts than what can be specified with a 64
>> > bit modifier.
>>
>> The main problem is our tiling and other metadata parameters can't
>> generally fit in a modifier, so we find passing a blob of metadata a
>> more suitable mechanism.
>
>
> I understand that you may have n knobs with a total of more than a total of
> 56 bits that configure your tiling/swizzling for color buffers. What I don't
> buy is that you need all those combinations when passing buffers around
> between codecs, cameras and display controllers. Even if you're sharing
> between the same 3D drivers in different processes, I expect just locking
> down, say, 64 different combinations (you can add more over time) and
> assigning each a modifier would be sufficient. I doubt you'd extract
> meaningful performance gains from going all the way to a blob.

There's probably a world of stuff that we don't know about in nouveau,
but I have a hard time coming up with more than 64-bits worth of
tiling info for dGPU surfaces...

There's 8 bits (sorta, not fully populated, but might as well use
them) of "micro" tiling which is done at the PTE level by the memory
controller and includes compression settings, and then there's 4 bits
of tiling per dimension for macro blocks (which configures different
sizes for each dimension for tile sizes) -- that's only 20 bits. MSAA
level (which is part of the micro tiling setting usually, but may not
necessarily have to be) - another couple of bits, maybe something else
weird for another few bits. Anyways, this is *nowhere* close to 64
bits.

What am I missing?

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

Re: [RFC PATCH v2 1/1] drm/tegra: sor: Fix hang on tegra124 due to NULL clk_out

[Thierry Reding]

On Wed, Dec 20, 2017 at 11:32:23AM +, Guillaume Tucker wrote:
> When neither HDMI nor DP is supported such as on the tegra124, the
> sor->clk_out is not initialised and remains NULL.  In this case, the
> parent clock can't be assigned to it so revert to the previous
> behaviour of assigning it to the main sor->clk instead.
> 
> This fixes a kernel hang on tegra124 and should also affect tegra210
> as they both don't support HDMI and DP.  Tested on tegra124 only.
> 
> Fixes: e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")
> Signed-off-by: Guillaume Tucker 
> CC: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/sor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

How about just the below instead? It's one more line than your patch,
but it will automatically handle all occurrences of clk_out properly.

--- >8 ---
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index f6313c4d612e..4be9edf9c6fe 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3047,6 +3047,8 @@ static int tegra_sor_probe(struct platform_device *pdev)
name, err);
goto remove;
}
+   } else {
+   sor->clk_out = sor->clk;
}
 
sor->clk_parent = devm_clk_get(>dev, "parent");
--- >8 ---

That said, I suspect the SOR might be compatible from a clock point of
view with later versions and perhaps we just didn't implement clocks
correctly back in the Tegra124 timeframe.

Maybe Peter knows.

Thierry


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

[Bug 102130] pp_dpm_mclk always on level 1 (cant set to level 0) rx 480

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher  ---
Is this still an issue?

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

[Bug 97471] kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

-- 
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 94973] R9 380X (Tonga) SMC failure with pcie_dpm_key_disabled=0

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Is this still an issue?

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

[Bug 97993] amdgpu_query_gpu_info () segfaults when user does not have permission to open /dev/dri/card*

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

-- 
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 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30

[Thierry Reding]

On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format if
> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore with
> both modesetting and opentegra drivers. On older Tegra's each plane has
> a blending configuration which should be used to enable / disable alpha
> blending and right now the blending configs are hardcoded to disabled
> alpha blending. In order to support alpha formats properly, planes
> blending configuration must be adjusted, until then the alpha formats
> are equal to non-alpha.
> 
> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/dc.c| 29 ++---
>  drivers/gpu/drm/tegra/dc.h|  1 +
>  drivers/gpu/drm/tegra/fb.c| 13 -
>  drivers/gpu/drm/tegra/hub.c   |  3 ++-
>  drivers/gpu/drm/tegra/plane.c | 22 +-
>  drivers/gpu/drm/tegra/plane.h |  2 +-
>  6 files changed, 39 insertions(+), 31 deletions(-)

This kept bugging me, so I spent some time looking at the blending
programming. I came up with the attached patch which seems to work
for all scenarios and is fairly similar to your patch. It has the
added benefit that we can keep support for more formats.

Any comments?

Thierry
--- >8 ---
From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
From: Thierry Reding 
Date: Wed, 20 Dec 2017 09:39:14 +0100
Subject: [PATCH] drm/tegra: dc: Implement legacy blending

This implements alpha blending on legacy display controllers (Tegra20,
Tegra30 and Tegra114). While it's theoretically possible to support the
zpos property to enable userspace to specify the Z-order of each plane
individually, this is not currently supported and the same fixed Z-
order as previously defined is used.

Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
the opaque formats are now supported.

Reported-by: Dmitry Osipenko 
Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/dc.c| 74 ++-
 drivers/gpu/drm/tegra/dc.h| 13 
 drivers/gpu/drm/tegra/fb.c| 12 ---
 drivers/gpu/drm/tegra/plane.c | 41 
 drivers/gpu/drm/tegra/plane.h |  3 ++
 5 files changed, 116 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index bc65c314e00f..07c687d7f615 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned int in)
return dfixed_frac(inf);
 }
 
-static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
+static void
+tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
+ const struct tegra_dc_window *window)
 {
+   u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
+BLEND_COLOR_KEY_NONE;
+   u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
+BLEND_COLOR_KEY_NONE;
+   u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
+
+   /* enable alpha blending if window->alpha */
+   if (window->alpha) {
+   background |= BLEND_CONTROL_DEPENDENT;
+   foreground |= BLEND_CONTROL_ALPHA;
+   }
+
/*
 * Disable blending and assume Window A is the bottom-most window,
 * Window C is the top-most window and Window B is in the middle.
 */
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_NOKEY);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_1WIN);
+   tegra_plane_writel(plane, blendnokey, DC_WIN_BLEND_NOKEY);
+   tegra_plane_writel(plane, foreground, DC_WIN_BLEND_1WIN);
 
switch (plane->index) {
case 0:
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+   tegra_plane_writel(plane, background, DC_WIN_BLEND_2WIN_X);
+   tegra_plane_writel(plane, background, DC_WIN_BLEND_2WIN_Y);
+   tegra_plane_writel(plane, background, DC_WIN_BLEND_3WIN_XY);
break;
 
case 1:
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
-   tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+   tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_X);
+   tegra_plane_writel(plane, background, DC_WIN_BLEND_2WIN_Y);
+   tegra_plane_writel(plane, background, 

[Bug 96866] REGRESSION System frozen after resume

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

-- 
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 104347] AMD RX 580: Hide/Show window sometimes corrupts screen (see screenshot)

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
Please attach the corresponding glxinfo output.

Did this not happen with an older version of Mesa / LLVM? If so, can you
bisect?

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

RE: [PATCH 1/3] drm/prime: forward begin_cpu_access callback to drivers

[Li, Samuel]

Ping... can someone please review this patch?

Samuel Li



> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Samuel Li
> Sent: Friday, December 15, 2017 11:28 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Koenig, Christian 
> Subject: [PATCH 1/3] drm/prime: forward begin_cpu_access callback to
> drivers
> 
> From: Christian König 
> 
> Allow drivers to implement their own begin_cpu_access callback.
> 
> Change-Id: I97709b42b9351a04ee7e01106107a87bc56ea258
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/drm_prime.c | 13 +
>  include/drm/drm_drv.h   |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 8de93a2..b4b0e64 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -346,6 +346,18 @@ void drm_gem_dmabuf_release(struct dma_buf
> *dma_buf)  }  EXPORT_SYMBOL(drm_gem_dmabuf_release);
> 
> +static int drm_gem_dmabuf_begin_cpu_access(struct dma_buf *dma_buf,
> + enum dma_data_direction
> direction) {
> + struct drm_gem_object *obj = dma_buf->priv;
> + struct drm_device *dev = obj->dev;
> +
> + if (!dev->driver->gem_prime_begin_cpu_access)
> + return 0;
> +
> + return dev->driver->gem_prime_begin_cpu_access(obj, direction); }
> +
>  static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)  {
>   struct drm_gem_object *obj = dma_buf->priv; @@ -403,6 +415,7
> @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  {
>   .map_dma_buf = drm_gem_map_dma_buf,
>   .unmap_dma_buf = drm_gem_unmap_dma_buf,
>   .release = drm_gem_dmabuf_release,
> + .begin_cpu_access = drm_gem_dmabuf_begin_cpu_access,
>   .map = drm_gem_dmabuf_kmap,
>   .map_atomic = drm_gem_dmabuf_kmap_atomic,
>   .unmap = drm_gem_dmabuf_kunmap,
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index
> 412e83a..1fbf298 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -475,6 +475,8 @@ struct drm_driver {
>   struct drm_device *dev,
>   struct dma_buf_attachment *attach,
>   struct sg_table *sgt);
> + int (*gem_prime_begin_cpu_access)(struct drm_gem_object *obj,
> +enum dma_data_direction
> direction);
>   void *(*gem_prime_vmap)(struct drm_gem_object *obj);
>   void (*gem_prime_vunmap)(struct drm_gem_object *obj, void
> *vaddr);
>   int (*gem_prime_mmap)(struct drm_gem_object *obj,
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104347] AMD RX 580: Hide/Show window sometimes corrupts screen (see screenshot)

[bugzilla-daemon]

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

--- Comment #1 from network...@rkmail.ru ---
I had the same issue with my RX480, but it does not happen on hd7950 with
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

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

[Max Staudt]

On 12/20/2017 04:35 PM, Ray Strode wrote:
> Hi,
> 
>> Actually, I don't want that :)
>>
>> This was a design decision that I've made to keep the code small and simple 
>> to audit.
>> As it is, the simple bootsplash code will make 99% of people happy.
> You think only 1% of linux users have more than one monitor or a 4k screen?

No, I think 99% will be glad to see a splash at all, and it's a 99% 
probabililty that the splash will look alright on at least one screen, if not 
more.

By the simple virtue that dual-monitor setups tend to use identical screens, 
it's okay if these are cloned while the splash is shown. So maybe 95% of these 
users are fine, as well.

As for 4k screens - a logo that looks okay on 800x600 will probably look fine, 
even though it's physically smaller, on a 4k screen.


If there really, really, really is a need, HiDPI can be retrofitted to the 
format later on.


>> I've made this decision from the point of view of someone who wants to ship 
>> a general
>> purpose distribution. If you have a look around and compare this to e.g. the 
>> Windows or
>> Mac OS X bootsplashes, the possibilities that my kernel code provides already
>> surpasses them.
> I haven't looked specifically, but I don't believe you :-)  You're
> telling me the apple boot
> splash isn't scaled up on machines with retina displays?  I don't use
> OSX (or windows),
> so I don't know, but I'd be really surprised.

Admittedly, my knowledge is aging as well. My pre-retina MacBook certainly 
didn't scale anything.

And Windows XP booted in 640x480, then went black, switched modes, and drew the 
desktop.


>> If you really want such sophisticated features, supplanting the initial 
>> bootsplash  with
>> Plymouth (or not using it at all) is a better solution. In my opinion, it is 
>> overengineering,
>> at least for kernel code.
> disagree..it's support for basic, commodity hardware these days.

Hmm. I guess it's a matter of taste, and we have to agree to disagree on this 
one. See above.

Also, like pointed out in the other email, it's meant as an alternative to 
Plymouth. Maybe I should have made this clear from the beginning - it's an 
option, not a replacement. We're in the FOSS ecosystem after all, where it's 
all about choice, and that choice exists because we admit that sometimes, not 
everyone can be made happy with the same solution.


>> As for HiDPI, if you're working on an embedded device with a fixed screen 
>> size -
>> say a phone - you can easily include a huge picture the size of the screen 
>> in the
>> bootsplash.
> I'm talking about a situation where you have a dell xps or whatever
> with an external
> monitor attached.  Each monitor should be able to show the splash
> without deforming
> it, and without making it huge or microscopic. pretty basic stuff...
See above. I doubt any other system cares.

And we can't even care before native driver KMS comes up, which may take a 
while, depending on the system.

I'd like to have this as an alternative to Plymouth in such setups.



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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 04:21 PM, Ray Strode wrote:
> If we've reached the scenario you're discussing above, the real
> failure is that the KMS
> driver took too long to load. DRM is the platform graphics api.  If
> it's not loading
> timely enough to show graphics then that's the problem!  It sounds
> like maybe in the
> above bug, you're just failing to load the drm driver in the initrd ?

This case needs to be handled.

Again, please read my bug report.

When the user changes graphics cards, the initrd does not contain the new 
driver. It's in the rootfs, if at all.

If it does happen to be on the rootfs, then it is potentially loaded after 
Plymouth has already opened /dev/fb0. And then the bug occurs.

Please don't say that I'm to blame for changing my graphics card. This is not 
fair.


And I have to admit, it's not even necessarily a bug. It's just the nature of 
the kernel/userspace split. All I know is that the boot failing due to this is 
not right, and horrible to debug the next time it happens to someone.


>> And then, if something causes Plymouth to sense a new device (such as 
>> Plymouth
>>  thinking that udev coldplug is complete), it will open the device, and as 
>> part of that,
>> call VT_SETMODE. This is unexpected, since "plymouth deactivate" should keep 
>> it
>> from doing this. And Plymouth's code architecture is such that this bug is 
>> hard to fix.
> If what you're describing is happening, this does sound like a bug. I
> don't think it
> should be hard to fix, if it's a problem. I'll look into it.

Thank you!

It'd be nice to see this bug fixed, as it happens only occasionally (as is the 
nature of a race condition), and was thus really hard to debug. I'm sure it can 
drive people insane, as they try to find out whether they've disabled 
Ctrl-Alt-Fx in their xorg.conf, but really it's Plymouth getting the system 
into a bad state. I probably owe a bald patch on my head to this bug.


>> [I] have decided to write a kernel-based replacement to simplify things and 
>> to show a
>> splash as early as possible. It just avoids all of this complexity.
> So, for the record, I don't actually have a problem with you doing a
> kernel based splash.

Thanks!

It's really just meant as an alternative. I've heard enough people who'd prefer 
it over Plymouth, but Plymouth is just as important as it is much more 
feature-rich.


>> This is the sleep that I mean.
>>
>> On the one hand, it is this delay that makes most users not notice the
>> "busy VRAM bug". If the DRM driver that replaces the FB driver is included 
>> in the
>> initramfs, then in most cases, it will be loaded before the 5 seconds are 
>> up. However,
>> if the driver is loaded after these 5 seconds have elapsed, then Plymouth 
>> will have
>> opened /dev/fb0 and the modprobe fails.
> Think of this from a user perspective.  If the screen is black for 15 seconds
> (or something) before a splash is shown, then we've already hit a
> problem! That's like 15
> seconds of time where the user is wondering if their system is broken.

This is exactly where the kernel bootsplash is useful. Since it starts even 
before any userspace program is loaded, it can close this gap.

I've even tried it in combination with Plymouth: Plymouth is just another 
graphical application, so it simply pops up "on top", just like X would. The 
two splashes integrate flawlessly.


> But I don't think that actually happens in practice.  I think (maybe?)
> the situation you're
> hitting is your drm driver isn't starting to get loaded until N
> seconds after boot has started,
> because it's not in the initrd.  So the fix is to put it in the initrd.
No. See above.

One could argue that one could put all DRM drivers into the initrd. Ubuntu does 
this, and the initrd is ~40 MB in size. Not nice.

And even then, the initrd could be outdated for some reason. Maybe it's a 
developer machine. Nobody would expect the boot to hang/fail because of this 
problem.


>> On the other hand, what is the motivation for this delay?
> As I said earlier, the motivation for the delay is to avoid showing a
> splash for systems that
> boot in 4 seconds or something. At that point a splash is just getting
> in the way.
> 
>>  If Plymouth were to display the splash instantly on a system that needs 0.5 
>> seconds to
>> boot, then the splash would flash for 0.5 seconds.
> No, flashing a splash for half a second would be a bug. (again think
> of things from a user
> perpective).  Plymouth splashes have animations at the end to
> transition the user to the
>  login screen.  Normally those animations don't contribute to boot
> time, because we know
> when boot will finish from prior boot data.  But if boot were 0.5
> seconds long, then those
>  animations would contribute 2 to 3 seconds to boot time, and if boot
> is 0.5 seconds long
> showing a splash is pointless.
>> But with the delay, a system that needs 5.5 seconds to boot will also flash 
>> it for 0.5 seconds.
>> Either way, the splash will 

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 04:19 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter  wrote:
>> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt  wrote:
>>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
 btw since I'm probably sounding a bit too grumpy here: I'd very much
 support this. I think bootsplash in kernel has a bunch of uses, and it
 shouldn't be hard to get non-suse people to cheer for it (makes merging
 easier if it's not just a one-off hack).
>>>
>>> Thank you!
>>>
>>> As it seems, other people and distros are already interested - for example 
>>> Manjaro.
>>>
>>> It's also a chance to (maybe in the near future) integrate with a splash 
>>> painted by EFI and/or GRUB, before userspace has even started.
>>
>> Maybe I've sounded too optimistic now.
>>
>> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
>> But most likely you want this on a highly embedded system, which
>> probably is compiled for your exact hw, with pretty much everything
>> built in. Also, no fbcon, maybe even no vt subsystem at all.
>> Definitely not your general purpose distro.
>>
>> Your proposal to work on top of fbcon doesn't fix that niche.
>>
>> Now for your problem, which seems to be to have a working bootsplash
>> for a general purpose distro, specifically for the bug where plymouth
>> prevents the real drm driver from loading: Adding an in-kernel
>> bootsplash doesn't make any sense, at least not to me. Instead I think
>> the right action is to fix the problem, both in the kernel and in
>> userspace.
>>
>> All the problems below have fairly simple solutions, but there's imo
>> no point in talking technical solutions for specific problems when
>> we're trying to fix the wrong problem.
> 
> Aside: The problem you think you need the vt/console subsystem for is
> simple to fix with plain kms: kms works without fbdev, fbcon and the
> entire vt subsystem. Dislay ownership is controlled through the drm
> master concept. That's the exact same trick that we're using already
> to figure out whether fbdev (not just fbcon) is allowed to touch the
> display hw.

So when there is no DRM master, then the FB emulation becomes active.

Sure. But I still have to multiplex between the console and the splash.
It seemed cleanest to do this inside the console. If there's a good way 
outside, that's just as good for me, and I'm happy to implement it.
But please help me and point me at how to do it best. Ideally, in both FB and 
KMS contexts. Without using additional video RAM wherever possible.


> So yeah, there's a solution, and a modern system definitely would not
> want to get encumbered with the entire vt subsystem to be able to use
> a bootsplash. David Herrman had the entire pile prototyped btw,
> including userspace console on top of drm, emergency log on top of
> drm, and replacement for simpledrm. Adding an in-kernel boot splash
> would be fairly simple for this setup. It's just that no one else
> cared enough to get it merged.

So... the solution for being unable to implement a good splash in userspace 
is... to move the console into the userspace?

A ton of people will beg to differ. And I'm afraid I have to disagree as well.


To be clear, I dislike the nature of the VT subsystem as well. It's a hack. But 
it's such an incredibly useful hack that I'm willing to turn a blind eye to its 
ugliness. There's a good reason why we have a terminal emulator in the kernel 
itself, and I'd rather keep it around for a while longer.



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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 04:11 PM, Daniel Vetter wrote:
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt subsystem at all.
> Definitely not your general purpose distro.

If an embedded distro can use it, then so can a general purpose distro that 
doesn't want to use Plymouth.

It's useful in many cases.


> Your proposal to work on top of fbcon doesn't fix that niche.

It does fix it very well - it's just that it also requires fbcon.
And I'm glad to fix this if you have a good idea for a cleaner alternative.


> Now for your problem, which seems to be to have a working bootsplash
> for a general purpose distro, specifically for the bug where plymouth
> prevents the real drm driver from loading: Adding an in-kernel
> bootsplash doesn't make any sense, at least not to me. Instead I think
> the right action is to fix the problem, both in the kernel and in
> userspace.

So we SIGBUS any process using the framebuffer just because we're loading an 
alternative driver, which uses a hack to kick out the old driver?

It's loading the new driver that should fail because the hardware resource is 
busy serving the old driver!
Not existing applications being killed. This is horribly broken semantics.

Just like unloading a driver that's still in use MUST fail. Not kill the 
processes using it!

And if it fails to load with -EBUSY, as it should, then the bug still stands.


> All the problems below have fairly simple solutions, but there's imo
> no point in talking technical solutions for specific problems when
> we're trying to fix the wrong problem.

The problem is that a splash in userspace brings horrible hacks and workarounds 
into the room. We're already discussing killing processes!

No, just no. Processes aren't ours to kill willy-nilly.



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

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

[Ray Strode]

Hi,

> Actually, I don't want that :)
>
> This was a design decision that I've made to keep the code small and simple 
> to audit.
> As it is, the simple bootsplash code will make 99% of people happy.
You think only 1% of linux users have more than one monitor or a 4k screen?

> I've made this decision from the point of view of someone who wants to ship a 
> general
> purpose distribution. If you have a look around and compare this to e.g. the 
> Windows or
> Mac OS X bootsplashes, the possibilities that my kernel code provides already
> surpasses them.
I haven't looked specifically, but I don't believe you :-)  You're
telling me the apple boot
splash isn't scaled up on machines with retina displays?  I don't use
OSX (or windows),
so I don't know, but I'd be really surprised.

> If you really want such sophisticated features, supplanting the initial 
> bootsplash  with
> Plymouth (or not using it at all) is a better solution. In my opinion, it is 
> overengineering,
> at least for kernel code.
disagree..it's support for basic, commodity hardware these days.

> As for HiDPI, if you're working on an embedded device with a fixed screen 
> size -
> say a phone - you can easily include a huge picture the size of the screen in 
> the
> bootsplash.
I'm talking about a situation where you have a dell xps or whatever
with an external
monitor attached.  Each monitor should be able to show the splash
without deforming
it, and without making it huge or microscopic. pretty basic stuff...

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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Daniel Vetter]

On Wed, Dec 20, 2017 at 4:19 PM, Daniel Vetter  wrote:
> On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter  wrote:
>> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt  wrote:
>>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
 btw since I'm probably sounding a bit too grumpy here: I'd very much
 support this. I think bootsplash in kernel has a bunch of uses, and it
 shouldn't be hard to get non-suse people to cheer for it (makes merging
 easier if it's not just a one-off hack).
>>>
>>> Thank you!
>>>
>>> As it seems, other people and distros are already interested - for example 
>>> Manjaro.
>>>
>>> It's also a chance to (maybe in the near future) integrate with a splash 
>>> painted by EFI and/or GRUB, before userspace has even started.
>>
>> Maybe I've sounded too optimistic now.
>>
>> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
>> But most likely you want this on a highly embedded system, which
>> probably is compiled for your exact hw, with pretty much everything
>> built in. Also, no fbcon, maybe even no vt subsystem at all.
>> Definitely not your general purpose distro.
>>
>> Your proposal to work on top of fbcon doesn't fix that niche.
>>
>> Now for your problem, which seems to be to have a working bootsplash
>> for a general purpose distro, specifically for the bug where plymouth
>> prevents the real drm driver from loading: Adding an in-kernel
>> bootsplash doesn't make any sense, at least not to me. Instead I think
>> the right action is to fix the problem, both in the kernel and in
>> userspace.
>>
>> All the problems below have fairly simple solutions, but there's imo
>> no point in talking technical solutions for specific problems when
>> we're trying to fix the wrong problem.
>
> Aside: The problem you think you need the vt/console subsystem for is
> simple to fix with plain kms: kms works without fbdev, fbcon and the
> entire vt subsystem. Dislay ownership is controlled through the drm
> master concept. That's the exact same trick that we're using already
> to figure out whether fbdev (not just fbcon) is allowed to touch the
> display hw.
>
> So yeah, there's a solution, and a modern system definitely would not
> want to get encumbered with the entire vt subsystem to be able to use
> a bootsplash. David Herrman had the entire pile prototyped btw,
> including userspace console on top of drm, emergency log on top of
> drm, and replacement for simpledrm. Adding an in-kernel boot splash
> would be fairly simple for this setup. It's just that no one else
> cared enough to get it merged.

*replacement for efifb/vesafb in the form of simpledrm. The
in-userspace fbcon is called kmscon, so also exists already. The
emergency boot splash thing was called drmlog iirc.
-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: [RFC PATCH v2 00/13] Kernel based bootsplash

[Ray Strode]

Hi,

> The problem that I am stumbling upon is different:
>  - the system starts with an FB driver
>  - after the ShowDelay time, Plymouth opens /dev/fb0
>  - the system finally loads the DRM driver, which tries to kick the previous 
> FB driver
>  - loading the DRM driver fails because Plymouth still has the previous 
> /dev/fb0 open
So the thing to realize is, that using /dev/fb is a last ditch effort
by plymouth to make
things work. It's basically a compat hack to keep vga=0x318 working
and also a nod
to embedded systems that just have /dev/fb and don't have a kms driver.  If we
fall back to /dev/fb we lose, as mentioned before, multi-monitor
support. And it's a
legacy, deprecated api.

If we've reached the scenario you're discussing above, the real
failure is that the KMS
driver took too long to load. DRM is the platform graphics api.  If
it's not loading
timely enough to show graphics then that's the problem!  It sounds
like maybe in the
above bug, you're just failing to load the drm driver in the initrd ?

> If you have a better way of calling it, I'd be glad to learn.
> Maybe "grabbing the VT", "taking ownership of the VT", ...?
I don't care what we call it, I just didn't understand what you were
saying before.
I think i'd say "manages vt switching", but whatever.

> And then, if something causes Plymouth to sense a new device (such as Plymouth
>  thinking that udev coldplug is complete), it will open the device, and as 
> part of that,
> call VT_SETMODE. This is unexpected, since "plymouth deactivate" should keep 
> it
> from doing this. And Plymouth's code architecture is such that this bug is 
> hard to fix.
If what you're describing is happening, this does sound like a bug. I
don't think it
should be hard to fix, if it's a problem. I'll look into it.

> [I] have decided to write a kernel-based replacement to simplify things and 
> to show a
> splash as early as possible. It just avoids all of this complexity.
So, for the record, I don't actually have a problem with you doing a
kernel based splash.
(though it should use drm subsystem apis not graphics subsystem apis,
/dev/fb is going
the way of the dodo)

> This is the sleep that I mean.
>
> On the one hand, it is this delay that makes most users not notice the
> "busy VRAM bug". If the DRM driver that replaces the FB driver is included in 
> the
> initramfs, then in most cases, it will be loaded before the 5 seconds are up. 
> However,
> if the driver is loaded after these 5 seconds have elapsed, then Plymouth 
> will have
> opened /dev/fb0 and the modprobe fails.
Think of this from a user perspective.  If the screen is black for 15 seconds
(or something) before a splash is shown, then we've already hit a
problem! That's like 15
seconds of time where the user is wondering if their system is broken.
But I don't think that actually happens in practice.  I think (maybe?)
the situation you're
hitting is your drm driver isn't starting to get loaded until N
seconds after boot has started,
because it's not in the initrd.  So the fix is to put it in the initrd.

> On the other hand, what is the motivation for this delay?
As I said earlier, the motivation for the delay is to avoid showing a
splash for systems that
boot in 4 seconds or something. At that point a splash is just getting
in the way.

>  If Plymouth were to display the splash instantly on a system that needs 0.5 
> seconds to
> boot, then the splash would flash for 0.5 seconds.
No, flashing a splash for half a second would be a bug. (again think
of things from a user
perpective).  Plymouth splashes have animations at the end to
transition the user to the
 login screen.  Normally those animations don't contribute to boot
time, because we know
when boot will finish from prior boot data.  But if boot were 0.5
seconds long, then those
 animations would contribute 2 to 3 seconds to boot time, and if boot
is 0.5 seconds long
showing a splash is pointless.
> But with the delay, a system that needs 5.5 seconds to boot will also flash 
> it for 0.5 seconds.
> Either way, the splash will just flash for a moment.
again, we don't blink the splash on and off. we have transition animations.

> The delay only changes which systems are affected. However, if you set the 
> delay to 0,
> you'll run into the bug I described above.
Then put the drm driver in the initramfs so you fix your bug !

> This is a design problem, hidden by a needless delay.
really don't see how it is.

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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Daniel Vetter]

On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter  wrote:
> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt  wrote:
>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>>> support this. I think bootsplash in kernel has a bunch of uses, and it
>>> shouldn't be hard to get non-suse people to cheer for it (makes merging
>>> easier if it's not just a one-off hack).
>>
>> Thank you!
>>
>> As it seems, other people and distros are already interested - for example 
>> Manjaro.
>>
>> It's also a chance to (maybe in the near future) integrate with a splash 
>> painted by EFI and/or GRUB, before userspace has even started.
>
> Maybe I've sounded too optimistic now.
>
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt subsystem at all.
> Definitely not your general purpose distro.
>
> Your proposal to work on top of fbcon doesn't fix that niche.
>
> Now for your problem, which seems to be to have a working bootsplash
> for a general purpose distro, specifically for the bug where plymouth
> prevents the real drm driver from loading: Adding an in-kernel
> bootsplash doesn't make any sense, at least not to me. Instead I think
> the right action is to fix the problem, both in the kernel and in
> userspace.
>
> All the problems below have fairly simple solutions, but there's imo
> no point in talking technical solutions for specific problems when
> we're trying to fix the wrong problem.

Aside: The problem you think you need the vt/console subsystem for is
simple to fix with plain kms: kms works without fbdev, fbcon and the
entire vt subsystem. Dislay ownership is controlled through the drm
master concept. That's the exact same trick that we're using already
to figure out whether fbdev (not just fbcon) is allowed to touch the
display hw.

So yeah, there's a solution, and a modern system definitely would not
want to get encumbered with the entire vt subsystem to be able to use
a bootsplash. David Herrman had the entire pile prototyped btw,
including userspace console on top of drm, emergency log on top of
drm, and replacement for simpledrm. Adding an in-kernel boot splash
would be fairly simple for this setup. It's just that no one else
cared enough to get it merged.
-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: [RFC PATCH v2 00/13] Kernel based bootsplash

[Daniel Vetter]

On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt  wrote:
> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>> support this. I think bootsplash in kernel has a bunch of uses, and it
>> shouldn't be hard to get non-suse people to cheer for it (makes merging
>> easier if it's not just a one-off hack).
>
> Thank you!
>
> As it seems, other people and distros are already interested - for example 
> Manjaro.
>
> It's also a chance to (maybe in the near future) integrate with a splash 
> painted by EFI and/or GRUB, before userspace has even started.

Maybe I've sounded too optimistic now.

So fundamentally I don't think an in-kernel bootsplash is a bad idea.
But most likely you want this on a highly embedded system, which
probably is compiled for your exact hw, with pretty much everything
built in. Also, no fbcon, maybe even no vt subsystem at all.
Definitely not your general purpose distro.

Your proposal to work on top of fbcon doesn't fix that niche.

Now for your problem, which seems to be to have a working bootsplash
for a general purpose distro, specifically for the bug where plymouth
prevents the real drm driver from loading: Adding an in-kernel
bootsplash doesn't make any sense, at least not to me. Instead I think
the right action is to fix the problem, both in the kernel and in
userspace.

All the problems below have fairly simple solutions, but there's imo
no point in talking technical solutions for specific problems when
we're trying to fix the wrong problem.
-Daniel

>> But I'm really not sold on the current integration path being anywhere
>> near close to a good idea long-term.
> Sure, that's a valid concern.
>
> So there's two questions I understand from you here:
>
> 1. Do I really need to build on top of the console driver?
> 2. If not (1), then can I build on top of KMS instead?
>
>
> Let's look at this...
>
> 1. The starting point was that the kernel's built-in terminal emulator, 
> fbcon, is the "fallback" thing to display when no graphical application is 
> running. It is hidden automatically as soon as a program switches to 
> KD_GRAPHICS, and reappears as soon as that program switches back to KD_TEXT, 
> or dies.
> It seemed desirable to me to want the same behavior for a splash screen.
>
> Furthermore, when fbcon runs, there is already a mode set. Whatever mode that 
> may be, it's good enough for us.
> It makes sense to re-use the same mode.
> (This isn't really important for FB, but would be important when talking 
> about drmcon).
>
> Since fbcon and the splash will never be shown at the same time, it makes 
> sense to re-use whatever framebuffer fbcon is writing into, and silence fbcon 
> during this time (that's what my dummyops do).
>
> When the splash is disabled, it needs to show the text that was hidden. So 
> what I do is to call update_screen(vc_cons[fg_console].d) and also restore 
> the original fbcon character rendering operations, thus allowing it to 
> re-render the screen.
>
>
> It thus seemed sensible to me to work inside of fbcon.
>
>
> Let's stay at the FB level for the sake of taking things step by step. How 
> would I solve this without hooking into fbcon?
>
> To shut up fbcon, I could play with do_console_blank() and 
> do_console_unblank(). These are called when changing between KD_GRAPHICS and 
> KD_TEXT. I'd then have to introduce additional logic for the KD_TEXT state, 
> which switches between showing fbcon and showing the splash. I haven't tried 
> this, but fair enough.
>
> To decide when to render, I'd have to have a hook that tells me when an FB 
> mode changes, or the device disappears, or a new device appears. With fbcon, 
> I can simply draw my splash in the fbcon_switch() function, not needing to 
> care about whether this is a good time and whether I have a device underneath 
> my feet. If fbcon can draw, then so can I.
>
>
> 2. Let's assume we follow the ideas from the final paragraphs of (1) above, 
> and also move to KMS. How would I deal with setting modes, etc.? I wouldn't 
> want to change modes, and I also can't always get a new framebuffer for 
> background buffering - think devices that only have a single framebuffer, 
> such as a fictional efidrm, or devices with little VRAM. So if these 
> semantics get figured out for a future drmcon, then it makes sense to just 
> double-purpose its framebuffer. After all, the console framebuffer is the one 
> shown as a fallback, when no other process is using the graphics mode. 
> Otherwise, I'd have to check which one to show: The splash, or the text?
>
>
>
> So... it seemed helpful to me to build on top of the graphical console driver 
> and double-purpose it, because it takes away the need to think about "what 
> mode do I use", "which framebuffer to draw on", "when is it safe to draw", 
> and so forth.
>
> If you disagree with that, or even think that it's easier to do outside 
> fbcon, I'd be grateful to hear ideas on 

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 11:14 AM, Daniel Vetter wrote:
> btw since I'm probably sounding a bit too grumpy here: I'd very much
> support this. I think bootsplash in kernel has a bunch of uses, and it
> shouldn't be hard to get non-suse people to cheer for it (makes merging
> easier if it's not just a one-off hack).

Thank you!

As it seems, other people and distros are already interested - for example 
Manjaro.

It's also a chance to (maybe in the near future) integrate with a splash 
painted by EFI and/or GRUB, before userspace has even started.


> But I'm really not sold on the current integration path being anywhere
> near close to a good idea long-term.
Sure, that's a valid concern.

So there's two questions I understand from you here:

1. Do I really need to build on top of the console driver?
2. If not (1), then can I build on top of KMS instead?


Let's look at this...

1. The starting point was that the kernel's built-in terminal emulator, fbcon, 
is the "fallback" thing to display when no graphical application is running. It 
is hidden automatically as soon as a program switches to KD_GRAPHICS, and 
reappears as soon as that program switches back to KD_TEXT, or dies.
It seemed desirable to me to want the same behavior for a splash screen.

Furthermore, when fbcon runs, there is already a mode set. Whatever mode that 
may be, it's good enough for us.
It makes sense to re-use the same mode.
(This isn't really important for FB, but would be important when talking about 
drmcon).

Since fbcon and the splash will never be shown at the same time, it makes sense 
to re-use whatever framebuffer fbcon is writing into, and silence fbcon during 
this time (that's what my dummyops do).

When the splash is disabled, it needs to show the text that was hidden. So what 
I do is to call update_screen(vc_cons[fg_console].d) and also restore the 
original fbcon character rendering operations, thus allowing it to re-render 
the screen.


It thus seemed sensible to me to work inside of fbcon.


Let's stay at the FB level for the sake of taking things step by step. How 
would I solve this without hooking into fbcon?

To shut up fbcon, I could play with do_console_blank() and 
do_console_unblank(). These are called when changing between KD_GRAPHICS and 
KD_TEXT. I'd then have to introduce additional logic for the KD_TEXT state, 
which switches between showing fbcon and showing the splash. I haven't tried 
this, but fair enough.

To decide when to render, I'd have to have a hook that tells me when an FB mode 
changes, or the device disappears, or a new device appears. With fbcon, I can 
simply draw my splash in the fbcon_switch() function, not needing to care about 
whether this is a good time and whether I have a device underneath my feet. If 
fbcon can draw, then so can I.


2. Let's assume we follow the ideas from the final paragraphs of (1) above, and 
also move to KMS. How would I deal with setting modes, etc.? I wouldn't want to 
change modes, and I also can't always get a new framebuffer for background 
buffering - think devices that only have a single framebuffer, such as a 
fictional efidrm, or devices with little VRAM. So if these semantics get 
figured out for a future drmcon, then it makes sense to just double-purpose its 
framebuffer. After all, the console framebuffer is the one shown as a fallback, 
when no other process is using the graphics mode. Otherwise, I'd have to check 
which one to show: The splash, or the text?



So... it seemed helpful to me to build on top of the graphical console driver 
and double-purpose it, because it takes away the need to think about "what mode 
do I use", "which framebuffer to draw on", "when is it safe to draw", and so 
forth.

If you disagree with that, or even think that it's easier to do outside fbcon, 
I'd be grateful to hear ideas on how to implement it. Maybe it wasn't the best 
decision - but as the old saying goes, "it seemed like a very good idea at the 
time".


As for the FB/KMS discussion:
Since I decided to build on top of the only graphical console driver that we 
have, I have no choice: fbcon builds on fbdev, and thus the bootsplash is on 
fbdev, too. Complaining that it's not on KMS is a red herring - after all, it 
does work on KMS drivers, and people are happy with fbcon on KMS as well.


If integration and future paths are to be discussed, let's first talk about 
whether to move the splash inside/outside the console driver (fbcon).



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

[Bug 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

--- Comment #9 from Harry Wentland  ---
Created attachment 136321
  --> https://bugs.freedesktop.org/attachment.cgi?id=136321=edit
DC scatter gather patch

You'll need this DC patch.

-- 
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 4/7] drm/ttm: use an operation ctx for ttm_tt_populate in ttm_bo_driver

[Christian König]

Am 20.12.2017 um 11:34 schrieb Roger He:

Change-Id: I803ea52d11e5c06add0dffab836c3aecc00b56dd
Signed-off-by: Roger He 


Commit message! And please double check the coding style of 
ast_ttm_tt_populate.


With that fixed that patch is Reviewed-by: Christian König 
.


Regards,
Christian.


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  7 ---
  drivers/gpu/drm/ast/ast_ttm.c|  5 +++--
  drivers/gpu/drm/cirrus/cirrus_ttm.c  |  5 +++--
  drivers/gpu/drm/nouveau/nouveau_bo.c |  8 
  drivers/gpu/drm/qxl/qxl_ttm.c|  5 +++--
  drivers/gpu/drm/radeon/radeon_ttm.c  |  9 +
  drivers/gpu/drm/ttm/ttm_agp_backend.c|  4 ++--
  drivers/gpu/drm/ttm/ttm_bo_util.c| 11 ---
  drivers/gpu/drm/ttm/ttm_bo_vm.c  |  7 ++-
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 13 +
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 11 ---
  drivers/gpu/drm/ttm/ttm_tt.c |  6 +-
  drivers/gpu/drm/virtio/virtgpu_object.c  |  6 +-
  drivers/gpu/drm/virtio/virtgpu_ttm.c |  5 +++--
  drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c   | 13 +
  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c  | 13 +++--
  include/drm/ttm/ttm_bo_driver.h  |  5 +++--
  include/drm/ttm/ttm_page_alloc.h | 11 +++
  18 files changed, 86 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f1b7d98..52aab9d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -990,7 +990,8 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct 
ttm_bo_device *bdev,
return >ttm.ttm;
  }
  
-static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)

+static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
+   struct ttm_operation_ctx *ctx)
  {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
@@ -1018,11 +1019,11 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
  
  #ifdef CONFIG_SWIOTLB

if (swiotlb_nr_tbl()) {
-   return ttm_dma_populate(>ttm, adev->dev);
+   return ttm_dma_populate(>ttm, adev->dev, ctx);
}
  #endif
  
-	return ttm_populate_and_map_pages(adev->dev, >ttm);

+   return ttm_populate_and_map_pages(adev->dev, >ttm, ctx);
  }
  
  static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 28da7c2..1413e94 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -216,9 +216,10 @@ static struct ttm_tt *ast_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
  }
  
-static int ast_ttm_tt_populate(struct ttm_tt *ttm)

+static int ast_ttm_tt_populate(struct ttm_tt *ttm,
+   struct ttm_operation_ctx *ctx)
  {
-   return ttm_pool_populate(ttm);
+   return ttm_pool_populate(ttm, ctx);
  }
  
  static void ast_ttm_tt_unpopulate(struct ttm_tt *ttm)

diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 2a5b54d..95e2d40 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -216,9 +216,10 @@ static struct ttm_tt *cirrus_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
  }
  
-static int cirrus_ttm_tt_populate(struct ttm_tt *ttm)

+static int cirrus_ttm_tt_populate(struct ttm_tt *ttm,
+   struct ttm_operation_ctx *ctx)
  {
-   return ttm_pool_populate(ttm);
+   return ttm_pool_populate(ttm, ctx);
  }
  
  static void cirrus_ttm_tt_unpopulate(struct ttm_tt *ttm)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 6b6fb20..b141c27 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1547,7 +1547,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object 
*bo)
  }
  
  static int

-nouveau_ttm_tt_populate(struct ttm_tt *ttm)
+nouveau_ttm_tt_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
  {
struct ttm_dma_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
@@ -1572,17 +1572,17 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
  
  #if IS_ENABLED(CONFIG_AGP)

if (drm->agp.bridge) {
-   return ttm_agp_tt_populate(ttm);
+   return ttm_agp_tt_populate(ttm, ctx);
}
  #endif
  
  #if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)

if (swiotlb_nr_tbl()) {
-   return ttm_dma_populate((void *)ttm, dev);
+   return ttm_dma_populate((void *)ttm, dev, ctx);
}
  #endif
  
-	r = ttm_pool_populate(ttm);

+   r = ttm_pool_populate(ttm, ctx);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c 

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 11:06 AM, Neil Armstrong wrote:
> My 2cents about this patchset:
> You did a good job about all the animation and splash logic, but for me all 
> this fbcon
> stuff is a huge hack, please use a standard and modern display subsystem en 
> leave fbcon
> die alone

Thanks for the compliment!

As for fbcon: I think you're confusing things. fbcon is not the same as fbdev.

I've hooked into the terminal emulator because it allows me to hide exactly the 
thing I want to hide (text), it allows me to show what I want when I want 
(splash or text), and it spares me from defining a third competing user of the 
device.

I understand that you want old code to die, and as it is now, catering for the 
old code will cater for everyone, including the new style drivers (via their 
legacy interface).


> My DRM ARM systems would love to have such bootsplash, so please, make it 
> happen using DRM
> then leave the fbcon based stuff like efifb migrate to DRM in a second time !
The current solution will "just work" on your systems as it is. I'm not 
ignoring them. If you've ever used a kernel console on your DRM ARM device, 
then the current splash will work exactly as good.



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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 10:43 AM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
>> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
>>> So essentially you're telling me that on a current general purpose
>>> distro the gfx driver loading is a dumpster fire, and we're fixing
>>> this by ignoring it an adding a hole new layer on top. That doesn't
>>> sound like any kind of good idea to me.
>>
>> Yes. It is a vast improvement over the status quo, and people are asking
>> for it. And the bootsplash layer can be moved elsewhere, just change the
>> hooks and keep the loading/rendering.
>>
>> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It
>> just mustn't be done 100% carelessly.
> 
> You've talked about using sleep and stuff to paper over races. That
> doesn't sound good at all.

Sorry, I was unclear.

It's Plymouth's ShowDelay that, unintentionally, papers over this bug.

The driver loading bug will happen with any user based splash - it's not 
limited to Plymouth.

On the other hand, if you don't start a graphical application before having 
loaded the final graphics driver, everything is good and there is no race.

So, module loading works as intended ;)


>>> So if just using drm for everything isn't possible (since drm drivers
>>> can at least in theory be hotunplugged), can we at least fix the
>>> existing fbdev kernel bugs? Not being able to unplug a drm driver when
>>> it's still open sounds like a rather serious issues that probably
>>> should be fixed anyway ... so we're better able to hotunplug an fbdev
>>> driver when it's in use.
>>
>> I don't see it as a bug. The fbdev driver gets unloaded as much as
>> possible, but as long as a userspace application keeps the address_space
>> mmap()ed, there's nothing we can do, short of forcibly removing it and
>> segfaulting the process the next time it tries to render something. Am I
>> missing something?
> 
> I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering
> in a sighandler and abort if you hit that. In drm we try to be a bit
> better and keep things around until userspace has gone.

Hmm. Are you sure it's okay to SIG these processes just because someone else 
has decided to unload a driver? That is counter to everything else that I've 
seen so far.

Also, is it even feasible, implementation wise?


>>> Or we get simpledrm merged (for efifb and vesafb support) and someone
>>> types the xendrm driver (there is floating around, it's just old) and
>>> we could forget about any real fbdev drivers except the drm based
>>> ones.
>>
>> And drmcon, unless we come up with a better idea than hooking into the *con 
>> driver.
> 
> If we have everything as drm drivers, you can just use plymouth (with no
> fbdev backend ofc) and everyone is happy. Including the efifb folks (it's
> simply going to be called efidrmfb or something like that). So no idea why
> you need a *con.

Hmm, that still makes us wait until userspace has appeared...

And the reason I built it into *con is because the logic for 
appearing/disappearing is basically the same, and in this chain it makes sense 
for the bootsplash show/hide logic to be chained behind *con.


>> Sure, that'd help a lot. But what do we do until then?
> 
> Make it happen? Twiddling thumbs is an option too ofc, but it tends to not
> result in results :-)

I'm afraid I don't have the time to write an in-kernel terminal emulator, thus 
the wish to build upon the existing one...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/i915/vlv: Add cdclk workaround for DSI

[Ville Syrjälä]

On Wed, Dec 20, 2017 at 11:50:17AM +0100, Hans de Goede wrote:
> At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
> shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
> colors, showing that the panel controller is starting with sampling the
> datastream somewhere mid-line. This happens after the first blanking and
> re-init of the panel.
> 
> After looking at drm.debug output I noticed that initially we inherit the
> cdclk of 33 KHz set by the GOP, but after the re-init we picked 27
> KHz, which turns out to be the cause of this problem, a quick hack to hard
> code the cdclk to 33 KHz makes the problem go away.
> 
> I've tested this on various Bay Trail devices, to make sure this not
> causes regressions on other devices and the higher cdclk does not cause
> any problems on the following devices:
> -GP-electronic T701  1024x600   33 KHz cdclk after this patch
> -PEAQ C1010  1920x1200  33 KHz cdclk after this patch
> -PoV mobii-wintab-800w800x1280  33 KHz cdclk after this patch
> -Asus Transformer-T100TA 1368x768   32 KHz cdclk after this patch
> 
> Also interesting wrt this is the comment in vlv_calc_cdclk about the
> existing workaround to avoid 200 Mhz as clock because that causes issues
> in some cases.

IIRC the 200 MHz clock never worked on any machine/display.

> 
> This commit extends the "do not use 200 Mhz" workaround with an extra
> check to require atleast 32 KHz (avoiding 27 KHz) when a DSI
> panel is active.
> 
> Changes in v2:
> -Change the commit message and the code comment to not treat the GOP as
>  a reference, the GOP should not be treated as a reference
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 9c5ceb98d48f..a15976f55f47 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct 
> intel_crtc_state *crtc_state)
>   if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
>   min_cdclk = max(2 * 96000, min_cdclk);
>  
> + /*
> +  * On Valleyview some DSI panels loose (v|h)sync when the clock is lower

s/loose/lose/

My VLV+DSI tablet is happy with the 266 MHz cdclk, so it's a little
disappointing to apply this to all such machines. But unless someone
can come up with a better workaround I think this will have to do.

Acked-by: Ville Syrjälä 


> +  * then 32KHz.
> +  */
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> + IS_VALLEYVIEW(dev_priv))
> + min_cdclk = max(32, min_cdclk);
> +
>   if (min_cdclk > dev_priv->max_cdclk_freq) {
>   DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n",
> min_cdclk, dev_priv->max_cdclk_freq);
> -- 
> 2.14.3

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

Re: [PATCH v2 0/7] Add drm_fb_helper_fbdev_setup/teardown()

[Noralf Trønnes]

Den 15.12.2017 18.51, skrev Noralf Trønnes:

Hi,

This is a new attempt at simplifying fbdev setup/teardown in drivers.

Only doc changes in this version based on feedback from Daniel.

Noralf.

Changes since version 1:
- Document a case where drm_fb_helper_fbdev_setup() can't be used:
   connector hotplugging (e.g. dp mst).
- Document where drm_fb_helper_defio_init() should be called from.
- Move drm_fb_helper_defio_init() recommendation to DOC framebuffer
   flushing section.

Noralf Trønnes (7):
   drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini
   drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()
   drm/docs: Add todo entry for drm_fb_helper_fbdev_setup()
   drm/fb-helper: Update DOC with new helpers
   drm/fb-helper: Add drm_fb_helper_defio_init()


Pathes 1-5 applied to drm-misc. Thanks for the review Daniel!
I will do a round up of the remaining cma helper patches when I have
moved tinydrm to the vmalloc BO helper.

Noralf.


   drm/fb-cma-helper: Use drm_fb_helper_fbdev_setup/teardown()
   drm/fb-cma-helper: Honour DRM_FBDEV_EMULATION

  Documentation/gpu/todo.rst  |  18 
  drivers/gpu/drm/Kconfig |   5 +-
  drivers/gpu/drm/drm_fb_cma_helper.c | 111 +++--
  drivers/gpu/drm/drm_fb_helper.c | 188 +---
  include/drm/drm_fb_helper.h |  38 
  5 files changed, 247 insertions(+), 113 deletions(-)



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

Re: [PATCH 3/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc_page

[Christian König]

Commit message!

Am 20.12.2017 um 11:34 schrieb Roger He:

Change-Id: I4104a12e09a374b6477a0dd5a8fce26dce27a746
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_memory.c | 15 ---
  drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 +-
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  8 ++--
  include/drm/ttm/ttm_memory.h |  3 ++-
  4 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 525d3b6..8df0755 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -539,15 +539,14 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob, 
uint64_t memory,
  EXPORT_SYMBOL(ttm_mem_global_alloc);
  
  int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,

- struct page *page, uint64_t size)
+ struct page *page, uint64_t size,
+ struct ttm_operation_ctx *ctx)
  {
-
+   int ret;
struct ttm_mem_zone *zone = NULL;
-   struct ttm_operation_ctx ctx = {
-   .interruptible = false,
-   .no_wait_gpu = false
-   };
+   bool tmp_no_wait_gpu = ctx->no_wait_gpu;


Mhm, please drop that. That the function might wait for the GPU even 
when the caller requested not to do so sounds like a bug to me.


Christian.

  
+	ctx->no_wait_gpu = false;

/**
 * Page allocations may be registed in a single zone
 * only if highmem or !dma32.
@@ -560,7 +559,9 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
  #endif
-   return ttm_mem_global_alloc_zone(glob, zone, size, );
+   ret = ttm_mem_global_alloc_zone(glob, zone, size, ctx);
+   ctx->no_wait_gpu = tmp_no_wait_gpu;
+   return ret;
  }
  
  void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct page *page,

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba644..8f93ff3 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1061,6 +1061,10 @@ void ttm_page_alloc_fini(void)
  int ttm_pool_populate(struct ttm_tt *ttm)
  {
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
unsigned i;
int ret;
  
@@ -1076,7 +1080,7 @@ int ttm_pool_populate(struct ttm_tt *ttm)
  
  	for (i = 0; i < ttm->num_pages; ++i) {

ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
-   PAGE_SIZE);
+   PAGE_SIZE, );
if (unlikely(ret != 0)) {
ttm_pool_unpopulate(ttm);
return -ENOMEM;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index bda00b2..8aac86a 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -927,6 +927,10 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
  {
struct ttm_tt *ttm = _dma->ttm;
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
enum pool_type type;
@@ -962,7 +966,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
break;
  
  		ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],

-   pool->size);
+   pool->size, );
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
@@ -998,7 +1002,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
}
  
  		ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],

-   pool->size);
+   pool->size, );
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 755c107..8936285 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -84,7 +84,8 @@ extern int ttm_mem_global_alloc(struct ttm_mem_global *glob, 
uint64_t memory,
  extern void ttm_mem_global_free(struct ttm_mem_global *glob,
uint64_t amount);
  extern int ttm_mem_global_alloc_page(struct ttm_mem_global 

Re: [PATCH 2/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc

[Christian König]

Commit message needed! Something like:

Forward the operation context to ttm_mem_global_alloc as well.

Am 20.12.2017 um 11:34 schrieb Roger He:

Change-Id: I5279b5cd3560c4082b00f822219575a5f9c3808a
Signed-off-by: Roger He 


With the commit message fixed, patch is Reviewed-by: Christian König 
.


I would like to get an rb or ab from Thomas and/or Sinclair as well, 
since this is touching a lot of vmwgfx code.


Regards,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
  drivers/gpu/drm/ttm/ttm_memory.c| 15 +--
  drivers/gpu/drm/ttm/ttm_object.c| 13 ++---
  drivers/gpu/drm/vmwgfx/vmwgfx_binding.c |  6 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c  | 13 ++---
  drivers/gpu/drm/vmwgfx/vmwgfx_context.c |  6 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |  6 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c   |  6 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  | 18 +++---
  drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c |  6 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_so.c  |  6 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 12 ++--
  include/drm/ttm/ttm_memory.h|  3 ++-
  13 files changed, 87 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fa57aa8..c59f572 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1133,7 +1133,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
bool locked;
  
-	ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);

+   ret = ttm_mem_global_alloc(mem_glob, acc_size, ctx);
if (ret) {
pr_err("Out of kernel memory\n");
if (destroy)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 9130bdf..525d3b6 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -508,7 +508,7 @@ static int ttm_mem_global_reserve(struct ttm_mem_global 
*glob,
  static int ttm_mem_global_alloc_zone(struct ttm_mem_global *glob,
 struct ttm_mem_zone *single_zone,
 uint64_t memory,
-bool no_wait, bool interruptible)
+struct ttm_operation_ctx *ctx)
  {
int count = TTM_MEMORY_ALLOC_RETRIES;
  
@@ -516,7 +516,7 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global *glob,

   single_zone,
   memory, true)
!= 0)) {
-   if (no_wait)
+   if (ctx->no_wait_gpu)
return -ENOMEM;
if (unlikely(count-- == 0))
return -ENOMEM;
@@ -527,15 +527,14 @@ static int ttm_mem_global_alloc_zone(struct 
ttm_mem_global *glob,
  }
  
  int ttm_mem_global_alloc(struct ttm_mem_global *glob, uint64_t memory,

-bool no_wait, bool interruptible)
+struct ttm_operation_ctx *ctx)
  {
/**
 * Normal allocations of kernel memory are registered in
 * all zones.
 */
  
-	return ttm_mem_global_alloc_zone(glob, NULL, memory, no_wait,

-interruptible);
+   return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx);
  }
  EXPORT_SYMBOL(ttm_mem_global_alloc);
  
@@ -544,6 +543,10 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,

  {
  
  	struct ttm_mem_zone *zone = NULL;

+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
  
  	/**

 * Page allocations may be registed in a single zone
@@ -557,7 +560,7 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
  #endif
-   return ttm_mem_global_alloc_zone(glob, zone, size, false, false);
+   return ttm_mem_global_alloc_zone(glob, zone, size, );
  }
  
  void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct page *page,

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index 26a7ad0..1aa2baa 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -325,6 +325,10 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
struct ttm_ref_object *ref;
struct drm_hash_item *hash;
struct ttm_mem_global *mem_glob = tfile->tdev->mem_glob;
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
int ret = -EINVAL;
  
  	if (base->tfile 

Re: [PATCH 1/7] drm/ttm: call ttm_bo_swapout directly when ttm shrink

[Christian König]

Am 20.12.2017 um 11:34 schrieb Roger He:

then remove superfluous functions


We need a better commit message. Something like:

Remove the extra indirection, cause we have only one implementation anyway.



Change-Id: Iea020f0e30a239e0265e7a1500168c7d7f819bd9
Signed-off-by: Roger He 


With the commit message fixed Reviewed-by: Christian König 
.


Regards,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo.c | 21 +++-
  drivers/gpu/drm/ttm/ttm_memory.c | 12 ++-
  include/drm/ttm/ttm_bo_api.h |  1 +
  include/drm/ttm/ttm_bo_driver.h  |  1 -
  include/drm/ttm/ttm_memory.h | 69 +---
  5 files changed, 9 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 60bb5c1..fa57aa8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -42,7 +42,6 @@
  #include 
  #include 
  
-static int ttm_bo_swapout(struct ttm_mem_shrink *shrink);

  static void ttm_bo_global_kobj_release(struct kobject *kobj);
  
  static struct attribute ttm_bo_count = {

@@ -1454,7 +1453,6 @@ static void ttm_bo_global_kobj_release(struct kobject 
*kobj)
struct ttm_bo_global *glob =
container_of(kobj, struct ttm_bo_global, kobj);
  
-	ttm_mem_unregister_shrink(glob->mem_glob, >shrink);

__free_page(glob->dummy_read_page);
kfree(glob);
  }
@@ -1479,6 +1477,7 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
mutex_init(>device_list_mutex);
spin_lock_init(>lru_lock);
glob->mem_glob = bo_ref->mem_glob;
+   glob->mem_glob->bo_glob = glob;
glob->dummy_read_page = alloc_page(__GFP_ZERO | GFP_DMA32);
  
  	if (unlikely(glob->dummy_read_page == NULL)) {

@@ -1489,14 +1488,6 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
INIT_LIST_HEAD(>swap_lru[i]);
INIT_LIST_HEAD(>device_list);
-
-   ttm_mem_init_shrink(>shrink, ttm_bo_swapout);
-   ret = ttm_mem_register_shrink(glob->mem_glob, >shrink);
-   if (unlikely(ret != 0)) {
-   pr_err("Could not register buffer object swapout\n");
-   goto out_no_shrink;
-   }
-
atomic_set(>bo_count, 0);
  
  	ret = kobject_init_and_add(

@@ -1504,8 +1495,6 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
if (unlikely(ret != 0))
kobject_put(>kobj);
return ret;
-out_no_shrink:
-   __free_page(glob->dummy_read_page);
  out_no_drp:
kfree(glob);
return ret;
@@ -1688,11 +1677,8 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
   * A buffer object shrink method that tries to swap out the first
   * buffer object on the bo_global::swap_lru list.
   */
-
-static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
+int ttm_bo_swapout(struct ttm_bo_global *glob)
  {
-   struct ttm_bo_global *glob =
-   container_of(shrink, struct ttm_bo_global, shrink);
struct ttm_buffer_object *bo;
int ret = -EBUSY;
unsigned i;
@@ -1774,10 +1760,11 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
kref_put(>list_kref, ttm_bo_release_list);
return ret;
  }
+EXPORT_SYMBOL(ttm_bo_swapout);
  
  void ttm_bo_swapout_all(struct ttm_bo_device *bdev)

  {
-   while (ttm_bo_swapout(>glob->shrink) == 0)
+   while (ttm_bo_swapout(bdev->glob) == 0)
;
  }
  EXPORT_SYMBOL(ttm_bo_swapout_all);
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index e963749..9130bdf 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -214,26 +214,20 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool 
from_wq,
   uint64_t extra)
  {
int ret;
-   struct ttm_mem_shrink *shrink;
  
  	spin_lock(>lock);

-   if (glob->shrink == NULL)
-   goto out;
  
  	while (ttm_zones_above_swap_target(glob, from_wq, extra)) {

-   shrink = glob->shrink;
spin_unlock(>lock);
-   ret = shrink->do_shrink(shrink);
+   ret = ttm_bo_swapout(glob->bo_glob);
spin_lock(>lock);
if (unlikely(ret != 0))
-   goto out;
+   break;
}
-out:
+
spin_unlock(>lock);
  }
  
-

-
  static void ttm_shrink_work(struct work_struct *work)
  {
struct ttm_mem_global *glob =
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index c126330..24a8db7 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -752,6 +752,7 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file 
*filp,
  const char __user *wbuf, char __user *rbuf,
  size_t count, loff_t *f_pos, bool write);
  
+int ttm_bo_swapout(struct ttm_bo_global *glob);

  void 

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Julia Lawall]

On Wed, 20 Dec 2017, Joe Perches wrote:

> On Wed, 2017-12-20 at 10:59 +0100, Greg Kroah-Hartman wrote:
> > > > Why you didn't send that patch to the sysfs maintainer is a bit odd...  
> > > > :)
> > >
> > > So here's an opportunity for you:
> > >
> > > The sysfs maintainer hasn't added include/linux/sysfs.h to
> > > the list of maintained files...
> > >
> > > DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
> > > M:Greg Kroah-Hartman 
> > > T:git 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> > > S:Supported
> > > F:Documentation/kobject.txt
> > > F:drivers/base/
> > > F:fs/debugfs/
> > > F:fs/sysfs/
> > > F:include/linux/debugfs.h
> > > F:include/linux/kobj*
> > > F:lib/kobj*
> >
> > Heh, good point, but using get_maintainer.pl does put me at the top of
> > the list that you should be cc:ing:
> >
> > $ ./scripts/get_maintainer.pl --file include/linux/sysfs.h
> > Greg Kroah-Hartman  
> > (commit_signer:3/3=100%,authored:2/3=67%,added_lines:7/8=88%)
> > Kate Stewart  (commit_signer:1/3=33%)
> > Thomas Gleixner  (commit_signer:1/3=33%)
> > Philippe Ombredanne  (commit_signer:1/3=33%)
> > Nick Desaulniers  
> > (commit_signer:1/3=33%,authored:1/3=33%,added_lines:1/8=12%,removed_lines:1/1=100%)
> > linux-ker...@vger.kernel.org (open list)
>
> The script I use to send patches adds --nogit --nogit-fallback
> to copy only listed maintainers because people that send cleanup
> patches don't generally like to get random patches.
>
> > > btw: there are many uses of a reversed declaration style of DEVICE_ATTR
> > >
> > > Here's another thing that could be done for more DEVICE_ATTR_ uses.
> > >
> > > ===
> > >
> > > Some DEVICE_ATTR definitions use a reversed static function form from
> > > the typical.  Convert them to use the more common macro form so it is
> > > easier to grep for the style.
> []
> > > $ git grep --name-only -w DEVICE_ATTR | \
> > >   xargs perl -i dev_attr_rw_backwards.perl
> > Ah, nice, I love perl :
>
> That was a bad copy/paste of the script.
>
> The actual script for RW is:
>
> $ cat dev_attr_rw_backwards.perl
> local $/;
> while (<>) {
> my $file = $_;
> while ($file =~ m/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,/g) {
>   my $var = $1;
>   if ($file =~ 
> s/\bDEVICE_ATTR\s*\(\s*${var}\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*show_${var}\s*,\s*store_${var}\s*\)/DEVICE_ATTR_RW(${var})/g)
>  {
>   $file =~ s/\bshow_${var}\b/${var}_show/g;
>   $file =~ s/\bstore_${var}\b/${var}_store/g;
>   }
> }
> print $file;
> }
>
> There are 3 different perl scripts for rw, ro, and wo.
> and these scripts, because of function renaming and
> possible reuse of the original function names by other
> string concatenated macros, create some bad conversions
> so they need some manual cleanups too.
>
> Perhaps coccinelle could do a better job of it, but
> likely string concatenation macro uses are going to
> be hard to deal with in any case.

I made a rule for this at one point, but there are cases where the
functions have the wrong names, and then these functions may be used
elsewhere.

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

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

[Max Staudt]

On 12/19/2017 10:01 PM, Ray Strode wrote:
> Hi,
> 
> On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt  wrote:
>> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a
>> functional extension of that. It just happens that fbcon sits on top of FB, 
>> so I
>> work with what I get.
>>
>> And the console in turn happens to work on all FB and KMS drivers, so it
>> makes users of all kinds of drivers happy. In fact, that's why the FB 
>> emulation
>> in KMS drivers came to be in the first place, if I remember right - to ensure
>> fbcon continues to work.
> 
> But what about multi-monitor? what about hidpi screens?  Ideally you want
> each monitor to show the splash in a way that best fits that monitor.

Actually, I don't want that :)

This was a design decision that I've made to keep the code small and simple to 
audit.
As it is, the simple bootsplash code will make 99% of people happy. It includes 
positioning of objects in corners and in the center, and a background color, 
and thus can render something that doesn't look funny in all but the most 
extreme cases.

I've made this decision from the point of view of someone who wants to ship a 
general purpose distribution. If you have a look around and compare this to 
e.g. the Windows or Mac OS X bootsplashes, the possibilities that my kernel 
code provides already surpasses them.

If you really want such sophisticated features, supplanting the initial 
bootsplash  with Plymouth (or not using it at all) is a better solution. In my 
opinion, it is overengineering, at least for kernel code.


So... I'll just take what the fbdev emulation gives me. In most cases (single 
screen systems), this looks good. In most remaining cases, you have two 
identical monitors that show exactly the same thing. And whatever remains can 
live with whatever mode the DRM driver decides to set for the fbdev emulation.


As for HiDPI, if you're working on an embedded device with a fixed screen size 
- say a phone - you can easily include a huge picture the size of the screen in 
the bootsplash.


Again, it's feature creep now. Apple just centers a, well, an apple in the 
middle of the screen. Windows may even boot in 640x480 and then do a mode 
switch when showing the desktop (not sure whether this is still true with the 
latest version). Neither of them scales for HiDPI, and neither cares about 
multiple monitors. People are happy.


So in the end, it's a matter of taste. I agree that in user space, exploring 
these features is fun. But in kernel space, it's definitely important to keep 
the code short and simple. I'm convinced that I've found a good balance :)


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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/19/2017 09:30 PM, Ray Strode wrote:
> Hi,
> 
>> For example, having a userspace splash that starts as early as it can
>> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail
>> reserving the entirety of video RAM, and thus fail loading. This cannot be 
>> fixed.
> well the fix there is to use drm devices... like this:
> 
> https://cgit.freedesktop.org/plymouth/commit/?id=97f02ee959374afb1b8a78dc67116cd880cf2d23

Sorry, you're confusing things. Please re-read the v1 cover letter, the commit 
message for patch 1, and the associated discussions.

There is also a bug report where I've described what happens - I think it 
clarifies the situation a lot:
  https://bugzilla.opensuse.org/show_bug.cgi?id=980750


To summarise: What you mean is for Plymouth to ignore FB devices when they have 
equivalent DRM devices. And yes, Plymouth does that just fine.

The problem that I am stumbling upon is different:
 - the system starts with an FB driver
 - after the ShowDelay time, Plymouth opens /dev/fb0
 - the system finally loads the DRM driver, which tries to kick the previous FB 
driver
 - loading the DRM driver fails because Plymouth still has the previous 
/dev/fb0 open


It's a wholly different issue.


>> Furthermore, Plymouth is quite broken. For example, it may lock
>> (via VT_SETMODE) the VT even though Plymouth is in "disabled"
>> state and X has already taken control of the VT.
> What do you mean by "disabled" (plymouth.enable=0?) ?  if it's
> disabled, it's not going to call VT_SETMODE ...

1. System boots
2. Plymouth starts and grabs some displays
3. gdm starts and runs /usr/bin/plymouth deactivate
4. X server grabs VT
5. udev queue is empty
6. Plymouth thinks that coldplugging has finished, and grabs remaining displays
7. 
8. gdm runs /usr/bin/plymouth quit --retain-splash


> Why do you refer to VT_SETMODE as locking ?

It's not a lock in the concurrency sense, sure.

If you have a better way of calling it, I'd be glad to learn.
Maybe "grabbing the VT", "taking ownership of the VT", ...?


> VT_SETMODE sets
> whether a process handles VT changes or the kernel does.  There is a
> long standing kernel issue where a mode of VT_AUTO (kernel handles
> vt switching) + KDGRAPHICS means VTs can't be changed. is that what
> you're talking about?

No, that's not what I mean. I've inserted printk()s in the kernel, and I've 
seen the X server's PID being thrown out when Plymouth calls VT_SETMODE. Once 
this happens, the kernel can no longer tell X to release the display.

The VT_SETMODE API is meant to be used by a single user at a time, not by two 
concurrently. It was built in a time when it was assumed that nobody other than 
the X server would use it.


> Anyway plymouth is only going to step on X's toes, if the distro erroneously
> asks it to.  Normally, a distro would run "plymouth deactivate" before
> starting X, instead of trying to run them at the same time...

That's what gdm, sddm, etc. do.

And then, if something causes Plymouth to sense a new device (such as Plymouth 
thinking that udev coldplug is complete), it will open the device, and as part 
of that, call VT_SETMODE. This is unexpected, since "plymouth deactivate" 
should keep it from doing this. And Plymouth's code architecture is such that 
this bug is hard to fix.

This is accurate as of about one year ago. I haven't looked into it since, but 
have decided to write a kernel-based replacement to simplify things and to show 
a splash as early as possible. It just avoids all of this complexity.


>> This causes the kernel to throw away X's PID as the VT owner, and thus
>> chvt and Ctrl-Alt-Fx no longer work because X can neither release the
>> console (VT_RELDISP fails), nor does the kernel send it the signal to do
>> so. This is hard to impossible to fix.
> Unless i'm missing something, this is totally just a problem with startup
> scripts not doing the right thing?  Plymouth shouldn't be doing anything
> once X is started.  If it is, that's either a plymouth bug (or more likely a
> distro integration problem)

It is a Plymouth bug, see above.


>> A third reason is that in practice, Plymouth's start is delayed for reasons
>> such as the above. Yes, race conditions are being worked around with
>> sleeps.
> ??? that's not true.  We don't have any sleep statements in the code to work
> around race conditions with X.
> 
> We do have two configurable delays in the code, are you talking about one of
> them?
> 
> 1) The first is a ShowDelay option.  The point of this option is,
> "If boot takes 5 seconds or less, it's essentially instant and we
> shouldn't show a splash at all".  Nothing to do with race conditions.
> You can set it to 0 if you want.

This is the sleep that I mean.

On the one hand, it is this delay that makes most users not notice the "busy 
VRAM bug". If the DRM driver that replaces the FB driver is included in the 
initramfs, then in most cases, it will be loaded before the 5 seconds are up. 
However, if the driver is 

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, seasons greetings, just a few small fixes.

BR,
Jani.

The following changes since commit 2cf654db8d7eafb973d28eb3cddf043d353e1345:

  drm/i915/fence: Use rcu to defer freeing of irq_work (2017-12-14 10:58:59 
+0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2017-12-20

for you to fetch changes up to a4ffdc2b6726958c07d535318400124e3a3bc19b:

  drm/i915: Protect DDI port to DPLL map from theoretical race. (2017-12-19 
14:59:53 +0200)


drm/i915 fixes for v4.15-rc5


Chris Wilson (1):
  drm/i915/lpe: Remove double-encapsulation of info string

Rodrigo Vivi (1):
  drm/i915: Protect DDI port to DPLL map from theoretical race.

 drivers/gpu/drm/i915/intel_ddi.c   | 4 
 drivers/gpu/drm/i915/intel_lpe_audio.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv4] drm/sun4i: validate modes for HDMI

[Maxime Ripard]

Hi Daniel,

On Tue, Dec 19, 2017 at 11:05:04AM +0100, Daniel Vetter wrote:
> On Mon, Dec 18, 2017 at 08:50:46AM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Fri, Dec 15, 2017 at 06:06:32PM +0100, Daniel Vetter wrote:
> > > On Fri, Dec 15, 2017 at 05:46:19PM +0100, Hans Verkuil wrote:
> > > > When I connected my cubieboard running 4.15-rc1 to my 4k display I got 
> > > > no picture. Some
> > > > digging found that there is no check against the upper pixelclock limit 
> > > > of the HDMI
> > > > output, so X selects a 4kp60 format at 594 MHz, which obviously won't 
> > > > work.
> > > > 
> > > > The patch below adds a check for the upper bound of what this hardware 
> > > > can do, and
> > > > it checks if the requested tmds clock can be obtained.
> > > > 
> > > > It also allows for the ± 0.5% pixel clock variation that the HDMI spec 
> > > > permits.
> > > > 
> > > > That code is based on commit 22d0be2a557e53a22feb484e8fce255fe09e6ad5 
> > > > from
> > > > Jose Abreu for drm/arc.
> > > > 
> > > > Signed-off-by: Hans Verkuil 
> > > > ---
> > > > Changes since v3:
> > > > - Move the mode_valid callback to struct drm_encoder_helper_funcs.
> > > >   I'm assuming this is the correct struct, since this check is specific 
> > > > to the
> > > >   hdmi encoder.
> > > 
> > > Reviewed-by: Daniel Vetter 
> > > 
> > > I think sun4i is in drm-misc, so feel free to push.
> > 
> > I already pushed the v3. Hans, can you provide an additional patch? on top 
> > of your v3?
> 
> Pretty sure I reviewed before you pushed, why should I bother?

Yeah, sorry. My mailer didn't fetch your mail until monday morning, so
your review went unnoticed :/

I just pushed a patch to bring the changes to the v4, with your
Acked-by as you told on IRC.

Sorry again,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[RFC PATCH v2 0/1] Fix drm driver hang on tegra124-nyan-big

[Guillaume Tucker]

This patch was initially sent along with another one to fix a
first hang in the nouveau drm driver[1].  I'm now sending it
again as a separate patch as it's to fix a second hang which is
not strictly related.  It is hidden by the first hang though, as
this happens later on during the driver initialisation.

The issue this is addressing is due to a rework[2] of the driver
which apparently wasn't fully tested on tegra124 and possibly
also on tegra210.  The sor->clk_out is not used on these
platforms as HDMI and DP are both not supported (but eDP is), so
trying to assign the parent clock to clk_out does nothing.  The
driver then goes on to configure the clock and PLL registers in
tegra_sor_edp_enable and this is where it hangs.

As this is hard to debug further without full documentation or a
hardware debugger, this patch essentially makes the driver do
what it used to do on these platforms before the rework
(i.e. assign the parent clock to sor->clk instead).  There might
be a more correct way of fixing this, hence the RFC.

[1] https://patchwork.kernel.org/patch/10124637/
[2] e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")

Guillaume Tucker (1):
  drm/tegra: sor: Fix hang on tegra124 due to NULL clk_out

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

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

[RFC PATCH v2 1/1] drm/tegra: sor: Fix hang on tegra124 due to NULL clk_out

[Guillaume Tucker]

When neither HDMI nor DP is supported such as on the tegra124, the
sor->clk_out is not initialised and remains NULL.  In this case, the
parent clock can't be assigned to it so revert to the previous
behaviour of assigning it to the main sor->clk instead.

This fixes a kernel hang on tegra124 and should also affect tegra210
as they both don't support HDMI and DP.  Tested on tegra124 only.

Fixes: e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")
Signed-off-by: Guillaume Tucker 
CC: Thierry Reding 
---
 drivers/gpu/drm/tegra/sor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index b0a1dedac802..a344f66d4ecb 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -255,7 +255,7 @@ static int tegra_sor_set_parent_clock(struct tegra_sor 
*sor, struct clk *parent)
 
clk_disable_unprepare(sor->clk);
 
-   err = clk_set_parent(sor->clk_out, parent);
+   err = clk_set_parent(sor->clk_out ? sor->clk_out : sor->clk, parent);
if (err < 0)
return err;
 
-- 
2.11.0

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

[Bug 104347] AMD RX 580: Hide/Show window sometimes corrupts screen (see screenshot)

[bugzilla-daemon]

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

Bug ID: 104347
   Summary: AMD RX 580: Hide/Show window sometimes corrupts screen
(see screenshot)
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: arthurborsb...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136316
  --> https://bugs.freedesktop.org/attachment.cgi?id=136316=edit
Screenshot of scrambled window

When I hide all Windows with a shortcut and then show another one, a window
(not the whole desktop) looks a scrambled, see attachments. It restores itself
usually after 3-5 seconds and/or hiding/showing of the window after a couple of
times.

In dmesg there is no message of a GPU warning/error.

Kernel: Linux 4.14.5-1-ARCH
Driver: amdgpu
X11: xf86-video-amdgpu 1.4.0
Mesa: 17.3.0

If this is the wrong place to report this issue, can you please move it to the
correct location?

If other information is needed, please let me know.

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

Re: [PATCH] drm/rockchip: analogix_dp: Ensure that the bridge is powered before poking it

[Andrzej Hajda]

On 19.12.2017 12:42, Marc Zyngier wrote:
> On 19/12/17 07:55, Andrzej Hajda wrote:
>> On 18.12.2017 12:28, Marc Zyngier wrote:
>>> Stopping the X display manager on a kevin platform results in the
>>> following crash:
>>>
>>> [  674.833536] Synchronous External Abort: synchronous external abort 
>>> (0x9610) at 0x0c970640
>>> [  674.843886] Internal error: : 9610 [#1] PREEMPT SMP
>>> [  674.849744] Modules linked in:
>>> [  674.849755] CPU: 1 PID: 86 Comm: kworker/1:1 Not tainted 
>>> 4.15.0-rc3-00057-gff24f8cf492d-dirty #3
>>> [  674.849760] detected fb_set_par error, error code: -16
>>> [  674.849761] Hardware name: Google Kevin (DT)
>>> [  674.849773] Workqueue: events analogix_dp_psr_work
>>> [  674.849778] pstate: 6005 (nZCv daif -PAN -UAO)
>>> [  674.849784] pc : analogix_dp_send_psr_spd+0x8/0x168
>>> [  674.849788] lr : analogix_dp_enable_psr+0x54/0x60
>>> [  674.849789] sp : 09b2bd60
>>> [  674.849790] x29: 09b2bd60 x28: 
>>> [  674.849794] x27: 09913d20 x26: 0900fbf0
>>> [  674.849797] x25: 8000f1b3 x24: 8000f0c21d98
>>> [  674.849800] x23:  x22: 8000f7d3aa00
>>> [  674.849803] x21: 8000f7d36980 x20: 8000f0c21c18
>>> [  674.849806] x19: 8000f0c21db8 x18: 0001
>>> [  674.849809] x17: 89f2ed58 x16: 08222908
>>> [  674.849812] x15:  x14: 0400
>>> [  674.849815] x13: 0400 x12: 
>>> [  674.849817] x11: 1414 x10: 0a00
>>> [  674.849820] x9 : 09b2bbb0 x8 : 8000f1b30a60
>>> [  674.849823] x7 : 0008 x6 : 0001
>>> [  674.849826] x5 : 0010 x4 : 0007
>>> [  674.849829] x3 : 0002 x2 : 0c970640
>>> [  674.849832] x1 : 09b2bd78 x0 : 8000f1624018
>>> [  674.849836] Process kworker/1:1 (pid: 86, stack limit = 
>>> 0x83e5f7c3)
>>> [  674.849838] Call trace:
>>> [  674.849842]  analogix_dp_send_psr_spd+0x8/0x168
>>> [  674.849844]  analogix_dp_psr_work+0x9c/0xa0
>>> [  674.849849]  process_one_work+0x1cc/0x328
>>> [  674.849852]  worker_thread+0x50/0x450
>>> [  674.849856]  kthread+0xf8/0x128
>>> [  674.849860]  ret_from_fork+0x10/0x18
>>> [  674.849864] Code: b901 d65f03c0 f9445802 91190042 (b9400042)
>>>
>>> Further investigation show that this happens because the the workqueue
>>> races with the analogix_dp_bridge_disable() call from the core DRM code,
>>> and end up trying to write to the DP bridge that has already been powered
>>> down. This result is a very black screen, and a hard reset.
>>>
>>> Instead of counting on luck to keep the bridge alive, let's use the
>>> pm_runtime framework and take a reference on the device when we're about
>>> to poke it. That is a fairly big hammer, but one that allows the system
>>> to stay alive across dozens of X start/stop sequences.
>> Wouldn't be better to cancel the work in analogix_dp_bridge_disable, it
>> looks safer.
> Not sure. That would only cancel a single work that would be in flight
> right when we hit disable, but won't prevent the work from being queued
> right after the cancel.
>
> In summary, I think you're trading a race between pm_runtime_put_sync
> and analogix_dp_send_psr_spd for another between cancel_work_sync and
> analogix_dp_send_psr_spd. Also, I seem to remember that the disable can
> occur in its own work queue:
>
> commit_tail -> drm_atomic_helper_commit_modeset_disables ->
> disable_outputs -> drm_bridge_disable -> analogix_dp_bridge_disable
>
> making it racy by nature. But I'm no DRM expert (as you can probably tell).
>
> My approach is to guarantee that analogix_dp_send_psr_spd cannot fault
> due to the IP being powered off, which feels a bit more bullet proof.

I suspect the worker should not be executed during/after disable, at
least its body suggests it.
And if it will be guaranteed, runtime dance in the worker is pointless.

Regards
Andrzej

>
> Please shoot me down if I got it wrong!
>
> Thanks,
>
>   M.


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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Daniel Stone]

Hi Johannes,

On 20 December 2017 at 11:08, Johannes Thumshirn  wrote:
> On Tue, Dec 19, 2017 at 05:16:30PM +0100, Daniel Vetter wrote:
>> Ok I've realized that my assumptions about why you need this aren't
>> So from reading these patches it sounded like you want an in-kernel boot
>> splash because that would be on the display faster than a userspace one
>> like plymouth. That's the only reasons I can see for this (if there's
>> another good justification, please bring it up).
>>
>> I only know of very embedded setups (tv top boxes, in vehicle
>> entertainment) where that kind of "time to first image" really matters,
>> and those systems:
>> - have a real hw kms driver
>> - don't have fbcon or fbdev emulation enabled (except for some closed
>>   source stacks that are a bit slow to adapt to the new world, and we
>>   don't care about those in gfx).
>>
>> But from discussions it sounds like you very much want to use this on
>> servers, which makes 0 sense to me. On a server something like plymouth
>> should do a perfectly reasonable job.
>
> For _one_ reason we'd like to see this is (I was one of the requesters of this
> implementation), plymouth in it's infinite wisdom also grabs the serial (IPMI)
> console and escape characters in a screen log are (you can think of the rest
> of this sentence yourself I think).

You can set 'plymouth.ignore-serial-consoles' on your boot line to
disable this behaviour.

> Also plymouth grabs the escape character of HPE iLOs, which is a serious
> no-go.

I'm not entirely sure what this means, but maybe it's best addressed
as a bug report to the Plymouth developers? One of them is in this
thread.

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

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

[bugzilla-daemon]

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

--- Comment #17 from Andreas Brogle (an...@ok.de) ---
What do you suggest ?
Who is the maintainer for fixing this bug ?

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

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Joe Perches]

On Wed, 2017-12-20 at 10:59 +0100, Greg Kroah-Hartman wrote:
> > > Why you didn't send that patch to the sysfs maintainer is a bit odd...  :)
> > 
> > So here's an opportunity for you:
> > 
> > The sysfs maintainer hasn't added include/linux/sysfs.h to
> > the list of maintained files...
> > 
> > DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
> > M:  Greg Kroah-Hartman 
> > T:  git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> > S:  Supported
> > F:  Documentation/kobject.txt
> > F:  drivers/base/
> > F:  fs/debugfs/
> > F:  fs/sysfs/
> > F:  include/linux/debugfs.h
> > F:  include/linux/kobj*
> > F:  lib/kobj*
> 
> Heh, good point, but using get_maintainer.pl does put me at the top of
> the list that you should be cc:ing:
> 
> $ ./scripts/get_maintainer.pl --file include/linux/sysfs.h
> Greg Kroah-Hartman  
> (commit_signer:3/3=100%,authored:2/3=67%,added_lines:7/8=88%)
> Kate Stewart  (commit_signer:1/3=33%)
> Thomas Gleixner  (commit_signer:1/3=33%)
> Philippe Ombredanne  (commit_signer:1/3=33%)
> Nick Desaulniers  
> (commit_signer:1/3=33%,authored:1/3=33%,added_lines:1/8=12%,removed_lines:1/1=100%)
> linux-ker...@vger.kernel.org (open list)

The script I use to send patches adds --nogit --nogit-fallback
to copy only listed maintainers because people that send cleanup
patches don't generally like to get random patches.

> > btw: there are many uses of a reversed declaration style of DEVICE_ATTR
> > 
> > Here's another thing that could be done for more DEVICE_ATTR_ uses.
> > 
> > ===
> > 
> > Some DEVICE_ATTR definitions use a reversed static function form from
> > the typical.  Convert them to use the more common macro form so it is
> > easier to grep for the style.
[]
> > $ git grep --name-only -w DEVICE_ATTR | \
> >   xargs perl -i dev_attr_rw_backwards.perl
> Ah, nice, I love perl :

That was a bad copy/paste of the script.

The actual script for RW is:

$ cat dev_attr_rw_backwards.perl
local $/;
while (<>) {
my $file = $_;
while ($file =~ m/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,/g) {
my $var = $1;
if ($file =~ 
s/\bDEVICE_ATTR\s*\(\s*${var}\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*show_${var}\s*,\s*store_${var}\s*\)/DEVICE_ATTR_RW(${var})/g)
 {
$file =~ s/\bshow_${var}\b/${var}_show/g;
$file =~ s/\bstore_${var}\b/${var}_store/g;
}
}
print $file;
}

There are 3 different perl scripts for rw, ro, and wo.
and these scripts, because of function renaming and
possible reuse of the original function names by other
string concatenated macros, create some bad conversions
so they need some manual cleanups too.

Perhaps coccinelle could do a better job of it, but
likely string concatenation macro uses are going to
be hard to deal with in any case.

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

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

[bugzilla-daemon]

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

--- Comment #16 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Andreas Brogle from comment #14)
> 60e8d3e11645a1b9c4197d9786df3894332c1685 (BAD)
> 190c3ee06a0f0660839785b7ad8a830e832d9481 (GOOD)

There are only PCI subsystem changes between those two commits. Please reassign
the product/component of this report accordingly.

-- 
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 104345] Playing video hangs X-Server with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
Please attach the output of glxinfo and vdpauinfo.

-- 
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 6/7] drm/ttm: add ttm_bo_evict_swapout_allowable to check bo is allowable to evict or swapout

[Roger He]

extract this function since eviction and swapout share same logic

Change-Id: I80a475a93fceed8d66d74a1832c815a0756341ac
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e7595b4..313925c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -706,6 +706,23 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
+static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
+   struct ttm_operation_ctx *ctx, bool *locked)
+{
+   bool ret = false;
+
+   *locked = false;
+   if (bo->resv == ctx->resv) {
+   if (ctx->allow_reserved_eviction || !list_empty(>ddestroy))
+   ret = true;
+   } else {
+   *locked = reservation_object_trylock(bo->resv);
+   ret = *locked;
+   }
+
+   return ret;
+}
+
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
   uint32_t mem_type,
   const struct ttm_place *place,
@@ -721,21 +738,13 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
-   if (bo->resv == ctx->resv) {
-   if (!ctx->allow_reserved_eviction &&
-   list_empty(>ddestroy))
-   continue;
-   } else {
-   locked = reservation_object_trylock(bo->resv);
-   if (!locked)
-   continue;
-   }
+   if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+   continue;
 
if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
if (locked)
reservation_object_unlock(bo->resv);
-   locked = false;
continue;
}
break;
-- 
2.7.4

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

[PATCH 7/7] drm/ttm: enable swapout of per VM BOs during allocation and allows reaping of deleted BOs

[Roger He]

Change-Id: I1e87954564f38ad298bf6e4ff88c9f26f291a62d
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 15 +++
 drivers/gpu/drm/ttm/ttm_memory.c | 12 
 include/drm/ttm/ttm_bo_api.h |  3 ++-
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 313925c..ecb8916 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1686,18 +1686,20 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
  * A buffer object shrink method that tries to swap out the first
  * buffer object on the bo_global::swap_lru list.
  */
-int ttm_bo_swapout(struct ttm_bo_global *glob)
+int ttm_bo_swapout(struct ttm_bo_global *glob, struct ttm_operation_ctx *ctx)
 {
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+   bool locked;
unsigned i;
 
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >swap_lru[i], swap) {
-   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
-   if (!ret)
+   if (ttm_bo_evict_swapout_allowable(bo, ctx, )) {
+   ret = 0;
break;
+   }
}
if (!ret)
break;
@@ -1773,7 +1775,12 @@ EXPORT_SYMBOL(ttm_bo_swapout);
 
 void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
 {
-   while (ttm_bo_swapout(bdev->glob) == 0)
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
+
+   while (ttm_bo_swapout(bdev->glob, ) == 0)
;
 }
 EXPORT_SYMBOL(ttm_bo_swapout_all);
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 8df0755..8817b86 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -211,7 +211,7 @@ static bool ttm_zones_above_swap_target(struct 
ttm_mem_global *glob,
  */
 
 static void ttm_shrink(struct ttm_mem_global *glob, bool from_wq,
-  uint64_t extra)
+   uint64_t extra, struct ttm_operation_ctx *ctx)
 {
int ret;
 
@@ -219,7 +219,7 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool 
from_wq,
 
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(>lock);
-   ret = ttm_bo_swapout(glob->bo_glob);
+   ret = ttm_bo_swapout(glob->bo_glob, ctx);
spin_lock(>lock);
if (unlikely(ret != 0))
break;
@@ -230,10 +230,14 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool 
from_wq,
 
 static void ttm_shrink_work(struct work_struct *work)
 {
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
struct ttm_mem_global *glob =
container_of(work, struct ttm_mem_global, work);
 
-   ttm_shrink(glob, true, 0ULL);
+   ttm_shrink(glob, true, 0ULL, );
 }
 
 static int ttm_mem_init_kernel_zone(struct ttm_mem_global *glob,
@@ -520,7 +524,7 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global 
*glob,
return -ENOMEM;
if (unlikely(count-- == 0))
return -ENOMEM;
-   ttm_shrink(glob, false, memory + (memory >> 2) + 16);
+   ttm_shrink(glob, false, memory + (memory >> 2) + 16, ctx);
}
 
return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 24a8db7..f1c74c2 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -752,7 +752,8 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file 
*filp,
  const char __user *wbuf, char __user *rbuf,
  size_t count, loff_t *f_pos, bool write);
 
-int ttm_bo_swapout(struct ttm_bo_global *glob);
+int ttm_bo_swapout(struct ttm_bo_global *glob,
+   struct ttm_operation_ctx *ctx);
 void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
 int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
 #endif
-- 
2.7.4

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

[PATCH 5/7] drm/ttm: use an operation ctx for ttm_tt_bind

[Roger He]

Change-Id: I42a7df8c50e1ce3b527ee9cb78809f8e58136f07
Signed-off-by: Roger He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c   | 2 +-
 drivers/gpu/drm/ttm/ttm_tt.c| 9 +++--
 include/drm/ttm/ttm_bo_driver.h | 3 ++-
 7 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 52aab9d..ed235b7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -497,7 +497,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object 
*bo, bool evict,
goto out_cleanup;
}
 
-   r = ttm_tt_bind(bo->ttm, _mem);
+   r = ttm_tt_bind(bo->ttm, _mem, ctx);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index b141c27..a83ba6a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1218,7 +1218,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool 
evict, bool intr,
if (ret)
return ret;
 
-   ret = ttm_tt_bind(bo->ttm, _reg);
+   ret = ttm_tt_bind(bo->ttm, _reg, );
if (ret)
goto out;
 
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 634fc6f..0f6fdc2 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -339,7 +339,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
*bo,
goto out_cleanup;
}
 
-   r = ttm_tt_bind(bo->ttm, _mem);
+   r = ttm_tt_bind(bo->ttm, _mem, );
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c59f572..e7595b4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -300,7 +300,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
goto out_err;
 
if (mem->mem_type != TTM_PL_SYSTEM) {
-   ret = ttm_tt_bind(bo->ttm, mem);
+   ret = ttm_tt_bind(bo->ttm, mem, ctx);
if (ret)
goto out_err;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index b7eb507..153de1b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -73,7 +73,7 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
return ret;
 
if (new_mem->mem_type != TTM_PL_SYSTEM) {
-   ret = ttm_tt_bind(ttm, new_mem);
+   ret = ttm_tt_bind(ttm, new_mem, ctx);
if (unlikely(ret != 0))
return ret;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index b48d7a0..5a046a3 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -261,12 +261,9 @@ void ttm_tt_unbind(struct ttm_tt *ttm)
}
 }
 
-int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem)
+int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem,
+   struct ttm_operation_ctx *ctx)
 {
-   struct ttm_operation_ctx ctx = {
-   .interruptible = false,
-   .no_wait_gpu = false
-   };
int ret = 0;
 
if (!ttm)
@@ -275,7 +272,7 @@ int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg 
*bo_mem)
if (ttm->state == tt_bound)
return 0;
 
-   ret = ttm->bdev->driver->ttm_tt_populate(ttm, );
+   ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);
if (ret)
return ret;
 
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 84860ec..94064b1 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -650,7 +650,8 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma);
  *
  * Bind the pages of @ttm to an aperture location identified by @bo_mem
  */
-int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem);
+int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem,
+   struct ttm_operation_ctx *ctx);
 
 /**
  * ttm_ttm_destroy:
-- 
2.7.4

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

[PATCH 4/7] drm/ttm: use an operation ctx for ttm_tt_populate in ttm_bo_driver

[Roger He]

Change-Id: I803ea52d11e5c06add0dffab836c3aecc00b56dd
Signed-off-by: Roger He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  7 ---
 drivers/gpu/drm/ast/ast_ttm.c|  5 +++--
 drivers/gpu/drm/cirrus/cirrus_ttm.c  |  5 +++--
 drivers/gpu/drm/nouveau/nouveau_bo.c |  8 
 drivers/gpu/drm/qxl/qxl_ttm.c|  5 +++--
 drivers/gpu/drm/radeon/radeon_ttm.c  |  9 +
 drivers/gpu/drm/ttm/ttm_agp_backend.c|  4 ++--
 drivers/gpu/drm/ttm/ttm_bo_util.c| 11 ---
 drivers/gpu/drm/ttm/ttm_bo_vm.c  |  7 ++-
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 13 +
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 11 ---
 drivers/gpu/drm/ttm/ttm_tt.c |  6 +-
 drivers/gpu/drm/virtio/virtgpu_object.c  |  6 +-
 drivers/gpu/drm/virtio/virtgpu_ttm.c |  5 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c   | 13 +
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c  | 13 +++--
 include/drm/ttm/ttm_bo_driver.h  |  5 +++--
 include/drm/ttm/ttm_page_alloc.h | 11 +++
 18 files changed, 86 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f1b7d98..52aab9d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -990,7 +990,8 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct 
ttm_bo_device *bdev,
return >ttm.ttm;
 }
 
-static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
+static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
+   struct ttm_operation_ctx *ctx)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
@@ -1018,11 +1019,11 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
 
 #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
-   return ttm_dma_populate(>ttm, adev->dev);
+   return ttm_dma_populate(>ttm, adev->dev, ctx);
}
 #endif
 
-   return ttm_populate_and_map_pages(adev->dev, >ttm);
+   return ttm_populate_and_map_pages(adev->dev, >ttm, ctx);
 }
 
 static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 28da7c2..1413e94 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -216,9 +216,10 @@ static struct ttm_tt *ast_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-static int ast_ttm_tt_populate(struct ttm_tt *ttm)
+static int ast_ttm_tt_populate(struct ttm_tt *ttm,
+   struct ttm_operation_ctx *ctx)
 {
-   return ttm_pool_populate(ttm);
+   return ttm_pool_populate(ttm, ctx);
 }
 
 static void ast_ttm_tt_unpopulate(struct ttm_tt *ttm)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 2a5b54d..95e2d40 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -216,9 +216,10 @@ static struct ttm_tt *cirrus_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-static int cirrus_ttm_tt_populate(struct ttm_tt *ttm)
+static int cirrus_ttm_tt_populate(struct ttm_tt *ttm,
+   struct ttm_operation_ctx *ctx)
 {
-   return ttm_pool_populate(ttm);
+   return ttm_pool_populate(ttm, ctx);
 }
 
 static void cirrus_ttm_tt_unpopulate(struct ttm_tt *ttm)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 6b6fb20..b141c27 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1547,7 +1547,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object 
*bo)
 }
 
 static int
-nouveau_ttm_tt_populate(struct ttm_tt *ttm)
+nouveau_ttm_tt_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
 {
struct ttm_dma_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
@@ -1572,17 +1572,17 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
 
 #if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge) {
-   return ttm_agp_tt_populate(ttm);
+   return ttm_agp_tt_populate(ttm, ctx);
}
 #endif
 
 #if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)
if (swiotlb_nr_tbl()) {
-   return ttm_dma_populate((void *)ttm, dev);
+   return ttm_dma_populate((void *)ttm, dev, ctx);
}
 #endif
 
-   r = ttm_pool_populate(ttm);
+   r = ttm_pool_populate(ttm, ctx);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 78ce118..989645c 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -291,14 +291,15 @@ static struct ttm_backend_func qxl_backend_func = {
.destroy = _ttm_backend_destroy,
 };
 
-static int qxl_ttm_tt_populate(struct ttm_tt *ttm)
+static int 

[Bug 104345] Playing video hangs X-Server with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

--- Comment #2 from bernhardu  ---
(In reply to Michel Dänzer from comment #1)
> It's more likely a Mesa or maybe LLVM issue. Did this start happening after
> you upgraded Mesa and/or LLVM, or maybe another component such as the kernel?

I get such hangs since I am using this system since april. I waited to report
it because at that time I wondered if this might be a firmware issue, as the
hardware was very new.
But after some bios updates these hangs did not resolve.
(Just mainboard firmware update, found not yet an update for the graphics
card.)
Also thought that maybe the versions in Debian Stretch would be too old.

The earliest hanging logs I have are from mid June with kernel 4.9.0-3-amd64.
There the output was a little different as there was Xorg shown as blocking:
INFO: task Xorg:1024 blocked for more than 120 seconds.
I tried every following kernel up to 4.12 via backports and upgraded at begin
of december to testing with 4.13.

-- 
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 2/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc

[Roger He]

Change-Id: I5279b5cd3560c4082b00f822219575a5f9c3808a
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
 drivers/gpu/drm/ttm/ttm_memory.c| 15 +--
 drivers/gpu/drm/ttm/ttm_object.c| 13 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_binding.c |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c  | 13 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c   |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  | 18 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_so.c  |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 12 ++--
 include/drm/ttm/ttm_memory.h|  3 ++-
 13 files changed, 87 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fa57aa8..c59f572 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1133,7 +1133,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
bool locked;
 
-   ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
+   ret = ttm_mem_global_alloc(mem_glob, acc_size, ctx);
if (ret) {
pr_err("Out of kernel memory\n");
if (destroy)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 9130bdf..525d3b6 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -508,7 +508,7 @@ static int ttm_mem_global_reserve(struct ttm_mem_global 
*glob,
 static int ttm_mem_global_alloc_zone(struct ttm_mem_global *glob,
 struct ttm_mem_zone *single_zone,
 uint64_t memory,
-bool no_wait, bool interruptible)
+struct ttm_operation_ctx *ctx)
 {
int count = TTM_MEMORY_ALLOC_RETRIES;
 
@@ -516,7 +516,7 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global 
*glob,
   single_zone,
   memory, true)
!= 0)) {
-   if (no_wait)
+   if (ctx->no_wait_gpu)
return -ENOMEM;
if (unlikely(count-- == 0))
return -ENOMEM;
@@ -527,15 +527,14 @@ static int ttm_mem_global_alloc_zone(struct 
ttm_mem_global *glob,
 }
 
 int ttm_mem_global_alloc(struct ttm_mem_global *glob, uint64_t memory,
-bool no_wait, bool interruptible)
+struct ttm_operation_ctx *ctx)
 {
/**
 * Normal allocations of kernel memory are registered in
 * all zones.
 */
 
-   return ttm_mem_global_alloc_zone(glob, NULL, memory, no_wait,
-interruptible);
+   return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx);
 }
 EXPORT_SYMBOL(ttm_mem_global_alloc);
 
@@ -544,6 +543,10 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
 {
 
struct ttm_mem_zone *zone = NULL;
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
 
/**
 * Page allocations may be registed in a single zone
@@ -557,7 +560,7 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
 #endif
-   return ttm_mem_global_alloc_zone(glob, zone, size, false, false);
+   return ttm_mem_global_alloc_zone(glob, zone, size, );
 }
 
 void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct page *page,
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index 26a7ad0..1aa2baa 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -325,6 +325,10 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
struct ttm_ref_object *ref;
struct drm_hash_item *hash;
struct ttm_mem_global *mem_glob = tfile->tdev->mem_glob;
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
int ret = -EINVAL;
 
if (base->tfile != tfile && !base->shareable)
@@ -350,7 +354,7 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
return -EPERM;
 
ret = ttm_mem_global_alloc(mem_glob, sizeof(*ref),
-  false, false);
+  );
if (unlikely(ret != 0))
return ret;
   

[PATCH 3/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc_page

[Roger He]

Change-Id: I4104a12e09a374b6477a0dd5a8fce26dce27a746
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_memory.c | 15 ---
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 +-
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  8 ++--
 include/drm/ttm/ttm_memory.h |  3 ++-
 4 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 525d3b6..8df0755 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -539,15 +539,14 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob, 
uint64_t memory,
 EXPORT_SYMBOL(ttm_mem_global_alloc);
 
 int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
- struct page *page, uint64_t size)
+ struct page *page, uint64_t size,
+ struct ttm_operation_ctx *ctx)
 {
-
+   int ret;
struct ttm_mem_zone *zone = NULL;
-   struct ttm_operation_ctx ctx = {
-   .interruptible = false,
-   .no_wait_gpu = false
-   };
+   bool tmp_no_wait_gpu = ctx->no_wait_gpu;
 
+   ctx->no_wait_gpu = false;
/**
 * Page allocations may be registed in a single zone
 * only if highmem or !dma32.
@@ -560,7 +559,9 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
 #endif
-   return ttm_mem_global_alloc_zone(glob, zone, size, );
+   ret = ttm_mem_global_alloc_zone(glob, zone, size, ctx);
+   ctx->no_wait_gpu = tmp_no_wait_gpu;
+   return ret;
 }
 
 void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct page *page,
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba644..8f93ff3 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1061,6 +1061,10 @@ void ttm_page_alloc_fini(void)
 int ttm_pool_populate(struct ttm_tt *ttm)
 {
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
unsigned i;
int ret;
 
@@ -1076,7 +1080,7 @@ int ttm_pool_populate(struct ttm_tt *ttm)
 
for (i = 0; i < ttm->num_pages; ++i) {
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
-   PAGE_SIZE);
+   PAGE_SIZE, );
if (unlikely(ret != 0)) {
ttm_pool_unpopulate(ttm);
return -ENOMEM;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index bda00b2..8aac86a 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -927,6 +927,10 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
 {
struct ttm_tt *ttm = _dma->ttm;
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false
+   };
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
enum pool_type type;
@@ -962,7 +966,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
break;
 
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
-   pool->size);
+   pool->size, );
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
@@ -998,7 +1002,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
}
 
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
-   pool->size);
+   pool->size, );
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 755c107..8936285 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -84,7 +84,8 @@ extern int ttm_mem_global_alloc(struct ttm_mem_global *glob, 
uint64_t memory,
 extern void ttm_mem_global_free(struct ttm_mem_global *glob,
uint64_t amount);
 extern int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
-struct page *page, uint64_t size);
+struct page *page, uint64_t size,
+struct 

[PATCH 1/7] drm/ttm: call ttm_bo_swapout directly when ttm shrink

[Roger He]

then remove superfluous functions

Change-Id: Iea020f0e30a239e0265e7a1500168c7d7f819bd9
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 21 +++-
 drivers/gpu/drm/ttm/ttm_memory.c | 12 ++-
 include/drm/ttm/ttm_bo_api.h |  1 +
 include/drm/ttm/ttm_bo_driver.h  |  1 -
 include/drm/ttm/ttm_memory.h | 69 +---
 5 files changed, 9 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 60bb5c1..fa57aa8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 
-static int ttm_bo_swapout(struct ttm_mem_shrink *shrink);
 static void ttm_bo_global_kobj_release(struct kobject *kobj);
 
 static struct attribute ttm_bo_count = {
@@ -1454,7 +1453,6 @@ static void ttm_bo_global_kobj_release(struct kobject 
*kobj)
struct ttm_bo_global *glob =
container_of(kobj, struct ttm_bo_global, kobj);
 
-   ttm_mem_unregister_shrink(glob->mem_glob, >shrink);
__free_page(glob->dummy_read_page);
kfree(glob);
 }
@@ -1479,6 +1477,7 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
mutex_init(>device_list_mutex);
spin_lock_init(>lru_lock);
glob->mem_glob = bo_ref->mem_glob;
+   glob->mem_glob->bo_glob = glob;
glob->dummy_read_page = alloc_page(__GFP_ZERO | GFP_DMA32);
 
if (unlikely(glob->dummy_read_page == NULL)) {
@@ -1489,14 +1488,6 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
INIT_LIST_HEAD(>swap_lru[i]);
INIT_LIST_HEAD(>device_list);
-
-   ttm_mem_init_shrink(>shrink, ttm_bo_swapout);
-   ret = ttm_mem_register_shrink(glob->mem_glob, >shrink);
-   if (unlikely(ret != 0)) {
-   pr_err("Could not register buffer object swapout\n");
-   goto out_no_shrink;
-   }
-
atomic_set(>bo_count, 0);
 
ret = kobject_init_and_add(
@@ -1504,8 +1495,6 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
if (unlikely(ret != 0))
kobject_put(>kobj);
return ret;
-out_no_shrink:
-   __free_page(glob->dummy_read_page);
 out_no_drp:
kfree(glob);
return ret;
@@ -1688,11 +1677,8 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
  * A buffer object shrink method that tries to swap out the first
  * buffer object on the bo_global::swap_lru list.
  */
-
-static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
+int ttm_bo_swapout(struct ttm_bo_global *glob)
 {
-   struct ttm_bo_global *glob =
-   container_of(shrink, struct ttm_bo_global, shrink);
struct ttm_buffer_object *bo;
int ret = -EBUSY;
unsigned i;
@@ -1774,10 +1760,11 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
kref_put(>list_kref, ttm_bo_release_list);
return ret;
 }
+EXPORT_SYMBOL(ttm_bo_swapout);
 
 void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
 {
-   while (ttm_bo_swapout(>glob->shrink) == 0)
+   while (ttm_bo_swapout(bdev->glob) == 0)
;
 }
 EXPORT_SYMBOL(ttm_bo_swapout_all);
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index e963749..9130bdf 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -214,26 +214,20 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool 
from_wq,
   uint64_t extra)
 {
int ret;
-   struct ttm_mem_shrink *shrink;
 
spin_lock(>lock);
-   if (glob->shrink == NULL)
-   goto out;
 
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
-   shrink = glob->shrink;
spin_unlock(>lock);
-   ret = shrink->do_shrink(shrink);
+   ret = ttm_bo_swapout(glob->bo_glob);
spin_lock(>lock);
if (unlikely(ret != 0))
-   goto out;
+   break;
}
-out:
+
spin_unlock(>lock);
 }
 
-
-
 static void ttm_shrink_work(struct work_struct *work)
 {
struct ttm_mem_global *glob =
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index c126330..24a8db7 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -752,6 +752,7 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file 
*filp,
  const char __user *wbuf, char __user *rbuf,
  size_t count, loff_t *f_pos, bool write);
 
+int ttm_bo_swapout(struct ttm_bo_global *glob);
 void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
 int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
 #endif
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 5115718..934fecf 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -522,7 +522,6 @@ 

Re: [PATCH 3/3] drm/i915: Disable all planes for load detection, v2.

[Daniel Vetter]

On Wed, Dec 20, 2017 at 10:35:45AM +0100, Maarten Lankhorst wrote:
> From: Ville Syrjälä 
> 
> We don't need any active planes during load detection, so just disable
> them all. This saves us from having to come up with a suitable
> framebuffer. And we also avoid leaving sprite/cursor planes on and
> potentially presenting them at a peculiar location during the load
> detection.
> 
> Changes since v1 (Maarten):
> - Add missing call to add_all_affected_planes.
> 
> Signed-off-by: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102707

Less code, I like. And I think we have enough load-detect machines (+ plus
the nasty igt to do it anywhere we still have native vga) to have
reasonable ensurance it actually works.

But maybe let's soak this in -next first for a while, then cherry-pick
over after a few weeks once it's solid.

With the missing Fixes: line added.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 147 
> +--
>  1 file changed, 18 insertions(+), 129 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7e833268c9df..ef61f9a75c93 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9689,111 +9689,27 @@ intel_framebuffer_create(struct drm_i915_gem_object 
> *obj,
>   return ERR_PTR(ret);
>  }
>  
> -static u32
> -intel_framebuffer_pitch_for_width(int width, int bpp)
> -{
> - u32 pitch = DIV_ROUND_UP(width * bpp, 8);
> - return ALIGN(pitch, 64);
> -}
> -
> -static u32
> -intel_framebuffer_size_for_mode(const struct drm_display_mode *mode, int bpp)
> -{
> - u32 pitch = intel_framebuffer_pitch_for_width(mode->hdisplay, bpp);
> - return PAGE_ALIGN(pitch * mode->vdisplay);
> -}
> -
> -static struct drm_framebuffer *
> -intel_framebuffer_create_for_mode(struct drm_device *dev,
> -   const struct drm_display_mode *mode,
> -   int depth, int bpp)
> -{
> - struct drm_framebuffer *fb;
> - struct drm_i915_gem_object *obj;
> - struct drm_mode_fb_cmd2 mode_cmd = { 0 };
> -
> - obj = i915_gem_object_create(to_i915(dev),
> - intel_framebuffer_size_for_mode(mode, bpp));
> - if (IS_ERR(obj))
> - return ERR_CAST(obj);
> -
> - mode_cmd.width = mode->hdisplay;
> - mode_cmd.height = mode->vdisplay;
> - mode_cmd.pitches[0] = intel_framebuffer_pitch_for_width(mode_cmd.width,
> - bpp);
> - mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);
> -
> - fb = intel_framebuffer_create(obj, _cmd);
> - if (IS_ERR(fb))
> - i915_gem_object_put(obj);
> -
> - return fb;
> -}
> -
> -static struct drm_framebuffer *
> -mode_fits_in_fbdev(struct drm_device *dev,
> -const struct drm_display_mode *mode)
> -{
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_i915_gem_object *obj;
> - struct drm_framebuffer *fb;
> -
> - if (!dev_priv->fbdev)
> - return NULL;
> -
> - if (!dev_priv->fbdev->fb)
> - return NULL;
> -
> - obj = dev_priv->fbdev->fb->obj;
> - BUG_ON(!obj);
> -
> - fb = _priv->fbdev->fb->base;
> - if (fb->pitches[0] < intel_framebuffer_pitch_for_width(mode->hdisplay,
> -
> fb->format->cpp[0] * 8))
> - return NULL;
> -
> - if (obj->base.size < mode->vdisplay * fb->pitches[0])
> - return NULL;
> -
> - drm_framebuffer_get(fb);
> - return fb;
> -#else
> - return NULL;
> -#endif
> -}
> -
> -static int intel_modeset_setup_plane_state(struct drm_atomic_state *state,
> -struct drm_crtc *crtc,
> -const struct drm_display_mode *mode,
> -struct drm_framebuffer *fb,
> -int x, int y)
> +static int intel_modeset_disable_planes(struct drm_atomic_state *state,
> + struct drm_crtc *crtc)
>  {
> + struct drm_plane *plane;
>   struct drm_plane_state *plane_state;
> - int hdisplay, vdisplay;
> - int ret;
> -
> - plane_state = drm_atomic_get_plane_state(state, crtc->primary);
> - if (IS_ERR(plane_state))
> - return PTR_ERR(plane_state);
> -
> - if (mode)
> - drm_mode_get_hv_timing(mode, , );
> - else
> - hdisplay = vdisplay = 0;
> + int ret, i;
>  
> - ret = drm_atomic_set_crtc_for_plane(plane_state, fb ? crtc : NULL);
> + ret = 

Re: [PATCH 2/3] drm/framebuffer: Print task that allocated the fb in debug info.

[Daniel Vetter]

On Wed, Dec 20, 2017 at 10:35:44AM +0100, Maarten Lankhorst wrote:
> This is is very useful to finding sources of leaked framebufers.
> The fbcon fb is annotated with [fbcon], to give it a better name
> than kworker.
> 
> Signed-off-by: Maarten Lankhorst 

I think we can polish this more later on, it's a good start.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_fb_helper.c   | 1 +
>  drivers/gpu/drm/drm_framebuffer.c | 2 ++
>  include/drm/drm_framebuffer.h | 6 ++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 04a3a5ce370a..d396d74a7dda 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1848,6 +1848,7 @@ static int drm_fb_helper_single_fb_probe(struct 
> drm_fb_helper *fb_helper,
>   if (ret < 0)
>   return ret;
>  
> + strcpy(fb_helper->fb->comm, "[fbcon]");
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index d63d4c2ac4c8..5a13ff29f4f0 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -664,6 +664,7 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
> drm_framebuffer *fb,
>   INIT_LIST_HEAD(>filp_head);
>  
>   fb->funcs = funcs;
> + strcpy(fb->comm, current->comm);
>  
>   ret = __drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_FB,
>   false, drm_framebuffer_free);
> @@ -978,6 +979,7 @@ void drm_framebuffer_print_info(struct drm_printer *p, 
> unsigned int indent,
>   struct drm_format_name_buf format_name;
>   unsigned int i;
>  
> + drm_printf_indent(p, indent, "allocated by = %s\n", fb->comm);
>   drm_printf_indent(p, indent, "refcount=%u\n",
> drm_framebuffer_read_refcount(fb));
>   drm_printf_indent(p, indent, "format=%s\n",
> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> index dccb897951ba..c50502c656e5 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -121,6 +121,12 @@ struct drm_framebuffer {
>* @base: base modeset object structure, contains the reference count.
>*/
>   struct drm_mode_object base;
> +
> + /**
> +  * @comm: Name of the process allocating the fb, used for fb dumping.
> +  */
> + char comm[TASK_COMM_LEN];
> +
>   /**
>* @format: framebuffer format information
>*/
> -- 
> 2.15.1
> 
> ___
> 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 1/3] drm/plane: Make framebuffer refcounting the responsibility of setplane_internal callers

[Daniel Vetter]

On Wed, Dec 20, 2017 at 10:35:43AM +0100, Maarten Lankhorst wrote:
> lock_all_ctx in setplane_internal may return -EINTR, and
> __setplane_internal could return -EDEADLK. Making more
> special cases for fb would make the code even harder to
> read, so the easiest solution is not taking over the fb
> refcount, and making callers responsible for dropping
> the ref.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102707
> Fixes: 13736ba3b38b ("drm/legacy: Convert setplane ioctl locking to 
> interruptible.")
> Testcase: kms_atomic_interruptible
> Signed-off-by: Maarten Lankhorst 

I thought I reviewed this one before already, but probably just a paste
somewhere on irc.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_plane.c | 42 --
>  1 file changed, 20 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 37a93cdffb4a..2c90519576a3 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -558,11 +558,10 @@ int drm_plane_check_pixel_format(const struct drm_plane 
> *plane, u32 format)
>  }
>  
>  /*
> - * setplane_internal - setplane handler for internal callers
> + * __setplane_internal - setplane handler for internal callers
>   *
> - * Note that we assume an extra reference has already been taken on fb.  If 
> the
> - * update fails, this reference will be dropped before return; if it 
> succeeds,
> - * the previous framebuffer (if any) will be unreferenced instead.
> + * This function will take a reference on the new fb for the plane
> + * on success.
>   *
>   * src_{x,y,w,h} are provided in 16.16 fixed point format
>   */
> @@ -630,14 +629,12 @@ static int __setplane_internal(struct drm_plane *plane,
>   if (!ret) {
>   plane->crtc = crtc;
>   plane->fb = fb;
> - fb = NULL;
> + drm_framebuffer_get(plane->fb);
>   } else {
>   plane->old_fb = NULL;
>   }
>  
>  out:
> - if (fb)
> - drm_framebuffer_put(fb);
>   if (plane->old_fb)
>   drm_framebuffer_put(plane->old_fb);
>   plane->old_fb = NULL;
> @@ -685,6 +682,7 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
>   struct drm_plane *plane;
>   struct drm_crtc *crtc = NULL;
>   struct drm_framebuffer *fb = NULL;
> + int ret;
>  
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
> @@ -717,15 +715,16 @@ int drm_mode_setplane(struct drm_device *dev, void 
> *data,
>   }
>   }
>  
> - /*
> -  * setplane_internal will take care of deref'ing either the old or new
> -  * framebuffer depending on success.
> -  */
> - return setplane_internal(plane, crtc, fb,
> -  plane_req->crtc_x, plane_req->crtc_y,
> -  plane_req->crtc_w, plane_req->crtc_h,
> -  plane_req->src_x, plane_req->src_y,
> -  plane_req->src_w, plane_req->src_h);
> + ret = setplane_internal(plane, crtc, fb,
> + plane_req->crtc_x, plane_req->crtc_y,
> + plane_req->crtc_w, plane_req->crtc_h,
> + plane_req->src_x, plane_req->src_y,
> + plane_req->src_w, plane_req->src_h);
> +
> + if (fb)
> + drm_framebuffer_put(fb);
> +
> + return ret;
>  }
>  
>  static int drm_mode_cursor_universal(struct drm_crtc *crtc,
> @@ -788,13 +787,12 @@ static int drm_mode_cursor_universal(struct drm_crtc 
> *crtc,
>   src_h = fb->height << 16;
>   }
>  
> - /*
> -  * setplane_internal will take care of deref'ing either the old or new
> -  * framebuffer depending on success.
> -  */
>   ret = __setplane_internal(crtc->cursor, crtc, fb,
> - crtc_x, crtc_y, crtc_w, crtc_h,
> - 0, 0, src_w, src_h, ctx);
> +   crtc_x, crtc_y, crtc_w, crtc_h,
> +   0, 0, src_w, src_h, ctx);
> +
> + if (fb)
> + drm_framebuffer_put(fb);
>  
>   /* Update successful; save new cursor position, if necessary */
>   if (ret == 0 && req->flags & DRM_MODE_CURSOR_MOVE) {
> -- 
> 2.15.1
> 
> ___
> 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: [RFC PATCH v2 00/13] Kernel based bootsplash

[Daniel Vetter]

On Wed, Dec 20, 2017 at 11:06:34AM +0100, Neil Armstrong wrote:
> On 20/12/2017 10:43, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
> >> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> >>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt  wrote:
>  Well, those could enable fbcon if they want the bootsplash. Shouldn't 
>  make a difference anyway if they're powerful enough to run Linux. As 
>  long as the bootsplash is shown, no fbcon drawing operations are 
>  executed, so there is no expensive scrolling or such to hog the system.
> >>>
> >>> It's too big, and those folks tend to be super picky about space.
> >>
> >> I know, they really are.
> >>
> >> However, given just how big and clunky modern systems have become, I
> >> raise my doubts about a few extra KB for fbcon code to be relevant.
> >>
> >> My feeling is that the kernel splash probably saves even more space on
> >> the userspace side than it adds on the kernel side, thus netting a
> >> reduction in overall code size.
> >>
> >>
> >>> So essentially you're telling me that on a current general purpose
> >>> distro the gfx driver loading is a dumpster fire, and we're fixing
> >>> this by ignoring it an adding a hole new layer on top. That doesn't
> >>> sound like any kind of good idea to me.
> >>
> >> Yes. It is a vast improvement over the status quo, and people are asking
> >> for it. And the bootsplash layer can be moved elsewhere, just change the
> >> hooks and keep the loading/rendering.
> >>
> >> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It
> >> just mustn't be done 100% carelessly.
> > 
> > You've talked about using sleep and stuff to paper over races. That
> > doesn't sound good at all.
> > 
> >>> So if just using drm for everything isn't possible (since drm drivers
> >>> can at least in theory be hotunplugged), can we at least fix the
> >>> existing fbdev kernel bugs? Not being able to unplug a drm driver when
> >>> it's still open sounds like a rather serious issues that probably
> >>> should be fixed anyway ... so we're better able to hotunplug an fbdev
> >>> driver when it's in use.
> >>
> >> I don't see it as a bug. The fbdev driver gets unloaded as much as
> >> possible, but as long as a userspace application keeps the address_space
> >> mmap()ed, there's nothing we can do, short of forcibly removing it and
> >> segfaulting the process the next time it tries to render something. Am I
> >> missing something?
> > 
> > I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering
> > in a sighandler and abort if you hit that. In drm we try to be a bit
> > better and keep things around until userspace has gone.
> > 
> >>> Also I'm not clear at all on the "papering over races with sleeps"
> >>> part. DRM drivers shouldn't be racy when getting loaded ...
> >>
> >> The DRM driver loading isn't racy, but the fbdev can't be fully unloaded
> >> while Plymouth has the address_space mmap()ed. If Plymouth sleeps until
> >> drivers that are included in initramfs are (hopefully) loaded, then it
> >> will forego using its FB backend.
> >>
> >> A solution we've experimented with is dropping the FB backend from
> >> Plymouth. It instantly fixed the busy video RAM bug. However it made the
> >> folks relying on efifb very, very unhappy.
> >>
> >>
> >>> Or we get simpledrm merged (for efifb and vesafb support) and someone
> >>> types the xendrm driver (there is floating around, it's just old) and
> >>> we could forget about any real fbdev drivers except the drm based
> >>> ones.
> >>
> >> And drmcon, unless we come up with a better idea than hooking into the 
> >> *con driver.
> > 
> > If we have everything as drm drivers, you can just use plymouth (with no
> > fbdev backend ofc) and everyone is happy. Including the efifb folks (it's
> > simply going to be called efidrmfb or something like that). So no idea why
> > you need a *con.
> > 
> >> Sure, that'd help a lot. But what do we do until then?
> > 
> > Make it happen? Twiddling thumbs is an option too ofc, but it tends to not
> > result in results :-)
> > 
> > Cheers, Daniel
> > 
> 
> My 2cents about this patchset:
> You did a good job about all the animation and splash logic, but for me all 
> this fbcon
> stuff is a huge hack, please use a standard and modern display subsystem en 
> leave fbcon
> die alone
> 
> My DRM ARM systems would love to have such bootsplash, so please, make it 
> happen using DRM
> then leave the fbcon based stuff like efifb migrate to DRM in a second time !

btw since I'm probably sounding a bit too grumpy here: I'd very much
support this. I think bootsplash in kernel has a bunch of uses, and it
shouldn't be hard to get non-suse people to cheer for it (makes merging
easier if it's not just a one-off hack).

But I'm really not sold on the current integration path being anywhere
near close to a good idea long-term.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel 

[Bug 104345] Playing video hangs X-Server with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #1 from Michel Dänzer  ---
It's more likely a Mesa or maybe LLVM issue. Did this start happening after you
upgraded Mesa and/or LLVM, or maybe another component such as the kernel?

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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Neil Armstrong]

On 20/12/2017 10:43, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
>> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
>>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt  wrote:
 Well, those could enable fbcon if they want the bootsplash. Shouldn't make 
 a difference anyway if they're powerful enough to run Linux. As long as 
 the bootsplash is shown, no fbcon drawing operations are executed, so 
 there is no expensive scrolling or such to hog the system.
>>>
>>> It's too big, and those folks tend to be super picky about space.
>>
>> I know, they really are.
>>
>> However, given just how big and clunky modern systems have become, I
>> raise my doubts about a few extra KB for fbcon code to be relevant.
>>
>> My feeling is that the kernel splash probably saves even more space on
>> the userspace side than it adds on the kernel side, thus netting a
>> reduction in overall code size.
>>
>>
>>> So essentially you're telling me that on a current general purpose
>>> distro the gfx driver loading is a dumpster fire, and we're fixing
>>> this by ignoring it an adding a hole new layer on top. That doesn't
>>> sound like any kind of good idea to me.
>>
>> Yes. It is a vast improvement over the status quo, and people are asking
>> for it. And the bootsplash layer can be moved elsewhere, just change the
>> hooks and keep the loading/rendering.
>>
>> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It
>> just mustn't be done 100% carelessly.
> 
> You've talked about using sleep and stuff to paper over races. That
> doesn't sound good at all.
> 
>>> So if just using drm for everything isn't possible (since drm drivers
>>> can at least in theory be hotunplugged), can we at least fix the
>>> existing fbdev kernel bugs? Not being able to unplug a drm driver when
>>> it's still open sounds like a rather serious issues that probably
>>> should be fixed anyway ... so we're better able to hotunplug an fbdev
>>> driver when it's in use.
>>
>> I don't see it as a bug. The fbdev driver gets unloaded as much as
>> possible, but as long as a userspace application keeps the address_space
>> mmap()ed, there's nothing we can do, short of forcibly removing it and
>> segfaulting the process the next time it tries to render something. Am I
>> missing something?
> 
> I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering
> in a sighandler and abort if you hit that. In drm we try to be a bit
> better and keep things around until userspace has gone.
> 
>>> Also I'm not clear at all on the "papering over races with sleeps"
>>> part. DRM drivers shouldn't be racy when getting loaded ...
>>
>> The DRM driver loading isn't racy, but the fbdev can't be fully unloaded
>> while Plymouth has the address_space mmap()ed. If Plymouth sleeps until
>> drivers that are included in initramfs are (hopefully) loaded, then it
>> will forego using its FB backend.
>>
>> A solution we've experimented with is dropping the FB backend from
>> Plymouth. It instantly fixed the busy video RAM bug. However it made the
>> folks relying on efifb very, very unhappy.
>>
>>
>>> Or we get simpledrm merged (for efifb and vesafb support) and someone
>>> types the xendrm driver (there is floating around, it's just old) and
>>> we could forget about any real fbdev drivers except the drm based
>>> ones.
>>
>> And drmcon, unless we come up with a better idea than hooking into the *con 
>> driver.
> 
> If we have everything as drm drivers, you can just use plymouth (with no
> fbdev backend ofc) and everyone is happy. Including the efifb folks (it's
> simply going to be called efidrmfb or something like that). So no idea why
> you need a *con.
> 
>> Sure, that'd help a lot. But what do we do until then?
> 
> Make it happen? Twiddling thumbs is an option too ofc, but it tends to not
> result in results :-)
> 
> Cheers, Daniel
> 

My 2cents about this patchset:
You did a good job about all the animation and splash logic, but for me all 
this fbcon
stuff is a huge hack, please use a standard and modern display subsystem en 
leave fbcon
die alone

My DRM ARM systems would love to have such bootsplash, so please, make it 
happen using DRM
then leave the fbcon based stuff like efifb migrate to DRM in a second time !

Neil

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

[Bug 104345] Playing video hangs X-Server with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

Bug ID: 104345
   Summary: Playing video hangs X-Server with showing scrambled
picture, sound still playing.
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bernha...@mailbox.org

Created attachment 136312
  --> https://bugs.freedesktop.org/attachment.cgi?id=136312=edit
kernel output captured from the serial line.

Playing video hangs X-Server with showing scrambled picture, sound still
playing.

System hangs after some time playing mostly when playing a recorded DVB-S-SD
stream via VLC. Happened also with other videos and players.

This left the system showing a distorted version of the last shown frame from
the video. Most of the time it is a chess board like pattern.
Sound is still playing regularly.
A ssh connection is still possible.

Playing the exact same video again later works without problem.


Kernel output shows at this time following:

[ 4353.316286] amdgpu :08:00.0: GPU fault detected: 146 0x0570480c
[ 4353.328836] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001004AE
[ 4353.343791] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0A04800C
[ 4353.358755] amdgpu :08:00.0: VM fault (0x0c, vmid 5) at page 1049774,
read from 'TC0' (0x54433000) (72)
[ 4353.378234] amdgpu :08:00.0: GPU fault detected: 146 0x0570440c
[ 4353.390777] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0010049C
[ 4353.405735] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0A04400C
[ 4353.420692] amdgpu :08:00.0: VM fault (0x0c, vmid 5) at page 1049756,
read from 'TC1' (0x54433100) (68)

Followed by this:

[ 4592.681352] INFO: task amdgpu_cs:0:1007 blocked for more than 120 seconds.
[ 4592.695116]   Tainted: G   O4.13.0-1-amd64 #1 Debian
4.13.13-1
[ 4592.709587] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 4592.725255] amdgpu_cs:0 D0  1007   1000 0x0040
[ 4592.736245] Call Trace:
[ 4592.741145]  ? __schedule+0x3c8/0x860
[ 4592.748486]  ? schedule+0x32/0x80
[ 4592.755120]  ? schedule_timeout+0x1da/0x350
[ 4592.763537]  ? amdgpu_vm_validate_level.isra.9+0x80/0x80 [amdgpu]
[ 4592.775725]  ? dma_fence_default_wait+0x239/0x260
[ 4592.785138]  ? dma_fence_default_wait+0x239/0x260
[ 4592.794548]  ? dma_fence_free+0x20/0x20
[ 4592.802220]  ? dma_fence_wait_timeout+0x33/0xe0
[ 4592.811317]  ? amdgpu_ctx_add_fence+0x61/0xf0 [amdgpu]
[ 4592.821632]  ? amdgpu_cs_ioctl+0x156b/0x1920 [amdgpu]
[ 4592.831784]  ? amdgpu_cs_find_mapping+0x90/0x90 [amdgpu]
[ 4592.842432]  ? drm_ioctl_kernel+0x65/0xb0 [drm]
[ 4592.851510]  ? drm_ioctl+0x2e3/0x3a0 [drm]
[ 4592.859737]  ? amdgpu_cs_find_mapping+0x90/0x90 [amdgpu]
[ 4592.870373]  ? do_futex+0x2df/0xa90
[ 4592.877376]  ? amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 4592.886971]  ? do_vfs_ioctl+0x9f/0x600
[ 4592.894471]  ? SyS_futex+0x7a/0x170
[ 4592.901453]  ? SyS_ioctl+0x74/0x80
[ 4592.908264]  ? system_call_fast_compare_end+0xc/0x97

Attached is a log captured on the serial port from boot to the
crash follwed by a Magic-Sys-Req-T.

This are the system specs:

Graphics:  Card: Advanced Micro Devices [AMD/ATI] Baffin [Radeon RX 460] (XFX)
   Display Server: x11 (X.Org 1.19.5 ) drivers: amdgpu (unloaded:
modesetting,fbdev,vesa)
   Resolution: 1920x1080@60.00hz
   OpenGL: renderer: AMD Radeon RX 460 Graphics (AMD POLARIS11 / DRM
3.18.0 / 4.13.0-1-amd64, LLVM 5.0.0)
   version: 4.5 Mesa 17.2.5
System:Kernel: 4.13.0-1-amd64 x86_64 bits: 64
Desktop:   KDE Plasma 5.10.5
Machine:   Device: desktop Mobo: ASUSTeK model: PRIME B350M-A v: Rev X.0x
serial: N/A
   UEFI: American Megatrends v: 3203 date: 11/09/2017
CPU:   Octa core AMD Ryzen 7 1700 Eight-Core (-HT-MCP-) speed/max:
1550/3000 MHz

Error happened with Debian Stretch with linux 4.9 and later.
Currently it is running a Debian testing.

Is this the right product/component for this report?

-- 
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 104331] [r600g] Ogre demo "TutorialUAV01" crash at r600_decompress_color_images

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
(In reply to MWATTT from comment #2)
> However, the demo does not render properly(I don't know if I should make
> another report for that).

Please do.

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

Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Daniel Vetter]

On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote:
> I forgot to include this brief information about this patch series.
> 
> This patch series contains the implementation of a new device driver,
> hyper_dmabuf, which provides a method for DMA-BUF sharing across
> different OSes running on the same virtual OS platform powered by
> a hypervisor.
> 
> Detailed information about this driver is described in a high-level doc
> added by the second patch of the series.
> 
> [RFC PATCH 02/60] hyper_dmabuf: added a doc for hyper_dmabuf sharing
> 
> I am attaching 'Overview' section here as a summary.
> 
> --
> Section 1. Overview
> --
> 
> Hyper_DMABUF driver is a Linux device driver running on multiple Virtual
> achines (VMs), which expands DMA-BUF sharing capability to the VM environment
> where multiple different OS instances need to share same physical data without
> data-copy across VMs.
> 
> To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the
> exporting VM (so called, “exporter”) imports a local DMA_BUF from the original
> producer of the buffer, then re-exports it with an unique ID, hyper_dmabuf_id
> for the buffer to the importing VM (so called, “importer”).
> 
> Another instance of the Hyper_DMABUF driver on importer registers
> a hyper_dmabuf_id together with reference information for the shared physical
> pages associated with the DMA_BUF to its database when the export happens.
> 
> The actual mapping of the DMA_BUF on the importer’s side is done by
> the Hyper_DMABUF driver when user space issues the IOCTL command to access
> the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and
> exporting driver as is, that is, no special configuration is required.
> Consequently, only a single module per VM is needed to enable cross-VM DMA_BUF
> exchange.

So I know that most dma-buf implementations (especially lots of importers
in drivers/gpu) break this, but fundamentally only the original exporter
is allowed to know about the underlying pages. There's various scenarios
where a dma-buf isn't backed by anything like a struct page.

So your first step of noodling the underlying struct page out from the
dma-buf is kinda breaking the abstraction, and I think it's not a good
idea to have that. Especially not for sharing across VMs.

I think a better design would be if hyper-dmabuf would be the dma-buf
exporter in both of the VMs, and you'd import it everywhere you want to in
some gpu/video/whatever driver in the VMs. That way hyper-dmabuf is always
in control of the pages, and a lot of the troubling forwarding you
currently need to do disappears.

2nd thing: This seems very much related to what's happening around gvt and
allowing at least the host (in a kvm based VM environment) to be able to
access some of the dma-buf (or well, framebuffers in general) that the
client is using. Adding some mailing lists for that.
-Daniel

> 
> --
> 
> There is a git repository at github.com where this series of patches are all
> integrated in Linux kernel tree based on the commit:
> 
> commit ae64f9bd1d3621b5e60d7363bc20afb46aede215
> Author: Linus Torvalds 
> Date:   Sun Dec 3 11:01:47 2017 -0500
> 
> Linux 4.15-rc2
> 
> https://github.com/downor/linux_hyper_dmabuf.git hyper_dmabuf_integration_v3
> 
> ___
> 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: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 01:54:41AM -0800, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:32 +0100, Greg Kroah-Hartman wrote:
> > On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> > > On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > > > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > > > > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
> > > 
> > > [] 
> > > > > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
> > > 
> > > []
> > > > > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device 
> > > > > *dev,
> > > > >   return size;
> > > > >  }
> > > > >  
> > > > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, 
> > > > > dma_op_mode_store);
> > > > > +static DEVICE_ATTR_RW(dma_op_mode);
> > > > >  
> > > > 
> > > > While I can ack this part here if it helps generic cleanup effort I
> > > > don't understart would it improve code readability in general? Mode 644
> > > > is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to 
> > > > go
> > > > through all of these files in order to see what does it mean:
> > 
> > Yeah, 644 is "clear", but _RW() is even more clear.  Ideally I want to
> > get rid of all of the "non-standard" users that set random modes of
> > sysfs files, as we get it wrong too many times.  Using the "defaults" is
> > much better.
> > 
> > > Are you suggesting that device.h (as that is where
> > > DEVICE_ATTR and the other DEVICE_ATTR_ variants
> > > are #defined) should have better comments for the
> > > _ variants?
> > > 
> > > > DEVICE_ATTR_RW: include/linux/device.h
> > > > __ATTR_RW: include/linux/sysfs.h
> > > > S_IWUSR: include/uapi/linux/stat.h
> > > > S_IRUGO: include/linux/stat.h
> > > 
> > > btw: patch 1/4 of the series does remove the uses of
> > > S_ from these macros in sysfs.h and converts
> > > them to simple octal instead.
> > 
> > Why you didn't send that patch to the sysfs maintainer is a bit odd...  :)
> 
> So here's an opportunity for you:
> 
> The sysfs maintainer hasn't added include/linux/sysfs.h to
> the list of maintained files...
> 
> DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
> M:Greg Kroah-Hartman 
> T:git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> S:Supported
> F:Documentation/kobject.txt
> F:drivers/base/
> F:fs/debugfs/
> F:fs/sysfs/
> F:include/linux/debugfs.h
> F:include/linux/kobj*
> F:lib/kobj*

Heh, good point, but using get_maintainer.pl does put me at the top of
the list that you should be cc:ing:

$ ./scripts/get_maintainer.pl --file include/linux/sysfs.h
Greg Kroah-Hartman  
(commit_signer:3/3=100%,authored:2/3=67%,added_lines:7/8=88%)
Kate Stewart  (commit_signer:1/3=33%)
Thomas Gleixner  (commit_signer:1/3=33%)
Philippe Ombredanne  (commit_signer:1/3=33%)
Nick Desaulniers  
(commit_signer:1/3=33%,authored:1/3=33%,added_lines:1/8=12%,removed_lines:1/1=100%)
linux-ker...@vger.kernel.org (open list)

Anyway, I'll go add sysfs.h to the list, thanks for pointing it out.

> > I should be taking this whole series through my tree.  Joe, thanks for
> > doing this in an automated way, I've been wanting to see this done for a
> > long time.
> 
> btw: there are many uses of a reversed declaration style of DEVICE_ATTR
> 
> Here's another thing that could be done for more DEVICE_ATTR_ uses.
> 
> ===
> 
> Some DEVICE_ATTR definitions use a reversed static function form from
> the typical.  Convert them to use the more common macro form so it is
> easier to grep for the style.
> 
> i.e.:
> static ssize_t show_(...)
> and
> static ssize_t store_(...)
> 
> where the static function names in the DEVICE_ATTR_RW macro are reversed
> 
> static ssize_t _show(...)
> and
> static ssize_t _store(...)
> 
> Done with perl script
> 
> $ cat dev_attr_rw_backwards.perl
> local $/;
> while (<>) {
> my $file = $_;
> while ($file =~ m/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,/g) {
> my $var = $1;
> if ($file =~ 
> s/\bDEVICE_ATTR\s*\(\s*${var}\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S
> $file =~ s/\bshow_${var}\b/${var}_show/g;
> $file =~ s/\bstore_${var}\b/${var}_store/g;
> }
> }
> print $file;
> }
> 
> $ git grep --name-only -w DEVICE_ATTR | \
>   xargs perl -i dev_attr_rw_backwards.perl
> 

Ah, nice, I love perl :)

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

[Bug 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
(In reply to Alex_Zhang1 from comment #7)

Without the patch referenced in comment 3, a buffer must be pinned to VRAM
before it can be scanned out (displayed). The problem described in this report
happens because pinning to VRAM fails, because there isn't enough space in
VRAM. The patch allows buffers to be pinned to GTT instead of VRAM for scanout.
Another DC patch is probably needed to fix the garbled display described in
comment 4. Maybe try the patch on top of the amd-staging-drm-next branch.

-- 
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: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Joe Perches]

On Wed, 2017-12-20 at 10:32 +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> > On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > > > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
> > 
> > [] 
> > > > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
> > 
> > []
> > > > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device *dev,
> > > > return size;
> > > >  }
> > > >  
> > > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, 
> > > > dma_op_mode_store);
> > > > +static DEVICE_ATTR_RW(dma_op_mode);
> > > >  
> > > 
> > > While I can ack this part here if it helps generic cleanup effort I
> > > don't understart would it improve code readability in general? Mode 644
> > > is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to go
> > > through all of these files in order to see what does it mean:
> 
> Yeah, 644 is "clear", but _RW() is even more clear.  Ideally I want to
> get rid of all of the "non-standard" users that set random modes of
> sysfs files, as we get it wrong too many times.  Using the "defaults" is
> much better.
> 
> > Are you suggesting that device.h (as that is where
> > DEVICE_ATTR and the other DEVICE_ATTR_ variants
> > are #defined) should have better comments for the
> > _ variants?
> > 
> > > DEVICE_ATTR_RW: include/linux/device.h
> > > __ATTR_RW: include/linux/sysfs.h
> > > S_IWUSR: include/uapi/linux/stat.h
> > > S_IRUGO: include/linux/stat.h
> > 
> > btw: patch 1/4 of the series does remove the uses of
> > S_ from these macros in sysfs.h and converts
> > them to simple octal instead.
> 
> Why you didn't send that patch to the sysfs maintainer is a bit odd...  :)

So here's an opportunity for you:

The sysfs maintainer hasn't added include/linux/sysfs.h to
the list of maintained files...

DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
M:  Greg Kroah-Hartman 
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
S:  Supported
F:  Documentation/kobject.txt
F:  drivers/base/
F:  fs/debugfs/
F:  fs/sysfs/
F:  include/linux/debugfs.h
F:  include/linux/kobj*
F:  lib/kobj*

> I should be taking this whole series through my tree.  Joe, thanks for
> doing this in an automated way, I've been wanting to see this done for a
> long time.

btw: there are many uses of a reversed declaration style of DEVICE_ATTR

Here's another thing that could be done for more DEVICE_ATTR_ uses.

===

Some DEVICE_ATTR definitions use a reversed static function form from
the typical.  Convert them to use the more common macro form so it is
easier to grep for the style.

i.e.:
static ssize_t show_(...)
and
static ssize_t store_(...)

where the static function names in the DEVICE_ATTR_RW macro are reversed

static ssize_t _show(...)
and
static ssize_t _store(...)

Done with perl script

$ cat dev_attr_rw_backwards.perl
local $/;
while (<>) {
my $file = $_;
while ($file =~ m/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,/g) {
my $var = $1;
if ($file =~ s/\bDEVICE_ATTR\s*\(\s*${var}\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S
$file =~ s/\bshow_${var}\b/${var}_show/g;
$file =~ s/\bstore_${var}\b/${var}_store/g;
}
}
print $file;
}

$ git grep --name-only -w DEVICE_ATTR | \
  xargs perl -i dev_attr_rw_backwards.perl


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

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

[Daniel Vetter]

On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote:
> On 12/19/2017 05:02 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt  wrote:
> >> On 12/19/2017 02:57 PM, Daniel Vetter wrote:
> >>> The problem is that defio is totally not how a real driver works.
> >>
> >> But they do exist and I can't ignore them.
> >>
> >> I'm afraid I don't understand - why are those, such as xenfb, not real 
> >> drivers?
> > 
> > I mean kms drivers. The problem is that the magic mapping that fbdev
> > expects is real pain. Everyone else, including kms, expects an
> > explicit flush operation. So instead of hacking around even more with
> > the defio corner cases that don't work, I'm suggesting we just add
> > that flush operation. At least internally.
> > 
> > Fixing kms drivers to implement a better defio is probably not a
> > reasonable investement of time.
> 
> Ah yes, I understand now, you mean that KMS drivers have explicit flush,
> and defio is a hack to retrofit such drivers to an API that never
> supported a flush operation (the fbdev API), but always used to expose
> the video memory directly. Right?
> 
> If yes, then I agree. Fixing the defio in the KMS drivers wouldn't even
> solve my problem - I'd still need to implement flush. So might as well
> care about the flush straight away, yep!

Yup.

I'll leave the more fundamental discussion to the other thread on the
cover letter.
-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: [RFC PATCH v2 00/13] Kernel based bootsplash

[Daniel Vetter]

On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt  wrote:
> >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make 
> >> a difference anyway if they're powerful enough to run Linux. As long as 
> >> the bootsplash is shown, no fbcon drawing operations are executed, so 
> >> there is no expensive scrolling or such to hog the system.
> > 
> > It's too big, and those folks tend to be super picky about space.
> 
> I know, they really are.
> 
> However, given just how big and clunky modern systems have become, I
> raise my doubts about a few extra KB for fbcon code to be relevant.
> 
> My feeling is that the kernel splash probably saves even more space on
> the userspace side than it adds on the kernel side, thus netting a
> reduction in overall code size.
> 
> 
> > So essentially you're telling me that on a current general purpose
> > distro the gfx driver loading is a dumpster fire, and we're fixing
> > this by ignoring it an adding a hole new layer on top. That doesn't
> > sound like any kind of good idea to me.
> 
> Yes. It is a vast improvement over the status quo, and people are asking
> for it. And the bootsplash layer can be moved elsewhere, just change the
> hooks and keep the loading/rendering.
> 
> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It
> just mustn't be done 100% carelessly.

You've talked about using sleep and stuff to paper over races. That
doesn't sound good at all.

> > So if just using drm for everything isn't possible (since drm drivers
> > can at least in theory be hotunplugged), can we at least fix the
> > existing fbdev kernel bugs? Not being able to unplug a drm driver when
> > it's still open sounds like a rather serious issues that probably
> > should be fixed anyway ... so we're better able to hotunplug an fbdev
> > driver when it's in use.
> 
> I don't see it as a bug. The fbdev driver gets unloaded as much as
> possible, but as long as a userspace application keeps the address_space
> mmap()ed, there's nothing we can do, short of forcibly removing it and
> segfaulting the process the next time it tries to render something. Am I
> missing something?

I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering
in a sighandler and abort if you hit that. In drm we try to be a bit
better and keep things around until userspace has gone.

> > Also I'm not clear at all on the "papering over races with sleeps"
> > part. DRM drivers shouldn't be racy when getting loaded ...
> 
> The DRM driver loading isn't racy, but the fbdev can't be fully unloaded
> while Plymouth has the address_space mmap()ed. If Plymouth sleeps until
> drivers that are included in initramfs are (hopefully) loaded, then it
> will forego using its FB backend.
> 
> A solution we've experimented with is dropping the FB backend from
> Plymouth. It instantly fixed the busy video RAM bug. However it made the
> folks relying on efifb very, very unhappy.
> 
> 
> > Or we get simpledrm merged (for efifb and vesafb support) and someone
> > types the xendrm driver (there is floating around, it's just old) and
> > we could forget about any real fbdev drivers except the drm based
> > ones.
> 
> And drmcon, unless we come up with a better idea than hooking into the *con 
> driver.

If we have everything as drm drivers, you can just use plymouth (with no
fbdev backend ofc) and everyone is happy. Including the efifb folks (it's
simply going to be called efidrmfb or something like that). So no idea why
you need a *con.

> Sure, that'd help a lot. But what do we do until then?

Make it happen? Twiddling thumbs is an option too ofc, but it tends to not
result in results :-)

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

[PATCH 1/3] drm/plane: Make framebuffer refcounting the responsibility of setplane_internal callers

[Maarten Lankhorst]

lock_all_ctx in setplane_internal may return -EINTR, and
__setplane_internal could return -EDEADLK. Making more
special cases for fb would make the code even harder to
read, so the easiest solution is not taking over the fb
refcount, and making callers responsible for dropping
the ref.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102707
Fixes: 13736ba3b38b ("drm/legacy: Convert setplane ioctl locking to 
interruptible.")
Testcase: kms_atomic_interruptible
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_plane.c | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 37a93cdffb4a..2c90519576a3 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -558,11 +558,10 @@ int drm_plane_check_pixel_format(const struct drm_plane 
*plane, u32 format)
 }
 
 /*
- * setplane_internal - setplane handler for internal callers
+ * __setplane_internal - setplane handler for internal callers
  *
- * Note that we assume an extra reference has already been taken on fb.  If the
- * update fails, this reference will be dropped before return; if it succeeds,
- * the previous framebuffer (if any) will be unreferenced instead.
+ * This function will take a reference on the new fb for the plane
+ * on success.
  *
  * src_{x,y,w,h} are provided in 16.16 fixed point format
  */
@@ -630,14 +629,12 @@ static int __setplane_internal(struct drm_plane *plane,
if (!ret) {
plane->crtc = crtc;
plane->fb = fb;
-   fb = NULL;
+   drm_framebuffer_get(plane->fb);
} else {
plane->old_fb = NULL;
}
 
 out:
-   if (fb)
-   drm_framebuffer_put(fb);
if (plane->old_fb)
drm_framebuffer_put(plane->old_fb);
plane->old_fb = NULL;
@@ -685,6 +682,7 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
struct drm_plane *plane;
struct drm_crtc *crtc = NULL;
struct drm_framebuffer *fb = NULL;
+   int ret;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -717,15 +715,16 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
}
}
 
-   /*
-* setplane_internal will take care of deref'ing either the old or new
-* framebuffer depending on success.
-*/
-   return setplane_internal(plane, crtc, fb,
-plane_req->crtc_x, plane_req->crtc_y,
-plane_req->crtc_w, plane_req->crtc_h,
-plane_req->src_x, plane_req->src_y,
-plane_req->src_w, plane_req->src_h);
+   ret = setplane_internal(plane, crtc, fb,
+   plane_req->crtc_x, plane_req->crtc_y,
+   plane_req->crtc_w, plane_req->crtc_h,
+   plane_req->src_x, plane_req->src_y,
+   plane_req->src_w, plane_req->src_h);
+
+   if (fb)
+   drm_framebuffer_put(fb);
+
+   return ret;
 }
 
 static int drm_mode_cursor_universal(struct drm_crtc *crtc,
@@ -788,13 +787,12 @@ static int drm_mode_cursor_universal(struct drm_crtc 
*crtc,
src_h = fb->height << 16;
}
 
-   /*
-* setplane_internal will take care of deref'ing either the old or new
-* framebuffer depending on success.
-*/
ret = __setplane_internal(crtc->cursor, crtc, fb,
-   crtc_x, crtc_y, crtc_w, crtc_h,
-   0, 0, src_w, src_h, ctx);
+ crtc_x, crtc_y, crtc_w, crtc_h,
+ 0, 0, src_w, src_h, ctx);
+
+   if (fb)
+   drm_framebuffer_put(fb);
 
/* Update successful; save new cursor position, if necessary */
if (ret == 0 && req->flags & DRM_MODE_CURSOR_MOVE) {
-- 
2.15.1

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

[PATCH 3/3] drm/i915: Disable all planes for load detection, v2.

[Maarten Lankhorst]

From: Ville Syrjälä 

We don't need any active planes during load detection, so just disable
them all. This saves us from having to come up with a suitable
framebuffer. And we also avoid leaving sprite/cursor planes on and
potentially presenting them at a peculiar location during the load
detection.

Changes since v1 (Maarten):
- Add missing call to add_all_affected_planes.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102707
---
 drivers/gpu/drm/i915/intel_display.c | 147 +--
 1 file changed, 18 insertions(+), 129 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7e833268c9df..ef61f9a75c93 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9689,111 +9689,27 @@ intel_framebuffer_create(struct drm_i915_gem_object 
*obj,
return ERR_PTR(ret);
 }
 
-static u32
-intel_framebuffer_pitch_for_width(int width, int bpp)
-{
-   u32 pitch = DIV_ROUND_UP(width * bpp, 8);
-   return ALIGN(pitch, 64);
-}
-
-static u32
-intel_framebuffer_size_for_mode(const struct drm_display_mode *mode, int bpp)
-{
-   u32 pitch = intel_framebuffer_pitch_for_width(mode->hdisplay, bpp);
-   return PAGE_ALIGN(pitch * mode->vdisplay);
-}
-
-static struct drm_framebuffer *
-intel_framebuffer_create_for_mode(struct drm_device *dev,
- const struct drm_display_mode *mode,
- int depth, int bpp)
-{
-   struct drm_framebuffer *fb;
-   struct drm_i915_gem_object *obj;
-   struct drm_mode_fb_cmd2 mode_cmd = { 0 };
-
-   obj = i915_gem_object_create(to_i915(dev),
-   intel_framebuffer_size_for_mode(mode, bpp));
-   if (IS_ERR(obj))
-   return ERR_CAST(obj);
-
-   mode_cmd.width = mode->hdisplay;
-   mode_cmd.height = mode->vdisplay;
-   mode_cmd.pitches[0] = intel_framebuffer_pitch_for_width(mode_cmd.width,
-   bpp);
-   mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);
-
-   fb = intel_framebuffer_create(obj, _cmd);
-   if (IS_ERR(fb))
-   i915_gem_object_put(obj);
-
-   return fb;
-}
-
-static struct drm_framebuffer *
-mode_fits_in_fbdev(struct drm_device *dev,
-  const struct drm_display_mode *mode)
-{
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_i915_gem_object *obj;
-   struct drm_framebuffer *fb;
-
-   if (!dev_priv->fbdev)
-   return NULL;
-
-   if (!dev_priv->fbdev->fb)
-   return NULL;
-
-   obj = dev_priv->fbdev->fb->obj;
-   BUG_ON(!obj);
-
-   fb = _priv->fbdev->fb->base;
-   if (fb->pitches[0] < intel_framebuffer_pitch_for_width(mode->hdisplay,
-  
fb->format->cpp[0] * 8))
-   return NULL;
-
-   if (obj->base.size < mode->vdisplay * fb->pitches[0])
-   return NULL;
-
-   drm_framebuffer_get(fb);
-   return fb;
-#else
-   return NULL;
-#endif
-}
-
-static int intel_modeset_setup_plane_state(struct drm_atomic_state *state,
-  struct drm_crtc *crtc,
-  const struct drm_display_mode *mode,
-  struct drm_framebuffer *fb,
-  int x, int y)
+static int intel_modeset_disable_planes(struct drm_atomic_state *state,
+   struct drm_crtc *crtc)
 {
+   struct drm_plane *plane;
struct drm_plane_state *plane_state;
-   int hdisplay, vdisplay;
-   int ret;
-
-   plane_state = drm_atomic_get_plane_state(state, crtc->primary);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
-
-   if (mode)
-   drm_mode_get_hv_timing(mode, , );
-   else
-   hdisplay = vdisplay = 0;
+   int ret, i;
 
-   ret = drm_atomic_set_crtc_for_plane(plane_state, fb ? crtc : NULL);
+   ret = drm_atomic_add_affected_planes(state, crtc);
if (ret)
return ret;
-   drm_atomic_set_fb_for_plane(plane_state, fb);
-   plane_state->crtc_x = 0;
-   plane_state->crtc_y = 0;
-   plane_state->crtc_w = hdisplay;
-   plane_state->crtc_h = vdisplay;
-   plane_state->src_x = x << 16;
-   plane_state->src_y = y << 16;
-   plane_state->src_w = hdisplay << 16;
-   plane_state->src_h = vdisplay << 16;
+
+   for_each_new_plane_in_state(state, plane, plane_state, i) {
+   if (plane_state->crtc != crtc)
+   continue;
+
+   

[PATCH 2/3] drm/framebuffer: Print task that allocated the fb in debug info.

[Maarten Lankhorst]

This is is very useful to finding sources of leaked framebufers.
The fbcon fb is annotated with [fbcon], to give it a better name
than kworker.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_fb_helper.c   | 1 +
 drivers/gpu/drm/drm_framebuffer.c | 2 ++
 include/drm/drm_framebuffer.h | 6 ++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 04a3a5ce370a..d396d74a7dda 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1848,6 +1848,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
if (ret < 0)
return ret;
 
+   strcpy(fb_helper->fb->comm, "[fbcon]");
return 0;
 }
 
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index d63d4c2ac4c8..5a13ff29f4f0 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -664,6 +664,7 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
INIT_LIST_HEAD(>filp_head);
 
fb->funcs = funcs;
+   strcpy(fb->comm, current->comm);
 
ret = __drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_FB,
false, drm_framebuffer_free);
@@ -978,6 +979,7 @@ void drm_framebuffer_print_info(struct drm_printer *p, 
unsigned int indent,
struct drm_format_name_buf format_name;
unsigned int i;
 
+   drm_printf_indent(p, indent, "allocated by = %s\n", fb->comm);
drm_printf_indent(p, indent, "refcount=%u\n",
  drm_framebuffer_read_refcount(fb));
drm_printf_indent(p, indent, "format=%s\n",
diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index dccb897951ba..c50502c656e5 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -121,6 +121,12 @@ struct drm_framebuffer {
 * @base: base modeset object structure, contains the reference count.
 */
struct drm_mode_object base;
+
+   /**
+* @comm: Name of the process allocating the fb, used for fb dumping.
+*/
+   char comm[TASK_COMM_LEN];
+
/**
 * @format: framebuffer format information
 */
-- 
2.15.1

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

[PATCH 0/3] drm: Plug framebuffer leaks.

[Maarten Lankhorst]

There's a small leak excerbated by interruptible waiting in setplane_internal,
which was triggered by kms_atomic. Another leak is in load detection, and easily
plugged by just removing the fb handling.

Maarten Lankhorst (2):
  drm/plane: Make framebuffer refcounting the responsibility of
setplane_internal callers
  drm/framebuffer: Print task that allocated the fb in debug info.

Ville Syrjälä (1):
  drm/i915: Disable all planes for load detection, v2.

 drivers/gpu/drm/drm_fb_helper.c  |   1 +
 drivers/gpu/drm/drm_framebuffer.c|   2 +
 drivers/gpu/drm/drm_plane.c  |  42 +-
 drivers/gpu/drm/i915/intel_display.c | 147 +--
 include/drm/drm_framebuffer.h|   6 ++
 5 files changed, 47 insertions(+), 151 deletions(-)

-- 
2.15.1

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

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

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

--- Comment #11 from Charles (ylang-yl...@libertysurf.fr) ---
Hi team,

Just to say... same error :

[drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!

with 4.15-rc4

(on the same noteboook)

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

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
> [] 
> > > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
> []
> > > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device *dev,
> > >   return size;
> > >  }
> > >  
> > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, 
> > > dma_op_mode_store);
> > > +static DEVICE_ATTR_RW(dma_op_mode);
> > >  
> > 
> > While I can ack this part here if it helps generic cleanup effort I
> > don't understart would it improve code readability in general? Mode 644
> > is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to go
> > through all of these files in order to see what does it mean:

Yeah, 644 is "clear", but _RW() is even more clear.  Ideally I want to
get rid of all of the "non-standard" users that set random modes of
sysfs files, as we get it wrong too many times.  Using the "defaults" is
much better.

> Are you suggesting that device.h (as that is where
> DEVICE_ATTR and the other DEVICE_ATTR_ variants
> are #defined) should have better comments for the
> _ variants?
> 
> > DEVICE_ATTR_RW: include/linux/device.h
> > __ATTR_RW: include/linux/sysfs.h
> > S_IWUSR: include/uapi/linux/stat.h
> > S_IRUGO: include/linux/stat.h
> 
> btw: patch 1/4 of the series does remove the uses of
> S_ from these macros in sysfs.h and converts
> them to simple octal instead.

Why you didn't send that patch to the sysfs maintainer is a bit odd...  :)

I should be taking this whole series through my tree.  Joe, thanks for
doing this in an automated way, I've been wanting to see this done for a
long time.

thanks,

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

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Joe Perches]

On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
[] 
> > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
[]
> > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device *dev,
> > return size;
> >  }
> >  
> > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, dma_op_mode_store);
> > +static DEVICE_ATTR_RW(dma_op_mode);
> >  
> 
> While I can ack this part here if it helps generic cleanup effort I
> don't understart would it improve code readability in general? Mode 644
> is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to go
> through all of these files in order to see what does it mean:

Are you suggesting that device.h (as that is where
DEVICE_ATTR and the other DEVICE_ATTR_ variants
are #defined) should have better comments for the
_ variants?

> DEVICE_ATTR_RW: include/linux/device.h
> __ATTR_RW: include/linux/sysfs.h
> S_IWUSR: include/uapi/linux/stat.h
> S_IRUGO: include/linux/stat.h

btw: patch 1/4 of the series does remove the uses of
S_ from these macros in sysfs.h and converts
them to simple octal instead.

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

Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_

[Corey Minyard]

On 12/19/2017 12:15 PM, Joe Perches wrote:

  drivers/char/ipmi/ipmi_msghandler.c| 17 +++---


For ipmi:

Acked-by: Corey Minyard 

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

Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Juergen Gross]

On 20/12/17 00:27, Dongwon Kim wrote:
> I forgot to include this brief information about this patch series.
> 
> This patch series contains the implementation of a new device driver,
> hyper_dmabuf, which provides a method for DMA-BUF sharing across
> different OSes running on the same virtual OS platform powered by
> a hypervisor.

Some general remarks regarding this series:

You are starting the whole driver in drivers/xen/ and in the last patch
you move it over to drivers/dma-buf/. Why don't you use drivers/dma-buf/
from the beginning? The same applies to e.g. patch 22 changing the
license. Please make it easier for the reviewers by not letting us
review the development history of your work.

Please run ./scripts/checkpatch.pl on each patch and correct the issues
it is reporting. At the first glance I've seen several style problems
which I won't comment until the next round.

Please add the maintainers as Cc:, not only the related mailing lists.
As you seem to aim supporting other hypervisors than Xen you might want
to add virtualizat...@lists.linux-foundation.org as well.


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

Re: [trivial PATCH] treewide: Align function definition open/close braces

[Mauro Carvalho Chehab]

Em Sun, 17 Dec 2017 16:28:44 -0800
Joe Perches  escreveu:

> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
> 
> Move those braces to column 1.
> 
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
> 
> Miscellanea:
> 
> o Remove extra trailing ; and blank line from xfs_agf_verify
> 
> Signed-off-by: Joe Perches 

For the media patch:

Acked-by: Mauro Carvalho Chehab 

> ---
> git diff -w shows no difference other than the above 'Miscellanea'
> 
> (this is against -next, but it applies against Linus' tree
>  with a couple offsets)
> 
>  arch/x86/include/asm/atomic64_32.h   |  2 +-
>  drivers/acpi/custom_method.c |  2 +-
>  drivers/acpi/fan.c   |  2 +-
>  drivers/gpu/drm/amd/display/dc/core/dc.c |  2 +-
>  drivers/media/i2c/msp3400-kthreads.c |  2 +-
>  drivers/message/fusion/mptsas.c  |  2 +-
>  drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c |  2 +-
>  drivers/net/wireless/ath/ath9k/xmit.c|  2 +-
>  drivers/platform/x86/eeepc-laptop.c  |  2 +-
>  drivers/rtc/rtc-ab-b5ze-s3.c |  2 +-
>  drivers/scsi/dpt_i2o.c   |  2 +-
>  drivers/scsi/sym53c8xx_2/sym_glue.c  |  2 +-
>  fs/locks.c   |  2 +-
>  fs/ocfs2/stack_user.c|  2 +-
>  fs/xfs/libxfs/xfs_alloc.c|  5 ++---
>  fs/xfs/xfs_export.c  |  2 +-
>  kernel/audit.c   |  6 +++---
>  kernel/trace/trace_printk.c  |  4 ++--
>  lib/raid6/sse2.c | 14 +++---
>  sound/soc/fsl/fsl_dma.c  |  2 +-
>  20 files changed, 30 insertions(+), 31 deletions(-)
> 
> diff --git a/arch/x86/include/asm/atomic64_32.h 
> b/arch/x86/include/asm/atomic64_32.h
> index 97c46b8169b7..d4d4883080fa 100644
> --- a/arch/x86/include/asm/atomic64_32.h
> +++ b/arch/x86/include/asm/atomic64_32.h
> @@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
>   long long r;
>   alternative_atomic64(read, "=" (r), "c" (v) : "memory");
>   return r;
> - }
> +}
>  
>  /**
>   * atomic64_add_return - add and return
> diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
> index c68e72414a67..e967c1173ba3 100644
> --- a/drivers/acpi/custom_method.c
> +++ b/drivers/acpi/custom_method.c
> @@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
>  {
>   if (cm_dentry)
>   debugfs_remove(cm_dentry);
> - }
> +}
>  
>  module_init(acpi_custom_method_init);
>  module_exit(acpi_custom_method_exit);
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 6cf4988206f2..3563103590c6 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, 
> unsigned long state)
>   return fan_set_state_acpi4(device, state);
>   else
>   return fan_set_state(device, state);
> - }
> +}
>  
>  static const struct thermal_cooling_device_ops fan_cooling_ops = {
>   .get_max_state = fan_get_max_state,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d1488d5ee028..1e0d1e7c5324 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct 
> dc_state *context)
>   
> **/
>  
>  struct dc *dc_create(const struct dc_init_data *init_params)
> - {
> +{
>   struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
>   unsigned int full_pipe_count;
>  
> diff --git a/drivers/media/i2c/msp3400-kthreads.c 
> b/drivers/media/i2c/msp3400-kthreads.c
> index 4dd01e9f553b..dc6cb8d475b3 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
>  }
>  
>  static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
> - {
> +{
>   struct msp_state *state = to_state(i2c_get_clientdata(client));
>   int source, matrix;
>  
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
> index 345f6035599e..69a62d23514b 100644
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -2968,7 +2968,7 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
>   mutex_unlock(>sas_mgmt.mutex);
>  out:
>   return ret;
> - }
> +}
>  
>  static void
>  

Re: [Bug 198123] Console is the wrong color at boot with radeon 6670

[Peter Rosin]

On 2017-12-18 12:37, Michel Dänzer wrote:
> 
> Following up by e-mail, since I can't find Peter Rosin in the kernel
> bugzilla.
> 
> 
> On 2017-12-16 02:41 AM, bugzilla-dae...@bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198123
>>
>> --- Comment #8 from Deposite Pirate (dpir...@metalpunks.info) ---
>> Ok, I went through all the git bisect process. Here are the results:
>>
>> [...]
>>
>> b8e2b0199cc377617dc238f5106352c06dcd3fa2 is the first bad commit
>> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
>> Author: Peter Rosin 
>> Date:   Tue Jul 4 12:36:57 2017 +0200
>>
>> drm/fb-helper: factor out pseudo-palette
>>
>> 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 
>> Signed-off-by: Daniel Vetter 
>> Link:
>> http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-p...@axentia.se
>>
>> :04 04 a8c2650554e199fee994ac63c2700c73ba2ecffe
>> 7f72ed414efadd77ef1d718e7477475c4ba1127d M  drivers
> 
> My guess would be this is because fb_helper->funcs->gamma_set is no
> longer called from drm_fb_helper_setcmap in the FB_VISUAL_TRUECOLOR case
> (was previously called via setcolreg).

No, that's not right, fb_helper->funcs->gamma_set() wasn't called for the
FB_VISUAL_TRUECOLOR case before the commit either.

However, crtc_funcs->load_lut() was called, but that operation is now
gone in a later cleanup. However#2, that ->load_lut() did not use anything
that was provided in the call to drm_fb_helper_setcmap, since the load_lut
implementations generally didn't look at the pseudo_palette variable. So,
the now-missing ->load_lut() call probably just reloaded the clut?

> Peter, how is the hardware CLUT intended to be initialized in that case
> with this change?

I thought that truecolor visuals didn't have any hardware clut. Seems
like an easy enough mistake to make, and I still don't get it...

I don't know what the correct behavior is since I don't get what is
going on with that, but I assume it should be fairly easy to rearrange
things so that a write to the hw clut is triggered.

Are we sure that FB_VISUAL_TRUECOLOR is involved at all? Why? Or is that
just a red herring?

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

Re: [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

[Tony Lindgren]

* Tomi Valkeinen  [171219 10:51]:
> On 11/12/17 17:22, Tony Lindgren wrote:
> > * H. Nikolaus Schaller  [171201 07:44]:
> > > Official vendor string is now "tpo" and not "toppoly".
> > > 
> > > Requires patch "omapdrm: panel: fix compatible vendor string for 
> > > td028ttec1"
> > > so that the driver understands both.
> > 
> > Tomi, so what's the plan with the dependency patch, is that for v4.16
> > or for the v4.15-rc cycle?
> 
> The dependency patch for this one is queued for v4.16 (I just sent a pull
> request today). I could pick this one up (if you give an ack) if I send
> another DRM pull request, but I probably don't have anything else to send so
> most likely I won't pick this up for v4.16.

OK thanks I'll queue both of these for v4.16 then.

> The patch 2/2 in the series doesn't have dependencies and can be applied as
> a fix for 4.15, or for 4.16.
> 
> Neither of these are critical, as things work fine without these patches.

OK thanks for confirming that.

Regards,

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

Re: [PATCH] kthread: finer-grained lockdep/cross-release completion

[Byungchul Park]

On 12/19/2017 6:59 PM, Daniel Vetter wrote:

On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:

On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter  wrote:


This didn't seem to have made it into -rc4. Anything needed to get it
going?


Do you actually see the problem in -rc4?

Because we ended up removing the cross-release checking due to other
developers complaining. It seemed to need a lot more work before it
was ready.

So I suspect the patch is simply not relevant any more (even if it's
not necessarily wrong either).


Awww ... I like the cross release stuff, it's catching lots of good bugs
for us - writing a gpu memory manager that's supposed to interface with
the core one ain't the simplest thing to get right. That's also why we're
going around and fixing up fallout (we've worked on the worker annotations
for 4.14 too). I guess next release, hopefully.

I think between 4.14 and 4.15 attemps cross-release spotted around 5 or so
genuine deadlocks in i915 code. And at least right now, with the current
set of fixups our CI runs are splat-free. So at least a Kconfig option
would be nice, to be able to enable it easily when you want to.

Wrt us not noticing: Getting the patches in through normal means takes too
long, so we constantly carry arounda  bunch of fixup patches to address
serious issues that block CI (no lockdep is no good CI). That's why we
won't immediately notice when an issue is resolved some other way.


Hello Ingo and Linus,

IMO, taking it off by default is enough. What fs folk actually
wanted is not to remove whole stuff but make it off by default.

Cross-release logic itself makes sense. Please consider it back
and apply my patch making it off by default.

I will do what I can do for the classification in layered fs.

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

Re: [PATCH] drm/rockchip: analogix_dp: Ensure that the bridge is powered before poking it

[Marc Zyngier]

On 19/12/17 07:55, Andrzej Hajda wrote:
> On 18.12.2017 12:28, Marc Zyngier wrote:
>> Stopping the X display manager on a kevin platform results in the
>> following crash:
>>
>> [  674.833536] Synchronous External Abort: synchronous external abort 
>> (0x9610) at 0x0c970640
>> [  674.843886] Internal error: : 9610 [#1] PREEMPT SMP
>> [  674.849744] Modules linked in:
>> [  674.849755] CPU: 1 PID: 86 Comm: kworker/1:1 Not tainted 
>> 4.15.0-rc3-00057-gff24f8cf492d-dirty #3
>> [  674.849760] detected fb_set_par error, error code: -16
>> [  674.849761] Hardware name: Google Kevin (DT)
>> [  674.849773] Workqueue: events analogix_dp_psr_work
>> [  674.849778] pstate: 6005 (nZCv daif -PAN -UAO)
>> [  674.849784] pc : analogix_dp_send_psr_spd+0x8/0x168
>> [  674.849788] lr : analogix_dp_enable_psr+0x54/0x60
>> [  674.849789] sp : 09b2bd60
>> [  674.849790] x29: 09b2bd60 x28: 
>> [  674.849794] x27: 09913d20 x26: 0900fbf0
>> [  674.849797] x25: 8000f1b3 x24: 8000f0c21d98
>> [  674.849800] x23:  x22: 8000f7d3aa00
>> [  674.849803] x21: 8000f7d36980 x20: 8000f0c21c18
>> [  674.849806] x19: 8000f0c21db8 x18: 0001
>> [  674.849809] x17: 89f2ed58 x16: 08222908
>> [  674.849812] x15:  x14: 0400
>> [  674.849815] x13: 0400 x12: 
>> [  674.849817] x11: 1414 x10: 0a00
>> [  674.849820] x9 : 09b2bbb0 x8 : 8000f1b30a60
>> [  674.849823] x7 : 0008 x6 : 0001
>> [  674.849826] x5 : 0010 x4 : 0007
>> [  674.849829] x3 : 0002 x2 : 0c970640
>> [  674.849832] x1 : 09b2bd78 x0 : 8000f1624018
>> [  674.849836] Process kworker/1:1 (pid: 86, stack limit = 
>> 0x83e5f7c3)
>> [  674.849838] Call trace:
>> [  674.849842]  analogix_dp_send_psr_spd+0x8/0x168
>> [  674.849844]  analogix_dp_psr_work+0x9c/0xa0
>> [  674.849849]  process_one_work+0x1cc/0x328
>> [  674.849852]  worker_thread+0x50/0x450
>> [  674.849856]  kthread+0xf8/0x128
>> [  674.849860]  ret_from_fork+0x10/0x18
>> [  674.849864] Code: b901 d65f03c0 f9445802 91190042 (b9400042)
>>
>> Further investigation show that this happens because the the workqueue
>> races with the analogix_dp_bridge_disable() call from the core DRM code,
>> and end up trying to write to the DP bridge that has already been powered
>> down. This result is a very black screen, and a hard reset.
>>
>> Instead of counting on luck to keep the bridge alive, let's use the
>> pm_runtime framework and take a reference on the device when we're about
>> to poke it. That is a fairly big hammer, but one that allows the system
>> to stay alive across dozens of X start/stop sequences.
> 
> Wouldn't be better to cancel the work in analogix_dp_bridge_disable, it
> looks safer.

Not sure. That would only cancel a single work that would be in flight
right when we hit disable, but won't prevent the work from being queued
right after the cancel.

In summary, I think you're trading a race between pm_runtime_put_sync
and analogix_dp_send_psr_spd for another between cancel_work_sync and
analogix_dp_send_psr_spd. Also, I seem to remember that the disable can
occur in its own work queue:

commit_tail -> drm_atomic_helper_commit_modeset_disables ->
disable_outputs -> drm_bridge_disable -> analogix_dp_bridge_disable

making it racy by nature. But I'm no DRM expert (as you can probably tell).

My approach is to guarantee that analogix_dp_send_psr_spd cannot fault
due to the IP being powered off, which feels a bit more bullet proof.

Please shoot me down if I got it wrong!

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel