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.
regards
Philipp
