lkml.org 
[lkml]   [2022]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/6] dt-bindings: ti,sci: Add ti,ctx-memory-region property
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

\
 
 \ /
  Last update: 2022-04-23 15:37    [W:0.069 / U:4.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site