LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stanimir Varbanov <email@example.com>
To: Mark Brown <firstname.lastname@example.org>
Cc: Stanimir Varbanov <email@example.com>,
Rob Herring <firstname.lastname@example.org>,
Mark Rutland <email@example.com>,
Kumar Gala <firstname.lastname@example.org>,
Andy Gross <email@example.com>,
Sagar Dharia <firstname.lastname@example.org>,
Daniel Sneddon <email@example.com>
Subject: Re: [PATCH v2] spi: qup: Add DMA capabilities
Date: Fri, 27 Feb 2015 16:46:17 +0200 [thread overview]
Message-ID: <54F08339.firstname.lastname@example.org> (raw)
On 02/26/2015 04:33 AM, Mark Brown wrote:
> 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.
yep, that's what I wanted to express in third option above.
next prev parent reply other threads:[~2015-02-27 14:46 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
2015-02-27 14:46 ` Stanimir Varbanov [this message]
2015-02-24 16:09 ` Ivan T. Ivanov
2015-02-24 17:11 ` Ivan T. Ivanov
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH v2] spi: qup: Add DMA capabilities' \
* 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).