Igor Stoppa wrote: > On Tue, 2007-03-20 at 17:58 +0300, ext Dmitry Krivoschekov wrote: >> Igor Stoppa wrote: >>> On Tue, 2007-03-20 at 16:07 +0300, ext Dmitry Krivoschekov 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. >>>> Linux - Operating system, the key word is "system", doing things on >>>> one layer you have to think how it is refleceted to other layers, so >>>> here are not bare technical questions. >>>>> Anyway in the USB example mentioned the rule is very high level, >>>> What level can be lower than driver level? >>> Enable/disable autosuspend is certainly higher level command than >>> forcing a clock that a driver is using. >> Please re-read what you wrote, "Anyway in the USB example mentioned the >> rule is very high level", >> by the rule I assume "suspend a device if it doesn't need for USB >> interface for now", I didn't consider >> enabling/disabling the rule itself here. > And you were correct. It _is_ high level if it refers to the whole > device rather than directly to a resource used by the device, like a > clock. If you consider a bit that controls a clock for particular device (and only for this device) then I agree with you. But I initially referred to system wide clocks that are propagated to different devices. >>>> I agree, USB stack consist of a number of drivers but all of them >>>> belongs to one, USB, subsystem, more precisely USB host subsystem >>>> (considering the case with AUTOSUSPEND) >>>> >>>> Driver level is serving the lowest level - interacting with particular >>>> system device, while layer serving system clocks is higher by default >>>> since clocks are usually distributed for several devices in the system, >>>> and you need a common knowledge then. Putting the knowledge to driver >>>> layer means duplicating of the knowledge for each driver. >>> I really can't immagine how you have read this into what i wrote. >> Just think of that then, I don't insist though :) >>>>> 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? >>>> Assuming we consider normal device driver, because it needs to coordinate >>>> actions with a number of other drivers in this case, and also for the reason >>>> I mentioned in previous comment. >>>> >>>> And you should definitely read the first chapter of the "Linux Device >>>> drivers" book, >>>> see "The Role of the Device Driver" section. >>> I'll try to reformulate, so maybe this time you won't jump to such funny >>> conclusions: >> It's not a conclusion it's a suggestion, there you may find explanations >> what is wrong >> with delegating policies to device drivers. > Your approach is to just label policy what you want to kick out of the > driver =) Nice one! I may want to kick out policy which may prevent higher layer PM managers to work properly but leave only those rules that device's specification defines to be kept. > > acquire_resource_before_proceeding/release_resource_when_done > > that's a mechanism; the _policy_ is to tell the driver what "when done" > means. At it can be done dynamically. >>> case 1-you are speaking in favour of a framework where policies can >>> orchestrate system level decisions by having a strict control on every >>> shared resource >> I personally don't favor any approach I just want to sort out advantages >> and disadvantages >> of every approach. >>> case 2-i'm saying that it is simpler to rely on drivers doing their job, >> What criteria do you use to accept one approach is simpler than another? > case 2 is already in place for OMAP2, to prevent retention in certain > cases, you can check the code. It works and has very little impact in > terms of code. Furthermore only the drivers that need it are affected. >>> as they are doing right now, on OMAP, at least, of releasing resources >> Did you think of other archs? > well, this is linux-pm ml, so i felt that it was correct to delimit the > current playground; it's to >>> when not needed. Based on this default behavior, there might be certain >>> cases when a system-level manager can interact with them by making the >> the system-level manager has to be arch-dependent in this case > but very trivial; there's no point in having something > cross-architecture if it initroduces unnecessary complexity just for the > sake of it. Better stick to a cross platform interface and let the > details to arch-specific code. >>> _localised_ power saving less aggressive, thus optimiising the global >>> saves/performance. So if others than you are happy with just the >>> distributed approach, they can avoid using the framework, while you can >>> just put it on top and achive the same power saving that you would get >>> in case 1 >> Ok, seems you are happy with current clock framework and advocating it >> to be as is. > As I wrote several times i haven't seen yet a reason to replace it; > certainly there is space for improvement but so far this proposal has > not been on the lines of: how to improve the clk fw >> Are you against addition some features to it, such as enable/disable >> "turn the unused clock off" >> rule, set/get state of associated clock device (to control low power >> modes of the clock device itself)? >> Besides that it is meaningless for you, do you have any technical >> objections for that? > Do you mean apart from the fact that it means hijacking the fw? > Noooo, not at all. > But why is it meaningful to you? Why can't you interact with the entity > that is actually controlling a certain clock, rather than with the clock > itself? You interact with hardware entity when interacting with a clock, so interacting with a corresponding software entity by appropriate driver of software entity is the only meaning for now. Making software entity to be cross-platform also makes sense. Igor, Thanks for all of your valuable comments! Regards, Dmitry _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
