VDD1 voltage after resume from idle

VDD1 voltage after resume from idle

[Premi, Sanjeev]

Hi,
 
I am facing a strange problem on OMAP3EVM after resuming from idle.
When using OPP5, the VDD1 voltage ramps to 1.35V.
 
However, when i go thru the idle/wakeup cycle, the voltage never
ramps back to 1.35V but stays at 1.20V.
 
I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
this problem is not observed there. Actually, here the voltage
did not drop during suspend at all.
 
While I continue to debug, any suggestions?
 
Best regards,
Sanjeev

RE: VDD1 voltage after resume from idle

[Menon, Nishanth]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Friday, November 20, 2009 9:47 AM
> To: linux-omap@vger.kernel.org
> Subject: VDD1 voltage after resume from idle
> 
> Hi,
> 
> I am facing a strange problem on OMAP3EVM after resuming from idle.
> When using OPP5, the VDD1 voltage ramps to 1.35V.
> 
> However, when i go thru the idle/wakeup cycle, the voltage never
> ramps back to 1.35V but stays at 1.20V.
> 
> I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
> this problem is not observed there. Actually, here the voltage
> did not drop during suspend at all.
> 
> While I continue to debug, any suggestions?

Look for retention voltage setup (they should be OPP dependent).. 
this was one of my plans of cleanups anyways..

> 
> Best regards,
> Sanjeev

Regards,
Nishanth Menon

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth 
> Sent: Friday, November 20, 2009 9:19 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: VDD1 voltage after resume from idle
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
> > Sent: Friday, November 20, 2009 9:47 AM
> > To: linux-omap@vger.kernel.org
> > Subject: VDD1 voltage after resume from idle
> > 
> > Hi,
> > 
> > I am facing a strange problem on OMAP3EVM after resuming from idle.
> > When using OPP5, the VDD1 voltage ramps to 1.35V.
> > 
> > However, when i go thru the idle/wakeup cycle, the voltage never
> > ramps back to 1.35V but stays at 1.20V.
> > 
> > I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
> > this problem is not observed there. Actually, here the voltage
> > did not drop during suspend at all.
> > 
> > While I continue to debug, any suggestions?
> 
> Look for retention voltage setup (they should be OPP dependent).. 
> this was one of my plans of cleanups anyways..

So far the problem seems to be optimizations in the enable_smartreflex and
disable_smartreflex.

On resume path, enable_smartreflex() is called, but doesn't do anything
unless autocomp flag is on. This is different from the boot-time where
the current freq is looked at and appropriate voltage is set.

I am currently trying to get rid of optimizations and see the result.
We do need the optimizations; but may be different ones.

~sanjeev

> 
> > 
> > Best regards,
> > Sanjeev
> 
> Regards,
> Nishanth Menon
> 
> 

RE: VDD1 voltage after resume from idle

[Menon, Nishanth]

> From: Premi, Sanjeev
> Sent: Friday, November 20, 2009 9:54 AM
> > >
> > > Hi,
> > >
> > > I am facing a strange problem on OMAP3EVM after resuming from idle.
> > > When using OPP5, the VDD1 voltage ramps to 1.35V.
> > >
> > > However, when i go thru the idle/wakeup cycle, the voltage never
> > > ramps back to 1.35V but stays at 1.20V.
> > >
> > > I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
> > > this problem is not observed there. Actually, here the voltage
> > > did not drop during suspend at all.
> > >
> > > While I continue to debug, any suggestions?
> >
> > Look for retention voltage setup (they should be OPP dependent)..
> > this was one of my plans of cleanups anyways..
> 
> So far the problem seems to be optimizations in the enable_smartreflex and
> disable_smartreflex.
> 
> On resume path, enable_smartreflex() is called, but doesn't do anything
> unless autocomp flag is on. This is different from the boot-time where
> the current freq is looked at and appropriate voltage is set.
> 
> I am currently trying to get rid of optimizations and see the result.
> We do need the optimizations; but may be different ones.
What specific optimization are you talking about?
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=blob;f=arch/arm/mach-omap2/resource34xx.c;h=04be4d26945beccf81cad08a8cdfc6086d6ce70a;hb=refs/heads/pm#l277 ?
Regards,
Nishanth Menon

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth 
> Sent: Friday, November 20, 2009 9:29 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: VDD1 voltage after resume from idle
> 
> > From: Premi, Sanjeev
> > Sent: Friday, November 20, 2009 9:54 AM
> > > >
> > > > Hi,
> > > >
> > > > I am facing a strange problem on OMAP3EVM after 
> resuming from idle.
> > > > When using OPP5, the VDD1 voltage ramps to 1.35V.
> > > >
> > > > However, when i go thru the idle/wakeup cycle, the voltage never
> > > > ramps back to 1.35V but stays at 1.20V.
> > > >
> > > > I don't notice many changes in smartreflex.c since 
> 2.6.31-rc7 but
> > > > this problem is not observed there. Actually, here the voltage
> > > > did not drop during suspend at all.
> > > >
> > > > While I continue to debug, any suggestions?
> > >
> > > Look for retention voltage setup (they should be OPP dependent)..
> > > this was one of my plans of cleanups anyways..
> > 
> > So far the problem seems to be optimizations in the 
> enable_smartreflex and
> > disable_smartreflex.
> > 
> > On resume path, enable_smartreflex() is called, but doesn't 
> do anything
> > unless autocomp flag is on. This is different from the 
> boot-time where
> > the current freq is looked at and appropriate voltage is set.
> > 
> > I am currently trying to get rid of optimizations and see 
> the result.
> > We do need the optimizations; but may be different ones.
> What specific optimization are you talking about?
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p
> m.git;a=blob;f=arch/arm/mach-omap2/resource34xx.c;h=04be4d2694
> 5beccf81cad08a8cdfc6086d6ce70a;hb=refs/heads/pm#l277 ?

I not using SRF - vanilla no-op layer.

The optimization is check for is_autocomp_active and is_sr_reset flags.
unless both are set, there is no real processing in the both the functions.

However, I it is possible that voltage processor has lost the configuration
set earlier via sr_configure_vp(). Only thing still puzzling me is that
same behavior occurs even when enable_off_mode=0 (Only sleep_while_idle=1).

Or, it may just be something missing at init...

Best regards,
Sanjeev

> Regards,
> Nishanth Menon
> 

Re: VDD1 voltage after resume from idle

[Maxime Petazzoni]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

Hi,

* Premi, Sanjeev <premi@ti.com> [2009-11-20 21:17:04]:

> I am facing a strange problem on OMAP3EVM after resuming from idle.
> When using OPP5, the VDD1 voltage ramps to 1.35V.
>  
> However, when i go thru the idle/wakeup cycle, the voltage never
> ramps back to 1.35V but stays at 1.20V.

I'm seeing some interesting behavior with the OPP values here, too, with
suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:

When changing the CPU frequency through the scaling_setfreq knob of
CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
suspend/resume cycles, the OPPs return to their pre-suspend values, all
is fine.

But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
the CPU frequency is changed accordingly, which is expected. But after a
suspend/resume cycle, the OPP values return to the value CPUFREQ set
them to (which may be different than the default OPP values of 3).

Is this the normal behavior? Is cpufreq authoritative on the OPP values
on resume? Or should it follow whatever value was manually set before
suspending?

Thanks,
- Maxime

PS: if I was not clear, I can provide a console log that may be more
explicit--just ask.

-- 
Maxime Petazzoni
Linux kernel & software dev
MontaVista Software, Inc

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -----Original Message-----
> From: Maxime Petazzoni [mailto:mpetazzoni@mvista.com] 
> Sent: Friday, November 20, 2009 10:00 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: VDD1 voltage after resume from idle
> 
> Hi,
> 
> * Premi, Sanjeev <premi@ti.com> [2009-11-20 21:17:04]:
> 
> > I am facing a strange problem on OMAP3EVM after resuming from idle.
> > When using OPP5, the VDD1 voltage ramps to 1.35V.
> >  
> > However, when i go thru the idle/wakeup cycle, the voltage never
> > ramps back to 1.35V but stays at 1.20V.
> 
> I'm seeing some interesting behavior with the OPP values 
> here, too, with
> suspend/resume. I'm using SRF based PM and CPUFREQ. Here's 
> what happens:
> 
> When changing the CPU frequency through the scaling_setfreq knob of
> CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> suspend/resume cycles, the OPPs return to their pre-suspend 
> values, all
> is fine.
> 
> But when changing the OPP values by hand through the 
> vdd{1,2}_opp knobs,
> the CPU frequency is changed accordingly, which is expected. 
> But after a
> suspend/resume cycle, the OPP values return to the value CPUFREQ set
> them to (which may be different than the default OPP values of 3).
> 
> Is this the normal behavior? Is cpufreq authoritative on the 
> OPP values
> on resume? Or should it follow whatever value was manually set before
> suspending?

I guess the root cause could be same. I have not been able to ascertain
the reason for the voltage changing during the idle/wakeup sequence.
Also tried to eliminate the enable_smartreflex() calls on wakeup path.
Sill I see voltage ramp-up.

I am trying to find the cause of voltage ramping to 1.2V in hope that
the reason for ramp down will be just inverted reflection.

With smartreflex disabled, there is no change in the voltage during
suspend; so the problem area seems to be smartreflex.

Best regards,
Sanjeev

> 
> Thanks,
> - Maxime
> 
> PS: if I was not clear, I can provide a console log that may be more
> explicit--just ask.
> 
> -- 
> Maxime Petazzoni
> Linux kernel & software dev
> MontaVista Software, Inc
> 

Re: VDD1 voltage after resume from idle

[Kevin Hilman]

Maxime Petazzoni <mpetazzoni@mvista.com> writes:

> Hi,
>
> * Premi, Sanjeev <premi@ti.com> [2009-11-20 21:17:04]:
>
>> I am facing a strange problem on OMAP3EVM after resuming from idle.
>> When using OPP5, the VDD1 voltage ramps to 1.35V.
>>  
>> However, when i go thru the idle/wakeup cycle, the voltage never
>> ramps back to 1.35V but stays at 1.20V.
>
> I'm seeing some interesting behavior with the OPP values here, too, with
> suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:
>
> When changing the CPU frequency through the scaling_setfreq knob of
> CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> suspend/resume cycles, the OPPs return to their pre-suspend values, all
> is fine.
>
> But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
> the CPU frequency is changed accordingly, which is expected. But after a
> suspend/resume cycle, the OPP values return to the value CPUFREQ set
> them to (which may be different than the default OPP values of 3).
>
> Is this the normal behavior? Is cpufreq authoritative on the OPP values
> on resume? Or should it follow whatever value was manually set before
> suspending?

FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
be considered experimental (a.k.a broken.) They will disappear from
the PM branch shortly.

CPUfreq should be the only interface used for DVFS.

Kevin

Re: VDD1 voltage after resume from idle

[Maxime Petazzoni]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

* Kevin Hilman <khilman@deeprootsystems.com> [2009-11-20 10:29:02]:

> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
> be considered experimental (a.k.a broken.) They will disappear from
> the PM branch shortly.
> 
> CPUfreq should be the only interface used for DVFS.

Ah, well then I guess that fixes my problem. So, was I right on saying
that CPUfreq is "taking control" of the OPP values on wake up? (just
trying to make sure I understand how this works correctly).

Thanks for the info,
- Maxime
-- 
Maxime Petazzoni
Linux kernel & software dev
MontaVista Software, Inc

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: VDD1 voltage after resume from idle

[Jean Pihet]

Hi Kevin,

On Friday 20 November 2009 19:29:02 Kevin Hilman wrote:
> Maxime Petazzoni <mpetazzoni@mvista.com> writes:
> > Hi,
> >
> > * Premi, Sanjeev <premi@ti.com> [2009-11-20 21:17:04]:
> >> I am facing a strange problem on OMAP3EVM after resuming from idle.
> >> When using OPP5, the VDD1 voltage ramps to 1.35V.
> >>
> >> However, when i go thru the idle/wakeup cycle, the voltage never
> >> ramps back to 1.35V but stays at 1.20V.
> >
> > I'm seeing some interesting behavior with the OPP values here, too, with
> > suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:
> >
> > When changing the CPU frequency through the scaling_setfreq knob of
> > CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> > suspend/resume cycles, the OPPs return to their pre-suspend values, all
> > is fine.
> >
> > But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
> > the CPU frequency is changed accordingly, which is expected. But after a
> > suspend/resume cycle, the OPP values return to the value CPUFREQ set
> > them to (which may be different than the default OPP values of 3).
> >
> > Is this the normal behavior? Is cpufreq authoritative on the OPP values
> > on resume? Or should it follow whatever value was manually set before
> > suspending?
>
> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
> be considered experimental (a.k.a broken.) They will disappear from
> the PM branch shortly.
>
> CPUfreq should be the only interface used for DVFS.
Could the PM page on elinux.org be updated with that info? I am proposing to 
change it before you ask me ;p

>
> Kevin

Thanks,
Jean

> --
> 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: VDD1 voltage after resume from idle

[Kevin Hilman]

Jean Pihet <jpihet@mvista.com> writes:

> Hi Kevin,
>
> On Friday 20 November 2009 19:29:02 Kevin Hilman wrote:
>> Maxime Petazzoni <mpetazzoni@mvista.com> writes:
>> > Hi,
>> >
>> > * Premi, Sanjeev <premi@ti.com> [2009-11-20 21:17:04]:
>> >> I am facing a strange problem on OMAP3EVM after resuming from idle.
>> >> When using OPP5, the VDD1 voltage ramps to 1.35V.
>> >>
>> >> However, when i go thru the idle/wakeup cycle, the voltage never
>> >> ramps back to 1.35V but stays at 1.20V.
>> >
>> > I'm seeing some interesting behavior with the OPP values here, too, with
>> > suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:
>> >
>> > When changing the CPU frequency through the scaling_setfreq knob of
>> > CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
>> > suspend/resume cycles, the OPPs return to their pre-suspend values, all
>> > is fine.
>> >
>> > But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
>> > the CPU frequency is changed accordingly, which is expected. But after a
>> > suspend/resume cycle, the OPP values return to the value CPUFREQ set
>> > them to (which may be different than the default OPP values of 3).
>> >
>> > Is this the normal behavior? Is cpufreq authoritative on the OPP values
>> > on resume? Or should it follow whatever value was manually set before
>> > suspending?
>>
>> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
>> be considered experimental (a.k.a broken.) They will disappear from
>> the PM branch shortly.
>>
>> CPUfreq should be the only interface used for DVFS.
> Could the PM page on elinux.org be updated with that info? I am proposing to 
> change it before you ask me ;p

Done.

I added the following note to the 'opp control' section.

OPP control via sysfs is deprecated. Please use CPUfreq interfaces for DVFS. 

Re: VDD1 voltage after resume from idle

[Jean Pihet]

On Friday 20 November 2009 20:11:26 Kevin Hilman wrote:
> Jean Pihet <jpihet@mvista.com> writes:
> > Hi Kevin,
> >
> > On Friday 20 November 2009 19:29:02 Kevin Hilman wrote:
> >> Maxime Petazzoni <mpetazzoni@mvista.com> writes:
> >> > Hi,
> >> >
> >> > * Premi, Sanjeev <premi@ti.com> [2009-11-20 21:17:04]:
> >> >> I am facing a strange problem on OMAP3EVM after resuming from idle.
> >> >> When using OPP5, the VDD1 voltage ramps to 1.35V.
> >> >>
> >> >> However, when i go thru the idle/wakeup cycle, the voltage never
> >> >> ramps back to 1.35V but stays at 1.20V.
> >> >
> >> > I'm seeing some interesting behavior with the OPP values here, too,
> >> > with suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what
> >> > happens:
> >> >
> >> > When changing the CPU frequency through the scaling_setfreq knob of
> >> > CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> >> > suspend/resume cycles, the OPPs return to their pre-suspend values,
> >> > all is fine.
> >> >
> >> > But when changing the OPP values by hand through the vdd{1,2}_opp
> >> > knobs, the CPU frequency is changed accordingly, which is expected.
> >> > But after a suspend/resume cycle, the OPP values return to the value
> >> > CPUFREQ set them to (which may be different than the default OPP
> >> > values of 3).
> >> >
> >> > Is this the normal behavior? Is cpufreq authoritative on the OPP
> >> > values on resume? Or should it follow whatever value was manually set
> >> > before suspending?
> >>
> >> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
> >> be considered experimental (a.k.a broken.) They will disappear from
> >> the PM branch shortly.
> >>
> >> CPUfreq should be the only interface used for DVFS.
> >
> > Could the PM page on elinux.org be updated with that info? I am proposing
> > to change it before you ask me ;p
>
> Done.
>
> I added the following note to the 'opp control' section.
>
> OPP control via sysfs is deprecated. Please use CPUfreq interfaces for
> DVFS.
Thanks!

Jean

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Friday, November 20, 2009 11:46 PM
> To: Maxime Petazzoni
> Cc: linux-omap@vger.kernel.org
> Subject: RE: VDD1 voltage after resume from idle
> 
> > -----Original Message-----
> > From: Maxime Petazzoni [mailto:mpetazzoni@mvista.com] 
> > Sent: Friday, November 20, 2009 10:00 PM
> > To: Premi, Sanjeev
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: VDD1 voltage after resume from idle
> > 

[snip]--[snip]--[snip]

> 
> I guess the root cause could be same. I have not been able to 
> ascertain
> the reason for the voltage changing during the idle/wakeup sequence.
> Also tried to eliminate the enable_smartreflex() calls on wakeup path.
> Sill I see voltage ramp-up.
> 
> I am trying to find the cause of voltage ramping to 1.2V in hope that
> the reason for ramp down will be just inverted reflection.
> 
> With smartreflex disabled, there is no change in the voltage during
> suspend; so the problem area seems to be smartreflex.
> 
> Best regards,
> Sanjeev

Found the problem!

In sr_configure_vp() the vsel is picked up from the OPP table and used,
setting the voltage as expected (1.35V in my case).

A printk confirms PRM_VC_CMD_VAL_0 is 0x3C201E00. 

By the time, kernel boots up, the value has changed to 0x30201E00.
(0x30 corresponds to 1.2V)

[root@OMAP3EVM /]# devmem 0x4830722c 32
0x30201E00

Now, when I update the init voltage back to 3C (via devmem) the voltage
after resume/idle-wakeup is right (as expected).

[root@OMAP3EVM /]# devmem 0x4830722c 32 0x3c201e00
[root@OMAP3EVM /]#

So, I just need to find exact location where the configuration is being
overwritten.

It is well past midnight now. So the patch will have to wait until
tomorrow.

Best regards,
Sanjeev

[snip]--[snip]--[snip]

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -----Original Message-----
> From: Premi, Sanjeev 
> Sent: Saturday, November 21, 2009 1:04 AM
> To: Premi, Sanjeev; Maxime Petazzoni
> Cc: linux-omap@vger.kernel.org
> Subject: RE: VDD1 voltage after resume from idle
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org 
> > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of 
> Premi, Sanjeev
> > Sent: Friday, November 20, 2009 11:46 PM
> > To: Maxime Petazzoni
> > Cc: linux-omap@vger.kernel.org
> > Subject: RE: VDD1 voltage after resume from idle
> > 
> > > -----Original Message-----
> > > From: Maxime Petazzoni [mailto:mpetazzoni@mvista.com] 
> > > Sent: Friday, November 20, 2009 10:00 PM
> > > To: Premi, Sanjeev
> > > Cc: linux-omap@vger.kernel.org
> > > Subject: Re: VDD1 voltage after resume from idle
> > > 
> 
> [snip]--[snip]--[snip]
> 
> > 
> > I guess the root cause could be same. I have not been able to 
> > ascertain
> > the reason for the voltage changing during the idle/wakeup sequence.
> > Also tried to eliminate the enable_smartreflex() calls on 
> wakeup path.
> > Sill I see voltage ramp-up.
> > 
> > I am trying to find the cause of voltage ramping to 1.2V in 
> hope that
> > the reason for ramp down will be just inverted reflection.
> > 
> > With smartreflex disabled, there is no change in the voltage during
> > suspend; so the problem area seems to be smartreflex.
> > 
> > Best regards,
> > Sanjeev
> 
> Found the problem!
> 
> In sr_configure_vp() the vsel is picked up from the OPP table 
> and used,
> setting the voltage as expected (1.35V in my case).
> 
> A printk confirms PRM_VC_CMD_VAL_0 is 0x3C201E00. 
> 
> By the time, kernel boots up, the value has changed to 0x30201E00.
> (0x30 corresponds to 1.2V)
> 
> [root@OMAP3EVM /]# devmem 0x4830722c 32
> 0x30201E00
> 
> Now, when I update the init voltage back to 3C (via devmem) 
> the voltage
> after resume/idle-wakeup is right (as expected).
> 
> [root@OMAP3EVM /]# devmem 0x4830722c 32 0x3c201e00
> [root@OMAP3EVM /]#
> 
> So, I just need to find exact location where the 
> configuration is being
> overwritten.

Correction. Though I expected/assumed VSEL to be written to this
Location. It wasn't the case. VSEL is used to update the ON voltage
Field in PRM_VP1_CONFIG; but not the PRM_VC_CMD_VAL_0.

Haven't tried (too hard) to find initiator programming this reg in
kernel - so, it might be retaining values from u-boot.

After ensuring that PRM_VC_CMD_VAL_0,1 are updated based on the
VSEL values in current opp tables, the problem seems to be fixed.

Patch from my working tree following soon for review. Will refresh
it against /pm, if needed, there are no comments.

Best regards,
Sanjeev

> 
> It is well past midnight now. So the patch will have to wait until
> tomorrow.
> 
> Best regards,
> Sanjeev
> 
> [snip]--[snip]--[snip]
>