Re: omap voltage management
On 04/06/2015 10:36 AM, Ryan wrote: > Hi Nishanth, > > On Mon, Apr 6, 2015 at 6:39 PM, Nishanth Menon wrote: >> On 04/06/2015 06:42 AM, Ryan wrote: >>> >>> On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
Hi Nishanth, On Mon, Apr 6, 2015 at 6:39 PM, Nishanth Menon wrote: > On 04/06/2015 06:42 AM, Ryan wrote: >> >> On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
On 04/06/2015 06:42 AM, Ryan wrote: On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
On Wed, Apr 1, 2015 at 7:17 PM, Nishanth Menon 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
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 wrote: > On Wed, Mar 25, 2015 at 4:47 PM, Tony Lindgren wrote: >> * Ran Shalit [150321 12:18]: >>> On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit 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 regul
Re: omap voltage management
On Wed, Mar 25, 2015 at 4:47 PM, Tony Lindgren wrote: > * Ran Shalit [150321 12:18]: >> On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit 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] h
Re: omap voltage management
* Ran Shalit [150321 12:18]: > On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
* Ran Shalit [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html