Thread (24 messages) 24 messages, 6 authors, 2014-01-29

[PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings

From: Lorenzo Pieralisi <hidden>
Date: 2014-01-27 18:22:07
Also in: linux-devicetree, linux-pm

On Mon, Jan 27, 2014 at 12:48:15PM +0000, Antti P Miettinen wrote:
From: Lorenzo Pieralisi <redacted>
quoted
That's why I defined the worst case. How did you implemented it in your
idle drivers ? That would help generalize it, after all these bindings
are there to simplify drivers upstreaming, feedback welcome.
Currently we do not handle this well downstream either. The problem
with worst case is that the absolute worst case can be really bad and
probability of it might be very low. Sorry - no ready answer :-)
Point taken, but these bindings still get us to a point that is much
better than today situation. After all, if the worst case can happen
either we design for worst case or we update parameters at runtime in
the kernel (which is not happening as of now) according to a notification
mechanism.

It is certainly worth investigating, probably we can define OPPs as
generic (ie not tied to the CPU), as performance point or system
operating points. I will think about this.

In the meantime if you have further pieces of feedback please keep them
coming.

Thanks,
Lorenzo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help