[PM-WIP/voltdm_c][PATCH 00/11] OMAP4: Fixes for voltage scale

[PM-WIP/voltdm_c][PATCH 00/11] OMAP4: Fixes for voltage scale

[Nishanth Menon]

Hi,
The following patches are on top of:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch: pm-wip/voltdm_c

This contains a set of misc fixes and cleanups necessary for voltage scale
to function.

Tested on: SDP4430

Nishanth Menon (9):
  OMAP3+: PM: SR: fix debugfs
  OMAP3+: PM: voltage: add required debugfs interfaces
  OMAP3+: PM: VP: fix vstepmax
  OMAP4: PM: VC: support configuration of i2c clks
  OMAP4: PM: VC: fix highspeed i2c for SR
  OMAP4: PM: VC: fix channel bit offset for MPU
  OMAP4: PM: TWL6030: fix uv to voltage for >0x39
  OMAP4: PM: TWL6030: address 0V conversions
  OMAP4: PM: TWL6030: add cmd register

Patrick Titiano (2):
  OMAP4: PM: TWL6030: fix voltage conversion formula
  OMAP4: PM: TWL6030: fix ON/RET/OFF voltages

 arch/arm/mach-omap2/omap_twl.c         |   68 ++++++++++++++++++++++---------
 arch/arm/mach-omap2/prm-regbits-44xx.h |    8 ++++
 arch/arm/mach-omap2/smartreflex.c      |   21 +++++++++-
 arch/arm/mach-omap2/vc.c               |   55 +++++++++++++++----------
 arch/arm/mach-omap2/vc.h               |   37 ++++++++++++++++-
 arch/arm/mach-omap2/vc3xxx_data.c      |    2 +-
 arch/arm/mach-omap2/vc44xx_data.c      |   12 +++++-
 arch/arm/mach-omap2/voltage.c          |   66 +++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/voltage.h          |    9 ++++
 arch/arm/mach-omap2/vp.c               |    2 +-
 10 files changed, 232 insertions(+), 48 deletions(-)

Regards,
Nishanth Menon

[PM-WIP/voltdm_c][PATCH 01/11] OMAP3+: PM: SR: fix debugfs

[Nishanth Menon]

Kevin's patch:
OMAP3+: voltage: remove unneeded debugfs interface

broke SR autocomp enablement - autocomps for all domains are
created now in debugfs/smartreflex instead of debugfs/smartreflex/domain
causing SR not to work.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/smartreflex.c |   21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index b100661..372b935 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -62,6 +62,7 @@ static LIST_HEAD(sr_list);
 
 static struct omap_sr_class_data *sr_class;
 static struct omap_sr_pmic_data *sr_pmic_data;
+static struct dentry		*sr_dbg_dir;
 
 static inline void sr_write_reg(struct omap_sr *sr, unsigned offset, u32 value)
 {
@@ -829,6 +830,7 @@ static int __init omap_sr_probe(struct platform_device *pdev)
 	struct dentry *nvalue_dir;
 	struct omap_volt_data *volt_data;
 	int i, ret = 0;
+	char *name;
 
 	if (!sr_info) {
 		dev_err(&pdev->dev, "%s: unable to allocate sr_info\n",
@@ -898,8 +900,25 @@ static int __init omap_sr_probe(struct platform_device *pdev)
 	}
 
 	dev_info(&pdev->dev, "%s: SmartReflex driver initialized\n", __func__);
+	if (!sr_dbg_dir) {
+		sr_dbg_dir = debugfs_create_dir("smartreflex", NULL);
+		if (!sr_dbg_dir) {
+			ret = PTR_ERR(sr_dbg_dir);
+			pr_err("%s:sr debugfs dir creation failed(%d)\n",
+				__func__, ret);
+			goto err_iounmap;
+		}
+	}
 
-	sr_info->dbg_dir = debugfs_create_dir("smartreflex", NULL);
+	name = kasprintf(GFP_KERNEL, "sr_%s", sr_info->voltdm->name);
+	if (!name) {
+		dev_err(&pdev->dev, "%s: Unable to alloc debugfs name\n",
+			__func__);
+		ret = -ENOMEM;
+		goto err_iounmap;
+	}
+	sr_info->dbg_dir = debugfs_create_dir(name, sr_dbg_dir);
+	kfree(name);
 	if (IS_ERR(sr_info->dbg_dir)) {
 		dev_err(&pdev->dev, "%s: Unable to create debugfs directory\n",
 			__func__);
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 01/11] OMAP3+: PM: SR: fix debugfs

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Kevin's patch:
> OMAP3+: voltage: remove unneeded debugfs interface
>
> broke SR autocomp enablement - autocomps for all domains are
> created now in debugfs/smartreflex instead of debugfs/smartreflex/domain
> causing SR not to work.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>

Thanks, will add to voltdm work, probably folding it into the original
patch.

Kevin

[PM-WIP/voltdm_c][PATCH 02/11] OMAP3+: PM: voltage: add required debugfs interfaces

[Nishanth Menon]

Kevin's patch:
OMAP3+: voltage: remove unneeded debugfs interface

removed ability to check the voltages in the domains.
This puts a crunch on validation we can do, hence we
re-introduce them back in

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/voltage.c |   66 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/voltage.h |    1 +
 2 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 890ce39..ab5cbbd 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -282,6 +282,65 @@ void omap_change_voltscale_method(struct voltagedomain *voltdm,
 	}
 }
 
+/* Voltage debugfs support */
+static int vp_volt_debug_get(void *data, u64 *val)
+{
+	struct voltagedomain *voltdm = (struct voltagedomain *)data;
+
+	if (!voltdm) {
+		pr_warning("Wrong paramater passed\n");
+		return -EINVAL;
+	}
+	*val = omap_vp_get_curr_volt(voltdm);
+
+	return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(vp_volt_debug_fops, vp_volt_debug_get, NULL, "%llu\n");
+
+static int nom_volt_debug_get(void *data, u64 *val)
+{
+	struct voltagedomain *voltdm = (struct voltagedomain *) data;
+
+	if (!voltdm) {
+		pr_warning("Wrong paramater passed\n");
+		return -EINVAL;
+	}
+
+	*val = omap_voltage_get_nom_volt(voltdm);
+
+	return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(nom_volt_debug_fops, nom_volt_debug_get, NULL,
+								"%llu\n");
+
+static void __init voltdm_debugfs_init(struct dentry *voltage_dir,
+					struct voltagedomain *voltdm)
+{
+	char *name;
+
+	name = kasprintf(GFP_KERNEL, "vdd_%s", voltdm->name);
+	if (!name) {
+		pr_warning("%s:vdd_%s: no mem for debugfs\n", __func__,
+				voltdm->name);
+		return;
+	}
+
+	voltdm->debug_dir = debugfs_create_dir(name, voltage_dir);
+	kfree(name);
+	if (IS_ERR_OR_NULL(voltdm->debug_dir)) {
+		pr_warning("%s: Unable to create debugfs directory for"
+			" vdd_%s\n", __func__, voltdm->name);
+		voltdm->debug_dir = NULL;
+		return;
+	}
+
+	(void) debugfs_create_file("curr_vp_volt", S_IRUGO, voltdm->debug_dir,
+				(void *) voltdm, &vp_volt_debug_fops);
+	(void) debugfs_create_file("curr_nominal_volt", S_IRUGO,
+				voltdm->debug_dir, (void *) voltdm,
+				&nom_volt_debug_fops);
+}
+
 /**
  * omap_voltage_late_init() - Init the various voltage parameters
  *
@@ -292,6 +351,7 @@ void omap_change_voltscale_method(struct voltagedomain *voltdm,
 int __init omap_voltage_late_init(void)
 {
 	struct voltagedomain *voltdm;
+	struct dentry *voltage_dir;
 
 	if (list_empty(&voltdm_list)) {
 		pr_err("%s: Voltage driver support not added\n",
@@ -299,6 +359,8 @@ int __init omap_voltage_late_init(void)
 		return -EINVAL;
 	}
 
+	voltage_dir = debugfs_create_dir("voltage", NULL);
+
 	list_for_each_entry(voltdm, &voltdm_list, node) {
 		if (!voltdm->scalable)
 			continue;
@@ -311,6 +373,10 @@ int __init omap_voltage_late_init(void)
 
 		if (voltdm->vc)
 			omap_vc_init_channel(voltdm);
+
+		if (voltage_dir)
+			voltdm_debugfs_init(voltage_dir, voltdm);
+
 	}
 
 	return 0;
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index f079167..2f7b268 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -88,6 +88,7 @@ struct voltagedomain {
 	u32 curr_volt;
 
 	struct omap_vdd_info *vdd;
+	struct dentry *debug_dir;
 };
 
 /**
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 02/11] OMAP3+: PM: voltage: add required debugfs interfaces

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [110518 08:13]:
> Kevin's patch:
> OMAP3+: voltage: remove unneeded debugfs interface
> 
> removed ability to check the voltages in the domains.
> This puts a crunch on validation we can do, hence we
> re-introduce them back in
 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  arch/arm/mach-omap2/voltage.c |   66 +++++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/voltage.h |    1 +
>  2 files changed, 67 insertions(+), 0 deletions(-)

Hmm, this seems to be adding the debug code instead?

Tony

Re: [PM-WIP/voltdm_c][PATCH 02/11] OMAP3+: PM: voltage: add required debugfs interfaces

[Menon, Nishanth]

On Wed, May 18, 2011 at 02:59, Tony Lindgren <tony@atomide.com> wrote:
> * Nishanth Menon <nm@ti.com> [110518 08:13]:
>> Kevin's patch:
>> OMAP3+: voltage: remove unneeded debugfs interface
>>
>> removed ability to check the voltages in the domains.
>> This puts a crunch on validation we can do, hence we
>> re-introduce them back in
>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>>  arch/arm/mach-omap2/voltage.c |   66 +++++++++++++++++++++++++++++++++++++++++
>>  arch/arm/mach-omap2/voltage.h |    1 +
>>  2 files changed, 67 insertions(+), 0 deletions(-)
>
> Hmm, this seems to be adding the debug code instead?

Yes, we need some interface to know what the current voltages are for
each of the domain when verifying if dvfs is actually scaling voltage
or not. the other option is to use omapconf (not yet public and only
supports OMAP4) to see what the voltages are. Though omapconf is an
option, it shows what it's computation of voltage from vsel is, not
what the kernel internally thinks (vsel_uv functions) it is.

Regards,
Nishanth Menon
--
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

Re: [PM-WIP/voltdm_c][PATCH 02/11] OMAP3+: PM: voltage: add required debugfs interfaces

[Tony Lindgren]

* Menon, Nishanth <nm@ti.com> [110518 11:03]:
> On Wed, May 18, 2011 at 02:59, Tony Lindgren <tony@atomide.com> wrote:
> > * Nishanth Menon <nm@ti.com> [110518 08:13]:
> >> Kevin's patch:
> >> OMAP3+: voltage: remove unneeded debugfs interface
> >>
> >> removed ability to check the voltages in the domains.
> >> This puts a crunch on validation we can do, hence we
> >> re-introduce them back in
> >
> >> Signed-off-by: Nishanth Menon <nm@ti.com>
> >> ---
> >>  arch/arm/mach-omap2/voltage.c |   66 +++++++++++++++++++++++++++++++++++++++++
> >>  arch/arm/mach-omap2/voltage.h |    1 +
> >>  2 files changed, 67 insertions(+), 0 deletions(-)
> >
> > Hmm, this seems to be adding the debug code instead?
> 
> Yes, we need some interface to know what the current voltages are for
> each of the domain when verifying if dvfs is actually scaling voltage
> or not. the other option is to use omapconf (not yet public and only
> supports OMAP4) to see what the voltages are. Though omapconf is an
> option, it shows what it's computation of voltage from vsel is, not
> what the kernel internally thinks (vsel_uv functions) it is.

I guess I just got confused reading the patch description..

Tony
--
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

Re: [PM-WIP/voltdm_c][PATCH 02/11] OMAP3+: PM: voltage: add required debugfs interfaces

[Menon, Nishanth]

On Wed, May 18, 2011 at 03:34, Tony Lindgren <tony@atomide.com> wrote:
> * Menon, Nishanth <nm@ti.com> [110518 11:03]:
>> On Wed, May 18, 2011 at 02:59, Tony Lindgren <tony@atomide.com> wrote:
>> > * Nishanth Menon <nm@ti.com> [110518 08:13]:
>> >> Kevin's patch:
>> >> OMAP3+: voltage: remove unneeded debugfs interface
>> >>
>> >> removed ability to check the voltages in the domains.
>> >> This puts a crunch on validation we can do, hence we
>> >> re-introduce them back in
>> >
>> >> Signed-off-by: Nishanth Menon <nm@ti.com>
>> >> ---
>> >>  arch/arm/mach-omap2/voltage.c |   66 +++++++++++++++++++++++++++++++++++++++++
>> >>  arch/arm/mach-omap2/voltage.h |    1 +
>> >>  2 files changed, 67 insertions(+), 0 deletions(-)
>> >
>> > Hmm, this seems to be adding the debug code instead?
>>
>> Yes, we need some interface to know what the current voltages are for
>> each of the domain when verifying if dvfs is actually scaling voltage
>> or not. the other option is to use omapconf (not yet public and only
>> supports OMAP4) to see what the voltages are. Though omapconf is an
>> option, it shows what it's computation of voltage from vsel is, not
>> what the kernel internally thinks (vsel_uv functions) it is.
>
> I guess I just got confused reading the patch description..

sorry - will fix it up for v3 after waiting for further comments - and
if Sanjeev is ok, will wrap it up under #ifdefs for DEBUG_FS as well
to prevent !DEBUGFS builds..

Regards,
Nishanth Menon
--
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

Re: [PM-WIP/voltdm_c][PATCH 02/11] OMAP3+: PM: voltage: add required debugfs interfaces

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Kevin's patch:
> OMAP3+: voltage: remove unneeded debugfs interface
>
> removed ability to check the voltages in the domains.
> This puts a crunch on validation we can do, hence we
> re-introduce them back in
>
> Signed-off-by: Nishanth Menon <nm@ti.com>

NAK.

I don't want any OMAP specific debugfs interface for this.  The voltage
domains will be represented by regulators (when I finish this
cleanup/restructure), and we will use the regulator framework for
interfacing to the voltages.

If you need a temporary debugfs interface for this, then I suggest you 
revert my original patch in your internal tree, or keep $SUBJECT patch
as an internal patch.

Kevin

Re: [PM-WIP/voltdm_c][PATCH 02/11] OMAP3+: PM: voltage: add required debugfs interfaces

[Menon, Nishanth]

On Wed, May 18, 2011 at 03:44, Kevin Hilman <khilman@ti.com> wrote:
> Nishanth Menon <nm@ti.com> writes:
>
>> Kevin's patch:
>> OMAP3+: voltage: remove unneeded debugfs interface
>>
>> removed ability to check the voltages in the domains.
>> This puts a crunch on validation we can do, hence we
>> re-introduce them back in
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>
> NAK.
>
> I don't want any OMAP specific debugfs interface for this.  The voltage
> domains will be represented by regulators (when I finish this
> cleanup/restructure), and we will use the regulator framework for
> interfacing to the voltages.
>
> If you need a temporary debugfs interface for this, then I suggest you
> revert my original patch in your internal tree, or keep $SUBJECT patch
> as an internal patch.

Regulators are the right approach. dropping this patch.

Regards,
Nishanth Menon
--
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

[PM-WIP/voltdm_c][PATCH 03/11] OMAP3+: PM: VP: fix vstepmax

[Nishanth Menon]

Kevin's
OMAP3+: VP: remove omap_vp_runtime_data

has a typo to fix which causes waittime to be populated for stepmax.
this is flawed.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/vp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 6336ba6..e7d38f6 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -87,7 +87,7 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
 	voltdm->write(val, vp->vstepmin);
 
 	/* VSTEPMAX */
-	val = (waittime << vp->common->vstepmax_stepmax_shift) |
+	val = (vstepmax << vp->common->vstepmax_stepmax_shift) |
 		(waittime << vp->common->vstepmax_smpswaittimemax_shift);
 	voltdm->write(val, vp->vstepmax);
 
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 03/11] OMAP3+: PM: VP: fix vstepmax

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Kevin's
> OMAP3+: VP: remove omap_vp_runtime_data
>
> has a typo to fix which causes waittime to be populated for stepmax.
> this is flawed.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>

Adding to voltdm queue, will fold into original patch.

Thanks for testing/finding/fixing!

Kevin

> ---
>  arch/arm/mach-omap2/vp.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 6336ba6..e7d38f6 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -87,7 +87,7 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
>  	voltdm->write(val, vp->vstepmin);
>  
>  	/* VSTEPMAX */
> -	val = (waittime << vp->common->vstepmax_stepmax_shift) |
> +	val = (vstepmax << vp->common->vstepmax_stepmax_shift) |
>  		(waittime << vp->common->vstepmax_smpswaittimemax_shift);
>  	voltdm->write(val, vp->vstepmax);

[PM-WIP/voltdm_c][PATCH 04/11] OMAP4: PM: VC: support configuration of i2c clks

[Nishanth Menon]

Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated layer"
splits out the hardcoded value in the code to vc's channel init.

This patch further isolates the configuration to remove out PMIC specific
configuration as high and low times are pmic specific.

Values are updated as well based on latest TI analysis done in android k35
kernel.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
note: Generates two over 80 char warnings, left as is for maintaining
code continuity.
WARNING: line over 80 characters
#71: FILE: arch/arm/mach-omap2/prm-regbits-44xx.h:1068:
+#define OMAP4430_HSCLH_MASK						(0xff << 16)
	WARNING: line over 80 characters
#75: FILE: arch/arm/mach-omap2/prm-regbits-44xx.h:1072:
	+#define OMAP4430_HSCLL_MASK						(0xff << 24)

 arch/arm/mach-omap2/omap_twl.c         |   13 +++++++++++++
 arch/arm/mach-omap2/prm-regbits-44xx.h |    8 ++++++++
 arch/arm/mach-omap2/vc.c               |   16 ++++++++++++----
 arch/arm/mach-omap2/voltage.h          |    8 ++++++++
 4 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 30f4323..82a91be 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -202,6 +202,10 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
 	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
 	.volt_reg_addr		= OMAP4_VDD_MPU_SR_VOLT_REG,
 	.i2c_high_speed		= true,
+	.i2c_scll_low		= 0x28,
+	.i2c_scll_high		= 0x2C,
+	.i2c_hscll_low		= 0x0B,
+	.i2c_hscll_high		= 0x00,
 	.vsel_to_uv		= twl6030_vsel_to_uv,
 	.uv_to_vsel		= twl6030_uv_to_vsel,
 };
@@ -223,6 +227,10 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
 	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
 	.volt_reg_addr		= OMAP4_VDD_IVA_SR_VOLT_REG,
 	.i2c_high_speed		= true,
+	.i2c_scll_low		= 0x28,
+	.i2c_scll_high		= 0x2C,
+	.i2c_hscll_low		= 0x0B,
+	.i2c_hscll_high		= 0x00,
 	.vsel_to_uv		= twl6030_vsel_to_uv,
 	.uv_to_vsel		= twl6030_uv_to_vsel,
 };
@@ -242,6 +250,11 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
 	.vp_vddmax		= OMAP4_VP_CORE_VLIMITTO_VDDMAX,
 	.vp_timeout_us		= OMAP4_VP_VLIMITTO_TIMEOUT_US,
 	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
+	.i2c_high_speed		= true,
+	.i2c_scll_low		= 0x28,
+	.i2c_scll_high		= 0x2C,
+	.i2c_hscll_low		= 0x0B,
+	.i2c_hscll_high		= 0x00,
 	.volt_reg_addr		= OMAP4_VDD_CORE_SR_VOLT_REG,
 	.vsel_to_uv		= twl6030_vsel_to_uv,
 	.uv_to_vsel		= twl6030_uv_to_vsel,
diff --git a/arch/arm/mach-omap2/prm-regbits-44xx.h b/arch/arm/mach-omap2/prm-regbits-44xx.h
index 6d2776f..32a5eb5 100644
--- a/arch/arm/mach-omap2/prm-regbits-44xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-44xx.h
@@ -1063,6 +1063,14 @@
 #define OMAP4430_SCLL_SHIFT						8
 #define OMAP4430_SCLL_MASK						(0xff << 8)
 
+/* Used by PRM_VC_CFG_I2C_CLK */
+#define OMAP4430_HSCLH_SHIFT						16
+#define OMAP4430_HSCLH_MASK						(0xff << 16)
+
+/* Used by PRM_VC_CFG_I2C_CLK */
+#define OMAP4430_HSCLL_SHIFT						24
+#define OMAP4430_HSCLL_MASK						(0xff << 24)
+
 /* Used by PRM_RSTST */
 #define OMAP4430_SECURE_WDT_RST_SHIFT					4
 #define OMAP4430_SECURE_WDT_RST_MASK					(1 << 4)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 8ca200d..79b9e86 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -191,14 +191,22 @@ static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
 static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
 {
 	static bool is_initialized;
-	u32 vc_val;
+	struct omap_voltdm_pmic *pmic = voltdm->pmic;
+	u32 vc_val = 0;
 
 	if (is_initialized)
 		return;
 
-	/* XXX These are magic numbers and do not belong! */
-	vc_val = (0x60 << OMAP4430_SCLL_SHIFT | 0x26 << OMAP4430_SCLH_SHIFT);
-	voltdm->write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET);
+	if (pmic->i2c_high_speed) {
+		vc_val |= pmic->i2c_hscll_low << OMAP4430_HSCLL_SHIFT;
+		vc_val |= pmic->i2c_hscll_high << OMAP4430_HSCLH_SHIFT;
+	}
+
+	vc_val |= pmic->i2c_scll_low << OMAP4430_SCLL_SHIFT;
+	vc_val |= pmic->i2c_scll_high << OMAP4430_SCLH_SHIFT;
+
+	if (vc_val)
+		voltdm->write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET);
 
 	is_initialized = true;
 }
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 2f7b268..3fe56e4 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -118,6 +118,10 @@ struct omap_volt_data {
  * @i2c_mcode: master code value for I2C high-speed preamble transmission
  * @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.
+ * @i2c_hscll_low: PMIC interface speed config for highspeed mode (T low)
+ * @i2c_hscll_high: PMIC interface speed config for highspeed mode (T high)
+ * @i2c_scll_low: PMIC interface speed config for fullspeed mode (T low)
+ * @i2c_scll_high: PMIC interface speed config for fullspeed mode (T high)
  */
 struct omap_voltdm_pmic {
 	int slew_rate;
@@ -137,6 +141,10 @@ struct omap_voltdm_pmic {
 	u8 volt_reg_addr;
 	u8 cmd_reg_addr;
 	bool i2c_high_speed;
+	u8 i2c_hscll_low;
+	u8 i2c_hscll_high;
+	u8 i2c_scll_low;
+	u8 i2c_scll_high;
 	u8 i2c_mcode;
 	unsigned long (*vsel_to_uv) (const u8 vsel);
 	u8 (*uv_to_vsel) (unsigned long uV);
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 04/11] OMAP4: PM: VC: support configuration of i2c clks

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated layer"
> splits out the hardcoded value in the code to vc's channel init.
>
> This patch further isolates the configuration to remove out PMIC specific
> configuration as high and low times are pmic specific.
>
> Values are updated as well based on latest TI analysis done in android k35
> kernel.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>

OK, this is a step in the right direction, but IIUC, these values are
sys_clk dependent right?  Shouldn't we be calculating these values based
on sys_clk?

Kevin

> ---
> note: Generates two over 80 char warnings, left as is for maintaining
> code continuity.
> WARNING: line over 80 characters
> #71: FILE: arch/arm/mach-omap2/prm-regbits-44xx.h:1068:
> +#define OMAP4430_HSCLH_MASK						(0xff << 16)
> 	WARNING: line over 80 characters
> #75: FILE: arch/arm/mach-omap2/prm-regbits-44xx.h:1072:
> 	+#define OMAP4430_HSCLL_MASK						(0xff << 24)
>
>  arch/arm/mach-omap2/omap_twl.c         |   13 +++++++++++++
>  arch/arm/mach-omap2/prm-regbits-44xx.h |    8 ++++++++
>  arch/arm/mach-omap2/vc.c               |   16 ++++++++++++----
>  arch/arm/mach-omap2/voltage.h          |    8 ++++++++
>  4 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 30f4323..82a91be 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -202,6 +202,10 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
>  	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
>  	.volt_reg_addr		= OMAP4_VDD_MPU_SR_VOLT_REG,
>  	.i2c_high_speed		= true,
> +	.i2c_scll_low		= 0x28,
> +	.i2c_scll_high		= 0x2C,
> +	.i2c_hscll_low		= 0x0B,
> +	.i2c_hscll_high		= 0x00,
>  	.vsel_to_uv		= twl6030_vsel_to_uv,
>  	.uv_to_vsel		= twl6030_uv_to_vsel,
>  };
> @@ -223,6 +227,10 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
>  	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
>  	.volt_reg_addr		= OMAP4_VDD_IVA_SR_VOLT_REG,
>  	.i2c_high_speed		= true,
> +	.i2c_scll_low		= 0x28,
> +	.i2c_scll_high		= 0x2C,
> +	.i2c_hscll_low		= 0x0B,
> +	.i2c_hscll_high		= 0x00,
>  	.vsel_to_uv		= twl6030_vsel_to_uv,
>  	.uv_to_vsel		= twl6030_uv_to_vsel,
>  };
> @@ -242,6 +250,11 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
>  	.vp_vddmax		= OMAP4_VP_CORE_VLIMITTO_VDDMAX,
>  	.vp_timeout_us		= OMAP4_VP_VLIMITTO_TIMEOUT_US,
>  	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
> +	.i2c_high_speed		= true,
> +	.i2c_scll_low		= 0x28,
> +	.i2c_scll_high		= 0x2C,
> +	.i2c_hscll_low		= 0x0B,
> +	.i2c_hscll_high		= 0x00,
>  	.volt_reg_addr		= OMAP4_VDD_CORE_SR_VOLT_REG,
>  	.vsel_to_uv		= twl6030_vsel_to_uv,
>  	.uv_to_vsel		= twl6030_uv_to_vsel,
> diff --git a/arch/arm/mach-omap2/prm-regbits-44xx.h b/arch/arm/mach-omap2/prm-regbits-44xx.h
> index 6d2776f..32a5eb5 100644
> --- a/arch/arm/mach-omap2/prm-regbits-44xx.h
> +++ b/arch/arm/mach-omap2/prm-regbits-44xx.h
> @@ -1063,6 +1063,14 @@
>  #define OMAP4430_SCLL_SHIFT						8
>  #define OMAP4430_SCLL_MASK						(0xff << 8)
>  
> +/* Used by PRM_VC_CFG_I2C_CLK */
> +#define OMAP4430_HSCLH_SHIFT						16
> +#define OMAP4430_HSCLH_MASK						(0xff << 16)
> +
> +/* Used by PRM_VC_CFG_I2C_CLK */
> +#define OMAP4430_HSCLL_SHIFT						24
> +#define OMAP4430_HSCLL_MASK						(0xff << 24)
> +
>  /* Used by PRM_RSTST */
>  #define OMAP4430_SECURE_WDT_RST_SHIFT					4
>  #define OMAP4430_SECURE_WDT_RST_MASK					(1 << 4)
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 8ca200d..79b9e86 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -191,14 +191,22 @@ static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
>  static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
>  {
>  	static bool is_initialized;
> -	u32 vc_val;
> +	struct omap_voltdm_pmic *pmic = voltdm->pmic;
> +	u32 vc_val = 0;
>  
>  	if (is_initialized)
>  		return;
>  
> -	/* XXX These are magic numbers and do not belong! */
> -	vc_val = (0x60 << OMAP4430_SCLL_SHIFT | 0x26 << OMAP4430_SCLH_SHIFT);
> -	voltdm->write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET);
> +	if (pmic->i2c_high_speed) {
> +		vc_val |= pmic->i2c_hscll_low << OMAP4430_HSCLL_SHIFT;
> +		vc_val |= pmic->i2c_hscll_high << OMAP4430_HSCLH_SHIFT;
> +	}
> +
> +	vc_val |= pmic->i2c_scll_low << OMAP4430_SCLL_SHIFT;
> +	vc_val |= pmic->i2c_scll_high << OMAP4430_SCLH_SHIFT;
> +
> +	if (vc_val)
> +		voltdm->write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET);
>  
>  	is_initialized = true;
>  }
> diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
> index 2f7b268..3fe56e4 100644
> --- a/arch/arm/mach-omap2/voltage.h
> +++ b/arch/arm/mach-omap2/voltage.h
> @@ -118,6 +118,10 @@ struct omap_volt_data {
>   * @i2c_mcode: master code value for I2C high-speed preamble transmission
>   * @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.
> + * @i2c_hscll_low: PMIC interface speed config for highspeed mode (T low)
> + * @i2c_hscll_high: PMIC interface speed config for highspeed mode (T high)
> + * @i2c_scll_low: PMIC interface speed config for fullspeed mode (T low)
> + * @i2c_scll_high: PMIC interface speed config for fullspeed mode (T high)
>   */
>  struct omap_voltdm_pmic {
>  	int slew_rate;
> @@ -137,6 +141,10 @@ struct omap_voltdm_pmic {
>  	u8 volt_reg_addr;
>  	u8 cmd_reg_addr;
>  	bool i2c_high_speed;
> +	u8 i2c_hscll_low;
> +	u8 i2c_hscll_high;
> +	u8 i2c_scll_low;
> +	u8 i2c_scll_high;
>  	u8 i2c_mcode;
>  	unsigned long (*vsel_to_uv) (const u8 vsel);
>  	u8 (*uv_to_vsel) (unsigned long uV);

Re: [PM-WIP/voltdm_c][PATCH 04/11] OMAP4: PM: VC: support configuration of i2c clks

[Menon, Nishanth]

On Wed, May 18, 2011 at 03:53, Kevin Hilman <khilman@ti.com> wrote:
> Nishanth Menon <nm@ti.com> writes:
>
>> Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated layer"
>> splits out the hardcoded value in the code to vc's channel init.
>>
>> This patch further isolates the configuration to remove out PMIC specific
>> configuration as high and low times are pmic specific.
>>
>> Values are updated as well based on latest TI analysis done in android k35
>> kernel.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>
> OK, this is a step in the right direction, but IIUC, these values are
> sys_clk dependent right?  Shouldn't we be calculating these values based
> on sys_clk?
3 factors to my knowledge:
a) sr clk I believe(I need to grab the relevant internal doc to
verify) - factor of sysclk - > board based/in a way pmic based
b)  factor of board capacitance (similar to i2c bus)
c)  i2c bus capability of the PMIC itself.

hence based it off pmic data..

Regards,
Nishanth Menon


>
> Kevin
>
>> ---
>> note: Generates two over 80 char warnings, left as is for maintaining
>> code continuity.
>> WARNING: line over 80 characters
>> #71: FILE: arch/arm/mach-omap2/prm-regbits-44xx.h:1068:
>> +#define OMAP4430_HSCLH_MASK                                          (0xff << 16)
>>       WARNING: line over 80 characters
>> #75: FILE: arch/arm/mach-omap2/prm-regbits-44xx.h:1072:
>>       +#define OMAP4430_HSCLL_MASK                                            (0xff << 24)
>>
>>  arch/arm/mach-omap2/omap_twl.c         |   13 +++++++++++++
>>  arch/arm/mach-omap2/prm-regbits-44xx.h |    8 ++++++++
>>  arch/arm/mach-omap2/vc.c               |   16 ++++++++++++----
>>  arch/arm/mach-omap2/voltage.h          |    8 ++++++++
>>  4 files changed, 41 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
>> index 30f4323..82a91be 100644
>> --- a/arch/arm/mach-omap2/omap_twl.c
>> +++ b/arch/arm/mach-omap2/omap_twl.c
>> @@ -202,6 +202,10 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
>>       .i2c_slave_addr         = OMAP4_SRI2C_SLAVE_ADDR,
>>       .volt_reg_addr          = OMAP4_VDD_MPU_SR_VOLT_REG,
>>       .i2c_high_speed         = true,
>> +     .i2c_scll_low           = 0x28,
>> +     .i2c_scll_high          = 0x2C,
>> +     .i2c_hscll_low          = 0x0B,
>> +     .i2c_hscll_high         = 0x00,
>>       .vsel_to_uv             = twl6030_vsel_to_uv,
>>       .uv_to_vsel             = twl6030_uv_to_vsel,
>>  };
>> @@ -223,6 +227,10 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
>>       .i2c_slave_addr         = OMAP4_SRI2C_SLAVE_ADDR,
>>       .volt_reg_addr          = OMAP4_VDD_IVA_SR_VOLT_REG,
>>       .i2c_high_speed         = true,
>> +     .i2c_scll_low           = 0x28,
>> +     .i2c_scll_high          = 0x2C,
>> +     .i2c_hscll_low          = 0x0B,
>> +     .i2c_hscll_high         = 0x00,
>>       .vsel_to_uv             = twl6030_vsel_to_uv,
>>       .uv_to_vsel             = twl6030_uv_to_vsel,
>>  };
>> @@ -242,6 +250,11 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
>>       .vp_vddmax              = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
>>       .vp_timeout_us          = OMAP4_VP_VLIMITTO_TIMEOUT_US,
>>       .i2c_slave_addr         = OMAP4_SRI2C_SLAVE_ADDR,
>> +     .i2c_high_speed         = true,
>> +     .i2c_scll_low           = 0x28,
>> +     .i2c_scll_high          = 0x2C,
>> +     .i2c_hscll_low          = 0x0B,
>> +     .i2c_hscll_high         = 0x00,
>>       .volt_reg_addr          = OMAP4_VDD_CORE_SR_VOLT_REG,
>>       .vsel_to_uv             = twl6030_vsel_to_uv,
>>       .uv_to_vsel             = twl6030_uv_to_vsel,
>> diff --git a/arch/arm/mach-omap2/prm-regbits-44xx.h b/arch/arm/mach-omap2/prm-regbits-44xx.h
>> index 6d2776f..32a5eb5 100644
>> --- a/arch/arm/mach-omap2/prm-regbits-44xx.h
>> +++ b/arch/arm/mach-omap2/prm-regbits-44xx.h
>> @@ -1063,6 +1063,14 @@
>>  #define OMAP4430_SCLL_SHIFT                                          8
>>  #define OMAP4430_SCLL_MASK                                           (0xff << 8)
>>
>> +/* Used by PRM_VC_CFG_I2C_CLK */
>> +#define OMAP4430_HSCLH_SHIFT                                         16
>> +#define OMAP4430_HSCLH_MASK                                          (0xff << 16)
>> +
>> +/* Used by PRM_VC_CFG_I2C_CLK */
>> +#define OMAP4430_HSCLL_SHIFT                                         24
>> +#define OMAP4430_HSCLL_MASK                                          (0xff << 24)
>> +
>>  /* Used by PRM_RSTST */
>>  #define OMAP4430_SECURE_WDT_RST_SHIFT                                        4
>>  #define OMAP4430_SECURE_WDT_RST_MASK                                 (1 << 4)
>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
>> index 8ca200d..79b9e86 100644
>> --- a/arch/arm/mach-omap2/vc.c
>> +++ b/arch/arm/mach-omap2/vc.c
>> @@ -191,14 +191,22 @@ static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
>>  static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
>>  {
>>       static bool is_initialized;
>> -     u32 vc_val;
>> +     struct omap_voltdm_pmic *pmic = voltdm->pmic;
>> +     u32 vc_val = 0;
>>
>>       if (is_initialized)
>>               return;
>>
>> -     /* XXX These are magic numbers and do not belong! */
>> -     vc_val = (0x60 << OMAP4430_SCLL_SHIFT | 0x26 << OMAP4430_SCLH_SHIFT);
>> -     voltdm->write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET);
>> +     if (pmic->i2c_high_speed) {
>> +             vc_val |= pmic->i2c_hscll_low << OMAP4430_HSCLL_SHIFT;
>> +             vc_val |= pmic->i2c_hscll_high << OMAP4430_HSCLH_SHIFT;
>> +     }
>> +
>> +     vc_val |= pmic->i2c_scll_low << OMAP4430_SCLL_SHIFT;
>> +     vc_val |= pmic->i2c_scll_high << OMAP4430_SCLH_SHIFT;
>> +
>> +     if (vc_val)
>> +             voltdm->write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET);
>>
>>       is_initialized = true;
>>  }
>> diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
>> index 2f7b268..3fe56e4 100644
>> --- a/arch/arm/mach-omap2/voltage.h
>> +++ b/arch/arm/mach-omap2/voltage.h
>> @@ -118,6 +118,10 @@ struct omap_volt_data {
>>   * @i2c_mcode: master code value for I2C high-speed preamble transmission
>>   * @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.
>> + * @i2c_hscll_low: PMIC interface speed config for highspeed mode (T low)
>> + * @i2c_hscll_high: PMIC interface speed config for highspeed mode (T high)
>> + * @i2c_scll_low: PMIC interface speed config for fullspeed mode (T low)
>> + * @i2c_scll_high: PMIC interface speed config for fullspeed mode (T high)
>>   */
>>  struct omap_voltdm_pmic {
>>       int slew_rate;
>> @@ -137,6 +141,10 @@ struct omap_voltdm_pmic {
>>       u8 volt_reg_addr;
>>       u8 cmd_reg_addr;
>>       bool i2c_high_speed;
>> +     u8 i2c_hscll_low;
>> +     u8 i2c_hscll_high;
>> +     u8 i2c_scll_low;
>> +     u8 i2c_scll_high;
>>       u8 i2c_mcode;
>>       unsigned long (*vsel_to_uv) (const u8 vsel);
>>       u8 (*uv_to_vsel) (unsigned long uV);
>
--
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

Re: [PM-WIP/voltdm_c][PATCH 04/11] OMAP4: PM: VC: support configuration of i2c clks

[Kevin Hilman]

"Menon, Nishanth" <nm@ti.com> writes:

> On Wed, May 18, 2011 at 03:53, Kevin Hilman <khilman@ti.com> wrote:
>> Nishanth Menon <nm@ti.com> writes:
>>
>>> Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated layer"
>>> splits out the hardcoded value in the code to vc's channel init.
>>>
>>> This patch further isolates the configuration to remove out PMIC specific
>>> configuration as high and low times are pmic specific.
>>>
>>> Values are updated as well based on latest TI analysis done in android k35
>>> kernel.
>>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>
>> OK, this is a step in the right direction, but IIUC, these values are
>> sys_clk dependent right?  Shouldn't we be calculating these values based
>> on sys_clk?
> 3 factors to my knowledge:
> a) sr clk I believe(I need to grab the relevant internal doc to
> verify) - factor of sysclk - > board based/in a way pmic based
> b)  factor of board capacitance (similar to i2c bus)
> c)  i2c bus capability of the PMIC itself.
>
> hence based it off pmic data..

These are hard-coded constants, that are calculated somehow, or their
simply pulled out of the air at random.  Either way, we need to know
*how* they are calculated, and explain it in.

Personaly, I'd prefer that the explanation come in the form of code.
IOW, functions that calculate the value based on dependent clocks using
whatever the board-specific factors are as inputs.

Kevin



--
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

Re: [PM-WIP/voltdm_c][PATCH 04/11] OMAP4: PM: VC: support configuration of i2c clks

[Menon, Nishanth]

On Wed, May 25, 2011 at 11:17, Kevin Hilman <khilman@ti.com> wrote:
> "Menon, Nishanth" <nm@ti.com> writes:
>
>> On Wed, May 18, 2011 at 03:53, Kevin Hilman <khilman@ti.com> wrote:
>>> Nishanth Menon <nm@ti.com> writes:
>>>
>>>> Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated layer"
>>>> splits out the hardcoded value in the code to vc's channel init.
>>>>
>>>> This patch further isolates the configuration to remove out PMIC specific
>>>> configuration as high and low times are pmic specific.
>>>>
>>>> Values are updated as well based on latest TI analysis done in android k35
>>>> kernel.
>>>>
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>
>>> OK, this is a step in the right direction, but IIUC, these values are
>>> sys_clk dependent right?  Shouldn't we be calculating these values based
>>> on sys_clk?
>> 3 factors to my knowledge:
>> a) sr clk I believe(I need to grab the relevant internal doc to
>> verify) - factor of sysclk - > board based/in a way pmic based
>> b)  factor of board capacitance (similar to i2c bus)
>> c)  i2c bus capability of the PMIC itself.
>>
>> hence based it off pmic data..
>
> These are hard-coded constants, that are calculated somehow, or their
> simply pulled out of the air at random.  Either way, we need to know
> *how* they are calculated, and explain it in.
>
> Personaly, I'd prefer that the explanation come in the form of code.
> IOW, functions that calculate the value based on dependent clocks using
> whatever the board-specific factors are as inputs.

yep, trying to dig internally to simplify the blackmagic involved.
ideally, I'd like a person to look at the PMIC data sheet and update
relevant params(timing, maybe bus capacitance max) and the rest of the
computation should be automated. it makes bigger sense for us
considering 4460 has a combination of TPS and TWL controlling rails
and we just have one VC I2C config register to configure the common
value.

Regards,
Nishanth Menon
--
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

[PM-WIP/voltdm_c][PATCH 05/11] OMAP4: PM: VC: fix highspeed i2c for SR

[Nishanth Menon]

Patch "OMAP3+: VC: make I2C config programmable with PMIC-specific settings"
wrongly uses shift register causing mcode to be set instead
of HS mode bit to be set for I2C_SR.

Fix the same for OMAP4 and rename the "shift" to "mask" to rightly
indicate what is to be provided in the structure.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/vc.c          |    4 ++--
 arch/arm/mach-omap2/vc.h          |    4 ++--
 arch/arm/mach-omap2/vc3xxx_data.c |    2 +-
 arch/arm/mach-omap2/vc44xx_data.c |    2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 79b9e86..f8185d2 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -240,8 +240,8 @@ void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
 
 	i2c_high_speed = voltdm->pmic->i2c_high_speed;
 	if (i2c_high_speed)
-		voltdm->rmw(vc->common->i2c_cfg_hsen_shift,
-			    vc->common->i2c_cfg_hsen_shift,
+		voltdm->rmw(vc->common->i2c_cfg_hsen_mask,
+			    vc->common->i2c_cfg_hsen_mask,
 			    vc->common->i2c_cfg_reg);
 
 	mcode = voltdm->pmic->i2c_mcode;
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index 85f13f1..f0fb61f 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -36,7 +36,7 @@ struct voltagedomain;
  * @cmd_ret_shift: RET field shift in PRM_VC_CMD_VAL_* register
  * @cmd_off_shift: OFF field shift in PRM_VC_CMD_VAL_* register
  * @i2c_cfg_reg: I2C configuration register offset
- * @i2c_cfg_hsen_shift: high-speed mode bit field shift in I2C config register
+ * @i2c_cfg_hsen_mask: high-speed mode bit field mask in I2C config register
  * @i2c_mcode_mask: MCODE field mask for I2C config register
  *
  * XXX One of cmd_on_mask and cmd_on_shift are not needed
@@ -58,7 +58,7 @@ struct omap_vc_common {
 	u8 cmd_off_shift;
 	u8 cfg_channel_reg;
 	u8 i2c_cfg_reg;
-	u8 i2c_cfg_hsen_shift;
+	u8 i2c_cfg_hsen_mask;
 	u8 i2c_mcode_mask;
 };
 
diff --git a/arch/arm/mach-omap2/vc3xxx_data.c b/arch/arm/mach-omap2/vc3xxx_data.c
index 688d55d..95d7701 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -44,7 +44,7 @@ static struct omap_vc_common omap3_vc_common = {
 	.cmd_ret_shift	 = OMAP3430_VC_CMD_RET_SHIFT,
 	.cmd_off_shift	 = OMAP3430_VC_CMD_OFF_SHIFT,
 	.cfg_channel_reg = OMAP3_PRM_VC_CH_CONF_OFFSET,
-	.i2c_cfg_hsen_shift = OMAP3430_HSEN_MASK,
+	.i2c_cfg_hsen_mask = OMAP3430_HSEN_MASK,
 	.i2c_cfg_reg	 = OMAP3_PRM_VC_I2C_CFG_OFFSET,
 	.i2c_mcode_mask	 = OMAP3430_MCODE_MASK,
 };
diff --git a/arch/arm/mach-omap2/vc44xx_data.c b/arch/arm/mach-omap2/vc44xx_data.c
index 8aee1fe..fe4f4e5 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -46,7 +46,7 @@ static const struct omap_vc_common omap4_vc_common = {
 	.cmd_off_shift = OMAP4430_OFF_SHIFT,
 	.cfg_channel_reg = OMAP4_PRM_VC_CFG_CHANNEL_OFFSET,
 	.i2c_cfg_reg = OMAP4_PRM_VC_CFG_I2C_MODE_OFFSET,
-	.i2c_cfg_hsen_shift = OMAP4430_HSMODEEN_SHIFT,
+	.i2c_cfg_hsen_mask = OMAP4430_HSMODEEN_MASK,
 	.i2c_mcode_mask	 = OMAP4430_HSMCODE_MASK,
 };
 
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 05/11] OMAP4: PM: VC: fix highspeed i2c for SR

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Patch "OMAP3+: VC: make I2C config programmable with PMIC-specific settings"
> wrongly uses shift register causing mcode to be set instead
> of HS mode bit to be set for I2C_SR.

Oops, thanks for testing/finding/fixing.

> Fix the same for OMAP4 and rename the "shift" to "mask" to rightly
> indicate what is to be provided in the structure.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>

Thanks, adding to voltdm work, probably will fold into original patch.

Kevin

> ---
>  arch/arm/mach-omap2/vc.c          |    4 ++--
>  arch/arm/mach-omap2/vc.h          |    4 ++--
>  arch/arm/mach-omap2/vc3xxx_data.c |    2 +-
>  arch/arm/mach-omap2/vc44xx_data.c |    2 +-
>  4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 79b9e86..f8185d2 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -240,8 +240,8 @@ void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
>  
>  	i2c_high_speed = voltdm->pmic->i2c_high_speed;
>  	if (i2c_high_speed)
> -		voltdm->rmw(vc->common->i2c_cfg_hsen_shift,
> -			    vc->common->i2c_cfg_hsen_shift,
> +		voltdm->rmw(vc->common->i2c_cfg_hsen_mask,
> +			    vc->common->i2c_cfg_hsen_mask,
>  			    vc->common->i2c_cfg_reg);
>  
>  	mcode = voltdm->pmic->i2c_mcode;
> diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
> index 85f13f1..f0fb61f 100644
> --- a/arch/arm/mach-omap2/vc.h
> +++ b/arch/arm/mach-omap2/vc.h
> @@ -36,7 +36,7 @@ struct voltagedomain;
>   * @cmd_ret_shift: RET field shift in PRM_VC_CMD_VAL_* register
>   * @cmd_off_shift: OFF field shift in PRM_VC_CMD_VAL_* register
>   * @i2c_cfg_reg: I2C configuration register offset
> - * @i2c_cfg_hsen_shift: high-speed mode bit field shift in I2C config register
> + * @i2c_cfg_hsen_mask: high-speed mode bit field mask in I2C config register
>   * @i2c_mcode_mask: MCODE field mask for I2C config register
>   *
>   * XXX One of cmd_on_mask and cmd_on_shift are not needed
> @@ -58,7 +58,7 @@ struct omap_vc_common {
>  	u8 cmd_off_shift;
>  	u8 cfg_channel_reg;
>  	u8 i2c_cfg_reg;
> -	u8 i2c_cfg_hsen_shift;
> +	u8 i2c_cfg_hsen_mask;
>  	u8 i2c_mcode_mask;
>  };
>  
> diff --git a/arch/arm/mach-omap2/vc3xxx_data.c b/arch/arm/mach-omap2/vc3xxx_data.c
> index 688d55d..95d7701 100644
> --- a/arch/arm/mach-omap2/vc3xxx_data.c
> +++ b/arch/arm/mach-omap2/vc3xxx_data.c
> @@ -44,7 +44,7 @@ static struct omap_vc_common omap3_vc_common = {
>  	.cmd_ret_shift	 = OMAP3430_VC_CMD_RET_SHIFT,
>  	.cmd_off_shift	 = OMAP3430_VC_CMD_OFF_SHIFT,
>  	.cfg_channel_reg = OMAP3_PRM_VC_CH_CONF_OFFSET,
> -	.i2c_cfg_hsen_shift = OMAP3430_HSEN_MASK,
> +	.i2c_cfg_hsen_mask = OMAP3430_HSEN_MASK,
>  	.i2c_cfg_reg	 = OMAP3_PRM_VC_I2C_CFG_OFFSET,
>  	.i2c_mcode_mask	 = OMAP3430_MCODE_MASK,
>  };
> diff --git a/arch/arm/mach-omap2/vc44xx_data.c b/arch/arm/mach-omap2/vc44xx_data.c
> index 8aee1fe..fe4f4e5 100644
> --- a/arch/arm/mach-omap2/vc44xx_data.c
> +++ b/arch/arm/mach-omap2/vc44xx_data.c
> @@ -46,7 +46,7 @@ static const struct omap_vc_common omap4_vc_common = {
>  	.cmd_off_shift = OMAP4430_OFF_SHIFT,
>  	.cfg_channel_reg = OMAP4_PRM_VC_CFG_CHANNEL_OFFSET,
>  	.i2c_cfg_reg = OMAP4_PRM_VC_CFG_I2C_MODE_OFFSET,
> -	.i2c_cfg_hsen_shift = OMAP4430_HSMODEEN_SHIFT,
> +	.i2c_cfg_hsen_mask = OMAP4430_HSMODEEN_MASK,
>  	.i2c_mcode_mask	 = OMAP4430_HSMCODE_MASK,
>  };

[PM-WIP/voltdm_c][PATCH 06/11] OMAP4: PM: VC: fix channel bit offset for MPU

[Nishanth Menon]

Patch "OMAP3+: VC: abstract out channel configuration" abstracts out
VC channel configuration. However, TRM has it's little surprises such
as the following for channel_cfg:
CFG_CHANNEL_SA    BIT(0)
CFG_CHANNEL_RAV   BIT(1)
CFG_CHANNEL_RAC   BIT(2)
CFG_CHANNEL_RACEN BIT(3)
CFG_CHANNEL_CMD   BIT(4)
is valid for core and iva, *but* for mpu, the channel offsets
are as follows:
CFG_CHANNEL_SA    BIT(0)
CFG_CHANNEL_CMD   BIT(1)
CFG_CHANNEL_RAV   BIT(2)
CFG_CHANNEL_RAC   BIT(3)
CFG_CHANNEL_RACEN BIT(4)

to handle this on the fly, add a structure to describe this
and use the structure for vc44xx mpu definition. use the
default for rest of the domains.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/vc.c          |   35 +++++++++++++++++++----------------
 arch/arm/mach-omap2/vc.h          |   33 +++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/vc44xx_data.c |   10 ++++++++++
 3 files changed, 62 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index f8185d2..2add945 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -10,18 +10,6 @@
 #include "prm-regbits-44xx.h"
 #include "prm44xx.h"
 
-/*
- * Channel configuration bits, common for OMAP3 & 4
- * OMAP3 register: PRM_VC_CH_CONF
- * OMAP4 register: PRM_VC_CFG_CHANNEL
- */
-#define CFG_CHANNEL_SA    BIT(0)
-#define CFG_CHANNEL_RAV   BIT(1)
-#define CFG_CHANNEL_RAC   BIT(2)
-#define CFG_CHANNEL_RACEN BIT(3)
-#define CFG_CHANNEL_CMD   BIT(4)
-#define CFG_CHANNEL_MASK 0x3f
-
 /**
  * omap_vc_config_channel - configure VC channel to PMIC mappings
  * @voltdm: pointer to voltagdomain defining the desired VC channel
@@ -258,6 +246,14 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
 	struct omap_vc_channel *vc = voltdm->vc;
 	u8 on_vsel, onlp_vsel, ret_vsel, off_vsel;
 	u32 val;
+	struct omap_vc_channel_cfg *cfg_channel_data;
+	struct omap_vc_channel_cfg cfg_channel_common = {
+		.cfg_channel_sa = CFG_CHANNEL_SA,
+		.cfg_channel_rav = CFG_CHANNEL_RAV,
+		.cfg_channel_rac = CFG_CHANNEL_RAC,
+		.cfg_channel_racen = CFG_CHANNEL_RACEN,
+		.cfg_channel_cmd = CFG_CHANNEL_CMD,
+	};
 
 	if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
 		pr_err("%s: PMIC info requried to configure vc for"
@@ -272,6 +268,12 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
 		return;
 	}
 
+	/* if there is an exception case, use the exception data */
+	if (!vc->cfg_ch_data)
+		cfg_channel_data = &cfg_channel_common;
+	else
+		cfg_channel_data = vc->cfg_ch_data;
+
 	vc->cfg_channel = 0;
 
 	/* get PMIC/board specific settings */
@@ -284,7 +286,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
 	voltdm->rmw(vc->smps_sa_mask,
 		    vc->i2c_slave_addr << __ffs(vc->smps_sa_mask),
 		    vc->common->smps_sa_reg);
-	vc->cfg_channel |= CFG_CHANNEL_SA;
+	vc->cfg_channel |= cfg_channel_data->cfg_channel_sa;
 
 	/*
 	 * Configure the PMIC register addresses.
@@ -292,13 +294,14 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
 	voltdm->rmw(vc->smps_volra_mask,
 		    vc->volt_reg_addr << __ffs(vc->smps_volra_mask),
 		    vc->common->smps_volra_reg);
-	vc->cfg_channel |= CFG_CHANNEL_RAV;
+	vc->cfg_channel |= cfg_channel_data->cfg_channel_rav;
 
 	if (vc->cmd_reg_addr) {
 		voltdm->rmw(vc->smps_cmdra_mask,
 			    vc->cmd_reg_addr << __ffs(vc->smps_cmdra_mask),
 			    vc->common->smps_cmdra_reg);
-		vc->cfg_channel |= CFG_CHANNEL_RAC | CFG_CHANNEL_RACEN;
+		vc->cfg_channel |= cfg_channel_data->cfg_channel_rac |
+					cfg_channel_data->cfg_channel_racen;
 	}
 
 	/* Set up the on, inactive, retention and off voltage */
@@ -311,7 +314,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
 	       (ret_vsel << vc->common->cmd_ret_shift) |
 	       (off_vsel << vc->common->cmd_off_shift));
 	voltdm->write(val, vc->cmdval_reg);
-	vc->cfg_channel |= CFG_CHANNEL_CMD;
+	vc->cfg_channel |= cfg_channel_data->cfg_channel_cmd;
 
 	/* Channel configuration */
 	omap_vc_config_channel(voltdm);
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index f0fb61f..bbd8f1f 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -62,11 +62,42 @@ struct omap_vc_common {
 	u8 i2c_mcode_mask;
 };
 
+/*
+ * Channel configuration bits, common for OMAP3 & 4
+ * OMAP3 register: PRM_VC_CH_CONF
+ * OMAP4 register: PRM_VC_CFG_CHANNEL
+ */
+#define CFG_CHANNEL_SA    BIT(0)
+#define CFG_CHANNEL_RAV   BIT(1)
+#define CFG_CHANNEL_RAC   BIT(2)
+#define CFG_CHANNEL_RACEN BIT(3)
+#define CFG_CHANNEL_CMD   BIT(4)
+#define CFG_CHANNEL_MASK 0x3f
+/**
+ * struct omap_vc_channel_cfg - describe the cfg_channel bitfield
+ * @cfg_channel_sa:	SA_VDD_xxx_L
+ * @cfg_channel_rav:	RAV_VDD_xxx_L
+ * @cfg_channel_rac:	RAC_VDD_xxx_L
+ * @cfg_channel_racen:	RACEN_VDD_xxx_L
+ * @cfg_channel_cmd:	CMD_VDD_xxx_L
+ *
+ * by default it uses CFG_CHANNEL_xyz regs, but in OMAP4 MPU,
+ * there is a need for an exception case.
+ */
+struct omap_vc_channel_cfg {
+	u8 cfg_channel_sa;
+	u8 cfg_channel_rav;
+	u8 cfg_channel_rac;
+	u8 cfg_channel_racen;
+	u8 cfg_channel_cmd;
+};
+
 /**
  * struct omap_vc_channel - VC per-instance data
  * @common: pointer to VC common data for this platform
  * @smps_sa_mask: i2c slave address bitmask in the PRM_VC_SMPS_SA register
  * @smps_volra_mask: VOLRA* bitmask in the PRM_VC_VOL_RA register
+ * @cfg_ch_data: exception handling for unordered register bits in cfg_channel
  */
 struct omap_vc_channel {
 	/* channel state */
@@ -74,6 +105,7 @@ struct omap_vc_channel {
 	u8 volt_reg_addr;
 	u8 cmd_reg_addr;
 	u8 cfg_channel;
+	struct omap_vc_channel_cfg *cfg_ch_data;
 	u16 setup_time;
 	bool i2c_high_speed;
 
@@ -86,6 +118,7 @@ struct omap_vc_channel {
 	u8 cfg_channel_sa_shift;
 };
 
+
 extern struct omap_vc_channel omap3_vc_mpu;
 extern struct omap_vc_channel omap3_vc_core;
 
diff --git a/arch/arm/mach-omap2/vc44xx_data.c b/arch/arm/mach-omap2/vc44xx_data.c
index fe4f4e5..b53b05e 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -50,6 +50,15 @@ static const struct omap_vc_common omap4_vc_common = {
 	.i2c_mcode_mask	 = OMAP4430_HSMCODE_MASK,
 };
 
+/* handle exception case for vc44xx */
+static struct omap_vc_channel_cfg vc44xx_mpu_cfg_channel = {
+	.cfg_channel_sa = CFG_CHANNEL_SA,
+	.cfg_channel_cmd = BIT(1),
+	.cfg_channel_rav = BIT(2),
+	.cfg_channel_rac = BIT(3),
+	.cfg_channel_racen = BIT(4),
+};
+
 /* VC instance data for each controllable voltage line */
 struct omap_vc_channel omap4_vc_mpu = {
 	.common = &omap4_vc_common,
@@ -58,6 +67,7 @@ struct omap_vc_channel omap4_vc_mpu = {
 	.smps_volra_mask = OMAP4430_VOLRA_VDD_MPU_L_MASK,
 	.smps_cmdra_mask = OMAP4430_CMDRA_VDD_MPU_L_MASK,
 	.cfg_channel_sa_shift = OMAP4430_SA_VDD_MPU_L_SHIFT,
+	.cfg_ch_data = &vc44xx_mpu_cfg_channel,
 };
 
 struct omap_vc_channel omap4_vc_iva = {
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 06/11] OMAP4: PM: VC: fix channel bit offset for MPU

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Patch "OMAP3+: VC: abstract out channel configuration" abstracts out
> VC channel configuration. However, TRM has it's little surprises such
> as the following for channel_cfg:
> CFG_CHANNEL_SA    BIT(0)
> CFG_CHANNEL_RAV   BIT(1)
> CFG_CHANNEL_RAC   BIT(2)
> CFG_CHANNEL_RACEN BIT(3)
> CFG_CHANNEL_CMD   BIT(4)
> is valid for core and iva, *but* for mpu, the channel offsets
> are as follows:
> CFG_CHANNEL_SA    BIT(0)
> CFG_CHANNEL_CMD   BIT(1)
> CFG_CHANNEL_RAV   BIT(2)
> CFG_CHANNEL_RAC   BIT(3)
> CFG_CHANNEL_RACEN BIT(4)

sigh, glad to see the IP designers have something to do. :(

Hmm, and I don't suppose there's any chance we can tell the difference
based on IP revision information from the IP?  After looking at the TRM
and the functional spec, there's a difference.  In the funcional spec,
all 3 OMAP4 VCs have the "default" order, but in the TRM, the MPU is
different.  Which one is right?   I assume you found this because of a
bug in testing, so I take it the TRM is right.

> to handle this on the fly, add a structure to describe this
> and use the structure for vc44xx mpu definition. use the
> default for rest of the domains.

IMO, while it makes us generate a few more struct in the data, I think
it's cleaner to not treat this as an exception.  IOW, just define
the channel struct(s) in each data file, so every VC has one associated
with it.  Probably also need a WARN() and graceful failure during init
if a channel doesn't have a channel config defined.

> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  arch/arm/mach-omap2/vc.c          |   35 +++++++++++++++++++----------------
>  arch/arm/mach-omap2/vc.h          |   33 +++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/vc44xx_data.c |   10 ++++++++++
>  3 files changed, 62 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index f8185d2..2add945 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -10,18 +10,6 @@
>  #include "prm-regbits-44xx.h"
>  #include "prm44xx.h"
>  
> -/*
> - * Channel configuration bits, common for OMAP3 & 4
> - * OMAP3 register: PRM_VC_CH_CONF
> - * OMAP4 register: PRM_VC_CFG_CHANNEL
> - */
> -#define CFG_CHANNEL_SA    BIT(0)
> -#define CFG_CHANNEL_RAV   BIT(1)
> -#define CFG_CHANNEL_RAC   BIT(2)
> -#define CFG_CHANNEL_RACEN BIT(3)
> -#define CFG_CHANNEL_CMD   BIT(4)
> -#define CFG_CHANNEL_MASK 0x3f
> -
>  /**
>   * omap_vc_config_channel - configure VC channel to PMIC mappings
>   * @voltdm: pointer to voltagdomain defining the desired VC channel
> @@ -258,6 +246,14 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
>  	struct omap_vc_channel *vc = voltdm->vc;
>  	u8 on_vsel, onlp_vsel, ret_vsel, off_vsel;
>  	u32 val;
> +	struct omap_vc_channel_cfg *cfg_channel_data;
> +	struct omap_vc_channel_cfg cfg_channel_common = {
> +		.cfg_channel_sa = CFG_CHANNEL_SA,
> +		.cfg_channel_rav = CFG_CHANNEL_RAV,
> +		.cfg_channel_rac = CFG_CHANNEL_RAC,
> +		.cfg_channel_racen = CFG_CHANNEL_RACEN,
> +		.cfg_channel_cmd = CFG_CHANNEL_CMD,
> +	};
>  
>  	if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
>  		pr_err("%s: PMIC info requried to configure vc for"
> @@ -272,6 +268,12 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
>  		return;
>  	}
>  
> +	/* if there is an exception case, use the exception data */
> +	if (!vc->cfg_ch_data)
> +		cfg_channel_data = &cfg_channel_common;
> +	else
> +		cfg_channel_data = vc->cfg_ch_data;

Based on the above,  this block could be dropped, and...

>  	vc->cfg_channel = 0;
>  
>  	/* get PMIC/board specific settings */
> @@ -284,7 +286,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
>  	voltdm->rmw(vc->smps_sa_mask,
>  		    vc->i2c_slave_addr << __ffs(vc->smps_sa_mask),
>  		    vc->common->smps_sa_reg);
> -	vc->cfg_channel |= CFG_CHANNEL_SA;
> +	vc->cfg_channel |= cfg_channel_data->cfg_channel_sa;

...this would look like

	vc->cfg_channel |= vc->cfg_ch_bits->sa;

and similar for below.

>  	/*
>  	 * Configure the PMIC register addresses.
> @@ -292,13 +294,14 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
>  	voltdm->rmw(vc->smps_volra_mask,
>  		    vc->volt_reg_addr << __ffs(vc->smps_volra_mask),
>  		    vc->common->smps_volra_reg);
> -	vc->cfg_channel |= CFG_CHANNEL_RAV;
> +	vc->cfg_channel |= cfg_channel_data->cfg_channel_rav;
>  
>  	if (vc->cmd_reg_addr) {
>  		voltdm->rmw(vc->smps_cmdra_mask,
>  			    vc->cmd_reg_addr << __ffs(vc->smps_cmdra_mask),
>  			    vc->common->smps_cmdra_reg);
> -		vc->cfg_channel |= CFG_CHANNEL_RAC | CFG_CHANNEL_RACEN;
> +		vc->cfg_channel |= cfg_channel_data->cfg_channel_rac |
> +					cfg_channel_data->cfg_channel_racen;
>  	}
>  
>  	/* Set up the on, inactive, retention and off voltage */
> @@ -311,7 +314,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
>  	       (ret_vsel << vc->common->cmd_ret_shift) |
>  	       (off_vsel << vc->common->cmd_off_shift));
>  	voltdm->write(val, vc->cmdval_reg);
> -	vc->cfg_channel |= CFG_CHANNEL_CMD;
> +	vc->cfg_channel |= cfg_channel_data->cfg_channel_cmd;
>  
>  	/* Channel configuration */
>  	omap_vc_config_channel(voltdm);
> diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
> index f0fb61f..bbd8f1f 100644
> --- a/arch/arm/mach-omap2/vc.h
> +++ b/arch/arm/mach-omap2/vc.h
> @@ -62,11 +62,42 @@ struct omap_vc_common {
>  	u8 i2c_mcode_mask;
>  };
>  
> +/*
> + * Channel configuration bits, common for OMAP3 & 4
> + * OMAP3 register: PRM_VC_CH_CONF
> + * OMAP4 register: PRM_VC_CFG_CHANNEL
> + */
> +#define CFG_CHANNEL_SA    BIT(0)
> +#define CFG_CHANNEL_RAV   BIT(1)
> +#define CFG_CHANNEL_RAC   BIT(2)
> +#define CFG_CHANNEL_RACEN BIT(3)
> +#define CFG_CHANNEL_CMD   BIT(4)
> +#define CFG_CHANNEL_MASK 0x3f
> +/**
> + * struct omap_vc_channel_cfg - describe the cfg_channel bitfield
> + * @cfg_channel_sa:	SA_VDD_xxx_L
> + * @cfg_channel_rav:	RAV_VDD_xxx_L
> + * @cfg_channel_rac:	RAC_VDD_xxx_L
> + * @cfg_channel_racen:	RACEN_VDD_xxx_L
> + * @cfg_channel_cmd:	CMD_VDD_xxx_L

You should drop the cfg_channel_ prefix here (and below.)

> + *
> + * by default it uses CFG_CHANNEL_xyz regs, but in OMAP4 MPU,
> + * there is a need for an exception case.

This comment isn't really needed here.  IOW, let's assume it's not an
exception, as new SoCs might decide to change again.

> + */
> +struct omap_vc_channel_cfg {
> +	u8 cfg_channel_sa;
> +	u8 cfg_channel_rav;
> +	u8 cfg_channel_rac;
> +	u8 cfg_channel_racen;
> +	u8 cfg_channel_cmd;
> +};
> +
>  /**
>   * struct omap_vc_channel - VC per-instance data
>   * @common: pointer to VC common data for this platform
>   * @smps_sa_mask: i2c slave address bitmask in the PRM_VC_SMPS_SA register
>   * @smps_volra_mask: VOLRA* bitmask in the PRM_VC_VOL_RA register
> + * @cfg_ch_data: exception handling for unordered register bits in cfg_channel

>   */
>  struct omap_vc_channel {
>  	/* channel state */
> @@ -74,6 +105,7 @@ struct omap_vc_channel {
>  	u8 volt_reg_addr;
>  	u8 cmd_reg_addr;
>  	u8 cfg_channel;
> +	struct omap_vc_channel_cfg *cfg_ch_data;

s/cfg_ch_data/cfg_ch_bits/

>  	u16 setup_time;
>  	bool i2c_high_speed;
>  
> @@ -86,6 +118,7 @@ struct omap_vc_channel {
>  	u8 cfg_channel_sa_shift;
>  };
>  
> +

stray whitespace change

>  extern struct omap_vc_channel omap3_vc_mpu;
>  extern struct omap_vc_channel omap3_vc_core;
>  
> diff --git a/arch/arm/mach-omap2/vc44xx_data.c b/arch/arm/mach-omap2/vc44xx_data.c
> index fe4f4e5..b53b05e 100644
> --- a/arch/arm/mach-omap2/vc44xx_data.c
> +++ b/arch/arm/mach-omap2/vc44xx_data.c
> @@ -50,6 +50,15 @@ static const struct omap_vc_common omap4_vc_common = {
>  	.i2c_mcode_mask	 = OMAP4430_HSMCODE_MASK,
>  };
>  
> +/* handle exception case for vc44xx */
> +static struct omap_vc_channel_cfg vc44xx_mpu_cfg_channel = {
> +	.cfg_channel_sa = CFG_CHANNEL_SA,
> +	.cfg_channel_cmd = BIT(1),
> +	.cfg_channel_rav = BIT(2),
> +	.cfg_channel_rac = BIT(3),
> +	.cfg_channel_racen = BIT(4),
> +};
> +
>  /* VC instance data for each controllable voltage line */
>  struct omap_vc_channel omap4_vc_mpu = {
>  	.common = &omap4_vc_common,
> @@ -58,6 +67,7 @@ struct omap_vc_channel omap4_vc_mpu = {
>  	.smps_volra_mask = OMAP4430_VOLRA_VDD_MPU_L_MASK,
>  	.smps_cmdra_mask = OMAP4430_CMDRA_VDD_MPU_L_MASK,
>  	.cfg_channel_sa_shift = OMAP4430_SA_VDD_MPU_L_SHIFT,
> +	.cfg_ch_data = &vc44xx_mpu_cfg_channel,
>  };
>  
>  struct omap_vc_channel omap4_vc_iva = {

Kevin

Re: [PM-WIP/voltdm_c][PATCH 06/11] OMAP4: PM: VC: fix channel bit offset for MPU

[Menon, Nishanth]

On Wed, May 18, 2011 at 04:34, Kevin Hilman <khilman@ti.com> wrote:
> Nishanth Menon <nm@ti.com> writes:
>
>> Patch "OMAP3+: VC: abstract out channel configuration" abstracts out
>> VC channel configuration. However, TRM has it's little surprises such
>> as the following for channel_cfg:
>> CFG_CHANNEL_SA    BIT(0)
>> CFG_CHANNEL_RAV   BIT(1)
>> CFG_CHANNEL_RAC   BIT(2)
>> CFG_CHANNEL_RACEN BIT(3)
>> CFG_CHANNEL_CMD   BIT(4)
>> is valid for core and iva, *but* for mpu, the channel offsets
>> are as follows:
>> CFG_CHANNEL_SA    BIT(0)
>> CFG_CHANNEL_CMD   BIT(1)
>> CFG_CHANNEL_RAV   BIT(2)
>> CFG_CHANNEL_RAC   BIT(3)
>> CFG_CHANNEL_RACEN BIT(4)
>
> sigh, glad to see the IP designers have something to do. :(
/me thinks "lets say 'integration folks'.." ;)

>
> Hmm, and I don't suppose there's any chance we can tell the difference
> based on IP revision information from the IP?  After looking at the TRM
> and the functional spec, there's a difference.  In the funcional spec,
> all 3 OMAP4 VCs have the "default" order, but in the TRM, the MPU is
> different.  Which one is right?   I assume you found this because of a
> bug in testing, so I take it the TRM is right.
Unfortunately, that is what I have been burnt previously upon as well
- in all cases, I have been told, "in case of conflict funcspec Vs
TRM, believe the TRM" as there is integration aspects of an IP for an
SoC involved :(. Unfortunately in this case, MPU caused core to
transition until fixed.

>
>> to handle this on the fly, add a structure to describe this
>> and use the structure for vc44xx mpu definition. use the
>> default for rest of the domains.
>
> IMO, while it makes us generate a few more struct in the data, I think
> it's cleaner to not treat this as an exception.  IOW, just define
> the channel struct(s) in each data file, so every VC has one associated
> with it.  Probably also need a WARN() and graceful failure during init
> if a channel doesn't have a channel config defined.
..

>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>>  arch/arm/mach-omap2/vc.c          |   35 +++++++++++++++++++----------------
>>  arch/arm/mach-omap2/vc.h          |   33 +++++++++++++++++++++++++++++++++
>>  arch/arm/mach-omap2/vc44xx_data.c |   10 ++++++++++
>>  3 files changed, 62 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
>> index f8185d2..2add945 100644
>> --- a/arch/arm/mach-omap2/vc.c
>> +++ b/arch/arm/mach-omap2/vc.c
[..]
>>
>> +     /* if there is an exception case, use the exception data */
>> +     if (!vc->cfg_ch_data)
>> +             cfg_channel_data = &cfg_channel_common;
>> +     else
>> +             cfg_channel_data = vc->cfg_ch_data;
>
> Based on the above,  this block could be dropped, and...
Except I will have to replicate this for OMAP3 and 4 - which is
possible.. but replicated data which is needed only during init
:( did not want vc pointer to contain __initdata pointer (dangling
ones after boot)

>
>>       vc->cfg_channel = 0;
>>
>>       /* get PMIC/board specific settings */
>> @@ -284,7 +286,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
>>       voltdm->rmw(vc->smps_sa_mask,
>>                   vc->i2c_slave_addr << __ffs(vc->smps_sa_mask),
>>                   vc->common->smps_sa_reg);
>> -     vc->cfg_channel |= CFG_CHANNEL_SA;
>> +     vc->cfg_channel |= cfg_channel_data->cfg_channel_sa;
>
> ...this would look like
>
>        vc->cfg_channel |= vc->cfg_ch_bits->sa;
>
> and similar for below.
ok..
[...]

>> diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
>> index f0fb61f..bbd8f1f 100644
>> --- a/arch/arm/mach-omap2/vc.h
>> +++ b/arch/arm/mach-omap2/vc.h
>> @@ -62,11 +62,42 @@ struct omap_vc_common {
>>       u8 i2c_mcode_mask;
>>  };
>>
>> +/*
>> + * Channel configuration bits, common for OMAP3 & 4
>> + * OMAP3 register: PRM_VC_CH_CONF
>> + * OMAP4 register: PRM_VC_CFG_CHANNEL
>> + */
>> +#define CFG_CHANNEL_SA    BIT(0)
>> +#define CFG_CHANNEL_RAV   BIT(1)
>> +#define CFG_CHANNEL_RAC   BIT(2)
>> +#define CFG_CHANNEL_RACEN BIT(3)
>> +#define CFG_CHANNEL_CMD   BIT(4)
>> +#define CFG_CHANNEL_MASK 0x3f
>> +/**
>> + * struct omap_vc_channel_cfg - describe the cfg_channel bitfield
>> + * @cfg_channel_sa:  SA_VDD_xxx_L
>> + * @cfg_channel_rav: RAV_VDD_xxx_L
>> + * @cfg_channel_rac: RAC_VDD_xxx_L
>> + * @cfg_channel_racen:       RACEN_VDD_xxx_L
>> + * @cfg_channel_cmd: CMD_VDD_xxx_L
>
> You should drop the cfg_channel_ prefix here (and below.)
ok..

>
>> + *
>> + * by default it uses CFG_CHANNEL_xyz regs, but in OMAP4 MPU,
>> + * there is a need for an exception case.
>
> This comment isn't really needed here.  IOW, let's assume it's not an
> exception, as new SoCs might decide to change again.
true.

[..]
>>   */
>>  struct omap_vc_channel {
>>       /* channel state */
>> @@ -74,6 +105,7 @@ struct omap_vc_channel {
>>       u8 volt_reg_addr;
>>       u8 cmd_reg_addr;
>>       u8 cfg_channel;
>> +     struct omap_vc_channel_cfg *cfg_ch_data;
>
> s/cfg_ch_data/cfg_ch_bits/
ok.

>
>>       u16 setup_time;
>>       bool i2c_high_speed;
>>
>> @@ -86,6 +118,7 @@ struct omap_vc_channel {
>>       u8 cfg_channel_sa_shift;
>>  };
>>
>> +
>
> stray whitespace change
oops :( will fix in rev2

[...]


Regards,
Nishanth Menon
--
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

Re: [PM-WIP/voltdm_c][PATCH 06/11] OMAP4: PM: VC: fix channel bit offset for MPU

[Kevin Hilman]

"Menon, Nishanth" <nm@ti.com> writes:

[...]

>>
>>> to handle this on the fly, add a structure to describe this
>>> and use the structure for vc44xx mpu definition. use the
>>> default for rest of the domains.
>>
>> IMO, while it makes us generate a few more struct in the data, I think
>> it's cleaner to not treat this as an exception.  IOW, just define
>> the channel struct(s) in each data file, so every VC has one associated
>> with it.  Probably also need a WARN() and graceful failure during init
>> if a channel doesn't have a channel config defined.
> ..
>
>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>>  arch/arm/mach-omap2/vc.c          |   35 +++++++++++++++++++----------------
>>>  arch/arm/mach-omap2/vc.h          |   33 +++++++++++++++++++++++++++++++++
>>>  arch/arm/mach-omap2/vc44xx_data.c |   10 ++++++++++
>>>  3 files changed, 62 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
>>> index f8185d2..2add945 100644
>>> --- a/arch/arm/mach-omap2/vc.c
>>> +++ b/arch/arm/mach-omap2/vc.c
> [..]
>>>
>>> +     /* if there is an exception case, use the exception data */
>>> +     if (!vc->cfg_ch_data)
>>> +             cfg_channel_data = &cfg_channel_common;
>>> +     else
>>> +             cfg_channel_data = vc->cfg_ch_data;
>>
>> Based on the above,  this block could be dropped, and...
>
> Except I will have to replicate this for OMAP3 and 4 - which is
> possible.. but replicated data which is needed only during init

Yes, but remember we are trying to keep data separated from code.
Eventually, much of this data will likely be migrated to the device
tree, so we want to be sure our data is cleanly separated from code.

> :( did not want vc pointer to contain __initdata pointer (dangling
> ones after boot)

Yes, so far, we're not using initdata for per-SoC stuff, and there have
been proposals around that.  However, moving to device tree will largely
solve the per-SoC bloat issues around that.

Kevin
--
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

Re: [PM-WIP/voltdm_c][PATCH 06/11] OMAP4: PM: VC: fix channel bit offset for MPU

[Menon, Nishanth]

On Wed, May 18, 2011 at 06:06, Kevin Hilman <khilman@ti.com> wrote:
> "Menon, Nishanth" <nm@ti.com> writes:
>
> [...]
>
>>>
>>>> to handle this on the fly, add a structure to describe this
>>>> and use the structure for vc44xx mpu definition. use the
>>>> default for rest of the domains.
>>>
>>> IMO, while it makes us generate a few more struct in the data, I think
>>> it's cleaner to not treat this as an exception.  IOW, just define
>>> the channel struct(s) in each data file, so every VC has one associated
>>> with it.  Probably also need a WARN() and graceful failure during init
>>> if a channel doesn't have a channel config defined.
>> ..
>>
>>>
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>> ---
>>>>  arch/arm/mach-omap2/vc.c          |   35 +++++++++++++++++++----------------
>>>>  arch/arm/mach-omap2/vc.h          |   33 +++++++++++++++++++++++++++++++++
>>>>  arch/arm/mach-omap2/vc44xx_data.c |   10 ++++++++++
>>>>  3 files changed, 62 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
>>>> index f8185d2..2add945 100644
>>>> --- a/arch/arm/mach-omap2/vc.c
>>>> +++ b/arch/arm/mach-omap2/vc.c
>> [..]
>>>>
>>>> +     /* if there is an exception case, use the exception data */
>>>> +     if (!vc->cfg_ch_data)
>>>> +             cfg_channel_data = &cfg_channel_common;
>>>> +     else
>>>> +             cfg_channel_data = vc->cfg_ch_data;
>>>
>>> Based on the above,  this block could be dropped, and...
>>
>> Except I will have to replicate this for OMAP3 and 4 - which is
>> possible.. but replicated data which is needed only during init
>
> Yes, but remember we are trying to keep data separated from code.
> Eventually, much of this data will likely be migrated to the device
> tree, so we want to be sure our data is cleanly separated from code.
>
>> :( did not want vc pointer to contain __initdata pointer (dangling
>> ones after boot)
>
> Yes, so far, we're not using initdata for per-SoC stuff, and there have
> been proposals around that.  However, moving to device tree will largely
> solve the per-SoC bloat issues around that.

ok. will post a new rev as soon as I get free.

Regards,
Nishanth Menon
--
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

[PM-WIP/voltdm_c][PATCH 07/11] OMAP4: PM: TWL6030: fix voltage conversion formula

[Nishanth Menon]

From: Patrick Titiano <p-titiano@ti.com>

omap_twl_vsel_to_uv() and omap_twl_uv_to_vsel() functions used to convert
voltages to TWL6030 SMPS commands (a.k.a "vsel") implement incorrect conversion
formula.
It uses legacy OMAP3 formula, but OMAP4 Power IC has different offset and
voltage step:
 - Voltage Step is now 12.66mV (instead of 12.5mV)
 - Offset is either 607.7mV or 709mV depending on TWL6030 chip revision
   (instead of 600mV)
This leads to setting voltages potentially higher than expected, and so
potentially some (limited) power overconsumption.

For reference, see formula and tables in section 8.5.2.3
"Output Voltage Selection (Standard Mode / Extended Mode with or without offset)"
 in TWL6030 functional specifications document.

[nm@ti.com: ported to voltdm_c]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Patrick Titiano <p-titiano@ti.com>
---
 arch/arm/mach-omap2/omap_twl.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 82a91be..78fd985 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -106,9 +106,9 @@ static unsigned long twl6030_vsel_to_uv(const u8 vsel)
 		return 1350000;
 
 	if (smps_offset & 0x8)
-		return ((((vsel - 1) * 125) + 7000)) * 100;
+		return ((((vsel - 1) * 1266) + 70900)) * 10;
 	else
-		return ((((vsel - 1) * 125) + 6000)) * 100;
+		return ((((vsel - 1) * 1266) + 60770)) * 10;
 }
 
 static u8 twl6030_uv_to_vsel(unsigned long uv)
@@ -138,9 +138,9 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
 		return 0x3A;
 
 	if (smps_offset & 0x8)
-		return DIV_ROUND_UP(uv - 700000, 12500) + 1;
+		return DIV_ROUND_UP(uv - 709000, 12660) + 1;
 	else
-		return DIV_ROUND_UP(uv - 600000, 12500) + 1;
+		return DIV_ROUND_UP(uv - 607700, 12660) + 1;
 }
 
 static struct omap_voltdm_pmic omap3_mpu_pmic = {
@@ -187,7 +187,7 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
 
 static struct omap_voltdm_pmic omap4_mpu_pmic = {
 	.slew_rate		= 4000,
-	.step_size		= 12500,
+	.step_size		= 12660,
 	.on_volt		= 1350000,
 	.onlp_volt		= 1350000,
 	.ret_volt		= 837500,
@@ -212,7 +212,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
 
 static struct omap_voltdm_pmic omap4_iva_pmic = {
 	.slew_rate		= 4000,
-	.step_size		= 12500,
+	.step_size		= 12660,
 	.on_volt		= 1100000,
 	.onlp_volt		= 1100000,
 	.ret_volt		= 837500,
@@ -237,7 +237,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
 
 static struct omap_voltdm_pmic omap4_core_pmic = {
 	.slew_rate		= 4000,
-	.step_size		= 12500,
+	.step_size		= 12660,
 	.on_volt		= 1100000,
 	.onlp_volt		= 1100000,
 	.ret_volt		= 837500,
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 07/11] OMAP4: PM: TWL6030: fix voltage conversion formula

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> From: Patrick Titiano <p-titiano@ti.com>
>
> omap_twl_vsel_to_uv() and omap_twl_uv_to_vsel() functions used to convert
> voltages to TWL6030 SMPS commands (a.k.a "vsel") implement incorrect conversion
> formula.
> It uses legacy OMAP3 formula, but OMAP4 Power IC has different offset and
> voltage step:
>  - Voltage Step is now 12.66mV (instead of 12.5mV)
>  - Offset is either 607.7mV or 709mV depending on TWL6030 chip revision
>    (instead of 600mV)
> This leads to setting voltages potentially higher than expected, and so
> potentially some (limited) power overconsumption.
>
> For reference, see formula and tables in section 8.5.2.3
> "Output Voltage Selection (Standard Mode / Extended Mode with or without offset)"
>  in TWL6030 functional specifications document.
>
> [nm@ti.com: ported to voltdm_c]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Patrick Titiano <p-titiano@ti.com>

Thanks, adding to voltdm queue.

Kevin

> ---
>  arch/arm/mach-omap2/omap_twl.c |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 82a91be..78fd985 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -106,9 +106,9 @@ static unsigned long twl6030_vsel_to_uv(const u8 vsel)
>  		return 1350000;
>  
>  	if (smps_offset & 0x8)
> -		return ((((vsel - 1) * 125) + 7000)) * 100;
> +		return ((((vsel - 1) * 1266) + 70900)) * 10;
>  	else
> -		return ((((vsel - 1) * 125) + 6000)) * 100;
> +		return ((((vsel - 1) * 1266) + 60770)) * 10;
>  }
>  
>  static u8 twl6030_uv_to_vsel(unsigned long uv)
> @@ -138,9 +138,9 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
>  		return 0x3A;
>  
>  	if (smps_offset & 0x8)
> -		return DIV_ROUND_UP(uv - 700000, 12500) + 1;
> +		return DIV_ROUND_UP(uv - 709000, 12660) + 1;
>  	else
> -		return DIV_ROUND_UP(uv - 600000, 12500) + 1;
> +		return DIV_ROUND_UP(uv - 607700, 12660) + 1;
>  }
>  
>  static struct omap_voltdm_pmic omap3_mpu_pmic = {
> @@ -187,7 +187,7 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
>  
>  static struct omap_voltdm_pmic omap4_mpu_pmic = {
>  	.slew_rate		= 4000,
> -	.step_size		= 12500,
> +	.step_size		= 12660,
>  	.on_volt		= 1350000,
>  	.onlp_volt		= 1350000,
>  	.ret_volt		= 837500,
> @@ -212,7 +212,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
>  
>  static struct omap_voltdm_pmic omap4_iva_pmic = {
>  	.slew_rate		= 4000,
> -	.step_size		= 12500,
> +	.step_size		= 12660,
>  	.on_volt		= 1100000,
>  	.onlp_volt		= 1100000,
>  	.ret_volt		= 837500,
> @@ -237,7 +237,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
>  
>  static struct omap_voltdm_pmic omap4_core_pmic = {
>  	.slew_rate		= 4000,
> -	.step_size		= 12500,
> +	.step_size		= 12660,
>  	.on_volt		= 1100000,
>  	.onlp_volt		= 1100000,
>  	.ret_volt		= 837500,

[PM-WIP/voltdm_c][PATCH 08/11] OMAP4: PM: TWL6030: fix uv to voltage for >0x39

[Nishanth Menon]

using 1.35V as a check is not correct, we know that beyond 0x39,
voltages are non linear - hence use the conversion iff uV greater
than that for 0x39. For example, with  709mV as the smps offset,
the max linear is actually 1.41V(0x39vsel)!

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap_twl.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 78fd985..fce7e6d 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -134,8 +134,13 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
 	 * hardcoding only for 1.35 V which is used for 1GH OPP for
 	 * OMAP4430.
 	 */
-	if (uv == 1350000)
+	if (uv > twl6030_vsel_to_uv(0x39)) {
+		if (uv == 1350000)
+			return 0x3A;
+		pr_err("%s:OUT OF RANGE! non mapped vsel for %ld Vs max %ld\n",
+			__func__, uv, twl6030_vsel_to_uv(0x39));
 		return 0x3A;
+	}
 
 	if (smps_offset & 0x8)
 		return DIV_ROUND_UP(uv - 709000, 12660) + 1;
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 08/11] OMAP4: PM: TWL6030: fix uv to voltage for >0x39

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> using 1.35V as a check is not correct, we know that beyond 0x39,
> voltages are non linear - hence use the conversion iff uV greater
> than that for 0x39. For example, with  709mV as the smps offset,
> the max linear is actually 1.41V(0x39vsel)!
>
> Signed-off-by: Nishanth Menon <nm@ti.com>

Thanks, adding to voltdm queue.

Kevin

> ---
>  arch/arm/mach-omap2/omap_twl.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 78fd985..fce7e6d 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -134,8 +134,13 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
>  	 * hardcoding only for 1.35 V which is used for 1GH OPP for
>  	 * OMAP4430.
>  	 */
> -	if (uv == 1350000)
> +	if (uv > twl6030_vsel_to_uv(0x39)) {
> +		if (uv == 1350000)
> +			return 0x3A;
> +		pr_err("%s:OUT OF RANGE! non mapped vsel for %ld Vs max %ld\n",
> +			__func__, uv, twl6030_vsel_to_uv(0x39));
>  		return 0x3A;
> +	}
>  
>  	if (smps_offset & 0x8)
>  		return DIV_ROUND_UP(uv - 709000, 12660) + 1;

[PM-WIP/voltdm_c][PATCH 09/11] OMAP4: PM: TWL6030: address 0V conversions

[Nishanth Menon]

0V conversions should be mapped to 0 as it is meant to denote
off voltages.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap_twl.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index fce7e6d..8b1e93c 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -95,6 +95,8 @@ static unsigned long twl6030_vsel_to_uv(const u8 vsel)
 		is_offset_valid = true;
 	}
 
+	if (!vsel)
+		return 0;
 	/*
 	 * There is no specific formula for voltage to vsel
 	 * conversion above 1.3V. There are special hardcoded
@@ -127,6 +129,8 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
 		is_offset_valid = true;
 	}
 
+	if (!uv)
+		return 0x00;
 	/*
 	 * There is no specific formula for voltage to vsel
 	 * conversion above 1.3V. There are special hardcoded
-- 
1.7.0.4

[PM-WIP/voltdm_c][PATCH 10/11] OMAP4: PM: TWL6030: fix ON/RET/OFF voltages

[Nishanth Menon]

From: Patrick Titiano <p-titiano@ti.com>

According to latest OMAP4430 Data Manual v0.4 dated March 2011:
 - Retention voltage shall be set to 0.83V. See tables 2.2, 2.4 and 2.6 in DM.
   This allows saving a little more power in retention states.
 - OPP100 IVA nominal voltage is 1.188V. See table 2.4 in DM.
   This allows saving a little power when CPU wakes up until Smart-Reflex is
   not yet resumed.

[nm@ti.com: ported to voltdm_c]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Patrick Titiano <p-titiano@ti.com>
---
 arch/arm/mach-omap2/omap_twl.c |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 8b1e93c..54a6e02 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -197,10 +197,10 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
 static struct omap_voltdm_pmic omap4_mpu_pmic = {
 	.slew_rate		= 4000,
 	.step_size		= 12660,
-	.on_volt		= 1350000,
-	.onlp_volt		= 1350000,
-	.ret_volt		= 837500,
-	.off_volt		= 600000,
+	.on_volt		= 1375000,
+	.onlp_volt		= 1375000,
+	.ret_volt		= 830000,
+	.off_volt		= 0,
 	.volt_setup_time	= 0,
 	.vp_erroroffset		= OMAP4_VP_CONFIG_ERROROFFSET,
 	.vp_vstepmin		= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -222,10 +222,10 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
 static struct omap_voltdm_pmic omap4_iva_pmic = {
 	.slew_rate		= 4000,
 	.step_size		= 12660,
-	.on_volt		= 1100000,
-	.onlp_volt		= 1100000,
-	.ret_volt		= 837500,
-	.off_volt		= 600000,
+	.on_volt		= 1188000,
+	.onlp_volt		= 1188000,
+	.ret_volt		= 830000,
+	.off_volt		= 0,
 	.volt_setup_time	= 0,
 	.vp_erroroffset		= OMAP4_VP_CONFIG_ERROROFFSET,
 	.vp_vstepmin		= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -247,10 +247,10 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
 static struct omap_voltdm_pmic omap4_core_pmic = {
 	.slew_rate		= 4000,
 	.step_size		= 12660,
-	.on_volt		= 1100000,
-	.onlp_volt		= 1100000,
-	.ret_volt		= 837500,
-	.off_volt		= 600000,
+	.on_volt		= 1200000,
+	.onlp_volt		= 1200000,
+	.ret_volt		= 830000,
+	.off_volt		= 0,
 	.volt_setup_time	= 0,
 	.vp_erroroffset		= OMAP4_VP_CONFIG_ERROROFFSET,
 	.vp_vstepmin		= OMAP4_VP_VSTEPMIN_VSTEPMIN,
-- 
1.7.0.4

Re: [PM-WIP/voltdm_c][PATCH 10/11] OMAP4: PM: TWL6030: fix ON/RET/OFF voltages

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> From: Patrick Titiano <p-titiano@ti.com>
>
> According to latest OMAP4430 Data Manual v0.4 dated March 2011:
>  - Retention voltage shall be set to 0.83V. See tables 2.2, 2.4 and 2.6 in DM.
>    This allows saving a little more power in retention states.
>  - OPP100 IVA nominal voltage is 1.188V. See table 2.4 in DM.
>    This allows saving a little power when CPU wakes up until Smart-Reflex is
>    not yet resumed.
>
> [nm@ti.com: ported to voltdm_c]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Patrick Titiano <p-titiano@ti.com>

Thanks, adding to voltdm queue.

Kevin

[PM-WIP/voltdm_c][PATCH 11/11] OMAP4: PM: TWL6030: add cmd register

[Nishanth Menon]

Without the command register, ON/ONLP/RET/OFF voltages are
useless. and TWL will be unable to use these

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap_twl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 54a6e02..147e858 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -42,8 +42,11 @@
 
 #define OMAP4_SRI2C_SLAVE_ADDR		0x12
 #define OMAP4_VDD_MPU_SR_VOLT_REG	0x55
+#define OMAP4_VDD_MPU_SR_CMD_REG	0x56
 #define OMAP4_VDD_IVA_SR_VOLT_REG	0x5B
+#define OMAP4_VDD_IVA_SR_CMD_REG	0x5C
 #define OMAP4_VDD_CORE_SR_VOLT_REG	0x61
+#define OMAP4_VDD_CORE_SR_CMD_REG	0x62
 
 #define OMAP4_VP_CONFIG_ERROROFFSET	0x00
 #define OMAP4_VP_VSTEPMIN_VSTEPMIN	0x01
@@ -210,6 +213,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
 	.vp_timeout_us		= OMAP4_VP_VLIMITTO_TIMEOUT_US,
 	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
 	.volt_reg_addr		= OMAP4_VDD_MPU_SR_VOLT_REG,
+	.cmd_reg_addr		= OMAP4_VDD_MPU_SR_CMD_REG,
 	.i2c_high_speed		= true,
 	.i2c_scll_low		= 0x28,
 	.i2c_scll_high		= 0x2C,
@@ -235,6 +239,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
 	.vp_timeout_us		= OMAP4_VP_VLIMITTO_TIMEOUT_US,
 	.i2c_slave_addr		= OMAP4_SRI2C_SLAVE_ADDR,
 	.volt_reg_addr		= OMAP4_VDD_IVA_SR_VOLT_REG,
+	.cmd_reg_addr		= OMAP4_VDD_IVA_SR_CMD_REG,
 	.i2c_high_speed		= true,
 	.i2c_scll_low		= 0x28,
 	.i2c_scll_high		= 0x2C,
@@ -265,6 +270,7 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
 	.i2c_hscll_low		= 0x0B,
 	.i2c_hscll_high		= 0x00,
 	.volt_reg_addr		= OMAP4_VDD_CORE_SR_VOLT_REG,
+	.cmd_reg_addr		= OMAP4_VDD_CORE_SR_CMD_REG,
 	.vsel_to_uv		= twl6030_vsel_to_uv,
 	.uv_to_vsel		= twl6030_uv_to_vsel,
 };
-- 
1.7.0.4