1. 10 4月, 2013 1 次提交
    • S
      ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state() · e7457253
      Santosh Shilimkar 提交于
      Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
      to check whether the MPU cluster lost context or not before calling
      cpu_cluster_pm_exit().  This was initially done an optimization for
      corner cases, where if the cluster low power entry fails for some
      reason, the cluster context restore gets skipped.  However, since
      reading the previous context is expensive (involving slow accesses to
      the PRCM), it's better to avoid it and simply check the target cluster
      state instead.
      
      Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
      once the PRM/CM code gets moved to drivers. This patch also reduces one
      dependency with platform code for idle driver movement.
      Acked-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      [khilman@linaro.org: minor changelog edits]
      Signed-off-by: NKevin Hilman <khilman@linaro.org>
      e7457253
  2. 09 4月, 2013 1 次提交
  3. 27 3月, 2013 1 次提交
    • R
      ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized · ff931c82
      Rajendra Nayak 提交于
      clk inits on OMAP happen quite early, even before slab is available.
      The dependency comes from the fact that the timer init code starts to
      use clocks and hwmod and we need clocks to be initialized by then.
      
      There are various problems doing clk inits this early, one is,
      not being able to do dynamic clk registrations and hence the
      dependency on clk-private.h. The other is, inability to debug
      early kernel crashes without enabling DEBUG_LL and earlyprintk.
      
      Doing early clk init also exposed another instance of a kernel
      panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled.
      
      [    0.000000] Kernel BUG at c01174f8 [verbose debug info unavailable]
      [    0.000000] Internal error: Oops - BUG: 0 [#1] SMP ARM
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Not tainted  (3.9.0-rc1-12179-g72d48f9 #6)
      [    0.000000] PC is at __kmalloc+0x1d4/0x248
      [    0.000000] LR is at __clk_init+0x2e0/0x364
      [    0.000000] pc : [<c01174f8>]    lr : [<c0441f54>]    psr: 600001d3
      [    0.000000] sp : c076ff28  ip : c065cefc  fp : c0441f54
      [    0.000000] r10: 0000001c  r9 : 000080d0  r8 : c076ffd4
      [    0.000000] r7 : c074b578  r6 : c0794d88  r5 : 00000040  r4 : 00000000
      [    0.000000] r3 : 00000000  r2 : c07cac70  r1 : 000080d0  r0 : 0000001c
      [    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      [    0.000000] Control: 10c53c7d  Table: 8000404a  DAC: 00000017
      [    0.000000] Process swapper (pid: 0, stack limit = 0xc076e240)
      [    0.000000] Stack: (0xc076ff28 to 0xc0770000)
      [    0.000000] ff20:                   22222222 c0794ec8 c06546e8 00000000 00000040 c0794d88
      [    0.000000] ff40: c074b578 c076ffd4 c07951c8 c076e000 00000000 c0441f54 c074b578 c076ffd4
      [    0.000000] ff60: c0793828 00000040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac
      [    0.000000] ff80: 2f800000 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 00000000 00000000
      [    0.000000] ffa0: 00000000 00000000 00000000 00000001 c074cd6c c077b1ec 8000406a c0715724
      [    0.000000] ffc0: 00000000 00000000 00000000 00000000 00000000 c074c968 10c53c7d c0776974
      [    0.000000] ffe0: c074cd6c c077b1ec 8000406a 411fc092 00000000 80008074 00000000 00000000
      [    0.000000] [<c01174f8>] (__kmalloc+0x1d4/0x248) from [<c0441f54>] (__clk_init+0x2e0/0x364)
      [    0.000000] [<c0441f54>] (__clk_init+0x2e0/0x364) from [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140)
      [    0.000000] [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140) from [<c0719780>] (setup_arch+0x15c/0x284)
      [    0.000000] [<c0719780>] (setup_arch+0x15c/0x284) from [<c0715724>] (start_kernel+0x7c/0x334)
      [    0.000000] [<c0715724>] (start_kernel+0x7c/0x334) from [<80008074>] (0x80008074)
      [    0.000000] Code: e5883004 e1a00006 e28dd00c e8bd8ff0 (e7f001f2)
      [    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
      [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
      
      It was a know issue, that slab allocations would fail when common
      clock core tries to cache parent pointers for mux clocks on OMAP,
      and hence a patch 'clk: Allow late cache allocation for clk->parents,
      commit 7975059d' was added to work this problem around.
      A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely
      overlooked causing this regression.
      
      More details on the issue reported can be found here,
      http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html
      
      With all these issues around clk inits happening way too early, it
      makes sense to at least move them to a point where dynamic memory
      allocations are possible. So move them to a point just before the
      timer code starts using clocks and hwmod.
      
      This should at least pave way for clk inits on OMAP moving to dynamic
      clock registrations instead of using the static macros defined in
      clk-private.h.
      
      The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled
      was reported by Piotr Haber and Tony Lindgren and this patch
      fixes the reported issue as well.
      Reported-by: NPiotr Haber <phaber@broadcom.com>
      Reported-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: NMike Turquette <mturquette@linaro.org>
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Cc: stable@vger.kernel.org  # v3.8
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ff931c82
  4. 05 3月, 2013 1 次提交
  5. 02 2月, 2013 1 次提交
  6. 25 12月, 2012 1 次提交
  7. 22 11月, 2012 1 次提交
  8. 09 11月, 2012 3 次提交
  9. 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
  10. 01 11月, 2012 1 次提交
    • T
      ARM: OMAP: Remove plat-omap/common.h · 5c2e8852
      Tony Lindgren 提交于
      Most of the prototypes in plat-omap/common.h are not
      common to omap1 and omap2+, they are local to omap2+
      and should not be in plat-omap/common.h.
      
      The only shared function prototype in this file is
      omap_init_clocksource_32k(), let's put that into
      counter-32k.h.
      
      Note that the new plat/counter-32k.h must not be
      included from drivers, that will break omap2+ build
      for CONFIG_MULTIPLATFORM.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      5c2e8852
  11. 25 10月, 2012 2 次提交
  12. 19 10月, 2012 2 次提交
  13. 18 10月, 2012 2 次提交
  14. 13 9月, 2012 4 次提交
    • 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
    • T
      ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ · ec2c0825
      Tony Lindgren 提交于
      Remove hardcoded IRQs in irqs.h and related files as these
      are no longer needed.
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ec2c0825
    • T
      ARM: OMAP2+: Prepare for irqs.h removal · 7d7e1eba
      Tony Lindgren 提交于
      As the interrupts should only be defined in the platform_data, and
      eventually coming from device tree, there's no need to define them
      in header files.
      
      Let's remove the hardcoded references to irqs.h and fix up the includes
      so we don't rely on headers included in irqs.h. Note that we're
      defining OMAP_INTC_START as 0 to the interrupts. This will be needed
      when we enable SPARSE_IRQ. For some drivers we need to add
      #include <plat/cpu.h> for now until these drivers are fixed to
      remove cpu_is_omapxxxx() usage.
      
      While at it, sort som of the includes the standard way, and add
      the trailing commas where they are missing in the related data
      structures.
      
      Note that for drivers/staging/tidspbridge we just define things
      locally.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7d7e1eba
  15. 09 7月, 2012 4 次提交
  16. 05 7月, 2012 1 次提交
  17. 18 6月, 2012 1 次提交
  18. 05 6月, 2012 1 次提交
  19. 11 5月, 2012 2 次提交
  20. 09 5月, 2012 1 次提交
    • B
      ARM: OMAP4: hsmmc: check for null pointer · 1ee47b0a
      Balaji T K 提交于
      platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
      Add check for NULL pointer. while at it move the duplicated functions
      to omap4-common.c
      
      Fixes the following boot crash seen with omap4sdp and omap4panda
      when MMC is disabled.
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000008c
      pgd = c0004000
      [0000008c] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in:
      CPU: 0    Not tainted  (3.4.0-rc1-05971-ga4dfa82 #4)
      PC is at omap_4430sdp_init+0x184/0x410
      LR is at device_add+0x1a0/0x664
      Signed-off-by: NBalaji T K <balajitk@ti.com>
      Reported-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1ee47b0a
  21. 08 5月, 2012 2 次提交
  22. 13 4月, 2012 1 次提交
    • P
      ARM: OMAP: add includes for missing prototypes · e2ed89fc
      Paul Walmsley 提交于
      Several C files in arch/arm/mach-omap* and arch/arm/plat-omap declare
      functions that are used by other files, but don't include the header
      file where the prototype is declared.  This results in the following
      warnings from sparse:
      
          arch/arm/mach-omap2/irq.c:114:5: warning: symbol 'omap_irq_pending' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:186:13: warning: symbol 'omap2_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:191:13: warning: symbol 'omap3_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:196:13: warning: symbol 'ti81xx_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:233:39: warning: symbol 'omap2_intc_handle_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:242:6: warning: symbol 'omap_intc_save_context' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'omap_intc_restore_context' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:291:6: warning: symbol 'omap3_intc_suspend' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:297:6: warning: symbol 'omap3_intc_prepare_idle' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:306:6: warning: symbol 'omap3_intc_resume_idle' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:312:39: warning: symbol 'omap3_intc_handle_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/omap-secure.c:59:12: warning: symbol 'omap_secure_ram_reserve_memblock' was not declared. Should it be static?
          arch/arm/mach-omap2/board-zoom-display.c:133:13: warning: symbol 'zoom_display_init' was not declared. Should it be static?
          arch/arm/plat-omap/common.c:73:13: warning: symbol 'omap_init_consistent_dma_size' was not declared. Should it be static?
          arch/arm/mach-omap1/irq.c:61:5: warning: symbol 'omap_irq_flags' was not declared. Should it be static?
          arch/arm/mach-omap1/irq.c:179:13: warning: symbol 'omap1_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap1/reset.c:11:6: warning: symbol 'omap1_restart' was not declared. Should it be static?
      
      Fix by including the appropriate header files.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      
      e2ed89fc
  23. 27 2月, 2012 1 次提交
  24. 25 2月, 2012 3 次提交