1. 11 2月, 2014 1 次提交
  2. 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
  3. 10 12月, 2013 1 次提交
  4. 30 11月, 2013 1 次提交
  5. 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
  6. 24 10月, 2013 1 次提交
  7. 02 10月, 2013 1 次提交
  8. 12 8月, 2013 1 次提交
  9. 02 7月, 2013 1 次提交
  10. 28 6月, 2013 5 次提交
  11. 04 6月, 2013 1 次提交
  12. 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
  13. 17 4月, 2013 1 次提交
  14. 14 3月, 2013 1 次提交
  15. 25 2月, 2013 7 次提交
  16. 08 2月, 2013 1 次提交
    • R
      ARM: DMA mapping: fix bad atomic test · 633dc92a
      Russell King 提交于
      Realview fails to boot with this warning:
      BUG: spinlock lockup suspected on CPU#0, init/1
       lock: 0xcf8bde10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:cf8bde10 r5:cf83d1c0 r4:cf8bde10 r3:cf83d1c0
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c018926c>] (spin_dump+0x84/0x98)
      [<c01891e8>] (spin_dump+0x0/0x98) from [<c0189460>] (do_raw_spin_lock+0x100/0x198)
      [<c0189360>] (do_raw_spin_lock+0x0/0x198) from [<c032cbac>] (_raw_spin_lock+0x3c/0x44)
      [<c032cb70>] (_raw_spin_lock+0x0/0x44) from [<c01c9224>] (pl011_console_write+0xe8/0x11c)
      [<c01c913c>] (pl011_console_write+0x0/0x11c) from [<c002aea8>] (call_console_drivers.clone.7+0xdc/0x104)
      [<c002adcc>] (call_console_drivers.clone.7+0x0/0x104) from [<c002b320>] (console_unlock+0x2e8/0x454)
      [<c002b038>] (console_unlock+0x0/0x454) from [<c002b8b4>] (vprintk_emit+0x2d8/0x594)
      [<c002b5dc>] (vprintk_emit+0x0/0x594) from [<c0329718>] (printk+0x3c/0x44)
      [<c03296dc>] (printk+0x0/0x44) from [<c002929c>] (warn_slowpath_common+0x28/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c)
      [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0070ab0>] (lockdep_trace_alloc+0xd8/0xf0)
      [<c00709d8>] (lockdep_trace_alloc+0x0/0xf0) from [<c00c0850>] (kmem_cache_alloc+0x24/0x11c)
      [<c00c082c>] (kmem_cache_alloc+0x0/0x11c) from [<c00bb044>] (__get_vm_area_node.clone.24+0x7c/0x16c)
      [<c00bafc8>] (__get_vm_area_node.clone.24+0x0/0x16c) from [<c00bb7b8>] (get_vm_area_caller+0x48/0x54)
      [<c00bb770>] (get_vm_area_caller+0x0/0x54) from [<c0020064>] (__alloc_remap_buffer.clone.15+0x38/0xb8)
      [<c002002c>] (__alloc_remap_buffer.clone.15+0x0/0xb8) from [<c0020244>] (__dma_alloc+0x160/0x2c8)
      [<c00200e4>] (__dma_alloc+0x0/0x2c8) from [<c00204d8>] (arm_dma_alloc+0x88/0xa0)[<c0020450>] (arm_dma_alloc+0x0/0xa0) from [<c00beb00>] (dma_pool_alloc+0xcc/0x1a8)
      [<c00bea34>] (dma_pool_alloc+0x0/0x1a8) from [<c01a9d14>] (pl08x_fill_llis_for_desc+0x28/0x568)
      [<c01a9cec>] (pl08x_fill_llis_for_desc+0x0/0x568) from [<c01aab8c>] (pl08x_prep_slave_sg+0x258/0x3b0)
      [<c01aa934>] (pl08x_prep_slave_sg+0x0/0x3b0) from [<c01c9f74>] (pl011_dma_tx_refill+0x140/0x288)
      [<c01c9e34>] (pl011_dma_tx_refill+0x0/0x288) from [<c01ca748>] (pl011_start_tx+0xe4/0x120)
      [<c01ca664>] (pl011_start_tx+0x0/0x120) from [<c01c54a4>] (__uart_start+0x48/0x4c)
      [<c01c545c>] (__uart_start+0x0/0x4c) from [<c01c632c>] (uart_start+0x2c/0x3c)
      [<c01c6300>] (uart_start+0x0/0x3c) from [<c01c795c>] (uart_write+0xcc/0xf4)
      [<c01c7890>] (uart_write+0x0/0xf4) from [<c01b0384>] (n_tty_write+0x1c0/0x3e4)
      [<c01b01c4>] (n_tty_write+0x0/0x3e4) from [<c01acfe8>] (tty_write+0x144/0x240)
      [<c01acea4>] (tty_write+0x0/0x240) from [<c01ad17c>] (redirected_tty_write+0x98/0xac)
      [<c01ad0e4>] (redirected_tty_write+0x0/0xac) from [<c00c371c>] (vfs_write+0xbc/0x150)
      [<c00c3660>] (vfs_write+0x0/0x150) from [<c00c39c0>] (sys_write+0x4c/0x78)
      [<c00c3974>] (sys_write+0x0/0x78) from [<c0014460>] (ret_fast_syscall+0x0/0x3c)
      
      This happens because the DMA allocation code is not respecting atomic
      allocations correctly.
      
      GFP flags should not be tested for GFP_ATOMIC to determine if an
      atomic allocation is being requested.  GFP_ATOMIC is not a flag but
      a value.  The GFP bitmask flags are all prefixed with __GFP_.
      
      The rest of the kernel tests for __GFP_WAIT not being set to indicate
      an atomic allocation.  We need to do the same.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      633dc92a
  17. 19 1月, 2013 1 次提交
  18. 29 11月, 2012 1 次提交
  19. 22 11月, 2012 1 次提交
  20. 24 10月, 2012 1 次提交
  21. 02 10月, 2012 5 次提交
  22. 24 9月, 2012 1 次提交
  23. 10 9月, 2012 1 次提交
    • T
      arm: mm: fix DMA pool affiliation check · f3d87524
      Thomas Petazzoni 提交于
      The __free_from_pool() function was changed in
      e9da6e99. Unfortunately, the test that
      checks whether the provided (start,size) is within the DMA pool has
      been improperly modified. It used to be:
      
        if (start < coherent_head.vm_start || end > coherent_head.vm_end)
      
      Where coherent_head.vm_end was non-inclusive (i.e, it did not include
      the first byte after the pool). The test has been changed to:
      
        if (start < pool->vaddr || start > pool->vaddr + pool->size)
      
      So now pool->vaddr + pool->size is inclusive (i.e, it includes the
      first byte after the pool), so the test should be >= instead of >.
      
      This bug causes the following message when freeing the *first* DMA
      coherent buffer that has been allocated, because its virtual address
      is exactly equal to pool->vaddr + pool->size :
      
      WARNING: at /home/thomas/projets/linux-2.6/arch/arm/mm/dma-mapping.c:463 __free_from_pool+0xa4/0xc0()
      freeing wrong coherent size from pool
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Lior Amsalem <alior@marvell.com>
      Cc: Maen Suleiman <maen@marvell.com>
      Cc: Tawfik Bayouk <tawfik@marvell.com>
      Cc: Shadi Ammouri <shadi@marvell.com>
      Cc: Eran Ben-Avi <benavi@marvell.com>
      Cc: Yehuda Yitschak <yehuday@marvell.com>
      Cc: Nadav Haklai <nadavh@marvell.com>
      [m.szyprowski: rebased onto v3.6-rc5 and resolved conflict]
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      f3d87524
  24. 29 8月, 2012 3 次提交