@@ -493,19 +493,22 @@ WKUP GPIO
493493Main 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
713716Configuring 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