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
|
|
|
/*
|
|
|
|
|
* OMAP4 PRCM_MPU module functions
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2009 Nokia Corporation
|
|
|
|
|
* Paul Walmsley
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <linux/errno.h>
|
|
|
|
|
#include <linux/err.h>
|
|
|
|
|
#include <linux/io.h>
|
|
|
|
|
|
2012-02-25 02:34:35 +08:00
|
|
|
#include "iomap.h"
|
2011-11-11 05:45:17 +08:00
|
|
|
#include "common.h"
|
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
|
|
|
#include "prcm_mpu44xx.h"
|
|
|
|
|
#include "cm-regbits-44xx.h"
|
|
|
|
|
|
2012-10-30 10:57:39 +08:00
|
|
|
/*
|
|
|
|
|
* prcm_mpu_base: the virtual address of the start of the PRCM_MPU IP
|
|
|
|
|
* block registers
|
|
|
|
|
*/
|
|
|
|
|
void __iomem *prcm_mpu_base;
|
|
|
|
|
|
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
|
|
|
/* PRCM_MPU low-level functions */
|
|
|
|
|
|
|
|
|
|
u32 omap4_prcm_mpu_read_inst_reg(s16 inst, u16 reg)
|
|
|
|
|
{
|
|
|
|
|
return __raw_readl(OMAP44XX_PRCM_MPU_REGADDR(inst, reg));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void omap4_prcm_mpu_write_inst_reg(u32 val, s16 inst, u16 reg)
|
|
|
|
|
{
|
|
|
|
|
__raw_writel(val, OMAP44XX_PRCM_MPU_REGADDR(inst, reg));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
u32 omap4_prcm_mpu_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 reg)
|
|
|
|
|
{
|
|
|
|
|
u32 v;
|
|
|
|
|
|
|
|
|
|
v = omap4_prcm_mpu_read_inst_reg(inst, reg);
|
|
|
|
|
v &= ~mask;
|
|
|
|
|
v |= bits;
|
|
|
|
|
omap4_prcm_mpu_write_inst_reg(v, inst, reg);
|
|
|
|
|
|
|
|
|
|
return v;
|
|
|
|
|
}
|
2012-10-30 10:57:39 +08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* omap2_set_globals_prcm_mpu - set the MPU PRCM base address (for early use)
|
|
|
|
|
* @prcm_mpu: PRCM_MPU base virtual address
|
|
|
|
|
*
|
|
|
|
|
* XXX Will be replaced when the PRM/CM drivers are completed.
|
|
|
|
|
*/
|
|
|
|
|
void __init omap2_set_globals_prcm_mpu(void __iomem *prcm_mpu)
|
|
|
|
|
{
|
|
|
|
|
prcm_mpu_base = prcm_mpu;
|
|
|
|
|
}
|
