1. 11 2月, 2013 3 次提交
  2. 19 1月, 2013 1 次提交
  3. 18 12月, 2012 1 次提交
  4. 04 12月, 2012 1 次提交
  5. 01 12月, 2012 1 次提交
    • T
      ARM: OMAP: Move plat-omap/dma-omap.h to include/linux/omap-dma.h · 45c3eb7d
      Tony Lindgren 提交于
      Based on earlier discussions[1] we attempted to find a suitable
      location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
      DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
      to dmaengine is complete.
      
      Unfortunately that was before I was able to try to test compile
      of the ARM multiplatform builds for omap2+, and the end result
      was not very good.
      
      So I'm creating yet another all over the place patch to cut the
      last dependency for building omap2+ for ARM multiplatform. After
      this, we have finally removed the driver dependencies to the
      arch/arm code, except for few drivers that are being worked on.
      
      The other option was to make the <plat-omap/dma-omap.h> path
      to work, but we'd have to add some new header directory to for
      multiplatform builds.
      
      Or we would have to manually include arch/arm/plat-omap/include
      again from arch/arm/Makefile for omap2+.
      
      Neither of these alternatives sound appealing as they will
      likely lead addition of various other headers exposed to the
      drivers, which we want to avoid for the multiplatform kernels.
      
      Since we already have a minimal include/linux/omap-dma.h,
      let's just use that instead and add a note to it to not
      use the custom omap DMA functions any longer where possible.
      
      Note that converting omap DMA to dmaengine depends on
      dmaengine supporting automatically incrementing the FIFO
      address at the device end, and converting all the remaining
      legacy drivers. So it's going to be few more merge windows.
      
      [1] https://patchwork.kernel.org/patch/1519591/#
      
      cc: Russell King <linux@arm.linux.org.uk>
      cc: Kevin Hilman <khilman@ti.com>
      cc: "Benoît Cousson" <b-cousson@ti.com>
      cc: Herbert Xu <herbert@gondor.apana.org.au>
      cc: "David S. Miller" <davem@davemloft.net>
      cc: Vinod Koul <vinod.koul@intel.com>
      cc: Dan Williams <djbw@fb.com>
      cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
      cc: David Woodhouse <dwmw2@infradead.org>
      cc: Kyungmin Park <kyungmin.park@samsung.com>
      cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      cc: Hans Verkuil <hans.verkuil@cisco.com>
      cc: Vaibhav Hiremath <hvaibhav@ti.com>
      cc: Lokesh Vutla <lokeshvutla@ti.com>
      cc: Rusty Russell <rusty@rustcorp.com.au>
      cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      cc: Afzal Mohammed <afzal@ti.com>
      cc: linux-crypto@vger.kernel.org
      cc: linux-media@vger.kernel.org
      cc: linux-mtd@lists.infradead.org
      cc: linux-usb@vger.kernel.org
      cc: linux-fbdev@vger.kernel.org
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      45c3eb7d
  6. 28 11月, 2012 1 次提交
  7. 21 11月, 2012 1 次提交
  8. 13 11月, 2012 1 次提交
    • J
      ARM: OMAP2+: Don't use __omap_dm_timer_reset() · 10759e82
      Jon Hunter 提交于
      Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
      configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
      timer OCP_CFG register. The name of the function is mis-leading because this
      function does not actually perform a reset of the timer.
      
      For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
      timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
      OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
      have the fields clock-activity, wakeup-enable and auto-idle and so this
      function could configure the OCP_CFG register incorrectly.
      
      Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
      register for timers that have this field. Commit 0f0d0807 (ARM: OMAP: DMTimer:
      Use posted mode) configures the clock-activity field to keep the f-clk enabled
      so that the wake-up capability is enabled. Therefore, add the appropriate flags
      to the timer HWMOD structures to configure this field in the same way.
      
      For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
      OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
      
      Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
      configuring the dmtimer OCP_CFG register as expected for clock-events timer.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      10759e82
  9. 08 11月, 2012 1 次提交
  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. 31 10月, 2012 1 次提交
    • P
      ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init · bc05244e
      Paul Walmsley 提交于
      Resolve this kernel boot message:
      
      omap_hwmod: mcpdm: cannot be enabled for reset (3)
      
      The McPDM on OMAP4 can only receive its functional clock from an
      off-chip source.  This source is not guaranteed to be present on the
      board, and when present, it is controlled by I2C.  This would
      introduce a board dependency to the early hwmod code which it was not
      designed to handle.  Also, neither the driver for this off-chip clock
      provider nor the I2C code is available early in boot when the hwmod
      code is attempting to enable and reset IP blocks.  This effectively
      makes it impossible to enable and reset this device during hwmod init.
      
      At its core, this patch is a workaround for an OMAP hardware problem.
      It should be possible to configure the OMAP to provide any IP block's
      functional clock from an on-chip source.  (This is true for almost
      every IP block on the chip.  As far as I know, McPDM is the only
      exception.)  If the kernel cannot reset and configure IP blocks, it
      cannot guarantee a sane SoC state.  Relying on an optional off-chip
      clock also creates a board dependency which is beyond the scope of the
      early hwmod code.
      
      This patch works around the issue by marking the McPDM hwmod record
      with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
      code from touching the device early during boot.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      bc05244e
  12. 19 10月, 2012 1 次提交
  13. 18 10月, 2012 2 次提交
  14. 16 10月, 2012 2 次提交
  15. 24 9月, 2012 9 次提交
  16. 22 9月, 2012 1 次提交
  17. 19 9月, 2012 1 次提交
    • A
      ARM: omap: move platform_data definitions · 2203747c
      Arnd Bergmann 提交于
      Platform data for device drivers should be defined in
      include/linux/platform_data/*.h, not in the architecture
      and platform specific directories.
      
      This moves such data out of the omap include directories
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: "Benoît Cousson" <b-cousson@ti.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: Jean Pihet <j-pihet@ti.com>
      Cc: J Keerthy <j-keerthy@ti.com>
      Cc: linux-omap@vger.kernel.org
      2203747c
  18. 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: OMAP: Move gpio.h to include/linux/platform_data · 4b25408f
      Tony Lindgren 提交于
      This way we can remove includes of plat/gpio.h which won't work
      with the single zImage support.
      
      Note that we also remove the cpu_class_is_omap2() check
      in gpio-omap.c as the drivers should not call it as we need to
      make it local to arch/arm/mach-omap2 for single zImage support.
      
      While at it, arrange the related includes in the standard way.
      
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: linux-mtd@lists.infradead.org
      Cc: alsa-devel@alsa-project.org
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      4b25408f
  19. 11 9月, 2012 1 次提交
  20. 04 9月, 2012 1 次提交
  21. 04 7月, 2012 2 次提交
  22. 22 6月, 2012 2 次提交
    • R
      ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled · dc57aef5
      Ricardo Neri 提交于
      As per the OMAP4 documentation, audio over HDMI must be transmitted in
      no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
      no-idle/force-idle settings instead of smart-idle mode.
      
      This is required as the DSS interface clock is used as functional clock
      for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
      be choppy, have bad quality or not be audible at all.
      Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
      [b-cousson@ti.com: Update the subject and align the .flags
      location with the script template]
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      dc57aef5
    • P
      ARM: OMAP4: hwmod data: fix 32k sync timer idle modes · 252a4c54
      Paul Walmsley 提交于
      The 32k sync timer IP block target idle modes in the hwmod data are
      incorrect.  The IP block does not support any smart-idle modes.
      Update the data to reflect the correct modes.
      
      This problem was initially identified and a diff fragment posted to
      the lists by Benoît Cousson <b-cousson@ti.com>.  A patch description
      bug in the first version was also identified by Benoît.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      252a4c54
  23. 20 6月, 2012 1 次提交
  24. 19 6月, 2012 1 次提交
    • K
      ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module · 9ebfd285
      Kevin Hilman 提交于
      The enable/disable module functions are specific to SoCs with
      OMAP4-class PRCM.  Rather than use cpu_is* checks at runtime inside
      the enable/disable module functions, use cpu_is at init time to
      initialize function pointers only for SoCs that need them.
      
      NOTE: the cpu_is* check for _enable_module was different than
            the one for _disable_module, and this patch uses
            cpu_is_omap44xx() for both.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      [paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than
       per-hwmod since they do not vary by hwmod; added kerneldoc]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      9ebfd285
  25. 14 6月, 2012 1 次提交
    • J
      ARM: OMAP2+: HWMOD: Correct timer device attributes · 139486fa
      Jon Hunter 提交于
      Fix the following issues with the timer device attributes for OMAP2+ devices:
      
      1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
         that these timers are in an ALWAYS-ON power domain. This is not the case
         only timer1 is in an ALWAYS-ON power domain.
      2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
         that these timers are in an ALWAYS-ON power domain. This is not the case
         only timer1 and timer12 are in an ALWAYS-ON power domain.
      3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but
         is in an always-on power domain.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      139486fa