Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 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
  3. 20 2月, 2015 1 次提交
  5. 30 1月, 2015 1 次提交
  7. 29 1月, 2015 1 次提交
  9. 02 12月, 2014 1 次提交
  11. 30 10月, 2014 1 次提交
  13. 10 10月, 2014 2 次提交
  15. 07 8月, 2014 1 次提交
  17. 18 7月, 2014 1 次提交
  19. 22 5月, 2014 2 次提交
  21. 20 5月, 2014 1 次提交
  23. 07 5月, 2014 1 次提交
  25. 23 4月, 2014 1 次提交
  27. 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
  29. 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
  31. 11 2月, 2014 1 次提交
  33. 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
  35. 10 12月, 2013 1 次提交
  37. 30 11月, 2013 1 次提交
  39. 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
  41. 24 10月, 2013 1 次提交
  43. 02 10月, 2013 1 次提交
  45. 12 8月, 2013 1 次提交
  47. 02 7月, 2013 1 次提交
  49. 28 6月, 2013 5 次提交
  51. 04 6月, 2013 1 次提交
  53. 23 5月, 2013 1 次提交
    • M
      ARM: 7730/1: DMA-mapping: mark all !DMA_TO_DEVICE pages in unmapping as clean · b2a234ed
      由 Ming Lei 提交于 
      It is common for one sg to include many pages, so mark all these
pages as clean to avoid unnecessary flushing on them in
set_pte_at() or update_mmu_cache().

The patch might improve loading performance of applciation code a bit.

On the below test code to read file(~1GByte size) from usb mass storage
disk to buffer created with mmap(PROT_READ | PROT_EXEC) on
Pandaboard, average ~1% improvement can be observed with the patch on
10 times test.

unsigned int sum = 0;
static unsigned long tv_diff(struct timeval *tv1, struct timeval *tv2)
{
	return (tv2->tv_sec - tv1->tv_sec) * 1000000 + (tv2->tv_usec - tv1->tv_usec);
}
int main(int argc, char *argv[])
{
	char *mbuffer;
	int fd;
	int i;
	unsigned long page_size, size;
	struct stat stat;
	struct timeval t1, t2;

	page_size = getpagesize();
	fd = open(argv[1], O_RDONLY);
	assert(fd >= 0);

	fstat(fd, &stat);
	size = stat.st_size;
	printf("%s: file %s, file size %lu, page size %lun", argv[0],
	        read_filename, size, page_size);

	gettimeofday(&t1, NULL);
	mbuffer = mmap(NULL, size, PROT_READ | PROT_EXEC, MAP_SHARED, fd, 0);
	for (i = 0 ; i < size ; i += page_size)
	        sum += mbuffer[i];
	munmap(mbuffer, page_size);
	gettimeofday(&t2, NULL);
	printf("tread mmaped time: %luusn", tv_diff(&t1, &t2));

	close(fd);
}
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b2a234ed
  55. 17 4月, 2013 1 次提交
  57. 14 3月, 2013 1 次提交
  59. 25 2月, 2013 4 次提交