From: Florian Mickler <florian@mickler.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Andy Walls <awalls@md.metrocast.net>,
mchehab@infradead.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, js@linuxtv.org, tskd2@yahoo.co.jp,
liplianin@me.by, g.marco@freenet.de, aet@rasterburn.org,
pb@linuxtv.org, mkrufky@linuxtv.org, nick@nick-andrew.net,
max@veneto.com, janne-dvb@grunau.be,
Oliver Neukum <oliver@neukum.org>,
Greg Kroah-Hartman <greg@kroah.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: [PATCH 0/6] get rid of on-stack dma buffers
Date: Tue, 22 Mar 2011 15:02:48 +0100 [thread overview]
Message-ID: <AANLkTinWhwX1ZONGi-JwPr-oG565bKSsF0-UvJRh+4Cp@mail.gmail.com> (raw)
In-Reply-To: <1300800904.3290.7.camel@mulgrave.site>
2011/3/22 James Bottomley <James.Bottomley@hansenpartnership.com>:
> On Mon, 2011-03-21 at 22:03 +0100, Florian Mickler wrote:
>> On Mon, 21 Mar 2011 15:26:43 -0400
>> Andy Walls <awalls@md.metrocast.net> wrote:
>>
>> > Florian Mickler <florian@mickler.org> wrote:
>>
>> To be blunt, I'm not shure I fully understand the requirements myself.
>> But as far as I grasped it, the main problem is that we need memory
>> which the processor can see as soon as the device has scribbled upon
>> it. (think caches and the like)
>>
>> Somewhere down the line, the buffer to usb_control_msg get's to be
>> a parameter to dma_map_single which is described as part of
>> the DMA API in Documentation/DMA-API.txt
>>
>> The main point I filter out from that is that the memory has to begin
>> exactly at a cache line boundary...
>
> The API will round up so that the correct region covers the API.
> However, if you have other structures packed into the space (as very
> often happens on stack), you get cache line interference in the CPU if
> they get accessed: The act of accessing an adjacent object pulls in
> cache above your object and destroys DMA coherence. This is the
> principle reason why DMA to stack is a bad idea.
Thanks, this was the missing piece of information to make sense of
why it's bad for stack memory to be part of this.
>
>> I guess (not verified), that the dma api takes sufficient precautions
>> to abort the dma transfer if a timeout happens. So freeing _should_
>> not be an issue. (At least, I would expect big fat warnings everywhere
>> if that were the case)
I did mean s/dma api/usb_control_msg/ in the above paragraph. As that is the
''dma api'' these drivers are using... sorry for the confusion there...
>
> No, it doesn't take any precautions like this. the DMA API is just
> mapping (possibly via an IOMMU). If the transfer times out, that's done
> in the DMA engine of the card, and must be cleaned up by the driver and
> unmapped.
ok.
> The general rule though is never DMA to stack. On some processors, the
> way stack is allocated can actually make this not work.
>
> James
thanks,
Flo
p.s.: hope this message get's through to the list... I am on the road
at the moment,
so I'm not shure that there won't be any html in it again :(
next prev parent reply other threads:[~2011-03-22 14:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 18:33 [PATCH 0/6] get rid of on-stack dma buffers Florian Mickler
2011-03-21 18:33 ` [PATCH 1/6] [media] a800: " Florian Mickler
2011-03-21 18:33 ` [PATCH 2/6 v2] [media] vp7045: " Florian Mickler
2011-03-21 18:33 ` [PATCH 3/6] [media] friio: " Florian Mickler
2011-03-21 18:33 ` [PATCH 4/6] [media] dw2102: get rid of on-stack dma buffer Florian Mickler
2011-03-21 18:33 ` [PATCH 5/6] [media] m920x: get rid of on-stack dma buffers Florian Mickler
2011-03-21 18:33 ` [PATCH 6/6] [media] opera1: get rid of on-stack dma buffer Florian Mickler
2011-03-21 19:26 ` [PATCH 0/6] get rid of on-stack dma buffers Andy Walls
2011-03-21 21:03 ` Florian Mickler
2011-03-22 10:44 ` Roedel, Joerg
[not found] ` <AANLkTimXobrwc-XHgoVN1dD5NCTde64dykbyvtJMo229@mail.gmail.com>
2011-03-22 13:12 ` Oliver Neukum
2011-03-22 14:27 ` Florian Mickler
2011-03-22 10:59 ` Jiri Kosina
2011-03-22 12:33 ` Johannes Stezenbach
2011-03-22 13:35 ` James Bottomley
2011-03-22 14:02 ` Florian Mickler [this message]
2011-03-22 20:15 ` David Miller
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=AANLkTinWhwX1ZONGi-JwPr-oG565bKSsF0-UvJRh+4Cp@mail.gmail.com \
--to=florian@mickler.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=aet@rasterburn.org \
--cc=awalls@md.metrocast.net \
--cc=g.marco@freenet.de \
--cc=greg@kroah.com \
--cc=janne-dvb@grunau.be \
--cc=joerg.roedel@amd.com \
--cc=js@linuxtv.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=liplianin@me.by \
--cc=max@veneto.com \
--cc=mchehab@infradead.org \
--cc=mkrufky@linuxtv.org \
--cc=nick@nick-andrew.net \
--cc=oliver@neukum.org \
--cc=pb@linuxtv.org \
--cc=rjw@sisk.pl \
--cc=tskd2@yahoo.co.jp \
/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;
as well as URLs for NNTP newsgroup(s).