diff --git a/source/linux/Foundational_Components/Power_Management/pm_dfs.rst b/source/linux/Foundational_Components/Power_Management/pm_dfs.rst index 6c2db7067..cc0e87b38 100644 --- a/source/linux/Foundational_Components/Power_Management/pm_dfs.rst +++ b/source/linux/Foundational_Components/Power_Management/pm_dfs.rst @@ -332,9 +332,10 @@ table. }; To disable any of the above OPP's one can simply add + .. code-block:: dts - status = "disabled"; + status = "disabled"; to the corresponding DT Node. diff --git a/source/linux/Foundational_Components/Power_Management/pm_low_power_modes.rst b/source/linux/Foundational_Components/Power_Management/pm_low_power_modes.rst index e20361b18..a5631574e 100644 --- a/source/linux/Foundational_Components/Power_Management/pm_low_power_modes.rst +++ b/source/linux/Foundational_Components/Power_Management/pm_low_power_modes.rst @@ -54,7 +54,7 @@ sources is found to be enabled, Partial I/O is entered instead of poweroff. The following wakeup sources have been configured for Partial I/O: mcu_uart0, mcu_mcan0, and mcu_mcan1. Partial I/O mode can only be tested -when `k3-am62x-sk-lpm-wkup-sources.dtso `__ +when `k3-am62x-sk-lpm-wkup-sources.dtso `__ overlay is loaded. Please refer to :ref:`How to enable DT overlays` for more details. After Linux boots, the MCAN wakeup for Partial I/O is enabled using the @@ -250,7 +250,7 @@ The benefits of using deep sleep in embedded devices: reducing the amount of time that the processor is idle. This is because the processor can be kept in a low-power state when it is not needed. -In order to enter deep sleep, use the following command: +In order to enter Deep Sleep, use the following command: .. ifconfig:: CONFIG_part_variant in ('AM62X') @@ -298,7 +298,7 @@ In order to enter deep sleep, use the following command: [ 230.292413] psci: CPU2 killed (polled 4 ms) [ 230.295457] psci: CPU3 killed (polled 0 ms) -This partially indicates that linux has finished it's deep sleep sequence. +This partially indicates that Linux has finished it's Deep Sleep suspend sequence. For further confirmation, one can take a look at the PMIC_LPM_EN pin on the EVM (after programming the PMCTRL_SYS register (0x43018080) to 0x15). Here, if the pin is 3.3V when active and 0V when in deep sleep. @@ -320,7 +320,7 @@ Similar to Deep Sleep, with the major distinction being that the MCU core is kep The benefits of using MCU Only mode: #. Low power consumption: MCU Only mode can save a significant amount of power, especially in battery-powered - devices. This is because The rest of the SoC status is the same as Deep Sleep and DDR is in self-refresh. + devices. This is because the rest of the SoC status is the same as Deep Sleep and DDR is in self-refresh. #. Run background tasks: This mode can be used to run background tasks that do not require the full power of the system. For example, you could use the firmware on the MCU core to run a watchdog timer, a sensor polling loop, or a network communication task. diff --git a/source/linux/Foundational_Components/Power_Management/pm_sw_arch.rst b/source/linux/Foundational_Components/Power_Management/pm_sw_arch.rst index a42694929..08d94497a 100644 --- a/source/linux/Foundational_Components/Power_Management/pm_sw_arch.rst +++ b/source/linux/Foundational_Components/Power_Management/pm_sw_arch.rst @@ -11,12 +11,12 @@ Overview TI AM62 family of devices support multiple Suspend-to-RAM modes, including Deep Sleep and MCU Only as described in :ref:`Low Power Modes` section. The SoC consumes very low power overall yet it is not completely shut off in these modes. -For example, During Deep Sleep, Certain IPs +For example, during Deep Sleep, certain IPs (depending on the power domain to which then belong) will lose context on suspend. S/W should save and restore the context as required across state transitions. DDR is in self- refresh to allow context saving. -This section explains the high-level Software Flow of low power modes in AM62 family of devices. +This section explains the high-level software flow of low power modes in AM62 family of devices. It also introduces the LPM constraints framework that enables seamless management of multiple Suspend-to-RAM modes. @@ -27,26 +27,26 @@ System diagram and components .. Image:: /images/AM62x_Deep_Sleep_Flow.png -Above diagram has software sequence for how deep sleep (ie. Suspend to RAM) works on +Above diagram has software sequence for how Deep Sleep (ie. Suspend to RAM) works on SK-AM62 ( Read more on the Starter Kit `here `__ ). Deep Sleep Entry ================ -#. The user first instructs the System to Suspend. This triggers a suspend - sequence from linux side (which runs on the A53 cluster of the SoC). +#. The user first instructs the system to suspend. This triggers a suspend + sequence from Linux side (which runs on the A53 cluster of the SoC). #. As part of the TI_SCI driver's suspend hook, I/O isolation is invoked which isolates all the pads from their respective pinmuxed controllers. Refer to :ref:`Wakeup sources Documentation` to understand more on this. #. Linux then suspends all the drivers in the order that they are probed. - After ensuring that there were no faults in suspending the drivers, linux + After ensuring that there were no faults in suspending the drivers, Linux then issues core system suspend which ultimately is a PSCI system suspend call. Read more about PSCI `here `__ #. At this point only ATF is running on A53 cores and it does the job of - sending a TISCI Message to the TIFS Core telling it to enter deep sleep + sending a TISCI Message to the TIFS Core telling it to enter Deep Sleep and then it puts A53 into standby. #. The TIFS Core then encrypts and writes the contents of it's own SRAM to DDR. @@ -54,7 +54,7 @@ Deep Sleep Entry #. Further it stops tick timer, disables interrupts that are not needed, and suspends local drivers. After the above steps it sends TISCI To DM for Suspend Finish and enters WFI. -#. The DM (Device Manager) is the final entity in this entire deep sleep sequence. It does the following: +#. The DM (Device Manager) is the final entity in this entire Deep Sleep sequence. It does the following: a. Saves own context to DDR b. Disables Security IP LPSCs, such as LPSC_SAUL. @@ -151,8 +151,8 @@ Specifically, checking of constraints is done at two levels: The code enabling the constraints framework can be found in: -#. TISCI PM Domain driver: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pmdomain/ti/ti_sci_pm_domains.c?h=10.00.07 -#. TISCI driver: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pmdomain/ti/ti_sci_pm_domains.c?h=10.00.07 +#. TISCI PM Domain driver: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pmdomain/ti/ti_sci_pm_domains.c?h=10.01.10 +#. TISCI driver: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/firmware/ti_sci.c?h=10.01.10 Examples of adding constraints from the remote core side are being implemented and will be enabled in future release. @@ -174,11 +174,6 @@ are required. Some devices may disable the wakeup property by default. These can be enabled via the sysfs interface (e.g., :file:`/sys/bus/platform/devices/\*/power/wakeup`) -If a device wants to put a constraint to be not 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=10.00.07#n535 - Resume Latency Constraint ------------------------- @@ -200,6 +195,11 @@ 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=10.01.10#n523 + .. note:: The constraints need to be set before each system suspend as DM firmware clears all @@ -217,7 +217,7 @@ Otherwise, the mode selection is done as described below: Above diagram shows the mode selection if constraints are set on MCU_WAKEUP devgroup devices. As shown, if the constraints are set on WAKEUP Domain devices or Always ON MCU domain devices, -deep sleep mode will be selected. Otherwise, MCU Only mode will be selected. +Deep Sleep mode will be selected. Otherwise, MCU Only mode will be selected. If constraint is put on MAIN devgroup devices, then no low power mode is possible. @@ -225,7 +225,7 @@ If constraint is put on MAIN devgroup devices, then no low power mode is possibl USB devices are an exception in MAIN devgroup as there is extra hardware logic preventing reset of USB devices in Deep Sleep and MCU Only mode. - If constraints are set on USB devices, deep sleep mode will be selected even though it's + If constraints are set on USB devices, Deep Sleep mode will be selected even though it's technically part of MAIN devgroup. .. ifconfig:: CONFIG_part_variant in ('AM62X') diff --git a/source/linux/Foundational_Components/Power_Management/pm_wakeup_sources.rst b/source/linux/Foundational_Components/Power_Management/pm_wakeup_sources.rst index 716dc79fd..cb5a3a081 100644 --- a/source/linux/Foundational_Components/Power_Management/pm_wakeup_sources.rst +++ b/source/linux/Foundational_Components/Power_Management/pm_wakeup_sources.rst @@ -274,10 +274,10 @@ MCU GPIO One of the most common ways to wakeup a system is by using some I/O activity. MCU GPIOs allow us to do this by configuring the MCU GPIO controller as a wakeup source. -In ideal scenarios, The firmware running on MCU core is responsible for configuring MCU GPIO's as a wakeup source. +In ideal scenarios, the firmware running on MCU core is responsible for configuring MCU GPIO's as a wakeup source. However, if the application design doesn't rely too much on the MCU firmware then -linux can be used to configure the MCU GPIOs as a wakeup source. You can refer to the mcu_gpio_key node in -`k3-am62x-sk-lpm-wkup-sources.dtso `__ +Linux can be used to configure the MCU GPIOs as a wakeup source. You can refer to the mcu_gpio_key node in +`k3-am62x-sk-lpm-wkup-sources.dtso `__ and use it as a template to configure the MCU GPIO of your choice as a wakeup capable GPIO. A brief guide to configuring an MCU GPIO as wakeup: @@ -302,7 +302,7 @@ Setup the interrupt parent and interrupt as MCU_GPIO0, .. code-block:: dts interrupt-parent = <&mcu_gpio0>; - interrupts = <16 IRQ_TYPE_EDGE_RISING>; + interrupts = <4 IRQ_TYPE_EDGE_RISING>; Now, under the switch node we add the following: @@ -311,7 +311,7 @@ Now, under the switch node we add the following: switch { label = "MCUGPIO"; linux,code = <143>; - gpios = <&mcu_gpio0 16 GPIO_ACTIVE_LOW>; + gpios = <&mcu_gpio0 4 GPIO_ACTIVE_LOW>; wakeup-source; }; @@ -319,8 +319,8 @@ Now, under the switch node we add the following: .. code-block:: console - root@:~# cat /proc/interrupts | grep "MCUGPIO" - 262: 0 0 0 0 GPIO 16 Edge -davinci_gpio MCUGPIO + root@:~# cat /proc/interrupts | grep "MCUGPIO" + 273: 0 0 0 0 GPIO 4 Edge -davinci_gpio MCUGPIO #. linux,code: Keycode to emit. #. gpios: the gpio required to be used as the gpio-key. @@ -336,12 +336,12 @@ source and send a wakeup interrupt to the Device Manager. To understand the role please refer to :ref:`S/W Architecture of System Suspend` MCU GPIO wakeup can only be tested when -`k3-am62x-sk-lpm-wkup-sources.dtso `__ +`k3-am62x-sk-lpm-wkup-sources.dtso `__ overlay is loaded. Please refer to :ref:`How to enable DT overlays` for more details. Once the system has entered Deep Sleep or MCU Only mode as shown in the -:ref:`LPM section`, wakeup from MCU GPIO0_16 can be triggered -by grounding Pin 11 on J8 MCU Header. +:ref:`LPM section`, wakeup from MCU_SPI0_D1 can be triggered +by grounding Pin 4 on J8 MCU Header. ******************** Main I/O Daisy Chain @@ -352,16 +352,16 @@ Main UART, GPIO, I2C, etc. The question then arises how to wakeup the SoC from p to these controllers (for example main UART)? Here's where the role of I/O Daisy Chaining comes in. At the hardware level, all the pads in an SoC have to be pinmuxed to dedicated controllers like UART or GPIO. -For example, If a key press on Main UART (which is used for linux console logs) -were to wakeup the system from deep sleep then simply configuring the Main UART controller as a +For example, If a key press on Main UART (which is used for Linux console logs) +were to wakeup the system from Deep Sleep then simply configuring the Main UART controller as a wakeup source wouldn't suffice. This is because the UART controller is powered off and wouldn't be able to register any key press as such. However, at the "pad" level we are still connected, and the pads have a specific way to be configured as wakeup sources. For detailed information and sequence please refer to I/O Power Management and Daisy Chaining section in the TRM. To briefly explain, -Setting the 29th Bit in the desired padconfig register, allows the pad to act as a wakeup source by -triggering a wake irq to the DM R5 in deep sleep states. +setting the 29th bit in the desired padconfig register, allows the pad to act as a wakeup source by +triggering a wake irq to the DM R5 in Deep Sleep states. .. note:: |__PART_FAMILY_DEVICE_NAMES__| supports the ability to wakeup using pad based wake event ONLY in Deep Sleep or MCU Only Mode. @@ -371,7 +371,7 @@ triggering a wake irq to the DM R5 in deep sleep states. To demonstrate I/O daisy chain wakeup as part of |__PART_FAMILY_DEVICE_NAMES__| offering, two reference examples are provided: -#. main_uart0 is used where a key press on the linux console can wakeup the system. +#. main_uart0 is used where a key press on the Linux console can wakeup the system. #. main_gpio is used where activity on configured GPIO pin can wakeup the system. @@ -379,7 +379,7 @@ Main UART ========= The way to configure UART as an I/O daisy chain wakeup, refer to the -main_uart0 node in `k3-am62x-sk-common.dtsi `_ +main_uart0 node in `k3-am62x-sk-common.dtsi `_ .. code-block:: dts @@ -388,7 +388,7 @@ main_uart0 node in `k3-am62x-sk-common.dtsi `__ +gpio_key node in `k3-am62x-sk-lpm-wkup-sources.dtso `__ Main GPIO wakeup can only be tested when -`k3-am62x-sk-lpm-wkup-sources.dtso `__ +`k3-am62x-sk-lpm-wkup-sources.dtso `__ overlay is loaded. Please refer to :ref:`How to enable DT overlays` for more details. To use main_gpio as a wakeup source, ensure gpio is a wake-irq in /proc/interrupts: @@ -469,7 +469,7 @@ Sleep and MCU Only modes. In order to use WKUP UART as a wakeup source, it needs to be configured in a generic way using the ti-sysc interconnect target module driver. The reference configuration can be found under target-module in -`k3-am62-wakeup.dtsi `__ +`k3-am62-wakeup.dtsi `__ WKUP UART is generally available on the third serial port (/dev/ttyUSB2) and by default it only shows output from DM R5. @@ -516,7 +516,7 @@ Plug in a USB device to one of the port on the board and check that the device i Follow the steps described in :ref:`LPM section` to put the system in Low Power Mode via Deep Sleep or MCU only method. Once the system is suspended, disconnect the USB device from the board and this should wakeup the system. -And device would not show up in list of USB enumerated devices. This can be verified by executing +The device will not show up in list of USB enumerated devices. This can be verified by executing .. code-block:: console @@ -541,13 +541,13 @@ It should show "suspended", indicating that the keyboard has entered into suspen .. code-block:: console - # cat /sys/bus/usb/devices/1-1/power/runtime_status + # cat /sys/bus/usb/devices/1-1/power/runtime_status Now press a key on the keyboard and check the runtime power status and it would come back to "active". .. code-block:: console - # cat /sys/bus/usb/devices/1-1/power/runtime_status + # cat /sys/bus/usb/devices/1-1/power/runtime_status Follow the steps described in :ref:`LPM section` to put the system in Low Power Mode via Deep Sleep or MCU only method. @@ -556,7 +556,7 @@ And USB keyboard would still be present in the system's list of USB enumerated d .. code-block:: console - # lsusb -t + # lsusb -t Device Mode Wakeup Events ========================= @@ -568,17 +568,17 @@ Load a USB gadget driver such as g_zero .. code-block:: console - # modprobe g_zero + # modprobe g_zero Follow the steps described in :ref:`LPM section` to put the system in Low Power Mode via Deep Sleep or MCU only method. Once the system has entered the suspend state, plug a cable from a different Host system to the board's USB DRP port. -This should wakeup the system and gadget would be enumerated on the Host. Enumeration of the gadget on the Host system can be verified by executing the +This should wakeup the system and gadget will be enumerated on the Host. Enumeration of the gadget on the Host system can be verified by executing the below command on the Host system .. code-block:: console - HOST:~$ > lsusb -t + HOST:~$ lsusb -t ********************