Kevin Hilman had written, on 09/02/2010 12:47 PM, the following:
> Nishanth Menon <nm@ti.com> writes:
> 
>> Thomas Petazzoni had written, on 09/02/2010 02:43 AM, the following:
>>> Hello,
>>>
>>> On Wed, 01 Sep 2010 15:51:40 -0700
>>> Kevin Hilman <khilman@deeprootsystems.com> wrote:
>>>
>>>> Looking closer at this, keeping track of a list of devices and
>>>> constraints is what the regulator framework does as well.  
>>>>
>>>> Before we get too far down this path, we need to start working with
>>>> Thomas Petazzoni to better understand how we can use the regulator
>>>> framework for much of the management levels of the voltage layer.
>>> Yes, as discussed on IRC with Kevin, I think that some of this voltage
>>> layer mechanisms would benefit from using the existing kernel regulator
>>> framework.
>>>
>>> The regulator framework already keeps tracks of consumers (in your
>>> patch set called "vdd users"), and for each consumer, keeps track of
>>> the requested voltage. The maximum requested voltage is then applied to
>>> the regulator. It seems to fit quite well some of the mechanisms you're
>>> introducing in this patch set.
>> Just brainstorming -> if we use the regulator framework - there are
>> potential benefits - agreed. BUT, consider the cpuidle path ->
>> currently we disable SR while hitting off/ret for class3, this is done
>> in irq locked context while the regulator framework uses locks by
>> itself - we would probably have to evolve an entirely different
>> mechanism to handle this.
>>
>> SR by itself can easily be represented I believe and my thoughts  when
>> i initialy looked at that option had been:
>> a) latency overheads
>> b) flexibility we achieve vs complexity in s/w implementation
>> c) lock handling - esp impact on omap_sram_idle paths..
> 
> If you look at the current PM branch (specifically pm-sr), you'll see
> that with the updated SR layer, there is no SR enable/disable in the
> idle path because there is no voltage scaling during idle.
This is interesting and I wonder if it works in reality, class 3 operation:
you enable SR h/w monitoring loop as part of dvfs, and when you hit 
cpuidle and you discover that domain x is going to idle,
you'd do:
omap_sram_idle() {
	figureout a lot of stuff
	if (core_next_state == OFF)
		disable_sr(core);
	if (mpu_next_state == OFF)
		disable_sr(mpu);
	__omap_sram_idle()
	if (core_next_state == OFF)
		enable_sr(core);
	if (mpu_next_state == OFF)
		enable_sr(mpu);

}

disable_sr(domain){
disable hw loop
forceupdate to nominal voltage
}
enable_sr(domain){
enable hw loop
}

in the days of SRF, we used to have a patch as well.. see one of the 
first versions:
http://marc.info/?l=linux-omap&m=122000411826768&w=2


> 
> That being said, even if this is add later, the idle path can potentialy
> call the SR API directly if needed for the enable/disable.
not clean if it was directly implemented by regulator framework

> 
> The concern Thomas and I are raising is that we don't want to re-invent
> regulator framework functionality in the OMAP voltage layer.  Rather, we
> should keep the OMAP voltage layer as the part that touches the HW, but
> use the regulator framework for the higher-level management of users and
> constraints.
I completely like the idea of going down the regulator path for voltage 
management, only brainstorming on how to make that happen.


btw, I was playing around with something(attached) that "might" show how 
it might be done by enhancing the regulator framework for folks who may 
want to manage their own exclusivity.. e.g. see attachment..

note: I am not saying this is the way to do it, just that: we need to 
allow regulator operations in irq_locked context if we want to do SR 
operations (including voltage transitions)

> 
> Performance issues can be addressed as we hit them, but at this level of
> the design, I want to make sure the frameworks make sense.
I agree.

> 
> Kevin
> 


-- 
Regards,
Nishanth Menon