MCXA: Automatic Clock Gating

[jamesmunns]

At some point, we may want to reduce power on the MCX-A family as much as possible.

The current strategy is largely:

1. Focus on three main power states (rough summary):

• "Active/Running": CPU running and all clocks active
• "Active/Sleeping": e.g. WFE sleep, CPU (and flash) gated, all peripheral clocks still running
• "LowPower/DeepSleep": CPU and flash gated, some peripheral clocks stopped

1. Aim for "LowPower" state to be the main way to reduce power usage
2. Setup Active and LowPower clocks at init time, enforce that peripherals have "reasonable" clocks for what they are being used for
3. IF a peripheral needs to be used in low power mode:

• It must be clocked from a source that is ALWAYS active in LowPower mode, OR
• It must be dropped + recreated BEFORE going to LowPower, and optionally dropped + recreated AFTER returning to Active mode, if we require "better perf" or something in Active Mode, but some remaining functionality in LowPower, OR
• It must support some kind of [async] fn reclock(&mut self, src: Source) -> Result<(), ClockError> interface which can be used to reconfigure the peripheral at runtime without invalidating the existing peripheral, though this MAY require "flushing" active DMA transactions, etc. before reclocking.

However, we have a few peripherals that are "always on" because they are auto-managed by the HAL. As of Jan '26, this includes:

• OsTimer: Used for embassy-time-driver impl
• Dma: Used for all DMA channels across peripherals
• PORT(0-4), GPIO(0-4) peripherals

At least in Active modes, NOT disabling these peripherals has a somewhat observable power usage impact, experimentally somewhere in the magnitude of 100uA - 1000uA range, though this needs to be better quantified, and probably depends on the source clocks used.

We probably want to:

1. Get quantitive numbers for these peripherals, maybe with different source clocks
2. Determine if this impact is repeated in DeepSleep mode

If we DO care about this, there are probably two main strategies to consider/investigate:

• The MRCC has an "automatic clock gating" feature, which can either automatically gate peripherals when idle, and/or prevent the system from entering DeepSleep modes UNTIL the peripheral is idle. I'm not clear if this achieves the power goals we want, or if it fits with our general plans.
• We could address this in software, e.g. with some basic reference counting, e.g. starting clocks for a GPIO/PORT when we go 0->1 active pins, or stopping clocks for a GPIO/PORT when we go 1->0; or the same for stopping the eDMA peripheral when no transfers are active, and restarting on demand.

CC @felipebalbi