From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: mapping uncached memory
Date: Tue, 16 Mar 2010 23:54:22 +0000 [thread overview]
Message-ID: <20100316235422.GC13948@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <57314e841003161617l53dc3a50la969369f0161ccdd@mail.gmail.com>
On Wed, Mar 17, 2010 at 01:17:45AM +0200, Budhee Jamaich wrote:
> these are the alternatives we currently see:
>
>
> 1. clean cache after every write to the memory (/invalidate the cache
> before every read)
>
> this can be done using dmac_clean/inv_range and outer_clean/inv_range
> just like in dma_cache_maint.
> btw - what's the difference between the dmac_* and the outer_*
> functions ? why both are needed ?
You don't need to know; they're the wrong interface to use.
See the DMA API instead; that is the official interface. What you're
looking at above is an implementation detail of that interface which is
not intended for direct use by anything other than the DMA API. Use of
this implementation detail will lead to breakage.
> 2. use pgprot_noncached when assigning vma->vm_page_prot in our
> driver's mmap method
>
>
> will that really work ? all memory accesses will be uncached ?
Not on ARMv6 and above - it has become illegal to remap memory with
differing type attributes.
> 3. use dma_alloc_coherent in some way
>
> cons: documentation says we still need to use cache clean/inv
> operations, so this might not really be of any advantage. but if that
> is so, what's the idea behind coherent pools of memory ? how does it
> work at all ?
Please provide a pointer to that documentation.
Note that the whole "DMA to user mapped pages" issue is a _big_ can of
worms and doesn't appear to have any sane and non-expensive solutions.
next prev parent reply other threads:[~2010-03-16 23:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-16 23:17 mapping uncached memory Budhee Jamaich
2010-03-16 23:54 ` Russell King - ARM Linux [this message]
2010-03-17 4:34 ` Jamie Lokier
2010-03-17 8:02 ` Budhee Jamaich
2010-03-17 8:15 ` Russell King - ARM Linux
2010-03-17 9:09 ` Budhee Jamaich
2010-03-17 21:26 ` Colin Cross
2010-03-17 22:03 ` Catalin Marinas
2010-03-23 12:22 ` Budhee Jamaich
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=20100316235422.GC13948@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).