1. 21 Jan, 2014 1 commit
    • Santosh Shilimkar's avatar
      arch/arm/kernel/: use memblock apis for early memory allocations · 9233d2be
      Santosh Shilimkar authored
      
      
      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: default avatarSantosh 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9233d2be
  2. 13 Jan, 2014 1 commit
    • Dario Faggioli's avatar
      sched: Add new scheduler syscalls to support an extended scheduling parameters ABI · d50dde5a
      Dario Faggioli authored
      
      
      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: default avatarDario Faggioli <raistlin@linux.it>
      [ Rewrote to use sched_attr. ]
      Signed-off-by: default avatarJuri Lelli <juri.lelli@gmail.com>
      [ Removed sched_setscheduler2() for now. ]
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1383831828-15501-3-git-send-email-juri.lelli@gmail.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d50dde5a
  3. 11 Jan, 2014 3 commits
  4. 05 Jan, 2014 1 commit
  5. 17 Dec, 2013 1 commit
  6. 13 Dec, 2013 1 commit
    • Russell King's avatar
      ARM: fix asm/memory.h build error · b713aa0b
      Russell King authored
      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: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b713aa0b
  7. 09 Dec, 2013 4 commits
  8. 30 Nov, 2013 2 commits
  9. 18 Nov, 2013 1 commit
  10. 14 Nov, 2013 2 commits
  11. 12 Nov, 2013 1 commit
  12. 08 Nov, 2013 1 commit
    • Stephen Boyd's avatar
      ARM: 7887/1: Don't smp_cross_call() on UP devices in arch_irq_work_raise() · c682e51d
      Stephen Boyd authored
      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: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c682e51d
  13. 06 Nov, 2013 3 commits
  14. 29 Oct, 2013 5 commits
  15. 19 Oct, 2013 9 commits
  16. 10 Oct, 2013 3 commits
    • Santosh Shilimkar's avatar
      ARM: mm: Recreate kernel mappings in early_paging_init() · a77e0c7b
      Santosh Shilimkar authored
      
      
      This patch adds a step in the init sequence, in order to recreate
      the kernel code/data page table mappings prior to full paging
      initialization.  This is necessary on LPAE systems that run out of
      a physical address space outside the 4G limit.  On these systems,
      this implementation provides a machine descriptor hook that allows
      the PHYS_OFFSET to be overridden in a machine specific fashion.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarR Sricharan <r.sricharan@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      a77e0c7b
    • Sricharan R's avatar
      ARM: mm: Correct virt_to_phys patching for 64 bit physical addresses · f52bb722
      Sricharan R authored
      
      
      The current phys_to_virt patching mechanism works only for 32 bit
      physical addresses and this patch extends the idea for 64bit physical
      addresses.
      
      The 64bit v2p patching mechanism patches the higher 8 bits of physical
      address with a constant using 'mov' instruction and lower 32bits are patched
      using 'add'. While this is correct, in those platforms where the lowmem addressable
      physical memory spawns across 4GB boundary, a carry bit can be produced as a
      result of addition of lower 32bits. This has to be taken in to account and added
      in to the upper. The patched __pv_offset and va are added in lower 32bits, where
      __pv_offset can be in two's complement form when PA_START < VA_START and that can
      result in a false carry bit.
      
      e.g
          1) PA = 0x80000000; VA = 0xC0000000
             __pv_offset = PA - VA = 0xC0000000 (2's complement)
      
          2) PA = 0x2 80000000; VA = 0xC000000
             __pv_offset = PA - VA = 0x1 C0000000
      
      So adding __pv_offset + VA should never result in a true overflow for (1).
      So in order to differentiate between a true carry, a __pv_offset is extended
      to 64bit and the upper 32bits will have 0xffffffff if __pv_offset is
      2's complement. So 'mvn #0' is inserted instead of 'mov' while patching
      for the same reason. Since mov, add, sub instruction are to patched
      with different constants inside the same stub, the rotation field
      of the opcode is using to differentiate between them.
      
      So the above examples for v2p translation becomes for VA=0xC0000000,
          1) PA[63:32] = 0xffffffff
             PA[31:0] = VA + 0xC0000000 --> results in a carry
             PA[63:32] = PA[63:32] + carry
      
             PA[63:0] = 0x0 80000000
      
          2) PA[63:32] = 0x1
             PA[31:0] = VA + 0xC0000000 --> results in a carry
             PA[63:32] = PA[63:32] + carry
      
             PA[63:0] = 0x2 80000000
      
      The above ideas were suggested by Nicolas Pitre <nico@linaro.org> as
      part of the review of first and second versions of the subject patch.
      
      There is no corresponding change on the phys_to_virt() side, because
      computations on the upper 32-bits would be discarded anyway.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarSricharan R <r.sricharan@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      f52bb722
    • Santosh Shilimkar's avatar
      ARM: mm: Introduce virt_to_idmap() with an arch hook · 4dc9a817
      Santosh Shilimkar authored
      
      
      On some PAE systems (e.g. TI Keystone), memory is above the
      32-bit addressable limit, and the interconnect provides an
      aliased view of parts of physical memory in the 32-bit addressable
      space.  This alias is strictly for boot time usage, and is not
      otherwise usable because of coherency limitations. On such systems,
      the idmap mechanism needs to take this aliased mapping into account.
      
      This patch introduces virt_to_idmap() and a arch function pointer which
      can be populated by platform which needs it. Also populate necessary
      idmap spots with now available virt_to_idmap(). Avoided #ifdef approach
      to be compatible with multi-platform builds.
      
      Most architecture won't touch it and in that case virt_to_idmap()
      fall-back to existing virt_to_phys() macro.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      4dc9a817
  17. 09 Oct, 2013 1 commit