[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95ea572e201545b27ff9f48313f7aaea157d4764.camel@collabora.com>
Date: Tue, 27 Apr 2021 12:18:32 -0300
From: Ezequiel Garcia <ezequiel@...labora.com>
To: Robin Murphy <robin.murphy@....com>,
Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: linuxarm@...wei.com, mauro.chehab@...wei.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v3 79/79] media: hantro: document the usage of
pm_runtime_get_sync()
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@...nel.org>
> > ---
> > 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
Powered by blists - more mailing lists