Thank you for your further explanation! It's all clear for me and I
will write a new patch to fix this imbalance.
Regards,
Dinghao
> On 21/05/2020 08:00, dinghao@zju.edu.cn wrote:
> > Hi Steve,
> >
> > There are two bailing out points in panfrost_job_hw_submit(): one is
> > the error path
On 21/05/2020 08:00, dinghao@zju.edu.cn wrote:
Hi Steve,
There are two bailing out points in panfrost_job_hw_submit(): one is
the error path beginning from pm_runtime_get_sync(), the other one is
the error path beginning from WARN_ON() in the if statement. The pm
imbalance fixed in this patc
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4 +++-
1 file changed, 3 insert
Hi Steve,
There are two bailing out points in panfrost_job_hw_submit(): one is
the error path beginning from pm_runtime_get_sync(), the other one is
the error path beginning from WARN_ON() in the if statement. The pm
imbalance fixed in this patch is between these two paths. I think the
caller
On 20/05/2020 12:05, Dinghao Liu wrote:
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Actually I think we have the opposi
