Re: Alternative Concept

[Igor Stoppa <igor.stoppa@nokia.com>]

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.
> >> 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!

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?
> 
> 
> Thanks,
> Dmitry
> 
-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)