CPUFreq PowerOP integration, Intro 0/3

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your "struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

and let's also add a

	int i_am_special;

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

Hi!

As you know, I never looked too friendly upon PowerOP and the "operating points" concept. My latest messages may have illustrated this point even further -- but the reason for that is that I more and more get the feeling that PowerOP and "operating points" and the so-called new "PM core" is trying to do too many things at once, and therefore mixes up differnt levels. Here is a rough sketch of what I'd like to discuss[1] as an alternative:

A) The lowest level: lots of knobs.

Somewhere in a "computer system"[2] there are very many "knobs" which may be turned to influence various voltages, clock levels, or operating modes ("turbo", "performance" or "powersave", for example).

Also, there might be many dependencies on how these "knobs" may be changed.

Let's assume the system is in a well-defined, working state right now.

B) I want to change one such knob!!!

Now, let's say that we want to change one value controlled by such a knob. What must we do? We need to check that changing it
a) does not violate any dependency ["verification"]
b) all dependencies are handled in correct order ["notification"]

C) Notification

Let's look at the "notification" stage first -- that's what current cpufreq notifiers do in a very basic way. However, this is also what the new clock and voltage frameworks are trying to do, right? So that's the lesser problem now.

D) Verification

So, how to do this verification? Basically, there are two approaches:

1) ask every other subsystem whether the new value is OK with it. This is what cpufreq currently suggests to do. It is evident that this gets overly complicated with lots of dependencies and dependencies within the dependencies -- both in terms of concept and in terms of time the verification code takes to execute.
Advantages:
- easy to expand, also in runtime (e.g. USB system is modprobed and telling you of a new minimum voltage requirement on certain circumstances)
- does not limit choices for each knob Disadvantages:
- might get very complex

2) look up all valid states in a table
This is basically what PowerOP and the "operating points" concept suggests: if you want to change one value, you check what operating points a) contain the new value and b) is most suitable to you.
Advantages:
- fast
- pre-defined set of operating points which the system designer is comfortable with
Disadvantages:
- needs to be limited to "core" of the system as else the tables may get overly large
- limits the choices

E) So, why not combine the best of both worlds?

If you want to change a knob, the "PM core" looks both at every other subsystem adding dependencies, and at a "operating points" table _ifff_ it exists.

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your "struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

and let's also add a

	int i_am_special;

Let's assume that there is an OMAP1 PM module which implements a ->set and ->get function for all of them. A yet-to-be-defined interface then tells this PM module

"I want to increase the CPU frequency from C1 MHz to C2 MHz!"

->set(CPU_VLTG, C2);

The ->set function would then ask whether it is allowed to switch to frequency B. How would it ask for that? It would both call the "operating points" layer to check whether such a table is registered. Now, let's assume there are no external subsystems affected by this change, and the system engineer has defined such a table:

Nr. CPU_VLTG CPU TC ... i_am_special
1 A1 C1 D1 1
2 A2 C1 D1 2
3 A1 C2 D2 3
4 A2 C2 D3 4

The core would determine that the latter two states are now allwed, and using some sensible algorithm (e.g. "where do I not have to switch too many knobs", or minimize the costs of switching) decide between those two. Basically, it would recignize now that it is OK to proceed from state Nr. 1 to Nr. 3, but that this means that "tc" also needs to be changed. After notifing relevant subsystems using the clock and voltage frameworks, it would then proceed to set the hardware accordingly.

Now, some might argue "I want to tell the interface to enter mp3-mode, and not enter some CPU_VLTG and hope that it selects the right table entry then in the verifcation stage!" Well, you can do that. Using the i_am_special pseudo-knob. You just tell the yet-to-be-defined interface "I want to switch knob I_AM_SPECIAL to 4". The process is the same.

G) So, what does this get us?

It may look as "Operating Points" turned on its head now. And yes, it is. But you can do the following now:
- let cpufreq call ->set(CPU_FREQ, <value>), if you want dynamic frequency scaling,
- use pre-defined operating points if it's suitable to do so,
- handles all dependencies either way.

Oh, and as the operating point concept is only introduced as an element between the low-level setting and the "high-level policy decision", it does not need to be squeezed into current cpufreq drivers or even the current cpufreq core in any way. cpufreq may call it, but that should be relatively easy to implement.

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

Thanks,
Dominik

[1] As many here are aware, I will have very limited time to actually implement it.
[2] embedded device, notebook, cluster, desktop with lots of USB devices connected, and so on
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Hi!

Quoted 14 lines

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your "struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

Quoted 3 lines

and let's also add a

	int i_am_special;

Hehe, nice idea.

Quoted 5 lines

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

Looks okay to me. Unlike powerop design, this actually works for everyone.

Quoted 6 lines

Quoted 5 lines

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

Quoted 2 lines

Looks okay to me. Unlike powerop design, this actually works for everyone.

Pavel, if you would pay attention better you would notice that at the underneath of what Dominic is talking about is a concept of *more knobs* for controlling platform power states. This is what PowerOP is trying to bring to the table.

PowerOP is not a policy engine like what Dominic is talking about. And what Dominic is talking about will need to build on something that will end up looking so much like power op that it wont be funny.

Quoted 28 lines · Pavel Machek

Hi!

Quoted 14 lines

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your "struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

Quoted 3 lines

and let's also add a

	int i_am_special;

Hehe, nice idea.

Quoted 5 lines

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

Quoted 2 lines

Looks okay to me. Unlike powerop design, this actually works for everyone.

Pavel, if you would pay attention better you would notice that at the underneath of what Dominic is talking about is a concept of *more knobs* for controlling platform power states. This is what PowerOP is trying to bring to the table.

PowerOP is not a policy engine like what Dominic is talking about. And what Dominic is talking about will need to build on something that will end up looking so much like power op that it wont be funny.

I believe I did pay attention. What PowerOP has is crappy patches, crappy changelogs, and when you don't like it, you are obviously biased (or not paying attention).

On 10/12/06, Pavel Machek <[1][email protected]> wrote:

I believe I did pay attention. What PowerOP has is crappy patches, crappy changelogs, and when you don't like it, you are obviously biased (or not paying attention).

I would say that by these words and by what you say later you confirm you just haven't got any valid points you can prove your position with.

Hi!

As you know, I never looked too friendly upon PowerOP and the "operating points" concept. My latest messages may have illustrated this point even further -- but the reason for that is that I more and more get the feeling that PowerOP and "operating points" and the so-called new "PM core" is trying to do too many things at once, and therefore mixes up differnt levels. Here is a rough sketch of what I'd like to discuss[1] as an alternative:

A) The lowest level: lots of knobs.

Somewhere in a "computer system"[2] there are very many "knobs" which may be turned to influence various voltages, clock levels, or operating modes ("turbo", "performance" or "powersave", for example).

Also, there might be many dependencies on how these "knobs" may be changed.

Let's assume the system is in a well-defined, working state right now.

B) I want to change one such knob!!!

Now, let's say that we want to change one value controlled by such a knob. What must we do? We need to check that changing it
a) does not violate any dependency ["verification"]
b) all dependencies are handled in correct order ["notification"]

C) Notification

Let's look at the "notification" stage first -- that's what current cpufreq notifiers do in a very basic way. However, this is also what the new clock and voltage frameworks are trying to do, right? So that's the lesser problem now.

D) Verification

So, how to do this verification? Basically, there are two approaches:

1) ask every other subsystem whether the new value is OK with it. This is what cpufreq currently suggests to do. It is evident that this gets overly complicated with lots of dependencies and dependencies within the dependencies -- both in terms of concept and in terms of time the verification code takes to execute.
Advantages:
- easy to expand, also in runtime (e.g. USB system is modprobed and telling you of a new minimum voltage requirement on certain circumstances)
- does not limit choices for each knob Disadvantages:
- might get very complex

2) look up all valid states in a table
This is basically what PowerOP and the "operating points" concept suggests: if you want to change one value, you check what operating points a) contain the new value and b) is most suitable to you.
Advantages:
- fast
- pre-defined set of operating points which the system designer is comfortable with
Disadvantages:
- needs to be limited to "core" of the system as else the tables may get overly large
- limits the choices

E) So, why not combine the best of both worlds?

If you want to change a knob, the "PM core" looks both at every other subsystem adding dependencies, and at a "operating points" table _ifff_ it exists.

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your "struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

and let's also add a

	int i_am_special;

Let's assume that there is an OMAP1 PM module which implements a ->set and ->get function for all of them. A yet-to-be-defined interface then tells this PM module

"I want to increase the CPU frequency from C1 MHz to C2 MHz!"

->set(CPU_VLTG, C2);

The ->set function would then ask whether it is allowed to switch to frequency B. How would it ask for that? It would both call the "operating points" layer to check whether such a table is registered. Now, let's assume there are no external subsystems affected by this change, and the system engineer has defined such a table:

Nr. CPU_VLTG CPU TC ... i_am_special
1 A1 C1 D1 1
2 A2 C1 D1 2
3 A1 C2 D2 3
4 A2 C2 D3 4

The core would determine that the latter two states are now allwed, and using some sensible algorithm (e.g. "where do I not have to switch too many knobs", or minimize the costs of switching) decide between those two. Basically, it would recignize now that it is OK to proceed from state Nr. 1 to Nr. 3, but that this means that "tc" also needs to be changed. After notifing relevant subsystems using the clock and voltage frameworks, it would then proceed to set the hardware accordingly.

Now, some might argue "I want to tell the interface to enter mp3-mode, and not enter some CPU_VLTG and hope that it selects the right table entry then in the verifcation stage!" Well, you can do that. Using the i_am_special pseudo-knob. You just tell the yet-to-be-defined interface "I want to switch knob I_AM_SPECIAL to 4". The process is the same.

G) So, what does this get us?

It may look as "Operating Points" turned on its head now. And yes, it is. But you can do the following now:
- let cpufreq call ->set(CPU_FREQ, <value>), if you want dynamic frequency scaling,
- use pre-defined operating points if it's suitable to do so,
- handles all dependencies either way.

Oh, and as the operating point concept is only introduced as an element between the low-level setting and the "high-level policy decision", it does not need to be squeezed into current cpufreq drivers or even the current cpufreq core in any way. cpufreq may call it, but that should be relatively easy to implement.

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

Thanks,
Dominik

[1] As many here are aware, I will have very limited time to actually implement it.
[2] embedded device, notebook, cluster, desktop with lots of USB devices connected, and so on

That's it. Bottom line is: what you are talking about is NOT an Alternative Concept but a particular case instead. While PowerOP design is generic case.

The last remark about 256 CPU case. Leveraging POwerOP such systems will be built using just one (current) operating point approach as described above.

Quoted 21 lines

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your "struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

and let's also add a

	int i_am_special;

Let's assume that there is an OMAP1 PM module which implements a ->set and ->get function for all of them. A yet-to-be-defined interface then tells this PM module

Hi!

Quoted 3 lines

That's it. Bottom line is: what you are talking about is NOT an Alternative Concept but a particular case instead. While PowerOP design is generic case.

Fine then; submit powerOP with interface Dominik suggested. Notice that his solution exposes all the knobs to userspace directly, so his interface _is_ different to yours. "i_am_special" is just one of knobs.

Quoted 4 lines

The last remark about 256 CPU case. Leveraging POwerOP such systems will be built using just one (current) operating point approach as described above.

Notice that Dominik's solution still allows to have more than one operating point for each of 256 CPUs without explosion of number of states.

Pavel

Quoted 21 lines

Quoted 21 lines

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your "struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

and let's also add a

	int i_am_special;

Let's assume that there is an OMAP1 PM module which implements a ->set and ->get function for all of them. A yet-to-be-defined interface then tells this PM module

Signature · 6 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Hi Mark,

Quoted 6 lines · Mark Gross

Quoted 6 lines

Quoted 5 lines

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

Quoted 7 lines

Quoted 2 lines

Looks okay to me. Unlike powerop design, this actually works for everyone.

Pavel, if you would pay attention better you would notice that at the underneath of what Dominic is talking about is a concept of *more knobs* for controlling platform power states. This is what PowerOP is trying to bring to the table.

Oh no. PowerOP does it top->bottom; I try to do it bototm->top. That's the difference, and it is a _fundamental_ difference. Yes, both will lead to a concept of "operating points" on systems which may need it. But still the way you get there (which is important if you want to keep it flexible, and you do want to keep it flexible to allow for cpufreq) is different.

Quoted 4 lines

PowerOP is not a policy engine like what Dominic is talking about. And what Dominic is talking about will need to build on something that will end up looking so much like power op that it wont be funny.

This I dare to doubt.

Thanks,
Dominik

Quoted 7 lines

Quoted 3 lines

That's it. Bottom line is: what you are talking about is NOT an Alternative Concept but a particular case instead. While PowerOP design is generic case.

Fine then; submit powerOP with interface Dominik suggested. Notice that his solution exposes all the knobs to userspace directly, so his interface _is_ different to yours. "i_am_special" is just one of knobs.

I am very keen on Dominic's design concept, however; I missed his sysfs interface that exposes the knobs to userspace.

Quoted 24 lines · Dominik Brodowski

Hi Mark,

Quoted 13 lines · Mark Gross

Quoted 10 lines

Quoted 9 lines

I think that this might be much easier to implement than your PowerOP /
operating points / PM core / PowerOP - cpufreq interaction patches. As a
matter of fact, some parts of your operating points table infrastructure
may be usable for the concept outlined above. So, what do you think? What
does everyone else involved think about this alternative approach?

Quoted 2 lines

Looks okay to me. Unlike powerop design, this actually works for everyone.

Quoted 7 lines

Pavel, if you would pay attention better you would notice that at the
underneath of what Dominic is talking about is a concept of *more knobs*
for controlling platform power states. This is what PowerOP is trying
to bring to the table.

Quoted 9 lines

Oh no. PowerOP does it top->bottom; I try to do it bototm->top. That's the
difference, and it is a _fundamental_ difference. Yes, both will lead to a
concept of "operating points" on systems which may need it. But still the
way you get there (which is important if you want to keep it flexible, and
you do want to keep it flexible to allow for cpufreq) is different.

I'll take a closer look at both. It really looks to me that folks are in
violent agreement more than anything else. I also prefer a bottom-

Quoted 1 line

top

approach.

--mgross

Quoted 11 lines

Quoted 6 lines

PowerOP is not a policy engine like what Dominic is talking about. And
what Dominic is talking about will need to build on something that will
end up looking so much like power op that it wont be funny.

This I dare to doubt.

Thanks,
Dominik

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 10 lines

A) The lowest level: lots of knobs.

Somewhere in a "computer system"[2] there are very many "knobs" which may be turned to influence various voltages, clock levels, or operating modes ("turbo", "performance" or "powersave", for example).

Also, there might be many dependencies on how these "knobs" may be changed.

Let's assume the system is in a well-defined, working state right now.

In terms which we use to describe PowerOP a "kbob" is "power parameter" and "operating point" is an entity which corresponds to "well-defined, _working_ [system power] state".

So, what PowerOP Core does: it just maintains a collection of operating point,
i.e. collection of known-to-be-working system power states. On many platforms
(especially embedded) not all combinations of power parameters are valid. Some
[invalid] combinations of the power parameters may crash or damage the system.

1) you have a table which tells you that there are some combinations of power
parameter values which are
a) _known-to-be-working_
and
b) contains SOME_PLATFORM_POWER_PARAMETER=value1.
Then you chose one of these operating points and switch to it.

The table creation is simply registration of operating points with POwerOP Core.

Now selection and switch. Obviously the functionality of selection between operating points based on some algo (which btw varies even not across platforms
but even across different profiles of the same platform) has nothing to do with
the code which actually switches operating points. So having such functionalities coupled within the ->set() method is just invalid design - they
have to be separated. That's exactly what PowerOP approach does:

an upper
layer
can implement selection logic leveraging PowerOP Core interface and then request
POwerOP Core to switch system to the selected operating point.

2) table does not exist. There are two options here:

Either,
a)an entity which calls ->set() for a particular power parameter IS RESPONSIBLE for that resulting combination of power parameter values (once the
set has been executed) IS valid one

OR
b) the system executes complex logic you described under D) 1) (in fact, cpufreq policy notifiers) to get a valid combination of power parameter values
with a predefined value of a certain power parameter.

Let me illustrate why 2)a) is just particular case in contrast to POwerOP which
is general case in this situation.

i) PowerOP Core provides interface to get/set value of a particular power parameter

ii) Let's assume we limit the set of operating points for a platform to one point. This one operating point is always the current operating point. All operations occur on the the current operating point.

iii)in the assumptions above your ->set() is nothing else than:
set(param, value)
{
struct powerop_pwr_param p;

p.attr = param;
p.value = value;
powerop_set_pwr_params(CURRENT_POINT, &p, 1);
powerop_set_point(CURRENT_POINT);
}

That's it. Bottom line is: what you are talking about is NOT an Alternative Concept but a particular case instead. While PowerOP design is generic case.

Quoted 1 line

D) Verification

i.e. constraint checking and enforcement

Quoted 7 lines

Let's assume that there is an OMAP1 PM module which implements a ->set and ->get function for all of them. A yet-to-be-defined interface then tells this PM module

"I want to increase the CPU frequency from C1 MHz to C2 MHz!"

->set(CPU_VLTG, C2);

did you mean ->set(CPU, C2) ?

Quoted 7 lines

The core would determine that the latter two states are now allwed, and using some sensible algorithm (e.g. "where do I not have to switch too many knobs", or minimize the costs of switching) decide between those two. Basically, it would recignize now that it is OK to proceed from state Nr. 1 to Nr. 3, but that this means that "tc" also needs to be changed. After notifing relevant subsystems using the clock and voltage frameworks, it would then proceed to set the hardware accordingly.

This adds a sort of tree search defining a power state path from a current state to one of the possible target stats with C2. In this case the only way to get to CPU==C2 is to change TC to D2 and deal with all the ripples that will cause.

One question is how do we know that changing TC is a better way to go than changing CPU_VLTG? We'll need to figure out an ordering in the phase space of power states. Thinking out loud, I would try to pick the target state based on latency if there are more than one targets to satisfy the ->set() request.

Quoted 6 lines

I think that this might be much easier to implement than your PowerOP / operating points / PM core / PowerOP - cpufreq interaction patches. As a matter of fact, some parts of your operating points table infrastructure may be usable for the concept outlined above. So, what do you think? What does everyone else involved think about this alternative approach?

I still see a need to take the first step of enabling "lots of knobs". This is the primary goal of the PowerOp patch set. The stuff with the sysfs is just an interface to set/get the operating points while a more complete solution like what you are talking about evolves.

Hi!

As you know, I never looked too friendly upon PowerOP and the "operating
points" concept. My latest messages may have illustrated this point even
further -- but the reason for that is that I more and more get the feeling
that PowerOP and "operating points" and the so-called new "PM core" is trying to do too many things at once, and therefore mixes up differnt levels. Here is a rough sketch of what I'd like to discuss[1] as an alternative:

A) The lowest level: lots of knobs.

Somewhere in a "computer system"[2] there are very many "knobs" which may
be turned to influence various voltages, clock levels, or operating modes
("turbo", "performance" or "powersave", for example).

Also, there might be many dependencies on how these "knobs" may be changed.

Let's assume the system is in a well-defined, working state right now.

B) I want to change one such knob!!!

Now, let's say that we want to change one value controlled by such a knob.
What must we do? We need to check that changing it
a) does not violate any dependency ["verification"]
b) all dependencies are handled in correct order ["notification"]

C) Notification

Let's look at the "notification" stage first -- that's what current cpufreq
notifiers do in a very basic way. However, this is also what the new clock
and voltage frameworks are trying to do, right? So that's the lesser problem
now.

D) Verification

So, how to do this verification? Basically, there are two approaches:

1) ask every other subsystem whether the new value is OK with it. This is what cpufreq currently suggests to do. It is evident that this gets overly complicated with lots of dependencies and dependencies within the dependencies -- both in terms of concept and in terms of time the verification code takes to execute.
Advantages:
- easy to expand, also in runtime (e.g. USB system is modprobed and telling you of a new minimum voltage requirement on certain circumstances)
- does not limit choices for each knob Disadvantages:
- might get very complex

2) look up all valid states in a table
This is basically what PowerOP and the "operating points" concept suggests: if you want to change one value, you check what operating points a) contain the new value and b) is most suitable to you.
Advantages:
- fast
- pre-defined set of operating points which the system designer is comfortable with
Disadvantages:
- needs to be limited to "core" of the system as else the tables may get overly large
- limits the choices

E) So, why not combine the best of both worlds?

If you want to change a knob, the "PM core" looks both at every other subsystem adding dependencies, and at a "operating points" table _ifff_ it
exists.

F) So, how would this work for OMAP1?

Let's limit it, to keep it somewhat simple, to the values contained in your
"struct pm_core_point" for OMAP:

int cpu_vltg; /* voltage in mV */
int dpll; /* in KHz */
int cpu; /* CPU frequency in KHz */
int tc; /* in KHz */
int per; /* in KHz */
int dsp; /* in KHz */
int dspmmu; /* in KHz */
int lcd; /* in KHz */

and let's also add a

	int i_am_special;

Let's assume that there is an OMAP1 PM module which implements a -

Quoted 1 line

set and

->get function for all of them. A yet-to-be-defined interface then tells
this PM module

"I want to increase the CPU frequency from C1 MHz to C2 MHz!"

->set(CPU_VLTG, C2);

The ->set function would then ask whether it is allowed to switch to frequency B. How would it ask for that? It would both call the "operating
points" layer to check whether such a table is registered. Now, let's assume
there are no external subsystems affected by this change, and the system
engineer has defined such a table:

Nr. CPU_VLTG CPU TC ... i_am_special
1 A1 C1 D1 1
2 A2 C1 D1 2
3 A1 C2 D2 3
4 A2 C2 D3 4

The core would determine that the latter two states are now allwed, and
using some sensible algorithm (e.g. "where do I not have to switch too many
knobs", or minimize the costs of switching) decide between those two. Basically, it would recignize now that it is OK to proceed from state Nr. 1
to Nr. 3, but that this means that "tc" also needs to be changed. After
notifing relevant subsystems using the clock and voltage frameworks, it
would then proceed to set the hardware accordingly.

Now, some might argue "I want to tell the interface to enter mp3- mode, and
not enter some CPU_VLTG and hope that it selects the right table entry then
in the verifcation stage!" Well, you can do that. Using the i_am_special
pseudo-knob. You just tell the yet-to-be-defined interface "I want to switch
knob I_AM_SPECIAL to 4". The process is the same.

G) So, what does this get us?

It may look as "Operating Points" turned on its head now. And yes, it is.
But you can do the following now:
- let cpufreq call ->set(CPU_FREQ, <value>), if you want dynamic frequency
scaling,
- use pre-defined operating points if it's suitable to do so,
- handles all dependencies either way.

Oh, and as the operating point concept is only introduced as an element
between the low-level setting and the "high-level policy decision", it does
not need to be squeezed into current cpufreq drivers or even the current
cpufreq core in any way. cpufreq may call it, but that should be relatively
easy to implement.

I think that this might be much easier to implement than your PowerOP /
operating points / PM core / PowerOP - cpufreq interaction patches. As a
matter of fact, some parts of your operating points table infrastructure
may be usable for the concept outlined above. So, what do you think? What
does everyone else involved think about this alternative approach?

Thanks,
Dominik

[1] As many here are aware, I will have very limited time to actually implement it.
[2] embedded device, notebook, cluster, desktop with lots of USB devices
connected, and so on
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

I believe this power parameter framework should solve many (if not all) of the issues raised by using operating points as the base abstraction and provide a common layer across architectures. Eugeny and I have the beginnings of an API proposal for this framework, but we wanted to get some high level feedback on the concepts so we can adjust the API if necessary. So, comments?

Hi!

Quoted 6 lines

I believe this power parameter framework should solve many (if not all) of the issues raised by using operating points as the base abstraction and provide a common layer across architectures. Eugeny and I have the beginnings of an API proposal for this framework, but we wanted to get some high level feedback on the concepts so we can adjust the API if necessary. So, comments?

Looks better than powerop certainly.

Perhaps first step would be to convert cpufreq to this new framework?

Quoted 10 lines · Pavel Machek

Hi!

Quoted 6 lines

I believe this power parameter framework should solve many (if not all) of the issues raised by using operating points as the base abstraction and provide a common layer across architectures. Eugeny and I have the beginnings of an API proposal for this framework, but we wanted to get some high level feedback on the concepts so we can adjust the API if necessary. So, comments?

Looks better than powerop certainly.

Quoted 1 line

Perhaps first step would be to convert cpufreq to this new framework?

The first step is to get a parameter framework in upstream.

It will take some time for the applications of this proposed framework to materialize and drive the maturing of the implementation. These won't get written unless a framework is upstream.

I don't know if having cpufreq plug into this framework will ever make a lot of sense. However; it would be simple to create a cpufreq driver that access the parameter layer for some selected platforms. (N800?)

--mgross
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Perhaps first step would be to convert cpufreq to this new framework?

Hi,

Quoted 10 lines · Mark Gross

Quoted 9 lines · Pavel Machek

Hi!

Quoted 6 lines

I believe this power parameter framework should solve many (if not all) of the issues raised by using operating points as the base abstraction and provide a common layer across architectures. Eugeny and I have the beginnings of an API proposal for this framework, but we wanted to get some high level feedback on the concepts so we can adjust the API if necessary. So, comments?

Looks better than powerop certainly.

I also think this power parameter framework is a lot easier to adopt. PowerOp ideas can be built on top of this framework later.

Quoted 2 lines

Quoted 1 line

Perhaps first step would be to convert cpufreq to this new framework?

The first step is to get a parameter framework in upstream.

Would this involve replacing the clock framework, or are they going to coexist?

Quoted 9 lines

It will take some time for the applications of this proposed framework to materialize and drive the maturing of the implementation. These won't get written unless a framework is upstream.

I don't know if having cpufreq plug into this framework will ever make a lot of sense. However; it would be simple to create a cpufreq driver that access the parameter layer for some selected platforms. (N800?)

Quoted 6 lines

--mgross
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

It seems that this power parameter framework is more toward dynamic (or runtime) power management of various devices on a platform. We should make sure it does not break (and is not broken by) system suspend/resume operations.

ikhwan
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 2 lines

Would this involve replacing the clock framework, or are they going to coexist?

parameter framework would eventually replace clock framework.

Separate clock and
voltage frameworks lead to code and functionality duplication and do not address such things as relationship between clocks and voltages, clock/voltage/power domains, etc needed for aggressive power management.

Basically a good way of thinking about parameter framework is that parameter framework would start from existed clock framework and gradually evolve by addressing voltages, relationship between clocks and voltages, domains. Eventually clock framework functionality would be a part of power parameter framework.

This alternative "concept" would seem to be missing a few essential aspects. Like proposed interfaces, for starters ...

Quoted 1 line · Eugeny S. Mints

Quoted 1 line

Quoted 3 lines

Quoted 1 line

Would this involve replacing the clock framework, or are they going to coexist?

parameter framework would eventually replace clock framework.

That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement).

Quoted 4 lines

Separate clock and
voltage frameworks lead to code and functionality duplication and do not address such things as relationship between clocks and voltages, clock/voltage/power domains, etc needed for aggressive power management.

Most clocks don't have those issues. Why penalize all clocks for issues which only relate to a few? Better to only do that for the few cocks which have such additional constraints.

Plus, remember that the clock framework is an interface ... so by definition, it has no code associated with it. Hence no duplication of code is possible... at least at this hand-wavey "concept" level. Possibly a given implementation has scope for code sharing; but I doubt it. Code behind a given implementation of the clock interface is invariably quite slim.

If a clock being enabled implies a power or voltage domain being active, there's no reason that constraint shouldn't be enforced by whatever implementation a given platform uses.

And having a generic -- basically untyped -- notion of "parameter" seems significantly less good than having a typed notion, with type-specific operations. Typed notions are easier to understand, read, and maintain.

Quoted 6 lines

Basically a good way of thinking about parameter framework is that parameter framework would start from existed clock framework and gradually evolve by addressing voltages, relationship between clocks and voltages, domains. Eventually clock framework functionality would be a part of power parameter framework.

A better way would be to say that implementions of the clock interface on a given platform can build on whatever they need to build. That might include a "parameter" framework, if such a thing were defined in such a way that it became useful to such implementations.

Quoted 8 lines · ext David Brownell

This alternative "concept" would seem to be missing a few essential aspects. Like proposed interfaces, for starters ...

Quoted 3 lines · Eugeny S. Mints

Quoted 2 lines

Would this involve replacing the clock framework, or are they going to coexist?

Quoted 5 lines

Quoted 1 line

parameter framework would eventually replace clock framework.

That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement).

I think the rationale for choosing to abstract a clock/voltage should be clarified more.

Quoted 5 lines

Quoted 4 lines

Separate clock and
voltage frameworks lead to code and functionality duplication and do not address such things as relationship between clocks and voltages, clock/voltage/power domains, etc needed for aggressive power management.

Quoted 3 lines

Most clocks don't have those issues. Why penalize all clocks for issues which only relate to a few? Better to only do that for the few clocks which have such additional constraints.

Those that have such constraints tend to be very architecture dependant, so that not much can be generalised or ported easily without having to add too many levels of indirection.

Quoted 7 lines

Plus, remember that the clock framework is an interface ... so by definition, it has no code associated with it. Hence no duplication of code is possible... at least at this hand-wavey "concept" level. Possibly a given implementation has scope for code sharing; but I doubt it. Code behind a given implementation of the clock interface is invariably quite slim.

Quoted 3 lines

If a clock being enabled implies a power or voltage domain being active, there's no reason that constraint shouldn't be enforced by whatever implementation a given platform uses.

And that implementation could be highly optimised since it wouldn't care too much about being portable.

Quoted 4 lines

And having a generic -- basically untyped -- notion of "parameter" seems significantly less good than having a typed notion, with type-specific operations. Typed notions are easier to understand, read, and maintain.

That sounds like being on the same lines of C vs C++ comments :) or why not to use typedef struct foo {...} bar

Quoted 6 lines

Quoted 5 lines

Basically a good way of thinking about parameter framework is that parameter framework would start from existed clock framework and gradually evolve by addressing voltages, relationship between clocks and voltages, domains. Eventually clock framework functionality would be a part of power parameter framework.

Quoted 5 lines

A better way would be to say that implementions of the clock interface on a given platform can build on whatever they need to build. That might include a "parameter" framework, if such a thing were defined in such a way that it became useful to such implementations.

But shouldn't it be useful on every platform? As a sort of resource manager (because that's what it would become if it would start adressing interdependencies between clocks and voltages).

This alternative "concept" would seem to be missing a few essential aspects. Like proposed interfaces, for starters ...

Quoted 2 lines

Quoted 1 line

Would this involve replacing the clock framework, or are they going to coexist?

parameter framework would eventually replace clock framework.

That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement).

Quoted 6 lines

Separate clock and
voltage frameworks lead to code and functionality duplication and do not address such things as relationship between clocks and voltages, clock/voltage/power domains, etc needed for aggressive power management.

Most clocks don't have those issues. Why penalize all clocks for issues which only relate to a few? Better to only do that for the few cocks which have such additional constraints.

Plus, remember that the clock framework is an interface ... so by definition, it has no code associated with it. Hence no duplication of code is possible... at least at this hand-wavey "concept" level. Possibly a given implementation has scope for code sharing; but I doubt it. Code behind a given implementation of the clock interface is invariably quite slim.

If a clock being enabled implies a power or voltage domain being active, there's no reason that constraint shouldn't be enforced by whatever implementation a given platform uses.

And having a generic -- basically untyped -- notion of "parameter" seems significantly less good than having a typed notion, with type-specific operations.

Typed notions are easier to understand,
read, and maintain.

Quoted 7 lines

Basically a good way of thinking about parameter framework is that parameter framework would start from existed clock framework and gradually evolve by addressing voltages, relationship between clocks and voltages, domains. Eventually clock framework functionality would be a part of power parameter framework.

A better way would be to say that implementions of the clock interface on a given platform can build on whatever they need to build. That might include a "parameter" framework, if such a thing were defined in such a way that it became useful to such implementations.

- Dave

Quoted 2 lines · David Brownell

This alternative "concept" would seem to be missing a few essential aspects. Like proposed interfaces, for starters ...

stay tuned - it follows ;)

Quoted 9 lines · Eugeny S. Mints

Quoted 2 lines

Quoted 1 line

Would this involve replacing the clock framework, or are they going to coexist?

parameter framework would eventually replace clock framework.

That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement).

a cherry-picking on clk fw API:

- clk_set_rate() sticks to an individual clock - no way to set rates for number of clocks at once instead of having series of clk_set_rate() calls. The former for example is required for clocks which have required predefined ratio dependency though: two clocks always have to be n:2n and any other ratio leads to hardware misbehavior. So, you can't go from 100:200 to 300:600 via series of clk_set_rate() for such clocks, i.e. 100:200 -> 300:200 -> 300:600 or 100:200 -> 100:600 -> 300:600 (see SH7722 hw for reference)

- only a rate can be set up via clk_set_rate() while for a PLL I want to set up a desired idle state as well (btw there can be more than one idle state)

- current API does not provide support for clock domains

a cherry-picking on clk fw implementation:

- clock tree structure and traversing clock tree code are duplicated in every architecture while can be done in arch independent way and just once (hint: what indeed is an arch specific thing it's a clock tree configuration)

Quoted 6 lines

Quoted 6 lines

Separate clock and
voltage frameworks lead to code and functionality duplication and do not address such things as relationship between clocks and voltages, clock/voltage/power domains, etc needed for aggressive power management.

Quoted 3 lines

Most clocks don't have those issues. Why penalize all clocks for issues which only relate to a few? Better to only do that for the few cocks which have such additional constraints.

parameter fw would give exactly this behavior: relationship between clocks and voltages, clock/voltage/power domains implementation would be just additional arcs between nodes for clock and voltages. Nowadays clk fw has only one type of arcs - parent-child type. parameter fw would bring additional types. But clock nodes would be linked just with required arcs (of required type; both are arch specific things) so for an arch without any additional dependencies between clocks (and voltages) parameter fw would end up with exactly equivalent clock tree as clk fw for the arch has today.

Quoted 7 lines

Plus, remember that the clock framework is an interface ... so by definition, it has no code associated with it. Hence no duplication of code is possible... at least at this hand-wavey "concept" level. Possibly a given implementation has scope for code sharing; but I doubt it. Code behind a given implementation of the clock interface is invariably quite slim.

and invariably looks like a hack and still duplicate clock tree building and traversing code. Dependencies which exist in modern hw between clocks, clocks and voltages require a more straight and standard technique to be set up for implementing clk/vltg/name_it framework. Moving most of the code to be arch independent and setting a clear rules on how a clock/vltg tree configuration would look like while just looking at a hw manual would help.

Quoted 4 lines

If a clock being enabled implies a power or voltage domain being active, there's no reason that constraint shouldn't be enforced by whatever implementation a given platform uses.

true. but it's the same functionality required on different arches. and it can be done in arch independent way without penalties for arches which do not require the functionality. What's the rationale to move it down to arch specific code then?

Quoted 4 lines

And having a generic -- basically untyped -- notion of "parameter" seems significantly less good than having a typed notion, with type-specific operations.

there is no type-specific operations. clk_set_rate() and vltg_set() basically do the same thing - set a value for a pm resource provided by clock or voltage device (regulator). The difference is that output of clock regulator is measured in Hz and named 'frequesncy' and output of voltage regulator os measured in mV and named 'voltage' which actually does not matter from API POV. So, i see more sense in having param_set(), parame_set_state() (set_state primitive for idle states) rather than in

clk_set_rate(), clk_set_state()
vltg_set(), vltg_set_state()
and, our analysis shows that you would end up with a separate type for domains, so it would be at least
domain_set_state() as well.

Quoted 2 lines

Typed notions are easier to understand,
read, and maintain.

common, after tricks with spinlocks in [merged!] RT patches? ;)

Eugeny

Quoted 8 lines

Quoted 7 lines

Basically a good way of thinking about parameter framework is that parameter framework would start from existed clock framework and gradually evolve by addressing voltages, relationship between clocks and voltages, domains. Eventually clock framework functionality would be a part of power parameter framework.

Quoted 8 lines

A better way would be to say that implementions of the clock interface on a given platform can build on whatever they need to build. That might include a "parameter" framework, if such a thing were defined in such a way that it became useful to such implementations.

- Dave

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 4 lines · ext Eugeny S. Mints

Quoted 4 lines · Eugeny S. Mints

Quoted 2 lines

Quoted 1 line

Would this involve replacing the clock framework, or are they going to coexist?

parameter framework would eventually replace clock framework.

Quoted 8 lines

Quoted 3 lines

That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement).

a cherry-picking on clk fw API:

- clk_set_rate() sticks to an individual clock - no way to set rates for number of clocks at once instead of having series of clk_set_rate() calls.

Quoted 4 lines

The former
for example is required for clocks which have required predefined ratio dependency though: two clocks always have to be n:2n and any other ratio leads to hardware misbehavior.

Quoted 3 lines

So, you can't go from 100:200 to 300:600 via series of clk_set_rate() for such clocks, i.e. 100:200 -> 300:200 -> 300:600 or 100:200 -> 100:600 -> 300:600 (see SH7722 hw for reference)

What's wrong with expanding the clk_fw?
All is needed is:
clk_set_rate_buffered(clk1, 300); clk_set_rate_buffered(clk2, 600); clk_rate_flush(); /* can include validation of the set */

Which is, incidentally, what OMAP2 does in hw for all the relevant clk dividers and it also provides validation for the new set of values.

Furthermore if the original assumption that complex transitions are allowed only atomically (p1A, p1B) => (p2A, p2B), hw support is mandatory, otherwise the transition is impossible, no matter what fancy sw fw is performing it.

Quoted 2 lines

- only a rate can be set up via clk_set_rate() while for a PLL I want to set up a desired idle state as well (btw there can be more than one idle state)

Is there any PLL which provide automatic switching between running/idle state? Do you have any HW architecture on your mind?

Quoted 1 line

- current API does not provide support for clock domains

So?

Quoted 1 line

a cherry-picking on clk fw implementation:

Quoted 3 lines

- clock tree structure and traversing clock tree code are duplicated in every architecture while can be done in arch independent way and just once (hint: what indeed is an arch specific thing it's a clock tree configuration)

that looks more like an optimisation to the clk fw, not a call for a brand new one

Quoted 1 line

Quoted 1 line

Quoted 1 line

Separate clock and voltage frameworks

Quoted 1 line

Quoted 1 line

Quoted 1 line

lead to code and functionality duplication

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

and do not address
such things as relationship between clocks and voltages, clock/voltage/power domains, etc needed for aggressive power management.

relationships are very arch specific so having or not the fw there wouldn't probably make any real difference.
About power domains ... well, what's the deal?
Aren't they controlled like voltages, in the end?

Quoted 4 lines

Quoted 3 lines

Most clocks don't have those issues. Why penalize all clocks for issues which only relate to a few? Better to only do that for the few cocks which have such additional constraints.

Quoted 8 lines

parameter fw would give exactly this behavior: relationship between clocks and voltages, clock/voltage/power domains implementation would be just additional arcs between nodes for clock and voltages. Nowadays clk fw has only one type of arcs - parent-child type. parameter fw would bring additional types. But clock nodes would be linked just with required arcs (of required type; both are arch specific things) so for an arch without any additional dependencies between clocks (and voltages) parameter fw would end up with exactly equivalent clock tree as clk fw for the arch has today.

I think what has to be clarified, is wether there is a real need for new features or not.

Quoted 9 lines

Quoted 6 lines

Plus, remember that the clock framework is an interface ... so by definition, it has no code associated with it. Hence no duplication of code is possible... at least at this hand-wavey "concept" level. Possibly a given implementation has scope for code sharing; but I doubt it. Code behind a given implementation of the clock interface is invariably quite slim.

and invariably looks like a hack and still duplicate clock tree building and traversing code.

Quoted 3 lines

Dependencies which exist in modern hw between clocks, clocks
and voltages require a more straight and standard technique to be set up for implementing clk/vltg/name_it framework.

Quoted 3 lines

Moving most of the code to be arch
independent and setting a clear rules on how a clock/vltg tree configuration would look like while just looking at a hw manual would help.

I think clocks and voltages providers have very different behaviours: for example a voltage src can sometimes be put in quiescent state, where the voltage value is preserved, but the max current is significantly reduced, therefore minimizing the leakage. I wouldn't welcome such functionality to be merged with clock handling.

Quoted 8 lines

Quoted 3 lines

If a clock being enabled implies a power or voltage domain being active, there's no reason that constraint shouldn't be enforced by whatever implementation a given platform uses.

true. but it's the same functionality required on different arches. and it can be done in arch independent way without penalties for arches which do not require the functionality. What's the rationale to move it down to arch specific code then?

I'd rather ask: what's the benefit of merging apples and oranges?

Quoted 11 lines

Quoted 3 lines

And having a generic -- basically untyped -- notion of "parameter" seems significantly less good than having a typed notion, with type-specific operations.

there is no type-specific operations. clk_set_rate() and vltg_set() basically do the same thing - set a value for a pm resource provided by clock or voltage device (regulator). The difference is that output of clock regulator is measured in Hz and named 'frequesncy' and output of voltage regulator os measured in mV and named 'voltage' which actually does not matter from API POV. So, i see more sense in having param_set(), parame_set_state() (set_state primitive for idle states) rather than in

See my comment above about different, peculiar, behaviour of voltages. And that's just an example.

Quoted 2 lines

clk_set_rate(), clk_set_state()
vltg_set(), vltg_set_state()

Quoted 3 lines

and, our analysis shows that you would end up with a separate type for domains, so it would be at least
domain_set_state() as well.

Quoted 4 lines

Quoted 2 lines

Typed notions are easier to understand,
read, and maintain.

common, after tricks with spinlocks in [merged!] RT patches? ;)

Quoted 3 lines

Eugeny

Quoted 5 lines · Igor Stoppa

Quoted 4 lines · ext Eugeny S. Mints

Quoted 4 lines · Eugeny S. Mints

Quoted 2 lines

Quoted 1 line

Would this involve replacing the clock framework, or are they going to coexist?

parameter framework would eventually replace clock framework.

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement).

a cherry-picking on clk fw API:

- clk_set_rate() sticks to an individual clock - no way to set rates for number of clocks at once instead of having series of clk_set_rate() calls.

This isn't "wrong", it's a "lack of feature". The normal process for addressing such things is to improve working/deployed software interfaces, not throw them out and try to create and deploy something new. :)

Plus, that's not actually true. When you change the rate for a parent clock, all its derived clocks necessarily change ... however many they may be. And there's nothing to prevent updating non-derived clocks.

Of course, such a change *does* touch on something I'd agree is a notable
omission: requests to change such a clock rate (call it a "base" rate for purposes of discussion here) are currently safe only if the related clocks have no drivers using them, since there's no way for those driver to either veto the change ("I can't support 115200 baud at that base rate"), or reclock to handle the changed environment ("update clock divisor to maintain current serial port baud rate").

Which is why currently most clock rates aren't currently changeable; and those which can be changed are mostly leaves on the clock tree.

On some platforms that significantly impacts what cpufreq (or whatever DVFS scheme is used) could achieve.

Quoted 4 lines

Quoted 4 lines

The former
for example is required for clocks which have required predefined ratio dependency though: two clocks always have to be n:2n and any other ratio leads to hardware misbehavior.

The programming interface doesn't preclude enforcement of that rule though. In fact, I'd call any *implementation* buggy if the hardware has such a rule about base rates, but the software doesn't enforce it. (That is: it's not an interface issue.)

Quoted 3 lines

Quoted 3 lines

So, you can't go from 100:200 to 300:600 via series of clk_set_rate() for such clocks, i.e. 100:200 -> 300:200 -> 300:600 or 100:200 -> 100:600 -> 300:600 (see SH7722 hw for reference)

AT91 (e.g. at91sam9263) processors have MCKR with similar restrictions, but the only time this could ever matter seems to be for cpufreq.

Does this matter to you for any other reason than trying to use the clock framework to implement cpufreq? If not, there's no need for the clock framework to define how to do this ... since cpufreq is so highly platform-specific.

If you want to say that this makes it hard to implement cpufreq in terms of the clock API, I'd agree ... but then, the *complete* lack of driver clock change notifications is a far bigger issue. Drivers like MMC/SD, UART, SPI, and I2C commonly need to update internal clock settings when rates change, and may need to plug their lowlevel I/O queues while those base clock rates change.

Quoted 6 lines

What's wrong with expanding the clk_fw?
All is needed is:
clk_set_rate_buffered(clk1, 300); clk_set_rate_buffered(clk2, 600); clk_rate_flush(); /* can include validation of the set */

Quoted 7 lines

Which is, incidentally, what OMAP2 does in hw for all the relevant clk dividers and it also provides validation for the new set of values.

Furthermore if the original assumption that complex transitions are allowed only atomically (p1A, p1B) => (p2A, p2B), hw support is mandatory, otherwise the transition is impossible, no matter what fancy sw fw is performing it.

I think Scott's "power transaction" notion is a bit better, since it should among other things provide a way to cope with cases like two concurrent tasks trying issue conflicting changes. An SMP system ought to be able to reclock two or more CPU cores at once; and maybe even do it with one "power transaction".

Quoted 5 lines

Quoted 2 lines

- only a rate can be set up via clk_set_rate() while for a PLL I want to set up a desired idle state as well (btw there can be more than one idle state)

Is there any PLL which provide automatic switching between running/idle state? Do you have any HW architecture on your mind?

And why should such a hardware-specific mechanism show up in an all-platforms API? There's quite a lot of hardware-specific stuff going on, and that seems like just one more instance of it.

Quoted 3 lines

Quoted 1 line

- current API does not provide support for clock domains

So?

Exactly. :)

And again, that's not strictly true either; the clock tree itself defines one kind of domain, also known as "subtrees".

A point I'll make below with respect to power domains: unless those domains need to be exposed for some reason to drivers, there is no need for these to show up the programming interface except as implementation artifacts. As in: activate this clock, and platform-specific stuff happens. It always does, of course, but in some cases it will be more extensive than in others.

(Activating a PLL normally takes more than setting a bit to open a clock gate; activating some clocks might invove kicking some clock or power domain logic.)

Quoted 1 line

Quoted 1 line

a cherry-picking on clk fw implementation:

Which platform's implementation? I've seen several...

Quoted 5 lines

Quoted 3 lines

- clock tree structure and traversing clock tree code are duplicated in every architecture while can be done in arch independent way and just once (hint: what indeed is an arch specific thing it's a clock tree configuration)

that looks more like an optimisation to the clk fw, not a call for a brand new one

And I'm not even sure calling it an "optimization" is correct.

Given how arch-specific the tree structure is, it's not clear that traversing it shouldn't be arch-specific too. And in any case ... the traversal code I've seen is so trivial I'd have a hard time worring about sharing it. Implementation flexibility seems to be widely useful in handling arch-specific differences.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Separate clock and voltage frameworks

Not that we _have_ a voltage framework yet, e.g. "turn on that that power rail, configured at 3.3V".

Plus rememember that a voltage framework is not synonymous with a DVFS kit ... and that a DVFS kit may need to interact with a lot more than just voltage and frequency controls. Example, reclocking CPU and memory frequency may need to run out of SRAM and without accessing page tables stored in DRAM.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

lead to code and functionality duplication

But since a clock is not a voltage, the primitives must differ. There's no analogue of "allocate 80 mA" for a clock, as there would be with a voltage framework's power budget primitives.

Quoted 8 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

and do not address
such things as relationship between clocks and voltages, clock/voltage/power domains, etc needed for aggressive power management.

relationships are very arch specific so having or not the fw there wouldn't probably make any real difference.
About power domains ... well, what's the deal?
Aren't they controlled like voltages, in the end?

The last time I looked at a power domain, it was more like a prerequisite to using various device clocks. It wasn't something that needed to be exposed in an API ... it would suffice to have it be activated/deactivated as a side effect of accessing those clocks.

That is, the existing hooks suffice. The platform-specific code to enable a given clock subtree would just have a few lines of code teaching it how to enable the relevant power domain. They already rely on platform-specific logic to sort out which register bank to touch, which bits there, and various other things.

Although that recent work for memory partitioning is relevant here too: being able to power down banks of DRAM (ensuring they hold no data or code that's currently needed) can certainly cut down one category of power drain.

In the same vein, some utilities to manage on-chip SRAM would likely be helpful. It's common that certain low power modes disable all DRAM, leaving only (say) 16 KB of SRAM available for running code ... or that DRAM be unavailable while CPU and/or memory are being reclocked (maybe by a DVFS scheme, using cpufreq or whatever).

Quoted 13 lines

Quoted 4 lines

Quoted 3 lines

Most clocks don't have those issues. Why penalize all clocks for issues which only relate to a few? Better to only do that for the few cocks which have such additional constraints.

Quoted 8 lines

parameter fw would give exactly this behavior: relationship between clocks and voltages, clock/voltage/power domains implementation would be just additional arcs between nodes for clock and voltages. Nowadays clk fw has only one type of arcs - parent-child type. parameter fw would bring additional types. But clock nodes would be linked just with required arcs (of required type; both are arch specific things) so for an arch without any additional dependencies between clocks (and voltages) parameter fw would end up with exactly equivalent clock tree as clk fw for the arch has today.

Quoted 2 lines

I think what has to be clarified, is wether there is a real need for new features or not.

Not just "new features" but "new cross-platform features". This PM stuff is really down'n'dirty code ... who will be working with such code? The less we demand of those people, the more likely it is that such features would actually be delivered in working form. A lot of platform vendors work with older kernel releases (2.6.10 etc), which means that new APIs will be obstacles to development and deployment.

Going back to clock and power domain examples above: it's *easy* to see how those could be delivered using the current clock framework. There are a LOT of folk who are familiar with those interfaces -- today. So unless there really is no way to address the issue with the current APIs, it's best to avoid creating new interfaces for those issues.

Quoted 9 lines

Quoted 9 lines

Quoted 6 lines

Plus, remember that the clock framework is an interface ... so by definition, it has no code associated with it. Hence no duplication of code is possible... at least at this hand-wavey "concept" level. Possibly a given implementation has scope for code sharing; but I doubt it. Code behind a given implementation of the clock interface is invariably quite slim.

and invariably looks like a hack and still duplicate clock tree building and traversing code.

Most cases I've seen build the clock tree with a bunch of static struct declarations, so the building is all at compile time ... and could hardly duplicate something on another platform, since it's all platform-specific. And as noted above, traversal code is trivial ...

Quoted 3 lines

Quoted 3 lines

Dependencies which exist in modern hw between clocks, clocks
and voltages require a more straight and standard technique to be set up for implementing clk/vltg/name_it framework.

I think Linus has pointed out that cut'n'paste is a very straightforward and standard technique. :)

The clock-to-clock dependencies are handled by the clock framework already. As are at least some cases of power domains.

DVFS -- cpufreq or otherwise -- is the primary example of a case where coupling is needed between clocks and voltages. These PM discussions lately seem to dance around DVFS without saying so explicitly ... seemingly, to avoid the "so why not just fix cpufreq" discussions that would (should!) naturally follow.

My own two cents on the cpufreq thing: (a) it should support the driver model better; (b) a generic "run from SRAM" solution would be an aid to that and other PM code; (c) without clock framework support for drivers being able to reject changes or else re-clock, changing base clocks is often impractical; (d) I don't recall seeing anyone really answer the "so why not ust fix cpufreq" question.

Quoted 8 lines

Quoted 3 lines

Moving most of the code to be arch
independent and setting a clear rules on how a clock/vltg tree configuration would look like while just looking at a hw manual would help.

I think clocks and voltages providers have very different behaviours: for example a voltage src can sometimes be put in quiescent state, where the voltage value is preserved, but the max current is significantly reduced, therefore minimizing the leakage. I wouldn't welcome such functionality to be merged with clock handling.

Another good example of these APIs being domain-specific ... though in a way it's a special case of the one I gave above. In a similar vein, lower current (but not quiescent) modes may be able to use alternate schemes for voltage regulation. The regulation may need software inputs to switch schemes.

Quoted 10 lines

Quoted 8 lines

Quoted 3 lines

If a clock being enabled implies a power or voltage domain being active, there's no reason that constraint shouldn't be enforced by whatever implementation a given platform uses.

true. but it's the same functionality required on different arches. and it can be done in arch independent way without penalties for arches which do not require the functionality. What's the rationale to move it down to arch specific code then?

I'd rather ask: what's the benefit of merging apples and oranges?

Someone may be tiring of a steady diet, and wants to become a chef? :)

I'll repeat that power and clock domain examples above: the current clock framework is **ALREADY** arch-independant in exactly the way Eugeny sketched, for several platforms.

Quoted 12 lines

Quoted 11 lines

Quoted 3 lines

And having a generic -- basically untyped -- notion of "parameter" seems significantly less good than having a typed notion, with type-specific operations.

there is no type-specific operations. clk_set_rate() and vltg_set() basically do the same thing - set a value for a pm resource provided by clock or voltage device (regulator). The difference is that output of clock regulator is measured in Hz and named 'frequesncy' and output of voltage regulator os measured in mV and named 'voltage' which actually does not matter from API POV. So, i see more sense in having param_set(), parame_set_state() (set_state primitive for idle states) rather than in

Quoted 2 lines

See my comment above about different, peculiar, behaviour of voltages. And that's just an example.

One of several, I added more ...

Quoted 2 lines

Quoted 2 lines

clk_set_rate(), clk_set_state()
vltg_set(), vltg_set_state()

vtg_allocate_budget() would have no clock domain analogue, nor would vtg_free_budget() ...

Quoted 3 lines

Quoted 3 lines

and, our analysis shows that you would end up with a separate type for domains, so it would be at least
domain_set_state() as well.

See my comments above re clock and voltage domains, applicable to at least half a dozen platforms.

Until you share your analysis, so we can see what we agree and disagree with, it's not helpful for you to claim that it supports your argument.

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

Typed notions are easier to understand,
read, and maintain.

common, after tricks with spinlocks in [merged!] RT patches? ;)

I don't follow this comment. I'm still waiting to see the NO_HZ stuff become as stable and fast as the previous NO_IDLE_HZ stuff ... but none of that seems to relate to type-unsafe programming interfaces.

- Dave

Quoted 3 lines

Quoted 3 lines

Eugeny

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Hi,

Although I agree that the current clock framework can handle power or voltage domains in many platforms, having something like (struct clk powerdomain1, powerdomain2;) does not seem like a good implementation, a struct for clocks representing a power domain.

If a new framework is more straighforward and introduces a negligible overhead to the current kernel, I think it is worthwhile to have a look at it. Plus this new framework might be able to take care of those platforms that are not nicely supported by the current clock framework.

Quoted 7 lines · Igor Stoppa

Quoted 6 lines · ext Eugeny S. Mints

Quoted 6 lines · Eugeny S. Mints

Quoted 2 lines

Quoted 1 line

Would this involve replacing the clock framework, or are they going to coexist?

parameter framework would eventually replace clock framework.

That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement).

Quoted 4 lines

Quoted 4 lines

a cherry-picking on clk fw API:

- clk_set_rate() sticks to an individual clock - no way to set rates for number of clocks at once instead of having series of clk_set_rate() calls.

This isn't "wrong", it's a "lack of feature". The normal process for addressing such things is to improve working/deployed software interfaces, not throw them out and try to create and deploy something new. :)

- PM resource representation
Similar to the device abstraction available today.

I surprised you didn't comment
on original Matthew's post since it contains so many points to discuss.

Quoted 2 lines · Dmitry Krivoschekov

I surprised you didn't comment
on original Matthew's post since it contains so many points to discuss.

As a direction, it sounded better than many notions I've seen here.

But there was a certain lack of ... detail ... making discussion impractical, except as speculation.

The goal of this parameter framework is to expose the resources in a way that allows other s/w (governors, policy mangers, etc) to control the resources while keeping the system operational. One of the main requirements in our thinking is that we want this layer to represent the h/w and not include policy or decision making. Meaning the software using the parameter framework would be responsible for deciding the appropriate value for the parameters.

Quoted 6 lines · Ikhwan Lee

Hi,

Although I agree that the current clock framework can handle power or voltage domains in many platforms, having something like (struct clk powerdomain1, powerdomain2;) does not seem like a good implementation, a struct for clocks representing a power domain.

Good thing that's not what I suggested then, right? :)

The point was that in the examples I've seen, the power domains are associated with clock domains, so that each clock is tied to one power domain. And since you can't use the power domain without having a clock ... the implementation can tell if it's got to activate a power domain by looking at the clock.

There may be other models of power domain, but that's the one I've had reason to look at (which isn't synonymous with a straight voltage/current supply).

Quoted 5 lines

If a new framework is more straighforward and introduces a negligible overhead to the current kernel, I think it is worthwhile to have a look at it. Plus this new framework might be able to take care of those platforms that are not nicely supported by the current clock framework.

Perhaps when we see one, we could discuss that as somethong other than pure handwaving. But that still won't address the basic point that it's wrong to assume the clock framework should be written out of the picture.

- Dave

For me, there is a point that seems debatable already at the starting stage:

Quoted 7 lines

The goal of this parameter framework is to expose the resources in a way that allows other s/w (governors, policy mangers, etc) to control the resources while keeping the system operational. One of the main requirements in our thinking is that we want this layer to represent the h/w and not include policy or decision making. Meaning the software using the parameter framework would be responsible for deciding the appropriate value for the parameters.

Sometimes it's quite reasonable to make decisions (or policy) at the low level, without exposing events to higher layers,

e.g. turning a clock off when reference counter gets zero, this is what OMAP's clock framework currently does.

Hi,

Quoted 10 lines · David Brownell

Quoted 6 lines · Ikhwan Lee

Hi,

Although I agree that the current clock framework can handle power or voltage domains in many platforms, having something like (struct clk powerdomain1, powerdomain2;) does not seem like a good implementation, a struct for clocks representing a power domain.

Good thing that's not what I suggested then, right? :)

Quoted 5 lines

The point was that in the examples I've seen, the power domains are associated with clock domains, so that each clock is tied to one power domain. And since you can't use the power domain without having a clock ... the implementation can tell if it's got to activate a power domain by looking at the clock.

True, although sometimes it gets dirty because multiple clock sources are associated with one power domain

at the same time multiple power
domains are associated with one clock source.

Simple parent and child
relationship provided by the clock framework is not always enough.

Quoted 11 lines

There may be other models of power domain, but that's the one I've had reason to look at (which isn't synonymous with a straight voltage/current supply).

Quoted 5 lines

If a new framework is more straighforward and introduces a negligible overhead to the current kernel, I think it is worthwhile to have a look at it. Plus this new framework might be able to take care of those platforms that are not nicely supported by the current clock framework.

Quoted 4 lines

Perhaps when we see one, we could discuss that as somethong other than pure handwaving. But that still won't address the basic point that it's wrong to assume the clock framework should be written out of the picture.

I think we can reach an agreement. The clock framework does not need to be replaced with a new one since it is serving its purpose well enough. If extra functionalities are needed for clocks, we can extend the existing clock framework. Such extensions will include functions like clk_set_rate_pending() and power_transaction_commit(). However, since clocks and voltages (or power domains) have different characteristics, it is desirable to have a separate framework for power domains and associate that framework with the existing clock framework.

I am not sure if this is the direction that the original PowerOp people suggested. If we can agree on this, however, I think we can proceed to look at the code.

Quoted 3 lines · Dmitry Krivoschekov

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.

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.

Quoted 2 lines

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

gating is what the clock framework is defined as doing; there's nothing OMAP-specific about that.

The interesting bit for OMAP is that clock gating will often be done in hardware, not just in software.

There are other low-power SOC
designs that do such things,

Quoted 6 lines · David Brownell

Quoted 3 lines · Dmitry Krivoschekov

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?

Quoted 10 lines

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.

Quoted 2 lines

e.g. turning a clock off when reference counter gets zero, this is what OMAP's clock framework currently does.

Quoted 2 lines

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.

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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?

Do you really expect every single
algorithm choice to be packaged as a pluggable policy?

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.

Quoted 7 lines

Quoted 7 lines

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.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 10 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 4 lines

Any
time I've seen systems designed that way, those pluggabilty hooks have been a major drag on performance and maintainability.

Quoted 3 lines

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.

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.

Quoted 15 lines

Quoted 7 lines

Quoted 7 lines

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.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 5 lines

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

Quoted 23 lines · ext Dmitry Krivoschekov

Quoted 9 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 4 lines

Any
time I've seen systems designed that way, those pluggabilty hooks have been a major drag on performance and maintainability.

Quoted 7 lines

Quoted 3 lines

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?

Quoted 27 lines

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.

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

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.

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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?

Quoted 7 lines

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.

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?

(quoted diff) +0 -2

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

Quoted 37 lines · Igor Stoppa

Quoted 23 lines · ext Dmitry Krivoschekov

Quoted 9 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 4 lines

Any
time I've seen systems designed that way, those pluggabilty hooks have been a major drag on performance and maintainability.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

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.

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.

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.

Quoted 35 lines

Quoted 34 lines

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.

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

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.

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 17 lines

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?

(quoted diff) +0 -2

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

Quoted 23 lines · ext Dmitry Krivoschekov

Quoted 9 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 4 lines

Any
time I've seen systems designed that way, those pluggabilty hooks have been a major drag on performance and maintainability.

Quoted 7 lines

Quoted 3 lines

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?

Quoted 27 lines

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.

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

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.

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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?

Quoted 7 lines

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.

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

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

Quoted 4 lines

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.

Quoted 31 lines · Igor Stoppa

Quoted 30 lines · ext Dmitry Krivoschekov

Quoted 9 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 1 line

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.

Quoted 1 line

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.

Quoted 7 lines

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.

Quoted 35 lines

Quoted 34 lines

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.

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

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.

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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

Quoted 1 line

I find that a bogus example.

It's just a technical example.

Quoted 1 line

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.

Quoted 10 lines

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.

Quoted 7 lines

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.

Quoted 8 lines

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

Quoted 32 lines · ext Dmitry Krivoschekov

Quoted 31 lines · Igor Stoppa

Quoted 30 lines · ext Dmitry Krivoschekov

Quoted 9 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 1 line

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.

Quoted 9 lines

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.

Quoted 12 lines

Quoted 8 lines

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.

Quoted 3 lines

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:

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

case 2-i'm saying that it is simpler to rely on drivers doing their job,

as they are doing right now, on OMAP, at least, of releasing resources

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

_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

Quoted 2 lines

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

Quoted 5 lines

_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.
Are you against addition some features to it, such as enable/disable "turn the unused clock off"

Quoted 38 lines · Igor Stoppa

Quoted 37 lines · ext Dmitry Krivoschekov

Quoted 24 lines · Igor Stoppa

Quoted 23 lines · ext Dmitry Krivoschekov

Quoted 9 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 4 lines

Any
time I've seen systems designed that way, those pluggabilty hooks have been a major drag on performance and maintainability.

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Anyway in the USB example mentioned the rule is very high level,

Quoted 3 lines

Quoted 1 line

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.

Quoted 10 lines

Quoted 9 lines

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 :)

Quoted 12 lines

Quoted 12 lines

Quoted 8 lines

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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 1 line

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?

Quoted 1 line

as they are doing right now, on OMAP, at least, of releasing resources

Did you think of other archs?

Quoted 2 lines

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

Quoted 5 lines

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

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?

Thanks,
Dmitry

Hi!

Quoted 8 lines

Quoted 2 lines

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

Quoted 5 lines

_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

Quoted 4 lines

Ok, seems you are happy with current clock framework and advocating it to be as is.
Are you against addition some features to it, such as enable/disable "turn the unused clock off"

What kind of debate is this?!

Of course I and everyone else is against adding features without _really good_ explanation why this is needed. And no, you should not even ask unless you have patch ready,

Quoted 42 lines · ext Dmitry Krivoschekov

Quoted 41 lines · Igor Stoppa

Quoted 32 lines · ext Dmitry Krivoschekov

Quoted 31 lines · Igor Stoppa

Quoted 30 lines · ext Dmitry Krivoschekov

Quoted 9 lines · David Brownell

Quoted 7 lines · Dmitry Krivoschekov

Quoted 4 lines · David Brownell

Quoted 2 lines · Dmitry Krivoschekov

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.

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 1 line

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.

Quoted 5 lines

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.

Quoted 25 lines

Quoted 10 lines

Quoted 9 lines

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 :)

Quoted 14 lines

Quoted 14 lines

Quoted 7 lines

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 2 lines

Quoted 1 line

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

Quoted 3 lines

Quoted 2 lines

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.

Quoted 7 lines

Quoted 5 lines

_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

Quoted 6 lines

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?

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 5 lines

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

Your approach is to just label policy what you want to kick out of the driver =) Nice one!

Quoted 2 lines

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

Quoted 2 lines

Are you against addition some features to it, such as enable/disable "turn the unused clock off" rule,

Quoted 2 lines

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?

And you should definitely read the first chapter of the "Linux Device drivers" book, see "The Role of the Device Driver" section.

Quoted 5 lines

Quoted 4 lines

Ok, seems you are happy with current clock framework and advocating it to be as is.
Are you against addition some features to it, such as enable/disable "turn the unused clock off"

Quoted 5 lines

What kind of debate is this?!

Of course I and everyone else is against adding features without _really good_ explanation why this is needed. And no, you should not even ask unless you have patch ready,

If I understand you correctly, you are against big debates unless a patch is ready,

I agree to that if someone tries to speculate on adding some feature which is easily

can be shown as a patch, but before doing something more complex, say new subsystem,
it is worth to make sure whether your intention makes sense at all, and if it does

the first question would be:

Q: Does Linux Power management take care about personal computers only?
A: ????

P.S. Are there special Etiquette notes for the list?

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.

Quoted 2 lines

If I understand you correctly, you are against big debates unless a patch is ready,

You understood it well.

But we do not want new subsystem. We want power management to work. Take a look how Alan added pm to usb... and just do it like him. If some code makes sense to be shared, share it. But start with support for platform you care about and don't overdesign it.

Quoted 4 lines

But we do not want new subsystem. We want power management to work. Take a look how Alan added pm to usb... and just do it like him. If some code makes sense to be shared, share it. But start with support for platform you care about and don't overdesign it.

Note, Alan didn't do it by himself. The autosuspend stuff built on previous work in USB PM, and this DID get discussed -- as concrete proposals -- before he did all that good stuff.

Hi!

Quoted 5 lines

Quoted 4 lines

But we do not want new subsystem. We want power management to work. Take a look how Alan added pm to usb... and just do it like him. If some code makes sense to be shared, share it. But start with support for platform you care about and don't overdesign it.

Quoted 3 lines

Note, Alan didn't do it by himself. The autosuspend stuff built on previous work in USB PM, and this DID get discussed -- as concrete proposals -- before he did all that good stuff.

Okay, you are right. But I do not remember any "handwaving" phase... (And sorry for not giving credit where it was due, obviously Alan did not do it all by himself).

Quoted 2 lines

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.

There are patches to allow disabling it at runtime through sysfs attributes of any given device.

The primary reason to have one is bugs in those external devices, where they don't behave according to the USB spec. That's the

Quoted 6 lines · David Brownell

Quoted 2 lines

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.

There are patches to allow disabling it at runtime through sysfs attributes of any given device.

Quoted 2 lines

The primary reason to have one is bugs in those external devices, where they don't behave according to the USB spec. That's the

If I didn't miss something, the primary reason was to allow devices to charge batteries from the bus, so, does USB specs restrict this somehow? Or, what's wrong with that?

Quoted 11 lines · Dmitry Krivoschekov

Quoted 7 lines · David Brownell

Quoted 2 lines

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.

There are patches to allow disabling it at runtime through sysfs attributes of any given device.

The primary reason to have one is bugs in those external devices, where they don't behave according to the USB spec. That's the

If I didn't miss something, the primary reason was to allow devices to charge batteries from the bus, so, does USB specs restrict this somehow? Or, what's wrong with that?

You're mixing up two distinct issues:

- Minimizing power use by the USB host ... to stretch its battery life, or otherwise shrink its power usage, starting with current delivered between on USB (between VBUS and GND).

- How the peripheral uses whatever VBUS current it draws ... which can power arbitrary electronics, including a battery charger, but might be nothing more than powering the USB link. (FWIW that's all the Nokia 800 does with VBUS; that helps stretch battery life.)

Clearly there's some competition there. The default policy allows autosuspend. The primary reason to disable autosuspend is, as I said, that some devices don't work well with it. (Flakey circuits or firmware, etc.)

However, enabling autosuspend *does* have a side effect that would matter for those few devices that use VBUS to recharge a battery:
the VBUS current going to a suspended device is almost certainly not enough to recharge anything substantial. So -- for those few devices that do recharge batteries over USB -- yes, another reason to disable autosuspend might be to help recharge a battery.

I clearly understand these distinct issues, I read Oliver's comments for "switching off autosuspend through sysfs" patch, where he said "This is needed for devices which recharge their batteries of the bus" (but nothing regarding improper behavior of some devices)

so I decided you was referring
to that issue, that made me think that I overlooked something in USB spec :)

Anyway, thanks for your explanation.

If I didn't miss something, the primary reason was to allow devices to charge batteries from the bus, so, does USB specs restrict this somehow? Or, what's wrong with that?

Quoted 6 lines

I clearly understand these distinct issues, I read Oliver's comments for "switching off autosuspend through sysfs" patch, where he said "This is needed for devices which recharge their batteries of the bus" (but nothing regarding improper behavior of some devices)

Sometimes people have been known to focus too much on secondary issues. ;)