The sequence diagrams in Figure 3-5 through Figure 3-7 identify the PRCM module hardware-controlled enabling and gating of the functional and interface clocks to the module. They show the changes in the state of the module based on the changes to the clock domain state and module mode settings.
Figure 3-5 shows the behavior of a slave module receiving the interface and functional clocks and having two configurable module modes: disabled and enabled.
Initially, the clock domain, which includes the slave module, is inactive. The module is in FULL IDLE state and its functional and interface clocks are gated.
- The clock domain wakes up and changes its state to ACTIVE. Because the MODULEMODE control is still disabled, this event has no effect on the state of the module. The functional and interface clocks can still be restarted automatically, based on the requirements of other modules sharing these clocks.
- Software changes the module mode to ENABLED. The clocks to the module are automatically restarted. The PRCM module then deasserts a hardware IDLE request signal to the module. The module sends an IDLE request acknowledge to the PRCM module. The module is now effectively awake. The module IDLE state is functional.
- The clock domain switches to IDLE_TRANSITION state. In turn, the PRCM module requests the module to go into IDLE state by asserting the IDLE request signal. When acknowledged, the clock to the module can be gated, depending on other modules sharing the same clock. The functional clock of the module remains enabled because the module is in enabled mode.
- The clock domain does not have all conditions to complete the sleep transition and wakes up again. In turn, the interface clock to the module is automatically restarted, and then the module is put out of IDLE state.
- Software disables the module. The PRCM module requests the module to go to IDLE state by asserting the IDLE request signal. When acknowledged, the clock to the module can be gated, depending on other modules sharing the same clock.
- The clock domain switches to IDLE_TRANSITION state. When the sleep transition conditions of the clock domain are satisfied, the clocks (functional and interface) are gated. The clock domain then switches to INACTIVE state. This has no effect on the module, which is already in FULL IDLE state.
Figure 3-6 shows the behavior of the same slave module, receiving the interface and functional clocks, when the module mode is changed while the clock domain state is IDLE_TRANSITION.
Initially, the clock domain, which includes the slave module, is inactive. The module is in FULL IDLE state and its functional and interface clocks are gated.
- The clock domain wakes up and changes its state to ACTIVE. Because the MODULEMODE control is disabled, this event has no effect on the state of the module. The functional and interface clocks can still be restarted automatically, based on the requirements of other modules sharing these clocks.
- The clock domain goes into the IDLE_TRANSITION state. Because the module mode control is disabled, this event has no effect on the module state.
- Software changes the module mode to ENABLED. The clocks to the module are restarted automatically and then the module is put out of IDLE state. As soon as acknowledged, the module is requested to go back to IDLE state with gating of the interface clock only (that is, the INTERFACE IDLE state). The interface clock to the module can be gated, depending on other modules sharing the same clocks.
- Software disables the module. The interface clock to the module is restarted automatically. The PRCM module requests the module to go out of IDLE state by asserting the IDLE request signal. As IDLE request acknowledge is de-asseted, PRCM set back the module to IDLE state. When acknowledged, the interface and the functional clocks to the module can be gated, depending on other modules sharing the same clock.
- When the clock domain sleep transition conditions are satisfied and the functional and interface clocks are gated, the clock domain switches to INACTIVE state. This has no effect on the module, which is already in FULL IDLE state.
Figure 3-7 shows the behavior of a slave module receiving only interface clock and supporting the configurable auto module mode.
Initially, the clock domain, which includes the slave module, is inactive. The module is in FULL IDLE state and its interface clock is gated.
- The clock domain wakes up and changes its state to ACTIVE. In turn, the interface clock to the module is automatically restarted. The PRCM module then deasserts a hardware IDLE request signal to the module. The module sends an IDLE request acknowledge to the PRCM module. The module is now effectively awake; that is, the module IDLE state is functional.
- The clock domain switches to IDLE_TRANSITION state. The PRCM module requests the module to go to IDLE state by asserting the IDLE request signal. When acknowledged, the interface clock to the module can be gated, depending on other modules sharing the same clock.
- The clock domain does not have all conditions to complete the sleep transition and wakes up again. In turn, the interface clock to the module is automatically restarted, and then the module goes out of IDLE state.
- This step is the same as Step 2.
- The clock domain has all conditions to complete the sleep transition. The module is in IDLE state and its clock is gated.