Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <991331d8-ddda-a816-d279-fdaed90b43c1@linaro.org>
Date:   Thu, 16 Jun 2022 11:27:39 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH] drm/msm: Fix fence rollover issue
Content-Language: en-GB
To:     Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc:     freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
        Rob Clark <robdclark@chromium.org>,
        Abhinav Kumar <quic_abhinavk@quicinc.com>,
        Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        open list <linux-kernel@vger.kernel.org>
References: <20220615162435.3011793-1-robdclark@gmail.com>
From:   Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
In-Reply-To: <20220615162435.3011793-1-robdclark@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 15/06/2022 19:24, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> And while we are at it, let's start the fence counter close to the
> rollover point so that if issues slip in, they are more obvious.
> 
> Signed-off-by: Rob Clark <robdclark@chromium.org>

Should it also have

Fixes: fde5de6cb461 ("drm/msm: move fence code to it's own file")

Or maybe

Fixes: 5f3aee4ceb5b ("drm/msm: Handle fence rollover")

Otherwise:

Reviewed: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>


> ---
>   drivers/gpu/drm/msm/msm_fence.c | 13 +++++++++++--
>   1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
> index 3df255402a33..a35a6746c7cd 100644
> --- a/drivers/gpu/drm/msm/msm_fence.c
> +++ b/drivers/gpu/drm/msm/msm_fence.c
> @@ -28,6 +28,14 @@ msm_fence_context_alloc(struct drm_device *dev, volatile uint32_t *fenceptr,
>   	fctx->fenceptr = fenceptr;
>   	spin_lock_init(&fctx->spinlock);
>   
> +	/*
> +	 * Start out close to the 32b fence rollover point, so we can
> +	 * catch bugs with fence comparisons.
> +	 */
> +	fctx->last_fence = 0xffffff00;
> +	fctx->completed_fence = fctx->last_fence;
> +	*fctx->fenceptr = fctx->last_fence;

This looks like a debugging hack. But probably it's fine to have it, as 
it wouldn't cause any side effects.

> +
>   	return fctx;
>   }
>   
> @@ -46,11 +54,12 @@ bool msm_fence_completed(struct msm_fence_context *fctx, uint32_t fence)
>   		(int32_t)(*fctx->fenceptr - fence) >= 0;
>   }
>   
> -/* called from workqueue */
> +/* called from irq handler */
>   void msm_update_fence(struct msm_fence_context *fctx, uint32_t fence)
>   {
>   	spin_lock(&fctx->spinlock);
> -	fctx->completed_fence = max(fence, fctx->completed_fence);
> +	if (fence_after(fence, fctx->completed_fence))
> +		fctx->completed_fence = fence;
>   	spin_unlock(&fctx->spinlock);
>   }
>   


-- 
With best wishes
Dmitry