iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ba112a4e86
linux/arch/arm/mach-omap2/vc.h

99 lines
3.1 KiB
C
Raw Normal View History

OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
/*
* OMAP3/4 Voltage Controller (VC) structure and macro definitions
*
* Copyright (C) 2007, 2010 Texas Instruments, Inc.
* Rajendra Nayak <rnayak@ti.com>
* Lesly A M <x0080970@ti.com>
* Thara Gopinath <thara@ti.com>
*
* Copyright (C) 2008, 2011 Nokia Corporation
* Kalle Jokiniemi
* 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.
*/
#ifndef __ARCH_ARM_MACH_OMAP2_VC_H
#define __ARCH_ARM_MACH_OMAP2_VC_H
#include <linux/kernel.h>
OMAP2+: voltage: split voltage controller (VC) code into dedicated layer As part of the voltage layer cleanup, split out VC specific code into a dedicated VC layer. This patch primarily just moves VC code from voltage.c into vc.c, and adds prototypes to vc.h. No functional changes. For readability, each function was given a local 'vc' pointer: struct omap_vc_instance_data *vc = voltdm->vdd->vc_data; and a global replace of s/vdd->vc_data/vc/ was done. Also vc_init was renamed to vc_init_channel to reflect that this is per-VC channel initializtion. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-22 00:08:55 +03:00
struct voltagedomain;
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
/**
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
* struct omap_vc_common - per-VC register/bitfield data
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
* @cmd_on_mask: ON bitmask in PRM_VC_CMD_VAL* register
* @valid: VALID bitmask in PRM_VC_BYPASS_VAL register
* @smps_sa_reg: Offset of PRM_VC_SMPS_SA reg from PRM start
* @smps_volra_reg: Offset of PRM_VC_SMPS_VOL_RA reg from PRM start
* @bypass_val_reg: Offset of PRM_VC_BYPASS_VAL reg from PRM start
* @data_shift: DATA field shift in PRM_VC_BYPASS_VAL register
* @slaveaddr_shift: SLAVEADDR field shift in PRM_VC_BYPASS_VAL register
* @regaddr_shift: REGADDR field shift in PRM_VC_BYPASS_VAL register
* @cmd_on_shift: ON field shift in PRM_VC_CMD_VAL_* register
* @cmd_onlp_shift: ONLP field shift in PRM_VC_CMD_VAL_* register
* @cmd_ret_shift: RET field shift in PRM_VC_CMD_VAL_* register
* @cmd_off_shift: OFF field shift in PRM_VC_CMD_VAL_* register
*
* XXX One of cmd_on_mask and cmd_on_shift are not needed
* XXX VALID should probably be a shift, not a mask
*/
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
struct omap_vc_common {
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
u32 cmd_on_mask;
u32 valid;
u8 smps_sa_reg;
u8 smps_volra_reg;
u8 bypass_val_reg;
u8 data_shift;
u8 slaveaddr_shift;
u8 regaddr_shift;
u8 cmd_on_shift;
u8 cmd_onlp_shift;
u8 cmd_ret_shift;
u8 cmd_off_shift;
};
/**
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
* struct omap_vc_channel - VC per-instance data
OMAP3+: VC: cleanup i2c slave address configuration - Add an i2c_slave_address field to the omap_vc_channel - use VC/VP read/modify/write helper instead of open-coding - remove smps_sa_shift, use __ffs(mask) for shift value - I2C addresses 10-bit, change size to u16 Special thanks to Shweta Gulati <shweta.gulati@ti.com> for suggesting the use of __ffs(x) instead of ffs(x) - 1. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-30 01:02:36 +04:00
* @i2c_slave_addr: I2C slave address of PMIC for this VC channel
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
* @common: pointer to VC common data for this platform
OMAP3+: VC: cleanup i2c slave address configuration - Add an i2c_slave_address field to the omap_vc_channel - use VC/VP read/modify/write helper instead of open-coding - remove smps_sa_shift, use __ffs(mask) for shift value - I2C addresses 10-bit, change size to u16 Special thanks to Shweta Gulati <shweta.gulati@ti.com> for suggesting the use of __ffs(x) instead of ffs(x) - 1. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-30 01:02:36 +04:00
* @smps_sa_mask: i2c slave address bitmask in the PRM_VC_SMPS_SA register
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
* @smps_volra_mask: VOLRA* bitmask in the PRM_VC_VOL_RA register
* @smps_volra_shift: VOLRA* field shift in the PRM_VC_VOL_RA register
*
* XXX It is not necessary to have both a *_mask and a *_shift -
* remove one
*/
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
struct omap_vc_channel {
OMAP3+: VC: cleanup i2c slave address configuration - Add an i2c_slave_address field to the omap_vc_channel - use VC/VP read/modify/write helper instead of open-coding - remove smps_sa_shift, use __ffs(mask) for shift value - I2C addresses 10-bit, change size to u16 Special thanks to Shweta Gulati <shweta.gulati@ti.com> for suggesting the use of __ffs(x) instead of ffs(x) - 1. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-30 01:02:36 +04:00
/* channel state */
u16 i2c_slave_addr;
/* register access data */
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
const struct omap_vc_common *common;
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
u32 smps_sa_mask;
u32 smps_volra_mask;
u8 cmdval_reg;
u8 smps_volra_shift;
};
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
extern struct omap_vc_channel omap3_vc_mpu;
extern struct omap_vc_channel omap3_vc_core;
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
extern struct omap_vc_channel omap4_vc_mpu;
extern struct omap_vc_channel omap4_vc_iva;
extern struct omap_vc_channel omap4_vc_core;
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
OMAP2+: voltage: split voltage controller (VC) code into dedicated layer As part of the voltage layer cleanup, split out VC specific code into a dedicated VC layer. This patch primarily just moves VC code from voltage.c into vc.c, and adds prototypes to vc.h. No functional changes. For readability, each function was given a local 'vc' pointer: struct omap_vc_instance_data *vc = voltdm->vdd->vc_data; and a global replace of s/vdd->vc_data/vc/ was done. Also vc_init was renamed to vc_init_channel to reflect that this is per-VC channel initializtion. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-22 00:08:55 +03:00
void omap_vc_init_channel(struct voltagedomain *voltdm);
int omap_vc_pre_scale(struct voltagedomain *voltdm,
unsigned long target_volt,
u8 *target_vsel, u8 *current_vsel);
void omap_vc_post_scale(struct voltagedomain *voltdm,
unsigned long target_volt,
u8 target_vsel, u8 current_vsel);
OMAP2+: voltage: move VC into struct voltagedomain, misc. renames Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-03-23 02:14:57 +03:00
int omap_vc_bypass_scale(struct voltagedomain *voltdm,
unsigned long target_volt);
OMAP2+: voltage: split voltage controller (VC) code into dedicated layer As part of the voltage layer cleanup, split out VC specific code into a dedicated VC layer. This patch primarily just moves VC code from voltage.c into vc.c, and adds prototypes to vc.h. No functional changes. For readability, each function was given a local 'vc' pointer: struct omap_vc_instance_data *vc = voltdm->vdd->vc_data; and a global replace of s/vdd->vc_data/vc/ was done. Also vc_init was renamed to vc_init_channel to reflect that this is per-VC channel initializtion. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-22 00:08:55 +03:00
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 08:17:45 +03:00
#endif
Reference in New Issue Copy Permalink