Re: Alternative Concept

[Dmitry Krivoschekov <dmitry.krivoschekov@gmail.com>]

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