drivers: clock_control: stm32h7: disabling PLL when executing in memory map mode leads to a stall

[GeorgeCGV]

Using XIP (memory map mode) introduced in #68597, #72339 with the
(Q|O)SPI with a clock source set to PLL1 leads to an application stall/freeze.

It happens right after

zephyr/drivers/clock_control/clock_stm32_ll_h7.c

Line 769 in 67a31ef

LL_RCC_PLL1_Disable();

The PLL1 disabling before configuration was introduced back in #57337.
The disabling makes sense. However, for some reason PLL2 and PLL3
were left out.

To allow the application to boot successfully we must not disable the PLL(1|2)
when it is used by (Q|O)SPI peripheral.

The issue was mentioned in #62349 (comment).

To Reproduce
Steps to reproduce would be to build and run an application that uses (Q}O)SPI
in memory map mode when it is clocked from PLL1.

Expected behavior
Ideally, the application boots in memory map mode with a reconfigured (Q|O)SPI clock.

That would require to extend existing drivers to support clock reconfiguration and to
switch (Q|O)SPI clock selector to HCLK before that.

The peripheral prescaler depends on the bus clock and can be changed only when
the memory map mode is aborted. Consider that the read opcode might
come from SFDP. Overall, it will require some refactoring in the driver.
Apart from that, the driver code might need to be in RAM.

A quick solution would be not to disable PLL which is used as the the clock source
for the (Q|O)SPI when executing the application in memory map mode.

Impact
Showstopper when an application runs in memory map mode for (Q|O)SPI clocked from PLL1.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.