Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Dynamic Clocking

Most configurations are created with fixed clock configurations. One strategy for power management is to use variable, dynamic clocking where the CPU clock frequency is lowered during periods of inactivity.

Clock Update Function

Variable clocking is not difficult to achieve but most ports are created with fixed clock configuration using settings defined in the board.h header file. For example, Kinetis has:

...

NOTE: Additional complexities may be associated with changing the clocking other than just controlling dividers, PLLs, and clock sources. For example, FLASH wait states. When increasing the clocking, the FLASH wait states must be increased BEFORE re-configuring the faster clocking. But when reducing the clocking, FLASH wait states cannot be reduced until AFTER re-configuring the slower clocking.

Power Management (PM) Subsystem

I would expect that the logic that performs clocking adjustments would utilize the NuttX Power Management (PM) subsystem. That subsystem basically implements a random walk. It collects and monitors system utilization information from devices drivers. This utilization information comes from critical device drivers via calls to:

...

When there is no further activity, the activity counter will decrease and when it crosses a threshold, it will initiate a change to a lower power usage state. There are many actions that systems may take when the reduced power state is entered. They may, for example, dim that backlight on a display or enable MCU-specific reduced power consumptions modes. And for the purposes of this discussion, they may also reduce the clocking to the CPU.

Further Information: Power Management (PM)

Handling Driver Dependencies

The first part of the problem was modifying the clock configuration logic to support variable configurations. The second part of the problem is that now all of the devices that depend on clocking such as the timer, the system timer, all MCU-specific timers, UARTS, and perhaps other device need to be notified of the change in clock frequency.

...

Full functionality is not normally expected in low power consumption states. So the most typical behavior for drivers in response to reduced power consumption state changes is simply to shut themselves down (turn off the peripheral, disable clocking to the peripheral, and other actions as appropriate). The above discussion only applies to peripherals that you expect to continue normal operation in the reduced power state: You may, as an example, want to keep timing accuracy throughout the low power state or you may want to preserve serial debug output in the reduced power state.

Driver PM Callback Functions

The NuttX PM subsystem provides the glue that integrates both parts of the clock management problem. The first part is managed by PM activity monitor and PM state changes. The PM subsystem integrates the second part of the problem using PM driver callback functions: The timing sensitive device drivers can be notified of the change in clocking using the driver callbacks that are a port of NuttX Power Management (PM) functionality.

...

Code Block
  /* Power management callback function prototypes */
Code Block
  #ifdef CONFIG_PM
  static void xyz_pm_notify(struct pm_callback_s *cb, int domain,
                            enum pm_state_e pmstate);
  static int xyz_pm_prepare(struct pm_callback_s *cb, int domain,
                            enum pm_state_e pmstate);
  #endif

...

Code Block
  /* Power management callback function vtable */
Code Block
  #ifdef CONFIG_PM
  static struct pm_callback_s g_xyz_pmcb =
  {
    .notify  = xyz_pm_notify,
    .prepare = xyz_pm_prepare,
  };
  #endif

...

Code Block
  /* Register to receive power management callbacks */
Code Block
  int ret = pm_register(&g_xyz_pmcb);

Dynamic Clock Frequency Utility Functions

Most timers and drivers in the system us the constant frequency values defined in the board.h header file. In order to have variable time, the drivers must be able to determine the current clock frequencies dynamically, not via a fixed, constant definitions. This means that there must be clock functions that derive various clock firequencies in the clock distribution knowing only the input frequency (i.e., crystal frequency of internal clock selection).

...