1. 15 7月, 2013 1 次提交
    • P
      arm: delete __cpuinit/__CPUINIT usage from all ARM users · 8bd26e3a
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the ARM uses of the __cpuinit macros from C code,
      and all __CPUINIT from assembly code.  It also had two ".previous"
      section statements that were paired off against __CPUINIT
      (aka .section ".cpuinit.text") that also get removed here.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8bd26e3a
  2. 08 4月, 2013 1 次提交
  3. 25 9月, 2012 1 次提交
    • L
      ARM: mm: implement LoUIS API for cache maintenance ops · 031bd879
      Lorenzo Pieralisi 提交于
      ARM v7 architecture introduced the concept of cache levels and related
      control registers. New processors like A7 and A15 embed an L2 unified cache
      controller that becomes part of the cache level hierarchy. Some operations in
      the kernel like cpu_suspend and __cpu_disable do not require a flush of the
      entire cache hierarchy to DRAM but just the cache levels belonging to the
      Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
      correspond to L1.
      
      The current cache flushing API used in cpu_suspend and __cpu_disable,
      flush_cache_all(), ends up flushing the whole cache hierarchy since for
      v7 it cleans and invalidates all cache levels up to Level of Coherency
      (LoC) which cripples system performance when used in hot paths like hotplug
      and cpuidle.
      
      Therefore a new kernel cache maintenance API must be added to cope with
      latest ARM system requirements.
      
      This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.
      
      This function cleans and invalidates all data cache levels up to the
      Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
      cache for processors that support it (> v7).
      
      This patch also creates an alias of the cache LoUIS function to flush_kern_all
      for all processor versions prior to v7, so that the current cache flushing
      behaviour is unchanged for those processors.
      
      v7 cache maintenance code implements a cache LoUIS function that cleans and
      invalidates the D-cache up to LoUIS and invalidates the I-cache, according
      to the new API.
      Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: NShawn Guo <shawn.guo@linaro.org>
      031bd879
  4. 07 5月, 2012 1 次提交
  5. 02 5月, 2012 1 次提交
  6. 06 12月, 2011 1 次提交
  7. 07 7月, 2011 1 次提交
  8. 23 2月, 2011 1 次提交
  9. 08 10月, 2010 1 次提交
  10. 27 7月, 2010 1 次提交
    • R
      ARM: Factor out common code from cpu_proc_fin() · 9ca03a21
      Russell King 提交于
      All implementations of cpu_proc_fin() start by disabling interrupts
      and then flush caches.  Rather than have every processors proc_fin()
      implementation do this, move it out into generic code - and move the
      cache flush past setup_mm_for_reboot() (so it can benefit from having
      caches still enabled.)
      
      This allows cpu_proc_fin() to become independent of the L1/L2 cache
      types, and eventually move the L2 cache flushing into the L2 support
      code.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9ca03a21
  11. 15 2月, 2010 2 次提交
  12. 14 12月, 2009 1 次提交
  13. 03 10月, 2009 1 次提交
  14. 23 3月, 2009 1 次提交
    • E
      [ARM] pxa: add base support for Marvell's PXA168 processor line · 49cbe786
      Eric Miao 提交于
      """The Marvell® PXA168 processor is the first in a family of application
      processors targeted at mass market opportunities in computing and consumer
      devices. It balances high computing and multimedia performance with low
      power consumption to support extended battery life, and includes a wealth
      of integrated peripherals to reduce overall BOM cost .... """
      
      See http://www.marvell.com/featured/pxa168.jsp for more information.
      
        1. Marvell Mohawk core is a hybrid of xscale3 and its own ARM core,
           there are many enhancements like instructions for flushing the
           whole D-cache, and so on
      
        2. Clock reuses Russell's common clkdev, and added the basic support
           for UART1/2.
      
        3. Devices are a bit different from the 'mach-pxa' way, the platform
           devices are now dynamically allocated only when necessary (i.e.
           when pxa_register_device() is called). Description for each device
           are stored in an array of 'struct pxa_device_desc'. Now that:
      
           a. this array of device description is marked with __initdata and
              can be freed up system is fully up
      
           b. which means board code has to add all needed devices early in
              his initializing function
      
           c. platform specific data can now be marked as __initdata since
              they are allocated and copied by platform_device_add_data()
      
        4. only the basic UART1/2/3 are added, more devices will come later.
      Signed-off-by: NJason Chagas <chagas@marvell.com>
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      49cbe786
  15. 01 10月, 2008 2 次提交
  16. 18 5月, 2008 1 次提交
  17. 24 4月, 2008 1 次提交
  18. 19 4月, 2008 1 次提交
  19. 31 10月, 2007 1 次提交
    • R
      [ARM] Fix FIQ issue with ARM926 · 0214f922
      Russell King 提交于
      Jon Eibertzon writes:
      > We have noticed that the I-cache is disabled while waiting for
      > interrupt in cpu_arm926_do_idle in arch/arm/mm/proc-arm926.S
      > and we are curious to know why, because this causes us a great
      > performance hit when executing in FIQ-handlers. Is it assumed
      > here that every individual FIQ-handler re-enables the I-cache?
      
      The I-cache disable is an errata workaround, so the solution is to
      disable FIQs across the section with the I-cache disabled.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0214f922
  20. 13 12月, 2006 1 次提交
    • R
      [ARM] Unuse another Linux PTE bit · ad1ae2fe
      Russell King 提交于
      L_PTE_ASID is not really required to be stored in every PTE, since we
      can identify it via the address passed to set_pte_at().  So, create
      set_pte_ext() which takes the address of the PTE to set, the Linux
      PTE value, and the additional CPU PTE bits which aren't encoded in
      the Linux PTE value.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ad1ae2fe
  21. 09 12月, 2006 1 次提交
    • R
      [ARM] Handle HWCAP_VFP in VFP support code · efe90d27
      Russell King 提交于
      Don't set HWCAP_VFP in the processor support file; not only does it
      depend on the processor features, but it also depends on the support
      code being present.  Therefore, only set it if the support code
      detects that we have a VFP coprocessor attached.
      
      Also, move the VFP handling of the coprocessor access register into
      the VFP support code.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      efe90d27
  22. 30 11月, 2006 1 次提交
  23. 07 9月, 2006 1 次提交
  24. 01 7月, 2006 1 次提交
  25. 30 6月, 2006 1 次提交
    • R
      [ARM] Set bit 4 on section mappings correctly depending on CPU · 8799ee9f
      Russell King 提交于
      On some CPUs, bit 4 of section mappings means "update the
      cache when written to".  On others, this bit is required to
      be one, and others it's required to be zero.  Finally, on
      ARMv6 and above, setting it turns on "no execute" and prevents
      speculative prefetches.
      
      With all these combinations, no one value fits all CPUs, so we
      have to pick a value depending on the CPU type, and the area
      we're mapping.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8799ee9f
  26. 29 6月, 2006 3 次提交
  27. 22 3月, 2006 2 次提交
  28. 20 9月, 2005 1 次提交
  29. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4