Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 9月, 2015 1 次提交
    • A
      ARM: 8437/1: dma-mapping: fix build warning with new DMA_ERROR_CODE definition · 90cde558
      由 Andre Przywara 提交于 
      Commit 96231b26: ("ARM: 8419/1: dma-mapping: harmonize definition
of DMA_ERROR_CODE") changed the definition of DMA_ERROR_CODE to use
dma_addr_t, which makes the compiler barf on assigning this to an
"int" variable on ARM with LPAE enabled:
*************
In file included from /src/linux/include/linux/dma-mapping.h:86:0,
                 from /src/linux/arch/arm/mm/dma-mapping.c:21:
/src/linux/arch/arm/mm/dma-mapping.c: In function '__iommu_create_mapping':
/src/linux/arch/arm/include/asm/dma-mapping.h:16:24: warning:
overflow in implicit constant conversion [-Woverflow]
 #define DMA_ERROR_CODE (~(dma_addr_t)0x0)
                        ^
/src/linux/arch/arm/mm/dma-mapping.c:1252:15: note: in expansion of
macro DMA_ERROR_CODE'
  int i, ret = DMA_ERROR_CODE;
               ^
*************

Remove the actually unneeded initialization of "ret" in
__iommu_create_mapping() and move the variable declaration inside the
for-loop to make the scope of this variable more clear.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      90cde558
  3. 17 7月, 2015 1 次提交
  5. 06 6月, 2015 1 次提交
    • M
      ARM: 8387/1: arm/mm/dma-mapping.c: Add arm_coherent_dma_mmap · 55af8a91
      由 Mike Looijmans 提交于 
      When dma-coherent transfers are enabled, the mmap call must
not change the pg_prot flags in the vma struct.

Split the arm_dma_mmap into a common and specific parts,
and add a "arm_coherent_dma_mmap" implementation that does
not alter the page protection flags.

Tested on a topic-miami board (Zynq) using the ACP port
to transfer data between FPGA and CPU using the Dyplo
framework. Without this patch, byte-wise access to mmapped
coherent DMA memory was about 20x slower because of the
memory being marked as non-cacheable, and transfer speeds
would not exceed 240MB/s.

After this patch, the mapped memory is cacheable and the
transfer speed is again 600MB/s (limited by the FPGA) when
the data is in the L2 cache, while data integrity is being
maintained.

The patch has no effect on non-coherent DMA.
Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      55af8a91
  7. 04 5月, 2015 1 次提交
  9. 02 4月, 2015 1 次提交
  11. 18 3月, 2015 1 次提交
  13. 13 3月, 2015 1 次提交
  15. 11 3月, 2015 1 次提交
    • R
      ARM: dma-api: fix off-by-one error in __dma_supported() · 8bf1268f
      由 Russell King 提交于 
      When validating the mask against the amount of memory we have available
(so that we can trap 32-bit DMA addresses with >32-bits memory), we had
not taken account of the fact that max_pfn is the maximum PFN number
plus one that would be in the system.

There are several references in the code which bear this out:

mm/page_owner.c:
	for (; pfn < max_pfn; pfn++) {
	}

arch/x86/kernel/setup.c:
	high_memory = (void *)__va(max_pfn * PAGE_SIZE - 1)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8bf1268f
  17. 23 2月, 2015 1 次提交
  19. 20 2月, 2015 1 次提交
  21. 30 1月, 2015 1 次提交
  23. 29 1月, 2015 1 次提交
  25. 02 12月, 2014 1 次提交
  27. 30 10月, 2014 1 次提交
  29. 10 10月, 2014 2 次提交
  31. 07 8月, 2014 1 次提交
  33. 18 7月, 2014 1 次提交
  35. 22 5月, 2014 2 次提交
  37. 20 5月, 2014 1 次提交
  39. 07 5月, 2014 1 次提交
  41. 23 4月, 2014 1 次提交
  43. 28 2月, 2014 2 次提交
    • M
      arm: dma-mapping: remove order parameter from arm_iommu_create_mapping() · 68efd7d2
      由 Marek Szyprowski 提交于 
      The 'order' parameter for IOMMU-aware dma-mapping implementation was
introduced mainly as a hack to reduce size of the bitmap used for
tracking IO virtual address space. Since now it is possible to dynamically
resize the bitmap, this hack is not needed and can be removed without any
impact on the client devices. This way the parameters for
arm_iommu_create_mapping() becomes much easier to understand. 'size'
parameter now means the maximum supported IO address space size.

The code will allocate (resize) bitmap in chunks, ensuring that a single
chunk is not larger than a single memory page to avoid unreliable
allocations of size larger than PAGE_SIZE in atomic context.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      68efd7d2
    • A
      arm: dma-mapping: Add support to extend DMA IOMMU mappings · 4d852ef8
      由 Andreas Herrmann 提交于 
      Instead of using just one bitmap to keep track of IO virtual addresses
(handed out for IOMMU use) introduce an array of bitmaps. This allows
us to extend existing mappings when running out of iova space in the
initial mapping etc.

If there is not enough space in the mapping to service an IO virtual
address allocation request, __alloc_iova() tries to extend the mapping
-- by allocating another bitmap -- and makes another allocation
attempt using the freshly allocated bitmap.

This allows arm iommu drivers to start with a decent initial size when
an dma_iommu_mapping is created and still to avoid running out of IO
virtual addresses for the mapping.
Signed-off-by: NAndreas Herrmann <andreas.herrmann@calxeda.com>
[mszyprow: removed extensions parameter to arm_iommu_create_mapping()
 function, which will be modified in the next patch anyway, also some
 debug messages about extending bitmap]
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      4d852ef8
  45. 19 2月, 2014 1 次提交
    • S
      ARM: 7979/1: mm: Remove hugetlb warning from Coherent DMA allocator · 6ea41c80
      由 Steven Capper 提交于 
      The Coherant DMA allocator allocates pages of high order then splits
them up into smaller pages.

This splitting logic would run into problems if the allocator was
given compound pages. Thus the Coherant DMA allocator was originally
incompatible with compound pages existing and, by extension, huge
pages. A compile #error was put in place whenever huge pages were
enabled.

Compatibility with compound pages has since been introduced by the
following commit (which merely excludes GFP_COMP pages from being
requested by the coherant DMA allocator):
  ea2e7057 ARM: 7172/1: dma: Drop GFP_COMP for DMA memory allocations

When huge page support was introduced to ARM, the compile #error in
dma-mapping.c was replaced by a #warning when it should have been
removed instead.

This patch removes the compile #warning in dma-mapping.c when huge
pages are enabled.
Signed-off-by: NSteve Capper <steve.capper@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6ea41c80
  47. 11 2月, 2014 1 次提交
  49. 11 12月, 2013 1 次提交
    • R
      ARM: fix executability of CMA mappings · 71b55663
      由 Russell King 提交于 
      The CMA region was being marked executable:

0xdc04e000-0xdc050000           8K     RW x      MEM/CACHED/WBRA
0xdc060000-0xdc100000         640K     RW x      MEM/CACHED/WBRA
0xdc4f5000-0xdc500000          44K     RW x      MEM/CACHED/WBRA
0xdcce9000-0xe0000000       52316K     RW x      MEM/CACHED/WBRA

This is mainly due to the badly worded MT_MEMORY_DMA_READY symbol, but
there are also a few other places in dma-mapping which should be
corrected to use the right constant.  Fix all these places:

0xdc04e000-0xdc050000           8K     RW NX     MEM/CACHED/WBRA
0xdc060000-0xdc100000         640K     RW NX     MEM/CACHED/WBRA
0xdc280000-0xdc300000         512K     RW NX     MEM/CACHED/WBRA
0xdc6fc000-0xe0000000       58384K     RW NX     MEM/CACHED/WBRA
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      71b55663
  51. 10 12月, 2013 1 次提交
  53. 30 11月, 2013 1 次提交
  55. 31 10月, 2013 1 次提交
    • R
      ARM: DMA-API: better handing of DMA masks for coherent allocations · 4dcfa600
      由 Russell King 提交于 
      We need to start treating DMA masks as something which is specific to
the bus that the device resides on, otherwise we're going to hit all
sorts of nasty issues with LPAE and 32-bit DMA controllers in >32-bit
systems, where memory is offset from PFN 0.

In order to start doing this, we convert the DMA mask to a PFN using
the device specific dma_to_pfn() macro.  This is the reverse of the
pfn_to_dma() macro which is used to get the DMA address for the device.

This gives us a PFN mask, which we can then check against the PFN
limit of the DMA zone.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4dcfa600
  57. 24 10月, 2013 1 次提交
  59. 02 10月, 2013 1 次提交
  61. 12 8月, 2013 1 次提交
  63. 02 7月, 2013 1 次提交
  65. 28 6月, 2013 5 次提交