Skip to content

Additional LPM documentation updates #259

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 9, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -317,7 +317,7 @@ The benefits of using MCU Only mode:
or a network communication task.
#. Respond to interrupts: This allows the system to still respond to external events, while it is in a low-power state.

To enter MCU Only mode, set :code:`100000 usec` resume latency for CPU0 in linux:
To enter MCU Only mode, set :code:`100 msec` resume latency for CPU0 in Linux:

.. code-block:: console

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -180,7 +180,8 @@ Resume Latency Constraint
This constraint is exposed to the user-level through the existing sysfs PM QoS interface for CPU Cores.
Default constraint is "no constraint", but it can be changed as shown in the examples below:

a. To set 100000 usec resume latency for the SoC, a constraint can be placed for CPU0 (or any other CPU core):
a. To set 100 msec resume latency for the SoC, a constraint can be placed for
CPU0 (or any other CPU core):

.. code:: console

Expand All @@ -195,11 +196,6 @@ Default constraint is "no constraint", but it can be changed as shown in the exa
Setting a resume latency constraint impacts the deepest low power mode system can enter.
The various modes and their latencies are documented here: https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#tisci-msg-lpm-set-latency-constraint

If a device wants to put a constraint to not be powered-off, it can use the Linux
QoS framework and set the ``DEV_PM_QOS_RESUME_LATENCY`` equal to 0.
An example is shown in the following RemoteProc driver:
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/remoteproc/ti_k3_r5_remoteproc.c?h=11.00.09#n549

.. note::

The constraints need to be set before each system suspend as DM firmware clears all
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -677,14 +677,20 @@ triggered by grounding Pin 11 or Pin 22 on J8 MCU Header, respectively.
Confirming the Wakeup event type
********************************

When the SoC wakes up from any Low Power Mode, the Device Manager logs the wake reason.
This wake reason can be queried by Linux using the `TISCI LPM API <https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html>`__.
When the SoC wakes up from any Low Power Mode, the Device Manager logs the wake
reason, the pin number that triggered the wakeup, and the last low power mode
entered. This wake reason and low power mode can be queried by Linux using the
`TISCI LPM API <https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html>`__.
The wakeup pin can be found in the datasheet by converting the pin number from
hex to decimal and finding the corresponding PADCONFIG register.

This wake reason is printed as part of the Linux suspend/resume log:

.. code-block:: console

[ 37.357109] CPU3 is up
[ 37.357710] ti-sci 44043000.system-controller: ti_sci_resume: wakeup source: 0x50
[ 249.471725] CPU3 is up
[ 249.472314] ti-sci 44043000.system-controller: ti_sci: wakeup source:0x80, pin:0x72, mode:0x1

In the above example, 0x50 means that WKUP_RTC0 is the wakeup source.
In the above example, the wakeup source of 0x80 is MAIN_IO. The 0x72 pin refers
to PADCONFIG114. This means the cause of the wakeup event is UART0_RXD. The
mode of 0x1 is the last low power mode entered which was MCU_ONLY.