Nishanth Menon <nm@xxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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. 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. 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. 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. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
