From: Jon Hunter <jonathanh@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
Laxman Dewangan <ldewangan@nvidia.com>,
Vinod Koul <vkoul@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Ben Dooks <ben.dooks@codethink.co.uk>
Cc: <dmaengine@vger.kernel.org>, <linux-tegra@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] dmaengine: tegra-apb: Handle DMA_PREP_INTERRUPT flag properly
Date: Wed, 8 May 2019 10:24:37 +0100 [thread overview]
Message-ID: <287d7e67-1572-b4f2-d4bb-b1f02f534d47@nvidia.com> (raw)
In-Reply-To: <20190505181235.14798-1-digetx@gmail.com>
On 05/05/2019 19:12, Dmitry Osipenko wrote:
> The DMA_PREP_INTERRUPT flag means that descriptor's callback should be
> invoked upon transfer completion and that's it. For some reason driver
> completely disables the hardware interrupt handling, leaving channel in
> unusable state if transfer is issued with the flag being unset. Note
> that there are no occurrences in the relevant drivers that do not set
> the flag, hence this patch doesn't fix any actual bug and merely fixes
> potential problem.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
From having a look at this, I am guessing that we have never really
tested the case where DMA_PREP_INTERRUPT flag is not set because as you
mentioned it does not look like this will work at all!
Is there are use-case you are looking at where you don't set the
DMA_PREP_INTERRUPT flag?
If not I am wondering if we should even bother supporting this and warn
if it is not set. AFAICT it does not appear to be mandatory, but maybe
Vinod can comment more on this.
Cheers
Jon
--
nvpublic
next prev parent reply other threads:[~2019-05-08 9:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-05 18:12 [PATCH v1] dmaengine: tegra-apb: Handle DMA_PREP_INTERRUPT flag properly Dmitry Osipenko
2019-05-08 9:24 ` Jon Hunter [this message]
2019-05-08 12:37 ` Dmitry Osipenko
2019-05-21 4:55 ` Vinod Koul
2019-05-21 13:46 ` Dmitry Osipenko
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=287d7e67-1572-b4f2-d4bb-b1f02f534d47@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=ben.dooks@codethink.co.uk \
--cc=digetx@gmail.com \
--cc=dmaengine@vger.kernel.org \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=thierry.reding@gmail.com \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox