-
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
PWM driver turns off pin if off time is 0 in set_values #1955
Comments
by Geoff Gustafson: |
by Kuo-Lang Tseng: Patch for QMSI driver posted: https://gerrit.zephyrproject.org/r/#/c/2475/ |
by Kuo-Lang Tseng: Fixed in PWM QMSI shim driver. |
by Mark Linkmeyer: Sharron LIU , this bug is in the Resolve state, but there's no label applied yet to indicate who needs to verify it. Please review is and attach appropriate label so we can get it tested and verified ASAP. Thanks! |
by ethan gao: Verified always on and always off: |
by ethan gao: If I am not wrong, I remember that QUARK datasheet requires at least > 2 clock cycle length for both on and off value, so if we set it to 0 or 1, is it really useful ? |
by Baohong Liu: ethan gao You are very right. But, some people in the community think setting "off" to 0 means always on. |
by Mark Linkmeyer: Fixing incorrect priority |
Related to GH-1731 |
Reported by Geoff Gustafson:
If you try to set a PWM to on or off all the time (with off = 0 or on = 0), in both cases the driver will see it as an error in __set_one_port() and silently turn off the pin entirely. For the "on = 0" case, this is great - this is exactly what you want. But for the "off = 0" case, this is exactly the opposite of what you want. Now, it seems the PWM can't be set to fully on, so the "best" solution is to change the pin to GPIO mode and set it high. But that may be impractical because it would presumably require including the GPIO module as well.
In any case, the documentation for the pwm_pin_set_values() function currently says nothing about this border case.
Another option may be that this function shouldn't just fail silently but rather report an error. But it strikes me that in the case of an accidental call to this function with "off = 0", it would be better to just leave the PWM in whatever state it was previously in.
But I think the best solutions are either:
I've attached a patch with solution #1 for DW and QMSI. Not sure if the problem exists in other drivers; they are different.
(Imported from Jira ZEP-401)
The text was updated successfully, but these errors were encountered: