[PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

[PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

[Eric Anholt]

We were returning without decrementing if the error happened, meaning
that at the next submit we wouldn't try to bring up the power domain.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

I stumbled across this error when testing my CMA patch with a very low
(64MB) CMA area -- we would oops on the submit after the one that
failed.

 drivers/gpu/drm/vc4/vc4_gem.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 777a8d9afd60..735412e3725a 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1016,13 +1016,16 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
 	}
 
 	mutex_lock(&vc4->power_lock);
-	if (vc4->power_refcount++ == 0)
+	if (vc4->power_refcount++ == 0) {
 		ret = pm_runtime_get_sync(&vc4->v3d->pdev->dev);
-	mutex_unlock(&vc4->power_lock);
-	if (ret < 0) {
-		kfree(exec);
-		return ret;
+		if (ret < 0) {
+			mutex_unlock(&vc4->power_lock);
+			vc4->power_refcount--;
+			kfree(exec);
+			return ret;
+		}
 	}
+	mutex_unlock(&vc4->power_lock);
 
 	exec->args = args;
 	INIT_LIST_HEAD(&exec->unref_list);
-- 
2.11.0

[PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

[Eric Anholt]

We were returning without decrementing if the error happened, meaning
that at the next submit we wouldn't try to bring up the power domain.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

I stumbled across this error when testing my CMA patch with a very low
(64MB) CMA area -- we would oops on the submit after the one that
failed.

 drivers/gpu/drm/vc4/vc4_gem.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 777a8d9afd60..735412e3725a 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1016,13 +1016,16 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
 	}
 
 	mutex_lock(&vc4->power_lock);
-	if (vc4->power_refcount++ == 0)
+	if (vc4->power_refcount++ == 0) {
 		ret = pm_runtime_get_sync(&vc4->v3d->pdev->dev);
-	mutex_unlock(&vc4->power_lock);
-	if (ret < 0) {
-		kfree(exec);
-		return ret;
+		if (ret < 0) {
+			mutex_unlock(&vc4->power_lock);
+			vc4->power_refcount--;
+			kfree(exec);
+			return ret;
+		}
 	}
+	mutex_unlock(&vc4->power_lock);
 
 	exec->args = args;
 	INIT_LIST_HEAD(&exec->unref_list);
-- 
2.11.0

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

Re: [PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

[Sean Paul]

On Mon, Apr 17, 2017 at 09:26:03AM -0700, Eric Anholt wrote:
> We were returning without decrementing if the error happened, meaning
> that at the next submit we wouldn't try to bring up the power domain.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>

This change looks good to me. It seems a little odd to wrap pm_runtime which
is already refcounted in another refcount, but I'm really not familiar with
the driver, and I'm sure there's a good reason for it.

Reviewed-by: Sean Paul <seanpaul@chromium.org>

> ---
> 
> I stumbled across this error when testing my CMA patch with a very low
> (64MB) CMA area -- we would oops on the submit after the one that
> failed.
> 
>  drivers/gpu/drm/vc4/vc4_gem.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 777a8d9afd60..735412e3725a 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -1016,13 +1016,16 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
>  	}
>  
>  	mutex_lock(&vc4->power_lock);
> -	if (vc4->power_refcount++ == 0)
> +	if (vc4->power_refcount++ == 0) {
>  		ret = pm_runtime_get_sync(&vc4->v3d->pdev->dev);
> -	mutex_unlock(&vc4->power_lock);
> -	if (ret < 0) {
> -		kfree(exec);
> -		return ret;
> +		if (ret < 0) {
> +			mutex_unlock(&vc4->power_lock);
> +			vc4->power_refcount--;
> +			kfree(exec);
> +			return ret;
> +		}
>  	}
> +	mutex_unlock(&vc4->power_lock);
>  
>  	exec->args = args;
>  	INIT_LIST_HEAD(&exec->unref_list);
> -- 
> 2.11.0

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

[Sean Paul]

On Mon, Apr 17, 2017 at 09:26:03AM -0700, Eric Anholt wrote:
> We were returning without decrementing if the error happened, meaning
> that at the next submit we wouldn't try to bring up the power domain.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>

This change looks good to me. It seems a little odd to wrap pm_runtime which
is already refcounted in another refcount, but I'm really not familiar with
the driver, and I'm sure there's a good reason for it.

Reviewed-by: Sean Paul <seanpaul@chromium.org>

> ---
> 
> I stumbled across this error when testing my CMA patch with a very low
> (64MB) CMA area -- we would oops on the submit after the one that
> failed.
> 
>  drivers/gpu/drm/vc4/vc4_gem.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 777a8d9afd60..735412e3725a 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -1016,13 +1016,16 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
>  	}
>  
>  	mutex_lock(&vc4->power_lock);
> -	if (vc4->power_refcount++ == 0)
> +	if (vc4->power_refcount++ == 0) {
>  		ret = pm_runtime_get_sync(&vc4->v3d->pdev->dev);
> -	mutex_unlock(&vc4->power_lock);
> -	if (ret < 0) {
> -		kfree(exec);
> -		return ret;
> +		if (ret < 0) {
> +			mutex_unlock(&vc4->power_lock);
> +			vc4->power_refcount--;
> +			kfree(exec);
> +			return ret;
> +		}
>  	}
> +	mutex_unlock(&vc4->power_lock);
>  
>  	exec->args = args;
>  	INIT_LIST_HEAD(&exec->unref_list);
> -- 
> 2.11.0

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

Sean Paul <seanpaul@chromium.org> writes:

> On Mon, Apr 17, 2017 at 09:26:03AM -0700, Eric Anholt wrote:
>> We were returning without decrementing if the error happened, meaning
>> that at the next submit we wouldn't try to bring up the power domain.
>> 
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>
> This change looks good to me. It seems a little odd to wrap pm_runtime which
> is already refcounted in another refcount, but I'm really not familiar with
> the driver, and I'm sure there's a good reason for it.
>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>

Yeah, it's an unfortunate hack because the reset control is buried in
the power domain driver on the RPi, so we have to get the power domain
actually off (0 refcount) in order to reset the GPU.

Yay for building around closed-source firmware :(

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 836 bytes --]

Sean Paul <seanpaul@chromium.org> writes:

> On Mon, Apr 17, 2017 at 09:26:03AM -0700, Eric Anholt wrote:
>> We were returning without decrementing if the error happened, meaning
>> that at the next submit we wouldn't try to bring up the power domain.
>> 
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>
> This change looks good to me. It seems a little odd to wrap pm_runtime which
> is already refcounted in another refcount, but I'm really not familiar with
> the driver, and I'm sure there's a good reason for it.
>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>

Yeah, it's an unfortunate hack because the reset control is buried in
the power domain driver on the RPi, so we have to get the power domain
actually off (0 refcount) in order to reset the GPU.

Yay for building around closed-source firmware :(

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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