This patch adds the STM32L4x5 RCC (Reset and Clock Control) device and is part
of a series implementing the STM32L4x5 with a few peripherals.

Due to the high number of lines, I tried to split the patch into several independent commits.
Each commit compiles on its own but I had to add temporary workarounds in intermediary commits to allow them to compile even if some functions are not used. However, they have been removed once the functions were used. Tell me if this is ok or if I should remove them.

Also, the tests are not very exhaustive for the moment. I have not found a way to test the clocks' frequency from the qtests, which limits severely the exhaustiveness of the tests.

Thanks to Philippe Mathieu-Daudé and Luc Michel for guiding me toward the hw/misc/bcm2835_cprman.c implementation and answering my questions about clock emulation in qemu !

Changes from v1 to v2:
- Removed a mention in the tests
- Added an early return to prevent a clang compilation error in rcc_update_pllsaixcfgr()

Changes from v2 to v3:
- Changed the timeout method used in the tests
- Added a real value for ICSR register
- Replaced some TODOs with correct error handling
- Added a commit that implements correct write protections for the CR register

Changes from v3 to v4:
- Rebased on top of current master
- Implemented reset functions for the multiplexers and the PLLs
- Added explanatory messages to every commit
- Addded logs for unimplemented registers
- Completed the VMState for the multiplexers and the PLLs

Changes from v4 to v5:
- Abort when trying to set an out-of-bound pll vco multiplier

Arnaud Minier (8):
  Implement STM32L4x5_RCC skeleton
  Add an internal clock multiplexer object
  Add an internal PLL Clock object
  Add initialization information for PLLs and clock multiplexers
  RCC: Handle Register Updates
  Add write protections to CR register
  STM32L4x5: Use the RCC Sysclk
  Add tests for the STM32L4x5_RCC

 MAINTAINERS                               |    5 +-
 docs/system/arm/b-l475e-iot01a.rst        |    2 +-
 hw/arm/Kconfig                            |    1 +
 hw/arm/b-l475e-iot01a.c                   |   10 +-
 hw/arm/stm32l4x5_soc.c                    |   45 +-
 hw/misc/Kconfig                           |    3 +
 hw/misc/meson.build                       |    1 +
 hw/misc/stm32l4x5_rcc.c                   | 1416 +++++++++++++++++++++
 hw/misc/trace-events                      |   14 +
 include/hw/arm/stm32l4x5_soc.h            |    5 +-
 include/hw/misc/stm32l4x5_rcc.h           |  239 ++++
 include/hw/misc/stm32l4x5_rcc_internals.h | 1042 +++++++++++++++
 tests/qtest/meson.build                   |    3 +-
 tests/qtest/stm32l4x5_rcc-test.c          |  207 +++
 14 files changed, 2948 insertions(+), 45 deletions(-)
 create mode 100644 hw/misc/stm32l4x5_rcc.c
 create mode 100644 include/hw/misc/stm32l4x5_rcc.h
 create mode 100644 include/hw/misc/stm32l4x5_rcc_internals.h
 create mode 100644 tests/qtest/stm32l4x5_rcc-test.c

-- 
2.34.1

On Mon, 19 Feb 2024 at 20:09, Arnaud Minier
<arnaud.minier@telecom-paris.fr> wrote:
>
> This patch adds the STM32L4x5 RCC (Reset and Clock Control) device and is part
> of a series implementing the STM32L4x5 with a few peripherals.
>
> Due to the high number of lines, I tried to split the patch into several independent commits.
> Each commit compiles on its own but I had to add temporary workarounds in intermediary commits to allow them to compile even if some functions are not used. However, they have been removed once the functions were used. Tell me if this is ok or if I should remove them.
>
> Also, the tests are not very exhaustive for the moment. I have not found a way to test the clocks' frequency from the qtests, which limits severely the exhaustiveness of the tests.

Where you have a device connected to an output clock that produces some
useful behaviour dependent on the clock frequency it is given (eg if
it is a timer device that has a timer count register you can read or
which will fire an interrupt or set a status bit after a certain time),
you can do something like:
 * configure the RCC for a given frequency
 * advance the simulation time with clock_step()
 * check that the device connected to that clock has changed
   in the way you expect it to

But you're right that we don't have any handy way to look specifically
at the outputs of a clock-controller to check the frequency they're set to.
It would probably be possible to add one, but we'd need to enhance
the qtest protocol to add a "for the Clock specified by this QOM path,
return the period it's currently set to".

-- PMM