All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Dave Jiang <dave.jiang@intel.com>, Vinod <vkoul@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	dmaengine <dmaengine@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dmaengine: add verification of DMA_INTERRUPT capability for dmatest
Date: Mon, 30 May 2022 10:06:39 +0200	[thread overview]
Message-ID: <CAMuHMdVjDTAW-84c9Fh21f_GWOhnD4+VW2nqSTQ6EK-m+KG=vQ@mail.gmail.com> (raw)
In-Reply-To: <164978679251.2361020.5856734256126725993.stgit@djiang5-desk3.ch.intel.com>

Hi Dave, Vinod,

On Wed, Apr 13, 2022 at 12:58 AM Dave Jiang <dave.jiang@intel.com> wrote:
> Looks like I forgot to add DMA_INTERRUPT cap setting to the idxd driver and
> dmatest is still working regardless of this mistake. Add an explicit check
> of DMA_INTERRUPT capability for dmatest to make sure the DMA device being used
> actually supports interrupt before the test is launched and also that the
> driver is programmed correctly.
>
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>

Thanks for your patch, which is now commit a8facc7b988599f8
("dmaengine: add verification of DMA_INTERRUPT capability for
dmatest") upstream.

> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -675,10 +675,16 @@ static int dmatest_func(void *data)
>         /*
>          * src and dst buffers are freed by ourselves below
>          */
> -       if (params->polled)
> +       if (params->polled) {
>                 flags = DMA_CTRL_ACK;
> -       else
> -               flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
> +       } else {
> +               if (dma_has_cap(DMA_INTERRUPT, dev->cap_mask)) {
> +                       flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
> +               } else {
> +                       pr_err("Channel does not support interrupt!\n");
> +                       goto err_pq_array;
> +               }
> +       }
>
>         ktime = ktime_get();
>         while (!(kthread_should_stop() ||
> @@ -906,6 +912,7 @@ static int dmatest_func(void *data)

Shimoda-san reports that this commit breaks dmatest on rcar-dmac.
Like most DMA engine drivers, rcar-dmac does not set the DMA_INTERRUPT
capability flag, hence dmatest now fails to start:

    dmatest: Channel does not support interrupt!

To me, it looks like the new check is bogus, as I believe it confuses
two different concepts:

  1. Documentation/driver-api/dmaengine/provider.rst says:

       - DMA_INTERRUPT

         - The device is able to trigger a dummy transfer that will
           generate periodic interrupts

  2. In non-polled mode, dmatest sets DMA_PREP_INTERRUPT.
     include/linux/dmaengine.h says:

       * @DMA_PREP_INTERRUPT - trigger an interrupt (callback) upon
completion of
       *  this transaction

As dmatest uses real transfers, I think it does not depend on
the ability to use interrupts from dummy transfers.

Do you agree?
Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2022-05-30  8:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 18:06 [PATCH] dmaengine: add verification of DMA_INTERRUPT capability for dmatest Dave Jiang
2022-05-30  8:06 ` Geert Uytterhoeven [this message]
2022-05-31  5:24   ` Vinod Koul
2022-05-31 14:49     ` Dave Jiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMuHMdVjDTAW-84c9Fh21f_GWOhnD4+VW2nqSTQ6EK-m+KG=vQ@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=vkoul@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.