From: Grant Grundler <grundler@google.com> To: Arnd Bergmann <arnd@arndb.de> 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 11:08:27 -0700 [thread overview] Message-ID: <da824cf30905191108y77a44a2av7911dc2784b7ea90@mail.gmail.com> (raw) In-Reply-To: <200905191740.21150.arnd@arndb.de> On Tue, May 19, 2009 at 10:40 AM, Arnd Bergmann <arnd@arndb.de> wrote: > 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? Not necessarily. It might work fine for the subset of machines that use that code. But generic code should use the masks - even if they are set to ~0UL. >> 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? Verify or enforce that the physical memory is allocated from a memory pool suitable for use by that device. If any bits "stick out" from the address (vs the mask), the device won't be able to DMA to that address and very likely truncate the address. By default the PCI dma_mask is 32-bits. Drivers that can support more than 32-bits (some PCI, most PCI-X and all PCI-E devices) will be calling pci_set_dma_mask() and pci_set_coherent_dma_mask() or the equivalent DMA API call. > All the architectures I've looked > at as well as arch/parisc/kernel/pci-dma.c ignore it. pci-dma.c ignores it for the same reason it ignores coherent_dma_mask. None of those parisc machines have host memory at a physical address that is NOT reachable via DMA by *all* known/supported devices. Maybe it's ok and we just need a comment stating the constraints of the generic code. And there must be some way (e.g. dma_support()) to verify the highest physical memory location is reachable by the given device. So that would be another way to enforce the mask. > Should dma_map_* just fail in case of an address exceeding dma_mask? That would probably be correct behavior too. But my gut feeling is we don't want the device driver module to load unless we know the device can DMA to any possible host memory location handed to dma_map_single(). My preference is the initialization path fail first. dma_alloc_coherent() is generally in the initialization path after the drivers call pci_set*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. That's what I expected. I'm pretty sure parisc could use a generic implementation for PA7100LC and PA7300LC CPUs (other parisc CPUs/memory controllers don't support uncached mappings to host memory). So we would need run-time detection and set dma_ops appropriately. > 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. Ok - cool! thanks, grant -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Grant Grundler <grundler@google.com> To: Arnd Bergmann <arnd@arndb.de> 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 11:08:27 -0700 [thread overview] Message-ID: <da824cf30905191108y77a44a2av7911dc2784b7ea90@mail.gmail.com> (raw) In-Reply-To: <200905191740.21150.arnd@arndb.de> On Tue, May 19, 2009 at 10:40 AM, Arnd Bergmann <arnd@arndb.de> wrote: > 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? Not necessarily. It might work fine for the subset of machines that use that code. But generic code should use the masks - even if they are set to ~0UL. >> 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? Verify or enforce that the physical memory is allocated from a memory pool suitable for use by that device. If any bits "stick out" from the address (vs the mask), the device won't be able to DMA to that address and very likely truncate the address. By default the PCI dma_mask is 32-bits. Drivers that can support more than 32-bits (some PCI, most PCI-X and all PCI-E devices) will be calling pci_set_dma_mask() and pci_set_coherent_dma_mask() or the equivalent DMA API call. > All the architectures I've looked > at as well as arch/parisc/kernel/pci-dma.c ignore it. pci-dma.c ignores it for the same reason it ignores coherent_dma_mask. None of those parisc machines have host memory at a physical address that is NOT reachable via DMA by *all* known/supported devices. Maybe it's ok and we just need a comment stating the constraints of the generic code. And there must be some way (e.g. dma_support()) to verify the highest physical memory location is reachable by the given device. So that would be another way to enforce the mask. > Should dma_map_* just fail in case of an address exceeding dma_mask? That would probably be correct behavior too. But my gut feeling is we don't want the device driver module to load unless we know the device can DMA to any possible host memory location handed to dma_map_single(). My preference is the initialization path fail first. dma_alloc_coherent() is generally in the initialization path after the drivers call pci_set*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. That's what I expected. I'm pretty sure parisc could use a generic implementation for PA7100LC and PA7300LC CPUs (other parisc CPUs/memory controllers don't support uncached mappings to host memory). So we would need run-time detection and set dma_ops appropriately. > 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. Ok - cool! thanks, grant
next prev parent reply other threads:[~2009-05-19 18:08 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20090511222702.352192505@arndb.de> 2009-05-11 22:37 ` [PATCH] mb862xxfb: use CONFIG_OF instead of CONFIG_PPC_OF Arnd Bergmann 2009-05-13 12:25 ` Anatolij Gustschin 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 13:05 ` Arnd Bergmann 2009-05-12 8:06 ` Alan Cox 2009-05-12 9:23 ` Arnd Bergmann 2009-05-12 9:23 ` Arnd Bergmann 2009-05-13 3:30 ` Brad Boyer 2009-05-13 3:30 ` Brad Boyer 2009-05-13 4:12 ` Michael Schmitz 2009-05-13 4:12 ` Michael Schmitz 2009-05-13 4:12 ` Michael Schmitz 2009-05-13 4:34 ` Brad Boyer 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: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 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 2009-05-19 18:08 ` Grant Grundler [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-26 12:35 ` Arnd Bergmann 2009-05-27 3:58 ` 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 2009-05-13 10:39 ` Arnd Bergmann 2009-05-13 10:39 ` Arnd Bergmann 2009-05-11 22:40 ` [PATCH] scsi: libsas " Arnd Bergmann 2009-05-11 22:50 ` James Bottomley 2009-05-11 22:59 ` James Bottomley 2009-05-11 23:16 ` Arnd Bergmann 2009-05-11 22:43 ` [PATCH] arm: rename CLOCK_TICK_RATE to ARM_TICK_RATE Arnd Bergmann 2009-05-11 23:11 ` [PATCH v2] " Arnd Bergmann 2009-05-13 17:11 ` [PATCH] " Arnd Bergmann 2009-05-11 22:50 ` [PATCH] x86: use PIT_TICK_RATE consistently Arnd Bergmann 2009-05-11 23:05 ` Arnd Bergmann 2009-05-11 22:55 ` [PATCH] move PIT_TICK_RATE to linux/timex.h Arnd Bergmann 2009-05-11 22:55 ` Arnd Bergmann 2009-05-12 0:01 ` Andrew Morton 2009-05-12 0:36 ` Arnd Bergmann 2009-05-11 22:57 ` [PATCH] mips: use PIT_TICK_RATE in i8253 Arnd Bergmann 2009-05-11 22:58 ` [PATCH] input: use PIT_TICK_RATE in vt beep ioctl Arnd Bergmann 2009-05-12 9:31 ` Alan Cox 2009-05-11 22:59 ` [PATCH] x86: fix ktermios-termio conversion Arnd Bergmann 2009-05-11 23:19 ` [PATCH v2] " Arnd Bergmann 2009-05-12 7:55 ` Ingo Molnar 2009-05-12 9:04 ` Arnd Bergmann 2009-05-12 9:10 ` Ingo Molnar 2009-05-12 9:21 ` Alan Cox 2009-05-12 9:26 ` Ingo Molnar 2009-05-12 10:05 ` Alan Cox 2009-05-12 10:15 ` Ingo Molnar 2009-05-12 11:33 ` [PATCH v3] " Arnd Bergmann 2009-05-12 11:42 ` [PATCH v2] " Arnd Bergmann 2009-05-12 9:17 ` Alan Cox 2009-05-11 23:02 ` [PATCH] ipc: use __ARCH_WANT_IPC_PARSE_VERSION in ipc/util.h Arnd Bergmann 2009-05-12 0:19 ` Serge E. Hallyn 2009-05-11 23:03 ` [PATCH] syscalls.h add the missing sys_pipe2 declaration Arnd Bergmann 2009-05-11 23:08 ` 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=da824cf30905191108y77a44a2av7911dc2784b7ea90@mail.gmail.com \ --to=grundler@google.com \ --cc=alan@lxorguk.ukuu.org.uk \ --cc=arnd@arndb.de \ --cc=flar@allandria.com \ --cc=fujita.tomonori@lab.ntt.co.jp \ --cc=geert@linux-m68k.org \ --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: linkBe 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.