From: Jakub Jelinek <jakub@redhat.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: "David S. Miller" <davem@redhat.com>, 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 07:01:26 +0100 [thread overview]
Message-ID: <20000130070126.C948@mff.cuni.cz> (raw)
In-Reply-To: <200001300006.AAA02084@raistlin.arm.linux.org.uk>; from Russell King on Sun, Jan 30, 2000 at 12:06:15AM +0000
On Sun, Jan 30, 2000 at 12:06:15AM +0000, Russell King wrote:
> Hi,
>
> I've been looking over the 2.3.41 patch, and have come across a major problem
> area for ARM.
>
> 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.
Some SPARCs are not DMA coherent either and a similar interface works for
them for quite some years.
With the pci_map_single/pci_map_sg/pci_unmap_single/pci_unmap_sg
you can sync caches in those routines as required (plus there are
pci_dma_sync_single/pci_dma_sync_sg which should sync as well).
With pci_alloc_consistant, on DMA non-coherent systems the trick is to
allocate a non-cacheable memory (or make it uncacheable after allocating).
>
> I have had ideas about ways to do this on the ARM, but it will not be trivial
> changes to the mm layer, and certainly has not been implemented yet.
>
> This effectively means that I seem to have two options:
>
> 1. either we loose any hope of IDE DMA for the rest of 2.3 and 2.4, or
> 2. the IDE DMA code gets the dma_cache_* macros added back in
>
> 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.
The interface was lined out e.g. during the
Alpha: virt_to_bus/GFP_DMA problem
thread on l-k in december.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.41 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
-
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 1:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-30 0:06 DMA changes in 2.3.41 - how the f* do I get this working on ARM? Russell King
2000-01-30 5:52 ` Andre Hedrick
2000-01-30 6:01 ` Jakub Jelinek [this message]
2000-01-30 9:48 ` Russell King
2000-01-30 22:11 ` David S. Miller
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=20000130070126.C948@mff.cuni.cz \
--to=jakub@redhat.com \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.