On 2021-05-31 21:07, Pascal Roeleven wrote: > On 2021-05-31 06:46, Roman Beranek wrote: >> As Emil Lenngren has previously shown [1], actually only 1-2 cycles of >> the prescaler-divided clock are necessary to pass before the PWM turns >> off, not a full period. >> >> To avoid having the PWM re-enabled from another thread while asleep, >> ctrl_lock spinlock was converted to a mutex so that it can be released >> only after the clock gate has finally been turned on. >> >> [1] https://linux-sunxi.org/PWM_Controller_Register_Guide >> >> Roman Beranek (6): >> pwm: sun4i: enable clk prior to getting its rate >> pwm: sun4i: disable EN bit prior to the delay >> pwm: sun4i: replace spinlock with a mutex >> pwm: sun4i: simplify calculation of the delay time >> pwm: sun4i: shorten the delay to 2 cycles >> pwm: sun4i: don't delay if the PWM is already off >> >> drivers/pwm/pwm-sun4i.c | 56 +++++++++++++++++++---------------------- >> 1 file changed, 26 insertions(+), 30 deletions(-) > > Hi Roman, > > Thanks for your attempt to fix this. > > Unfortunately on my A10 device (Topwise A721), the controller still gets > stuck in an unrecoverable state after disabling and re-enabling the PWM > when it was already on (set in U-Boot), or when enabling it when it was > off. In this state, any changes to the period register (using devmem) > don't seem to have any effect. It seems to be stuck in the state it was > before disabling. The only thing which still works is enabling and > disabling. > > I can't reproduce this behavior manually so I'm not sure what is causing > this. > > Regarding the amount of cycles of sleep; Using a prescaler of 72000 the > PWM clock is 3 ms. Although timing tests using devmem seem unreliable > (too much overhead?), in U-Boot I need to 'sleep' for at least 7 ms > between the commands to make sure the output doesn't sometimes get stuck > in the enabled state. So in my case it seems to be at least 3 cycles. I > am not sure how reliable this method is. However even if I can get it > stuck in the enabled state using a shorter time, it doesn't cause the > behavior I mentioned before. I was always able to recover it manually. > Increasing the number of cycles to sleep therefore also doesn't solve my > problem. Until we can solve that I cannot confirm nor deny if 2 cycles > is enough. > > Regards, > Pascal
Turns out, what I'm referring to here is actually a different issue not related to this patch series. A different series might be sent later to address that. So no objections from my side for this one. Regards, Pascal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/8c3dd01c9a0b292771a3a557c247c087%40pascalroeleven.nl.
