[PATCH 1/5] Revert "drm/amd/dal: Fix underlay pipe and pipe count for Stoney"

[PATCH 1/5] Revert "drm/amd/dal: Fix underlay pipe and pipe count for Stoney"

[Christian König]

From: Harry Wentland <harry.wentland@amd.com>

This reverts commit 4a183f66e543f697271f2ef717fb72aed071e968.

Change-Id: I331ab0afccf55bd4e50890c64f354249993fb20a
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
---
 drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c b/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c
index 0258aba..9187b34 100644
--- a/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c
@@ -1053,15 +1053,14 @@ static bool construct(
 	 *************************************************/
 
 	pool->base.pipe_count = 3;
-	pool->base.stream_enc_count = 3;
 	pool->base.underlay_pipe_index = 3;
 
 	if (ASIC_REV_IS_STONEY(asic_id.hw_internal_rev)) {
 		pool->base.pipe_count = 2;
-		pool->base.stream_enc_count = 2;
 		pool->base.underlay_pipe_index = 2;
 	}
 
+	pool->base.stream_enc_count = 3;
 	dc->public.caps.max_downscale_ratio = 150;
 	dc->public.caps.i2c_speed_in_khz = 100;
 
-- 
2.5.0

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

[PATCH 2/5] dma-buf/fence: make timeout handling in fence_default_wait consistent

[Christian König]

From: Christian König <christian.koenig@amd.com>

Kernel functions taking a timeout usually return 1 on success even
when they get a zero timeout.

Signen-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
---
 drivers/dma-buf/fence.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 4d51f9e..fb915ab 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -335,18 +335,20 @@ fence_default_wait_cb(struct fence *fence, struct fence_cb *cb)
  * @timeout:	[in]	timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
  *
  * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the
- * remaining timeout in jiffies on success.
+ * remaining timeout in jiffies on success. If timeout is zero the value one is
+ * returned if the fence is already signaled for consistency with other
+ * functions taking a jiffies timeout.
  */
 signed long
 fence_default_wait(struct fence *fence, bool intr, signed long timeout)
 {
 	struct default_wait_cb cb;
 	unsigned long flags;
-	signed long ret = timeout;
+	signed long ret = timeout ? timeout : 1;
 	bool was_set;
 
 	if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags))
-		return timeout;
+		return ret;
 
 	spin_lock_irqsave(fence->lock, flags);
 
-- 
2.5.0

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

[PATCH 3/5] dma-buf/fence: revert "don't wait when specified timeout is zero"

[Christian König]

From: Christian König <christian.koenig@amd.com>

This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.

When we don't call the wait function software signaling might never be
activated. This can cause infinite polling loops with unreliable interrupt
driven hardware.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
---
 drivers/dma-buf/fence.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index fb915ab..64478f9 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -159,9 +159,6 @@ fence_wait_timeout(struct fence *fence, bool intr, signed long timeout)
 	if (WARN_ON(timeout < 0))
 		return -EINVAL;
 
-	if (timeout == 0)
-		return fence_is_signaled(fence);
-
 	trace_fence_wait_start(fence);
 	ret = fence->ops->wait(fence, intr, timeout);
 	trace_fence_wait_end(fence);
-- 
2.5.0

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

[PATCH 4/5] drm/ttm: fix ttm_bo_wait

[Christian König]

From: Christian König <christian.koenig@amd.com>

reservation_object_wait_timeout_rcu() should enable signaling even with a zero
timeout, but ttm_bo_wait() can also be called from atomic context and then it
is not a good idea to do this.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/ttm/ttm_bo.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 608c585..478d563 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1605,7 +1605,14 @@ EXPORT_SYMBOL(ttm_bo_unmap_virtual);
 int ttm_bo_wait(struct ttm_buffer_object *bo,
 		bool interruptible, bool no_wait)
 {
-	long timeout = no_wait ? 0 : 15 * HZ;
+	long timeout = 15 * HZ;
+
+	if (no_wait) {
+		if (reservation_object_test_signaled_rcu(bo->resv, true))
+			return 0;
+		else
+			return -EBUSY;
+	}
 
 	timeout = reservation_object_wait_timeout_rcu(bo->resv, true,
 						      interruptible, timeout);
-- 
2.5.0

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

[PATCH 5/5] reservation: revert "wait only with non-zero timeout specified (v3)" v2

[Christian König]

From: Christian König <christian.koenig@amd.com>

This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.

Otherwise signaling might never be activated on the fences. This can
result in infinite waiting with hardware which has unreliable interrupts.

v2: still return one when the timeout is zero and we don't have any fences.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1)
---
 drivers/dma-buf/reservation.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 9566a62..debb91d 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -379,10 +379,7 @@ long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 {
 	struct fence *fence;
 	unsigned seq, shared_count, i = 0;
-	long ret = timeout;
-
-	if (!timeout)
-		return reservation_object_test_signaled_rcu(obj, wait_all);
+	long ret = timeout ? timeout : 1;
 
 retry:
 	fence = NULL;
-- 
2.5.0

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

Re: [PATCH 1/5] Revert "drm/amd/dal: Fix underlay pipe and pipe count for Stoney"

[Christian König]

Ups my fault. I actually didn't want to send this patch out.

Please ignore.

Christian.

Am 20.10.2016 um 15:20 schrieb Christian König:
> From: Harry Wentland <harry.wentland@amd.com>
>
> This reverts commit 4a183f66e543f697271f2ef717fb72aed071e968.
>
> Change-Id: I331ab0afccf55bd4e50890c64f354249993fb20a
> Acked-by: Alex Deucher <alexander.deucher@amd.com>
> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> ---
>   drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c b/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c
> index 0258aba..9187b34 100644
> --- a/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c
> +++ b/drivers/gpu/drm/amd/dal/dc/dce110/dce110_resource.c
> @@ -1053,15 +1053,14 @@ static bool construct(
>   	 *************************************************/
>   
>   	pool->base.pipe_count = 3;
> -	pool->base.stream_enc_count = 3;
>   	pool->base.underlay_pipe_index = 3;
>   
>   	if (ASIC_REV_IS_STONEY(asic_id.hw_internal_rev)) {
>   		pool->base.pipe_count = 2;
> -		pool->base.stream_enc_count = 2;
>   		pool->base.underlay_pipe_index = 2;
>   	}
>   
> +	pool->base.stream_enc_count = 3;
>   	dc->public.caps.max_downscale_ratio = 150;
>   	dc->public.caps.i2c_speed_in_khz = 100;
>   


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

Re: [PATCH 2/5] dma-buf/fence: make timeout handling in fence_default_wait consistent

[Alex Deucher]

On Thu, Oct 20, 2016 at 9:20 AM, Christian König
<deathsimple@vodafone.de> wrote:
> From: Christian König <christian.koenig@amd.com>
>
> Kernel functions taking a timeout usually return 1 on success even
> when they get a zero timeout.
>
> Signen-off-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>

Adding Sumit.  This series is:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

> ---
>  drivers/dma-buf/fence.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
> index 4d51f9e..fb915ab 100644
> --- a/drivers/dma-buf/fence.c
> +++ b/drivers/dma-buf/fence.c
> @@ -335,18 +335,20 @@ fence_default_wait_cb(struct fence *fence, struct fence_cb *cb)
>   * @timeout:   [in]    timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
>   *
>   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the
> - * remaining timeout in jiffies on success.
> + * remaining timeout in jiffies on success. If timeout is zero the value one is
> + * returned if the fence is already signaled for consistency with other
> + * functions taking a jiffies timeout.
>   */
>  signed long
>  fence_default_wait(struct fence *fence, bool intr, signed long timeout)
>  {
>         struct default_wait_cb cb;
>         unsigned long flags;
> -       signed long ret = timeout;
> +       signed long ret = timeout ? timeout : 1;
>         bool was_set;
>
>         if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> -               return timeout;
> +               return ret;
>
>         spin_lock_irqsave(fence->lock, flags);
>
> --
> 2.5.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] dma-buf/fence: make timeout handling in fence_default_wait consistent

[Gustavo Padovan]

Hi Christian,

2016-10-20 Christian König <deathsimple@vodafone.de>:

> From: Christian König <christian.koenig@amd.com>
> 
> Kernel functions taking a timeout usually return 1 on success even
> when they get a zero timeout.
> 
> Signen-off-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
> ---
>  drivers/dma-buf/fence.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

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

Re: [PATCH 3/5] dma-buf/fence: revert "don't wait when specified timeout is zero"

[Gustavo Padovan]

Hi Christian,

2016-10-20 Christian König <deathsimple@vodafone.de>:

> From: Christian König <christian.koenig@amd.com>
> 
> This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.
> 
> When we don't call the wait function software signaling might never be
> activated. This can cause infinite polling loops with unreliable interrupt
> driven hardware.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
> ---
>  drivers/dma-buf/fence.c | 3 ---
>  1 file changed, 3 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

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

Re: [PATCH 4/5] drm/ttm: fix ttm_bo_wait

[Gustavo Padovan]

Hi Christian,

2016-10-20 Christian König <deathsimple@vodafone.de>:

> From: Christian König <christian.koenig@amd.com>
> 
> reservation_object_wait_timeout_rcu() should enable signaling even with a zero
> timeout, but ttm_bo_wait() can also be called from atomic context and then it
> is not a good idea to do this.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

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

Re: [PATCH 5/5] reservation: revert "wait only with non-zero timeout specified (v3)" v2

[Gustavo Padovan]

Hi Christian,

2016-10-20 Christian König <deathsimple@vodafone.de>:

> From: Christian König <christian.koenig@amd.com>
> 
> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
> 
> Otherwise signaling might never be activated on the fences. This can
> result in infinite waiting with hardware which has unreliable interrupts.
> 
> v2: still return one when the timeout is zero and we don't have any fences.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1)
> ---
>  drivers/dma-buf/reservation.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

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

Re: [PATCH 5/5] reservation: revert "wait only with non-zero timeout specified (v3)" v2

[Alex Deucher]

On Sun, Nov 6, 2016 at 8:07 PM, Gustavo Padovan <gustavo@padovan.org> wrote:
> Hi Christian,
>
> 2016-10-20 Christian König <deathsimple@vodafone.de>:
>
>> From: Christian König <christian.koenig@amd.com>
>>
>> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
>>
>> Otherwise signaling might never be activated on the fences. This can
>> result in infinite waiting with hardware which has unreliable interrupts.
>>
>> v2: still return one when the timeout is zero and we don't have any fences.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1)
>> ---
>>  drivers/dma-buf/reservation.c | 5 +----
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

I've rebased these patches based on the fence renaming in drm-next.
Should I pull these in through my tree or should they go in through
drm-misc or the dma-buf tree?  If the later, I'll send out the rebased
patches.

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

Re: [PATCH 5/5] reservation: revert "wait only with non-zero timeout specified (v3)" v2

[Daniel Vetter]

On Mon, Nov 07, 2016 at 12:55:30PM -0500, Alex Deucher wrote:
> On Sun, Nov 6, 2016 at 8:07 PM, Gustavo Padovan <gustavo@padovan.org> wrote:
> > Hi Christian,
> >
> > 2016-10-20 Christian König <deathsimple@vodafone.de>:
> >
> >> From: Christian König <christian.koenig@amd.com>
> >>
> >> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
> >>
> >> Otherwise signaling might never be activated on the fences. This can
> >> result in infinite waiting with hardware which has unreliable interrupts.
> >>
> >> v2: still return one when the timeout is zero and we don't have any fences.
> >>
> >> Signed-off-by: Christian König <christian.koenig@amd.com>
> >> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1)
> >> ---
> >>  drivers/dma-buf/reservation.c | 5 +----
> >>  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> 
> I've rebased these patches based on the fence renaming in drm-next.
> Should I pull these in through my tree or should they go in through
> drm-misc or the dma-buf tree?  If the later, I'll send out the rebased
> patches.

If there's no amdgpu deps I think best to merge through drm-misc (which
now also contains dma-buf stuff, maintainers patch should go out as soon
as the new drm-misc.git is live).
-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