LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-spi@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Kumar Gala <galak@codeaurora.org>,
Andy Gross <agross@codeaurora.org>,
Sagar Dharia <sdharia@codeaurora.org>,
Daniel Sneddon <dsneddon@codeaurora.org>
Subject: Re: [PATCH v2] spi: qup: Add DMA capabilities
Date: Thu, 26 Feb 2015 11:33:17 +0900 [thread overview]
Message-ID: <20150226023317.GE6236@finisterre.sirena.org.uk> (raw)
In-Reply-To: <54ECA216.306@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote:
> yes, there is a potential race between atomic_inc and dma callback. I
> reordered these calls to save few checks, and now it returns to me.
> I imagine few options here:
> - reorder the dmaengine calls and atomic operations, i.e.
> call atomic_inc for rx and tx channels before corresponding
> dmaengine_submit and dmaengine_issue_pending.
> - have two different dma callbacks and two completions and waiting for
> the two.
> - manage to receive only one dma callback, i.e. the last transfer in
> case of presence of the rx_buf and tx_buf at the same time.
> - let me see for better solution.
Any solution which doesn't make use of atomics is likely to be better,
as I said they are enormously error prone. A more common approach is a
single completion triggering on the RX (for RX only or bidirectional
transfers) or TX if that's the only thing active. For most hardware you
can just use the RX to manage completion since it must of necessity
complete at the same time as or later than the transmit side, transmit
often completes early since the DMA completes when the FIFO is full not
when the data is on the wire.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-02-26 2:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 13:00 Stanimir Varbanov
2015-02-24 13:56 ` Mark Brown
2015-02-24 16:08 ` Stanimir Varbanov
2015-02-24 22:38 ` Andy Gross
2015-02-26 2:33 ` Mark Brown [this message]
2015-02-27 14:46 ` Stanimir Varbanov
2015-02-24 16:09 ` Ivan T. Ivanov
2015-02-24 17:11 ` Ivan T. Ivanov
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=20150226023317.GE6236@finisterre.sirena.org.uk \
--to=broonie@kernel.org \
--cc=agross@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dsneddon@codeaurora.org \
--cc=galak@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sdharia@codeaurora.org \
--cc=stanimir.varbanov@linaro.org \
--subject='Re: [PATCH v2] spi: qup: Add DMA capabilities' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).