1. 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
  2. 11 12月, 2014 1 次提交
  3. 28 9月, 2013 1 次提交
  4. 12 6月, 2013 1 次提交
    • T
      ARM: OMAP: add vdds_dsi supply for omapdss_dpi.0 · 1f92a1a4
      Tomi Valkeinen 提交于
      DPI driver gets currently the vdds_dsi regulator via omapdss device.
      This is not correct, and we'll change the DPI driver to get the
      regulator directly via omapdss_dpi.0 device.
      
      This patch changes the relevant board files to add vdds_dsi supply for
      omapdss_dpi.0 device.
      
      Note that the vdds_dsi supply for omapdss device is still left there, as
      the current display driver uses it. When both the board files and the
      display driver has been changed, we can remove the unused supply.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1f92a1a4
  5. 06 2月, 2013 1 次提交
    • T
      ARM: OMAP2+: Fix twl section warnings related to omap_twl4030_audio_init · 6689c875
      Tony Lindgren 提交于
      With the recent twl related changes we can now get:
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15f88): Section mismatch in
      reference from the function sdp3430_twl_gpio_setup() to the function
      .init.text:omap_twl4030_audio_init()
      The function sdp3430_twl_gpio_setup() references
      the function __init omap_twl4030_audio_init().
      This is often because sdp3430_twl_gpio_setup lacks a __init
      annotation or the annotation of omap_twl4030_audio_init is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0x16968): Section mismatch in
      reference from the function zoom_twl_gpio_setup() to the function
      .init.text:omap_twl4030_audio_init()
      The function zoom_twl_gpio_setup() references
      the function __init omap_twl4030_audio_init().
      This is often because zoom_twl_gpio_setup lacks a __init
      annotation or the annotation of omap_twl4030_audio_init is wrong.
      
      Fix this by removing __init from omap_twl4030_audio_init() as
      suggested by Peter Ujfalusi <peter.ujfalusi@ti.com>.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      6689c875
  6. 05 2月, 2013 1 次提交
  7. 22 1月, 2013 2 次提交
  8. 13 11月, 2012 1 次提交
    • K
      ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC · 1ef43369
      Kevin Hilman 提交于
      On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
      connected to the MSECURE input of the TWL6030 PMIC.  This signal
      controls the secure-mode operation of the PMIC.  If its not mux'd
      correctly, some functionality of the PMIC will not be accessible since
      the PMIC will be in secure mode.
      
      For example, if the TWL RTC is in secure mode, most of its registers
      are read-only, meaning (re)programming the RTC (e.g. for wakeup from
      suspend) will fail.
      
      To fix, ensure the signal is properly mux'd as output when TWL is
      intialized.
      
      This fix is required when using recent versions of u-boot (>= v2012.04.01)
      since u-boot is no longer setting the default mux for this pin.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1ef43369
  9. 06 11月, 2012 1 次提交
  10. 25 10月, 2012 1 次提交
    • T
      ARM: OMAP2+: Introduce local usb.h · 54db6eee
      Tony Lindgren 提交于
      Let's move what we can from plat/usb.h to the local usb.h
      for ARM common zImage support.
      
      This is needed so we can remove plat/usb.h for ARM common
      zImage support.
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Partha Basak <parthab@india.ti.com>
      Cc: Keshava Munegowda <keshava_mgowda@ti.com>
      Cc: linux-usb@vger.kernel.org
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      54db6eee
  11. 18 10月, 2012 1 次提交
  12. 09 10月, 2012 1 次提交
    • K
      ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS · 24d7b40a
      Kevin Hilman 提交于
      Currently, a dummy omap_device is created for the MPU sub-system so
      that a device node exists for MPU DVFS.  Specifically, for the
      association of MPU OPPs to a device node, and so that a voltage
      regulator can be mapped to a device node.
      
      For drivers to get a handle to this device node, an OMAP-specific API
      has been used.  However, the kernel already has device nodes for the
      CPU(s) in the system, so we can use those instead of an OMAP-specific
      dummy device and then drivers (like OMAP CPUfreq) can use generic
      APIs.
      
      To use the existing CPU device nodes, modify the OPP creation and
      regulator registration to use the CPU0 device node for registraion.
      
      NOTE: this patch always uses CPU0 as the device node.  On all
            OMAPs today, MPU DVFS scales all CPUs together, so this will
            not be a problem, but this assumption will need to be changed
            if independently scalable CPUs are introduced.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      24d7b40a
  13. 25 9月, 2012 1 次提交
  14. 13 9月, 2012 2 次提交
    • 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+: 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. 08 9月, 2012 1 次提交
  16. 07 9月, 2012 1 次提交
  17. 23 8月, 2012 1 次提交
  18. 16 8月, 2012 1 次提交
  19. 08 8月, 2012 1 次提交
  20. 20 7月, 2012 1 次提交
  21. 02 7月, 2012 1 次提交
  22. 21 6月, 2012 1 次提交
  23. 20 6月, 2012 1 次提交
  24. 10 5月, 2012 1 次提交
  25. 16 4月, 2012 1 次提交
  26. 07 3月, 2012 3 次提交
  27. 29 2月, 2012 1 次提交
  28. 24 11月, 2011 1 次提交
  29. 30 9月, 2011 2 次提交
  30. 10 8月, 2011 1 次提交
    • P
      OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds · d12d1fca
      Peter Ujfalusi 提交于
      Commit b22f954b (OMAP4: Move common twl6030 configuration to twl-common)
      caused compile failures for code for OMAP arch which is not selected by
      the config.
      
      Fixes issues like:
      With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
      
      arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
      
      Fix the problem by moving the code to ifdef sections for omap3 and omap4.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d12d1fca
  31. 04 7月, 2011 5 次提交