linux/arch/arm/plat-omap/include/plat/omap_hwmod.h

471 lines
16 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-03 17:14:03 +00:00
/*
* omap_hwmod macros, structures
*
* Copyright (C) 2009 Nokia Corporation
* Paul Walmsley
*
* Created in collaboration with (alphabetical order): Benoit Cousson,
* Kevin Hilman, Tony Lindgren, Rajendra Nayak, Vikram Pandita, Sakari
* Poussa, Anand Sawant, Santosh Shilimkar, Richard Woodruff
*
* 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.
*
* These headers and macros are used to define OMAP on-chip module
* data and their integration with other OMAP modules and Linux.
*
* References:
* - 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:
* - add interconnect error log structures
* - add pinmuxing
* - init_conn_id_bit (CONNID_BIT_VECTOR)
* - implement default hwmod SMS/SDRC flags?
*
*/
#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_HWMOD_H
#define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_HWMOD_H
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <plat/cpu.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-03 17:14:03 +00:00
struct omap_device;
/* OCP SYSCONFIG bit shifts/masks */
#define SYSC_MIDLEMODE_SHIFT 12
#define SYSC_MIDLEMODE_MASK (0x3 << SYSC_MIDLEMODE_SHIFT)
#define SYSC_CLOCKACTIVITY_SHIFT 8
#define SYSC_CLOCKACTIVITY_MASK (0x3 << SYSC_CLOCKACTIVITY_SHIFT)
#define SYSC_SIDLEMODE_SHIFT 3
#define SYSC_SIDLEMODE_MASK (0x3 << SYSC_SIDLEMODE_SHIFT)
#define SYSC_ENAWAKEUP_SHIFT 2
#define SYSC_ENAWAKEUP_MASK (1 << SYSC_ENAWAKEUP_SHIFT)
#define SYSC_SOFTRESET_SHIFT 1
#define SYSC_SOFTRESET_MASK (1 << SYSC_SOFTRESET_SHIFT)
#define SYSC_AUTOIDLE_SHIFT 0
#define SYSC_AUTOIDLE_MASK (1 << SYSC_AUTOIDLE_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-03 17:14:03 +00:00
/* OCP SYSSTATUS bit shifts/masks */
#define SYSS_RESETDONE_SHIFT 0
#define SYSS_RESETDONE_MASK (1 << SYSS_RESETDONE_SHIFT)
/* Master standby/slave idle mode flags */
#define HWMOD_IDLEMODE_FORCE (1 << 0)
#define HWMOD_IDLEMODE_NO (1 << 1)
#define HWMOD_IDLEMODE_SMART (1 << 2)
/**
* struct omap_hwmod_irq_info - MPU IRQs used by the hwmod
* @name: name of the IRQ channel (module local name)
* @irq_ch: IRQ channel ID
*
* @name should be something short, e.g., "tx" or "rx". It is for use
* by platform_get_resource_byname(). It is defined locally to the
* hwmod.
*/
struct omap_hwmod_irq_info {
const char *name;
u16 irq;
};
/**
* struct omap_hwmod_dma_info - DMA channels used by the 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-03 17:14:03 +00:00
* @name: name of the DMA channel (module local name)
* @dma_ch: DMA channel ID
*
* @name should be something short, e.g., "tx" or "rx". It is for use
* by platform_get_resource_byname(). It is defined locally to the
* hwmod.
*/
struct omap_hwmod_dma_info {
const char *name;
u16 dma_ch;
};
/**
* struct omap_hwmod_opt_clk - optional clocks used by this hwmod
* @role: "sys", "32k", "tv", etc -- for use in clk_get()
* @clkdev_dev_id: opt clock: clkdev dev_id string
* @clkdev_con_id: opt clock: clkdev con_id string
* @_clk: pointer to the struct clk (filled in at runtime)
*
* The module's interface clock and main functional clock should not
* be added as optional clocks.
*/
struct omap_hwmod_opt_clk {
const char *role;
const char *clkdev_dev_id;
const char *clkdev_con_id;
struct clk *_clk;
};
/* omap_hwmod_omap2_firewall.flags bits */
#define OMAP_FIREWALL_L3 (1 << 0)
#define OMAP_FIREWALL_L4 (1 << 1)
/**
* struct omap_hwmod_omap2_firewall - OMAP2/3 device firewall data
* @l3_perm_bit: bit shift for L3_PM_*_PERMISSION_*
* @l4_fw_region: L4 firewall region ID
* @l4_prot_group: L4 protection group ID
* @flags: (see omap_hwmod_omap2_firewall.flags macros above)
*/
struct omap_hwmod_omap2_firewall {
u8 l3_perm_bit;
u8 l4_fw_region;
u8 l4_prot_group;
u8 flags;
};
/*
* omap_hwmod_addr_space.flags bits
*
* ADDR_MAP_ON_INIT: Map this address space during omap_hwmod init.
* ADDR_TYPE_RT: Address space contains module register target data.
*/
#define ADDR_MAP_ON_INIT (1 << 0)
#define ADDR_TYPE_RT (1 << 1)
/**
* struct omap_hwmod_addr_space - MPU address space handled by the hwmod
* @pa_start: starting physical address
* @pa_end: ending physical address
* @flags: (see omap_hwmod_addr_space.flags macros above)
*
* Address space doesn't necessarily follow physical interconnect
* structure. GPMC is one example.
*/
struct omap_hwmod_addr_space {
u32 pa_start;
u32 pa_end;
u8 flags;
};
/*
* omap_hwmod_ocp_if.user bits: these indicate the initiators that use this
* interface to interact with the hwmod. Used to add sleep dependencies
* when the module is enabled or disabled.
*/
#define OCP_USER_MPU (1 << 0)
#define OCP_USER_SDMA (1 << 1)
/* omap_hwmod_ocp_if.flags bits */
#define OCPIF_HAS_IDLEST (1 << 0)
#define OCPIF_SWSUP_IDLE (1 << 1)
#define OCPIF_CAN_BURST (1 << 2)
/**
* struct omap_hwmod_ocp_if - OCP interface data
* @master: struct omap_hwmod that initiates OCP transactions on this link
* @slave: struct omap_hwmod that responds to OCP transactions on this link
* @addr: address space associated with this link
* @clkdev_dev_id: interface clock: clkdev dev_id string
* @clkdev_con_id: interface clock: clkdev con_id string
* @_clk: pointer to the interface struct clk (filled in at runtime)
* @fw: interface firewall data
* @addr_cnt: ARRAY_SIZE(@addr)
* @width: OCP data width
* @thread_cnt: number of threads
* @max_burst_len: maximum burst length in @width sized words (0 if unlimited)
* @user: initiators using this interface (see OCP_USER_* macros above)
* @flags: OCP interface flags (see OCPIF_* macros above)
*
* It may also be useful to add a tag_cnt field for OCP2.x devices.
*
* Parameter names beginning with an underscore are managed internally by
* the omap_hwmod code and should not be set during initialization.
*/
struct omap_hwmod_ocp_if {
struct omap_hwmod *master;
struct omap_hwmod *slave;
struct omap_hwmod_addr_space *addr;
const char *clkdev_dev_id;
const char *clkdev_con_id;
struct clk *_clk;
union {
struct omap_hwmod_omap2_firewall omap2;
} fw;
u8 addr_cnt;
u8 width;
u8 thread_cnt;
u8 max_burst_len;
u8 user;
u8 flags;
};
/* Macros for use in struct omap_hwmod_sysconfig */
/* Flags for use in omap_hwmod_sysconfig.idlemodes */
#define MASTER_STANDBY_SHIFT 2
#define SLAVE_IDLE_SHIFT 0
#define SIDLE_FORCE (HWMOD_IDLEMODE_FORCE << SLAVE_IDLE_SHIFT)
#define SIDLE_NO (HWMOD_IDLEMODE_NO << SLAVE_IDLE_SHIFT)
#define SIDLE_SMART (HWMOD_IDLEMODE_SMART << SLAVE_IDLE_SHIFT)
#define MSTANDBY_FORCE (HWMOD_IDLEMODE_FORCE << MASTER_STANDBY_SHIFT)
#define MSTANDBY_NO (HWMOD_IDLEMODE_NO << MASTER_STANDBY_SHIFT)
#define MSTANDBY_SMART (HWMOD_IDLEMODE_SMART << MASTER_STANDBY_SHIFT)
/* omap_hwmod_sysconfig.sysc_flags capability flags */
#define SYSC_HAS_AUTOIDLE (1 << 0)
#define SYSC_HAS_SOFTRESET (1 << 1)
#define SYSC_HAS_ENAWAKEUP (1 << 2)
#define SYSC_HAS_EMUFREE (1 << 3)
#define SYSC_HAS_CLOCKACTIVITY (1 << 4)
#define SYSC_HAS_SIDLEMODE (1 << 5)
#define SYSC_HAS_MIDLEMODE (1 << 6)
#define SYSS_MISSING (1 << 7)
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 00:30:51 +00:00
#define SYSC_NO_CACHE (1 << 8) /* XXX SW flag, belongs elsewhere */
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-03 17:14:03 +00:00
/* omap_hwmod_sysconfig.clockact flags */
#define CLOCKACT_TEST_BOTH 0x0
#define CLOCKACT_TEST_MAIN 0x1
#define CLOCKACT_TEST_ICLK 0x2
#define CLOCKACT_TEST_NONE 0x3
/**
* struct omap_hwmod_sysconfig - hwmod OCP_SYSCONFIG/OCP_SYSSTATUS data
* @rev_offs: IP block revision register offset (from module base addr)
* @sysc_offs: OCP_SYSCONFIG register offset (from module base addr)
* @syss_offs: OCP_SYSSTATUS register offset (from module base addr)
* @idlemodes: One or more of {SIDLE,MSTANDBY}_{OFF,FORCE,SMART}
* @sysc_flags: SYS{C,S}_HAS* flags indicating SYSCONFIG bits supported
* @clockact: the default value of the module CLOCKACTIVITY bits
*
* @clockact describes to the module which clocks are likely to be
* disabled when the PRCM issues its idle request to the module. Some
* modules have separate clockdomains for the interface clock and main
* functional clock, and can check whether they should acknowledge the
* idle request based on the internal module functionality that has
* been associated with the clocks marked in @clockact. This field is
* only used if HWMOD_SET_DEFAULT_CLOCKACT is set (see below)
*
*/
struct omap_hwmod_sysconfig {
u16 rev_offs;
u16 sysc_offs;
u16 syss_offs;
u8 idlemodes;
u8 sysc_flags;
u8 clockact;
};
/**
* struct omap_hwmod_omap2_prcm - OMAP2/3-specific PRCM data
* @module_offs: PRCM submodule offset from the start of the PRM/CM
* @prcm_reg_id: PRCM register ID (e.g., 3 for CM_AUTOIDLE3)
* @module_bit: register bit shift for AUTOIDLE, WKST, WKEN, GRPSEL regs
* @idlest_reg_id: IDLEST register ID (e.g., 3 for CM_IDLEST3)
* @idlest_idle_bit: register bit shift for CM_IDLEST slave idle bit
* @idlest_stdby_bit: register bit shift for CM_IDLEST master standby bit
*
* @prcm_reg_id and @module_bit are specific to the AUTOIDLE, WKST,
* WKEN, GRPSEL registers. In an ideal world, no extra information
* would be needed for IDLEST information, but alas, there are some
* exceptions, so @idlest_reg_id, @idlest_idle_bit, @idlest_stdby_bit
* are needed for the IDLEST registers (c.f. 2430 I2CHS, 3430 USBHOST)
*/
struct omap_hwmod_omap2_prcm {
s16 module_offs;
u8 prcm_reg_id;
u8 module_bit;
u8 idlest_reg_id;
u8 idlest_idle_bit;
u8 idlest_stdby_bit;
};
/**
* struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data
* @module_offs: PRCM submodule offset from the start of the PRM/CM1/CM2
* @device_offs: device register offset from @module_offs
* @submodule_wkdep_bit: bit shift of the WKDEP range
*/
struct omap_hwmod_omap4_prcm {
u32 module_offs;
u16 device_offs;
u8 submodule_wkdep_bit;
};
/*
* omap_hwmod.flags definitions
*
* HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring module in and out
* of idle, rather than relying on module smart-idle
* HWMOD_SWSUP_MSTDBY: omap_hwmod code should manually bring module in and out
* of standby, rather than relying on module smart-standby
* HWMOD_INIT_NO_RESET: don't reset this module at boot - important for
* SDRAM controller, etc.
* HWMOD_INIT_NO_IDLE: don't idle this module at boot - important for SDRAM
* controller, etc.
* HWMOD_NO_AUTOIDLE: disable module autoidle (OCP_SYSCONFIG.AUTOIDLE)
* when module is enabled, rather than the default, which is to
* enable autoidle
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-03 17:14:03 +00:00
* HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup
*/
#define HWMOD_SWSUP_SIDLE (1 << 0)
#define HWMOD_SWSUP_MSTANDBY (1 << 1)
#define HWMOD_INIT_NO_RESET (1 << 2)
#define HWMOD_INIT_NO_IDLE (1 << 3)
#define HWMOD_NO_OCP_AUTOIDLE (1 << 4)
#define HWMOD_SET_DEFAULT_CLOCKACT (1 << 5)
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-03 17:14:03 +00:00
/*
* omap_hwmod._int_flags definitions
* These are for internal use only and are managed by the omap_hwmod code.
*
* _HWMOD_NO_MPU_PORT: no path exists for the MPU to write to this module
* _HWMOD_WAKEUP_ENABLED: set when the omap_hwmod code has enabled ENAWAKEUP
* _HWMOD_SYSCONFIG_LOADED: set when the OCP_SYSCONFIG value has been cached
*/
#define _HWMOD_NO_MPU_PORT (1 << 0)
#define _HWMOD_WAKEUP_ENABLED (1 << 1)
#define _HWMOD_SYSCONFIG_LOADED (1 << 2)
/*
* omap_hwmod._state definitions
*
* INITIALIZED: reset (optionally), initialized, enabled, disabled
* (optionally)
*
*
*/
#define _HWMOD_STATE_UNKNOWN 0
#define _HWMOD_STATE_REGISTERED 1
#define _HWMOD_STATE_CLKS_INITED 2
#define _HWMOD_STATE_INITIALIZED 3
#define _HWMOD_STATE_ENABLED 4
#define _HWMOD_STATE_IDLE 5
#define _HWMOD_STATE_DISABLED 6
/**
* struct omap_hwmod - integration data for OMAP hardware "modules" (IP blocks)
* @name: name of the hwmod
* @od: struct omap_device currently associated with this hwmod (internal use)
* @mpu_irqs: ptr to an array of MPU IRQs (see also mpu_irqs_cnt)
* @sdma_chs: ptr to an array of SDMA channel IDs (see also sdma_chs_cnt)
* @prcm: PRCM data pertaining to this hwmod
* @clkdev_dev_id: main clock: clkdev dev_id string
* @clkdev_con_id: main clock: clkdev con_id string
* @_clk: pointer to the main struct clk (filled in at runtime)
* @opt_clks: other device clocks that drivers can request (0..*)
* @masters: ptr to array of OCP ifs that this hwmod can initiate on
* @slaves: ptr to array of OCP ifs that this hwmod can respond on
* @sysconfig: device SYSCONFIG/SYSSTATUS register data
* @dev_attr: arbitrary device attributes that can be passed to the driver
* @_sysc_cache: internal-use hwmod flags
* @_rt_va: cached register target start address (internal use)
* @_mpu_port_index: cached MPU register target slave ID (internal use)
* @msuspendmux_reg_id: CONTROL_MSUSPENDMUX register ID (1-6)
* @msuspendmux_shift: CONTROL_MSUSPENDMUX register bit shift
* @mpu_irqs_cnt: number of @mpu_irqs
* @sdma_chs_cnt: number of @sdma_chs
* @opt_clks_cnt: number of @opt_clks
* @master_cnt: number of @master entries
* @slaves_cnt: number of @slave entries
* @response_lat: device OCP response latency (in interface clock cycles)
* @_int_flags: internal-use hwmod flags
* @_state: internal-use hwmod state
* @flags: hwmod flags (documented below)
* @omap_chip: OMAP chips this hwmod is present on
* @node: list node for hwmod list (internal use)
*
* @clkdev_dev_id, @clkdev_con_id, and @clk all refer to this module's "main
* clock," which for our purposes is defined as "the functional clock needed
* for register accesses to complete." Modules may not have a main clock if
* the interface clock also serves as a main clock.
*
* Parameter names beginning with an underscore are managed internally by
* the omap_hwmod code and should not be set during initialization.
*/
struct omap_hwmod {
const char *name;
struct omap_device *od;
struct omap_hwmod_irq_info *mpu_irqs;
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-03 17:14:03 +00:00
struct omap_hwmod_dma_info *sdma_chs;
union {
struct omap_hwmod_omap2_prcm omap2;
struct omap_hwmod_omap4_prcm omap4;
} prcm;
const char *clkdev_dev_id;
const char *clkdev_con_id;
struct clk *_clk;
struct omap_hwmod_opt_clk *opt_clks;
struct omap_hwmod_ocp_if **masters; /* connect to *_IA */
struct omap_hwmod_ocp_if **slaves; /* connect to *_TA */
struct omap_hwmod_sysconfig *sysconfig;
void *dev_attr;
u32 _sysc_cache;
void __iomem *_rt_va;
struct list_head node;
u16 flags;
u8 _mpu_port_index;
u8 msuspendmux_reg_id;
u8 msuspendmux_shift;
u8 response_lat;
u8 mpu_irqs_cnt;
u8 sdma_chs_cnt;
u8 opt_clks_cnt;
u8 masters_cnt;
u8 slaves_cnt;
u8 hwmods_cnt;
u8 _int_flags;
u8 _state;
const struct omap_chip_id omap_chip;
};
int omap_hwmod_init(struct omap_hwmod **ohs);
int omap_hwmod_register(struct omap_hwmod *oh);
int omap_hwmod_unregister(struct omap_hwmod *oh);
struct omap_hwmod *omap_hwmod_lookup(const char *name);
int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh));
int omap_hwmod_late_init(void);
int omap_hwmod_enable(struct omap_hwmod *oh);
int omap_hwmod_idle(struct omap_hwmod *oh);
int omap_hwmod_shutdown(struct omap_hwmod *oh);
int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
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-03 17:14:03 +00:00
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
void omap_hwmod_writel(u32 v, struct omap_hwmod *oh, u16 reg_offs);
u32 omap_hwmod_readl(struct omap_hwmod *oh, u16 reg_offs);
int omap_hwmod_count_resources(struct omap_hwmod *oh);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
struct powerdomain *omap_hwmod_get_pwrdm(struct omap_hwmod *oh);
int omap_hwmod_add_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh);
int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh);
int omap_hwmod_set_clockact_both(struct omap_hwmod *oh);
int omap_hwmod_set_clockact_main(struct omap_hwmod *oh);
int omap_hwmod_set_clockact_iclk(struct omap_hwmod *oh);
int omap_hwmod_set_clockact_none(struct omap_hwmod *oh);
int omap_hwmod_enable_wakeup(struct omap_hwmod *oh);
int omap_hwmod_disable_wakeup(struct omap_hwmod *oh);
#endif