1. 12 9月, 2014 2 次提交
    • L
      arm64: kernel: introduce cpu_init_idle CPU operation · d64f84f6
      Lorenzo Pieralisi 提交于
      The CPUidle subsystem on ARM64 machines requires the idle states
      implementation back-end to initialize idle states parameter upon
      boot. This patch adds a hook in the CPU operations structure that
      should be initialized by the CPU operations back-end in order to
      provide a function that initializes cpu idle states.
      
      This patch also adds the infrastructure to arm64 kernel required
      to export the CPU operations based initialization interface, so
      that drivers (ie CPUidle) can use it when they are initialized
      at probe time.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      d64f84f6
    • L
      arm64: kernel: refactor the CPU suspend API for retention states · 714f5992
      Lorenzo Pieralisi 提交于
      CPU suspend is the standard kernel interface to be used to enter
      low-power states on ARM64 systems. Current cpu_suspend implementation
      by default assumes that all low power states are losing the CPU context,
      so the CPU registers must be saved and cleaned to DRAM upon state
      entry. Furthermore, the current cpu_suspend() implementation assumes
      that if the CPU suspend back-end method returns when called, this has
      to be considered an error regardless of the return code (which can be
      successful) since the CPU was not expected to return from a code path that
      is different from cpu_resume code path - eg returning from the reset vector.
      
      All in all this means that the current API does not cope well with low-power
      states that preserve the CPU context when entered (ie retention states),
      since first of all the context is saved for nothing on state entry for
      those states and a successful state entry can return as a normal function
      return, which is considered an error by the current CPU suspend
      implementation.
      
      This patch refactors the cpu_suspend() API so that it can be split in
      two separate functionalities. The arm64 cpu_suspend API just provides
      a wrapper around CPU suspend operation hook. A new function is
      introduced (for architecture code use only) for states that require
      context saving upon entry:
      
      __cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
      
      __cpu_suspend() saves the context on function entry and calls the
      so called suspend finisher (ie fn) to complete the suspend operation.
      The finisher is not expected to return, unless it fails in which case
      the error is propagated back to the __cpu_suspend caller.
      
      The API refactoring results in the following pseudo code call sequence for a
      suspending CPU, when triggered from a kernel subsystem:
      
      /*
       * int cpu_suspend(unsigned long idx)
       * @idx: idle state index
       */
      {
      -> cpu_suspend(idx)
      	|---> CPU operations suspend hook called, if present
      		|--> if (retention_state)
      			|--> direct suspend back-end call (eg PSCI suspend)
      		     else
      			|--> __cpu_suspend(idx, &back_end_finisher);
      }
      
      By refactoring the cpu_suspend API this way, the CPU operations back-end
      has a chance to detect whether idle states require state saving or not
      and can call the required suspend operations accordingly either through
      simple function call or indirectly through __cpu_suspend() which carries out
      state saving and suspend finisher dispatching to complete idle state entry.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      714f5992
  2. 01 9月, 2014 2 次提交
  3. 29 8月, 2014 3 次提交
  4. 27 8月, 2014 1 次提交
  5. 22 8月, 2014 1 次提交
  6. 20 8月, 2014 3 次提交
  7. 19 8月, 2014 1 次提交
  8. 09 8月, 2014 1 次提交
    • A
      arm64,ia64,ppc,s390,sh,tile,um,x86,mm: remove default gate area · a6c19dfe
      Andy Lutomirski 提交于
      The core mm code will provide a default gate area based on
      FIXADDR_USER_START and FIXADDR_USER_END if
      !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
      
      This default is only useful for ia64.  arm64, ppc, s390, sh, tile, 64-bit
      UML, and x86_32 have their own code just to disable it.  arm, 32-bit UML,
      and x86_64 have gate areas, but they have their own implementations.
      
      This gets rid of the default and moves the code into ia64.
      
      This should save some code on architectures without a gate area: it's now
      possible to inline the gate_area functions in the default case.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Acked-by: NNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [in principle]
      Acked-by: Richard Weinberger <richard@nod.at> [for um]
      Acked-by: Will Deacon <will.deacon@arm.com> [for arm64]
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Nathan Lynch <Nathan_Lynch@mentor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6c19dfe
  9. 08 8月, 2014 1 次提交
  10. 06 8月, 2014 2 次提交
  11. 01 8月, 2014 1 次提交
    • M
      arm64: add newline to I-cache policy string · ea171967
      Mark Rutland 提交于
      Due to a missing newline in the I-cache policy detection log output,
      it's possible to get some ratehr unfortunate output at boot time:
      
      CPU1: Booted secondary processor
      Detected VIPT I-cache on CPU1CPU2: Booted secondary processor
      Detected VIPT I-cache on CPU2CPU3: Booted secondary processor
      Detected VIPT I-cache on CPU3CPU4: Booted secondary processor
      Detected PIPT I-cache on CPU4CPU5: Booted secondary processor
      Detected PIPT I-cache on CPU5Brought up 6 CPUs
      SMP: Total of 6 processors activated.
      
      This patch adds the missing newline to the format string, cleaning up
      the output.
      
      Fixes: 59ccc0d4 ("arm64: cachetype: report weakest cache policy")
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      ea171967
  12. 31 7月, 2014 3 次提交
  13. 30 7月, 2014 1 次提交
    • A
      arm64: vdso: fix build error when switching from LE to BE · 1915e2ad
      Arun Chandran 提交于
      Building a kernel with CPU_BIG_ENDIAN fails if there are stale objects
      from a !CPU_BIG_ENDIAN build. Due to a missing FORCE prerequisite on an
      if_changed rule in the VDSO Makefile, we attempt to link a stale LE
      object into the new BE kernel.
      
      According to Documentation/kbuild/makefiles.txt, FORCE is required for
      if_changed rules and forgetting it is a common mistake, so fix it by
      'Forcing' the build of vdso. This patch fixes build errors like these:
      
      arch/arm64/kernel/vdso/note.o: compiled for a little endian system and target is big endian
      failed to merge target specific data of file arch/arm64/kernel/vdso/note.o
      
      arch/arm64/kernel/vdso/sigreturn.o: compiled for a little endian system and target is big endian
      failed to merge target specific data of file arch/arm64/kernel/vdso/sigreturn.o
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NArun Chandran <achandran@mvista.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      1915e2ad
  14. 25 7月, 2014 1 次提交
  15. 24 7月, 2014 3 次提交
  16. 23 7月, 2014 5 次提交
  17. 21 7月, 2014 1 次提交
  18. 19 7月, 2014 4 次提交
    • A
      efi/arm64: Handle missing virtual mapping for UEFI System Table · 99a5603e
      Ard Biesheuvel 提交于
      If we cannot resolve the virtual address of the UEFI System Table, its
      physical offset must be missing from the virtual memory map, and there
      is really no point in proceeding with installing the virtual memory map
      and the runtime services dispatch table. So back out gracefully.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NMark Salter <msalter@redhat.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      99a5603e
    • A
      efi: efistub: Convert into static library · f4f75ad5
      Ard Biesheuvel 提交于
      This patch changes both x86 and arm64 efistub implementations
      from #including shared .c files under drivers/firmware/efi to
      building shared code as a static library.
      
      The x86 code uses a stub built into the boot executable which
      uncompresses the kernel at boot time. In this case, the library is
      linked into the decompressor.
      
      In the arm64 case, the stub is part of the kernel proper so the library
      is linked into the kernel proper as well.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f4f75ad5
    • S
      arm64, ftrace: Remove check of obsolete variable function_trace_stop · ac694fda
      Steven Rostedt (Red Hat) 提交于
      Nothing sets function_trace_stop to disable function tracing anymore.
      Remove the check for it in the arch code.
      
      arm64 was broken anyway, as it had an ifdef testing
       CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST which is only set if
      the arch supports the code (which it obviously did not), and
      it was testing a non existent ftrace_trace_stop instead of
      function_trace_stop.
      
      Link: http://lkml.kernel.org/r/20140627124421.GP26276@arm.com
      
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      ac694fda
    • M
      arm64: cpuinfo: print info for all CPUs · d7a49086
      Mark Rutland 提交于
      Currently reading /proc/cpuinfo will result in information being read
      out of the MIDR_EL1 of the current CPU, and the information is not
      associated with any particular logical CPU number.
      
      This is problematic for systems with heterogeneous CPUs (i.e.
      big.LITTLE) where MIDR fields will vary across CPUs, and the output will
      differ depending on the executing CPU.
      
      This patch reorganises the code responsible for /proc/cpuinfo to print
      information per-cpu. In the process, we perform several cleanups:
      
      * Property names are coerced to lower-case (to match "processor" as per
        glibc's expectations).
      * Property names are simplified and made to match the MIDR field names.
      * Revision is changed to hex as with every other field.
      * The meaningless Architecture property is removed.
      * The ripe-for-abuse Machine field is removed.
      
      The features field (a human-readable representation of the hwcaps)
      remains printed once, as this is expected to remain in use as the
      globally support CPU features. To enable the possibility of the addition
      of per-cpu HW feature information later, this is printed before any
      CPU-specific information.
      
      Comments are added to guide userspace developers in the right direction
      (using the hwcaps provided in auxval). Hopefully where userspace
      applications parse /proc/cpuinfo rather than using the readily available
      hwcaps, they limit themselves to reading said first line.
      
      If CPU features differ from each other, the previously installed sanity
      checks will give us some advance notice with warnings and
      TAINT_CPU_OUT_OF_SPEC. If we are lucky, we will never see such systems.
      Rework will be required in many places to support such systems anyway.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marcus Shawcroft <marcus.shawcroft@arm.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      [catalin.marinas@arm.com: remove machine_name as it is no longer reported]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      d7a49086
  19. 18 7月, 2014 4 次提交