1. 23 6月, 2016 1 次提交
  2. 13 5月, 2016 1 次提交
    • N
      ARM: OMAP5 / DRA7: Introduce workaround for 801819 · c0053bd5
      Nishanth Menon 提交于
      Add workaround for Cortex-A15 ARM erratum 801819 which says in summary
      that "A livelock can occur in the L2 cache arbitration that might
      prevent a snoop from completing. Under certain conditions this can
      cause the system to deadlock. "
      
      Recommended workaround is as follows:
      Do both of the following:
      
      1) Do not use the write-back no-allocate memory type.
      2) Do not issue write-back cacheable stores at any time when the cache
      is disabled (SCTLR.C=0) and the MMU is enabled (SCTLR.M=1). Because it
      is implementation defined whether cacheable stores update the cache when
      the cache is disabled it is not expected that any portable code will
      execute cacheable stores when the cache is disabled.
      
      For implementations of Cortex-A15 configured without the “L2 arbitration
      register slice” option (typically one or two core systems), you must
      also do the following:
      
      3) Disable write-streaming in each CPU by setting ACTLR[28:25] = 0b1111
      
      So, we provide an option to disable write streaming on OMAP5 and DRA7.
      It is a rare condition to occur and may be enabled selectively based
      on platform acceptance of risk.
      
      Applies to: A15 revisions r2p0, r2p1, r2p2, r2p3 or r2p4 and REVIDR[3]
      is set to 0.
      
      Based on ARM errata Document revision 18.0 (22 Nov 2013)
      
      Note: the configuration for the workaround needs to be done with
      each CPU bringup, since CPU0 bringup is done by bootloader, it is
      recommended to have the workaround in the bootloader, kernel also does
      ensure that CPU0 has the workaround and makes the workaround active
      when CPU1 gets active.
      
      With CONFIG_SMP disabled, it is expected to be done by the bootloader.
      
      This does show significant degradation in synthetic tests such as
      mbw (https://packages.qa.debian.org/m/mbw.html)
      mbw -n 100 100|grep AVG (on a test platform)
      Without enabling the erratum:
      AVG Method: MEMCPY  Elapsed: 0.13406  MiB: 100.00000  Copy: 745.913 MiB/s
      AVG Method: DUMB    Elapsed: 0.06746  MiB: 100.00000  Copy: 1482.357 MiB/s
      AVG Method: MCBLOCK Elapsed: 0.03058  MiB: 100.00000  Copy: 3270.569 MiB/s
      After enabling the erratum:
      AVG Method: MEMCPY  Elapsed: 0.13757  MiB: 100.00000  Copy: 726.913 MiB/s
      AVG Method: DUMB    Elapsed: 0.12024  MiB: 100.00000  Copy: 831.668 MiB/s
      AVG Method: MCBLOCK Elapsed: 0.09243  MiB: 100.00000  Copy: 1081.942 MiB/s
      
      Most benchmarks are designed for specific performance analysis, so
      overall usecase must be considered before making a decision to
      enable/disable the erratum workaround.
      
      Pending internal investigation, the erratum is kept disabled by default.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Suggested-by: NRichard Woodruff <r-woodruff2@ti.com>
      Suggested-by: NBrad Griffis <bgriffis@ti.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c0053bd5
  3. 02 12月, 2015 1 次提交
  4. 26 11月, 2015 1 次提交
    • G
      ARM: OMAP4+: SMP: use lockless clkdm/pwrdm api in omap4_boot_secondary · 918af9f9
      Grygorii Strashko 提交于
      OMAP CPU hotplug uses cpu1's clocks and power domains for CPU1 wake up
      from low power states (or turn on CPU1). This part of code is also
      part of system suspend (disable_nonboot_cpus()).
      >From other side, cpu1's clocks and power domains are used by CPUIdle. All above
      functionality is mutually exclusive and, therefore, lockless clkdm/pwrdm api
      can be used in omap4_boot_secondary().
      
      This fixes below back-trace on -RT which is triggered by
      pwrdm_lock/unlock():
      
      BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
       in_atomic(): 1, irqs_disabled(): 0, pid: 118, name: sh
       9 locks held by sh/118:
        #0:  (sb_writers#4){.+.+.+}, at: [<c0144a6c>] vfs_write+0x13c/0x164
        #1:  (&of->mutex){+.+.+.}, at: [<c01b4c70>] kernfs_fop_write+0x48/0x19c
        #2:  (s_active#24){.+.+.+}, at: [<c01b4c78>] kernfs_fop_write+0x50/0x19c
        #3:  (device_hotplug_lock){+.+.+.}, at: [<c03cbff0>] lock_device_hotplug_sysfs+0xc/0x4c
        #4:  (&dev->mutex){......}, at: [<c03cd284>] device_online+0x14/0x88
        #5:  (cpu_add_remove_lock){+.+.+.}, at: [<c003af90>] cpu_up+0x50/0x1a0
        #6:  (cpu_hotplug.lock){++++++}, at: [<c003ae48>] cpu_hotplug_begin+0x0/0xc4
        #7:  (cpu_hotplug.lock#2){+.+.+.}, at: [<c003aec0>] cpu_hotplug_begin+0x78/0xc4
        #8:  (boot_lock){+.+...}, at: [<c002b254>] omap4_boot_secondary+0x1c/0x178
       Preemption disabled at:[<  (null)>]   (null)
      
       CPU: 0 PID: 118 Comm: sh Not tainted 4.1.12-rt11-01998-gb4a62c3-dirty #137
       Hardware name: Generic DRA74X (Flattened Device Tree)
       [<c0017574>] (unwind_backtrace) from [<c0013be8>] (show_stack+0x10/0x14)
       [<c0013be8>] (show_stack) from [<c05a8670>] (dump_stack+0x80/0x94)
       [<c05a8670>] (dump_stack) from [<c05ad158>] (rt_spin_lock+0x24/0x54)
       [<c05ad158>] (rt_spin_lock) from [<c0030dac>] (clkdm_wakeup+0x10/0x2c)
       [<c0030dac>] (clkdm_wakeup) from [<c002b2c0>] (omap4_boot_secondary+0x88/0x178)
       [<c002b2c0>] (omap4_boot_secondary) from [<c0015d00>] (__cpu_up+0xc4/0x164)
       [<c0015d00>] (__cpu_up) from [<c003b09c>] (cpu_up+0x15c/0x1a0)
       [<c003b09c>] (cpu_up) from [<c03cd2d4>] (device_online+0x64/0x88)
       [<c03cd2d4>] (device_online) from [<c03cd360>] (online_store+0x68/0x74)
       [<c03cd360>] (online_store) from [<c01b4ce0>] (kernfs_fop_write+0xb8/0x19c)
       [<c01b4ce0>] (kernfs_fop_write) from [<c0144124>] (__vfs_write+0x20/0xd8)
       [<c0144124>] (__vfs_write) from [<c01449c0>] (vfs_write+0x90/0x164)
       [<c01449c0>] (vfs_write) from [<c01451e4>] (SyS_write+0x44/0x9c)
       [<c01451e4>] (SyS_write) from [<c0010240>] (ret_fast_syscall+0x0/0x54)
       CPU1: smp_ops.cpu_die() returned, trying to resuscitate
      
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      918af9f9
  5. 06 1月, 2015 1 次提交
    • L
      ARM: omap5/dra7xx: Enable booting secondary CPU in HYP mode · 999f934d
      Lennart Sorensen 提交于
      If the boot loader enables HYP mode on the boot CPU, the secondary CPU
      also needs to call into the ROM to switch to HYP mode before booting.
      The firmwares on the omap5 and dra7xx unfortunately do not take care
      of this, so it has to be handled by the kernel.
      
      This patch is based on "[PATCH 2/2] ARM: OMAP5: Add HYP mode entry support
      for secondary CPUs" by Santosh Shilimkar <santosh.shilimkar@ti.com>,
      except this version does not require a compile time CONFIG to control
      if it should enable HYP mode or not, it simply does it based on the mode
      of the boot CPU, so it works whether the CPU boots in SVC or HYP mode,
      and should even work as a guest kernel inside kvm if qemu decides to
      support emulating the omap5 or dra7xx.
      
      Cc: stable@vger.kernel.org #v3.16+
      Signed-off-by: NLen Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      999f934d
  6. 08 5月, 2014 1 次提交
  7. 01 2月, 2014 1 次提交
  8. 11 10月, 2013 1 次提交
  9. 19 9月, 2013 1 次提交
  10. 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
  11. 10 4月, 2013 1 次提交
  12. 06 4月, 2013 1 次提交
  13. 28 3月, 2013 3 次提交
  14. 27 3月, 2013 1 次提交
  15. 01 2月, 2013 1 次提交
  16. 29 1月, 2013 1 次提交
  17. 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
  18. 11 1月, 2013 1 次提交
  19. 15 11月, 2012 1 次提交
    • K
      ARM: OMAP4: PM: fix errata handling when CONFIG_PM=n · 93640735
      Kevin Hilman 提交于
      commit c9621844 (ARM: OMAP4: PM: add errata support) introduced errata
      handling for OMAP4, but was broken when CONFIG_PM=n.
      
      When CONFIG_PM=n, pm44xx.c is not compiled, yet that is where pm44xx_errata
      is defined.  However, these errata are needed for the SMP boot/hotplug case
      also, and are primarily used in omap-smp.c.
      
      Move the definition of pm44xx_errata to omap-smp.c so that it's available
      even in the CONFIG_PM=n case.
      
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      93640735
  20. 06 11月, 2012 2 次提交
    • C
      ARM: OMAP4: retrigger localtimers after re-enabling gic · cd8ce159
      Colin Cross 提交于
      'Workaround for ROM bug because of CA9 r2pX gic control'
      register change disables the gic distributor while the secondary
      cpu is being booted.  If a localtimer interrupt on the primary cpu
      occurs when the distributor is turned off, the interrupt is lost,
      and the localtimer never fires again.
      
      Make the primary cpu wait for the secondary cpu to reenable the
      gic distributor (with interrupts off for safety), and then
      check if the pending bit is set in the localtimer but not the
      gic.  If so, ack it in the localtimer, and reset the timer with
      the minimum timeout to trigger a new timer interrupt.
      Signed-off-by: NColin Cross <ccross@android.com>
      [s-jan@ti.com: adapted to k3.4 + validated functionality]
      Signed-off-by: NSebastien Jan <s-jan@ti.com>
      [t-kristo@ti.com: dropped generic ARM kernel exports from the code, rebased
       to mainline]
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      cd8ce159
    • S
      ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change. · ff999b8a
      Santosh Shilimkar 提交于
      On OMAP4+ devices, GIC register context is lost when MPUSS hits
      the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code
      gets executed and one of the steps in it is to restore the
      saved context of the GIC. The ROM Code GIC distributor restoration
      is split in two parts: CPU specific register done by each CPU and
      common register done by only one CPU.
      
      Below is the abstract flow.
      
      ...............................................................
      - MPUSS in OSWR state.
      - CPU0 wakes up on the event(interrupt) and start executing ROM code.
      
      [..]
      
      - CPU0 executes "GIC Restoration:"
      
      [...]
      
      - CPU0 swicthes to non-secure mode and jumps to OS resume code.
      
      [...]
      
      - CPU0 is online in OS
      - CPU0 enables the GIC distributor. GICD.Enable Non-secure = 1
      - CPU0 wakes up CPU1 with clock-domain force wakeup method.
      - CPU0 continues it's execution.
      [..]
      
      - CPU1 wakes up and start executing ROM code.
      
      [..]
      
      - CPU1 executes "GIC Restoration:"
      
      [..]
      
      - CPU1 swicthes to non-secure mode and jumps to OS resume code.
      
      [...]
      
      - CPU1 is online in OS and start executing.
      [...]   -
      
      GIC Restoration: /* Common routine for HS and GP devices */
      {
             if (GICD != 1)  { /* This will be true in OSWR state */
                     if (GIC_SAR_BACKUP_STATE == SAVED)
                             - CPU restores GIC distributor
                     else
                             - reconfigure GIC distributor to boot values.
      
                     GICD.Enable secure = 1
             }
      
             if (GIC_SAR_BACKUP_STATE == SAVED)
                     - CPU restore its GIC CPU interface registers if saved.
             else
                     - reconfigure its GIC CPU interface registers to boot
                             values.
      }
      ...............................................................
      
      So as mentioned in the flow, GICD != 1 condition decides how
      the GIC registers are handled in ROM code wakeup path from
      OSWR. As evident from the flow, ROM code relies on the entire
      GICD register value and not specific register bits.
      
      The assumption was valid till CortexA9 r1pX version since there
      was only one banked bit to control secure and non-secure GICD.
      Secure view which ROM code sees:
             bit 0 == Enable Non-secure
      Non-secure view which HLOS sees:
             bit 0 == Enable secure
      
      But GICD register has changed between CortexA9 r1pX and r2pX.
      On r2pX GICD register is composed of 2 bits.
      Secure view which ROM code sees:
             bit 1 == Enable Non-secure
             bit 0 == Enable secure
      Non-secure view which HLOS sees:
             bit 0 == Enable Non-secure
      
      Hence on OMAP4460(r2pX) devices, if you go through the
      above flow again during CPU1 wakeup, GICD == 3 and hence
      ROM code fails to understand the real wakeup power state
      and reconfigures GIC distributor to boot values. This is
      nasty since you loose the entire interrupt controller
      context in a live system.
      
      The ROM code fix done on next OMAP4 device (OMAP4470 - r2px) is to
      check "GICD.Enable secure != 1" for GIC restoration in OSWR wakeup path.
      
      Since ROM code can't be fixed on OMAP4460 devices, a work around
      needs to be implemented. As evident from the flow, as long as
      CPU1 sees GICD == 1 in it's wakeup path from OSWR, the issue
      won't happen. Below is the flow with the work-around.
      
      ...............................................................
      - MPUSS in OSWR state.
      - CPU0 wakes up on the event(interrupt) and start executing ROM code.
      
      [..]
      
      - CPU0 executes "GIC Restoration:"
      
      [..]
      
      - CPU0 swicthes to non-secure mode and jumps to OS resume code.
      
      [..]
      
      - CPU0 is online in OS.
      - CPU0 does GICD.Enable Non-secure = 0
      - CPU0 wakes up CPU1 with clock domain force wakeup method.
      - CPU0 waits for GICD.Enable Non-secure = 1
      - CPU0 coninues it's execution.
      [..]
      
      - CPU1 wakes up and start executing ROM code.
      
      [..]
      
      - CPU1 executes "GIC Restoration:"
      
      [..]
      
      - CPU1 swicthes to non-secure mode and jumps to OS resume code.
      
      [..]
      
      - CPU1 is online in OS
      - CPU1 does GICD.Enable Non-secure = 1
      - CPU1 start executing
      [...]
      ...............................................................
      
      With this procedure, the GIC configuration done between the
      CPU0 wakeup and CPU1 wakeup will not be lost but during this
      short windows, the CPU0 will not receive interrupts.
      
      The BUG is applicable to only OMAP4460(r2pX) devices.
      OMAP4470 (also r2pX) is not affected by this bug because
      ROM code has been fixed.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      ff999b8a
  21. 21 9月, 2012 2 次提交
  22. 13 9月, 2012 2 次提交
    • M
      ARM: SoC: convert OMAP4 to SMP operations · 06915321
      Marc Zyngier 提交于
      Convert OMAP4 to use struct smp_operations to provide its SMP
      and CPU hotplug operations.
      
      Tested on both Panda and IGEPv2 (MULTI_OMAP kernel)
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      06915321
    • T
      ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ · dbc04161
      Tony Lindgren 提交于
      As the plat and mach includes need to disappear for single zImage work,
      we need to remove plat/hardware.h.
      
      Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.
      
      The old plat/hardware.h already has omap1 only defines, so it gets moved
      to mach/hardware.h for omap1. For omap2+, we use the local soc.h
      that for now just includes the related SoC headers to keep this patch more
      readable.
      
      Note that the local soc.h still includes plat/cpu.h that can be dealt
      with in later patches. Let's also include plat/serial.h from common.h for
      all the board-*.c files. This allows making the include files local later
      on without patching these files again.
      
      Note that only minimal changes are done in this patch for the
      drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
      patches are needed to eventually remove cpu_is_omap usage in the drivers.
      
      Also only minimal changes are done to sound/soc/omap/* to remove the
      unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
      no need to include omap44xx.h.
      
      While at it, also sort some of the includes in the standard way.
      
      Cc: linux-watchdog@vger.kernel.org
      Cc: alsa-devel@alsa-project.org
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Acked-by: NWim Van Sebroeck <wim@iguana.be>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc04161
  23. 10 7月, 2012 1 次提交
  24. 09 7月, 2012 2 次提交
  25. 25 2月, 2012 1 次提交
  26. 09 12月, 2011 3 次提交
  27. 18 11月, 2011 1 次提交
  28. 21 10月, 2011 1 次提交
  29. 20 10月, 2011 1 次提交
  30. 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
  31. 23 5月, 2011 1 次提交
  32. 20 12月, 2010 1 次提交