2010-12-22 06:30:54 +08:00
|
|
|
/*
|
|
|
|
|
* OMAP44xx PRCM MPU instance offset macros
|
|
|
|
|
*
|
2012-10-30 10:57:39 +08:00
|
|
|
* Copyright (C) 2010, 2012 Texas Instruments, Inc.
|
2010-12-22 06:30:54 +08:00
|
|
|
* Copyright (C) 2010 Nokia Corporation
|
|
|
|
|
*
|
|
|
|
|
* Paul Walmsley (paul@pwsan.com)
|
|
|
|
|
* Rajendra Nayak (rnayak@ti.com)
|
|
|
|
|
* Benoit Cousson (b-cousson@ti.com)
|
|
|
|
|
*
|
|
|
|
|
* This file is automatically generated from the OMAP hardware databases.
|
|
|
|
|
* We respectfully ask that any modifications to this file be coordinated
|
|
|
|
|
* with the public linux-omap@vger.kernel.org mailing list and the
|
|
|
|
|
* authors above to ensure that the autogeneration scripts are kept
|
|
|
|
|
* up-to-date with the file contents.
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* XXX This file needs to be updated to align on one of "OMAP4", "OMAP44XX",
|
|
|
|
|
* or "OMAP4430".
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_MPU44XX_H
|
|
|
|
|
#define __ARCH_ARM_MACH_OMAP2_PRCM_MPU44XX_H
|
|
|
|
|
|
2012-10-30 10:57:39 +08:00
|
|
|
#include "common.h"
|
|
|
|
|
|
|
|
|
|
# ifndef __ASSEMBLER__
|
|
|
|
|
extern void __iomem *prcm_mpu_base;
|
|
|
|
|
# endif
|
|
|
|
|
|
2010-12-22 06:30:54 +08:00
|
|
|
#define OMAP4430_PRCM_MPU_BASE 0x48243000
|
|
|
|
|
|
OMAP4: PRCM: rename _MOD macros to _INST
Back in the OMAP2/3 PRCM interface days, the macros that referred to
the offsets of individual PRM/CM instances from the top of the PRM/CM
hardware modules were incorrectly suffixed with "_MOD". (They should
have been suffixed with something like "_INST" or "_INSTANCE".) These
days, now that we have better contact with the OMAP hardware people,
we know that this naming is wrong. And in fact in OMAP4, there are
actual hardware module offsets inside the instances, so the incorrect
naming gets confusing very quickly for anyone who knows the hardware.
Fix this naming for OMAP4, before things get too far along, by
changing "_MOD" to "_INST" on the end of these macros. So, for
example, OMAP4430_CM2_INSTR_MOD becomes OMAP4430_CM2_INSTR_INST.
This unfortunately creates quite a large diff, but it is a
straightforward rename. This patch should not result in any
functional changes.
The autogeneration scripts have been updated accordingly.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-22 06:30:55 +08:00
|
|
|
#define OMAP44XX_PRCM_MPU_REGADDR(inst, reg) \
|
|
|
|
|
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE + (inst) + (reg))
|
2010-12-22 06:30:54 +08:00
|
|
|
|
|
|
|
|
/* PRCM_MPU instances */
|
OMAP4: PRCM: rename _MOD macros to _INST
Back in the OMAP2/3 PRCM interface days, the macros that referred to
the offsets of individual PRM/CM instances from the top of the PRM/CM
hardware modules were incorrectly suffixed with "_MOD". (They should
have been suffixed with something like "_INST" or "_INSTANCE".) These
days, now that we have better contact with the OMAP hardware people,
we know that this naming is wrong. And in fact in OMAP4, there are
actual hardware module offsets inside the instances, so the incorrect
naming gets confusing very quickly for anyone who knows the hardware.
Fix this naming for OMAP4, before things get too far along, by
changing "_MOD" to "_INST" on the end of these macros. So, for
example, OMAP4430_CM2_INSTR_MOD becomes OMAP4430_CM2_INSTR_INST.
This unfortunately creates quite a large diff, but it is a
straightforward rename. This patch should not result in any
functional changes.
The autogeneration scripts have been updated accordingly.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-22 06:30:55 +08:00
|
|
|
#define OMAP4430_PRCM_MPU_OCP_SOCKET_PRCM_INST 0x0000
|
|
|
|
|
#define OMAP4430_PRCM_MPU_DEVICE_PRM_INST 0x0200
|
|
|
|
|
#define OMAP4430_PRCM_MPU_CPU0_INST 0x0400
|
|
|
|
|
#define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
|
2010-12-22 06:30:54 +08:00
|
|
|
|
2010-12-22 12:05:15 +08:00
|
|
|
/* PRCM_MPU clockdomain register offsets (from instance start) */
|
2011-02-09 05:30:31 +08:00
|
|
|
#define OMAP4430_PRCM_MPU_CPU0_CPU0_CDOFFS 0x0018
|
|
|
|
|
#define OMAP4430_PRCM_MPU_CPU1_CPU1_CDOFFS 0x0018
|
2010-12-22 12:05:15 +08:00
|
|
|
|
|
|
|
|
|
2010-12-22 06:30:54 +08:00
|
|
|
/*
|
|
|
|
|
* PRCM_MPU
|
|
|
|
|
*
|
|
|
|
|
* The PRCM_MPU is a local PRCM inside the MPU subsystem. For the PRCM (global)
|
|
|
|
|
* point of view the PRCM_MPU is a single entity. It shares the same
|
|
|
|
|
* programming model as the global PRCM and thus can be assimilate as two new
|
|
|
|
|
* MOD inside the PRCM
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* PRCM_MPU.OCP_SOCKET_PRCM register offsets */
|
2011-07-10 09:15:06 +08:00
|
|
|
#define OMAP4_REVISION_PRCM_OFFSET 0x0000
|
|
|
|
|
#define OMAP4430_REVISION_PRCM OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_OCP_SOCKET_PRCM_INST, 0x0000)
|
2010-12-22 06:30:54 +08:00
|
|
|
|
|
|
|
|
/* PRCM_MPU.DEVICE_PRM register offsets */
|
2011-07-10 09:15:06 +08:00
|
|
|
#define OMAP4_PRCM_MPU_PRM_RSTST_OFFSET 0x0000
|
|
|
|
|
#define OMAP4430_PRCM_MPU_PRM_RSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_DEVICE_PRM_INST, 0x0000)
|
|
|
|
|
#define OMAP4_PRCM_MPU_PRM_PSCON_COUNT_OFFSET 0x0004
|
|
|
|
|
#define OMAP4430_PRCM_MPU_PRM_PSCON_COUNT OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_DEVICE_PRM_INST, 0x0004)
|
2010-12-22 06:30:54 +08:00
|
|
|
|
|
|
|
|
/* PRCM_MPU.CPU0 register offsets */
|
2011-07-10 09:15:06 +08:00
|
|
|
#define OMAP4_PM_CPU0_PWRSTCTRL_OFFSET 0x0000
|
|
|
|
|
#define OMAP4430_PM_CPU0_PWRSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0000)
|
|
|
|
|
#define OMAP4_PM_CPU0_PWRSTST_OFFSET 0x0004
|
|
|
|
|
#define OMAP4430_PM_CPU0_PWRSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0004)
|
|
|
|
|
#define OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET 0x0008
|
|
|
|
|
#define OMAP4430_RM_CPU0_CPU0_CONTEXT OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0008)
|
|
|
|
|
#define OMAP4_RM_CPU0_CPU0_RSTCTRL_OFFSET 0x000c
|
|
|
|
|
#define OMAP4430_RM_CPU0_CPU0_RSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x000c)
|
|
|
|
|
#define OMAP4_RM_CPU0_CPU0_RSTST_OFFSET 0x0010
|
|
|
|
|
#define OMAP4430_RM_CPU0_CPU0_RSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0010)
|
|
|
|
|
#define OMAP4_CM_CPU0_CPU0_CLKCTRL_OFFSET 0x0014
|
|
|
|
|
#define OMAP4430_CM_CPU0_CPU0_CLKCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0014)
|
|
|
|
|
#define OMAP4_CM_CPU0_CLKSTCTRL_OFFSET 0x0018
|
|
|
|
|
#define OMAP4430_CM_CPU0_CLKSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0018)
|
2010-12-22 06:30:54 +08:00
|
|
|
|
|
|
|
|
/* PRCM_MPU.CPU1 register offsets */
|
2011-07-10 09:15:06 +08:00
|
|
|
#define OMAP4_PM_CPU1_PWRSTCTRL_OFFSET 0x0000
|
|
|
|
|
#define OMAP4430_PM_CPU1_PWRSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0000)
|
|
|
|
|
#define OMAP4_PM_CPU1_PWRSTST_OFFSET 0x0004
|
|
|
|
|
#define OMAP4430_PM_CPU1_PWRSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0004)
|
|
|
|
|
#define OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET 0x0008
|
|
|
|
|
#define OMAP4430_RM_CPU1_CPU1_CONTEXT OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0008)
|
|
|
|
|
#define OMAP4_RM_CPU1_CPU1_RSTCTRL_OFFSET 0x000c
|
|
|
|
|
#define OMAP4430_RM_CPU1_CPU1_RSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x000c)
|
|
|
|
|
#define OMAP4_RM_CPU1_CPU1_RSTST_OFFSET 0x0010
|
|
|
|
|
#define OMAP4430_RM_CPU1_CPU1_RSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0010)
|
|
|
|
|
#define OMAP4_CM_CPU1_CPU1_CLKCTRL_OFFSET 0x0014
|
|
|
|
|
#define OMAP4430_CM_CPU1_CPU1_CLKCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0014)
|
|
|
|
|
#define OMAP4_CM_CPU1_CLKSTCTRL_OFFSET 0x0018
|
|
|
|
|
#define OMAP4430_CM_CPU1_CLKSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0018)
|
2010-12-22 06:30:54 +08:00
|
|
|
|
OMAP4: PRCM: add OMAP4-specific accessor/mutator functions
In some ways, the OMAP4 PRCM register layout is quite different than
the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a
register layout point of view, all CM instances were located in the CM
subsystem, and all PRM instances were located in the PRM subsystem.
OMAP4 changes this. Now, for example, some CM instances, such as
WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a
"local PRCM" exists for the MPU - this PRCM combines registers that
would normally appear in both CM and PRM instances, but uses its own
register layout which matches neither the OMAP2/3 PRCM layout nor the
OMAP4 PRCM layout.
To try to deal with this, introduce some new functions, omap4_cminst*
and omap4_prminst*. The former is to be used when writing to a CM
instance register (no matter what subsystem or hardware module it
exists in), and the latter, similarly, with PRM instance registers.
To determine which "PRCM partition" to write to, the functions take a
PRCM instance ID argument. Subsequent patches add these partition IDs
to the OMAP4 powerdomain and clockdomain definitions.
As far as I can see, there's really no good way to handle these types
of register access inconsistencies. This patch seemed like the least
bad approach.
Moving forward, the long-term goal is to remove all direct PRCM
register access from the PM code. PRCM register access should go
through layers such as the powerdomain and clockdomain code that can
hide the details of how to interact with the specific hardware
variant.
While here, rename cm4xxx.c to cm44xx.c to match the naming convention
of the other OMAP4 PRCM files.
Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
<rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-22 12:05:14 +08:00
|
|
|
/* Function prototypes */
|
|
|
|
|
# ifndef __ASSEMBLER__
|
|
|
|
|
extern u32 omap4_prcm_mpu_read_inst_reg(s16 inst, u16 idx);
|
|
|
|
|
extern void omap4_prcm_mpu_write_inst_reg(u32 val, s16 inst, u16 idx);
|
|
|
|
|
extern u32 omap4_prcm_mpu_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst,
|
|
|
|
|
s16 idx);
|
2012-10-30 10:57:39 +08:00
|
|
|
extern void __init omap2_set_globals_prcm_mpu(void __iomem *prcm_mpu);
|
OMAP4: PRCM: add OMAP4-specific accessor/mutator functions
In some ways, the OMAP4 PRCM register layout is quite different than
the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a
register layout point of view, all CM instances were located in the CM
subsystem, and all PRM instances were located in the PRM subsystem.
OMAP4 changes this. Now, for example, some CM instances, such as
WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a
"local PRCM" exists for the MPU - this PRCM combines registers that
would normally appear in both CM and PRM instances, but uses its own
register layout which matches neither the OMAP2/3 PRCM layout nor the
OMAP4 PRCM layout.
To try to deal with this, introduce some new functions, omap4_cminst*
and omap4_prminst*. The former is to be used when writing to a CM
instance register (no matter what subsystem or hardware module it
exists in), and the latter, similarly, with PRM instance registers.
To determine which "PRCM partition" to write to, the functions take a
PRCM instance ID argument. Subsequent patches add these partition IDs
to the OMAP4 powerdomain and clockdomain definitions.
As far as I can see, there's really no good way to handle these types
of register access inconsistencies. This patch seemed like the least
bad approach.
Moving forward, the long-term goal is to remove all direct PRCM
register access from the PM code. PRCM register access should go
through layers such as the powerdomain and clockdomain code that can
hide the details of how to interact with the specific hardware
variant.
While here, rename cm4xxx.c to cm44xx.c to match the naming convention
of the other OMAP4 PRCM files.
Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
<rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-22 12:05:14 +08:00
|
|
|
# endif
|
|
|
|
|
|
2010-12-22 06:30:54 +08:00
|
|
|
#endif
|