From: Arnd Bergmann <arnd@arndb.de>
To: Grant Grundler <grundler@google.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
jgarzik@pobox.com, hancockrwd@gmail.com, htejun@gmail.com,
alan@lxorguk.ukuu.org.uk, flar@allandria.com,
schmitz@biophys.uni-duesseldorf.de, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, takata@linux-m32r.org,
geert@linux-m68k.org, linux-m68k@vger.kernel.org,
ysato@users.sourceforge.jp
Subject: Re: [PATCH] asm-generic: add a dma-mapping.h file
Date: Tue, 19 May 2009 17:40:20 +0000 [thread overview]
Message-ID: <200905191740.21150.arnd@arndb.de> (raw)
In-Reply-To: <da824cf30905191001p29217d44u62bcc1c38b0acd92@mail.gmail.com>
On Tuesday 19 May 2009 17:01:27 Grant Grundler wrote:
> On Tue, May 19, 2009 at 9:22 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I've reviewed the first bit and it looks fine (so far to me).
> Two related bugs:
> 1) dma_alloc_coherent() is not respecting the coherent_dma_mask field
> in device.h:struct device.
Hmm, I've taken that function unchanged from powerpc. I guess that means
that powerpc is broken here as well, right?
> 2) dma_map_single() is not respecting dma_mask in struct pci_dev (and
> pointer from struct device).
What should it do with the mask? All the architectures I've looked
at as well as arch/parisc/kernel/pci-dma.c ignore it.
Should dma_map_* just fail in case of an address exceeding dma_mask?
> > +/**
> > + * dma_alloc_coherent - allocate consistent memory for DMA
> > + * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
> > + * @size: required memory size
> > + * @handle: bus-specific DMA address
> > + *
> > + * Allocate some uncached, unbuffered memory for a device for
> > + * performing DMA. This function allocates pages, and will
> > + * return the CPU-viewed address, and sets @handle to be the
> > + * device-viewed address.
>
> Key here is the DMA is coherent, bi-directional, and the DMA address fit in
> the coherent_dma_mask. "uncached/unbuffered" is one way of doing this and
> is how we've implemented "DMA coherency" on parisc platforms that don't
> have an IOMMU (which all have PA1.1 CPUs) - see arch/parisc/kernel/pci-dma.c
All the architectures I've looked at come with their own version of _alloc_coherent
that works in similar ways to allocate an uncached mapping. Now that you
mention this, I realize that there is a bug on cris, which after my patch either
has two conflicting implementations of dma_{alloc,free}_coherent, or
is missing the dma_coherent_dev() function that is hidden inside of the
same #ifdef. The one in arch/cris/arch-v32/drivers/pci/dma.c does seem
to be correct though.
Arnd <><
next prev parent reply other threads:[~2009-05-19 17:40 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090511222702.352192505@arndb.de>
2009-05-11 22:38 ` [PATCH] ata: libata depends on HAS_DMA Arnd Bergmann
2009-05-12 0:58 ` Jeff Garzik
2009-05-12 12:40 ` Arnd Bergmann
2009-05-12 13:05 ` Arnd Bergmann
2009-05-12 8:06 ` Alan Cox
2009-05-12 9:23 ` Arnd Bergmann
2009-05-13 3:30 ` Brad Boyer
2009-05-13 4:12 ` Michael Schmitz
2009-05-13 4:34 ` Brad Boyer
2009-05-13 8:51 ` Alan Cox
2009-05-13 8:55 ` Geert Uytterhoeven
2009-05-13 23:57 ` Robert Hancock
2009-05-14 0:18 ` FUJITA Tomonori
2009-05-15 5:31 ` Tejun Heo
2009-05-15 11:16 ` Arnd Bergmann
2009-05-15 11:21 ` Tejun Heo
2009-05-15 11:55 ` Arnd Bergmann
2009-05-17 9:00 ` Robert Hancock
2009-05-17 19:38 ` Arnd Bergmann
2009-05-17 20:05 ` Jeff Garzik
2009-05-17 22:45 ` [PATCH] asm-generic: add a dma-mapping.h file Arnd Bergmann
2009-05-18 6:03 ` Geert Uytterhoeven
2009-05-18 8:28 ` Arnd Bergmann
2009-05-18 10:45 ` FUJITA Tomonori
2009-05-18 14:45 ` Arnd Bergmann
2009-05-18 22:44 ` FUJITA Tomonori
2009-05-19 16:22 ` Arnd Bergmann
2009-05-19 17:01 ` Grant Grundler
2009-05-19 17:40 ` Arnd Bergmann [this message]
2009-05-19 18:08 ` Grant Grundler
2009-05-22 12:12 ` FUJITA Tomonori
2009-05-22 14:07 ` Arnd Bergmann
2009-05-22 14:38 ` FUJITA Tomonori
2009-05-22 15:05 ` Arnd Bergmann
2009-05-26 4:36 ` FUJITA Tomonori
2009-05-18 22:54 ` Jeff Garzik
2009-05-18 23:22 ` FUJITA Tomonori
2009-05-18 10:45 ` [PATCH] ata: libata depends on HAS_DMA FUJITA Tomonori
2009-05-13 10:39 ` Arnd Bergmann
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=200905191740.21150.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=flar@allandria.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=geert@linux-m68k.org \
--cc=grundler@google.com \
--cc=hancockrwd@gmail.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=schmitz@biophys.uni-duesseldorf.de \
--cc=takata@linux-m32r.org \
--cc=ysato@users.sourceforge.jp \
/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).