1. 08 Sep, 2014 1 commit
  2. 29 May, 2014 2 commits
  3. 08 May, 2014 1 commit
  4. 31 Jan, 2014 1 commit
  5. 14 Jul, 2013 1 commit
    • Paul Gortmaker's avatar
      arm: delete __cpuinit/__CPUINIT usage from all ARM users · 8bd26e3a
      Paul Gortmaker authored
      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: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      8bd26e3a
  6. 09 Apr, 2013 4 commits
  7. 29 Jan, 2013 1 commit
  8. 05 Nov, 2012 1 commit
    • Santosh Shilimkar's avatar
      ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change. · ff999b8a
      Santosh Shilimkar authored
      
      
      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: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      ff999b8a
  9. 18 Oct, 2012 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2 · e4c060db
      Tony Lindgren authored
      
      
      We want to remove plat/cpu.h. To do this, let's first split
      it to private soc.h to mach-omap1 and mach-omap2. We have to
      keep plat/cpu.h around until the remaining drivers are fixed,
      so let's include the local soc.h in plat/cpu.h and for drivers
      still including plat/cpu.h.
      
      Once the drivers are fixed not to include plat/cpu.h, we
      can remove the file.
      
      This is needed for the ARM common zImage support.
      
      [tony@atomide.com: updated to not print a warning]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e4c060db
  10. 12 Sep, 2012 1 commit
  11. 20 Jul, 2012 1 commit
  12. 25 Jun, 2012 1 commit
  13. 28 Mar, 2012 1 commit
  14. 05 Mar, 2012 1 commit
  15. 28 Feb, 2012 1 commit
  16. 08 Dec, 2011 6 commits