| Message ID | 20170417162603.12726-1-eric@anholt.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <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 :(
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);
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(-)