<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/tile/include/asm/dma-mapping.h, branch dev-4.4</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.4</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.4'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-09-10T20:29:01+00:00</updated>
<entry>
<title>dma-mapping: consolidate dma_set_mask</title>
<updated>2015-09-10T20:29:01+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-09-09T22:39:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=452e06af1f0149b01201f94264d452cd7a95db7a'/>
<id>urn:sha1:452e06af1f0149b01201f94264d452cd7a95db7a</id>
<content type='text'>
Almost everyone implements dma_set_mask the same way, although some time
that's hidden in -&gt;set_dma_mask methods.

This patch consolidates those into a common implementation that either
calls -&gt;set_dma_mask if present or otherwise uses the default
implementation.  Some architectures used to only call -&gt;set_dma_mask
after the initial checks, and those instance have been fixed to do the
full work.  h8300 implemented dma_set_mask bogusly as a no-ops and has
been fixed.

Unfortunately some architectures overload unrelated semantics like changing
the dma_ops into it so we still need to allow for an architecture override
for now.

[jcmvbkbc@gmail.com: fix xtensa]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Guan Xuetao &lt;gxt@mprc.pku.edu.cn&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>dma-mapping: consolidate dma_supported</title>
<updated>2015-09-10T20:29:01+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-09-09T22:39:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ee196371d5cb1942ebdccc16bdce389812aa265e'/>
<id>urn:sha1:ee196371d5cb1942ebdccc16bdce389812aa265e</id>
<content type='text'>
Most architectures just call into -&gt;dma_supported, but some also return 1
if the method is not present, or 0 if no dma ops are present (although
that should never happeb). Consolidate this more broad version into
common code.

Also fix h8300 which inorrectly always returned 0, which would have been
a problem if it's dma_set_mask implementation wasn't a similarly buggy
noop.

As a few architectures have much more elaborate implementations, we
still allow for arch overrides.

[jcmvbkbc@gmail.com: fix xtensa]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Guan Xuetao &lt;gxt@mprc.pku.edu.cn&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>dma-mapping: cosolidate dma_mapping_error</title>
<updated>2015-09-10T20:29:01+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-09-09T22:39:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=efa21e432c7b3c8ae976039d614a017799b6e874'/>
<id>urn:sha1:efa21e432c7b3c8ae976039d614a017799b6e874</id>
<content type='text'>
Currently there are three valid implementations of dma_mapping_error:

 (1) call -&gt;mapping_error
 (2) check for a hardcoded error code
 (3) always return 0

This patch provides a common implementation that calls -&gt;mapping_error
if present, then checks for DMA_ERROR_CODE if defined or otherwise
returns 0.

[jcmvbkbc@gmail.com: fix xtensa]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Guan Xuetao &lt;gxt@mprc.pku.edu.cn&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>dma-mapping: consolidate dma_{alloc,free}_noncoherent</title>
<updated>2015-09-10T20:29:01+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-09-09T22:39:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1e8937526e2309d48fccd81bb30a590ac21a5516'/>
<id>urn:sha1:1e8937526e2309d48fccd81bb30a590ac21a5516</id>
<content type='text'>
Most architectures do not support non-coherent allocations and either
define dma_{alloc,free}_noncoherent to their coherent versions or stub
them out.

Openrisc uses dma_{alloc,free}_attrs to implement them, and only Mips
implements them directly.

This patch moves the Openrisc version to common code, and handles the
DMA_ATTR_NON_CONSISTENT case in the mips dma_map_ops instance.

Note that actual non-coherent allocations require a dma_cache_sync
implementation, so if non-coherent allocations didn't work on
an architecture before this patch they still won't work after it.

[jcmvbkbc@gmail.com: fix xtensa]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Guan Xuetao &lt;gxt@mprc.pku.edu.cn&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}</title>
<updated>2015-09-10T20:29:01+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-09-09T22:39:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6894258eda2f9badc28c878086c0e54bd5b7fb30'/>
<id>urn:sha1:6894258eda2f9badc28c878086c0e54bd5b7fb30</id>
<content type='text'>
Since 2009 we have a nice asm-generic header implementing lots of DMA API
functions for architectures using struct dma_map_ops, but unfortunately
it's still missing a lot of APIs that all architectures still have to
duplicate.

This series consolidates the remaining functions, although we still need
arch opt outs for two of them as a few architectures have very
non-standard implementations.

This patch (of 5):

The coherent DMA allocator works the same over all architectures supporting
dma_map operations.

This patch consolidates them and converges the minor differences:

 - the debug_dma helpers are now called from all architectures, including
   those that were previously missing them
 - dma_alloc_from_coherent and dma_release_from_coherent are now always
   called from the generic alloc/free routines instead of the ops
   dma-mapping-common.h always includes dma-coherent.h to get the defintions
   for them, or the stubs if the architecture doesn't support this feature
 - checks for -&gt;alloc / -&gt;free presence are removed.  There is only one
   magic instead of dma_map_ops without them (mic_dma_ops) and that one
   is x86 only anyway.

Besides that only x86 needs special treatment to replace a default devices
if none is passed and tweak the gfp_flags.  An optional arch hook is provided
for that.

[linux@roeck-us.net: fix build]
[jcmvbkbc@gmail.com: fix xtensa]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Guan Xuetao &lt;gxt@mprc.pku.edu.cn&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>tile PCI RC: make default consistent DMA mask 32-bit</title>
<updated>2013-09-03T18:53:37+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2013-08-30T14:12:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b40f451d56de69477a2244a0b4082f644699673f'/>
<id>urn:sha1:b40f451d56de69477a2244a0b4082f644699673f</id>
<content type='text'>
This change sets the PCI devices' initial DMA capabilities
conservatively and promotes them at the request of the driver,
as opposed to assuming advanced DMA capabilities. The old design
runs the risk of breaking drivers that assume default capabilities.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>tile PCI RC: add dma_get_required_mask()</title>
<updated>2013-08-06T16:56:00+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2013-08-05T17:40:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dc7d5cf2cab6d1fbb43c5c0569f43b7e4c822760'/>
<id>urn:sha1:dc7d5cf2cab6d1fbb43c5c0569f43b7e4c822760</id>
<content type='text'>
The standard kernel function dma_get_required_mask() uses the
highest DRAM address to determine if 32-bit or 64-bit DMA addressing
is needed.  This only works on architectures that have direct mapping
between the PA and the PCI address space, i.e. those that don't have
I/O TLBs or have I/O TLB but choose to use direct mapping.  Neither
of these are true for tilegx.  Whether to use 64-bit DMA should depend
on the PCI device's capability only, not on the amount of DRAM
installeds, so we now advertise a 64-bit DMA mask unconditionally.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>tile: support LSI MEGARAID SAS HBA hybrid dma_ops</title>
<updated>2013-08-06T16:52:33+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2013-08-02T16:24:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=803c874abe1358998ab65a8cca728684ebb50a13'/>
<id>urn:sha1:803c874abe1358998ab65a8cca728684ebb50a13</id>
<content type='text'>
The LSI MEGARAID SAS HBA suffers from the problem where it can do
64-bit DMA to streaming buffers but not to consistent buffers.
In other words, 64-bit DMA is used for disk data transfers and 32-bit
DMA must be used for control message transfers. According to LSI,
the firmware is not fully functional yet. This change implements a
kind of hybrid dma_ops to support this.

Note that on most other platforms, the 64-bit DMA addressing space is the
same as the 32-bit DMA space and they overlap the physical memory space.
No special arrangement is needed to support this kind of mixed DMA
capability.  On TILE-Gx, the 64-bit DMA space is completely separate
from the 32-bit DMA space.  Due to the use of the IOMMU, the 64-bit DMA
space doesn't overlap the physical memory space.  On the other hand,
the 32-bit DMA space overlaps the physical memory space under 4GB.
The separate address spaces make it necessary to have separate dma_ops.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>tile: dma_debug: add debug_dma_mapping_error support</title>
<updated>2012-11-28T14:29:00+00:00</updated>
<author>
<name>Shuah Khan</name>
<email>shuah.khan@hp.com</email>
</author>
<published>2012-11-23T21:37:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fd78a95ac662a18e94509b7314c327475cbeafb4'/>
<id>urn:sha1:fd78a95ac662a18e94509b7314c327475cbeafb4</id>
<content type='text'>
Add dma-debug interface debug_dma_mapping_error() to debug drivers that fail
to check dma mapping errors on addresses returned by dma_map_single() and
dma_map_page() interfaces.

Signed-off-by: Shuah Khan &lt;shuah.khan@hp.com&gt;
Signed-off-by: Joerg Roedel &lt;joro@8bytes.org&gt;
</content>
</entry>
<entry>
<title>tile pci: enable IOMMU to support DMA for legacy devices</title>
<updated>2012-07-18T20:40:17+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2012-06-15T19:23:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=41bb38fc5398ae878c799647f3c4b25374029afb'/>
<id>urn:sha1:41bb38fc5398ae878c799647f3c4b25374029afb</id>
<content type='text'>
This change uses the TRIO IOMMU to map the PCI DMA space and physical
memory at different addresses.  We also now use the dma_mapping_ops
to provide support for non-PCI DMA, PCIe DMA (64-bit) and legacy PCI
DMA (32-bit).  We use the kernel's software I/O TLB framework
(i.e. bounce buffers) for the legacy 32-bit PCI device support since
there are a limited number of TLB entries in the IOMMU and it is
non-trivial to handle indexing, searching, matching, etc.  For 32-bit
devices the performance impact of bounce buffers should not be a concern.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
</feed>
