Thread (39 messages) 39 messages, 9 authors, 2020-07-20

Re: [PATCH v5 07/13] pwm: add support for sl28cpld PWM controller

From: Michael Walle <hidden>
Date: 2020-07-15 20:41:32
Also in: linux-arm-kernel, linux-gpio, linux-hwmon, linux-pwm, linux-watchdog, lkml

Hi Uwe,

Am 2020-07-15 20:18, schrieb Uwe Kleine-König:
On Wed, Jul 15, 2020 at 07:45:10PM +0200, Michael Walle wrote:
quoted
Am 2020-07-15 18:36, schrieb Uwe Kleine-König:
quoted
On Tue, Jul 14, 2020 at 11:09:28PM +0200, Michael Walle wrote:
quoted
quoted
My wishlist (just as it comes to my mind, so no guarantee of
completeness):

 - can do 0% duty cycle for all supported period lengths
 - can do 100% duty cycle for all supported period lengths
 - supports both polarities
 - supports immediate change of configuration and after completion of
   the currently running period
 - atomic update (i.e. if you go from configuration A to configuration B
   the hardware guarantees to only emit periods of type A and then type
   B. (Depending on the item above, the last A period might be cut off.)
We actually discussed this, because the implementation would be
easier. But
if the change takes place immediately you might end up with a longer
duty
cycle. Assume the PWM runs at 80% duty cycle and starts with the
on-period.
If you now change that to 50% you might end up with one successive
duty
cycle of "130%". Eg. the 80% of the old and right after that you
switch to
the new 50% and then you'd have a high output which corresponds to a
130%
cycle. I don't know if that is acceptable for all applications.
I thought this is a "change takes place immediately" implementation?! So
these problems are actually real here. (And this not happening is
exactly
my wish here. Is there a mis-understanding?)
I wasn't talking about the sl28cpld btw. What is the difference 
between
your proposed "change take place immediately" and "after the cycle".
I understand how the after the cycle should work. But how would the
immediate change work in your ideal PWM?
If the PWM is running at 1/3 duty cycle and reconfigured for 2/3, then
the two scenarios are (the * marks the moment where pwm_apply_state() 
is
called, ^ marks the start of a period):

immediately:

  __       __    _____    _____
 /  \_____/  \__/     \__/
 ^        ^     ^        ^
                *
Ok lets assume 2/3 and change it to 1/3:

    ____     ______      __
   /    \___/      \____/  \____
   ^        ^   ^       ^
                *
This will then have a longer on period than any of the settings.
and with my ideal PWM I can choose which of the two behaviours I want.
Ahh, that I've missed.
quoted
quoted
quoted
quoted
quoted
quoted
What about disable()?
Mhh well, it would do one 100% cycle.. mhh ;) Lets see if there we can
fix that (in hardware), not much we can do in the driver here. We are
_very_ constraint in size, therefore all that little edge cases fall
off
the table.
You're saying that on disable the hardware emits a constant high level
for one cycle? I hope not ...
Mh, I was mistaken, disabling the PWM will turn it off immediately,
but
And does turn off mean, the output gets inactive?
If so you might also disable the hardware if a 0% duty cycle is
configured assuming this saves some energy without modifying the
resulting wave form.
Disabling it has some side effects like switching to another function
for this multi function pin. So I'd rather keep it on ;)
So IMHO you should also keep it on when pwm_apply_state is called with
state.enabled = false to ensure a low output.
That won't work either, because that is how you would turn on that multi
function. Ie. it is GPIO (default input) as long as the PWM is not 
enabled,
otherwise its PWM.

-michael
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help