On Tue, 2007-03-20 at 15:13 +0300, ext Eugeny S. Mints wrote: > 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. Not really. > 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. That's why we have, for example, such thing as the clk fw to manage shared clocks. > 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. Really? It's just abstracting what you are proposing to do by directly touching the resource underneath the driver. Takiing for example the MMC driver, it would be as simple as having a High/low responsiveness/troughput toggle which would prevent deep power saving states when there is a high volume of data to be transferred. > 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. Your policy manager becomes too invasive and even _mandatory_ because it becomes the only way to perform resource management. With a decentralised approach, instead, only people who _want_ to use the policy manager can include it, while otherwise they rely on the automatic handling. > > > > > >> 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. Not only that: switching a voltage may require also context saving/restoring; of course there are latencies involved in voltage scaling but that doesn't makes it automatic to merge voltage and frequencies handling. Because as pointed out in other branches of this discussion, there are aspects of voltages and clocks handling that set them apart from each other. > > > 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. > No, the point is that by default every driver would try to go to the lowest power state autonomously. The policy layer (or whatever would take care of the system point of view, in case the decentralised approach is not enough) would _prevent_ temporarily certain deeper power saving states. > > > > 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. As i wrote in he last 3 lines below, that's why upper layers can interact with drivers, _if needed_ > > > > > 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. > -- Cheers, Igor Igor Stoppa <igor.stoppa@xxxxxxxxx> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
