-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STM32: Enhance PWM driver #5469
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for user selectable prescaler.
Code concatenation should be reworked to take F0 into account.
ee5b12f
to
f95e5fd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach in the last 3 patches looks sane -- seems like this needs a rebase though
035de66
to
f1f8942
Compare
Hi @mbolivar and @erwango, thanks for the review! @erwango : The current driver does not seem to have F0-specific bits. Do you want me to port this driver to F0? I do not have such a board around to test. I can add the necessary part if you tell me what to look for. Is the clock name different on F0 ? @mbolivar : Rebase done. |
Codecov Report
@@ Coverage Diff @@
## master #5469 +/- ##
=======================================
Coverage 55.03% 55.03%
=======================================
Files 483 483
Lines 53965 53965
Branches 10489 10489
=======================================
Hits 29697 29697
Misses 19992 19992
Partials 4276 4276 Continue to review full report at Codecov.
|
@vaussard : You don't need to develop PWM for F0, but considering this is an exception to the rule you used to factorize code. I'd like it to be taken into account from the start. |
Ok @erwango, so I will add a new patch to support F0 and see if nucleo_f091rc and alike compile. I won't be able to test however. Would it be acceptable for you? |
@vaussard : Yes, of course. You can mention in your commit message that minimum is done on F0 to compile but feature should not be considered as available on F0 until futher dev/test. |
Hi @erwango, I addressed your comments (and even more):
|
6b38c09
to
ff730a4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for docs
6371b3f
to
9393419
Compare
I just rebased due to forced changes in the arm branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you move commit 8caa2cf3ffbe7c0229b3baed1fc0fd076281fc5f before commit 1aedb4e54e669df869e8cc0c31485b6542c4deb8 and squash commits 1aedb4e54e669df869e8cc0c31485b6542c4deb8 with bc0db4de0ea839431dd713a266dc2cda7f2a2cd0 and aad0b8dc0ca2d8f73f6aedb89d285cd92517ceb7 with 8caa2cf3ffbe7c0229b3baed1fc0fd076281fc5f?
Hi @ydamigos. These patches were done later and the only reason that I did not squashed 1aedb4e and bc0db4d was to avoid facing a huge amount of conflicts. But I will do that if you insist :-) |
@vaussard My comments are not blocking. IMO, the proposed changes make the PR easier to check.
In that case, I would move both 8caa2cf and bde95a9 before 1aedb4e. |
@ydamigos Moving 8caa2cf and bde95a9 before 1aedb4e will force me to rewrite almost all the patches due to the conflicts. IMHO such ordering would be acceptable:
It boils down to enhancing-before-extending or extending-before-enhancing. I am OK with both but one is more work to rewrite. |
@vaussard Sounds good. |
Not sure now what docs were updated that I reviewed before the rebase... the API material will update automatically if the header files changed (http://docs.zephyrproject.org/api/io_interfaces.html#pwm-interface). Might be worth looking through the PWM samples docs (http://docs.zephyrproject.org/samples/basic/basic.html) to see if they're still OK or if a new sample would be useful. |
9393419
to
c62478e
Compare
@vaussard Nice job! Hopefully this PR can be merged as soon as possible! |
8033989
to
e638508
Compare
@galak : Can you check then? |
The registration of each PWM differs only by a few details. These differences can be factorized in order to create a generic registration macro. This has several advantages: - Less code - Easier to add new PWM Signed-off-by: Florian Vaussard <[email protected]>
All the PWM between 1 and 20 can be found on the STM32 depending on the serie and the specific model. Add all the missing PWMs up to PWM20 to plan for the future needs. Tested on STM32L496 with available PWMs. Signed-off-by: Florian Vaussard <[email protected]>
The prescalers are currently hardcoded and are not user-selectable. As a result, the frequency of the timer can be inadequate to the task. For instance, the frequency of the 16-bit timers (prescaler 10000) is usually too low to correctly generate of PWM of a few kilohertz. Hardcoded prescalers are replaced by Kconfigs so the user can choose at compile time. The default value of each Kconfig matches the hardcoded prescaler, so the change will be transparent. Signed-off-by: Florian Vaussard <[email protected]>
Not all PWM clocks belong to the GRP1, for example TIM1 on STM32F0. Add the group information to the macro to enable supporting these PWMs in the future. Signed-off-by: Florian Vaussard <[email protected]>
PWM1 / PWM15 / PWM16 and PWM17 on STM32F0 do not use the same clocks compared to the other series. Add the STM32F0-specific clocks where needed. Signed-off-by: Florian Vaussard <[email protected]>
CONFIG_CLOCK_STM32_APB2_PRESCALER does not exist for STM32F0 as it was removed from the RCC Kconfig by commit d067820 ("drivers: clock_control: provide support for stm32f0."). This will break the PWM driver if compiled for STM32F0. Conditionally disable usage of this symbol for STM32F0 as all PWMs are on APB1 for this family. Signed-off-by: Florian Vaussard <[email protected]>
The nucleo_f334r8 uses STM32F3_PINMUX_FUNC_PA8_PWM1_CH1 inside its pinmux but it is not defined anywhere. Add the definition into the pinmux file to fix the build of nucleo_f334r8 when enabling CONFIG_PWM. Signed-off-by: Florian Vaussard <[email protected]>
In some cases, node label could be generated with "/" character in name string, which prevents compilation Signed-off-by: Erwan Gouriou <[email protected]> Signed-off-by: Florian Vaussard <[email protected]>
Add new device tree bindings for STM32 Timer and PWM IPs. Signed-off-by: Florian Vaussard <[email protected]>
Add available PWM nodes to the existing STM32F0 device trees. Signed-off-by: Florian Vaussard <[email protected]>
Add available PWM nodes to the existing STM32F1 device trees. Signed-off-by: Florian Vaussard <[email protected]>
Add available PWM nodes to the existing STM32F3 device trees. Signed-off-by: Florian Vaussard <[email protected]>
Add available PWM nodes to the existing STM32F4 device trees. Signed-off-by: Florian Vaussard <[email protected]>
Add available PWM nodes to the existing STM32L4 device trees. Signed-off-by: Florian Vaussard <[email protected]>
Enable the PWM nodes for the board already using them in their pinmux. Signed-off-by: Florian Vaussard <[email protected]>
Add fixup info for PWM nodes on STM32F0/F1/F3/F4/L4 and remove the conflicting Kconfig symbols to fully switch STM32 PWM to device tree. Signed-off-by: Florian Vaussard <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like we need to update various stm32 board.yaml files to say we support PWM.
Update various stm32 board yaml files to add pwm as a supported feature of the board. Signed-off-by: Kumar Gala <[email protected]>
Thank you @galak for the update. |
Is anything still blocking this PR from being merged? I'm looking forward to using some new things from this PR. Thank you very much! |
I guess that new features should not be merged before Zephyr 1.12 is released. |
Waiting for this one to be merged. Thanks! |
This patchset performs the following tasks:
Fixes #6625