2009-09-04 01:14:03 +08:00
|
|
|
/*
|
|
|
|
* omap_hwmod implementation for OMAP2/3/4
|
|
|
|
*
|
2011-03-01 02:58:14 +08:00
|
|
|
* Copyright (C) 2009-2011 Nokia Corporation
|
2012-04-19 14:49:09 +08:00
|
|
|
* Copyright (C) 2011-2012 Texas Instruments, Inc.
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
2010-05-19 10:24:05 +08:00
|
|
|
* Paul Walmsley, Benoît Cousson, Kevin Hilman
|
|
|
|
*
|
|
|
|
* Created in collaboration with (alphabetical order): Thara Gopinath,
|
|
|
|
* Tony Lindgren, Rajendra Nayak, Vikram Pandita, Sakari Poussa, Anand
|
|
|
|
* Sawant, Santosh Shilimkar, Richard Woodruff
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
2010-09-22 05:02:23 +08:00
|
|
|
* Introduction
|
|
|
|
* ------------
|
|
|
|
* One way to view an OMAP SoC is as a collection of largely unrelated
|
|
|
|
* IP blocks connected by interconnects. The IP blocks include
|
|
|
|
* devices such as ARM processors, audio serial interfaces, UARTs,
|
|
|
|
* etc. Some of these devices, like the DSP, are created by TI;
|
|
|
|
* others, like the SGX, largely originate from external vendors. In
|
|
|
|
* TI's documentation, on-chip devices are referred to as "OMAP
|
|
|
|
* modules." Some of these IP blocks are identical across several
|
|
|
|
* OMAP versions. Others are revised frequently.
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
2010-09-22 05:02:23 +08:00
|
|
|
* These OMAP modules are tied together by various interconnects.
|
|
|
|
* Most of the address and data flow between modules is via OCP-based
|
|
|
|
* interconnects such as the L3 and L4 buses; but there are other
|
|
|
|
* interconnects that distribute the hardware clock tree, handle idle
|
|
|
|
* and reset signaling, supply power, and connect the modules to
|
|
|
|
* various pads or balls on the OMAP package.
|
|
|
|
*
|
|
|
|
* OMAP hwmod provides a consistent way to describe the on-chip
|
|
|
|
* hardware blocks and their integration into the rest of the chip.
|
|
|
|
* This description can be automatically generated from the TI
|
|
|
|
* hardware database. OMAP hwmod provides a standard, consistent API
|
|
|
|
* to reset, enable, idle, and disable these hardware blocks. And
|
|
|
|
* hwmod provides a way for other core code, such as the Linux device
|
|
|
|
* code or the OMAP power management and address space mapping code,
|
|
|
|
* to query the hardware database.
|
|
|
|
*
|
|
|
|
* Using hwmod
|
|
|
|
* -----------
|
|
|
|
* Drivers won't call hwmod functions directly. That is done by the
|
|
|
|
* omap_device code, and in rare occasions, by custom integration code
|
|
|
|
* in arch/arm/ *omap*. The omap_device code includes functions to
|
|
|
|
* build a struct platform_device using omap_hwmod data, and that is
|
|
|
|
* currently how hwmod data is communicated to drivers and to the
|
|
|
|
* Linux driver model. Most drivers will call omap_hwmod functions only
|
|
|
|
* indirectly, via pm_runtime*() functions.
|
|
|
|
*
|
|
|
|
* From a layering perspective, here is where the OMAP hwmod code
|
|
|
|
* fits into the kernel software stack:
|
|
|
|
*
|
|
|
|
* +-------------------------------+
|
|
|
|
* | Device driver code |
|
|
|
|
* | (e.g., drivers/) |
|
|
|
|
* +-------------------------------+
|
|
|
|
* | Linux driver model |
|
|
|
|
* | (platform_device / |
|
|
|
|
* | platform_driver data/code) |
|
|
|
|
* +-------------------------------+
|
|
|
|
* | OMAP core-driver integration |
|
|
|
|
* |(arch/arm/mach-omap2/devices.c)|
|
|
|
|
* +-------------------------------+
|
|
|
|
* | omap_device code |
|
|
|
|
* | (../plat-omap/omap_device.c) |
|
|
|
|
* +-------------------------------+
|
|
|
|
* ----> | omap_hwmod code/data | <-----
|
|
|
|
* | (../mach-omap2/omap_hwmod*) |
|
|
|
|
* +-------------------------------+
|
|
|
|
* | OMAP clock/PRCM/register fns |
|
2014-04-16 01:37:46 +08:00
|
|
|
* | ({read,write}l_relaxed, clk*) |
|
2010-09-22 05:02:23 +08:00
|
|
|
* +-------------------------------+
|
|
|
|
*
|
|
|
|
* Device drivers should not contain any OMAP-specific code or data in
|
|
|
|
* them. They should only contain code to operate the IP block that
|
|
|
|
* the driver is responsible for. This is because these IP blocks can
|
|
|
|
* also appear in other SoCs, either from TI (such as DaVinci) or from
|
|
|
|
* other manufacturers; and drivers should be reusable across other
|
|
|
|
* platforms.
|
|
|
|
*
|
|
|
|
* The OMAP hwmod code also will attempt to reset and idle all on-chip
|
|
|
|
* devices upon boot. The goal here is for the kernel to be
|
|
|
|
* completely self-reliant and independent from bootloaders. This is
|
|
|
|
* to ensure a repeatable configuration, both to ensure consistent
|
|
|
|
* runtime behavior, and to make it easier for others to reproduce
|
|
|
|
* bugs.
|
|
|
|
*
|
|
|
|
* OMAP module activity states
|
|
|
|
* ---------------------------
|
|
|
|
* The hwmod code considers modules to be in one of several activity
|
|
|
|
* states. IP blocks start out in an UNKNOWN state, then once they
|
|
|
|
* are registered via the hwmod code, proceed to the REGISTERED state.
|
|
|
|
* Once their clock names are resolved to clock pointers, the module
|
|
|
|
* enters the CLKS_INITED state; and finally, once the module has been
|
|
|
|
* reset and the integration registers programmed, the INITIALIZED state
|
|
|
|
* is entered. The hwmod code will then place the module into either
|
|
|
|
* the IDLE state to save power, or in the case of a critical system
|
|
|
|
* module, the ENABLED state.
|
|
|
|
*
|
|
|
|
* OMAP core integration code can then call omap_hwmod*() functions
|
|
|
|
* directly to move the module between the IDLE, ENABLED, and DISABLED
|
|
|
|
* states, as needed. This is done during both the PM idle loop, and
|
|
|
|
* in the OMAP core integration code's implementation of the PM runtime
|
|
|
|
* functions.
|
|
|
|
*
|
|
|
|
* References
|
|
|
|
* ----------
|
|
|
|
* This is a partial list.
|
2009-09-04 01:14:03 +08:00
|
|
|
* - OMAP2420 Multimedia Processor Silicon Revision 2.1.1, 2.2 (SWPU064)
|
|
|
|
* - OMAP2430 Multimedia Device POP Silicon Revision 2.1 (SWPU090)
|
|
|
|
* - OMAP34xx Multimedia Device Silicon Revision 3.1 (SWPU108)
|
|
|
|
* - OMAP4430 Multimedia Device Silicon Revision 1.0 (SWPU140)
|
|
|
|
* - Open Core Protocol Specification 2.2
|
|
|
|
*
|
|
|
|
* To do:
|
|
|
|
* - handle IO mapping
|
|
|
|
* - bus throughput & module latency measurement code
|
|
|
|
*
|
|
|
|
* XXX add tests at the beginning of each function to ensure the hwmod is
|
|
|
|
* in the appropriate state
|
|
|
|
* XXX error return values should be checked to ensure that they are
|
|
|
|
* appropriate
|
|
|
|
*/
|
|
|
|
#undef DEBUG
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/io.h>
|
2012-11-11 07:58:41 +08:00
|
|
|
#include <linux/clk-provider.h>
|
2009-09-04 01:14:03 +08:00
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/mutex.h>
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
#include <linux/spinlock.h>
|
2011-12-17 05:36:59 +08:00
|
|
|
#include <linux/slab.h>
|
2012-04-19 18:04:30 +08:00
|
|
|
#include <linux/bootmem.h>
|
2013-03-22 05:49:38 +08:00
|
|
|
#include <linux/cpu.h>
|
2013-01-21 21:10:57 +08:00
|
|
|
#include <linux/of.h>
|
|
|
|
#include <linux/of_address.h>
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2013-01-26 15:48:56 +08:00
|
|
|
#include <asm/system_misc.h>
|
|
|
|
|
2012-09-28 00:33:34 +08:00
|
|
|
#include "clock.h"
|
2012-10-03 08:41:35 +08:00
|
|
|
#include "omap_hwmod.h"
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-09-01 01:59:07 +08:00
|
|
|
#include "soc.h"
|
|
|
|
#include "common.h"
|
|
|
|
#include "clockdomain.h"
|
|
|
|
#include "powerdomain.h"
|
2012-10-21 15:01:11 +08:00
|
|
|
#include "cm2xxx.h"
|
|
|
|
#include "cm3xxx.h"
|
2012-09-12 07:18:53 +08:00
|
|
|
#include "cm33xx.h"
|
2012-10-30 10:57:44 +08:00
|
|
|
#include "prm.h"
|
2012-10-21 15:01:10 +08:00
|
|
|
#include "prm3xxx.h"
|
2010-12-22 06:30:54 +08:00
|
|
|
#include "prm44xx.h"
|
2012-09-12 07:18:53 +08:00
|
|
|
#include "prm33xx.h"
|
2011-07-10 19:56:31 +08:00
|
|
|
#include "prminst44xx.h"
|
2010-12-23 10:42:35 +08:00
|
|
|
#include "mux.h"
|
2012-06-22 22:40:04 +08:00
|
|
|
#include "pm.h"
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
/* Name of the OMAP hwmod for the MPU */
|
2010-05-21 02:31:10 +08:00
|
|
|
#define MPU_INITIATOR_NAME "mpu"
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
/*
|
|
|
|
* Number of struct omap_hwmod_link records per struct
|
|
|
|
* omap_hwmod_ocp_if record (master->slave and slave->master)
|
|
|
|
*/
|
|
|
|
#define LINKS_PER_OCP_IF 2
|
|
|
|
|
2012-06-19 02:12:23 +08:00
|
|
|
/**
|
|
|
|
* struct omap_hwmod_soc_ops - fn ptrs for some SoC-specific operations
|
|
|
|
* @enable_module: function to enable a module (via MODULEMODE)
|
|
|
|
* @disable_module: function to disable a module (via MODULEMODE)
|
|
|
|
*
|
|
|
|
* XXX Eventually this functionality will be hidden inside the PRM/CM
|
|
|
|
* device drivers. Until then, this should avoid huge blocks of cpu_is_*()
|
|
|
|
* conditionals in this code.
|
|
|
|
*/
|
|
|
|
struct omap_hwmod_soc_ops {
|
|
|
|
void (*enable_module)(struct omap_hwmod *oh);
|
|
|
|
int (*disable_module)(struct omap_hwmod *oh);
|
2012-06-19 02:12:24 +08:00
|
|
|
int (*wait_target_ready)(struct omap_hwmod *oh);
|
2012-06-19 02:12:24 +08:00
|
|
|
int (*assert_hardreset)(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri);
|
|
|
|
int (*deassert_hardreset)(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri);
|
|
|
|
int (*is_hardreset_asserted)(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri);
|
2012-06-19 02:12:25 +08:00
|
|
|
int (*init_clkdm)(struct omap_hwmod *oh);
|
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kristo@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-22 07:15:17 +08:00
|
|
|
void (*update_context_lost)(struct omap_hwmod *oh);
|
|
|
|
int (*get_context_lost)(struct omap_hwmod *oh);
|
2012-06-19 02:12:23 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* soc_ops: adapts the omap_hwmod code to the currently-booted SoC */
|
|
|
|
static struct omap_hwmod_soc_ops soc_ops;
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/* omap_hwmod_list contains all registered struct omap_hwmods */
|
|
|
|
static LIST_HEAD(omap_hwmod_list);
|
|
|
|
|
|
|
|
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
|
|
|
|
static struct omap_hwmod *mpu_oh;
|
|
|
|
|
2012-06-22 22:40:04 +08:00
|
|
|
/* io_chain_lock: used to serialize reconfigurations of the I/O chain */
|
|
|
|
static DEFINE_SPINLOCK(io_chain_lock);
|
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
/*
|
|
|
|
* linkspace: ptr to a buffer that struct omap_hwmod_link records are
|
|
|
|
* allocated from - used to reduce the number of small memory
|
|
|
|
* allocations, which has a significant impact on performance
|
|
|
|
*/
|
|
|
|
static struct omap_hwmod_link *linkspace;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* free_ls, max_ls: array indexes into linkspace; representing the
|
|
|
|
* next free struct omap_hwmod_link index, and the maximum number of
|
|
|
|
* struct omap_hwmod_link records allocated (respectively)
|
|
|
|
*/
|
|
|
|
static unsigned short free_ls, max_ls, ls_supp;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-06-19 02:12:23 +08:00
|
|
|
/* inited: set to true once the hwmod code is initialized */
|
|
|
|
static bool inited;
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/* Private functions */
|
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
/**
|
2012-04-19 18:04:32 +08:00
|
|
|
* _fetch_next_ocp_if - return the next OCP interface in a list
|
2012-04-19 18:04:30 +08:00
|
|
|
* @p: ptr to a ptr to the list_head inside the ocp_if to return
|
2012-04-19 18:04:32 +08:00
|
|
|
* @i: pointer to the index of the element pointed to by @p in the list
|
|
|
|
*
|
|
|
|
* Return a pointer to the struct omap_hwmod_ocp_if record
|
|
|
|
* containing the struct list_head pointed to by @p, and increment
|
|
|
|
* @p such that a future call to this routine will return the next
|
|
|
|
* record.
|
2012-04-19 18:04:28 +08:00
|
|
|
*/
|
|
|
|
static struct omap_hwmod_ocp_if *_fetch_next_ocp_if(struct list_head **p,
|
|
|
|
int *i)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_ocp_if *oi;
|
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
oi = list_entry(*p, struct omap_hwmod_link, node)->ocp_if;
|
|
|
|
*p = (*p)->next;
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
*i = *i + 1;
|
|
|
|
|
|
|
|
return oi;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
|
|
|
* _update_sysc_cache - return the module OCP_SYSCONFIG register, keep copy
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Load the current value of the hwmod OCP_SYSCONFIG register into the
|
|
|
|
* struct omap_hwmod for later use. Returns -EINVAL if the hwmod has no
|
|
|
|
* OCP_SYSCONFIG register or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int _update_sysc_cache(struct omap_hwmod *oh)
|
|
|
|
{
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc) {
|
|
|
|
WARN(1, "omap_hwmod: %s: cannot read OCP_SYSCONFIG: not defined on hwmod's class\n", oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* XXX ensure module interface clock is up */
|
|
|
|
|
2010-10-09 01:23:22 +08:00
|
|
|
oh->_sysc_cache = omap_hwmod_read(oh, oh->class->sysc->sysc_offs);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!(oh->class->sysc->sysc_flags & SYSC_NO_CACHE))
|
2010-01-20 08:30:51 +08:00
|
|
|
oh->_int_flags |= _HWMOD_SYSCONFIG_LOADED;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _write_sysconfig - write a value to the module's OCP_SYSCONFIG register
|
|
|
|
* @v: OCP_SYSCONFIG value to write
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2010-02-23 13:09:34 +08:00
|
|
|
* Write @v into the module class' OCP_SYSCONFIG register, if it has
|
|
|
|
* one. No return value.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
|
|
|
static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
|
|
|
|
{
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc) {
|
|
|
|
WARN(1, "omap_hwmod: %s: cannot write OCP_SYSCONFIG: not defined on hwmod's class\n", oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* XXX ensure module interface clock is up */
|
|
|
|
|
2010-12-15 03:42:36 +08:00
|
|
|
/* Module might have lost context, always update cache and register */
|
|
|
|
oh->_sysc_cache = v;
|
|
|
|
omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _set_master_standbymode: set the OCP_SYSCONFIG MIDLEMODE field in @v
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @standbymode: MIDLEMODE field bits
|
|
|
|
* @v: pointer to register contents to modify
|
|
|
|
*
|
|
|
|
* Update the master standby mode bits in @v to be @standbymode for
|
|
|
|
* the @oh hwmod. Does not write to the hardware. Returns -EINVAL
|
|
|
|
* upon error or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int _set_master_standbymode(struct omap_hwmod *oh, u8 standbymode,
|
|
|
|
u32 *v)
|
|
|
|
{
|
2010-02-25 03:05:58 +08:00
|
|
|
u32 mstandby_mask;
|
|
|
|
u8 mstandby_shift;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_MIDLEMODE))
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
2010-02-25 03:05:58 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
mstandby_shift = oh->class->sysc->sysc_fields->midle_shift;
|
2010-02-25 03:05:58 +08:00
|
|
|
mstandby_mask = (0x3 << mstandby_shift);
|
|
|
|
|
|
|
|
*v &= ~mstandby_mask;
|
|
|
|
*v |= __ffs(standbymode) << mstandby_shift;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _set_slave_idlemode: set the OCP_SYSCONFIG SIDLEMODE field in @v
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @idlemode: SIDLEMODE field bits
|
|
|
|
* @v: pointer to register contents to modify
|
|
|
|
*
|
|
|
|
* Update the slave idle mode bits in @v to be @idlemode for the @oh
|
|
|
|
* hwmod. Does not write to the hardware. Returns -EINVAL upon error
|
|
|
|
* or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int _set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode, u32 *v)
|
|
|
|
{
|
2010-02-25 03:05:58 +08:00
|
|
|
u32 sidle_mask;
|
|
|
|
u8 sidle_shift;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_SIDLEMODE))
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
2010-02-25 03:05:58 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
sidle_shift = oh->class->sysc->sysc_fields->sidle_shift;
|
2010-02-25 03:05:58 +08:00
|
|
|
sidle_mask = (0x3 << sidle_shift);
|
|
|
|
|
|
|
|
*v &= ~sidle_mask;
|
|
|
|
*v |= __ffs(idlemode) << sidle_shift;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _set_clockactivity: set OCP_SYSCONFIG.CLOCKACTIVITY bits in @v
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @clockact: CLOCKACTIVITY field bits
|
|
|
|
* @v: pointer to register contents to modify
|
|
|
|
*
|
|
|
|
* Update the clockactivity mode bits in @v to be @clockact for the
|
|
|
|
* @oh hwmod. Used for additional powersaving on some modules. Does
|
|
|
|
* not write to the hardware. Returns -EINVAL upon error or 0 upon
|
|
|
|
* success.
|
|
|
|
*/
|
|
|
|
static int _set_clockactivity(struct omap_hwmod *oh, u8 clockact, u32 *v)
|
|
|
|
{
|
2010-02-25 03:05:58 +08:00
|
|
|
u32 clkact_mask;
|
|
|
|
u8 clkact_shift;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_CLOCKACTIVITY))
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
2010-02-25 03:05:58 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
clkact_shift = oh->class->sysc->sysc_fields->clkact_shift;
|
2010-02-25 03:05:58 +08:00
|
|
|
clkact_mask = (0x3 << clkact_shift);
|
|
|
|
|
|
|
|
*v &= ~clkact_mask;
|
|
|
|
*v |= clockact << clkact_shift;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2013-12-09 09:39:02 +08:00
|
|
|
* _set_softreset: set OCP_SYSCONFIG.SOFTRESET bit in @v
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @v: pointer to register contents to modify
|
|
|
|
*
|
|
|
|
* Set the SOFTRESET bit in @v for hwmod @oh. Returns -EINVAL upon
|
|
|
|
* error or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int _set_softreset(struct omap_hwmod *oh, u32 *v)
|
|
|
|
{
|
2010-02-25 03:05:58 +08:00
|
|
|
u32 softrst_mask;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
2010-02-25 03:05:58 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
softrst_mask = (0x1 << oh->class->sysc->sysc_fields->srst_shift);
|
2010-02-25 03:05:58 +08:00
|
|
|
|
|
|
|
*v |= softrst_mask;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-12-09 09:39:02 +08:00
|
|
|
/**
|
|
|
|
* _clear_softreset: clear OCP_SYSCONFIG.SOFTRESET bit in @v
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @v: pointer to register contents to modify
|
|
|
|
*
|
|
|
|
* Clear the SOFTRESET bit in @v for hwmod @oh. Returns -EINVAL upon
|
|
|
|
* error or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int _clear_softreset(struct omap_hwmod *oh, u32 *v)
|
|
|
|
{
|
|
|
|
u32 softrst_mask;
|
|
|
|
|
|
|
|
if (!oh->class->sysc ||
|
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1,
|
|
|
|
"omap_hwmod: %s: sysc_fields absent for sysconfig class\n",
|
|
|
|
oh->name);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
softrst_mask = (0x1 << oh->class->sysc->sysc_fields->srst_shift);
|
|
|
|
|
|
|
|
*v &= ~softrst_mask;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-10-30 12:02:13 +08:00
|
|
|
/**
|
|
|
|
* _wait_softreset_complete - wait for an OCP softreset to complete
|
|
|
|
* @oh: struct omap_hwmod * to wait on
|
|
|
|
*
|
|
|
|
* Wait until the IP block represented by @oh reports that its OCP
|
|
|
|
* softreset is complete. This can be triggered by software (see
|
|
|
|
* _ocp_softreset()) or by hardware upon returning from off-mode (one
|
|
|
|
* example is HSMMC). Waits for up to MAX_MODULE_SOFTRESET_WAIT
|
|
|
|
* microseconds. Returns the number of microseconds waited.
|
|
|
|
*/
|
|
|
|
static int _wait_softreset_complete(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_class_sysconfig *sysc;
|
|
|
|
u32 softrst_mask;
|
|
|
|
int c = 0;
|
|
|
|
|
|
|
|
sysc = oh->class->sysc;
|
|
|
|
|
|
|
|
if (sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
|
|
|
|
omap_test_timeout((omap_hwmod_read(oh, sysc->syss_offs)
|
|
|
|
& SYSS_RESETDONE_MASK),
|
|
|
|
MAX_MODULE_SOFTRESET_WAIT, c);
|
|
|
|
else if (sysc->sysc_flags & SYSC_HAS_RESET_STATUS) {
|
|
|
|
softrst_mask = (0x1 << sysc->sysc_fields->srst_shift);
|
|
|
|
omap_test_timeout(!(omap_hwmod_read(oh, sysc->sysc_offs)
|
|
|
|
& softrst_mask),
|
|
|
|
MAX_MODULE_SOFTRESET_WAIT, c);
|
|
|
|
}
|
|
|
|
|
|
|
|
return c;
|
|
|
|
}
|
|
|
|
|
2012-07-04 19:09:21 +08:00
|
|
|
/**
|
|
|
|
* _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* The DMADISABLE bit is a semi-automatic bit present in sysconfig register
|
|
|
|
* of some modules. When the DMA must perform read/write accesses, the
|
|
|
|
* DMADISABLE bit is cleared by the hardware. But when the DMA must stop
|
|
|
|
* for power management, software must set the DMADISABLE bit back to 1.
|
|
|
|
*
|
|
|
|
* Set the DMADISABLE bit in @v for hwmod @oh. Returns -EINVAL upon
|
|
|
|
* error or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int _set_dmadisable(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
u32 v;
|
|
|
|
u32 dmadisable_mask;
|
|
|
|
|
|
|
|
if (!oh->class->sysc ||
|
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_DMADISABLE))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* clocks must be on for this operation */
|
|
|
|
if (oh->_state != _HWMOD_STATE_ENABLED) {
|
|
|
|
pr_warn("omap_hwmod: %s: dma can be disabled only from enabled state\n", oh->name);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: setting DMADISABLE\n", oh->name);
|
|
|
|
|
|
|
|
v = oh->_sysc_cache;
|
|
|
|
dmadisable_mask =
|
|
|
|
(0x1 << oh->class->sysc->sysc_fields->dmadisable_shift);
|
|
|
|
v |= dmadisable_mask;
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-09 07:34:15 +08:00
|
|
|
/**
|
|
|
|
* _set_module_autoidle: set the OCP_SYSCONFIG AUTOIDLE field in @v
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @autoidle: desired AUTOIDLE bitfield value (0 or 1)
|
|
|
|
* @v: pointer to register contents to modify
|
|
|
|
*
|
|
|
|
* Update the module autoidle bit in @v to be @autoidle for the @oh
|
|
|
|
* hwmod. The autoidle bit controls whether the module can gate
|
|
|
|
* internal clocks automatically when it isn't doing anything; the
|
|
|
|
* exact function of this bit varies on a per-module basis. This
|
|
|
|
* function does not write to the hardware. Returns -EINVAL upon
|
|
|
|
* error or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int _set_module_autoidle(struct omap_hwmod *oh, u8 autoidle,
|
|
|
|
u32 *v)
|
|
|
|
{
|
2010-02-25 03:05:58 +08:00
|
|
|
u32 autoidle_mask;
|
|
|
|
u8 autoidle_shift;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_AUTOIDLE))
|
2009-12-09 07:34:15 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
2010-02-25 03:05:58 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
autoidle_shift = oh->class->sysc->sysc_fields->autoidle_shift;
|
2011-03-04 05:22:46 +08:00
|
|
|
autoidle_mask = (0x1 << autoidle_shift);
|
2010-02-25 03:05:58 +08:00
|
|
|
|
|
|
|
*v &= ~autoidle_mask;
|
|
|
|
*v |= autoidle << autoidle_shift;
|
2009-12-09 07:34:15 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-17 05:36:58 +08:00
|
|
|
/**
|
|
|
|
* _set_idle_ioring_wakeup - enable/disable IO pad wakeup on hwmod idle for mux
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @set_wake: bool value indicating to set (true) or clear (false) wakeup enable
|
|
|
|
*
|
|
|
|
* Set or clear the I/O pad wakeup flag in the mux entries for the
|
|
|
|
* hwmod @oh. This function changes the @oh->mux->pads_dynamic array
|
|
|
|
* in memory. If the hwmod is currently idled, and the new idle
|
|
|
|
* values don't match the previous ones, this function will also
|
|
|
|
* update the SCM PADCTRL registers. Otherwise, if the hwmod is not
|
|
|
|
* currently idled, this function won't touch the hardware: the new
|
|
|
|
* mux settings are written to the SCM PADCTRL registers when the
|
|
|
|
* hwmod is idled. No return value.
|
|
|
|
*/
|
|
|
|
static void _set_idle_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
|
|
|
|
{
|
|
|
|
struct omap_device_pad *pad;
|
|
|
|
bool change = false;
|
|
|
|
u16 prev_idle;
|
|
|
|
int j;
|
|
|
|
|
|
|
|
if (!oh->mux || !oh->mux->enabled)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (j = 0; j < oh->mux->nr_pads_dynamic; j++) {
|
|
|
|
pad = oh->mux->pads_dynamic[j];
|
|
|
|
|
|
|
|
if (!(pad->flags & OMAP_DEVICE_PAD_WAKEUP))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
prev_idle = pad->idle;
|
|
|
|
|
|
|
|
if (set_wake)
|
|
|
|
pad->idle |= OMAP_WAKEUP_EN;
|
|
|
|
else
|
|
|
|
pad->idle &= ~OMAP_WAKEUP_EN;
|
|
|
|
|
|
|
|
if (prev_idle != pad->idle)
|
|
|
|
change = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (change && oh->_state == _HWMOD_STATE_IDLE)
|
|
|
|
omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
|
|
|
* _enable_wakeup: set OCP_SYSCONFIG.ENAWAKEUP bit in the hardware
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Allow the hardware module @oh to send wakeups. Returns -EINVAL
|
|
|
|
* upon error or 0 upon success.
|
|
|
|
*/
|
OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed
OMAP: hwmod: Enable module wakeup if in smartidle
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22 12:08:34 +08:00
|
|
|
static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
2010-12-22 12:31:28 +08:00
|
|
|
!((oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP) ||
|
2011-07-02 04:54:00 +08:00
|
|
|
(oh->class->sysc->idlemodes & SIDLE_SMART_WKUP) ||
|
|
|
|
(oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)))
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
2010-02-25 03:05:58 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2011-07-02 04:54:03 +08:00
|
|
|
if (oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)
|
|
|
|
*v |= 0x1 << oh->class->sysc->sysc_fields->enwkup_shift;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-12-22 12:31:28 +08:00
|
|
|
if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
|
|
|
|
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
|
2011-07-02 04:54:00 +08:00
|
|
|
if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)
|
|
|
|
_set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
|
2010-12-22 12:31:28 +08:00
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _disable_wakeup: clear OCP_SYSCONFIG.ENAWAKEUP bit in the hardware
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Prevent the hardware module @oh to send wakeups. Returns -EINVAL
|
|
|
|
* upon error or 0 upon success.
|
|
|
|
*/
|
OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed
OMAP: hwmod: Enable module wakeup if in smartidle
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22 12:08:34 +08:00
|
|
|
static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
2010-12-22 12:31:28 +08:00
|
|
|
!((oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP) ||
|
2011-07-02 04:54:00 +08:00
|
|
|
(oh->class->sysc->idlemodes & SIDLE_SMART_WKUP) ||
|
|
|
|
(oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)))
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc->sysc_fields) {
|
|
|
|
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
|
2010-02-25 03:05:58 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2011-07-02 04:54:03 +08:00
|
|
|
if (oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)
|
|
|
|
*v &= ~(0x1 << oh->class->sysc->sysc_fields->enwkup_shift);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-12-22 12:31:28 +08:00
|
|
|
if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
|
|
|
|
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v);
|
2011-07-02 04:54:00 +08:00
|
|
|
if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)
|
2012-06-18 01:57:51 +08:00
|
|
|
_set_master_standbymode(oh, HWMOD_IDLEMODE_SMART, v);
|
2010-12-22 12:31:28 +08:00
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
static struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-04-27 19:02:53 +08:00
|
|
|
struct clk_hw_omap *clk;
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
if (oh->clkdm) {
|
|
|
|
return oh->clkdm;
|
|
|
|
} else if (oh->_clk) {
|
2013-07-12 17:26:41 +08:00
|
|
|
if (__clk_get_flags(oh->_clk) & CLK_IS_BASIC)
|
|
|
|
return NULL;
|
2012-11-11 07:58:41 +08:00
|
|
|
clk = to_clk_hw_omap(__clk_get_hw(oh->_clk));
|
|
|
|
return clk->clkdm;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
|
|
|
* _add_initiator_dep: prevent @oh from smart-idling while @init_oh is active
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Prevent the hardware module @oh from entering idle while the
|
|
|
|
* hardare module initiator @init_oh is active. Useful when a module
|
|
|
|
* will be accessed by a particular initiator (e.g., if a module will
|
|
|
|
* be accessed by the IVA, there should be a sleepdep between the IVA
|
|
|
|
* initiator and the module). Only applies to modules in smart-idle
|
2011-03-10 18:50:09 +08:00
|
|
|
* mode. If the clockdomain is marked as not needing autodeps, return
|
|
|
|
* 0 without doing anything. Otherwise, returns -EINVAL upon error or
|
|
|
|
* passes along clkdm_add_sleepdep() value upon success.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
|
|
|
static int _add_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh)
|
|
|
|
{
|
2012-11-11 07:58:41 +08:00
|
|
|
struct clockdomain *clkdm, *init_clkdm;
|
|
|
|
|
|
|
|
clkdm = _get_clkdm(oh);
|
|
|
|
init_clkdm = _get_clkdm(init_oh);
|
|
|
|
|
|
|
|
if (!clkdm || !init_clkdm)
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
if (clkdm && clkdm->flags & CLKDM_NO_AUTODEPS)
|
2011-03-10 18:50:09 +08:00
|
|
|
return 0;
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
return clkdm_add_sleepdep(clkdm, init_clkdm);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _del_initiator_dep: allow @oh to smart-idle even if @init_oh is active
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Allow the hardware module @oh to enter idle while the hardare
|
|
|
|
* module initiator @init_oh is active. Useful when a module will not
|
|
|
|
* be accessed by a particular initiator (e.g., if a module will not
|
|
|
|
* be accessed by the IVA, there should be no sleepdep between the IVA
|
|
|
|
* initiator and the module). Only applies to modules in smart-idle
|
2011-03-10 18:50:09 +08:00
|
|
|
* mode. If the clockdomain is marked as not needing autodeps, return
|
|
|
|
* 0 without doing anything. Returns -EINVAL upon error or passes
|
|
|
|
* along clkdm_del_sleepdep() value upon success.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
|
|
|
static int _del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh)
|
|
|
|
{
|
2012-11-11 07:58:41 +08:00
|
|
|
struct clockdomain *clkdm, *init_clkdm;
|
|
|
|
|
|
|
|
clkdm = _get_clkdm(oh);
|
|
|
|
init_clkdm = _get_clkdm(init_oh);
|
|
|
|
|
|
|
|
if (!clkdm || !init_clkdm)
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
if (clkdm && clkdm->flags & CLKDM_NO_AUTODEPS)
|
2011-03-10 18:50:09 +08:00
|
|
|
return 0;
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
return clkdm_del_sleepdep(clkdm, init_clkdm);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _init_main_clk - get a struct clk * for the the hwmod's main functional clk
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Called from _init_clocks(). Populates the @oh _clk (main
|
|
|
|
* functional clock pointer) if a main_clk is present. Returns 0 on
|
|
|
|
* success or -EINVAL on error.
|
|
|
|
*/
|
|
|
|
static int _init_main_clk(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2010-02-23 13:09:31 +08:00
|
|
|
if (!oh->main_clk)
|
2009-09-04 01:14:03 +08:00
|
|
|
return 0;
|
|
|
|
|
2012-09-22 16:24:16 +08:00
|
|
|
oh->_clk = clk_get(NULL, oh->main_clk);
|
|
|
|
if (IS_ERR(oh->_clk)) {
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: cannot clk_get main_clk %s\n",
|
|
|
|
oh->name, oh->main_clk);
|
2010-05-21 02:31:10 +08:00
|
|
|
return -EINVAL;
|
2010-06-24 08:15:12 +08:00
|
|
|
}
|
2012-09-22 16:24:16 +08:00
|
|
|
/*
|
|
|
|
* HACK: This needs a re-visit once clk_prepare() is implemented
|
|
|
|
* to do something meaningful. Today its just a no-op.
|
|
|
|
* If clk_prepare() is used at some point to do things like
|
|
|
|
* voltage scaling etc, then this would have to be moved to
|
|
|
|
* some point where subsystems like i2c and pmic become
|
|
|
|
* available.
|
|
|
|
*/
|
|
|
|
clk_prepare(oh->_clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
if (!_get_clkdm(oh))
|
2012-09-24 07:28:18 +08:00
|
|
|
pr_debug("omap_hwmod: %s: missing clockdomain for %s.\n",
|
2012-09-22 16:24:17 +08:00
|
|
|
oh->name, oh->main_clk);
|
2009-12-09 07:34:24 +08:00
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2010-07-27 06:34:33 +08:00
|
|
|
* _init_interface_clks - get a struct clk * for the the hwmod's interface clks
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Called from _init_clocks(). Populates the @oh OCP slave interface
|
|
|
|
* clock pointers. Returns 0 on success or -EINVAL on error.
|
|
|
|
*/
|
|
|
|
static int _init_interface_clks(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-04-19 18:04:28 +08:00
|
|
|
struct omap_hwmod_ocp_if *os;
|
2012-04-19 18:04:32 +08:00
|
|
|
struct list_head *p;
|
2009-09-04 01:14:03 +08:00
|
|
|
struct clk *c;
|
2012-04-19 18:04:28 +08:00
|
|
|
int i = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
p = oh->slave_ports.next;
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
while (i < oh->slaves_cnt) {
|
2012-04-19 18:04:32 +08:00
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
2010-02-23 13:09:31 +08:00
|
|
|
if (!os->clk)
|
2009-09-04 01:14:03 +08:00
|
|
|
continue;
|
|
|
|
|
2012-09-22 16:24:16 +08:00
|
|
|
c = clk_get(NULL, os->clk);
|
|
|
|
if (IS_ERR(c)) {
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: cannot clk_get interface_clk %s\n",
|
|
|
|
oh->name, os->clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
ret = -EINVAL;
|
2013-12-09 09:39:03 +08:00
|
|
|
continue;
|
2010-06-24 08:15:12 +08:00
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
os->_clk = c;
|
2012-09-22 16:24:16 +08:00
|
|
|
/*
|
|
|
|
* HACK: This needs a re-visit once clk_prepare() is implemented
|
|
|
|
* to do something meaningful. Today its just a no-op.
|
|
|
|
* If clk_prepare() is used at some point to do things like
|
|
|
|
* voltage scaling etc, then this would have to be moved to
|
|
|
|
* some point where subsystems like i2c and pmic become
|
|
|
|
* available.
|
|
|
|
*/
|
|
|
|
clk_prepare(os->_clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _init_opt_clk - get a struct clk * for the the hwmod's optional clocks
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Called from _init_clocks(). Populates the @oh omap_hwmod_opt_clk
|
|
|
|
* clock pointers. Returns 0 on success or -EINVAL on error.
|
|
|
|
*/
|
|
|
|
static int _init_opt_clks(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_opt_clk *oc;
|
|
|
|
struct clk *c;
|
|
|
|
int i;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
|
2012-09-22 16:24:16 +08:00
|
|
|
c = clk_get(NULL, oc->clk);
|
|
|
|
if (IS_ERR(c)) {
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: cannot clk_get opt_clk %s\n",
|
|
|
|
oh->name, oc->clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
ret = -EINVAL;
|
2013-12-09 09:39:03 +08:00
|
|
|
continue;
|
2010-06-24 08:15:12 +08:00
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
oc->_clk = c;
|
2012-09-22 16:24:16 +08:00
|
|
|
/*
|
|
|
|
* HACK: This needs a re-visit once clk_prepare() is implemented
|
|
|
|
* to do something meaningful. Today its just a no-op.
|
|
|
|
* If clk_prepare() is used at some point to do things like
|
|
|
|
* voltage scaling etc, then this would have to be moved to
|
|
|
|
* some point where subsystems like i2c and pmic become
|
|
|
|
* available.
|
|
|
|
*/
|
|
|
|
clk_prepare(oc->_clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _enable_clocks - enable hwmod main clock and interface clocks
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Enables all clocks necessary for register reads and writes to succeed
|
|
|
|
* on the hwmod @oh. Returns 0.
|
|
|
|
*/
|
|
|
|
static int _enable_clocks(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-04-19 18:04:28 +08:00
|
|
|
struct omap_hwmod_ocp_if *os;
|
2012-04-19 18:04:32 +08:00
|
|
|
struct list_head *p;
|
2012-04-19 18:04:28 +08:00
|
|
|
int i = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: enabling clocks\n", oh->name);
|
|
|
|
|
2010-05-21 02:31:09 +08:00
|
|
|
if (oh->_clk)
|
2009-09-04 01:14:03 +08:00
|
|
|
clk_enable(oh->_clk);
|
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
p = oh->slave_ports.next;
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
while (i < oh->slaves_cnt) {
|
2012-04-19 18:04:32 +08:00
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE))
|
|
|
|
clk_enable(os->_clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The opt clocks are controlled by the device driver. */
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _disable_clocks - disable hwmod main clock and interface clocks
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Disables the hwmod @oh main functional and interface clocks. Returns 0.
|
|
|
|
*/
|
|
|
|
static int _disable_clocks(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-04-19 18:04:28 +08:00
|
|
|
struct omap_hwmod_ocp_if *os;
|
2012-04-19 18:04:32 +08:00
|
|
|
struct list_head *p;
|
2012-04-19 18:04:28 +08:00
|
|
|
int i = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: disabling clocks\n", oh->name);
|
|
|
|
|
2010-05-21 02:31:09 +08:00
|
|
|
if (oh->_clk)
|
2009-09-04 01:14:03 +08:00
|
|
|
clk_disable(oh->_clk);
|
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
p = oh->slave_ports.next;
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
while (i < oh->slaves_cnt) {
|
2012-04-19 18:04:32 +08:00
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE))
|
|
|
|
clk_disable(os->_clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The opt clocks are controlled by the device driver. */
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-09-22 00:57:58 +08:00
|
|
|
static void _enable_optional_clocks(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_opt_clk *oc;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: enabling optional clocks\n", oh->name);
|
|
|
|
|
|
|
|
for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
|
|
|
|
if (oc->_clk) {
|
|
|
|
pr_debug("omap_hwmod: enable %s:%s\n", oc->role,
|
2012-09-22 16:24:17 +08:00
|
|
|
__clk_get_name(oc->_clk));
|
2010-09-22 00:57:58 +08:00
|
|
|
clk_enable(oc->_clk);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void _disable_optional_clocks(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_opt_clk *oc;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: disabling optional clocks\n", oh->name);
|
|
|
|
|
|
|
|
for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
|
|
|
|
if (oc->_clk) {
|
|
|
|
pr_debug("omap_hwmod: disable %s:%s\n", oc->role,
|
2012-09-22 16:24:17 +08:00
|
|
|
__clk_get_name(oc->_clk));
|
2010-09-22 00:57:58 +08:00
|
|
|
clk_disable(oc->_clk);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-07-10 19:56:33 +08:00
|
|
|
/**
|
2012-06-19 02:12:23 +08:00
|
|
|
* _omap4_enable_module - enable CLKCTRL modulemode on OMAP4
|
2011-07-10 19:56:33 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Enables the PRCM module mode related to the hwmod @oh.
|
|
|
|
* No return value.
|
|
|
|
*/
|
2012-06-19 02:12:23 +08:00
|
|
|
static void _omap4_enable_module(struct omap_hwmod *oh)
|
2011-07-10 19:56:33 +08:00
|
|
|
{
|
|
|
|
if (!oh->clkdm || !oh->prcm.omap4.modulemode)
|
|
|
|
return;
|
|
|
|
|
2012-06-19 02:12:23 +08:00
|
|
|
pr_debug("omap_hwmod: %s: %s: %d\n",
|
|
|
|
oh->name, __func__, oh->prcm.omap4.modulemode);
|
2011-07-10 19:56:33 +08:00
|
|
|
|
2014-10-27 23:39:24 +08:00
|
|
|
omap_cm_module_enable(oh->prcm.omap4.modulemode,
|
|
|
|
oh->clkdm->prcm_partition,
|
|
|
|
oh->clkdm->cm_inst, oh->prcm.omap4.clkctrl_offs);
|
2012-09-12 07:18:53 +08:00
|
|
|
}
|
|
|
|
|
2011-07-10 19:56:33 +08:00
|
|
|
/**
|
2011-12-17 08:09:11 +08:00
|
|
|
* _omap4_wait_target_disable - wait for a module to be disabled on OMAP4
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Wait for a module @oh to enter slave idle. Returns 0 if the module
|
|
|
|
* does not have an IDLEST bit or if the module successfully enters
|
|
|
|
* slave idle; otherwise, pass along the return value of the
|
|
|
|
* appropriate *_cm*_wait_module_idle() function.
|
|
|
|
*/
|
|
|
|
static int _omap4_wait_target_disable(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-09-24 07:28:18 +08:00
|
|
|
if (!oh)
|
2011-12-17 08:09:11 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2012-09-24 07:28:18 +08:00
|
|
|
if (oh->_int_flags & _HWMOD_NO_MPU_PORT || !oh->clkdm)
|
2011-12-17 08:09:11 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (oh->flags & HWMOD_NO_IDLEST)
|
|
|
|
return 0;
|
|
|
|
|
2014-10-27 23:39:23 +08:00
|
|
|
return omap_cm_wait_module_idle(oh->clkdm->prcm_partition,
|
|
|
|
oh->clkdm->cm_inst,
|
|
|
|
oh->prcm.omap4.clkctrl_offs, 0);
|
2012-09-12 07:18:53 +08:00
|
|
|
}
|
|
|
|
|
2011-07-10 09:14:06 +08:00
|
|
|
/**
|
|
|
|
* _count_mpu_irqs - count the number of MPU IRQ lines associated with @oh
|
|
|
|
* @oh: struct omap_hwmod *oh
|
|
|
|
*
|
|
|
|
* Count and return the number of MPU IRQs associated with the hwmod
|
|
|
|
* @oh. Used to allocate struct resource data. Returns 0 if @oh is
|
|
|
|
* NULL.
|
|
|
|
*/
|
|
|
|
static int _count_mpu_irqs(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_irq_info *ohii;
|
|
|
|
int i = 0;
|
|
|
|
|
|
|
|
if (!oh || !oh->mpu_irqs)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
do {
|
|
|
|
ohii = &oh->mpu_irqs[i++];
|
|
|
|
} while (ohii->irq != -1);
|
|
|
|
|
2011-11-24 06:35:07 +08:00
|
|
|
return i-1;
|
2011-07-10 09:14:06 +08:00
|
|
|
}
|
|
|
|
|
2011-07-10 09:14:07 +08:00
|
|
|
/**
|
|
|
|
* _count_sdma_reqs - count the number of SDMA request lines associated with @oh
|
|
|
|
* @oh: struct omap_hwmod *oh
|
|
|
|
*
|
|
|
|
* Count and return the number of SDMA request lines associated with
|
|
|
|
* the hwmod @oh. Used to allocate struct resource data. Returns 0
|
|
|
|
* if @oh is NULL.
|
|
|
|
*/
|
|
|
|
static int _count_sdma_reqs(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_dma_info *ohdi;
|
|
|
|
int i = 0;
|
|
|
|
|
|
|
|
if (!oh || !oh->sdma_reqs)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
do {
|
|
|
|
ohdi = &oh->sdma_reqs[i++];
|
|
|
|
} while (ohdi->dma_req != -1);
|
|
|
|
|
2011-11-24 06:35:07 +08:00
|
|
|
return i-1;
|
2011-07-10 09:14:07 +08:00
|
|
|
}
|
|
|
|
|
2011-07-10 09:14:05 +08:00
|
|
|
/**
|
|
|
|
* _count_ocp_if_addr_spaces - count the number of address space entries for @oh
|
|
|
|
* @oh: struct omap_hwmod *oh
|
|
|
|
*
|
|
|
|
* Count and return the number of address space ranges associated with
|
|
|
|
* the hwmod @oh. Used to allocate struct resource data. Returns 0
|
|
|
|
* if @oh is NULL.
|
|
|
|
*/
|
|
|
|
static int _count_ocp_if_addr_spaces(struct omap_hwmod_ocp_if *os)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_addr_space *mem;
|
|
|
|
int i = 0;
|
|
|
|
|
|
|
|
if (!os || !os->addr)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
do {
|
|
|
|
mem = &os->addr[i++];
|
|
|
|
} while (mem->pa_start != mem->pa_end);
|
|
|
|
|
2011-11-24 06:35:07 +08:00
|
|
|
return i-1;
|
2011-07-10 09:14:05 +08:00
|
|
|
}
|
|
|
|
|
2012-04-19 09:10:06 +08:00
|
|
|
/**
|
|
|
|
* _get_mpu_irq_by_name - fetch MPU interrupt line number by name
|
|
|
|
* @oh: struct omap_hwmod * to operate on
|
|
|
|
* @name: pointer to the name of the MPU interrupt number to fetch (optional)
|
|
|
|
* @irq: pointer to an unsigned int to store the MPU IRQ number to
|
|
|
|
*
|
|
|
|
* Retrieve a MPU hardware IRQ line number named by @name associated
|
|
|
|
* with the IP block pointed to by @oh. The IRQ number will be filled
|
|
|
|
* into the address pointed to by @dma. When @name is non-null, the
|
|
|
|
* IRQ line number associated with the named entry will be returned.
|
|
|
|
* If @name is null, the first matching entry will be returned. Data
|
|
|
|
* order is not meaningful in hwmod data, so callers are strongly
|
|
|
|
* encouraged to use a non-null @name whenever possible to avoid
|
|
|
|
* unpredictable effects if hwmod data is later added that causes data
|
|
|
|
* ordering to change. Returns 0 upon success or a negative error
|
|
|
|
* code upon error.
|
|
|
|
*/
|
|
|
|
static int _get_mpu_irq_by_name(struct omap_hwmod *oh, const char *name,
|
|
|
|
unsigned int *irq)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
if (!oh->mpu_irqs)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
while (oh->mpu_irqs[i].irq != -1) {
|
|
|
|
if (name == oh->mpu_irqs[i].name ||
|
|
|
|
!strcmp(name, oh->mpu_irqs[i].name)) {
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!found)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
*irq = oh->mpu_irqs[i].irq;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _get_sdma_req_by_name - fetch SDMA request line ID by name
|
|
|
|
* @oh: struct omap_hwmod * to operate on
|
|
|
|
* @name: pointer to the name of the SDMA request line to fetch (optional)
|
|
|
|
* @dma: pointer to an unsigned int to store the request line ID to
|
|
|
|
*
|
|
|
|
* Retrieve an SDMA request line ID named by @name on the IP block
|
|
|
|
* pointed to by @oh. The ID will be filled into the address pointed
|
|
|
|
* to by @dma. When @name is non-null, the request line ID associated
|
|
|
|
* with the named entry will be returned. If @name is null, the first
|
|
|
|
* matching entry will be returned. Data order is not meaningful in
|
|
|
|
* hwmod data, so callers are strongly encouraged to use a non-null
|
|
|
|
* @name whenever possible to avoid unpredictable effects if hwmod
|
|
|
|
* data is later added that causes data ordering to change. Returns 0
|
|
|
|
* upon success or a negative error code upon error.
|
|
|
|
*/
|
|
|
|
static int _get_sdma_req_by_name(struct omap_hwmod *oh, const char *name,
|
|
|
|
unsigned int *dma)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
if (!oh->sdma_reqs)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
while (oh->sdma_reqs[i].dma_req != -1) {
|
|
|
|
if (name == oh->sdma_reqs[i].name ||
|
|
|
|
!strcmp(name, oh->sdma_reqs[i].name)) {
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!found)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
*dma = oh->sdma_reqs[i].dma_req;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _get_addr_space_by_name - fetch address space start & end by name
|
|
|
|
* @oh: struct omap_hwmod * to operate on
|
|
|
|
* @name: pointer to the name of the address space to fetch (optional)
|
|
|
|
* @pa_start: pointer to a u32 to store the starting address to
|
|
|
|
* @pa_end: pointer to a u32 to store the ending address to
|
|
|
|
*
|
|
|
|
* Retrieve address space start and end addresses for the IP block
|
|
|
|
* pointed to by @oh. The data will be filled into the addresses
|
|
|
|
* pointed to by @pa_start and @pa_end. When @name is non-null, the
|
|
|
|
* address space data associated with the named entry will be
|
|
|
|
* returned. If @name is null, the first matching entry will be
|
|
|
|
* returned. Data order is not meaningful in hwmod data, so callers
|
|
|
|
* are strongly encouraged to use a non-null @name whenever possible
|
|
|
|
* to avoid unpredictable effects if hwmod data is later added that
|
|
|
|
* causes data ordering to change. Returns 0 upon success or a
|
|
|
|
* negative error code upon error.
|
|
|
|
*/
|
|
|
|
static int _get_addr_space_by_name(struct omap_hwmod *oh, const char *name,
|
|
|
|
u32 *pa_start, u32 *pa_end)
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
struct omap_hwmod_ocp_if *os;
|
2012-04-19 18:04:30 +08:00
|
|
|
struct list_head *p = NULL;
|
2012-04-19 09:10:06 +08:00
|
|
|
bool found = false;
|
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
p = oh->slave_ports.next;
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
i = 0;
|
|
|
|
while (i < oh->slaves_cnt) {
|
2012-04-19 18:04:32 +08:00
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
2012-04-19 09:10:06 +08:00
|
|
|
|
|
|
|
if (!os->addr)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
j = 0;
|
|
|
|
while (os->addr[j].pa_start != os->addr[j].pa_end) {
|
|
|
|
if (name == os->addr[j].name ||
|
|
|
|
!strcmp(name, os->addr[j].name)) {
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!found)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
*pa_start = os->addr[j].pa_start;
|
|
|
|
*pa_end = os->addr[j].pa_end;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
2012-04-19 18:04:29 +08:00
|
|
|
* _save_mpu_port_index - find and save the index to @oh's MPU port
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2012-04-19 18:04:29 +08:00
|
|
|
* Determines the array index of the OCP slave port that the MPU uses
|
|
|
|
* to address the device, and saves it into the struct omap_hwmod.
|
|
|
|
* Intended to be called during hwmod registration only. No return
|
|
|
|
* value.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
2012-04-19 18:04:29 +08:00
|
|
|
static void __init _save_mpu_port_index(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2012-04-19 18:04:29 +08:00
|
|
|
struct omap_hwmod_ocp_if *os = NULL;
|
2012-04-19 18:04:32 +08:00
|
|
|
struct list_head *p;
|
2012-04-19 18:04:28 +08:00
|
|
|
int i = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
if (!oh)
|
2012-04-19 18:04:29 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
oh->_int_flags |= _HWMOD_NO_MPU_PORT;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
p = oh->slave_ports.next;
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
while (i < oh->slaves_cnt) {
|
2012-04-19 18:04:32 +08:00
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
2009-09-04 01:14:03 +08:00
|
|
|
if (os->user & OCP_USER_MPU) {
|
2012-04-19 18:04:30 +08:00
|
|
|
oh->_mpu_port = os;
|
2012-04-19 18:04:29 +08:00
|
|
|
oh->_int_flags &= ~_HWMOD_NO_MPU_PORT;
|
2009-09-04 01:14:03 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-19 18:04:29 +08:00
|
|
|
return;
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
2012-04-19 18:04:27 +08:00
|
|
|
/**
|
|
|
|
* _find_mpu_rt_port - return omap_hwmod_ocp_if accessible by the MPU
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Given a pointer to a struct omap_hwmod record @oh, return a pointer
|
|
|
|
* to the struct omap_hwmod_ocp_if record that is used by the MPU to
|
|
|
|
* communicate with the IP block. This interface need not be directly
|
|
|
|
* connected to the MPU (and almost certainly is not), but is directly
|
|
|
|
* connected to the IP block represented by @oh. Returns a pointer
|
|
|
|
* to the struct omap_hwmod_ocp_if * upon success, or returns NULL upon
|
|
|
|
* error or if there does not appear to be a path from the MPU to this
|
|
|
|
* IP block.
|
|
|
|
*/
|
|
|
|
static struct omap_hwmod_ocp_if *_find_mpu_rt_port(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
if (!oh || oh->_int_flags & _HWMOD_NO_MPU_PORT || oh->slaves_cnt == 0)
|
|
|
|
return NULL;
|
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
return oh->_mpu_port;
|
2012-04-19 18:04:27 +08:00
|
|
|
};
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
2012-04-19 09:10:05 +08:00
|
|
|
* _find_mpu_rt_addr_space - return MPU register target address space for @oh
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2012-04-19 09:10:05 +08:00
|
|
|
* Returns a pointer to the struct omap_hwmod_addr_space record representing
|
|
|
|
* the register target MPU address space; or returns NULL upon error.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
2012-04-19 09:10:05 +08:00
|
|
|
static struct omap_hwmod_addr_space * __init _find_mpu_rt_addr_space(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
|
|
|
struct omap_hwmod_ocp_if *os;
|
|
|
|
struct omap_hwmod_addr_space *mem;
|
2012-04-19 09:10:05 +08:00
|
|
|
int found = 0, i = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 18:04:27 +08:00
|
|
|
os = _find_mpu_rt_port(oh);
|
2012-04-19 18:04:29 +08:00
|
|
|
if (!os || !os->addr)
|
2011-07-10 09:14:05 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
do {
|
|
|
|
mem = &os->addr[i++];
|
|
|
|
if (mem->flags & ADDR_TYPE_RT)
|
2009-09-04 01:14:03 +08:00
|
|
|
found = 1;
|
2011-07-10 09:14:05 +08:00
|
|
|
} while (!found && mem->pa_start != mem->pa_end);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 09:10:05 +08:00
|
|
|
return (found) ? mem : NULL;
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2010-09-22 05:02:23 +08:00
|
|
|
* _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive. If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled. The
WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx,
no OCP header existed on the 32k sync timer.) Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch. Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-07-04 19:22:53 +08:00
|
|
|
* Ensure that the OCP_SYSCONFIG register for the IP block represented
|
|
|
|
* by @oh is set to indicate to the PRCM that the IP block is active.
|
|
|
|
* Usually this means placing the module into smart-idle mode and
|
|
|
|
* smart-standby, but if there is a bug in the automatic idle handling
|
|
|
|
* for the IP block, it may need to be placed into the force-idle or
|
|
|
|
* no-idle variants of these modes. No return value.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
2010-09-22 05:02:23 +08:00
|
|
|
static void _enable_sysc(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2010-02-23 13:09:34 +08:00
|
|
|
u8 idlemode, sf;
|
2009-09-04 01:14:03 +08:00
|
|
|
u32 v;
|
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive. If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled. The
WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx,
no OCP header existed on the 32k sync timer.) Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch. Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-07-04 19:22:53 +08:00
|
|
|
bool clkdm_act;
|
2012-11-11 07:58:41 +08:00
|
|
|
struct clockdomain *clkdm;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc)
|
2009-09-04 01:14:03 +08:00
|
|
|
return;
|
|
|
|
|
2012-10-30 12:02:13 +08:00
|
|
|
/*
|
|
|
|
* Wait until reset has completed, this is needed as the IP
|
|
|
|
* block is reset automatically by hardware in some cases
|
|
|
|
* (off-mode for example), and the drivers require the
|
|
|
|
* IP to be ready when they access it
|
|
|
|
*/
|
|
|
|
if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
|
|
|
|
_enable_optional_clocks(oh);
|
|
|
|
_wait_softreset_complete(oh);
|
|
|
|
if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
|
|
|
|
_disable_optional_clocks(oh);
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
v = oh->_sysc_cache;
|
2010-02-23 13:09:34 +08:00
|
|
|
sf = oh->class->sysc->sysc_flags;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
clkdm = _get_clkdm(oh);
|
2010-02-23 13:09:34 +08:00
|
|
|
if (sf & SYSC_HAS_SIDLEMODE) {
|
2013-05-15 22:48:38 +08:00
|
|
|
if (oh->flags & HWMOD_SWSUP_SIDLE ||
|
|
|
|
oh->flags & HWMOD_SWSUP_SIDLE_ACT) {
|
2013-05-15 22:48:37 +08:00
|
|
|
idlemode = HWMOD_IDLEMODE_NO;
|
|
|
|
} else {
|
|
|
|
if (sf & SYSC_HAS_ENAWAKEUP)
|
|
|
|
_enable_wakeup(oh, &v);
|
|
|
|
if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART_WKUP;
|
|
|
|
else
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is special handling for some IPs like
|
|
|
|
* 32k sync timer. Force them to idle!
|
|
|
|
*/
|
2012-11-11 07:58:41 +08:00
|
|
|
clkdm_act = (clkdm && clkdm->flags & CLKDM_ACTIVE_WITH_MPU);
|
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive. If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled. The
WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx,
no OCP header existed on the 32k sync timer.) Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch. Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-07-04 19:22:53 +08:00
|
|
|
if (clkdm_act && !(oh->class->sysc->idlemodes &
|
|
|
|
(SIDLE_SMART | SIDLE_SMART_WKUP)))
|
|
|
|
idlemode = HWMOD_IDLEMODE_FORCE;
|
2013-05-15 22:48:37 +08:00
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
_set_slave_idlemode(oh, idlemode, &v);
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (sf & SYSC_HAS_MIDLEMODE) {
|
2013-03-12 03:49:00 +08:00
|
|
|
if (oh->flags & HWMOD_FORCE_MSTANDBY) {
|
|
|
|
idlemode = HWMOD_IDLEMODE_FORCE;
|
|
|
|
} else if (oh->flags & HWMOD_SWSUP_MSTANDBY) {
|
2011-07-02 04:54:00 +08:00
|
|
|
idlemode = HWMOD_IDLEMODE_NO;
|
|
|
|
} else {
|
|
|
|
if (sf & SYSC_HAS_ENAWAKEUP)
|
|
|
|
_enable_wakeup(oh, &v);
|
|
|
|
if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART_WKUP;
|
|
|
|
else
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART;
|
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
_set_master_standbymode(oh, idlemode, &v);
|
|
|
|
}
|
|
|
|
|
OMAP3 hwmod: drop most of the OCP_SYSCONFIG.CLOCKACTIVITY code
Earlier, the hwmod code had considered the OCP_SYSCONFIG.CLOCKACTIVITY
bits to be incremental power saving bits, controlling internal IP
block clock gates. This was a misapprehension. The CLOCKACTIVITY
bits are used to indicate, in advance, which clocks will be cut when
the module acknowledges an idle request. This enables the IP block to
take whatever action is necessary to complete any in-progress work
before asserting its IdleAck.
In the current Linux-OMAP code, this implies that the clock framework
should be changing module CLOCKACTIVITY bits as module clocks are enabled
and disabled. We don't do that yet, but in the future, we should.
This must wait until the clock tree is annotated with omap_hwmod pointers
(or vice-versa). In the meantime, drop most of the hwmod code that
controls CLOCKACTIVITY bits to avoid confusion.
This patch has benefited from many illuminating discussions with (in
alphabetical order) Benoît Cousson <b-cousson@ti.com>, Rajendra Nayak
<rnayak@ti.com>, and Sebastien Sabatier <s-sabatier1@ti.com>.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Sebastien Sabatier <s-sabatier1@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2009-12-09 07:34:17 +08:00
|
|
|
/*
|
|
|
|
* XXX The clock framework should handle this, by
|
|
|
|
* calling into this code. But this must wait until the
|
|
|
|
* clock structures are tagged with omap_hwmod entries
|
|
|
|
*/
|
2010-02-23 13:09:34 +08:00
|
|
|
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
|
|
|
|
(sf & SYSC_HAS_CLOCKACTIVITY))
|
|
|
|
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
ARM: OMAP2+: Only write the sysconfig on idle when necessary
Currently, whenever we idle a device _idle_sysc() is called and writes to the
devices SYSCONFIG register to set the idle mode. A lot devices are using the
smart-idle mode and so the write to the SYSCONFIG register is programming the
same value that is already stored in the register.
Writes to the devices SYSCONFIG register can be slow, for example, writing to
the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional
clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can
take ~100us.
Furthermore, during boot on an OMAP4430 panda board, I see that there are 100
calls to _idle_sysc(), however, only 3 out of the 100 calls actually write
the SYSCONFIG register with a new value.
Therefore, to avoid unnecessary writes to device SYSCONFIG registers when
idling the device, only write the value if the value has changed. It should be
safe to do this on idle as the context of the register will never be lost while
the device is active.
Verified that suspend, CORE off and retention states are working with this
change on OMAP3430 Beagle board.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2013-08-23 18:40:23 +08:00
|
|
|
/* If the cached value is the same as the new value, skip the write */
|
|
|
|
if (oh->_sysc_cache != v)
|
|
|
|
_write_sysconfig(v, oh);
|
2010-09-25 00:23:19 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the autoidle bit only after setting the smartidle bit
|
|
|
|
* Setting this will not have any impact on the other modules.
|
|
|
|
*/
|
|
|
|
if (sf & SYSC_HAS_AUTOIDLE) {
|
|
|
|
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
|
|
|
|
0 : 1;
|
|
|
|
_set_module_autoidle(oh, idlemode, &v);
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2010-09-22 05:02:23 +08:00
|
|
|
* _idle_sysc - try to put a module into idle via OCP_SYSCONFIG
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* If module is marked as SWSUP_SIDLE, force the module into slave
|
|
|
|
* idle; otherwise, configure it for smart-idle. If module is marked
|
|
|
|
* as SWSUP_MSUSPEND, force the module into master standby; otherwise,
|
|
|
|
* configure it for smart-standby. No return value.
|
|
|
|
*/
|
2010-09-22 05:02:23 +08:00
|
|
|
static void _idle_sysc(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2010-02-23 13:09:34 +08:00
|
|
|
u8 idlemode, sf;
|
2009-09-04 01:14:03 +08:00
|
|
|
u32 v;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc)
|
2009-09-04 01:14:03 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
v = oh->_sysc_cache;
|
2010-02-23 13:09:34 +08:00
|
|
|
sf = oh->class->sysc->sysc_flags;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (sf & SYSC_HAS_SIDLEMODE) {
|
2013-05-15 22:48:37 +08:00
|
|
|
if (oh->flags & HWMOD_SWSUP_SIDLE) {
|
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive. If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled. The
WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx,
no OCP header existed on the 32k sync timer.) Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch. Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-07-04 19:22:53 +08:00
|
|
|
idlemode = HWMOD_IDLEMODE_FORCE;
|
2013-05-15 22:48:37 +08:00
|
|
|
} else {
|
|
|
|
if (sf & SYSC_HAS_ENAWAKEUP)
|
|
|
|
_enable_wakeup(oh, &v);
|
|
|
|
if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART_WKUP;
|
|
|
|
else
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART;
|
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
_set_slave_idlemode(oh, idlemode, &v);
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (sf & SYSC_HAS_MIDLEMODE) {
|
2013-03-12 03:49:00 +08:00
|
|
|
if ((oh->flags & HWMOD_SWSUP_MSTANDBY) ||
|
|
|
|
(oh->flags & HWMOD_FORCE_MSTANDBY)) {
|
2011-07-02 04:54:00 +08:00
|
|
|
idlemode = HWMOD_IDLEMODE_FORCE;
|
|
|
|
} else {
|
|
|
|
if (sf & SYSC_HAS_ENAWAKEUP)
|
|
|
|
_enable_wakeup(oh, &v);
|
|
|
|
if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART_WKUP;
|
|
|
|
else
|
|
|
|
idlemode = HWMOD_IDLEMODE_SMART;
|
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
_set_master_standbymode(oh, idlemode, &v);
|
|
|
|
}
|
|
|
|
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2010-09-22 05:02:23 +08:00
|
|
|
* _shutdown_sysc - force a module into idle via OCP_SYSCONFIG
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Force the module into slave idle and master suspend. No return
|
|
|
|
* value.
|
|
|
|
*/
|
2010-09-22 05:02:23 +08:00
|
|
|
static void _shutdown_sysc(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
|
|
|
u32 v;
|
2010-02-23 13:09:34 +08:00
|
|
|
u8 sf;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc)
|
2009-09-04 01:14:03 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
v = oh->_sysc_cache;
|
2010-02-23 13:09:34 +08:00
|
|
|
sf = oh->class->sysc->sysc_flags;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (sf & SYSC_HAS_SIDLEMODE)
|
2009-09-04 01:14:03 +08:00
|
|
|
_set_slave_idlemode(oh, HWMOD_IDLEMODE_FORCE, &v);
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (sf & SYSC_HAS_MIDLEMODE)
|
2009-09-04 01:14:03 +08:00
|
|
|
_set_master_standbymode(oh, HWMOD_IDLEMODE_FORCE, &v);
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (sf & SYSC_HAS_AUTOIDLE)
|
2009-12-09 07:34:15 +08:00
|
|
|
_set_module_autoidle(oh, 1, &v);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _lookup - find an omap_hwmod by name
|
|
|
|
* @name: find an omap_hwmod by name
|
|
|
|
*
|
|
|
|
* Return a pointer to an omap_hwmod by name, or NULL if not found.
|
|
|
|
*/
|
|
|
|
static struct omap_hwmod *_lookup(const char *name)
|
|
|
|
{
|
|
|
|
struct omap_hwmod *oh, *temp_oh;
|
|
|
|
|
|
|
|
oh = NULL;
|
|
|
|
|
|
|
|
list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
|
|
|
|
if (!strcmp(name, temp_oh->name)) {
|
|
|
|
oh = temp_oh;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return oh;
|
|
|
|
}
|
2012-06-20 05:01:02 +08:00
|
|
|
|
2011-07-10 19:56:30 +08:00
|
|
|
/**
|
|
|
|
* _init_clkdm - look up a clockdomain name, store pointer in omap_hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Convert a clockdomain name stored in a struct omap_hwmod into a
|
|
|
|
* clockdomain pointer, and save it into the struct omap_hwmod.
|
2012-06-20 05:01:02 +08:00
|
|
|
* Return -EINVAL if the clkdm_name lookup failed.
|
2011-07-10 19:56:30 +08:00
|
|
|
*/
|
|
|
|
static int _init_clkdm(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-09-24 07:28:18 +08:00
|
|
|
if (!oh->clkdm_name) {
|
|
|
|
pr_debug("omap_hwmod: %s: missing clockdomain\n", oh->name);
|
2011-07-10 19:56:30 +08:00
|
|
|
return 0;
|
2012-09-24 07:28:18 +08:00
|
|
|
}
|
2011-07-10 19:56:30 +08:00
|
|
|
|
|
|
|
oh->clkdm = clkdm_lookup(oh->clkdm_name);
|
|
|
|
if (!oh->clkdm) {
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: could not associate to clkdm %s\n",
|
2011-07-10 19:56:30 +08:00
|
|
|
oh->name, oh->clkdm_name);
|
2013-07-17 23:03:25 +08:00
|
|
|
return 0;
|
2011-07-10 19:56:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: associated to clkdm %s\n",
|
|
|
|
oh->name, oh->clkdm_name);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
/**
|
2011-07-10 19:56:30 +08:00
|
|
|
* _init_clocks - clk_get() all clocks associated with this hwmod. Retrieve as
|
|
|
|
* well the clockdomain.
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
2010-07-27 06:34:30 +08:00
|
|
|
* @data: not used; pass NULL
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
2011-02-23 15:14:07 +08:00
|
|
|
* Called by omap_hwmod_setup_*() (after omap2_clk_init()).
|
2011-02-23 15:14:07 +08:00
|
|
|
* Resolves all clock names embedded in the hwmod. Returns 0 on
|
|
|
|
* success, or a negative error code on failure.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
2010-07-27 06:34:30 +08:00
|
|
|
static int _init_clocks(struct omap_hwmod *oh, void *data)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2011-02-23 15:14:07 +08:00
|
|
|
if (oh->_state != _HWMOD_STATE_REGISTERED)
|
|
|
|
return 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: looking up clocks\n", oh->name);
|
|
|
|
|
2012-07-09 20:54:30 +08:00
|
|
|
if (soc_ops.init_clkdm)
|
|
|
|
ret |= soc_ops.init_clkdm(oh);
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
ret |= _init_main_clk(oh);
|
|
|
|
ret |= _init_interface_clks(oh);
|
|
|
|
ret |= _init_opt_clks(oh);
|
|
|
|
|
2010-05-21 02:31:10 +08:00
|
|
|
if (!ret)
|
|
|
|
oh->_state = _HWMOD_STATE_CLKS_INITED;
|
2011-07-02 04:54:06 +08:00
|
|
|
else
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: cannot _init_clocks\n", oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2011-02-16 20:11:24 +08:00
|
|
|
return ret;
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
/**
|
2011-03-05 04:32:44 +08:00
|
|
|
* _lookup_hardreset - fill register bit info for this hwmod/reset line
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @name: name of the reset line in the context of this hwmod
|
2011-03-05 04:32:44 +08:00
|
|
|
* @ohri: struct omap_hwmod_rst_info * that this function will fill in
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
*
|
|
|
|
* Return the bit position of the reset line that match the
|
|
|
|
* input name. Return -ENOENT if not found.
|
|
|
|
*/
|
2012-08-03 23:21:10 +08:00
|
|
|
static int _lookup_hardreset(struct omap_hwmod *oh, const char *name,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < oh->rst_lines_cnt; i++) {
|
|
|
|
const char *rst_line = oh->rst_lines[i].name;
|
|
|
|
if (!strcmp(rst_line, name)) {
|
2011-03-05 04:32:44 +08:00
|
|
|
ohri->rst_shift = oh->rst_lines[i].rst_shift;
|
|
|
|
ohri->st_shift = oh->rst_lines[i].st_shift;
|
|
|
|
pr_debug("omap_hwmod: %s: %s: %s: rst %d st %d\n",
|
|
|
|
oh->name, __func__, rst_line, ohri->rst_shift,
|
|
|
|
ohri->st_shift);
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
2011-03-05 04:32:44 +08:00
|
|
|
return 0;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _assert_hardreset - assert the HW reset line of submodules
|
|
|
|
* contained in the hwmod module.
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @name: name of the reset line to lookup and assert
|
|
|
|
*
|
2012-06-19 02:12:24 +08:00
|
|
|
* Some IP like dsp, ipu or iva contain processor that require an HW
|
|
|
|
* reset line to be assert / deassert in order to enable fully the IP.
|
|
|
|
* Returns -EINVAL if @oh is null, -ENOSYS if we have no way of
|
|
|
|
* asserting the hardreset line on the currently-booted SoC, or passes
|
|
|
|
* along the return value from _lookup_hardreset() or the SoC's
|
|
|
|
* assert_hardreset code.
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
*/
|
|
|
|
static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
|
|
|
|
{
|
2011-03-05 04:32:44 +08:00
|
|
|
struct omap_hwmod_rst_info ohri;
|
2012-08-03 23:21:10 +08:00
|
|
|
int ret = -EINVAL;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
if (!soc_ops.assert_hardreset)
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2011-03-05 04:32:44 +08:00
|
|
|
ret = _lookup_hardreset(oh, name, &ohri);
|
2012-08-03 23:21:10 +08:00
|
|
|
if (ret < 0)
|
2011-03-05 04:32:44 +08:00
|
|
|
return ret;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
ret = soc_ops.assert_hardreset(oh, &ohri);
|
|
|
|
|
|
|
|
return ret;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _deassert_hardreset - deassert the HW reset line of submodules contained
|
|
|
|
* in the hwmod module.
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @name: name of the reset line to look up and deassert
|
|
|
|
*
|
2012-06-19 02:12:24 +08:00
|
|
|
* Some IP like dsp, ipu or iva contain processor that require an HW
|
|
|
|
* reset line to be assert / deassert in order to enable fully the IP.
|
|
|
|
* Returns -EINVAL if @oh is null, -ENOSYS if we have no way of
|
|
|
|
* deasserting the hardreset line on the currently-booted SoC, or passes
|
|
|
|
* along the return value from _lookup_hardreset() or the SoC's
|
|
|
|
* deassert_hardreset code.
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
*/
|
|
|
|
static int _deassert_hardreset(struct omap_hwmod *oh, const char *name)
|
|
|
|
{
|
2011-03-05 04:32:44 +08:00
|
|
|
struct omap_hwmod_rst_info ohri;
|
2012-06-19 02:12:24 +08:00
|
|
|
int ret = -EINVAL;
|
2012-09-24 07:28:21 +08:00
|
|
|
int hwsup = 0;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
if (!soc_ops.deassert_hardreset)
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2011-03-05 04:32:44 +08:00
|
|
|
ret = _lookup_hardreset(oh, name, &ohri);
|
ARM: OMAP: use consistent error checking
Consistently check errors using the usual method used in the kernel
for much of its history. For instance:
int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
int div;
div = gpmc_calc_divider(t->sync_clk);
if (div < 0)
return div;
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
{
...
return gpmc_cs_set_timings(cs, t);
.....
ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
if (IS_ERR_VALUE(ret))
return ret;
So, gpmc_cs_set_timings() thinks any negative return value is an error,
but where we check that in higher levels, only a limited range are
errors...
There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
appropriate, and that is in arch/arm/include/asm/syscall.h:
static inline long syscall_get_error(struct task_struct *task,
struct pt_regs *regs)
{
unsigned long error = regs->ARM_r0;
return IS_ERR_VALUE(error) ? error : 0;
}
because this function really does have to differentiate between error
return values and addresses which look like negative numbers (eg, from
mmap()).
So, here's a patch to remove them from OMAP, except for the above.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-03-14 04:44:21 +08:00
|
|
|
if (ret < 0)
|
2011-03-05 04:32:44 +08:00
|
|
|
return ret;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
2012-09-24 07:28:21 +08:00
|
|
|
if (oh->clkdm) {
|
|
|
|
/*
|
|
|
|
* A clockdomain must be in SW_SUP otherwise reset
|
|
|
|
* might not be completed. The clockdomain can be set
|
|
|
|
* in HW_AUTO only when the module become ready.
|
|
|
|
*/
|
|
|
|
hwsup = clkdm_in_hwsup(oh->clkdm);
|
|
|
|
ret = clkdm_hwmod_enable(oh->clkdm, oh);
|
|
|
|
if (ret) {
|
|
|
|
WARN(1, "omap_hwmod: %s: could not enable clockdomain %s: %d\n",
|
|
|
|
oh->name, oh->clkdm->name, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
_enable_clocks(oh);
|
|
|
|
if (soc_ops.enable_module)
|
|
|
|
soc_ops.enable_module(oh);
|
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
ret = soc_ops.deassert_hardreset(oh, &ohri);
|
2012-09-24 07:28:21 +08:00
|
|
|
|
|
|
|
if (soc_ops.disable_module)
|
|
|
|
soc_ops.disable_module(oh);
|
|
|
|
_disable_clocks(oh);
|
|
|
|
|
2011-03-05 04:32:44 +08:00
|
|
|
if (ret == -EBUSY)
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: failed to hardreset\n", oh->name);
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
2015-02-27 00:06:00 +08:00
|
|
|
if (oh->clkdm) {
|
2012-09-24 07:28:21 +08:00
|
|
|
/*
|
|
|
|
* Set the clockdomain to HW_AUTO, assuming that the
|
|
|
|
* previous state was HW_AUTO.
|
|
|
|
*/
|
2015-02-27 00:06:00 +08:00
|
|
|
if (hwsup)
|
2012-09-24 07:28:21 +08:00
|
|
|
clkdm_allow_idle(oh->clkdm);
|
2015-02-27 00:06:00 +08:00
|
|
|
|
|
|
|
clkdm_hwmod_disable(oh->clkdm, oh);
|
2012-09-24 07:28:21 +08:00
|
|
|
}
|
|
|
|
|
2011-03-05 04:32:44 +08:00
|
|
|
return ret;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _read_hardreset - read the HW reset line state of submodules
|
|
|
|
* contained in the hwmod module
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @name: name of the reset line to look up and read
|
|
|
|
*
|
2012-06-19 02:12:24 +08:00
|
|
|
* Return the state of the reset line. Returns -EINVAL if @oh is
|
|
|
|
* null, -ENOSYS if we have no way of reading the hardreset line
|
|
|
|
* status on the currently-booted SoC, or passes along the return
|
|
|
|
* value from _lookup_hardreset() or the SoC's is_hardreset_asserted
|
|
|
|
* code.
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
*/
|
|
|
|
static int _read_hardreset(struct omap_hwmod *oh, const char *name)
|
|
|
|
{
|
2011-03-05 04:32:44 +08:00
|
|
|
struct omap_hwmod_rst_info ohri;
|
2012-08-03 23:21:10 +08:00
|
|
|
int ret = -EINVAL;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
if (!soc_ops.is_hardreset_asserted)
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2011-03-05 04:32:44 +08:00
|
|
|
ret = _lookup_hardreset(oh, name, &ohri);
|
2012-08-03 23:21:10 +08:00
|
|
|
if (ret < 0)
|
2011-03-05 04:32:44 +08:00
|
|
|
return ret;
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
return soc_ops.is_hardreset_asserted(oh, &ohri);
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
}
|
|
|
|
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
/**
|
2012-09-24 07:28:20 +08:00
|
|
|
* _are_all_hardreset_lines_asserted - return true if the @oh is hard-reset
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2012-09-24 07:28:20 +08:00
|
|
|
* If all hardreset lines associated with @oh are asserted, then return true.
|
|
|
|
* Otherwise, if part of @oh is out hardreset or if no hardreset lines
|
|
|
|
* associated with @oh are asserted, then return false.
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
* This function is used to avoid executing some parts of the IP block
|
2012-09-24 07:28:20 +08:00
|
|
|
* enable/disable sequence if its hardreset line is set.
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
*/
|
2012-09-24 07:28:20 +08:00
|
|
|
static bool _are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
{
|
2012-09-24 07:28:20 +08:00
|
|
|
int i, rst_cnt = 0;
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
|
|
|
|
if (oh->rst_lines_cnt == 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
for (i = 0; i < oh->rst_lines_cnt; i++)
|
|
|
|
if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
|
2012-09-24 07:28:20 +08:00
|
|
|
rst_cnt++;
|
|
|
|
|
|
|
|
if (oh->rst_lines_cnt == rst_cnt)
|
|
|
|
return true;
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-10-09 13:08:15 +08:00
|
|
|
/**
|
|
|
|
* _are_any_hardreset_lines_asserted - return true if any part of @oh is
|
|
|
|
* hard-reset
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* If any hardreset lines associated with @oh are asserted, then
|
|
|
|
* return true. Otherwise, if no hardreset lines associated with @oh
|
|
|
|
* are asserted, or if @oh has no hardreset lines, then return false.
|
|
|
|
* This function is used to avoid executing some parts of the IP block
|
|
|
|
* enable/disable sequence if any hardreset line is set.
|
|
|
|
*/
|
|
|
|
static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
int rst_cnt = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < oh->rst_lines_cnt && rst_cnt == 0; i++)
|
|
|
|
if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
|
|
|
|
rst_cnt++;
|
|
|
|
|
|
|
|
return (rst_cnt) ? true : false;
|
|
|
|
}
|
|
|
|
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
/**
|
|
|
|
* _omap4_disable_module - enable CLKCTRL modulemode on OMAP4
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Disable the PRCM module mode related to the hwmod @oh.
|
|
|
|
* Return EINVAL if the modulemode is not supported and 0 in case of success.
|
|
|
|
*/
|
|
|
|
static int _omap4_disable_module(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
int v;
|
|
|
|
|
|
|
|
if (!oh->clkdm || !oh->prcm.omap4.modulemode)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-09-24 07:28:20 +08:00
|
|
|
/*
|
|
|
|
* Since integration code might still be doing something, only
|
|
|
|
* disable if all lines are under hardreset.
|
|
|
|
*/
|
2012-10-09 13:08:15 +08:00
|
|
|
if (_are_any_hardreset_lines_asserted(oh))
|
2012-09-24 07:28:20 +08:00
|
|
|
return 0;
|
|
|
|
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
|
|
|
|
|
2014-10-27 23:39:24 +08:00
|
|
|
omap_cm_module_disable(oh->clkdm->prcm_partition, oh->clkdm->cm_inst,
|
|
|
|
oh->prcm.omap4.clkctrl_offs);
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
|
|
|
|
v = _omap4_wait_target_disable(oh);
|
|
|
|
if (v)
|
|
|
|
pr_warn("omap_hwmod: %s: _wait_target_disable failed\n",
|
|
|
|
oh->name);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
* _ocp_softreset - reset an omap_hwmod via the OCP_SYSCONFIG bit
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Resets an omap_hwmod @oh via the OCP_SYSCONFIG bit. hwmod must be
|
2012-04-19 14:49:09 +08:00
|
|
|
* enabled for this to work. Returns -ENOENT if the hwmod cannot be
|
|
|
|
* reset this way, -EINVAL if the hwmod is in the wrong state,
|
|
|
|
* -ETIMEDOUT if the module did not reset in time, or 0 upon success.
|
2010-09-22 00:57:59 +08:00
|
|
|
*
|
|
|
|
* In OMAP3 a specific SYSSTATUS register is used to get the reset status.
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
* Starting in OMAP4, some IPs do not have SYSSTATUS registers and instead
|
2010-09-22 00:57:59 +08:00
|
|
|
* use the SYSCONFIG softreset bit to provide the status.
|
|
|
|
*
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
* Note that some IP like McBSP do have reset control but don't have
|
|
|
|
* reset status.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
static int _ocp_softreset(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2012-10-30 12:02:13 +08:00
|
|
|
u32 v;
|
2009-12-09 07:33:16 +08:00
|
|
|
int c = 0;
|
2010-09-22 00:57:58 +08:00
|
|
|
int ret = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh->class->sysc ||
|
2010-09-22 00:57:59 +08:00
|
|
|
!(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
|
2012-04-19 14:49:09 +08:00
|
|
|
return -ENOENT;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
/* clocks must be on for this operation */
|
|
|
|
if (oh->_state != _HWMOD_STATE_ENABLED) {
|
2012-07-26 14:54:26 +08:00
|
|
|
pr_warn("omap_hwmod: %s: reset can only be entered from enabled state\n",
|
|
|
|
oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-09-22 00:57:58 +08:00
|
|
|
/* For some modules, all optionnal clocks need to be enabled as well */
|
|
|
|
if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
|
|
|
|
_enable_optional_clocks(oh);
|
|
|
|
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
pr_debug("omap_hwmod: %s: resetting via OCP SOFTRESET\n", oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
v = oh->_sysc_cache;
|
2010-09-22 00:57:58 +08:00
|
|
|
ret = _set_softreset(oh, &v);
|
|
|
|
if (ret)
|
|
|
|
goto dis_opt_clks;
|
2013-12-09 09:39:02 +08:00
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
|
2012-04-13 19:08:03 +08:00
|
|
|
if (oh->class->sysc->srst_udelay)
|
|
|
|
udelay(oh->class->sysc->srst_udelay);
|
|
|
|
|
2012-10-30 12:02:13 +08:00
|
|
|
c = _wait_softreset_complete(oh);
|
2014-02-05 23:06:09 +08:00
|
|
|
if (c == MAX_MODULE_SOFTRESET_WAIT) {
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: softreset failed (waited %d usec)\n",
|
|
|
|
oh->name, MAX_MODULE_SOFTRESET_WAIT);
|
2014-02-05 23:06:09 +08:00
|
|
|
ret = -ETIMEDOUT;
|
|
|
|
goto dis_opt_clks;
|
|
|
|
} else {
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
pr_debug("omap_hwmod: %s: softreset in %d usec\n", oh->name, c);
|
2014-02-05 23:06:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = _clear_softreset(oh, &v);
|
|
|
|
if (ret)
|
|
|
|
goto dis_opt_clks;
|
|
|
|
|
|
|
|
_write_sysconfig(v, oh);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX add _HWMOD_STATE_WEDGED for modules that don't come back from
|
|
|
|
* _wait_target_ready() or _reset()
|
|
|
|
*/
|
|
|
|
|
2010-09-22 00:57:58 +08:00
|
|
|
dis_opt_clks:
|
|
|
|
if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
|
|
|
|
_disable_optional_clocks(oh);
|
|
|
|
|
|
|
|
return ret;
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
/**
|
|
|
|
* _reset - reset an omap_hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2012-04-19 14:49:09 +08:00
|
|
|
* Resets an omap_hwmod @oh. If the module has a custom reset
|
|
|
|
* function pointer defined, then call it to reset the IP block, and
|
|
|
|
* pass along its return value to the caller. Otherwise, if the IP
|
|
|
|
* block has an OCP_SYSCONFIG register with a SOFTRESET bitfield
|
|
|
|
* associated with it, call a function to reset the IP block via that
|
|
|
|
* method, and pass along the return value to the caller. Finally, if
|
|
|
|
* the IP block has some hardreset lines associated with it, assert
|
|
|
|
* all of those, but do _not_ deassert them. (This is because driver
|
|
|
|
* authors have expressed an apparent requirement to control the
|
|
|
|
* deassertion of the hardreset lines themselves.)
|
|
|
|
*
|
|
|
|
* The default software reset mechanism for most OMAP IP blocks is
|
|
|
|
* triggered via the OCP_SYSCONFIG.SOFTRESET bit. However, some
|
|
|
|
* hwmods cannot be reset via this method. Some are not targets and
|
|
|
|
* therefore have no OCP header registers to access. Others (like the
|
|
|
|
* IVA) have idiosyncratic reset sequences. So for these relatively
|
|
|
|
* rare cases, custom reset code can be supplied in the struct
|
2012-07-04 19:09:21 +08:00
|
|
|
* omap_hwmod_class .reset function pointer.
|
|
|
|
*
|
|
|
|
* _set_dmadisable() is called to set the DMADISABLE bit so that it
|
|
|
|
* does not prevent idling of the system. This is necessary for cases
|
|
|
|
* where ROMCODE/BOOTLOADER uses dma and transfers control to the
|
|
|
|
* kernel without disabling dma.
|
|
|
|
*
|
|
|
|
* Passes along the return value from either _ocp_softreset() or the
|
|
|
|
* custom reset function - these must return -EINVAL if the hwmod
|
|
|
|
* cannot be reset this way or if the hwmod is in the wrong state,
|
|
|
|
* -ETIMEDOUT if the module did not reset in time, or 0 upon success.
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
*/
|
|
|
|
static int _reset(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-04-19 14:49:09 +08:00
|
|
|
int i, r;
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: resetting\n", oh->name);
|
|
|
|
|
2012-04-19 14:49:09 +08:00
|
|
|
if (oh->class->reset) {
|
|
|
|
r = oh->class->reset(oh);
|
|
|
|
} else {
|
|
|
|
if (oh->rst_lines_cnt > 0) {
|
|
|
|
for (i = 0; i < oh->rst_lines_cnt; i++)
|
|
|
|
_assert_hardreset(oh, oh->rst_lines[i].name);
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
r = _ocp_softreset(oh);
|
|
|
|
if (r == -ENOENT)
|
|
|
|
r = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-07-04 19:09:21 +08:00
|
|
|
_set_dmadisable(oh);
|
|
|
|
|
2012-04-19 09:10:02 +08:00
|
|
|
/*
|
2012-04-19 14:49:09 +08:00
|
|
|
* OCP_SYSCONFIG bits need to be reprogrammed after a
|
|
|
|
* softreset. The _enable() function should be split to avoid
|
|
|
|
* the rewrite of the OCP_SYSCONFIG register.
|
2012-04-19 09:10:02 +08:00
|
|
|
*/
|
2012-03-14 01:25:23 +08:00
|
|
|
if (oh->class->sysc) {
|
|
|
|
_update_sysc_cache(oh);
|
|
|
|
_enable_sysc(oh);
|
|
|
|
}
|
|
|
|
|
2012-04-19 14:49:09 +08:00
|
|
|
return r;
|
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
}
|
|
|
|
|
2012-06-22 22:40:04 +08:00
|
|
|
/**
|
|
|
|
* _reconfigure_io_chain - clear any I/O chain wakeups and reconfigure chain
|
|
|
|
*
|
|
|
|
* Call the appropriate PRM function to clear any logged I/O chain
|
|
|
|
* wakeups and to reconfigure the chain. This apparently needs to be
|
|
|
|
* done upon every mux change. Since hwmods can be concurrently
|
|
|
|
* enabled and idled, hold a spinlock around the I/O chain
|
|
|
|
* reconfiguration sequence. No return value.
|
|
|
|
*
|
|
|
|
* XXX When the PRM code is moved to drivers, this function can be removed,
|
|
|
|
* as the PRM infrastructure should abstract this.
|
|
|
|
*/
|
|
|
|
static void _reconfigure_io_chain(void)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&io_chain_lock, flags);
|
|
|
|
|
2014-10-27 23:39:26 +08:00
|
|
|
omap_prm_reconfigure_io_chain();
|
2012-06-22 22:40:04 +08:00
|
|
|
|
|
|
|
spin_unlock_irqrestore(&io_chain_lock, flags);
|
|
|
|
}
|
|
|
|
|
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kristo@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-22 07:15:17 +08:00
|
|
|
/**
|
|
|
|
* _omap4_update_context_lost - increment hwmod context loss counter if
|
|
|
|
* hwmod context was lost, and clear hardware context loss reg
|
|
|
|
* @oh: hwmod to check for context loss
|
|
|
|
*
|
|
|
|
* If the PRCM indicates that the hwmod @oh lost context, increment
|
|
|
|
* our in-memory context loss counter, and clear the RM_*_CONTEXT
|
|
|
|
* bits. No return value.
|
|
|
|
*/
|
|
|
|
static void _omap4_update_context_lost(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
if (oh->prcm.omap4.flags & HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!prm_was_any_context_lost_old(oh->clkdm->pwrdm.ptr->prcm_partition,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.context_offs))
|
|
|
|
return;
|
|
|
|
|
|
|
|
oh->prcm.omap4.context_lost_counter++;
|
|
|
|
prm_clear_context_loss_flags_old(oh->clkdm->pwrdm.ptr->prcm_partition,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.context_offs);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _omap4_get_context_lost - get context loss counter for a hwmod
|
|
|
|
* @oh: hwmod to get context loss counter for
|
|
|
|
*
|
|
|
|
* Returns the in-memory context loss counter for a hwmod.
|
|
|
|
*/
|
|
|
|
static int _omap4_get_context_lost(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
return oh->prcm.omap4.context_lost_counter;
|
|
|
|
}
|
|
|
|
|
2013-02-11 02:22:22 +08:00
|
|
|
/**
|
|
|
|
* _enable_preprogram - Pre-program an IP block during the _enable() process
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Some IP blocks (such as AESS) require some additional programming
|
|
|
|
* after enable before they can enter idle. If a function pointer to
|
|
|
|
* do so is present in the hwmod data, then call it and pass along the
|
|
|
|
* return value; otherwise, return 0.
|
|
|
|
*/
|
2013-05-17 02:25:07 +08:00
|
|
|
static int _enable_preprogram(struct omap_hwmod *oh)
|
2013-02-11 02:22:22 +08:00
|
|
|
{
|
|
|
|
if (!oh->class->enable_preprogram)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return oh->class->enable_preprogram(oh);
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
* _enable - enable an omap_hwmod
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Enables an omap_hwmod @oh such that the MPU can access the hwmod's
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
* register target. Returns -EINVAL if the hwmod is in the wrong
|
|
|
|
* state or passes along the return value of _wait_target_ready().
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
static int _enable(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
int r;
|
2011-07-10 19:57:07 +08:00
|
|
|
int hwsup = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2011-07-02 04:54:07 +08:00
|
|
|
pr_debug("omap_hwmod: %s: enabling\n", oh->name);
|
|
|
|
|
2011-12-16 20:50:12 +08:00
|
|
|
/*
|
2012-04-19 09:10:03 +08:00
|
|
|
* hwmods with HWMOD_INIT_NO_IDLE flag set are left in enabled
|
|
|
|
* state at init. Now that someone is really trying to enable
|
|
|
|
* them, just ensure that the hwmod mux is set.
|
2011-12-16 20:50:12 +08:00
|
|
|
*/
|
|
|
|
if (oh->_int_flags & _HWMOD_SKIP_ENABLE) {
|
|
|
|
/*
|
|
|
|
* If the caller has mux data populated, do the mux'ing
|
|
|
|
* which wouldn't have been done as part of the _enable()
|
|
|
|
* done during setup.
|
|
|
|
*/
|
|
|
|
if (oh->mux)
|
|
|
|
omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
|
|
|
|
|
|
|
|
oh->_int_flags &= ~_HWMOD_SKIP_ENABLE;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
if (oh->_state != _HWMOD_STATE_INITIALIZED &&
|
|
|
|
oh->_state != _HWMOD_STATE_IDLE &&
|
|
|
|
oh->_state != _HWMOD_STATE_DISABLED) {
|
2012-02-07 18:59:37 +08:00
|
|
|
WARN(1, "omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state\n",
|
|
|
|
oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2011-07-02 04:54:05 +08:00
|
|
|
/*
|
2012-09-24 07:28:20 +08:00
|
|
|
* If an IP block contains HW reset lines and all of them are
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
* asserted, we let integration code associated with that
|
|
|
|
* block handle the enable. We've received very little
|
|
|
|
* information on what those driver authors need, and until
|
|
|
|
* detailed information is provided and the driver code is
|
|
|
|
* posted to the public lists, this is probably the best we
|
|
|
|
* can do.
|
2011-07-02 04:54:05 +08:00
|
|
|
*/
|
2012-09-24 07:28:20 +08:00
|
|
|
if (_are_all_hardreset_lines_asserted(oh))
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
return 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2011-07-10 19:57:07 +08:00
|
|
|
/* Mux pins for device runtime if populated */
|
|
|
|
if (oh->mux && (!oh->mux->enabled ||
|
|
|
|
((oh->_state == _HWMOD_STATE_IDLE) &&
|
2012-06-22 22:40:04 +08:00
|
|
|
oh->mux->pads_dynamic))) {
|
2011-07-10 19:57:07 +08:00
|
|
|
omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
|
2012-06-22 22:40:04 +08:00
|
|
|
_reconfigure_io_chain();
|
2014-09-18 23:58:28 +08:00
|
|
|
} else if (oh->flags & HWMOD_RECONFIG_IO_CHAIN) {
|
2014-08-26 07:15:35 +08:00
|
|
|
_reconfigure_io_chain();
|
2012-06-22 22:40:04 +08:00
|
|
|
}
|
2011-07-10 19:57:07 +08:00
|
|
|
|
|
|
|
_add_initiator_dep(oh, mpu_oh);
|
2011-07-02 04:54:07 +08:00
|
|
|
|
2011-07-10 19:57:07 +08:00
|
|
|
if (oh->clkdm) {
|
|
|
|
/*
|
|
|
|
* A clockdomain must be in SW_SUP before enabling
|
|
|
|
* completely the module. The clockdomain can be set
|
|
|
|
* in HW_AUTO only when the module become ready.
|
|
|
|
*/
|
ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems
The idle status of the IP blocks and clocks inside the EMU clockdomain
isn't taken into account by the PRCM hardware when deciding whether
the clockdomain is idle. Add a workaround flag in the clockdomain
code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
the code necessary to support it.
If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
clockdomain will be forced active whenever an IP block inside that
clockdomain is in use, even if the clockdomain supports
hardware-supervised idle. When the kernel indicates that the last
active IP block inside the clockdomain is no longer used, the
clockdomain will be forced idle, or, if that mode is not supported in
the hardware, it will be placed into hardware-supervised idle.
This patch is an equal collaboration with Jon Hunter
<jon-hunter@ti.com>. Ming Lei <ming.lei@canonical.com>, Will Deacon
<will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman
<khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh
Shilimkar <santosh.shilimkar@ti.com> all made essential contributions
to the understanding of EMU clockdomain power management on OMAP.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Madhav Vij <mvij@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Jon Hunter <jon-hunter@ti.com>
2012-09-24 07:28:28 +08:00
|
|
|
hwsup = clkdm_in_hwsup(oh->clkdm) &&
|
|
|
|
!clkdm_missing_idle_reporting(oh->clkdm);
|
2011-07-10 19:57:07 +08:00
|
|
|
r = clkdm_hwmod_enable(oh->clkdm, oh);
|
|
|
|
if (r) {
|
|
|
|
WARN(1, "omap_hwmod: %s: could not enable clockdomain %s: %d\n",
|
|
|
|
oh->name, oh->clkdm->name, r);
|
|
|
|
return r;
|
|
|
|
}
|
2011-07-02 04:54:07 +08:00
|
|
|
}
|
2011-07-10 19:57:07 +08:00
|
|
|
|
|
|
|
_enable_clocks(oh);
|
2012-06-19 02:12:23 +08:00
|
|
|
if (soc_ops.enable_module)
|
|
|
|
soc_ops.enable_module(oh);
|
2013-01-26 15:48:56 +08:00
|
|
|
if (oh->flags & HWMOD_BLOCK_WFI)
|
2013-03-22 05:49:38 +08:00
|
|
|
cpu_idle_poll_ctrl(true);
|
2011-07-02 04:54:07 +08:00
|
|
|
|
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kristo@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-22 07:15:17 +08:00
|
|
|
if (soc_ops.update_context_lost)
|
|
|
|
soc_ops.update_context_lost(oh);
|
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
r = (soc_ops.wait_target_ready) ? soc_ops.wait_target_ready(oh) :
|
|
|
|
-EINVAL;
|
2011-07-10 19:57:07 +08:00
|
|
|
if (!r) {
|
|
|
|
/*
|
|
|
|
* Set the clockdomain to HW_AUTO only if the target is ready,
|
|
|
|
* assuming that the previous state was HW_AUTO
|
|
|
|
*/
|
|
|
|
if (oh->clkdm && hwsup)
|
|
|
|
clkdm_allow_idle(oh->clkdm);
|
|
|
|
|
|
|
|
oh->_state = _HWMOD_STATE_ENABLED;
|
|
|
|
|
|
|
|
/* Access the sysconfig only if the target is ready */
|
|
|
|
if (oh->class->sysc) {
|
|
|
|
if (!(oh->_int_flags & _HWMOD_SYSCONFIG_LOADED))
|
|
|
|
_update_sysc_cache(oh);
|
|
|
|
_enable_sysc(oh);
|
|
|
|
}
|
2013-02-11 02:22:22 +08:00
|
|
|
r = _enable_preprogram(oh);
|
2011-07-10 19:57:07 +08:00
|
|
|
} else {
|
2012-10-30 10:57:55 +08:00
|
|
|
if (soc_ops.disable_module)
|
|
|
|
soc_ops.disable_module(oh);
|
2011-07-10 19:57:07 +08:00
|
|
|
_disable_clocks(oh);
|
2014-12-19 20:34:50 +08:00
|
|
|
pr_err("omap_hwmod: %s: _wait_target_ready failed: %d\n",
|
|
|
|
oh->name, r);
|
2011-07-02 04:54:07 +08:00
|
|
|
|
2011-07-10 19:57:07 +08:00
|
|
|
if (oh->clkdm)
|
|
|
|
clkdm_hwmod_disable(oh->clkdm, oh);
|
2010-05-21 02:31:08 +08:00
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
* _idle - idle an omap_hwmod
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Idles an omap_hwmod @oh. This should be called once the hwmod has
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
* no further work. Returns -EINVAL if the hwmod is in the wrong
|
|
|
|
* state or returns 0.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
static int _idle(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2011-07-02 04:54:07 +08:00
|
|
|
pr_debug("omap_hwmod: %s: idling\n", oh->name);
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
if (oh->_state != _HWMOD_STATE_ENABLED) {
|
2012-02-07 18:59:37 +08:00
|
|
|
WARN(1, "omap_hwmod: %s: idle state can only be entered from enabled state\n",
|
|
|
|
oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-09-24 07:28:20 +08:00
|
|
|
if (_are_all_hardreset_lines_asserted(oh))
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
return 0;
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
if (oh->class->sysc)
|
2010-09-22 05:02:23 +08:00
|
|
|
_idle_sysc(oh);
|
2009-09-04 01:14:03 +08:00
|
|
|
_del_initiator_dep(oh, mpu_oh);
|
2011-12-17 08:09:11 +08:00
|
|
|
|
2013-01-26 15:48:56 +08:00
|
|
|
if (oh->flags & HWMOD_BLOCK_WFI)
|
2013-03-22 05:49:38 +08:00
|
|
|
cpu_idle_poll_ctrl(false);
|
2012-06-19 02:12:23 +08:00
|
|
|
if (soc_ops.disable_module)
|
|
|
|
soc_ops.disable_module(oh);
|
2011-12-17 08:09:11 +08:00
|
|
|
|
2011-07-10 19:56:33 +08:00
|
|
|
/*
|
|
|
|
* The module must be in idle mode before disabling any parents
|
|
|
|
* clocks. Otherwise, the parent clock might be disabled before
|
|
|
|
* the module transition is done, and thus will prevent the
|
|
|
|
* transition to complete properly.
|
|
|
|
*/
|
|
|
|
_disable_clocks(oh);
|
2011-07-10 19:57:07 +08:00
|
|
|
if (oh->clkdm)
|
|
|
|
clkdm_hwmod_disable(oh->clkdm, oh);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2010-12-23 10:42:35 +08:00
|
|
|
/* Mux pins for device idle if populated */
|
2012-06-22 22:40:04 +08:00
|
|
|
if (oh->mux && oh->mux->pads_dynamic) {
|
2010-12-23 10:42:35 +08:00
|
|
|
omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
|
2012-06-22 22:40:04 +08:00
|
|
|
_reconfigure_io_chain();
|
2014-09-18 23:58:28 +08:00
|
|
|
} else if (oh->flags & HWMOD_RECONFIG_IO_CHAIN) {
|
2014-08-26 07:15:35 +08:00
|
|
|
_reconfigure_io_chain();
|
2012-06-22 22:40:04 +08:00
|
|
|
}
|
2010-12-23 10:42:35 +08:00
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
oh->_state = _HWMOD_STATE_IDLE;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _shutdown - shutdown an omap_hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Shut down an omap_hwmod @oh. This should be called when the driver
|
|
|
|
* used for the hwmod is removed or unloaded or if the driver is not
|
|
|
|
* used by the system. Returns -EINVAL if the hwmod is in the wrong
|
|
|
|
* state or returns 0.
|
|
|
|
*/
|
|
|
|
static int _shutdown(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-04-19 09:10:02 +08:00
|
|
|
int ret, i;
|
2010-12-15 03:42:34 +08:00
|
|
|
u8 prev_state;
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
if (oh->_state != _HWMOD_STATE_IDLE &&
|
|
|
|
oh->_state != _HWMOD_STATE_ENABLED) {
|
2012-02-07 18:59:37 +08:00
|
|
|
WARN(1, "omap_hwmod: %s: disabled state can only be entered from idle, or enabled state\n",
|
|
|
|
oh->name);
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-09-24 07:28:20 +08:00
|
|
|
if (_are_all_hardreset_lines_asserted(oh))
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
return 0;
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
pr_debug("omap_hwmod: %s: disabling\n", oh->name);
|
|
|
|
|
2010-12-15 03:42:34 +08:00
|
|
|
if (oh->class->pre_shutdown) {
|
|
|
|
prev_state = oh->_state;
|
|
|
|
if (oh->_state == _HWMOD_STATE_IDLE)
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
_enable(oh);
|
2010-12-15 03:42:34 +08:00
|
|
|
ret = oh->class->pre_shutdown(oh);
|
|
|
|
if (ret) {
|
|
|
|
if (prev_state == _HWMOD_STATE_IDLE)
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
_idle(oh);
|
2010-12-15 03:42:34 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-07-02 04:54:02 +08:00
|
|
|
if (oh->class->sysc) {
|
|
|
|
if (oh->_state == _HWMOD_STATE_IDLE)
|
|
|
|
_enable(oh);
|
2010-09-22 05:02:23 +08:00
|
|
|
_shutdown_sysc(oh);
|
2011-07-02 04:54:02 +08:00
|
|
|
}
|
OMAP: hwmod: Add hardreset management support
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
2010-09-22 00:34:11 +08:00
|
|
|
|
2010-09-22 00:34:08 +08:00
|
|
|
/* clocks and deps are already disabled in idle */
|
|
|
|
if (oh->_state == _HWMOD_STATE_ENABLED) {
|
|
|
|
_del_initiator_dep(oh, mpu_oh);
|
|
|
|
/* XXX what about the other system initiators here? dma, dsp */
|
2013-01-26 15:48:56 +08:00
|
|
|
if (oh->flags & HWMOD_BLOCK_WFI)
|
2013-03-22 05:49:38 +08:00
|
|
|
cpu_idle_poll_ctrl(false);
|
2012-06-19 02:12:23 +08:00
|
|
|
if (soc_ops.disable_module)
|
|
|
|
soc_ops.disable_module(oh);
|
2011-07-10 19:56:33 +08:00
|
|
|
_disable_clocks(oh);
|
2011-07-10 19:57:07 +08:00
|
|
|
if (oh->clkdm)
|
|
|
|
clkdm_hwmod_disable(oh->clkdm, oh);
|
2010-09-22 00:34:08 +08:00
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
/* XXX Should this code also force-disable the optional clocks? */
|
|
|
|
|
2012-04-19 09:10:02 +08:00
|
|
|
for (i = 0; i < oh->rst_lines_cnt; i++)
|
|
|
|
_assert_hardreset(oh, oh->rst_lines[i].name);
|
2011-07-02 04:54:05 +08:00
|
|
|
|
2010-12-23 10:42:35 +08:00
|
|
|
/* Mux pins to safe mode or use populated off mode values */
|
|
|
|
if (oh->mux)
|
|
|
|
omap_hwmod_mux(oh->mux, _HWMOD_STATE_DISABLED);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
oh->_state = _HWMOD_STATE_DISABLED;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
static int of_dev_find_hwmod(struct device_node *np,
|
|
|
|
struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
int count, i, res;
|
|
|
|
const char *p;
|
|
|
|
|
|
|
|
count = of_property_count_strings(np, "ti,hwmods");
|
|
|
|
if (count < 1)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
res = of_property_read_string_index(np, "ti,hwmods",
|
|
|
|
i, &p);
|
|
|
|
if (res)
|
|
|
|
continue;
|
|
|
|
if (!strcmp(p, oh->name)) {
|
|
|
|
pr_debug("omap_hwmod: dt %s[%i] uses hwmod %s\n",
|
|
|
|
np->name, i, oh->name);
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2013-01-21 21:10:57 +08:00
|
|
|
/**
|
|
|
|
* of_dev_hwmod_lookup - look up needed hwmod from dt blob
|
|
|
|
* @np: struct device_node *
|
|
|
|
* @oh: struct omap_hwmod *
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
* @index: index of the entry found
|
|
|
|
* @found: struct device_node * found or NULL
|
2013-01-21 21:10:57 +08:00
|
|
|
*
|
|
|
|
* Parse the dt blob and find out needed hwmod. Recursive function is
|
|
|
|
* implemented to take care hierarchical dt blob parsing.
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
* Return: Returns 0 on success, -ENODEV when not found.
|
2013-01-21 21:10:57 +08:00
|
|
|
*/
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
static int of_dev_hwmod_lookup(struct device_node *np,
|
|
|
|
struct omap_hwmod *oh,
|
|
|
|
int *index,
|
|
|
|
struct device_node **found)
|
2013-01-21 21:10:57 +08:00
|
|
|
{
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
struct device_node *np0 = NULL;
|
|
|
|
int res;
|
|
|
|
|
|
|
|
res = of_dev_find_hwmod(np, oh);
|
|
|
|
if (res >= 0) {
|
|
|
|
*found = np;
|
|
|
|
*index = res;
|
|
|
|
return 0;
|
|
|
|
}
|
2013-01-21 21:10:57 +08:00
|
|
|
|
|
|
|
for_each_child_of_node(np, np0) {
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
struct device_node *fc;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
res = of_dev_hwmod_lookup(np0, oh, &i, &fc);
|
|
|
|
if (res == 0) {
|
|
|
|
*found = fc;
|
|
|
|
*index = i;
|
|
|
|
return 0;
|
2013-01-21 21:10:57 +08:00
|
|
|
}
|
|
|
|
}
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
|
|
|
|
*found = NULL;
|
|
|
|
*index = 0;
|
|
|
|
|
|
|
|
return -ENODEV;
|
2013-01-21 21:10:57 +08:00
|
|
|
}
|
|
|
|
|
2012-04-19 14:58:22 +08:00
|
|
|
/**
|
|
|
|
* _init_mpu_rt_base - populate the virtual address for a hwmod
|
|
|
|
* @oh: struct omap_hwmod * to locate the virtual address
|
2013-10-09 15:26:55 +08:00
|
|
|
* @data: (unused, caller should pass NULL)
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
* @index: index of the reg entry iospace in device tree
|
2013-10-09 15:26:55 +08:00
|
|
|
* @np: struct device_node * of the IP block's device node in the DT data
|
2012-04-19 14:58:22 +08:00
|
|
|
*
|
|
|
|
* Cache the virtual address used by the MPU to access this IP block's
|
|
|
|
* registers. This address is needed early so the OCP registers that
|
|
|
|
* are part of the device's address space can be ioremapped properly.
|
2013-10-09 13:46:49 +08:00
|
|
|
*
|
|
|
|
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
|
|
|
|
* -ENXIO on absent or invalid register target address space.
|
2012-04-19 14:58:22 +08:00
|
|
|
*/
|
2013-10-09 15:26:55 +08:00
|
|
|
static int __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data,
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
int index, struct device_node *np)
|
2012-04-19 14:58:22 +08:00
|
|
|
{
|
2012-04-19 09:10:05 +08:00
|
|
|
struct omap_hwmod_addr_space *mem;
|
2013-01-21 21:10:57 +08:00
|
|
|
void __iomem *va_start = NULL;
|
2012-04-19 09:10:05 +08:00
|
|
|
|
|
|
|
if (!oh)
|
2013-10-09 13:46:49 +08:00
|
|
|
return -EINVAL;
|
2012-04-19 09:10:05 +08:00
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
_save_mpu_port_index(oh);
|
|
|
|
|
2012-04-19 14:58:22 +08:00
|
|
|
if (oh->_int_flags & _HWMOD_NO_MPU_PORT)
|
2013-10-09 13:46:49 +08:00
|
|
|
return -ENXIO;
|
2012-04-19 14:58:22 +08:00
|
|
|
|
2012-04-19 09:10:05 +08:00
|
|
|
mem = _find_mpu_rt_addr_space(oh);
|
|
|
|
if (!mem) {
|
|
|
|
pr_debug("omap_hwmod: %s: no MPU register target found\n",
|
|
|
|
oh->name);
|
2013-01-21 21:10:57 +08:00
|
|
|
|
|
|
|
/* Extract the IO space from device tree blob */
|
2013-10-09 15:26:55 +08:00
|
|
|
if (!np)
|
2013-10-09 13:46:49 +08:00
|
|
|
return -ENXIO;
|
2013-01-21 21:10:57 +08:00
|
|
|
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
va_start = of_iomap(np, index + oh->mpu_rt_idx);
|
2013-01-21 21:10:57 +08:00
|
|
|
} else {
|
|
|
|
va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start);
|
2012-04-19 09:10:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!va_start) {
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
if (mem)
|
|
|
|
pr_err("omap_hwmod: %s: Could not ioremap\n", oh->name);
|
|
|
|
else
|
|
|
|
pr_err("omap_hwmod: %s: Missing dt reg%i for %s\n",
|
|
|
|
oh->name, index, np->full_name);
|
2013-10-09 13:46:49 +08:00
|
|
|
return -ENXIO;
|
2012-04-19 09:10:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: MPU register target at va %p\n",
|
|
|
|
oh->name, va_start);
|
|
|
|
|
|
|
|
oh->_mpu_rt_va = va_start;
|
2013-10-09 13:46:49 +08:00
|
|
|
return 0;
|
2012-04-19 14:58:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _init - initialize internal data for the hwmod @oh
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @n: (unused)
|
|
|
|
*
|
|
|
|
* Look up the clocks and the address space used by the MPU to access
|
|
|
|
* registers belonging to the hwmod @oh. @oh must already be
|
|
|
|
* registered at this point. This is the first of two phases for
|
|
|
|
* hwmod initialization. Code called here does not touch any hardware
|
|
|
|
* registers, it simply prepares internal data structures. Returns 0
|
2013-10-09 13:46:49 +08:00
|
|
|
* upon success or if the hwmod isn't registered or if the hwmod's
|
|
|
|
* address space is not defined, or -EINVAL upon failure.
|
2012-04-19 14:58:22 +08:00
|
|
|
*/
|
|
|
|
static int __init _init(struct omap_hwmod *oh, void *data)
|
|
|
|
{
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
int r, index;
|
2013-10-09 15:26:55 +08:00
|
|
|
struct device_node *np = NULL;
|
2012-04-19 14:58:22 +08:00
|
|
|
|
|
|
|
if (oh->_state != _HWMOD_STATE_REGISTERED)
|
|
|
|
return 0;
|
|
|
|
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
if (of_have_populated_dt()) {
|
|
|
|
struct device_node *bus;
|
|
|
|
|
|
|
|
bus = of_find_node_by_name(NULL, "ocp");
|
|
|
|
if (!bus)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
r = of_dev_hwmod_lookup(bus, oh, &index, &np);
|
|
|
|
if (r)
|
|
|
|
pr_debug("omap_hwmod: %s missing dt data\n", oh->name);
|
|
|
|
else if (np && index)
|
|
|
|
pr_warn("omap_hwmod: %s using broken dt data from %s\n",
|
|
|
|
oh->name, np->name);
|
|
|
|
}
|
2013-10-09 15:26:55 +08:00
|
|
|
|
2013-10-09 13:46:49 +08:00
|
|
|
if (oh->class->sysc) {
|
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-07 06:20:16 +08:00
|
|
|
r = _init_mpu_rt_base(oh, NULL, index, np);
|
2013-10-09 13:46:49 +08:00
|
|
|
if (r < 0) {
|
|
|
|
WARN(1, "omap_hwmod: %s: doesn't have mpu register target base\n",
|
|
|
|
oh->name);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
2012-04-19 14:58:22 +08:00
|
|
|
|
|
|
|
r = _init_clocks(oh, NULL);
|
ARM: OMAP: use consistent error checking
Consistently check errors using the usual method used in the kernel
for much of its history. For instance:
int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
int div;
div = gpmc_calc_divider(t->sync_clk);
if (div < 0)
return div;
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
{
...
return gpmc_cs_set_timings(cs, t);
.....
ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
if (IS_ERR_VALUE(ret))
return ret;
So, gpmc_cs_set_timings() thinks any negative return value is an error,
but where we check that in higher levels, only a limited range are
errors...
There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
appropriate, and that is in arch/arm/include/asm/syscall.h:
static inline long syscall_get_error(struct task_struct *task,
struct pt_regs *regs)
{
unsigned long error = regs->ARM_r0;
return IS_ERR_VALUE(error) ? error : 0;
}
because this function really does have to differentiate between error
return values and addresses which look like negative numbers (eg, from
mmap()).
So, here's a patch to remove them from OMAP, except for the above.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-03-14 04:44:21 +08:00
|
|
|
if (r < 0) {
|
2012-04-19 14:58:22 +08:00
|
|
|
WARN(1, "omap_hwmod: %s: couldn't init clocks\n", oh->name);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-03-14 17:15:17 +08:00
|
|
|
if (np) {
|
2013-10-09 15:26:55 +08:00
|
|
|
if (of_find_property(np, "ti,no-reset-on-init", NULL))
|
|
|
|
oh->flags |= HWMOD_INIT_NO_RESET;
|
|
|
|
if (of_find_property(np, "ti,no-idle-on-init", NULL))
|
|
|
|
oh->flags |= HWMOD_INIT_NO_IDLE;
|
2014-03-14 17:15:17 +08:00
|
|
|
}
|
2013-10-09 15:26:55 +08:00
|
|
|
|
2012-04-19 14:58:22 +08:00
|
|
|
oh->_state = _HWMOD_STATE_INITIALIZED;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
2012-04-19 09:10:03 +08:00
|
|
|
* _setup_iclk_autoidle - configure an IP block's interface clocks
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2012-04-19 09:10:03 +08:00
|
|
|
* Set up the module's interface clocks. XXX This function is still mostly
|
|
|
|
* a stub; implementing this properly requires iclk autoidle usecounting in
|
|
|
|
* the clock code. No return value.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
2012-04-19 09:10:03 +08:00
|
|
|
static void __init _setup_iclk_autoidle(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2012-04-19 18:04:28 +08:00
|
|
|
struct omap_hwmod_ocp_if *os;
|
2012-04-19 18:04:32 +08:00
|
|
|
struct list_head *p;
|
2012-04-19 18:04:28 +08:00
|
|
|
int i = 0;
|
2012-04-19 14:58:22 +08:00
|
|
|
if (oh->_state != _HWMOD_STATE_INITIALIZED)
|
2012-04-19 09:10:03 +08:00
|
|
|
return;
|
2011-02-23 15:14:07 +08:00
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
p = oh->slave_ports.next;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
while (i < oh->slaves_cnt) {
|
2012-04-19 18:04:32 +08:00
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
2012-04-19 18:04:28 +08:00
|
|
|
if (!os->_clk)
|
2012-04-19 09:10:03 +08:00
|
|
|
continue;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 09:10:03 +08:00
|
|
|
if (os->flags & OCPIF_SWSUP_IDLE) {
|
|
|
|
/* XXX omap_iclk_deny_idle(c); */
|
|
|
|
} else {
|
|
|
|
/* XXX omap_iclk_allow_idle(c); */
|
2012-04-19 18:04:28 +08:00
|
|
|
clk_enable(os->_clk);
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-19 09:10:03 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _setup_reset - reset an IP block during the setup process
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Reset the IP block corresponding to the hwmod @oh during the setup
|
|
|
|
* process. The IP block is first enabled so it can be successfully
|
|
|
|
* reset. Returns 0 upon success or a negative error code upon
|
|
|
|
* failure.
|
|
|
|
*/
|
|
|
|
static int __init _setup_reset(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
|
|
|
if (oh->_state != _HWMOD_STATE_INITIALIZED)
|
|
|
|
return -EINVAL;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-10-30 12:11:50 +08:00
|
|
|
if (oh->flags & HWMOD_EXT_OPT_MAIN_CLK)
|
|
|
|
return -EPERM;
|
|
|
|
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
if (oh->rst_lines_cnt == 0) {
|
|
|
|
r = _enable(oh);
|
|
|
|
if (r) {
|
2014-09-14 02:31:16 +08:00
|
|
|
pr_warn("omap_hwmod: %s: cannot be enabled for reset (%d)\n",
|
|
|
|
oh->name, oh->_state);
|
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 09:10:04 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2010-05-21 02:31:08 +08:00
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-03-14 01:25:23 +08:00
|
|
|
if (!(oh->flags & HWMOD_INIT_NO_RESET))
|
2012-04-19 09:10:03 +08:00
|
|
|
r = _reset(oh);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _setup_postsetup - transition to the appropriate state after _setup
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Place an IP block represented by @oh into a "post-setup" state --
|
|
|
|
* either IDLE, ENABLED, or DISABLED. ("post-setup" simply means that
|
|
|
|
* this function is called at the end of _setup().) The postsetup
|
|
|
|
* state for an IP block can be changed by calling
|
|
|
|
* omap_hwmod_enter_postsetup_state() early in the boot process,
|
|
|
|
* before one of the omap_hwmod_setup*() functions are called for the
|
|
|
|
* IP block.
|
|
|
|
*
|
|
|
|
* The IP block stays in this state until a PM runtime-based driver is
|
|
|
|
* loaded for that IP block. A post-setup state of IDLE is
|
|
|
|
* appropriate for almost all IP blocks with runtime PM-enabled
|
|
|
|
* drivers, since those drivers are able to enable the IP block. A
|
|
|
|
* post-setup state of ENABLED is appropriate for kernels with PM
|
|
|
|
* runtime disabled. The DISABLED state is appropriate for unusual IP
|
|
|
|
* blocks such as the MPU WDTIMER on kernels without WDTIMER drivers
|
|
|
|
* included, since the WDTIMER starts running on reset and will reset
|
|
|
|
* the MPU if left active.
|
|
|
|
*
|
|
|
|
* This post-setup mechanism is deprecated. Once all of the OMAP
|
|
|
|
* drivers have been converted to use PM runtime, and all of the IP
|
|
|
|
* block data and interconnect data is available to the hwmod code, it
|
|
|
|
* should be possible to replace this mechanism with a "lazy reset"
|
|
|
|
* arrangement. In a "lazy reset" setup, each IP block is enabled
|
|
|
|
* when the driver first probes, then all remaining IP blocks without
|
|
|
|
* drivers are either shut down or enabled after the drivers have
|
|
|
|
* loaded. However, this cannot take place until the above
|
|
|
|
* preconditions have been met, since otherwise the late reset code
|
|
|
|
* has no way of knowing which IP blocks are in use by drivers, and
|
|
|
|
* which ones are unused.
|
|
|
|
*
|
|
|
|
* No return value.
|
|
|
|
*/
|
|
|
|
static void __init _setup_postsetup(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
u8 postsetup_state;
|
|
|
|
|
|
|
|
if (oh->rst_lines_cnt > 0)
|
|
|
|
return;
|
2010-09-22 00:34:11 +08:00
|
|
|
|
2010-12-15 03:42:35 +08:00
|
|
|
postsetup_state = oh->_postsetup_state;
|
|
|
|
if (postsetup_state == _HWMOD_STATE_UNKNOWN)
|
|
|
|
postsetup_state = _HWMOD_STATE_ENABLED;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX HWMOD_INIT_NO_IDLE does not belong in hwmod data -
|
|
|
|
* it should be set by the core code as a runtime flag during startup
|
|
|
|
*/
|
|
|
|
if ((oh->flags & HWMOD_INIT_NO_IDLE) &&
|
2011-12-16 20:50:12 +08:00
|
|
|
(postsetup_state == _HWMOD_STATE_IDLE)) {
|
|
|
|
oh->_int_flags |= _HWMOD_SKIP_ENABLE;
|
2010-12-15 03:42:35 +08:00
|
|
|
postsetup_state = _HWMOD_STATE_ENABLED;
|
2011-12-16 20:50:12 +08:00
|
|
|
}
|
2010-12-15 03:42:35 +08:00
|
|
|
|
|
|
|
if (postsetup_state == _HWMOD_STATE_IDLE)
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
_idle(oh);
|
2010-12-15 03:42:35 +08:00
|
|
|
else if (postsetup_state == _HWMOD_STATE_DISABLED)
|
|
|
|
_shutdown(oh);
|
|
|
|
else if (postsetup_state != _HWMOD_STATE_ENABLED)
|
|
|
|
WARN(1, "hwmod: %s: unknown postsetup state %d! defaulting to enabled\n",
|
|
|
|
oh->name, postsetup_state);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 09:10:03 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _setup - prepare IP block hardware for use
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @n: (unused, pass NULL)
|
|
|
|
*
|
|
|
|
* Configure the IP block represented by @oh. This may include
|
|
|
|
* enabling the IP block, resetting it, and placing it into a
|
|
|
|
* post-setup state, depending on the type of IP block and applicable
|
|
|
|
* flags. IP blocks are reset to prevent any previous configuration
|
|
|
|
* by the bootloader or previous operating system from interfering
|
|
|
|
* with power management or other parts of the system. The reset can
|
|
|
|
* be avoided; see omap_hwmod_no_setup_reset(). This is the second of
|
|
|
|
* two phases for hwmod initialization. Code called here generally
|
|
|
|
* affects the IP block hardware, or system integration hardware
|
|
|
|
* associated with the IP block. Returns 0.
|
|
|
|
*/
|
|
|
|
static int __init _setup(struct omap_hwmod *oh, void *data)
|
|
|
|
{
|
|
|
|
if (oh->_state != _HWMOD_STATE_INITIALIZED)
|
|
|
|
return 0;
|
|
|
|
|
2014-10-09 22:03:14 +08:00
|
|
|
if (oh->parent_hwmod) {
|
|
|
|
int r;
|
|
|
|
|
|
|
|
r = _enable(oh->parent_hwmod);
|
|
|
|
WARN(r, "hwmod: %s: setup: failed to enable parent hwmod %s\n",
|
|
|
|
oh->name, oh->parent_hwmod->name);
|
|
|
|
}
|
|
|
|
|
2012-04-19 09:10:03 +08:00
|
|
|
_setup_iclk_autoidle(oh);
|
|
|
|
|
|
|
|
if (!_setup_reset(oh))
|
|
|
|
_setup_postsetup(oh);
|
|
|
|
|
2014-10-09 22:03:14 +08:00
|
|
|
if (oh->parent_hwmod) {
|
|
|
|
u8 postsetup_state;
|
|
|
|
|
|
|
|
postsetup_state = oh->parent_hwmod->_postsetup_state;
|
|
|
|
|
|
|
|
if (postsetup_state == _HWMOD_STATE_IDLE)
|
|
|
|
_idle(oh->parent_hwmod);
|
|
|
|
else if (postsetup_state == _HWMOD_STATE_DISABLED)
|
|
|
|
_shutdown(oh->parent_hwmod);
|
|
|
|
else if (postsetup_state != _HWMOD_STATE_ENABLED)
|
|
|
|
WARN(1, "hwmod: %s: unknown postsetup state %d! defaulting to enabled\n",
|
|
|
|
oh->parent_hwmod->name, postsetup_state);
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2010-12-22 12:31:27 +08:00
|
|
|
* _register - register a struct omap_hwmod
|
2009-09-04 01:14:03 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2010-02-23 13:09:34 +08:00
|
|
|
* Registers the omap_hwmod @oh. Returns -EEXIST if an omap_hwmod
|
|
|
|
* already has been registered by the same name; -EINVAL if the
|
|
|
|
* omap_hwmod is in the wrong state, if @oh is NULL, if the
|
|
|
|
* omap_hwmod's class field is NULL; if the omap_hwmod is missing a
|
|
|
|
* name, or if the omap_hwmod's class is missing a name; or 0 upon
|
|
|
|
* success.
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
|
|
|
* XXX The data should be copied into bootmem, so the original data
|
|
|
|
* should be marked __initdata and freed after init. This would allow
|
|
|
|
* unneeded omap_hwmods to be freed on multi-OMAP configurations. Note
|
|
|
|
* that the copy process would be relatively complex due to the large number
|
|
|
|
* of substructures.
|
|
|
|
*/
|
2010-12-22 12:31:28 +08:00
|
|
|
static int __init _register(struct omap_hwmod *oh)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2010-02-23 13:09:34 +08:00
|
|
|
if (!oh || !oh->name || !oh->class || !oh->class->name ||
|
|
|
|
(oh->_state != _HWMOD_STATE_UNKNOWN))
|
2009-09-04 01:14:03 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: registering\n", oh->name);
|
|
|
|
|
2010-12-22 12:31:28 +08:00
|
|
|
if (_lookup(oh->name))
|
|
|
|
return -EEXIST;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
list_add_tail(&oh->node, &omap_hwmod_list);
|
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
INIT_LIST_HEAD(&oh->master_ports);
|
|
|
|
INIT_LIST_HEAD(&oh->slave_ports);
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_lock_init(&oh->_lock);
|
2015-02-26 15:00:51 +08:00
|
|
|
lockdep_set_class(&oh->_lock, &oh->hwmod_key);
|
2010-12-15 03:42:35 +08:00
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
oh->_state = _HWMOD_STATE_REGISTERED;
|
|
|
|
|
2011-02-23 15:14:06 +08:00
|
|
|
/*
|
|
|
|
* XXX Rather than doing a strcmp(), this should test a flag
|
|
|
|
* set in the hwmod data, inserted by the autogenerator code.
|
|
|
|
*/
|
|
|
|
if (!strcmp(oh->name, MPU_INITIATOR_NAME))
|
|
|
|
mpu_oh = oh;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2011-02-23 15:14:06 +08:00
|
|
|
return 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
/**
|
|
|
|
* _alloc_links - return allocated memory for hwmod links
|
|
|
|
* @ml: pointer to a struct omap_hwmod_link * for the master link
|
|
|
|
* @sl: pointer to a struct omap_hwmod_link * for the slave link
|
|
|
|
*
|
|
|
|
* Return pointers to two struct omap_hwmod_link records, via the
|
|
|
|
* addresses pointed to by @ml and @sl. Will first attempt to return
|
|
|
|
* memory allocated as part of a large initial block, but if that has
|
|
|
|
* been exhausted, will allocate memory itself. Since ideally this
|
|
|
|
* second allocation path will never occur, the number of these
|
|
|
|
* 'supplemental' allocations will be logged when debugging is
|
|
|
|
* enabled. Returns 0.
|
|
|
|
*/
|
|
|
|
static int __init _alloc_links(struct omap_hwmod_link **ml,
|
|
|
|
struct omap_hwmod_link **sl)
|
|
|
|
{
|
|
|
|
unsigned int sz;
|
|
|
|
|
|
|
|
if ((free_ls + LINKS_PER_OCP_IF) <= max_ls) {
|
|
|
|
*ml = &linkspace[free_ls++];
|
|
|
|
*sl = &linkspace[free_ls++];
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
sz = sizeof(struct omap_hwmod_link) * LINKS_PER_OCP_IF;
|
|
|
|
|
|
|
|
*sl = NULL;
|
2014-01-22 07:50:51 +08:00
|
|
|
*ml = memblock_virt_alloc(sz, 0);
|
2012-04-19 18:04:30 +08:00
|
|
|
|
|
|
|
*sl = (void *)(*ml) + sizeof(struct omap_hwmod_link);
|
|
|
|
|
|
|
|
ls_supp++;
|
|
|
|
pr_debug("omap_hwmod: supplemental link allocations needed: %d\n",
|
|
|
|
ls_supp * LINKS_PER_OCP_IF);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _add_link - add an interconnect between two IP blocks
|
|
|
|
* @oi: pointer to a struct omap_hwmod_ocp_if record
|
|
|
|
*
|
|
|
|
* Add struct omap_hwmod_link records connecting the master IP block
|
|
|
|
* specified in @oi->master to @oi, and connecting the slave IP block
|
|
|
|
* specified in @oi->slave to @oi. This code is assumed to run before
|
|
|
|
* preemption or SMP has been enabled, thus avoiding the need for
|
|
|
|
* locking in this code. Changes to this assumption will require
|
|
|
|
* additional locking. Returns 0.
|
|
|
|
*/
|
|
|
|
static int __init _add_link(struct omap_hwmod_ocp_if *oi)
|
|
|
|
{
|
|
|
|
struct omap_hwmod_link *ml, *sl;
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s -> %s: adding link\n", oi->master->name,
|
|
|
|
oi->slave->name);
|
|
|
|
|
|
|
|
_alloc_links(&ml, &sl);
|
|
|
|
|
|
|
|
ml->ocp_if = oi;
|
|
|
|
list_add(&ml->node, &oi->master->master_ports);
|
|
|
|
oi->master->masters_cnt++;
|
|
|
|
|
|
|
|
sl->ocp_if = oi;
|
|
|
|
list_add(&sl->node, &oi->slave->slave_ports);
|
|
|
|
oi->slave->slaves_cnt++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _register_link - register a struct omap_hwmod_ocp_if
|
|
|
|
* @oi: struct omap_hwmod_ocp_if *
|
|
|
|
*
|
|
|
|
* Registers the omap_hwmod_ocp_if record @oi. Returns -EEXIST if it
|
|
|
|
* has already been registered; -EINVAL if @oi is NULL or if the
|
|
|
|
* record pointed to by @oi is missing required fields; or 0 upon
|
|
|
|
* success.
|
|
|
|
*
|
|
|
|
* XXX The data should be copied into bootmem, so the original data
|
|
|
|
* should be marked __initdata and freed after init. This would allow
|
|
|
|
* unneeded omap_hwmods to be freed on multi-OMAP configurations.
|
|
|
|
*/
|
|
|
|
static int __init _register_link(struct omap_hwmod_ocp_if *oi)
|
|
|
|
{
|
|
|
|
if (!oi || !oi->master || !oi->slave || !oi->user)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (oi->_int_flags & _OCPIF_INT_FLAGS_REGISTERED)
|
|
|
|
return -EEXIST;
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: registering link from %s to %s\n",
|
|
|
|
oi->master->name, oi->slave->name);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Register the connected hwmods, if they haven't been
|
|
|
|
* registered already
|
|
|
|
*/
|
|
|
|
if (oi->master->_state != _HWMOD_STATE_REGISTERED)
|
|
|
|
_register(oi->master);
|
|
|
|
|
|
|
|
if (oi->slave->_state != _HWMOD_STATE_REGISTERED)
|
|
|
|
_register(oi->slave);
|
|
|
|
|
|
|
|
_add_link(oi);
|
|
|
|
|
|
|
|
oi->_int_flags |= _OCPIF_INT_FLAGS_REGISTERED;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _alloc_linkspace - allocate large block of hwmod links
|
|
|
|
* @ois: pointer to an array of struct omap_hwmod_ocp_if records to count
|
|
|
|
*
|
|
|
|
* Allocate a large block of struct omap_hwmod_link records. This
|
|
|
|
* improves boot time significantly by avoiding the need to allocate
|
|
|
|
* individual records one by one. If the number of records to
|
|
|
|
* allocate in the block hasn't been manually specified, this function
|
|
|
|
* will count the number of struct omap_hwmod_ocp_if records in @ois
|
|
|
|
* and use that to determine the allocation size. For SoC families
|
|
|
|
* that require multiple list registrations, such as OMAP3xxx, this
|
|
|
|
* estimation process isn't optimal, so manual estimation is advised
|
|
|
|
* in those cases. Returns -EEXIST if the allocation has already occurred
|
|
|
|
* or 0 upon success.
|
|
|
|
*/
|
|
|
|
static int __init _alloc_linkspace(struct omap_hwmod_ocp_if **ois)
|
|
|
|
{
|
|
|
|
unsigned int i = 0;
|
|
|
|
unsigned int sz;
|
|
|
|
|
|
|
|
if (linkspace) {
|
|
|
|
WARN(1, "linkspace already allocated\n");
|
|
|
|
return -EEXIST;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (max_ls == 0)
|
|
|
|
while (ois[i++])
|
|
|
|
max_ls += LINKS_PER_OCP_IF;
|
|
|
|
|
|
|
|
sz = sizeof(struct omap_hwmod_link) * max_ls;
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: allocating %d byte linkspace (%d links)\n",
|
|
|
|
__func__, sz, max_ls);
|
|
|
|
|
2014-01-22 07:50:51 +08:00
|
|
|
linkspace = memblock_virt_alloc(sz, 0);
|
2012-04-19 18:04:30 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2010-12-22 12:31:27 +08:00
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
/* Static functions intended only for use in soc_ops field function pointers */
|
|
|
|
|
|
|
|
/**
|
2014-10-27 23:39:23 +08:00
|
|
|
* _omap2xxx_3xxx_wait_target_ready - wait for a module to leave slave idle
|
2012-06-19 02:12:24 +08:00
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Wait for a module @oh to leave slave idle. Returns 0 if the module
|
|
|
|
* does not have an IDLEST bit or if the module successfully leaves
|
|
|
|
* slave idle; otherwise, pass along the return value of the
|
|
|
|
* appropriate *_cm*_wait_module_ready() function.
|
|
|
|
*/
|
2014-10-27 23:39:23 +08:00
|
|
|
static int _omap2xxx_3xxx_wait_target_ready(struct omap_hwmod *oh)
|
2012-06-19 02:12:24 +08:00
|
|
|
{
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (oh->flags & HWMOD_NO_IDLEST)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!_find_mpu_rt_port(oh))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* XXX check module SIDLEMODE, hardreset status, enabled clocks */
|
|
|
|
|
2014-10-27 23:39:23 +08:00
|
|
|
return omap_cm_wait_module_ready(0, oh->prcm.omap2.module_offs,
|
|
|
|
oh->prcm.omap2.idlest_reg_id,
|
|
|
|
oh->prcm.omap2.idlest_idle_bit);
|
2012-06-19 02:12:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _omap4_wait_target_ready - wait for a module to leave slave idle
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Wait for a module @oh to leave slave idle. Returns 0 if the module
|
|
|
|
* does not have an IDLEST bit or if the module successfully leaves
|
|
|
|
* slave idle; otherwise, pass along the return value of the
|
|
|
|
* appropriate *_cm*_wait_module_ready() function.
|
|
|
|
*/
|
|
|
|
static int _omap4_wait_target_ready(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-09-24 07:28:18 +08:00
|
|
|
if (!oh)
|
2012-06-19 02:12:24 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2012-09-24 07:28:18 +08:00
|
|
|
if (oh->flags & HWMOD_NO_IDLEST || !oh->clkdm)
|
2012-06-19 02:12:24 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!_find_mpu_rt_port(oh))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* XXX check module SIDLEMODE, hardreset status */
|
|
|
|
|
2014-10-27 23:39:23 +08:00
|
|
|
return omap_cm_wait_module_ready(oh->clkdm->prcm_partition,
|
|
|
|
oh->clkdm->cm_inst,
|
|
|
|
oh->prcm.omap4.clkctrl_offs, 0);
|
2012-09-12 07:18:53 +08:00
|
|
|
}
|
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
/**
|
|
|
|
* _omap2_assert_hardreset - call OMAP2 PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to assert hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call omap2_prm_assert_hardreset() with parameters extracted from
|
|
|
|
* the hwmod @oh and the hardreset line data @ohri. Only intended for
|
|
|
|
* use as an soc_ops function pointer. Passes along the return value
|
|
|
|
* from omap2_prm_assert_hardreset(). XXX This function is scheduled
|
|
|
|
* for removal when the PRM code is moved into drivers/.
|
|
|
|
*/
|
|
|
|
static int _omap2_assert_hardreset(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2014-10-27 23:39:24 +08:00
|
|
|
return omap_prm_assert_hardreset(ohri->rst_shift, 0,
|
|
|
|
oh->prcm.omap2.module_offs, 0);
|
2012-06-19 02:12:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _omap2_deassert_hardreset - call OMAP2 PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to deassert hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call omap2_prm_deassert_hardreset() with parameters extracted from
|
|
|
|
* the hwmod @oh and the hardreset line data @ohri. Only intended for
|
|
|
|
* use as an soc_ops function pointer. Passes along the return value
|
|
|
|
* from omap2_prm_deassert_hardreset(). XXX This function is
|
|
|
|
* scheduled for removal when the PRM code is moved into drivers/.
|
|
|
|
*/
|
|
|
|
static int _omap2_deassert_hardreset(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2014-10-27 23:39:25 +08:00
|
|
|
return omap_prm_deassert_hardreset(ohri->rst_shift, ohri->st_shift, 0,
|
|
|
|
oh->prcm.omap2.module_offs, 0, 0);
|
2012-06-19 02:12:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _omap2_is_hardreset_asserted - call OMAP2 PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to test hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call omap2_prm_is_hardreset_asserted() with parameters extracted
|
|
|
|
* from the hwmod @oh and the hardreset line data @ohri. Only
|
|
|
|
* intended for use as an soc_ops function pointer. Passes along the
|
|
|
|
* return value from omap2_prm_is_hardreset_asserted(). XXX This
|
|
|
|
* function is scheduled for removal when the PRM code is moved into
|
|
|
|
* drivers/.
|
|
|
|
*/
|
|
|
|
static int _omap2_is_hardreset_asserted(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2014-10-27 23:39:25 +08:00
|
|
|
return omap_prm_is_hardreset_asserted(ohri->st_shift, 0,
|
|
|
|
oh->prcm.omap2.module_offs, 0);
|
2012-06-19 02:12:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _omap4_assert_hardreset - call OMAP4 PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to assert hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call omap4_prminst_assert_hardreset() with parameters extracted
|
|
|
|
* from the hwmod @oh and the hardreset line data @ohri. Only
|
|
|
|
* intended for use as an soc_ops function pointer. Passes along the
|
|
|
|
* return value from omap4_prminst_assert_hardreset(). XXX This
|
|
|
|
* function is scheduled for removal when the PRM code is moved into
|
|
|
|
* drivers/.
|
|
|
|
*/
|
|
|
|
static int _omap4_assert_hardreset(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2012-06-21 10:11:36 +08:00
|
|
|
if (!oh->clkdm)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-10-27 23:39:24 +08:00
|
|
|
return omap_prm_assert_hardreset(ohri->rst_shift,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_partition,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.rstctrl_offs);
|
2012-06-19 02:12:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _omap4_deassert_hardreset - call OMAP4 PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to deassert hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call omap4_prminst_deassert_hardreset() with parameters extracted
|
|
|
|
* from the hwmod @oh and the hardreset line data @ohri. Only
|
|
|
|
* intended for use as an soc_ops function pointer. Passes along the
|
|
|
|
* return value from omap4_prminst_deassert_hardreset(). XXX This
|
|
|
|
* function is scheduled for removal when the PRM code is moved into
|
|
|
|
* drivers/.
|
|
|
|
*/
|
|
|
|
static int _omap4_deassert_hardreset(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2012-06-21 10:11:36 +08:00
|
|
|
if (!oh->clkdm)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-06-19 02:12:24 +08:00
|
|
|
if (ohri->st_shift)
|
|
|
|
pr_err("omap_hwmod: %s: %s: hwmod data error: OMAP4 does not support st_shift\n",
|
|
|
|
oh->name, ohri->name);
|
2014-10-27 23:39:25 +08:00
|
|
|
return omap_prm_deassert_hardreset(ohri->rst_shift, 0,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_partition,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.rstctrl_offs, 0);
|
2012-06-19 02:12:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _omap4_is_hardreset_asserted - call OMAP4 PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to test hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call omap4_prminst_is_hardreset_asserted() with parameters
|
|
|
|
* extracted from the hwmod @oh and the hardreset line data @ohri.
|
|
|
|
* Only intended for use as an soc_ops function pointer. Passes along
|
|
|
|
* the return value from omap4_prminst_is_hardreset_asserted(). XXX
|
|
|
|
* This function is scheduled for removal when the PRM code is moved
|
|
|
|
* into drivers/.
|
|
|
|
*/
|
|
|
|
static int _omap4_is_hardreset_asserted(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2012-06-21 10:11:36 +08:00
|
|
|
if (!oh->clkdm)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-10-27 23:39:25 +08:00
|
|
|
return omap_prm_is_hardreset_asserted(ohri->rst_shift,
|
|
|
|
oh->clkdm->pwrdm.ptr->
|
|
|
|
prcm_partition,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.rstctrl_offs);
|
2012-06-19 02:12:24 +08:00
|
|
|
}
|
|
|
|
|
2012-09-12 07:18:53 +08:00
|
|
|
/**
|
|
|
|
* _am33xx_assert_hardreset - call AM33XX PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to assert hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call am33xx_prminst_assert_hardreset() with parameters extracted
|
|
|
|
* from the hwmod @oh and the hardreset line data @ohri. Only
|
|
|
|
* intended for use as an soc_ops function pointer. Passes along the
|
|
|
|
* return value from am33xx_prminst_assert_hardreset(). XXX This
|
|
|
|
* function is scheduled for removal when the PRM code is moved into
|
|
|
|
* drivers/.
|
|
|
|
*/
|
|
|
|
static int _am33xx_assert_hardreset(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
|
|
|
|
{
|
2014-10-27 23:39:24 +08:00
|
|
|
return omap_prm_assert_hardreset(ohri->rst_shift, 0,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.rstctrl_offs);
|
2012-09-12 07:18:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _am33xx_deassert_hardreset - call AM33XX PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to deassert hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call am33xx_prminst_deassert_hardreset() with parameters extracted
|
|
|
|
* from the hwmod @oh and the hardreset line data @ohri. Only
|
|
|
|
* intended for use as an soc_ops function pointer. Passes along the
|
|
|
|
* return value from am33xx_prminst_deassert_hardreset(). XXX This
|
|
|
|
* function is scheduled for removal when the PRM code is moved into
|
|
|
|
* drivers/.
|
|
|
|
*/
|
|
|
|
static int _am33xx_deassert_hardreset(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2014-10-27 23:39:25 +08:00
|
|
|
return omap_prm_deassert_hardreset(ohri->rst_shift, ohri->st_shift, 0,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.rstctrl_offs,
|
|
|
|
oh->prcm.omap4.rstst_offs);
|
2012-09-12 07:18:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* _am33xx_is_hardreset_asserted - call AM33XX PRM hardreset fn with hwmod args
|
|
|
|
* @oh: struct omap_hwmod * to test hardreset
|
|
|
|
* @ohri: hardreset line data
|
|
|
|
*
|
|
|
|
* Call am33xx_prminst_is_hardreset_asserted() with parameters
|
|
|
|
* extracted from the hwmod @oh and the hardreset line data @ohri.
|
|
|
|
* Only intended for use as an soc_ops function pointer. Passes along
|
|
|
|
* the return value from am33xx_prminst_is_hardreset_asserted(). XXX
|
|
|
|
* This function is scheduled for removal when the PRM code is moved
|
|
|
|
* into drivers/.
|
|
|
|
*/
|
|
|
|
static int _am33xx_is_hardreset_asserted(struct omap_hwmod *oh,
|
|
|
|
struct omap_hwmod_rst_info *ohri)
|
|
|
|
{
|
2014-10-27 23:39:25 +08:00
|
|
|
return omap_prm_is_hardreset_asserted(ohri->rst_shift, 0,
|
|
|
|
oh->clkdm->pwrdm.ptr->prcm_offs,
|
|
|
|
oh->prcm.omap4.rstctrl_offs);
|
2012-09-12 07:18:53 +08:00
|
|
|
}
|
|
|
|
|
2010-12-22 12:31:27 +08:00
|
|
|
/* Public functions */
|
|
|
|
|
|
|
|
u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs)
|
|
|
|
{
|
|
|
|
if (oh->flags & HWMOD_16BIT_REG)
|
2014-04-16 01:37:46 +08:00
|
|
|
return readw_relaxed(oh->_mpu_rt_va + reg_offs);
|
2010-12-22 12:31:27 +08:00
|
|
|
else
|
2014-04-16 01:37:46 +08:00
|
|
|
return readl_relaxed(oh->_mpu_rt_va + reg_offs);
|
2010-12-22 12:31:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs)
|
|
|
|
{
|
|
|
|
if (oh->flags & HWMOD_16BIT_REG)
|
2014-04-16 01:37:46 +08:00
|
|
|
writew_relaxed(v, oh->_mpu_rt_va + reg_offs);
|
2010-12-22 12:31:27 +08:00
|
|
|
else
|
2014-04-16 01:37:46 +08:00
|
|
|
writel_relaxed(v, oh->_mpu_rt_va + reg_offs);
|
2010-12-22 12:31:27 +08:00
|
|
|
}
|
|
|
|
|
2011-07-10 19:27:16 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_softreset - reset a module via SYSCONFIG.SOFTRESET bit
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* This is a public function exposed to drivers. Some drivers may need to do
|
|
|
|
* some settings before and after resetting the device. Those drivers after
|
|
|
|
* doing the necessary settings could use this function to start a reset by
|
|
|
|
* setting the SYSCONFIG.SOFTRESET bit.
|
|
|
|
*/
|
|
|
|
int omap_hwmod_softreset(struct omap_hwmod *oh)
|
|
|
|
{
|
2012-04-13 19:08:43 +08:00
|
|
|
u32 v;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!oh || !(oh->_sysc_cache))
|
2011-07-10 19:27:16 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2012-04-13 19:08:43 +08:00
|
|
|
v = oh->_sysc_cache;
|
|
|
|
ret = _set_softreset(oh, &v);
|
|
|
|
if (ret)
|
|
|
|
goto error;
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
|
2013-12-09 09:39:02 +08:00
|
|
|
ret = _clear_softreset(oh, &v);
|
|
|
|
if (ret)
|
|
|
|
goto error;
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
|
2012-04-13 19:08:43 +08:00
|
|
|
error:
|
|
|
|
return ret;
|
2011-07-10 19:27:16 +08:00
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_lookup - look up a registered omap_hwmod by name
|
|
|
|
* @name: name of the omap_hwmod to look up
|
|
|
|
*
|
|
|
|
* Given a @name of an omap_hwmod, return a pointer to the registered
|
|
|
|
* struct omap_hwmod *, or NULL upon error.
|
|
|
|
*/
|
|
|
|
struct omap_hwmod *omap_hwmod_lookup(const char *name)
|
|
|
|
{
|
|
|
|
struct omap_hwmod *oh;
|
|
|
|
|
|
|
|
if (!name)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
oh = _lookup(name);
|
|
|
|
|
|
|
|
return oh;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_for_each - call function for each registered omap_hwmod
|
|
|
|
* @fn: pointer to a callback function
|
2010-07-27 06:34:30 +08:00
|
|
|
* @data: void * data to pass to callback function
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
|
|
|
* Call @fn for each registered omap_hwmod, passing @data to each
|
|
|
|
* function. @fn must return 0 for success or any other value for
|
|
|
|
* failure. If @fn returns non-zero, the iteration across omap_hwmods
|
|
|
|
* will stop and the non-zero return value will be passed to the
|
|
|
|
* caller of omap_hwmod_for_each(). @fn is called with
|
|
|
|
* omap_hwmod_for_each() held.
|
|
|
|
*/
|
2010-07-27 06:34:30 +08:00
|
|
|
int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
|
|
|
|
void *data)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
|
|
|
struct omap_hwmod *temp_oh;
|
2011-06-01 13:58:56 +08:00
|
|
|
int ret = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
if (!fn)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
|
2010-07-27 06:34:30 +08:00
|
|
|
ret = (*fn)(temp_oh, data);
|
2009-09-04 01:14:03 +08:00
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_register_links - register an array of hwmod links
|
|
|
|
* @ois: pointer to an array of omap_hwmod_ocp_if to register
|
|
|
|
*
|
|
|
|
* Intended to be called early in boot before the clock framework is
|
|
|
|
* initialized. If @ois is not null, will register all omap_hwmods
|
2012-06-19 02:12:23 +08:00
|
|
|
* listed in @ois that are valid for this chip. Returns -EINVAL if
|
|
|
|
* omap_hwmod_init() hasn't been called before calling this function,
|
|
|
|
* -ENOMEM if the link memory area can't be allocated, or 0 upon
|
|
|
|
* success.
|
2012-04-19 18:04:30 +08:00
|
|
|
*/
|
|
|
|
int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois)
|
|
|
|
{
|
|
|
|
int r, i;
|
|
|
|
|
2012-06-19 02:12:23 +08:00
|
|
|
if (!inited)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
if (!ois)
|
|
|
|
return 0;
|
|
|
|
|
2014-08-28 09:38:23 +08:00
|
|
|
if (ois[0] == NULL) /* Empty list */
|
|
|
|
return 0;
|
|
|
|
|
2012-04-19 18:04:30 +08:00
|
|
|
if (!linkspace) {
|
|
|
|
if (_alloc_linkspace(ois)) {
|
|
|
|
pr_err("omap_hwmod: could not allocate link space\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
do {
|
|
|
|
r = _register_link(ois[i]);
|
|
|
|
WARN(r && r != -EEXIST,
|
|
|
|
"omap_hwmod: _register_link(%s -> %s) returned %d\n",
|
|
|
|
ois[i]->master->name, ois[i]->slave->name, r);
|
|
|
|
} while (ois[++i]);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-04-19 14:58:22 +08:00
|
|
|
/**
|
|
|
|
* _ensure_mpu_hwmod_is_setup - ensure the MPU SS hwmod is init'ed and set up
|
|
|
|
* @oh: pointer to the hwmod currently being set up (usually not the MPU)
|
|
|
|
*
|
|
|
|
* If the hwmod data corresponding to the MPU subsystem IP block
|
|
|
|
* hasn't been initialized and set up yet, do so now. This must be
|
|
|
|
* done first since sleep dependencies may be added from other hwmods
|
|
|
|
* to the MPU. Intended to be called only by omap_hwmod_setup*(). No
|
|
|
|
* return value.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
2012-04-19 14:58:22 +08:00
|
|
|
static void __init _ensure_mpu_hwmod_is_setup(struct omap_hwmod *oh)
|
2011-02-15 07:40:21 +08:00
|
|
|
{
|
2012-04-19 14:58:22 +08:00
|
|
|
if (!mpu_oh || mpu_oh->_state == _HWMOD_STATE_UNKNOWN)
|
|
|
|
pr_err("omap_hwmod: %s: MPU initiator hwmod %s not yet registered\n",
|
|
|
|
__func__, MPU_INITIATOR_NAME);
|
|
|
|
else if (mpu_oh->_state == _HWMOD_STATE_REGISTERED && oh != mpu_oh)
|
|
|
|
omap_hwmod_setup_one(MPU_INITIATOR_NAME);
|
2011-02-15 07:40:21 +08:00
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
2011-02-23 15:14:07 +08:00
|
|
|
* omap_hwmod_setup_one - set up a single hwmod
|
|
|
|
* @oh_name: const char * name of the already-registered hwmod to set up
|
|
|
|
*
|
2012-04-19 14:58:22 +08:00
|
|
|
* Initialize and set up a single hwmod. Intended to be used for a
|
|
|
|
* small number of early devices, such as the timer IP blocks used for
|
|
|
|
* the scheduler clock. Must be called after omap2_clk_init().
|
|
|
|
* Resolves the struct clk names to struct clk pointers for each
|
|
|
|
* registered omap_hwmod. Also calls _setup() on each hwmod. Returns
|
|
|
|
* -EINVAL upon error or 0 upon success.
|
2011-02-23 15:14:07 +08:00
|
|
|
*/
|
|
|
|
int __init omap_hwmod_setup_one(const char *oh_name)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
|
|
|
struct omap_hwmod *oh;
|
|
|
|
|
2011-02-23 15:14:07 +08:00
|
|
|
pr_debug("omap_hwmod: %s: %s\n", oh_name, __func__);
|
|
|
|
|
|
|
|
oh = _lookup(oh_name);
|
|
|
|
if (!oh) {
|
|
|
|
WARN(1, "omap_hwmod: %s: hwmod not yet registered\n", oh_name);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 14:58:22 +08:00
|
|
|
_ensure_mpu_hwmod_is_setup(oh);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 14:58:22 +08:00
|
|
|
_init(oh, NULL);
|
2011-02-23 15:14:07 +08:00
|
|
|
_setup(oh, NULL);
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-04-19 14:58:22 +08:00
|
|
|
* omap_hwmod_setup_all - set up all registered IP blocks
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
2012-04-19 14:58:22 +08:00
|
|
|
* Initialize and set up all IP blocks registered with the hwmod code.
|
|
|
|
* Must be called after omap2_clk_init(). Resolves the struct clk
|
|
|
|
* names to struct clk pointers for each registered omap_hwmod. Also
|
|
|
|
* calls _setup() on each hwmod. Returns 0 upon success.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
2011-03-01 02:58:14 +08:00
|
|
|
static int __init omap_hwmod_setup_all(void)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2012-04-19 14:58:22 +08:00
|
|
|
_ensure_mpu_hwmod_is_setup(NULL);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-04-19 14:58:22 +08:00
|
|
|
omap_hwmod_for_each(_init, NULL);
|
2010-12-15 03:42:35 +08:00
|
|
|
omap_hwmod_for_each(_setup, NULL);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-01-12 03:24:18 +08:00
|
|
|
omap_core_initcall(omap_hwmod_setup_all);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_enable - enable an omap_hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2010-09-22 05:02:23 +08:00
|
|
|
* Enable an omap_hwmod @oh. Intended to be called by omap_device_enable().
|
2009-09-04 01:14:03 +08:00
|
|
|
* Returns -EINVAL on error or passes along the return value from _enable().
|
|
|
|
*/
|
|
|
|
int omap_hwmod_enable(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
int r;
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
|
|
|
r = _enable(oh);
|
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_idle - idle an omap_hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2010-09-22 05:02:23 +08:00
|
|
|
* Idle an omap_hwmod @oh. Intended to be called by omap_device_idle().
|
2009-09-04 01:14:03 +08:00
|
|
|
* Returns -EINVAL on error or passes along the return value from _idle().
|
|
|
|
*/
|
|
|
|
int omap_hwmod_idle(struct omap_hwmod *oh)
|
|
|
|
{
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
|
|
|
_idle(oh);
|
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_shutdown - shutdown an omap_hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
2010-09-22 05:02:23 +08:00
|
|
|
* Shutdown an omap_hwmod @oh. Intended to be called by
|
2009-09-04 01:14:03 +08:00
|
|
|
* omap_device_shutdown(). Returns -EINVAL on error or passes along
|
|
|
|
* the return value from _shutdown().
|
|
|
|
*/
|
|
|
|
int omap_hwmod_shutdown(struct omap_hwmod *oh)
|
|
|
|
{
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
2009-09-04 01:14:03 +08:00
|
|
|
_shutdown(oh);
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-04-19 09:10:06 +08:00
|
|
|
/*
|
|
|
|
* IP block data retrieval functions
|
|
|
|
*/
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_count_resources - count number of struct resources needed by hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
2012-11-22 07:15:17 +08:00
|
|
|
* @flags: Type of resources to include when counting (IRQ/DMA/MEM)
|
2009-09-04 01:14:03 +08:00
|
|
|
*
|
|
|
|
* Count the number of struct resource array elements necessary to
|
|
|
|
* contain omap_hwmod @oh resources. Intended to be called by code
|
|
|
|
* that registers omap_devices. Intended to be used to determine the
|
|
|
|
* size of a dynamically-allocated struct resource array, before
|
|
|
|
* calling omap_hwmod_fill_resources(). Returns the number of struct
|
|
|
|
* resource array elements needed.
|
|
|
|
*
|
|
|
|
* XXX This code is not optimized. It could attempt to merge adjacent
|
|
|
|
* resource IDs.
|
|
|
|
*
|
|
|
|
*/
|
2012-11-22 07:15:17 +08:00
|
|
|
int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
|
2009-09-04 01:14:03 +08:00
|
|
|
{
|
2012-11-22 07:15:17 +08:00
|
|
|
int ret = 0;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-11-22 07:15:17 +08:00
|
|
|
if (flags & IORESOURCE_IRQ)
|
|
|
|
ret += _count_mpu_irqs(oh);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2012-11-22 07:15:17 +08:00
|
|
|
if (flags & IORESOURCE_DMA)
|
|
|
|
ret += _count_sdma_reqs(oh);
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-11-22 07:15:17 +08:00
|
|
|
if (flags & IORESOURCE_MEM) {
|
|
|
|
int i = 0;
|
|
|
|
struct omap_hwmod_ocp_if *os;
|
|
|
|
struct list_head *p = oh->slave_ports.next;
|
|
|
|
|
|
|
|
while (i < oh->slaves_cnt) {
|
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
|
|
|
ret += _count_ocp_if_addr_spaces(os);
|
|
|
|
}
|
2012-04-19 18:04:28 +08:00
|
|
|
}
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_fill_resources - fill struct resource array with hwmod data
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @res: pointer to the first element of an array of struct resource to fill
|
|
|
|
*
|
|
|
|
* Fill the struct resource array @res with resource data from the
|
|
|
|
* omap_hwmod @oh. Intended to be called by code that registers
|
|
|
|
* omap_devices. See also omap_hwmod_count_resources(). Returns the
|
|
|
|
* number of array elements filled.
|
|
|
|
*/
|
|
|
|
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res)
|
|
|
|
{
|
2012-04-19 18:04:28 +08:00
|
|
|
struct omap_hwmod_ocp_if *os;
|
2012-04-19 18:04:32 +08:00
|
|
|
struct list_head *p;
|
2012-04-19 18:04:28 +08:00
|
|
|
int i, j, mpu_irqs_cnt, sdma_reqs_cnt, addr_cnt;
|
2009-09-04 01:14:03 +08:00
|
|
|
int r = 0;
|
|
|
|
|
|
|
|
/* For each IRQ, DMA, memory area, fill in array.*/
|
|
|
|
|
2011-07-10 09:14:06 +08:00
|
|
|
mpu_irqs_cnt = _count_mpu_irqs(oh);
|
|
|
|
for (i = 0; i < mpu_irqs_cnt; i++) {
|
2015-01-17 18:21:08 +08:00
|
|
|
unsigned int irq;
|
|
|
|
|
|
|
|
if (oh->xlate_irq)
|
|
|
|
irq = oh->xlate_irq((oh->mpu_irqs + i)->irq);
|
|
|
|
else
|
|
|
|
irq = (oh->mpu_irqs + i)->irq;
|
2009-12-09 07:34:16 +08:00
|
|
|
(res + r)->name = (oh->mpu_irqs + i)->name;
|
2015-01-17 18:21:08 +08:00
|
|
|
(res + r)->start = irq;
|
|
|
|
(res + r)->end = irq;
|
2009-09-04 01:14:03 +08:00
|
|
|
(res + r)->flags = IORESOURCE_IRQ;
|
|
|
|
r++;
|
|
|
|
}
|
|
|
|
|
2011-07-10 09:14:07 +08:00
|
|
|
sdma_reqs_cnt = _count_sdma_reqs(oh);
|
|
|
|
for (i = 0; i < sdma_reqs_cnt; i++) {
|
2010-09-22 00:34:08 +08:00
|
|
|
(res + r)->name = (oh->sdma_reqs + i)->name;
|
|
|
|
(res + r)->start = (oh->sdma_reqs + i)->dma_req;
|
|
|
|
(res + r)->end = (oh->sdma_reqs + i)->dma_req;
|
2009-09-04 01:14:03 +08:00
|
|
|
(res + r)->flags = IORESOURCE_DMA;
|
|
|
|
r++;
|
|
|
|
}
|
|
|
|
|
2012-04-19 18:04:32 +08:00
|
|
|
p = oh->slave_ports.next;
|
2012-04-19 18:04:30 +08:00
|
|
|
|
2012-04-19 18:04:28 +08:00
|
|
|
i = 0;
|
|
|
|
while (i < oh->slaves_cnt) {
|
2012-04-19 18:04:32 +08:00
|
|
|
os = _fetch_next_ocp_if(&p, &i);
|
2011-07-10 09:14:05 +08:00
|
|
|
addr_cnt = _count_ocp_if_addr_spaces(os);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
2011-07-10 09:14:05 +08:00
|
|
|
for (j = 0; j < addr_cnt; j++) {
|
2011-02-25 04:51:45 +08:00
|
|
|
(res + r)->name = (os->addr + j)->name;
|
2009-09-04 01:14:03 +08:00
|
|
|
(res + r)->start = (os->addr + j)->pa_start;
|
|
|
|
(res + r)->end = (os->addr + j)->pa_end;
|
|
|
|
(res + r)->flags = IORESOURCE_MEM;
|
|
|
|
r++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2012-08-29 17:48:11 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_fill_dma_resources - fill struct resource array with dma data
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @res: pointer to the array of struct resource to fill
|
|
|
|
*
|
|
|
|
* Fill the struct resource array @res with dma resource data from the
|
|
|
|
* omap_hwmod @oh. Intended to be called by code that registers
|
|
|
|
* omap_devices. See also omap_hwmod_count_resources(). Returns the
|
|
|
|
* number of array elements filled.
|
|
|
|
*/
|
|
|
|
int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res)
|
|
|
|
{
|
|
|
|
int i, sdma_reqs_cnt;
|
|
|
|
int r = 0;
|
|
|
|
|
|
|
|
sdma_reqs_cnt = _count_sdma_reqs(oh);
|
|
|
|
for (i = 0; i < sdma_reqs_cnt; i++) {
|
|
|
|
(res + r)->name = (oh->sdma_reqs + i)->name;
|
|
|
|
(res + r)->start = (oh->sdma_reqs + i)->dma_req;
|
|
|
|
(res + r)->end = (oh->sdma_reqs + i)->dma_req;
|
|
|
|
(res + r)->flags = IORESOURCE_DMA;
|
|
|
|
r++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2012-04-19 09:10:06 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_get_resource_byname - fetch IP block integration data by name
|
|
|
|
* @oh: struct omap_hwmod * to operate on
|
|
|
|
* @type: one of the IORESOURCE_* constants from include/linux/ioport.h
|
|
|
|
* @name: pointer to the name of the data to fetch (optional)
|
|
|
|
* @rsrc: pointer to a struct resource, allocated by the caller
|
|
|
|
*
|
|
|
|
* Retrieve MPU IRQ, SDMA request line, or address space start/end
|
|
|
|
* data for the IP block pointed to by @oh. The data will be filled
|
|
|
|
* into a struct resource record pointed to by @rsrc. The struct
|
|
|
|
* resource must be allocated by the caller. When @name is non-null,
|
|
|
|
* the data associated with the matching entry in the IRQ/SDMA/address
|
|
|
|
* space hwmod data arrays will be returned. If @name is null, the
|
|
|
|
* first array entry will be returned. Data order is not meaningful
|
|
|
|
* in hwmod data, so callers are strongly encouraged to use a non-null
|
|
|
|
* @name whenever possible to avoid unpredictable effects if hwmod
|
|
|
|
* data is later added that causes data ordering to change. This
|
|
|
|
* function is only intended for use by OMAP core code. Device
|
|
|
|
* drivers should not call this function - the appropriate bus-related
|
|
|
|
* data accessor functions should be used instead. Returns 0 upon
|
|
|
|
* success or a negative error code upon error.
|
|
|
|
*/
|
|
|
|
int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int type,
|
|
|
|
const char *name, struct resource *rsrc)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
unsigned int irq, dma;
|
|
|
|
u32 pa_start, pa_end;
|
|
|
|
|
|
|
|
if (!oh || !rsrc)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (type == IORESOURCE_IRQ) {
|
|
|
|
r = _get_mpu_irq_by_name(oh, name, &irq);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
rsrc->start = irq;
|
|
|
|
rsrc->end = irq;
|
|
|
|
} else if (type == IORESOURCE_DMA) {
|
|
|
|
r = _get_sdma_req_by_name(oh, name, &dma);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
rsrc->start = dma;
|
|
|
|
rsrc->end = dma;
|
|
|
|
} else if (type == IORESOURCE_MEM) {
|
|
|
|
r = _get_addr_space_by_name(oh, name, &pa_start, &pa_end);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
rsrc->start = pa_start;
|
|
|
|
rsrc->end = pa_end;
|
|
|
|
} else {
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
rsrc->flags = type;
|
|
|
|
rsrc->name = name;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_get_pwrdm - return pointer to this module's main powerdomain
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Return the powerdomain pointer associated with the OMAP module
|
|
|
|
* @oh's main clock. If @oh does not have a main clk, return the
|
|
|
|
* powerdomain associated with the interface clock associated with the
|
|
|
|
* module's MPU port. (XXX Perhaps this should use the SDMA port
|
|
|
|
* instead?) Returns NULL on error, or a struct powerdomain * on
|
|
|
|
* success.
|
|
|
|
*/
|
|
|
|
struct powerdomain *omap_hwmod_get_pwrdm(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
struct clk *c;
|
2012-04-19 18:04:27 +08:00
|
|
|
struct omap_hwmod_ocp_if *oi;
|
2012-11-11 07:58:41 +08:00
|
|
|
struct clockdomain *clkdm;
|
|
|
|
struct clk_hw_omap *clk;
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return NULL;
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
if (oh->clkdm)
|
|
|
|
return oh->clkdm->pwrdm.ptr;
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
if (oh->_clk) {
|
|
|
|
c = oh->_clk;
|
|
|
|
} else {
|
2012-04-19 18:04:27 +08:00
|
|
|
oi = _find_mpu_rt_port(oh);
|
|
|
|
if (!oi)
|
2009-09-04 01:14:03 +08:00
|
|
|
return NULL;
|
2012-04-19 18:04:27 +08:00
|
|
|
c = oi->_clk;
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
clk = to_clk_hw_omap(__clk_get_hw(c));
|
|
|
|
clkdm = clk->clkdm;
|
|
|
|
if (!clkdm)
|
2010-03-31 18:16:29 +08:00
|
|
|
return NULL;
|
|
|
|
|
2012-11-11 07:58:41 +08:00
|
|
|
return clkdm->pwrdm.ptr;
|
2009-09-04 01:14:03 +08:00
|
|
|
}
|
|
|
|
|
2010-07-27 06:34:33 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_get_mpu_rt_va - return the module's base address (for the MPU)
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Returns the virtual address corresponding to the beginning of the
|
|
|
|
* module's register target, in the address range that is intended to
|
|
|
|
* be used by the MPU. Returns the virtual address upon success or NULL
|
|
|
|
* upon error.
|
|
|
|
*/
|
|
|
|
void __iomem *omap_hwmod_get_mpu_rt_va(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
if (!oh)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (oh->_int_flags & _HWMOD_NO_MPU_PORT)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (oh->_state == _HWMOD_STATE_UNKNOWN)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return oh->_mpu_rt_va;
|
|
|
|
}
|
|
|
|
|
2009-09-04 01:14:03 +08:00
|
|
|
/*
|
|
|
|
* XXX what about functions for drivers to save/restore ocp_sysconfig
|
|
|
|
* for context save/restore operations?
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_enable_wakeup - allow device to wake up the system
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Sets the module OCP socket ENAWAKEUP bit to allow the module to
|
2012-04-05 16:59:32 +08:00
|
|
|
* send wakeups to the PRCM, and enable I/O ring wakeup events for
|
|
|
|
* this IP block if it has dynamic mux entries. Eventually this
|
|
|
|
* should set PRCM wakeup registers to cause the PRCM to receive
|
|
|
|
* wakeup events from the module. Does not set any wakeup routing
|
|
|
|
* registers beyond this point - if the module is to wake up any other
|
|
|
|
* module or subsystem, that must be set separately. Called by
|
|
|
|
* omap_device code. Returns -EINVAL on error or 0 upon success.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
|
|
|
int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
|
|
|
|
{
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed
OMAP: hwmod: Enable module wakeup if in smartidle
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22 12:08:34 +08:00
|
|
|
u32 v;
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
|
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
2012-04-05 16:59:32 +08:00
|
|
|
|
|
|
|
if (oh->class->sysc &&
|
|
|
|
(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)) {
|
|
|
|
v = oh->_sysc_cache;
|
|
|
|
_enable_wakeup(oh, &v);
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
}
|
|
|
|
|
2011-12-17 05:36:58 +08:00
|
|
|
_set_idle_ioring_wakeup(oh, true);
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_disable_wakeup - prevent device from waking the system
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Clears the module OCP socket ENAWAKEUP bit to prevent the module
|
2012-04-05 16:59:32 +08:00
|
|
|
* from sending wakeups to the PRCM, and disable I/O ring wakeup
|
|
|
|
* events for this IP block if it has dynamic mux entries. Eventually
|
|
|
|
* this should clear PRCM wakeup registers to cause the PRCM to ignore
|
|
|
|
* wakeup events from the module. Does not set any wakeup routing
|
|
|
|
* registers beyond this point - if the module is to wake up any other
|
|
|
|
* module or subsystem, that must be set separately. Called by
|
|
|
|
* omap_device code. Returns -EINVAL on error or 0 upon success.
|
2009-09-04 01:14:03 +08:00
|
|
|
*/
|
|
|
|
int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
|
|
|
|
{
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed
OMAP: hwmod: Enable module wakeup if in smartidle
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22 12:08:34 +08:00
|
|
|
u32 v;
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
|
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
2012-04-05 16:59:32 +08:00
|
|
|
|
|
|
|
if (oh->class->sysc &&
|
|
|
|
(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)) {
|
|
|
|
v = oh->_sysc_cache;
|
|
|
|
_disable_wakeup(oh, &v);
|
|
|
|
_write_sysconfig(v, oh);
|
|
|
|
}
|
|
|
|
|
2011-12-17 05:36:58 +08:00
|
|
|
_set_idle_ioring_wakeup(oh, false);
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2009-09-04 01:14:03 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2010-02-23 13:09:34 +08:00
|
|
|
|
2010-09-22 00:34:11 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_assert_hardreset - assert the HW reset line of submodules
|
|
|
|
* contained in the hwmod module.
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @name: name of the reset line to lookup and assert
|
|
|
|
*
|
|
|
|
* Some IP like dsp, ipu or iva contain processor that require
|
|
|
|
* an HW reset line to be assert / deassert in order to enable fully
|
|
|
|
* the IP. Returns -EINVAL if @oh is null or if the operation is not
|
|
|
|
* yet supported on this OMAP; otherwise, passes along the return value
|
|
|
|
* from _assert_hardreset().
|
|
|
|
*/
|
|
|
|
int omap_hwmod_assert_hardreset(struct omap_hwmod *oh, const char *name)
|
|
|
|
{
|
|
|
|
int ret;
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
2010-09-22 00:34:11 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
2010-09-22 00:34:11 +08:00
|
|
|
ret = _assert_hardreset(oh, name);
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2010-09-22 00:34:11 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_deassert_hardreset - deassert the HW reset line of submodules
|
|
|
|
* contained in the hwmod module.
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @name: name of the reset line to look up and deassert
|
|
|
|
*
|
|
|
|
* Some IP like dsp, ipu or iva contain processor that require
|
|
|
|
* an HW reset line to be assert / deassert in order to enable fully
|
|
|
|
* the IP. Returns -EINVAL if @oh is null or if the operation is not
|
|
|
|
* yet supported on this OMAP; otherwise, passes along the return value
|
|
|
|
* from _deassert_hardreset().
|
|
|
|
*/
|
|
|
|
int omap_hwmod_deassert_hardreset(struct omap_hwmod *oh, const char *name)
|
|
|
|
{
|
|
|
|
int ret;
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
2010-09-22 00:34:11 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
2010-09-22 00:34:11 +08:00
|
|
|
ret = _deassert_hardreset(oh, name);
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2010-09-22 00:34:11 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-02-23 13:09:34 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_for_each_by_class - call @fn for each hwmod of class @classname
|
|
|
|
* @classname: struct omap_hwmod_class name to search for
|
|
|
|
* @fn: callback function pointer to call for each hwmod in class @classname
|
|
|
|
* @user: arbitrary context data to pass to the callback function
|
|
|
|
*
|
2010-12-22 12:31:28 +08:00
|
|
|
* For each omap_hwmod of class @classname, call @fn.
|
|
|
|
* If the callback function returns something other than
|
2010-02-23 13:09:34 +08:00
|
|
|
* zero, the iterator is terminated, and the callback function's return
|
|
|
|
* value is passed back to the caller. Returns 0 upon success, -EINVAL
|
|
|
|
* if @classname or @fn are NULL, or passes back the error code from @fn.
|
|
|
|
*/
|
|
|
|
int omap_hwmod_for_each_by_class(const char *classname,
|
|
|
|
int (*fn)(struct omap_hwmod *oh,
|
|
|
|
void *user),
|
|
|
|
void *user)
|
|
|
|
{
|
|
|
|
struct omap_hwmod *temp_oh;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!classname || !fn)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
pr_debug("omap_hwmod: %s: looking for modules of class %s\n",
|
|
|
|
__func__, classname);
|
|
|
|
|
|
|
|
list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
|
|
|
|
if (!strcmp(temp_oh->class->name, classname)) {
|
|
|
|
pr_debug("omap_hwmod: %s: %s: calling callback fn\n",
|
|
|
|
__func__, temp_oh->name);
|
|
|
|
ret = (*fn)(temp_oh, user);
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
pr_debug("omap_hwmod: %s: iterator terminated early: %d\n",
|
|
|
|
__func__, ret);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-12-15 03:42:35 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_set_postsetup_state - set the post-_setup() state for this hwmod
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
* @state: state that _setup() should leave the hwmod in
|
|
|
|
*
|
2011-03-01 02:58:14 +08:00
|
|
|
* Sets the hwmod state that @oh will enter at the end of _setup()
|
2012-04-19 09:10:03 +08:00
|
|
|
* (called by omap_hwmod_setup_*()). See also the documentation
|
|
|
|
* for _setup_postsetup(), above. Returns 0 upon success or
|
|
|
|
* -EINVAL if there is a problem with the arguments or if the hwmod is
|
|
|
|
* in the wrong state.
|
2010-12-15 03:42:35 +08:00
|
|
|
*/
|
|
|
|
int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state)
|
|
|
|
{
|
|
|
|
int ret;
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
unsigned long flags;
|
2010-12-15 03:42:35 +08:00
|
|
|
|
|
|
|
if (!oh)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (state != _HWMOD_STATE_DISABLED &&
|
|
|
|
state != _HWMOD_STATE_ENABLED &&
|
|
|
|
state != _HWMOD_STATE_IDLE)
|
|
|
|
return -EINVAL;
|
|
|
|
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_lock_irqsave(&oh->_lock, flags);
|
2010-12-15 03:42:35 +08:00
|
|
|
|
|
|
|
if (oh->_state != _HWMOD_STATE_REGISTERED) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto ohsps_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
oh->_postsetup_state = state;
|
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
ohsps_unlock:
|
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-15 03:42:35 +08:00
|
|
|
spin_unlock_irqrestore(&oh->_lock, flags);
|
2010-12-15 03:42:35 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2010-12-22 12:31:55 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_get_context_loss_count - get lost context count
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kristo@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-22 07:15:17 +08:00
|
|
|
* Returns the context loss count of associated @oh
|
|
|
|
* upon success, or zero if no context loss data is available.
|
2010-12-22 12:31:55 +08:00
|
|
|
*
|
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kristo@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-22 07:15:17 +08:00
|
|
|
* On OMAP4, this queries the per-hwmod context loss register,
|
|
|
|
* assuming one exists. If not, or on OMAP2/3, this queries the
|
|
|
|
* enclosing powerdomain context loss count.
|
2010-12-22 12:31:55 +08:00
|
|
|
*/
|
2011-06-09 21:56:23 +08:00
|
|
|
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
|
2010-12-22 12:31:55 +08:00
|
|
|
{
|
|
|
|
struct powerdomain *pwrdm;
|
|
|
|
int ret = 0;
|
|
|
|
|
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kristo@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-22 07:15:17 +08:00
|
|
|
if (soc_ops.get_context_lost)
|
|
|
|
return soc_ops.get_context_lost(oh);
|
|
|
|
|
2010-12-22 12:31:55 +08:00
|
|
|
pwrdm = omap_hwmod_get_pwrdm(oh);
|
|
|
|
if (pwrdm)
|
|
|
|
ret = pwrdm_get_context_loss_count(pwrdm);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2011-03-10 18:50:07 +08:00
|
|
|
|
2012-06-19 02:12:23 +08:00
|
|
|
/**
|
|
|
|
* omap_hwmod_init - initialize the hwmod code
|
|
|
|
*
|
|
|
|
* Sets up some function pointers needed by the hwmod code to operate on the
|
|
|
|
* currently-booted SoC. Intended to be called once during kernel init
|
|
|
|
* before any hwmods are registered. No return value.
|
|
|
|
*/
|
|
|
|
void __init omap_hwmod_init(void)
|
|
|
|
{
|
2012-10-21 15:01:11 +08:00
|
|
|
if (cpu_is_omap24xx()) {
|
2014-10-27 23:39:23 +08:00
|
|
|
soc_ops.wait_target_ready = _omap2xxx_3xxx_wait_target_ready;
|
2012-10-21 15:01:11 +08:00
|
|
|
soc_ops.assert_hardreset = _omap2_assert_hardreset;
|
|
|
|
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
|
|
|
|
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
|
|
|
|
} else if (cpu_is_omap34xx()) {
|
2014-10-27 23:39:23 +08:00
|
|
|
soc_ops.wait_target_ready = _omap2xxx_3xxx_wait_target_ready;
|
2012-06-19 02:12:24 +08:00
|
|
|
soc_ops.assert_hardreset = _omap2_assert_hardreset;
|
|
|
|
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
|
|
|
|
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
|
2013-07-17 23:03:25 +08:00
|
|
|
soc_ops.init_clkdm = _init_clkdm;
|
2013-07-02 20:50:08 +08:00
|
|
|
} else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
|
2012-06-19 02:12:23 +08:00
|
|
|
soc_ops.enable_module = _omap4_enable_module;
|
|
|
|
soc_ops.disable_module = _omap4_disable_module;
|
2012-06-19 02:12:24 +08:00
|
|
|
soc_ops.wait_target_ready = _omap4_wait_target_ready;
|
2012-06-19 02:12:24 +08:00
|
|
|
soc_ops.assert_hardreset = _omap4_assert_hardreset;
|
|
|
|
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
|
|
|
|
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
|
2012-06-19 02:12:25 +08:00
|
|
|
soc_ops.init_clkdm = _init_clkdm;
|
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kristo@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-22 07:15:17 +08:00
|
|
|
soc_ops.update_context_lost = _omap4_update_context_lost;
|
|
|
|
soc_ops.get_context_lost = _omap4_get_context_lost;
|
2013-10-12 18:16:20 +08:00
|
|
|
} else if (soc_is_am43xx()) {
|
|
|
|
soc_ops.enable_module = _omap4_enable_module;
|
|
|
|
soc_ops.disable_module = _omap4_disable_module;
|
|
|
|
soc_ops.wait_target_ready = _omap4_wait_target_ready;
|
2014-10-27 23:39:24 +08:00
|
|
|
soc_ops.assert_hardreset = _omap4_assert_hardreset;
|
|
|
|
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
|
|
|
|
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
|
2013-10-12 18:16:20 +08:00
|
|
|
soc_ops.init_clkdm = _init_clkdm;
|
2015-01-27 01:26:32 +08:00
|
|
|
} else if (cpu_is_ti816x() || soc_is_am33xx()) {
|
2014-10-27 23:39:24 +08:00
|
|
|
soc_ops.enable_module = _omap4_enable_module;
|
|
|
|
soc_ops.disable_module = _omap4_disable_module;
|
|
|
|
soc_ops.wait_target_ready = _omap4_wait_target_ready;
|
2012-09-12 07:18:53 +08:00
|
|
|
soc_ops.assert_hardreset = _am33xx_assert_hardreset;
|
|
|
|
soc_ops.deassert_hardreset = _am33xx_deassert_hardreset;
|
|
|
|
soc_ops.is_hardreset_asserted = _am33xx_is_hardreset_asserted;
|
|
|
|
soc_ops.init_clkdm = _init_clkdm;
|
2012-06-19 02:12:24 +08:00
|
|
|
} else {
|
|
|
|
WARN(1, "omap_hwmod: unknown SoC type\n");
|
2012-06-19 02:12:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
inited = true;
|
|
|
|
}
|
2012-07-06 15:58:43 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* omap_hwmod_get_main_clk - get pointer to main clock name
|
|
|
|
* @oh: struct omap_hwmod *
|
|
|
|
*
|
|
|
|
* Returns the main clock name assocated with @oh upon success,
|
|
|
|
* or NULL if @oh is NULL.
|
|
|
|
*/
|
|
|
|
const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh)
|
|
|
|
{
|
|
|
|
if (!oh)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return oh->main_clk;
|
|
|
|
}
|