public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
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;
 



             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