1. 24 Sep, 2010 16 commits
  2. 23 Sep, 2010 2 commits
  3. 22 Sep, 2010 2 commits
  4. 21 Sep, 2010 18 commits
    • Rajendra Nayak's avatar
      OMAP: hwmod: Enable module wakeup if in smartidle · 9980ce53
      Rajendra Nayak authored
      If a module's OCP slave port is programmed to be in smartidle,
      its also necessary that they have module level wakeup enabled.
      Update _sysc_enable in hwmod framework to do this.
      
      The thread "[PATCH 7/8] : Hwmod api changes" archived here:
      
      http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34212.html
      
      has additional technical information on the rationale of this patch.
      
      Sergei Shtylyov <sshtylyov@mvista.com> identified an indentation
      problem with this patch - thanks, Sergei.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarPartha Basak <p-basak2@ti.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      [paul@pwsan.com: revised patch description]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      9980ce53
    • Benoit Cousson's avatar
      OMAP: hwmod: Fix softreset for modules with optional clocks · 96835af9
      Benoit Cousson authored
      Some modules (like GPIO, DSS...) require optionals clock to be enabled
      in order to complete the sofreset properly.
      Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
      to be enabled before reset. Disabled them once the reset is done.
      
      TODO:
      For the moment it is very hard to understand from the HW spec, which
      optional clock is needed and which one is not. So the current approach
      will enable all the optional clocks.
      Paul proposed a much finer approach that will allow to tag only the needed
      clock in the optional clock table. This might be doable as soon as we have
      a clear understanding of these dependencies.
      Reported-by: default avatarPartha Basak <p-basak2@ti.com>
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      96835af9
    • Benoit Cousson's avatar
      OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs · 2cb06814
      Benoit Cousson authored
      In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
      Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
      use the SYSC softreset bit to provide the status.
      
      Other cases might exist:
      - Some IPs like McBSP does have a softreset control but no reset status.
      - Some IPs that represent subsystem, like the DSS, can contains
      a reset status without softreset control. The status is the aggregation
      of all the sub modules reset status.
      
      - Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
      and replace the previous SYSS_MISSING, that was used to flag IP with
      softreset control but without the SYSSTATUS register, with a specific
      SYSS_HAS_RESET_STATUS flag.
      
      - MCSPI and MMC contains both programming models, so the legacy one
      will be prevented by removing the syss offset field that become useless.
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      2cb06814
    • Paul Walmsley's avatar
      OMAP: hwmod: add an hardreset API for use by other core code · aee48e3c
      Paul Walmsley authored
      Expose an hardreset API from hwmod in order to assert / deassert all the
      individual reset lines that belong to an hwmod.  This API is needed by
      some of the more complicated processor drivers, e.g., DSP/Bridge,
      Syslink, etc.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      aee48e3c
    • Benoit Cousson's avatar
      OMAP: hwmod: Force a softreset during _setup · 76e5589e
      Benoit Cousson authored
      Force the softreset of every IPs during the _setup phase.
      IPs that cannot support softreset or that should not
      be reset must set the HWMOD_INIT_NO_RESET flag in the
      hwmod struct.
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      76e5589e
    • Benoît Cousson's avatar
      OMAP: hwmod: Add hardreset management support · 5365efbe
      Benoît Cousson authored
      Most processor IPs does have a hardreset signal controlled by the PRM.
      This is different of the softreset used for local IP reset from the
      SYSCONFIG register.
      The granularity can be much finer than orginal HWMOD, for ex, the IVA
      hwmod contains 3 reset lines, the IPU 3 as well, the DSP 2...
      Since this granularity is needed by the driver, we have to ensure
      than one hwmod exist for each hardreset line.
      
      - Store reset lines as hwmod resources that a driver can query by name like
        an irq or sdma line.
      
      - Add two functions for asserting / deasserting reset lines in hwmods
        processor that require manual reset control.
      - Add one functions to get the current reset state.
      - If an hwmod contains only one line, an automatic assertion / de-assertion
        is done.
        -> de-assert the hardreset line only during enable from disable transition
        -> assert the hardreset line only during shutdown
      
      Note: The hwmods with hardreset line and HWMOD_INIT_NO_RESET flag must be
      kept in INITIALIZED state.
      They can be properly enabled only if the hardreset line is de-asserted
      before.
      
      For information here is the list of IPs with HW reset control
      on an OMAP4430 device:
      
      RM_DSP_RSTCTRL
        1,1,'RST2','RW','1','DSP - MMU, cache and slave interface reset control'
        0,0,'RST1','RW','1','DSP - DSP reset control'
      
      RM_IVA_RSTCTRL
        2,2,'RST3','RW','1','IVA logic and SL2 reset control'
        1,1,'RST2','RW','1','IVA Sequencer2 reset control'
        0,0,'RST1','RW','1','IVA sequencer1 reset control'
      
      RM_IPU_RSTCTRL
        2,2,'RST3','RW','1','IPU MMU and CACHE interface reset control.'
        1,1,'RST2','RW','1','IPU Cortex M3 CPU2  reset control.'
        0,0,'RST1','RW','1','IPU Cortex M3 CPU1  reset control.'
      
      PRM_RSTCTRL
        1,1,'RST_GLOBAL_COLD_SW','RW','0','Global COLD software reset control.'
        0,0,'RST_GLOBAL_WARM_SW','RW','0','Global WARM software reset control.'
      
      RM_CPU0_CPU0_RSTCTRL
      RM_CPU1_CPU1_RSTCTRL
        0,0,'RST','RW','0','Cortex A9 CPU0&1 warm local reset control'
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      [paul@pwsan.com: made the hardreset functions static; moved the register
       twiddling into prm*.c functions in previous patches; changed the
       function names to conform with hwmod practice]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      5365efbe
    • Paul Walmsley's avatar
      OMAP2/3: PRM: add module hard reset support · cf21405f
      Paul Walmsley authored
      This patch adds hard-reset support for processor modules (e.g., DSP, IVA)
      on OMAP2/3 platforms.  It's based on the OMAP4 hard-reset support that Benoît
      developed in the previous patch.
      
      This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
      and Paul Walmsley <paul@pwsan.com>.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      cf21405f
    • Benoît Cousson's avatar
      OMAP4: PRM: add module hard reset support · 0be1621a
      Benoît Cousson authored
      Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset
      under the control of the PRM.  This patch adds an API for this purpose
      for OMAP4 devices:
      
      int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
      int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
      int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);
      
      This API is intended to be used only by the hwmod code - a subsequent
      patch will add that support to hwmod.
      
      This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
      and Paul Walmsley <paul@pwsan.com>.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      0be1621a
    • Benoit Cousson's avatar
      OMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM · 16b04012
      Benoit Cousson authored
      Since OMAP4 is using an absolute address, the current PRM accessors
      are not useable.
      OMAP4 adaptation for these API are currently ongoing, so define temp
      version until the proper ones are defined.
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      16b04012
    • Kevin Hilman's avatar
      OMAP: hwmod: separate list locking and hwmod hardware locking · 12b1fdb4
      Kevin Hilman authored
      Currently omap_hwmod_mutex is being used to protect both the list
      access/modification and concurrent access to hwmod functions.  This
      patch separates these two types of locking.
      
      First, omap_hwmod_mutex is used only to protect access and
      modification of omap_hwmod_list.  Also cleaned up some comments
      referring to this mutex that are no longer needed.
      
      Then, for protecting concurrent access to hwmod functions, use a
      per-hwmod mutex.  This protects concurrent access to a single hwmod,
      but would allow concurrent access to different hwmods.
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      [paul@pwsan.com: added structure documentation; changed mutex variable
       name]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      12b1fdb4
    • Rajeev Kulkarni's avatar
      OMAP4: prcm: Fix global warm reset bit position · ff4d3e18
      Rajeev Kulkarni authored
      OMAP4 platform has different register bits for Warm and Cold Resets.
      Write one into appropriate bits.
      Signed-off-by: default avatarRajeev Kulkarni <rajeevk@ti.com>
      Cc: Leed Aguilar <leed.aguilar@ti.com>
      [b-cousson@ti.com: Change the define with the proper one from omap4 headers]
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      ff4d3e18
    • Liam Girdwood's avatar
      OMAP: hwmod: Fix omap_hwmod_reset wrong state test · 9b579114
      Liam Girdwood authored
      The reset function wrongly used the state flag as a bit mask and was trying
      to re-enable after a reset.
      
      hwmod is still enabled for the PRCM point of view after a softreset
      so there is no need to re-enable.
      
      Remove the state check from omap_hwmod_reset since the _reset
      function is checking that as well and in addition can generate
      a warning
      Signed-off-by: default avatarLiam Girdwood <lrg@slimlogic.co.uk>
      [b-cousson@ti.com: remove the wrong test, remove the re-enable]
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      9b579114
    • Benoit Cousson's avatar
      OMAP: hwmod: Do not disable clocks if hwmod already in idle · 3827f949
      Benoit Cousson authored
      The disable function was disabling clocks and dependencies
      from both enable and idle state. Since idle function is already
      disabling both, an enable -> idle -> disable sequence will
      try to disable twice the clocks and thus generate a
      "Trying disable clock XXX with 0 usecount" warning.
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      3827f949
    • Kevin Hilman's avatar
      OMAP1: PM: add simple runtime PM layer to manage clocks · e933ec7c
      Kevin Hilman authored
      On OMAP1, we do not have omap_device + omap_hwmod to manage the
      device-specific idle, enable and shutdown.  Instead, just
      enable/disable device clocks automatically at the runtime PM level.
      
      This allows drivers to not have any OMAP1 specific clock management
      and allows them to simply use the runtime PM API to manage clocks.
      
      OMAP1 compile fixes Manjunatha GK <manjugk@ti.com>
      
      Cc: Manjunatha GK <manjugk@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      e933ec7c
    • Kevin Hilman's avatar
      OMAP2+: PM: initial runtime PM core support · 57e6fe7b
      Kevin Hilman authored
      Implement the new runtime PM framework as a thin layer on top of the
      omap_device API.  OMAP specific runtime PM methods are registered with
      the as custom methods on the platform_bus.
      
      In order to determine if a device is an omap_device, its parent device
      is checked.  All omap_devices have a new 'omap_device_parent_ device
      as their parent device, so checking for this parent is used to check
      for valid omap_devices.  If a device is an omap_device, then the
      appropriate omap_device functions are called for it.  If not, only the
      generic runtime PM functions are called.
      
      Device driver's ->runtime_idle() hook is called when the runtime PM
      usecount reaches zero for that device.  Driver's ->runtime_suspend()
      hooks are called just before the device is disabled (via
      omap_device_idle()), and device driver ->runtime_resume() hooks are
      called just after device has been enabled (via omap_device_enable().)
      
      OMAP4 build support from Rajendra Nayak <rnayak@ti.com>.
      OMAP2 build support from Charulatha V <charu@ti.com>
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Charulatha V <charu@ti.com>
      Acked-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      57e6fe7b
    • Thara Gopinath's avatar
      OMAP: PM debugfs removing OMAP3 hardcodings. · 6cdee912
      Thara Gopinath authored
      This patch removes omap3 hardcodings from pm-debug.c
      so that enabling PM debugfs support does break compilation
      for other OMAP's. This is a preparatory patch for supporting
      OMAP4 pm entries through PM debugfs.
      Signed-off-by: default avatarThara Gopinath <thara@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      6cdee912
    • Kevin Hilman's avatar
      OMAP3: PM: whitespace cleanup around IO wakeup enable · d5c47d7e
      Kevin Hilman authored
      Cleanup indentation around IO wakeup enable, the '\' terminator is
      not required in C when wrapping an expression past end-of-line.
      
      Whitespace change only.
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      d5c47d7e
    • Benoit Cousson's avatar
      OMAP: hwmod: Rename dma_ch to dma_req · 9ee9fff9
      Benoit Cousson authored
      The dma request line attribute was named dma channel, which leads
      to confusion with the real dma channel definition.
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      9ee9fff9
  5. 20 Sep, 2010 2 commits