lkml.org 
[lkml]   [2005]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] SPI subsystem
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-03 17:25    [W:0.094 / U:1.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site