On Wed, Aug 16, 2006 at 10:20:42PM -0700, Matthew Locke wrote: > On Aug 15, 2006, at 12:04 PM, Dave Jones wrote: > > If there are dependancies inherently linking core1 and core2, cpufreq > > should already be programming both parts. For example, the SA1100 > > driver programs both CPU and SDRAM controller. If there isn't any > > dependancy between them, I don't see the attraction of creating an > > artificial one in the way suggested for no real purpose. > > Are you arguing against the operating point concept because it creates > an artificial dependency? I assume your definition of dependency means > a physical dependency. > > The operating point represents both a physical and operational > dependency. It is a collection of parameters that can/will be adjusted > to reduce power consumption. However, adjusting these parameters can > have a severe impact to performance and operational state of the > system. The parameters can not be adjusted individually and still > achieve the goal of an operational and power efficient system. SoC's > have a fixed number of values in a fixed number of combinations that > keep the system operational and power efficient. Using power op, a > piece of controlling software can tell the system to go to specific > instance of the power parameters that provide the best combination of > power savings and performance/operational integrity according to the > current state of the system. This instance is represented by a string. > The core1 and core interdependencies are something that cpufreq doesn't handle particularly well. If it's something as simple as recalibrating your baud rate generator or adjusting the SDRAM controller, these are all things that need to be done for normal operation to continue, not things that end up being exposed or configurable, so it tends to largely ignore the interdependency issue. The problem occurs when you have independent cores that want to be throttled or scaled independently, yet still have some fixed dependency between them (say, enabling a synchronization circuit), where failure to handle this will ultimately result in core reset or otherwise undefined behaviour. In order to handle this cleanly, one would need multiple drivers for each core, as well as some shared common code for handling the clocks, voltage, and sanity checks. This alone already begins to enter the scope for what things like PowerOP are reasonably suited for. The operating point semantics work well here, as independent core states can be trivially defined based off of vendor-defined usage profiles. It's necessary to have a big picture view of the operating point in order to sanely handle sanity checks and rate validation, which is something that gets rather ugly with cpufreq without referencing common validation code between each core (which will also cause problems for code reuse in the cases where one of the cores is used in another processor). PowerOP seems well suited for these sorts of cases, and it's not clear that trying to beat cpufreq in to submission will offer any benefits in this case, particularly since it's something x86 people largely don't seem to care about, given that ACPI does most of the heavy lifting.
