Re: Alternative Concept

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

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?

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.
> 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.
>
>
>> 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's just a technical example.
> It seems like you are generalising clock handling based on PLLs.
Nop. I just found it does not provide a mechanism to control clock devices
themselves. Gates, multipliers, dividers don't need for this, but PLL's
do need.

> 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.
> 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.
>
> 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
Request to whom? Requesting for something assumes a subsystem that
serves the requests.
>
> -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.


Thanks,
Dmitry