OpenCloudOS-Kernel/arch/arm/mach-omap2/omap_hwmod.c

3949 lines
112 KiB
C
Raw Normal View History

OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/*
* omap_hwmod implementation for OMAP2/3/4
*
* Copyright (C) 2009-2011 Nokia Corporation
* Copyright (C) 2011-2012 Texas Instruments, Inc.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +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
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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.
*
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +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 |
* | ({read,write}l_relaxed, clk*) |
* +-------------------------------+
*
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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>
#include <linux/clk-provider.h>
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/list.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
#include <linux/bootmem.h>
#include <linux/cpu.h>
#include <linux/of.h>
#include <linux/of_address.h>
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
#include <asm/system_misc.h>
#include "clock.h"
#include "omap_hwmod.h"
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-09-01 01:59:07 +08:00
#include "soc.h"
#include "common.h"
#include "clockdomain.h"
#include "powerdomain.h"
#include "cm2xxx.h"
#include "cm3xxx.h"
#include "cm33xx.h"
#include "prm.h"
#include "prm3xxx.h"
#include "prm44xx.h"
#include "prm33xx.h"
#include "prminst44xx.h"
#include "mux.h"
#include "pm.h"
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* Name of the OMAP hwmod for the MPU */
#define MPU_INITIATOR_NAME "mpu"
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
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
/**
* 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);
int (*wait_target_ready)(struct omap_hwmod *oh);
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);
int (*init_clkdm)(struct omap_hwmod *oh);
void (*update_context_lost)(struct omap_hwmod *oh);
int (*get_context_lost)(struct omap_hwmod *oh);
};
/* soc_ops: adapts the omap_hwmod code to the currently-booted SoC */
static struct omap_hwmod_soc_ops soc_ops;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
/* io_chain_lock: used to serialize reconfigurations of the I/O chain */
static DEFINE_SPINLOCK(io_chain_lock);
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
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;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* inited: set to true once the hwmod code is initialized */
static bool inited;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* Private functions */
/**
* _fetch_next_ocp_if - return the next OCP interface in a list
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
* @p: ptr to a ptr to the list_head inside the ocp_if to return
* @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.
*/
static struct omap_hwmod_ocp_if *_fetch_next_ocp_if(struct list_head **p,
int *i)
{
struct omap_hwmod_ocp_if *oi;
oi = list_entry(*p, struct omap_hwmod_link, node)->ocp_if;
*p = (*p)->next;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
*i = *i + 1;
return oi;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
if (!oh->class->sysc) {
WARN(1, "omap_hwmod: %s: cannot read OCP_SYSCONFIG: not defined on hwmod's class\n", oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
}
/* XXX ensure module interface clock is up */
oh->_sysc_cache = omap_hwmod_read(oh, oh->class->sysc->sysc_offs);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!(oh->class->sysc->sysc_flags & SYSC_NO_CACHE))
OMAP3: hwmod: Adding flag to prevent caching of sysconfig register. In the current implementation the sysconfig value is read into _sysc_cache once and an actual update to the sysconfig register happens only if the new value paased is differnt from the one in _sysc_cache. _sysc_cache is updated only if _HWMOD_SYSCONFIG_LOADED is not set. This can lead to the follwing issue if off mode is enabled in modules which employs "always-retore" mechanism of context save and restore. a. The module sets the sysconfig register through omap_device_enable. Here _sysc_cache is updated with the value written to the sysconfig register and left. b. The power domain containig the module enters off mode and the module context is lost. c. The module in use becomes active and calls omap_device_enable to enable itself. Here a read of sysconfig register does not happen as _HWMOD_SYSCONFIG_LOADED flag is set. The value to be written to the sysconfig register will be same as the one written in step a. Since _sysc_cache reflects the previous written value an update of the sysconfig register does not happen. This means in modules which employs "always-restore" mechanism after off , the sysconfig regsiters will never get updated. This patch introduces a flag SYSC_NO_CACHE which if set ensures that the sysconfig register is always read into _sysc_cache before an update is attempted. This flags need to be set only by modules which does not do a context save but re-initializes the registers every time the module is accessed. This includes modules like i2c, smartreflex etc. Signed-off-by: Thara Gopinath <thara@ti.com> [paul@pwsan.com: tweaked to apply on a different head, added flag comment] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-01-20 08:30:51 +08:00
oh->_int_flags |= _HWMOD_SYSCONFIG_LOADED;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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 *
*
* Write @v into the module class' OCP_SYSCONFIG register, if it has
* one. No return value.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
{
if (!oh->class->sysc) {
WARN(1, "omap_hwmod: %s: cannot write OCP_SYSCONFIG: not defined on hwmod's class\n", oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return;
}
/* XXX ensure module interface clock is up */
/* Module might have lost context, always update cache and register */
oh->_sysc_cache = v;
omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
u32 mstandby_mask;
u8 mstandby_shift;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_MIDLEMODE))
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
return -EINVAL;
}
mstandby_shift = oh->class->sysc->sysc_fields->midle_shift;
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
mstandby_mask = (0x3 << mstandby_shift);
*v &= ~mstandby_mask;
*v |= __ffs(standbymode) << mstandby_shift;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
u32 sidle_mask;
u8 sidle_shift;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_SIDLEMODE))
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
return -EINVAL;
}
sidle_shift = oh->class->sysc->sysc_fields->sidle_shift;
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
sidle_mask = (0x3 << sidle_shift);
*v &= ~sidle_mask;
*v |= __ffs(idlemode) << sidle_shift;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
u32 clkact_mask;
u8 clkact_shift;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_CLOCKACTIVITY))
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
return -EINVAL;
}
clkact_shift = oh->class->sysc->sysc_fields->clkact_shift;
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
clkact_mask = (0x3 << clkact_shift);
*v &= ~clkact_mask;
*v |= clockact << clkact_shift;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
/**
* _set_softreset: set OCP_SYSCONFIG.SOFTRESET bit in @v
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
u32 softrst_mask;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
return -EINVAL;
}
softrst_mask = (0x1 << oh->class->sysc->sysc_fields->srst_shift);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
*v |= softrst_mask;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
/**
* _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;
}
/**
* _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;
}
/**
* _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;
}
/**
* _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)
{
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
u32 autoidle_mask;
u8 autoidle_shift;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_AUTOIDLE))
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
return -EINVAL;
}
autoidle_shift = oh->class->sysc->sysc_fields->autoidle_shift;
autoidle_mask = (0x1 << autoidle_shift);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
*v &= ~autoidle_mask;
*v |= autoidle << autoidle_shift;
return 0;
}
/**
* _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);
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
if (!oh->class->sysc ||
!((oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP) ||
(oh->class->sysc->idlemodes & SIDLE_SMART_WKUP) ||
(oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)))
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
return -EINVAL;
}
if (oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)
*v |= 0x1 << oh->class->sysc->sysc_fields->enwkup_shift;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)
_set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
if (!oh->class->sysc ||
!((oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP) ||
(oh->class->sysc->idlemodes & SIDLE_SMART_WKUP) ||
(oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)))
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
WARN(1, "omap_hwmod: %s: offset struct for sysconfig not provided in class\n", oh->name);
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-25 03:05:58 +08:00
return -EINVAL;
}
if (oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)
*v &= ~(0x1 << oh->class->sysc->sysc_fields->enwkup_shift);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v);
if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)
_set_master_standbymode(oh, HWMOD_IDLEMODE_SMART, v);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
return 0;
}
static struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
{
struct clk_hw_omap *clk;
if (oh->clkdm) {
return oh->clkdm;
} else if (oh->_clk) {
if (__clk_get_flags(oh->_clk) & CLK_IS_BASIC)
return NULL;
clk = to_clk_hw_omap(__clk_get_hw(oh->_clk));
return clk->clkdm;
}
return NULL;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static int _add_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh)
{
struct clockdomain *clkdm, *init_clkdm;
clkdm = _get_clkdm(oh);
init_clkdm = _get_clkdm(init_oh);
if (!clkdm || !init_clkdm)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (clkdm && clkdm->flags & CLKDM_NO_AUTODEPS)
return 0;
return clkdm_add_sleepdep(clkdm, init_clkdm);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static int _del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh)
{
struct clockdomain *clkdm, *init_clkdm;
clkdm = _get_clkdm(oh);
init_clkdm = _get_clkdm(init_oh);
if (!clkdm || !init_clkdm)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
if (clkdm && clkdm->flags & CLKDM_NO_AUTODEPS)
return 0;
return clkdm_del_sleepdep(clkdm, init_clkdm);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
if (!oh->main_clk)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
oh->_clk = clk_get(NULL, oh->main_clk);
if (IS_ERR(oh->_clk)) {
pr_warn("omap_hwmod: %s: cannot clk_get main_clk %s\n",
oh->name, oh->main_clk);
return -EINVAL;
}
ARM: omap: clk: add clk_prepare and clk_unprepare As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
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);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!_get_clkdm(oh))
pr_debug("omap_hwmod: %s: missing clockdomain for %s.\n",
oh->name, oh->main_clk);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return ret;
}
/**
* _init_interface_clks - get a struct clk * for the the hwmod's interface clks
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
struct omap_hwmod_ocp_if *os;
struct list_head *p;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
struct clk *c;
int i = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
int ret = 0;
p = oh->slave_ports.next;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
while (i < oh->slaves_cnt) {
os = _fetch_next_ocp_if(&p, &i);
if (!os->clk)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
continue;
c = clk_get(NULL, os->clk);
if (IS_ERR(c)) {
pr_warn("omap_hwmod: %s: cannot clk_get interface_clk %s\n",
oh->name, os->clk);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
ret = -EINVAL;
ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced missing braces, however, we just set return result if clk_get fail and we populate the error pointer in clk pointer and pass it along to clk_prepare. This is wrong. The intent seems to be retry remaining clocks if they are available and warn the ones we cant find clks for. With the current logic, we see the following crash: omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick Unable to handle kernel NULL pointer dereference at virtual address 00000032 pgd = c0004000 [00000032] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19 task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000 PC is at __clk_prepare+0x10/0x74 LR is at clk_prepare+0x14/0x24 <snip> [<c044d59c>] (__clk_prepare+0x10/0x74) from [<c044d9b0>] (clk_prepare+0x14/0x24) [<c044d9b0>] (clk_prepare+0x14/0x24) from [<c077d8c4>] (_init+0x24c/0x3bc) [<c077d8c4>] (_init+0x24c/0x3bc) from [<c0027328>] (omap_hwmod_for_each+0x34/0x5c) [<c0027328>] (omap_hwmod_for_each+0x34/0x5c) from [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) from [<c0008928>] (do_one_initcall+0x38/0x168) [<c0008928>] (do_one_initcall+0x38/0x168) from [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) from [<c0521064>] (kernel_init+0x8/0x110) [<c0521064>] (kernel_init+0x8/0x110) from [<c000e568>] (ret_from_fork+0x14/0x2c) Code: e92d4038 e2504000 01a05004 0a000005 (e5943034) So, just warn and continue instead of proceeding and crashing, with missing clock nodes/bad data, we will eventually fail, however we should now have enough information to identify the culprit. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2013-12-09 09:39:03 +08:00
continue;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
os->_clk = c;
ARM: omap: clk: add clk_prepare and clk_unprepare As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
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);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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++) {
c = clk_get(NULL, oc->clk);
if (IS_ERR(c)) {
pr_warn("omap_hwmod: %s: cannot clk_get opt_clk %s\n",
oh->name, oc->clk);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
ret = -EINVAL;
ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced missing braces, however, we just set return result if clk_get fail and we populate the error pointer in clk pointer and pass it along to clk_prepare. This is wrong. The intent seems to be retry remaining clocks if they are available and warn the ones we cant find clks for. With the current logic, we see the following crash: omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick Unable to handle kernel NULL pointer dereference at virtual address 00000032 pgd = c0004000 [00000032] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19 task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000 PC is at __clk_prepare+0x10/0x74 LR is at clk_prepare+0x14/0x24 <snip> [<c044d59c>] (__clk_prepare+0x10/0x74) from [<c044d9b0>] (clk_prepare+0x14/0x24) [<c044d9b0>] (clk_prepare+0x14/0x24) from [<c077d8c4>] (_init+0x24c/0x3bc) [<c077d8c4>] (_init+0x24c/0x3bc) from [<c0027328>] (omap_hwmod_for_each+0x34/0x5c) [<c0027328>] (omap_hwmod_for_each+0x34/0x5c) from [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) from [<c0008928>] (do_one_initcall+0x38/0x168) [<c0008928>] (do_one_initcall+0x38/0x168) from [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) from [<c0521064>] (kernel_init+0x8/0x110) [<c0521064>] (kernel_init+0x8/0x110) from [<c000e568>] (ret_from_fork+0x14/0x2c) Code: e92d4038 e2504000 01a05004 0a000005 (e5943034) So, just warn and continue instead of proceeding and crashing, with missing clock nodes/bad data, we will eventually fail, however we should now have enough information to identify the culprit. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2013-12-09 09:39:03 +08:00
continue;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
oc->_clk = c;
ARM: omap: clk: add clk_prepare and clk_unprepare As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
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);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
struct omap_hwmod_ocp_if *os;
struct list_head *p;
int i = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
pr_debug("omap_hwmod: %s: enabling clocks\n", oh->name);
if (oh->_clk)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
clk_enable(oh->_clk);
p = oh->slave_ports.next;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
while (i < oh->slaves_cnt) {
os = _fetch_next_ocp_if(&p, &i);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE))
clk_enable(os->_clk);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
struct omap_hwmod_ocp_if *os;
struct list_head *p;
int i = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
pr_debug("omap_hwmod: %s: disabling clocks\n", oh->name);
if (oh->_clk)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
clk_disable(oh->_clk);
p = oh->slave_ports.next;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
while (i < oh->slaves_cnt) {
os = _fetch_next_ocp_if(&p, &i);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE))
clk_disable(os->_clk);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
}
/* The opt clocks are controlled by the device driver. */
return 0;
}
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,
__clk_get_name(oc->_clk));
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,
__clk_get_name(oc->_clk));
clk_disable(oc->_clk);
}
}
/**
* _omap4_enable_module - enable CLKCTRL modulemode on OMAP4
* @oh: struct omap_hwmod *
*
* Enables the PRCM module mode related to the hwmod @oh.
* No return value.
*/
static void _omap4_enable_module(struct omap_hwmod *oh)
{
if (!oh->clkdm || !oh->prcm.omap4.modulemode)
return;
pr_debug("omap_hwmod: %s: %s: %d\n",
oh->name, __func__, oh->prcm.omap4.modulemode);
omap_cm_module_enable(oh->prcm.omap4.modulemode,
oh->clkdm->prcm_partition,
oh->clkdm->cm_inst, oh->prcm.omap4.clkctrl_offs);
}
/**
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported If the module does not have any modulemode, the _disable_module function will do nothing. There is then no point waiting for a idle status change. It will remove the following warnings. [ 0.331848] omap_hwmod: dmm: _wait_target_disable failed [ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed [ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed [ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed [ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed [ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed Note: For such module, the state is managed automatically by HW according to clock domain transition. It is then not possible to wait for idle even later in the _idle function since the status will change at clock domain boundary. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved _wait_target_disable() into _disable_module(), removing duplicate code] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
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)
{
if (!oh)
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported If the module does not have any modulemode, the _disable_module function will do nothing. There is then no point waiting for a idle status change. It will remove the following warnings. [ 0.331848] omap_hwmod: dmm: _wait_target_disable failed [ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed [ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed [ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed [ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed [ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed Note: For such module, the state is managed automatically by HW according to clock domain transition. It is then not possible to wait for idle even later in the _idle function since the status will change at clock domain boundary. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved _wait_target_disable() into _disable_module(), removing duplicate code] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-17 08:09:11 +08:00
return -EINVAL;
if (oh->_int_flags & _HWMOD_NO_MPU_PORT || !oh->clkdm)
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported If the module does not have any modulemode, the _disable_module function will do nothing. There is then no point waiting for a idle status change. It will remove the following warnings. [ 0.331848] omap_hwmod: dmm: _wait_target_disable failed [ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed [ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed [ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed [ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed [ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed Note: For such module, the state is managed automatically by HW according to clock domain transition. It is then not possible to wait for idle even later in the _idle function since the status will change at clock domain boundary. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved _wait_target_disable() into _disable_module(), removing duplicate code] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-17 08:09:11 +08:00
return 0;
if (oh->flags & HWMOD_NO_IDLEST)
return 0;
return omap_cm_wait_module_idle(oh->clkdm->prcm_partition,
oh->clkdm->cm_inst,
oh->prcm.omap4.clkctrl_offs, 0);
}
/**
* _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);
return i-1;
}
/**
* _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);
return i-1;
}
/**
* _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);
return i-1;
}
/**
* _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;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
struct list_head *p = NULL;
bool found = false;
p = oh->slave_ports.next;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
i = 0;
while (i < oh->slaves_cnt) {
os = _fetch_next_ocp_if(&p, &i);
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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* _save_mpu_port_index - find and save the index to @oh's MPU port
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
* @oh: struct omap_hwmod *
*
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static void __init _save_mpu_port_index(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
struct omap_hwmod_ocp_if *os = NULL;
struct list_head *p;
int i = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh)
return;
oh->_int_flags |= _HWMOD_NO_MPU_PORT;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
p = oh->slave_ports.next;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
while (i < oh->slaves_cnt) {
os = _fetch_next_ocp_if(&p, &i);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (os->user & OCP_USER_MPU) {
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
oh->_mpu_port = os;
oh->_int_flags &= ~_HWMOD_NO_MPU_PORT;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
break;
}
}
return;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +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;
return oh->_mpu_port;
};
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* _find_mpu_rt_addr_space - return MPU register target address space for @oh
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
* @oh: struct omap_hwmod *
*
* Returns a pointer to the struct omap_hwmod_addr_space record representing
* the register target MPU address space; or returns NULL upon error.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static struct omap_hwmod_addr_space * __init _find_mpu_rt_addr_space(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
struct omap_hwmod_ocp_if *os;
struct omap_hwmod_addr_space *mem;
int found = 0, i = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
os = _find_mpu_rt_port(oh);
if (!os || !os->addr)
return NULL;
do {
mem = &os->addr[i++];
if (mem->flags & ADDR_TYPE_RT)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
found = 1;
} while (!found && mem->pa_start != mem->pa_end);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return (found) ? mem : NULL;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
}
/**
* _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static void _enable_sysc(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
u8 idlemode, sf;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
struct clockdomain *clkdm;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh->class->sysc)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return;
/*
* 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);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
v = oh->_sysc_cache;
sf = oh->class->sysc->sysc_flags;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
clkdm = _get_clkdm(oh);
if (sf & SYSC_HAS_SIDLEMODE) {
if (oh->flags & HWMOD_SWSUP_SIDLE ||
oh->flags & HWMOD_SWSUP_SIDLE_ACT) {
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!
*/
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;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_set_slave_idlemode(oh, idlemode, &v);
}
if (sf & SYSC_HAS_MIDLEMODE) {
if (oh->flags & HWMOD_FORCE_MSTANDBY) {
idlemode = HWMOD_IDLEMODE_FORCE;
} else if (oh->flags & HWMOD_SWSUP_MSTANDBY) {
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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_set_master_standbymode(oh, idlemode, &v);
}
/*
* 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);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +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);
/*
* 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);
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
}
/**
* _idle_sysc - try to put a module into idle via OCP_SYSCONFIG
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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.
*/
static void _idle_sysc(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
u8 idlemode, sf;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
u32 v;
if (!oh->class->sysc)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return;
v = oh->_sysc_cache;
sf = oh->class->sysc->sysc_flags;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (sf & SYSC_HAS_SIDLEMODE) {
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;
} 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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_set_slave_idlemode(oh, idlemode, &v);
}
if (sf & SYSC_HAS_MIDLEMODE) {
if ((oh->flags & HWMOD_SWSUP_MSTANDBY) ||
(oh->flags & HWMOD_FORCE_MSTANDBY)) {
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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_set_master_standbymode(oh, idlemode, &v);
}
_write_sysconfig(v, oh);
}
/**
* _shutdown_sysc - force a module into idle via OCP_SYSCONFIG
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
* @oh: struct omap_hwmod *
*
* Force the module into slave idle and master suspend. No return
* value.
*/
static void _shutdown_sysc(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
u32 v;
u8 sf;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh->class->sysc)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return;
v = oh->_sysc_cache;
sf = oh->class->sysc->sysc_flags;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (sf & SYSC_HAS_SIDLEMODE)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_set_slave_idlemode(oh, HWMOD_IDLEMODE_FORCE, &v);
if (sf & SYSC_HAS_MIDLEMODE)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_set_master_standbymode(oh, HWMOD_IDLEMODE_FORCE, &v);
if (sf & SYSC_HAS_AUTOIDLE)
_set_module_autoidle(oh, 1, &v);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
}
/**
* _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.
* Return -EINVAL if the clkdm_name lookup failed.
*/
static int _init_clkdm(struct omap_hwmod *oh)
{
if (!oh->clkdm_name) {
pr_debug("omap_hwmod: %s: missing clockdomain\n", oh->name);
return 0;
}
oh->clkdm = clkdm_lookup(oh->clkdm_name);
if (!oh->clkdm) {
pr_warn("omap_hwmod: %s: could not associate to clkdm %s\n",
oh->name, oh->clkdm_name);
return 0;
}
pr_debug("omap_hwmod: %s: associated to clkdm %s\n",
oh->name, oh->clkdm_name);
return 0;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* _init_clocks - clk_get() all clocks associated with this hwmod. Retrieve as
* well the clockdomain.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
* @oh: struct omap_hwmod *
* @data: not used; pass NULL
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*
* Called by omap_hwmod_setup_*() (after omap2_clk_init()).
* Resolves all clock names embedded in the hwmod. Returns 0 on
* success, or a negative error code on failure.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static int _init_clocks(struct omap_hwmod *oh, void *data)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
int ret = 0;
if (oh->_state != _HWMOD_STATE_REGISTERED)
return 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
pr_debug("omap_hwmod: %s: looking up clocks\n", oh->name);
if (soc_ops.init_clkdm)
ret |= soc_ops.init_clkdm(oh);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
ret |= _init_main_clk(oh);
ret |= _init_interface_clks(oh);
ret |= _init_opt_clks(oh);
if (!ret)
oh->_state = _HWMOD_STATE_CLKS_INITED;
else
pr_warn("omap_hwmod: %s: cannot _init_clocks\n", oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return ret;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
/**
* _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
* @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.
*/
ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
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)) {
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
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
*
* 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)
{
struct omap_hwmod_rst_info ohri;
ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
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;
if (!soc_ops.assert_hardreset)
return -ENOSYS;
ret = _lookup_hardreset(oh, name, &ohri);
ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
2012-08-03 23:21:10 +08:00
if (ret < 0)
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
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
*
* 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)
{
struct omap_hwmod_rst_info ohri;
int ret = -EINVAL;
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;
if (!soc_ops.deassert_hardreset)
return -ENOSYS;
ret = _lookup_hardreset(oh, name, &ohri);
if (ret < 0)
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
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);
ret = soc_ops.deassert_hardreset(oh, &ohri);
if (soc_ops.disable_module)
soc_ops.disable_module(oh);
_disable_clocks(oh);
if (ret == -EBUSY)
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
if (!ret) {
/*
* Set the clockdomain to HW_AUTO, assuming that the
* previous state was HW_AUTO.
*/
if (oh->clkdm && hwsup)
clkdm_allow_idle(oh->clkdm);
} else {
if (oh->clkdm)
clkdm_hwmod_disable(oh->clkdm, oh);
}
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
*
* 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)
{
struct omap_hwmod_rst_info ohri;
ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
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;
if (!soc_ops.is_hardreset_asserted)
return -ENOSYS;
ret = _lookup_hardreset(oh, name, &ohri);
ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
2012-08-03 23:21:10 +08:00
if (ret < 0)
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
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
/**
* _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 *
*
* 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
* 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
*/
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
{
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)
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;
}
/**
* _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;
/*
* Since integration code might still be doing something, only
* disable if all lines are under hardreset.
*/
if (_are_any_hardreset_lines_asserted(oh))
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__);
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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* _ocp_softreset - reset an omap_hwmod via the OCP_SYSCONFIG bit
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* 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.
*
* In OMAP3 a specific SYSSTATUS register is used to get the reset status.
* Starting in OMAP4, some IPs do not have SYSSTATUS registers and instead
* use the SYSCONFIG softreset bit to provide the status.
*
* Note that some IP like McBSP do have reset control but don't have
* reset status.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static int _ocp_softreset(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
u32 v;
int c = 0;
int ret = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
return -ENOENT;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* clocks must be on for this operation */
if (oh->_state != _HWMOD_STATE_ENABLED) {
pr_warn("omap_hwmod: %s: reset can only be entered from enabled state\n",
oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
}
/* 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);
pr_debug("omap_hwmod: %s: resetting via OCP SOFTRESET\n", oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
v = oh->_sysc_cache;
ret = _set_softreset(oh, &v);
if (ret)
goto dis_opt_clks;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_write_sysconfig(v, oh);
if (oh->class->sysc->srst_udelay)
udelay(oh->class->sysc->srst_udelay);
c = _wait_softreset_complete(oh);
if (c == MAX_MODULE_SOFTRESET_WAIT) {
pr_warn("omap_hwmod: %s: softreset failed (waited %d usec)\n",
oh->name, MAX_MODULE_SOFTRESET_WAIT);
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);
}
ret = _clear_softreset(oh, &v);
if (ret)
goto dis_opt_clks;
_write_sysconfig(v, oh);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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()
*/
dis_opt_clks:
if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
_disable_optional_clocks(oh);
return ret;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
}
/**
* _reset - reset an omap_hwmod
* @oh: struct omap_hwmod *
*
* 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
* 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.
*/
static int _reset(struct omap_hwmod *oh)
{
int i, r;
pr_debug("omap_hwmod: %s: resetting\n", oh->name);
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;
}
}
_set_dmadisable(oh);
/*
* 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.
*/
if (oh->class->sysc) {
_update_sysc_cache(oh);
_enable_sysc(oh);
}
return r;
}
/**
* _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);
omap_prm_reconfigure_io_chain();
spin_unlock_irqrestore(&io_chain_lock, flags);
}
/**
* _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;
}
/**
* _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.
*/
ARM: OMAP: fix __init section mismatch for _enable_preprogram _enable_preprogram is marked as __init, but is called from _enable which is not. Without this patch, the board oopses after init. Tested on custom hardware and on beagle board xM. Otherwise we can get: Unable to handle kernel paging request at virtual address 000b0012 pgd = cf968000 *pgd=8fb06831, *pte=00000000, *ppte=00000000 PREEMPT ARM Modules linked in: CPU: 0 Not tainted (3.9.0 #2) PC is at _enable_preprogram+0x1c/0x24 LR is at omap_hwmod_enable+0x34/0x60 psr: 80000093 sp : cf95de08 ip : 00002de5 fp : bec33d4c r10: 00000000 r9 : 00000002 r8 : b6dd2c78 r7 : 00000004 r6 : 00000000 r5 : a0000013 r4 : cf95c000 r3 : 00000000 r2 : b6dd2c7c r1 : 00000000 r0 : 000b0012 Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8f968019 DAC: 00000015 Process otpcmd (pid: 607, stack limit = 0xcf95c230) Stack: (0xcf95de08 to 0xcf95e000) de00: 00000001 cf91f840 00000000 c001d6fc 00000002 cf91f840 de20: cf8f7e10 c001de54 cf8f7e10 c001de78 c001de68 c01d5e80 00000000 cf8f7e10 de40: cf8f7e10 c01d5f28 cf8f7e10 c0530d30 00000000 c01d6f28 00000000 c0088664 de60: b6ea1000 cfb05284 cf95c000 00000001 cf95c000 60000013 00000001 cf95dee4 de80: cf870050 c01d7308 cf870010 cf870050 00000001 c0278b14 c0526f28 00000000 dea0: cf870050 ffff8e18 00000001 cf95dee4 00000000 c0274f7c cf870050 00000001 dec0: cf95dee4 cf1d8484 000000e0 c0276464 00000008 cf9c0000 00000007 c0276980 dee0: cf9c0000 00000064 00000008 cf1d8404 cf1d8400 c01cc05c 0000270a cf1d8504 df00: 00000023 cf1d8484 00000007 c01cc670 00000bdd 00000001 00000000 cf449e60 df20: cf1dde70 cf1d8400 bec33d18 cf1d8504 c0246f00 00000003 cf95c000 00000000 df40: bec33d4c c01cd078 00000003 cf1d8504 00000081 c01cbcb8 bec33d18 00000003 df60: bec33d18 c00a9034 00002000 c00a9c68 cf92fe00 00000003 c0246f00 cf92fe00 df80: 00000000 c00a9cb0 00000003 00000000 00008e70 00000000 b6f17000 00000036 dfa0: c000e484 c000e300 00008e70 00000000 00000003 c0246f00 bec33d18 bec33d18 dfc0: 00008e70 00000000 b6f17000 00000036 00000000 00000000 b6f6d000 bec33d4c dfe0: b6ea1bd0 bec33d0c 00008c9c b6ea1bdc 60000010 00000003 00000000 00000000 (_omap_device_enable_hwmods+0x20/0x34) (omap_device_enable+0x3c/0x50) (_od_runtime_resume+0x10/0x1c) (__rpm_callback+0x54/0x98) (rpm_callback+0x64/0x7c) (rpm_resume+0x434/0x554) (__pm_runtime_resume+0x48/0x74) (omap_i2c_xfer+0x28/0xe8) (__i2c_transfer+0x3c/0x78) (i2c_transfer+0x6c/0xc0) (i2c_master_send+0x38/0x48) (sha204p_send_command+0x60/0x9c) (sha204c_send_and_receive+0x5c/0x1e0) (sha204m_read+0x94/0xa0) (otp_do_read+0x50/0xa4) (vfs_ioctl+0x24/0x40) (do_vfs_ioctl+0x1b0/0x1c0) (sys_ioctl+0x38/0x54) (ret_fast_syscall+0x0/0x30) Code: e1a08002 ea000009 e598003c e592c05c (e7904003) Cc: stable@vger.kernel.org Signed-off-by: Jean-Philippe Fran=C3=A7ois <jp.francois@cynove.com> Acked-by: Kevin Hilman <khilman@linaro.org> [tony@atomide.com: updated description with oops] Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-05-17 02:25:07 +08:00
static int _enable_preprogram(struct omap_hwmod *oh)
{
if (!oh->class->enable_preprogram)
return 0;
return oh->class->enable_preprogram(oh);
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* _enable - enable an omap_hwmod
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* register target. Returns -EINVAL if the hwmod is in the wrong
* state or passes along the return value of _wait_target_ready().
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static int _enable(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
int hwsup = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
pr_debug("omap_hwmod: %s: enabling\n", oh->name);
/*
* 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.
*/
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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (oh->_state != _HWMOD_STATE_INITIALIZED &&
oh->_state != _HWMOD_STATE_IDLE &&
oh->_state != _HWMOD_STATE_DISABLED) {
WARN(1, "omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state\n",
oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
}
/*
* 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.
*/
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;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* Mux pins for device runtime if populated */
if (oh->mux && (!oh->mux->enabled ||
((oh->_state == _HWMOD_STATE_IDLE) &&
oh->mux->pads_dynamic))) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
_reconfigure_io_chain();
} else if (oh->flags & HWMOD_RECONFIG_IO_CHAIN) {
_reconfigure_io_chain();
}
_add_initiator_dep(oh, mpu_oh);
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);
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;
}
}
_enable_clocks(oh);
if (soc_ops.enable_module)
soc_ops.enable_module(oh);
if (oh->flags & HWMOD_BLOCK_WFI)
cpu_idle_poll_ctrl(true);
if (soc_ops.update_context_lost)
soc_ops.update_context_lost(oh);
r = (soc_ops.wait_target_ready) ? soc_ops.wait_target_ready(oh) :
-EINVAL;
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);
}
r = _enable_preprogram(oh);
} else {
if (soc_ops.disable_module)
soc_ops.disable_module(oh);
_disable_clocks(oh);
pr_err("omap_hwmod: %s: _wait_target_ready failed: %d\n",
oh->name, r);
if (oh->clkdm)
clkdm_hwmod_disable(oh->clkdm, oh);
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return r;
}
/**
* _idle - idle an omap_hwmod
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* no further work. Returns -EINVAL if the hwmod is in the wrong
* state or returns 0.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static int _idle(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
pr_debug("omap_hwmod: %s: idling\n", oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (oh->_state != _HWMOD_STATE_ENABLED) {
WARN(1, "omap_hwmod: %s: idle state can only be entered from enabled state\n",
oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
}
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;
if (oh->class->sysc)
_idle_sysc(oh);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_del_initiator_dep(oh, mpu_oh);
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported If the module does not have any modulemode, the _disable_module function will do nothing. There is then no point waiting for a idle status change. It will remove the following warnings. [ 0.331848] omap_hwmod: dmm: _wait_target_disable failed [ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed [ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed [ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed [ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed [ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed Note: For such module, the state is managed automatically by HW according to clock domain transition. It is then not possible to wait for idle even later in the _idle function since the status will change at clock domain boundary. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved _wait_target_disable() into _disable_module(), removing duplicate code] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-17 08:09:11 +08:00
if (oh->flags & HWMOD_BLOCK_WFI)
cpu_idle_poll_ctrl(false);
if (soc_ops.disable_module)
soc_ops.disable_module(oh);
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported If the module does not have any modulemode, the _disable_module function will do nothing. There is then no point waiting for a idle status change. It will remove the following warnings. [ 0.331848] omap_hwmod: dmm: _wait_target_disable failed [ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed [ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed [ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed [ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed [ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed Note: For such module, the state is managed automatically by HW according to clock domain transition. It is then not possible to wait for idle even later in the _idle function since the status will change at clock domain boundary. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved _wait_target_disable() into _disable_module(), removing duplicate code] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-17 08:09:11 +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);
if (oh->clkdm)
clkdm_hwmod_disable(oh->clkdm, oh);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* Mux pins for device idle if populated */
if (oh->mux && oh->mux->pads_dynamic) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
_reconfigure_io_chain();
} else if (oh->flags & HWMOD_RECONFIG_IO_CHAIN) {
_reconfigure_io_chain();
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
int ret, i;
u8 prev_state;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (oh->_state != _HWMOD_STATE_IDLE &&
oh->_state != _HWMOD_STATE_ENABLED) {
WARN(1, "omap_hwmod: %s: disabled state can only be entered from idle, or enabled state\n",
oh->name);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
}
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;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
pr_debug("omap_hwmod: %s: disabling\n", oh->name);
if (oh->class->pre_shutdown) {
prev_state = oh->_state;
if (oh->_state == _HWMOD_STATE_IDLE)
_enable(oh);
ret = oh->class->pre_shutdown(oh);
if (ret) {
if (prev_state == _HWMOD_STATE_IDLE)
_idle(oh);
return ret;
}
}
if (oh->class->sysc) {
if (oh->_state == _HWMOD_STATE_IDLE)
_enable(oh);
_shutdown_sysc(oh);
}
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
/* 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 */
if (oh->flags & HWMOD_BLOCK_WFI)
cpu_idle_poll_ctrl(false);
if (soc_ops.disable_module)
soc_ops.disable_module(oh);
_disable_clocks(oh);
if (oh->clkdm)
clkdm_hwmod_disable(oh->clkdm, oh);
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/* XXX Should this code also force-disable the optional clocks? */
for (i = 0; i < oh->rst_lines_cnt; i++)
_assert_hardreset(oh, oh->rst_lines[i].name);
/* Mux pins to safe mode or use populated off mode values */
if (oh->mux)
omap_hwmod_mux(oh->mux, _HWMOD_STATE_DISABLED);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
}
/**
* 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
*
* 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.
*/
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)
{
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;
}
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;
}
}
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;
}
/**
* _init_mpu_rt_base - populate the virtual address for a hwmod
* @oh: struct omap_hwmod * to locate the virtual address
* @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
* @np: struct device_node * of the IP block's device node in the DT data
*
* 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.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
*/
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)
{
struct omap_hwmod_addr_space *mem;
void __iomem *va_start = NULL;
if (!oh)
return -EINVAL;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
_save_mpu_port_index(oh);
if (oh->_int_flags & _HWMOD_NO_MPU_PORT)
return -ENXIO;
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug("omap_hwmod: %s: no MPU register target found\n",
oh->name);
/* Extract the IO space from device tree blob */
if (!np)
return -ENXIO;
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);
} else {
va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start);
}
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);
return -ENXIO;
}
pr_debug("omap_hwmod: %s: MPU register target at va %p\n",
oh->name, va_start);
oh->_mpu_rt_va = va_start;
return 0;
}
/**
* _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
* upon success or if the hwmod isn't registered or if the hwmod's
* address space is not defined, or -EINVAL upon failure.
*/
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;
struct device_node *np = NULL;
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);
}
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);
if (r < 0) {
WARN(1, "omap_hwmod: %s: doesn't have mpu register target base\n",
oh->name);
return 0;
}
}
r = _init_clocks(oh, NULL);
if (r < 0) {
WARN(1, "omap_hwmod: %s: couldn't init clocks\n", oh->name);
return -EINVAL;
}
if (np) {
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;
}
oh->_state = _HWMOD_STATE_INITIALIZED;
return 0;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* _setup_iclk_autoidle - configure an IP block's interface clocks
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
* @oh: struct omap_hwmod *
*
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static void __init _setup_iclk_autoidle(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
struct omap_hwmod_ocp_if *os;
struct list_head *p;
int i = 0;
if (oh->_state != _HWMOD_STATE_INITIALIZED)
return;
p = oh->slave_ports.next;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
while (i < oh->slaves_cnt) {
os = _fetch_next_ocp_if(&p, &i);
if (!os->_clk)
continue;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (os->flags & OCPIF_SWSUP_IDLE) {
/* XXX omap_iclk_deny_idle(c); */
} else {
/* XXX omap_iclk_allow_idle(c); */
clk_enable(os->_clk);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14: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;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +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) {
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;
}
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!(oh->flags & HWMOD_INIT_NO_RESET))
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;
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) &&
(postsetup_state == _HWMOD_STATE_IDLE)) {
oh->_int_flags |= _HWMOD_SKIP_ENABLE;
postsetup_state = _HWMOD_STATE_ENABLED;
}
if (postsetup_state == _HWMOD_STATE_IDLE)
_idle(oh);
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);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14: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;
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);
}
_setup_iclk_autoidle(oh);
if (!_setup_reset(oh))
_setup_postsetup(oh);
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);
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
/**
* _register - register a struct omap_hwmod
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
* @oh: struct omap_hwmod *
*
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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.
*/
static int __init _register(struct omap_hwmod *oh)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
if (!oh || !oh->name || !oh->class || !oh->class->name ||
(oh->_state != _HWMOD_STATE_UNKNOWN))
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return -EINVAL;
pr_debug("omap_hwmod: %s: registering\n", oh->name);
if (_lookup(oh->name))
return -EEXIST;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
list_add_tail(&oh->node, &omap_hwmod_list);
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
INIT_LIST_HEAD(&oh->master_ports);
INIT_LIST_HEAD(&oh->slave_ports);
spin_lock_init(&oh->_lock);
lockdep_set_class(&oh->_lock, &oh->hwmod_key);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
oh->_state = _HWMOD_STATE_REGISTERED;
/*
* 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;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
}
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
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;
*ml = memblock_virt_alloc(sz, 0);
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
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);
linkspace = memblock_virt_alloc(sz, 0);
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
return 0;
}
/* Static functions intended only for use in soc_ops field function pointers */
/**
* _omap2xxx_3xxx_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 _omap2xxx_3xxx_wait_target_ready(struct omap_hwmod *oh)
{
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 */
return omap_cm_wait_module_ready(0, oh->prcm.omap2.module_offs,
oh->prcm.omap2.idlest_reg_id,
oh->prcm.omap2.idlest_idle_bit);
}
/**
* _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)
{
if (!oh)
return -EINVAL;
if (oh->flags & HWMOD_NO_IDLEST || !oh->clkdm)
return 0;
if (!_find_mpu_rt_port(oh))
return 0;
/* XXX check module SIDLEMODE, hardreset status */
return omap_cm_wait_module_ready(oh->clkdm->prcm_partition,
oh->clkdm->cm_inst,
oh->prcm.omap4.clkctrl_offs, 0);
}
/**
* _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)
{
return omap_prm_assert_hardreset(ohri->rst_shift, 0,
oh->prcm.omap2.module_offs, 0);
}
/**
* _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)
{
return omap_prm_deassert_hardreset(ohri->rst_shift, ohri->st_shift, 0,
oh->prcm.omap2.module_offs, 0, 0);
}
/**
* _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)
{
return omap_prm_is_hardreset_asserted(ohri->st_shift, 0,
oh->prcm.omap2.module_offs, 0);
}
/**
* _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)
{
if (!oh->clkdm)
return -EINVAL;
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);
}
/**
* _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)
{
if (!oh->clkdm)
return -EINVAL;
if (ohri->st_shift)
pr_err("omap_hwmod: %s: %s: hwmod data error: OMAP4 does not support st_shift\n",
oh->name, ohri->name);
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);
}
/**
* _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)
{
if (!oh->clkdm)
return -EINVAL;
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);
}
/**
* _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)
{
return omap_prm_assert_hardreset(ohri->rst_shift, 0,
oh->clkdm->pwrdm.ptr->prcm_offs,
oh->prcm.omap4.rstctrl_offs);
}
/**
* _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)
{
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);
}
/**
* _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)
{
return omap_prm_is_hardreset_asserted(ohri->rst_shift, 0,
oh->clkdm->pwrdm.ptr->prcm_offs,
oh->prcm.omap4.rstctrl_offs);
}
/* Public functions */
u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs)
{
if (oh->flags & HWMOD_16BIT_REG)
return readw_relaxed(oh->_mpu_rt_va + reg_offs);
else
return readl_relaxed(oh->_mpu_rt_va + reg_offs);
}
void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs)
{
if (oh->flags & HWMOD_16BIT_REG)
writew_relaxed(v, oh->_mpu_rt_va + reg_offs);
else
writel_relaxed(v, oh->_mpu_rt_va + reg_offs);
}
/**
* 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)
{
u32 v;
int ret;
if (!oh || !(oh->_sysc_cache))
return -EINVAL;
v = oh->_sysc_cache;
ret = _set_softreset(oh, &v);
if (ret)
goto error;
_write_sysconfig(v, oh);
ret = _clear_softreset(oh, &v);
if (ret)
goto error;
_write_sysconfig(v, oh);
error:
return ret;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* @data: void * data to pass to callback function
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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.
*/
int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
void *data)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
struct omap_hwmod *temp_oh;
int ret = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!fn)
return -EINVAL;
list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
ret = (*fn)(temp_oh, data);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (ret)
break;
}
return ret;
}
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
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
* 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.
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
*/
int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois)
{
int r, i;
if (!inited)
return -EINVAL;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
if (!ois)
return 0;
if (ois[0] == NULL) /* Empty list */
return 0;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
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;
}
/**
* _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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static void __init _ensure_mpu_hwmod_is_setup(struct omap_hwmod *oh)
{
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);
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* omap_hwmod_setup_one - set up a single hwmod
* @oh_name: const char * name of the already-registered hwmod to set up
*
* 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.
*/
int __init omap_hwmod_setup_one(const char *oh_name)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
struct omap_hwmod *oh;
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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_ensure_mpu_hwmod_is_setup(oh);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_init(oh, NULL);
_setup(oh, NULL);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
/**
* omap_hwmod_setup_all - set up all registered IP blocks
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
static int __init omap_hwmod_setup_all(void)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
_ensure_mpu_hwmod_is_setup(NULL);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
omap_hwmod_for_each(_init, NULL);
omap_hwmod_for_each(_setup, NULL);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
omap_core_initcall(omap_hwmod_setup_all);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
* Enable an omap_hwmod @oh. Intended to be called by omap_device_enable().
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
unsigned long flags;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh)
return -EINVAL;
spin_lock_irqsave(&oh->_lock, flags);
r = _enable(oh);
spin_unlock_irqrestore(&oh->_lock, flags);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return r;
}
/**
* omap_hwmod_idle - idle an omap_hwmod
* @oh: struct omap_hwmod *
*
* Idle an omap_hwmod @oh. Intended to be called by omap_device_idle().
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
unsigned long flags;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh)
return -EINVAL;
spin_lock_irqsave(&oh->_lock, flags);
_idle(oh);
spin_unlock_irqrestore(&oh->_lock, flags);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
/**
* omap_hwmod_shutdown - shutdown an omap_hwmod
* @oh: struct omap_hwmod *
*
* Shutdown an omap_hwmod @oh. Intended to be called by
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
unsigned long flags;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh)
return -EINVAL;
spin_lock_irqsave(&oh->_lock, flags);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
_shutdown(oh);
spin_unlock_irqrestore(&oh->_lock, flags);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
/*
* IP block data retrieval functions
*/
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
/**
* omap_hwmod_count_resources - count number of struct resources needed by hwmod
* @oh: struct omap_hwmod *
* @flags: Type of resources to include when counting (IRQ/DMA/MEM)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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.
*
*/
int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
{
int ret = 0;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (flags & IORESOURCE_IRQ)
ret += _count_mpu_irqs(oh);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (flags & IORESOURCE_DMA)
ret += _count_sdma_reqs(oh);
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +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);
}
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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)
{
struct omap_hwmod_ocp_if *os;
struct list_head *p;
int i, j, mpu_irqs_cnt, sdma_reqs_cnt, addr_cnt;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
int r = 0;
/* For each IRQ, DMA, memory area, fill in array.*/
mpu_irqs_cnt = _count_mpu_irqs(oh);
for (i = 0; i < mpu_irqs_cnt; i++) {
unsigned int irq;
if (oh->xlate_irq)
irq = oh->xlate_irq((oh->mpu_irqs + i)->irq);
else
irq = (oh->mpu_irqs + i)->irq;
(res + r)->name = (oh->mpu_irqs + i)->name;
(res + r)->start = irq;
(res + r)->end = irq;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
(res + r)->flags = IORESOURCE_IRQ;
r++;
}
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;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
(res + r)->flags = IORESOURCE_DMA;
r++;
}
p = oh->slave_ports.next;
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 18:04:30 +08:00
i = 0;
while (i < oh->slaves_cnt) {
os = _fetch_next_ocp_if(&p, &i);
addr_cnt = _count_ocp_if_addr_spaces(os);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
for (j = 0; j < addr_cnt; j++) {
(res + r)->name = (os->addr + j)->name;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
}
/**
* 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;
}
/**
* 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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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;
struct omap_hwmod_ocp_if *oi;
struct clockdomain *clkdm;
struct clk_hw_omap *clk;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (!oh)
return NULL;
if (oh->clkdm)
return oh->clkdm->pwrdm.ptr;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
if (oh->_clk) {
c = oh->_clk;
} else {
oi = _find_mpu_rt_port(oh);
if (!oi)
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return NULL;
c = oi->_clk;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
}
clk = to_clk_hw_omap(__clk_get_hw(c));
clkdm = clk->clkdm;
if (!clkdm)
return NULL;
return clkdm->pwrdm.ptr;
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +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;
}
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
{
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;
spin_lock_irqsave(&oh->_lock, flags);
if (oh->class->sysc &&
(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)) {
v = oh->_sysc_cache;
_enable_wakeup(oh, &v);
_write_sysconfig(v, oh);
}
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(&oh->_lock, flags);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
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
* 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.
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
*/
int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
{
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;
spin_lock_irqsave(&oh->_lock, flags);
if (oh->class->sysc &&
(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP)) {
v = oh->_sysc_cache;
_disable_wakeup(oh, &v);
_write_sysconfig(v, oh);
}
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(&oh->_lock, flags);
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-04 01:14:03 +08:00
return 0;
}
/**
* 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;
unsigned long flags;
if (!oh)
return -EINVAL;
spin_lock_irqsave(&oh->_lock, flags);
ret = _assert_hardreset(oh, name);
spin_unlock_irqrestore(&oh->_lock, flags);
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;
unsigned long flags;
if (!oh)
return -EINVAL;
spin_lock_irqsave(&oh->_lock, flags);
ret = _deassert_hardreset(oh, name);
spin_unlock_irqrestore(&oh->_lock, flags);
return ret;
}
/**
* 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
*
* For each omap_hwmod of class @classname, call @fn.
* If the callback function returns something other than
* 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;
}
/**
* 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
*
* Sets the hwmod state that @oh will enter at the end of _setup()
* (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.
*/
int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state)
{
int ret;
unsigned long flags;
if (!oh)
return -EINVAL;
if (state != _HWMOD_STATE_DISABLED &&
state != _HWMOD_STATE_ENABLED &&
state != _HWMOD_STATE_IDLE)
return -EINVAL;
spin_lock_irqsave(&oh->_lock, flags);
if (oh->_state != _HWMOD_STATE_REGISTERED) {
ret = -EINVAL;
goto ohsps_unlock;
}
oh->_postsetup_state = state;
ret = 0;
ohsps_unlock:
spin_unlock_irqrestore(&oh->_lock, flags);
return ret;
}
/**
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
* Returns the context loss count of associated @oh
* upon success, or zero if no context loss data is available.
*
* 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.
*/
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
{
struct powerdomain *pwrdm;
int ret = 0;
if (soc_ops.get_context_lost)
return soc_ops.get_context_lost(oh);
pwrdm = omap_hwmod_get_pwrdm(oh);
if (pwrdm)
ret = pwrdm_get_context_loss_count(pwrdm);
return ret;
}
/**
* 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)
{
if (cpu_is_omap24xx()) {
soc_ops.wait_target_ready = _omap2xxx_3xxx_wait_target_ready;
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()) {
soc_ops.wait_target_ready = _omap2xxx_3xxx_wait_target_ready;
soc_ops.assert_hardreset = _omap2_assert_hardreset;
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
} else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
soc_ops.assert_hardreset = _omap4_assert_hardreset;
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
soc_ops.update_context_lost = _omap4_update_context_lost;
soc_ops.get_context_lost = _omap4_get_context_lost;
} 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;
soc_ops.assert_hardreset = _omap4_assert_hardreset;
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
} else if (cpu_is_ti816x() || soc_is_am33xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
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;
} else {
WARN(1, "omap_hwmod: unknown SoC type\n");
}
inited = true;
}
/**
* 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;
}