Hi Guys,

Sorry, I think the conversation went pretty far from my patch.  

Concerning my original patch, do you have any more ideas or concerns?

I'm not sure I have a clear idea what, if anything, needs to be changed.

I was able to verify it on the TC2 platform without issue.

Thanks again for all of your time.

Sebastian

On 22 May 2013 11:51, Sebastian Capella <sebastian.capella@linaro.org> wrote:

Quoting Dave Martin (2013-05-22 11:22:36)

> Currently not.  This partly depends on whether the target residency is
> supposed to be a hint about the rough order of magnitude of the expected
> idle period, or whether it's supposed to be a strict contract.
>
> In effect, I think it's a hint which steers the choice of powerdown
> state, rather than soemthing with a strong real-time guarantee attached
> to it.  In that case shaving the firmware latency off this value before
> using it may not be worth it.  If the specified target residency is
> small enough that this makes a significant difference, this suggests a
> very short period of actual powerdown, which may not outweigh its own
> overheads in terms of power-saving.
>

Thanks Dave, Liviu,

Sorry, you've caught me mixing terms and concepts.

I agree, target residency to me also is more an estimate of the cost vs.
benefit for a state.

The cstates also define a latency parameter that is used for limiting
selection of certain states by the governor.  This is affected by QoS
constraints, which we use alot in embedded.  This is the one needed for
realtime use that is tricky with host os' additional latency.

Both latency and target residency would need some adjustment for
embedded mobile if we have additional overhead as it becomes very
important to squeeze this as much as possible.  For latency,
microseconds count as we cannot allow a cstate which will fail to meet
our qos constraints.

Thanks,

Sebastian