1. 19 3月, 2014 3 次提交
  2. 10 2月, 2014 1 次提交
    • S
      ARM: 7952/1: mm: Fix the memblock allocation for LPAE machines · ca474408
      Santosh Shilimkar 提交于
      Commit ad6492b8 added much needed memblock_virt_alloc_low() and further
      commit 07bacb38 {memblock, bootmem: restore goal for alloc_low} fixed
      the issue with low memory limit thanks to Yinghai. But even after all
      these fixes, there is still one case where the limit check done with
      ARCH_LOW_ADDRESS_LIMIT for low memory fails. Russell pointed out the
      issue with 32 bit LPAE machines in below thread.
      	https://lkml.org/lkml/2014/1/28/364
      
      Since on some LPAE machines where memory start address is beyond 4GB,
      the low memory marker in memblock will be set to default
      ARCH_LOW_ADDRESS_LIMIT which is wrong. We can fix this by letting
      architectures set the ARCH_LOW_ADDRESS_LIMIT using another export
      similar to memblock_set_current_limit() but am not sure whether
      its worth the trouble. Tell me if you think otherwise.
      
      Rather am just trying to fix that one broken case using
      memblock_virt_alloc() in setup code since the memblock.current_limit
      is updated appropriately makes it work on all ARM 32 bit machines.
      
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Strashko, Grygorii <grygorii.strashko@ti.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ca474408
  3. 28 1月, 2014 4 次提交
  4. 22 1月, 2014 3 次提交
    • S
      arch/arm/kernel/: use memblock apis for early memory allocations · 9233d2be
      Santosh Shilimkar 提交于
      Switch to memblock interfaces for early memory allocator instead of
      bootmem allocator.  No functional change in beahvior than what it is in
      current code from bootmem users points of view.
      
      Archs already converted to NO_BOOTMEM now directly use memblock
      interfaces instead of bootmem wrappers build on top of memblock.  And
      the archs which still uses bootmem, these new apis just fallback to
      exiting bootmem APIs.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9233d2be
    • R
      ARM: SMP implementations are not supposed to return from smp_ops.cpu_die() · 668bc386
      Russell King 提交于
      Although we allow recovery in this case, this is not supposed to be
      the normal path for hotplugging a CPU back in.  This path only exists
      to serve those rare platforms where it's not possible to power down
      the CPU or reset the CPU.  This patch causes the kernel to print a
      message when a platform uses this path.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      668bc386
    • R
      ARM: ignore memory below PHYS_OFFSET · 571b1437
      Russell King 提交于
      If the kernel is loaded higher in physical memory than normal, and we
      calculate PHYS_OFFSET higher than the start of RAM, this leads to
      boot problems as we attempt to map part of this RAM into userspace.
      Rather than struggle with this, just truncate the mapping.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      571b1437
  5. 13 1月, 2014 1 次提交
    • D
      sched: Add new scheduler syscalls to support an extended scheduling parameters ABI · d50dde5a
      Dario Faggioli 提交于
      Add the syscalls needed for supporting scheduling algorithms
      with extended scheduling parameters (e.g., SCHED_DEADLINE).
      
      In general, it makes possible to specify a periodic/sporadic task,
      that executes for a given amount of runtime at each instance, and is
      scheduled according to the urgency of their own timing constraints,
      i.e.:
      
       - a (maximum/typical) instance execution time,
       - a minimum interval between consecutive instances,
       - a time constraint by which each instance must be completed.
      
      Thus, both the data structure that holds the scheduling parameters of
      the tasks and the system calls dealing with it must be extended.
      Unfortunately, modifying the existing struct sched_param would break
      the ABI and result in potentially serious compatibility issues with
      legacy binaries.
      
      For these reasons, this patch:
      
       - defines the new struct sched_attr, containing all the fields
         that are necessary for specifying a task in the computational
         model described above;
      
       - defines and implements the new scheduling related syscalls that
         manipulate it, i.e., sched_setattr() and sched_getattr().
      
      Syscalls are introduced for x86 (32 and 64 bits) and ARM only, as a
      proof of concept and for developing and testing purposes. Making them
      available on other architectures is straightforward.
      
      Since no "user" for these new parameters is introduced in this patch,
      the implementation of the new system calls is just identical to their
      already existing counterpart. Future patches that implement scheduling
      policies able to exploit the new data structure must also take care of
      modifying the sched_*attr() calls accordingly with their own purposes.
      Signed-off-by: NDario Faggioli <raistlin@linux.it>
      [ Rewrote to use sched_attr. ]
      Signed-off-by: NJuri Lelli <juri.lelli@gmail.com>
      [ Removed sched_setscheduler2() for now. ]
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1383831828-15501-3-git-send-email-juri.lelli@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d50dde5a
  6. 11 1月, 2014 3 次提交
  7. 05 1月, 2014 1 次提交
  8. 29 12月, 2013 7 次提交
  9. 17 12月, 2013 1 次提交
  10. 14 12月, 2013 1 次提交
    • R
      ARM: fix asm/memory.h build error · b713aa0b
      Russell King 提交于
      Jason Gunthorpe reports a build failure when ARM_PATCH_PHYS_VIRT is
      not defined:
      
      In file included from arch/arm/include/asm/page.h:163:0,
                       from include/linux/mm_types.h:16,
                       from include/linux/sched.h:24,
                       from arch/arm/kernel/asm-offsets.c:13:
      arch/arm/include/asm/memory.h: In function '__virt_to_phys':
      arch/arm/include/asm/memory.h:244:40: error: 'PHYS_OFFSET' undeclared (first use in this function)
      arch/arm/include/asm/memory.h:244:40: note: each undeclared identifier is reported only once for each function it appears in
      arch/arm/include/asm/memory.h: In function '__phys_to_virt':
      arch/arm/include/asm/memory.h:249:13: error: 'PHYS_OFFSET' undeclared (first use in this function)
      
      Fixes: ca5a45c0 ("ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions")
      Tested-By: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b713aa0b
  11. 11 12月, 2013 1 次提交
  12. 10 12月, 2013 4 次提交
  13. 01 12月, 2013 2 次提交
  14. 24 11月, 2013 1 次提交
    • S
      ARM: mm: Remove bootmem code and switch to NO_BOOTMEM · 84f452b1
      Santosh Shilimkar 提交于
      Now with dma_mask series merged and max*pfn has consistent meaning on ARM
      as rest of the arch's thanks to RMK's mega series, lets switch ARM code
      to NO_BOOTMEM. With NO_BOOTMEM change, now we use memblock allocator to
      reserve space for crash kernel to have one less dependency with nobootmem
      allocator wrapper.
      
      Tested with both flat memory and sparse (faked) memory models with highmem
      enabled.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      84f452b1
  15. 19 11月, 2013 1 次提交
  16. 14 11月, 2013 2 次提交
  17. 13 11月, 2013 1 次提交
  18. 09 11月, 2013 1 次提交
    • S
      ARM: 7887/1: Don't smp_cross_call() on UP devices in arch_irq_work_raise() · c682e51d
      Stephen Boyd 提交于
      If we're running a kernel compiled with SMP_ON_UP=y and the
      hardware only supports UP operation there isn't any
      smp_cross_call function assigned. Unfortunately, we call
      smp_cross_call() unconditionally in arch_irq_work_raise() and
      crash the kernel on UP devices. Check to make sure we're running
      on an SMP device before calling smp_cross_call() here.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 80000005 [#1] SMP ARM
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-rc6-00018-g8d451442-dirty #16
      task: de05b440 ti: de05c000 task.ti: de05c000
      PC is at 0x0
      LR is at arch_irq_work_raise+0x3c/0x48
      pc : [<00000000>]    lr : [<c0019590>]    psr: 60000193
      sp : de05dd60  ip : 00000001  fp : 00000000
      r10: c085e2f0  r9 : de05c000  r8 : c07be0a4
      r7 : de05c000  r6 : de05c000  r5 : c07c5778  r4 : c0824554
      r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : c0529a58
      Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      Control: 10c5387d  Table: 80004019  DAC: 00000017
      Process swapper/0 (pid: 1, stack limit = 0xde05c248)
      Stack: (0xde05dd60 to 0xde05e000)
      dd60: c07b9dbc c00cb2dc 00000001 c08242c0 c08242c0 60000113 c07be0a8 c00b0590
      dd80: de05c000 c085e2f0 c08242c0 c08242c0 c1414c28 c00b07cc de05b440 c1414c28
      dda0: c08242c0 c00b0af8 c0862bb0 c0862db0 c1414cd8 de05c028 c0824840 de05ddb8
      ddc0: 00000000 00000009 00000001 00000024 c07be0a8 c07be0a4 de05c000 c085e2f0
      dde0: 00000000 c004a4b0 00000010 de00d2dc 00000054 00000100 00000024 00000000
      de00: de05c028 0000000a ffff8ae7 00200040 00000016 de05c000 60000193 de05c000
      de20: 00000054 00000000 00000000 00000000 00000000 c004a704 00000000 de05c008
      de40: c07ba254 c004aa1c c07c5778 c0014b70 fa200000 00000054 de05de80 c0861244
      de60: 00000000 c0008634 de05b440 c051c778 20000113 ffffffff de05deb4 c051d0a4
      de80: 00000001 00000001 00000000 de05b440 c082afac de057ac0 de057ac0 de0443c0
      dea0: 00000000 00000000 00000000 00000000 c082afbc de05dec8 c009f2a0 c051c778
      dec0: 20000113 ffffffff 00000000 c016edb0 00000000 000002b0 de057ac0 de057ac0
      dee0: 00000000 c016ee40 c0875e50 de05df2e de057ac0 00000000 00000013 00000000
      df00: 00000000 c016f054 de043600 de0443c0 c008eb38 de004ec0 c0875e50 c008eb44
      df20: 00000012 00000000 00000000 3931f0f8 00000000 00000000 00000014 c0822e84
      df40: 00000000 c008ed2c 00000000 00000000 00000000 c07b7490 c07b7490 c075ab3c
      df60: 00000000 c00701ac 00000002 00000000 c0070160 dffadb73 7bf8edb4 00000000
      df80: c051092c 00000000 00000000 00000000 00000000 00000000 00000000 c0510934
      dfa0: de05aa40 00000000 c051092c c0013ce8 00000000 00000000 00000000 00000000
      dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 07efffe5 4dfac6f5
      [<c0019590>] (arch_irq_work_raise+0x3c/0x48) from [<c00cb2dc>] (irq_work_queue+0xe4/0xf8)
      [<c00cb2dc>] (irq_work_queue+0xe4/0xf8) from [<c00b0590>] (rcu_accelerate_cbs+0x1d4/0x1d8)
      [<c00b0590>] (rcu_accelerate_cbs+0x1d4/0x1d8) from [<c00b07cc>] (rcu_start_gp+0x34/0x48)
      [<c00b07cc>] (rcu_start_gp+0x34/0x48) from [<c00b0af8>] (rcu_process_callbacks+0x318/0x608)
      [<c00b0af8>] (rcu_process_callbacks+0x318/0x608) from [<c004a4b0>] (__do_softirq+0x114/0x2a0)
      [<c004a4b0>] (__do_softirq+0x114/0x2a0) from [<c004a704>] (do_softirq+0x6c/0x74)
      [<c004a704>] (do_softirq+0x6c/0x74) from [<c004aa1c>] (irq_exit+0xac/0x100)
      [<c004aa1c>] (irq_exit+0xac/0x100) from [<c0014b70>] (handle_IRQ+0x54/0xb4)
      [<c0014b70>] (handle_IRQ+0x54/0xb4) from [<c0008634>] (omap3_intc_handle_irq+0x60/0x74)
      [<c0008634>] (omap3_intc_handle_irq+0x60/0x74) from [<c051d0a4>] (__irq_svc+0x44/0x5c)
      Exception stack(0xde05de80 to 0xde05dec8)
      de80: 00000001 00000001 00000000 de05b440 c082afac de057ac0 de057ac0 de0443c0
      dea0: 00000000 00000000 00000000 00000000 c082afbc de05dec8 c009f2a0 c051c778
      dec0: 20000113 ffffffff
      [<c051d0a4>] (__irq_svc+0x44/0x5c) from [<c051c778>] (_raw_spin_unlock_irq+0x28/0x2c)
      [<c051c778>] (_raw_spin_unlock_irq+0x28/0x2c) from [<c016edb0>] (proc_alloc_inum+0x30/0xa8)
      [<c016edb0>] (proc_alloc_inum+0x30/0xa8) from [<c016ee40>] (proc_register+0x18/0x130)
      [<c016ee40>] (proc_register+0x18/0x130) from [<c016f054>] (proc_mkdir_data+0x44/0x6c)
      [<c016f054>] (proc_mkdir_data+0x44/0x6c) from [<c008eb44>] (register_irq_proc+0x6c/0x128)
      [<c008eb44>] (register_irq_proc+0x6c/0x128) from [<c008ed2c>] (init_irq_proc+0x74/0xb0)
      [<c008ed2c>] (init_irq_proc+0x74/0xb0) from [<c075ab3c>] (kernel_init_freeable+0x84/0x1c8)
      [<c075ab3c>] (kernel_init_freeable+0x84/0x1c8) from [<c0510934>] (kernel_init+0x8/0x150)
      [<c0510934>] (kernel_init+0x8/0x150) from [<c0013ce8>] (ret_from_fork+0x14/0x2c)
      Code: bad PC value
      
      Fixes: bf18525f "ARM: 7872/1: Support arch_irq_work_raise() via self IPIs"
      Reported-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Tested-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c682e51d
  19. 07 11月, 2013 2 次提交