1. 08 2月, 2018 1 次提交
  2. 04 11月, 2017 1 次提交
    • P
      Update MIPS email addresses · fb615d61
      Paul Burton 提交于
      MIPS will soon not be a part of Imagination Technologies, and as such
      many @imgtec.com email addresses will no longer be valid. This patch
      updates the addresses for those who:
      
       - Have 10 or more patches in mainline authored using an @imgtec.com
         email address, or any patches dated within the past year.
      
       - Are still with Imagination but leaving as part of the MIPS business
         unit, as determined from an internal email address list.
      
       - Haven't already updated their email address (ie. JamesH) or expressed
         a desire to be excluded (ie. Maciej).
      
       - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
         myself.
      
      New addresses are of the form firstname.lastname@mips.com, and all
      verified against an internal email address list.  An entry is added to
      .mailmap for each person such that get_maintainer.pl will report the new
      addresses rather than @imgtec.com addresses which will soon be dead.
      
      Instances of the affected addresses throughout the tree are then
      mechanically replaced with the new @mips.com address.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
      Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@mips.com>
      Acked-by: NMatt Redfearn <matt.redfearn@mips.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: trivial@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fb615d61
  3. 01 11月, 2017 1 次提交
    • P
      Update MIPS email addresses · 48c834be
      Paul Burton 提交于
      MIPS will soon not be a part of Imagination Technologies, and as such
      many @imgtec.com email addresses will no longer be valid. This patch
      updates the addresses for those who:
      
       - Have 10 or more patches in mainline authored using an @imgtec.com
         email address, or any patches dated within the past year.
      
       - Are still with Imagination but leaving as part of the MIPS business
         unit, as determined from an internal email address list.
      
       - Haven't already updated their email address (ie. JamesH) or expressed
         a desire to be excluded (ie. Maciej).
      
       - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
         myself.
      
      New addresses are of the form firstname.lastname@mips.com, and all
      verified against an internal email address list. An entry is added to
      .mailmap for each person such that get_maintainer.pl will report the new
      addresses rather than @imgtec.com addresses which will soon be dead.
      
      Instances of the affected addresses throughout the tree are then
      mechanically replaced with the new @mips.com address.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
      Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@mips.com>
      Acked-by: NMatt Redfearn <matt.redfearn@mips.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: trivial@kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/17540/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      48c834be
  4. 30 8月, 2017 3 次提交
    • P
      MIPS: CPS: Have asm/mips-cps.h include CM & CPC headers · e83f7e02
      Paul Burton 提交于
      With Coherence Manager (CM) 3.5 information about the topology of the
      system, which has previously only been available through & accessed from
      the CM, is now also provided by the Cluster Power Controller (CPC). This
      includes a new CPC_CONFIG register mirroring GCR_CONFIG, and similarly a
      new CPC_Cx_CONFIG register mirroring GCR_Cx_CONFIG.
      
      In preparation for adjusting functions such as mips_cm_numcores(), which
      have previously only needed to access the CM, to also access the CPC
      this patch modifies the way we use the various CPS headers. Rather than
      having users include asm/mips-cm.h or asm/mips-cpc.h individually we
      instead have users include asm/mips-cps.h which in turn includes
      asm/mips-cm.h & asm/mips-cpc.h. This means that users will gain access
      to both CM & CPC registers by including one header, and most importantly
      it makes asm/mips-cps.h an ideal location for helper functions which
      need to access the various components of the CPS.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17015/
      Patchwork: https://patchwork.linux-mips.org/patch/17217/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e83f7e02
    • P
      MIPS: Abstract CPU core & VP(E) ID access through accessor functions · f875a832
      Paul Burton 提交于
      We currently have fields in struct cpuinfo_mips for the core & VP(E) ID
      of a particular CPU, and various pieces of code directly access those
      fields. This patch abstracts such access by introducing accessor
      functions cpu_core(), cpu_set_core(), cpu_vpe_id() & cpu_set_vpe_id()
      and having code that needs to access these values call those functions
      rather than directly accessing the struct cpuinfo_mips fields. This
      prepares us for changes to the way in which those values are stored in
      later patches.
      
      The cpu_vpe_id() function is introduced even though we already had a
      cpu_vpe_id() macro for a couple of reasons:
      
        1) It's more consistent with the core, and future cluster, accessors.
      
        2) It ensures a sensible return type without explicit casts.
      
        3) It's generally preferable to use functions rather than macros.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17009/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f875a832
    • P
      MIPS: CPC: Use BIT/GENMASK for register fields, order & drop shifts · 829ca2be
      Paul Burton 提交于
      Tidy up asm/mips-cpc.h in a similar way to what "MIPS: CM: Use
      BIT/GENMASK for register fields, order & drop shifts" did for
      asm/mips-cm.h.
      
      We use BIT() & GENMASK() to simplify the definition of register fields,
      drop the _SHF definitions since that information can be found in the
      _MSK ones, and then drop the _MSK suffix.
      
      Fields definitions are moved to be next to the appropriate register
      definition, making it easier to link the two & keep everything ordered
      by register address. Comments are added including the name of each
      register & a brief description of its purpose which helps to understand
      what registers are for, link them back to hardware documentation or grep
      for them.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17003/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      829ca2be
  5. 29 8月, 2017 1 次提交
    • P
      MIPS: CM: Use BIT/GENMASK for register fields, order & drop shifts · 93c5bba5
      Paul Burton 提交于
      There's no reason for us not to use BIT() & GENMASK() in asm/mips-cm.h
      when declaring macros corresponding to register fields. This patch
      modifies our definitions to do so.
      
      The *_SHF definitions are removed entirely - they duplicate information
      found in the masks, are infrequently used & can be replaced with use of
      __ffs() where needed.
      
      The *_MSK definitions then lose their _MSK suffix which is now somewhat
      redundant, and users are modified to match.
      
      The field definitions are moved to follow the appropriate register's
      accessor functions, which helps to keep the field definitions in order &
      to find the appropriate fields for a given register. Whilst here a
      comment is added describing each register & including its name, which is
      helpful both for linking the register back to hardware documentation &
      for grepping purposes.
      
      This also cleans up a couple of issues that became obvious as a result
      of making the changes described above:
      
        - We previously had definitions for GCR_Cx_RESET_EXT_BASE & a phony
          copy of that named GCR_RESET_EXT_BASE - a register which does not
          exist. The bad definitions were added by commit 497e803e ("MIPS:
          smp-cps: Ensure secondary cores start with EVA disabled") and made
          use of from boot_core(), which is now modified to use the
          GCR_Cx_RESET_EXT_BASE definitions.
      
        - We had a typo in CM_GCR_ERROR_CAUSE_ERRINGO_MSK - we now correctly
          define this as inFo rather than inGo.
      
      Now that we don't duplicate field information between _SHF & _MSK
      definitions, and keep the fields next to the register accessors, it will
      be much easier to spot & prevent any similar oddities being introduced
      in the future.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Acked-by: Thomas Gleixner <tglx@linutronix.de
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17001/
      Patchwork: https://patchwork.linux-mips.org/patch/17216/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      93c5bba5
  6. 04 11月, 2016 1 次提交
  7. 04 10月, 2016 2 次提交
  8. 11 11月, 2015 1 次提交
  9. 26 8月, 2015 2 次提交
  10. 25 11月, 2014 1 次提交
  11. 28 5月, 2014 1 次提交
    • P
      MIPS: smp-cps: rework core/VPE initialisation · 245a7868
      Paul Burton 提交于
      When hotplug and/or a powered down idle state are supported cases will
      arise where a non-zero VPE must be brought online without VPE 0, and it
      where multiple VPEs must be onlined simultaneously. This patch prepares
      for that by:
      
        - Splitting struct boot_config into core & VPE boot config structures,
          allocated one per core or VPE respectively. This allows for multiple
          VPEs to be onlined simultaneously without clobbering each others
          configuration.
      
        - Indicating which VPEs should be online within a core at any given
          time using a bitmap. This allows multiple VPEs to be brought online
          simultaneously and also indicates to VPE 0 whether it should halt
          after starting any non-zero VPEs that should be online within the
          core. For example if all VPEs within a core are offlined via hotplug
          and the user onlines the second VPE within that core:
      
            1) The core will be powered up.
      
            2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to
               initialise the core.
      
            3) VPE 0 will start VPE 1 because its bit is set in the cores
               bitmap.
      
            4) VPE 0 will halt itself because its bit is clear in the cores
               bitmap.
      
        - Moving the core & VPE initialisation to assembly code which does not
          make any use of the stack. This is because if a non-zero VPE is to
          be brought online in a powered down core then when VPE 0 of that
          core runs it may not have a valid stack, and even if it did then
          it's messy to run through parts of generic kernel code on VPE 0
          before starting the correct VPE.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      245a7868
  12. 02 5月, 2014 1 次提交
    • P
      MIPS: CPC: provide locking functions · 76ae6584
      Paul Burton 提交于
      This patch provides functions to lock & unlock access to the
      "core-other" register region of the CPC. Without performing appropriate
      locking it is possible for code using this region to be preempted or to
      race with code on another VPE within the same core, with one changing
      the core which the "core-other" region is acting upon at an inopportune
      time for the other.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      76ae6584
  13. 07 3月, 2014 1 次提交