1. 23 6月, 2016 2 次提交
    • T
      ARM: OMAP4+: Prevent CPU1 related hang with kexec · 0573b957
      Tony Lindgren 提交于
      Kexec booted kernels on omap4 will hang early during the boot if the
      booted kernel is different version from the previous kernel.
      
      This is because the previous kernel may have configured low-power mode
      using CPU1_WAKEUP_NS_PA_ADDR. In that case it points to the previous
      kernel's omap4_secondary_startup(), and CPU1 can be in low power mode
      from the previous kernel. When the new kernel configures the CPU1
      clockdomain, CPU1 can wake from low power state prematurely during
      omap44xx_clockdomains_init() running random code.
      
      Let's fix the issue by configuring CPU1_WAKEUP_NS_PA_ADDR before we
      call omap44xx_clockdomains_init(). Note that this is very early during
      the init, and we will do proper CPU1 reset during SMP init a bit later
      on in omap4_smp_prepare_cpus(). And we need to do this when SMP is
      not enabled as the previous kernel may have had it enabled.
      Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
      Tested-by: NKeerthy <j-keerthy@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      0573b957
    • T
      ARM: OMAP4+: Initialize SAR RAM base early for proper CPU1 reset for kexec · f4b9f40a
      Tony Lindgren 提交于
      Prepare things for making kexec work on SMP omap variants by initializing
      SARM RAM base early. This allows us to configure CPU1 for kexec in case
      the previous kernel has put CPU1 in low power mode.
      
      Note that this should not prevent moving other SAR RAM code to live
      under drivers. However for kexec, we will need this very early.
      Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
      Tested-by: NKeerthy <j-keerthy@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f4b9f40a
  2. 02 12月, 2015 1 次提交
  3. 17 10月, 2015 1 次提交
  4. 16 10月, 2015 1 次提交
  5. 25 7月, 2015 2 次提交
  6. 16 7月, 2015 1 次提交
  7. 17 3月, 2015 1 次提交
  8. 18 1月, 2015 1 次提交
    • M
      ARM: OMAP: Work around hardcoded interrupts · 0fb22a8f
      Marc Zyngier 提交于
      Commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain")
      changed the GIC driver to use a non-legacy IRQ domain on DT
      platforms. This patch assumes that DT-driven systems are getting
      all of their interrupts from device tree.
      
      Turns out that OMAP has quite a few hidden gems, and still uses
      hardcoded interrupts despite having fairly complete DTs.
      
      This patch attempts to work around these by offering a translation
      method that can be called directly from the hwmod code, if present.
      The same hack is sprinkled over PRCM and TWL.
      
      It isn't pretty, but it seems to do the job without having to add
      more hacks to the interrupt controller code.
      
      Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NNishanth Menon <nm@ti.com>
      [tony@atomide.com: updated to fix make randconfig issue]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      0fb22a8f
  9. 16 1月, 2015 1 次提交
  10. 15 1月, 2015 2 次提交
    • T
      ARM: OMAP2+: Fix reboot for 81xx · bc7235c9
      Tony Lindgren 提交于
      We are missing proper hooks for 81xx for reboot to work.
      
      Cc: Brian Hutchinson <b.hutchman@gmail.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      bc7235c9
    • T
      ARM: OMAP2+: Fix ti81xx class type · c27964b5
      Tony Lindgren 提交于
      Otherwise it will return true for cpu_is_omap34xx() which we don't
      want for the clocks and hwmod. It's closer to am33xx for the clocks
      and hwmod than to the omap34xx. We also want to be able to detect
      814x and 816x separately as at least the clocks are different with
      814x using a apll and 816x using a fapll for the source clocks.
      
      Note that we can also remove omap3xxx_clk_init() call as it's wrong
      and ti81xx are booting in device tree only mode.
      
      Cc: Brian Hutchinson <b.hutchman@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c27964b5
  11. 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
  12. 17 9月, 2014 1 次提交
    • F
      irqchip: add irq-omap-intc.h header · eaacabc0
      Felipe Balbi 提交于
      OMAP INTC irqchip driver will be moved under
      drivers/irqchip/ soon but we still have a dependency
      with mach-omap2 when it comes to idle functions.
      
      In order to make it easy to share those function
      prototypes with OMAP PM code, we introduce this new
      header.
      
      To avoid modifying several board-files and some of
      the PM-related code, we just include the new header
      from common.h which was already included by all
      users of IRQ-related PM code.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      eaacabc0
  13. 12 9月, 2014 5 次提交
  14. 09 9月, 2014 2 次提交
  15. 07 7月, 2014 1 次提交
  16. 17 6月, 2014 1 次提交
    • A
      ARM: omap2: fix am43xx dependency on l2x0 cache · 2ad501cc
      Arnd Bergmann 提交于
      Commit d941f86f ("ARM: l2c: AM43x: add L2 cache support") enabled
      the L2 cache support for the am43xx SoC, but caused a build regression
      when the driver for that cache controller is disabled:
      
      arch/arm/mach-omap2/built-in.o: In function `am43xx_init_early':
      :(.init.text+0xb20): undefined reference to `omap_l2_cache_init'
      
      This did not happen for OMAP4, which has the same call, but enables
      the l2x0 driver unconditionally. We could do the same thing for
      am43xx, but it seems better to allow turning it off and make the
      code work in either case.
      
      This adds an inline wrapper for omap_l2_cache_init for the disabled
      case, and removes the 'select' from OMAP4 so it becomes a user
      visible option.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: linux-omap@vger.kernel.org
      2ad501cc
  17. 16 6月, 2014 1 次提交
  18. 30 5月, 2014 1 次提交
  19. 19 3月, 2014 2 次提交
    • T
      ARM: OMAP2+: DT 'compatible' tweak for displays · 6a0e6b38
      Tomi Valkeinen 提交于
      As there is no common panel framework in the kernel, we have OMAP
      specific panel drivers. However, the DT data should be generic. This
      brings the issue that some other platform could use the same panels, and
      would need to create a driver with the same 'compatible' string as the
      OMAP driver.
      
      In the long run, we have to get a common panel framework. For the time
      being, this patch solves the issue:
      
      At early boot time, we go through the DT nodes looking for the panels
      the kernel supports for OMAP. For each found node, the 'compatible'
      string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
      "omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
      at the beginning of their compatible field.
      
      This allows us to have generic DT data, but OMAP specific display
      drivers.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      6a0e6b38
    • T
      ARM: OMAP2+: add omapdss_init_of() · dcdf407b
      Tomi Valkeinen 提交于
      The OMAP display architecture requires a bunch of platform devices which
      are not created via .dts (for now). We also need to pass a few function
      pointers and the DSS hardware version from the arch code to omapdss
      driver.
      
      This patch adds omapdss_init_of() function, called from board-generic at
      init time, which handles those tasks.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      dcdf407b
  20. 01 2月, 2014 2 次提交
  21. 18 1月, 2014 1 次提交
  22. 09 12月, 2013 1 次提交
    • T
      ARM: OMAP2+: Add support for legacy auxdata for twl · dad12d11
      Tony Lindgren 提交于
      As we currently need to support a mix of legacy platform data and
      device tree intialized data, let's make sure things keep working
      for the TWL GPIOs.
      
      Mostly the issue is caused by the fact that DSS does not yet have
      device tree bindings, so we need to rely on the TWL GPIO callback
      for setting up things like LCD backlight for some boards.
      
      As of_platform_populate() for the TWL GPIO is called by twl-core
      after the I2C bus has been initialized, we cannot pass the auxdata
      table from the board init code to twl-core like we used to with
      just legacy platform data.
      
      So let's use the omap_device bus hook to patch in the platform
      data for TWL GPIO until we have sorted out the issues with the
      TWL GPIOs and device tree bindings.
      
      The other option was be to initialize twl core using legacy
      platform data, which seems like a step backwards as we're moving
      to device tree only initialization.  And we really don't want to
      add custom configuration functions to the TWL GPIO driver either
      for this.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dad12d11
  23. 19 11月, 2013 1 次提交
  24. 22 10月, 2013 1 次提交
    • N
      ARM: OMAP2+: add missing lateinit hook for calling pm late init · 765e7a06
      Nishanth Menon 提交于
      AM335x, AM43xx, OMAP5 and DRA7 have missing late init hook. Introduce
      SoC specific hook with a call to OMAP2+ generic lateinit hook. This
      allows the generic late initializations such as cpufreq hooks to be
      active.
      
      Based on out-of-tree patches that need to be introduced in
      mainline, this introduction allows us to provide the foundation for
      further SoC specific features as they are developed.
      
      Cc: Benoit Cousson <bcousson@baylibre.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      765e7a06
  25. 11 10月, 2013 1 次提交
  26. 26 9月, 2013 1 次提交
  27. 13 8月, 2013 1 次提交
  28. 10 7月, 2013 1 次提交
  29. 12 6月, 2013 1 次提交
    • A
      ARM: OMAP2+: AM43x: early init · c5107027
      Afzal Mohammed 提交于
      Minimal early init - PRCM initialization not yet taken care.
      
      Control module is similar (base address, feature register etc.) as
      that of AM335x, while PRCM base address is different. Instead of
      adding a new header file for AM43x, PRCM base address is added in
      AM335x header file as it is similar to it to a large extent.
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      [tony@atomide.com: updated to drop am33xx_check_features()]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c5107027
  30. 10 4月, 2013 1 次提交