diff options
| author | davidcunado-arm <david.cunado@arm.com> | 2017-10-06 10:38:42 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-10-06 10:38:42 +0100 |
| commit | a368922f57f17719257871c48e2b7521fcaf3640 (patch) | |
| tree | 47561407b6c49c1a902eb0470ec7376b7968df26 /docs | |
| parent | c64d1345a8227ec9c9d8f8fa6a6c3e5e487b82f0 (diff) | |
| parent | c5229f8c0d46a4a4c2fa18adf635337c1a5bc5ba (diff) | |
Merge pull request #1116 from soby-mathew/sm/gicv3_save_restore
GICv3 context save and restore
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/porting-guide.rst | 33 |
1 files changed, 28 insertions, 5 deletions
diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst index 97985666..6c07b2eb 100644 --- a/docs/porting-guide.rst +++ b/docs/porting-guide.rst @@ -2107,13 +2107,32 @@ power domain levels. The handler needs to perform power management operation corresponding to the local state at each power level. The generic code expects the handler to succeed. -The difference between turning a power domain off versus suspending it -is that in the former case, the power domain is expected to re-initialize -its state when it is next powered on (see ``pwr_domain_on_finish()``). In the -latter case, the power domain is expected to save enough state so that it can -resume execution by restoring this state when its powered on (see +The difference between turning a power domain off versus suspending it is that +in the former case, the power domain is expected to re-initialize its state +when it is next powered on (see ``pwr_domain_on_finish()``). In the latter +case, the power domain is expected to save enough state so that it can resume +execution by restoring this state when its powered on (see ``pwr_domain_suspend_finish()``). +When suspending a core, the platform can also choose to power off the GICv3 +Redistributor and ITS through an implementation-defined sequence. To achieve +this safely, the ITS context must be saved first. The architectural part is +implemented by the ``gicv3_its_save_disable()`` helper, but most of the needed +sequence is implementation defined and it is therefore the responsibility of +the platform code to implement the necessary sequence. Then the GIC +Redistributor context can be saved using the ``gicv3_rdistif_save()`` helper. +Powering off the Redistributor requires the implementation to support it and it +is the responsibility of the platform code to execute the right implementation +defined sequence. + +When a system suspend is requested, the platform can also make use of the +``gicv3_distif_save()`` helper to save the context of the GIC Distributor after +it has saved the context of the Redistributors and ITS of all the cores in the +system. The context of the Distributor can be large and may require it to be +allocated in a special area if it cannot fit in the platform's global static +data, for example in DRAM. The Distributor can then be powered down using an +implementation-defined sequence. + plat\_psci\_ops.pwr\_domain\_pwr\_down\_wfi() ............................................. @@ -2159,6 +2178,10 @@ The ``target_state`` (first argument) has a similar meaning as described in the ``pwr_domain_on_finish()`` operation. The generic code expects the platform to succeed. +If the Distributor, Redistributors or ITS have been powered off as part of a +suspend, their context must be restored in this function in the reverse order +to how they were saved during suspend sequence. + plat\_psci\_ops.system\_off() ............................. |
