Skip to content

Commit 6141849

Browse files
committed
style(pm_wakeup_sources): Reword Main I/O Daisy Chain section
Reword the Main I/O Daisy Chain section to remove passive language. Signed-off-by: Kendall Willis <[email protected]>
1 parent be5dca5 commit 6141849

File tree

1 file changed

+33
-28
lines changed

1 file changed

+33
-28
lines changed

source/linux/Foundational_Components/Power_Management/pm_wakeup_sources.rst

Lines changed: 33 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -493,19 +493,22 @@ WKUP GPIO
493493
Main I/O Daisy Chain
494494
********************
495495

496-
The main domain is powered-off when the SoC enters low power mode. This includes controllers like
497-
Main UART, GPIO, I2C, etc. The question then arises how to wakeup the SoC from peripherals connected
498-
to these controllers (for example main UART)? Here's where the role of I/O Daisy Chaining comes in.
499-
At the hardware level, all the pads in an SoC have to be pinmuxed to dedicated controllers like UART or GPIO.
500-
501-
For example, if a key press on Main UART (which is used for Linux console logs)
502-
were to wakeup the system from Deep Sleep then simply configuring the Main UART controller as a
503-
wakeup source wouldn't suffice. This is because the UART controller is powered off and wouldn't be able to
504-
register any key press as such. However, at the "pad" level we are still connected, and the pads have
505-
a specific way to be configured as wakeup sources.
506-
507-
For detailed information and sequence please refer to
508-
I/O Power Management and Daisy Chaining section in the TRM.
496+
When the SoC enters a low power mode, the main domain is powered-off. The main
497+
domain includes controllers like Main UART, GPIO, I2C, etc. I/O daisy chaining
498+
is used in order to wakeup the SoC from peripherals that are connected to
499+
powered-off controllers. At the hardware level, all the pads in an SoC are
500+
pinmuxed to dedicated controllers, such as UART or GPIO.
501+
502+
For example, to wakeup the system from Deep Sleep via a key press on Main UART
503+
(used for Linux console logs), then simply configuring the Main UART
504+
controller as a wakeup source wouldn't work. This is because the UART
505+
controller is powered off and wouldn't be able to register any key press as
506+
a wakeup event. However, the UART is still connected at the "pad" level and the
507+
pads can be configured as wakeup sources by setting a specific bit in the pad
508+
register.
509+
510+
For detailed information and sequence please refer to I/O Power Management and
511+
Daisy Chaining section in the TRM.
509512

510513
.. ifconfig:: CONFIG_part_variant in ('AM62X', 'AM62AX', 'AM62PX')
511514

@@ -711,9 +714,9 @@ Main GPIO
711714
=========
712715

713716
Configuring Main GPIO as an I/O daisy chain wakeup source requires a
714-
combination of gpio-keys with chained IRQ in the pinctrl driver. To briefly
715-
explain, setting the 29th bit in the desired padconfig register, allows the
716-
pad to act as a wakeup source by triggering a wake IRQ in Deep Sleep states.
717+
combination of gpio-keys with a chained IRQ in the pinctrl driver. Setting the
718+
29th bit in the desired padconfig register, allows the pad to act as a wakeup
719+
source by triggering a wake IRQ in Deep Sleep states.
717720

718721
.. ifconfig:: CONFIG_part_variant in ('AM62X', 'AM62AX', 'AM62PX')
719722

@@ -737,17 +740,18 @@ pad to act as a wakeup source by triggering a wake IRQ in Deep Sleep states.
737740
};
738741
};
739742
740-
Here, we chain the IRQ to the pinctrl driver using the second
741-
interrupts-extended entry. The wake IRQ framework in Linux works in such a
742-
way that the second entry gets marked as a wakeup source, and then the
743-
pinctrl driver is informed that the pad 0x1a0 in this case is to be
744-
configured as a wakeup pad when system enters Deep Sleep.
743+
The IRQ is chained to the pinctrl driver using the second
744+
interrupts-extended entry. The wake IRQ framework in Linux works so that the
745+
second entry gets marked as a wakeup source, and then the pinctrl driver is
746+
informed that the pad, 0x1a0 in this case, is to be configured as a wakeup
747+
pad when system enters Deep Sleep.
745748

746749
Main GPIO wakeup can only be tested when
747750
`k3-am62x-sk-lpm-wkup-sources.dtso <https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62x-sk-lpm-wkup-sources.dtso?h=11.01.05>`__
748751
overlay is loaded. Please refer to :ref:`How to enable DT overlays<howto_dt_overlays>` for more details.
749752

750-
To use main_gpio as a wakeup source, ensure gpio is a wake-irq in /proc/interrupts:
753+
To use main_gpio as a wakeup source, ensure gpio is a wake-irq in
754+
/proc/interrupts:
751755

752756
.. code-block:: console
753757
@@ -780,13 +784,14 @@ pad to act as a wakeup source by triggering a wake IRQ in Deep Sleep states.
780784
};
781785
};
782786
783-
Here, we chain the IRQ to the pinctrl driver using the second
784-
interrupts-extended entry. The wake IRQ framework in Linux works in such a
785-
way that the second entry gets marked as a wakeup source, and then the
786-
pinctrl driver is informed that the pad 0x1ac in this case is to be
787-
configured as a wakeup pad when system enters Deep Sleep.
787+
The IRQ is chained to the pinctrl driver using the second
788+
interrupts-extended entry. The wake IRQ framework in Linux works so that the
789+
second entry gets marked as a wakeup source, and then the pinctrl driver is
790+
informed that the pad, 0x1ac in this case, is to be configured as a wakeup
791+
pad when system enters Deep Sleep.
788792

789-
To use main_gpio as a wakeup source, ensure gpio is a wake-irq in /proc/interrupts:
793+
To use main_gpio as a wakeup source, ensure gpio is a wake-irq in
794+
/proc/interrupts:
790795

791796
.. code-block:: console
792797

0 commit comments

Comments
 (0)