fjpanag commented on pull request #2177: URL: https://github.com/apache/incubator-nuttx/pull/2177#issuecomment-724833818
Now I am really confused. We are discussing about multiple (and independent?) issues, I think... Firstly, this PR only limits the _maximum_ wait cycles that may be configured in RCC. The maximum system frequency is known, and if it does not need so many wait cycles, they are reduced. How is this affecting the sequence things are following, or waking-up from idle? Secondly, just as the system frequency affect the wait cycles, so does system voltage (in some cases). So, in a different PR, we shall further reduce, or increase the maximum wait cycles based on Vin? Thirdly, there is `stm32_clockenable()`, which is called when exiting IDLE. And which implies that the clock was disabled before (and that's why it is has to be enabled now). And of course, by exiting a sleep state I would only expect the clock to increase, and never decrease. So there is only one procedure to follow in `stm32_stdclockconfig()` I guess... Fourthly, based on the assumption: > The point is that these functions are invoked also when returning from sleep, where you may be using a clock with a lower/higher frequency than the one you are about to re-activate I am afraid that the code is already broken. As `stm32_clockenable()` always follows the sequence for increasing the clock speed, and as the sequence for core over-drive makes assumptions for the current clock used. Which is also work for another PR I think. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
