Skip to content

L
linux
Switch branch/tag
  1. 27 Sep, 2010 4 commits
  3. 24 Sep, 2010 17 commits
  5. 23 Sep, 2010 2 commits
  7. 22 Sep, 2010 2 commits
  9. 21 Sep, 2010 15 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7