1. 20 5月, 2013 1 次提交
  2. 11 4月, 2013 1 次提交
  3. 13 3月, 2013 1 次提交
    • P
      ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup · 92702df3
      Paul Walmsley 提交于
      Commit 17b7e7d3 ("ARM: OMAP4:
      clock/hwmod data: start to remove some IP block control "clocks"")
      introduced a regression preventing the L3INIT clockdomain of OMAP4
      systems from entering idle.  This in turn prevented these systems from
      entering full chip clock-stop.
      
      The regression was caused by the incorrect removal of a so-called
      "optional functional clock" from the OMAP4 clock data.  This wasn't
      caught for two reasons.  First, I missed the retention entry failure
      in the branch test logs:
      
      http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt
      
      Second, the integration data for the OCP2SCP PHY IP block, added by
      commit 0c668875 ("ARM: OMAP4: hwmod
      data: add remaining USB-related IP blocks"), should have associated this
      clock with the IP block, but did not.
      
      Fix by adding back the so-called "optional" functional clock to the
      clock data, and by linking that clock to the OCP2SCP PHY IP block
      integration hwmod data.
      
      The problem patch was discovered by J, Keerthy <j-keerthy@ti.com>.
      
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      92702df3
  4. 11 2月, 2013 3 次提交
  5. 07 2月, 2013 1 次提交
  6. 26 1月, 2013 2 次提交
    • P
      ARM: OMAP4: clock/hwmod data: remove MODULEMODE entries in mux + gate combos · ee877acd
      Paul Walmsley 提交于
      Convert all DEFINE_OMAP_MUX_GATE() combinations that list MODULEMODE
      registers in their gate arguments to DEFINE_OMAP_MUX(), dropping the
      MODULEMODE data.  This is possible because the MODULEMODE bits control
      IP blocks, not clocks; and the hwmod code takes care of IP block
      control.  Rename these clocks to reflect the original multiplexer name
      as specified in the comments.  And convert the hwmod data to use the
      multiplexer clock name.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      ee877acd
    • P
      ARM: OMAP4: clock/hwmod data: start to remove some IP block control "clocks" · 17b7e7d3
      Paul Walmsley 提交于
      Remove some leaf "clocks" that are actually IP block idle control
      points, since these should now be handled by the hwmod code.
      
      There are still a few types of MODULEMODE clocks that need to be
      cleaned up:
      
      - those still in use by driver or integration code
      
      - those in DEFINE_CLK_OMAP_MUX_GATE() blocks; the gate portion of
        these should be removed
      
      A similar process may also be possible on OMAP2/3.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      17b7e7d3
  7. 19 1月, 2013 1 次提交
  8. 18 12月, 2012 1 次提交
  9. 04 12月, 2012 1 次提交
  10. 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
  11. 28 11月, 2012 1 次提交
  12. 21 11月, 2012 1 次提交
  13. 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
  14. 08 11月, 2012 1 次提交
  15. 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
  16. 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
  17. 19 10月, 2012 1 次提交
  18. 18 10月, 2012 2 次提交
  19. 16 10月, 2012 2 次提交
  20. 24 9月, 2012 9 次提交
  21. 22 9月, 2012 1 次提交
  22. 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
  23. 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
  24. 11 9月, 2012 1 次提交
  25. 04 9月, 2012 1 次提交
  26. 04 7月, 2012 1 次提交