From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
To: linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [RFC PATCH] make dma_declare_coherent_memory API use cacheable memory
Date: Mon, 28 Apr 2008 10:51:38 -0400 [thread overview]
Message-ID: <1209394298.3367.28.camel@localhost.localdomain> (raw)
This one is up for discussion because a recent change in x86:
commit 6371b495991debfd1417b17c2bc4f7d7bae05739
Author: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Date: Wed Jan 30 13:33:40 2008 +0100
x86: change ioremap() to default to uncached
Changed the way the memory the x86 implementation obtains via ioremap is
cached.
Fortunately, since dma_declare_coherent_memory() is architecturally
implemented, the caching doesn't have to be the same on all
architectures. However, its worth thinking about what the architectures
want. For the x86 use, which is actually on a MCA bus, I want the
caching because the memory is slow to access. It has been pointed out
to me that any similar memory behind a PCI bridge would have to be
uncached by default, so perhaps the issue is moot on newer systems.
An alternative might be to extend the API to get the user to hint
whether they want cached memory or not.
James
---
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 388b113..df83ffd 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -214,7 +214,7 @@ int dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
/* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */
- mem_base = ioremap(bus_addr, size);
+ mem_base = ioremap_cache(bus_addr, size);
if (!mem_base)
goto out;
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: linux-arch@vger.kernel.org
Subject: [RFC PATCH] make dma_declare_coherent_memory API use cacheable memory
Date: Mon, 28 Apr 2008 10:51:38 -0400 [thread overview]
Message-ID: <1209394298.3367.28.camel@localhost.localdomain> (raw)
Message-ID: <20080428145138.yfViMKEto7R2upVqqpbhsb1vjpuKbKIqm7VpuaG_Bbo@z> (raw)
This one is up for discussion because a recent change in x86:
commit 6371b495991debfd1417b17c2bc4f7d7bae05739
Author: Ingo Molnar <mingo@elte.hu>
Date: Wed Jan 30 13:33:40 2008 +0100
x86: change ioremap() to default to uncached
Changed the way the memory the x86 implementation obtains via ioremap is
cached.
Fortunately, since dma_declare_coherent_memory() is architecturally
implemented, the caching doesn't have to be the same on all
architectures. However, its worth thinking about what the architectures
want. For the x86 use, which is actually on a MCA bus, I want the
caching because the memory is slow to access. It has been pointed out
to me that any similar memory behind a PCI bridge would have to be
uncached by default, so perhaps the issue is moot on newer systems.
An alternative might be to extend the API to get the user to hint
whether they want cached memory or not.
James
---
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 388b113..df83ffd 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -214,7 +214,7 @@ int dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
/* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */
- mem_base = ioremap(bus_addr, size);
+ mem_base = ioremap_cache(bus_addr, size);
if (!mem_base)
goto out;
next reply other threads:[~2008-04-28 14:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 14:51 James Bottomley [this message]
2008-04-28 14:51 ` [RFC PATCH] make dma_declare_coherent_memory API use cacheable memory James Bottomley
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=1209394298.3367.28.camel@localhost.localdomain \
--to=james.bottomley-d9phhud1jfjcxq6kfmz53/egyhegw8jk@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.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