From: Russell King <rmk+lkml@arm.linux.org.uk>
To: David Brownell <david-b@pacbell.net>
Cc: basicmark@yahoo.com, arjan@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] SPI subsystem
Date: Mon, 3 Oct 2005 16:23:12 +0100 [thread overview]
Message-ID: <20051003152312.GH16717@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20051003151457.AD64FEE8CE@adsl-69-107-32-110.dsl.pltn13.pacbell.net>
On Mon, Oct 03, 2005 at 08:14:57AM -0700, David Brownell wrote:
> > From: Arjan van de Ven <arjan@infradead.org>
> > Date: Mon, 03 Oct 2005 13:07:36 +0200
> >
> > please NEVER EVER do dma from or to a stack variable. It's not allowed
> > on all architectures and it is really really bad practice in general
> > anyway.
>
> Arjan, could you mention some Linuxes which don't allow it?
>
> Every time the topic of DMA to/from stack comes up, the advice is
> always to avoid it ... but so far as I recall, nobody's yet provided
> us with an example where it actually doesn't work.
>
> Failing such examples, it's normal to discount such dire warnings and
> just plan to apply the relevant minor tweaks if/when they're needed.
I believe the issue is that you can't properly control the alignment
to ensure that you don't inadvertantly dirty the cache lines
corresponding with the memory you're performing DMA to/from.
Eg, on ARM, if the memory you're DMAing to/from is just above the
next stack location which will be used when you call a sub-function,
you'll have just undone the effects of the DMA API. Provided GCC
decided to arrange the stack that way.
Or maybe there's a local variable right next to the DMA region.
Same effect.
However, who knows how different gcc versions will lay out the
stack? That's completely up to the compilers whims.
So, if you want portable code and don't want random failures,
avoid DMA to/from the stack.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2005-10-03 15:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-03 10:13 [RFC][PATCH] SPI subsystem Mark Underwood
2005-09-09 21:39 ` David Brownell
2005-09-10 11:17 ` Mark Underwood
2005-09-15 0:08 ` David Brownell
2005-09-15 19:24 ` Mark Underwood
2005-09-15 22:14 ` David Brownell
2005-09-15 23:27 ` Mark Underwood
2005-09-16 3:25 ` David Brownell
2005-09-16 17:55 ` Mark Underwood
2005-09-16 18:43 ` David Brownell
2005-09-18 14:45 ` Mark Underwood
2005-09-30 1:02 ` David Brownell
2005-10-02 12:36 ` Mark Underwood
2005-10-03 4:47 ` David Brownell
2005-10-03 10:57 ` Mark Underwood
2005-10-03 11:07 ` Arjan van de Ven
2005-10-03 15:14 ` David Brownell
2005-10-03 15:23 ` Russell King [this message]
2005-10-03 15:40 ` David Brownell
2005-09-10 10:55 ` Vital
2005-09-10 11:54 ` Mark Underwood
2005-09-10 21:20 ` Vital
2005-09-11 8:35 ` Mark Underwood
2005-09-15 0:14 ` David Brownell
2005-09-26 16:50 ` Vitaly Wool
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=20051003152312.GH16717@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=arjan@infradead.org \
--cc=basicmark@yahoo.com \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.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