* [PATCHv2 1/5] OMAP: move voltage.h and vp.h under platform include directory
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
@ 2011-07-13 14:00 ` Tero Kristo
2011-07-13 14:00 ` [PATCHv2 2/5] regulator: omap smps regulator driver Tero Kristo
` (6 subsequent siblings)
7 siblings, 0 replies; 21+ messages in thread
From: Tero Kristo @ 2011-07-13 14:00 UTC (permalink / raw)
To: linux-omap; +Cc: broonie, lrg, khilman
This is needed so that these include files can be accessed from drivers.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/omap_opp_data.h | 3 +-
arch/arm/mach-omap2/omap_twl.c | 2 +-
arch/arm/mach-omap2/pm.c | 2 +-
arch/arm/mach-omap2/smartreflex.h | 2 +-
arch/arm/mach-omap2/sr_device.c | 2 +-
arch/arm/mach-omap2/vc3xxx_data.c | 2 +-
arch/arm/mach-omap2/vc44xx_data.c | 2 +-
arch/arm/mach-omap2/voltage.c | 4 +-
arch/arm/mach-omap2/voltage.h | 184 -------------------------
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 3 +-
arch/arm/mach-omap2/voltagedomains44xx_data.c | 3 +-
arch/arm/mach-omap2/vp.h | 143 -------------------
arch/arm/mach-omap2/vp3xxx_data.c | 4 +-
arch/arm/mach-omap2/vp44xx_data.c | 4 +-
arch/arm/plat-omap/include/plat/voltage.h | 183 ++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/vp.h | 143 +++++++++++++++++++
16 files changed, 338 insertions(+), 348 deletions(-)
delete mode 100644 arch/arm/mach-omap2/voltage.h
delete mode 100644 arch/arm/mach-omap2/vp.h
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
create mode 100644 arch/arm/plat-omap/include/plat/vp.h
diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..4d93209 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -20,8 +20,7 @@
#define __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H
#include <plat/omap_hwmod.h>
-
-#include "voltage.h"
+#include <plat/voltage.h>
/*
* *BIG FAT WARNING*:
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 07d6140..ffe7e5c 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -18,7 +18,7 @@
#include <linux/kernel.h>
#include <linux/i2c/twl.h>
-#include "voltage.h"
+#include <plat/voltage.h>
#include "pm.h"
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index ce1a9f3..26ff6fa 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -18,8 +18,8 @@
#include <plat/omap-pm.h>
#include <plat/omap_device.h>
#include <plat/common.h>
+#include <plat/voltage.h>
-#include "voltage.h"
#include "powerdomain.h"
#include "clockdomain.h"
#include "pm.h"
diff --git a/arch/arm/mach-omap2/smartreflex.h b/arch/arm/mach-omap2/smartreflex.h
index 5f35b9e..fe9b242 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -22,7 +22,7 @@
#include <linux/platform_device.h>
-#include "voltage.h"
+#include <plat/voltage.h>
/*
* Different Smartreflex IPs version. The v1 is the 65nm version used in
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 10d3c5e..a636604 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -23,9 +23,9 @@
#include <linux/io.h>
#include <plat/omap_device.h>
+#include <plat/voltage.h>
#include "smartreflex.h"
-#include "voltage.h"
#include "control.h"
#include "pm.h"
diff --git a/arch/arm/mach-omap2/vc3xxx_data.c b/arch/arm/mach-omap2/vc3xxx_data.c
index f37dc4b..7df566c 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -19,9 +19,9 @@
#include <linux/init.h>
#include <plat/common.h>
+#include <plat/voltage.h>
#include "prm-regbits-34xx.h"
-#include "voltage.h"
#include "vc.h"
diff --git a/arch/arm/mach-omap2/vc44xx_data.c b/arch/arm/mach-omap2/vc44xx_data.c
index a98da8d..7a69821 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -19,10 +19,10 @@
#include <linux/init.h>
#include <plat/common.h>
+#include <plat/voltage.h>
#include "prm44xx.h"
#include "prm-regbits-44xx.h"
-#include "voltage.h"
#include "vc.h"
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 9ef3789..7e3c512 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -27,6 +27,7 @@
#include <linux/slab.h>
#include <plat/common.h>
+#include <plat/voltage.h>
#include "prm-regbits-34xx.h"
#include "prm-regbits-44xx.h"
@@ -35,10 +36,7 @@
#include "prminst44xx.h"
#include "control.h"
-#include "voltage.h"
-
#include "vc.h"
-#include "vp.h"
#define VOLTAGE_DIR_SIZE 16
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
deleted file mode 100644
index e9f5408..0000000
--- a/arch/arm/mach-omap2/voltage.h
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * OMAP Voltage Management Routines
- *
- * Author: Thara Gopinath <thara@ti.com>
- *
- * Copyright (C) 2009 Texas Instruments, Inc.
- * Thara Gopinath <thara@ti.com>
- *
- * 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_VOLTAGE_H
-#define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
-
-#include <linux/err.h>
-
-#include "vc.h"
-#include "vp.h"
-
-/* XXX document */
-#define VOLTSCALE_VPFORCEUPDATE 1
-#define VOLTSCALE_VCBYPASS 2
-
-/*
- * OMAP3 GENERIC setup times. Revisit to see if these needs to be
- * passed from board or PMIC file
- */
-#define OMAP3_CLKSETUP 0xff
-#define OMAP3_VOLTOFFSET 0xff
-#define OMAP3_VOLTSETUP2 0xff
-
-/**
- * struct omap_vfsm_instance_data - per-voltage manager FSM register/bitfield
- * data
- * @voltsetup_mask: SETUP_TIME* bitmask in the PRM_VOLTSETUP* register
- * @voltsetup_reg: register offset of PRM_VOLTSETUP from PRM base
- * @voltsetup_shift: SETUP_TIME* field shift in the PRM_VOLTSETUP* register
- *
- * XXX What about VOLTOFFSET/VOLTCTRL?
- * XXX It is not necessary to have both a _mask and a _shift for the same
- * bitfield - remove one!
- */
-struct omap_vfsm_instance_data {
- u32 voltsetup_mask;
- u8 voltsetup_reg;
- u8 voltsetup_shift;
-};
-
-/**
- * struct voltagedomain - omap voltage domain global structure.
- * @name: Name of the voltage domain which can be used as a unique
- * identifier.
- */
-struct voltagedomain {
- char *name;
-};
-
-/**
- * struct omap_volt_data - Omap voltage specific data.
- * @voltage_nominal: The possible voltage value in uV
- * @sr_efuse_offs: The offset of the efuse register(from system
- * control module base address) from where to read
- * the n-target value for the smartreflex module.
- * @sr_errminlimit: Error min limit value for smartreflex. This value
- * differs at differnet opp and thus is linked
- * with voltage.
- * @vp_errorgain: Error gain value for the voltage processor. This
- * field also differs according to the voltage/opp.
- */
-struct omap_volt_data {
- u32 volt_nominal;
- u32 sr_efuse_offs;
- u8 sr_errminlimit;
- u8 vp_errgain;
-};
-
-/**
- * struct omap_volt_pmic_info - PMIC specific data required by voltage driver.
- * @slew_rate: PMIC slew rate (in uv/us)
- * @step_size: PMIC voltage step size (in uv)
- * @vsel_to_uv: PMIC API to convert vsel value to actual voltage in uV.
- * @uv_to_vsel: PMIC API to convert voltage in uV to vsel value.
- */
-struct omap_volt_pmic_info {
- int slew_rate;
- int step_size;
- u32 on_volt;
- u32 onlp_volt;
- u32 ret_volt;
- u32 off_volt;
- u16 volt_setup_time;
- u8 vp_erroroffset;
- u8 vp_vstepmin;
- u8 vp_vstepmax;
- u8 vp_vddmin;
- u8 vp_vddmax;
- u8 vp_timeout_us;
- u8 i2c_slave_addr;
- u8 pmic_reg;
- unsigned long (*vsel_to_uv) (const u8 vsel);
- u8 (*uv_to_vsel) (unsigned long uV);
-};
-
-/**
- * omap_vdd_info - Per Voltage Domain info
- *
- * @volt_data : voltage table having the distinct voltages supported
- * by the domain and other associated per voltage data.
- * @pmic_info : pmic specific parameters which should be populted by
- * the pmic drivers.
- * @vp_data : the register values, shifts, masks for various
- * vp registers
- * @vp_rt_data : VP data derived at runtime, not predefined
- * @vc_data : structure containing various various vc registers,
- * shifts, masks etc.
- * @vfsm : voltage manager FSM data
- * @voltdm : pointer to the voltage domain structure
- * @debug_dir : debug directory for this voltage domain.
- * @curr_volt : current voltage for this vdd.
- * @vp_enabled : flag to keep track of whether vp is enabled or not
- * @volt_scale : API to scale the voltage of the vdd.
- */
-struct omap_vdd_info {
- struct omap_volt_data *volt_data;
- struct omap_volt_pmic_info *pmic_info;
- struct omap_vp_instance_data *vp_data;
- struct omap_vp_runtime_data vp_rt_data;
- struct omap_vc_instance_data *vc_data;
- const struct omap_vfsm_instance_data *vfsm;
- struct voltagedomain voltdm;
- struct dentry *debug_dir;
- u32 curr_volt;
- bool vp_enabled;
- u32 (*read_reg) (u16 mod, u8 offset);
- void (*write_reg) (u32 val, u16 mod, u8 offset);
- int (*volt_scale) (struct omap_vdd_info *vdd,
- unsigned long target_volt);
-};
-
-unsigned long omap_vp_get_curr_volt(struct voltagedomain *voltdm);
-void omap_vp_enable(struct voltagedomain *voltdm);
-void omap_vp_disable(struct voltagedomain *voltdm);
-int omap_voltage_scale_vdd(struct voltagedomain *voltdm,
- unsigned long target_volt);
-void omap_voltage_reset(struct voltagedomain *voltdm);
-void omap_voltage_get_volttable(struct voltagedomain *voltdm,
- struct omap_volt_data **volt_data);
-struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm,
- unsigned long volt);
-unsigned long omap_voltage_get_nom_volt(struct voltagedomain *voltdm);
-struct dentry *omap_voltage_get_dbgdir(struct voltagedomain *voltdm);
-int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_mod,
- struct omap_vdd_info *omap_vdd_array[],
- u8 omap_vdd_count);
-#ifdef CONFIG_PM
-int omap_voltage_register_pmic(struct voltagedomain *voltdm,
- struct omap_volt_pmic_info *pmic_info);
-void omap_change_voltscale_method(struct voltagedomain *voltdm,
- int voltscale_method);
-/* API to get the voltagedomain pointer */
-struct voltagedomain *omap_voltage_domain_lookup(char *name);
-
-int omap_voltage_late_init(void);
-#else
-static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
- struct omap_volt_pmic_info *pmic_info)
-{
- return -EINVAL;
-}
-static inline void omap_change_voltscale_method(struct voltagedomain *voltdm,
- int voltscale_method) {}
-static inline int omap_voltage_late_init(void)
-{
- return -EINVAL;
-}
-static inline struct voltagedomain *omap_voltage_domain_lookup(char *name)
-{
- return ERR_PTR(-EINVAL);
-}
-#endif
-
-#endif
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index def230f..2e17350 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -20,12 +20,11 @@
#include <plat/common.h>
#include <plat/cpu.h>
+#include <plat/voltage.h>
#include "prm-regbits-34xx.h"
#include "omap_opp_data.h"
-#include "voltage.h"
#include "vc.h"
-#include "vp.h"
/*
* VDD data
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index cb64996..be61419 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -22,15 +22,14 @@
#include <linux/init.h>
#include <plat/common.h>
+#include <plat/voltage.h>
#include "prm-regbits-44xx.h"
#include "prm44xx.h"
#include "prcm44xx.h"
#include "prminst44xx.h"
-#include "voltage.h"
#include "omap_opp_data.h"
#include "vc.h"
-#include "vp.h"
static const struct omap_vfsm_instance_data omap4_vdd_mpu_vfsm_data = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET,
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
deleted file mode 100644
index 7ce134f..0000000
--- a/arch/arm/mach-omap2/vp.h
+++ /dev/null
@@ -1,143 +0,0 @@
-/*
- * OMAP3/4 Voltage Processor (VP) 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_VP_H
-#define __ARCH_ARM_MACH_OMAP2_VP_H
-
-#include <linux/kernel.h>
-
-/* XXX document */
-#define VP_IDLE_TIMEOUT 200
-#define VP_TRANXDONE_TIMEOUT 300
-
-
-/**
- * struct omap_vp_common_data - register data common to all VDDs
- * @vpconfig_errorgain_mask: ERRORGAIN bitmask in the PRM_VP*_CONFIG reg
- * @vpconfig_initvoltage_mask: INITVOLTAGE bitmask in the PRM_VP*_CONFIG reg
- * @vpconfig_timeouten_mask: TIMEOUT bitmask in the PRM_VP*_CONFIG reg
- * @vpconfig_initvdd: INITVDD bitmask in the PRM_VP*_CONFIG reg
- * @vpconfig_forceupdate: FORCEUPDATE bitmask in the PRM_VP*_CONFIG reg
- * @vpconfig_vpenable: VPENABLE bitmask in the PRM_VP*_CONFIG reg
- * @vpconfig_erroroffset_shift: ERROROFFSET field shift in PRM_VP*_CONFIG reg
- * @vpconfig_errorgain_shift: ERRORGAIN field shift in PRM_VP*_CONFIG reg
- * @vpconfig_initvoltage_shift: INITVOLTAGE field shift in PRM_VP*_CONFIG reg
- * @vpconfig_stepmin_shift: VSTEPMIN field shift in the PRM_VP*_VSTEPMIN reg
- * @vpconfig_smpswaittimemin_shift: SMPSWAITTIMEMIN field shift in PRM_VP*_VSTEPMIN reg
- * @vpconfig_stepmax_shift: VSTEPMAX field shift in the PRM_VP*_VSTEPMAX reg
- * @vpconfig_smpswaittimemax_shift: SMPSWAITTIMEMAX field shift in PRM_VP*_VSTEPMAX reg
- * @vpconfig_vlimitto_vddmin_shift: VDDMIN field shift in PRM_VP*_VLIMITTO reg
- * @vpconfig_vlimitto_vddmax_shift: VDDMAX field shift in PRM_VP*_VLIMITTO reg
- * @vpconfig_vlimitto_timeout_shift: TIMEOUT field shift in PRM_VP*_VLIMITTO reg
- *
- * XXX It it not necessary to have both a mask and a shift for the same
- * bitfield - remove one
- * XXX Many of these fields are wrongly named -- e.g., vpconfig_smps* -- fix!
- */
-struct omap_vp_common_data {
- u32 vpconfig_errorgain_mask;
- u32 vpconfig_initvoltage_mask;
- u32 vpconfig_timeouten;
- u32 vpconfig_initvdd;
- u32 vpconfig_forceupdate;
- u32 vpconfig_vpenable;
- u8 vpconfig_erroroffset_shift;
- u8 vpconfig_errorgain_shift;
- u8 vpconfig_initvoltage_shift;
- u8 vstepmin_stepmin_shift;
- u8 vstepmin_smpswaittimemin_shift;
- u8 vstepmax_stepmax_shift;
- u8 vstepmax_smpswaittimemax_shift;
- u8 vlimitto_vddmin_shift;
- u8 vlimitto_vddmax_shift;
- u8 vlimitto_timeout_shift;
-};
-
-/**
- * struct omap_vp_prm_irqst_data - PRM_IRQSTATUS_MPU.VP_TRANXDONE_ST data
- * @prm_irqst_reg: reg offset for PRM_IRQSTATUS_MPU from top of PRM
- * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
- *
- * XXX prm_irqst_reg does not belong here
- * XXX Note that on OMAP3, VP_TRANXDONE interrupt may not work due to a
- * hardware bug
- * XXX This structure is probably not needed
- */
-struct omap_vp_prm_irqst_data {
- u8 prm_irqst_reg;
- u32 tranxdone_status;
-};
-
-/**
- * struct omap_vp_instance_data - VP register offsets (per-VDD)
- * @vp_common: pointer to struct omap_vp_common_data * for this SoC
- * @prm_irqst_data: pointer to struct omap_vp_prm_irqst_data for this VDD
- * @vpconfig: PRM_VP*_CONFIG reg offset from PRM start
- * @vstepmin: PRM_VP*_VSTEPMIN reg offset from PRM start
- * @vlimitto: PRM_VP*_VLIMITTO reg offset from PRM start
- * @vstatus: PRM_VP*_VSTATUS reg offset from PRM start
- * @voltage: PRM_VP*_VOLTAGE reg offset from PRM start
- *
- * XXX vp_common is probably not needed since it is per-SoC
- */
-struct omap_vp_instance_data {
- const struct omap_vp_common_data *vp_common;
- const struct omap_vp_prm_irqst_data *prm_irqst_data;
- u8 vpconfig;
- u8 vstepmin;
- u8 vstepmax;
- u8 vlimitto;
- u8 vstatus;
- u8 voltage;
-};
-
-/**
- * struct omap_vp_runtime_data - VP data populated at runtime by code
- * @vpconfig_erroroffset: value of ERROROFFSET bitfield in PRM_VP*_CONFIG
- * @vpconfig_errorgain: value of ERRORGAIN bitfield in PRM_VP*_CONFIG
- * @vstepmin_smpswaittimemin: value of SMPSWAITTIMEMIN bitfield in PRM_VP*_VSTEPMIN
- * @vstepmax_smpswaittimemax: value of SMPSWAITTIMEMAX bitfield in PRM_VP*_VSTEPMAX
- * @vlimitto_timeout: value of TIMEOUT bitfield in PRM_VP*_VLIMITTO
- * @vstepmin_stepmin: value of VSTEPMIN bitfield in PRM_VP*_VSTEPMIN
- * @vstepmax_stepmax: value of VSTEPMAX bitfield in PRM_VP*_VSTEPMAX
- * @vlimitto_vddmin: value of VDDMIN bitfield in PRM_VP*_VLIMITTO
- * @vlimitto_vddmax: value of VDDMAX bitfield in PRM_VP*_VLIMITTO
- *
- * XXX Is this structure really needed? Why not just program the
- * device directly? They are in PRM space, therefore in the WKUP
- * powerdomain, so register contents should not be lost in off-mode.
- * XXX Some of these fields are incorrectly named, e.g., vstep*
- */
-struct omap_vp_runtime_data {
- u32 vpconfig_erroroffset;
- u16 vpconfig_errorgain;
- u16 vstepmin_smpswaittimemin;
- u16 vstepmax_smpswaittimemax;
- u16 vlimitto_timeout;
- u8 vstepmin_stepmin;
- u8 vstepmax_stepmax;
- u8 vlimitto_vddmin;
- u8 vlimitto_vddmax;
-};
-
-extern struct omap_vp_instance_data omap3_vp1_data;
-extern struct omap_vp_instance_data omap3_vp2_data;
-
-extern struct omap_vp_instance_data omap4_vp_mpu_data;
-extern struct omap_vp_instance_data omap4_vp_iva_data;
-extern struct omap_vp_instance_data omap4_vp_core_data;
-
-#endif
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c b/arch/arm/mach-omap2/vp3xxx_data.c
index 6452170..a7ac327 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -20,11 +20,9 @@
#include <linux/init.h>
#include <plat/common.h>
+#include <plat/voltage.h>
#include "prm-regbits-34xx.h"
-#include "voltage.h"
-
-#include "vp.h"
/*
* VP data common to 34xx/36xx chips
diff --git a/arch/arm/mach-omap2/vp44xx_data.c b/arch/arm/mach-omap2/vp44xx_data.c
index 65d1ad6..88d059f 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -20,12 +20,10 @@
#include <linux/init.h>
#include <plat/common.h>
+#include <plat/voltage.h>
#include "prm44xx.h"
#include "prm-regbits-44xx.h"
-#include "voltage.h"
-
-#include "vp.h"
/*
* VP data common to 44xx chips
diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
new file mode 100644
index 0000000..46573bf
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -0,0 +1,183 @@
+/*
+ * OMAP Voltage Management Routines
+ *
+ * Author: Thara Gopinath <thara@ti.com>
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ * Thara Gopinath <thara@ti.com>
+ *
+ * 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_PLAT_OMAP_VOLTAGE_H
+#define __ARCH_ARM_PLAT_OMAP_VOLTAGE_H
+
+#include <linux/err.h>
+
+#include <plat/vp.h>
+
+/* XXX document */
+#define VOLTSCALE_VPFORCEUPDATE 1
+#define VOLTSCALE_VCBYPASS 2
+
+/*
+ * OMAP3 GENERIC setup times. Revisit to see if these needs to be
+ * passed from board or PMIC file
+ */
+#define OMAP3_CLKSETUP 0xff
+#define OMAP3_VOLTOFFSET 0xff
+#define OMAP3_VOLTSETUP2 0xff
+
+/**
+ * struct omap_vfsm_instance_data - per-voltage manager FSM register/bitfield
+ * data
+ * @voltsetup_mask: SETUP_TIME* bitmask in the PRM_VOLTSETUP* register
+ * @voltsetup_reg: register offset of PRM_VOLTSETUP from PRM base
+ * @voltsetup_shift: SETUP_TIME* field shift in the PRM_VOLTSETUP* register
+ *
+ * XXX What about VOLTOFFSET/VOLTCTRL?
+ * XXX It is not necessary to have both a _mask and a _shift for the same
+ * bitfield - remove one!
+ */
+struct omap_vfsm_instance_data {
+ u32 voltsetup_mask;
+ u8 voltsetup_reg;
+ u8 voltsetup_shift;
+};
+
+/**
+ * struct voltagedomain - omap voltage domain global structure.
+ * @name: Name of the voltage domain which can be used as a unique
+ * identifier.
+ */
+struct voltagedomain {
+ char *name;
+};
+
+/**
+ * struct omap_volt_data - Omap voltage specific data.
+ * @voltage_nominal: The possible voltage value in uV
+ * @sr_efuse_offs: The offset of the efuse register(from system
+ * control module base address) from where to read
+ * the n-target value for the smartreflex module.
+ * @sr_errminlimit: Error min limit value for smartreflex. This value
+ * differs at differnet opp and thus is linked
+ * with voltage.
+ * @vp_errorgain: Error gain value for the voltage processor. This
+ * field also differs according to the voltage/opp.
+ */
+struct omap_volt_data {
+ u32 volt_nominal;
+ u32 sr_efuse_offs;
+ u8 sr_errminlimit;
+ u8 vp_errgain;
+};
+
+/**
+ * struct omap_volt_pmic_info - PMIC specific data required by voltage driver.
+ * @slew_rate: PMIC slew rate (in uv/us)
+ * @step_size: PMIC voltage step size (in uv)
+ * @vsel_to_uv: PMIC API to convert vsel value to actual voltage in uV.
+ * @uv_to_vsel: PMIC API to convert voltage in uV to vsel value.
+ */
+struct omap_volt_pmic_info {
+ int slew_rate;
+ int step_size;
+ u32 on_volt;
+ u32 onlp_volt;
+ u32 ret_volt;
+ u32 off_volt;
+ u16 volt_setup_time;
+ u8 vp_erroroffset;
+ u8 vp_vstepmin;
+ u8 vp_vstepmax;
+ u8 vp_vddmin;
+ u8 vp_vddmax;
+ u8 vp_timeout_us;
+ u8 i2c_slave_addr;
+ u8 pmic_reg;
+ unsigned long (*vsel_to_uv) (const u8 vsel);
+ u8 (*uv_to_vsel) (unsigned long uV);
+};
+
+/**
+ * omap_vdd_info - Per Voltage Domain info
+ *
+ * @volt_data : voltage table having the distinct voltages supported
+ * by the domain and other associated per voltage data.
+ * @pmic_info : pmic specific parameters which should be populted by
+ * the pmic drivers.
+ * @vp_data : the register values, shifts, masks for various
+ * vp registers
+ * @vp_rt_data : VP data derived at runtime, not predefined
+ * @vc_data : structure containing various various vc registers,
+ * shifts, masks etc.
+ * @vfsm : voltage manager FSM data
+ * @voltdm : pointer to the voltage domain structure
+ * @debug_dir : debug directory for this voltage domain.
+ * @curr_volt : current voltage for this vdd.
+ * @vp_enabled : flag to keep track of whether vp is enabled or not
+ * @volt_scale : API to scale the voltage of the vdd.
+ */
+struct omap_vdd_info {
+ struct omap_volt_data *volt_data;
+ struct omap_volt_pmic_info *pmic_info;
+ struct omap_vp_instance_data *vp_data;
+ struct omap_vp_runtime_data vp_rt_data;
+ struct omap_vc_instance_data *vc_data;
+ const struct omap_vfsm_instance_data *vfsm;
+ struct voltagedomain voltdm;
+ struct dentry *debug_dir;
+ u32 curr_volt;
+ bool vp_enabled;
+ u32 (*read_reg) (u16 mod, u8 offset);
+ void (*write_reg) (u32 val, u16 mod, u8 offset);
+ int (*volt_scale) (struct omap_vdd_info *vdd,
+ unsigned long target_volt);
+};
+
+unsigned long omap_vp_get_curr_volt(struct voltagedomain *voltdm);
+void omap_vp_enable(struct voltagedomain *voltdm);
+void omap_vp_disable(struct voltagedomain *voltdm);
+int omap_voltage_scale_vdd(struct voltagedomain *voltdm,
+ unsigned long target_volt);
+void omap_voltage_reset(struct voltagedomain *voltdm);
+void omap_voltage_get_volttable(struct voltagedomain *voltdm,
+ struct omap_volt_data **volt_data);
+struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm,
+ unsigned long volt);
+unsigned long omap_voltage_get_nom_volt(struct voltagedomain *voltdm);
+struct dentry *omap_voltage_get_dbgdir(struct voltagedomain *voltdm);
+int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_mod,
+ struct omap_vdd_info *omap_vdd_array[],
+ u8 omap_vdd_count);
+#ifdef CONFIG_PM
+int omap_voltage_register_pmic(struct voltagedomain *voltdm,
+ struct omap_volt_pmic_info *pmic_info);
+void omap_change_voltscale_method(struct voltagedomain *voltdm,
+ int voltscale_method);
+/* API to get the voltagedomain pointer */
+struct voltagedomain *omap_voltage_domain_lookup(char *name);
+
+int omap_voltage_late_init(void);
+#else
+static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
+ struct omap_volt_pmic_info *pmic_info)
+{
+ return -EINVAL;
+}
+static inline void omap_change_voltscale_method(struct voltagedomain *voltdm,
+ int voltscale_method) {}
+static inline int omap_voltage_late_init(void)
+{
+ return -EINVAL;
+}
+static inline struct voltagedomain *omap_voltage_domain_lookup(char *name)
+{
+ return ERR_PTR(-EINVAL);
+}
+#endif
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/vp.h b/arch/arm/plat-omap/include/plat/vp.h
new file mode 100644
index 0000000..95f93b9
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/vp.h
@@ -0,0 +1,143 @@
+/*
+ * OMAP3/4 Voltage Processor (VP) 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_PLAT_OMAP_VP_H
+#define __ARCH_ARM_PLAT_OMAP_VP_H
+
+#include <linux/kernel.h>
+
+/* XXX document */
+#define VP_IDLE_TIMEOUT 200
+#define VP_TRANXDONE_TIMEOUT 300
+
+
+/**
+ * struct omap_vp_common_data - register data common to all VDDs
+ * @vpconfig_errorgain_mask: ERRORGAIN bitmask in the PRM_VP*_CONFIG reg
+ * @vpconfig_initvoltage_mask: INITVOLTAGE bitmask in the PRM_VP*_CONFIG reg
+ * @vpconfig_timeouten_mask: TIMEOUT bitmask in the PRM_VP*_CONFIG reg
+ * @vpconfig_initvdd: INITVDD bitmask in the PRM_VP*_CONFIG reg
+ * @vpconfig_forceupdate: FORCEUPDATE bitmask in the PRM_VP*_CONFIG reg
+ * @vpconfig_vpenable: VPENABLE bitmask in the PRM_VP*_CONFIG reg
+ * @vpconfig_erroroffset_shift: ERROROFFSET field shift in PRM_VP*_CONFIG reg
+ * @vpconfig_errorgain_shift: ERRORGAIN field shift in PRM_VP*_CONFIG reg
+ * @vpconfig_initvoltage_shift: INITVOLTAGE field shift in PRM_VP*_CONFIG reg
+ * @vpconfig_stepmin_shift: VSTEPMIN field shift in the PRM_VP*_VSTEPMIN reg
+ * @vpconfig_smpswaittimemin_shift: SMPSWAITTIMEMIN field shift in PRM_VP*_VSTEPMIN reg
+ * @vpconfig_stepmax_shift: VSTEPMAX field shift in the PRM_VP*_VSTEPMAX reg
+ * @vpconfig_smpswaittimemax_shift: SMPSWAITTIMEMAX field shift in PRM_VP*_VSTEPMAX reg
+ * @vpconfig_vlimitto_vddmin_shift: VDDMIN field shift in PRM_VP*_VLIMITTO reg
+ * @vpconfig_vlimitto_vddmax_shift: VDDMAX field shift in PRM_VP*_VLIMITTO reg
+ * @vpconfig_vlimitto_timeout_shift: TIMEOUT field shift in PRM_VP*_VLIMITTO reg
+ *
+ * XXX It it not necessary to have both a mask and a shift for the same
+ * bitfield - remove one
+ * XXX Many of these fields are wrongly named -- e.g., vpconfig_smps* -- fix!
+ */
+struct omap_vp_common_data {
+ u32 vpconfig_errorgain_mask;
+ u32 vpconfig_initvoltage_mask;
+ u32 vpconfig_timeouten;
+ u32 vpconfig_initvdd;
+ u32 vpconfig_forceupdate;
+ u32 vpconfig_vpenable;
+ u8 vpconfig_erroroffset_shift;
+ u8 vpconfig_errorgain_shift;
+ u8 vpconfig_initvoltage_shift;
+ u8 vstepmin_stepmin_shift;
+ u8 vstepmin_smpswaittimemin_shift;
+ u8 vstepmax_stepmax_shift;
+ u8 vstepmax_smpswaittimemax_shift;
+ u8 vlimitto_vddmin_shift;
+ u8 vlimitto_vddmax_shift;
+ u8 vlimitto_timeout_shift;
+};
+
+/**
+ * struct omap_vp_prm_irqst_data - PRM_IRQSTATUS_MPU.VP_TRANXDONE_ST data
+ * @prm_irqst_reg: reg offset for PRM_IRQSTATUS_MPU from top of PRM
+ * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ *
+ * XXX prm_irqst_reg does not belong here
+ * XXX Note that on OMAP3, VP_TRANXDONE interrupt may not work due to a
+ * hardware bug
+ * XXX This structure is probably not needed
+ */
+struct omap_vp_prm_irqst_data {
+ u8 prm_irqst_reg;
+ u32 tranxdone_status;
+};
+
+/**
+ * struct omap_vp_instance_data - VP register offsets (per-VDD)
+ * @vp_common: pointer to struct omap_vp_common_data * for this SoC
+ * @prm_irqst_data: pointer to struct omap_vp_prm_irqst_data for this VDD
+ * @vpconfig: PRM_VP*_CONFIG reg offset from PRM start
+ * @vstepmin: PRM_VP*_VSTEPMIN reg offset from PRM start
+ * @vlimitto: PRM_VP*_VLIMITTO reg offset from PRM start
+ * @vstatus: PRM_VP*_VSTATUS reg offset from PRM start
+ * @voltage: PRM_VP*_VOLTAGE reg offset from PRM start
+ *
+ * XXX vp_common is probably not needed since it is per-SoC
+ */
+struct omap_vp_instance_data {
+ const struct omap_vp_common_data *vp_common;
+ const struct omap_vp_prm_irqst_data *prm_irqst_data;
+ u8 vpconfig;
+ u8 vstepmin;
+ u8 vstepmax;
+ u8 vlimitto;
+ u8 vstatus;
+ u8 voltage;
+};
+
+/**
+ * struct omap_vp_runtime_data - VP data populated at runtime by code
+ * @vpconfig_erroroffset: value of ERROROFFSET bitfield in PRM_VP*_CONFIG
+ * @vpconfig_errorgain: value of ERRORGAIN bitfield in PRM_VP*_CONFIG
+ * @vstepmin_smpswaittimemin: value of SMPSWAITTIMEMIN bitfield in PRM_VP*_VSTEPMIN
+ * @vstepmax_smpswaittimemax: value of SMPSWAITTIMEMAX bitfield in PRM_VP*_VSTEPMAX
+ * @vlimitto_timeout: value of TIMEOUT bitfield in PRM_VP*_VLIMITTO
+ * @vstepmin_stepmin: value of VSTEPMIN bitfield in PRM_VP*_VSTEPMIN
+ * @vstepmax_stepmax: value of VSTEPMAX bitfield in PRM_VP*_VSTEPMAX
+ * @vlimitto_vddmin: value of VDDMIN bitfield in PRM_VP*_VLIMITTO
+ * @vlimitto_vddmax: value of VDDMAX bitfield in PRM_VP*_VLIMITTO
+ *
+ * XXX Is this structure really needed? Why not just program the
+ * device directly? They are in PRM space, therefore in the WKUP
+ * powerdomain, so register contents should not be lost in off-mode.
+ * XXX Some of these fields are incorrectly named, e.g., vstep*
+ */
+struct omap_vp_runtime_data {
+ u32 vpconfig_erroroffset;
+ u16 vpconfig_errorgain;
+ u16 vstepmin_smpswaittimemin;
+ u16 vstepmax_smpswaittimemax;
+ u16 vlimitto_timeout;
+ u8 vstepmin_stepmin;
+ u8 vstepmax_stepmax;
+ u8 vlimitto_vddmin;
+ u8 vlimitto_vddmax;
+};
+
+extern struct omap_vp_instance_data omap3_vp1_data;
+extern struct omap_vp_instance_data omap3_vp2_data;
+
+extern struct omap_vp_instance_data omap4_vp_mpu_data;
+extern struct omap_vp_instance_data omap4_vp_iva_data;
+extern struct omap_vp_instance_data omap4_vp_core_data;
+
+#endif
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCHv2 2/5] regulator: omap smps regulator driver
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
2011-07-13 14:00 ` [PATCHv2 1/5] OMAP: move voltage.h and vp.h under platform include directory Tero Kristo
@ 2011-07-13 14:00 ` Tero Kristo
2011-07-13 14:40 ` Mark Brown
2011-07-14 6:29 ` Todd Poynor
2011-07-13 14:00 ` [PATCHv2 3/5] omap3: beagle: instantiate smps regulators Tero Kristo
` (5 subsequent siblings)
7 siblings, 2 replies; 21+ messages in thread
From: Tero Kristo @ 2011-07-13 14:00 UTC (permalink / raw)
To: linux-omap; +Cc: broonie, lrg, khilman
OMAP SMPS regulator driver provides access to OMAP voltage processor
controlled regulators. These include VDD1 and VDD2 for OMAP3 and additionally
VDD3 for OMAP4. SMPS regulators use the OMAP voltage layer for the actual
voltage regulation operations.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/regulator/Kconfig | 9 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/omap-smps-regulator.c | 126 +++++++++++++++++++++++++++++++
include/linux/regulator/omap-smps.h | 20 +++++
4 files changed, 156 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/omap-smps-regulator.c
create mode 100644 include/linux/regulator/omap-smps.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index d7ed20f..bb18ff2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -303,5 +303,14 @@ config REGULATOR_TPS65910
help
This driver supports TPS65910 voltage regulator chips.
+config REGULATOR_OMAP_SMPS
+ tristate "TI OMAP SMPS Power Regulators"
+ depends on (ARCH_OMAP3 || ARCH_OMAP4) && PM && TWL4030_CORE
+ help
+ This driver supports the OMAP3 / OMAP4 SMPS regulators for VDD1,
+ VDD2 and VDD3. These regulators reside inside the TWL4030 /
+ TWL6030 chip but are accessed using the voltage processor
+ interface of OMAP.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 3932d2e..191e3d5 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -43,5 +43,6 @@ obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
obj-$(CONFIG_REGULATOR_AB8500) += ab8500.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
+obj-$(CONFIG_REGULATOR_OMAP_SMPS) += omap-smps-regulator.o
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/omap-smps-regulator.c b/drivers/regulator/omap-smps-regulator.c
new file mode 100644
index 0000000..88009b1
--- /dev/null
+++ b/drivers/regulator/omap-smps-regulator.c
@@ -0,0 +1,126 @@
+/*
+ * omap-vp-regulator.c -- support SMPS regulators for OMAP chips
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/omap-smps.h>
+#include <plat/voltage.h>
+
+#define DRIVER_NAME "omap-smps"
+
+struct omap_smps_reg_info {
+ struct voltagedomain *voltdm;
+ struct regulator_desc desc;
+};
+
+static int omap_smps_set_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return omap_voltage_scale_vdd(info->voltdm, min_uV);
+}
+
+static int omap_smps_get_voltage(struct regulator_dev *rdev)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return omap_vp_get_curr_volt(info->voltdm);
+}
+
+static struct regulator_ops omap_smps_ops = {
+ .set_voltage = omap_smps_set_voltage,
+ .get_voltage = omap_smps_get_voltage,
+};
+
+static int __devinit omap_smps_reg_probe(struct platform_device *pdev)
+{
+ int i;
+ struct omap_smps_reg_info *info;
+ struct omap_smps_platform_data *pdata;
+ struct regulation_constraints *c;
+ struct regulator_dev *rdev;
+ struct regulator_init_data *initdata;
+ struct voltagedomain *voltdm;
+
+ pdata = pdev->dev.platform_data;
+
+ for (i = 0; i < pdata->num_regulators; i++) {
+ initdata = pdata->regulators[i];
+
+ c = &initdata->constraints;
+ c->valid_modes_mask &= REGULATOR_MODE_NORMAL;
+ c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE;
+ c->always_on = true;
+
+ voltdm = omap_voltage_domain_lookup(
+ initdata->consumer_supplies[0].dev_name);
+
+ if (IS_ERR(voltdm)) {
+ dev_err(&pdev->dev, "can't find voltdm %s, %ld\n",
+ initdata->consumer_supplies[0].dev_name,
+ PTR_ERR(voltdm));
+ return PTR_ERR(voltdm);
+ }
+ info = kzalloc(sizeof(struct omap_smps_reg_info), GFP_KERNEL);
+
+ info->voltdm = voltdm;
+ info->desc.ops = &omap_smps_ops;
+ info->desc.name = c->name;
+ info->desc.type = REGULATOR_VOLTAGE;
+ info->desc.n_voltages = 0;
+ rdev = regulator_register(&info->desc, &pdev->dev, initdata,
+ info);
+ if (IS_ERR(rdev)) {
+ dev_err(&pdev->dev, "can't register %s, %ld\n",
+ info->desc.name, PTR_ERR(rdev));
+ return PTR_ERR(rdev);
+ }
+ platform_set_drvdata(pdev, rdev);
+ }
+
+ return 0;
+}
+
+static int omap_smps_reg_remove(struct platform_device *pdev)
+{
+ regulator_unregister(platform_get_drvdata(pdev));
+ return 0;
+}
+
+static struct platform_driver omap_smps_reg_driver = {
+ .probe = omap_smps_reg_probe,
+ .remove = __devexit_p(omap_smps_reg_remove),
+ .driver.name = DRIVER_NAME,
+ .driver.owner = THIS_MODULE,
+};
+
+static int __init omap_smps_reg_init(void)
+{
+ return platform_driver_register(&omap_smps_reg_driver);
+}
+subsys_initcall(omap_smps_reg_init);
+
+static void __exit omap_smps_reg_exit(void)
+{
+ platform_driver_unregister(&omap_smps_reg_driver);
+}
+module_exit(omap_smps_reg_exit);
+
+MODULE_ALIAS("platform:"DRIVER_NAME);
+MODULE_AUTHOR("Tero Kristo <t-kristo@ti.com>");
+MODULE_DESCRIPTION("OMAP SMPS regulator driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/regulator/omap-smps.h b/include/linux/regulator/omap-smps.h
new file mode 100644
index 0000000..1d5f940
--- /dev/null
+++ b/include/linux/regulator/omap-smps.h
@@ -0,0 +1,20 @@
+/*
+ * omap-smps.h - header for OMAP SMPS regulator support
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ *
+ * 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 __OMAP_SMPS_H__
+#define __OMAP_SMPS_H__
+
+struct omap_smps_platform_data {
+ struct regulator_init_data **regulators;
+ int num_regulators;
+};
+
+#endif /* End of __OMAP_SMPS_H__ */
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCHv2 2/5] regulator: omap smps regulator driver
2011-07-13 14:00 ` [PATCHv2 2/5] regulator: omap smps regulator driver Tero Kristo
@ 2011-07-13 14:40 ` Mark Brown
2011-07-13 15:53 ` Tero Kristo
2011-07-14 6:29 ` Todd Poynor
1 sibling, 1 reply; 21+ messages in thread
From: Mark Brown @ 2011-07-13 14:40 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-omap, lrg, khilman
On Wed, Jul 13, 2011 at 05:00:35PM +0300, Tero Kristo wrote:
> +config REGULATOR_OMAP_SMPS
> + tristate "TI OMAP SMPS Power Regulators"
> + depends on (ARCH_OMAP3 || ARCH_OMAP4) && PM && TWL4030_CORE
What is the dependency on the TWL4030? I see no references to it in the
code...
> + for (i = 0; i < pdata->num_regulators; i++) {
> + initdata = pdata->regulators[i];
> +
I do strongly prefer the idiom of just registering all the regulators
even if they're read only.
> + c = &initdata->constraints;
> + c->valid_modes_mask &= REGULATOR_MODE_NORMAL;
> + c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE;
> + c->always_on = true;
No, this is bad. We *always* pay attention to the constraints the user
set even if they're nuts or won't work, the machine driver has the final
say on what is or isn't allowed on a given board. The mode setting is
especially suspect as there's no mode support in the driver.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCHv2 2/5] regulator: omap smps regulator driver
2011-07-13 14:40 ` Mark Brown
@ 2011-07-13 15:53 ` Tero Kristo
2011-07-13 22:55 ` Mark Brown
0 siblings, 1 reply; 21+ messages in thread
From: Tero Kristo @ 2011-07-13 15:53 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-omap, Girdwood, Liam, Hilman, Kevin
On Wed, 2011-07-13 at 16:40 +0200, Mark Brown wrote:
> On Wed, Jul 13, 2011 at 05:00:35PM +0300, Tero Kristo wrote:
>
> > +config REGULATOR_OMAP_SMPS
> > + tristate "TI OMAP SMPS Power Regulators"
> > + depends on (ARCH_OMAP3 || ARCH_OMAP4) && PM && TWL4030_CORE
>
> What is the dependency on the TWL4030? I see no references to it in the
> code...
Hmm, true... I was mainly thinking about the HW setup where we usually
have a TWL family chip which is controlled by the SMPS regulator driver.
I think that one can actually be dropped as it might be possible to use
some other power IC behind the SMPS channels. I think I'll remove all
the references to TWL4030 / TWL6030 from this patch.
>
> > + for (i = 0; i < pdata->num_regulators; i++) {
> > + initdata = pdata->regulators[i];
> > +
>
> I do strongly prefer the idiom of just registering all the regulators
> even if they're read only.
Number of available SMPS regulators is kind of board specific issue.
OMAP3 has 2 available, OMAP4 has 3. If we are using some custom powering
solution, we might have even different amounts for these.
>
> > + c = &initdata->constraints;
> > + c->valid_modes_mask &= REGULATOR_MODE_NORMAL;
> > + c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE;
> > + c->always_on = true;
>
> No, this is bad. We *always* pay attention to the constraints the user
> set even if they're nuts or won't work, the machine driver has the final
> say on what is or isn't allowed on a given board. The mode setting is
> especially suspect as there's no mode support in the driver.
Just a clarification on this one that I have understood your comment
right... Do you mean that I should be checking the constraints user sets
more thoroughly to see if there is something bogus? I was looking at
some of the other regulator drivers and they seem to be fiddling with
the constraints in similar manner.
-Tero
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCHv2 2/5] regulator: omap smps regulator driver
2011-07-13 15:53 ` Tero Kristo
@ 2011-07-13 22:55 ` Mark Brown
2011-07-14 7:51 ` Tero Kristo
0 siblings, 1 reply; 21+ messages in thread
From: Mark Brown @ 2011-07-13 22:55 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-omap, Girdwood, Liam, Hilman, Kevin
On Wed, Jul 13, 2011 at 06:53:45PM +0300, Tero Kristo wrote:
> On Wed, 2011-07-13 at 16:40 +0200, Mark Brown wrote:
> > I do strongly prefer the idiom of just registering all the regulators
> > even if they're read only.
> Number of available SMPS regulators is kind of board specific issue.
> OMAP3 has 2 available, OMAP4 has 3. If we are using some custom powering
> solution, we might have even different amounts for these.
Right, but the interface to them is always there?
> > No, this is bad. We *always* pay attention to the constraints the user
> > set even if they're nuts or won't work, the machine driver has the final
> > say on what is or isn't allowed on a given board. The mode setting is
> > especially suspect as there's no mode support in the driver.
> Just a clarification on this one that I have understood your comment
> right... Do you mean that I should be checking the constraints user sets
> more thoroughly to see if there is something bogus? I was looking at
> some of the other regulator drivers and they seem to be fiddling with
> the constraints in similar manner.
No! You should *always* use the constraints the user has set, don't
randomly add new permissions without them doing so.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 2/5] regulator: omap smps regulator driver
2011-07-13 22:55 ` Mark Brown
@ 2011-07-14 7:51 ` Tero Kristo
0 siblings, 0 replies; 21+ messages in thread
From: Tero Kristo @ 2011-07-14 7:51 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-omap, Girdwood, Liam, Hilman, Kevin, toddpoynor
On Thu, 2011-07-14 at 00:55 +0200, Mark Brown wrote:
> On Wed, Jul 13, 2011 at 06:53:45PM +0300, Tero Kristo wrote:
> > On Wed, 2011-07-13 at 16:40 +0200, Mark Brown wrote:
>
> > > I do strongly prefer the idiom of just registering all the regulators
> > > even if they're read only.
>
> > Number of available SMPS regulators is kind of board specific issue.
> > OMAP3 has 2 available, OMAP4 has 3. If we are using some custom powering
> > solution, we might have even different amounts for these.
>
> Right, but the interface to them is always there?
The library used in this driver will attempt to lookup for the
voltagedomains, and this will fail for 'iva' on omap3, as it does not
exist. I could change the driver to always try to look for all of the
possible known domains, and just register the ones it finds, and apply
user settings for the ones that board file provides. This contradicts
now a bit on the comment I just said to Todd, but you believe this to be
a better way?
>
> > > No, this is bad. We *always* pay attention to the constraints the user
> > > set even if they're nuts or won't work, the machine driver has the final
> > > say on what is or isn't allowed on a given board. The mode setting is
> > > especially suspect as there's no mode support in the driver.
>
> > Just a clarification on this one that I have understood your comment
> > right... Do you mean that I should be checking the constraints user sets
> > more thoroughly to see if there is something bogus? I was looking at
> > some of the other regulator drivers and they seem to be fiddling with
> > the constraints in similar manner.
>
> No! You should *always* use the constraints the user has set, don't
> randomly add new permissions without them doing so.
Ah ok, so no fiddling with the constraints at all, core should take care
of proper functioning regarding this part.
-Tero
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 2/5] regulator: omap smps regulator driver
2011-07-13 14:00 ` [PATCHv2 2/5] regulator: omap smps regulator driver Tero Kristo
2011-07-13 14:40 ` Mark Brown
@ 2011-07-14 6:29 ` Todd Poynor
2011-07-14 7:23 ` Tero Kristo
1 sibling, 1 reply; 21+ messages in thread
From: Todd Poynor @ 2011-07-14 6:29 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-omap, broonie, lrg, khilman
On Wed, Jul 13, 2011 at 05:00:35PM +0300, Tero Kristo wrote:
> OMAP SMPS regulator driver provides access to OMAP voltage processor
> controlled regulators. These include VDD1 and VDD2 for OMAP3 and additionally
> VDD3 for OMAP4. SMPS regulators use the OMAP voltage layer for the actual
> voltage regulation operations.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
...
> + for (i = 0; i < pdata->num_regulators; i++) {
> + initdata = pdata->regulators[i];
> +
> + c = &initdata->constraints;
> + c->valid_modes_mask &= REGULATOR_MODE_NORMAL;
> + c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE;
> + c->always_on = true;
> +
> + voltdm = omap_voltage_domain_lookup(
> + initdata->consumer_supplies[0].dev_name);
> +
> + if (IS_ERR(voltdm)) {
> + dev_err(&pdev->dev, "can't find voltdm %s, %ld\n",
> + initdata->consumer_supplies[0].dev_name,
> + PTR_ERR(voltdm));
> + return PTR_ERR(voltdm);
Or maybe continue to next loop iteration.
> + }
> + info = kzalloc(sizeof(struct omap_smps_reg_info), GFP_KERNEL);
> +
> + info->voltdm = voltdm;
Check kzalloc NULL return.
> + info->desc.ops = &omap_smps_ops;
> + info->desc.name = c->name;
> + info->desc.type = REGULATOR_VOLTAGE;
> + info->desc.n_voltages = 0;
> + rdev = regulator_register(&info->desc, &pdev->dev, initdata,
> + info);
> + if (IS_ERR(rdev)) {
> + dev_err(&pdev->dev, "can't register %s, %ld\n",
> + info->desc.name, PTR_ERR(rdev));
> + return PTR_ERR(rdev);
Or suggest continue to next loop iteration.
> + }
> + platform_set_drvdata(pdev, rdev);
Performed in a loop, but only last iteration's rdev is set as the
driver data for pdev. Platform driver data should be pdata?
> + }
> +
> + return 0;
> +}
> +
> +static int omap_smps_reg_remove(struct platform_device *pdev)
> +{
> + regulator_unregister(platform_get_drvdata(pdev));
Should kfree() the struct omap_smps_reg_info data structure(s) and
platform_set_drvdata(pdev, NULL) ?
Todd
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCHv2 2/5] regulator: omap smps regulator driver
2011-07-14 6:29 ` Todd Poynor
@ 2011-07-14 7:23 ` Tero Kristo
0 siblings, 0 replies; 21+ messages in thread
From: Tero Kristo @ 2011-07-14 7:23 UTC (permalink / raw)
To: Todd Poynor; +Cc: linux-omap, broonie, Girdwood, Liam, Hilman, Kevin
On Thu, 2011-07-14 at 08:29 +0200, Todd Poynor wrote:
> On Wed, Jul 13, 2011 at 05:00:35PM +0300, Tero Kristo wrote:
> > OMAP SMPS regulator driver provides access to OMAP voltage processor
> > controlled regulators. These include VDD1 and VDD2 for OMAP3 and additionally
> > VDD3 for OMAP4. SMPS regulators use the OMAP voltage layer for the actual
> > voltage regulation operations.
> >
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > ---
> ...
> > + for (i = 0; i < pdata->num_regulators; i++) {
> > + initdata = pdata->regulators[i];
> > +
> > + c = &initdata->constraints;
> > + c->valid_modes_mask &= REGULATOR_MODE_NORMAL;
> > + c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE;
> > + c->always_on = true;
> > +
> > + voltdm = omap_voltage_domain_lookup(
> > + initdata->consumer_supplies[0].dev_name);
> > +
> > + if (IS_ERR(voltdm)) {
> > + dev_err(&pdev->dev, "can't find voltdm %s, %ld\n",
> > + initdata->consumer_supplies[0].dev_name,
> > + PTR_ERR(voltdm));
> > + return PTR_ERR(voltdm);
>
>
> Or maybe continue to next loop iteration.
Not sure about this. If one of the regulators fails, it is probably
better to fail/disable them all, otherwise we end up in partly
functioning situation. I think I'll just change this into a setup where
all the SMPS regulators are disabled if init of any of them fails.
>
> > + }
> > + info = kzalloc(sizeof(struct omap_smps_reg_info), GFP_KERNEL);
> > +
> > + info->voltdm = voltdm;
>
>
> Check kzalloc NULL return.
True.
>
> > + info->desc.ops = &omap_smps_ops;
> > + info->desc.name = c->name;
> > + info->desc.type = REGULATOR_VOLTAGE;
> > + info->desc.n_voltages = 0;
> > + rdev = regulator_register(&info->desc, &pdev->dev, initdata,
> > + info);
> > + if (IS_ERR(rdev)) {
> > + dev_err(&pdev->dev, "can't register %s, %ld\n",
> > + info->desc.name, PTR_ERR(rdev));
> > + return PTR_ERR(rdev);
>
> Or suggest continue to next loop iteration.
Same as above continue comment.
>
> > + }
> > + platform_set_drvdata(pdev, rdev);
>
> Performed in a loop, but only last iteration's rdev is set as the
> driver data for pdev. Platform driver data should be pdata?
I'll check what the cleanup part needs and fix it.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int omap_smps_reg_remove(struct platform_device *pdev)
> > +{
> > + regulator_unregister(platform_get_drvdata(pdev));
>
>
> Should kfree() the struct omap_smps_reg_info data structure(s) and
> platform_set_drvdata(pdev, NULL) ?
Same as above.
>
>
> Todd
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCHv2 3/5] omap3: beagle: instantiate smps regulators
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
2011-07-13 14:00 ` [PATCHv2 1/5] OMAP: move voltage.h and vp.h under platform include directory Tero Kristo
2011-07-13 14:00 ` [PATCHv2 2/5] regulator: omap smps regulator driver Tero Kristo
@ 2011-07-13 14:00 ` Tero Kristo
2011-07-13 14:00 ` [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6 Tero Kristo
` (4 subsequent siblings)
7 siblings, 0 replies; 21+ messages in thread
From: Tero Kristo @ 2011-07-13 14:00 UTC (permalink / raw)
To: linux-omap; +Cc: broonie, lrg, khilman
VDD1 and VDD2 are now available. This requires SMPS regulator driver to work.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 53 +++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 78cf5f2..d7ae648 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -31,6 +31,7 @@
#include <linux/mmc/host.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/omap-smps.h>
#include <linux/i2c/twl.h>
#include <mach/hardware.h>
@@ -274,6 +275,15 @@ static struct regulator_consumer_supply beagle_vsim_supply[] = {
REGULATOR_SUPPLY("vmmc_aux", "omap_hsmmc.0"),
};
+static struct regulator_consumer_supply beagle_smps1_supply[] = {
+ REGULATOR_SUPPLY("vcc", "mpu"),
+};
+
+static struct regulator_consumer_supply beagle_smps2_supply[] = {
+ REGULATOR_SUPPLY("vcc", "core"),
+};
+
+
static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
@@ -400,6 +410,30 @@ static struct regulator_init_data beagle_vpll2 = {
.consumer_supplies = beagle_vdvi_supplies,
};
+static struct regulator_init_data beagle_smps1 = {
+ .constraints = {
+ .name = "VDD1",
+ .min_uV = 600000,
+ .max_uV = 1450000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(beagle_smps1_supply),
+ .consumer_supplies = beagle_smps1_supply,
+};
+
+static struct regulator_init_data beagle_smps2 = {
+ .constraints = {
+ .name = "VDD2",
+ .min_uV = 600000,
+ .max_uV = 1450000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(beagle_smps2_supply),
+ .consumer_supplies = beagle_smps2_supply,
+};
+
static struct twl4030_usb_data beagle_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
@@ -425,6 +459,16 @@ static struct twl4030_platform_data beagle_twldata = {
.vpll2 = &beagle_vpll2,
};
+static struct regulator_init_data *beagle_smps_reg_list[] = {
+ &beagle_smps1,
+ &beagle_smps2,
+};
+
+static struct omap_smps_platform_data beagle_smps_info = {
+ .regulators = beagle_smps_reg_list,
+ .num_regulators = ARRAY_SIZE(beagle_smps_reg_list),
+};
+
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
{
I2C_BOARD_INFO("eeprom", 0x50),
@@ -494,6 +538,14 @@ static struct platform_device keys_gpio = {
},
};
+static struct platform_device beagle_smps = {
+ .name = "omap-smps",
+ .id = -1,
+ .dev = {
+ .platform_data = &beagle_smps_info,
+ },
+};
+
static void __init omap3_beagle_init_early(void)
{
omap2_init_common_infrastructure();
@@ -509,6 +561,7 @@ static void __init omap3_beagle_init_irq(void)
static struct platform_device *omap3_beagle_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
+ &beagle_smps,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
` (2 preceding siblings ...)
2011-07-13 14:00 ` [PATCHv2 3/5] omap3: beagle: instantiate smps regulators Tero Kristo
@ 2011-07-13 14:00 ` Tero Kristo
2011-07-13 17:49 ` Premi, Sanjeev
2011-07-13 14:00 ` [PATCHv2 5/5] omap: voltage: changed parameter of omap_voltage_lookup to const Tero Kristo
` (3 subsequent siblings)
7 siblings, 1 reply; 21+ messages in thread
From: Tero Kristo @ 2011-07-13 14:00 UTC (permalink / raw)
To: linux-omap; +Cc: broonie, lrg, khilman
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 32 +++++++++++++++++++++++++++++++
arch/arm/mach-omap2/opp3xxx_data.c | 4 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index d7ae648..5ab507d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -592,6 +592,38 @@ static void __init beagle_opp_init(void)
return;
}
+ /* Custom OPP enabled for C4 */
+ if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
+ struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
+ struct omap_hwmod *dh = omap_hwmod_lookup("iva");
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
+ __func__, mh, dh);
+ }
+ /* Enable MPU 720MHz opp */
+ dev = &mh->od->pdev.dev;
+ r = opp_enable(dev, 720000000);
+
+ /* Enable IVA 520MHz opp */
+ dev = &dh->od->pdev.dev;
+ r |= opp_enable(dev, 520000000);
+
+ if (r) {
+ pr_err("%s: failed to enable higher opp %d\n",
+ __func__, r);
+ /*
+ * Cleanup - disable the higher freqs - we dont care
+ * about the results
+ */
+ dev = &mh->od->pdev.dev;
+ opp_disable(dev, 720000000);
+ dev = &dh->od->pdev.dev;
+ opp_disable(dev, 520000000);
+ }
+ }
+
/* Custom OPP enabled for all xM versions */
if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..a0f5fe1 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -98,6 +98,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
OPP_INITIALIZER("mpu", true, 550000000, OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
OPP_INITIALIZER("mpu", true, 600000000, OMAP3430_VDD_MPU_OPP5_UV),
+ /* MPU OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER("mpu", false, 720000000, OMAP3430_VDD_MPU_OPP5_UV),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -123,6 +125,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
OPP_INITIALIZER("iva", true, 400000000, OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
OPP_INITIALIZER("iva", true, 430000000, OMAP3430_VDD_MPU_OPP5_UV),
+ /* DSP OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER("iva", false, 520000000, OMAP3430_VDD_MPU_OPP5_UV),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply related [flat|nested] 21+ messages in thread* RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
2011-07-13 14:00 ` [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6 Tero Kristo
@ 2011-07-13 17:49 ` Premi, Sanjeev
2011-07-14 7:10 ` Tero Kristo
0 siblings, 1 reply; 21+ messages in thread
From: Premi, Sanjeev @ 2011-07-13 17:49 UTC (permalink / raw)
To: Kristo, Tero, linux-omap; +Cc: broonie, Girdwood, Liam, Hilman, Kevin
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kristo, Tero
> Sent: Wednesday, July 13, 2011 7:31 PM
> To: linux-omap@vger.kernel.org
> Cc: broonie@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin
> Subject: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
>
> Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can
> run at 720MHz.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> arch/arm/mach-omap2/board-omap3beagle.c | 32
> +++++++++++++++++++++++++++++++
> arch/arm/mach-omap2/opp3xxx_data.c | 4 +++
> 2 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index d7ae648..5ab507d 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -592,6 +592,38 @@ static void __init beagle_opp_init(void)
> return;
> }
>
> + /* Custom OPP enabled for C4 */
> + if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
> + struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
> + struct omap_hwmod *dh = omap_hwmod_lookup("iva");
> + struct device *dev;
> +
> + if (!mh || !dh) {
> + pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
> + __func__, mh, dh);
> + }
> + /* Enable MPU 720MHz opp */
> + dev = &mh->od->pdev.dev;
> + r = opp_enable(dev, 720000000);
> +
> + /* Enable IVA 520MHz opp */
> + dev = &dh->od->pdev.dev;
> + r |= opp_enable(dev, 520000000);
> +
> + if (r) {
> + pr_err("%s: failed to enable higher opp %d\n",
> + __func__, r);
> + /*
> + * Cleanup - disable the higher freqs -
> we dont care
> + * about the results
> + */
> + dev = &mh->od->pdev.dev;
> + opp_disable(dev, 720000000);
> + dev = &dh->od->pdev.dev;
> + opp_disable(dev, 520000000);
> + }
> + }
> +
> /* Custom OPP enabled for all xM versions */
> if (cpu_is_omap3630()) {
> struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
> diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
> b/arch/arm/mach-omap2/opp3xxx_data.c
> index d95f3f9..a0f5fe1 100644
> --- a/arch/arm/mach-omap2/opp3xxx_data.c
> +++ b/arch/arm/mach-omap2/opp3xxx_data.c
> @@ -98,6 +98,8 @@ static struct omap_opp_def __initdata
> omap34xx_opp_def_list[] = {
> OPP_INITIALIZER("mpu", true, 550000000,
> OMAP3430_VDD_MPU_OPP4_UV),
> /* MPU OPP5 */
> OPP_INITIALIZER("mpu", true, 600000000,
> OMAP3430_VDD_MPU_OPP5_UV),
> + /* MPU OPP6 : omap3530 high speed grade only */
> + OPP_INITIALIZER("mpu", false, 720000000,
> OMAP3430_VDD_MPU_OPP5_UV),
>
> /*
> * L3 OPP1 - 41.5 MHz is disabled because: The voltage
> for that OPP is
> @@ -123,6 +125,8 @@ static struct omap_opp_def __initdata
> omap34xx_opp_def_list[] = {
> OPP_INITIALIZER("iva", true, 400000000,
> OMAP3430_VDD_MPU_OPP4_UV),
> /* DSP OPP5 */
> OPP_INITIALIZER("iva", true, 430000000,
> OMAP3430_VDD_MPU_OPP5_UV),
> + /* DSP OPP6 : omap3530 high speed grade only */
> + OPP_INITIALIZER("iva", false, 520000000,
> OMAP3430_VDD_MPU_OPP5_UV),
> };
>
> static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
[sp] Basic support for 720MHz was already closed early this year.
See: http://marc.info/?l=linux-omap&m=129735630928696&w=2
I cannot check the current tree status right now; but I assume
the patch should already be in.
~sanjeev
> --
> 1.7.4.1
>
>
> Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
> 0115040-6. Kotipaikka: Helsinki
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 21+ messages in thread* RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
2011-07-13 17:49 ` Premi, Sanjeev
@ 2011-07-14 7:10 ` Tero Kristo
2011-07-14 8:46 ` Premi, Sanjeev
0 siblings, 1 reply; 21+ messages in thread
From: Tero Kristo @ 2011-07-14 7:10 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap, broonie, Girdwood, Liam, Hilman, Kevin
On Wed, 2011-07-13 at 19:49 +0200, Premi, Sanjeev wrote:
> >
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
-----Original Message-----
> > From: linux-omap-owner@vger.kernel.org
> > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kristo, Tero
> > Sent: Wednesday, July 13, 2011 7:31 PM
> > To: linux-omap@vger.kernel.org
> > Cc: broonie@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin
> > Subject: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
> >
> > Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can
> > run at 720MHz.
> >
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > ---
> > arch/arm/mach-omap2/board-omap3beagle.c | 32
> > +++++++++++++++++++++++++++++++
> > arch/arm/mach-omap2/opp3xxx_data.c | 4 +++
> > 2 files changed, 36 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> > b/arch/arm/mach-omap2/board-omap3beagle.c
> > index d7ae648..5ab507d 100644
> > --- a/arch/arm/mach-omap2/board-omap3beagle.c
> > +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> > @@ -592,6 +592,38 @@ static void __init beagle_opp_init(void)
> > return;
> > }
> >
> > + /* Custom OPP enabled for C4 */
> > + if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
> > + struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
> > + struct omap_hwmod *dh = omap_hwmod_lookup("iva");
> > + struct device *dev;
> > +
> > + if (!mh || !dh) {
> > + pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
> > + __func__, mh, dh);
> > + }
> > + /* Enable MPU 720MHz opp */
> > + dev = &mh->od->pdev.dev;
> > + r = opp_enable(dev, 720000000);
> > +
> > + /* Enable IVA 520MHz opp */
> > + dev = &dh->od->pdev.dev;
> > + r |= opp_enable(dev, 520000000);
> > +
> > + if (r) {
> > + pr_err("%s: failed to enable higher opp %d\n",
> > + __func__, r);
> > + /*
> > + * Cleanup - disable the higher freqs -
> > we dont care
> > + * about the results
> > + */
> > + dev = &mh->od->pdev.dev;
> > + opp_disable(dev, 720000000);
> > + dev = &dh->od->pdev.dev;
> > + opp_disable(dev, 520000000);
> > + }
> > + }
> > +
> > /* Custom OPP enabled for all xM versions */
> > if (cpu_is_omap3630()) {
> > struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
> > diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
> > b/arch/arm/mach-omap2/opp3xxx_data.c
> > index d95f3f9..a0f5fe1 100644
> > --- a/arch/arm/mach-omap2/opp3xxx_data.c
> > +++ b/arch/arm/mach-omap2/opp3xxx_data.c
> > @@ -98,6 +98,8 @@ static struct omap_opp_def __initdata
> > omap34xx_opp_def_list[] = {
> > OPP_INITIALIZER("mpu", true, 550000000,
> > OMAP3430_VDD_MPU_OPP4_UV),
> > /* MPU OPP5 */
> > OPP_INITIALIZER("mpu", true, 600000000,
> > OMAP3430_VDD_MPU_OPP5_UV),
> > + /* MPU OPP6 : omap3530 high speed grade only */
> > + OPP_INITIALIZER("mpu", false, 720000000,
> > OMAP3430_VDD_MPU_OPP5_UV),
> >
> > /*
> > * L3 OPP1 - 41.5 MHz is disabled because: The voltage
> > for that OPP is
> > @@ -123,6 +125,8 @@ static struct omap_opp_def __initdata
> > omap34xx_opp_def_list[] = {
> > OPP_INITIALIZER("iva", true, 400000000,
> > OMAP3430_VDD_MPU_OPP4_UV),
> > /* DSP OPP5 */
> > OPP_INITIALIZER("iva", true, 430000000,
> > OMAP3430_VDD_MPU_OPP5_UV),
> > + /* DSP OPP6 : omap3530 high speed grade only */
> > + OPP_INITIALIZER("iva", false, 520000000,
> > OMAP3430_VDD_MPU_OPP5_UV),
> > };
> >
> > static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
>
> [sp] Basic support for 720MHz was already closed early this year.
> See: http://marc.info/?l=linux-omap&m=129735630928696&w=2
>
> I cannot check the current tree status right now; but I assume
> the patch should already be in.
>
Yea, I heard this was agreed upon, however it is not in the tree yet.
Thus I just added this patch in the set for testing purposes... and
tagged as TEMP.
> ~sanjeev
>
> > --
> > 1.7.4.1
> >
> >
> > Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
> > 0115040-6. Kotipaikka: Helsinki
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 21+ messages in thread* RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
2011-07-14 7:10 ` Tero Kristo
@ 2011-07-14 8:46 ` Premi, Sanjeev
0 siblings, 0 replies; 21+ messages in thread
From: Premi, Sanjeev @ 2011-07-14 8:46 UTC (permalink / raw)
To: Kristo, Tero; +Cc: linux-omap, broonie, Girdwood, Liam, Hilman, Kevin
> -----Original Message-----
> From: Kristo, Tero
> Sent: Thursday, July 14, 2011 12:41 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org;
> broonie@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin
> Subject: RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
>
> On Wed, 2011-07-13 at 19:49 +0200, Premi, Sanjeev wrote:
> > >
> Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
> 0115040-6. Kotipaikka: Helsinki
>
> -----Original Message-----
>
> > > From: linux-omap-owner@vger.kernel.org
> > > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
> Kristo, Tero
> > > Sent: Wednesday, July 13, 2011 7:31 PM
> > > To: linux-omap@vger.kernel.org
> > > Cc: broonie@opensource.wolfsonmicro.com; Girdwood, Liam;
> Hilman, Kevin
> > > Subject: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
> > >
> > > Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can
> > > run at 720MHz.
> > >
> > > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > > ---
[snip]...[snip]
> >
> > [sp] Basic support for 720MHz was already closed early this year.
> > See: http://marc.info/?l=linux-omap&m=129735630928696&w=2
> >
> > I cannot check the current tree status right now; but I assume
> > the patch should already be in.
> >
>
> Yea, I heard this was agreed upon, however it is not in the tree yet.
> Thus I just added this patch in the set for testing purposes... and
> tagged as TEMP.
I noticed this today morning. Will be reposting it today after rebase.
~sanjeev
>
> > ~sanjeev
> >
> > > --
> > > 1.7.4.1
> > >
> > >
> > > Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
> > > 0115040-6. Kotipaikka: Helsinki
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
> > > linux-omap" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCHv2 5/5] omap: voltage: changed parameter of omap_voltage_lookup to const
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
` (3 preceding siblings ...)
2011-07-13 14:00 ` [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6 Tero Kristo
@ 2011-07-13 14:00 ` Tero Kristo
2011-07-13 19:00 ` [PATCHv2 0/5] OMAP SMPS regulator driver Kevin Hilman
` (2 subsequent siblings)
7 siblings, 0 replies; 21+ messages in thread
From: Tero Kristo @ 2011-07-13 14:00 UTC (permalink / raw)
To: linux-omap; +Cc: broonie, lrg, khilman
This fixes a couple of compilation warnings with OMAP SMPS regulator
driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/voltage.c | 2 +-
arch/arm/plat-omap/include/plat/voltage.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 7e3c512..832fa7a 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -1036,7 +1036,7 @@ void omap_change_voltscale_method(struct voltagedomain *voltdm,
* a pointer to the voltage domain structure corresponding to the
* VDD<name>. Else retuns error pointer.
*/
-struct voltagedomain *omap_voltage_domain_lookup(char *name)
+struct voltagedomain *omap_voltage_domain_lookup(const char *name)
{
int i;
diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
index 46573bf..76d314c 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -159,7 +159,7 @@ int omap_voltage_register_pmic(struct voltagedomain *voltdm,
void omap_change_voltscale_method(struct voltagedomain *voltdm,
int voltscale_method);
/* API to get the voltagedomain pointer */
-struct voltagedomain *omap_voltage_domain_lookup(char *name);
+struct voltagedomain *omap_voltage_domain_lookup(const char *name);
int omap_voltage_late_init(void);
#else
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCHv2 0/5] OMAP SMPS regulator driver
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
` (4 preceding siblings ...)
2011-07-13 14:00 ` [PATCHv2 5/5] omap: voltage: changed parameter of omap_voltage_lookup to const Tero Kristo
@ 2011-07-13 19:00 ` Kevin Hilman
2011-07-13 23:22 ` Mark Brown
2011-07-14 0:22 ` Kevin Hilman
2011-07-18 8:19 ` Tony Lindgren
7 siblings, 1 reply; 21+ messages in thread
From: Kevin Hilman @ 2011-07-13 19:00 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-omap, broonie, lrg, Paul Walmsley
+Paul
Tero Kristo <t-kristo@ti.com> writes:
> Based on the comments for the previous version of this set, I implemented
> a regulator driver for the OMAP SMPS now. It could actually be moved under
> arch/arm/mach-omap2/ directory instead of drivers/regulator, I think it
> should work from there also. This would also require less hacking for the
> header files. Any thoughts on this?
Actually, I'd prefer it stay in drivers/regulator. We're trying to move
driver-type stuff out of arch/arm/* into the right place in drivers/*.
In fact, I wonder if our VP/VC layers might better live under
drivers/regulator also.
I'd appreciate any input from Mark/Liam on how to organize things.
For some background, see Figures 3-75 and 3-76 in the OMAP4430 Public
TRM[1]. The SMPSs are physically on an external PMIC, but all the
control is typically done via on-chip resources: voltage processor (VP),
voltage controller (VC). There's also an optional SmartReflex (SR)
block involved which can drive the VP. I'm not as familiar with other
non-OMAP SoCs, but I don't imagine this is unique to OMAP.
Currently, we have separate drivers for VC, VP and SR in
arch/arm/mach-omap2. In mainline, these are currently more like
libraries than drivers and are a bit hackish and interwoven with each
other. We're currently separating these out into separate VC, VP and SR
layers[2], and I'm wondering exactly how we should structure this, and
where they should live under drivers/*.
What Paul and I have discussed so far is that SR should just be
implemented as a sensor under hwmod. For VC/VP, I think it makes the
most sense that these be part of drivers/regulator someplace. In this
series, the proposed driver is just small shell that calls the VP
functions.
Mark/Liam, are you OK with having some "helper" libraries in
drivers/regulator? I'm thinking specifically of our VC/VP layers (see
arch/arm/mach-omap2/vc*.c and vp*.c here in my pm-wip/voltdm branch[2].)
So far, I'm just brainstorming on how to cleanup/restructure this stuff,
so any advice from you guys would be appreciated.
Thanks,
Kevin
[1] http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vU.zip
[2] latest are in pm-wip/voltdm branch of my git tree
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCHv2 0/5] OMAP SMPS regulator driver
2011-07-13 19:00 ` [PATCHv2 0/5] OMAP SMPS regulator driver Kevin Hilman
@ 2011-07-13 23:22 ` Mark Brown
2011-07-13 23:51 ` Kevin Hilman
0 siblings, 1 reply; 21+ messages in thread
From: Mark Brown @ 2011-07-13 23:22 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Tero Kristo, linux-omap, lrg, Paul Walmsley
On Wed, Jul 13, 2011 at 12:00:37PM -0700, Kevin Hilman wrote:
> Actually, I'd prefer it stay in drivers/regulator. We're trying to move
> driver-type stuff out of arch/arm/* into the right place in drivers/*.
> In fact, I wonder if our VP/VC layers might better live under
> drivers/regulator also.
Well, if they don't look hideous in the API then sure. I'd guess it's
probably a case of lifting the implementation APIs that Tero's driver is
calling up into the regulator driver he's writing.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] OMAP SMPS regulator driver
2011-07-13 23:22 ` Mark Brown
@ 2011-07-13 23:51 ` Kevin Hilman
0 siblings, 0 replies; 21+ messages in thread
From: Kevin Hilman @ 2011-07-13 23:51 UTC (permalink / raw)
To: Mark Brown; +Cc: Tero Kristo, linux-omap, lrg, Paul Walmsley
Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> On Wed, Jul 13, 2011 at 12:00:37PM -0700, Kevin Hilman wrote:
>
>> Actually, I'd prefer it stay in drivers/regulator. We're trying to move
>> driver-type stuff out of arch/arm/* into the right place in drivers/*.
>> In fact, I wonder if our VP/VC layers might better live under
>> drivers/regulator also.
>
> Well, if they don't look hideous in the API then sure. I'd guess it's
> probably a case of lifting the implementation APIs that Tero's driver is
> calling up into the regulator driver he's writing.
Basically, yes. But it also would mean dragging the rest of the VC/VP
APIs along as well.
I'll work in this direction and hopefully have some better RFC type code
to show soonish.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] OMAP SMPS regulator driver
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
` (5 preceding siblings ...)
2011-07-13 19:00 ` [PATCHv2 0/5] OMAP SMPS regulator driver Kevin Hilman
@ 2011-07-14 0:22 ` Kevin Hilman
2011-07-14 7:24 ` Tero Kristo
2011-07-18 8:19 ` Tony Lindgren
7 siblings, 1 reply; 21+ messages in thread
From: Kevin Hilman @ 2011-07-14 0:22 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-omap, broonie, lrg
Hi Tero,
Tero Kristo <t-kristo@ti.com> writes:
> Based on the comments for the previous version of this set, I implemented
> a regulator driver for the OMAP SMPS now.
Could you rebase this on my pm-wip/voltdm branch where I've started the
work to separate out the VC/VP layers into their own files.
I've just rebased that branch on top of current l-o master, so it also
includes all the PRCM core code changes queued for v3.1.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCHv2 0/5] OMAP SMPS regulator driver
2011-07-14 0:22 ` Kevin Hilman
@ 2011-07-14 7:24 ` Tero Kristo
0 siblings, 0 replies; 21+ messages in thread
From: Tero Kristo @ 2011-07-14 7:24 UTC (permalink / raw)
To: Hilman, Kevin; +Cc: linux-omap, broonie, Girdwood, Liam
On Thu, 2011-07-14 at 02:22 +0200, Hilman, Kevin wrote:
> Hi Tero,
>
> Tero Kristo <t-kristo@ti.com> writes:
>
> > Based on the comments for the previous version of this set, I implemented
> > a regulator driver for the OMAP SMPS now.
>
> Could you rebase this on my pm-wip/voltdm branch where I've started the
> work to separate out the VC/VP layers into their own files.
>
I'll do this for next version.
> I've just rebased that branch on top of current l-o master, so it also
> includes all the PRCM core code changes queued for v3.1.
>
> Thanks,
>
> Kevin
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] OMAP SMPS regulator driver
2011-07-13 14:00 [PATCHv2 0/5] OMAP SMPS regulator driver Tero Kristo
` (6 preceding siblings ...)
2011-07-14 0:22 ` Kevin Hilman
@ 2011-07-18 8:19 ` Tony Lindgren
7 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2011-07-18 8:19 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-omap, broonie, lrg, khilman
* Tero Kristo <t-kristo@ti.com> [110713 06:56]:
> Hello,
>
> Based on the comments for the previous version of this set, I implemented
> a regulator driver for the OMAP SMPS now. It could actually be moved under
> arch/arm/mach-omap2/ directory instead of drivers/regulator, I think it
> should work from there also. This would also require less hacking for the
> header files. Any thoughts on this?
If it's a driver it should be under drivers/ then.
Tony
^ permalink raw reply [flat|nested] 21+ messages in thread