1. 02 12月, 2015 1 次提交
  2. 06 8月, 2015 1 次提交
  3. 18 5月, 2015 2 次提交
  4. 12 12月, 2013 1 次提交
  5. 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
  6. 08 4月, 2013 2 次提交
  7. 27 3月, 2013 1 次提交
  8. 30 1月, 2013 1 次提交
  9. 13 1月, 2013 1 次提交
    • R
      irqchip: Move ARM gic.h to include/linux/irqchip/arm-gic.h · 520f7bd7
      Rob Herring 提交于
      Now that we have GIC moved to drivers/irqchip and all GIC DT init for
      platforms using irqchip_init, move gic.h and update the remaining
      includes.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Anton Vorontsov <avorontsov@mvista.com>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Viresh Kumar <viresh.linux@gmail.com>
      Cc: Shiraz Hashim <shiraz.hashim@st.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      520f7bd7
  10. 11 1月, 2013 2 次提交
  11. 14 9月, 2012 2 次提交
  12. 05 9月, 2012 1 次提交
  13. 09 8月, 2012 1 次提交
    • L
      ARM: ux500: reform Ux500 family names · e1bbb55d
      Linus Walleij 提交于
      Counting the U9540 and the new U8540 as a U8500 family member
      does not work. Instead, split the function in two:
      
      cpu_is_u8500_family() covering U8500 and U8520
      cpu_is_ux540_family() covering U9540 and U8540
      
      This works much better in practice. Update users to keep the
      same behaviour.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      e1bbb55d
  14. 02 5月, 2012 2 次提交
    • L
      ARM: ux500: delete U5500 support · 29746f48
      Linus Walleij 提交于
      This platform has been obsoleted and was only available inside of
      ST-Ericsson, no users of this code are left in the world. This
      deletes the core U5500 support entirely in the same manner as the
      obsoleted U8500 silicon was previously deleted.
      
      The cpu_is_u5500() macros that can read out the CPU ID is left
      until the next kernel cycle, this makes it possible to merge
      deletion of dependent drivers without breakage.
      
      This also has the upside of removing the mailbox driver which was
      our only driver that was outside the drivers/* hiearchy, now the
      machine directory only handles machines and nothing else.
      
      Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Cc: Rabin Vincent <rabin.vincent@stericsson.com>
      Cc: Jonas Aberg <jonas.aberg@stericsson.com>
      Cc: Per Forlin <per.forlin@stericsson.com>
      Cc: Ulf Hansson <ulf.hansson@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      29746f48
    • L
      ARM: ux500: core U9540 support · bc71c096
      Linus Walleij 提交于
      This adds support for the U9540 variant of the U8500 series. This
      is an application processor without internal modem. This is the
      most basic part with ASIC ID, CPU-related fixes, IRQ list, register
      ranges, timer, UART, and L2 cache setup. This is based on a patch
      by Michel Jaouen which was rewritten to fit with the latest 3.3
      kernel.
      
      ChangeLog v1->v2: deleted the irqs-db9540.h file since we expect to
        migrate to using Device Tree for getting the IRQs to devices.
      ChangeLog v2->v3: introduced a fixed virtual offset for the ROM
        as suggested by Arnd Bergmann.
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NSebastien Pasdeloup <sebastien.pasdeloup-nonst@stericsson.com>
      Signed-off-by: NMichel Jaouen <michel.jaouen@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      bc71c096
  15. 11 4月, 2012 1 次提交
  16. 23 1月, 2012 1 次提交
  17. 21 10月, 2011 1 次提交
  18. 17 10月, 2011 1 次提交
  19. 07 7月, 2011 1 次提交
    • S
      ARM: 6993/1: platsmp: Allow secondary cpu hotplug with maxcpus=1 · 7fa22bd5
      Stephen Boyd 提交于
      If an ARM system has multiple cpus in the same socket and the
      kernel is booted with maxcpus=1, secondary cpus are possible but
      not present due to how platform_smp_prepare_cpus() is called.
      Since most typical ARM processors don't actually support physical
      hotplug, initialize the present map to be equal to the possible
      map in generic ARM SMP code. Also, always call
      platform_smp_prepare_cpus() as long as max_cpus is non-zero (0
      means no SMP) to allow platform code to do any SMP setup.
      
      After applying this patch it's possible to boot an ARM system
      with maxcpus=1 on the command line and then hotplug in secondary
      cpus via sysfs. This is more in line with how x86 does things.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Cc: Linus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7fa22bd5
  20. 23 5月, 2011 2 次提交
  21. 11 1月, 2011 1 次提交
  22. 20 12月, 2010 7 次提交
  23. 15 12月, 2010 1 次提交
  24. 03 12月, 2010 1 次提交
  25. 19 9月, 2010 1 次提交
  26. 05 5月, 2010 1 次提交
  27. 14 4月, 2010 1 次提交
  28. 28 11月, 2009 1 次提交