mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-25 17:50:54 +07:00
c0718df4d6
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>
97 lines
3.3 KiB
C
97 lines
3.3 KiB
C
/*
|
|
* OMAP SoC specific OPP Data helpers
|
|
*
|
|
* Copyright (C) 2009-2010 Texas Instruments Incorporated - http://www.ti.com/
|
|
* Nishanth Menon
|
|
* Kevin Hilman
|
|
* Copyright (C) 2010 Nokia Corporation.
|
|
* Eduardo Valentin
|
|
*
|
|
* 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.
|
|
*
|
|
* This program is distributed "as is" WITHOUT ANY WARRANTY of any
|
|
* kind, whether express or implied; without even the implied warranty
|
|
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
* GNU General Public License for more details.
|
|
*/
|
|
#ifndef __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H
|
|
#define __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H
|
|
|
|
#include <plat/omap_hwmod.h>
|
|
|
|
#include "voltage.h"
|
|
|
|
/*
|
|
* *BIG FAT WARNING*:
|
|
* USE the following ONLY in opp data initialization common to an SoC.
|
|
* DO NOT USE these in board files/pm core etc.
|
|
*/
|
|
|
|
/**
|
|
* struct omap_opp_def - OMAP OPP Definition
|
|
* @hwmod_name: Name of the hwmod for this domain
|
|
* @freq: Frequency in hertz corresponding to this OPP
|
|
* @u_volt: Nominal voltage in microvolts corresponding to this OPP
|
|
* @default_available: True/false - is this OPP available by default
|
|
*
|
|
* OMAP SOCs have a standard set of tuples consisting of frequency and voltage
|
|
* pairs that the device will support per voltage domain. This is called
|
|
* Operating Points or OPP. The actual definitions of OMAP Operating Points
|
|
* varies over silicon within the same family of devices. For a specific
|
|
* domain, you can have a set of {frequency, voltage} pairs and this is denoted
|
|
* by an array of omap_opp_def. As the kernel boots and more information is
|
|
* available, a set of these are activated based on the precise nature of
|
|
* device the kernel boots up on. It is interesting to remember that each IP
|
|
* which belongs to a voltage domain may define their own set of OPPs on top
|
|
* of this - but this is handled by the appropriate driver.
|
|
*/
|
|
struct omap_opp_def {
|
|
char *hwmod_name;
|
|
|
|
unsigned long freq;
|
|
unsigned long u_volt;
|
|
|
|
bool default_available;
|
|
};
|
|
|
|
/*
|
|
* Initialization wrapper used to define an OPP for OMAP variants.
|
|
*/
|
|
#define OPP_INITIALIZER(_hwmod_name, _enabled, _freq, _uv) \
|
|
{ \
|
|
.hwmod_name = _hwmod_name, \
|
|
.default_available = _enabled, \
|
|
.freq = _freq, \
|
|
.u_volt = _uv, \
|
|
}
|
|
|
|
/*
|
|
* Initialization wrapper used to define SmartReflex process data
|
|
* XXX Is this needed? Just use C99 initializers in data files?
|
|
*/
|
|
#define VOLT_DATA_DEFINE(_v_nom, _efuse_offs, _errminlimit, _errgain) \
|
|
{ \
|
|
.volt_nominal = _v_nom, \
|
|
.sr_efuse_offs = _efuse_offs, \
|
|
.sr_errminlimit = _errminlimit, \
|
|
.vp_errgain = _errgain \
|
|
}
|
|
|
|
/* Use this to initialize the default table */
|
|
extern int __init omap_init_opp_table(struct omap_opp_def *opp_def,
|
|
u32 opp_def_size);
|
|
|
|
|
|
extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
|
|
extern struct omap_volt_data omap34xx_vddcore_volt_data[];
|
|
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
|
|
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
|
|
|
|
extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
|
|
extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
|
|
extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
|
|
|
|
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
|