On Tue, May 19, 2009 at 9:22 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
On Tuesday 19 May 2009, FUJITA Tomonori wrote:
Would you agree to a patch that works with the same
code on e.g. arm, microblaze, mn10300 and sh and
uses only a few #ifdefs?
Having such helper for a linear mapping might be helpful but your
approach is wrong.
Do you like this approach better? I've merged a few architectures
that were relatively simple. This file should be usable by all
architectures that have a linear mapping and are either fully coherent
(like cris) or just require flushing the dcache when passing a
buffer to the device.
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.
2) dma_map_single() is not respecting dma_mask in struct pci_dev (and
pointer from struct device).
...
+/**
+ * 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
And I'll confess pci-dma.c doesn't implement support for coherent_dma_mask .
AFAIK, the targeted platforms have < 4GB of RAM and only PCI devices.
ISA support is completely missing and is the only case this class of machines
need coherent_dma_mask support.
More comments on how DMA works for PARISC in
arch/parisc/include/asm/dma-mapping.h
hth,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
