RIOT-OS / RIOT

RIOT - The friendly OS for IoT
https://riot-os.org
GNU Lesser General Public License v2.1
4.9k stars 1.98k forks source link

[Tracking] Refactor STM32 clock configuration and initialization #14975

Open aabadie opened 4 years ago

aabadie commented 4 years ago

Description

This issue is a tracking for the refactoring of the clock configuration and initialization on STM32 cpus.

Current situation

In the current situation, the whole clock configuration is done at board level although a lot parameters are CPU level specific.

Expected situation

In general, the expected situation should provide a way to easily configure the clocks of a CPU: by easily, we mean no need to know the bitfields in advance and the parameters can be overridden via CFLAGS (command line or Makefile), a custom config header and Kconfig.

Doing this will allow a simpler and centralized clock configuration: less code duplication and more flexibility. The CLOCK_CORECLOCK and all sub-clock values should be computed at build time with good defaults.

For the 48MHz source clocks, they should only be enabled if required by the application. For the moment, this is only the case when the USB peripheral feature is required. On F4 and F7 families, several 48MHz clock source are possible (from PLLQ, PLLI2S or PLLSAI). The idea is to fall back to PLLI2S/PLLSAI when PLLQ cannot output 48MHz and to fail at build time if no 48MHz clock is available. For 100MHz and 180MHz capable CPUs (typically on F4), we should by default configure them to reach their maximum clock frequency by default and adapt it when 48MHz is needed (and then their core clock would decrease to 96/168MHz).

After that rework, the cpu/dist/clk_conf tool will become obsolete and will not longer be needed.

Work to be done

Achieving what's described above is a lot of work and cannot be done in a single PR. To prepare the work needed for Kconfig, all configuration constants will be prefixed by CONFIG_.

Here are the steps needed (not necessary in order, for some there are already opened PRs and some PRs were already merged):

This is is not exhaustive and is subject to change over time.

MrKevinWeiss commented 7 months ago

Should we keep this around? All open issues are there, the Kconfig model should replace the headers...