1. 17 Nov, 2014 1 commit
  2. 14 Nov, 2014 1 commit
    • Mark Rutland's avatar
      arm64: Fix up /proc/cpuinfo · 44b82b77
      Mark Rutland authored
      Commit d7a49086 (arm64: cpuinfo: print info for all CPUs)
      attempted to clean up /proc/cpuinfo, but due to concerns regarding
      further changes was reverted in commit 5e39977e
       (Revert "arm64:
      cpuinfo: print info for all CPUs").
      There are two major issues with the arm64 /proc/cpuinfo format
      * The "Features" line describes (only) the 64-bit hwcaps, which is
        problematic for some 32-bit applications which attempt to parse it. As
        the same names are used for analogous ISA features (e.g. aes) despite
        these generally being architecturally unrelated, it is not possible to
        simply append the 64-bit and 32-bit hwcaps in a manner that might not
        be misleading to some applications.
        Various potential solutions have appeared in vendor kernels. Typically
        the format of the Features line varies depending on whether the task
        is 32-bit.
      * Information is only printed regarding a single CPU. This does not
        match the ARM format, and does not provide sufficient information in
        big.LITTLE systems where CPUs are heterogeneous. The CPU information
        printed is queried from the current CPU's registers, which is racy
        w.r.t. cross-cpu migration.
      This patch attempts to solve these issues. The following changes are
      * When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
        the "Features" line contains the decoded 32-bit hwcaps, as with the
        arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
        with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
        the absense of compat support, the Features line is empty.
        The set of hwcaps injected into a task's auxval are unaffected.
      * Properties are printed per-cpu, as with the ARM port. The per-cpu
        information is queried from pre-recorded cpu information (as used by
        the sanity checks).
      * As with the previous attempt at fixing up /proc/cpuinfo, the hardware
        field is removed. The only users so far are 32-bit applications tied
        to particular boards, so no portable applications should be affected,
        and this should prevent future tying to particular boards.
      The following differences remain:
      * No model_name is printed, as this cannot be queried from the hardware
        and cannot be provided in a stable fashion. Use of the CPU
        {implementor,variant,part,revision} fields is sufficient to identify a
        CPU and is portable across arm and arm64.
      * The following system-wide properties are not provided, as they are not
        possible to provide generally. Programs relying on these are already
        tied to particular (32-bit only) boards:
        - Hardware
        - Revision
        - Serial
      No software has yet been identified for which these remaining
      differences are problematic.
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: Ian Campbell <ijc@hellion.org.uk>
      Cc: Serban Constantinescu <serban.constantinescu@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: cross-distro@lists.linaro.org
      Cc: linux-api@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  3. 06 Nov, 2014 2 commits
  4. 15 Sep, 2014 1 commit
    • Jon Masters's avatar
      setup: Move unmask of async interrupts after possible earlycon setup · 7a9c43be
      Jon Masters authored
      The kernel wants to enable reporting of asynchronous interrupts (i.e.
      System Errors) as early as possible. But if this happens too early then
      any pending System Error on initial entry into the kernel may never be
      reported where a user can see it. This situation will occur if the kernel
      is configured with CONFIG_PANIC_ON_OOPS set and (default or command line)
      enabled, in which case the kernel will panic as intended, however the
      associated logging messages indicating this failure condition will remain
      only in the kernel ring buffer and never be flushed out to the (not yet
      configured) console. Therefore, this patch moves the enabling of
      asynchronous interrupts during early setup to as early as reasonable,
      but after parsing any possible earlycon parameters setting up earlycon.
      Signed-off-by: default avatarJon Masters <jcm@redhat.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  5. 01 Sep, 2014 1 commit
  6. 31 Jul, 2014 1 commit
  7. 21 Jul, 2014 1 commit
  8. 18 Jul, 2014 2 commits
    • Mark Rutland's avatar
      arm64: cpuinfo: print info for all CPUs · d7a49086
      Mark Rutland authored
      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: default avatarMark 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: default avatarWill Deacon <will.deacon@arm.com>
      [catalin.marinas@arm.com: remove machine_name as it is no longer reported]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Mark Rutland's avatar
      arm64: cpuinfo: record cpu system register values · df857416
      Mark Rutland authored
      Several kernel subsystems need to know details about CPU system register
      values, sometimes for CPUs other than that they are executing on. Rather
      than hard-coding system register accesses and cross-calls for these
      cases, this patch adds logic to record various system register values at
      boot-time. This may be used for feature reporting, firmware bug
      detection, etc.
      Separate hooks are added for the boot and hotplug paths to enable
      one-time intialisation and cold/warm boot value mismatch detection in
      later patches.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  9. 09 May, 2014 2 commits
    • Catalin Marinas's avatar
      arm64: Clean up the default pgprot setting · a501e324
      Catalin Marinas authored
      The primary aim of this patchset is to remove the pgprot_default and
      prot_sect_default global variables and rely strictly on predefined
      values. The original goal was to be able to run SMP kernels on UP
      hardware by not setting the Shareability bit. However, it is unlikely to
      see UP ARMv8 hardware and even if we do, the Shareability bit is no
      longer assumed to disable cacheable accesses.
      A side effect is that the device mappings now have the Shareability
      attribute set. The hardware, however, should ignore it since Device
      accesses are always Outer Shareable.
      Following the removal of the two global variables, there is some PROT_*
      macro reshuffling and cleanup, including the __PAGE_* macros (replaced
      by PAGE_*).
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
    • Catalin Marinas's avatar
      arm64: Implement cache_line_size() based on CTR_EL0.CWG · a41dc0e8
      Catalin Marinas authored
      The hardware provides the maximum cache line size in the system via the
      CTR_EL0.CWG bits. This patch implements the cache_line_size() function
      to read such information, together with a sanity check if the statically
      defined L1_CACHE_BYTES is smaller than the hardware value.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
  10. 03 May, 2014 1 commit
  11. 30 Apr, 2014 1 commit
  12. 25 Apr, 2014 1 commit
  13. 07 Apr, 2014 2 commits
  14. 04 Mar, 2014 2 commits
  15. 19 Dec, 2013 3 commits
  16. 16 Dec, 2013 1 commit
    • Lorenzo Pieralisi's avatar
      arm64: kernel: build MPIDR_EL1 hash function data structure · 976d7d3f
      Lorenzo Pieralisi authored
      On ARM64 SMP systems, cores are identified by their MPIDR_EL1 register.
      The MPIDR_EL1 guidelines in the ARM ARM do not provide strict enforcement of
      MPIDR_EL1 layout, only recommendations that, if followed, split the MPIDR_EL1
      on ARM 64 bit platforms in four affinity levels. In multi-cluster
      systems like big.LITTLE, if the affinity guidelines are followed, the
      MPIDR_EL1 can not be considered a linear index. This means that the
      association between logical CPU in the kernel and the HW CPU identifier
      becomes somewhat more complicated requiring methods like hashing to
      associate a given MPIDR_EL1 to a CPU logical index, in order for the look-up
      to be carried out in an efficient and scalable way.
      This patch provides a function in the kernel that starting from the
      cpu_logical_map, implement collision-free hashing of MPIDR_EL1 values by
      checking all significative bits of MPIDR_EL1 affinity level bitfields.
      The hashing can then be carried out through bits shifting and ORing; the
      resulting hash algorithm is a collision-free though not minimal hash that can
      be executed with few assembly instructions. The mpidr_el1 is filtered through a
      mpidr mask that is built by checking all bits that toggle in the set of
      MPIDR_EL1s corresponding to possible CPUs. Bits that do not toggle do not
      carry information so they do not contribute to the resulting hash.
      Pseudo code:
      /* check all bits that toggle, so they are required */
      for (i = 1, mpidr_el1_mask = 0; i < num_possible_cpus(); i++)
      	mpidr_el1_mask |= (cpu_logical_map(i) ^ cpu_logical_map(0));
       * Build shifts to be applied to aff0, aff1, aff2, aff3 values to hash the
       * mpidr_el1
       * fls() returns the last bit set in a word, 0 if none
       * ffs() returns the first bit set in a word, 0 if none
      fs0 = mpidr_el1_mask[7:0] ? ffs(mpidr_el1_mask[7:0]) - 1 : 0;
      fs1 = mpidr_el1_mask[15:8] ? ffs(mpidr_el1_mask[15:8]) - 1 : 0;
      fs2 = mpidr_el1_mask[23:16] ? ffs(mpidr_el1_mask[23:16]) - 1 : 0;
      fs3 = mpidr_el1_mask[39:32] ? ffs(mpidr_el1_mask[39:32]) - 1 : 0;
      ls0 = fls(mpidr_el1_mask[7:0]);
      ls1 = fls(mpidr_el1_mask[15:8]);
      ls2 = fls(mpidr_el1_mask[23:16]);
      ls3 = fls(mpidr_el1_mask[39:32]);
      bits0 = ls0 - fs0;
      bits1 = ls1 - fs1;
      bits2 = ls2 - fs2;
      bits3 = ls3 - fs3;
      aff0_shift = fs0;
      aff1_shift = 8 + fs1 - bits0;
      aff2_shift = 16 + fs2 - (bits0 + bits1);
      aff3_shift = 32 + fs3 - (bits0 + bits1 + bits2);
      u32 hash(u64 mpidr_el1) {
      	u32 l[4];
      	u64 mpidr_el1_masked = mpidr_el1 & mpidr_el1_mask;
      	l[0] = mpidr_el1_masked & 0xff;
      	l[1] = mpidr_el1_masked & 0xff00;
      	l[2] = mpidr_el1_masked & 0xff0000;
      	l[3] = mpidr_el1_masked & 0xff00000000;
      	return (l[0] >> aff0_shift | l[1] >> aff1_shift | l[2] >> aff2_shift |
      		l[3] >> aff3_shift);
      The hashing algorithm relies on the inherent properties set in the ARM ARM
      recommendations for the MPIDR_EL1. Exotic configurations, where for instance
      the MPIDR_EL1 values at a given affinity level have large holes, can end up
      requiring big hash tables since the compression of values that can be achieved
      through shifting is somewhat crippled when holes are present. Kernel warns if
      the number of buckets of the resulting hash table exceeds the number of
      possible CPUs by a factor of 4, which is a symptom of a very sparse HW
      MPIDR_EL1 configuration.
      The hash algorithm is quite simple and can easily be implemented in assembly
      code, to be used in code paths where the kernel virtual address space is
      not set-up (ie cpu_resume) and instruction and data fetches are strongly
      ordered so code must be compact and must carry out few data accesses.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  17. 25 Nov, 2013 1 commit
  18. 30 Oct, 2013 1 commit
  19. 25 Oct, 2013 2 commits
  20. 09 Oct, 2013 3 commits
  21. 26 Sep, 2013 1 commit
  22. 20 Sep, 2013 1 commit
  23. 30 Aug, 2013 1 commit
  24. 28 Aug, 2013 1 commit
  25. 14 May, 2013 1 commit
  26. 20 Mar, 2013 2 commits
  27. 29 Jan, 2013 1 commit
  28. 22 Jan, 2013 1 commit
  29. 18 Oct, 2012 1 commit