Igor Stoppa wrote: > On Tue, 2007-03-20 at 12:45 +0300, ext Dmitry Krivoschekov wrote: >> David Brownell wrote: >>> On Monday 19 March 2007 5:03 pm, Dmitry Krivoschekov wrote: >>>> David Brownell wrote: >>>>> On Sunday 18 March 2007 1:25 pm, Dmitry Krivoschekov wrote: >>>>>> Sometimes it's quite reasonable to make decisions (or policy) >>>>>> at the low level, without exposing events to higher layers, >>>>> Of course. Any layer can incorporate a degree of policy. >>>> But users should be able to choose to use or do not use the incorporated >>>> policy, shouldn't they? >>> Sometimes. What's a user? >> It's a user of a kernel subsystem that (subsystem ) keeps a policy, >> i.e. a user it's another kernel subsystem or userspace application, >> it depends on implementation of a system. >>> Do you really expect every single >>> algorithm choice to be packaged as a pluggable policy? >> I didn't say pluggable policy, I just said there are must be >> an alternative - "use" or "do not use" a predefined policy. >> For example, in USB you are able to enable/disable autosuspend rule, >> don't know if it's possible to disable it at runtime though. >>> Any >>> time I've seen systems designed that way, those pluggabilty >>> hooks have been a major drag on performance and maintainability. >>> >>> Most components don't actually _need_ a choice of policies. >>> >>> >> Yes, but they at least need a mechanism to disable an associated policy, >> upper layers should be able to decide where the policy well be kept, >> they may delegate the keeping to lower layers but also may want to >> keep the policy themselves for some reason. > That sounds more like it's driven by IP than by technical reasons. > Anyway in the USB example mentioned the rule is very high level, while > here the proposal is to meddle with the internals of a driver. > It seems more logical to implement policies/rules at driver level, > rather than going straight for the resources of the driver. > > Why can't the driver itself be able to translate whatever high-level > command/hint it receives into the platform/arch/board specific actions? I guess you are confusing two things here. There are pm resources which are solely used by one linux device driver only. Such pm resources are not supposed to be under control of power parameter framework we are talking about. Indeed, a linux device driver controls such pm resources a) by itself and b) based on knowledge internal to the driver or translating whatever high-level command/hint it receives. However there is another type of pm resources - pm resources shared by several drivers. Such drivers of course do not know about each other and can't know which state of the pm resource in question is the best at the moment from the _whole_ _system_ point of view. In this case implementation of control of such a pm resource via hinting in some way both drivers seems to me neither reasonable/practical nor feasible. IMO autoidle (a state(s) hw puts a resource to without any sw interaction) as a particular control case for such pm resources is out of scope of a particular driver as well. So, in my thinking a devoted entity should exist to deal with such questions in regard to such shared pm resources. This entity is policy manager. Thus I see a need in an API for policy managers to be presented. > > >> Also, in some cases it is reasonable to adjust rules of a policy >> (without changing the policy). For example if you define a policy >> "keep an output frequency always for 33 MHz (an input frequency may vary)", >> you may want to change the base frequency to 66 MHz sometimes. >> >> >>>>> It's only when that's badly done -- or the problem is so complex >>>>> that multiple policies need to be supported -- that you need to >>>>> pull out that old "mechanism not policy" chestnut, and support >>>>> some kind of policy switching mechanism (governors, userspace >>>>> agents, etc) for different application domains. >>>>> >>>>> >>>>>> e.g. turning a clock off when reference counter gets zero, this is >>>>>> what OMAP's clock framework currently does. >>>>> There are no choices to be made in that layer; it's no more "policy" >>>>> than following the laws of arithmetic is "policy". Software clock >>>> there is some principle: "turn the clock off when use counter reaches >>>> zero", so it is a policy, and a choice is to disable or not to disable >>>> an output clock, it is the simplest case but it's certainly a policy. >>> That's not a choice; it's how the API is defined. It's not "policy". >>> >>> Arithmetic is defined so that 2 + 2 == 4. Should we have a "policy" >>> allowing it to == 5 instead? Or should we just accept that as how >>> things are defined, and move on? >> We should accept this if we agree that benefit of using the rule always >> exist, >> but if the rule constrain some functionality we may want to disable the >> rule. >> Considering the case with clocks, we may want to leave the clock running >> even if there is no users of the clock, but there is a timing constraint >> for readiness of a clock device (PLLs can't be started immediately). > > I find that a bogus example. > It seems like you are generalising clock handling based on PLLs. No. We are designing generic framework for various types of pm resources provided by currently available hw. Already today we know about such cases as PLLs. Please remember that we are approaching voltages as well and I hope you agree that voltage regulators also fit in this example as switching a voltage incurs latencies. > The PLL is actually the exception, having a penalty in commuting between > states, while all the children can be toggled on/off without any delay. > And that's easy to deal with: if a driver is going to do something that > could be affected by the PLL automatically going off, the driver can > avoid releasing its clock. That will effectively keep the PLL on. It's just about preventing effective power management. A particular driver does not have all necessary knowledge/information on what is the most efficient at the moment in regard to _system_ power management. Not releasing a clock/voltage which is not in use by the driver at the moment (and what more important in generic case the driver has no clue on when it will start to use it again) just prevents an upper layer (policy manager) from capability to perform effective power management. > > The PLL per se is not really significant, apart from the fact that it > tatkes power and it's desirable to keep it off for as long as possible, > but the important bit is that the drivers must have the clock ready and > available when needed. Indeed we may want to think about that a driver may want to export requirements on what expected latencies for pm_resource_get() are. But again, a particular driver can;t perform such a decision internally for shared pm resources. Eugeny > > A similar approach can be used for frequencies: if a driver periodically > needs a certain high frequency, it might be impacted by the system > automatically scaling voltage/frequence. > > Possible solutions? > -keep the request for high frequency > if a pll relock is involved in the scaling > > -keep the request for high voltage > if there is no significant delay from a possible pll relock or no > relock at all, but significant ramp-up time for the voltage regulator > > These actions could be performed by the driver either autonomously or > based on hints/commands receivied from upper layers, in the form of > driver specific commands. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
