Hi Philipp,
Thanks for the quick review of the series.
On Fri, 2019-04-26 at 11:16 +0200, Philipp Zabel wrote:
> On Thu, 2019-04-25 at 15:35 -0300, Ezequiel Garcia wrote:
> > The current interrupt handler is doing very little, and not doing
> > any non-atomic operations. Pretty much all it does is accessing
> > a couple registers, taking a couple spinlocks and then signalling
> > a completion.
> >
> > There is no reason this should be a threaded interrupt handler,
> > so move the handler to regular hard interrupt context.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx>
> > ---
> > drivers/media/platform/coda/coda-common.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
> > index 1f53ca4effd2..617d4547ec82 100644
> > --- a/drivers/media/platform/coda/coda-common.c
> > +++ b/drivers/media/platform/coda/coda-common.c
> > @@ -2789,8 +2789,8 @@ static int coda_probe(struct platform_device *pdev)
> > return irq;
> > }
> >
> > - ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, coda_irq_handler,
> > - IRQF_ONESHOT, dev_name(&pdev->dev), dev);
> > + ret = devm_request_irq(&pdev->dev, irq, coda_irq_handler, 0,
> > + dev_name(&pdev->dev), dev);
> > if (ret < 0) {
> > dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
> > return ret;
>
> There is one thing that this would complicate. For at least H.264 I
> know that we can pad the bitstream in reaction to a BIT_BUF_EMPTY
> interrupt, to make a picture run finish successfully when it is stuck in
> buffer underrun condition. This would need to be done under the
> bitstream_mutex in a threaded handler.
>
In this case, a top-half handler would still stand in good stead,
as it would check the interrupt status, and fire the bottom-half
threaded interrupt to handle the buffer underrun.
Thanks,
Ezequiel
