[PATCH v3 5/5] pwm: airoha: Add support for EN7581 SoC

[Benjamin Larsson]

Hi.

On 03/09/2024 17:47, Uwe Kleine-König wrote:
> Hello Benjamin,
>
> On Tue, Sep 03, 2024 at 01:58:30PM +0200, Benjamin Larsson wrote:
>> On 2024-09-03 12:46, Uwe Kleine-König wrote:
>>> Would you please add a "Limitations" paragraph here covering the
>>> following questions:
>>>
>>>    - How does the hardware behave on changes of configuration (does it
>>>      complete the currently running period? Are there any glitches?)
>>>    - How does the hardware behave on disabling?
>>>
>>> Please stick to the format used in several other drivers such that
>>>
>>> 	sed -rn '/Limitations:/,/\*\/?$/p' drivers/pwm/*.c
>>>
>>> emits the informations.
>> The answer to your questions are currently unknown. Is this information
>> needed for a merge of the driver ?
> It would be very welcome and typically isn't that hard to work out if
> you have an LED connected to the output or a similar means to observe
> the output. An oscilloscope makes it still easier.
>
> For example to check if the current period is completed configure the
> PWM with period = 1s and duty_cycle = 0 disabling the LED. (I leave it
> as an exercise for the reader what to do if duty_cycle = 0 enables the
> LED :-) Then do:
>
> 	pwm_apply_might_sleep(mypwm, &(struct pwm_state){
> 		.period = NSEC_PER_SEC,
> 		.duty_cycle = NSEC_PER_SEC,
> 		.enabled = true,
> 	});
> 	pwm_apply_might_sleep(mypwm, &(struct pwm_state){
> 		.period = NSEC_PER_SEC,
> 		.duty_cycle = 0,
> 		.enabled = true,
> 	});
>
> Iff that enables the LED for a second, the period is completed. The
> question about glitches is a bit harder to answer, but with a tool like
> memtool should be possible to answer. Alternatively add delays and
> printk output to .apply() in the critical places.
>
>

I connected a logic analyzer to a pin and configured the pwm for it.

I then configured the pwm with these parameters (setup for 2Hz).

echo 1000000000 > /sys/class/pwm/pwmchip0/pwm12/period
echo 0 > /sys/class/pwm/pwmchip0/pwm12/duty_cycle

If I then ran the following (in a script) no pulse was detected:

echo 500000000 > /sys/class/pwm/pwmchip0/pwm12/duty_cycle
echo 0 > /sys/class/pwm/pwmchip0/pwm12/duty_cycle

If I added a sleep 1 in between I always got 1 500ms pulse.

I then did the same but with direct register access with the same 
result. Setting the duty cycle to 0 disables the pwm function on the 
pin, it seems to take a while before it properly activates but before it 
disables it the cycle completes.


I also tested with enabling the pwn signal and then setting a 0 duty 
cycle. The last observed pulse was always 500ms long.


I am not sure what of your questions this answers and is there some 
other tests I should perform ?

For the record while toggling the registers I noticed that it was 
actually possible to generate 1 second long pulses. The documentation is 
not clear on this part.

MvH

Benjamin Larsson