From: "David S. Miller" <davem@redhat.com>
To: rmk@arm.linux.org.uk
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: DMA changes in 2.3.41 - how the f* do I get this working on ARM?
Date: Sun, 30 Jan 2000 14:11:49 -0800 [thread overview]
Message-ID: <200001302211.OAA03036@pizda.ninka.net> (raw)
In-Reply-To: <200001300006.AAA02084@raistlin.arm.linux.org.uk> (message from Russell King on Sun, 30 Jan 2000 00:06:15 +0000 (GMT))
From: Russell King <rmk@arm.linux.org.uk>
Date: Sun, 30 Jan 2000 00:06:15 +0000 (GMT)
On ARM, there is no such thing as "dma coherent" memory. Unfortunately, the
new PCI code (pci_alloc_consistent) appears to assume that there is a way
of doing this.
You have no mechanism whatsoever to disable the cache on a per-page
basis with MMU mappings? This would very much surprise me.
I would have preferred to have heard about the extent of these changes (and
that the dma_cache_* macros were going to be removed, along with my comments
marking them with my initials) before it was submitted.
For the actual transfers, you can do the dma_cache_*() calls in the
pci_{un,}map_streaming() calls.
The only place you could possibly need it is for the IDE scatter list
tables, and that would only be if you have _no_ mechanism to disable
the CPU cache in the MMU, which I severely doubt.
For now, I'm adding the dma_cache_* macros back in, and if I don't hear anything,
I will be re-submitting that code back to Linus.
(very pissed)
Actually, don't be pissed, and instead work with us to get your
port working again. The changes were designed so that all of
the cache flushing hacks could just dissapear and be hidden
within the new interfaces on ports which needed.
I was completely convinced that if all dma mappings were handled
explicitly in the manner they are now, none of that crap would be
needed anymore.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-01-30 18:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-30 0:06 Russell King
2000-01-30 5:52 ` Andre Hedrick
2000-01-30 6:01 ` Jakub Jelinek
2000-01-30 9:48 ` Russell King
2000-01-30 22:11 ` David S. Miller [this message]
2000-01-30 23:49 ` Russell King
2000-01-31 0:24 ` David S. Miller
2000-01-31 4:27 ` Andre Hedrick
2000-01-31 4:27 ` David S. Miller
2000-01-31 10:02 ` Jes Sorensen
2000-01-31 10:09 ` David S. Miller
2000-01-31 11:45 ` Jakub Jelinek
2000-01-31 12:48 ` Jes Sorensen
2000-01-31 18:00 ` Jeff Garzik
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=200001302211.OAA03036@pizda.ninka.net \
--to=davem@redhat.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=rmk@arm.linux.org.uk \
/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
all inboxes | Powered by JetHome®