omap voltage management

omap voltage management

[Ran Shalit]

Hello,

I am using DM8148 and I get error message in boot that voltage
management driver is not added.
Is it supported in DM8148. If not - why ?

Thank you,
Ran

Re: omap voltage management

[Tony Lindgren]

* Ran Shalit <ranshalit@gmail.com> [150319 13:05]:
> Hello,
> 
> I am using DM8148 and I get error message in boot that voltage
> management driver is not added.
> Is it supported in DM8148. If not - why ?

We currently are missing dm8148 support from mainline, dm8168
does have basic support now. Adding dm8148 will hopefully happen
too with time permitting :)

Regards,

Tony

Re: omap voltage management

[Ran Shalit]

> We currently are missing dm8148 support from mainline, dm8168
> does have basic support now. Adding dm8148 will hopefully happen
> too with time permitting :)
>

Hi Tony,

What is exactly the "voltage driver" capability ? Does it mean that it
does not support AVS (feature for power saving) ?

Regards,
Ran

Re: omap voltage management

[Ran Shalit]

On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit <ranshalit@gmail.com> wrote:
>> We currently are missing dm8148 support from mainline, dm8168
>> does have basic support now. Adding dm8148 will hopefully happen
>> too with time permitting :)
>>
>
> Hi Tony,
>
> What is exactly the "voltage driver" capability ? Does it mean that it
> does not support AVS (feature for power saving) ?
>
> Regards,
> Ran

Hi Tony,

Is it AVS or "voltage scaling" (used with cpufreq) ?

Thank you,
Ran

Re: omap voltage management

[Tony Lindgren]

* Ran Shalit <ranshalit@gmail.com> [150321 12:18]:
> On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit <ranshalit@gmail.com> wrote:
> >> We currently are missing dm8148 support from mainline, dm8168
> >> does have basic support now. Adding dm8148 will hopefully happen
> >> too with time permitting :)
> >>
> >
> > Hi Tony,
> >
> > What is exactly the "voltage driver" capability ? Does it mean that it
> > does not support AVS (feature for power saving) ?
> >
> > Regards,
> > Ran
> 
> Hi Tony,
> 
> Is it AVS or "voltage scaling" (used with cpufreq) ?

Nishanth might be able to summarize what all is happening :)

Regards,

Tony

Re: omap voltage management

[Nishanth Menon]

On Wed, Mar 25, 2015 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ran Shalit <ranshalit@gmail.com> [150321 12:18]:
>> On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit <ranshalit@gmail.com> wrote:
>> >> We currently are missing dm8148 support from mainline, dm8168
>> >> does have basic support now. Adding dm8148 will hopefully happen
>> >> too with time permitting :)
>> >>
>> >
>> > Hi Tony,
>> >
>> > What is exactly the "voltage driver" capability ? Does it mean that it
>> > does not support AVS (feature for power saving) ?
>> >
>> > Regards,
>> > Ran
>>
>> Hi Tony,
>>
>> Is it AVS or "voltage scaling" (used with cpufreq) ?
>
> Nishanth might be able to summarize what all is happening :)

Oh Boy, where do i start?????

Overall.... quick < 5 min write up:

PMIC Voltage rail-> voltage domain -> power domain -> clock domain -> clocks IP
TRM for each OMAP technology IPs should show how this looks like

Voltage domain and voltage rail can be tweaked depending on how the
frequency of IPs are.
We do a lot of stuff to save power depending on SoC family.. Some
places like OMAP5/DRA7 certain features might be originally designed,
but later descoped due to various other reasons.. anyways..

Lets take OMAP3 and beagleboard as an example
SMPS1 supplies MPU voltage domain that has MPU power domain and A8 under it

MPU DPLL clocks A8, and you can play around with frequency for it.. as
we reduce frequency, we can actually operate it at lower voltage -
these are discrete pairs called OPPs - even though intermediate
frequencies are possible to function, SoC companies like TI cannot
test all possible combinations, so do not guarentee functionality at
intermediate frequencies beyond what is provided in the data sheet.

we let cpufreq control that depending on the various load conditions...

For a specific frequency, the simplest thing is just reduce voltage -
but can we do better? ofcourse yes. it kinda plays with how SoC
production wafers behave.. and the silicon process itself.. this is
where AVS comes into play - AVS (or Adaptive Voltage Scaling) is a set
of different techniques depending on the SoC and process node, process
type etc.. but basically, the game is to find the least possible
voltage for functioning at frequency X, for a specific sample instance
at a certain point in time. AVS class0, class1, 1.5, 2 and class 3 are
some of the techniques used, there are aspects of temperature
compensation on certain SoCs as well. But this just ensures that the
worst possible usecase can still function at frequency X and tries to
reduce voltage below the OPP start voltage point (start voltage is
called nominal voltage in some parts of TI)..

Now, for the specific frequency, you can play further games by
controlling transistor leakage by providing a bias voltage - this is
called ABB - which is an SoC internal LDO, which can be controlled as
well - we can reverse or forward bias depending on vdd (voltage domain
voltage)

in a nut shell:
- A8 can operate in multiple frequencies
- for each frequency X, we can come with a common voltage which works
on every single silicon for every time for worst case usecase for the
worst possible conditions - we call this as nominal voltage(Y), this,
and the tuple (X,Y) is what we define as OPP - which is generic for
any OMAP3 sample.
- to do optimization per sample, we now need to tweak Y to lower value
- this is done along with tweaking ABB. - this ensures that as little
leakage of transistor at the least voltage is used for achieving
frequency X.


Does the game end there? nope. we can play even more.. Lets say at
frequency X, we dont have anything to do... ok, we can go to lower
power state - cpuidle, here we can gate clocks and go into different
deeper power saving states which trades off with wakeup latency
times.. at some lower power states, we dont even need the AVS
optimized voltage anymore.. - the voltage for operating in low power
state is called retention voltage - only some SoCs+PMIC combination
have ability to automatically do this since A8 itself is in idle when
the SoC decides it can achieve this low power state.


So voltage driver is a bit of a misnomer...
- Do we have a common entity that can ensure sequencing of AVS, ABB,
frequency in the right order in upstream - answer is no.. I did
attempt to post [1] but folks did not like it yet.. and i have'nt had
time to respin it - actually I dont really know where to go given that
maintainers differ in opinions..
- can we control a smps PMIC power supply? yeah - regulator framework
and corresponding regulator driver
- can we control ABB - yep - we have abb regulator driver in upstream
- can we control frequency - yep - all clock framework stuff
- what do we need for avs support? - well... VC and VP need to become
dt only (attempted[2]-but got killed), then AVS smartreflex need to be
modified to fit into that new framework - again dt-fication pending..
never got around to it..

my wish list from long time[3] is still waiting...

Hope this helps..

[1] https://lwn.net/Articles/587018/
[2] https://lkml.org/lkml/2013/5/22/471
[3] https://plus.google.com/112464029509057661457/posts/gvyZQcNieoq

-- 
---
Regards,
Nishanth Menon

Re: omap voltage management

[Ryan]

Hi,

I would like to ask a related question here

If i use performance governor alone - constantly running at the
highest frequency. Does the smart reflex still has a role to play?
Does smart-reflex involves reprogramming only the mpu power line alone?


Regards,
Ryan

On Thu, Mar 26, 2015 at 4:17 AM, Nishanth Menon <nm@ti.com> wrote:
> On Wed, Mar 25, 2015 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Ran Shalit <ranshalit@gmail.com> [150321 12:18]:
>>> On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit <ranshalit@gmail.com> wrote:
>>> >> We currently are missing dm8148 support from mainline, dm8168
>>> >> does have basic support now. Adding dm8148 will hopefully happen
>>> >> too with time permitting :)
>>> >>
>>> >
>>> > Hi Tony,
>>> >
>>> > What is exactly the "voltage driver" capability ? Does it mean that it
>>> > does not support AVS (feature for power saving) ?
>>> >
>>> > Regards,
>>> > Ran
>>>
>>> Hi Tony,
>>>
>>> Is it AVS or "voltage scaling" (used with cpufreq) ?
>>
>> Nishanth might be able to summarize what all is happening :)
>
> Oh Boy, where do i start?????
>
> Overall.... quick < 5 min write up:
>
> PMIC Voltage rail-> voltage domain -> power domain -> clock domain -> clocks IP
> TRM for each OMAP technology IPs should show how this looks like
>
> Voltage domain and voltage rail can be tweaked depending on how the
> frequency of IPs are.
> We do a lot of stuff to save power depending on SoC family.. Some
> places like OMAP5/DRA7 certain features might be originally designed,
> but later descoped due to various other reasons.. anyways..
>
> Lets take OMAP3 and beagleboard as an example
> SMPS1 supplies MPU voltage domain that has MPU power domain and A8 under it
>
> MPU DPLL clocks A8, and you can play around with frequency for it.. as
> we reduce frequency, we can actually operate it at lower voltage -
> these are discrete pairs called OPPs - even though intermediate
> frequencies are possible to function, SoC companies like TI cannot
> test all possible combinations, so do not guarentee functionality at
> intermediate frequencies beyond what is provided in the data sheet.
>
> we let cpufreq control that depending on the various load conditions...
>
> For a specific frequency, the simplest thing is just reduce voltage -
> but can we do better? ofcourse yes. it kinda plays with how SoC
> production wafers behave.. and the silicon process itself.. this is
> where AVS comes into play - AVS (or Adaptive Voltage Scaling) is a set
> of different techniques depending on the SoC and process node, process
> type etc.. but basically, the game is to find the least possible
> voltage for functioning at frequency X, for a specific sample instance
> at a certain point in time. AVS class0, class1, 1.5, 2 and class 3 are
> some of the techniques used, there are aspects of temperature
> compensation on certain SoCs as well. But this just ensures that the
> worst possible usecase can still function at frequency X and tries to
> reduce voltage below the OPP start voltage point (start voltage is
> called nominal voltage in some parts of TI)..
>
> Now, for the specific frequency, you can play further games by
> controlling transistor leakage by providing a bias voltage - this is
> called ABB - which is an SoC internal LDO, which can be controlled as
> well - we can reverse or forward bias depending on vdd (voltage domain
> voltage)
>
> in a nut shell:
> - A8 can operate in multiple frequencies
> - for each frequency X, we can come with a common voltage which works
> on every single silicon for every time for worst case usecase for the
> worst possible conditions - we call this as nominal voltage(Y), this,
> and the tuple (X,Y) is what we define as OPP - which is generic for
> any OMAP3 sample.
> - to do optimization per sample, we now need to tweak Y to lower value
> - this is done along with tweaking ABB. - this ensures that as little
> leakage of transistor at the least voltage is used for achieving
> frequency X.
>
>
> Does the game end there? nope. we can play even more.. Lets say at
> frequency X, we dont have anything to do... ok, we can go to lower
> power state - cpuidle, here we can gate clocks and go into different
> deeper power saving states which trades off with wakeup latency
> times.. at some lower power states, we dont even need the AVS
> optimized voltage anymore.. - the voltage for operating in low power
> state is called retention voltage - only some SoCs+PMIC combination
> have ability to automatically do this since A8 itself is in idle when
> the SoC decides it can achieve this low power state.
>
>
> So voltage driver is a bit of a misnomer...
> - Do we have a common entity that can ensure sequencing of AVS, ABB,
> frequency in the right order in upstream - answer is no.. I did
> attempt to post [1] but folks did not like it yet.. and i have'nt had
> time to respin it - actually I dont really know where to go given that
> maintainers differ in opinions..
> - can we control a smps PMIC power supply? yeah - regulator framework
> and corresponding regulator driver
> - can we control ABB - yep - we have abb regulator driver in upstream
> - can we control frequency - yep - all clock framework stuff
> - what do we need for avs support? - well... VC and VP need to become
> dt only (attempted[2]-but got killed), then AVS smartreflex need to be
> modified to fit into that new framework - again dt-fication pending..
> never got around to it..
>
> my wish list from long time[3] is still waiting...
>
> Hope this helps..
>
> [1] https://lwn.net/Articles/587018/
> [2] https://lkml.org/lkml/2013/5/22/471
> [3] https://plus.google.com/112464029509057661457/posts/gvyZQcNieoq
>
> --
> ---
> 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: omap voltage management

[Nishanth Menon]

On 04/01/2015 08:18 AM, Ryan wrote:
> Hi,
> 
> I would like to ask a related question here
Please try not to top post :).

> 
> If i use performance governor alone - constantly running at the
> highest frequency. Does the smart reflex still has a role to play?
Yes. cpufreq governor are just policies - cpufreq policies just
selects a frequency to run the CPU from a list of frequencies. for
each frequency to be achieved, there is ABB, AVS configuration needed
(strategy specific to SoC).

> Does smart-reflex involves reprogramming only the mpu power line alone?
> 
AVS strategies apply to all rails in TI SoCs which need such strategies.

-- 
Regards,
Nishanth Menon

Re: omap voltage management

[Ryan]

On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon <nm@ti.com> wrote:
> On 04/01/2015 08:18 AM, Ryan wrote:
>> Hi,
>>
>> I would like to ask a related question here
> Please try not to top post :).
>
>>
>> If i use performance governor alone - constantly running at the
>> highest frequency. Does the smart reflex still has a role to play?
> Yes. cpufreq governor are just policies - cpufreq policies just
> selects a frequency to run the CPU from a list of frequencies. for
> each frequency to be achieved, there is ABB, AVS configuration needed
> (strategy specific to SoC).

I was trying to find out where exactly the voltages for core and IVA
are set in the code.
Are they set whenever for every frequency change? - I see that the
table is divided into OPP50, OPP100 and
so on but was not able to trace the entire path.

Also, does smartreflex framework uses the same path to change the
voltages (omap446x_vdd_core_volt_data,
omap446x_vdd_core_volt_data)

Could anyone help me understand this or point to some documentation.


>
>> Does smart-reflex involves reprogramming only the mpu power line alone?
>>
> AVS strategies apply to all rails in TI SoCs which need such strategies.
>
> --
> Regards,
> Nishanth Menon

Thanks.

Re: omap voltage management

[Nishanth Menon]

On 04/06/2015 06:42 AM, Ryan wrote:
> On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon <nm@ti.com> wrote:
>> On 04/01/2015 08:18 AM, Ryan wrote:
>>> Hi,
>>>
>>> I would like to ask a related question here
>> Please try not to top post :).
>>
>>>
>>> If i use performance governor alone - constantly running at the
>>> highest frequency. Does the smart reflex still has a role to play?
>> Yes. cpufreq governor are just policies - cpufreq policies just
>> selects a frequency to run the CPU from a list of frequencies. for
>> each frequency to be achieved, there is ABB, AVS configuration needed
>> (strategy specific to SoC).
>
> I was trying to find out where exactly the voltages for core and IVA
> are set in the code.

The generic layer for dvfs is yet to be implemented in k.org.

> Are they set whenever for every frequency change? - I see that the

yes.

> table is divided into OPP50, OPP100 and
> so on but was not able to trace the entire path.
>
> Also, does smartreflex framework uses the same path to change the
> voltages (omap446x_vdd_core_volt_data,
> omap446x_vdd_core_volt_data)

4460 on Panda-es does not have an implementation yet.
--
Regards,
Nishanth Menon

Re: omap voltage management

[Ryan]

Hi Nishanth,

On Mon, Apr 6, 2015 at 6:39 PM, Nishanth Menon <nm@ti.com> wrote:
> On 04/06/2015 06:42 AM, Ryan wrote:
>>
>> On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon <nm@ti.com> wrote:
>>>
>>> On 04/01/2015 08:18 AM, Ryan wrote:
>>>>
>>>> Hi,
>>>>
>>>> I would like to ask a related question here
>>>
>>> Please try not to top post :).
>>>
>>>>
>>>> If i use performance governor alone - constantly running at the
>>>> highest frequency. Does the smart reflex still has a role to play?
>>>
>>> Yes. cpufreq governor are just policies - cpufreq policies just
>>> selects a frequency to run the CPU from a list of frequencies. for
>>> each frequency to be achieved, there is ABB, AVS configuration needed
>>> (strategy specific to SoC).
>>
>>
>> I was trying to find out where exactly the voltages for core and IVA
>> are set in the code.
>
>
> The generic layer for dvfs is yet to be implemented in k.org.
>

I am using a older TI Kernel. I thought this will a good starting
point to understand
as the platform i am working on uses this. if you could provide some pointers
on who initiates the voltage transition and how for each freq. It
would be highly helpful. I did add prints and start tracing
It became too complex for me to fully get a understanding.

http://git.omapzoom.org/?p=kernel/omap.git;a=tree;h=refs/heads/p-android-omap-3.0;hb=refs/heads/p-android-omap-3.0

>> Are they set whenever for every frequency change? - I see that the
>
>
> yes.
>
>> table is divided into OPP50, OPP100 and
>> so on but was not able to trace the entire path.
>>

Say if i use a lower freq (OPP50) - Apart from MPU - Should both core
and iva voltages should
also be set to opp50 voltages as listed in omap446x_vdd_core_volt_data
and omap446x_vdd_core_volt_data?

>> Also, does smartreflex framework uses the same path to change the
>> voltages (omap446x_vdd_core_volt_data,
>> omap446x_vdd_core_volt_data)
>
>
> 4460 on Panda-es does not have an implementation yet.
> --
> Regards,
> Nishanth Menon
>

Re: omap voltage management

[Nishanth Menon]

On 04/06/2015 10:36 AM, Ryan wrote:
> Hi Nishanth,
> 
> On Mon, Apr 6, 2015 at 6:39 PM, Nishanth Menon <nm@ti.com> wrote:
>> On 04/06/2015 06:42 AM, Ryan wrote:
>>>
>>> On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon <nm@ti.com> wrote:
>>>>
>>>> On 04/01/2015 08:18 AM, Ryan wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to ask a related question here
>>>>
>>>> Please try not to top post :).
>>>>
>>>>>
>>>>> If i use performance governor alone - constantly running at the
>>>>> highest frequency. Does the smart reflex still has a role to play?
>>>>
>>>> Yes. cpufreq governor are just policies - cpufreq policies just
>>>> selects a frequency to run the CPU from a list of frequencies. for
>>>> each frequency to be achieved, there is ABB, AVS configuration needed
>>>> (strategy specific to SoC).
>>>
>>>
>>> I was trying to find out where exactly the voltages for core and IVA
>>> are set in the code.
>>
>>
>> The generic layer for dvfs is yet to be implemented in k.org.
>>
> 
> I am using a older TI Kernel. I thought this will a good starting
> point to understand
> as the platform i am working on uses this. if you could provide some pointers
> on who initiates the voltage transition and how for each freq. It
> would be highly helpful. I did add prints and start tracing
> It became too complex for me to fully get a understanding.
> 
> http://git.omapzoom.org/?p=kernel/omap.git;a=tree;h=refs/heads/p-android-omap-3.0;hb=refs/heads/p-android-omap-3.0

The 3.0 kernel uses a TI framework for dvfs. I suggest discussing on
e2e.ti.com for TI kernel forks. different TI kernel forks tend to use
different versions of custom frameworks. It might not be of much
interest in an upstream discussion mailing list to discuss TI kernel
frameworks.


-- 
Regards,
Nishanth Menon