stm32h7/clk: work in progress

[tinnedkarma]

Summary

Some time ago I've learned about the nuttx's clk framework. My work being mostly on stm32h7 mcu's I've some nucleo boards to spare.

I've worked in my spare time on moving the reset and clock configuration to this clk framework.

It is starting to get some shape although I'm kinda worried that is not really the "embedded" way of doing things.

It uses more (by 100% some can say) ram usage to store the clk structs, the clk file part of the procfs needs 10kb ram just to generate the output buffer.

That being said, there are lot's of reasons to use this approach, at least of this beefy stm32h7 mcu family.
It simplifies a lot the clock interaction

I'll keep this in draft to see if there is any use of these changes. Anyone is free, or encouraged, to have a look over this changes, although lots of things still missing, the stm32_rcc.c file is close to something final.

Impact

Should be considered breaking change.
Lot's of things will differ.

• The previous clock configuration was done in the board.h while the initialization was done in some stm32_clkconfig function.
• usart driver will be reworked to adapt the new clk config.
• timers?? not yet there but most probably there should be changes as well.
• small changes thru ought the stm3h7 family will be touched

Testing

This is still work in progress, so, not many tests, other than the development lifecycle

[xiaoxiang781216]

it's better to move clock framework self change to new pr

[tinnedkarma]

Hello @xiaoxiang781216, thank you for your input.
I do not intend to merge it as is. At the moment I'm not sure it's worth merging at all.
I just opened this PR to "test the waters", see how much attention the nuttx clk framework will draw, to be honest.

There are some important thing I still need to figure out before I start splitting into more PRs, hopefully I find some time to document them in the PR description as well.

I am struggling with the initialization sequence, the clk framework needs memory allocation, so the clk init is delayed to nx_start, but a lot of things happens around the stm32 rcc before nx_start. As with my current progress I am sure I'll find a lot of other things that might be tricky to solve, hence the reason of opening this PR really early in the development. Maybe there is some progress done by someone else that might have some useful hints.

That said, I'll track my progress in the PR description. Maybe Issue would be a better approach, but it hides the code, which I kinda want to be upfront.