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 <[email protected]>
---
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
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 <[email protected]>
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 <[email protected]>
> ---
>
> 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
Sean Paul <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]>
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 :(