1. 23 Oct, 2012 2 commits
  2. 13 Oct, 2012 1 commit
    • Russell King's avatar
      ARM: config: sort select statements alphanumerically · b1b3f49c
      Russell King authored
      
      
      As suggested by Andrew Morton:
      
        This is a pet peeve of mine.  Any time there's a long list of items
        (header file inclusions, kconfig entries, array initalisers, etc) and
        someone wants to add a new item, they *always* go and stick it at the
        end of the list.
      
        Guys, don't do this.  Either put the new item into a randomly-chosen
        position or, probably better, alphanumerically sort the list.
      
      lets sort all our select statements alphanumerically.  This commit was
      created by the following perl:
      
      while (<>) {
      	while (/\\\s*$/) {
      		$_ .= <>;
      	}
      	undef %selects if /^\s*config\s+/;
      	if (/^\s+select\s+(\w+).*/) {
      		if (defined($selects{$1})) {
      			if ($selects{$1} eq $_) {
      				print STDERR "Warning: removing duplicated $1 entry\n";
      			} else {
      				print STDERR "Error: $1 differently selected\n".
      					"\tOld: $selects{$1}\n".
      					"\tNew: $_\n";
      				exit 1;
      			}
      		}
      		$selects{$1} = $_;
      		next;
      	}
      	if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or
      			  /^endif/ or /^endchoice/)) {
      		foreach $k (sort (keys %selects)) {
      			print "$selects{$k}";
      		}
      		undef %selects;
      	}
      	print;
      }
      if (%selects) {
      	foreach $k (sort (keys %selects)) {
      		print "$selects{$k}";
      	}
      }
      
      It found two duplicates:
      
      Warning: removing duplicated S5P_SETUP_MIPIPHY entry
      Warning: removing duplicated HARDIRQS_SW_RESEND entry
      
      and they are identical duplicates, hence the shrinkage in the diffstat
      of two lines.
      
      We have four testers reporting success of this change (Tony, Stephen,
      Linus and Sekhar.)
      Acked-by: default avatarJason Cooper <jason@lakedaemon.net>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b1b3f49c
  3. 09 Oct, 2012 2 commits
    • Shaohua Li's avatar
      readahead: fault retry breaks mmap file read random detection · 45cac65b
      Shaohua Li authored
      
      
      .fault now can retry.  The retry can break state machine of .fault.  In
      filemap_fault, if page is miss, ra->mmap_miss is increased.  In the second
      try, since the page is in page cache now, ra->mmap_miss is decreased.  And
      these are done in one fault, so we can't detect random mmap file access.
      
      Add a new flag to indicate .fault is tried once.  In the second try, skip
      ra->mmap_miss decreasing.  The filemap_fault state machine is ok with it.
      
      I only tested x86, didn't test other archs, but looks the change for other
      archs is obvious, but who knows :)
      Signed-off-by: default avatarShaohua Li <shaohua.li@fusionio.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      45cac65b
    • Michel Lespinasse's avatar
      mm: replace vma prio_tree with an interval tree · 6b2dbba8
      Michel Lespinasse authored
      
      
      Implement an interval tree as a replacement for the VMA prio_tree.  The
      algorithms are similar to lib/interval_tree.c; however that code can't be
      directly reused as the interval endpoints are not explicitly stored in the
      VMA.  So instead, the common algorithm is moved into a template and the
      details (node type, how to get interval endpoints from the node, etc) are
      filled in using the C preprocessor.
      
      Once the interval tree functions are available, using them as a
      replacement to the VMA prio tree is a relatively simple, mechanical job.
      Signed-off-by: default avatarMichel Lespinasse <walken@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6b2dbba8
  4. 02 Oct, 2012 6 commits
  5. 28 Sep, 2012 3 commits
  6. 25 Sep, 2012 3 commits
    • Santosh Shilimkar's avatar
      ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API · 6323fa22
      Santosh Shilimkar authored
      
      
      The ARMv7 processor setup function __v7_setup() cleans and invalidates the
      CPU cache before enabling MMU to start the CPU with a clean CPU local cache.
      
      But on ARMv7 architectures like Cortex-[A15/A8], this code will end
      up flushing the L2 caches(up to level of Coherency) which is undesirable
      and expensive. The setup functions are used in the CPU hotplug scenario too
      and hence flushing all cache levels should be avoided.
      
      This patch replaces the cache flushing call with the newly introduced
      v7 dcache LoUIS API where only cache levels up to LoUIS are cleaned and
      invalidated when a processors executes __v7_setup which is the expected
      behavior.
      
      For processors like A9 and A5 where the L2 cache is an outer one the
      behavior should be unchanged.
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: default avatarShawn Guo <shawn.guo@linaro.org>
      6323fa22
    • Lorenzo Pieralisi's avatar
      ARM: mm: rename jump labels in v7_flush_dcache_all function · 3287be8c
      Lorenzo Pieralisi authored
      
      
      This patch renames jump labels in v7_flush_dcache_all in order to define
      a specific flush cache levels entry point.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: default avatarShawn Guo <shawn.guo@linaro.org>
      3287be8c
    • Lorenzo Pieralisi's avatar
      ARM: mm: implement LoUIS API for cache maintenance ops · 031bd879
      Lorenzo Pieralisi authored
      
      
      ARM v7 architecture introduced the concept of cache levels and related
      control registers. New processors like A7 and A15 embed an L2 unified cache
      controller that becomes part of the cache level hierarchy. Some operations in
      the kernel like cpu_suspend and __cpu_disable do not require a flush of the
      entire cache hierarchy to DRAM but just the cache levels belonging to the
      Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
      correspond to L1.
      
      The current cache flushing API used in cpu_suspend and __cpu_disable,
      flush_cache_all(), ends up flushing the whole cache hierarchy since for
      v7 it cleans and invalidates all cache levels up to Level of Coherency
      (LoC) which cripples system performance when used in hot paths like hotplug
      and cpuidle.
      
      Therefore a new kernel cache maintenance API must be added to cope with
      latest ARM system requirements.
      
      This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.
      
      This function cleans and invalidates all data cache levels up to the
      Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
      cache for processors that support it (> v7).
      
      This patch also creates an alias of the cache LoUIS function to flush_kern_all
      for all processor versions prior to v7, so that the current cache flushing
      behaviour is unchanged for those processors.
      
      v7 cache maintenance code implements a cache LoUIS function that cleans and
      invalidates the D-cache up to LoUIS and invalidates the I-cache, according
      to the new API.
      Reviewed-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: default avatarShawn Guo <shawn.guo@linaro.org>
      031bd879
  7. 24 Sep, 2012 1 commit
  8. 19 Sep, 2012 1 commit
  9. 15 Sep, 2012 2 commits
  10. 11 Sep, 2012 1 commit
  11. 10 Sep, 2012 1 commit
    • Thomas Petazzoni's avatar
      arm: mm: fix DMA pool affiliation check · f3d87524
      Thomas Petazzoni authored
      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: default avatarThomas 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: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      f3d87524
  12. 28 Aug, 2012 6 commits
  13. 25 Aug, 2012 3 commits
    • Jonathan Austin's avatar
      ARM: 7499/1: mm: Fix vmalloc overlap check for !HIGHMEM · 36418c51
      Jonathan Austin authored
      
      
      With !HIGHMEM, sanity_check_meminfo checks for banks that completely or
      partially overlap the vmalloc region. The test for partial overlap checks
      __va(bank->start + bank->size) > vmalloc_min. This is not appropriate if
      there is a non-linear translation between virtual and physical addresses,
      as bank->start + bank->size is actually in the bank following the one being
      interrogated.
      
      In most cases, even when using SPARSEMEM, this is not problematic as the
      subsequent bank will start at a higher va than the one in question. However
      if the physical to virtual address conversion is not monotonic increasing,
      the incorrect test could result in a bank not being truncated when it
      should be.
      
      This patch ensures we perform the va-pa conversion on memory from the
      bank we are interested in, not the following one.
      Reported-by: default avatar??? (Steve) <zhanzhenbo@gmail.com>
      Signed-off-by: default avatarJonathan Austin <jonathan.austin@arm.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      36418c51
    • Will Deacon's avatar
      ARM: 7502/1: contextidr: avoid using bfi instruction during notifier · ae3790b8
      Will Deacon authored
      
      
      The bfi instruction is not available on ARMv6, so instead use an and/orr
      sequence in the contextidr_notifier. This gets rid of the assembler
      error:
      
        Assembler messages:
        Error: selected processor does not support ARM mode `bfi r3,r2,#0,#8'
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ae3790b8
    • Russell King's avatar
      ARM: Fix ioremap() of address zero · a849088a
      Russell King authored
      Murali Nalajala reports a regression that ioremapping address zero
      results in an oops dump:
      
      Unable to handle kernel paging request at virtual address fa200000
      pgd = d4f80000
      [fa200000] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0    Tainted: G        W (3.4.0-g3b5f728-00009-g638207a #13)
      PC is at msm_pm_config_rst_vector_before_pc+0x8/0x30
      LR is at msm_pm_boot_config_before_pc+0x18/0x20
      pc : [<c0078f84>]    lr : [<c007903c>]    psr: a0000093
      sp : c0837ef0  ip : cfe00000  fp : 0000000d
      r10: da7efc17  r9 : 225c4278  r8 : 00000006
      r7 : 0003c000  r6 : c085c824  r5 : 00000001  r4 : fa101000
      r3 : fa200000  r2 : c095080c  r1 : 002250fc  r0 : 00000000
      Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      Control: 10c5387d  Table: 25180059  DAC: 00000015
      [<c0078f84>] (msm_pm_config_rst_vector_before_pc+0x8/0x30) from [<c007903c>] (msm_pm_boot_config_before_pc+0x18/0x20)
      [<c007903c>] (msm_pm_boot_config_before_pc+0x18/0x20) from [<c007a55c>] (msm_pm_power_collapse+0x410/0xb04)
      [<c007a55c>] (msm_pm_power_collapse+0x410/0xb04) from [<c007b17c>] (arch_idle+0x294/0x3e0)
      [<c007b17c>] (arch_idle+0x294/0x3e0) from [<c000eed8>] (default_idle+0x18/0x2c)
      [<c000eed8>] (default_idle+0x18/0x2c) from [<c000f254>] (cpu_idle+0x90/0xe4)
      [<c000f254>] (cpu_idle+0x90/0xe4) from [<c057231c>] (rest_init+0x88/0xa0)
      [<c057231c>] (rest_init+0x88/0xa0) from [<c07ff890>] (start_kernel+0x3a8/0x40c)
      Code: c0704256 e12fff1e e59f2020 e5923000 (e5930000)
      
      This is caused by the 'reserved' entries which we insert (see
      19b52abe
      
       - ARM: 7438/1: fill possible PMD empty section gaps)
      which get matched for physical address zero.
      
      Resolve this by marking these reserved entries with a different flag.
      
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarMurali Nalajala <mnalajal@codeaurora.org>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a849088a
  14. 16 Aug, 2012 4 commits
  15. 12 Aug, 2012 1 commit
  16. 11 Aug, 2012 2 commits
  17. 08 Aug, 2012 1 commit
    • Aaro Koskinen's avatar
      ARM: dma-mapping: fix incorrect freeing of atomic allocations · d9e0d149
      Aaro Koskinen authored
      Commit e9da6e99
      
       (ARM: dma-mapping:
      remove custom consistent dma region) changed the way atomic allocations
      are handled. However, arm_dma_free() was not modified accordingly, and
      as a result freeing of atomic allocations does not work correctly when
      CMA is disabled. Memory is leaked and following WARNINGs are seen:
      
      [   57.698911] ------------[ cut here ]------------
      [   57.753518] WARNING: at arch/arm/mm/dma-mapping.c:263 arm_dma_free+0x88/0xe4()
      [   57.811473] trying to free invalid coherent area: e0848000
      [   57.867398] Modules linked in: sata_mv(-)
      [   57.921373] [<c000d270>] (unwind_backtrace+0x0/0xf0) from [<c0015430>] (warn_slowpath_common+0x50/0x68)
      [   58.033924] [<c0015430>] (warn_slowpath_common+0x50/0x68) from [<c00154dc>] (warn_slowpath_fmt+0x30/0x40)
      [   58.152024] [<c00154dc>] (warn_slowpath_fmt+0x30/0x40) from [<c000dc18>] (arm_dma_free+0x88/0xe4)
      [   58.219592] [<c000dc18>] (arm_dma_free+0x88/0xe4) from [<c008fa30>] (dma_pool_destroy+0x100/0x148)
      [   58.345526] [<c008fa30>] (dma_pool_destroy+0x100/0x148) from [<c019a64c>] (release_nodes+0x144/0x218)
      [   58.475782] [<c019a64c>] (release_nodes+0x144/0x218) from [<c0197e10>] (__device_release_driver+0x60/0xb8)
      [   58.614260] [<c0197e10>] (__device_release_driver+0x60/0xb8) from [<c0198608>] (driver_detach+0xd8/0xec)
      [   58.756527] [<c0198608>] (driver_detach+0xd8/0xec) from [<c0197c54>] (bus_remove_driver+0x7c/0xc4)
      [   58.901648] [<c0197c54>] (bus_remove_driver+0x7c/0xc4) from [<c004bfac>] (sys_delete_module+0x19c/0x220)
      [   59.051447] [<c004bfac>] (sys_delete_module+0x19c/0x220) from [<c0009140>] (ret_fast_syscall+0x0/0x2c)
      [   59.207996] ---[ end trace 0745420412c0325a ]---
      [   59.287110] ------------[ cut here ]------------
      [   59.366324] WARNING: at arch/arm/mm/dma-mapping.c:263 arm_dma_free+0x88/0xe4()
      [   59.450511] trying to free invalid coherent area: e0847000
      [   59.534357] Modules linked in: sata_mv(-)
      [   59.616785] [<c000d270>] (unwind_backtrace+0x0/0xf0) from [<c0015430>] (warn_slowpath_common+0x50/0x68)
      [   59.790030] [<c0015430>] (warn_slowpath_common+0x50/0x68) from [<c00154dc>] (warn_slowpath_fmt+0x30/0x40)
      [   59.972322] [<c00154dc>] (warn_slowpath_fmt+0x30/0x40) from [<c000dc18>] (arm_dma_free+0x88/0xe4)
      [   60.070701] [<c000dc18>] (arm_dma_free+0x88/0xe4) from [<c008fa30>] (dma_pool_destroy+0x100/0x148)
      [   60.256817] [<c008fa30>] (dma_pool_destroy+0x100/0x148) from [<c019a64c>] (release_nodes+0x144/0x218)
      [   60.445201] [<c019a64c>] (release_nodes+0x144/0x218) from [<c0197e10>] (__device_release_driver+0x60/0xb8)
      [   60.634148] [<c0197e10>] (__device_release_driver+0x60/0xb8) from [<c0198608>] (driver_detach+0xd8/0xec)
      [   60.823623] [<c0198608>] (driver_detach+0xd8/0xec) from [<c0197c54>] (bus_remove_driver+0x7c/0xc4)
      [   61.013268] [<c0197c54>] (bus_remove_driver+0x7c/0xc4) from [<c004bfac>] (sys_delete_module+0x19c/0x220)
      [   61.203472] [<c004bfac>] (sys_delete_module+0x19c/0x220) from [<c0009140>] (ret_fast_syscall+0x0/0x2c)
      [   61.393390] ---[ end trace 0745420412c0325b ]---
      
      The patch fixes this.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      d9e0d149