On Tue, 2021-04-27 at 16:08 +0100, Robin Murphy wrote: > On 2021-04-27 11:27, Mauro Carvalho Chehab wrote: > > Despite other *_get()/*_put() functions, where usage count is > > incremented only if not errors, the pm_runtime_get_sync() has > > a different behavior, incrementing the counter *even* on > > errors. > > > > That's an error prone behavior, as people often forget to > > decrement the usage counter. > > > > However, the hantro driver depends on this behavior, as it > > will decrement the usage_count unconditionally at the m2m > > job finish time, which makes sense. > > > > So, intead of using the pm_runtime_resume_and_get() that > > would decrement the counter on error, keep the current > > API, but add a documentation explaining the rationale for > > keep using pm_runtime_get_sync(). > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> > > --- > > drivers/staging/media/hantro/hantro_drv.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c > > index 595e82a82728..96f940c1c85c 100644 > > --- a/drivers/staging/media/hantro/hantro_drv.c > > +++ b/drivers/staging/media/hantro/hantro_drv.c > > @@ -155,6 +155,13 @@ static void device_run(void *priv) > > ret = clk_bulk_enable(ctx->dev->variant->num_clocks, ctx->dev->clocks); > > if (ret) > > goto err_cancel_job; > > ..except this can also cause the same pm_runtime_put_autosuspend() call > without even reaching the "matching" get below, so rather than some kind > of cleverness it seems more like it's just broken :/ > Indeed, I was trying to find time to cook a quick patch, but kept getting preempted. Feel free to submit a fix for this, otherwise, I'll try to find time later this week. Thanks, Ezequiel _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
