Re: [PATCH 1/6] dt-bindings: ti,sci: Add ti,ctx-memory-region property

[Nishanth Menon <nm@ti.com>]

On 14:10-20220422, Dave Gerlach wrote:
> Hi,
> 
> On 4/22/22 14:02, Andrew Davis wrote:
> > On 4/21/22 3:36 PM, Dave Gerlach wrote:
> >> Add documentation for the ti,ctx-memory-region property which is a
> >> phandle to a reserved-memory carveout to be used by the ti_sci driver
> >> storage of low power mode memory context. This is optional for normal
> >> system operation but required to enabled suspend-to-mem usage of Deep
> >> Sleep state.
> >>
> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> >> ---
> >>   .../devicetree/bindings/arm/keystone/ti,sci.yaml         | 9 +++++++++
> >>   1 file changed, 9 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> >> index 34f5f877d444..ec88aa88a2a0 100644
> >> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> >> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> >> @@ -61,6 +61,15 @@ properties:
> >>     mboxes:
> >>       minItems: 2
> >>   
> >> +  ti,ctx-memory-region:
> >> +    description:
> >> +      Phandle to the reserved memory node to be associated with the
> >> +      ti-sci device, to be used for saving low power context. The
> >> +      reserved memory node should be a carveout node, and should
> >> +      be defined as per the bindings in
> >> +      Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> >> +    $ref: /schemas/types.yaml#/definitions/string
> >> +
> > 
> > 
> > Why does this have to be yet another reserved carveout region,
> > should be dynamically allocated.
> > 
> 
> This must be a fixed address in order to support other low power modes
> which have not yet been introduced.

Please elaborate the need - Many of our devices, esp the AM62 class ones
are memory constrained devices - LPM states are controlled entry states, why
should we loose a chunk of DDR in operational state while waiting for
the suspend or idle state to be invoked?
OR, is the argument is as follows:
- need a guarenteed memory for me to enter low power and not be
  dependent on availability on attempt.
- Latency overhead of allocation during a "hot path" such as cpu idle,
  this is completely unacceptable?

  or something of that form.. please elaborate?
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D