On Tue, May 21, 2013 at 01:39:38AM +0100, Sebastian Capella wrote: > Hi Nico, Liviu, Catalin,
Hi Sebastian, > > Do you expect there to also be cases where the PSCI interface may > not be aware of all of the platform states? Not sure why the PSCI interface would have a say here. It's only an interface between two pieces of code, it should not have state awareness. Which side of the interface are you actually thinking of? > > Eg. if you have an SOC, not all of the cstates and latencies are > directly related to the ARM core.. Maybe you can have > additional states and latencies accounting for the cost of > enabling external power supplies, restoring state for > non-retained peripherals/hw, etc. I don't think there is any C-state other than simple idle (which translates into an WFI for the core) that *doesn't* take into account power domain latencies and code path lengths to reach that state. I don't see the usefulness of describing the latency of going into CPU_OFF state without including all the steps to reach the state and come back out of it. Are you thinking of C-states that do not belong to the compute domain but might still be part of the SoC? (things like an System MMU, or a DMA engine, etc) > > Currently, this type of thing can be specified in cpuidle with > aditional cstates and handled in vendor specific sw, with the > additional cstates being selected when the TR/latency requirements > are least restrictive. > > How would these states be handled considering also host os costs? I don't know how to draw the line between the host OS costs and the guest OS costs when using target latencies. On one hand I think that the host OS should add its own costs into what gets passed to the guest and the guest will see a slower than baremetal system in terms of state transitions; on the other hand I would like to see the guest OS shielded from this type of information as there are too many variables behind it (is the host OS also under some monitor code? are all transitions to the same state happening in constant time or are they dependent of number of cores involved, their state, etc, etc) If one uses a simple set of C-states (CPU_ON, CPU_IDLE, CPU_OFF, CLUSTER_OFF, SYSTEM_OFF) then the guest could make requests independent of the host OS latencies _after the relevant translations between time-to-next-event and intended target C-state have been performed_ . Hope this helps, Liviu > > Thanks, > > Sebastian > > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
